Loyal readership (if any remain), be advised: work stuff ahead. Feel free to skip this entry.

So: I’m using WiX 3.5 to create an MSI installer for [censored]. Among other things, this installer needs to create a few shortcuts in the Start menu (which these days is called the Program Menu Folder).

That’s easy: use a <Shortcut /> tag:

<Component Id='WiX_Shortcuts' Guid='*'>
    <Shortcut
        Id='WiX_Foo_Shortcut'
        Name='Foo'
        Description='Foo'
        Target='[INSTALLLOCATION]foo.exe'
        WorkingDirectory='INSTALLLOCATION'
        />
</Component>

But there’s a problem: every component needs a key file, and shortcuts – even though they are files – cannot be key files. The fix: add a registry key to the component, and make that the key file:

<Component Id='WiX_Shortcuts' Guid='*'>
    <Shortcut
        Id='WiX_Foo_Shortcut'
        Name='Foo'
        Description='Foo'
        Target='[INSTALLLOCATION]foo.exe'
        WorkingDirectory='INSTALLLOCATION'
        />
    <RegistryValue
        Root='HKCU'
        Key='Software\Wolfram Research\Foo'
        Name='installed'
        Type='integer'
        Value='1'
        KeyPath='yes'
        />
</Component>

But there’s a problem: the installer needs to run in either per-user or per-machine context (depending on user privileges, the version of Windows, and – for all I know – the phase of the moon, current temperature in Tahiti, etc., etc.). The fix: set the ALLUSERS and MSIINSTALLPERUSER properties:

<Property Id='ALLUSERS' Value='2' />
<Property Id='MSIINSTALLPERUSER' Value='1' />

But that causes validation errors. (Which ones? Beats me, I forgot to write ‘em down. Sorry.) That’s because the shortcut (which, you’ll recall, is a file) is installed into a (potentially) per-machine location, but the key file (which, you’ll recall, isn’t a file) is installed into a per-user location. (Why care about validation warnings/errors? Because MSI is such an insane kludge tower that if you get anything wrong, it will take a giant [censored] all over your computer. You’ll be hours cleaning up the mess.) The fix: use the HKMU registry root:

<Component Id='WiX_Shortcuts' Guid='*'>
    <Shortcut
        Id='WiX_Foo_Shortcut'
        Name='Foo'
        Description='Foo'
        Target='[INSTALLLOCATION]foo.exe'
        WorkingDirectory='INSTALLLOCATION'
        />
    <RegistryValue
        Root='HKMU'
        Key='Software\Wolfram Research\Foo'
        Name='installed'
        Type='integer'
        Value='1'
        KeyPath='yes'
        />
</Component>

There’s no such location in the Windows registry; it’s a kludge that magically points to the correct per-user / per-machine location. And it causes ICE57 errors:

ICE57: ICE57 - Checks that components contain per-machine or per-user data, but not both.
ICE57: Created 02/11/1999. Last Modified 01/17/2000.
setup.wxs(66) : error LGHT0204 : ICE57: Component 'WiX_Shortcuts' has both per-user data and a
keypath that can be either per-user or per-machine.

The fix: there isn’t one, because ICE57 is wrong. It seems the ‘softies who implemented ICE57 weren’t talking to the ‘softies who implemented dual-mode (per-user/per-machine) install packages. I may be disappointed, but I am not particularly surprised.

So the only thing to do is suppress ICE57, and get on with life.