What are the decisions behind type availability for particular platform?

Question

I just decided to play with PCL and converted my class library to PCL.

Not surprisingly it cannot be built showing many errors of type missing.

But what I was really confused is by by what types absent.

CancelEventArgs class is supported but CancelEventHandler is not.

Is this by a mere chance or deliberate decision not to include particular type? Can I extract any useful information about platforms design from the fact of type presense or absense?

Let me clarify:

I can understand the cases when too platform specific concepts are removed.

But with PCL things are not very evident to me.

I got used not to think of myself as cleverer than others thus I look for clear reasons.

To make common type set as large as possible is to ease the migration between platforms. As Eric Lippert says every feature must be justified from the point of view of value/expenses ratio. Hence, I either overestimate the value of large type set or underestimate the difficulties of implementing its portability.

---

As to specific events running code analysis gave a sound recomendation to use genreic version EventHandler<TEventArgs>

Another similar question.

Answer 1

It is a pretty mechanical process. Simply intersect the set of types available in each of the platforms that you selected for the PCL project. Remove every type that's not available in one of the targets. What you got left is what you can use.

CancelEventHandler might look like a strange omission, until you take a closer look at the type. It has an attribute, HostProtectionAttribute is not widely supported.

So PCL just helps you avoid the "oh shoot!" moment when you've heavily committed to using a type in a class library. To find out later that you can't make your library work on another target. That's very ugly, potentially destroying a lot of time spent on writing and testing the code. Getting an early heads-up about that problem can save you an enormous amount of pain and suffering.

Of course, that doesn't actually work when you do it the wrong way around, converting a regular class library project into a PCL project. That's a quick "oh shoot!", and doesn't have anything to do with limitations in PCL, but at least you'll know what to focus on and get a decent impression how much work is ahead of you.

Answer 2

I cover this a bit in the "Why APIs aren't Portable" section of this blog post.

When we were first working on Portable Class Libraries, .NET 4, Silverlight, and Windows Phone 7 were finished or mostly finished so we couldn't make many changes to them to support more portable APIs. With .NET 4.5, .NET for Windows Store apps, and Windows Phone 8, we were able to do much more to support PCLs. Almost all of the .NET types in .NET for Windows Store apps are available in PCLs that target .NET 4.5 and .NET for Windows Store apps. Windows Phone 8 also supports most of those APIs, and the biggest gap was HttpClient which we've filled with a NuGet package.

So basically, if you target newer platforms, many more types will be portable, and as time goes on it should continue to get better.