November Happy Hour will be moved to Thursday December 5th.

Magnus Rahl
Nov 4, 2024
  391
(2 votes)

.NET 8 FAQ

I have previously written about .NET compatibility in general and .NET 8 in particular, see blog posts here, here and here. With the end of support date for .NET 6 coming up this month we have seen questions pop up again. So in addition to linking back to those previous articles I figured I would type up an FAQ style post that I can keep adding to.

What does it mean for a .NET version to reach end of support?

The runtime for supported .NET versions receive patch updates with the Microsoft monthly "Patch Tuesday" release schedule. These can contain fixes e.g. for security or other severe issues. These are 100% backwards compatible, so an application just needs to be restarted on the new runtime version to get these updates.

When a .NET version reaches end of support, it will no longer be serviced with patches. If your application is affected by a new problem found, and Microsoft decides to fix the problem in a new patch, they will direct you to update your application to run on a supported version, e.g. switching to .NET 8 when .NET 6 is out of support.

Is it a problem to run on a .NET version that has reached end of support?

This really depends on whether there is a not-yet-patched issue found in the unsupported version, and if that issue affects you. Pratcially, until such a thing happens, you don't have a problem. But the advice is definitely to stay current, if nothing else then to more easily take a patch update should you be affected by a new issue.

Does Optimizely CMS and Commerce Connect support running in .NET 8?

Yes. As outlined in the articles linked at the top of this article, we have validated CMS and Commerce running on .NET 8 even prior to the release of .NET 8, and found no compatibility issues. By now, we also have several hundred of CMS and Commerce applications running in our DXP Service on .NET 8 which further builds confidence that there is a very high level of compatibility.

But when I look in the nuget packages, it says they target net6 still, what does this mean?

It means CMS 12.x and Commerce 14.x are still built using the net6 target framework, targeting the .NET 6 API. But with the high level of backwards compatibility in .NET (Core) you can still target your application to net8 and it will run using the .NET 8 runtime (including on DXP which detects this from your runtimeconfig.json). Referencing libraries originally built for older target framework is not a problem as long as those libraries are not affected by any of the very limited breaking changes in the newer .NET version. Remember that .NET builds to IL code and is JIT compiled, so it will essentially be both compiled and run in the newer .NET 8 version.

Will you ever change to target net8?

Yes, in the next major version (e.g. CMS 13). Changing the target framework is technically a breaking change (requiring a new major version) and adding a target frameworks can add significan development and testing overhead with multi-targeted code, as outlined in the links at the top of this post, we won't do it until it is required to overcome a major incompatibility. Something that we feel more and more confident will not be needed.

What should I do about Microsoft packages, such as the Microsoft.Extensions* packages? They seem to be versioned with .NET.

CMS and Commerce make use of several of the Microsoft.Extensions.*, Microsoft.Data.SqlClient and other Microsoft provided packages. You get these as transitive dependencies in your solution when you have CMS or Commerce packages. These have a package version that tracks the .NET 8 version, e.g. a wave of packages with Nuget version 8.0 were released with .NET 8. CMS and Commerce still references the 6.0 versions as the minimium requirement. I.e. you can reference these packages directly and through that force a higher version.

Beware however that new major versions of these packages also mean they may have breaking changes. We have done basic testing with the 8.0 packages and not found any issues. But at this time I would advice you to leave these transitive dependencies as-is as the default option.

Added Q: What about .NET 9?

DXP platform supports the .NET 9 runtime and CMS is working in .NET 9 according to preliminary testing. Commerce Connect however has a known incompatibility that we are looking to address. For now our recommendation is to keep production workloads on the LTS release .NET 8.

I have other issues or questions.

If you run into any issues, as usual contact support.

Nov 04, 2024

Comments

Matthew Jimenez
Matthew Jimenez Nov 4, 2024 07:29 PM

Even if most minimal dependencies stay the same, it would nice to see the dependencies for MailKit / MimeKit to be updated. 

Mark Stott
Mark Stott Nov 5, 2024 08:34 AM

Great post, and thank you for sharing.

I have a test CMS instance running on .NET 8 on a Linux Azure WebApp and I'm currently involved with a .NET client build that is using .NET 8.  I haven't observed any any issues with the Optimizely functionality running on the latest version of CMS 12.  But I would advise that you check what additional AddOns you install to ensure that they too are .NET 8 ready.

One hurdle I found was a breaking change in .NET Entity Framework moving into .NET 8.  I observed this with the EF migrations functionality.  Which is why I updated my Stott Security AddOn to dual target both .NET 6 and .NET 8 earlier this year.

Magnus Rahl
Magnus Rahl Nov 5, 2024 08:44 AM

@Matthew I took a look and saw that there are 4.x versions that are outside our dependency range. I wasn't able to find any information about what the breaking changes are though, so difficult to even guess how much work it could be, or if we could even just open up the dependency range and allow you to update at your own risk. Could you elaborate on if there is a specific reason you want the newer version?

Matthew Jimenez
Matthew Jimenez Nov 5, 2024 02:55 PM

@Magnus - I've built packages for my company used for all our .NET apps using MailKit 4.x, and would like to avoid lowering the dependency version as there is a vulnerability with high severity for MimeKit versions < 4.7.1

Sujit Senapati
Sujit Senapati Nov 13, 2024 11:52 PM

Not sure if you have started looking into .NET 9. I updated one of our client solution to .NET 9 and it worked well with Framework 12.21.7 but failed to work with 12.22.0. See here the error: https://world.optimizely.com/forum/developer-forum/cms-12/thread-container/2024/11/-net-9-platformnotsupportedexception-binaryformatter-serialization-and-deserialization-have-been-removed/

Please login to comment.
Latest blogs
Set Default Culture in Optimizely CMS 12

Take control over culture-specific operations like date and time formatting.

Tomas Hensrud Gulla | Nov 15, 2024 | Syndicated blog

I'm running Optimizely CMS on .NET 9!

It works 🎉

Tomas Hensrud Gulla | Nov 12, 2024 | Syndicated blog

Recraft's image generation with AI-Assistant for Optimizely

Recraft V3 model is outperforming all other models in the image generation space and we are happy to share: Recraft's new model is now available fo...

Luc Gosso (MVP) | Nov 8, 2024 | Syndicated blog

ExcludeDeleted(): Prevent Trashed Content from Appearing in Search Results

Introduction In Optimizely CMS, content that is moved to the trash can still appear in search results if it’s not explicitly excluded using the...

Ashish Rasal | Nov 7, 2024

CMS + CMP + Graph integration

We have just released a new package https://nuget.optimizely.com/package/?id=EPiServer.Cms.WelcomeIntegration.Graph which changes the way CMS fetch...

Bartosz Sekula | Nov 5, 2024

Block type selection doesn't work

Imagine you're trying to create a new block in a specific content area. You click the "Create" link, expecting to see a CMS modal with a list of...

Damian Smutek | Nov 4, 2024 | Syndicated blog