error : The project was restored using Microsoft.NETCore.App version 2.1.0, but with current settings, version 2.1.2 would be used instead.

Generally I’d like to know if this “breaking” change was intended and bring up awareness if it wasn’t. If everything is fine I’m happy with the workaround but would like to understand why I can no longer call dotnet restore in a separate call.

Steps to reproduce

The error appeared after updating to 2.1.302 from 2.1.300, Basically after this commit

• Travis

Expected behavior

Works as it did in 2.1.300

Actual behavior

E:\Projects\FAKE\src\app\fake-cli\fake-cli.fsproj : error : The project was restored using Microsoft.NETCore.App version 2.1.0, but with current settings, version 2.1.2 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.

Workaround

The workaround was to not try to call the “Restore” and “CreateDeb” separately, but on the same call:

Basically, I now call msbuild /t:Restore;CreateDeb instead of first dotnet restore followed by msbuild /t:CreateDeb… Commit fixing the issue

Related issues

• https://github.com/dotnet/cli/issues/9519
• https://github.com/aspnet/Home/issues/3221
• https://github.com/dotnet/sdk/issues/2344

Environment data

The CreateDeb target is imported from https://github.com/qmfrederik/dotnet-packaging

Project File:

• before
• after workaround

(see diff of the workaround)

dotnet --info output (But really it happened on all CI systems):

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.302
 Commit:    9048955601

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.302\

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

.NET Core SDKs installed:
  2.1.302 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[jwbats]

I’m using…

dotnet publish -c Release -r win-x64 -o bin\Release\PublishOutput

… and getting …

Error NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.4, but with current settings, version 2.1.0 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. For more information, see https://aka.ms/dotnet-runtime-patch-selection.

[jwbats]

@livarcocc I was indeed using win10-x64 as a RuntimeIdentifier. Incorrectly so, because my publish command (which I stuffed into a .bat file) was already making use of win-x64. So that’s the RID I intended to use. Anyway, I used win-x64 like you suggested and I can now build my project from the CLI without it causing an error in my project. I thank you for finally solving this thorn in my side, which had been there for too many weeks.

When I first created my project, VS did not put those properties in my csproj. Why does this work like this? Are TargetLatestRuntimePatch and RuntimeIdentifiers required properties now? Why does my VS build not cause errors, but my CLI build does (without these props)?

Why does the csproj allow for the setting of multiple RunTimeIdentifiers? You can only build for one RID at a time, and you define this in your CLI publish command.