Authenticated Proget via Noninteractive command line

I'm attempting to use proget as an authenticated nuget source using basic authentication and it seems to work fine when running from visual studio but doing it from command line (for my ci, by having the same problem locally) I am having trouble.

I've tried a couple combinations but end up with the same result, here's my latest attempt with setting the authentication details locally

nuget setapikey KEY -source URL
nuget sources update -Name SOURCENAME -source SOURCEURL -User USER -pass PASSWORD -StorePasswordInClearText

nuget restore -noninteractive
Installing 'PACKAGE'.
Please provide credentials for: ****
UserName: Cannot prompt for input in non-interactive mode.

It works fine if I enter the credentials at this point, but how do I do this without user interaction?

Couple Notes

Confirmed WWW-Authenticate headers are being sent back by proget via http intercept
nuget sources update is correctly applying changes to my \AppData\Roaming\NuGet\NuGet.Config
Attempted with versions 3.3.1, 3.3.0, and 2.8.6 of nuget.exe
Using IIS with ProGet, have not tried the integrated version though this seems to be client side to me.
Testing on both a Windows 2012 server as well as my local Windows 10 machine.

Product: ProGet
Version: 3.8.6

I think this is a bug/issue with NuGet.exe, in that it's not using the credentials in the NuGet.Config profile. Try passing in the user/pass via the APi key instead, that should be a work-around.

I do not see a way to pass an apikey through nuget restore. I tried editing my source too but nuget does not like that either.

Examples:
Still asks for auth, fiddler shows these are stripped by nuget before being passed on to proget: http://user:pass@host/

Not an option: nuget restore solution.sln -apikey key
https://docs.nuget.org/consume/command-line-reference#restore-command-options

Is there anywhere else the credentials can be passed?

There might be some strange work around, but we're not familiar with it. If you discover, please do share!

Unfortunately this has been broken for some time in NuGet.exe; we've heard that v2.6 is the best bet for build servers, as it's the least buggy.

For interactiving with NuGet feeds in BuildMaster, we just use our own client exe to bypass these problems. You can try the same proget client tools, which despite being deprecated and out of date, seem to work fine.

Thanks for the feedback Alana! I was afraid that might be the case. I might give the proget client tools a try sometime soon to see if that works, if I do ill report back here. I saw them but had not attempted yet.

I found a creative solution that works for me for now. I am currently running ProGet on the same system that runs my build runner so I updated the nuget source path to use the local cache, "C:\ProgramData\ProGet\Packages.nugetv2\F2"

That lets me keep authentication enabled so developers can access the files interactively and my maven/other repos stay authenticated too, but when building noninteractively it does not have to authenticate since it's just pulling from the local directory. This could probably be extended to multiple build systems using a shared cache directory.

Just for the record... we have to officially advise against this approach, since it's an internally-managed directly subject to change at anytime. It probably won't, but it may.

Moreover, the nuget.exe client will open each and every file in the directory... locking them (and may not properly releasing them until the process terminates), so, that may cause a error when ProGet tries to scan the directory for a consistency check.

The official solution would be to use the SDK to write an alternate package store that manages the storage directory and maybe copies it to a directory that is only used for this build server.

But... if you report the bug to the NuGet team (GitHub issue tracker), they are now actually pretty responsive in dealing with such problems.

Thanks Alana, that's very useful to be aware of, I'll follow up with the nuget team as well.