A lot of people these days wonder whether they should go for ASP.NET MVC 5 or ASP.NET Core. This article is about my experiences and background research findings that may help people to make up their minds. It is written for people already working with the .NET stack in business environment where all decisions have complications. If you're a student wondering which to learn, the answer is simple, go for ASP.NET Core.
This article is intended to be work in progress which I'll improve according to your feedback. So let it flow in. This article may contain false information too, so tread lightly and please correct me if I'm wrong. If I haven't touched a topic you'd like to be included, please ping me about it. This isn't a light and pleasant read and it's not even intended to be such, but it should correct some common misunderstandings and shave off some time from grasping the concepts compared to finding all this information on your own.
You might have noticed I haven't said ASP.NET MVC Core even once, even though you bump into that here and there.
No ASP.NET MVC Core?
ASP.NET Core is a new open-source and cross-platform framework for building modern cloud based internet connected applications, such as web apps, IoT apps and mobile backends. ASP.NET Core apps can run on .NET Core or on the full .NET Framework. It was architected to provide an optimized development framework for apps that are deployed to the cloud or run on-premises. It consists of modular components with minimal overhead, so you retain flexibility while constructing your solutions. You can develop and run your ASP.NET Core apps cross-platform on Windows, Mac and Linux. ASP.NET Core is open source at GitHub.
This means that ASP.NET Core (not MVC) is a significant redesign of ASP.NET. There's no MVC, Web Forms, WebApi or any other project types than ASP.NET Core. What MVC is these days is a "modular component with minimal overhead". These are called Middleware Components which you can choose into your ASP.NET Core project to "construct your solution". It's "open source" running on open source platforms too, which makes it viable for those who work in public sector. All of the components are delivered though NuGet. Including ASP.NET Core itself.
No MVC 6?
As said, there's only ASP.NET Core in which you can choose to use MVC Middleware Component. After Microsoft.AspNet.Mvc 6.0.0-rc1-final, Microsoft moved towards ASP.NET Core. So ASP.NET MVC 5.2.3 is the last supported release of "Classic" MVC and will remain so.
What about ASP.NET MVC 5 Support?
According to ASP.NET Support Lifecycle Policies, Microsoft may announce the end of support for MVC 5 any time while MVC 6 is not even officially supported as its final version is only a Release Candidate. After the end of support -announcement, clock will start ticking minimum of 12 months forward. Then, that's it.
Starting with MVC 5, Web Pages 3, Web API 2 and SignalR 2 the support policy will be to support the current version and the previous version. These products are defined as "Tools" in the Microsoft Support Lifecycle Policy. A "Tool" requires a minimum of 12 months notification prior to the end of support. For more information, please see this KB article.
It is true that MVC 5 will still be supported but only on supported .NET Framework.
On August 7, 2014, Microsoft announced that support will end for .NET Framework 4, 4.5, and 4.5.1 on January 12, 2016. Customers and developers need to have completed the in-place update to .NET Framework 4.5.2 by January 12, 2016 to continue receiving technical support and security updates. Support for .NET Framework 4.5.2, as well as all other .NET Framework versions such as 3.5 SP1, will continue to be supported for the duration of the operating system support lifecycle.
This means that if a security hole if found in .NET Framework 4.5.2 forward, the operating system updates should address this until the end of the parent operating system support lifecycle in which the application is installed. As Microsoft considers the MVC 5 a "tool", it is beyond me whether or not Microsoft will address security issues in the tool itself.
What about ASP.NET Core Support?
According to .NET Core Support Lifecycle Fact Sheet.
The .NET Core support lifecycle offers 3 years of support for each Major and Minor release.
However, there's a catch.
Within the 3-year support lifecycle, systems must remain current on released patch updates for the Major.Minor release.
What this means for the current .NET Core 1.0.0 released June 27, 2016, is that it will be supported until June 27, 2019 or 12 months after next LTS release which you can look for in the .NET Core Roadmap.
Bearing this in mind, it's imperative to utilize good development practices. Including continuous integration, continuous delivery and unit testing.
Will Our Existing Libraries Support .NET Core?
That is a good question. However, it pays off to analyze the situation instead of emotionally being scared of upgrade and steer away from the task. In fact, if you have the history of keeping up to date, you won't have that problem as much as you'd anticipate. If you don't have the tendency of constantly keeping up to date, then maybe it's really the time to start doing so. Remember? The .NET Core is not anymore tied to operating system releases and is Open Source, which means the releases will come in more quickly and that will mean more frequent upgrading. This is actually the Microsoft strategy in order to keep ahead of the competition.
Fortunately you don't need to guess your libraries' compatibility or go through trial and error route, you can use the .NET Portability Analyzer which is also available on Github.
Notice how the analysis shows only .NET Framework 4.6.2 and not .NET Core? Well this is because you need to pick which target platforms to analyze from Tools > Options in Visual Studio. Yes, I said platforms and there's quite a few of them too.
Can I use ASP.NET Core targeting only .NET 4.6.2?
There was an excellent question and answer on Stackoverflow about this. As you might remember that earlier in this article I wrote that "ASP.NET Core apps can run on .NET Core or on the full .NET Framework" and that "It consists of modular components with minimal overhead".
This in practice means that the whole "ASP.NET Core" is really just a set of NuGet packages built on top of .NET Framework. Let it sink in... ...once it has and if you look at project.json file in Microsoft.AspNetCore.Mvc, you'll notice it targets both net451 and netstandard1.6. .NET Platform Standard version supports a given set of platforms, from .NET 4.5.1 to .NET 4.6.3 as well as .NET Core 1.0, UWP and what not.
You might have hard time to get your head around this but meanwhile in plain English it means you can either target your ASP.NET Core application purely on .NET Core:
"dependencies": { "Microsoft.AspNetCore.Mvc": "1.0.0", "Microsoft.NETCore.App": { "type": "platform", "version": "1.0.0" } }, "frameworks": { "netcoreapp1.0": { } }
Purely on .NET 4.6.2
"dependencies": { "Microsoft.AspNetCore.Mvc": "1.0.0" }, "frameworks": { "net461": { } }
Or both.
"dependencies": { "Microsoft.AspNetCore.Mvc": "1.0.0", }, "frameworks": { "net461": { }, "netcoreapp1.0": { "dependencies": { "Microsoft.NETCore.App": { "type": "platform", "version": "1.0.0" } } } }
So, technically speaking, if you've done your homework and kept your libraries up to date with the new .NET Framework versions, you could as well be good to go today!
What About Our Existing Investment on MVC 5?
Even if you have used ASP.NET MVC for years and have a plethora of applications running on it, I think it does not pay off to invest further on it. The switch is inevitably going to come and the sooner you start preparing, the better. It does not pay off to train your personnel on MVC 5 as it's already dead and a lot of MVC Core concepts still apply to MVC 5. Even for people actively working on MVC 5 projects that won't be migrated anytime soon, it pays off to already learn ASP.NET Core so that they can keep their MVC 5 code as compatible as possible with the ASP.NET Core.
Keep in mind that ASP.NET Core is largely based on Middleware and pretty much ditches the global.asax and HttpHandlers in favor of Middleware components doing the same thing. Grabbing the concept today with your existing MVC 5 developers will give them time to gradually switch away from the old techniques and move towards Middleware. And that can already be done with existing MVC 5 applications as it's nothing that would not work in MVC 5. So your transition could be (and should be) gradual anyway.
Should We Consider .NET Core Skills and Experience as an Asset in Recruitment?
For sure! If you hire people with long experience in .NET and skills in .NET Core, the chances are that you'll be hiring the best people who keep track of what's going on in this world. The ones that will understand the value of continuous integration, continuous delivery and automated unit testing. The ones that will maintain the code as they write new code and will always leave a file in a better shape than they started with. The ones that drive value to your business instead of keeping in the comfort zone and let things gradually rot into an unmanageable pile of technical debt which you'll have to pay one day or which will end your business.
Not to mention how cool it is to work with people who are enthusiastic.