Joy of Setup

There’ve been a couple of reports that WiX v3.0.4123 doesn’t include mergemod.dll. That’s unfortunate because it’s a really annoying bug and worse, I was the last one to touch mergemod.dll (to fix 1965131) so it was probably my fault.

I couldn’t reproduce the problem, however; mergemod.dll was present in Wix3.msi, Wix3_x64.msi, and wix3-binaries.zip. I was about to ask for install logs to investigate when a likely cause occurred to me. The bug fix was to revert from a version of mergemod.dll with a bug to a prior one that doesn’t have the bug. Unfortunately, downgrading files is problematic with major upgrades: Windows Installer wants very much to keep higher-versioned files around. After all, the latest version probably has all the latest bug fixes, right?

If you install WiX v3.0.4123 over v3.0.4116, the log will contain a line like this:

MSI (c) (34:D4) [10:47:26:734]: Disallowing installation of component: {AAF02F71-9684-4F4F-8EEA-FC99A61EAA9A} since the same component with higher versioned keyfile exists

Simple workaround: Uninstall the earlier version of WiX, then install v3.0.4123.

The WiX installer had a bug that I noticed during our transition from Visual Studio 2005 to Visual Studio 2008. If you had the Votive feature installed for VS2005 and VS2008, then uninstalled VS2005, the Votive feature was "orphaned" and couldn’t be uninstalled. The cause is that the Votive features are enabled only when the corresponding version of Visual Studio is installed. (The Feature/@Level attribute is 0 with a Condition child element to enable it.) MSI sees the feature as disabled in maintenance mode and won’t remove it.

Oops.

The solution is easy, though: Add OR REMOVE to the condition that enables the feature. That ensures the feature is enabled during whole-product uninstall or an attempt to remove that particular feature.

VirtualBox, the desktop virtualization product acquired by Sun Microsystems in February, shipped version 1.6.0 on Friday. I previously mentioned VirtualBox in my blog post on setup testing with virtual machines. I lauded their clean setup and low custom-action count.

Unfortunately, the latest version hasn’t kept up that standard of Setup Goodness™.

The x64 package isn’t marked with the x64 platform template. I suspect that was intentional, as it allows the package to be opened and then canceled with a more friendly error message than the stock message Windows Installer provides. Nonetheless, it throws a bunch of ICE errors because MSI treats the package as 32-bit.

They also added a custom action: ActionRemoveDataFiles. Nothing to get too worked up about, but it’s like they tried to cram into one CA all the possible wrong things you can do with CAs:

1. It’s VBScript. Evil. One day after release, a user started a thread on the VirtualBox support forum about getting a 2738 error on Windows Vista.
2. It’s an immediate CA that modifies machine state.
3. As an immediate CA, it runs impersonating the installing user, so attempts to delete files outside that user’s profile will fail unless the user started the setup as an administrator.
4. It doesn’t have a “matching” rollback CA to undo what it does.
5. It tries to “clean up” user data — including the virtual machine and disk configuration.
6. It tries to clean up all users’ data, even those who aren’t logged in. That’s going to fail for roaming profiles, because the MSI server doesn’t have permissions to the remote data.
7. It’s scheduled in InstallExecuteSequence but shows message boxes to prompt the user for permission to clean up files. CAs scheduled in InstallExecuteSequence should never show UI; all UI should be handled via CAs scheduled in InstallUISequence or via dialog boxes in the Back/Next wizard sequence.
8. The CA’s condition in InstallExecuteSequence uses “UILevel>2″ presumably so the message boxes are shown when the user uninstalls VirtualBox from Add/Remove Programs (Programs and Features on Vista). Unfortunately, it violates the contract MSI provides for “basic UI” mode. Using the /qb or /passive switches is commonly used in automated installations to show modeless progress UI without ever showing a modal prompt. ActionRemoveDataFiles will show modal UI during any uninstall other than with the /silent or /qn switches.
   To be fair, the shell folks who designed ARP and the MSI folks are partially responsible: They didn’t provide a UI level that says “I’m uninstalling interactively from ARP, so it’s OK to show some modal UI.”

Worst of all: This particular custom action makes it way too easy to delete gigabytes of virtual machine configuration and drives with no more than an accidental Yes button click. <shudder/>

Raymond Chen, famous Windows shell ninja, suggests today in his blog that the “action” button in a setup wizard, should be labeled Next instead of Finish. While I wholeheartedly agree that Finish is a bad label for the button that kicks off the actual installation process, Next has its own problems. In WixUI, each installation action gets its own label: Install, Change, Remove, Repair. Buttons labeled Next are reserved for pages that lead to more options.

Raymond can undoubtedly call upon legions of minions to punish me for my heresy, but I think the current WixUI model is better because it’s more explicit. And it means you can “page surf” to your heart’s content as long as you see Back and Next buttons.

Google announced the release of Google Earth 4.3 today. Given the recent release of their WiX-based setup for the Google App Engine SDK, I had to give it a shot. (It helps that my day job also deals with 3-D terrain imagery.)

When you click the link to “Download Google Earth 4.3” (and accept the EULA), you download not Google Earth but “Google Updater.exe.” Run it and it starts downloading the Google Earth installer.

Personally, I much prefer to download the actual installers for the software I use. Some of it’s purely practical: I can stick it on a network and put it on multiple computers (EULA permitting, of course) without waiting for multiple downloads. Perhaps more importantly, for the paranoid among us, is the ability to virus-scan the installers. (Google Updater requests elevation, so it has admin rights to install multiple packages.)

Google Updater also runs as a startup app, optionally showing an icon in the increasingly-unusable system tray. (Yes, I know it’s technically the “notification area,” but come on, who calls it that?) I don’t think I need 24/7 instant access to software that doesn’t get updated that often. In fact, I’m sure I don’t.

Naturally, installing a packaging system with update capabilities is a boon to many users (and Google itself, of course, which has a nicely visible entry point to suggest additional apps for download). Apple does it with iTunes and Microsoft does it with Windows Live. Luckily, Google Updater has its own entry in Add/Remove Programs so you can remove it without impact to Google Earth.

Google Earth installer

The Google Earth installer is built with InstallShield, using its support for “dynamic file linking.” (If you haven’t used it, think of running Heat or Tallow with every build.) Interestingly, it uses the CAQuietExec custom action from WiX and has wixca.dll in the Binary table.

The .msi package fails ICE validation, with errors in ICE03, ICE15, ICE34, ICE38, ICE43, ICE44, ICE57, ICE64, and ICE99, and warnings in ICE45, ICE60, ICE82, ICE86, and ICE91.

There are 36 custom actions, some of which are mildly disturbing:

• registerFlashSOL is a deferred, no-impersonate custom action that runs an included .exe with a “-install” command-line switch. Oh joy: self-reg.
• InstallToolBarCA is an immediate custom action that runs an installed .exe. It’s not scheduled and is only available from the UI sequence – the one that’s suppressed because Google Updater runs the installation silently.
• SetGEUserStats is another custom action run only from the suppressed – but still included – UI sequence.
• SET_RES_READ_ONLY sets QtExecCmdLine to run the WiX CAQuietExec custom action. What is it hiding? It’s running attrib.exe to turn off the read-only attribute on a recursive set of files/directories. Doesn’t the File table let you control the read-only attribute? Yes, it does, but apparently not when you use InstallShield’s dynamic file linking to harvest a directory tree at build time. In a previous life, I used that functionality and turned off the read-only attributes in the build script before harvesting. Doing it as part of installation is bad karma on Google’s part.

Overall, it’s not a bad installer, but I hope Google cleans it up a bit before it loses the “beta” label.