2

I have a Wix (3.8) project that is relatively generic in that we are attempting to produce multiple Demo installers using a variety of tools such as the preprocessor to change the name, include different files and options. I also modify the ProductId/ProductCode/UpgradeCode for each so that they appear as 2 different products and install side by side. Installing and uninstalling one alone works fine. When I install 2 side-by-side and uninstall one there are several abandoned resources one of which is the shortcuts.

Here is the code I am using for the shortcuts:

<DirectoryRef Id="DesktopFolder">
  <Component Id="DesktopShortcuts"
             Guid="*">
    <Shortcut Id="ApplicationDesktopShortcut"
              Name="!(bind.property.ProductName)"
              Description="Demo Application"
              Target="[INSTALLDIR]Demo.exe"
              WorkingDirectory="INSTALLDIR"
              Advertise="no"/>
    <RegistryKey Root="HKMU"
                 Key="SOFTWARE\$(var.Manufacturer)\!(bind.property.ProductCode)\DesktopShortcuts">
      <RegistryValue Name="Installed"
                     Type="integer"
                     Value="1"
                     KeyPath="yes" />
    </RegistryKey>
  </Component>
</DirectoryRef>

After reviewing the installer logs I note that the ComponentId for the shortcuts is always the same which explains the abandoned resources (shortcuts).

I was under the impression that because the Path to my registry value was different for each installer (note that I bind the product code into the key) I would get a different Guid for each installer as a result of the Guid="*" attribute. However, the wix documenation is unclear WRT Registry keys as are other discussions I located. Apparently this isn't an issue with files that are in separate directories.

Such as this and the Wix docs.

Community
  • 1
  • 1
bakerhillpins
  • 96
  • 11

1 Answers1

3

So I figured out what is going on. It's all got to do with some subtle issues on this line:

 Key="SOFTWARE\$(var.Manufacturer)\!(bind.property.ProductCode)\DesktopShortcuts">

As noted in the question the documentation and references suggest that the Path for files and registry entries are used to dynamically generate the Guid. Note the path includes the file/Value Name. This is in fact happening but how was I getting the same Guid for the ComponentId for 2 different installers using 2 different ProductCodes? You would think that the inclusion of the ProductCode into the path would make each unique. Well, turns out it's because I was using !(bind.property.ProductCode) in the path. Binder variables don't get substituted until the Linking phase with light. The Guid="*" element is generated in the Compiling phase with Candle which is obviously before the linker. So while the substitution was occurring and the proper keys were being generated in the registry, the Guid was being generated from a non unique path:

SOFTWARE\MyCompany, Inc\!(bind.property.ProductCode)\DesktopShortcuts\Installed

So don't use binder variables in any KeyPath element when using the auto generated Guid functionality.

bakerhillpins
  • 96
  • 11
  • This is happening for me too with Visual Studio Installer projects in VS2015, it's basically just a hash on the targetdir\filename. This makes side by side installs impossible. There's no 'base guid' or salt value used (you would assume the ProductCode would be used as a combination). I have no workaround however. I guess you can turn these auto-guids off in wix? – GilesDMiddleton Nov 29 '16 at 17:26
  • @GilesDMiddleton Anyway you can use the VS build macros to inject a version # into the targetdir macro or the output filename? I know I tried some of this and wasn't successful but I am currently auto generating the version # string in custom MSBuild tasks and it's not once per solution but rather once per project so the build/revision #s change on me. If you inject into the solution build process as a define it might work. – bakerhillpins Dec 01 '16 at 15:21