A first hand look from the .NET engineering teams
As promised in our last blog post we’re releasing Microsoft.Net.Http as a stable NuGet package today. Yep, that’s right: You can finally start using the portable HttpClient 2.1 in production!
As we’ve discussed in previous blog posts, HttpClient is a modern networking API which makes it easy to access any resource exposed through HTTP. The HttpClient API has been available in some versions of .NET for a while now. This NuGet package makes a standard set of HttpClient APIs available across a wider array of platforms, including Windows Phone 7.5 and higher, .NET Framework 4.0 and higher, and Windows Store. This enables you to share more .NET code across these platforms.
This package also addresses one of the top User Voice requests for .NET: providing an HttpClient implementation for Portable Class Libraries (and therefore also on Windows Phone 8).
We closed this request when we posted the preview of the new HttpClient back in February. Now, with the release of a stable version, we’re excited that you now have a high-quality implementation to use and build on in your .NET projects.
This package requires Visual Studio 2010 or Visual Studio 2012, and NuGet package manager 2.5 or higher.
We haven’t changed much since last week's release candidate (RC), but this is by-design. For our NuGet packages, feature work is first released in beta builds only. Once we think we matured a feature enough (based on internal testing as well as customer feedback), we release an RC. If there aren’t any major bugs, we turn (generally the same) bits into an RTM, which NuGet calls a stable release. This process helps ensure that we ship high-quality components.
We did make some very minor changes to our package metadata:
As I explained in my last blog post, the current release doesn’t include support for automatic decompression. One of our readers commented that each time a web request is issued without gzip support, it hurts baby seals.
We know automatic compression is an important feature for you, and we care deeply about the health of baby seals, so we are working on a portable compression library that provides this feature. Our plan is to ship a beta release of HttpClient 2.2 that includes this library very soon. As a reminder, here is our tentative release schedule:
Until we release a stable version of automatic decompression that you can use in production, there are some alternatives you may want to consider. (Please note this isn’t intended to be a complete list. If you’ve developed a similar feature, let us know by posting a comment below.)
Morten Nielsen, a Microsoft Valued Professional (MVP), has provided an implementation of HttpClientHandler that has support for gzip compression. You can find the source code here:
Robert McLaws created a derived project and packaged it up as a NuGet package. You can install his NuGet package either via the package manager console:
Install-Package HttpClient.Compression –Pre
or by searching for HttpClient.Compression in the NuGet Package Manager dialog. At the time of this writing, HttpClient.Compression wasn’t available as a stable NuGet package, because the stable version of our HttpClient wasn’t released yet. I’m sure it will get updated very soon, though.
HttpClient 2.1 is now available as a stable release on NuGet. The license allows its use in production and unblocks third parties from building stable NuGet components on top of it.
You can expect a beta release of HttpClient 2.2 with support for automatic decompression very soon. Meanwhile, help protect baby seals by using one of community libraries we linked to above. If there are other community libraries available, please let us know in the comments section!
So this now breaks every MVC4 project that uses NuGet package restore... great work.
@SimonH.23 Nuget has issues with packages that include targets files. Just check-in the .targets from the dependent Microsoft.Bcl.Build.
I would like to use it, but I also need a portable JSON (de)serialization. There is a native implementation in WinRT and WP with .NET 4 use JSON.NET.
@Václav Dajbych: The WinRT JSON APIs are more useful for C++. JSON.NET does have support for Portable Class Libraries (net40+sl4+wp7+win8 as well as net45+wp80+win8). Thus, I'd suggest using JSON.NET on all platforms.
I'm getting this error after I try to build on my WP8 Project:
Microsoft.Bcl.Compression does not support the currently selected platform of 'AnyCPU'. The supported platforms are 'x86' and 'ARM'.
Any idea why I'm seeing this?
Nive work guys!
Any chance we can get a feature to ignore invalid SSL certificates as this cannot currently be done on Windows Phone?
@Ryan: Yes. You were installing the pre-release version of HttpClient that added a dependency on the Microsoft.Bcl.Compression pacakges which requires native code. The latest pre-release version fixed that issue, more details here:
If you would prefer the RTM version of HttpClient make sure to select "Stable Only" in the NuGet Package Manager Dialog.
@Damian: We don’t implement the SSL layer, that is in WinINet. You could install the certificate on the phone (that is what fiddler does, for example). To install a cert all you needs to do is get the .cer file on the phone and open it (either in email or IE).
Here is an MSDN article on SSL: msdn.microsoft.com/.../ff402533(v=vs.105).aspx
I have a strange error on a incremental deployment of my app on my test phone. The message says the following, "Native images generated against multiple versions of assembly System.Net.Http.Primitives"
I do not get this error,
1) on the emulator, whether it is an incremental or fresh deployment
2) on the phone when I do a clean and rebuild. Of course, that uninstalls and reinstalls the app which erases any all app data
This only happens on an incremental deployment to the phone.