.Net Standard is the standard. There is only 1 standard.

.Net Core is one implementation of the standard. .Net 4.6 is another implementation of the standard. Mono, Xamarin, Universal Windows Platforms are other implementations.

The idea is that any code written for .Net standard, will work across the different implementations.

As I said, I don't really understand how it's all supposed to fit together, but what I've found in practice is that completely random and innocuous methods are missing from the System frameworks depending on which "standard" you target in Visual Studio.

The .NET Standard spec has multiple _versions_, each of them adding more APIs: https://github.com/dotnet/standard/blob/master/docs/versions...

It's true that .NET Standard 1.0-1.6 had a lot of gaps but these should be rectified with 2.0 now so you shouldn't run into these problems anymore (otherwise there's usually a good reason why a method/API is missing from the standard).

Disclaimer: I'm working on Mono for Microsoft/Xamarin, primarily class libraries and tools.

Thanks for your work!

It's been covered by others here already, but my understanding, as an outsider reading all this, is that .Net Standard is like C99 or C++14, a standard or specification that defined how the language is to function, and then .Net Core is implementation, like GCC or Clang are compilers that implement the C/C++ standards. In the prior example given, Java has a standard for each version that defined how the language functions, and then there are virtual machines that implement that standard, such as Oracle's (originally Sun's) JVM implementation, OpenJDK, or in the distant past, the Blackdown Java port[1].

Contrast to languages where there isn't a spec, or the spec is the interpreter, such as Perl 5 (Perl 6 actually has a specification and multiple implementations or various levels of conformance), or things in between, such as Python with the Python Language Reference. There are benefits and drawbacks to a standard/specification. One benefit is that it's easy for someone to start their own implementation and test for conformance and have a high degree of surety whether it will work with existing programs. One downside is that when there's a problem found in the spec, it often requires more work to fix, as the changes need to propagate out to the implementations, which will have their own timelines as to when they can implement it.

1: https://en.wikipedia.org/wiki/Blackdown_Java

from what I've heard, .Net Standard 2 should be stable for a while and should fix the random missing stuff that was present in the various versions of .net standard 1.x

Naming is still one of the most difficult things. Then again we get used to bad names, and keep on... (For example why The JSON standard persist on calling things objects, rather than say... maps or dictionaries)...

.NET Standard is a standard like JDK version, which can be JDK 8, JDK 9 and so on... .NET Core is an implementation like OpenJDK, Oracle JDK If you write something for JDK 8 standard, like using the Java Time API, you expect it to work with either Oracle JDK 9 or OpenJDK 9 In .NET, the standard version, means that up to specific version of .NET Framework or .NET Core or any other implementation like Mono can execute the software. I don't see any real fragmentation here, one is solely for people that are ok with Windows and the other one is meant for people that are not okay with Windows (ofc the .NET Core is meant for more than just this). The same with Java, OracleJDK is meant for people that are ok with Oracle and OpenJDK for people that are not okay with Oracle. What fragmentation? There are but a few implementations and each of them have a clear use cases. It's not like choosing a JavaScript framework or a tool, now that ecosystem is a true fragmentation... And who knows, maybe with some time, the .NET Core will evolve to the point, where it will be the only .NET implementation

Because they have different runtimes, and Microsoft has been trying to clean up the mess created by Sinofsky regarding .NET, UWP and C++/CX.

Historically spoken, it was the WinXP security mess which forced the .NET team to take over WPF and then as a consequence build the different CoreCLR for Silverlight. That however was killed by the same guy who killed Flash. Mr. Jobs from Apple. The Win8/Mobile Team Just harvested the most modern technology at that time (CoreCLR).

There is a nice talk about it, somewhere on YouTube.

Win 8 sucked for .NET developers regarding API compatibility, because it required lots of incompatible changes, which are the reason Windows 10 FCU is the first UWP version to be finally compatible with .NET Standard 2.0 (4.6.1).

Then there was the whole 8.0, 8.1 with UAP, and finally UWP transitions.

The two only good things from UWP for .NET devs were finally getting .NET Native, which should be there since 1.0 given the Delphi roots of Anders, and the COM Runtime model that was in the genesis of .NET (formerly known as Ext-VOS).

I think the talk you refer to, is one from OS research group at MSR.

No the talk is from the .NET Rocks guys.

https://youtu.be/IqWar6cEWsA

UWP/UAP is a new UI stack from the Windows team BOUND to a CoreCLR. That is different with the existing .NET UI technology stacks.

Additional, the CoreCLR and its more modern Assembly packaging (System.Runtime vs mscorlib) made the code difficult to share (recompile or PCL). This is solved now by the .NET Standard.

> UWP/UAP is a new UI stack from the Windows team. That is different with the existing .NET technology stacks.

Which is what I meant with "mess created by Sinofsky regarding .NET, UWP and C++/CX.". I do have UWP experience since WP 8.

Thanks for the link about the talk.

Agree. History has not played nice with .NET but neither has with Java or Python.

Two other favourite ecosystems of mine. :)

I think the only popular ecosystem with a positive trending history is JavaScript. But... Na I do not start there :)

That sounds like the right answer. (I don't imagine Mono/Xamarin are to blame, as they were independent until recently. This is a big self-inflicted mess by MS.)

.NET Core and Mono are two different implementations of .NET Standard. It's a standard as described in the name.

.Net isn't the standard, it's Microsoft's implementation. (Or rather, .Net Core and .Net Standard are each Microsoft implementations.)

The standard is either CLR (Common Language Runtime) or CLI (Common Language Infrastructure), I'm not entirely sure.

Edit As far as I can tell, yes, even Miguel de Icaza is consistently misusing these terms.

Edit 2 - Nope, I'm wrong!

"The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations."

https://docs.microsoft.com/en-us/dotnet/standard/net-standar...

I see I'm mistaken -- thanks.

Jesus, it's like they went out of their way to make it as word-salad as possible.

There is no .NET Standard "implementation", you may be confusing .NET Standard with .NET Framework, which is the legacy Windows-entangled implementation.

(Yes, there are also ECMA standards for the CLR/CLI, C# language, and a somewhat small subset of the BCL [Base Class Library]. .NET Standard subsumes those underlying standards and then specs out a much larger set of the BCL and even some libraries that aren't strictly BCL but may as well have been in the way they've become standards such as ADO.NET.)

.NET Standard is an interface/spec and .NET Core and Mono are implementations of said interface/spec. .NET Core and Mono are currently focused on different needs/niches (as pointed out somewhat in the article here), partly born of their very different histories. .NET Core and Mono also share a bunch of code as it makes sense to do so with respect to their histories/needs/niches.