.NET 5 was officially released on Tuesday marking a milestone of maturity for .NET core that has been highly anticipated. This release is huge, with major new features, performance improvements, and many bug fixes. This release even includes a fix for my favorite EF Core bug #12911 which prompted me to create an open-source DevOps extension to work around it for the past 3 YEARS.
The lead-up to .NET 5 has been in the works for quite a while, with my first post being almost 18 months ago. Now that the release is real, what is next for the .NET ecosystem?
The Lifespan of .NET 5.0
Before discussing existing projects, it is important to understand the expected lifetime of .NET 5.0. Per the published support policy, .NET 5.0 is considered a "Current" support level release and will only be supported until three months after the release of .NET 6.0. Resulting in an anticipated end of support in February of 2022, only 15 months away.
There isn't anything wrong with this; however, it is important to remember that to adopt .NET successfully, we can no longer be complacent and need to balance bleeding-edge releases from long-term stability. In my consulting business IowaComputerGurus, Inc, we have decided that the benefits of being bleeding edge outweigh the drawbacks and have worked to set client expectations regarding the support burden. We are lucky, with owning multiple projects; we become very efficient in upgrading.
Managing Existing .NET Core Projects
Although each organization will be different, we can group existing .NET Core projects, and the path forward can be easier to interpret.</p
Projects on Unsupported Versions
For those with projects built on 1.0, 1.1, 2.0, 2.2, or 3.0 .NET Core, the decision is VERY simple; upgrade to .NET 5 as soon as possible. If you cannot get all-the-way there at a minimum get to a supported version NOW, I cannot emphasize this enough. Even for the most complex projects, we have found the migration documentation to be perfectly detailed and easy to understand.
If you find yourself in this situation, it will be important to look at your options to migrate to a supported version and evaluate your plans. As of November 12th, 2020, the following versions are still supported.
- .NET Core 2.1 (Supported to August 2021)
- .NET Core 3.1 (Supported until December 2022)
- .NET 5.0 (Supported until ~ February 2022)
Using this information, it is important to look back at how your existing project was left behind on an unsupported version. Was it due to a lack of understanding? A lack of budget or time? The answer to this question might dictate the best pathway forward. If you cannot secure confidence in future support, .NET Core 3.1 may be a safer bet.
All Other Projects
Given the massive improvements experienced with .NET 5.0, if you have managed a project and stayed on a current version successfully, the migration steps are trivial. I would strongly recommend moving to .NET 5.0 as soon as possible. The performance gains, bug fixes, and more will benefit your long term success.
Existing .NET Framework Projects
As a refresher, the .NET Framework's support lifecycle is dictated by the lifecycle of the underlying Operating System it was shipped with. Based on current support numbers for Windows Server 2019, this provides support through 2029 and beyond. Following this support cycle, we have a long runway to make any transition, and the type of application might dictate the best plan.
Infrequently Changed Applications
Projects with a low churn rate will most often benefit from the stability of not needing maintenance for the sake of maintenance. In these situations, it is often wise to leave these on the .NET Framework until there is a need for a major change to provide business value in transition.
WPF, WinForms, and MVC Projects
Although there are no "one-click" transition processes to move from .NET Framework to .NET 5, projects of the above types all have a .NET equivalent to that of their existing framework. Additionally, there are documented suggested pathways that can be followed to complete the transition. Underling dependencies, third-party components, and other items can cause additional difficulty as well.
Making the transition to .NET for these projects will almost guarantee substantial performance improvements and allow the latest technology to be utilized. My suggestion to customers is to complete an analysis of the effort to complete the transition as soon as possible and align implementation with a scheduled major change. I recommend this due to the need for substantial testing of the migrated application.
WebForms Projects
WebForms projects have been a cornerstone in the .NET Framework since the initial release of .NET Framework 1.0; these projects will not simply disappear overnight. However, these projects' transition is a lot like Classic ASP to .NET was; a complete re-write. Microsoft still maintains all documentation for WebForms and have simply added a note that Razor pages might be considered as an alternative.
With support until at least 2029, I cannot find a true urgency to move WebForms projects to .NET until there is a valid reason for a complete re-write. We utilize 3 & 5 year age limits and refresh requests from clients as a nice trigger point to undertake the transition. However, we are not pushing back on those that do not yet want to transition. It is known that .NET Framework 4.8 will not be getting new features, but for WebForms development, the new features would not substantially change the development paradigm and are a bit of a moot point.
This concept extends to my work with the DNN Platform open-source project as well. The transition cost just isn't possible, so the project is focusing on being the best it can be with the tools at our disposal.
New Projects
Without a doubt, new projects are a simple decision for me. As long as I don't have a compelling reason to use anything other than .NET, anything new will be .NET 5.
Reusable Libraries - .NET Standard
With any rule, there has to be an exception, right? Well, I would be doing a disservice if I didn't mention the usage of .NET Standard as a method to bridge the gap between both technologies. Both .NET Framework and .NET adhere to various versions of the .NET Standard. .NET Framework at the highest version, adheres to the .NET Standard 2.0 whereby .NET 5 is .NET Standard 2.1. Using this, you can create a Class Library that targets .NET Standard 2.0, and it can be consumed by both .NET Framework & .NET Core! Microsoft calls attention to that in the documentation in the following manner, emphasis added by me.
If you're building reusable libraries that you plan to ship on NuGet, consider the trade-off between reach and available feature set. .NET Standard 2.0 is the latest version that is supported by .NET Framework, so it gives good reach with a fairly large feature set. We don't recommend targeting .NET Standard 1.x, as you'd limit the available feature set for a minimal increase in reach.
If you don't need to support .NET Framework, you could go with .NET Standard 2.1 or .NET 5. We recommend you skip .NET Standard 2.1 and go straight to .NET 5. Most widely used libraries will end up multi-targeting for both .NET Standard 2.0 and .NET 5. Supporting .NET Standard 2.0 gives you the most reach, while supporting .NET 5 ensures you can leverage the latest platform features for customers that are already on .NET 5.
This gives a good pathway to continue to develop items with support for the new, while still supporting older technology.
Looking Forward
I can honestly say as a .NET Architect, I'm thrilled with things as they are. Over the past few years, I've been able to be more productive, deliver better performant solutions, and even deliver amazing iOS and Android applications, all with the power of .NET and not learning new languages! I'm sure we will continue to see hiccups here and there, but I'm excited for the days to come!