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

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

[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]

This issue was moved to dotnet/cli#9514