.NET 4 Client Profile: the good news and the bad news

22 March 2010

Block by block Way back in October last year, I discussed the .NET 4 Client Profile, the cut-down .NET Framework that will be the default framework target for new solutions in Visual Studio 2010. Since VS2010 is less than a month away from release (at least for MSDN subscribers), I thought it best to bring you up to date with our progress on this front.

As is traditional in these affairs, I’ll introduce it through sections labeled Good news and Bad news.

The Good news

We shall fully support the .NET 4 Client Profile with DXperience v2010 vol 1. That is, if you create a default app in VS2010 with v2010.1 installed, all of our WinForms and WPF controls will be visible and enabled in the toolbar. They will all work with the .NET 4 Client Profile. Hooray!

The Bad news

XtraCharts, because it targets both ASP.NET and WinForms applications, uses System.Web in its common assemblies in version 2009.3 and earlier. System.Web is not part of the Client Profile. So, we had a choice: shrug our shoulders and say, “creating charts in your app? Use the full framework.” or modify XtraCharts to remove the dependency. We opted for the latter. Many reasons I suppose, among them being XtraCharts also broke XtraReports, and new customers evaluating our charting and/or reporting products would probably get weird errors and/or non-working apps by default. For the latter: ouch, ouch, ouch. Like everyone in business, we depend on getting new customers for our growth and survival and the smoother we make the evaluation path, the better.

I hasten to add that this decision was hard to make and there were good arguments for both sides. It’s a measure of how difficult it was that it was only finalized just recently, within the last week. Indeed, it seems that XtraScheduler was also on the ‘bad news’ list until the end of the week, but the team thinks they’ve resolved their issues without any further problem.

What this means for our current customers though is that XtraCharts will have breaking changes, whether you use VS2010 or not. We’re investigating altering our Project Converter to modify your aspx files, since it’s these that will break most easily.

I’ll have more news as and when these changes have been made and fully tested and once our parser guys have investigated the Project Converter and ASPX files.

20 comment(s)
Michael Proctor [DX-Squad]

Gotta love those Spanners that keep getting thrown into the works ;)

I could imagine how hard that is because utlimately having a "Core" library that supports multiple technologies is a brilliant approach and one I believe was a good decision back when XtraCharts was first split, and now with other components such as Scheduler and RichEdit also having Core libraries it must be quite frustrating to have MS through this pansy idea of a "lite" (and I use that term lightly) framework, unless there has been some major changes it only reduced the framework installation from a 50mb to 40mb install (roughly) this is 1/5 saving but gain alot of headaches. One of the motivators was security but come on, you can't tell me with the bits they cut out that malware can't live free without restriction.

Not to be cheeky but I have to ask... based on this are we still looking about 3 weeks till public beta with release end of April?

23 March, 2010

If you guys came to this decision, then there should be some valid reasons.

I am bit curious :-) I am quite sure that you might have considered this option, if not,  how about shipping a two different versions of the same assemblies for Xtra Charts,   one which is built against Client Profile and one against full framework.  

So that you could install your client profile assemblies under this folder during your installation ?

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\Profile\Client

We shall continue using it without any problems or any additional deployment procedures,  right ?


23 March, 2010
Peter Thorpe

Not a fan of the client profile I don't think it saves enough downloading to justify itself for the developer headache. I am going to suffer from the same issue with my own code and System.Web.

Not investigated yet anyone know if I will be able to xcopy deploy System.Web?

23 March, 2010
mahdi vejdani

Please do this, I have a winforms application and need to reduce my setup package size.

It would be kind of you.

Please be Devexpress!.

23 March, 2010

I personnally think you did the right thing. I guess it's easy for me to say since I don't use charts this much though. :p

23 March, 2010
Michael Thuma

The size of the JRE is 15MB ... maybe this has something to do with this decision ... but you cannot rely that someone for whatever reason has decided only to install the Client Profile and as part of a standard image spread the thing to 100s of computers in a comp in order to increase the speed of the .net X rollout ... maybe the client profile needs less patches ... I don't know ... - But your decision is right in the end. You cannot rely that the full Framework is installed.

23 March, 2010

I'm all for client profile, I "voiced" my opinion on this long ago and put in the support center suggestion in prehistoric times :)

I read your article in that XC is broke with client profile, I would imagine XtraReports and XtraPrinting would also be broken since they too work both in win & web?  I'm curious of your components which depend on System.Web and therefore would need to be re-engineered for CP?

Thanks for doing this.  Remember the days you Delphi/C++ guys could deliver an app on a floppy where we VB'ers had to haul around all that muck?  Well now you're in our shoes, your small .NET apps require megs of payload.  Yeah, broadband is widespread but in the spirit of saving bandwidth AND helping those that don't have high speed internet it is a good thing and I'm willing to break/fix an app to get this capability.

23 March, 2010
Michael Thuma

@Neal: VBRUNXXX.dll hahaha ... I can remember programmers wondering - it works on my computer at home but at the customers site the application does not start ... end80s early 90s ...

Ok the size ob VBRUN100.dll has grown from 154KB to 972KB (after 1.1 MB in V5.x) in the ... so don't tell us it was the size of the floppy;-). Buy a second one.

Delphi/C++ guys  --> This still works ... but inventions of the last 2 decades the internet, the > 2 MBIT Land and the USB stick allow us now to add RTTI information to our executables and transport them to the users desktop:-). So we simply break the 1.4mb limit ... the smart way.

System.Web --> Afaik this was the original idea of Winforms and Webforms to have one codebase and only different renderings on a somewhat shared codebase. But I can be wrong ... as this is long ago ... and my intrest in .net has dramatically deceased ... in the past 2 years ...

23 March, 2010
Joe Hendricks

A little lost here.. so, with my upcoming XAF app that depends on webforms, but XTraReports/Charts have to be created in Winforms to be used online, should I stay with 9.x instead of 10.x?

23 March, 2010
Julian Bucknall (DevExpress)

/K: I thought I'd given a reason in my discussion. When you create a new solution in VS2010 it will target the .NET4 Client Profile by default. If I'm a pre-sales customer and want to evaluate our XtraCharts in a WinForms application then, if we did nothing, the evaluation program I write would *fail* on a Client Profile machine. I would thereby blame DevExpress for writing crappy controls: "look even a simple app crashes, what are they playing at over there?"

If I'm a current customer and I forget all about this Client Profile stuff, and my charting app crashes, I'm going to bombard support with emails demanding help. We certainly don't want to dump a whole load more support on them, because no one is going to read the help file where it says "To use XtraCharts make sure you target the Full Framework".

So all in all that's part of the reason for making this change.

Cheers, Julian

23 March, 2010
Julian Bucknall (DevExpress)

Joe: You'll be fine with 10.1 onwards.

Cheers, Julian

23 March, 2010
Julian Bucknall (DevExpress)

Peter: I'm pretty sure you cannot deploy individual assemblies from .NET. Your customers and users would have to install the full framework, if they don't have it already (and remember that essentially means Windows XP).

Cheers, Julian

23 March, 2010
Klaus Dress

Thank you very much for the warning!

This is very important info that I did not know about.

Best wishes


23 March, 2010
Andreas H. Lengauer

.NET Client Profile is not needed any more - The silverlight stuff does this job. Tried to work with client profile 3.5? The setup want to install it on a Windows 7 computer. Full works fine. That su...

So : If you want your software running on client machines then you develop in 3.5 comnpatible with W7. If you have full control over the machines your software should run you need no client profile. Simple - isnt't it?

24 March, 2010
Peter Thorpe

@Julian thanks for the reply wouldn't the fact the .NET 4 CLR is a new side by side version not additional libraries like 3.0 and 3.5 mean I would need the .NET 4 System.Web if I switched?

Meaning I would need to do the .NET 4 full install even on vista and 7.

24 March, 2010
Karthik M

Thanks Julian,  Keeping my fingers crossed as like others for your plans on WP7 in one of your future posts.


25 March, 2010
James Birnie

I understand this is the harder decision and will take extra work for your team in the short term.. but it's still the right decision.

Thanks, James.

25 March, 2010
Patrick Wolf

That's really unfortunate that you have to spend your time with this rather then improving features.

The only real solution would have been for Microsoft to scrap the Client Profile...

I really can't see ANY benefit of reducing the .NET Framework deployment by 6-7 MB if I think of the headache and extra work it causes you right now and many other developers along the line.

So sorry to hear that you had to do it but I understand that you had to do it since Microsoft started it.

All the best,


25 March, 2010

All I can say is Microsoft does it again: 1 step forward 3 steps back. They seem to want to fix the parts that aren't broken but leave the ones that are, untouched...

26 March, 2010
Tom Jackson Mboya

I am so lost on Visual Studio 2010, help us in africa, becuase, we love how you reason and dioscuss this issues but for us it is a big challenge, please help us my e-mail: mboyajackson@yahoo.com

Best regards


29 March, 2010

Please login or register to post comments.