What's the rationale for creating PCL Contrib and not implementing in PCL itself?

Sep 20, 2012 at 1:26 PM




Oct 9, 2012 at 7:03 PM

Sorry for the late reply, I didn't get notified when this was posted.

Good question. The biggest major reason is because this project covers APIs that we consider legacy or deprecated (such as BackgroundWorker). Shipping something in .NET implies that it will be supported, documented and serviced for as long the product itself is (which as it ships in Windows 8 is a long, long time). Given that, if we were to ship in PCL, most of them wouldn't have shipped in the first place.

The aim of this project, is provide quick, easy bridges that help you get up running for existing code. Long term you should consider moving across to the "supported" APIs.

In saying all that, however, there are PCLContrib-like libraries (such as Async) that we are looking at shipping officially. What we choose to support, is entirely based on customer feedback, so if you have suggestions, please add them over visualstudio.uservoice.com.