Why do we get an ICE57 error for non advertised shortcuts in per machine installations?

Question

This question is asking whether one of the ICE57 validators creates a false positive error report.

I am using WIX 3.9 to generate an installer. I want a per machine installation with non advertised shortcuts.

This WXS example installs a text file and a shortcut to open the text file:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="ShortcutTest" Language="1033" 
           Version="1.0.0.0" Manufacturer="Widget Co" 
           UpgradeCode="--YOUR GUID1--">
    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />

    <MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
    <MediaTemplate EmbedCab="yes"/>

    <Feature Id="ProductFeature" Title="ShortcutTest" Level="1">
      <ComponentRef Id="TextFile" />
      <ComponentRef Id="ShortCut" />
    </Feature>

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLFOLDER" Name="ShortcutTest">
          <Component Id="TextFile" Guid="--YOUR GUID2--">
            <File Id="File" Name="TextFile.txt" Source="TextFile.txt" KeyPath="yes"/>
          </Component>
        </Directory>
      </Directory>

      <Directory Id="ProgramMenuFolder">
        <Directory Id="ApplicationProgramsFolder" Name="Shortcut Test">
          <Component Id="ShortCut" Guid="--YOUR GUID3--">
            <RegistryValue Root="HKMU" Key="Software\WidgetCo\ReadMeTextFile\TextFile" Name="Installed" Type="string" Value="yes" KeyPath="yes"/>
            <Shortcut Id="Shortcut"
                Name="Open Text File"
                Description="Opens a text file"
                Target="[INSTALLFOLDER]TextFile.txt"
                WorkingDirectory="INSTALLFOLDER"/>
            <RemoveFolder Id="ApplicationProgramsFolder" Directory="ApplicationProgramsFolder" On="uninstall"/>
          </Component>
        </Directory>
      </Directory>
    </Directory>
  </Product>
</Wix>

If you build the above example into an MSI package, you get this Internal Consistency Evaluator (ICE) error:

D:\Robert\Documents\Visual Studio 2013\Projects\ShortcutTest\Product.wxs(27,0): error LGHT0204: ICE57: Component 'ShortCut' has both per-user data and a keypath that can be either per-user or per-machine.

ICE57 is implying an inconsistency between per-user and per-machine data. But, the key path of the component is HKMU, which in a per machine installation resolves to HKLM (HKEY_LOCAL_MACHINE). The location of the shortcut derives from 'ProgramMenuFolder', which in a per-machine installation resolves to C:\ProgramData\Microsoft\Windows\Start Menu\ (on Windows 8.1). None of the component's resources appear to have any per-user association.

You can build the installer package into an MSI by suppressing ICE57. The resulting MSI package installs without any obvious errors. Multiple users can log on and access the shortcut. Any user can un-install the package and all of the resources in the package are removed.

The answer to Wix create non advertised shortcut for all users / per machine has an interesting workaround, which is to author advertised shortcuts and then turn off advertising. Seems a round about way of creating un-advertised shortcuts.

A common fix for the ICE57 error is to change the <RegistryValue...> root to HKCU (HKEY_CURRENT_USER). However this creates an installer that can leave a user registry key behind when un-installed. For example if user A installs the package, a registry entry is added to user A's registry hive. If user B removes the package, the registry entry is not removed from user A's registry hive.

In this scenario is the ICE57 error a bug in the Internal Consistency Evaluators? Or is there something I have miss-understood?

Answer 1

While researching another problem I found this comment on http://sourceforge.net/p/wix/mailman/message/26687047/ from Rob Mensching:

IIRC, this is a bug in ICE57. The Windows Installer team didn't look at ALLUSERS property when evaluating these values... that was a long time ago though so my memory may have decayed a bit.

It looks like a bug in ICE57.