-1

I've experimented with deferred custom action type 18. I've read a lot of material on the internet including this similar question How to add a WiX custom action that happens only on uninstall (via MSI)? which gives a big truth table of properties, but nothing seems to match my experiences with my Wix. I've upgraded to the latest Wix 3.11.

File element is within the directory structure...

<File Id='ReplaceRegistryEntriesFile' Source='MikeyRegistryReset.bat' 
      DiskId='1' 
/>

The rest is under Product...

<InstallExecuteSequence>
<Custom Action="RunOnUninstall"  
        After="InstallInitialize"
> 
</Custom>
</InstallExecuteSequence>

<CustomAction Id="RunOnUninstall" 
    FileKey="ReplaceRegistryEntriesFile"
    ExeCommand=" mabwashere"
    Impersonate="no" Return="asyncNoWait"
    Execute="deferred" 
/>

It's actually causing the script to run during the uninstall phase. Why didn't it run during the installation phase? There is no logic (that could possibly have been placed there explained in the link above) currently there to stop it from running anytime it wants to run. I was expecting it to run during both install and uninstall.

It gets more strange. If I change After="InstallInitialize" to Before="InstallFinalize", my batch file then only runs during installation.

Maybe this is unique to deferred custom actions! So is a deferred custom action only ever run once in the Install/Uninstall cycle? I've seen no documentation to tell me this.

WTF is going on?

Mikey
  • 89
  • 7
  • `After="InstallInitialize"` - so it's before `InstallFiles`, meaning your batch file won't be installed yet. See [Suggested InstallExecuteSequence](https://learn.microsoft.com/en-us/windows/win32/msi/suggested-installexecutesequence). Note that you should also provide rollback custom actions, otherwise if something goes wrong during install/uninstall, what your custom actions have done won't be undone. – zett42 Aug 04 '19 at 17:29
  • Old classic: [Installation Phases and In-Script Execution Options for Custom Actions in Windows Installer](http://www.installsite.org/pages/en/isnews/200108/index.htm). You should never run batch files as part of installation in my opinion (poor reliability, no real error handling, generally no rollback, little flexibility coding-wise, etc...), what do you do in the batch file? I have some stuff written up about this, will have a look later (or search yourself using my name and batch file custom actions or similar terms). – Stein Åsmul Aug 04 '19 at 17:54
  • It's a deferred custom action. So as I understand it, the custom action isn't performed at the time of the specified action (InstallInitialize), but is deferred. Also, as I understand it, custom actions cause the script to be embedded, and the script isn't run from the directories. But I may be wrong. I'm able to put a logfile up if it helps anyone. – Mikey Aug 04 '19 at 23:16
  • I'd love to be able to skip using a batch file, but Wix functionality is seriously lacking and I need to use one. Eventually I want to run it on install and uninstall passing a different argument. – Mikey Aug 04 '19 at 23:19
  • Can you solve this problem in the application? One technique is to deprecate the old registry key and just make a new one that is "active". It is in general better to have your application do registry cleanup than to have the setup do it. The exception is HKLM settings that can't be written to during normal application operation (without elevated rights). – Stein Åsmul Aug 05 '19 at 15:00
  • @SteinÅsmul For some context, [this is the original question](https://stackoverflow.com/q/57253070/7571258). It was my suggestion to use a custom action only to restore the registry value on uninstall. Maybe you have a better idea? Don't see any other way than running a custom action on uninstall. – zett42 Aug 05 '19 at 19:01

1 Answers1

0

Well I've got a version working. I've got two deferred custom actions, one runs Before="RemoveRegistryValues", the other one is After="InstallFiles". They both call the same .bat file, but pass a different argument during install and uninstall (the values INSTALL and UNINSTALL in my case).

Some code...

<InstallExecuteSequence>
<Custom Action="RunOnUninstall"  
        Before="RemoveRegistryValues"
> 
</Custom>
<Custom Action="RunOnInstall"  
        After="InstallFiles"
> 
</Custom>
</InstallExecuteSequence>

<CustomAction Id="RunOnUninstall" 
    FileKey="ReplaceRegistryEntriesFile"
    ExeCommand=" UNINSTALL"
    Impersonate="no" Return="asyncNoWait"
    Execute="deferred" 
/>
<CustomAction Id="RunOnInstall" 
    FileKey="ReplaceRegistryEntriesFile"
    ExeCommand=" INSTALL"
    Impersonate="no" Return="asyncNoWait"
    Execute="deferred" 
/>

There are a couple of problems though I discovered during testing:

Problem 1: The File element is in the directory structure. I was forced to use the file element to run a batch file (with .bat extension) with custom action type 18, and that file element had to be placed in the directory structure causing the file to be installed on the computer. I did some testing, and that file/batch script can be modified after the .msi is installed (with admin privilege albeit), causing the uninstall to possibly not work correctly. I thought that deferred custom actions keep the file in the .msi script and run that. But this is not happening, it's running the batch script that is currently in the file structure during uninstall. If anyone has tips on how to correct this behaviour I'm still willing to hear about it.

Problem 2. When I install the .msi, the registry changes that were performed in the batch script take effect immediately (in this case NeverShowExt was removed), and the missing file extensions show immediately. But when the .msi is uninstalled and the registry entries are replaced, the file extensions still show until I log out and log back in.

Problem 3: Still the same problem as before, this is all undocumented behaviour. Anyone that can point me to some documentation that explains why this is working would be appreciated.

Even with the above problems, I'm actually quite happy I've got my product working. So I'm going to run with it and go on with other things now, until perhaps someone gives me more information addressing the problems I listed above.

Mikey
  • 89
  • 7