The ASP.NET Core kerfuffle, explained

Since I moved over to Javaland about a year and a half ago I have been a bit out of the loop on .NET stuff. I have made token attempts to stay on top of what’s happening with .NET Core, but it wasn’t a priority so I never really made much of an effort to understand it.

However this week I noticed something major taking place on Twitter around ASP.NET and figured I would take this opportunity to get my head around exactly what is happening in .NET land, and I may as well share what I learned. I went over all of this in a hurry and while on holiday, so please feel free to correct my mistakes!

So before we get started we should define some terms. I’ll do this as concisely as possible as this has been gone over ad nauseum on other parts of the web - for a wonderful code-based example I recommend David Fowler’s GitHub gist, How .NET Standard relates to .NET Platforms (this will need to be updated for .NET Core 2.0 and ASP.NET Core 2.0).

  • .NET Standard (netstandard) - You can think of this as the API that .NET implementations (such as the full Windows-based .NET Framework, Mono, .NET Core, etc) implement. The “lowest common denominator”. Usually specified with a version (eg, netstandard1.0)
  • NetFx - Shorthand for .NET Framework foundational libraries, this refers to the main Windows-based framework of yore. Usually specified with a version a version in the format netXX (eg, net46).
  • CoreFx (netcoreapp) - The equivalent to NetFx for .NET Core. Mostly a subset of NetFx at this point, but moving faster. Both of these should implement .NET Standard. Usually specified with a version (eg, netcoreapp1.0).

So what happened this week?

In this GitHub issue a user noted that ASP.NET Core (remember, this is just a library) changed from targeting .NET Core and NetFx 4.6 to targeting only .NET Core (the user specifies the original target as netstandard, which is incorrect but only trivially so - netcoreapp and netfx are the only supported implementations of netstandard for these purposes).

So why did this cause such a kerfuffle? As a developer (I assume if you’re reading this you’re either a developer or are at least steeped in that world) you already know it’s problematic for anything to reference an implementation instead of an interface where one is available. But the problem is deeper than that - because Microsoft initially had a de facto commitment to targeting netstandard in ASP.NET, many people had already started writing their applications using ASP.NET and targeting the full framework. These applications use features of the full framework that are not yet available on netcoreapp (such as System.Drawing and System.DirectoryServices), and it’s not clear if and when such features will become available. Many of these applications are ports of full netfx apps to ASP.NET Core, which appeared to be the way forward.

And perhaps the biggest reason for the response Microsoft received from this move comes from the way it all happened. .NET Core is supposed to represent a new Miccrosoft, a Microsoft that embraces the community and works openly in collaboration with them. This move came after no community consultation and without so much as an announcement. This is not the way that people were hoping .NET Core would be run.

A resolution?

Microsoft appears to have taken feedback on board and reversed the decision to tie ASP.NET Core 2.0 to .NET Core. Although the first preview will indeed ship without support for netfx, Microsoft are now framing it as a temporary measure needed to be taken to get the bits out to devs ASAP.

It would have been nice to see a mea culpa on Microsoft’s end, rather than an attempt to make it seem like this was always the plan. It’s important that Microsoft do as much as possible to maintain developer faith in this fledgling platform, because it’s not necessarily clear that C# and .NET will remain the dominant technologies that they have become.