
Explaining .NET Standard Like I'm Five - GordonS
http://miniml.ist/dotnet/explaining-dotnet-standard-like-im-five/
======
CWuestefeld
I found the linked analogy in code [1] was more helpful than this article
itself.

[1]
[https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...](https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7)

~~~
ldev
Haha, it's funny how it's so much clearer in code than in normal language.

------
adrianlmm
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.

~~~
nathanaldensr
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.

~~~
pllbnk
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.

~~~
rpeden
> _.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.

~~~
pllbnk
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.

~~~
rpeden
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.

------
bad_user
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?

~~~
paxcoder
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...](https://docs.microsoft.com/en-
us/dotnet/articles/standard/library#specification)

~~~
paxcoder
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...](http://www.hanselman.com/blog/WhatNETDevelopersOughtToKnowToStartIn2017.aspx)

------
schnable
Not sure this would be meaningful to a five year old.

------
scoj
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.

