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.

[matthid]

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
• After upgrading to ASP.NET Core 2.1, get error that project will use 2.1.0-rc1. How to fix? aspnetcore#3221
• dotnet build -r runtime --no-restore fails in 2.1.301 #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

[yadavvineet]

I am having different issue. I have version 2.1.302 of SDK installed. But when creating new or opening old project, 2.1.0 is used and not the newer one.

[ann-jie-li]

I have this issue by using 2.1.4 SDK on mac visual studio professional 7.6.4.

[livarcocc]

The 2.1.4 SDK does not support 2.1. The first SDK to support 2.1 was 2.1.300.

[livarcocc]

@matthid getting back to the original issue here, this happens because your createdeb target is trying to publish a self-contained app without using implicit restore, while when the app was restore, it was restored as a framework dependent apps. For FD apps, we always use the lowest version possible, so that it can run on most places. A FD app gets roll forward to the latest patch available on the machine by the host during runtime.

For a self-contained app, it is the opposite, we want it to use the highest version of the runtime that we know of at the publish time, so that it is as safe as possible.

Your solution above is not really recommended. We don't recommend running the restore target along with other targets, as restore itself may bring down props/targets that will not be included in that evaluation/build when done this way.

What you can try to do is invoke msbuild with msbuild /restore /t:CreateDeb, which instructs msbuild to treat the restore separately.

Other than that, this is the expected behavior when the versions don't match. We prefer to fail than to let you publish a potentially not safe app by mistake.

Let me know if my suggestion above does not work.

[matthid]

@livarcocc

target is trying to publish a self-contained app without using implicit restore

Is there a way to enable implicit restore for that target? Or is this some magic only available for a fixed set of targets? I

'll try your suggestion soon, thanks!

[matthid]

@livarcocc Indeed your suggestion with /restore seems to work as well, thanks!

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

[zorgoz]

I had the very same issue just now, but with 2.1.5. Then I have downloaded the SDK installer directly, which has installed 2.1.6. Now I had the same issue with 2.1.6. At this point, I have added the proper RuntimeIdentifiers (plural in my case) to the .csproj and TargetLatestRuntimePatch as true as well (this later might not be needed, but it is suggested at many places, including official documentation). Then I ran a dotnet restore, which downloaded all dependencies for the specified platforms with the proper version. And that was it, the issue is gone.

[jwbats]

I just did what zorgoz did. Now I got this...

Error NETSDK1047 Assets file 'S:\MyProjectDir\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.1/win10-x64'. Ensure that restore has run and that you have included 'netcoreapp2.1' in the TargetFrameworks for your project. You may also need to include 'win10-x64' in your project's RuntimeIdentifiers.

[zorgoz]

@jwbats take a look here: #1321, maybe one of the suggestions will help you out

[livarcocc]

@jwbats what does your project look like? Are you adding win10-x64 as a RuntimeIdentifier? You should be using win-x64 instead.

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