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

Possible Workaround

See #9555 (comment) in this issue discussing --ignore-failed-sources.

[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 NuGet/Home#6486

[wli3]

closing per above comment

[DerAlbertCom]

i think that NuGet/Home#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.

[sabrite]

This is still broken with .NET Core 6.0.200 and Nuget 6.0.0.280.

.NET CLI keeps referencing private feeds first when trying to install/update a tool. Can we please re-open this?

With --ignore-failed-sources, yes it works but it makes it so ugly to look at the console, full of warnings about private feeds.

[kjbartel]

I'm getting sick of getting people commenting that this is still an issue and the devs continuing to ignore it. I opened another issue to see if that gets more traction. #24140

[RwSgxx]

@KathleenDollard @wli3 This was reported in 2018. Now it is 2022(with .NET 6) and it sill gives an error if there are private feeds! Isn't there any capable developer at MS that can fix this? Do we have to wait for Musk to first do a Mars landing and then maybe you take this bug seriously?

[kjbartel]

@zuckerthoben this fix is in 3.0.100 preview and later

@RwSgxx the problem is that it was closed as "fixed" when it most definitely wasn't.

[ckpearson]

This is STILL an issue.

We're using an Azure DevOps private feed and it consistently gets in the way of using nuget, even within Visual Studio where the feed is configured sometimes!

Currently the only workaround that consistently works is to just disable the feed in visual studio, run the CLI command and then re-enable the feed in Visual Studio.

[benrobot]

This is not fixed

The command dotnet tool install JetBrains.ReSharper.GlobalTools is still getting errors like

C:\Program Files\dotnet\sdk\6.0.202\NuGet.targets(130,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/redacted/_packaging/REDACTED_Feed/nuget/v3/index.json. [C:\Users\Redacted\AppData\Local\Temp\txsvixqy.awu\restore.csproj]
C:\Program Files\dotnet\sdk\6.0.202\NuGet.targets(130,5): error :   Response status code does not indicate success: 401 (Unauthorized). [C:\Users\Redacted\AppData\Local\Temp\txsvixqy.awu\restore.csproj]
The tool package could not be restored.
Tool 'jetbrains.resharper.globaltools' 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

I keep having to add --ignore-failed-sources to the command: dotnet tool install --ignore-failed-sources JetBrains.ReSharper.GlobalTools

[javierdlg]

SOLUTION
Use a custom nuget config file that forces it to use NuGet.org as it's source for installation. I solved it by modifying my install command into:
dotnet tool install --tool-path . nbgv --configfile "azure-pipelines\justnugetorg.nuget.config"

And that config file only has NuGet.org as a source:

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

[sabrite]

C:\Program Files\dotnet\sdk\6.0.202\NuGet.targets

Thanks @javierdlg - but will this config file not be overwritten when .NET SDK is upgraded/reinstalled or when Visual Studio is upgraded/reinstalled? And please confirm that you are asking to replace the nuget targets file here "C:\Program Files\dotnet\sdk\6.0.202\NuGet.targets". Also, how will this play when discovering custom feeds from within Visual Studio?

Thanks,

[javierdlg]

@sabrite It's a file you create that lives outside of the .NET SDK, so it wont get replaced when you update .NET.
Basically what I'm saying is to use a custom nuget config file so that it pulls it from the nuget feed instead of your private feeds defined in the solution's global nuget config file. This one is separate from your solution and .NET SDK nuget config files

[klinsc]

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

This works for me when I installed 'csharpier' 🎉

[celluj34]

SOLUTION Use a custom nuget config file that forces it to use NuGet.org as it's source for installation. I solved it by modifying my install command into: dotnet tool install --tool-path . nbgv --configfile "azure-pipelines\justnugetorg.nuget.config"

And that config file only has NuGet.org as a source:

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

This is not a solution, it's a workaround at best. I shouldn't have to tiptoe around dotnet / nuget's atrocious handling of private feeds when other public feeds should work. neither again should installation fail because I am already authenticated with my private feed.

[FinalFortune]

Should at least have a -s parameter like with dotnet add package. There's already a myriad of tools a dev has to work with, I find it valuable to have consistency in the CLI so one doesn't have to keep searching for simple things.

[jt-pt-dev]

Still an issue in .NET 7

The presence of a private feed blocks the install of a tool if auth fails. Adding --ignore-failed-sources is a workaround still.

dotnet tool install --global dotnet-depends fails

dotnet tool install --global dotnet-depends --ignore-failed-sources works

[adamhill]

Its 2023 and this is still an issue in dotnet

--ignore-failed-sources did not work for me

[ardonjr]

I'm on .NET 7.0, SDK Version 7.0.203 and I just stumbled upon this issue. I can't follow a Microsoft Learn exercises as I have private feeds and the CLI command fails on the above issue when executing 'dotnet add package'.
I find it strange that there isn't a command to change 'default nuget feeds' within command prompt. Or at least make dotnet smart enough to check for other sources like the default nuget api if the private source fails.

[2mik]

July 2023: Faced the same problem. Installed EF Core Tools by command
dotnet tool install --global dotnet-ef --ignore-failed-sources

[IanOfOz]

I now have the opposite error when using the .NET 8 SDK. I'm trying to install a tool from a private repository.

I have setup a nuget.config just for the dotnet tool install command, and specified it via the --configfile argument.

There is only one feed in the repository - my private one. The nuget.config is correctly setup to clear any sources, and I've added packageSourceMapping into the bargain. But still dotnet tool install reports a failure as it is trying to access nuget.org - even though there is no mention of nuget.org in any config file.

It almost looks to me that the fix to the problem reported here is to got to nuget.org regardless.

If I run this with .NET 7 SDK or earlier it works. .NET 8 on the other hand and it is broken.

Actually I've now found that the most recent .NET 8 SDK build has the fix, looks like it was done here: #33835

Unfortunately my TeamCity build agents don't have this yet.

[snathanail]

.NET SDK 8.0.100 here. --ignore-failed-sources doesn't work for me.

I found another workaround:

dotnet nuget disable source <your_private_repo_name>
dotnet tool install --global <what you want to install>
dotnet nuget enable source <your_private_repo_name>

Waiting until this gets fixed, but at least it's more of a minor inconvenience now rather than a blocker.

ETA: dotnet nuget list source to get the name of your repo.

[kdrapel]

What is Microsoft doing? I just came upon that problem right now and discover this has been reported for ages as always !

[AcePalsgaard]

end of march 2024 - still not fixed.
I used workaround from benjaminbj - #9555 (comment)

[kdrapel]

end of march 2024 - still not fixed. I used workaround from benjaminbj - #9555 (comment)

I think the best is to make a patch by ourselves and make a PR (that will take forever to be included).... It looks like they just don't care.

[Ehabrizek]

Just ran into this as well.

Used the work arounds provided.

Would like to see this fixed. I shouldn't have to google around for a solution because I have a private NuGet server and want a tool installed.

[ChristoWolf]

Bumping to maybe get this issue re-opened.

[nkolev92]

Hey folks,

I'd file new issues if you're seeing problems.
The root cause of what you might be seeing is unrelated to what the issue was originally filled for.

For anyone using AzDO feeds, make sure https://github.com/microsoft/artifacts-credprovider is installed before filing an issue.

[jrummell-elite]

This is not fixed. We should not need to use a credential provider for public tool packages on nuget.org just because we also use a private feed for other packages.

The issue is that --ignore-failed-sources does nothing for tool installs.

[hollowback]

My workaround was about to run dotnet install from different directory than default $(Build.SourcesDirectory) where the repository is checkouted with nuget.config containing private feed leading to Devops Artifacts feed.

• task: PowerShell@2
  displayName: 'Install AzureSignTool'
  inputs:
  targetType: inline
  script: |
  cd $(Build.ArtifactStagingDirectory) #<- this is it
  $env:DOTNET_SKIP_FIRST_TIME_EXPERIENCE = "true"
  Write-Host "Installing AzureSignTool..."
  dotnet tool install --global AzureSignTool

[HassanJbara]

.NET SDK 8.0.100 here. --ignore-failed-sources doesn't work for me.

I found another workaround:

dotnet nuget disable source <your_private_repo_name>
dotnet tool install --global <what you want to install>
dotnet nuget enable source <your_private_repo_name>

Waiting until this gets fixed, but at least it's more of a minor inconvenience now rather than a blocker.

ETA: dotnet nuget list source to get the name of your repo.

I knew something like this should work but I kept googling cause I thought having to do this was too moronic, especially after all the complaints for years. Using Microsoft's devtools is equivalent to questioning your sanity everyday.