.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.