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

[jkotas]

From @gpresland on November 19, 2018 21:38

Creating a simple project from scratch and attempting to build it throws multiple errors with SDK 2.1.500.

Create a new project with:

dotnet new webapi -o example
cd example
code

Inside Visual Studio Code run:

dotnet publish -c Release -r win10-x64

You will be spammed with errors such as:

[fail]: OmniSharp.MSBuild.ProjectLoader
        NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.6, 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.

Copied from original issue: dotnet/coreclr#21095

[livarcocc]

cc @dsplaisted

[dsplaisted]

@DustinCampbell does VS Code have an auto-restore? How does that work?

[NatElkins]

Just want to chime in and say I'm also getting this error. Even when I clean my solution (dotnet clean Mysln.sln) and re-restore it (dotnet restore Mysln.sln -r linux-x64). The command I get these errors on is dotnet publish -o ./publish -r linux-x64.

[dsplaisted]

@NatElkins Is VS Code involved at all when you are hitting this? The original report involved using VS Code, so I'd like to understand in what contexts the issue is occurring.

[NatElkins]

@dsplaisted No, VSCode is not involved at all.

[gpresland]

The issue also appears when using Visual Studio.

Severity	Code	Description	Project	File	Line	Suppression State
Error		NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.6, 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.

Severity	Code	Description	Project	File	Line	Suppression State
Error		NETSDK1061: The project was restored using Microsoft.AspNetCore.App version 2.1.6, 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. For more information, see https://aka.ms/dotnet-runtime-patch-selection.

[NatElkins]

@dsplaisted Not sure about everyone else's problem, but my error seemed to be caused by having a transitive project dependency that was an executable. This worked just fine for me when I would do dotnet build, but would fail when I tried to do dotnet publish -r linux-x64. When I shifted things around to make the dependencies libraries (and make the executable a separate project) things started working.

If referencing an executable project as a dependency is not permitted, ideally the sdk/CLI would be able to detect this scenario and provide a less confusing error message.

[gauravagarwal28]

I have the same issue.

[JackYumCha]

@dsplaisted Not sure about everyone else's problem, but my error seemed to be caused by having a transitive project dependency that was an executable. This worked just fine for me when I would do dotnet build, but would fail when I tried to do dotnet publish -r linux-x64. When I shifted things around to make the dependencies libraries (and make the executable a separate project) things started working.

If referencing an executable project as a dependency is not permitted, ideally the sdk/CLI would be able to detect this scenario and provide a less confusing error message.

Yes. Fixed.

In my case, I got that error when publish target is osx. If I choose portable, it works without any issue.

[gllanderas]

I had similar problem, and I solved it indicating in the csproj file the version of the runtime framework to use:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RuntimeFrameworkVersion>2.1.5</RuntimeFrameworkVersion>
  </PropertyGroup>

</Project>

I saw the solution at: https://stackoverflow.com/questions/53720678/netsdk1061-the-project-was-restored-using-microsoft-netcore-app-version-1-0-0

[DustinCampbell]

@dsplaisted:

does VS Code have an auto-restore? How does that work?

Nope. It doesn't it. The C# for VS Code experience is designed around working with the .NET Core SDK at the command line. There is a way that you can run a restore within C# for VS Code, but it's pretty basic.

[eerhardt]

@dsplaisted - @imback82 is having the same problem:

What happens if you start clean and don't call restore at all?

git clean -xdf
dotnet publish -f netcoreapp2.1 -r win10-x64

?

I get the following (the original error I posted):

C:\SampleApp>dotnet publish -f netcoreapp2.1 -r win10-x64
C:\SampleApp\SampleApp.csproj : error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.7, but with current settings, version 2.1.0 would be used instead.

[imback82]

@dsplaisted - @imback82 is having the same problem:

I have project A (which produces EXE) that references project B (which also produces EXE). If I self-publish only the project B, it is fine. However, self-publishing project A results in NETSDK1061 which complains the mismatch in runtime version in project B.

I understand that it is werid to have EXE project to referece another EXE project, but the error message is not intuitive if this scenario is not supported.

[StingyJack]

I'm getting this error when trying to use the MSBuild task on an Azure DevOps hosted 2017 build for a netcore unit test project testing a netstandard20 assembly. I had to add a "dotnet restore" task before the MsBuild task to fix it. Forcing a latest version of nuget.exe or /t:Pack did not fix it.

[amlosi]

I get the error when I add any -r option. E.g.
dotnet publish myproj.csproj -r "win-x64"
It works without the -r option. Here are runtimes I have tried:
"win10-x64", "linux-x64", "linux-arm", "win-x64", "win10-x86", "win-x86".
Error looks like this (partial log listing):
error : NETSDK1061: The project was restored using Microsoft.AspNetCore.App version 2.2.1, but with current settings, version 2.2.0 would be used instead.

Any ideas why this should be a problem?

[NatElkins]

@amlosi There are two reasons I see this kind of error pop up often.

1. You are trying to reference a project as a library that's actually an exe.

2. You try to publish for a platform, but the last time you did a restore it was for the "portable" version of things.

Imagine this situation. You write some code. Then you do dotnet build MySln.sln. Build looks good. Then you try and do dotnet publish MyProj.csproj -r win-x64, and it complains. But it just built fine a second ago!

It's because the last restore wasn't for that specific platform, it was for whatever the "portable" version of things was. So what you probably need to do is restore, but using the platform specific version of things. Try this:

dotnet restore MySln.sln -r win-x64
dotnet publish MyProj.csproj -r win-x64

I see this issue all the time, it's a very common error, and just a horrible UX oversight. I don't know all the ins and outs and edge cases of MSBuild, but it seems like the sane behavior would be to automatically restore with the correct runtime option if you're trying to publish. Why MS chose to not do this and instead provide an inscrutable error, I don't know.

[amlosi]

@NatElkins thanks for the suggestion. It turns out that the restore was not the issue. I needed to change a referenced project to type library. I.e. change this:

<OutputType>Exe</OutputType>

to this:

<OutputType>Library</OutputType>

[NatElkins]

@amlosi Yeah that was the first error that I mentioned. You can also omit OutputType entirely, it will be a library by default.

[dsplaisted]

it seems like the sane behavior would be to automatically restore with the correct runtime option if you're trying to publish

@NatElkins This is essentially what does happen- since .NET Core 2.0 (IIRC), the publish command will automatically restore. So I think that in order to hit the second cause of the issue you listed you would generally need to explicitly specify --no-restore as an argument to publish

This mismatch issue should be fixed when targeting .NET Core 3.0, as we've made changes to how the self-contained assets are delivered that don't require those RID-specific assets to be in the assets file.

[eerhardt]

@dsplaisted - is the following scenario fixed in 3.0 as well?

I have project A (which produces EXE) that references project B (which also produces EXE). If I self-publish only the project B, it is fine. However, self-publishing project A results in NETSDK1061 which complains the mismatch in runtime version in project B.

[dsplaisted]

@eerhardt It should be fixed in the sense that you won't get the same error when you build. There might be other things that don't work, for example if you expect to be able to run project B from the output folder of project A, that could fail for a variety of reasons (dependencies aren't the same, runtimeconfig files don't get copied...)

[mafshin]

I had the same problem with version 2.2 and 2.2.3 which is resolved by adding TargetLatestRuntimePatch in csproj as suggest here

<PropertyGroup>
  <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
</PropertyGroup>

[bitbound]

As @mafshin commented, I also solved this by using :

<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>.

Another problem resolved by this: In Visual Studio, the Microsoft.NETCore.App NuGet package for the affected project was stuck at version 2.2.0, even though I have 2.2.203 SDK (2.2.4 runtime) installed. It says "Blocked by project" in the drop-down with the little message below that says "Implicitly referenced by the SDK. To update the package, update the SDK to which it belongs." Very misleading, if you ask me.

After adding TargetLatestRuntimePatch, the correct runtime version was selected.

[dsplaisted]

@jay-rad You do not need to reference the latest patch of the Microsoft.NETCore.App NuGet package when building. So it is expected that at build time it would reference version 2.2.0. At runtime it will use the latest patch that is installed, so 2.2.4 in your case.

We know that this can be confusing, and for .NET Core 3.0 we have made changes to the way the framework is referenced that we think will avoid these issues and be less confusing.

Thanks,
Daniel

[michaelveloz]

From a person new to .net core, this is a mess. I'm getting the NETSDK1061 error on a new project which consists of one exe and two libraries, all targeting 2.1. Each of those things also have a dependency on Newtonsoft.Json.

If I get rid of all .net core installations except 2.1, I do not get the error, but as soon as another 2.x version of .net core gets installed on my system, I get the error.

If I use the above recommendation of adding <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch> to all the .csproj's, I get what appears to be the opposite error NU1605 "Detected package downgrade. NETCore.App from 2.1.9 to 2.1.0"

I really want to solve the problem, and not get into finger pointing, but steam is coming out of my ears. It feels like VS 2019 is half-baked when it comes to .net core if a simple project like this can throw errors that are not due to actions the developer has taken, and worse yet, does not offer useful solutions. UGH!

So, what are my options at this point? I see from the comments above 3.0 addresses this, but that's not going to be released until "later in the year" afaik.

Any suggestions would be a great help

Update: i just uninstalled the patch version if 2.1.9, leaving only 2.1.0 on my system, and I am not getting the publishing errors. Obviously this is not a long term solution.

[bitbound]

@dsplaisted Thanks for the info, Daniel. What you're saying makes sense. I must say, it does make the message in Visual Studio even more misleading, though. :)

[dsplaisted]

@michaelveloz Sorry that you're having problems. I'm not exactly sure what is going on in your case. I would recommend using the 2.2.106 SDK, even if you are targeting .NET Core 2.1. If you still have issues when using that SDK, the easiest way for us to investigate what's going on would be if you can provide a binlog of your failing build.

Thanks!

[dhutarn]

A common scenario for having a project referencing another project that generates an executable is having a unit test library to test that executable. As described in https://docs.microsoft.com/en-us/dotnet/core/tutorials/testing-with-cli.

[morganjc50]

Just chiming in that I am seeing the same issue running in ubuntu between dotnet 2.2.0 and dotnet 2.2.5.
error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.2.5, but with current settings, version 2.2.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.

[donaldgray]

I'm also seeing this on a completely new checkout of an existing repo for debian-x64. I'm running:

git clone https://github.com/myorg/repo-name.git
cd repo-name
dotnet restore -r debian-x64
dotnet build -r debian-x64 --no-restore

After running the build I get the following error:

error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.2.0, but with current settings, version 2.2.5 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.

If I run without -r debian-x64 it works okay.
As mentioned above adding <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch> allows me to use -r debian-x64.

[Doggie52]

Seeing the same as everyone else, publishing to linux-x64 on a Windows 10 machine. I have two projects in the solution, and only one is set to output Exe - the other is Library.

Same solution as @donaldgray - had to apply it to both projects.

[douglasg14b]

Same error when publishing for win-x64 on a project that used to build just fine.

NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.2.8, but with current settings, version 2.2.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.