Change my component GUID in wix?

Question

When should I change or not change my component GUID in WIX? The Microsoft SDK information is confusing.

Glytzhkof edit: To clarify, the question deals with when a component GUID should be changed for an MSI component. A component can change with aspects such as: changed destination path, addition or removal of files to/from the same component, addition of registry data etc... This causes problems with regards to the so called component referencing, i.e the best practice for creating components in MSI.

Answer 1

The overall concept of MSI is that there is a 1:1 mapping between a component GUID (unique identifier) and an absolute path (install location / key path). The full path, including file name if any. See update below for a new Wix feature to deal auto-magically with this.

I use some simple rules to deal with the overly complex and nonsensical component rules:

• Always use a separate component per file (even for non-binaries). This avoids all kinds of problems. There are a few exceptions:
  • Multi-file .NET assemblies should all be in one component since they should always be installed / uninstalled as a single unit.
  • A few other, general file types come in "matching pairs" - they belong together. Often these are content and index files. As an example consider Microsoft help files:
    • .HLP and .CNT files belong together.
    • .CHM and .CHI files belong together.
  • There are likely several such file types that belong together and should hence be put in the same component so they install/uninstall together - I suspect certain certificate files to be candidates. It is hard to come up with a definite list. Simply ask yourself "do these files always belong together" - so they always show up in pairs whenever there is a new version? If yes, then install them via the same component. Set the versioned file, if any, as key file.
  • I want to add driver files as an example of a bunch of files always belonging together: SampleDriver.cat, SampleDriver.inf, SampleDriver.sys, SampleDriver.cer. They must all match as a "unit" for deployment.
• Remember that once you have allocated a GUID for a component, it's set in stone for that component's key path (absolute path). If you move the file to a new location or rename the file, give it a new component GUID (since the absolute path is different it's effectively a new identity).
• In summary component GUIDs are tied to an absolute installation location, and not to a specific file. The GUID doesn't follow the file around if it moves. The GUID reference counts an absolute location, not the file per se.
• Do not add or remove files from an existing component. All sorts of upgrade and patching problems result. This is why I like one file per component as a general rule.
• There is a lot more to component referencing, but I will leave it at that for an "overview".

Some samples:

• You rename the file C:\Program Files\MyCompany\MyApp\MyFile.exe to C:\Program Files\MyCompany\MyApp\MyFile_NEW.exe. What does this mean for component creation? This is a new absolute installation path, so you generate a new GUID for the hosting component, OR you add a new component and delete the old one (which has the same effect).
• Your updated MSI delivers a new version of MyFile.exe. The location is the same as before, this means the component GUID should not change. It is the same file (identity), just in a different version.

---

UPDATE:

Auto Component-GUIDs: WIX now has a new auto-generate component GUID feature that calculates a GUID as long as the target path stays the same. I have not tried this out to be honest, but many seem to use it without problems, and Rob Mensching (Wix author) states it is safe for normal use. As a concept I highly recommend this since it features some auto-magic and shields you from some complexity.

Minimal WiX Markup: Also note that you can leave out a lot of source attributes from your Wix xml file and rely on Wix defaults instead of hard coding values.

Answer 2

You never change the Component/@Guid. You also never change the set of Resources (File, RegistryKey, Shortcut, TypeLib, etc.) in the Component. When you have a new Resource, you must create a new Component with a new @Guid. The really tricky part is that new Component can have no overlap (think file path, or registry key path, or typelib, etc.) with the old Component.

These are basically the Component Rules, check out: https://robmensching.com/blog/posts/2003/10/18/component-rules-101/.

Answer 3

Have a look at the WiX Tutorial, The Files Inside, for a detailed explanation on component rules. Basically, it says you never change the GUID of a component, since that means orphaning the old component and creating a new component.