Magnus Rahl
Nov 4, 2024
  563
(2 votes)

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

Nov 04, 2024

Comments

Matthew Jimenez
Matthew Jimenez Nov 4, 2024 07:29 PM

Even if most minimal dependencies stay the same, it would nice to see the dependencies for MailKit / MimeKit to be updated. 

Mark Stott
Mark Stott Nov 5, 2024 08:34 AM

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.

Magnus Rahl
Magnus Rahl Nov 5, 2024 08:44 AM

@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?

Matthew Jimenez
Matthew Jimenez Nov 5, 2024 02:55 PM

@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

Sujit Senapati
Sujit Senapati Nov 13, 2024 11:52 PM

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/

Thomas Schmidt
Thomas Schmidt Nov 21, 2024 12:45 PM

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.

Magnus Rahl
Magnus Rahl Nov 21, 2024 01:48 PM

@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?

Please login to comment.
Latest blogs
Custom form element view in Optimizely CMS 12

Do you want full control over the form element markup? Create your own views!

Tomas Hensrud Gulla | Dec 11, 2024 | Syndicated blog

How to Elevate Your Experimentation - Opticon workshop experience

As a non-expert in the field of experimentation, I’d like to share my feedback on the recent Opticon San Antonio workshop session titled "How to...

David Ortiz | Dec 11, 2024

Persisting a Strawberry Shake GraphQL Client for Optimizely's Content Graph

A recent CMS project used Strawberry Shake to generate an up-to-date C# GraphQL client at each build. But what happens to the build if the GraphQL...

Nicholas Sideras | Dec 11, 2024 | Syndicated blog

Opti ID with Secure Cookies And Third Party AddOns

Opti ID has revolutionised access to the Optimizely One suite and is now the preferred authentication method on all PAAS CMS websites that I build....

Mark Stott | Dec 9, 2024

AsyncHelper can be considered harmful

.NET developers have been in the transition to move from synchronous APIs to asynchronous API. That was boosted a lot by await/async keyword of C#...

Quan Mai | Dec 4, 2024 | Syndicated blog

The search for dictionary key

Recently I helped to chase down a ghost (and you might be surprised to know that I, for most part, spend hours to be a ghostbuster, it could be fun...

Quan Mai | Dec 4, 2024 | Syndicated blog