search

dotnet / standard

This repo is building the .NET Standard
3.07k stars 429 forks source link

.NET Standard 2.0 is final #439

Closed terrajobst closed 7 years ago

terrajobst commented 7 years ago

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

Tooling Prerequisites

In general, make sure you run the latest version of the tooling:

Learn more by reading the .NET Standard FAQ.

TylerBrinkley commented 7 years ago

Is Visual Studio 15.3 RTM to be released in tandem?

VeselovAndrey commented 7 years ago

Please use Visual Studio 2017 15.3 to produce .NET Standard 2.0 libraries.

Only 15.3 preview available now. And if you read 15.3 preview release notes:

This release is not "go-live" and not intended for use on production computers or for creating production code.

Sounds like at this time we can produce .NET Standard 2.0 libraries for internal tests only.

terrajobst commented 7 years ago

@VeselovAndrey

The warning is standard boilerplate for unsupported previews and doesn't apply to the production of .NET Standard libraries. We're using this version of VS to build our stable bits too, so I wouldn't worry about it in this particular context.

terrajobst commented 7 years ago

@TylerBrinkley

Is Visual Studio 15.3 RTM to be released in tandem?

To quote Ron Gilbert "Soon. On the 17th of soon" 😄

MJomaa commented 7 years ago

FYI .NET Core 2 will be released on the 18th or 19th of September live during DEVintersection Europe.

Source: https://www.youtube.com/watch?v=fGxGeP7b8j0 https://www.devintersectioneurope.com

ncsurfus commented 7 years ago

Awesome! Great job guys!

bondarenkod commented 7 years ago

Is it OK now to use it for XF?

jeroenheijmans commented 7 years ago

Nice, good job yall!

One question though, if I look at the diff between 1.6 and 2.0 I see quite at the top:

+    public sealed class AppDomain : MarshalByRefObject {
+        public string BaseDirectory { get; }
+        public static AppDomain CurrentDomain { get; }
+        public string DynamicDirectory { get; }
// etc...

Did I miss some announcement about AppDomain getting back in there? A typical search still yields mostly info on that it will not be there. Using a ""previous month" search doesn't give much more. The SO post about it also still suggests it's out.

I'm sure that I'm missing something obvious, and I hope this is the correct place to ask about this. Any input welcome.

danmoseley commented 7 years ago

@jeroenheijmans yes the AppDomain class is in .NET Standard 2.0 (excluding some members snipped because they had problematic dependencies: remoting, CAS, ref emit).

Also yes .NET Core does not support secondary AppDomains so it's implementation of .NET Standard 2.0 will throw PlatformNotSupportedException or similar for some members.

Generally where a platform declares support for .NET Standard x it should fully implement it since this is the purpose of making a standard: and this is true in the vast majority of cases but there are always platform specific limitations such as secondary appdomains in the case of .NET Core that will bleed through the API in a few cases.

terrajobst commented 7 years ago

@jeroenheijmans

Did I miss some announcement about AppDomain getting back in there?

It's listed in our FAQ for quite some time.

I hope this is the correct place to ask about this. Any input welcome.

Yes, this is the right place to ask about all things .NET Standard.

jeroenheijmans commented 7 years ago

@danmosemsft Thx for the answer!

@terrajobst Also thx for the link. As I mentioned, I was already afraid that I had missed that. Apologies for not reading the FAQ first, I shouldn't have relied only on a Google search turning up that info.

kspearrin commented 7 years ago

.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.

Is there anything special you have to do to get this to work? I have a project targeting 461 and netcoreapp2.0 and have not been able to reference 3 different nuget libraries that I've tested so far.

terrajobst commented 7 years ago

@jeroenheijmans

No worries. It's a fast moving world on GitHub and following us can be confusing for sure :-)

terrajobst commented 7 years ago

@kspearrin

What tool are you using? Both VS and CLI should work, assuming you're running the latest versions (VS 15.3 and .NET Core 2.0 Preview 2). What's the error you're getting?

kspearrin commented 7 years ago

@terrajobst VS 2017. Tried installing Microsoft.Azure.NotificationHubs. Same issue with YubicoDotNetClient.

image

Microsoft Visual Studio Enterprise 2017 Preview (2)
Version 15.3.0 Preview 6.0
VisualStudio.15.Preview/15.3.0-pre.6.0+26724.1
Microsoft .NET Framework
Version 4.7.02046

Installed Version: Enterprise

Visual Basic 2017   00369-60000-00001-AA734
Microsoft Visual Basic 2017

Visual C# 2017   00369-60000-00001-AA734
Microsoft Visual C# 2017

Visual F# 4.1   00369-60000-00001-AA734
Microsoft Visual F# 4.1

Application Insights Tools for Visual Studio Package   8.8.00712.1
Application Insights Tools for Visual Studio

ASP.NET and Web Tools 2017   15.0.30718.0
ASP.NET and Web Tools 2017

ASP.NET Core Razor Language Services   1.0
Provides languages services for ASP.NET Core Razor.

ASP.NET Template Engine 2017   15.0.30718.0
ASP.NET Template Engine 2017

ASP.NET Web Frameworks and Tools 2017   5.2.50601.0
For additional information, visit https://www.asp.net/

Azure App Service Tools v3.0.0   15.0.30719.0
Azure App Service Tools v3.0.0

Azure Data Lake Tools for Visual Studio   2.2.9000.0
Microsoft Azure Data Lake Tools for Visual Studio

Azure Data Lake Tools for Visual Studio   2.2.9000.0
Microsoft Azure Data Lake Tools for Visual Studio

Commit Formatter   1.0
Adds automatic word wrap to the Git commit message textbox.

Common Azure Tools   1.10
Provides common services for use by Azure Mobile Services and Microsoft Azure Tools.

Fabric.DiagnosticEvents   1.0
Fabric Diagnostic Events

Indent Guides   15
Indent Guides

Adds visual guides at each indentation level.

JavaScript Language Service   2.0
JavaScript Language Service

Microsoft Azure Tools   2.9
Microsoft Azure Tools for Microsoft Visual Studio 2017 - v2.9.50712.2

Microsoft Continuous Delivery Tools for Visual Studio   0.3
Simplifying the configuration of continuous build integration and continuous build delivery from within the Visual Studio IDE.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Microsoft MI-Based Debugger   1.0
Provides support for connecting Visual Studio to MI compatible debuggers

NuGet Package Manager   4.3.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit http://docs.nuget.org/.

Redgate ReadyRoll   1.14.2.3918
Extend DevOps processes to your SQL Server databases and safely automate database deployments.

Visit https://www.red-gate.com/readyroll for more information.

Copyright (C) 2011 Red Gate Software Ltd. All rights reserved.

This software contains components from Component Owl.
SQL Server is a registered trademark of Microsoft Corporation. 
Visual Studio is a registered trademark of Microsoft Corporation. 

ReadyRoll contains code from the following open source software:

NuGet https://www.nuget.org/
SQL LocalDB Wrapper https://github.com/martincostello/sqllocaldb
Autofac https://autofac.org/
Json.NET https://json.net/
MahApps.Metro http://mahapps.com/
SemVer https://github.com/maxhauser/semver
Log4Net http://logging.apache.org/log4net/
Extended WPF Toolkit https://wpftoolkit.codeplex.com/
Code InfoBox VSX http://www.codeproject.com/Articles/55196/Code-InfoBox-Visual-Studio-Extension-VSX
OctoPack https://github.com/OctopusDeploy/OctoPack
SQLite https://sqlite.org/

This product contains icons from http://www.visualpharm.com distributed under a free backlink license.

For license details or other notices relating to the above software, please see NOTICE.TXT and EULA.rtf in the ReadyRoll application folder.

SQL Server Data Tools   15.1.61707.200
Microsoft SQL Server Data Tools

TypeScript   2.3.4.0
TypeScript tools for Visual Studio

Visual Studio Code Debug Adapter Host Package   1.0
Interop layer for hosting Visual Studio Code debug adapters in Visual Studio

WebJobs Tools v1.0.0   __RESXID_PRODUCTVERSION__
WebJobs Tools v1.0.0
andrewlock commented 7 years ago

Is there any way of opting out of the compatibility shim? What If I want it to be netstandard all the way down the dependencies, without the risk of pulling in a 461 dependency that isn't actually compatible?

Currently, the fact that I can happily reference and build with packages that aren't actually supported makes the process of building netstandard projects worse, not better for me. Previously (in < 2.0 days) I could reference a package, and if it wasn't supported, I'd get an error. Now, with the compat shim, I have to spend all my time trawling around nuget.org to check the dependencies, and see if each package I reference has a netstandard version (and hope that their dependencies don't rely on the compat shim and some unsupported api).

On top of that, the inclusion of AppDomain etc in netstandard means that even if you do avoid the compat shim, you could still end up with runtime PlatformNotSupportedExceptions from some dependency that supports netstandard but isn't cross platform! I know there was a trade off here, and the goal was to make it as easy to port to netstandard as possible, but this seems like it doesn't help with the goal of building cross platform apps. Runtime exceptions are the worst, so why make them a common and expected problem!?

Overall, 2.0 is great, especially if I can disable the compat shim (potentially selectively). But the incompatibilities between platforms will makes a concept that many people are already having some difficult understanding even harder to fathom.

dasMulli commented 7 years ago

The implicit .NET 4.6.1 package compatibility can be turned off by setting this property in your project file (inside of a PropertyGroup):

<DisableImplicitAssetTargetFallback>true</DisableImplicitAssetTargetFallback>
terrajobst commented 7 years ago

@kspearrin

The behavior you observe is correct and the compat shim is working as designed. Whenever you use NuGet packages that go through the compat shim you'll get a warning like this:

Warning NU1701: Package 'Huitian.PowerCollections 1.0.0' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

We've made sure you get this warning every time you build (rather only during package restore) to ensure you don't accidentally overlook it.

The idea here is that we have no way of knowing whether the .NET Framework binary will actually work. For example, it might depend on WinForms. To make sure you don't waste your time troubleshooting something that cannot work, we let you know that you're potentially going off the rails. Of course, warnings you have to overlook are annoying. Thus, we recommend that you test your application/library and if you're convinced everything is working fine, you suppress the warning:

image

In the project file this looks as follows:

<ItemGroup>
  <PackageReference Include="Huitian.PowerCollections" Version="1.0.0" NoWarn="NU1701" />
</ItemGroup>

Note that the suppression isn't global but per package reference. This ensures that just using one library through the compat shim doesn't result in a free ride for all future references. If you install another library that goes through the compat shim, you'll get another warning.

terrajobst commented 7 years ago

@andrewlock

Is there any way of opting out of the compatibility shim? What If I want it to be netstandard all the way down the dependencies, without the risk of pulling in a 461 dependency that isn't actually compatible?

See my comment above; we make sure to tell you when you're consuming a library through the compat shim. I wouldn't bother turning it off and rather follow good hygiene and ensure you build with zero warnings.

kspearrin commented 7 years ago

@terrajobst Great. I guess I incorrectly assumed that the warning meant it just wasn't going to work. Glad to know. :)

JaredShaver commented 7 years ago

I am a little confused as to why the .NET Framework 4.7.1 Preview announcement https://blogs.msdn.microsoft.com/dotnet/2017/08/07/welcome-to-the-net-framework-4-7-1-early-access/ lists ".NET Framework support for .NET Standard 2.0" as a feature if it's already supported by .NET Framework 4.6.1. Can someone clarify what this means?

terrajobst commented 7 years ago

@JaredShaver

Can someone clarify what this means?

Great question. Here is the deal: .NET Framework 4.6.1 has shipped before we built .NET Standard 2.0. While .NET Framework 4.6.1 supports the API surface of .NET Standard 2.0, it does require extra DLLs that need to be deployed by the application. This includes, for instance, netstandard.dll. Starting with .NET Framework 4.7.1, the .NET Standard support files will be shipped with the framework so that applications don't need to carry any extra files.

JaredShaver commented 7 years ago

@terrajobst That makes sense. Thank you for the explanation.

harvinders commented 7 years ago

Broad platform support. .NET Standard 2.0 is supported on the following platforms:

  • .NET Framework 4.6.1
  • .NET Core 2.0
  • Mono 5.4
  • Xamarin.iOS 10.14
  • Xamarin.Mac 3.8
  • Xamarin.Android 7.5
  • UWP is work in progress and will ship later this year.

@terrajobst What does that mean for UWP? Would we be limited to accessing .net standard 2.0 libraries from UWP apps targeting Fall Creators Update? Or would we be able to also target Anniversary Update?

terrajobst commented 7 years ago

AFAIR .NET Standard 2.0 will only be available for FCU and up. Reason being that we needed OS changes to make the added API surface work.

danmoseley commented 7 years ago

@terrajobst is correct.

GeertvanHorrik commented 7 years ago

@terrajobst / @danmosemsft And backported to mobile "feature2"? Or will the combo of Win10M and .NET standard be a no-go?

terrajobst commented 7 years ago

@GeertvanHorrik

We're trying to get an answer. Stay tuned.

andrii-litvinov commented 7 years ago

Does it mean that .NET Core 2.0 is released too? When I run dotnet --info I get 

...
Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
...

With no preview postfix. Or if it is a preview of runtime how can I tell the this is a preview?

tannergooding commented 7 years ago

@andrii-litvinov, .NET Core 2.0 was just released this morning: https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-core-2-0/

andrii-litvinov commented 7 years ago

@tannergooding Excellent, I missed this great news somehow 😄

mpaine-act commented 7 years ago

When will Full 4.6.2 be supported by .NET Standard 2.0?

terrajobst commented 7 years ago

When will Full 4.6.2 be supported by .NET Standard 2.0?

Not sure I understand the question. .NET Framework 4.6.2 can reference .NET Standard 2.0 libraries because 4.6.1 already supports it.

mpaine-act commented 7 years ago

Sorry for the confusion.

I see 4.6.1 is listed in all of the release notes and articles, but no mention of 4.6.2. For example: https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/

terrajobst commented 7 years ago

I see. That's implicit based on usual versioning rules: if 4.6.1 supports something, it's implied that it's supported on any later version as well (unless explicitly called out as a breaking change, which isn't the case here).

chris31389 commented 7 years ago

Do you know if there is work still to be done with Azure Deployments within VSTS for .net standard 2.0?

I'm getting this error when deploying to azure using VSTS. Its suggesting that netstandard2.0 isn't compatible with .net 4.7?

Errors in d:\a\1\s\Draycir.Approvals.TenantProvisioning.WebApi\Draycir.Approvals.TenantProvisioning.WebApi.csproj
      Project Draycir.Approvals.Ioc.Autofac is not compatible with net47 (.NETFramework,Version=v4.7). Project Draycir.Approvals.Ioc.Autofac supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Project Draycir.Approvals.Persistence is not compatible with net47 (.NETFramework,Version=v4.7). Project Draycir.Approvals.Persistence supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Package Microsoft.AspNetCore.Mvc 2.0.0 is not compatible with net47 (.NETFramework,Version=v4.7). Package Microsoft.AspNetCore.Mvc 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Package Microsoft.AspNetCore 2.0.0 is not compatible with net47 (.NETFramework,Version=v4.7). Package Microsoft.AspNetCore 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Package Microsoft.Extensions.Logging.Debug 2.0.0 is not compatible with net47 (.NETFramework,Version=v4.7). Package Microsoft.Extensions.Logging.Debug 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Project Draycir.Approvals.Domain is not compatible with net47 (.NETFramework,Version=v4.7). Project Draycir.Approvals.Domain supports: netstandard2.0 (.NETStandard,Version=v2.0)
      One or more projects are incompatible with .NETFramework,Version=v4.7.
      One or more packages are incompatible with .NETFramework,Version=v4.7.
      Package Microsoft.AspNetCore 2.0.0 is not compatible with net47 (.NETFramework,Version=v4.7) / win7-x86. Package Microsoft.AspNetCore 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Package Microsoft.AspNetCore.Mvc 2.0.0 is not compatible with net47 (.NETFramework,Version=v4.7) / win7-x86. Package Microsoft.AspNetCore.Mvc 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Package Microsoft.Extensions.Logging.Debug 2.0.0 is not compatible with net47 (.NETFramework,Version=v4.7) / win7-x86. Package Microsoft.Extensions.Logging.Debug 2.0.0 supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Project Draycir.Approvals.Ioc.Autofac is not compatible with net47 (.NETFramework,Version=v4.7) / win7-x86. Project Draycir.Approvals.Ioc.Autofac supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Project Draycir.Approvals.Persistence is not compatible with net47 (.NETFramework,Version=v4.7) / win7-x86. Project Draycir.Approvals.Persistence supports: netstandard2.0 (.NETStandard,Version=v2.0)
      Project Draycir.Approvals.Domain is not compatible with net47 (.NETFramework,Version=v4.7) / win7-x86. Project Draycir.Approvals.Domain supports: netstandard2.0 (.NETStandard,Version=v2.0)
      One or more projects are incompatible with .NETFramework,Version=v4.7 (win7-x86).
      One or more packages are incompatible with .NETFramework,Version=v4.7 (win7-x86).
mpaine-act commented 7 years ago

if 4.6.1 supports something, it's implied that it's supported on any later version as well

@terrajobst: there were many API and behavior changes between 4.6.1 and 4.6.2, so I didn't want to assume the same from the messaging.

https://github.com/Microsoft/dotnet/blob/master/releases/net462/dotnet462-api-changes.md https://docs.microsoft.com/en-us/dotnet/framework/whats-new/#v462

If all of .NET 4.6.x is supported, it would be easier to understand by leaving off the .1 part, or say 4.6.2; if .2 API deltas are not actually supported, I need to change my targeting accordingly.

Thanks for all the great work.

jnm2 commented 7 years ago

@mpaine-act 4.6.x would imply that 4.6(.0) supports it which it does not. In any case, there are never ever API breaking changes from one version to the next. There would have to be a breaking API change in order for 4.6.2 to stop supporting at least the same version of .NET Standard that 4.6.1 supports.

mpaine-act commented 7 years ago

4.6.x would imply that 4.6(.0) supports it which it does not.

@jnm2, OK. Why is 4.6.0 not compatible? Deprecated features or assembly age?

When I want to use System.Data.SqlClient.SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled, I can't target standard2.0 because it is in 4.6.2 and not in 4.6.1, and thus not in .NET Standard 2.0. confirmed. I'm sure that will be added once netstandard2.1 is released.

tannergooding commented 7 years ago

There are APIs in NS2.0 which 4.6.0 does not expose, only 4.6.1 and higher expose all the APIs that NS2.0 requires.

That is, you could construct a NS2.0 library that uses an API which cannot run on 4.6.0 because said API doesn't exist.

NS2.0 is a subset of 4.6.1 and later, so all APIs it exposes are available on 4.6.1 and later, but not all APIs exposed by 4.6.1 or 4.6.2 are available in NS2.0

svick commented 7 years ago

@mpaine-act

When I want to use System.Data.SqlClient.SqlConnection.ColumnEncryptionQueryMetadataCacheEnabled, I can't target standard2.0 because it is in 4.6.2 and not in 4.6.1, and thus not in .NET Standard 2.0. I'm sure that will be added once netstandard2.1 is released.

That property not in .Net Core 2.0, so it can't be in .Net Standard 2.0. It's listed as missing in https://github.com/dotnet/corefx/issues/17126, but with no specific mention that this member is planned to be added. So, if you want to have it included in a future version of .Net Standard, I think you should open an issue in dotnet/corefx.

andersborum commented 7 years ago

I don't understand why secondary AppDomains aren't supported in .NET Core 2.0 - was looking forward to the 2.0 release as it simplified the scenario of running dynamic processes (like plugins). What's the approach one should take instead? Keep using Process?

danmoseley commented 7 years ago

@andersborum AppDomains have pervasive impacts on the runtime that would make it difficult to meet the goals of .NET Core like footprint and performance. This document discusses alternatives:

https://docs.microsoft.com/en-us/dotnet/core/porting/libraries

arunkkarepu commented 7 years ago

when will DataTableConverter and DataSetConverter be updated?

danmoseley commented 7 years ago

@arunkkarepu those are newtonsoft right?

terrajobst commented 7 years ago

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.

vers-one commented 7 years ago
  1. I've created a library that targets .NET Standard 2.0 only: <TargetFramework>netstandard2.0</TargetFramework>
  2. I've put it into NuGet package.
  3. Created a new solution in VS 2017 15.3 with one .NET Core 2.0 console app.
  4. When I try to add a reference to the package I get Package ... was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.

Aren't .NET Standard 2.0 libraries supposed to be fully compatible with .NET Core 2.0 projects?

terrajobst commented 7 years ago

That seems wrong. Can you share the folder structure of the package?

vers-one commented 7 years ago

Sorry, my mistake. I was putting assembly in lib folder instead of lib\netstandard2.0.

GeertvanHorrik commented 7 years ago

@terrajobst / @danmosemsft And backported to mobile "feature2"? Or will the combo of Win10M and .NET standard be a no-go?

It has been 25 days now, any updates on Windows 10 Mobile?