WiX FileGroup element considered evil

My previous post details a method to use WiX and NAnt to automatically generate MSI's as part of an automated build. I'm going to recommend that no one follow the part of that example that auto-generates the WiX XML. I'm going to blame my spam filter. Let me explain...

A while ago I subscribed to the WiX mailing list. Unfortunately my spam filter was routing all posts to my junk folder so I wasn't reading them. If I had been reading them I would have noticed a lively debate on the use of the <FileGroup> element and how it is generally considered to be evil-incarnate. So much so that Rob Mensching is talking about removing it from WiX altogether so no one is tempted to misuse it.

FileGroup makes it far too easy to violate Windows Installer Component Rules. The SourceForge WiX mailing lists are not archived yet, but there will be detailed explanations of why its dangerous in posts found in the wix-users list soon.

Once you have defined a component (a set of files), the Component ID (which is a GUID) must not change unless the contents of the component changes. The technique I laid out generated new Component IDs every single build.

The current direction members of the WiX list seem to be leaning involves having a tool to initially generate the WiX XML fragments, checking them in to your source control, and then hand-maintaining them as changes are needed. Although auto-generating each time is handy from a developer perspective because new files are magically picked up, it is a nightmare when it comes to installing upgrades.

3 Comments

  • I'm not a Windows Installer guru in any way shape or form, but I have begun testing the addition of WiX and your Auto-gen MSI procedures into our build environment. If I understand correctly, the problem with the auto-gen is generate-install-script.js uses &lt;FileGroup filter=&quot;*.*&quot; ... /&gt; rather than &lt;File /&gt; elements? If that is true, then why wouldn't I modify the getDirTree js method to explicitly include the files needed?

  • The actual problem is that Component IDs have to be associated with a particular version of a component. If the component has not changed since the last time you ran install-script.js, it should not get a new GUID.

  • Hmm. Hmm - seems like if this was wrapped in a task or target in MSBuild, the input/output dependency checking would handle this situation. That is, input/output parameters of the component(s) and MSI, Wixobj, etc for an MSBuild target/task would allow you to always generate a new GUID. Hmm, maybe not. Then a new GUID would be created for ALL components even though only one changed. Dag-nabbit...



    Would you say that this issue is resolved if Upgrades aren't supported, but instead uninstalls are performed each time prior to installation?

Comments have been disabled for this content.