Simplifying WiX component authoring

In the latest in the ongoing series of simplifying the WiX language, I recently added two new defaults to the WiX compiler:

  • The Component/@Guid attribute value defaults to “*” so that if you don’t specify it, WiX generates a stable component GUID at link time. Generated component GUIDs are available as long as your component:
    • Does not contain an ODBCDataSource element. (ODBwhat?)
    • Has only one file.
    • Has only registry values.
  • The Component/@Id attribute value defaults to the id of the keypath resource. The component itself cannot be the keypath for this to work (obviously, there’s no id for it to default to).

These changes will appear in the first weekly release of WiX v3.5 in 2010.

Combine the two features and a single-file component can now be as simple as:

  <File Source=”foo.exe” />

In this case, the component’s id will be “foo.exe” because the File element’s default for its Id is the filename portion of the Source attribute. Call it hygenic double-dip defaulting.

A multi-file component isn’t suitable for generated GUIDs, so it requires an explicit GUID but can still take advantage of default component ids:

<Component Guid=”{A5B56773-5E26-4C5F-AC51-C2470C3658AF}”>
  <File Source=”foo.dll” />
  <File Source=”bar.dll” />
  <File Source=”bob.exe” KeyPath=”yes” />

In this case, the component’s id will be “bob.exe” from the keypath File element’s default Id. Note that unless you use the generated GUID default and live within its rules, you must specify an explicit KeyPath attribute value of “yes” on the resource whose id you want to be the component id.

We can’t eliminate the dread component rules but we can make it simpler to live within them.

4 thoughts on “Simplifying WiX component authoring”

  1. I’m sure you’ll not like this suggestion, but if every attribute of the component attribute can be generated by the compiler, why even require a component element? If you ignore how Windows Installer works and think about describing the installer from a functional point of view, the more expresive relationship is file is a child of directory.

  2. Christopher,

    It’s possible but unless we adapt a .vdproj-like one-resource-per-component rule, it’s a very different thing than we have now. WiX v4 is when we’re looking at major changes like this.

  3. In my thought File could be a child of both directory and component so you could either imply the component on a 1:1 basis or call it out and give it a 1:many or otherwise adjust other attributes.

    VDPROJ is actually a mix of good and evil in this area to me. The user interface is actually decent in describing files and folders but it’s authoring is too restrictive and in the end causes many problems. I think WiX could have the best of both worlds.

Comments are closed.