What is Portable Class Library project in Visual Studio 2012– .NET 4.5

You can download from Windows Store at http://apps.microsoft.com/webpdp/en-US/app/emergency-help-me/477b898a-6781-4b75-a439-44dee5904f14

I recently installed Visual Studio 2012 Ultimate edition on Windows 8 RC and noticed Portable Class Library project in the New Project Dialog, which immediately made me to research on what PCL is about. Following is my findings about PCL from the web.

The need for portable .NET Framework code

Developers have seen a diversification of computing platforms over the last few years – PCs, phones, cloud, Xbox, and tablets. It often makes sense to target more than one of these platforms from your app. For example, most client apps and games that are built today call into a server component to retrieve and save data (for example, a set of high scores, a list of friends, a grocery list, or a new expense report). .NET developers often create rich object models that describe that data, and expect to code to that object model on both the client and the server. Wouldn’t it be even better if you could write, compile, and test that common code just once? That’s exactly what portable class libraries enable you to do.

Many of you have asked for the option to reuse assemblies (binaries), not just source code, across projects. Sharing code across projects creates more commonality across those projects, which makes you and your team more efficient. I would guess, however, that many of you share code today by either creating copies of common code for each project, with slight modifications, or maintain a common copy that contains a significant number of conditional compilation directives. These approaches to source code reuse are relatively easy to employ initially, especially in small code bases. As your product codebase grows, you may find that these source-sharing strategies start to scale poorly. You’ll start to wonder what you need to do to share binaries instead. The APIs across the .NET Framework platforms are generally the same, so binary reuse should just work, and that’s what many of you expect.

Portable class libraries enable you to create and compile code that can run on multiple .NET Framework platforms. You can build a library that is usable across all your projects. Whatever that library does, it will do that same thing in all the apps or websites/services that you build. You avoid having multiple copies of the code or managing a set of conditional compiler directives in a common copy. For app developers who have a few common dependent libraries across a suite of apps, this feature is a pretty significant win. It is also a huge step forward for library developers who make their assemblies available to a large audience of developers who build apps for a variety of Microsoft platforms. We’ve seen library developers creating several variants of their work, one for each .NET Framework platform. Portable class libraries either remove that need completely or scope the degree of differences that needs to be supported to something smaller and more manageable.

There are different kinds of .NET frameworks available. There is the .NET Framework, but .NET is also in Silverlight, the Windows Phone, the Xbox, Metro (Windows 8) etc. If you create a regular Class Library it has a single Target Framework. However, if you are doing a multi-platform application and you want to maximize your code reuse, you can run into trouble as you may not have all libraries available on the smaller platforms.

Thus, Portable Class Libraries were created. These Portable Class Libraries (PCLs) will generate a managed assembly that can be referenced by Windows Phone 8, Windows 8 Metro, Silverlight 5, the Microsoft .NET Framework (Client profile) and Xbox 360 platforms. This can really help to maximize reuse of your code and reduce the number of required projects, particularly in multi-targeted applications solutions that share the same codebase

Prior to PCL projects, solution projects could only reference assemblies of the same platform. Silverlight projects referenced other Silverlight assemblies, .NET projects other .NET assemblies and so on. To code effectively, we could accumulate an unmanageable number of projects; when creating shared codebases (code that can be used across all platforms), we’d have to create a project for each platform.

Once you reference another project, your project can become tightly coupled, forcing you to drag not only it, but also any dependencies it has, to the other projects. If you only have a few projects, it makes it increasingly more difficult to reuse the code in other solutions.

A PCL can significantly reduce the number of projects you have to manage, particularly if you want to have a clear separation of concerns permitting you to easily reuse your projects in other modules or solutions. The key is to keep your projects loosely coupled by programming against interfaces. This will permit you to use DI frameworks, such as the Managed Extensibility Framework (MEF) and Unity, which allow you to easily configure the implementation for the interfaces. That is, the DAL implementation for interfaces could be SQL Server, the cloud or SQLite classes.

Some of the key point to using PCL are as follows:

Write once, use everywhere : Portable Class Library is a new project in Visual Studio from Microsoft that enables you to create C# and Visual Basic libraries that run on a variety of .NET-based platforms without recompilation.

Simplify code sharing : No more complicated build scripts or #defines, and stop copying and pasting code for different platforms; portable libraries enable you to easily share code between apps that target different platforms.

Share between platforms : Create a Portable Library project and reference it from any .NET Framework, Silverlight, Windows Phone or XNA project as shown in Fig 1.

 

Fig 1: Example of using PCL in different apps that target different platforms

The Portable Class Library project enables you to write and build managed assemblies that work on more than one .NET Framework platform. You can create classes that contain code you wish to share across many projects, such as shared business logic, and then reference those classes from different types of projects.

Using the Portable Class Library project, you can build portable assemblies that work without modification on the .NET Framework, Silverlight, Windows Phone 7, or Xbox 360 platforms. Without the Portable Class Library project, you must target a single platform and then manually rework the class library for other platforms. The Portable Class Library project supports a subset of assemblies from these platforms, and provides a Visual Studio template that makes it possible to build assemblies that run without modification on these platforms. [Source = http://msdn.microsoft.com/en-us/library/gg597391(v=vs.110).aspx]

Target Platforms Determine Available APIs

Within a Portable Class Library project, you can specify which .NET platforms the library is intended to run on.  Although there is a ‘core’ set APIs that are available on all platforms, there are also some APIs that are only available on certain platforms.  An example of an API that exists on some platforms but not others is MEF.  Windows Phone and Xbox 360 do not currently have built-in support for MEF, but .NET and Silverlight do.  If you want to use MEF within a portable library, the library will currently only run on .NET and Silverlight.

When you specify the platforms you want to target in a Portable Class Library project, only the supported assemblies for those platforms are referenced in your project. If you try to reference an assembly that is not supported for the platforms you have targeted, Visual Studio warns you of the incompatibility. The core assemblies (mscorlib.dll, System.dll, System.Core.dll, System.Xml.dll, and System.Xml.Serialization.dll) are supported on all versions of all platforms.

If you target only the .NET Framework 4.5 RC and .NET for Metro style apps, you have access to a much larger set of assemblies than is available in other platform combinations. This larger set of assemblies is almost identical to the .NET APIs for Metro style apps, but doesn’t include the classes in the Windows.UI.Xaml namespaces. For more information, see .NET for Metro style apps in the Windows Dev Center.

Thus, the project’s selected target platforms determine which APIs can be used within the project.  The APIs that are shown in intellisense and available to the compiler are automatically filtered based on the selected target platforms, so you don’t need to have any special knowledge about each platform or worry about inadvertently using an API that doesn’t exist on a platform that you’re targeting.  The project system takes care of this for you.

In the future, as the underlying platforms evolve to support more APIs that could be portable, MS will update the API surface available to portable libraries as appropriate.

Supported scenarios : We used the following main scenarios to define the scope and direction of portable class libraries:

• Call BCL APIs
• Use the latest language features, such as dynamic programming, async and LINQ
• Read and write XML
• Call HTTP URIs, specifically for REST-style end-points
• Call WCF services
• Build Model-View-View Model (MVVM) patterns

Supported platforms : It’s easy to support the scenarios listed above for one or two .NET Framework platforms, but MS needed to reach farther and support a broader set of platforms. In Visual Studio Professional 2012 RC, the Portable Class Library project supports the following .NET Framework platforms:

• .NET Framework 4, Update 4.0.3 for the .NET Framework 4, and .NET Framework 4.5
• .NET for Metro style apps
• Windows Phone 7.x and higher
• Silverlight 4 and 5
• Xbox 360

The following table summarizes the high-level functionality currently available on each platform:

Fig 2. Supported portable class library features and scenarios

Following is some of the important features and the respective assemblies.

Core :mscorlib.dll, System.dll, System.Core.dll, System.Xml.dll, System.Xml.Serialization.dll

Managed Extensibility Framework(MEF):System.ComponentModel.Composition.dll

Network Class Library (NCL) : System.Net.dll

Serialization : System.Runtime.Serialization.dll

Windows Communication Foundation (WCF) : System.ServiceModel.dll, System.ServiceModel.Web.dll

Model-View-View Model (MVVM) : System.Windows.dll

Data annotations : System.ComponentModel.DataAnnotations.dll

LINQ to XML : System.Xml.Linq.dll

Constraints of PCL: The only constraint is that the PCL can’t reference platform-specific projects; it can only reference other PCL projects. On the surface this can appear limiting, especially for applications that utilize Prism and dependency injection (DI). But with careful planning, you can work around this constraint and create efficient PCL projects that will help enforce good development practices.