Core: dotnet tool install fails with multiple feeds

[ppumkin]

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

[karelz]

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

[karelz]

@KathleenDollard @richlander ping?

[KathleenDollard]

@wli3 @livarcocc

[wli3]

This issue was moved to dotnet/cli#10241

[wli3]

I removed this issue to CLI. You can close this issue.

[GF-Huang]

This bug still exists even 2020.04.03.

[Riebe]

I can assert that this bug still exists as of today, 09-Jun-2020

[wli3]

could https://github.com/dotnet/sdk/issues/9886#issuecomment-433472367 solve the problem?

[andrevdwal]

It does, but still hits the other sources you know will fail. Would be nice to be able to specify a source key to use to force it to only look at that source and nothing else. Could be useful in other scenarios

dotnet tool install the-bestest-tool --source nuget.org

nuget.config

[Riebe]

As Andrev points it does. My thoughts were among those lines prior to stumble upon this Thread so it was nice to assert it would work before doing anything. Still I think this could be improved, what andrev posted would be my preferred solution since you have the --add-source command too.

[wli3]

@andrevdwal @Riebe could you create a new issue on https://github.com/dotnet/sdk for the feature request?

[mturczyn]

Is it resolved? I just run into that issue...

It can be resolved by specifying additional argument: --ignore-failed-sources

[jyeagle]

I also just ran into this!

[euadams]

Any progress on this?? This just happened to me as well.
Update
I was able to get around this issue by specifying the flag --ignore-failed-sources.