Framework Profiles and Platforms

When .NET was initially launched, Microsoft released a single copy of the .NET Framework. This version ran with the one and only CLR that was released at the same time. As new versions of .NET were released, these two things tended to stay in step. A new version of the framework was matched with a new version of the CLR. However, as we moved from version 1 through version 4, the framework started becoming ever larger.

For part of .NET 3.5, Microsoft decided to create a subset of the full framework called the .NET 3.5 Client Profile. This wasn't a major change, but it created a subset of the full framework that could omit certain server-focused libraries. The result is a smaller deployment package for most client computers. The disadvantage, of course, is that it means you need to consider which .NET profile you will target, because the client profile contains only a subset of the full framework.

Now as we look at Windows 8 we see that Microsoft has added another framework platform specifically targeting Windows Metro style applications. In this case, however, the change isn't just to create a focused subset of features; it is designed with the idea that Metro as an alternate platform will have a different runtime and different features provided by the .NET Framework. With .NET 4.5 we are seeing an introduction of a completely different set of capabilities between the frameworks on these two platforms.

Client and Full Framework Profiles

As noted it is possible to state that the client profile available for .NET 3.5 (or later) is in fact a subset of the full framework. These represent what most developers who have been developing for the Windows environment see as the traditional .NET Framework. It should be noted that when we think about the version of .NET framework that will be available on versions of Windows prior to Windows 8, these represent what those machines will have.

The client profile is a subset within the traditional Windows environment that provides a subset of .NET Framework capabilities. It omits things like ASP.NET, the MSBuild engine, third party data-access, and even advanced WCF capabilities. By eliminating these capabilities the deployment of the .NET Framework is made easier.

However, keep in mind that although it is called a client profile, the client isn't limited to only installing this version. Both the client profile and the full version of the .NET 3.5 (or later) frameworks can be installed on any Windows computer. While the features available in each version 3.5 vs. 4 vs. 4.5 for the client profile may change the focus on having a subset of the full version, not a different platform.

Framework for Metro

There is a temptation to state that the .NET Framework for Metro breaks backward compatibility. However, that statement would imply that things written for the Metro environment would also run on version 4.5 of the CLR and leverage the same framework outside of Metro. That statement isn't true. The introduction of the .NET Framework for Metro is a branch in .NET to another platform. The CLR used on Metro does not integrate to the Windows 8 operating system in the same way that the non-Metro version of .NET does.

This is important because it helps explain why applications written against this branch of the .NET Framework will not run unless the Windows 8 operating system is available. In fact you can't even build against this framework unless you are developing on a Windows 8 machine. The .NET framework for Metro prevents actions that are difficult to monitor for security. For example COM-Interop isn't available within the Metro environment.

Applications typically aren't going to just need a minor rewrite in order to move from the existing .NET Framework to Metro. While the underlying features are similar, the Metro framework will have new namespaces and features that are not currently and probably never will be part of the traditional Windows framework. At the same time some of the underlying capabilities of the traditional Windows framework will not be part of the Metro framework. A good way to think of it is that the .NET Framework for Metro will be a client implementation on steroids that leverages WCF to communicate with server-based solutions.

As such the Metro platform will include features such as built-in support for GPS location data, multitouch interfaces, etc. These features in many cases are not going to be made available in the Windows platform. Similarly the Metro platform will have more in common with the .NET Framework Client Profile in that it doesn't support server-side capabilities like ASP.NET or classes that are focused on server-side WCF capabilities.

Silverlight, Windows Phone, and Others

If you've done any development for Silverlight or Windows Phones, you realize that each of these environments is in fact a separate platform. Traditionally, because they were on out-of-cycle release schedules, these platforms weren't part of the core .NET Framework releases.

However, just as Metro is being approached as a separate platform, these platforms have always hosted a custom version of the CLR. If you've done any work with either Silverlight or Windows Phone you know that classes created in a library project that targets the Windows version of the .NET Framework can't be referenced. Instead you've spent a lot of time copying code that exists in one project over to another project that targets one of these platforms.

The goal of this section isn't to break out the common and unique features across each platform. Instead you should now recognize that we need a solution that allows us to write code one time and have it function on multiple different .NET platforms. This is where the new project type within Visual Studio 2012 comes in.

.NET 4.5 Portable Class Library

With a plethora of different .NET Frameworks now in play, it potentially becomes more difficult to reuse your business objects across environments. After all, who wants to rewrite the same business logic for every different platform on which your application needs to function? This doesn't just mean the full application; it means that the Person object you create within the client is the same Person object that you need on the server. Having to rewrite your code potentially breaks interfaces.

You will use a Portable Class Library project, to create a solution that can move across different .NET Framework profiles. In this case the portable designation has nothing to do with a mobile device. The portability is focused on moving between different versions of the CLR. Applications built as a portable class library are limited to features common across each different .NET Framework that is included. In essence they target the lowest common denominator of .NET Framework features across these platforms.

Creating a Portable Class Library project allows you to choose two or more platforms. Table 2.1 shows the available platforms as of this writing. Note that since a profile is a subset of a platform, you'll actually be limited to the features for the client profile of the .NET Framework.

Table 2.1 Portable Class Library Targets