Explaining .NET Standard Like I'm Five
.NET Core, ASP.NET Core, .NET Standard 1.1, .NET Standard 2, Netstandard, .NET Framework - so many .NETTY things, no wonder I see comments like:
“I find the netstandard thing to be awesome but at the same time a bit confusing”
Or this one:
“You can use asp.net core either with .NET Core or .Net 4.x. Talk about confusing naming…”
Oh the confusion!
I couldn’t agree more, so I did a bit of research and found a useful nugget from David Fowler that attempts to provide a mental model for the .NET Standard (also called netstandard) using code. See David Fowler’s code-based model of netstandard.
Let’s talk about how I understand netstandard and what I think it means for us as .NET developers.
What actually is .NET Standard
Well, it’s a standard, a specification.
In the same way that HTTP is a definition of structure and behavior that app developers can implement in order to be compatible with HTTP servers, .NET Standard is a standard of classes that can be implemented by platform developers so that all libraries targeting the standard are compatible with it.
For the five year olds, think of it like the shape of an electrical outlet. Here in the U.S. we have the three pronged outlet. You could think of the house as the platform, who, by choosing to implement the standard U.S outlet, is then able to work with just about every appliance (library) made in the U.S.
Why does it exist?
The .NET Standard exists for the sake of code-sharing.
.NET has been evolving rapidly, and we have many platforms - the .NET Framework, .NET Core, Xamarin, etc. For library developers wanting to create a useful tool (for example a RESTful API Client creator like RestSharp) they would need to create and build separate versions for every platform they want to support. That can be a lot of work and a lot of code to maintain.
If, instead, all the .NET platforms agree to implement the .NET Standard, the RestSharp team can simply target one version of the standard and immediately becomes available on all supporting platforms.
Back to our outlet analogy, this might be as though houses had 5 or 6 different outlet configurations, one for brick houses, one for straw houses, one for tiny houses, etc. Then the toaster company would need to create separate toasters for each type! (my analogy game is on point…)
Why do I care? What does it mean for ME?
The comments are quite useful in Fowler’s post, and so they are where my answer is mostly derived.
If you’re an application developer (like me), you don’t really need to think about netstandard. You’ll be building your app by targeting a platform (like .NET Core or .NET Framework 4.6) and when you want to use a library, tools like NuGet will manage the details and help you pick a library that works with your platform.
If you’re a library developer, you’ll get the best compatibility (folks able to use your code), by targeting the lowest netstandard version. By doing that, you’ll get automatic support by any platform implementing that netstandard version or higher.
If you’re building yet another .NET platform, you’ll want to do your best to implement the highest netstandard version you can. This will give your platform the largest set of functionality so that you can support the most amount of libraries. By doing so, you’ll also increase the amount of developers that want to use your platform.
That’s it!
What do you think? Are there angles to this I’m not seeing? How else does the netstandard benefit us? Do you see anything bad about it?