Avoid package downgrades for (implicit) NETStandard.Library package

[dsplaisted]

Currently (in the 1.0 SDK), the implicit version of NETStandard.Library package is 1.6.1. With the 2.0 tooling, this will change to (presumably) 2.0.0. If someone creates a NuGet package targeting .NET Standard using the 2.0 tooling and someone else who is using the 1.0 tooling tries to reference that package from a .NET Standard project, they will get a package downgrade warning for NETStandard.Library.

We need to avoid this.

We could set PrivateAssets="all" on the implicit package reference in order to prevent it from being a dependency expressed on the NuGet packages that are generated. That would prevent the package downgrade issue, but .NET Framework projects need the NETStandard.Library package to be referenced in order to get the right facades to support .NET Standard at runtime.

Ideally, the package generated would have a dependencies group for net45 (or whatever the lowest version of the .NET Framework supported would be) that would express a dependency on the NETStandard.Library package, which wouldn't apply to projects targeting other frameworks. (It's possible that Xamarin or other targets might also need the dependency).

However, it's not possible to specify dependencies groups this way when creating a NuGet package from an SDK-style project. There is a NuGet issue filed to enable this: NuGet/Home#2300

[livarcocc]

@dsplaisted This is for libraries targeting 1.0 referencing a 2.0 project? Is this correct? If that is the case, that is actually a not supported scenario right? And what we should do is error out.

[livarcocc]

@richlander This is the issue that I started talking to you about today.

[dsplaisted]

This is for libraries targeting 1.0 referencing a 2.0 project? Is this correct? If that is the case, that is actually a not supported scenario right? And what we should do is error out.

This is for libraries targeting 1.x and building using the 1.0 tools referencing a NuGet package which targets 1.x but is built with the 2.0 tools.

A different fix would be to have the 2.0 SDK use NETStandard.Library 1.6.1 for projects that target .NET Standard 1.x. However, this is not consistent with the design of the NETStandard.Library package, where the intent is that the latest one should always be used. If the CoreFX team needs to fix an issue targeting 1.x after 2.0 has shipped, they do not plan to patch the 1.6.x packages, rather they would ship an update to the 2.x package which would fix the issue targeting .NET Standard 1.x.

On top of that as time went on we'd have to keep a mapping in the SDK from the version of .NET Standard targeted to the corresponding package to use, and this mapping would just grow over time.

[livarcocc]

I see.

On a separate note, for M.NC.App, we will map the TFM to the right version, is that true? Like, netcoreapp1.0 will target 1.0.4 (or whatever latest is, when we update the SDK). netcoreapp1.1 will be 1.1.1, etc? Is that correct for M.NC.App or will it also always roll to the latest version of the package?

[dasMulli]

@dsplaisted That latest PR broke referencing a netstandard 2.0 nuget package in a net461 app since no netstandard.dll is added to the consuming project.

Using cli 2.0.0-preview1-005957, if I create a NuGet package for netstandard2.0 with a simple type (FooClass) and reference that nupkg from a net461 app, the following runtime exception occurs:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
   at FooApp.Program.Main(String[] args)

If the nuget packages aren't supposed to reference NETStandard.Library, how are the type forwarders supposed to be brought into net* projects? (maybe cc @terrajobst, @weshaggard ?)

[dsplaisted]

@dasMulli

There is now a separate package used to support referencing .NET Standard from .NET Framework: NETStandard.Library.NETFramework. I believe the plan is for this to be automatically referenced if you need it if you are using PackageReference in your .NET Framework project and are using VS 15.3 or higher. For earlier versions of VS, or if you're using packages.config, you would need to reference it manually.

Some related PRs:

• Remove desktop facades from NETStandard.Library standard#301
• Desktop support package for netstandard2.0 corefx#18246

[dasMulli]

Thanks for the explanation!

[dasMulli]

Is the automatic reference to NETStandard.Library.NETFramework supposed to be an SDK feature or a NuGet feature? (=> classic csproj with PackageReference)

[gulbanana]

Also, does it work when you have ProjectReferences instead of PackageReferences?