Can't use dotnet add package with a private repository (basic authentication)
#5163
Comments
|
Really long winded workaround:
|
|
@a-h The feed - Please make sure that the config file has the right credentials. In the mean time I will try with a V2 feed as well. |
|
I was able to add package from the V2 feed as well - |
|
OK, here's a script which reproduces the same problem inside a Linux container: I created a file called Then I executed the file inside a container: I got exactly the same results on Linux as I did on my Mac. Not sure what the state of your Windows machine is. Maybe the problem is only on Linux and OSX. |
|
@a-h - Thanks for the script. I will see if I can run stuff on a mac and get a repro. One thought I had was -just try If the command is picking up the right config file then it should resolve the feed. That might give us more information. |
|
@a-h : I did some more digging and found an older issue: #2887 The problem is that dotnet does not support encrypted passwords on non-windows platform yet. So if you do - This is going to put your password into the config file in clear text, so its not the best solution but should unblock you. Let me if that works. |
|
I updated the script to add the I then tried So I'm inclined to think that there's an underlying problem. |
|
@a-h : The problem is that mono and dotnet resolve user and machine wide config files differently. When you add source using mono, it goes to the user wide config file that mono uses but dotnet does not know about. Tested workaround on linux - What this does is that it adds the source to the local |
|
Thanks for the workaround! :) I'll just let my team know that until the
Has the NuGet team thought of updating the |
|
duplicate of #4413. Closing. |
|
Just for anyone experiencing the same problem, there's of course, no way to upgrade / update packages either. To do this, delete them from the cache, then add it again: |
|
What a massive waste of time this was. It's actually really simple to get I wrote a Python file to do it based on environment variables I pass into the build server: from xml.sax.saxutils import quoteattr
import os
f = open('NuGet.config', 'w')
f.write('<?xml version="1.0" encoding="utf-8"?>\n')
f.write('<configuration>\n')
f.write(' <packageSources>\n')
f.write(' <add key="xxx" value="https://ci.appveyor.com/nuget/xxx" />\n')
f.write(' </packageSources>\n')
f.write(' <packageSourceCredentials>\n')
f.write(' <xxx>\n')
f.write(' <add key="Username" value=' + quoteattr(os.environ['APPVEYOR_NUGET_USERNAME']) + ' />\n')
f.write(' <add key="ClearTextPassword" value=' + quoteattr(os.environ['APPVEYOR_NUGET_PASSWORD']) + ' />\n')
f.write(' </xxx>\n')
f.write(' </packageSourceCredentials>\n')
f.write('</configuration>\n')
f.close() |
rrelyea
added
Resolution:Duplicate
|
doesnt work when using global Nuget.config dotnet v: 3.1.300 |
|
same here, please reopen (@mishra14 ). .NET Core SDK : Runtime Environment: dotnet add package output: my NuGet.Config (also tried with encrypted password): |
|
I'm not sure you can call this "closed" if the solution involves having credentials in a file in a repository... I've installed the Azure DevOps Artifacts Credentials Provider and that's not working, either. Bit of a shame to only consider nuget.org and ignoring auth issues. |
|
I solved this by using Visual Studio for Mac to add the source. Solution/Project -> Manage Nuget repositories -> Add source. |
|
@mishra14 Can you state categorically that the suggested solution (and reason for closing the case) is that we should all have |
|
@nbarnwell NuGet accumulates settings from multiple locations, so the credentials can be saved in the user-profile nuget.config, so there's no risk of accidentally committing credentials (encrypted or otherwise) into the repo nuget.config. However, if you're using Azure DevOps, then we absolutely recommend using the credential provider, and no credentials in nuget.config files will be needed. If it's not working for you, that's a separate issue than this one. |
|
We all know that plaintext credentials in text files (whether they might get accidentally committed to source control or not) are undesirable. It's a feature that shouldn't exist. My point is that |
|
There's an issue about supporting encrypted passwords on Linux and Mac: #1851. We prioritize work based on a number of factors, but the number of upvotes (👍 reactions to the original comment) is a one consideration.
If it's not working for you there's some kind of issue going on, but I disagree it's on-topic for this issue. I'm not aware of any cred provider for app veyor, and the discussion earlier in the thread was specifically about saving the credentials in a nuget.config, since Again, I expect |
Details about Problem
Steps to reproduce
4 Attempt to add the private NuGet package to a dotnet project using the CLI:
Expected
For the command to add the NuGet package to the project.
Actual
Got a message saying that it couldn't authenticate.
The text was updated successfully, but these errors were encountered: