dotnet build -r runtime --no-restore fails in 2.1.301

[mikeharder]

Repro Steps

1. dotnet new console --no-restore
2. dotnet restore -r win-x64
3. dotnet build -r win-x64 --no-restore

These steps work as expected in CLI 2.1.300. However, in CLI 2.1.301 the build step fails:

C:\Temp\foo\foo.csproj : error : The project was restored using Microsoft.NETCore.App version 2.1.0, but with current settings,
version 2.1.1 would be used instead.  To resolve this issue, make sure the same settings are used for restore and for subsequent
operations such as build or publish.  Typically this issue can occur if the RuntimeIdentifier property is set during build or publish
but not during restore.

The error message is misleading, since the RuntimeIdentifier (-r) is set during both restore and build.

A workaround is to remove the --no-restore from the dotnet build command:

  Restoring packages for C:\Temp\foo\foo.csproj...
  Installing runtime.win-x64.Microsoft.NETCore.DotNetAppHost 2.1.1.
  Installing runtime.win-x64.Microsoft.NETCore.DotNetHostResolver 2.1.1.
  Installing runtime.win-x64.Microsoft.NETCore.DotNetHostPolicy 2.1.1.
  Installing runtime.win-x64.Microsoft.NETCore.App 2.1.1.
  Generating MSBuild file C:\Temp\foo\obj\foo.csproj.nuget.g.props.
  Generating MSBuild file C:\Temp\foo\obj\foo.csproj.nuget.g.targets.
  Restore completed in 24.89 sec for C:\Temp\foo\foo.csproj.
  foo -> C:\Temp\foo\bin\Debug\netcoreapp2.1\win-x64\foo.dll

Is this a bug or by design? Is it expected that dotnet build -r runtime --no-restore should always work after dotnet restore -r runtime?

CC: @JunTaoLuo

[dasMulli]

Looks like a duplicate of #2312

[livarcocc]

@dsplaisted to comment and close.

[dsplaisted]

Here's the documentation of this behavior: https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection

@livarcocc @nguerrera Should we consider setting the RuntimeIdentifier property (instead of the plural RuntimeIdentifiers) when only one RID is passed to restore via -r? It seems like that would make a lot more sense from a user perspective.

[dsplaisted]

Also @KathleenDollard for discussion on whether we should change the behavior of the -r parameter to dotnet restore.

[dasMulli]

Maybe it would help if NuGet actually re-evaluated the project file for each RID, since putting

<RuntimeIdentifiers>osx-x64;win-x64</RuntimeIdentifiers>

no longer helps to fetch all RID-specific packages in advance (in fact, it will even go ahead and download old versions that dotnet publish won't use).
Could also help reduce the number of restore operations since the no-op restore is pretty much useless since the assets file will need updating for each build / publish operation with a difference in -r.

[dsplaisted]

@dasMulli When we were designing the runtime roll-forward for 2.1.300, we considered having separate restores for each RID. We may do so eventually but it would be a significant amount of work. The design we were thinking of was that there would be a separate assets file per combination of Configuration, TargetFramework, and RuntimeIdentifier.

Note that if you want to do self-contained publish for different RIDs, you can set the TargetLatestRuntimePatch to true along with setting the RuntimeIdentifiers property. Then the default restore will restore the right packages. The possible downside is that if you do a Framework-dependent deployment, it will required the latest patch version of the shared framework to run on.

[dsplaisted]

This issue was moved to dotnet/cli#9514