Goodbye .NET Standard – We Hardly Knew Ye

With the announcement of .NET 5 last year, and subsequent announcements leading up to MSBuild 2020, a big question has been what’s going to happen to “.NET Standard”. That sort of framework that’s not an actual framework just an interface that various platforms/frameworks are required to implement, but not really, and then you have to get David Fowler to do a Github Gist that gets shared a million times to actually explain to people what the hell this thing is.

Anyway. .NET Standard is no more (Or will be eventually). As confusing as it may be at first to get rid of something that was only created 3 odd years ago… It does kinda make sense to get rid of it at this juncture.

Rewinding The “Why” We Even Had .NET Standard

Let’s take a step back and look at how and why .NET Standard came to be.

When .NET Core was first released, there was a conundrum. We have all these libraries that are already written for .NET Framework, do we really want to re-write them all for .NET Core? Given that the majority of early .NET Core was actually a port of .NET Framework to work cross platform, many of the classes and method signatures were identical (Infact I would go as far as to say most of them were).

Let’s use an example. Let’s say that I want to open a File inside my library using the standard File.ReadAllLines(string path) call. Now it just so happens if you write this code in .NET Framework, .NET Core or even Mono, it takes the same parameters (a string path variable), and returns the same thing, (a string array). Now *how* these calls read a file is up to the individual platform (For example .NET Core and Mono may have some special code to handle Mac path files), but the result should always be the same, a string array of lines from the file.

So if I had a library that does nothing but open a file to read lines and return it. Should I really need to release that library multiple times for different frameworks? Well, that’s where .NET Standard comes in. The simplest way to think about it is it defines a list of classes and methods that every platform agrees to implement. So if File.ReadAllLines() is part of the standard, then I can be assured that my library can be released once as a .NET Standard library, and it will work on multiple platforms.

If you’re looking for a longer explanation about .NET Standard, then there’s an article I wrote over 3 years ago that is still relevant today : https://dotnetcoretutorials.com/2017/01/13/net-standard-vs-net-core-whats-difference/

TL;DR; .NET Standard provided a way for different .NET Platforms to share a set of common method signatures that afforded library creators to write code once and be able to run on multiple platforms. 

.NET Standard Is No Longer Needed

So we come to the present day where announcements are coming out that .NET Standard is no longer relevant (sort of). And there’s two main reasons for that….

.NET Core Functionality Surpassed .NET Framework – Meaning New .NET Standard Versions Were Hard To Come By

Initially, .NET Core was a subset of .NET Framework functionality. So the .NET Standard was a way almost of saying, if you wrote a library for .NET Framework, here’s how you know it will work out of the box for .NET Core. Yes, .NET Standard was also used as a way to see functionality across other platforms like Mono, Xamarin, Silverlight, and even Windows Phone. But I feel like the majority of use cases were for .NET Framework => .NET Core comparisons.

As .NET Core built up it’s functionality, it was still essentially trying to reach feature parity with .NET Framework. So as a new version of .NET Core got released each year, a new version of .NET Standard also got released with it that was, again, almost exclusively to look at the common method signatures across .NET Framework <=> .NET Core. So eventually .NET Core surpasses .NET Framework, or at the very least says “We aren’t porting anything extra over”. This point is essentially .NET Standard 2.0.

But obviously work on .NET Core doesn’t stop, and new features are added to .NET Core that don’t exist in .NET Framework. But .NET Framework updates at first are few and far between,  until it’s announced that essentially it’s maintenance mode only (Or some variation there-of). So with the new features being added to .NET Core, do they make sense to be added to a new version of standard given that .NET Framework will never actually implement that standard? Kind of.. .Or atleast they tried. .NET Standard 2.1 was the latest release of the standard and (supposedly, although some would disagree), is implemented by both Mono and Xamarin, but not .NET Framework.

So now we have a standard that was devised to describe the parity between two big platforms, that one platform is no longer going to be participating in. I mean I guess we can keep implementing new standards but if there is only one big player actually adhering to that standard (And infact, probably defining it), then it’s kinda moot.

The Merger Of .NET Platforms Makes A Standard Double Moot

But then of course we rolled around 6 months after the release of .NET Standard 2.1,  and find the news that .NET Framework and .NET Core are being rolled into this single .NET platform called .NET 5. Now we are doubly not needing a standard because the two platforms we were trying to define the parity are actually just going to become one and the same.

Now take that, and add in the fact that .NET 6 is going to include the rolling in of the Xamarin platform. Now all those charts you saw of .NET Standard where you tried to trace your finger along the columns to check which version you should support are moot because there’s only one row now, that of .NET 6.

In the future there is only one .NET platform. There is no Xamarin, no .NET Core, no Mono, no .NET Framework. Just .NET.

So I Should Stop Using .NET Standard?

This was something that got asked of me recently. If it’s all becoming one platform, do we just start writing libraries for .NET 5 going forward then? The answer is no. .NET Standard will still exist as a way to write libraries that run in .NET Framework or older versions of .NET Core. Even today, when picking a .NET Standard version for a library, you try and pick the lowest number you can feasibly go to ensure you support as many platforms as you can. That won’t change going forward – .NET 5 still implements .NET Standard 1.0 for example, so any library that is targeting an older standard still runs on the latest version of the .NET platform.

What will change for the better are those hideously complex charts and nuget dependency descriptions on what platforms can run a particular library/package. In a few years from now it won’t be “Oh this library is for .NET Standard 2.1, Is that for .NET Core 2.1? No, it’s for .NET Core 3+… Who could have known”. Instead it will be, oh this library is for .NET 5, then it will work in .NET 7 no problems.