Totally fair. The original name was ".NET Standard Library" but we were too lazy so we shortened it to just ".NET Standard", which then ended up becoming the product name.
99 karma · joined December 5, 2014
In total, the .NET Framework has about 15k types.
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'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.
.NET Standard has about 32k APIs that set is pretty close to all the APIs that are part of .NET Framework that aren't specific to any application models. However, we still have a few things we need to bring to .NET Standard.
.NET Framework, .NET Core, Mono, Xamarin, and Unity are all implementing all the .NET specs. They are share many aspects, but each also bring specific capabilities that the others don't have, so its not very useful to think of these having a superset/subset relationship.
Here is how to think about this:
* .NET Standard is a specification of APIs.
* ECMA 335 is the specification of the .NET runtime aspects (i.e. what the metadata format is, what the semantics are of the intermediate language and so on).
* ECMA 334 is the C# language specification.
So there are really multiple specs that would make up a ".NET spec". We simply settled on .NET Standard because it's shorter than .NET Standard Library and the word standard conveys the spec aspect around it. We could have called it .NET Standard API Set but hey, it's supposed to be a product name, not a multi-word description :-)
Does this help?
Xamarin has an abstraction layer for UI called Xamarin Forms. This will allow you share UI code across .NET Framework, UWP, iOS, and Android.
.NET Core _already_ implements .NET Standard 1.x. It _will_ implement .NET Standard 2.0.
We highly care about making it easy to write code that works cross-plaform, especially on Linux. That's why we created .NET Standard!
* We've concrete .NET platforms, such as .NET Framework, .NET Core, and Xamarin. They are the moral equivalent of Linux distributions. * With .NET Standard we now have shared specification that dictates which APIs all these platforms have to implement. That's the moral equivalent of POSIX.
Yes.
> In an ideal world the old sync APIs would just work and we'd be able to move forward with .NET Core as it stabilizes and get off Mono without a major rewrite.
Yes, being able to move forward with existing code is the primary reason they were added to .NET Standard.
In other words, .NET Standard is POSIX for .NET.
https://blogs.msdn.microsoft.com/dotnet/2014/12/04/introduci...
Don't think of .NET Standard as another .NET platform. Think of it as the standard that ties them all together. It's similar in spirit to POSIX. It's not another Unix, it's a way to write code that works on multiple Unixes.
The developer division (DevDiv) currently mostly uses TFVC. For the open source projects this doesn't make a lot of sense though, which is why most these are moving to git.
Of course, we're a big company so you'll also find Mercurial and SVN, especially in MSR. I really hope that you don't find SourceSafe anymore though :-)