Why do some NuGet packages provide both a Portable Library and an Platform Specific One?

Question

It is my understanding that Portable Class Libraries can be used on many platforms, based upon the subset of the framework the designer of the library choose to support.

I noticed that many libraries available via NuGet also include a platform specific implementation and wonder what is the need for this.

For instance, the Microsoft.Net.Http package comes with many variations, including :

• Net 4.0 version
• WinRT (Windows Store Apps) Windows 8 Version
• Portable Class Library supporting Net 4.0, WinRT and others

Why is there a need to distribute separate .Net 4.0 or WinRT versions of the Library ? Isn't the Portable Class Library sufficient ?

When I'm designing my own custom Portable Libraries, should I adhere to this convention ?

To be clear, I'm not talking about Portable Class Libraries that need a small portion of platform specific code to work. Those usually have an accompanying managed Library whose name ends with .PlatformServices. But I'm talking about the core library distributed by the NuGet package.

Answer 1

Sure, the PCL version might well be sufficient for your needs. However, as you are bound to find out when you create your own PCL class library project, the sub-set of .NET Framework classes and methods that you can actually use in a PCL project is a rather small one. That sub-set is created by taking the full .NET Framework and subtracting out the parts that cannot work on another platform.

The most restrictive platforms are Silverlight and Phone7, they are based on the .NETCore version of the CLR. And Store and Phone8, based on the services available through the WinRT api. Targeting any of these quickly dwindles down the number of things you can do in your library.

The Microsoft.Net.Http package was optimized to still make some of the Http relevant methods and properties available if you are not limited by one of those restricted platforms. You can have a look-see in the packages subdirectory, the System.Net.Http.Extensions.xml files that provide IntelliSense shows you what is possible on one platform but not another. I see:

• HttpWebRequest.AllowAutoRedirect
• AuthenticationManager.PreAuthenticate
• HttpWebRequest.ProtocolVersion
• HttpRequestHeaders.TransferEncodingChunked
• HttpClientHandler.UseProxy

Do note that these properties are mapped with extension methods.