(WiX) Program files shortcut for per-machine install

Question

Following the example here, I added a shortcut to the ProgramMenuFolder that launches my application. (My code is actually simpler because I don't need the extra folder.)

<DirectoryRef Id='ProgramMenuFolder'>
  <Component Id='cmpStartMenuShortcut'
             Guid='MY GUID HERE'>
    <Shortcut Id='StartMenuShortcut'
              Name='$(var.ProductName)'
              Icon='MainIcon.ico'
              Description='$(var.ProductName)'
              Target='[ClientDir]myapp.exe'
              WorkingDirectory='ClientDir'/>
    <RegistryValue Action='write' Type='integer' Root='HKCU'
                   Key='Software\Company\Product Name'
                   Name='installed' Value='1' KeyPath='yes'/>
  </Component>
</DirectoryRef>

Since my installation is per machine (ALLUSERS=1, Package/@InstallPrivileges='elevated', and @InstallScope='perMachine') the ProgramMenuFolder is the folder for all users on the machine.

My question has to do with the registry value. My understanding is that it's needed simply to provide a KeyPath for the component that contains the shortcut. The sample uses HKCU, which is a per-user location.

Isn't it a mistake to use a per-user value as a KeyPath for a per-machine component?

If a machine has two admins, and admin #1 installs the product, and admin #2 attempts a repair, then Windows Installer won't see the registry value and think that the shortcut is missing and it will install a duplicate, right?

So I tried changing the RegistryValue/@Root to HKLM, but then WiX complains:

error LGHT0204 : ICE38: Component cmpStartMenuShortcut installs to user profile. It's[sic] KeyPath registry key must fall under HKCU.

error LGHT0204 : ICE43: Component cmpStartMenuShortcut has non-advertised shortcuts. It's[sic] KeyPath registry key should fall under HKCU.

error LGHT0204 : ICE57: Component 'cmpStartMenuShortcut' has both per-user and per-machine data with a per-machine KeyPath.

I don't understand why the key must be under HKCU.

Tom Blodget · Accepted Answer · 2013-06-24T19:59:38.323

That style of shortcut is for a target that might not be installed now nor at the time it is invoked. It creates the classic .lnk shortcut file. It is useful for shortcuts to targets that your installer is not responsible for but might be useful for users of your product to use (e.g. cmd.exe).

Alternatively, a shortcut for a target you are installing or advertising will be uninstalled when the target is unadvertised (product is uninstalled). For example, WiX installs a shortcut to wix.chm called WiX Documentation. The Shortcut element for an advertised shortcut can be made a child of the File element.

Here is a hand-written example:

<Component Id="ProductComponent">
   <File Source="$(var.ConsoleApplication1.TargetPath)" KeyPath="yes">
     <Shortcut Id="$(var.ConsoleApplication1.TargetName)Shortcut" 
               Name="$(var.ConsoleApplication1.TargetName)" 
               Advertise="yes"
               Description="Starts $(var.ConsoleApplication1.TargetName)"
               Directory="ProgramMenuFolder" />
   </File>
</Component>

To insert the Shortcut element into heat's output, pass it the path to an XSL transform. Snippet:

<xsl:template match="wix:File[contains(@Source,'\myapp.exe')]">
  <xsl:copy-of select="." />
  <Shortcut Id='StartMenuShortcut'
          Advertise="yes"
          Name='$(var.ProductName)'
          Icon='MainIcon.ico'
          Description='$(var.ProductName)'
          WorkingDirectory='ClientDir'/>
</xsl:template>

Thanks. This solution seems to be working for me. I didn't know I was going to have to learn about XSLT when I started down the WiX road. — Adrian McCarthy, Jun 27 '13 at 15:51
You haven't really answered why a non-advertised shortcut can't write its `KeyPath` to HKLM, or why a non-advertised shortcut requires a **registry** `KeyPath` but an advertised one doesn't. — Drazen Bjelovuk, May 14 '16 at 18:32
This answer is a bit tangential to what I think the question is about, and as @DrazenBjelovuk mentions, does not fully explain or cover why a regular (non-advertised) shortcut, which most applications would be using I imagine, warrants the errors quoted in the question. — Armen Michaeli, Sep 25 '18 at 14:46

score 0 · Answer 2 · answered Jun 23 '13 at 12:10

0

What I would recommend doing is simply making the folder as you said, but not placing the shortcut directly under it. Instead make a shortcut element under the component holding the file. You can use the Directory attribute to specify where you want the shortcut to appear.

answered Jun 23 '13 at 12:10

Christopher B. Adkins

3,499
2
26
29

Thanks for the suggestion. Unfortunately, the component holding the file is generated by heat (and periodically regenerated), so it's not practical to use that approach. And I'd really like to understand _why_ it's an error to use a per-machine location as the KeyPath for a per-machine component. – Adrian McCarthy Jun 23 '13 at 13:46
1

The main issue here is that the entire start menu is per-user. The user that you are referencing is the entire User group, but still that is considered by Windows Installer to be a user itself. – Christopher B. Adkins Jun 24 '13 at 06:49
Isn't the start menu a hybrid view of per-user and per-machine elements? When I run my installer per-machine, the shortcut is added to All Users\Start Menu\Programs not \Start Menu\Programs. – Adrian McCarthy Jun 24 '13 at 16:04
All Users counts as a user from the view of Windows Installer. It is simply another user profile. S-1-1-0 SID, if that makes more sense to you. – Christopher B. Adkins Jun 24 '13 at 19:21
2

But the HKCU registry value will correspond to the installing user, not to the S-1-1-0 SID. If another admin comes in and tries to repair the installation, it won't find the existing HKCU KeyPath and will instead create a redundant shortcut. – Adrian McCarthy Jun 24 '13 at 19:35

(WiX) Program files shortcut for per-machine install

2 Answers2

Linked