Explaining .NET Standard Like I'm Five(miniml.ist)
miniml.ist
Explaining .NET Standard Like I'm Five
http://miniml.ist/dotnet/explaining-dotnet-standard-like-im-five/
30 comments
Haha, it's funny how it's so much clearer in code than in normal language.
I got the idea of what .NET standar is, the confusing part is the versioning, they have version of .NET standar, version of .NET Framework, version for Mono, version for .NET Core, version for the tooling, version for the libraries in project.json (now extint) etc, and all with different release schedules, that is the most confusing part and I stil not getting it.
It's a cluster. The way Microsoft rolled out .NET Core and all these related technologies did nothing but confuse everyone, even seasoned .NET developers and architects such as myself. The name changes, horrible Visual Studio tooling, version numbers with seemingly no rhyme or reason...it's been a nightmare.
They are finally clearing things up with .NET Standard 2.0, which is like the One Standard to Rule Them All. I consider .NET Standard 2.0 and its related implementations, along with Visual Studio 2017, to be the first real production-ready set of standards, tooling, and frameworks. It's what .NET Core should've been from the very beginning.
They are finally clearing things up with .NET Standard 2.0, which is like the One Standard to Rule Them All. I consider .NET Standard 2.0 and its related implementations, along with Visual Studio 2017, to be the first real production-ready set of standards, tooling, and frameworks. It's what .NET Core should've been from the very beginning.
I often wonder why did they decide to introduce such complexity with all independently developed runtimes with unrelated versions and all if they went fully open source. This problem that they have solved in their own unique way has been solved before countless times. Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.
Now we have so many different versions to follow that I am really worried it will be impossible to keep any level of uniformity and compatibility between them. There are .NET Standard, Canadian, .NET Core, Mono, .NET Framework with .NET Standard's compatibility shim and .NET Core tooling. I hope I didn't forget anything else. It's already crazy as it is.
I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.
Now we have so many different versions to follow that I am really worried it will be impossible to keep any level of uniformity and compatibility between them. There are .NET Standard, Canadian, .NET Core, Mono, .NET Framework with .NET Standard's compatibility shim and .NET Core tooling. I hope I didn't forget anything else. It's already crazy as it is.
I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.
> .NET Standard, Canadian, .NET Core, Mono, .NET Framework
Ahh yes, good old .NET Canadian. It's exactly the same as normal .NET, except all methods and properties referring to 'Color' have been changed to 'Colour'.
As a Canadian .NET developer, this has caused me endless headaches when trying to pull in American graphics libraries via NuGet.
Ahh yes, good old .NET Canadian. It's exactly the same as normal .NET, except all methods and properties referring to 'Color' have been changed to 'Colour'.
As a Canadian .NET developer, this has caused me endless headaches when trying to pull in American graphics libraries via NuGet.
Autocorrect got me there and I could not figure out how to edit the comment. I forgot what I meant to write there if anything but the point stays the same.
I figured you were a victim of autocorrect. I was just having a bit of fun with it.
I thought you might have been taking about the .NET Foundation but made a typo and it got mangled by autocorrect.
Regardless, I agree with your point. The name of things in the .NET ecosystem is a bit confusing right now.
I thought you might have been taking about the .NET Foundation but made a typo and it got mangled by autocorrect.
Regardless, I agree with your point. The name of things in the .NET ecosystem is a bit confusing right now.
[deleted]
«I often wonder why did they decide to introduce such complexity with all independently developed runtimes with unrelated versions and all if they went fully open source.»
Most of the runtimes were developed evolutionarily for different system niches, well before .NET was given the option to be open source by default. .NET Core tried to reboot some of the "organic" evolutionary tech debt of several runtimes it was directly replacing/built from (the Silverlight runtime; the old Windows Phone runtime; the WinRT .NET runtime).
«Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.»
Python still has multiple runtimes and some small amounts of confusion: CPython, Pypy, Stackless, IronPython, Python on Parrot... They don't/haven't all support the same version of the language and CPython has always been the "official standard" version, but Python is an example that no language is entirely immune from multiple runtimes either.
«I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.»
I don't think .NET Core was in a rush to release an "unfinished product", though it may seem to for a long term .NET developer. .NET Core has been the first runtime allowed to develop out in the open, as open source. It took about the same development time, I'd estimate, as the most similar projects you could imagine. But instead of showing up "out of nowhere" in VS 2017 Preview 1, mostly complete, we saw a lot of the little and big decisions along the way. Because it was .NET and promising big things I think .NET Core got a lot more early scrutiny by the .NET developers in what was closer to the equivalent of Python's "PEP development" phase, to use Python as the analogy, than .NET Developers had ever seen before.
Most of the runtimes were developed evolutionarily for different system niches, well before .NET was given the option to be open source by default. .NET Core tried to reboot some of the "organic" evolutionary tech debt of several runtimes it was directly replacing/built from (the Silverlight runtime; the old Windows Phone runtime; the WinRT .NET runtime).
«Python is a great example, since you have your standard library with some rather carefully selected OS-specific APIs and then you got a bunch of runtimes all under the same version; no confusion whatsoever.»
Python still has multiple runtimes and some small amounts of confusion: CPython, Pypy, Stackless, IronPython, Python on Parrot... They don't/haven't all support the same version of the language and CPython has always been the "official standard" version, but Python is an example that no language is entirely immune from multiple runtimes either.
«I am a long time .NET developer and I also was confused in the beginning of .NET Core about what was going on and I think their rush to release an unfinished product was to blame.»
I don't think .NET Core was in a rush to release an "unfinished product", though it may seem to for a long term .NET developer. .NET Core has been the first runtime allowed to develop out in the open, as open source. It took about the same development time, I'd estimate, as the most similar projects you could imagine. But instead of showing up "out of nowhere" in VS 2017 Preview 1, mostly complete, we saw a lot of the little and big decisions along the way. Because it was .NET and promising big things I think .NET Core got a lot more early scrutiny by the .NET developers in what was closer to the equivalent of Python's "PEP development" phase, to use Python as the analogy, than .NET Developers had ever seen before.
Just wait until it gets renamed to something like .NET Foundation 1.0 (comprising ASP.NET Foundation 1.0 and .NET Foundation Runtime 1.2 because reasons) aaand we're back to square one.
Well yes because .net standard is simply the specification, and .net framework, mono, core etc are the implementations.
Think about it in a web sense. We have ECMAScript which is slowly being added to. ECMAScript is the specification and it has it's own version. Then we have browsers that "implement" that specification and they also have their own version numbers because they aren't ONLY building something to handle ECMAScript, they are building other features on top of that.
So in terms of .Net Core vs Mono for example, while they both may implement the .net standard, they can also have their own features unique only to one. It's not a straight implementation with nothing else added.
Now say you are building a website and you want to target all "modern" browsers. It doesn't matter what version of ECMAScript is up to, it matters what each browser has so far implemented. If you are building a library for .net, then you can say "OK, I implement this standard. That means Mono Version X and .net Core version Y can be used". Similar to how you would say "You need Firefox version X or Chrome verson Y to use this feature".
Think about it in a web sense. We have ECMAScript which is slowly being added to. ECMAScript is the specification and it has it's own version. Then we have browsers that "implement" that specification and they also have their own version numbers because they aren't ONLY building something to handle ECMAScript, they are building other features on top of that.
So in terms of .Net Core vs Mono for example, while they both may implement the .net standard, they can also have their own features unique only to one. It's not a straight implementation with nothing else added.
Now say you are building a website and you want to target all "modern" browsers. It doesn't matter what version of ECMAScript is up to, it matters what each browser has so far implemented. If you are building a library for .net, then you can say "OK, I implement this standard. That means Mono Version X and .net Core version Y can be used". Similar to how you would say "You need Firefox version X or Chrome verson Y to use this feature".
I have exactly zero faith that they won't abandon this in a few years and come out with something that does the same thing in a different and incompatible way. Their mode of operation seems to never stick to something but instead replace it with something similar. The only reliable entities are Win32 and the .NET framework. .NET Core, Standard, UWP and whatever are just short lived experiments.
I can dig out examples for Apple and Google as well.
All big corporations are like that.
All big corporations are like that.
I can see .Net core eventually covering everything in framework other than windows specific bits, and desktop UI.
UWP, Xaml, and Mono could then become libraries as expansion on .Net core.
UWP, Xaml, and Mono could then become libraries as expansion on .Net core.
IIRC, .NET on UWP apps already are using .NET Core inside, at least if they are using the .NET Native toolset which is built on/from .NET Core.
That doesn't help anyone that thinks UWP itself is a "fad" (as in the GP comment) think .NET Core might not be a fad too, but UWP seems to be here to stay despite how many ancient developers seem to have "Win32 or Die" tattoos.
That doesn't help anyone that thinks UWP itself is a "fad" (as in the GP comment) think .NET Core might not be a fad too, but UWP seems to be here to stay despite how many ancient developers seem to have "Win32 or Die" tattoos.
Microsoft is one of the worst when it comes to naming products across the entire company, but doubly worse with the development offerings.
They could/should just hire a single person who manages all the naming and it would probably pay back 1000x in productivity increases.
They could/should just hire a single person who manages all the naming and it would probably pay back 1000x in productivity increases.
I don't get it. Why all the articles and tweets and presentations on what .NET Standard is? Why is it so confusing that it needs so much explaining?
Genuinely asking this as an outsider that has an interest in .NET and that follows some .NET blogs and twitter accounts.
From what I understood .NET Standard is a specification for the set of APIs that are supported across .NET runtimes. Well, OK, it is a little confusing since I thought .NET itself was supposed to be that standard, but I guess it got fragmented with all those new platforms being supported and now they need some common API. But are people having so much trouble understand this?
Genuinely asking this as an outsider that has an interest in .NET and that follows some .NET blogs and twitter accounts.
From what I understood .NET Standard is a specification for the set of APIs that are supported across .NET runtimes. Well, OK, it is a little confusing since I thought .NET itself was supposed to be that standard, but I guess it got fragmented with all those new platforms being supported and now they need some common API. But are people having so much trouble understand this?
I think some of the confusion comes from people trying to follow old standards (PCLs and PCL profiles) and the bouncing standards as they were being developed and settled on, all at roughly the same time.
For instance, there was a brief point where .NET Core itself was expected to be the .NET "standard bearer" and specification versions might have been derived from it [1]. That idea didn't last because it didn't well account for the history/current states of the other runtimes (.NET Framework, Mono/Xamarin), but I think it did leave lasting and confusing scars amongst some of the vanguard bloggers.
[1] And basically were; the 1.x sequence of .NET Standard do more directly correspond to a subset of the .NET Framework and .NET Core intersection as viewed from the lens of .NET Core, which is part of the compatibility break between 1.x and 2.0 in .NET Standard versions...
For instance, there was a brief point where .NET Core itself was expected to be the .NET "standard bearer" and specification versions might have been derived from it [1]. That idea didn't last because it didn't well account for the history/current states of the other runtimes (.NET Framework, Mono/Xamarin), but I think it did leave lasting and confusing scars amongst some of the vanguard bloggers.
[1] And basically were; the 1.x sequence of .NET Standard do more directly correspond to a subset of the .NET Framework and .NET Core intersection as viewed from the lens of .NET Core, which is part of the compatibility break between 1.x and 2.0 in .NET Standard versions...
It's not that complex but I think it's just that .NET naming and versions are currently quite confusing. I did a lot of reading on this for the book I wrote and I still find I need to double-check things.
I guess this is what you get when you try and munge three platforms together. Package support is very important for uptake and many library authors were waiting for some stability. I found this out when researching the support matrix at https://anclafs.com.
If you look at the volume of MS docs on this you would be forgiven for thinking it's complicated:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...
https://github.com/dotnet/standard/blob/master/docs/faq.md
https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
https://blog.xamarin.com/net-standard-library-support-for-xa...
I guess this is what you get when you try and munge three platforms together. Package support is very important for uptake and many library authors were waiting for some stability. I found this out when researching the support matrix at https://anclafs.com.
If you look at the volume of MS docs on this you would be forgiven for thinking it's complicated:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci...
https://github.com/dotnet/standard/blob/master/docs/faq.md
https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
https://blog.xamarin.com/net-standard-library-support-for-xa...
The first problem is that .NET Standard is not a specification in a traditional sense: "The official spec is a set of .cs files that define the APIs that are part of the standard." [0]
If you're new to the .NET ecosystem and you try to dig deeper, you find yourself having to understand more and more things: .NET Core, project.json (dependencies, frameworks, imports), vNext, portable class library, PCL profiles, CLI implementations etc, all the while battling misinformation, confusion and terrible proprietary tools, should you chose (or be forced to!) use them.
It took me about two weeks to finally wrap my head around the ecosystem in an effort to build a ".NET Standard library"(not a standard library) with a few dependencies and use it in a non-trivial Xamarin project. Let me know if you'd like me to share.
[0] https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
If you're new to the .NET ecosystem and you try to dig deeper, you find yourself having to understand more and more things: .NET Core, project.json (dependencies, frameworks, imports), vNext, portable class library, PCL profiles, CLI implementations etc, all the while battling misinformation, confusion and terrible proprietary tools, should you chose (or be forced to!) use them.
It took me about two weeks to finally wrap my head around the ecosystem in an effort to build a ".NET Standard library"(not a standard library) with a few dependencies and use it in a non-trivial Xamarin project. Let me know if you'd like me to share.
[0] https://docs.microsoft.com/en-us/dotnet/articles/standard/li...
Nobody showed an interest, but I've found an article which covers all of what I wanted to cover and since it costs me very little to post it, here's the link: http://www.hanselman.com/blog/WhatNETDevelopersOughtToKnowTo...
It's probably due for some rebranding. The problem is that the future isn't compatible with the past. It's akin to trying to find solutions to problems on MacOS but only finding articles on OS9. Right now most of what's out there is for legacy .NET frameworks and there's no easy term to add to your query that will magically filter them out all.
That being said, the old material isn't necessarily outdated or wrong but some of it very very much is.
That being said, the old material isn't necessarily outdated or wrong but some of it very very much is.
It is a little more than just a standard, my understanding is there are assemblies you can reference that do some magic redirection in the background. There is also a shim that gives you access to the whole BCL, I'm not sure how that works. I've ready a few articles and watched half a dozen videos and I still don't have a clear picture in my head.
I was having trouble understanding the difference between Core and Standard. I thought Core was supposed to be the new 'run everywhere' set of APIs? If that's the case then what is Standard?
It's all very confusing and I've been in DotNet since version 1
It's all very confusing and I've been in DotNet since version 1
Maybe this helps?
.NET Core is a new "run everywhere" runtime like Silverlight was and Mono is (and the venerable .NET Framework on Windows is, minus the "run everywhere" part).
.NET Standard is the new standard for what it means for something to be a .NET runtime. .NET Core meets certain versions of the .NET Standard and is in the process of meeting new ones. The venerable .NET Framework meets certain other versions of the .NET Standard. (Mono meets its own set of .NET Standard versions.)
If you've built "portable class libraries" (PCL) in the past, .NET Standard standardizes and cleans up the whole mess with PCL "Profiles".
.NET Core is a new "run everywhere" runtime like Silverlight was and Mono is (and the venerable .NET Framework on Windows is, minus the "run everywhere" part).
.NET Standard is the new standard for what it means for something to be a .NET runtime. .NET Core meets certain versions of the .NET Standard and is in the process of meeting new ones. The venerable .NET Framework meets certain other versions of the .NET Standard. (Mono meets its own set of .NET Standard versions.)
If you've built "portable class libraries" (PCL) in the past, .NET Standard standardizes and cleans up the whole mess with PCL "Profiles".
> Why is it so confusing that it needs so much explaining?
There isn't really. It looks more like Microsoft is trying to get PR by trying out "viral social media marketing" techniques like AMAs, ELI5s (Explain like I am 5) etc.
Think about it. You really think you can explain to any 5 year old any framework or language or standards?
There isn't really. It looks more like Microsoft is trying to get PR by trying out "viral social media marketing" techniques like AMAs, ELI5s (Explain like I am 5) etc.
Think about it. You really think you can explain to any 5 year old any framework or language or standards?
Not sure this would be meaningful to a five year old.
That was helpful. I have been confused many times.
It made me realize that the internal nuget packages we create (private), we should be targeting netstandard.
It made me realize that the internal nuget packages we create (private), we should be targeting netstandard.
[deleted]
[1] https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...