Rolling out support for .NET 6

In September last year, we released the Optimizely DXP platform for the modern version of the Microsoft .NET platform - .NET 5 (formerly known as .NET Core). This release wave included CMS version 12 and Commerce version 14 as well as platform support in our DXP cloud service.

In November Microsoft released the new version of this modern track of .NET: .NET 6. We have of course also been getting questions about .NET 6 support in Optimizely products. And specifically, whether projects on older versions (CMS 11, Commerce 13) using .NET Framework 4.x should upgrade to .NET 5 or wait for .NET 6 (spoiler: No need to wait, but also the wait is soon over).

Backwards compatibility in .NET (Core)

To understand what to expect from upgrades to .NET 5 and 6 it helps to think about their origins: .NET 5 and 6 are iterations of .NET Core, with .NET 5 following .NET Core 3.1. You can use .NET Core libraries in .NET 5 applications as long as they are not affected by any of the breaking changes in .NET 5, which are relatively few from .NET Core 3.1.

The same goes for .NET 6, it has relatively few breaking changes from .NET 5 and can use .NET 5 (and .NET Core) libraries in the same way. For example, the Microsoft.Data.SqlClient package does not contain assemblies compiled for .NET 5 or 6, since its .NET Core 3.1 assembly runs without modification in .NET 5 and 6.

In contrast, the changes from .NET Framework 4.x to the modern .NET are more significant, but hardly any difference between going from 4.x to 5 and directly from 4.x to 6.

Preparing for .NET 6, prioritizing .NET 5

Even before we released our .NET 5 support, we did test upgrades of our core packages to the .NET 6 preview version. And we confirmed our expectation that there were no major changes required. Reassured by this, we focused our efforts on tooling to support upgrades of .NET Framework solutions (CMS 11 / Commerce 13), including the newly released preview of self-service migration tooling for our cloud platform, as well as continuing to convert additional packages and addons to .NET 5.

.NET 6 wave starts today!

Today we are also announcing the first wave of support for .NET 6. This consists of two pieces:

• Version 12.4.0 of the CMS Core packages. Note that this is a minor version release, i.e. there are no breaking changes in our APIs. The package supports both .NET 5 and .NET 6 solutions through multi-targeting (including both .NET 5 and .NET 6 compiled assemblies).
• DXP cloud service support for .NET 6 solutions. Similar to the software, the platform also supports both .NET 5 and .NET 6 applications, and will automatically choose the correct runtime for your deployment package.

There is a reason I call this the first wave, and I’ll be completely transparent: We haven’t updated (or otherwise verified compatibility) all Optimizely packages yet. We are updating more packages as dependencies become available. Quite a few are under way and confirmed to not have any incompatibilities (but some require updated dependencies e.g. on Microsoft packages). We will continue to release .NET 5/6 multi targeted packages for CMS UI, Commerce, Find and select other packages in the coming weeks.

Should I choose .NET 5 or .NET 6?

The CMS Core packages we release today are the only ones that we know are affected by a breaking change in .NET 6 and hence need a .NET 6 compiled assembly to run properly in all scenarios. As far as we know all other Optimizely packages that today support .NET 5 also support .NET 6 without changes other than dependencies.

Because of this, we chose to release the first packages now so that you, depending on what packages you use, can potentially get started with .NET 6. If you are using a specific Optimizely addon or even a 3rd party package that is only compiled for .NET 5 (or even .NET Core, and certainly .NET Standard) it will most likely run fine in .NET 6 already.

If are working on a project, new or an upgrade from .NET Framework, you can continue to target .NET 5. A later upgrade to .NET 6 is likely going to be minimal effort.

Using .NET 6 today

Or if you want to, you can target .NET 6 today. Depending on what packages you use it will be more or less tricky. This is a setup I used to run a CMS site in .NET 6 on DXP today:

<PackageReference Include="EPiServer.CMS" Version="12.3.1" />
<PackageReference Include="EPiServer.CloudPlatform.Cms" Version="1.0.3" />
<!-- Extra top level dependencies needed to force CMS 6 compatible version of CMS Core -->
<PackageReference Include="EPiServer.CMS.AspNetCore.HtmlHelpers" Version="12.4.0" />
<PackageReference Include="EPiServer.Hosting" Version="12.4.0" />
<!-- Extra top level dependencies needed until our CloudPlatform and AspnetIdentity packages are updated to declare .NET 6 dependencies -->
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.Extensions" Version="6.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="6.0.0" /> 
<PackageReference Include="Microsoft.Extensions.Hosting.Abstractions" Version="6.0.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.Abstractions" Version="6.0.0" />
<PackageReference Include="Microsoft.Extensions.Options" Version="6.0.0" />

As you can see a few extra explicit top level dependencies are required to force the right versions of everything. Fewer and fewer of these will be necessary as we release packages with updated dependencies. So waiting a few weeks will make this simpler.

Minimal API:s Limitation

[Added 2022-03-28]

Note that the new hosting API using `WebApplication` that was introduced together with MinimalAPIs in ASP.NET Core 6 is not supported at this time. This is due to the a change in setup order that comes with this model which causes some issues with the way the CMS Initialization Modules currently work. So for the time being you will be limited to using the standard hosting model that relies on a separate Startup class when building your CMS applications.

Related: Resolving dependency conflits

[Added 2022-03-30]

I also recommend reading this blog post on Resolving Nuget dependency conflicts in Project SDK (PackageReference) model.

Related: Detailed .NET 6 support status

[Added 2022-09-05]

I have heard some misconceptions about our .NET 6 support, probably relating to this gradual rollout method we chose. To clarify: All packages that include a .NET 6 target are of course tested in .NET 6 and officially support .NET 6. By now this includes all of the core platform plus the absolute majority of Optimizely maintained modules and addons. You can check the status of a specific package here.