You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can now start producing .NET Standard 2.0 libraries and NuGet packages. Please use the latest .NET Core 2.0 Preview 2 as it contains many improvements that were necessary to provide a good experience.
Details
Bigger API Surface: We have more than doubled the set of available APIs from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0. Most of the added APIs are .NET Framework APIs. These additions make it much easier to port existing code to .NET Standard, and, by extension, to any .NET implementation of .NET Standard, such as .NET Core 2.0 and the upcoming version of UWP.
.NET Framework compatibility mode: The vast majority of NuGet packages are currently still targeting .NET Framework. Many projects are currently blocked from moving to .NET Standard because not all their dependencies are targeting .NET Standard yet. That's why we added a compatibility mode that allows .NET Standard projects to depend on .NET Framework libraries as if they were compiled for .NET Standard. Of course, this may not work in all cases (for instance, if the .NET Framework binaries uses WPF), but we found that 70% of all NuGet packages on nuget.org are API compatible with .NET Standard 2.0, so in practice it unblocks many projects.
UWP is work in progress and will ship later this year.
Tooling Prerequisites
In general, make sure you run the latest version of the tooling:
.NET Core SDK. You always need to install .NET Core 2.0 Preview 2. This also includes the CLI (dotnet) for building packages, so if you only want to use the CLI, you can stop here.
Visual Studio. If you want to use Visual Studio for authoring .NET Standard 2.0 libraries, you also need to install Visual Studio 2017 15.3. Make sure to use 15.3 and not an earlier version, as this release addressed a couple of key issues to provide a good experience. If you only need to consume .NET Standard 2.0 libraries, you can do that even in Visual Studio 2015 but you'll need NuGet client 3.6 or higher (download from Nuget.org/downloads)
Visual Studio for Mac. The latest version of Visual Studio for Mac supports building .NET Standard 2.0 libraries.
Rider. The latest version also has support for .NET Standard 2.0.
I'm closing this as the announcement has now been publicly communicated in our blog. Of course, this doesn't mean the discussion is over. Keep the questions coming.
Summary
.NET Standard 2.0 is final.
You can now start producing .NET Standard 2.0 libraries and NuGet packages. Please use the latest .NET Core 2.0 Preview 2 as it contains many improvements that were necessary to provide a good experience.
Details
Bigger API Surface: We have more than doubled the set of available APIs from 13k in .NET Standard 1.6 to 32k in .NET Standard 2.0. Most of the added APIs are .NET Framework APIs. These additions make it much easier to port existing code to .NET Standard, and, by extension, to any .NET implementation of .NET Standard, such as .NET Core 2.0 and the upcoming version of UWP.
.NET Framework compatibility mode: The vast majority of NuGet packages are currently still targeting .NET Framework. Many projects are currently blocked from moving to .NET Standard because not all their dependencies are targeting .NET Standard yet. That's why we added a compatibility mode that allows .NET Standard projects to depend on .NET Framework libraries as if they were compiled for .NET Standard. Of course, this may not work in all cases (for instance, if the .NET Framework binaries uses WPF), but we found that 70% of all NuGet packages on nuget.org are API compatible with .NET Standard 2.0, so in practice it unblocks many projects.
Tooling Prerequisites
In general, make sure you run the latest version of the tooling:
dotnet
) for building packages, so if you only want to use the CLI, you can stop here.Learn more by reading the .NET Standard FAQ.
Discussion
For discussion, see dotnet/standard#439.
The text was updated successfully, but these errors were encountered: