Difference in restore behaviour with same SDK version

[Zastai]

Describe the bug

After updating Visual Studio 2022 Build Tools from 17.3.2 to 17.6.5 on a Jenkins build node, builds started failing (even after explicitly adding the 6.0.412 SDK just in case):

$ dotnet --list-sdks
6.0.412 [C:\Program Files\dotnet\sdk]
7.0.306 [C:\Program Files\dotnet\sdk]

$ dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.32 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

$ dotnet publish my-project --configuration Release --self-contained true --output "my-path" --framework net6.0-windows -r win-x64
MSBuild version 17.6.8+c70978d4d for .NET
  Determining projects to restore...
my-project\my-project.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.win-x64 with version (= 6.0.20)
my-project\my-project.csproj : error NU1102: - Found 3 version(s) in Nexus [ Nearest version: 6.0.12 ]
my-project\my-project.csproj : error NU1102: Unable to find package Microsoft.WindowsDesktop.App.Runtime.win-x64 with version (= 6.0.20)
my-project\my-project.csproj : error NU1102: - Found 3 version(s) in Nexus [ Nearest version: 6.0.12 ]
my-project\my-project.csproj : error NU1102: Unable to find package Microsoft.AspNetCore.App.Runtime.win-x64 with version (= 6.0.20)
my-project\my-project.csproj : error NU1102: - Found 3 version(s) in Nexus [ Nearest version: 6.0.12 ]

Note: our package access is locked down; only our private Nexus instance is allowed as a source of packages.

The exact same project, on a machine with VS2022 Enterprise 17.6.5 and the exact same .NET SDKs (6.0.412 and 7.0.9) performs the publish just fine, even after clearing the nuget locals entirely.
In particular, when it runs, the ProcessFrameworkReferences task does not spit out those 3 packages as _PackageToDownload while on the build node it does (despite it having the same SDKs and runtimes installed).

I doubt the VS2022 version is particularly relevant, because this looks like pure .NET SDK behaviour. But it is not clear to me why that task behaves differently in the two environments, and what can be done to avoid the package download(*).

(*) for now I resolved the issue by adding the 6.0.20 versions of those 3 packages to Nexus, but it is not really a viable long-term solution to do that for all current-and-historic runtime versions "just in case".

[baronfel]

The version of the runtime to bundle against is something that floats with each serviced version of the .NET SDK. If you want to truly isolate your package sources, you likely will either need to port the runtime packages over each month as they are released, or explicitly set the version of the runtime you would like to use via the RuntimeFrameworkVersion property. Note that setting this explicitly will no longer update your runtime, causing potential security holes.

[Zastai]

But if it floats with the SDK, why is it not included with the SDK? This is only a problem because it hits the package feed instead of getting it from the SDK folder.

[marcpopMSFT]

We eventually want to improve the acquisition experience to allow for the runtime packs to be installed with the SDK (and updated with the SDK). At the moment though, they are downloaded separately from nuget because of size. We could download the version that matches your current platform and that wouldn't be too bad an increase but if we wanted to include additional platforms, the size on disk would expand rapidly. As you can see, there are a lot of different runtime packs for each target platform: https://www.nuget.org/packages?q=microsoft.netcore.app.runtime

So for the moment, we give customers the option to pin to a specific version per Chet's comment above and download what we need from the feed source configured.

[Zastai]

Fair enough. Including all runtimes would indeed make it quite big.

I suppose what would be useful is to have installable versions of it. I can go to aka.ms/dotnet-download and acquire both an sdk and a runtime package for my system (say, win-x64).

But I believe it will still use nuget to acquire the runtime parts to use for a self-contained install targeting the exact runtime already present on the machine. If a separate downloadable installer was added for the "runtime targeting package", or, even better, the sdk would use any locally installed runtimes without falling back on a nuget package install, that would be great (and require no extra effort when not cross-targeting, because I assume the win-x64 sdk includes the win-x64 runtime already).