Dotnet tool install fails with Azure DevOps artifact feeds

02 Mar 2024

Recently I tried to reinstall Dotnet Tools (DNT) on my local machine and encountered an unauthorized (401) error. Looking through the error message suggested that it was trying to connect to a private NuGet packages feed.

dotnet tool install -g dnt

It was strange to see Dotnet CLI was trying to use a private NuGet feed that I don't remember configuring anywhere in the system except for once from my Visual Studio 2022 - Options - NuGet Package manager - Packages Sources. So, Visual Studio would have added it to a global NuGet.config (%APPDATA%\NuGet\NuGet.Config) so that the source is available across multiple solutions/workspaces. This is the cause for this issue.

Option 1 - Quick fix

Removing it from the Visual Studio's package location dialog would be the simplest solution but it will force me to configure the private feed path in individual solution NuGet.config without which I can't browse through available private packages.

Option 2 - Didn't Work

So, I have started to look for alternate options that could avoid the above inconvenience. One of the suggestions in the NuGet threads was to use --ignore-failed-sources. It sounded good and I've tried as follows.

dotnet tool install -g --ignore-failed-sources dnt --no-cache --verbosity detailed --interactive

But still, the issue persisted without any change.

Option 3 - Good Workaround

There was a suggestion to provide an alternate NuGet.config file in the dotned CLI parameter, so that we can override and limit the sources that dotnet iterates during installation. So, I prepared a simple NuGet.config which just contained the NuGet org feed URL and saved it to a location in my system.

Content of dummy-nuget.config

<?xml version="1.0" encoding="utf-8"?>
    <clear />
    <add key="" value="" />

And in the dotnet tool installation command, I have specified it as follows

dotnet tool update -g dnt --configfile "C:\tmp\dummy-nuget.config"

Viola! The issue disappeared, and I was able to install the package as expected. This workaround solved the problem but needed me to remember to apply these steps for other tool installations too. So, I have started looking for a better way to solve this issue once and for all.

Option 4 - The Solution

I tried a couple of other options like doing Az Login to see if my PowerShell would remember my authenticated context and allow the dotnet tool install command to use that authenticated context, which didn't work as Dotnet CLI isn't a PowerShell Command let.

So, I continued to fish through a few more threads in the dotnet tool - GitHub project and came across a solution that would authenticate when Azure DevOps private feed links are encountered. The recommendation was to use 🔗Azure Artifact Credential provider that could authenticate and use the Bearer token automatically and access the target private feeds.

I have followed the steps by manually copying the Nuget plugins for netcore and netfx to the %UserProfile%/.nuget/plugins path.

NuGet plugins path

Then I tried the same installation without any additional flags, and it worked perfectly!

dotnet tool update -g dnt

Cheers! 🥂