WiX Proper Creation of Desktop Shortcut

Question

There are two answers on Create shortcut to desktop using WiX

Both these answers lack any real explanation of what is going on. What is the difference between these two methods of creating shortcuts? The first method falls in line with WiX - Create shortcut documentation.

The second method has a MergeRedirectFolder which I can't seem to find any documentation on, and I don't understand why the second example doesn't require the registry setting since according to WiX Documentation, a registry setting:

is required as a Shortcut cannot serve as the KeyPath for a component when installing non-advertised shortcuts for the current users.

Does this mean that the second method is an advertised shortcut? Or is it an answer that assumes the user is installing per machine? Or am I lost in the sauce? (Quite possible - second day trying to use WiX, since Microsoft forced me down this path.)

The first one:

<Directory Id="TARGETDIR" Name="SourceDir">
  <Directory Id="DesktopFolder" Name="Desktop">
    <Component Id="ApplicationShortcutDesktop" Guid="*">
      <Shortcut Id="ApplicationDesktopShortcut"
         Name="Text under your icon"
         Description="Comment field in your shortcut"
         Target="[MYAPPDIRPROPERTY]MyApp.exe"
         WorkingDirectory="MYAPPDIRPROPERTY"/>
      <RemoveFolder Id="DesktopFolder" On="uninstall"/>
      <RegistryValue
        Root="HKCU"
        Key="Software/MyAppName"
        Name="installed"
        Type="integer"
        Value="1"
        KeyPath="yes"/>
    </Component>
  </Directory>
    <Directory Id="ProgramFilesFolder" Name="PFiles">
      <Directory Id="MyCompany" Name="MyCompany">
        <Directory Id="MYAPPDIRPROPERTY" Name="MyAppName">
      </Directory>
    </Directory>
  </Directory>

The second one:

<Directory Id="TARGETDIR" Name="SourceDir">
  <Directory Id="DesktopFolder" SourceName="Desktop" />
  <Directory Id="MergeRedirectFolder">
    <Component Id="MyExeComponent" Guid="*">
      <File Id="MyExeFile" Source="$(var.ExeSourcePath)" KeyPath="yes">
        <Shortcut
          Id="DesktopShortcut"
          Directory="DesktopFolder"
          Name="$(var.ShortcutName)"
          WorkingDirectory="MergeRedirectFolder" />
      </File>
    </Component>
  </Directory>
</Directory>

Solution

Caveat: Per Doc's comment, since neither example specified the Advertise attribute, neither should create an advertised shortcut. I don't remember what led me to write the answer below; it seems likely to be incorrect. I'll leave the answer in tact in case there is some subtle truth behind it.

---

The first example creates an advertised shortcut; the second creates a non-advertised shortcut. The rules for the two types of shortcuts are described with the Shortcut Table Target column.

A non-advertised shortcut is a standard Windows shortcut like you would create with Windows Explorer. An advertised shortcut enhances resiliency by verifying that all the components in the feature are installed when the shortcut is activated.

Comments

[Doc]

The first example is not an advertised shortcut since that would need the Advertise attribute. Other than that, I haven't delved too deeply into the differences and went on ahead and used the first example.

[Stein Åsmul]

An advertised shortcut points to an MSI feature and triggering it will lead to all key paths in that feature and all its parent features to be validated. If a problem is found for any key path, a self-repair is triggered for the affected features and the missing components are (re)installed. This validation check is sometimes used to add per-user data for each Windows user when they launch their application (userdata or HKCU data).