Dotnet restore is unable to find runtime.*.Sytem packages after updating the SDK from 8.0.401 to 9.0.100-rc.1.24452.12 when using lock files

[breidikl]

NuGet Product Used

dotnet.exe

Product Version

.NET SDK 9.0.100-rc.1.24452.12

Worked before?

.NET SDK 8.0.401

Impact

I'm unable to use this version

Repro Steps & Context

We have multiple csproj files in our org that include various runtime.*.System packages as transitive dependencies, which do get resolved in packages.lock.json, similar to the following:

      "runtime.win.System.Diagnostics.Debug": {
        "type": "Transitive",
        "resolved": "4.3.0",
        "contentHash": "hHHP0WCStene2jjeYcuDkETozUYF/3sHVRHAEOgS3L15hlip24ssqCTnJC28Z03Wpo078oMcJd0H4egD2aJI8g=="
      },

When running the following after updating the SDK version:

dotnet.exe restore --use-lock-file --no-dependencies /p:ImportProjectExtensionProps=false /p:ImportProjectExtensionTargets=false /p:PublishReadyToRun=true /p:CommandlinePlatform=x64 /nodeReuse:false /maxcpucount:1 --lock-file-path "packages.lock.json"

It then fails with messages similar to the following (repeated for multiple runtime..System. packages):

error NU1101: Unable to find package runtime.win.System.Diagnostics.Debug. No packages exist with this id in source(s)

The package in question exists directly on the feed being used (and is even already in the local cache due to the earlier restore call when using 8.0.401).

If I delete the content of the lock file and re-run, restore succeeds and re-creates the exact same content. Attempting to rebuild again after that fails for restore again in the same way.

The specific MSBuild version being used is 17.12.0-preview-24422-09+d17ec720d.

Verbose Logs

No response

[jeffkl]

@breidikl can you please try with this command-line argument:

/p:RestoreUseLegacyDependencyResolver=true

This will help us narrow down the issue.

[breidikl]

If I append that to my existing command, restore succeeds.

[jeffkl]

@breidikl is there any way you could provide a simple project and package references that reproduces this issue? I'd like to investigate further.