Microsoft.NETCore.App.Host.win-x64 not found while nuget restore starting dotnetcore SDK 3.1.420

Question

Context

After migrating to version 3.1.420 of dotnetcore SDK (installed automatically by Windows Update) we are facing the problem, that a solution failed to build (on a build server) because nuget restore is unable to restore the package Microsoft.NETCore.App.Host.win-x64 .

We have local package feeds configured in nuget.config, the source nuget.org is not and must not accessed directly!

Now I get the following output:

c:\> nuget.exe restore ***.sln -NoCache -NonInteractive -ConfigFile .nuget\NuGet.config
[...]
Errors in C:\build\_work\313\s\***.csproj
    NU1101: Unable to find package Microsoft.NETCore.App.Host.win-x64. No packages exist with this id in source(s): ***, ***, ***

NuGet Config files used:
    C:\build\_work\313\s\.nuget\NuGet.config

Feeds used:
    https://***.com/tfs/***/_packaging/A***/nuget/v3/index.json
    https://***.com/tfs/***/_packaging/B***/nuget/v3/index.json
    https://***.com/tfs/***/_packaging/C***/nuget/v3/index.json

Environment:

C:\build\_work\313\s>dotnet --list-sdks
3.1.420 [C:\Program Files\dotnet\sdk]
5.0.400 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]

Question

Why restore process tries to fetch the nuget package while the content is already part of the SDK installed?

What I've tried?

I've analyzed the behavior of the nuget.exe using Process Monitor (Sysinternals). I found that the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.25\ is accessed but not found, only the folder 3.1.26 exists after update of SDK.

Why restore process tries to access "3.1.25" while "3.1.26" is installed?

On my local machine the restore works as expected. The package is NOT available in my local NuGet cache. Here the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.26\ is accessed as expected.

I also tried to reinstall the SDK version. No effect.

Answer 1

Firstly, I highly recommend avoiding nuget.exe restore . If you can, prefer dotnet restore , and otherwise msbuild -t:restore . It's unrelated to the problem you're having here, but you can avoid different types of problems by migrating.

Anyway, the .NET Core SDK 3.1.419 would have had the version 3.1.25 versions of the runtime host, whereas .NET Core SDK 3.1.420 has version 3.1.26 of the runtime hosts. Hence, when the SDK upgraded from 419 to 420, the old version of the runtime host was removed, and the new one installed.

However, as your dotnet --list-sdks output shows, you have the .NET 5 SDK installed. .NET 5 is now out of support, and so it did not receive any update in this month's Patch Tuesday. In May, the last month that the .NET 5 SDK was updated, the latest version of the .NET 3.1 hosting app package was 3.1.25, so when you restore/build an app targeting .NET Core 3.1 with the .NET 5 SDK, the SDK checks for the version of the runtime hosting package it knows about, sees it isn't available locally, and then tells NuGet to download it.

You can either use a global.json to pin that directory's dotnet commands to the .NET 3.1 SDK, or you can install the June 2022 .NET 6 SDK (6.0.301), and then both of them will know that the .NET 3.1 runtime hosting package is version 3.1.26, and therefore should not ask NuGet to download it. Well, unless you uninstall the .NET 3.1 SDK completely and use the .NET 6 SDK to build it.

I know it's confusing. The .NET marketing people chose names that doesn't aid in understanding the difference, but the .NET SDK are build tools that can build any version of .NET equal or lower version, and the .NET runtime is completely independent. As mentioned previously in this answer, you can build .NET Core 3.1 apps with the .NET 6 SDK, the .NET Core 3.1 SDK is not needed (but the runtime will be, unless you publish a "self-contained" app).