So the release of .Net Core 2.0 in the third quarter of 2017 will most likely be viewed as a watershed moment in its evolution. This is a pretty bold statement but having worked with it on and off again over the last 2 years it comes with one feature that anybody that has real world experience of working with .Net Core (or even Asp.Net 5 for web development before Core was Core) will appreciate and that is it implements .Net Standard 2.0.
Fun and frustration in equal measures
So .Net Core is effectively a rewrite of the .Net Framework from the ground up this is no small task.
Now using it in the context with MVC 6 was pretty amazing at first. Lots of the new features were simply common sense like the unification of MVC and Web API, built in dependency injection and a ton of other stuff that just made sense and fits into the modern world of things such as cloud first, scalable, environment agnostic applications.
The first time you see a .Net web app running on OSX scaffolded using a Yeoman generator you realize how far things have changed and perhaps it's the first time you realize that we are truly no longer tied to Windows or IIS anymore. (Which is great given the number of .Net devs I know that own a MacBook)
This was all well and good at home but once your team actually tried to do something like work with a legacy system then things became a bit more difficult.
Familiar APIs were missing and NuGet could feel like an abandoned village from a western complete with rolling tumbleweed.
A brave new world
Now whilst one might feel that .Net Core is a great choice for GreenField projects, the newer system that may be replacing an older system, may still rely upon another old system or data source that is not being replaced along with it. This is a scenario where the standard developer might lean on their experience of the million and one ways to process XML or deserialize data in the .Net Framework, but alas, most of these were gone!
Now, we all have our favorite packages that we rely upon to make our job that bit easier. However, most of these were written for the full-fat .Net Framework and were therefore not available anymore.
So whilst the language was familiar and the Web framework was awesome it was very much like having the wind taken from beneath your wings. Us developers don't like change half as much as the industry forces it on ourselves ;-).
Realistically as a .Net developer, what you want is one framework that executes on multiple platforms. Whilst it's perfectly reasonable to assume that the UI layer (Asp.Net MVC, Xamarin - of various flavors or UWP) will be different between platforms and target devices, it would really suck if there were going to be huge inconsistencies for everyday bread and butter tasks. Fortunately, there is a solution for this...
.Net Standard - One common set of APIs, multiple platforms
So the previous way of sharing code across multiple platforms was the Portable Class library, and it kinda sucked. The more platforms you attempted to support the fewer APIs you could access. Working with the lowest common denominator just doesn't scale.
.Net Standard effectively inverts this. It defines a set of APIs that all .Net platforms can implement. With each release of .Net Standard the number of APIs has increased.
Return of some familiar friends
So on a basic level, this should mean we are guaranteed to have some 32000 + APIs on all of the major .Net Platforms that implement .Net Standard 2.0.
So tasks that were previously troublesome such as:
should, in theory, become much easier. This should remove a lot of the feelings of impedance that may have existed, and therefore serve to embolden teams to make the move between platforms.
Changing the game for NuGet
Whilst .Net Standard has been around for about a year or so, V1.x had a serious limitation. This was that a library targeting .Net Standard could only reference other libraries targeting .Net Standard or Portable Class Libraries.
Over all this meant that NuGet for .Net Core (at least compared with .Net Standard) felt like:
Now via a compatibility shim made available libraries targeting .Net Standard 2.0 can reference:
- Portable class Libraries
- .Net Standard Libraries
- .Net Framework libraries (using 4.6.1, provided the library uses APIs that are part of .Net Standard)
This brings into play a purported 70% of current NuGet packages and in theory, means that making many of the existing non-compatible packages work with .Net Core a much easier task as well.
Suddenly Nuget feels like a more abundant and vibrant place once again.
Not quite lift and shift
Now just before we get all euphoric about all the trouble of the world being solved we are not quite at the stage where existing applications can be lifted and shifted.
For example, MVC 6 and EF Core are very different beasts to their predecessors. Consequently, many of the APIs are similar but not the same or use slightly different constructs.
Still, this should make moving large parts of existing code bases much easier. You were, after all, separating your concerns, weren't you? (Well we'll soon find out anyway!)
The level of familiarity that .Net Core 2.0 will offer development teams due to the fact it implements .Net Standard 2.0 is huge. The familiar APIs and increase in the availability of existing NuGet packages should really help teams make the move to using .Net Core.
.Net Core is the future of Asp.Net Web Development as well as Windows development (on desktop and beyond). By giving teams and enterprises the ability to choose a version that lets them leverage a huge amount of existing knowledge and code, the release of .Net Core 2.0 feels like a breakout moment that will see it become, in time, the default choice for the masses. It now offers the right balance of new features, performance gains, and general improvements, whilst allowing developers to retain enough to make the leap of faith that is required to brave the new world.