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

Created on 26 Jun 2018 · 10Comments · Source: dotnet/sdk

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

Source

natemcmaster

👍5

Most helpful comment

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

dsplaisted on 26 Jun 2018

👍4

All 10 comments

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

dsplaisted on 26 Jun 2018

👍4

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 on 26 Jun 2018

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'

https://github.com/dotnet/sdk/blob/1512386f2c279f2146d7c58cecde989bc2ec9176/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.props#L51-L56

natemcmaster on 26 Jun 2018

👍1

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.

dsplaisted on 26 Jun 2018

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

natemcmaster on 26 Jun 2018

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.