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.

As an aside, the content type for that URL is application/octet-stream, so Firefox won’t view the image but insists on downloading it. It needs to be image/png to be viewable in browser I believe.

The point being that ANSI C didn't took the rest of UNIX APIs to other OSes as part of the specification, but in the end most OSes that adopted C ended up having to support POSIX as well as a means to have some kind of usable C library common across OSes.

I understand that .NET Core is sort of a subset of it, a new "fresh start" with refactoring done as well as platform-specific code cut in order to be able to support multiple platforms. And that .NET Standard covers .NET Core and .NET Framework as an umbrella.

However, where is Microsoft's focus now? Is .NET Core the future? What about .NET Framework 5? Will it happen? What about UWP? .NET Framework include a _ton_ of legacy stuff now. Windows Forms. Heck even WPF can be argued to be in the past, now that UWP is the future? UWP isn't directly interchangeable with WPF even though the technologies are confusingly similar. What about ASP .NET vs ASP .NET Core? What about Entity Framework vs Entity Framework Core? Is Microsoft honestly going to move them ALL forward at a good pace? That sounds like an insane undertaking!

I'm sure they want Windows devs to develop UWP apps for the Windows Store. Still, are they cannibalizing on that platform with this move? Windows Phone essentially doesn't exist. Xbox? Many wouldn't care about universal Windows apps and suffering by having to follow "weakest link support" due to non-existing smartphone platforms. Many devs would hit a MUCH larger target if developing .NET Core and targeting the web for anything UI related.

I wish Microsoft was more clear on this, but maybe the issue here is that they don't know either where they're going since it depends on where the devs are going... This whole .NET ecosystem is becoming extremely large and complex, even when singling out Windows. A whole lot has happened in a short time that it's dazzling.

This is purely about growing market share (and they have my mind, over Java anyway).

If I don't want portable code, I don't get support anymore without learning .NET Core?

I look at .NET Standard as a good thing. Even if you don't write portable code now, a whole lot more of what you know as the .NET Framework today will be available to Core as part of the standard should you ever want to write portable code in the future.

I think .NET Standard will eventually make it easier to describe what .NET is. Right now, the .NET Framework is way bigger than what most people think about when they hear the word framework. The .NET Framework is a pretty extensive library, plus Winforms, WPF, WCF, ASP.NET, ADO.NET, Workflow Foundation, and probably others I'm forgetting.

Having a robust stdlib in .NET Standard should simplify things. All .NET environments will have the same standard library, and the .NET Framework to .NET Core comparison will be something like the Java EE to Java comparison. I know that's by no means a perfect one to one comparison, but it'll help make it easier for people to understand the difference between the two main non-mobile .NET distributions.

I don't mean to be cynical - ____ legitimately want to improve their APIs and the experience of working with their software. But that's what makes the "build an ecosystem" business model so amazing if you can swing it: the crazier your innovations, the more you capture mindshare as people try to keep up, and so you're able to make a great profit while attracting the craziest talent.

Insert Microsoft in the ____'s.

Now, for all the Angular 2 programmers out there, insert Google.

I appreciate that MS is working to find a common set of libraries. Eventually this refactoring hopefully leads us to the point where we can all use an open-source common set of libraries and then just add on the Windows, Linux, Android or OSX specific parts.

I like the direction MS is heading, in general, with Windows 10, even if there are certain things I don't like. I like that I can run python under WSL because it has a better CLI experience (in my opinion) than the native windows Python build. I also like they are open-sourcing key technologies.

I just wish they would do better about naming so to reduce confusion. I'm confused just looking at the tables of which versions support which versions of the Standard. In the one chart, in .NET Framework 4.6.1 supports standard 1.4. 4.6.2 supports 1.5, vNext supports 1.6. Then also 4.6.1 supports standard 2.0. So, .NET Framework 4.6.1 supports Standard 1.4 and 2.0, but 1.5 and 1.6 support different (presumably incompatible) standards? The way the table reads it's 2 steps forward, 1 step back.

Angular 2 is so different because they were trying to fix all of the problems with Angular 1. In fact, Angular 2 didn't even settle on how to do that after starting early releases of Angular 2. But, that wasn't some secret conspiracy to get people to use it. If anything, a lot of people that were sold on Angular 1 are slower to migrate, but that's what they get for trying to do things right.

.NET is massive, it is entrenched, but I doubt it is growing.

So "fire and motion" doesn't apply here.

.Net Standard: cross-platform comprehensive API

.Net 4.5: Windows-only build tooling + comprehensive API

.Net MVC: Windows-only web framework built on .Net 4+

ASP.NET MVC is a web framework that implements the MVC pattern, as opposed to ASP.NET Web Forms, which was control based. ASP.NET MVC versions 1-5 run on the full .NET framework.

ASP.NET Core includes MVC, and the API has stayed as close asp possible to previous versions of ASP.NET MVC. The lower level bootstrapping / hosting / middleware / config stuff is pretty different (much improved, IMO), but your application code (models, views, controllers, services, etc.) should move from ASP.NET MVC to ASP.NET Core pretty smoothly.

Controllers not so much. That's actually where the biggest changes are for most projects.

Mono is another implementation of the standard.. cross-platform too, but this time compatible with the actual .NET Framework, i.e. 4.5.

So i am starting with a large and varied Win code base, i will have an easier time porting (as much of it as possible) to Mono rather than Core ?

Mono is not a strict superset of .net Core. We follow desktop more closely.

The extra APIs that are part of .net core, and are features on .net standard 1.6 will come to mono as we get the time to implement them.

I really wish they would clean up their story. Same for UI. When to use WPF, Winforms or UWP? It's just a mess.

Any version of Core supports some version of Standard, as does any version of Framework from 4.5 on. (Framework 4.5 supports Standard 1.1, Framework 4.6.1 supports Standard 1.4 and 2.0, Framework 4.6.2 supports Standard 2.0 and 1.5, Framework vNext will support Standard 1.6 and 2.0, Core 1.0 supports Standard 1.6, Core vNext will support Standard 1.6 and 2.0, etc.)

Standard 2.0 will be a big deal, because pretty much all their active platforms will support it as of their next major version, though the earlier versions provide a handier way than has previously existing for addressing what works against the various .NET implementations, which should somewhat simplify cross-platform .NET development for the existing platforms.

Sounds like baseline API that will be present on all .Net <foo>.

So anyone care to take a stab at it? How does this differ from .Net Core?

In other words, .NET Standard is POSIX for .NET.

At least, that's my reading, but they manage to be fairly confusing by mixing present tense and future tense with two different names:

"- .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.

- .NET Standard 2.0 will be implemented by .NET Framework, .NET Core, and Xamarin. For .NET Core, this will add many of the existing APIs that have been requested.

- .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.

- .NET Standard will replace Portable Class Libraries (PCLs) as the tooling story for building multi-platform .NET libraries."

So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future? If so, why don't they say ".NET Standard 2.0 will include a compatibility shim for .NET Framework binaries"?

On the other hand https://github.com/dotnet/standard/blob/master/netstandard/p... seems to indicate the two are synonyms, and version 2.0 is the first version of this framework.

There are three key versions (and several others; they have 1.0 through 1.6 and 2.0) of .NET Standard referenced; the key versions are 1.5 (supported by .NET Framework 4.6.2 and later and .NET Core 1.0 and later), 1.6 (supported by .NET Framework vNext and later and .NET Core 1.0 and later), and 2.0 (supported by .NET Framework 4.6.1 and later and .NET Core vNext and later).

Also, rereading the article, I notice "When we shipped .NET Core 1.0, we also introduced .NET Standard."

This text really could do with a good editor.

I think the versions prior to v1.6 were retrospectively defined based on the common capabilities of pre-existing platforms; v1.6 was what .NET Core 1.0 supported and .NET Framework vNext will support (2.0 is what .NET Framework 4.6.1 supports and what .NET Core vNext -- and vNext of MS's other platforms -- will support, and beyond 2.0 there will be more synchronous development across different platforms.)

.NET Core _already_ implements .NET Standard 1.x. It _will_ implement .NET Standard 2.0.

My guess is jumping to 2.0 for future implementation base is to avoid conflicts with .Net Core 1.0 (though may exacerbate the issue)

Library authors need to do refactoring to achieve compatibility across .Net Platform (old stuff, Windows-only) and .Net Core (new stuff, cross-platform).

This is the bridge for library authors to transition from being Windows-only to cross-platform.

Think about library authors that need to write for both Python 2 and Python 3, there needs to be a common API between both, and this is it: .Net Standard.

Meanwhile .Net Core is cross-platform build tooling and a minimal API.

http://dotnetrocks.com/?show=1291

(I apologize in advance for anyone who uses JS blocking like me; open it in your other YOLO browser if you know what's good for you; the .NET Rocks team loves Angular a little too much.)