Derek Cicerone Installing...

WiX, Setup, and trying to make it all easy, not just easier

Friday, September 08, 2006

Automatically generating component GUIDs

Yes, this change is exactly what you think it is: automatically generating component GUIDs. We believe that we may have come up with a safe way to automatically generate component GUIDs each build and ensure that component rules will not be broken (easily). If this idea works, it will obviously have a huge impact on the way that setup is authored for Windows Installer since it may become possible to generate authoring each build instead of maintaining it by hand.

Due to the nature of this feature, I’d like to ask the community for help. If you can do any of the following, it would be greatly appreciated:
  • 1. Review the overall design for this feature. Do you see any scenarios in which it will allow the component rules to be violated?
  • 2. Try it out. Are you able to accidentally cause component rule violations? Do shared components properly share their component guids as well?

A component with a generated component GUID will look like this (note the asterisk in the Guid value):

<Component Id="MyComponent" Guid="*">

<File Id="MyFile" Name="myFile.txt" KeyPath="yes" Source="myFile.txt" />


Here’s how it works:

  1. Canonicalize the target path to the key path file by:
    • Lowercasing all the characters in the path except for the standard directory identifier which must start all paths (since the file system is case-insensitive).
    • Ignore any blank directory entries (those with “.” in the DefaultDir column). This prevents paths like “Root\.\file.txt” and “Root\file.txt” from getting different component guids.
    • Always begin a path with a standard directory identifier (such as “ProgramFilesFolder”). This eliminates differences in how source images are laid out in various products.
  2. Create a version 3 UUID based on a pre-determined WiX namespace Guid and the path to the file.

Why these are legal guids?

This implementation follows the RFC 4122 specification for a version 3 MD5-based UUID (you can verify this because the first number of the third set of hex digits in the guid will always be ‘3’, like this: {xxxxxxxx-xxxx-3xxx-xxxx-xxxxxxxxxxxx}). In case you are wondering, guidgen creates version 4 UUIDs (based on randomly pseudo-randomly generated data). There is also a version 5 UUID which uses SHA-1 hashing, but I chose MD5 because it had an example implementation which allowed me to verify that my port of the code is correct.


  • Only supports one file per component, which must be the key path.
  • No ODBCDataSource children allowed (but there can be registry values and any other type of child).
  • Does not support multiple components installing the same file – a collision of the component guids will occur (this is caught by ICE validation).
  • Guids cannot be generated until the binder because that’s when all localization and wix variables are resolved.
  • Files must be rooted under a well-known Windows Installer standard directory (such as “ProgramFilesFolder”).

Here is an example of a canonicalized path which is hashed to create the component GUID:

ProgramFilesFolder\my product\some file.exe


Post a Comment

<< Home