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.