With .NET 5, Microsoft has introduced a new release schedule and support policy for .NET technologies. From now on, Microsoft will release a new numbered update for .NET every November and a different support policy depending on the version.
How does support work for the New .NET?
Support for the .NET ecosystem can be broken into 4 groups:
Odd-Numbered Releases: These include .NET 5, .NET 7, etc. They will each receive support until the next version of .NET is released, so about one year. In general, teams that are using the odd-numbered releases are expected to upgrade .NET with every release.
Even-Numbered Releases: These include .NET 6, .NET 8, etc. They are considered the Long-Term Support versions and are supported for three years. Microsoft chose 3 years to give teams a full year to upgrade to the next even-numbered version after its release.
.NET Core 3.1: This version of Core is still in its Long-Term Support Window until December 2022. Teams using this version have time but will want to start thinking of moving to the new .NET branch in the next two years.
.NET Framework: This is a part of the Windows Operating System and is covered by the same Long-Term Support policy of the parent operating system. While this branch will not receive any more innovation or new features, it will continue to get security updates and bugfixes for a long time.
Which New Version of .NET Should My Team Target?
Even if you know all the support policies, it is still difficult to figure out which version of .NET to target for the future. And the answer is, “it depends.” Let’s break down why you would target each version:
.NET 5, Every New Version
.NET 5 is a good target for teams looking to be always at the forefront of .NET. Targeting .NET 5 now allows you to receive the current improvements over the other available versions and sets you up to upgrade to .NET 6 easily once it’s available.
.NET 5 is also a safe choice for any CI/CD team. The faster the pace of your releases, the more likely you are in a position to upgrade versions of .NET as they come out. Upgrading is part of your culture at this point, so it makes some sense to include upgrading .NET in that process. Plus, CI/CD teams are the most likely to take advantage of the new features introduced in each version as they have the fastest release cycle.
In general, you can safely target .NET 5 if you are in a position to keep up with the new pace of .NET releases.
.NET 6, Even-Numbered Versions Only
If you don’t want to adopt a version with no Long-Term Support policy or are not ready to upgrade to .NET 5 just yet, consider .NET 6. It will include any innovations from .NET 5, new features of its own, and a 3-year support policy.
The Long-Term Support path will still require upgrading versions of .NET, the main change being you can ignore half the releases. Microsoft’s intention with the new strategy seems to be making sure teams upgrade the version of .NET regularly. This path just allows teams to update a bit less regularly.
The even release path is good for teams that need more time to adopt new releases, don’t always need the newest features, and are strict about remaining on Long-Term Support.
What About the Older Versions of .NET?
You may be curious about targeting .NET Core 3.1 or .NET Framework. After all, they’re still covered by Long-Term Support policies. But we don’t think it’s a good idea.
.NET Core 3.1
Honestly, there is no good reason to target .NET Core 3.1 for new projects. .NET 5 and .NET 6 were built on the same branch but are simply better. The performance improvements and added features are enough that the slightly longer support policy of .NET Core 3.1 compared to .NET 5’s is not enough of a good reason to target the framework. Both will have to move to .NET 6 anyway to stay on a support policy.
If you are currently on .NET Core 3.1, you don’t have to move to .NET 5 and can wait for about two more years to move to .NET 6.
.NET Framework support introduces a bizarre situation for development teams. Out of all the announced .NET Versions, it has the longest support policy. That can look really appealing to the more conservative teams that don’t want to worry about keeping up with new versions of .NET every few years. But we think targeting or remaining on .NET Framework is a bad idea.
You can make a working application for sure, and it will continue to work for a long time. Targeting .NET Framework introduces many downsides:
More Costly Developers: In general, developers like to work on newer frameworks and technologies. As other companies leave .NET Framework for newer versions of .NET, this cost is only going to go up even further.
More Costly Infrastructure: With .NET Framework, you are locked into Windows for every machine needed to run the program. You can go slightly cheaper on the new .NET by opting to use Linux for some of your servers or containers. The real cost though is efficiency. The performance benefits of the newer versions of .NET mean you can get the same performance as a .NET Framework application using less expensive hardware. Or continue to use the same hardware and get more for what you paid for.
Less Marketable Software: The performance gaps between .NET Framework and the new versions of .NET are large enough that it will be hard to compete with any competitor that makes the jump. Also, the cross-platform nature of the new .NET opens you up to a whole new market compared to .NET Framework. These differences may be enough to push consumers towards a different product.
For these reasons, you should avoid targeting .NET Framework for any new projects. As far as current .NET Framework projects go, you should consider migrating to .NET 5, .NET 6, .NET 8, or whichever version of .NET is the most feasible.
Where to Start With Transitioning Your Applications to the new .NET
The good news is that if you are on .NET Framework or .NET Core, you have a lot of time to consider upgrading. For some .NET Core projects, it may be as easy as changing the target framework to move to .NET 5. It will be slightly different for each project.
For .NET Framework, it gets complicated for applications using technologies that were not brought into the new .NET. WCF (Windows Communication Framework), WebForms, Windows Workflow Foundation, and other technologies were left behind and required developers to find adequate replacements.
Luckily, there are plenty of good replacements for WCF users, and we built a tool dedicated to helping developers use them. Rewriting these applications by hand can be really time-consuming to do by hand but can be automated with Visual Recode. If you have a WCF application and are interested in moving off of .NET Framework, you can learn more about how Visual Recode can aid your migration.