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

Question

I'm developing a mobile app and using MS App Center for CI. Yesterday the Unit Test project failed to build in App Center with the following error. I couldn't recreate the issue on any developer machine, this error only occours in App Center.

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

Their paid support just give the basics, clean the project, roll back my last commit ect. Has anyone come into this issue before on App Center?

easiest way to avoid this issue is to build using the same configuration that you want to publish using and then run dotnet publish --no-restore -r win10-x64 or whatever runtime you expect to publish to — Jazb, Dec 11 '18 at 09:14
I can't control the commands used by App Center, it's a SaaS-based CI. — Chris Sewell, Dec 11 '18 at 09:18
you may have to raise it with somebody who does have control then — Jazb, Dec 11 '18 at 09:21
If this is the only way to fix then it's likely a problem with their platform yes. Is there some way to control the configuration in the csproj or sln files? — Chris Sewell, Dec 11 '18 at 09:23

score 34 · Answer 1 · answered Jan 17 '19 at 17:02

34

You need to set the same publish and building runtimes

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RuntimeFrameworkVersion>2.1.0</RuntimeFrameworkVersion> --> fix publishing issues
    <PlatformTarget>AnyCPU</PlatformTarget> --> fix publishing issues
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Update="Microsoft.NETCore.App" Version="2.1.0" /> --> fix building issues
    <ProjectReference Include="..\PublicSonar.Monitor.Persistent.Json\PublicSonar.Monitor.Persistent.Json.csproj" />
  </ItemGroup>
</Project>

answered Jan 17 '19 at 17:02

Pavlo Datsiuk

701
4
14

1

Hi Paul, could you possibly elaborate for this answer please, I get this problem after running a publish as a self hosting executable, does that quietly swap out the target SDK? The solution you suggested was simple and straight forward and worked, so thank you – Mike Feb 20 '19 at 07:53
Where is this XML from? – Ian Warburton Dec 18 '19 at 18:40
from csproj file – Pavlo Datsiuk Dec 19 '19 at 15:25

score 11 · Answer 2 · edited Jul 03 '19 at 15:24

11

If you use Azure DevOps, don't edit project file. Use "dotnet restore"(https://docs.microsoft.com/en-us/azure/devops/pipelines/languages/dotnet-core?view=azure-devops) instead of Nuget restore:

Replace this:

- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

With this:

- script: dotnet restore

edited Jul 03 '19 at 15:24

Nasreddine

33,475
17
73
91

answered Mar 28 '19 at 04:37

Quốc Ngô Đức

119
1
3

score 5 · Answer 3 · answered May 01 '19 at 18:38

5

Try Adding <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>to your <PropertyGroup> tag. Example :

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
    <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
  </PropertyGroup>

answered May 01 '19 at 18:38

Amir Shirazi

456
4
8

The only solution that worked for me. Thanks for saving my day! – neeohw Apr 08 '20 at 10:54

score 4 · Answer 4 · answered Apr 09 '19 at 22:04

I am on Visual Studio 2019. I encountered this issue when I tried to publish my project as Self-contained for the second time.

What I did to get rid of this error was:

Change the Deployment Mode to Framework Dependent
Publish the project
Change it back to Self-contained and published again

It seemed to be caused by some faulty cache that can be cleared by switching to a different deployment mode.

score 2 · Answer 5 · answered Mar 09 '20 at 07:37

2

Add this in the .csproj

<PropertyGroup>
<RuntimeFrameworkVersion>2.1.5</RuntimeFrameworkVersion>
</PropertyGroup>

answered Mar 09 '20 at 07:37

pranav aggarwal

103
3

This made my day..oops night! – Anuj May 18 '20 at 23:35

score 1 · Answer 6 · answered Apr 05 '19 at 06:41

1

I am on Visual Studio 2019 and this answer put me on the right path, my procedure was:

Uninstall all instances of Microsoft .NET Core SDK off my machine.
Restarted computer.
Installed latest version of the SDK from here.

answered Apr 05 '19 at 06:41

Jonathan L.

513
4
9

score 1 · Answer 7 · answered Oct 30 '19 at 08:34

1

I had this problem because I had a nuget source that was no longer existing. After removing the faulty nuget source I restored the project and everything worked.

I restored the project via commandline:

dotnet restore

answered Oct 30 '19 at 08:34

M4n1

41
1
6

score 0 · Answer 8 · answered Aug 24 '19 at 09:27

0

Check also the solution I suggested here (Using Azure Pipelines with multi targeting projects I get error NETSDK1061), maybe it works for you, too:

- task: NuGetToolInstaller@0
  inputs:
    versionSpec: '>=4.3.0'
    checkLatest: true

answered Aug 24 '19 at 09:27

ioan

702
3
10

score 0 · Answer 9 · answered Sep 06 '19 at 07:21

What solved the issue for me, was to update the default NuGet package cache 'C:\Users\.nuget\packages' used for restore by changing the parameter in msvc:

Tools > Options > NuGet Package Manager > Package Restore > Allow NuGet to download missing package & Automatically check for missing packages during build in Visual Studio.

score 0 · Answer 10 · answered Dec 20 '19 at 15:30

I had this issue when building in Azure Devops and none of the other answers would fix it. My Build and Publish steps already had matching --runtime options.

The fix for me turned out to be to add the following into the the .csproj file (substitute the RuntimeIdentifier with the correct one for your deployment scenario):

  <PropertyGroup>
      ...
      <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>

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

10 Answers10

Linked