Client Profile in .NET 4

If you redistribute or require .NET 4 for your applications, you now have the option of installing .NET 4 Client Profile – a subset of the Framework intended for client applications.

Even better, Client Profile includes almost all pieces of Windows Workflow Foundation and Windows Communication Foundation! The few exceptions are assemblies oriented around web-hosting and WF3 components; I’ll get to these limitations later in this post. First, I’ll describe how you can start taking advantage of the Client Profile right away, and explain what’s included from the perspective of WF and WCF. For more details about other parts of the Client Profile, refer to this introductory post by Jossef Goldberg.

An overriding theme of our efforts has been to ensure that applications running in .NET 3 or 3.5 remain unaffected when switched over to running in .NET 4. Also, developers with projects building in .NET 3 or .NET 3.5 looking to move to .NET 4 are also not affected (and in some cases, only minimally affected) when rolling their projects forward.

So if Client Profile doesn’t interest you, relax – it’s a choice. Also, note that if you install .NET 4 Full, .NET 4 Client Profile is a fully contained subset of .NET 4 Full – so anything that’s a part of .NET 4 Client Profile is a part of .NET 4 Full.

To enable your application to target the Client Profile, you just need to change the “Target Framework” setting in your project like so:

Applications built and targeted this way will be able to run on machines that have the .NET 4 Client Profile installed, as well as those with .NET 4 Full. These projects will not let you build successfully when referencing classes that exist in only .NET 4 Full. On the other hand, applications targeted at .NET 4 Full will be unable to run on machines that only have the .NET 4 Client Profile installed on them, and you’ll get an error message directing you to download and install the Full framework:

To maximize what you could exploit in the Client Profile, we have refactored two assemblies. Each of these assemblies is now effectively split into two, one existing in the Client Profile and another that can be referenced from only .NET Full projects:

1. We’ve moved the JSON serialization classes from System.ServiceModel.Web.dll to System.Runtime.Serialization.dll. These serialization classes are being type-forwarded, so if you have any existing applications, they’ll continue to run just fine. System.Runtime.Serialization.dll will be installed with.NET 4 Client Profile, while System.ServiceModel.Web.dll will come with only .NET 4 Full.

2. We’ve moved and type-forwarded some classes related to hosting and activation from System.ServiceModel.dll to a new assembly, System.ServiceModel.Activation.dll. The former assembly is a part of .NET 4 Client Profile, while the latter is in .NET 4 Full.

Like I mentioned earlier, almost all assemblies we shipped with .NET 3 and .NET 3.5 are a part of the new .NET 4 Client Profile. In addition, almost all assemblies we are shipping for the first time in .NET 4 – including all WF4 assemblies – are a part of .NET 4 Client Profile. A comprehensive list of what’s in the Client Profile and what’s not will be published on MSDN.

So what’s not included in .NET 4 Client Profile? Here is a list of the main pieces, but this is not meant to be exhaustive. If your applications depend on anything from this set of assemblies, your projects should target .NET 4 Full:

- WF3 in .NET 4: This includes System.Workflow.Runtime.dll, System.Workflow.Activities.dll, System.Workflow.ComponentModel.dll, System.WorkflowServices.dll, and other related SQL files, performance counters, and tools.

- WF4 and WCF Hosting assemblies: System.Xaml.Hosting.dll, System.ServiceModel.WasHosting.dll, System.ServiceModel.Web.dll, System.ServiceModel.Activation.dll, WsatConfig.exe, and related tools