{"id":18435,"date":"2013-05-22T17:24:00","date_gmt":"2013-05-22T17:24:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/2013\/05\/22\/portable-httpclient-is-now-available-as-rc\/"},"modified":"2021-10-04T12:35:27","modified_gmt":"2021-10-04T19:35:27","slug":"portable-httpclient-is-now-available-as-rc-2-2","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/portable-httpclient-is-now-available-as-rc-2-2\/","title":{"rendered":"Portable HttpClient is now available as RC"},"content":{"rendered":"

Three months ago we shipped the first preview of the portable HttpClient<\/a>. Many of you wondered when we would ship the RTM version. Today, we’re happy to announce the first step towards an RTM: We shipped a release candidate (RC) of HttpClient (Microsoft.Net.Http package on NuGet<\/a>) that includes all the bug fixes since the preview.<\/p>\n

New features<\/h2>\n

To address some of the platform differences in a portable fashion, we’ve added new capability APIs.<\/p>\n

HttpClientHandler.SupportsUseProxy()<\/strong>: The existing HttpClientHandler.SupportsProxy<\/a> property indicates whether both the UseProxy<\/a> property and the Proxy<\/a> property are supported. This created an issue because some platforms (for example, Windows Phone) don’t allow you to configure a proxy explicitly. However, Windows Phone lets you control whether the machine wide proxy should be used. To model this behavior, we added the HttpClientHandler.SupportsUseProxy()<\/strong> extension method. For some platforms that don’t support both, such as Windows Phone, the SupportsProxy<\/strong> property will continue to return false, but the SupportsUseProxy()<\/strong> method will return true.<\/p>\n

HttpClientHandler.SupportsAllowAutoRedirect()<\/strong>: The HttpClientHandler.SupportsRedirectConfiguration<\/a> property had a similar issue: It controls whether both the AllowAutoRedirect<\/a> and the MaxAutomaticRedirections<\/a> properties are supported. Windows Phone doesn’t support specifying the maximum number of automatic redirections, but it does support redirection. For that reason, we added the HttpClientHandler.SupportsAllowAutoRedirect()<\/strong> extension method.<\/p>\n

Here’s how you use these capability APIs:<\/p>\n

HttpClientHandler handler = new HttpClientHandler();\n\n\/\/ Configure proxy (if supported)\nif (handler.SupportsUseProxy())\n    handler.UseProxy = true;\n\n\/\/ Allow automatic redirection (if supported)\nif (handler.SupportsAllowAutoRedirect())\n    handler.AllowAutoRedirect = true;<\/pre>\n
In case you are wondering why we added extension methods instead of regular properties: Some of the platforms that Microsoft.Net.Http<\/strong> supports already provide the HttpClientHandler<\/strong> 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.<\/p>\n
Bug fixes<\/h2>\n
All bug fixes are listed in the release notes<\/a>. In this post, I’d like to highlight just one:<\/p>\n
Issue: When consuming a portable class library that depends on HttpClient from a Windows Store application, the app can crash with a MissingMethodException.<\/em><\/p>\n
We’ve fixed this bug by using the technique we explained in our blog post about Microsoft.Bcl.Async<\/a>: We ensure during the build that the application has a reference to the NuGet package.<\/p>\n
Future directions<\/h2>\n
This RC doesn’t include support for the HttpClientHandler.AutomaticDecompression<\/a> property. Many of you have asked for this support, and we certainly haven’t ignored it or forgotten about it. In fact, our original plan was<\/a> to ship another preview with support for automatic decompression, and then ship an RTM version a few weeks later. So why did we change our minds about it?<\/p>\n
We had two options:<\/p>\n
    \n
  1. Block the release of HttpClient until automatic decompression is ready.<\/li>\n
  2. Ship an interim release of HttpClient that doesn’t have automatic decompression but is marked as a stable NuGet release and comes with a license that allows usage in production.<\/li>\n<\/ol>\n
    We decided to go with the second option, because we believe it delivers functionality sooner to our customers. After all, that’s why we ship on NuGet, and we hope you agree.<\/p>\n
    Let’s recap why our team is investing so much in releasing components via NuGet. The reason is twofold:<\/p>\n
    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<\/a>. 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.<\/p>\n
    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.<\/p>\n
    A good example where we use your feedback quite heavily is in the previews of immutable collections<\/a>; in contrast to “big” betas, we were able to change the design of the APIs when we believe that’s the correct approach.<\/p>\n
    Unfortunately, shipping a constant stream of previews isn’t necessarily a helpful solution in all scenarios. On certain platforms, such as the .NET Framework 4.5 and Windows Store, HttpClient is already available as a fully supported, RTM-quality component. For that reason, we can offer a preview of HttpClient only for Windows Phone today.<\/p>\n
    Here are our tentative plans for future NuGet releases of HttpClient:<\/p>\n