Day: March 8, 2008

Adding UI to Add Remove Programs Uninstall

As part of our uninstall flow, we want to give the user the option to manually save any of their user generated data before our uninstaller deletes it. Giving all users on the computer, not just the uninstalling user, this option, is a completely separate bag of worms that I’ll address in a later post.

Unfortunately, Windows launches uninstall in minimum UI mode when run from Add/Remove program files. This meens that as fancy and elegant as my underlying UI is on uninstall …. You’re not gonna see it when launched from Add remove programs. After going down a few false positive routes

– Changing the uninstallstring in the registry from /X to /I (windows ignores this)

The Rube solution was to

  • Hide the repair option from ARP

  • Enable the change option from ARP.
  • Modify my installer UI so that control elements displayed would be dependent on whether installing, repairing, or uninstalling

Installed

Wix bootstrapper setup.exe

As part of an effort to address several edgy installer and deployment requirements, I finally decided to wrap our installer .msi in a setup.exe. Previous deployments required our users to download a setup.exe which would download, and launch a second .msi. Being constrained by the wix toolset, and not having the luxury of install shield or another setup application made this a non-trivial task.

Our bootstrapper requirements were fairly straight forward and consistent with any other …

– Extract the internal msi

– Launch the external msi with maximum allowed privileges. If running as admin, install per / machine, else install per/user. This allows us to get around some of the Vista UAC nonsense in determining whether the installer is running as admin or not.

– Launch upgrade path REINSTALLMODE=vomus if the application was previously installed and running setup.exe.

There’s several bootstrapper stubs out there and available on the internet, some even containing code, but none of them seemed to do the job. Our Rube Goldberg solution ….

Use the wix 3.0 setupbld.exe tool along with the wix default default setup.exe stub.

Setupbld.exe is a nice tool that is part of wix 3.0 that beautifully wraps an msi with any setup.exe stub. The setup.exe stub that is bundled with wix 3.0 fulfills the above installer requirements that we have, so there was no need to even write our own stub. The only problem a person may have with this approach is not functional, but rather cosmetic. The generated setup.exe bootstrapper contains the resource information from the stub. Ie. You’re stuck with the generic icon as well as version information contained in the stub. One work around for this (that’s tough to automate in a build system) is to manually crack open the stub.exe in visual studio (simply file open) and change the resource information to that which you prefer.

So … our process ….

1. Autobuild generates the binaries

2. Autobuild builds the installer msi wrapping these binaries

3. Autobuild wraps the msi into a setup.exe

a. setupbld -out Setup.exe –mpsu setup.msi -setup setup.exe -title “Product Setup”

If we had wanted to inject our own branding into the build, we could update the setup.exe bundled with wix 3.0 with our own branding / version information.