Sdk: dotnet tool install fails with multiple feeds

[wli3]

_From @ppumkin on September 26, 2018 10:20_

Issue Title

When I try to install a global tool, for example coverlet I get an error.

If I try any other tool I get the same error

General

The error message is as follows

dotnet tool install --global coverlet.console
C:\Program Files\dotnet\sdk\2.1.300\NuGet.targets(114,5): error : Unable to load the service index for source https://private_feed.pkgs.visualstudio.com/_packaging/private_feed/nuget/v3/index.json. [C:\Users\piotr.kula\AppData\Local\Temp\e4hqjeii.vid\restore.csproj]
C:\Program Files\dotnet\sdk\2.1.300\NuGet.targets(114,5): error :   Response status code does not indicate success: 401 (Unauthorized). [C:\Users\piotr.kula\AppData\Local\Temp\e4hqjeii.vid\restore.csproj]
The tool package could not be restored.
Tool 'coverlet.console' 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 Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.

The problem is that we use private NuGet feeds from Azure DevOps packages and symbol server.

So two things are happening here.

1. When access to a source feed fails the entire tool bombs out.
2. Expected to use NEXT source, which would have been NuGet.
3. Authorisation is not working from the command line
4. Expected authorisation window to show or use credentials Visual Studio has already created

Workaround

1. In visual studio, Disable the private feed and run the dotnet tool install.
2. Installs as expected.
3. Enable private feed after completed

_Copied from original issue: dotnet/core#1962_

[wli3]

_From @karelz on October 3, 2018 17:24_

@KathleenDollard @richlander this looks like a bug in our global tools story. Where do we track those?

[wli3]

_From @karelz on October 13, 2018 16:57_

@KathleenDollard @richlander ping?

[wli3]

_From @KathleenDollard on October 25, 2018 23:52_

@wli3 @livarcocc

[livarcocc]

This does not seem like a global tool issue. This is a restore issue and should likely be moved there. Again, following our principal that we are leveraging restore to acquire packages, if restore stops when one feed fails, than that's the behavior for regular packages and global tools packages.

For what is worth, NuGet does this because without checking all feeds, there is no guaranteed way to know that we are fetching the best package possible, as we haven't inspected all the feeds.

I am going to close this issue. If you feel strongly, please file a new issue on NuGet/Home about restore failing when one feed is inaccessible, even if there were other feeds available that could service the request. That's the main question here.

[wli3]

2.2.1xx added option --ignore-failed-sources can be used in this case. This can make workaround easier. https://github.com/dotnet/cli/pull/9830

reg the root cause auth issue. Could you restore a normal project in command line without special _nuget.config_?

Could you try to use --configfile and pass the path in the nuget.config with auth config?

[adamcroissant]

@wli3 Is there any plan to port this fix back to 2.1 since that is the current LTS version?

[wli3]

@adamcroissant sorry there is no plan to back port the fix. However, the next LTS, .net core 3.1 is planned to be released in December 2019

[sparker2000]

@wli3 is there any workaround for this? Changing the order of my sources doesn't seem to help.

[wli3]

@sparker2000 maybe you could use --configfile to pass a different config file to use