Sdk: dotnet tool install have trouble installing when an private feed is in nuget.config

[leecow]

@DerAlbertCom commented on Fri Jun 29 2018

Issue Title

dotnet tool install -g foobar does not install any tool if private nuget feed is in the nuget.config which requires authentication.

General

I tried 'dotnet tool install -g sourcelink', and have in the the global nuget.config the company nuget feed from vsts.

C:\Program Files\dotnet\sdk\2.1.301\NuGet.targets(114,5): error : Fehler beim Abrufen von Informationen zu "sourcelink" aus der Remotequelle "https://XYZ.pkgs.visualstudio.com/_packaging/172bc92f-50b3-48bc-b4cf-9555b7f0fd10/nuget/v3/flat2/fo/index.json". [C:\Users\DerAl\AppData\Local\Temp\ctdjxp0q.bbs\restore.csproj]
C:\Program Files\dotnet\sdk\2.1.301\NuGet.targets(114,5): error :   Response status code does not indicate success: 401 (Unauthorized). [C:\Users\DerAl\AppData\Local\Temp\ctdjxp0q.bbs\restore.csproj]

If i comment out the private feed out in then nuget.config, then the tool get's installed.

nuget restore has not problem with the nuget feed. dotnet restore (which should not be used with VSTS because you have to store a Cleartext PAT in the nuget.config) clearly has the same problem like dotnet tool

[leecow]

@KathleenDollard

[KathleenDollard]

@wli3 can you take a look at this.

@DerAlbertCom Can you confirm my understanding...

Is the global tool in an authenticated feed?
Or is the global tool on a non-authenticated feed and the presence of the authenticated feed blocks installation?

Will,

• The second would seem to be a bug, can you test that scenario?
• Can you tell me if the first should work?

[wli3]

global tools with the current implementation run dotnet restore underneath exactly. Could you show me the output of dotnet restore as well? And make sure dotnet restore uses that nuget.config .

[KathleenDollard]

@nkolev92 is this a slightly different manifestation of the problem we were discussing yesterday?

[nkolev92]

@KathleenDollard
Yes, this is that problem exactly.

@DerAlbertCom
We are adding support for a cross platform credential plugins for in 2.1.400.

@wli3, I think this can be duped out to https://github.com/NuGet/Home/issues/6486

[wli3]

closing per above comment

[DerAlbertCom]

i think that https://github.com/NuGet/Home/issues/6486 should solve the issue in general.

But

@KathleenDollard the global tool is on nuget.org. So the presense of the auth feed blocks the installation, so a fix for that before 2.1.400 would be nice. e.g. ignoriring the auth feed (with a warning instead of an stopping error). So that the tool will be installed.

[KathleenDollard]

@DerAlbertCom

We tied to NuGet early on, so I don't see a solution without their fix. We pass through to them, and are deliberately transparent about passing their errors through to you.

I suspect the problem is made worse by our treating feeds as additive. Thus, you can't remove a feed just by specifying another feed.

I'd like clarification on why you can't specify an alternate NuGet.config:

dotnet tool install greatTool --configfile <tool NuGet config>

I agree it is a pain, but it seems a decent workaround until we get the problem solved in 2.1.400

We added this because we thought most folks would not want two NuGet configs, but that on occasion, you really, really would, and we anticipated fine tuning your feeds in a nuget config file would be easier than on the command line.

Comments on all that thinking would be welcome.

[thoemmi]

This issue is still present in the current .NET Core 3.0 Preview2 SDK (3.0.100.10184). When I try to install the dotnet-format tool, an authenticated private feed in %appdata%\NuGet\nuget.config causes this issue:

> dotnet tool install -g dotnet-format --version 3.1.0-beta1-19080-04 --add-source https://dotnet.myget.org/F/roslyn/api/v3/index.json
C:\Program Files\dotnet\sdk\3.0.100-preview-010184\NuGet.targets(114,5): error : Failed to retrieve information about 'dotnet-format' from remote source '[private feed redacted]'. [C:\Users\Thomas\AppData\Local\Temp\loo5v2r3.idl\restore.csproj]
C:\Program Files\dotnet\sdk\3.0.100-preview-010184\NuGet.targets(114,5): error :   Response status code does not indicate success: 401 (Unauthorized). [C:\Users\Thomas\AppData\Local\Temp\loo5v2r3.idl\restore.csproj]

[zuckerthoben]

This issue is not fixed as I can't install any global tool with SDK 2.2.104 and a private feed in the nuget.config.
workaround: Remove the private feed from the config, install the tool you want and re-add the private feed.

[wli3]

@zuckerthoben this fix is in 3.0.100 preview and later

[nkolev92]

Note that if you have the credentials in the config file, then it should already work.

[DerAlbertCom]

Really? A Workaround? Why not just fix this. dotnet cli with authenticated feeds is a mess.

• not all commands accessing nuget feeds support --interactive
• --interactive does not work in newer sdks, because the logging of the needed oauth2 device flow information is swallowed.
• not all dotnet task in AzureDevOps supports selecting a Azure Artifact source

I'm really tired of this problems around the authenticated nuget feeds. For this reason we can not use Hosted Build Agents in Azure DevOps. We have to use a own Build Agent with CLEARTEXT Credentials in the config file.

We cannot use dotnet cli correctly from the command line on the dev machine without put the cleartext credentials in the dev machines.

Yes, for all this problems are issues filed, mostly with no information when it will be fixed, or zero reaction.

[zuckerthoben]

@zuckerthoben this fix is in 3.0.100 preview and later

ok, thanks. If you tag closed issues with the version that its fixed in people can understand better.

[KathleenDollard]

@wli3 : You said this was in 3.0.100 preview. Can you look at @thoemmi 's issue that he sees in 3.0.100 Preview 2.

[wli3]

@KathleenDollard I think there is a feed with name "[private feed redacted]" (and it is not dotnet-format's myget feed) that cannot be accessed. And it causes the whole operation fail. dotnet-format's myget does not need authentication.

[KathleenDollard]

@wli3 I missed that. Thanks

[BenjaminAbt]

My workaround because I also run in this issue on Azure DevOps (current VS2017 and VS2019 and Ubuntu with NuGet 4.9.4 and 5.0.0):

Create a single NuGet.config with only the nuget.org feed (you can also name it like NuGet-OfficialOnly.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

Now I am able to install via dotnet tool

Run

dotnet tool install --global GitVersion.Tool --version 5.0.0-beta2-65 --configfile NuGet-OfficialOnly.config

[joergmaier]

Does not seem to be fixed in 3.0.100.
We work with Azure DevOps Server 2019 U1 and Artifactory 6.10.
The error occurs at the .NET Core build and test tasks.

`
[command]C:\Windows\system32\chcp.com 65001
Active code page: 65001
[command]D:\agent3_work_tool\dncs\3.0.100\x64\dotnet.exe test D:\agent3_work\183\s\Source\xxx.Test\xxx.Test.csproj --logger trx --results-directory D:\agent3_work_temp --configuration release
D:\agent3_work_tool\dncs\3.0.100\x64\sdk\3.0.100\NuGet.targets(123,5): error : Failed to retrieve information about 'Microsoft.Extensions.Configuration.Json' from remote source 'https://artifactory.xxx/artifactory/api/nuget/xxxx/FindPackagesById()?id='Microsoft.Extensions.Configuration.Json'&semVerLevel=2.0.0'. [D:\agent3_work\183\s\Source\xxxx\xxxxTest.csproj]
D:\agent3_work_tool\dncs\3.0.100\x64\sdk\3.0.100\NuGet.targets(123,5): error : The input is not a valid Base-64 string as it contains a non-base 64 character, more than two padding characters, or an illegal character among the padding characters. [D:\agent3_work\183\s\Source\xxx\xxx.Test.csproj]

[error]Error: The process 'D:\agent3_work_tool\dncs\3.0.100\x64\dotnet.exe' failed with exit code 1

[warning]No test result files were found.

[error]Dotnet command failed with non-zero exit code on the following projects : D:\agent3_work\183\s\Source\xxx.Test\xxx.Test.csproj

[section]Finishing: Run xUnit Tests`

[KathleenDollard]

@wli3 @nkolev92

[winstonhenke]

+1 for wanting this fixed and being irritated working with dotnet cli and authenticated feeds

[wli3]

@joergmaier seems like there is invalid characters in your nuget config.

@winstonhenke and @joergmaier if you just want to skip these unauthorized feed, you could use --ignore-failed-sources.

If further discussion is needed, please create a new issue.

[winstonhenke]

@wli3 I tried --ignore-failed-sources with no luck

[wli3]

@winstonhenke could you create a new issue with the error and repro specific to you? There are several errors in this thread, and I don't think they have the same root cause.

[f2calv]

There is a new credential provider tool which I believe helps address this issue, Azure Artifacts Credential Provider.

I created a .NET Core 3.1 global tool which I then published to an Azure DevOps private artifact feed, but was initially unable to install elsewhere due to authentication issues. However after using the new credential tool it worked as expected...

My solution, in an elevated PowerShell terminal copy/paste/execute the below to install the Credentials Provider;

$url = "https://raw.githubusercontent.com/microsoft/artifacts-credprovider/master/helpers/installcredprovider.ps1"
$output = "installcredprovider.ps1"
Invoke-WebRequest -Uri $url -OutFile $output
./installcredprovider.ps1

Note: when the above script completes/stops, ensure you hit [enter] as the first time I thought the script had hung and did ctrl+c which obviously didn't complete the authentication process.

Next you can install your .NET Global Tool using the --add-source option as you would expect. Note the --interactive option which effectively means that you first auth with your azure devops account/feed via a browser+code.

$ToolName = "mytool"
$Organisation = "myorganisation"
$Project = "myproject"
$FeedName = "myfeedname"

dotnet tool install -g $ToolName --add-source 
https://pkgs.dev.azure.com/$Organisation/$Project/_packaging/$FeedName/nuget/v3/index.json --interactive

Note the above example is for a project-scoped artifact feed, you can remove the $Project variable if it's an organisation-scoped feed.

Hope this helps!

[joergmaier]

I thought the credential provider fixed my problem, but the publish action had the same error again. The "test" action seems to be working.
@wli3 I checked the project files and there were no invalid characters

[GF-Huang]

Does this bug fixed? I found that still exist .net core sdk 3.1.200 x64.

[ddtechboy]

@joergmaier seems like there is invalid characters in your nuget config.

@winstonhenke and @joergmaier if you just want to skip these unauthorized feed, you could use --ignore-failed-sources.

If further discussion is needed, please create a new issue.

I had a private nuget feed as well. --ignore-failed-sources worked for me
Thanks!

[Thieum]

Still really unintuitive in 3.1. The error message should hint to the necessary option.

[curtisault]

I think this is still a problem. I'm getting unauthorized to a private nuget feed when trying to install dotnet-ef:

PS C:\WINDOWS\system32> dotnet tool install --global dotnet-ef
C:\Program Files\dotnet\sdk\3.1.402\NuGet.targets(128,5): error : Unable to load the service index for source https://hcbb.pkgs.visualstudio.com/_packaging/my_private_feed_here/nuget/v3/index.json. [C:\Users\cault\AppData\Local\Temp\saauu5tq.352\restore.csproj]
C:\Program Files\dotnet\sdk\3.1.402\NuGet.targets(128,5): error :   Response status code does not indicate success: 401 (Unauthorized). [C:\Users\cault\AppData\Local\Temp\saauu5tq.352\restore.csproj]
The tool package could not be restored.
Tool 'dotnet-ef' 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.

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

The version of the dotnet SDK is in the error description.

[curtisault]

So I found a workaround about 5 minutes after posting and I think it may have to do with the order in which nuget feeds are accessed.

dotnet tool install --global dotnet-ef --ignore-failed-sources worked. This worked because, I assume, the cli attempted to access the private feed first, failed to access, then stopped trying other feeds. That's just a hunch. I am not a cli expert here.

Here's the full command + response:

PS C:\WINDOWS\system32> dotnet tool install --global dotnet-ef --ignore-failed-sources
C:\Program Files\dotnet\sdk\3.1.402\NuGet.targets(128,5): warning NU1801: Unable to load the service index for source https://hcbb.pkgs.visualstudio.com/_packaging/my_private_feed_here/nuget/v3/index.json. [C:\Users\cault\AppData\Local\Temp\xuaoxi11.gs1\restore.csproj]
You can invoke the tool using the following command: dotnet-ef
Tool 'dotnet-ef' (version '3.1.8') was successfully installed.

[jayoungers]

For those of you saying --ignore-failed-sources isn't working, you may only be referencing your private feed.

You can add the public one through the same command:

dotnet tool update --global [tool] --add-source 'https://api.nuget.org/v3/index.json' --ignore-failed-sources

[andreujuanc]

dotnet tool update --global [tool] --add-source 'https://api.nuget.org/v3/index.json' --ignore-failed-sources

This works, thanks @jayoungers
But I have to say that this is one of the worst developer experience ever.