sdk: Dotnet SDK 2.1.401 has runtime version 2.1.3-servicing-26724-03

Steps to reproduce

Checkout this repo at tag v2.1.401 Run ./build.sh /t:Compile Open shared/Microsoft.NETCore.App directory from build output

Expected behavior

We see a folder named 2.1.3, and can restore/publish/run applications against framework 2.1.3.

Actual behavior

We see a folder named 2.1.3-servicing-26724-03. This doesn’t seem to be the case when following the steps for installing (vs building from source): https://www.microsoft.com/net/download/linux-package-manager/ubuntu14-04/sdk-current

Supplying this value in the .csproj produces the following warning:

/tmp/app/msbuild_self_contained.csproj : warning NU1603: msbuild_self_contained depends on Microsoft.NETCore.App (>= 2.1.3-servicing-26724-03) but Microsoft.NETCore.App 2.1.3-servicing-26724-03 was not found. An approximate best match of Microsoft.NETCore.App 2.1.3 was resolved.
   2018-08-27T10:31:35.18-0400 [STG/0] OUT        /tmp/app/msbuild_self_contained.csproj : error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.3, but with current settings, version 2.1.3-servicing-26724-03 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.

This seems to be similar to https://github.com/dotnet/cli/issues/9456.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 28 (14 by maintainers)

Commits related to this issue

Cherry pick dotnet commit for version 2.1.401 See https://github.com/dotnet/cli/issues/9897#issuecomment-416361988 — committed to SUSE/buildpacks-ci by mudler 6 years ago
Cherry pick dotnet commit for version 2.1.401 See https://github.com/dotnet/cli/issues/9897#issuecomment-416361988 — committed to SUSE/buildpacks-ci by mudler 6 years ago
Cherry pick dotnet commit for version 2.1.401 See https://github.com/dotnet/cli/issues/9897#issuecomment-416361988 — committed to SUSE/buildpacks-ci by mudler 6 years ago
Cherry pick dotnet commit for version 2.1.401 See https://github.com/dotnet/cli/issues/9897#issuecomment-416361988 — committed to SUSE/buildpacks-ci by mudler 6 years ago
Patch dotnet build script only on specific versions Get rid off the TODOs and handle https://github.com/dotnet/cli/issues/8358 Cherry pick dotnet commit for version 2.1.401 See https://github.com/d... — committed to SUSE/buildpacks-ci by mudler 6 years ago
Patch dotnet build script only on specific versions Get rid off the TODOs and handle https://github.com/dotnet/cli/issues/8358 Cherry pick dotnet commit for version 2.1.401 See https://github.com/d... — committed to SUSE/buildpacks-ci by mudler 6 years ago

Most upvoted comments

It’s come to my attention that VS 15.8.2 did not include the correct, final build of the 2.1.401 SDK. We are working on resolving this issue. In the meantime, uninstalling the 2.1.401 SDK installed by Visual Studio and installing the SDK from the .NET Downloads site should correct the issue.

+12

peterhuene on Aug 29, 2018

I too ran into the following error after I updated to Visual Studio 2017.8.2 last night:

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

Simply uninstalling and reinstalling the .NET Core SDK - 2.1.401 resolved it for me as well.

+11

joshuadavidson on Aug 29, 2018

That’s correct. For people who got the wrong version, uninstalling and installing the correct one is the appropriate thing to do.

livarcocc on Sep 7, 2018

This is showing as fixed with 15.8.3 however - still had to uninstall and re-install 2.1.401 SDK to successfully publish.

NinjaKitt3n on Sep 7, 2018

i’ve just updated VS2017.8.2 and run in this? issue. I can’t compile my code anymore!

To reproduce (dotnet.exe --version = 2.1.401):

1. dotnet new console
2. dotnet.exe build --runtime win-x86
3. Build FAILED.

c:\Dev\Local\src\Sandbox\dotnet\xxx\xxx.csproj : warning NU1603: xxx depends on Microsoft.NETCore.App (>= 2.1.3-servicing-26724-03) but Microsoft.NETCore.App 2.1.3-servicing-26724-03 was not found. An approximate best match of Microsoft.NETCore.App 2.1.3 was resolved.
c:\Dev\Local\src\Sandbox\dotnet\xxx\xxx.csproj : warning NU1603: xxx depends on Microsoft.NETCore.App (>= 2.1.3-servicing-26724-03) but Microsoft.NETCore.App 2.1.3-servicing-26724-03 was not found. An approximate best match of Microsoft.NETCore.App 2.1.3 was resolved.
c:\Dev\Local\src\Sandbox\dotnet\xxx\xxx.csproj : error : NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.3, but with current settings, version 2.1.3-servicing-26724-03 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.
    2 Warning(s)
    1 Error(s)

Edit: i have solved my Problem by uninstall all of dotnet core and it related folders, and then install SDK 2.1.401 anew

s-trooper on Aug 29, 2018

@livarcocc In my opinion, a 2.1.402 needs to be pushed out in a VS update to complete solve the issue for all users. Only a version increment will insure everyone is using correct builds and the VS installer will actually update the installed SDK version. The current 15.8.3 update does nothing (!) on affected machines that had the bad 15.8.2 version installed.

dasMulli on Sep 7, 2018

Yeah, I think we should update the tick-tock to include ensuring the dependencies are updated before tagging, either via a maestro merge or manually. I’d hate to have this continue to happen to our community partners that build their packages from source tags.

peterhuene on Aug 27, 2018

2.1.402 is being pushed to an update of VS. However, we couldn’t put it in 15.8.3 because it was already done and it contains things that we couldn’t put it out in the wild sooner.

livarcocc on Sep 7, 2018

Maybe you should finally separate SDK updates from Visual Studio updates? (Android Studio has it)

//Edit: Thanks for your solution.

spixy on Sep 3, 2018

@peterhuene I did what you suggested and everything is working now. Thanks for your help!

spechacek on Aug 29, 2018

We shouldn’t re-tag, as the official 401 build came out of the commit with the marked SHA, but because it was a prodcon build, it has different dependencies. Our agreement is to create a second tag, v.2.1.401+dependencies that contains the updated dependencies.

livarcocc on Aug 27, 2018