If your product consists of a large number of files and the file set changes regularly – files being added and removed during the product lifetime – it’s only natural to want to avoid the cost of hand-authoring setup changes to match. (A little over a year ago, I shipped a product with over 7000 files, so I’m familiar with the pain and desire for automation.)

Unfortunately, our frenemy the component rules makes such automation difficult. The closest we-the-WiX-team has gotten to a complete solution is to create components with one file each, which makes the component eligible to have its component GUID automatically generated (using an asterisk in the Component element’s Guid attribute value).

What doesn’t work is when files are removed. Windows Installer doesn’t let you remove components in a minor upgrade, so using one file per component doesn’t immediately solve the automation problem: Your automatically-generated minor upgrade will be missing a component, which is a mortal component-rule sin.

Nor can you avoid the problem by using multiple files per component because component rules say that components must be immutable: You can’t add or remove resources from a component.

So automating the creation of minor upgrades has additional costs:

• Additional tooling to try to support removing files without blatantly violating component rules.
• Additional coding in your product to tolerate “obsolete” files without being able to remove them.

For many types of apps, but especially Web apps with many content files, that’s a huge cost. Being able to ship minor-upgrade patches from an automated build might be a benefit worth the cost. It’s really a decision your team needs to make.

I’ll add that if you don’t anticipate shipping patches on a regular schedule, you might just automate the authoring of your RTM product and pay the price of manually tweaking your setup authoring when you need to ship a patch. Again, it’s a cost-benefit decision your team needs to think about.

Cheap and easy

If you don’t absolutely need to ship patches, you can avoid the costs of minor upgrades by simply using major upgrades. You can remove files without worrying about component-rule violations if you use an “early” scheduling of the RemoveExistingProducts standard action – before or immediately after the InstallInitialize action.

The MSI SDK notes that scheduling RemoveExistingProducts early is “inefficient” because the files that are same between the two product versions are removed and then reinstalled. But that inefficiency is what lets you remove files and components. If you schedule RemoveExistingProducts immediately before or after InstallFinalize, MSI implements the major upgrade by installing the new version of the product “on top of” the previous version, upgrading files with newer versions, then removing the previous version. MSI increments the reference count of components in both packages during the installation of the newer version, then decrements it during the removal of the previous version. Component reference counting works only if component rules are followed, so it’s pretty much the same as minor upgrades.

If you have a large product, the size and install-time benefits of minor upgrade patches might be worth the development effort. Otherwise, major upgrades scheduled early are a great solution. Your call.

‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone,’ it means just what I choose it to mean, neither more nor less.’

‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’

‘The question is,’ said Humpty Dumpty, ‘which is to be master – that’s all.’

–Alice’s Adventures in Wonderland and brought to mind by almost anybody reading SDK documentation for any length of time

Windows Installer has three ways of upgrading products from one version to another:

• Major upgrades
• Minor upgrades
• Small updates

There are two common problems we run into when discussing upgrades given size-related terms to describe upgrades.

Version numbers

Major and minor are also commonly used to refer to particular elements in a version number (major.minor.build.patchlevel being most common).

But major upgrades can upgrade any product version number to any other version number, regardless of which parts of the version number change. For example, the WiX installers are always major upgrades for every 3.0.xxxx version; only the build portion of the version number changes with each weekly build. And the WiX v3.0 installers don’t do major upgrades down to WiX v2; we intentionally designed the installers to be able to live "side-by-side" on the same system to help migrating from WiX v2 to v3.

Minor upgrades, on the other hand, are usually used to deliver service packs; they must change some part of the product version but can’t change the major part of the product version (at least according to PatchWiz.dll error ERROR_PCW_INVALID_MAJOR_VERSION).

Small updates cannot change the product version at all.

Size matters not

Major, minor, and small also bring to mind size or breadth of a particular upgrade. To an extent, that’s true: Small updates tend to be for single-purpose "hotfix" types of fixes. Minor upgrades can update many files but can make only limited "structural" changes such as adding features and components; they can’t be used to remove components.

Major upgrades aren’t so limited: They can change anything in a product, but also support as few changes as a small update. So even if you’re changing only a few files, you can still use major upgrades. Think of major as an upper limit on the set of changes, not the lower limit on the type of upgrade you need.

Major upgrades also have the advantage of built-in support in Windows Installer. Using Upgrade and UpgradeVersion elements, you can use a "naked" .msi package to install a product for the first time or by major-upgrading a prior version of the product. Doing the same thing with a minor upgrade requires a bootstrapper executable or extra work to set the REINSTALL and REINSTALLMODE properties appropriately.

Note that FindRelatedProducts and MsiEnumRelatedProducts explicitly support finding multiple products installed on the system simultaneously. MSI doesn’t try to force you to use the same upgrade code only for products that are upgraded by major upgrades. That means it’s possible to use the same upgrade code for products that aren’t major upgrades for each other.

However, the Upgrade table supports only version and language as ways of narrowing down the products it finds. So if you use the same upgrade code for multiple products that can be installed simultaneously, FindRelatedProducts doesn’t have a way to filter out the ones you don’t want removed in a major upgrade.

You can use a custom action to remove product codes from the property specified by the UpgradeVersion/@Property attribute. Just schedule it to run after FindRelatedProducts. The cost is that you have to maintain by hand any such product codes and carry them from version to version.

The Upgrade table and FindRelatedProducts action let you search on multiple upgrade codes in a single product. So it’s always safe to use more upgrade codes if you think you might support having products side-by-side in the future — just use multiple Upgrade elements to detect and uninstall them via major upgrade.

In short, if you have products are never going to be installed at the same time, you can safely use the same upgrade code. But if you have products that might need to be installed simultaneously, give them separate upgrade codes. (Upgrade code GUIDs are cheap when you buy them in quantity from reputable online retailers.) And always test your servicing strategy before you release a product: Some things can’t be fixed in a patch.

1. The Google Chrome download is a svelte 474K bootstrapper that downloads the setup bits. No offline installer is available (unless it’s well-hidden).
2. Google Chrome is a "composite" setup: The guts of the application are installed by a non-MSI self-extractor. However, Google Chrome includes Google Gears, the browser add-in/library that adds a bunch of functionality for making apps-in-the-browser more powerful. The Gears in Google Chrome is installed by an MSI package. And yes, it’s built with WiX.
3. The Google Updater is no longer a LocalSystem service; instead, it starts at logon from the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key.
4. Last and absolutely not least: Google Chrome is a per-user application. It even installs in the per-user LocalAppDataFolder. (The included Google Gears is marked as "UAC compliant.")

That Google Chrome is a per-user app is amazing. Even with UAC on Windows Vista and Windows Server 2008, it’s so easy to say that "everyone’s used to needing admin privileges to install." That Google took the extra effort to limit themselves to the capabilities of a per-user app says a lot about their desire to have:

• a low-impact setup
• and absolutely no barriers to entry.

I wonder if it’s the start of a trend…

1. Provide rollback custom actions that "undo" what the deferred CAs do so that the installation transaction is actually transactional.
2. Test.
3. Test.
4. Test.

OK, so numbers 2 through 4 are kinda the same but not really: Even a simple installation (say, without patching or upgrades) has three different scenarios you need to test when you have deferred/rollback custom actions:

1. Installation rollback.
2. Repair rollback.
3. Uninstallation rollback.
4. All of the above.

The right behavior for each kind of rollback is usually the opposite action. Rolling back installation is uninstallation. Rolling back uninstallation is installation. Rolling back repair is usually installation. Mixing installation, repair, and uninstallation is possible if your package has user-selectable features and users go into maintenance mode to turn on and off features. And, of course, it’s always an option from the msiexec.exe command line using the ADDLOCAL/ADDSOURCE/ADDDEFAULT, REMOVE, and REINSTALL properties.

Testing rollback means testing failure

Windows Installer initiates rollback when an action fails, so to test rollback you need to cause a failure. WiX includes an easy way to trigger failure: The WixFailWhenDeferred custom action, part of WixUtilExtension, triggers a failure when it’s executed. Include it in your package by referencing WixUtilExtension (in your Votive .wixproj or via the -ext switch to the light.exe command line) and adding a CustomActionRef to your package authoring:

<CustomActionRef Id="WixFailWhenDeferred" />

WixFailWhenDeferred automatically schedules itself in InstallExecuteSequence before InstallFinalize, with a condition of:

WIXFAILWHENDEFERRED=1

The condition means that you can have one package to test all the different possible combinations of "normal" installation and rollback. Just pass the WIXFAILWHENDEFERRED=1 property value on the msiexec.exe command line to trigger rollback. For example:

msiexec /qb- /i intermediate.msi /L*vx installfail.log WIXFAILWHENDEFERRED=1
msiexec /qb- /i intermediate.msi /L*vx install.log
msiexec /qb- /fvamus intermediate.msi /L*vx repairfail.log WIXFAILWHENDEFERRED=1
msiexec /qb- /fvamus intermediate.msi /L*vx repair.log
msiexec /qb- /x intermediate.msi /L*vx uninstallfail.log WIXFAILWHENDEFERRED=1
msiexec /qb- /x intermediate.msi /L*vx uninstall.log

WixFailWhenDeferred has been in WiX v3 weekly releases since April.

VirtualBox 1.6.2 dropped that custom action. The VirtualBox installers still have a few ICE errors and warnings so here’s hoping the VirtualBox team continues cleaning those up.

StyleCop is a Visual Studio package that integrates analysis commands in the Solution Explorer and a tool window to show analysis results. StyleCop also includes MSBuild tasks so you can make analysis runs part of your daily builds.

Naturally, the Style…dammit…Microsoft Source Analysis for C# installer is authored in WiX. The package is extremely clean. There are no ICE errors and only ICE33 warnings about non-advertised COM registration. The only custom actions come from WixUIExtension and WixVSExtension. The UI is built with WixUI, though the StyleCop team chose to use some logo-themed white bitmaps rather than the classic-yet-modern red.

The first few times you run StyleCop on existing code, you’re bound to be surprised and probably frustrated. The rules are, after all, about enforcing a consistent coding style. Unless you happen to already be using the StyleCop style, you’ll get a lot of “violations” that seem quite arbitrary. Yep, and that’s the point: Coding style discussions are pretty much religious wars over arbitrary decisions. (Yes, there are exceptions, but mostly it’s personal esthetic choice. Except for tabs versus spaces; don’t mess with tabs versus spaces!)

Just stick with StyleCop style and you’ll be consistent, even if elements of the style aren’t your personal favorite.

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.

Most of the principles of the agile manifesto reinforce the idea that shipping software often is how to best deliver customer value. To ship often, you need predictability:

• Finish all the work associated with a feature.
• Make sure it’s of ship quality.

Done versus done-done

The waterfall model of designing, then coding, then throwing over the wall to test, then fixing bugs, then throwing over the other wall to setup–yes, of course I’m going to talk about setup–is just procrastinating. Sure, it’s more fun to start working on the next new thing, but it’s just postponing the work required to get a feature really done and ready to ship.

Setup development, like testing, is often considered one of the “taxes” of software development that is best put off as long as possible. But if you want to deliver shippable software on a rapid schedule, paying taxes late doesn’t work; you might get to April 15th and discover that you have more bugs than you can fix by midnight. Instead, you pay your taxes as you go along so there are no surprises when you get to the last day and you want to ship.

Rather than developers considering themselves “done” when they’ve written some code and debugged it, developers need to get “done done” by providing code, unit tests, acceptance tests, and setup.

WiX supports “done done” by easily integrating into the development build cycle. Every member of an agile team can author setup. That prevents the lone setup developer, who probably supports multiple product teams, from being a bottleneck.

Plus, if developers are responsible for their own setup authoring, they’re less likely to push bad design decisions onto the setup developer’s shoulders.

Keep quality high and take the weekends off

Agile methodologies bring a whole set of tools and processes to help keep quality high and ready to “ship on a dime,” like:

• Test-driven development to produce high-quality designs and code
• Automated acceptance testing to reduce the need for armies of testers to validate the whole system at the end

Add some setup flavor:

• Make sure that “done” for every feature includes its setup authoring.
• Run your automated acceptance tests from official setup packages, not from local builds.
• Build upgrades and patches and create automated tests to ensure you can service the product.
• Use only fully declarative custom actions–they make it easier to handle patching, upgrades, and repair.

Frequent, automated testing tells you if your code (and setup) do what they’re supposed to (or not–at least as far as the tests are concerned). Adding setup into the testing mix helps ensure that your setup is ready too.

One way to get consistent machine states is with imaging software: Take an image of the machine in a particular state using software like Acronis True Image and restore the image before you begin each test. The downside to machine images is the time needed to restore an image; a bare operating system image might be only a couple of gigabytes for a svelte Windows XP image but your setup or app might have other prerequisites that balloon the image size. For example, my testing for Flight Simulator X Service Pack 1 and Flight Simulator X: Acceleration both require an installation of Flight Simulator X, all 13GB and 42,000 files worth. Such an image takes about 20 minutes to restore, not counting the reboots and loading the imaging software: Call it a good half an hour. With that overhead, I avoid re-imaging between install tests; the overhead’s not worth it. And surely I never author any bad setup or make even the slightest bug in my deferred custom actions, much less the rollback custom actions. Oh wait…

But virtual machines have significantly less overhead. Instead of re-imaging, you shut down the VM and discard changes made during the test session. Then restart the VM to start clean: The only overhead is the time it takes the VM to “power on” and boot. Most VM software lets you create snapshots to record the state of the VM at key points. You can also create new VMs as clones or deltas of other VMs, to save the time of installing OSes over and over.

There are two potential drawbacks to cloning VMs:

1. Don’t forget your OS licensing.
2. If you need to join your VMs to a network domain, you’ll have to use a tool like SysPrep or NewSID to join cloned VMs to the domain.

Of course, both those things are true with hardware machine images too. I avoid the problem by not joining VMs to domains. Most VM software offers other ways of getting test files to VMs, like shared folders that simulate a network share to the host computer or drag-and-drop.

VMs aren’t as fast as real hardware but unless you have a huge setup or want to investigate timing-related issues, it’s rarely a serious problem. Though it gives you a great excuse for a powerful dev box: A quad-core CPU with 4GB RAM and RAID 0 storage works really well.<g> Fewer cores, less RAM, and non-RAID disks work too, of course, depending on how many simultaneous VMs you want to run.

VM software

Here’s a list of the VM software I’ve used.

• Virtual PC, Microsoft’s desktop VM product. Free (as in beer). Easy to use, OK GUI. Biggest cons: It’s a single-threaded app, so multiple VMs don’t take advantage of multi-core CPUs and it has no automation API.
• Virtual Server, Microsoft’s current server VM product. Free (as in beer). Multi-threaded with COM API. Biggest con: In the box, there’s only a Web administrative interface. VMRCplus, an unsupported WinForms UI, is available and while it has some rough edges, it’s a big improvement.
• VMware Workstation, VMware’s desktop VM product. $189. Great multi-process GUI with automation APIs. Hardware support improves with each version; the current version, 6.0, supports USB 2.0. The only drawback is that because it’s not free software (beer or speech), you need to make sure you’re in compliance with license if you want to use it on multiple machines.
• VirtualBox, innotek’s VM product. Free (beer and speech). VirtualBox comes in a closed-source edition that’s free of charge and a subset is available under the GPL. Multi-process and nicely automatable, via command line and XML configuration files. There’s a separate API that isn’t yet documented. The biggest downside is that virtual machines, hard drives, and CD/DVD images have to be registered so it’s slightly more complicated than the others to copy VMs among host machines. Secret setup geek benefit: The closed-source edition of VirtualBox comes with an installer — authored in WiX — that’s amazingly clean; it doesn’t quite pass validation but it’s very light on black-box custom actions.

Using machine images is vital if your setup requires particular hardware or if your app does and you need to test both the setup and the app. Otherwise, save yourself headaches, hassles, and horked dev machines and test your setups in virtual machines.