Restore fails with error NU1605 when RuntimeIdentifier is set and ProjectReference is used to netcoreapp2.1 project

[natemcmaster]

Repro
repro.zip

Create two projects:

• src/src.csproj
  • TargetFramework = netcoreapp2.1
  • RuntimeIdentifer = win-x64
• test/test.csproj
  • TargetFramework = netcoreapp2.1
  • ProjectReference to src/src.sproj

Run dotnet restore with the 2.1.301 SDK or newer

Result
Restore fails

/private/tmp/console1/test/test.csproj : error NU1605: Detected package downgrade: Microsoft.NETCore.App from 2.1.1 to 2.1.0. Reference the package directly from the project to select a different version.  [/private/tmp/console1/console1.sln]
/private/tmp/console1/test/test.csproj : error NU1605:  test -> src -> Microsoft.NETCore.App (>= 2.1.1)  [/private/tmp/console1/console1.sln]
/private/tmp/console1/test/test.csproj : error NU1605:  test -> Microsoft.NETCore.App (>= 2.1.0) [/private/tmp/console1/console1.sln]
  Restore failed in 396.65 ms for /private/tmp/console1/test/test.csproj.

Workarounds

• Add <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch> to test.csproj ( suggested by @dsplaisted )
• Add <RuntimeFrameworkVersion>2.1.1</RuntimeFrameworkVersion> to test.csproj
• Add <RuntimeIdentifier>win-x64</RuntimeIdentifier> and <OutputType>exe</OutputType> to test.csproj
• Change <RuntimeIdentifier> to <RuntimeIdentifiers> (plural) in src.csproj

Details

.NET Core SDK (reflecting any global.json):
 Version:   2.1.301
 Commit:    59524873d6

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.13
 OS Platform: Darwin
 RID:         osx.10.13-x64
 Base Path:   /Users/namc/.dotnet/sdk/2.1.301/

cc @dsplaisted

[dsplaisted]

The workaround I would suggest is to set TargetLatestRuntimePatch to true in the test project.

Some related info: https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection

[natemcmaster]

Good suggestion. I added to the list of workarounds above.

How hard would it be to automatically lift to latest when a ProjectReference is using latest (2.1.1) instead of default (2.1.0)?

[natemcmaster]

One more idea: what if we set PrivateAssets=All even when OutputType == exe? Based on this comment, it seems like we don't generally need Microsoft.NETCore.App in the .nuspec with the notable exception (and edge case) of '$(PackageType)' == 'DotnetCliTool'

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.props

Lines 51 to 56 in 1512386

	<!-- For libraries targeting .NET Core 2.0 or higher, don't include a dependency on Microsoft.NETCore.App in the package produced by pack.
	Packing an app (for example a .NET CLI tool) should include the Microsoft.NETCore.App package dependency. -->
	<PackageReference Update="Microsoft.NETCore.App"
	Condition="('$(OutputType)' != 'Exe') And ('$(_TargetFrameworkVersionWithoutV)' != '') And ('$(_TargetFrameworkVersionWithoutV)' >= '2.0')"
	PrivateAssets="All"
	Publish="true" />

[dsplaisted]

I filed #2204 to always set PrivateAssets=All, but we were worried that changing it would break cases where it's needed.

Is DotnetCliTool the only scenario where the reference is needed? Even then, I don't think there is an explicit PackageType or other declaration in the project that it is a DotnetCliTool.

How hard would it be to automatically lift to latest when a ProjectReference is using latest (2.1.1) instead of default (2.1.0)?

Prohibitively hard, I think.

[natemcmaster]

Is DotnetCliTool the only scenario where the reference is needed?

As far as I can tell, yes, this is the only scenario we support. We should be able to use $(PackageType) to detect this. example: https://github.com/aspnet/DotNetTools/blob/2.0.2/src/Microsoft.DotNet.Watcher.Tools/Microsoft.DotNet.Watcher.Tools.csproj#L12

[artiomchi]

In my case, even though I specified the RuntimeIdentifier on the src project, I actually wanted the app to be published in Framework Dependent mode. So my solution was to set <SelfContained>false</SelfContained> in the project. This prevented the test and src projects from using different runtimes.

[dsplaisted]

This should be fixed in the 2.2.100 SDK with #2395

[MisinformedDNA]

Is 2.2.100 released? I don't see it in the Releases.