Using the .NET 4 Client Profile

27 October 2009

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.

PlasticBlocks 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.)

36 comment(s)
Chris Walsh [DX-Squad]

I would like to see the work done to remove the dependencies on the design DLL, but you should't have to mitigate the issue with System.Web.

When adding XtraCharts, simply check the .net 4.0 target type and throw up a warning to the Developer.

I don't agree with duplicating proven code into another DLL, this puts extra risks on DevExpress and the Developers.

27 October, 2009
Bradley Uffner_2

I can tell you that everything I write will be targeting the full profile, so I guess that means that I don't care.  the ~30mb of space difference doesnt seem like its worth splitting the .net community over though.  This seems like it's going to be more trouble than it's worth.

27 October, 2009
Michael Proctor [DX-Squad]

Julian,

From my perspective the Client Profile for a 32bit/64bit is 47.1mb and the full is 54.5mb making a difference of just 7.4mb.

So even on a 100KB/s download it is only an additional 75 seconds for downloading the full versus the amount of "dramas" running a "lite" framework.

Doesn't seem to make sense to me. I certainly wouldn't be upset by having an additional 7mb to my package.

If the full was in the hundreds and the Client Profile was half I might (slightly) rethink it, but at the moment, I wouldn't waste my time.

27 October, 2009
Vijay2006

If targeting the client profile would mean that click once would work seamlessly than that would be an important consideration...

27 October, 2009
Julian Bucknall (DevExpress)

Michael, Bradley: Good point about the file sizes of the profiles. I'd completely forgotten to mention them, and the slight difference between the profile and the full framework. It almost seems like a storm in a teacup to produce such a huge solution over an effectively small size difference.

When I first read about the .NET 4 Client Profile, I was thinking that the profile would turn out to be Silverlight-sized, in which case I could countenance doing some work to support it. But 8-ish MB of difference?

Cheers, Julian

27 October, 2009
Chris Walsh [DX-Squad]

Michael,

The issue is that MS are looking to deploy the client profile version only via windows update.  

27 October, 2009
Jens Fudickar [DX-Squad]

I agree with Michael

27 October, 2009
Sakesun Roykiattisak

Last week, I just down-port my devexpress client application,  that originally develop for .NET 3.5, back to .NET 2.0, in order to keep clickonce prerequisite under tolerable size.

Unless silverlight control is as feature rich as WinForms, client profile is very importance to me.

27 October, 2009
Vijay2006

Julian,

For a click once application, the difference would be more about requiring administrative privileges rather than size per se. As a developer, targetting the client profile would mean a smoother installation. This is particularly critical in a large corporate environment where deploying the full framework may not be on IT supports priority list.

27 October, 2009
Nate Laff

Bleh, don't care.

Appreciate the pro-activity, (is that a word? pro-activness?) on your part, but i certainly wouldn't strain yourselves with it. the size difference just isn't worth it.

27 October, 2009
Chris Walsh [DX-Squad]

Nate,

Its not the size issue, its the fact the ONLY the client profile will be deployed via windows update.  

27 October, 2009
Jim Clay

I develop for an in house app and when I do convert over to VS 2010, and look at .net 4, I will load the whole framework on all of our clients, so that won't be an issue here.  Sometimes I think MS just likes to make more work for people.

27 October, 2009
Jim Foye

My initial reaction is, I don't care, it sounds like another pain in the *** we will have to deal with; it's maybe not a good idea at all on the part of MS.

27 October, 2009
Chris Seils

I don't think it's worth the time and resources you will have to throw at this to get it working.  It's such a small thing.

I'd rather you use the time on creating new controls and improvements to the existing ones.

28 October, 2009
Steve Sharkey

I'm with Chris - sure we all moaned at the .NET download size at some time but it's a download once issue. When I install an app on client here and find they don't have .net installed I don't re-write the app I download the framework. Microsoft are just trying to muddy the waters again (like the WPF/Silverlight confusion they seem intent on creating!)

28 October, 2009
Tor Myklebust

What Chris Seils said. :)

28 October, 2009
Peter Thorpe

The list of bits removed, fair enough sounds like only a developer would use, but I simply don't see the point.

The size difference in my opinion is negligible and it's just giving us one more thing to have to think about.

I know I use System.Web in one of my projects and since I use it in one it might as well be them all from a deployment perspective for internal apps, I want all my apps to work on any windows machine (Like .NET is supposed to be).

I would stick with the full for all your controls, save yourself the hassle.

28 October, 2009
Nate Laff

Chris,

I use installaware and have it auto-download what I need, so the full frameworks absense on windows update also doesn't bother me :)

28 October, 2009
Michael Proctor [DX-Squad]

I agree with Nate, the Windows Update only installing the Client Profile isn't such an issue.

Ideally what microsoft SHOULD do is release a .NET 4 Full Upgrade containing the other 8-20mb to bring the Client Profile up to a full version, that would solve a few issues.

However I beg the question that if the Client Profile has a few limitations in it how many apps like Nero and alot of other mainstream apps that are now using .NET will just install the full version anyways?

These days I am generally finding .NET 3.5 installed on systems that I wouldn't have thought would have had it, but find another app needed it an installed it already. If .NET4 is as good as it seems it will end up on alot of computers rather quickly anyway.

28 October, 2009
Crono

Actually I don't dislike the idea of having a "lite" .NET Framework. I couldn't care less about size either, but one of the most basic rules of computer security says that if you don't need it, then don't have it.

.NET somewhat encouraged us developers to forget about this rule.

28 October, 2009
Glenn Adams_1

Not an issue for me. I always install full framework.

28 October, 2009
Tom

I think this will be a big issue. We are developing apps that will target .NET 4.0, and we are counting on Windows Update to service the framework requirements.

If your controls require the full framework, and it forces our customers to download/install that in order to run our apps, then this is a major disadvantage.

I'm surprised so many commenters above are ignoring the customer usability problem this creates. I understand it is a thorny problem, but it is something that needs to be solved in my opinion.

28 October, 2009
Adriano

If us, the developers, use some code to build the actual application based on the framework, and then Microsoft decides to split the framework into a "lite" and "full" versions, then obviously this introduces incompatibility with the 99% of libraries and applications out there.

I hope and guess that the intention is, on the final version of the framework, to download the full version when required and as a "transparent" action, otherwise this will be another nightmare for all of us.

However for now I prefer to have the full framework instead of patching my apps/controls, at least for now... then decide to move to the lite version in the future, when the actual decisions from MS will be clear.

28 October, 2009
Jason Short

"but it is something that needs to be solved in my opinion."

Yes, by Microsoft.  How many .Net distributions are there?  There are at least 6 that I know of already.  They are not documented, there is no way we developers can actively target them.  Now in .Net 4 they want to add a lite mode, dumb.  Let's fragment the platform even more!

.Net = .Net

Don't make me have to start asking all the Java like questions.  Which build, what SPs,  Lite / Full, did you get this optional part that I can't install for you because Microsoft doesn't allow redistribution of that component?  Etc, etc.

Microsoft PLEASE make it a single deployment.  Get rid of Server Core, Lite, Full, Get rid of the hacked ugliness of Silverlight.  Make it a PLATFORM.  One that we developers can count on to be present.  

28 October, 2009
Shawn Oles

Maybe there is still time for adjustments, but Client profile seems confusing to me.

I totally agree with Jason and others about making sure Client Profile is abandoned if only 8MB diff in download.

Here is my opinions...

1) .Net 4  FULL, should included entire framework + silverlight for windows, should install via Windows Update, why do we need to seperate installs for silverlight and .net framework, or at least it feels like that is how it works now.

2) .Net 4 Silverlight..  only gets installed on Linux, Mac and other non ms platforms. Allows silverlight apps to run on non-windows platforms, this should be the only "lite" .net framework in my opinion.

3) Get rid of the distinction between 32 and 64 bit, this should be built on the installer.

4) Allow on demand download of obscure features in .net framework FULL for low bandwidth machines

5) Detect bandwidth in installer and give the option to install all now or on demand only if bandwidth is slow (or maybe always prompt for this when manually installing), if bandwidth is good to the client machine, why not install entire thing at that instant.    Even a 3G connection can download 50MB within a few minutes these days.

What are the justifificaitons from MS for Client Profile version??

It will be so frustrating to get to a client site, get to a point where we can run the app, but not be able to launch the app because the IT Department does not allow the end user to install apps....     Maybe we all need more clarity..

28 October, 2009
Martin

I'm somewhat surprised: you are the CTO of one of the two platinum sponsors of the Microsoft's PDC-event and yet it looks like Microsoft leaves you in the dark. I remember a blog post along the same lines about Silverlight and WPF from your hand.

That post made me decide to leave Slverlight/WPF alone until the dust settled.

This blog post makes it obvious that we should stay off VS2010 for at least a year. After all the majority of our customers isn't waiting for an update for the update's sake. I wouldn't be surprised if VS2010/NET 4 is the Vista fiasco all over again.

28 October, 2009
jossef

Thank you guys for your feedback.

Although a reduced redist size for the NET 4 Client Profile and the improved deployment speed are important, they are not the only reason why we decided to have  it.

Traditionally,  ASP.net and other server components (that are not included in the Client Profile) caused large amount of MSRC  and servicing events, so by keeping these components only in the Full framework, we reduce the reduce attack surface and in addition.

Users’ desktop will no longer get MU/WU updates for components that do not even use or need.

We believe that the NET 4 Client Profile has enough features to support most client applications.

We would love to get your feedback to see what you believe is missing from it.

Please note that NET 4 Client Profile now has a new System.Web.ApplicationServices.dll assembly which now includes some of the commonly used types that used to live in System.Web.dll  (which is in Full).

Have you checked it? I believe that PersistenceMode mentioned earlier is there.

Please read more about NET 4 Client Profile in this blog

Thank you.

Jossef

28 October, 2009
Julian Bucknall (DevExpress)

Jossef: Thanks for passing by and for your comments. I've forwarded them on to our development team for further investigation and I may be back to discuss any issues with you.

Cheers, Julian

28 October, 2009
jossef

Hi Julian

Can you provide email?

I would love to contact you to understand which classes from System.web.dll your you app must use to “export to HTML”

28 October, 2009
Julian Bucknall (DevExpress)

Jossef: My email is julianb@devexpress.com.

Cheers, Julian

28 October, 2009
RAUL TORTIMA

Hi, I should comment something that may be put aside in this topic...Ive read somewhere this framework "version" may be faster in the way it works, if compared to its larger brother. I am not completely sure about it, but it may be true because some methods would have been rewritten, or just supressed several calls not needed in this version. Well, if thats true, I would say download time is not as relevant as this argument to use it, dont u all agree?

30 October, 2009
Kevin White

I'm with Jim Clay.

I work on an in-house app and I'll just deploy the full framework when the time comes. I would much rather not have to deal with resultant issues from having only the client profile.

Sometimes I think Microsoft finds solutions in search of problems.

30 October, 2009
Shawn Oles

Hi Jossef,

Do you work for Microsoft?  If that is true, I thank you for your insider feedback.    If security was the main reason that Client Profile exists -rather then-  Full Framework maybe what you are saying is that we need to have the distinction of  "Server Profile" rather then "Full install".  That actually makes me feel much better, but if that is true then I hope that Developer Express and other third parties are given enough information about these Profiles.    Hopefully we will end up at a point where   "Client Profile" is all that is needed for  Windows Forms and  WPF Applications.       I still wish that it was a single install.    Maybe it would be worth considering  Always installing "Full" but require an Administrator for the Machine to specificlaly enable the   .net "Server Profile".

30 October, 2009
P. Hoogerkamp

I would prefer the .NET 4's Client Profile above the Full Framework.

As a company we make both in-house as 'off the shelf applications'. We experience the fact that in many cases the latest version of the .Net Framework is not on our clients pc's to be a major risk because it is another possible obstacle for a successfull installation. A failed installation means most of the times a lost sale.

Many times the download for the framework is several times bigger than our application. We also use InstallAware but have experienced problems with the download of the framework because of firewall and/or proxy servers.

So the fact that the Client Profile is installed by Windows Update and is smaller than the full installation is important to us.

5 November, 2009
J.D. Mullin

Most of my desktop apps use at least one web service, and depend on System.Web, so I'll be targeting the full framework.

5 November, 2009
Mark in the UK

Our software is for general sale and customers download and evaluate our software.  I don't want our customers to have to install the full framework just to try our software.  I have just upgraded from 12.2 to 14.2 for the Spreadsheet only to find it doesn't work on the Client Profile.  I can't say I'm impressed.

14 April, 2015

Please login or register to post comments.