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
Zombie Properties want to Eat Your Brains

It’s a story as old as time. You work hard to build a great site. You have all the right properties – with descriptive names – that the content...

Joe Mayberry | Mar 29, 2023 | Syndicated blog

Optimizely finally releases new and improved list properties!

For years, the Generic PropertyList has been widely used, despite it being unsupported. Today a better option is released!

Tomas Hensrud Gulla | Mar 28, 2023 | Syndicated blog

Official List property support

Introduction Until now users were able to store list properties in three ways: Store simple types (int, string, DateTime, double) as native...

Bartosz Sekula | Mar 28, 2023

New dashboard implemented in CMS UI 12.18.0

As part of the CMS UI 12.18.0 release , a new dashboard has been added as a ‘one stop shop’ to enable editors to access all of their content items,...

Matthew Slim | Mar 28, 2023