Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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. #2682

Open
jkotas opened this issue Nov 20, 2018 · 30 comments

Comments

Projects
None yet
@jkotas
Copy link
Member

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

@dsplaisted

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

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

@NatElkins

This comment has been minimized.

Copy link

commented Nov 20, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 20, 2018

@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

This comment has been minimized.

Copy link

commented Nov 20, 2018

@dsplaisted No, VSCode is not involved at all.

@gpresland

This comment has been minimized.

Copy link

commented Nov 21, 2018

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

This comment has been minimized.

Copy link

commented Nov 21, 2018

@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

This comment has been minimized.

Copy link

commented Jan 10, 2019

I have the same issue.

@JackYumCha

This comment has been minimized.

Copy link

commented Jan 14, 2019

@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

This comment has been minimized.

Copy link

commented Jan 29, 2019

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

This comment has been minimized.

Copy link
Member

commented Jan 30, 2019

@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

This comment has been minimized.

Copy link
Member

commented Feb 22, 2019

@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

This comment has been minimized.

Copy link

commented Feb 23, 2019

@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

This comment has been minimized.

Copy link

commented Mar 11, 2019

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

This comment has been minimized.

Copy link

commented Mar 19, 2019

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

This comment has been minimized.

Copy link

commented Mar 19, 2019

@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

This comment has been minimized.

Copy link

commented Mar 19, 2019

@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

This comment has been minimized.

Copy link

commented Mar 19, 2019

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

@dsplaisted

This comment has been minimized.

Copy link
Member

commented Mar 21, 2019

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

This comment has been minimized.

Copy link
Member

commented Mar 21, 2019

@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

This comment has been minimized.

Copy link
Member

commented Mar 21, 2019

@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

This comment has been minimized.

Copy link

commented Mar 30, 2019

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>
@Jay-Rad

This comment has been minimized.

Copy link

commented Apr 17, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

@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

This comment has been minimized.

Copy link

commented Apr 17, 2019

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.

@Jay-Rad

This comment has been minimized.

Copy link

commented Apr 17, 2019

@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

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

@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!

harrisaoz added a commit to harrisaoz/ProcessAttachments that referenced this issue May 22, 2019

Library dependency must not generate an executable.
If an executable is generated, then dotnet publish fails with an arcane error message.
See dotnet/sdk#2682.
@dhutarn

This comment has been minimized.

Copy link

commented May 27, 2019

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

This comment has been minimized.

Copy link

commented Jun 5, 2019

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

This comment has been minimized.

Copy link

commented Jun 28, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.