sdk: dotnet restore --interactive: 401 Unauthorized on Windows with Azure DevOps feed

Turns out I had the cred provider plugin already installed on macOS, which is why --interactive was working.

For anyone interested reading this, Nikolche let me know that Microsoft decided not to put the plugin in dotnet.exe because there were concerns that shipping auth integration to Azure DevOps within the sdk would’ve been unfair to other feed providers. To resolve your 401 issues you need to install the auth plugin manually that Nikolche mentioned:

Grab the plugin from https://github.com/Microsoft/artifacts-credprovider/releases Install into ~/.nuget/plugins/netcore

Full instructions: https://github.com/Microsoft/artifacts-credprovider

I wish this was more clear in some way; maybe dotnet could give a warning that --interactive will not work without some credential manager instead of doing nothing?

@dylank

Is your provide feed azure devops?

If it is, then you need to install the credential provider from https://github.com/Microsoft/artifacts-credprovider.

One command solved:

# Run as Admin
iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1'))

And then try to restore again.

Ah, I found this. https://github.com/Microsoft/artifacts-credprovider#azure-devops-pipelines

This is really annoying and was very hard to find a solution to. This should be much clearer in the dotnet restore error message.

Selecting “Connect to feed” in ADO and picking the “dotnet” option, it specifically says:

Restore packages (using the interactive flag, which allows dotnet to prompt you for credentials) dotnet restore --interactive

However, since the decision was to not allow dotnet restore --interactive to prompt for credentials, it’d be helpful if Azure Devops Artifacts (and preferably dotnet.exe too) was a little more clear on the fact that the only way to use --interactive with ADO is to install this credential provider plugin. I know there’s a link to it under the “Get the tools” link, but that only said something like “First time using dotnet on this machine?”, and maybe I’m a bit slow but to me that just sounds like it’s about installing dotnet core.

I think it would save some frustration if the Azure Devops Artifacts “Connect to feed” page for dotnet could instead say something like

Restore packages (using the interactive flag, which allows the credential provider plugin to prompt you for credentials if installed)

I’ve been fighting with this for a while. I installed the credential provider using the ps1 script, but am unclear on whether or not it is actually being picked up. dotnet restore --interactive just gives me a 401. however, if i manually run CredentialProvider.Microsoft.exe -I -V Verbose -U "https://pkgs.dev.azure.com/zzzzzzzzzzzzzz/zz/nuget/v3/index.json then it comes back saying found credentials with username VssSessionToken and what looks like a PAT.

anyway a giant +1 from me on dotnet --interactive being clearer about the potential fix.

1st update

after running the dotnet restore --interactive with -v detailed I was able to confirm that the plugin is being picked up. The debug spam seemed to indicate that it found credentials, somewhere, but I couldn’t determine WHERE. According to the docs https://github.com/microsoft/artifacts-credprovider#session-token-cache-locations the path Windows: $env:UserProfile\AppData\Local\MicrosoftCredentialProvider should be where the token is cached. i dont have this folder at all.

2nd update (solved)

I finally got it! The problem was there was a hardcoded value set for VSS_NUGET_EXTERNAL_FEED_ENDPOINTS with a JSON blob containing something like {"endpointCredentials": [{"endpoint":"https://pkgs.dev.azure.com/***/**/**/nuget/v3/index.json","password":"***(some PAT)***"}]} . I deleted the env var completely and ran dotnet restore --interactive and it popped up the UI to sign in. I now have the MicrosoftCredentialProvider folder in AppData\Local and well… thank goodness thats over!!

Turns out I had the cred provider plugin already installed on macOS, which is why --interactive was working.

For anyone interested reading this, Nikolche let me know that Microsoft decided not to put the plugin in dotnet.exe because there were concerns that shipping auth integration to Azure DevOps within the sdk would’ve been unfair to other feed providers. To resolve your 401 issues you need to install the auth plugin manually that Nikolche mentioned:

Grab the plugin from https://github.com/Microsoft/artifacts-credprovider/releases Install into ~/.nuget/plugins/netcore

Full instructions: https://github.com/Microsoft/artifacts-credprovider

Came across this for the first time today and these instructions were an absolute life saver (coming back from mac to windows): I really do think there needs to be some form of indicator on the --interactive flag to let you know that no credential provider is installed.

As a workaround, running nuget restore in the dotnet core project will take a PAT token, and allow you connect to a private feed.