Until recently, one of the problems with sharing code across .NET, Silverlight, Windows Phone, and Windows Store is the inability to make HTTP requests. Each framework supports one or more HTTP clients, but they are incompatible each other at an API level.
To work around this developers can create their own platform specific adapters and use dependency injection to add them to the portable libraries that need them. And essentially, that’s what the new Portable HttpClient does for you.
Of course, each version of HttpClientHandler has a different set of capabilities. So in order to expose as much functionality as possible, extension methods have been introduced such as SupportsUseProxy and SupportsAllowAutoRedirect.
In case you are wondering why we added extension methods instead of regular properties: Some of the platforms that Microsoft.Net.Http supports already provide the HttpClientHandler class, which is used on those platforms. Since we can’t modify the built-in version of the properties directly, we added extension methods that ship in a separate assembly with the NuGet package.
Small, out-of-band releases like the Portable HttpClient are becoming more popular with Microsoft for a couple of reasons,
First, it allows bridging differences in functionality between platforms we already shipped. A good example is HttpClient, and also includes the support for the async and await keywords. Shipping features out of band also enables us to ship new functionality for multiple platforms via a single portable class library, without having to wait for any of the platforms to add that functionality.
Second, our goal is to strengthen the feedback loop with you, our customers. In the past, we’ve shipped “big” betas, like a beta of the entire .NET Framework. This approach certainly has some advantages, but we’ve seen issues with it as well. The biggest downside is that “big” betas are pretty expensive to ship and are typically very close to RTM, which, in turn, means that we can’t make impactful changes anymore. In fact, we have to turn down a large number of the bug reports we get in “big” betas, either because they affect a relatively small number of customers or because fixing the bugs would place the RTM release at risk. We’re certainly not the first company running into this problem; there is an entire agile software development movement in our industry that focuses on this. I don’t want to go into a philosophical discussion about agile methodologies, but it’s pretty hard to disagree that shipping early and often helps with feedback loop issues.
Some features that developers wanted didn’t make it into this release candidate. The most important of these is support for automatic decompression. Rather than delaying the release, they are going to simply offer a follow-up version once that feature is ready.
In order to support async/await on older platforms such as Silverlight, the Portable HttpClient is dependent on the BCL Portability Pack.
