standard

You know when movie franchises go through a reboot? That's very similar what Microsoft is doing with .NET Core. The 'Core' part of the name is hinting at a redesign based on a new runtime. They could've called it .NET Framework 6, but that doesn't give you any hints about the rewrite. I appreciate it's still not the best name in the world, but hopefully the analogy helped. To add some additional information, whilst there has been a redesign, work has been carried out to allow a certain level of backward compatibility. This work is referred to by the name .NET Standard. Can think of this as re-implementing a selection of commonly used libraries from older .NET versions on the new .NET platform to make porting easier. The most up to date .NET Standard version is version 2.0. https://github.com/dotnet/standard/blob/master/docs/versions...

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.

I'm enjoying reaping the rewards of all the dotnet core work in my F# projects. One critique: Why break semver? https://github.com/dotnet/standard/blob/master/docs/faq.md#w... Like I get that it feels like a big change (and it is), but you've gone and confused a huge population of library writers and users with the major version bump. https://github.com/search?q=netstandard2.0&type=Issues&utf8=... How many of those are irrelevant or invalid? That's just github. I already see the noise being created in slack and gitter channels as well. Other than that I think dotnet core is an amazing engineering effort and I've been happy using F# on OSX with it.

For people confused about what .NET Standard is and how it relates to .NET Core: Here's an FAQ: https://github.com/dotnet/standard/blob/master/docs/faq.md Here's a series of short videos from the product team explaining it: https://www.youtube.com/playlist?list=PLRAdsfhKI4OWx321A_pr-... Short excerpt from the FAQ: .NET Standard is a specification that represents a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. Think of .NET Standard as POSIX for .NET. Having a standard solves the code sharing problem for .NET developers by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services. Conceptually, I think of it in terms of browsers and browser standards. The relationship be

".NET Standard is a specification that represents a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. Think of .NET Standard as POSIX for .NET." https://github.com/dotnet/standard/blob/master/docs/faq.md

Adopting and porting to .NET Core will become a ton easier, later this year. .NET Core 2.0 will add a ton of .NET Framework APIs. These APIs are almost entirely coming from .NET Standard 2.0. See the jump in APIs in this table[1]. We often get asked if this is going against the promise of a light-weight development platform. Answer: not really. The new APIs are not being added to a single library, but several, including new ones. We will be updating our publishing tools to make it easier publish apps w/only the libraries you need. We are also looking at going one step further, which is publishing only the IL you need (intra-assembly optimization). I am spending the week presenting at two Microsoft conferences in Europe (Milan, Amsterdam). I heard very similar feedback on EF yesterday in Milan. I will be passing this off to the EF team. FY

It's not that complex but I think it's just that .NET naming and versions are currently quite confusing. I did a lot of reading on this for the book I wrote and I still find I need to double-check things. I guess this is what you get when you try and munge three platforms together. Package support is very important for uptake and many library authors were waiting for some stability. I found this out when researching the support matrix at https://anclafs.com. If you look at the volume of MS docs on this you would be forgiven for thinking it's complicated: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introduci... https://github.com/dotnet/standard/blob/master/docs/faq.md https://docs.microsoft.com/en-us/dotnet/articles/standard/li... https://blog.xamarin.com/net-standard-library-support-for-xa...

If you look at this file, you should find the definitions for WebRequest and subclasses. It looks like the synchronous overloads you are looking for are there, but I'm not sure exactly which ones you want. Regardless, they should be there and if they aren't, it's most likely an accidental omission. https://github.com/dotnet/standard/blob/master/netstandard/r... I think that GitHub is either having trouble with how large some of these files are, or just hasn't indexed them yet, since they aren't showing up in the repo search.

Small correction: .NET Core _will_ implement it. It has to grow quite a bit to get there. 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

> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes, they most likely will be. If you search through the reference assembly interfaces listed here, you should be able to tell whether the functionality you want will be available. https://github.com/dotnet/standard/tree/master/netstandard/r... For things like legacy synchronous or Begin/End async methods, we are more or less adding them wholesale to the standard. If something like that is still missing, then it's most likely an accidental omission rather than a conscious removal. (I work on .NET at Microsoft).

Seems pretty simple to me. * Almost every .NET API will be in the standard library and thus will be cross-platform * Terrible APIs that they should have never created will be available as packages * Stuff that's platform-specific runs only on those platforms * Every API is listed in this repo: https://github.com/dotnet/standard I got that from reading the TL;DR and skimming the rest of the post