Learning WiX is not just about learning the WiX toolset. It appears that in order to use the toolset properly you need to know quite a bit of background of setup on Microsoft Windows in general including the structure of Windows Setup MSI files.

This approach for WiX, while flexible and powerful for developers and setup crews that need it, doesn't help the little guy very much. Third party applications that create MSI setups seem to be too inflexible to do what I want or impractical to insert into an automatic build script.

So in order to make a proper Windows setup you need to put the time into it. The good side-effect of this is that you're more likely to take setup and project deployment seriously, which I get the impression often becomes a project afterthought.

As an aside, my bottom line when it comes to builds is: can I do it in one step?. I shouldn't have to assemble anything "by hand". Without going into a long rant about it the most important aspect of this is consistency of the build process which ultimately contributes to the overall quality of the final product.

A toolset like WiX seems like the perfect toolset to integrate into an automated build process done with another build tool like make or Ant. I'm in a bit of uncharted territory because I'm trying to use WiX with Ant (not NAnt) on Windows to make an MSI installer for an Eclipse Rich Client Platform (RCP) application written in Java and deployed in the way that RCP applications must be deployed. Most of the people I've seen in the blogosphere using WiX are either still using Visual Studio with C++ or have moved on to .NET.

I started with the documentation distributed with Wix and the well-written WiX Tutorial by Gábor DEÁK JAHN. Then I realised a) how much I didn't know about setup on Windows and b) how much this knowledge was required for Wix and was forced to backtrack.

The good news was that the author of WiX, Rob Mensching, has a great blog and has been posting since late 2003. I've been reading the archives from the beginning and they provide a very good starting point for people interested in learning about Microsoft Setup details and some insider background behind it and Wix.

My main stumbling block right now? Resources, components and component rules.

The problem is that project I'm making an installer for is quite large (1500 files, 180 folders). The impression I get is that I'm going to have to manage each file and directory as explicit resources in the WiX .wxs file(s) so that it knows where all of the project files are and how they will be grouped/updated/versioned in their respective components. No wildcards like Ant.

Having done all of that work though, the generated MSI setup file will then not only install and uninstall but also sucessfully install the next version of the product right over an existing one using component GUIDs to track versions of components that have or haven't changed. That's how I understand it so far.

An interesting side effect of the one component to one directory guideline is that things get simpler component-wise if your directory structure is shallow. I don't have much control over directories because a large portion of the files and directories (1000 files and 100 directories) I'm packaging are coming either from the Eclipse project or are part of Sun's Java Runtime Environment (JRE) redestributable.

You might say "have you heard of tallow?". Yup, it produces a nice <Fragment> with 1500 <File>, 180 <Directory> and 180 <Component> tags in it.

The file generated from tallow is a good starting point but from what I understand I have to go into the generated file and give each Component a proper GUID so that its files can be properly uninstalled and I have to manage these GUIDs from product version to version, updating them when needed. For example, if I add a file to a directory the component has changed and it requires a new GUID. This is the distinction between managed and unmanaged Components. I can't see much use for the raw unmanaged Components generated by tallow in an installer if you want uninstall. What good is an installer if you can't uninstall?

I could definitely be way off base on my understanding of it but that seems like a lot of leg work -- not only for a setup engineer but also for individual developers if they are expected to update the WiX .wxs file if they add, remove or change files. The developer would also have to worry about the Component GUIDs if they make changes.

Once I generate that initial tallow file, that's it. From then on I have to manage that massive <Fragment> by hand without tallow's help. I can't use tallow again because it only generates unmanaged Components and I would have to reinsert all of the GUIDs again.

There could also be interesting installer problems if a file in a Component changes but someone doesn't change the Component's GUID in the Wix file. If that happens as far as Microsoft Setup is concerned, the Component didn't change and it won't be updated during the install. That seems to be a quality problem related to deployment waiting to happen.

If this is the case it seems like some sort of source control software (ie. CVS, Subversion) and WiX integration could be nice. The source control system could tell a WiX tool like tallow that a file in a certain Component had been added, removed or updated since the last release and the tool would automatically generate a new GUID for that Component for the next build.

At any rate it's good to know all of this background information just like it was good to know Ant really well. My practise with Ant on AudioMan really paid off and practise with WiX could pay off just as well in the long run.