list package doesn't with a solution argument in 9.0.201

[thorhj]

NuGet Product Used

dotnet.exe

Product Version

9.0.201

Worked before?

9.0.104

Impact

It's more difficult to complete my work

Repro Steps & Context

When using dotnet list <SOLUTION> package command, the result doesn't contain any projects unless the CWD is the directory containing the solution.

Let me describe this with the following folder structure:

C:\root\
├─ MyProject\
│  ├─ MyProject.sln
│  ├─ MyProject\
│  │  ├─ MyProject.csproj

Using dotnet list package --format json from C:\root\MyProject yields the expected result:

{
  "version": 1,
  "parameters": "",
  "projects": [
    {
      "path": "MyProject/MyProject.csproj",
      "frameworks": [
        {
          "framework": "net9.0"
        }
      ]
    }
  ]
}

But from C:\root, passing in the path to the solution files in various ways (with or without the solution file; relative and absolute paths) makes it return results where projects is an empty array:

> cd C:\root
> dotnet version
9.0.201
> dotnet restore MyProject
Restore complete (0.3s)

Build succeeded in 0.4s
> dotnet list .\MyProject package --format json
{
  "version": 1,
  "parameters": "",
  "projects": []
}
> dotnet list .\MyProject\MyProject.sln package --format json
{
  "version": 1,
  "parameters": "",
  "projects": []
}
> dotnet list C:\root\MyProject\MyProject.sln package --format json
{
  "version": 1,
  "parameters": "",
  "projects": []
}
> dotnet list C:\root\MyProject\ package --format json
{
  "version": 1,
  "parameters": "",
  "projects": []
}

If I change directory to C:\root\MyProject it works as expected:

> cd C:\root\MyProject
> dotnet list . package --format json
{
  "version": 1,
  "parameters": "",
  "projects": [
    {
      "path": "MyProject/MyProject.csproj",
      "frameworks": [
        {
          "framework": "net9.0"
        }
      ]
    }
  ]
}
> dotnet list .\MyProject.sln package --format json
{
  "version": 1,
  "parameters": "",
  "projects": [
    {
      "path": "MyProject/MyProject.csproj",
      "frameworks": [
        {
          "framework": "net9.0"
        }
      ]
    }
  ]
}
> dotnet list C:\root\MyProject package --format json
{
  "version": 1,
  "parameters": "",
  "projects": [
    {
      "path": "MyProject/MyProject.csproj",
      "frameworks": [
        {
          "framework": "net9.0"
        }
      ]
    }
  ]
}

It also works if I target MyProject.csproj instead of the solution file:

> cd C:\root
> dotnet list .\MyProject\MyProject\MyProject.csproj package --format json
{
  "version": 1,
  "parameters": "",
  "projects": [
    {
      "path": "C:/root/MyProject/MyProject/MyProject.csproj",
      "frameworks": [
        {
          "framework": "net9.0"
        }
      ]
    }
  ]
}
> dotnet list C:\root\MyProject\MyProject\MyProject.csproj package --format json
{
  "version": 1,
  "parameters": "",
  "projects": [
    {
      "path": "C:/root/MyProject/MyProject/MyProject.csproj",
      "frameworks": [
        {
          "framework": "net9.0"
        }
      ]
    }
  ]
}

And it also works if I change to version 9.0.104:

> cd C:\root
> '{ "sdk": { "version": "9.0.104" } }' >> global.json
> dotnet --version
9.0.104
> dotnet list .\MyProject package --format json
{
  "version": 1,
  "parameters": "",
  "projects": [
    {
      "path": "C:/root/MyProject/MyProject/MyProject.csproj",
      "frameworks": [
        {
          "framework": "net9.0"
        }
      ]
    }
  ]
}

Verbose logging (dotnet list package --verbosity d) doesn't yield any logs in the failing scenarios, so it seems like the command simply fails to detect the projects it needs to analyze.

Workaround: Instead of supplying the solution file path you can change to the directory where the solution file is located and invoke the command without a solution path.

Verbose Logs

[remoba]

We're also experiencing this in our automation flows. Worked as expected with 9.0.200 but stopped working in 9.0.201. It treats all projects as always up to date

[jeffkl]

This is a duplicate of #12954 which will be fixed in 9.0.3xx

[thorhj]

Thanks @jeffkl 🚀

[UniQP]

@jeffkl This is not a duplicate of #12954, which was fixed in 8.0.3xx. The fix (dotnet/sdk#38306) is contained in all .NET 9 SDKs (git tag --contains 755782c). This is a new issue, which was introduced in 9.0.201 (according to the comments above).