We are four months into the new version of .NET. In November of 2020, Microsoft officially released .NET 5 with a pretty decent amount of fanfare. But that doesn’t mean everyone has moved away from .NET Core or .NET Framework, or even thought about it. The holiday period and months after are often hectic times at many organizations. A stable and reliable application is a much greater priority than instantly migrating to the newest version of any technology.
Now that the dust is beginning to settle and folks have had time to look at .NET 5 in action, it’s a natural time to start thinking of what version of .NET will best support your future goals. One place to begin this process is to look at how Microsoft views the future of .NET, and we can use their support policies to do so.
What are the Current Support Policies?
The graph above shows the .NET Support periods from 2020 through the next five years. Note that the support periods for .NET 10 and .NET Framework go beyond the period of the graph.
Microsoft has developed a new release frequency for .NET, with a major release coming out about once a year. With this comes a group of new support policies:
.NET Framework: It’s part of the Windows Operating System and is covered by the same Long-Term Support. 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. Microsoft is keeping it around.
.NET Core 3.1: This version of Core is still in its Long-Term Support window until December 2022. Microsoft is staying true to the support terms they set in the past for .NET Core, but 2022 will come sooner than we think. Teams using this version should start planning for the end of .NET Core support now.
Odd-Numbered New Releases: These include .NET 5, .NET 7, .NET 9, etc. They will each receive support until the next version of .NET is released, so about one year. In general, Microsoft expects teams using the odd-numbered releases will upgrade .NET for every major release.
Even-Numbered New Releases: These include .NET 6, .NET 8, .NET 10, etc. They are considered the Long-Term Support versions and are supported for three years. Microsoft chose three years to give teams a full year to upgrade to the next even-numbered version after its release.
In general, the support policies suggest that regular upgrades will become part of .NET Development for all but .NET Framework users. Long-Term Support is now shorter, support for odd-numbered releases is a single year, and .NET Core will soon be completely unsupported. But let’s dig in a little deeper and study what these support periods suggest for the future of .NET applications.
What Does This Mean for New Applications?
If you are developing a new application or plan to do so soon, you should be targeting the new .NET branch and avoid using .NET Core 3.1 or .NET Framework. Whether you should choose to adopt .NET 5 or .NET 6 will vary from company to company.
.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 most CI/CD team. The faster the pace of your releases, the more likely you are in a position to make changes 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 target .NET 5 if you are in a position to keep up with the new pace of .NET releases.
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 allows teams to update a bit less often. The even release path is suitable for teams that need more time to adopt new releases, don’t always need the latest features, and are strict about remaining on Long-Term Support.
What Does This Mean for Established Applications?
For established applications, whether you need to upgrade right now or not will depend on which version of .NET you are using and your plans for the application:
Applications on .NET Core
Companies on .NET Core should be making plans for their applications before the support period is over. It’s not like your application will break down the day support ends, but .NET Core will stop receiving bugfixes, and your application will be at greater risk for security complications. Any bug, breach, or issue with .NET Core will be entirely on you to resolve.
For any established application you want to develop beyond the next two years, you will wish to upgrade it to .NET 5 or .NET 6. The good news is that the new .NET branch (.NET 5, .NET 6, etc.) is actually a continuation of .NET Core, just with a new naming scheme (because Microsoft loves to throw some curveballs when it comes to naming conventions for their products). Moving from .NET Core to .NET 5 or .NET 6 should be more like an upgrade than a complete migration or rewrite.
Applications on .NET Framework
Microsoft is committed to keeping .NET Framework functioning for as long as it is part of the Windows OS. So, in theory, you can safely keep your application on the platform for ten or more years. But by doing so, you are committing to developing on a legacy technology, which introduces some complications:
More Costly Developers: In general, developers like to work on newer frameworks and technologies. As other companies leave .NET Framework for more recent versions of .NET, this cost will only go up even further.
More Difficult Changes: Want to add new functionality or fix a bug with your .NET Framework application? Right now, that’s not too hard. But as .NET Framework loses users and knowledgeable developers, you either will have to hire the expensive developers we discussed in the previous point or have less experienced developers spend much more time applying changes, learning .NET Framework as they go. The good news is that the documentation is not getting set on fire, so there will still be plenty of references for them to use. But over time, they may become harder to find.
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.
Many companies use legacy software and continue to find success but know the complications that come with it.
What does .NET 5 Mean for VistaDB?
For us, it means building VistaDB to support the new .NET branch, starting with .NET 5 support, which will ship in VistaDB 6.1.
But we know that many .NET developers will continue to use .NET Framework and .NET Core, and we plan to continue to have a product that allows them to build the best applications possible, no matter the platform.
If you aren’t familiar with VistaDB, it is embedded database software for .NET developers. You can learn more here or give it a try for yourself with our free trial.