After more learning I think I need to backtrack even further with the WiX toolset and Windows Installer SDK. There are some fundamental decisions my team needs to make about how the product installation will work and it's something that should be decided before the first release. Once that first release is out the door from an installation perspective you're stuck with it.

Why? Uninstallation and upgrading. If a user installs version 14 of the product over version 13 what do you want to happen? Do you want to support patching to reduce upgrade installation sizes? Do you want to be able to gracefully uninstall the product? If so, what files do you want the uninstall to leave behind (ie. user data and application data) and where will they be? Do you want to be able to repair your product with the installer? These factors can affect how the installer is organized and written from day one.

Now's the time to get acquainted with some Windows Installer upgrade terminology. There are different options for updating and patching:

- patching
- small update
- minor upgrade
- major upgrade

Given these options I think I'm only going to support installing, uninstalling and repairing and not any type of upgrading. Updating, upgrading and patching with Windows Installer seems like a lot more work and pain than it's worth at this point. If a user tries to install the product over an older version I can either prompt them to uninstall the older version before they install the newer version or maybe even do it automatically as an installer step. Their user and application data will be preserved, of course.

What finally turned me off updating? Check out Organizing Applications into Components and Changing the Component Code from the SDK. Eww, gross.

To support uninstallation I need to use managed Components with universally unique GUIDs (also called the component code). The uninstaller will use the Component GUIDs to figure out which components (and their resources) to remove, and according to component rules will reference count resources (MSDN seems to recommend having a reference count of no more than one).

Backwards compatibility is something I'm not too concerned about either. Each new version of our product will have resources that are almost certainly not backwards compatible (ie. plugin.xml). This blows version numbers right out the window since they depend on backwards compatibility: "Do not create a version of a component that is incompatible with all previous versions of the component" from Organizing Applications into Components.

To make things really easy, each new version of the product can have new GUIDs for every Component so they aren't confused with old versions. This seems like the easiest way. The good news is that I can almost use tallow to automatically generate new Fragments with Components for each new version so I don't have to maintain the Fragments (and more importantly generate Component GUIDs) by hand. The only problem is that tallow doesn't generate Component GUIDs yet -- and therefore doesn't generate managed components that can be uninstalled -- so I made an RFE for that.

A very important aspect of installers is how they are tested and deployed. As I understand it even if I did support upgrading between file versions, a human tester would have to uninstall and reinstall the product to test daily builds because the daily builds within a version would contain the same Component GUIDs pointing to the same resource paths.

If the tester tried to install today's build over yesterday's build the installer would say: hey, the component GUID didn't change and the keyfile version number didn't change so don't update the component. Yeah, that seems bad for daily testing. I think it's safe to say that graceful upgrading is only between released final versions of the product. And that's all about keeping track of version numbers and Component GUIDs.

It's interesting that some places say the date is a factor in deciding which file to install and this diagram showing how it picks between two versioned files does not. Are dates in or out?

In a future blog post I'll try to go over some of the special issues I'm having creating a Windows installer with WiX for an Eclipse RCP app. I'm especially curious if a plugin's build.properties and plugin.xml files have enough information to generate a WiX Fragment from them by a tallow-like tool.