Over the past three years I've given many talks at conferences regarding .NET Core, I've implemented many solutions for customers using .NET Core, and help consult with many organizations looking to move forward. No matter what way you slice it, it seems that .NET Core is the future, but there are still many questions out there regarding the future and how you move forward. In my time working with .NET Core I made some assumptions early on that are starting to come true. With all of the recent news and confusion, I thought this would be a good time to try and summarize where we are, and what I think it means.
I will apologize in advance for the length of this posting, it will be long, and sadly mostly if not entirely text, but I think it is important to try and centralize all of this into a single posting....so without further delay, here we go!
Recent .NET Core News
In the past few months Microsoft has released a lot of new information regarding the future direction of .NET Core, and the features that are being included in the upcoming releases. We are currently on .NET Core 2.1, with 2.2 (already at preview 3) and 3.0 coming in the near future. Looking back it has been a wild ride, as Version 1.0 was only released about 3 years ago.
I want to be explicitly clear, the information I am sharing here is all 100% public knowledge, based on news articles, upgrade experiences, and past records. I have no insider information on the direction, but if you piece together the news it is easy to see the future. For clarity a few key articles that will help to support my hypothesis.
- Update on .NET Core 3.0 and .NET Framework 4.8
- Announcing .NET Standard 2.1
- Microsoft .NET Framework Lifecycle FAQ Updated October 2018
- Microsoft .NET Core Support Policy
- A First Look At ASP.NET Core 3.0 Changes
It is from these articles that we can start to form opinions on the direction of the platforms and what it means for us as developers, implementors, and system owners.
Microsoft's Stance on .NET Framework
If you go digging into these articles, there is a very important quote from Microsoft that helps to explain future direction. It is important to start here in our understanding. Microsoft specifically has stated verbatim:
.NET Framework is the implementation of .NET that’s installed on over one billion machines and thus needs to remain as compatible as possible. Because of this, it moves at a slower pace than .NET Core. Even security and bug fixes can cause breaks in applications because applications depend on the previous behavior. We will make sure that .NET Framework always supports the latest networking protocols, security standards, and Windows features.
Now, what does this really mean? I think it is important to look at a few things to understand where this places us. To ensure we look at this fairly, we will do the same when we look at .NET Core.
Support & Lifecycle
Fundamentally this question is the biggest tell as it relates to the future of a platform. Sadly, you used to have to go digging for this to get the true picture. However, following the Lifecycle FAQ link I posted above we get this nugget of information.
Beginning with version 4.5.2 and later, .NET Framework is defined as a component of the Windows operating system (OS). Components receive the same support as their parent products, therefore, .NET Framework 4.5.2 and later follows the lifecycle policy of the underlying Windows OS on which it is installed.
Now, let's be realistic, what does this really mean for us? As I look at this, it sets a future direction that gives us a very clear path. Following the official Support Lifecycle listing we see that mainstream support ends for Windows Server 2016 on 1/11/2022 and extended support ends 1/11/2027. From this information, it is a safe assumption that we have support, in some capacity for .NET 4.6 applications until 2027, remember that for later.
Another key aspect to monitor is the development of feature enhancements, bug fixes, and related works. Microsoft already admitted that the fequency of these updates will be limited due to a desire to maintain support. That is totally fine, as most of us prefer stability anyway.
They are still working to include feature enhancements, such as UWP support, high-resolution support, and modern browser support. The key question is what do you need added to .NET Framework to accomplish your tasks? For most people, this is not a huge concern.
Microsofts Stance on .NET Core
Recent information from Microsoft finally released more details on their thoughts on the role of .NET Core. Summarized, from Microsoft to be:
.NET Core is the open source, cross-platform, and fast-moving version of .NET. Because of its side-by-side nature it can take changes that we can’t risk applying back to .NET Framework. This means that .NET Core will get new APIs and language features over time that .NET Framework cannot. At Build we showed a demo how the file APIs are faster on .NET Core. If we put those same changes into .NET Framework we could break existing applications, and we don’t want to do that.
This is where the future becomes clear! Features of .NET Core allow Microsoft to embrace change, on the surface, this sounds great....but is it? Let's look at the same additional support aspects of .NET Core.
Support & Lifecycle
Support information on .NET Core has not always been managed with the highest level of grace. Thankfully we are at a point in the lifecycle of .NET Core that we have a formal plan. However, there are two different lifecycles with different lengths of time supported.
Long Term Support (LTS) Cycle
For developers desiring the longest support terms possible it will be required to stay with LTS releases. Current .NET Core 2.1.5 is a LTS flagged release. For individuals using LTS releases Microsoft explains the lifecycle as:
Customers using LTS will need the latest patch update installed to qualify for support. If a system is running 1.0 and 1.0.1 has been released, 1.0.1 will need to be installed as a first step. Once a patch update has been installed applications will begin using the update by default. LTS releases will be supported for 3-years after general availability, or for a 12 month Maintenance period after the next LTS release ships, whichever is longer.
This gives a 3 year minimum life to any project built on a particular version of .NET Core. You can continue to use the application after the end of the LTS period, however, you will then be using an application that doesn't have Microsoft support for patching, which is a risk.
Current Release Cycle
For those that want to leverage the latest and greatest or those that want to move forward quickly they will fall under this cycle. Microsoft support notes that all of the LTS requirements apply, and:
In addition to staying current with the latest patch update, customers using Current will need to update as new minor versions are released. The latest released minor version will become the minimum serviceable baseline after release. After a 3 month Maintenance period, the previous minor version will no longer be supported. For example, after 1.2 releases systems running version 1.1 will have 3 months to update to 1.2 to remain eligible for support. Applications do not automatically begin using the new minor update.
This is KEY consideration for anyone looking to leverage .NET Core. It is possible that without notice, you will have to upgrade to a later version within 3 months. Typically these updates are less likely to break things, however, that can be a VERY quick cycle.
I'm including this discussion briefly just to keep the consistency in review between .NET Core & .NET Framework. But the reality is that .NET Core for the near future will continue to get many new features. Along with that, methodologies will continue to change and more breaking changes might be introduced so buyer beware!.
So What Does That Mean For Me?
Now that we have established common ground on the news, direction, support cycles, etc, we can have a detailed review of what this means for specific scenarios. I have had conversations with people in multiple industries, with many different background, as well as a constant discussion/argument inside of the DNN community on direction. Rather than trying to summarize in a general manner, I thought I'd go through a few common questions.<./p>
Do I need to rewrite my WebForms application
My short answer to this is NO you don't need to rewrite your application. Support for .NET Framework is guaranteed until at least 2027, this is a long, long, runway for an application. It is true that the foundation under your application might not get as many updates, but you can rest assured that the platform will have support, that you will get security patches, and your code will still be able to execute.
Future planning for these applications is important however. If there is any desire to eventually migrate to .NET Core, the application will need to be rewritten. There is no support for WebForms in .NET Core and nothing on the horizon that indicate that it would be coming.
My stance with my consulting business IowaComputerGurus has been to look at applications when they need a major facelift to migrate them to .NET Core. This is not out of necessity, but out of a desire to try and keep as many customers on the same toolset for ease of support.
I'm creating a new application, what should I use?
In my mind, this answer is quite simple, .NET Core is the future that is quite clear. However, there are certain situations whereby that might not be the best answer. Regardless if you work on the LTS or Current models with .NET Core the upgrade process is something not to be forgotten. Organizations building on .NET Core need to ensure that they have proper support to move forward with these changes. it will not be recommended to build & forget an application on .NET Core, as many organizations do today with .NET.
I have an existing .NET ASP.NET MVC application, should I move it to .NET Core
Transition to .NET Core in this situation is possible, although not automatic, it is still fairly easy to do. We have converted a number of applications and with each of them have benefitted from new features, improved performance, and a better developer experience. I would recommend that anyone with an existing MVC application migrate when possible, the transition isn't difficult and the benefits will be great.
I have an existing .NET Core application, but it runs on .NET Framework, what should I do
This situation is one of the "odd duck" situations. Early on in the .NET Core days Microsoft supported a model where you could have a .NET Core application that would run on .NET Framework. This was a bridge process and with .NET Core 3.0 it has been announced that this model is no longer going to be support for ASP.NET. This puts applications in this arena to a place where a change is mandatory, so I would recommend transitioning as soon as possible.
This transition should be much easier at this point in time however because of all of the recently added API's to .NET Core since the early days.
I'm building a new web application, what do I use?
For 99.9% of my customers this is an easy answer. .NET Core, period. My suggestion for most organizations would be to settle on LTS releases and be sure to plan your project to upgrade at least once a year because the platform is changing.
For organizations, or solutions, that do not have a method to easily adopt the changes, it might be worth considering .NET Framework for the ability to let things sit for a longer period of time without updates.
Microsoft On The Future
Another nugget of information from Microsoft regarding the future eloquently supports my above statements.
If you have existing .NET Framework applications, you should not feel pressured to move to .NET Core. Both .NET Framework and .NET Core will move forward, and both will be fully supported, .NET Framework will always be a part of Windows. But moving forward they will contain somewhat different features. Even inside of Microsoft we have many large product lines that are based on the .NET Framework and will remain on .NET Framework.
The future here is charged, there are many variables in play, and every organization is going to be different. Support policies, features, and more might push one organization in one direction and another organization in a different direction. The key is to understand what it means to be on the platform that you are on and what that means to you.
I which it was more "black and white" but the reality here is that we have great opportunities given to us, we just have to figure out how to leverage them for our particular purposes.