Standard: Improve NETStandard.Library experience on desktop and PCL frameworks

[davidfowl]

For older .NET Standard tfms, it should be possible to elide most of the package references that noop anyways. This would help encourage people to reference NETStandard.Library because it would do the right thing on all platforms without incurring the cost of downloading packages that then in turn provide an _._ file (like most of the packages do today for those frameworks). It would also make the experience for packages.config more pleasant (even though we're encouraging people to use PackageReference instead).

To do this we basically need to run restore on all the frameworks we care about for NETStandard.Library, look at the assets file for each TFM and remove dependencies that don't have any runtime and compile time impact.

PS: Package authors do this today e.g. https://www.nuget.org/packages/xunit.abstractions/

/cc @ericstj @terrajobst @onovotny @bradwilson

[davidfowl]

This is what it looks like for somebody installing a package that depends on .NET Standard.Library into a desktop project today (BTW this is using PackageReference). Looking at the assets file, most of the packages provide 0 usable assets to the compilation and runtime.

Here's the assets file:

https://gist.github.com/davidfowl/b611d890da1a98bfb6be52ca85bb1b1e

[davidfowl]

Quotes from customers on this issue:

Hi, maybe I am asking the same thind as others before, but I am totally confused. So, I wrote a PCL targeting .Net Standard 1.0 and I publish it via nuget. Nuget setted Microsoft.NETCore.Portable.Compability and NETStandard.Library as dependencies. Then, I pull the package to a WPF/.Net Framework 4.6 project via Nuget and it installs a huge amount of "dependencies" and references all of them. I think most of them aren't even needed.
Because I uninstalled the package and its dependencies and then installed it again but with the "ignore dependencies" options and it worked. So how do I manage it in the way that nuget only installs the really needed dependencies for all platforms?

Another one:

I have a question regarding .NET Standard vs Full Framework vs NuGet packages vs what is referenced
My project is a simple Class Library targeting .net framework 4.61. When i go ahead and pull in https://www.nuget.org/packages/Microsoft.Extensions.DependencyInjection/, i'm getting a ton-load of extra packages and references, which i understand is due to Microsoft.Extensions.DependencyInjection referencing .NET Standard 1.1, but i have a hard time finding a definite explanation of why these extra packages are pulled in and referenced. Aren't they all already in framework 4.61 or what am i missinga?

Another one:

I am trying to use the Microsoft.Extensions.DependencyInjection.Abstractions (not even the full one) in a normal .NET 4.6 class library in order to ‘get on the right path’ but when installing the nuget it says that it wants to install this rather large list of dependencies as well

[ericstj]

To do this we basically need to run restore on all the frameworks we care about for NETStandard.Library, look at the assets file for each TFM and remove dependencies that don't have any runtime and compile time impact.

Actually we already have built in support that does this in our build pipeline. We just don't have it turned on for meta-packages. We could do that for NETStandard.Library.

[davidfowl]

Sweet!

[Petermarcu]

So should we use this issue to track doing that then?

[ericstj]

Sure, it might be fixable solely in standard repo. I might need to make a buildtools change.

[clairernovotny]

What would a fix entail though? Would you need a NETStandard.Library 1.6.2 package with the re-generated metadata? How would that affect LTS/FTS with .NET Core apps? (It's terrible that the NETStandard.Library package version even has an impact on LTS/FTS on .NET Core.)

I'd be all in favor of a new meta-package that has empty dependency groups for other platforms to minimize the pain.

[ericstj]

This is just talking about the 2.0 NETStandard.Library package. Also, the 2.0 package has no dependencies on NETStandard2.0 on, so that will indeed minimize pain.

[clairernovotny]

Okay....long as that package also works with UWP as a 1.4 target today.

[davidfowl]

👏