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.
- 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?
<Component Id="MyComponent" Guid="*">
<File Id="MyFile" Name="myFile.txt" KeyPath="yes" Source="myFile.txt" />
</Component>Here’s how it works:
- 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.
- 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.
Limitations:
- 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


0 Comments:
Post a Comment
<< Home