dotnet list package cannot resolve relative path

[mbenedykconfigit]

NuGet Product Used

dotnet.exe

Product Version

dotnet: 8.0.0-rc.2.23479.6, NuGet Command Line 6.8.0.117

Worked before?

No response

Impact

It's more difficult to complete my work

Repro Steps & Context

Follow-up dotnet/sdk#36254

Describe the bug

dotnet list XXX.sln package fails to list packages

To Reproduce

I'm having directory with multiple sln files inside so I have to point direct sln for dotnet list package.

Exceptions (if any)

• PATH TO SLN DIRECOTRY> dotnet list XXX.sln package

error: Unexpected failure reading NuGet.Config. Path: 'PATH TO SLN DIRECOTRY\XXX.sln\NuGet.Config'.
error:   Cannot create 'PATH TO SLN DIRECOTRY\XXX.sln' because a file or directory with the same name already exists.

• PATH TO SLN DIRECOTRY> dotnet list XXX.sln package --config NuGet.Config

PATH TO SLN DIRECOTRY>dotnet list XXX.sln package --config NuGet.Config
error: MSB0001: Internal MSBuild Error: Quote.sln unexpectedly not a rooted path

• Only variant with full path works
  PATH TO SLN DIRECOTRY> dotnet list "PATH TO SLN DIRECOTRY\XXX.sln" package --config "PATH TO SLN DIRECOTRY\NuGet.Config"

Further technical details

.NET SDK:
 Version:   8.0.100-rc.2.23502.2
 Commit:    0abacfc2b6

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19044
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\8.0.100-rc.2.23502.2\

.NET workloads installed:
There are no installed workloads to display.

Host:
  Version:      8.0.0-rc.2.23479.6
  Architecture: x64
  Commit:       0b25e38ad3

.NET SDKs installed:
  6.0.317 [C:\Program Files\dotnet\sdk]
  7.0.401 [C:\Program Files\dotnet\sdk]
  8.0.100-rc.2.23502.2 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-rc.2.23480.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-rc.2.23479.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.0-rc.2.23479.10 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  PATH TO SLN DIRECOTRY\global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

global.json used for solution

{
  "sdk": {
    "version": "8.0.100-rc.2.23502.2",
    "rollForward": "latestMinor"
  }
}

Verbose Logs

No response

[samsmithnz]

Adding my voice here too - I am also running into this today.

[sailro]

Same thing here.

We have a tool using dotnet list <solution> package --vulnerable --include-transitive on all our repos.
Trying the new .net 8 GA completely broke our stuff because of this bug.

[grichards23]

Same thing here.

We have a tool using dotnet list <solution> package --vulnerable --include-transitive on all our repos. Trying the new .net 8 GA completely broke our stuff because of this bug.

Same exact thing for us - built into our CI/CD pipeline. We're pivoting at the moment but would be great if the original functionality was restored.

[vernou]

Same here...
As alternative, it's to execute the command in the folder solution without specify the solution :

 dotnet list package --vulnerable --include-transitive

[jeffkl]

I looked under the debugger and this line of code isn't checking if the path coming in is a file or folder and leads to the path getting mangled:

https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Configuration/Settings/Settings.cs#L679

[SarahKonnild]

There is a workaround that I've put into pipelines, where you can specify a path to the Nuget.Config file, using the --config option @grichards23 @sailro

[ChristoWolf]

Same thing here.

We have a tool using dotnet list <solution> package --vulnerable --include-transitive on all our repos. Trying the new .net 8 GA completely broke our stuff because of this bug.

Same here.

[junlinz2]

Same thing here.

We have a tool using dotnet list <solution> package --vulnerable --include-transitive on all our repos. Trying the new .net 8 GA completely broke our stuff because of this bug.

Same here, encountering this issue as well on .NET 8.0.100.

[vernou]

@mbenedykconfigit, @grichards23, @ChristoWolf, @junlinz2, can you upvote this issue?
Maybe it will help to prioritize this.

[icecoldfire]

We added $Env:BUILD_SOURCESDIRECTORY in our Azure DevOps script as a mitigation.

scan-nuget-vulnerabilities.ps1

($output = dotnet list $Env:BUILD_SOURCESDIRECTORY/src/xxx.sln package --vulnerable --include-transitive)

$errors = $output | Select-String '>'

if ($errors.Count -gt 0) {
    foreach ($err in $errors) {
        Write-Host "##vso[task.logissue type=error]Found vulnerable NuGet package $err"
    }

    exit 1
}

exit 0

[0liver]

I've used dotnet list $(Resolve-Path .\src\solution.sln) package --vulnerable --include-transitive successfully.

[sharpSteff]

in shell i use dotnet list $(readlink -f ./src/Solution.sln) package --vulnerable --include-transitive as workarround

[DomZZ]

Same here... As alternative, it's to execute the command in the folder solution without specify the solution :

 dotnet list package --vulnerable --include-transitive

Doesn't work if you have more than one solution file ...

[Nigusu-Allehu]

As mentioned in #13149 (comment), this is a regression. It was caused by dotnet/sdk#20449 which tried addressing "dotnet list package fails when current directory path contains # character". The solution to this problem involved eliminating the use of PathUtility.GetAbsolutePath, which was previously employed to obtain the absolute path from a given relative path. However, this approach was problematic because the NuGet API consistently requires an absolute path, leading to issues in resolving relative paths.

[mhubis]

This has broken us too. Are there plans for a fix?

[ChristoWolf]

@mhubis:
As you can see in the PR linked above your comment, a fix is already approved, only a few CI checks are pending.

[Nigusu-Allehu]

We have resolved the problem and integrated a solution that will be included in the upcoming 8.0.3xx release.