Trying to understand the versioning “mess” that is .NET 2015

Right now there is a lot of talk about the next iteration of the .NET platform, and the different versions and runtimes that is about to be released. Unfortunately, it has turned into a quite complicated situation when it comes to the versions of things being released.

I get quite a few question about how it all fits together, and I try answering them as best as I can. However, as the question keeps popping up over and over again, I thought I would sum up the situation as I have understood it.

Disclaimer: Everything in this post is “as I have understood it”. I am not working for Microsoft, and I am in no way or form guaranteeing that this is the right description. This is just how I understand the situation. Hopefully it is fairly close to the real world.

Let’s start at the top…

.NET 2015

The first thing to clear up is the “.NET 2015” name. This is an umbrella name for the things that are about to be released in the .NET space. It includes a whole heap of things, including .NET 4.6, .NET Core, ASP.NET 5, which in turn contains ASP.NET MVC 6, Entity Framework 7, SignalR 3 etc. It is just an umbrella name, and not a new version name for .NET or anything like that.

.NET 4.6

Inside the .NET 2015 “release”, there is a new version of the .NET framework called .NET 4.6. It is “just” a new version of .NET, e.g. the same old .NET framework we know and love in a new version. It includes all the stuff we have today, with the addition of new features in a lot of areas. Just as we would expect a new version of the .NET framework to do.

It still includes WinForms, WPF, WCF and all the other things we are used to having.. It also includes ASP.NET as we are used to, supporting all the current stuff, such as ASP.NET MVC, WebForms etc, as well as a new ASP.NET implementation (ASP.NET 5). And as expected with a new version of .NET, there are new versions of most of the areas, including WebForms 4.6.

So just to make it clear, with .NET 4.6 you will be able to build anything you can build today, including ASP.NET WebForms application (version 4.6), which seems to be what most people are asking about.

.NET Native

This is one of the areas I know the least about, but as I understand it, .NET native is a special runtime used when building Universal Apps. Application using this runtime are compiled into native code instead of IL, and in that way offers better performance on low-power devices like phones. This means faster startup times etc. It is as far as I know only used for Universal Apps, so unless you build those, you can pretty much ignore it.

.NET Core

.NET Core is a new framework for building web- and console applications. It is a subset of the full .NET framework, a bit like the .NET Client Profile that we used to have (or might even have today). However, there are some major differences between .NET Core and anything we have seen so far in the .NET space.

The .NET Core framework is a modular framework with all of its components deployed through NuGet. This way we get framework that we can mix and match ourselves to get what we need for our applications. This in turn gives us a smaller package to deploy. Small enough to include it in the actual deployment. So when we deploy a .NET Core application, we actually deploy the “whole” framework with our application, meaning that we don’t need to install it on the machine we are deploying to. It also means that we can run .NET Core-based apps with different versions side by side on the same machine.

However, it is a subset, and a pretty small one at that at the moment. It includes the things needed to build web and console apps, and nothing else.

The parts inside this framework have been highly optimized to be as lean as possible. The goal being to make it small enough to deploy with the application, but also to make it lean enough from a performance point of view (memory etc), enabling a higher density of applications on a server.

It will probably grow in the future, but for now, it is a pretty small subset of functionality that has been “ported” to this framework.

It also has a pretty massive “kicker”. It works cross-platform, meaning that it runs on Windows, as well as Linux and Mac! However, being that it is a subset, it means that we can only run ASP.NET and console applications specifically targeted at this framework on these other platforms. It does NOT mean that we can just take any .NET app and use it on a Mac.

Unfortunately, the .NET Core framework has got the name .NET Core 5. However, it is not a next version of 4.5. It is completely separate. I do agree with some people that have suggested to name this XNET 1.0 (cross platform .net 1.0) or something to make it obvious that it is related to .NET, but no the 5th version of it.


ASP.NET 5 is a new ASP.NET implementation built so that it enables targeting both .NET 4.6 and .NET Core. This means for example that it does not have a dependency on System.Web, which has not been ported.

Note: It has some major changes in the way that it works, its feature set and so on, but that is all for another post. This post is just about trying to clear up the confusion with the versions.

When building ASP.NET 5 applications, we can choose to target .NET 4.6, and get ALL the bells and whistles that we are used to, or the .NET Core framework with its somewhat limited feature set. Or we can choose to target them both and use #IF/ELSE statements to get different implementations for the 2 different frameworks when using features that are not available on both.

At the moment, I do believe that most developers will choose to target .NET 4.6 when building ASP.NET 5 applications. Why? Well, the subset of features offered in the .NET Core framework will probably be too limiting for a lot of scenarios. And any external libraries will need to be updated to support .NET Core to be able to use them. So at least in the beginning, it will be a limited amount of third party libraries that will be abled to be added to an application targeting .NET Core.


ASP.NET MVC 6 is a completely new implementation of the ASP.NET MVC framework that we have had for a while now. However, it is built to work using both .NET 4.6 and the .NET Core framework. It has also been rebuilt as an OWIN middleware, making it possible to host it outside of the IIS. On top of that, it has also been united with ASP.NET Web Pages and ASP.NET Web Api, making them all one big, happy family.

It does include some new features like View Components, TagHelpers, attribute-based routing etc, but it seems as though most of the focus has gone into getting it to work with the .NET Core framework, which definitely is no small feat.

ASP.NET Web Api has also been changed around a bit, and works somewhat differently than before. Mostly due to the fact that is now a part of ASP.NET MVC and not its own thing with its own baseclasses etc.

Entity Framework 7 (and 6)

.NET 2015 also comes with a new implementation of EF called Entity Framework 7. However, this is not just another version. Instead, version 7 is another complete rewrite made to work on .NET Core. This means that it is a much smaller framework with some limitations.

Being that I ‘m not a massive EF person, I haven’t looked into this, but it seems as though version 7 is somewhat a step back feature-wise. However, it has the added bonus of working with .NET Core. And if you decide to target .NET 4.6 instead of .NET Core, you can still happily use EF 6 and get all the bells and whistles that you are used to.

SignalR 3

SignalR has also got a bumped version with support for .NET Core. I have not looked at all at this new version, but I do expect it to be pretty much on par with 2, but with .NET Core support. But once again, if it weren’t, you can always just target the full .NET framework and use the current version.


In this iteration, we also get a new version of C#, version 6. But that isn’t really why I have the headline C#. The reason is that I want to mention that this is all C# at the moment with no VB support. I assume this will be added in the future, but as far as I know I have heard nothing about it.


The next iteration of .NET will include some MAJOR changes. At least in the web-space. If you stay out of ASP.NET, not whole lot will change as such. It will just be another version. However, if you do wok with ASP.NET, and decide to move on to ASP.NET 5, there are some major changes. And by major, I mean MASSIVE. However, they are voluntary. You will still be able to use the current stuff if you don’t want to start targeting “the new stuff”.

It is very exciting times, with a LOT of changes on the way. Unfortunately, the versioning story has become very complicated. Hopefully it will sort itself out and become easier over time.

Comments (3) -

Good post Chris

Excellent post.  It sums up the complexity well, but I'm still trying to see how this is anything more than a solution chasing a problem.

I find it ironic that Microsoft has kept the “ASP.NET” in the new name “ASP.NET Core 1.0″. Prior to that, Microsoft called their MVC product “ASP.NET MVC”. I have thought about this quite a bit and have some thoughts on the subject.

In the beginning, Microsoft created classic ASP and it was (compared to the other technologies of the time) good. It was also immensely popular. Instead of old CGI applications, web development became easy.

Over the course of a few years, however, the spaghetti-code nature of classic ASP proved difficult to scale. Microsoft realized this and took their tremendously successful Visual Basic windows development paradigm and extended it to the web with ASP.Net. This solved many of the spaghetti code issues of by separating the presentation (HTML) from code (Codebehind). Did junior developers still put application code in form events? Yes. Did experienced developers use this to separate their UI from their application logic? Yes.

This happy state of affairs started 14 years ago and continues to this day for those who develop using web forms. The platform matured, robust 3rd party tool development took place, and there was much rejoicing.

Alas, during this time, the religious purists noted that some inexperienced programmers put business logic in their codebehind. This was an affront against the separation of concerns god which could not be permitted to stand. Over the course of years, they created the Microsoft version of MVC. No more would programmers put any business logic in their presentation tier (unless it is embedded in the Razor pages making them look suspiciously like classic ASP spaghetti).

Now, if the purists simply referred to MVC as Microsoft MVC, they knew it wouldn’t be adopted. They knew history, and saw the fate of Microsoft DNA, DCOM, Active X, .Net Remoting, etc…all technologies that were the “new way of doing things” that eventually were discarded as failed experiments. How to avoid this fate for MVC if it didn’t prove to be popular?

The easy solution is to tag it to probably their most popular development product (ASP.Net) and call it Microsoft ASP.Net MVC. By blurring the lines, they would increase adoption and funnel people into this technology whether they like it or not. Developers would think “if I don’t go this route, I’ll get left behind.” At the same time, they would kill the evil web forms and the unclean codebehind. A two-for-one.

A funny thing happened, though. People didn’t abandon web forms as the purists intended. The technology split people into two camps. The MVC camp and the webforms camp. The reason for this twofold. The first reason is that for most projects in a business environment, the people paying the bills don’t care what the technology is so long as it works and is stable. Like it or not, web forms are mature and tested. The second reason is that the MVC architecture requires a learning curve for limited benefit (other than pleasing the purists).

Here’s where it gets really funny. Now we are moving to the new version of ASP.Net. It is not only the “next new thing,” but it is a “complete rewrite from the ground up.” They are pushing this even to the point of calling it Core 1.0. However, like the push to MVC they realize that many developers would prefer to work on a mature and tested platform unless the new platform provides significant advantages (like classic ASP provided over CGI or ASP.Net provided over classic ASP).

Whatever shall we do? Of course! The new name is not Microsoft Core 1.0. It is Microsoft ASP.Net Core 1.0. Tag the .Net name to it because, let’s face it, developers like .Net. But at the same time, let’s strip it to the bone (and still not get it done on time). Let’s rip out web forms, VB.Net, etc…Wrap it in the ASP.Net wrapper and maybe we will fool those gullible developers again.

Come on, Microsoft….Just call it ASP.Net for web forms development and Microsoft MVC for MVC development. Good developers will have skills in both, but not be forced into either.

I’m glad that they are completely branching things even though they are keeping the misleading ASP.Net name. My prediction is that this branch will grow and end at the same dead-end as Active X, Microsoft DNA, etc.. in about 3-5 years. Some variation of web forms will be brought back and touted as a new feature…and the wheel continues to turn.

Maybe I’m wrong, but I’ve been doing this a long time. Time will tell.

fred grabbe 6/17/2017 11:08:55 PM

Great writing, I am looking foward to following your blog on a regular basis

Add comment