直到最近，关于在.NET、Silverlight、Windows Phone和Windows Store之间分享代码的问题之一，依旧是缺少发起HTTP请求的能力。每个框架支持一个或多个HTTP客户端，但在API层面它们互不兼容。

要解决该问题，开发者可以创建自己的平台相关适配器，并使用依赖注入把它们添加到有需要的可移植库中。而基本上，这也正是新的可移植HttpClient所做的事情。

当然，每个版本的HttpClientHandler都有不同的功能集。所以，为了尽可能地将更多的功能暴露出来，可移植HTTP客户端引入了诸如SupportsUseProxy和SupportsAllowAutoRedirect这样的扩展方法。

Immo Landwerth解释道：

倘若开发者想要知道为何我们添加扩展方法而不是常规属性的话：某些Microsoft.Net.Http支持的平台已经提供并正在使用HttpClientHandler类。由于不能直接修改属性的内建版本，我们添加了扩展方法并通过NuGet包以独立程序集的方式发布。

基于以下原因，微软正在变得越来越青睐类似于可移植HttpClient这样的小型、带外发布：

首先，它搭建了一座桥梁以跨越我们已经发布的平台之间的差异。HttpClient是一个很好的例子，同样的还有对async和await关键字的支持。带外发布特性允许我们通过单一可移植类库针对多平台发布新功能，而无需等待其中任何一个平台添加该功能。

其次，我们的目标是增强与客户之间的反馈回路。过去，我们发布“大型”beta版本，例如整个.NET框架的beta版本。这一方法当然有其优势，但我们也发现了它的问题。其中最大的缺点是“大型”beta版发布代价高昂，而且它一般与RTM非常接近，这也就意味着我们不能再进行重大变更。实际上，我们必须拒绝大量在“大型”beta版本中获得的bug报告，因为它们仅影响了相对小众的客户，或是因为修订这些bug会把RTM版本置于风险之中。我们当然不是第一家遇到这个问题的公司；在这个产业里，整个敏捷软件开发运动都在聚焦于此。虽然我不想开启关于敏捷方法论的哲学讨论，但是很难否认尽早并经常发布对反馈回路的问题是有帮助的。

某些开发者期望的特性未能纳入这次候选发布，其中最重要的是对自动解压缩的支持。为了不推迟本次发布，该特性将在完成后出现在后续版本中。

为了在诸如Silverlight等老平台上支持async/await，可移植HttpClient依赖BCL可移植性包。