Reputation: 492
So for "security" reasons I am forced to use a different account to run visual studio for certain admin level operations (registering COM objects mostly). TFS however only knows about my lower level regular account. In the past this hasn't been an issue and I've set credentials up for my admin account to log into TFS with the regular account.
However something has changed since I last did a password change and logging into one particular nuget feed (hosted by TFS / Azure devops server in house) from VS2019 running as admin will lock my AD account. Also my git TFS account seems not to be using the correct account. A different feed hosted by the same TFS instance (the only difference is the feed name) works fine.
I have tried setting credentials for nuget using dotnet nuget update source name -u username -p password
and that hasn't helped. I suspect since git gives issues when I push to the TFS server it's using some sort of windows stored user name and password and nuget is using the same invalid credentials. I can login to TFS to search for work items in VS2019 to add on git commits so at least one provider is set correctly.
So my question is how do I find out what the actual username and credential type / provider is being used for a particular nuget feed? Ideally I'd like to find out what username it's using as well.
Upvotes: 1
Views: 1771
Reputation: 51153
Please first make sure the account you were logging in with does have permission to the nuget package.
how do I find out what the actual username and credential type / provider is being used for a particular nuget feed?
You should find CredentialProvider in my local folder:
C:\Users\[username]\AppData\Local\NuGet\CredentialProviders\
Use NuGet with Azure DevOps Services feeds
Also give a try with below solution, check if this do the trick:
Upvotes: 1
Reputation: 492
Okay in my case it turns out different versions of nuget are in use. The CredentialProviders folder was empty.
However I suspect an older version of nuget was involved that looks in this config file
C:\Users\<your_account>\AppData\Roaming\NuGet\NuGet.Config
which in my case had the same repository name twice with slightly different casing (no idea why?) and the password was incorrect on one of those entries (they should all be the same).
So running nuget.exe sources update
for the older mechanism as well as dotnet nuget update source
worked. I also notice that update source
requires a later version of the dotnet sdk than I happened to have specified in global.json
for this project.
So I suspect this is mostly down to having
I hope this helps someone else at some point.
I have marked Patrick Lu answer as correct as it actually answers my original question.
Upvotes: 1