"dotnet restore --locked-mode" does not respect global.json

[vedion]

NuGet Product Used

dotnet.exe

Product Version

.NET Core SDK v8.0.202

Worked before?

I do not think so

Impact

It bothers me. A fix would be nice

Repro Steps & Context

Hi,

I have a project using:
<Project Sdk="Microsoft.NET.Sdk.BlazorWebAssembly">
and
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>

I get an auto-referenced package added to the "packages.lock.json" file:

{
  "version": 2,
  "dependencies": {
    "net8.0": {
      ...
      "Microsoft.NET.ILLink.Tasks": {
        "type": "Direct",
        "requested": "[8.0.2, )",
        "resolved": "8.0.2",
        "contentHash": "hKTrehpfVzOhAz0mreaTAZgbz0DrMEbWq4n3hAo8Ks6WdxdqQhNPvzOqn9VygKuWf1bmxPdraqzTaXriO/sn0A=="
      },      
      ...

I do not have a direct reference to "Microsoft.NET.ILLink.Tasks". It is also marked with "(A)" when doing a "dotnet list .\Client.csproj package":

Project 'Client' has the following package references
   [net8.0]: 
   Top-level Package                                     Requested        Resolved      
   > Microsoft.AspNetCore.Components.WebAssembly         8.0.2            8.0.2
   > Microsoft.AspNetCore.SignalR.Client                 8.0.2            8.0.2
   > Microsoft.Extensions.Http                           8.0.0            8.0.0
   > Microsoft.Extensions.Logging.Configuration          8.0.0            8.0.0
   > Microsoft.NET.ILLink.Tasks                    (A)   [8.0.2, )        8.0.2
   > Microsoft.NET.Sdk.WebAssembly.Pack            (A)   [8.0.2, )        8.0.2

I have a global.json file that looks like this:

{
  "sdk": {
    "version": "8.0.200",
    "rollForward": "disable"
  }
}

When running "dotnet restore --force-evaluate" it respects the SDK version in global.json and updates the packages.lock.json file to use v8.0.2 of Microsoft.NET.ILLink.Tasks:

"Microsoft.NET.ILLink.Tasks": {
  "type": "Direct",
  "requested": "[8.0.2, )",
  "resolved": "8.0.2",
  "contentHash": "hKTrehpfVzOhAz0mreaTAZgbz0DrMEbWq4n3hAo8Ks6WdxdqQhNPvzOqn9VygKuWf1bmxPdraqzTaXriO/sn0A=="
},

The Microsoft-hosted agents have v8.0.202 installed and when running "dotnet restore --locked-mode" it does not respect global.json and fails:
"error NU1004: The package reference Microsoft.NET.Sdk.WebAssembly.Pack version has changed from [8.0.3, ) to [8.0.2, ).The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Disable the RestoreLockedMode MSBuild property or pass an explicit --force-evaluate option to run restore to update the lock file."

- task: PowerShell@2
  displayName: 'Restore NuGet packages'
  inputs:
    targetType: 'inline'
    script: |
      dotnet restore --locked-mode --configfile "$(Build.SourcesDirectory)/NuGet.config"

Best Regards,
Anders Havn

Expected Behavior

"dotnet restore --locked-mode" also respects the .NET SDK version in global.json.

Verbose Logs

No response

[jeffkl]

NuGet itself does not enforce the .NET SDK used by dotnet specified in global.json. Please open an issue at https://github.com/dotnet/sdk/issues/new as I am unable to transfer this issue to repos outside of the NuGet organization.

[baronfel]

@jeffkl I think a related but relevant question here would be 'how should lock files and users of them think about packages that are implicitly provided by the SDK'? I know for CPM implicit packages are ignored, but I'm not sure that would make as much sense for lock file users.

[vedion]

I have already tried to create this issue in "https://github.com/dotnet/sdk/issues/":
dotnet/sdk#39697 (comment)

But here it was also closed and asked me to create it here :/

[zivkan]

@baronfel I don't fully agree that lock files don't make sense for implicit packages. I'm don't fully disagree either. Lock files have (at least) two purposes, and there's room for different opinions about how much different things matter. There isn't one objective "this is obviously the correct way".

One use of lock files is to pin versions. It's completely understandable that some people would want implicit packages to be absent from the lock file.

However, If the implicit package has dependencies, should the dependencies be listed in the lock file? If a package is a transitive dependency of both an implicit package, and a project's explicit PackageReference, but then updating to a newer .NET SDK causes the transitive package to choose a higher version, should --locked-mode fail restore? After all the point of --locked-mode is to error when different packages are restored than were locked.

If an implicit package doesn't have any dependencies, the product team can switch to PackageDownload, rather than PackageReference. This avoids all the CPM & lock file issues. But PackageDownload, by design, does not download package dependencies which may or may not be a problem.

The second use of lock files is to validate content hashes, to increase supply chain security. In this case, omitting implicit packages is a risk because it loses the protection. I mean, the same is true for PackageDownload, but it is what it is.

Honestly, I'm also wondering why this specific package Microsoft.NET.ILLink.Tasks, is a package, and isn't just inserted into the SDK directly.