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.

Solution 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.

---

Rob Mensching (WiX author):

• Windows Installer Component Rules 101
• Windows Installer Components Introduction

More on Component Rules:

• Organizing Applications into Components
• Best Practice for Creating Components.

---

I use some simple rules to deal with the overly complex and rather counterintuitive component rules (especially for developers as opposed to deployment specialists):

• 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.

Solution 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/.

Comments

[Rohit]

Do the location of component install as any effect?

[Rob Mensching]

Yes and no. :) If you change the Component/@Directory then you do not have to change the Component/@Guid but you may if you want... as long as there are no other Resources in the Component (like Registry keys). If there are other Resources in the Component and you change it's Guid then all the Resources need a new name or path. The new location will take care of the files, of course. No, Component Rules are not simple.

[Rob Mensching]

The part about "absolute path" is not exactly true. You can install the same Component (same GUID) to different directories and the reference counting works correctly. Directories put a wrinkle in the simplicity of the statements above.

[Stein Åsmul]

After file costing and resolution of the directory table with its directory properties and after the user has (maybe) selected an installation directory, the component GUIDs will point to absolute key paths? I think the simplest way to look at this is to focus on your source folder - if you move a file in your source folder you change the GUID. The actual install location is a "moving target" up until the point where are directories are resolved, but you always end up with an absolute path as key path for every installed component as far as I know?

[Farrukh Waheed]

@RobMensching. What if we use -ag option with Heat? As we know, it makes the generation of ComponentIds at link time on the basis of scenario defined by Glytzhkof in above response.

[Rob Mensching]

-ag was added after all these comments and is specifically designed to avoid all the problems with generating Component Guids. I use Component's without Guids (which is the preferred syntax over the old Guid='*' syntax) for every Component I can these days.

[Wolf]

The link is helpful, but the answer is not very helpful for deciding what to read there (not all people have a lot of time). I'd suggest to at least add a quote from the article, something like [...], a component should only contain items that belong together so strongly that they always need to be installed or removed together. If this means a single file, then your components will contain a single file each. This is not only normal but exactly what you're expected to do. Don't be afraid, Windows Installer can efficiently handle thousands of components or more, if needed.

[SINGULARITY]

The link is broken. Could you list the component rules?