Add dependencies from Microsoft.NETCore.App to Microsoft.NETCore.Targets and NETStandard.Library

We should add the following package dependencies to the "Empty" Microsoft.NETCore.App package (see #3528):

Microsoft.NETCore.Targets
- This will help fix Restore fails if netstandard1.x package reference is present sdk#3044
- This should be to the corresponding 3.0 version of this package
- We should also remove the runtime.json file from the Microsoft.NETCore.Targets package. It contains "supports" information which is not used anymore.
NETStandard.Library version 2.0.3
- This will prune the 1.x contracts from the dependency graph if they are coming from a package that has a dependency on NETStandard.Library 1.6.1 (or 1.6.0).
- .NET Standard 2.1 uses a targeting pack, so we don't have a 2.1 package to depend on
- We could create an "empty" 2.1 NETStandard.Library package if there's a reason to do so, but at this point I'm not sure there is

@ericstj

@wtgodbe

/cc @wtgodbe on the NETStandard.Library suggestion. We may want to make an empty one. I'll submit a change to empty MS.NETCore.Targets.

I think we should definitely make the empty netstandard 2.1 as well. Let's be consistent here in how these stubs work. I think it will be very confusing to see an actual reference to non-empty netstandard.library 2.0.x injected. It will also cause too much to be downloaded in cases with no legacy refs.

I think I'm missing some context here, why do we need to ship an empty Microsoft.NETCore.App? If we empty out NetStandard.Library, is the intention that the change will be permanent, and other repos should start consuming Microsoft.Private.Standard?

I don't know what Microsoft.Private.Standard is. NETStandard.Library.Ref is the real payload ("targeting pack"). The empty package is a way to short circuit things in nuget while we're currently lacking any other mechanism.

@nguerrera

@nguerrera Microsoft.Private.Standard contains essentially the same bits as Netstandard.Library - I believe Core-Setup currently depends on Microsoft.Private.Standard to get the netstandard bits that it injects into the targeting pack (@dagood can you confirm?). However if we empty out Netstandard.Library, that would break other repos that depend on that package (like corefx), unless we intend for those repos to switch over to Microsoft.Private.Standard. I'm missing some information here, so I'm not sure what the motivation is for this request, or what the guidance is for repos that depend on the packages that are going to become empty.

other repos should start consuming Microsoft.Private.Standard?

I believe the near-term goal is that Core-Setup is the only place referencing dotnet/standard bits, and it does so through the Microsoft.Private.Standard transport package. That's redisted as NETStandard.Library.Ref that should be used everywhere else. (Repos may need to use a new enough SDK to be able to use NETStandard.Library.Ref?)

We're still depending on NETStandard.Library here, but it should just be a matter of changing the PackageReference:

https://github.com/dotnet/core-setup/blob/29f2b13923b066173b1a156516a3f5f8763cb276/src/pkg/projects/netstandard/src/netstandard.depproj#L10

Long-term, dotnet/standard will produce NETStandard.Library.Ref using shared tooling. (And the workaround stub NETStandard.Library.)

For the moment, should we transition CoreFx to Microsoft.Private.Standard, or to NETStandard.Library.Ref? https://github.com/dotnet/corefx/blob/master/eng/Version.Details.xml#L41

Here's the issue for the "empty" Microsoft.NETCore.App implementation that might help with context: https://github.com/dotnet/core-setup/issues/5663.

(I don't know about the migration though.)

@wtgodbe

/cc @wtgodbe

@dagood

@dagood Hold off on this for now, currently we are thinking of not relying on the Microsoft.NETCore.App package.

@dsplaisted

Customers are reporting hitting this issue with the latest sdk, and don't like the manual workaround of having to add a reference to the Targets package. This is a regression, @dsplaisted do we plan to fix this for 3.0?

In case this is weighed against implementation difficulty (although so far it hasn't sounded like it), it's trivial to add workaround package dependencies, they just need to be added to this itemgroup:

https://github.com/dotnet/core-setup/blob/ccf0024ba099103a5b759613c48b8cd46af8754a/src/pkg/projects/netcoreapp/pkg/workaround/Microsoft.NETCore.App.pkgproj#L20-L22

@sbomer

A nestandard2.0 target should be added to Mono.Cecil and Blazor should depend on that.

cc @sbomer

@jbevain

It looks like the code was already moved to netstandard2.0, but no release was pushed to nuget?

jbevain/cecil#599 (comment)

cc @jbevain

@davidfowl

@davidfowl Can you help push 1.x assets out of dotnet new mvc graph?

dotnet new mvc
dotnet restore -r linux-arm

I cannot reproduce this in preview 8.

This didn't trigger it either:

dotnet new blazorserver
dotnet restore -r linux-arm

Neither of these have package references.

I don't think this happens with default projects. The binlog with the failure is linked here. Based on that, the following is a minimal repro:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <RuntimeIdentifier>linux-arm</RuntimeIdentifier>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.Blazor.Server" Version="3.0.0-preview7.19365.7" />
    <PackageReference Include="System.Device.Gpio" Version="0.1.0-prerelease.19376.1" />
  </ItemGroup>

</Project>

For the failure to occur, there need to be dependencies to both 1.0 and 1.1 band contract packages. The Blazor package is bringing in Mono.Cecil which is bringing in 1.0 contracts such as System.IO.FileSystem 4.0.1. The GPIO package is depending on several 1.1 contracts, such as System.Runtime.InteropServices.WindowsRuntime 4.3.0.

As Nick suggests, an updated Mono.Cecil package with a .NET Standard 2.0 version of the library would fix this. Updating the GPIO package so that it doesn't depend on the contract packages should also work if that's possible.

@ericstj

@ericstj and @joperezr pointed me to this issue.

I hit this today upgrading ML.NET to 3.0. Restoring this project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="BenchmarkDotNet" Version="0.11.3" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.8.0" />
  </ItemGroup>
</Project>

with the 3.0.100-preview8-013437 SDK results in:

F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605: Detected package downgrade: Microsoft.Win32.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605:  ThreeOhBug -> Microsoft.NET.Test.Sdk 15.8.0 -> Microsoft.TestPlatform.TestHost 15.8.0 -> Microsoft.TestPlatform.ObjectModel 15.8.0 -> NETStandard.Library 1.6.0 -> System.Net.Primitives 4.0.11 -> runtime.win.System.Net.Primitives 4.3.0 -> Microsoft.Win32.Primitives (>= 4.3.0)
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605:  ThreeOhBug -> Microsoft.NET.Test.Sdk 15.8.0 -> Microsoft.TestPlatform.TestHost 15.8.0 -> Microsoft.TestPlatform.ObjectModel 15.8.0 -> NETStandard.Library 1.6.0 -> Microsoft.Win32.Primitives (>= 4.0.1)
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605: Detected package downgrade: System.Net.Primitives from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605:  ThreeOhBug -> Microsoft.NET.Test.Sdk 15.8.0 -> Microsoft.TestPlatform.TestHost 15.8.0 -> Microsoft.TestPlatform.ObjectModel 15.8.0 -> NETStandard.Library 1.6.0 -> System.Net.Sockets 4.1.0 -> runtime.win.System.Net.Sockets 4.3.0 -> System.Net.Primitives (>= 4.3.0)
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605:  ThreeOhBug -> Microsoft.NET.Test.Sdk 15.8.0 -> Microsoft.TestPlatform.TestHost 15.8.0 -> Microsoft.TestPlatform.ObjectModel 15.8.0 -> NETStandard.Library 1.6.0 -> System.Net.Primitives (>= 4.0.11)
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605: Detected package downgrade: Microsoft.Win32.Primitives from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version.
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605:  ThreeOhBug -> Microsoft.NET.Test.Sdk 15.8.0 -> Microsoft.TestPlatform.TestHost 15.8.0 -> Microsoft.TestPlatform.ObjectModel 15.8.0 -> NETStandard.Library 1.6.0 -> System.Net.Sockets 4.1.0 -> runtime.win.System.Net.Sockets 4.3.0 -> System.Security.Principal.Windows 4.3.0 -> Microsoft.Win32.Primitives (>= 4.3.0)
F:\DotNetTest\ThreeOhBug\ThreeOhBug.csproj : error NU1605:  ThreeOhBug -> Microsoft.NET.Test.Sdk 15.8.0 -> Microsoft.TestPlatform.TestHost 15.8.0 -> Microsoft.TestPlatform.ObjectModel 15.8.0 -> NETStandard.Library 1.6.0 -> Microsoft.Win32.Primitives (>= 4.0.1)

If I literally change any line in the .csproj, it works:

change TFM to netcoreapp2.1 - works
remove RuntimeIdentifier - works
remove either PackageReference - works

Re-opening this issue so it gets noticed.

I don't think this issue can track a fix. We can't use an empty package for reasons that have been discussed.

Well, we can have the empty packages, but we can't auto reference them in the SDK.

dotnet/sdk#3044 tracks the work on the SDK to make these scenarios just work, which after trying many workarounds and failing, is now blocked on NuGet/Home#7344

Both are still open so we should focus there rather than on this workaround issue that won't work.

Please link any reports on either of those issues.

Navigation Menu

Repository navigation

Add dependencies from Microsoft.NETCore.App to Microsoft.NETCore.Targets and NETStandard.Library #3574

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add dependencies from Microsoft.NETCore.App to Microsoft.NETCore.Targets and NETStandard.Library #3574

Description

Activity

dsplaisted commented on May 2, 2019

ericstj commented on May 2, 2019

nguerrera commented on May 2, 2019

wtgodbe commented on May 2, 2019

nguerrera commented on May 2, 2019

wtgodbe commented on May 2, 2019

dagood commented on May 2, 2019

wtgodbe commented on May 2, 2019

dagood commented on May 2, 2019

ericstj commented on May 22, 2019

dsplaisted commented on May 29, 2019

joperezr commented on Aug 2, 2019

dagood commented on Aug 2, 2019

7 remaining items

nguerrera commented on Aug 3, 2019

nguerrera commented on Aug 3, 2019

nguerrera commented on Aug 4, 2019

nguerrera commented on Aug 5, 2019

dsplaisted commented on Aug 6, 2019

eerhardt commented on Aug 9, 2019

eerhardt commented on Aug 9, 2019

nguerrera commented on Aug 9, 2019

nguerrera commented on Aug 9, 2019

nguerrera commented on Aug 9, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions