Derek Cicerone Installing...

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

Friday, September 15, 2006

Retiring from the WiX community

After over 3 years of working on WiX, I've decided its time to pursue other interests. It has been a true pleasure to work with this incredible community of volunteers. In fact, I likely would have stopped working on WiX a very long time ago if not for all your support. Thank you all for the good memories and I wish you the best of luck for the future.

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

Torch and Pyro

Although the WiX toolset has been out for quite a while now, one very elusive area which has not been tackled is transform and patch support. With the addition of a new tool called "Torch", WiX will now have transform creation support.

How is the tool used?
Here's a sample command line: "torch.exe target.msi updated.msi -out transform.mst". This command will create a transform.mst file which will transform target.msi into updated.msi.

Does torch support special WiX xml file formats like the .wixout file format?
Yes, the .wixout file format has been extended for transform support. This provides full round-tripping support in conjunction with dark's new -xo command line option. You could create a transform with torch, then "decompile" it with dark into a .wixout file, then re-build the transform file by passing the .wixout file into torch. Although this is a pretty impractical series of tasks, there are likely scenarios in which an advanced user would want to examine a transform in an xml format (you could easily diff two transforms) or build a transform solely from xml.

What features would likely be added in the future?
  • Create a transform from two .wixout files.
  • Create a transform from two .wxl files (and a .wixout file) in order to create a language transform.
What about patch creation support?
Although it won't be supported at this time, the transform support is a key piece of the infrastructure needed to make progress towards patch creation support. There is a new tool called "Pyro" which contains the engine for patch creation but not the nice user-interaction necessary to make it usable. With a bit more work, Pyro should one day be the WiX tool for creating patches.