Support for .NET Client Profile being discontinued

ctodx
13 May 2014

OK, color me surprised: I thought we’d discontinued supporting the .NET Client Profile a while back, but it seems I am wrong. First of all, a little background.

Way back in .NET 4.0 beta days, Microsoft introduced a “smaller” set of .NET assemblies that contained the major part of the .NET Framework. The idea was that deploying the majority of .NET apps would result in a smaller download should the deployed-to PC not actually have the Framework installed. I wrote about this in October 2009 – “Using the .NET 4 Client Profile” – when we were learning about the proposal (at PDC if I recall correctly). We spent a considerable amount of effort at the time in order to try and support this new initiative from Microsoft – you can get hints from reading between the lines in that old post.

Given all this, my question to you is, do you use .Net Client Profile when deploy your application? If so, here is some important news.

Although Microsoft continued to support the .NET Client Profile in .NET Framework 4.0, they discontinued it in 4.5. The reason was simple: the size of complete framework had decreased by about 15% anyway, all it did was introduce headaches for developers and their end-users, and current Windows installations include the Framework by default. Based on this, we have decided to stop supporting .NET Client Profile in 14.1 for some products, and we are going to completely stop supporting it in v14.2. Doing so will allow us to get rid of some unnecessary assemblies; however it will mean a breaking change should you still be using the .NET Client Profile.

What do you think? Are you still using it? Do you rely on this functionality still? Please let me know your thoughts.

13 comment(s)
Nate Laff
Nate Laff

I did exactly what you did. Supported it (where I could) when it came out, but I upgraded all of my projects to 4.5 when it was released. With Microsoft dropping the concept in the latest .NET releases, it makes little sense for you guys to hold on to it.

13 May, 2014
Christopher Todd
Christopher Todd

Yeah, I concur.

13 May, 2014
Jonatas Hudler
Jonatas Hudler

We are one case that still requires (only) the 4.0 Client Profile from our clients, but I do agree with the discontinuation of it.

Some features (Eg: End-User report designer) already requires the full profile - as the product evolves, the requirements must respond as well.

13 May, 2014
Robert Schlesinger
Robert Schlesinger

I am also ok.

I miss polls or questionnaires from Devex to pickup opinion from devs.

14 May, 2014
Tony Phillips
Tony Phillips

Agree, makes perfect sense

14 May, 2014
Mark Harby
Mark Harby

We never supported this from the start.

You can't be expected to support a technology that Microsoft have discontinued.

15 May, 2014
Crono
Crono

Right now I am using 4.0 client profile for a Winform application. Are you saying I must target full 4.0 if I'm to use DX 14.1?

15 May, 2014
Josh Einstein
Josh Einstein

This is all well and good as long as you still pay attention to which assemblies you are referencing and don't do something crazy like take a dependency on System.Web in a client application that uses HTML formatting in an editor for example.

15 May, 2014
Chris R Moore
Chris R Moore

It cost me more in time to support it than I gained from smaller download sizes so no loss to me. Far higher priorities elsewhere.

17 May, 2014
Andreas Grabmüller
Andreas Grabmüller

Currently I'm using 4.0 Client Profile, but I don't have much of a problem of changing to Full Profile. It's just a question of changing the installers to install different prerequisites.

I believe the point where I can stop supporting Windows XP with new versions will come soon anyway, and at that point I will update to 4.5 anyway.

17 May, 2014
Crono
Crono

What exact challenges are you facing with supporting client profile? What core assembly functionality do you require so badly for your controls to work?

30 May, 2014
Julian Bucknall (DevExpress)
Julian Bucknall (DevExpress)

Crono: if I recall, the biggest issue was System.Web. It had some classes that we wanted to use in WinForms and WPF. We had to (basically) clone those classes in a separate assembly for those customers using the Client Profile. Since Microsoft have removed Client Profile from .NET 4.5, it makes sense for us to also clean up our packages by removing these "sketchy" clone assemblies (and the testing and resources that they require to be maintained, etc).

Cheers, Julian

30 May, 2014
Crono
Crono

I thought your WPF code was shared with Silverlight's? Won't using System.Web for Silverlight runtime be a problem?

2 June, 2014

Please login or register to post comments.