This /is/ geared heavily towards improving the .NET Core story. The purpose of this spec is to provide library authors with a set of APIs that they can expect will exist on .NET Standard 2.0-implementing runtimes (a list of which are supplied). This allows library authors to write code that works when deployed across multiple implementations and it allows application writers to trust that their dependencies will work on the platform of their choice.

Two major implementations of .NET Standard 2.0 are the traditional .NET Framework and .NET Core, so libraries targeting .NET Standard 2.0 can be used on both platforms without modification.

I can totally share the sentiment around complexity. We're working hard towards reducing it though and .NET Standard is one piece of the puzzle. Let me try to explain:

If you're a typical .NET customer, then you're used to the .NET Framework, which also means you're probably only used to doing development on Windows. That was no longer a viable strategy for .NET, so we're now pursing a cross-platform strategy. A good chunk of the complexity you see today is a result of the changed dynamics of software engineering: the PC is no longer the only relevant form factor, server applications have to be rethought as scalable cloud services, and the UI paradigm is no longer a sequence of dialogs but has to be tailored to multiple clients, and on top of that you now also have to deal with multiple different operating systems.

.NET has a long standing history of embracing the underlying platform (hello COM, hello P/Invokes) while also providing a ton of conveniences on top that make it approachable (hello WinForms). We can't really shield you from all the complexities that result from the changed dynamics. But what we can do is making it more consistent and productive.

Over the last years, various different .NET stacks were created, several of them outside of the Microsoft bubble (Mono, Xamarin, Unity). So in order to build modern experiences, you often have to use various different stacks to get the job done. We understand that this isn't free of challenges, which is why we try very hard to reconcile the differences. For instance, we acquired Xamarin to fully embrace the mobile support they offer and make it a fully integrated part of the .NET development platform. We changed the license on Mono to enable Unity to use the latest version and pick up innovation instantaneously. And we've created the

.NET Standard is a way to achieve API consistency between different .NET stacks. This makes it much easier for application and library authors to share code between different .NET implementations.

Our goal is to empower .NET developers to build any kind of app, for any kind of operating system. That's the world we live in now and we're fully committed to make this experience as productive as possible.

I am not sure if you are going about this the right way. Instead of doing .NET standard, .NET Core and .NET full framework with overlapping functionality, I think it would better to have .NET Core as the underlining cross-platform standard. Then add WPF, WCF and whatever as separate packages that may be cross-platform or not.

The whole thing reminds me a little of the UI situation. Start with Winforms, don't improve it but start WPF (and keep Winforms), then start Silverlight, then start UWP. All in parallel instead of building on top of each other.

MS doesn't need more more frameworks, but less.

.Net Standard isn't an implementation, it's a specification. Code that targets .Net Standard is guaranteed to run on any compatible runtime that supports it.

.Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.

All of these API surfaces are pretty large- what is a good way to get a feel for what they do/don't offer? In particular, what are you referring to in .NET Core that you wouldn't want in Framework?

.Net Core supports P/Invoke on Linux and macOS, you aren't going to be using a library that provides bindings for libsystemd.so or whatever on Windows - this is probably one of the most prominent examples. I know there's a handful of others, but I'm having a hard time finding a good article or any relevant documentation on it.

This sounds all good but now we are in the typical Microsoft dilemma when you start something. Core or full? Winforms, UWP or WPF? All very similar but different enough to make a move between them difficult.

You're never going to remove this choice entirely, the goal is to allow you to keep your libraries when moving between target frameworks.

In a sense, that's what we have been doing. But the challenge is that .NET Core is an actual implementation and the other .NET stacks have their own (i.e. the code base isn't shared, Mono/Xamarin/Unity are on a different train than .NET Framework/.NET Core).

For newer .NET implementations we push folks to start with .NET Core and adding their specific technologies on top. That is, for instance, what Samsung has been doing with Tizen. So if the open source community innovates in .NET Core, Samsung can just move to a later build of .NET Core in order to benefit from it. They are a pure superset of .NET Core, by construction. However, for all other cases someone needs to port the changes from .NET Core to Mono which makes it consumable by Xamarin and Unity. .NET Framework is in a similar boat, although porting is somewhat easier as the .NET Core code base originated from .NET Framework.

Since we can't (easily) move Mono/Xamarin/Unity/.NET Framework on top of .NET Core, we need a way to standardize the API set so that it's not all chaos. And that's where .NET Standard comes in.

If you are at it maybe you can also rename it so that its name doesn't start with a point and you don't need to put points in the middle of the sentences.

It came up before, but changing the brand from .NET would have been much more confusing (and expensive, as building up a brand requires a ton of work).

> improving the .NET Core story

They are. NET Core fully implements NET Standard.

From an interface perspective. From a behavioral perspective not so much. A lot of classes will throw not implemented or have slightly different results

That's true, but it's done so that you can have simple 'if' logic to determine if something is available without having to recompile. If the interfaces were missing altogether the libraries wouldn't be portable from one implementation to another.

Wait... first I've heard of this. Not that I'm reading every single post letter for letter but have been following the .NET Standard move quite a bit.

Is there a list somewhere that specifies what is not implemented per target, though it's in the standard?

There's multiple releases of .Net Standard, different releases of .Net Core target different releases of Standard. .Net Core 1.2 will be the first version to support the full .Net Standard 2.0 API surface.

Just to clarify, we are actually calling the next version of .NET Core "2.0" so that the name aligns with .NET Standard 2.0, and so their relationship is more clear.