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 :
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.
In NuGet 4.8+ support for cross platform plugins has been added. This was achieved with by building a new plugin extensibility model, that has to conform to a strict set of rules of operation. The plugins are self-contained executables (runnables in the .
NuGet provides the tools developers need for creating, publishing, and consuming packages. Most importantly, NuGet maintains a reference list of packages used in a project and the ability to restore and update those packages from that list.
NuGet is the official package-manager for . NET. Packages are basically compiled library with some descriptive metadata. NuGet is an essential tool for any modern development platform is a mechanism through which developers can create, share, and consume useful code.
When you add features to your project via a nuget package, you're just adding files to your project. It can be javascript files (like jQuery), DLLs that your project references (like Newtonsoft JSON), or a whole bunch of things (like Entity Framework or Owin/SignalR) -- anything really.
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:
Do note that these properties are mapped with extension methods.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With