NuGet historically didn’t handle company proxies, a common enough issue, which has led to a lot of guidance on the ‘net that is now out of date on how to deal with a proxy that isn’t playing nicely with your default credentials. Here are two tips: the first will let you get chocolatey installed and the second will let you configure NuGet so that chocolatey can do its goodness.
The above gist will let you install chocolatey from a PowerShell command line. I used the normal download URL like this:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted;$a=new-object net.webclient;$a.proxy.credentials=[system.net.credentialcache]::defaultnetworkcredentials;$a.downloadstring('https://chocolatey.org/install.ps1')|iex
From the linked configuration settings above I added:
.\nuget config -Set http_proxy=company-proxy:8080 .\nuget config -Set http_proxy.user=mylogin .\nuget config -Set http_proxy.password=secret
Note that the password is encrypted in your NuGet.config so you can’t edit it directly.
Now I can use chocolatey without seeing:
Please provide proxy credentials:
UserName: Cannot prompt for input in non-interactive mode.
I believe that PowerShell and NuGet are trying to present the default web credentials rather than the default network credentials and in our case the proxy we lurk behind isn’t satisfied with that, thus the need to be explicit. It’s possible that NuGet was failing to present any credentials; I could investigate with Fiddler but these fixes have solved it for me. YMMV.