What does the portable class library actually solve?

Question

I was wondering, what does the PCL actually solve? If all it does is limit me to what types are cross-platform, then why didn't Microsoft just make this as a feature in a standard .NET library through the IDE?

Basically, I can easily compile a .NET library containing some POCO objects and reference that DLL in my Silverlight, WPF, and Windows Store app without needing to recompile or having any issues. Is there any hard examples of code that works in the PCL that would not work in a standard .NET library?

Oh, and I know that obviously there are some things that would work in the standard .NET library, I'm not concerned about that... I guess my question is this:

Is there any code that would compile in a Portable Class Library, that would not function correclty if that exact same code was in a .NET Library?

It allows you to support multiple versions of the .NET Framework without creating multiple versions of the project. Otherwise you would need a seperate prject to target the WPF and Windows Store. — Security Hound, May 02 '13 at 12:52
@Ramhound: I understand what the goals of it are, but I was hoping for a real example of code that would only function correctly in a PCL (compiled once) vs a standard .NET library (compiled once). Couldn't I just use a standard .NET library if I forced myself to only use classes and methods that were cross-platform? Read the question, I'm asking if the **same exact code** that works in a PCL would not function properly in a .NET library. — michael, May 02 '13 at 12:58
Your idea of using only classes that exist on multiple versions of .NET Framework is exactly what the portable class library does. .NET Code is .NET Code. — Security Hound, May 02 '13 at 13:01
@Ramhound: I'm not 100% sure that is correct... it might be... but IIRC PCL compiled assemblies are slightly different... for example, they have the Retargetable flag set to yes. I think there probably is a code situation that would work in PCL that wouldn't in a standard .NET library, I just can't think of one off the top of my head. — myermian, May 02 '13 at 13:06
@m-y - There isn't because you would clearly just target the platform the code is support by. — Security Hound, May 02 '13 at 13:11

score 22 · Accepted Answer · answered May 03 '13 at 00:05

22

Two things:

First, if your intention is to create a library that does work on multiple platforms, you don't want to find out at runtime that you accidentally used an API that wasn't available on all platforms (via a TypeLoadException or MissingMethodException or something). So Portable Class Libraries will only give you intellisense for APIs that are supported on all the platforms you're targeting, and you will get build errors for anything outside that set.

Second, if you create a .NET Framework library that only uses APIs that are available on all platforms, the DLL created still will not work on other platforms (ie Windows Phone and Silverlight) without compiling it as a library for those platforms. It sounds like you expect that it would, and that is a reasonable expectation but has not been true in the past. Portable Class Libraries are the way we are making that work (and in fact it is the case that if you create a class library for Windows Store apps and only use APIs available for the .NET Framework and WP8, the resulting binary would work on both of those platforms unchanged).

answered May 03 '13 at 00:05

Daniel Plaisted

16,674
4
44
56

2

My guess is that the OP was trying to see if there is more to the PCL than just limiting intellisense, which there is... :) – myermian May 03 '13 at 20:24
2

Well, these may be some goals of PCLs, but they're definitely not there yet. Both .Net Framework and Silverlight/WP7 have `Socket`, `IPEndPoint` etc classes. Yet, PCLs don't have them. Both .Net Framework + XNA, Silverlight5 and WP7 have `Vector3`, `Matrix` etc. classes, yet PCLs have none. In addition to a handful of incompatible frameworks we now have 30 more not-so-compatible profiles. And I'm still wondering what was so non-portable in my function which adds two integers that I must use PCLs to make it portable... – Ark-kun Jun 09 '13 at 05:39
@Ark-kun See http://blogs.msdn.com/b/dsplaisted/archive/2012/08/27/how-to-make-portable-class-libraries-work-for-you.aspx for some common reasons why APIs aren't portable. In general, Silverlight and WP7 weren't really designed with PCLs in mind. From .NET 4.5, .NET for Windows Store apps, and Windows Phone 8 on, you will find that almost all APIs that are available on more than one platform are portable across those platforms. – Daniel Plaisted Jun 10 '13 at 21:18
The link you've posted has no relevance to what I've wrote. I've provided concrete examples of PCL problems. ".NET for Windows Store apps, and Windows Phone 8". Your solution to the real or perceived non-portability is the creation of a completely new forcibly-incompatible system which intentionally breaks backwards compatibility. There is nothing portable about creating yet-another-API which is not available on Windows 7 or WP7. – Ark-kun Jun 12 '13 at 05:30
@DanielPlaisted These will be my last two questions: What's so non-portable in a Vector2 class which encapsulates a pair of floating-point coordinates? Does the BCL team find it acceptable that after more than a decade of .Net development there is no universally available and used structure that encapsulates a pair of floating-point coordinates? – Ark-kun Jun 12 '13 at 05:34
Ark-kun, there's nothing inherently non-portable about a class with a couple of floats; except the fact that the platforms can't agree about where System.Object lives. Silverlight shipped (for reasons decided before my time) with a different mscorlib identity than .NET Framework. Portable for older platforms *is* limited, because we tried to add portable support after the horse had already left the gate. With new versions of our platforms, portability is baked in, hence why it is better on .NET Framework 4.5, Windows Phone 8 and Store apps. – David Kean Sep 03 '13 at 20:08

score 5 · Answer 2 · answered May 02 '13 at 21:10

I wouldn't worry too much about the code itself, but just try the following and see why Portable Class Libraries are useful.

Create a standard .NET 4.5 Class Library (it can be empty/contain no classes).
Create a Silverlight 5 application.
Attempt to reference the .NET 4.5 Class Library from your Silverlight 5 application.

You'll get the following error message:

You can't add a reference to Demo.Utils.dll as it was not built against the Silverlight runtime. Silverlight projects will only work with Silverlight assemblies.

That, in itself, is just a taste as to why Portable Class Libraries are so wonderful. The tough part is trying to adapt code to be platform agnostic, which sounds easy, but isn't as easy as you think. Trust me, when you first try to read a file from a folder and realize that the PCL doesn't allow FileInfo you'll be frustrated, but the guidance from Microsoft is to abstract the platform dependencies away and inject a class that implements an interface that actually takes care of it. In fact, here is a nice article on that.

Another useful article to look over goes over a bit of the inner workings of the way PCLs are set up. This article will help you understand why PCLs are able to target multiple platforms. https://www.simple-talk.com/blogs/2013/04/19/inside-portable-class-libraries/

"That, in itself, is just a taste as to why Portable Class Libraries are so wonderful". I'd say that PCLs try to solve a problem which should never been there, but fail to do so. — Ark-kun, Jun 09 '13 at 05:42
"I'd say that PCLs try to solve a problem which should never been there" - How wouldn't the problem be there? Obviously it's impractical to have the exact same APIs on different platforms. Making the entirety of .NET APIs platform agnostic is a huge undertaking and it would almost be better to have .NET support only a single platform. That's the same reason why Apply only supports their own hardware, because they have control over every aspect and can let devs use the full power of the language and APIs. — Anshul, Jun 26 '14 at 15:04

score 3 · Answer 3 · answered Sep 02 '13 at 04:32

I have created a simple youtube video on What is portable class library , you can see it from here http://www.youtube.com/watch?v=DcBfjdDHlxo

But let me answer in more detail here.The whole point of creating a class library project is reusability. Now we want this reusability not only within a .NET application, not across .NET applications but across different types of .NET applications. Now different types of .NET application means WPF, Windows, Silver light, Windows phone etc. enter image description here

Now each one of these application types are different have bit different .NET framework.

For example in silver light application if you try to reference a simple “Class project” you would end with a below error. That’s where portable class libraries are useful. By creating a portable class we can reference it in any kind of .NET project types.

score 2 · Answer 4 · answered May 02 '13 at 20:29

What does the portable class library actually solve?

Eventually it will solve a LOT! (Like Java but in this century)

Is there any code that would compile in a Portable Class Library, that would not function correctly if that exact same code was in a .NET Library?

By Principle I think Not , isn't the other way round ?

But I think, will all due respect, you might actually be missing the point

Think about copy/paste code , and Project cloning , linking code , conditional compiler directives ,( even T4 templates?) and the final result is reference DLL Hell and unneeded complexity, boilerplate , verbosity ( Not very elegant right ?)

Aren't they workarounds to binary incompatibility ?

Its very early But I think its an awesome direction, mostly when you see Xamarin and Mono are working in supporting pcl (they already do partially) ,I think its the only thing it could save as all from Html and Javascript frenzy or Code Generators. (long live TypeSafe!)

PCL could also free up the c# army from the Windows boxes

(but all this is just my opinion)

score 1 · Answer 5 · answered May 02 '13 at 18:58

There are some API differences in the Portable Class Library that concerns .NET Framework 4, when you are developing in Visual Studio 2012. Primarily, this concerns a few properties and methods in the System.Net and System.Xml namespaces. For detailed information, see this MSDN page.

What does the portable class library actually solve?

5 Answers5