Using the .NET 4 Client Profile

With beta 2 of Visual Studio 2010 and .NET 4 came a lot more information about the ".NET Client Profile". This is an (admittedly large) subset of the full .NET Framework that targets "desktop client" applications. Because it's a subset, it's by definition smaller than the full thing and so would appear to be more palatable a download for those Windows PCs that don't have a copy of .NET 4 (which at launch will be everybody, of course). The .NET 4 Client Profile will be downloaded onto people's PCs using Windows Update.

So, the pros are simple: smaller download; if you chain to the .NET installer in your installer, a smaller overall installer; by reducing the set of functionality in the client profile, a smaller possible attack surface; er and that's pretty much it. Shorter version: it's more compact.

The cons? Well, if you create a desktop client (a WinForms or a WPF app), you will have another step to go through, another decision to make, in your design and implementation: which profile does your app target? The client profile or the full framework? By default, VS2010 will create a new project to target the client profile and not the full framework (unless it's a Class Library, in which case you'll be targeting the full framework). Note that I said project there and not solution. It seems it's valid to have mixed-profile solutions, although Microsoft do warn of possible build errors and/or run-time errors if you do so.

If a user runs an application compiled for the full framework on a PC with only the client profile installed, they will get a dialog prompting them to download the full .NET framework. If an application compiled for the client profile runs on a PC with the full framework installed, it just works. If the application targets the client profile, but a class library within targets the full framework, and it is run on a client profile PC, you'll get an exception. Welcome to more "works on my machine" fun.

So what's not in the client profile? What's been taken out? Developer-oriented code (design-time stuff especially); the Oracle client (it's being deprecated anyway); the design time libraries for EF and ADO.NET Data Services; ASP.NET; ASP.NET AJAX; Workflow rules integration; WF3 and WF3.5. Of course, having seen that list, you won't be surprised to learn that you'll be developing in VS2010 using the full framework; no .NET Framework "lite" for us developers.

Sounds fairly innocuous right? As Microsoft put it, "most" client desktop apps should function perfectly well with the reduced functionality of the .NET 4 Client Profile. I would tend to agree; however, we've already found problems with that broad statement.

Let's take a look. In essence, if nothing changed in .NET 4 between now and release (that is, the client profile functionality doesn't change, or we don't rewrite some of our assemblies), the way it stands at the moment you would be forced to target the full framework with your app that uses DevExpress components and controls. There are three main reasons:

• We use System.Design.dll for some run-time related code, mostly related to attributes for serialization, type converters, localization, and the like. We use serialization all over the place to serialize information in charts, reports, bars, ribbons, what have you. This particular limitation is not too difficult to get around.
• We use System.Web.dll. Before you wonder why on earth anyone would use web-related things in a client desktop app, consider this. We use common assemblies that span platforms (indeed, I was celebrating the fact in a recent blog post) and for the ASP.NET side, we use System.Web. In fact there's one type in particular we use a lot in these common assemblies: PersistenceMode.
• Another use for System.Web.dll is in our export functionality in XtraReports, in particular the export to HTML. Rather than write our own classes, we've reused the ones in System.Web.dll. You know: reuse rather than copy/paste.

Now, of course, these limitations can be circumvented by writing new code and modifying what's there. However, in doing so, we would necessarily break a lot of customer code. A lot. Also, there's no possible way for us to split and maintain our codebase in two parts, one for VS2005/2008 and the other for VS2010 and later. That way madness lies.

In conclusion: at present we're investigating the issues that we see with .NET 4's Client Profile and how we can best mitigate them. I have a question for you though: would you prefer writing desktop apps that targeted the Client Profile (and therefore must have "client profile ready" controls), or do you not care in the slightest?

(For more information on the .NET 4 Client Profile, see this blog post.)

Free DevExpress Products - Get Your Copy Today