I’ve found the best way to avoid the problems with the Microsoft BCL Portability Pack, which I had in an ASP.NET MVC 4 project, was to get rid of it.
Remove all System.Net.Http and System.Net.Http.* references then use NuGet to remove the BCL Portability Pack. Use NuGet to install an earlier version of System.Net.Http that doesn’t rely on BCL:
Install-Package Microsoft.Net.Http -Version 2.0.20710.0
Then update the web.config:
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-126.96.36.199" newVersion="188.8.131.52"/>
Now any developer can open the solution *without* some silly M$ workaround.
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.
install chocolatey with windows auth proxy
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
NuGet configuration settings
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.