dotnet list <SOLUTION> package --vulnerable/--outdated/--deprecated fails with Azure Artifacts Credential Provider

[josundt]

NuGet Product Used

dotnet.exe

Product Version

dotnet 8.0.200 (NuGet 6.9.1.3)

Worked before?

Don't know

Impact

I'm unable to use this version

Repro Steps & Context

Given a repository with the following .NET solution:

┌─src
├─┬─MyProject1
│ └───MyProject1.csproj
├─┬─MyProject2
│ └───MyProject2.csproj
├─┬─MyProject3
│ └───MyProject3.csproj
├───MySolution.sln
├───nuget.config

All the 3 projects have NuGet PackageReferences from two different NuGet feeds:

• The public NuGet feed (https://api.nuget.org/v3/index.json)
• Our Azure DevOps Artifacts feed (https://pkgs.dev.azure.com/[myorg]/_packaging/[myfeed]/nuget/v3/index.json

Both of these feeds are listed in the nuget.config file.

I have installed the Azure Artifacts Credential Provider on the current device (tested on both Windows and Linux).

I have successfully authenticated and acquired a token for the Azure DevOps feed by using the --interactive option with some dotnet command; f.ex. by having run dotnet restore --interactive once from the src folder.

~/repos/myrepo/src> dotnet restore --interactive --no-cache
  Determining projects to restore...
      [CredentialProvider]DeviceFlow: https://pkgs.dev.azure.com/[myorg]/_packaging/[myfeed]/nuget/v3/index.json
      [CredentialProvider]ATTENTION: User interaction required.

      **********************************************************************

      To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code ****** to authenticate.

      **********************************************************************

  Restored /home/me/repos/myrepo/MyProject1/MyProject1.csproj (in 36,52 sec).
  Restored /home/me/repos/myrepo/MyProject2/MyProject2.csproj (in 36,6 sec).
  Restored /home/me/repos/myrepo/MyProject3/MyProject3.csproj (in 36,64 sec).

Having performed the above step, I can now successfully run dotnet restore without the --interactive option each time, since the acquired token is persisted on the device and can be reused until the token expiry:

~/repos/myrepo/src> dotnet restore
  Determining projects to restore...
  All projects are up-to-date for restore.

When changing cwd to one of the project directories, f.ex. src/MyProject1, I can now successfully run the dotnet list package --vulnerable command successfully; authentication to the Azure DevOps feed works fine:

~/repos/myrepo/src/MyProject1> dotnet list package --vulnerable

The following sources were used:
   https://api.nuget.org/v3/index.json
   https://pkgs.dev.azure.com/[myorg]/_packaging/[myfeed]/nuget/v3/index.json

The given project `MyProject1` has no vulnerable packages given the current sources.

But if I try to do the same from the solution folder (src):

~/repos/myrepo/src> dotnet list package --vulnerable

warn : The plugin credential provider could not acquire credentials. Authentication may require manual action. Consider re-running the command with --interactive for `dotnet`, /p:NuGetInteractive="true" for MSBuild or removing the -NonInteractive switch for `NuGet`
error: Response status code does not indicate success: 401 (Unauthorized).


Usage: NuGet.CommandLine.XPlat.dll package list [arguments] [options]

Arguments:
  <PROJECT | SOLUTION>  A path to a project, solution file or directory.
  ...

It looks like the solution file in the current folder is read but authentication to the Azure DevOps feed fails - even if my persisted token should still be valid.
(FYI: If I explicitly pass the SOLUTION file path as argument the same thing happens).

Please also see bug #13307 related to unexpected behavior with the <SOLUTION | PROJECT> argument.

Please figure out why authentication fails when using solution files but works when only using project files.

Verbose Logs

No response

[martinrrm]

This is probably related to dotnet/sdk#38306, we fixed a regression related to the relative paths, most likely we are not handling the exception correctly. This fix is in 8.0.3x, can you try it? Thanks!

[pkamphuis]

Is this fix in DotNet sdk 8.0.203? (runtime 8.0.3)

I am still experiencing this issue. Both on a solution or a project. As soon as I include --include-transitive it start repetitive authentication device flows. It seems be done for each referenced project in de project. I end up with dozens of created PAT tokens in my Azure Devops account. So it appears to create a token for each individual project.

[pkamphuis]

What information is needed to investigate this issue?

From what I can see, does the credential provider what is expected. Triggering a device flow login. I authenticate. A PAT token is created with the correct scope. However in the dotnet restore output it still indicate unable to load service index with a 401. After which it goes in the next device flow to retry

[josundt]

@pkamphuis @martinrrm
This is still not fixed (.NET 8.0.4/SDK 8.0.204).

I am still not sure if this is an Azure DevOps Credential Provider problem, therefore I also have an open issue in their GitHub repo, and I have just now added some repro information to that issue.

Can you please read that information and investigate this further?
This case should not be closed before the problem is solved!

As far as I can tell you should by now have all the required information to reproduce this.

[josundt]

@pkamphuis @martinrrm
I tested again today; and the problem has disappeared.
I am not exactly sure what may have solved it, but I'm aware of the following changes on my machine:

• .NET SDK has been upgraded from 8.0.205 to 8.0.300.
• NuGet CLI (Microsoft.NuGet) was upgraded (using winget) from ? to 6.10.0.107

Not sure if the NuGet CLI is used in this process but thought I'd mention it.