Set ARPINSTALLLOCATION custom action in wrong place

[aleksandr-grechko]

Hi,

I use this notation:

    project.ControlPanelInfo.InstallLocation = "[INSTALLDIR]";  

to set up ARPINSTALLLOCATION property.
It should create action to set this property and schedule it after CostFinalize action (link).
But Wix# adds this action right after my latest custom action in InstallExecuteSequence.

<CustomAction Id="CA_CompareVersionsOnUpgrade" BinaryKey="Action4_CompareVersionsOnUpgrade_File" DllEntry="CompareVersionsOnUpgrade" Return="check" Execute="firstSequence" />
<CustomAction Id="Set_ARPINSTALLLOCATION" Property="ARPINSTALLLOCATION" Value="[INSTALLDIR]" Return="check" Execute="immediate" />
<CustomAction Id="Set_ARPNOMODIFY" Property="ARPNOMODIFY" Value="True" Return="check" Execute="immediate" />
<CustomAction Id="Set_DirAbsolutePath" Property="INSTALLDIR" Value="C:\SPASandbox\" />

<InstallExecuteSequence>
  <Custom Action="CA_CompareVersionsOnUpgrade" Before="LaunchConditions">WIX_UPGRADE_DETECTED</Custom>
  <Custom Action="Set_ARPINSTALLLOCATION" After="CA_CompareVersionsOnUpgrade"> (NOT Installed) </Custom>
  <Custom Action="Set_ARPNOMODIFY" After="Set_ARPINSTALLLOCATION"> (NOT Installed) </Custom>
  <Custom Action="Set_DirAbsolutePath" Before="AppSearch">(NOT Installed) AND (UILevel &lt; 5) AND (INSTALLDIR = ABSOLUTEPATH)</Custom>
</InstallExecuteSequence>

<CustomAction Id="CA_CompareVersionsOnUpgrade" BinaryKey="Action5_CompareVersionsOnUpgrade_File" DllEntry="CompareVersionsOnUpgrade" Return="check" Execute="firstSequence" />
<CustomAction Id="CA_PostInstallSteps" BinaryKey="Action5_CompareVersionsOnUpgrade_File" DllEntry="PostInstallSteps" Return="check" Execute="immediate" />
<CustomAction Id="Set_ARPINSTALLLOCATION" Property="ARPINSTALLLOCATION" Value="[INSTALLDIR]" Return="check" Execute="immediate" />
<CustomAction Id="Set_ARPNOMODIFY" Property="ARPNOMODIFY" Value="True" Return="check" Execute="immediate" />
<CustomAction Id="Set_DirAbsolutePath" Property="INSTALLDIR" Value="C:\SPASandbox\" />

<InstallExecuteSequence>
  <Custom Action="CA_CompareVersionsOnUpgrade" Before="LaunchConditions">WIX_UPGRADE_DETECTED</Custom>
  <Custom Action="CA_PostInstallSteps" After="InstallFinalize"> (NOT Installed) </Custom>
  <Custom Action="Set_ARPINSTALLLOCATION" After="CA_PostInstallSteps"> (NOT Installed) </Custom>
  <Custom Action="Set_ARPNOMODIFY" After="Set_ARPINSTALLLOCATION"> (NOT Installed) </Custom>
  <Custom Action="Set_DirAbsolutePath" Before="AppSearch">(NOT Installed) AND (UILevel &lt; 5) AND (INSTALLDIR = ABSOLUTEPATH)</Custom>
</InstallExecuteSequence>

[oleg-shilo]

Thank you.

Fixed in 0722b11. Will be available in the next release

[TI-asilva]

Hello,

I am using the code from above:

project.ControlPanelInfo.InstallLocation = "[INSTALLDIR]";

which generates the 2 xml blocks in the .wxs file:

<CustomAction Id="Set_ARPINSTALLLOCATION" Property="ARPINSTALLLOCATION" Value="[INSTALLDIR]" Return="check" Execute="immediate" />
<InstallExecuteSequence> <Custom Action="Set_ARPINSTALLLOCATION" After="CostFinalize"> (NOT Installed) </Custom> </InstallExecuteSequence>

These are the only such blocks I have (i.e. there are no other custom actions). However, this does NOT lead to the setting of the InstallLocation key in the registry and I'm not sure why. One thing of note is that this msi is part of a bootstrapper bundle that contains another installer that is a prerequisite for the msi's app. The rest of the installer is fairly vanilla Program.cs (project was generated by WixSharp Project Templates). I am using the default/minimal UI and it makes no difference whether I specify a custom directory or not. For what it's worth, my Directory tags look like this:

<Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFiles64Folder" Name="ProgramFiles64Folder"> <Directory Id="INSTALLDIR" Name="appname"> . . . </Directory> </Directory> </Directory>

Any idea what I could be missing?

Also, a side question - is there documentation explaining that line of code anywhere? I have the same goal of setting the InstallLocation registry key, but were it not for this related bug post, I would not have known to do that.

Thank you

UPDATE: nevermind, it is all working as expected. Turns out I was looking at the uninstall reg tree for the bootstrapper not the bundled msi.

However, now that I see that there are 2 reg trees, I have found that the UninstallString for the msi does not actually uninstall the application (it doesn't delete the files or remove the registry keys and the entry under add/remove programs is still there). The only way to uninstall the msi is to run the bundle's UninstallString (which it appears is what Uninstall from add/remove programs also does).

The reason we're trying to uninstall via running the UninstallString directly is that we have an application manager and it detects installed apps via the MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall children and provides uninstall functionality by running the UninstallString for that entry when found. With the bootstrapper/bundle setup, there's one here for the msi and also one under MACHINE\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall for the bootstrapper. Currently, the app manager doesn't look under the WOW6432 sub-tree for uninstallers (and in this case, I don't know that we'd want it to anyway, since then there'd be 2 entries in our app list).

So not sure what the correct solution is here or if maybe I still have something setup incorrectly which is causing this odd setup - maybe we need to somehow overwrite the UninstallString for the msi with the bootstrapper's UninstallString? Although, that seems wrong since it was originally an msi install and now the uninstall would be the bootstrapper's uninstall (which is a cached version of the bootstrapper, itself).