Packages which suppress NETStandard.Library reference cause downgrades when installed in netcoreapp1.0

[ericstj]

This is true for both the 2.1 packages we're building now as well as the 2.0 packages we shipped prior.

This manifests as NU1605 errors.

As an example, install System.Buffers 4.4.0 in a netcoreapp1.0 project.

For example:

error NU1605: Detected package downgrade: System.IO.FileSystem.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version. 
error NU1605: project -> Microsoft.NETCore.App 1.0.5 -> NETStandard.Library 1.6.0 -> System.Console 4.0.0 -> runtime.unix.System.Console 4.3.0 -> System.IO.FileSystem.Primitives (>= 4.3.0) 
error NU1605: project -> Microsoft.NETCore.App 1.0.5 -> NETStandard.Library 1.6.0 -> System.IO.FileSystem.Primitives (>= 4.0.1)

The downgrade isn't caused by the common ancestor (NETStandard.Library) as the warning might lead you to believe. Instead it's occurring because of the following dependency:

System.Buffers 4.4.0 -> System.Diagnostics.Debug 4.3.0 -> Microsoft.NETCore.Platforms 1.1.0 (runtime.json).

They are hitting this NuGet issue: NuGet/Home#3541.

The set of packages impacted in the 2.1 release are the following:

• System.Buffers
• System.Diagnostics.DiagnosticSource
• System.Reflection.TypeExtensions
• System.Runtime.CompilerServices.Unsafe
• System.Security.Cryptography.Cng
• System.Security.Cryptography.OpenSsl
• System.Security.Principal.Windows
• System.Threading.Tasks.Extensions

They are only impacted on .NETCoreApp1.0.

If we wanted to fix this we could re-baseline to the 1.0 era packages: potentially breaking where folks counted on us bringing in the 1.1 version of packages in other TFMs. Special case the dependencies only on NETCoreApp1.0 could limit this, but is still potentially breaking if folks even on NETCoreApp1.0 depended on a fix or API added in a 1.1 version of a package.

In the realm of workarounds, folks can suppress the warning on NETCoreApp1.0 with <NoWarn>$(NoWarn);NU1605</NoWarn>, however this can result in real downgrades sneaking through. Alternatively you can lift up all of NETStandard.Library with <PackageReference Include="NETStandard.Library" Version="1.6.1" />, this bypasses the NuGet bug by lifting up every package to the 1.1 version which may be undesirable since you end up running on a mixed state.

/cc @joperezr @weshaggard

[weshaggard]

If we wanted to fix this we could re-baseline to the 1.0 era packages: potentially breaking where folks counted on us bringing in the 1.1 version of packages in other TFMs. Special case the dependencies only on NETCoreApp1.0 could limit this, but is still potentially breaking if folks even on NETCoreApp1.0 depended on a fix or API added in a 1.1 version of a package.

I don't like rebasing as I do expect some folks depend on us pulling in higher versions. I think the workaround is probably best.

[weshaggard]

@ericstj I put this in the 2.0 as if we want to fix it we will need to service packages there to do it, but I'm not convinced it is worth doing at this point.

[karelz]

It seems there is no interest to fix it in 2.0. Closing.