.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. Practically, 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 significant 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 advise 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.
Even if most minimal dependencies stay the same, it would nice to see the dependencies for MailKit / MimeKit to be updated.
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.
@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?
@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
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/
Will you at some point add support for usingWebApplication.CreateBuilder(args); in Program.cs to configure things instead of little more old-school Program.cs/Startup.cs ways of doing things? Would make it a bit easier to move forward to DistributedApplication.CreateBuilder(args); for some Aspire fun.
@Thomas We know we don't necessarily support all new features. There are a lot of things we want to do of course, and feedback is always welcome. Can I ask you to register this at our Customer Feedback portal please?
Adding a comment here in case someone finds this in the hunt for .NET version support.
CMS 13 is now released and supports (requires) .NET 10. Given the relatively short time left on .NET 8 support we are however going to validate .NET 10 support in CMS 12 too in Q2. Some very early indications it just works, but we need to cover a bit more thoroughly. And if we find things that actually need to change to make it work, we might first try to fix those without changing the compilation target. If we need to change compilation target we'll simply have to move to require .NET 10 in a CMS 12 minor release as we get closer to .NET 8 EOL in November.
For Commerce, Commerce 15 should be releasing soon with the same support/requirement as CMS 13. For Commerce 14 we know we need to make changes, but the work of validating/adapting Commerce 14 to support .NET 10 is also scheduled for Q3.
Thank you Magnus, Honestly I don't see an issue with requiring a higher .NET version in a future minor release and would welcome it.
Yes, technically it's a breaking change, but jumping version numbers for every .NET release is also overkill and only adds complications if there are multiple CMS versions in active support.
Thank you Mark, that is our thinking as well and it means a lot to get validation of that plan. Multi-targeting adds a lot of work so we want to avoid that. But we don't think that anyone would really care that we drop support for an EOL framework like net6 even though it is technically breaking, and stretching that just a bit more we can apply the same reasoning to net8 slightly in advance. Anyone can still continue to run on net8, just not on the absolutely latest CMS 12.x minor.