dotnet tool install -g --add-source exception when private nuget packageSource (myget) exists

[copernicus365]

It's possible to install a .NET global CLI type tool as explained in this tutorial. While installation can be done via a public nuget package, one can also use the --add-source property to install directly from a .nupkg file (as the above tutorial demos). The problem is I had exceptions that in the end I discovered were due to having an extra private nuget packageSource registered on my system, which caused the installation to fail. Simply removing the extra source temporarily fixed the problem, but then adding it back, any subsequent attempts to install a global tool require the same workaround.

Example: If I have a .nupkg named microsoft.botsay (to use the above tutorial example, thus full file name being: microsoft.botsay.1.0.0.nupkg) located within C:\Tools\Botsay, the following should work:

dotnet tool install -g --add-source C:\Tools\Botsay microsoft.botsay

But I get this exception:

C:\Program Files\dotnet\sdk\5.0.103\NuGet.targets(131,5): error : Unable to load the service index for source https://www.myget.org/F/<some-company>/api/v3/index.json. [C:\Users<user>\AppData\Local\Temp\aqoqbaoa.yc5\restore.csproj]
C:\Program Files\dotnet\sdk\5.0.103\NuGet.targets(131,5): error : Response status code does not indicate success: 401 (Unauthorized).
The tool package could not be restored.
Tool 'microsoft.botsay' failed to install. This failure may have been caused by:

• You are attempting to install a preview release and did not use the --version option to specify the version.
• A package by this name was found, but it was not a .NET tool.
• The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
• You mistyped the name of the tool.

For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool

As you can see there is a 401 Unauthorized exception when trying to read that myget feed, which clearly the only reason the system knows about it is because it's registered on one's system as a nuget package sourced.

One can navigate to their package manager settings via %appdata%/nuget where a NuGet.Config file exists, which is also what gets set by one's Visual Studio->Options->NuGet Package Manager->Package Sources form. In my case I had in addition to the normal nuget package source, a private myget source, listed last, by the same url as listed in the exception. One needs credentials to view that url in a browser etc. SIMPLY COMMENTING OUT that packageSource allows the above install command to succeed. One moment later and you can re-add the myget source, BUT: This would be a really bad experience if you need to have a team, etc, follow this workaround just to install this, as many other devs might easily have a private packageSource feed in their system as well.

My guess is that this tool reads all nuget sources listed as <packageSources> (reading the public nuget one first obviously) to see if there are any conflicts with the tool being installed. But then when it hits a private feed, which it is not authorized to open, the process fails and there is an exception, which terminates the install, even though otherwise that myget package source works fine in VStudio and on my system. It should just ignore that private (in this case myget) index.json file when it can't be read. That would fix this problem.

Cheers

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[sfoslund]

@wli3 it sounds like this might be expected behavior, do you know if it's an issue with dotnet tools specifically or all nuget.config handling?

[copernicus365]

do you know if it's an issue with dotnet tools specifically or all nuget.config handling?

That's a good question. It is a pain point and confusing how one gets a private nuget package source working with credentials. But that said, for the record, Visual Studio has been pulling from that source just fine for some time now for me.

it sounds like this might be expected behavior

Hmm, I hope not 😬

[wli3]

use --ignore-failed-sources option will ignore failed feeds

[copernicus365]

@wli3 interesting! While I personally think this should be the default behavior, I’m glad to know there is this option, will try to test it soon

[kyletraynor-neo]

This is still an issue - and using --ignore-failed-sources doesn't seem to work for me.

[heku]

I have the same issue, and --ignore-failed-sources option doesn't work, I have to comment out the sources in nuget.config too.
.NET SDK 8.0.300