If you’re building something like a .NET WPF client application then one of the major bugbears (for both you and for Microsoft – let’s be honest here :-)) is trying to get the .NET Framework on to the client machine.

We’re trying to make this easier but if you were to look at the recent .NET Framework packages you’d perhaps not be able to tell that 🙂

They seem to have mushroomed up to approximately 230MB in the case where you want to get a package that will install a framework like 3.5 or 3.5 Service Pack 1 without a network connection.

In some ways, that’s the salient point. If you do have a network connection then it’s not quite so bad because you run an online installer which takes a look at your machine, determines things like x86/x64 and then downloads the right bits for your machine and gets out of the way. That tends to feel like 60MB rather than 230MB which is a significant saving.

For me, at my download speeds I get 5Mbps so 0.5MBytesPerSecond and hence 30MB == 1 minute, 60 MB == 2 minutes and 230MB equals around 8 minutes which is a long time to wait.

Naturally, the download time is not the entire installation time so there’s a bunch more waiting to do and possibly even a reboot to sit through.

As a developer it’s pretty easy to move a single machine to .NET Framework V3.5 Service Pack 1 but it’s not so easy to do that on behalf of your users. Straight off you’re going to need those client machines to be on either;

• Windows XP Service Pack 2+
• Windows Vista RTM+

and I guess that you have a few choices depending on who your users are;

1. Some kind of unattended admin installation scheduled by an IT admin type using whatever infrastructure you have in place to push out updates in a managed environment.
2. Some kind of physical installation where you give someone a CD or a DVD or a memory stick and they run the installer from there.
3. Some kind of online download.

(1) isn’t perhaps as much of a worry as (2) and (3). Generally, the IT admin crew will have a route for pushing out software updates and .NET Framework V3.5 Service Pack 1 becomes one of them. Windows Update can help when Framework 3.5 Sp1 shows up there.

Now, whether they’ll actually do that on behalf of a specific application is another matter as they may worry about breaking existing applications. That’s another story.

For (2) it’s not so bad in that you can copy the 230MB redistributable of the .NET Framework V3.5 Sp1 onto your CD or DVD and then run it as part of your installation.

For (3), it’s not great. Asking a user to wait for up to 10 minutes whilst you download a 60MB framework to support an application that (given it’s MSIL) might only be a few KB in size is a tall order. It’s also a tall order to get them to run the installation as Administrator and to reboot the machine in order to complete the installation.

Along comes the .NET Framework Client Profile as part of .NET Framework V3.5 Sp1 with Visual Studio 2008 Sp1 and it’s intended to help with some of these situations.

Before I start going on about it here’s some links I’ve already used to learn some things about it;

• Troy Martez’s blog post on the Client Profile
• The Deployment Guide
• Sketched list of what’s in the Client Profile
• Jaime Rodriguez’s post on the Client Profile
• The Download of the Client Profile online bootstrapper
• The Download of the Client Profile offline installer

also – please note, take some of this with a pinch of salt as I’ve been experimenting with this today and I am by no means “Mr Setup Guy” so this is all a bit “rough” and might contain even more errors than usual 🙂

Some basic facts ( in as far as I’ve been able to work them out ) about the Client Profile;

1. It comes packaged as an online bootstrapper and an offline installer.
2. The online bootstrapper is small ( ~270KB I think ).
3. The offline installer is big ( ~250MB )
4. Both installers;
   1. Offer customisable UI and control flow to some extent.
   2. If the machine has no .NET Framework already installed ( i.e. must be XP by definition )
      1. Installs the .NET Client Profile ( approx 30MB of Framework subset ) without a reboot ( AFAICT ) but still requiring Admin privileges.
      2. Schedules an installation of the full .NET Framework V3.5 Sp1 via Windows Update at a later point ( or will do in the future, right now V3.5 Sp1 isn’t on Windows Update AFAIK )
   3. If the machine already has a .NET Framework installed then installs the full .NET Framework V3.5 Sp1 requiring reboot and Admin privileges.

You can mark an application in Visual Studio as “targeting .NET Client Profile” and that means that a line goes into the configuration file saying “This application will run on the client profile”.

Without that line in the config file, an application on a Client Profile machine will get an error message asking the user to go to http://www.microsoft.com/downloads and install .NET Framework V3.5 Sp1. This seems a bit clunky to me but it’s only likely to happen in the “time window” between steps 4.2.1 and 4.2.2 above so maybe it’s not the end of the world.

I wanted to get started with this so I set myself up with a Virtual PC running Windows XP Service Pack 3 and I made sure it had Undo Disks switched on so that I could keep throwing any installations of the Framework away.

I built a “Hello World” style WPF application. The only “odd” things about it were that I selected this option on my Application tab;

and that was about it. With that in place I threw a quick Setup project into my project with the only usual thing about that being that I selected a different pre-requisite for the project;

and then one other crucial thing that I threw in. By default, when I add my Primary Output of my application to my setup project Visual Studio then goes and detects dependencies for the output as in;

So, it detects that I have a dependency on the .NET Framework. That’s fine but detected dependencies can be hard to get rid of plus the setup project also adds a Launch Condition to check for the .NET Framework. Now, VS won’t let me delete the Launch Condition whilst the dependency is there and it doesn’t make it easy to get rid of the dependency so I got a bit stuck for a while.

The trick is to change the Launch Condition so that it checks for the right version of the Framework, that is;

Then I built and that gives me a setup.exe and an msi file. I copied them to my Virtual PC and ran setup.exe;

and then that went off and the next dialog is;

which seems to account for a bunch of downloading along with a bunch of installing ( well, the download looks to happen first 🙂 ) and then the application installation runs;

and my application actually runs.

Now, if I’d wanted to not use the online bootstrapper for the application but had wanted to, instead, use the offline installer for the .NET Framework Client Profile then what I need to do is to ensure that in my folder;

c:\program files\Microsoft SDKs\Windows\v6.0a\Bootstrapper\Packages\DotNetFx35Client

I have actually got the full offline installer which is called DotNetFx35ClientSetup.exe and comes in at approximately 250MB.

If I do have that in there then I can switch my option in Visual Studio to not download from the vendor’s website and then we don’t need the bootstrapper or the download process;

And then I’ve got approximately 250MB of installation bits which will cause the Client Profile to be installed without any additional downloading ( e.g. if I’m putting this onto a fileshare or a DVD or something ).

So far…so good. Where I’d like to go next with this;

1. How’d you get this to work with a ClickOnce application?
2. How’d you customise the installation experience?