Try our conversational search powered by Generative AI!

Magnus Rahl
Oct 28, 2022
(6 votes)

Five, Six, Seven, (Eight) - Out With the Old, In With the New .NET

As you all probably know, Microsoft plans to release .NET 7 in November, including even more performance improvements. Although we will continue developing the Optimizely CMS and Commerce products in .NET 6, the latest LTS version, we will support running these platforms on .NET 7.

.NET LTS Versions and Backward Compatibility

Optimizely CMS 12 and Commerce 14 currently ship with assemblies compiled for .NET 6, the current “Long Term Support” (LTS) version of .NET. In contrast, .NET 7 is a “Standard Term Support” release (previously known as a “Current” release), like .NET 5 was. If you want to learn more about the difference, check the .NET support policy for details.

There is also a very high level of backward compatibility between versions of .NET, so assemblies compiled targeting an earlier version of .NET in most cases run without changes in the newer version of the runtime. In fact, not even Microsoft themselves add new compilation targets to all packages for every version of .NET. For example the latest version of the official SQL client, Microsoft.Data.SqlClient, doesn’t ship with assemblies compiled for anything newer than .NET Core 3.1, the LTS version prior to .NET 6. And it runs in all of .NET 5, 6 and 7.

For these reasons, we will continue to ship CMS 12 and Commerce 14 with assemblies compiled for .NET 6. We will not add .NET 7 compiled assemblies unless that is the only way to solve a compatibility problem.

.NET 7 Supported by Optimizely Packages and in DXP Cloud Services

We will however make some adjustments to the next versions of our packages. We have had a very cautious approach to dependencies, where we declare an upper bound to dependency version ranges to not allow using new major versions of the dependencies. While this acts as an extra layer of protection to avoid breaking changes in those dependencies (it can be overridden however), it is not considered best practice.

Not by coincidence, the change of removing the upper bound on external dependencies will allow you to run CMS 12 and Commerce 14 on .NET 7, because it will allow the 7.0 versions of many Microsoft.* and System.* packages that we depend on. We have verified these versions are compatible using the .NET 7 release candidates. These changes will be released starting with EPiServer.CMS.UI 12.14.0 and EPiServer.CMS.Core 12.11.0.

Optimizely Cloud Services also supports running .NET 7 solutions, so once .NET 7 itself and our packages with updated version ranges are out, nothing should prevent you from running on .NET 7. You are of course also free to continue running on .NET 6 as both 6 and 7 will continue to be supported until after .NET 8 arrives. If you run into any issues, as usual contact support.

Caveat: Patch awaiting .NET 7

Our testing on .NET 7 uncovered an unintended breaking change in .NET itself. This has been reported and fixed, but the fix will not be included in the initial release of .NET 7. It is currently targeting 7.0.1. If patches follow the same cadence as for .NET 6, this should be released about a month after the initial .NET 7 release. We will include a workaround for the problems it causes in CMS/Commerce, but it can cause issues with your code or 3rd party components. For that reason, we advise you hold off running production applications on .NET 7 until Microsoft releases a patched version of .NET 7.

Thank You and Good-Bye to .NET 5

Running applications in .NET 5 has been unsupported by Microsoft since May 2022, and if such applications would run into a problem, Microsoft would point to upgrading to .NET 6 as the first step of solving the problem. As long as your application is running fine, it can stay on .NET 5, but the next time you deploy you should switch to .NET 6 anyway. Therefore there is no reason for us to continue to include .NET 5 compiled assemblies in new versions of our packages. We consider this a change in dependency requirements, which is not a breaking change in Semantic Versioning. Since we have not made any breaking changes in our APIs between the .NET 5 and 6 versions, we will hence not mark this by a new major version. The change will be released in a minor version of CMS 12 and Commerce 14.

ASP.NET Core is the Name of the Game

Finally, a sidenote on naming things. As .NET Core became .NET 5 it became more difficult to contrast with .NET Framework 4.x without being explicit with versions, which eventually makes the information look stale as new versions are released. To avoid this, we’re adopting ASP.NET Core, a brand that continues to be used in .NET 5+, as a collective name for modern .NET versions when we want to contrast with .NET Framework/ASP.NET.

Oct 28, 2022


Karol Berezicki
Karol Berezicki Oct 29, 2022 08:59 AM

Thank you Magnus for this article, I was waiting for some news regarding the .NET 7, and I'm very happy that we'll be able to utilize all the awesome features and performance improvements in Optimizely :) 

Magnus Rahl
Magnus Rahl Oct 31, 2022 09:34 AM

Karol, thank you for the positive feedback. I want to take the opportunity to clarify one thing to manage expectations though: We will support any current features running in the new version, but there is no guarantee that new .NET features are compatible or that we can commit to supporting them. I have no examples of what this would be for .NET 7, but we for example had the case with Minimal APIs launched in .NET 6 which turned out to be incompatible with our initialization system.

Italo Dec 16, 2022 02:55 PM

It seems like .NET 7.0.1 was released on the 13th of december 2022

Has anyone tested if this version actually fixes the unintended breaking change mentioned in this blog? 

Please login to comment.
Latest blogs
Headless forms reloaded (beta)

Forms is used on the vast majority of CMS installations. But using Forms in a headless setup is a bit of pain since the rendering pipeline is based...

MartinOttosen | Mar 1, 2024

Uploading blobs to Optimizely DXP via PowerShell

We had a client moving from an On-Prem v11 Optimizely instance to DXP v12 and we had a lot of blobs (over 40 GB) needing uploading to DXP as a part...

Nick Hamlin | Mar 1, 2024 | Syndicated blog

DbLocalizationProvider v8.0 Released

I’m pleased to announce that Localization Provider v8.0 is finally out.

valdis | Feb 28, 2024 | Syndicated blog

Epinova DXP deployment extension – With Octopus deploy

Example how you can use Epinova DXP deployment extension in Octopus deployment.

Ove Lartelius | Feb 28, 2024 | Syndicated blog