.NET 6 / .NET 8 migration, downward compatible

Question

Hi, we started migrating parts of our large project from .NET 4.x to .NET 6 in beginning of 2023. When we started, .NET 8 hadn't existed. It was quite some big effort to do this. Now we will release our product soon. Until the product is at the customer it will be spring/summer 2024. .NET 6 will not be supported at the end of 2024. So the customer is just able to use the product on a supported platform for half a year, then he has to update to a newer release (that we migrated to .NET 8). A software update means quite some effort for the customer, and i think they will not be happy to know if they can just use it for a short period on a supported platform. If i understand that correct, executing .net6.0 assemblies/applications on .NET 8 runtime is not possible. So do we have to have shorter release cycles? How can we address the problem when one new .NET version (.NET 8) is arriving (but not released) and the predecessor .NET (.NET 6) is then only supported for a short period? Do we have to develop on "not-yet-released"-.NET versions and are dependent that Microsoft will stick to their schedule? Is Multi-Targeting and option? But that is quite some effort - as we still have some .NET 4.x components that require common framework assemblies... Thank you very much :-)

Answer 1

Hi @Sponsel, Carsten ,

.NET release cadence

A new major release of .NET is published every year in November, enabling developers, the community, and businesses to plan their roadmaps. Even numbered releases are LTS releases that get free support and patches for three years.Odd numbered releases are STS releases that get free support and patches for 18 months.

The release of a new version does not mean that the old version is immediately unusable.

Since .NET 8 is currently released, if you want to avoid the work of upgrading from .NET 6 to .NET 8 for your customers, have you considered providing the .NET 8 version of the app directly to your customers? Migrating between versions of .NET won't be as cumbersome as migrating from .NET Framework to .NET.

Best Regards.

Jiachen Li

---

If the answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thank you very much for your reply. I'm aware of the fact, that .NET 6 will not be usable anymore if it is out of support. But customers will not be happy running our software on an unsupported platform. Bringing parts of our product to .NET 6 was quite some big effort, which is currently finished by doing extended tests of all parts of our not so small software solution. Bringing it to .NET 8 was not an option when we started migrating from .NET 4.x to .NET 6. And bringing it now to .NET 8 is not possible for the short time until our release. Because there are some basic things to migrate from .NET 6 to .NET 8, which will not easy. We're using WCF in combination with NetDataContractSerializer. There's one alternative implementation for NetDataContractSerializer, which seems to be working fine with .NET 6 - but not with .NET 8, as there are some further removals regarding binary serialization on which the NetDataContractSerializer depends. There's no .NET 8 implementation for this. Changing our WCF interfaces to not use NetDataContractSerializer anymore would be not so easy as there are many and there's a big data model behind it, which might be changed to. Our application, and the remote interface design originated with .NET 1.0 and was initially based on .NET Remoting :-o I'm aware, that we have to find a solution for this - also because of security reasons regarding NetDataContractSerializer. But that needs some time...

Answer 3

Unlike the previous framework where the runtime was updated in place, and runtime updates were not supposed break code, .net core code is bound to the runtime version. Even runtime patches are side by side. This means for your .net 6 to run on .net 8 it must be rebuilt as a .net 8 application. The tradeoff is that runtimes are patched for security fixes, not new features, an a runtime patch is less likely to break your application.

This architecture allows the correction of runtime design issues, a real problem with the old framework. Also with .net core the compiler version is tied to a runtime, so compiler changes can require runtime changes, which allows new data types or optimization features.

in the .net core world a LTS runtime is supported for 3 years, with 1 year overlap to the next LTS. This means you product needs to updated to the current runtime every 2 years.

a benefit for your app, is to stay supported with Microsoft, the customer must stay current with you application. You no longer need to support an application that has not been updated in years.