NuGet

Microsoft.Bcl generally considered harmful

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:

<dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
  <bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Now any developer can open the solution *without* some silly M$ workaround.

Advertisements

NuGet and chocolatey behind a proxy

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.