1

My WIX custom action should delete a SQL Job when the product is uninstalled. This works perfectly if the MSI is executed and REMOVE is selected.

However, it never seems to run if the product is removed via Add/Remove programs.

Here is my InstallExecuteSequence section

<Custom Action="CleanupServer_Set" Before="CleanupServer"><![CDATA[NOT UPGRADINGPRODUCTCODE AND (REMOVE="ALL")]]></Custom>
<Custom Action="CleanupServer" Before="RemoveFiles"><![CDATA[NOT UPGRADINGPRODUCTCODE AND (REMOVE="ALL")]]></Custom>

And this is my custom action definition

 <CustomAction Id="CleanupServer_Set" Property="CleanupServer" Value="SERVER=[SERVER];DBFILES=[DBFILES]" Execute="immediate"/>      
 <CustomAction Id="CleanupServer" BinaryKey="CA" DllEntry="CleanupServer" Execute="deferred" Return="ignore" Impersonate="no"/>

Any help would be greatly appreciated. Since I'm running the uninstall via Control Panel, I do not have a debug log file to review to see what is happening.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Russ R
  • 61
  • 1
  • 7
  • This is a nicely formatted and well phrased question. Let's give the guy some upvotes so he can get proper stackoverflow rights and privileges going? Shouldn't we welcome new users better? (this is obviously a real user). – Stein Åsmul Jun 05 '18 at 17:48

1 Answers1

0

UPDATE: In Add / Remove Programs. Maybe try Modify instead of Remove - if available. This will run the uninstall in GUI mode, instead of in silent mode which is what is used when you select Remove.

Impersonation: In silent mode the properties you depend on might not be set (if they are set in the GUI normally), or you could fail to connect to the database because msiexec.exe (the Windows Installer Engine) runs in system context. I believe one, or both of these issues to be at least part of your problem. Is it a remote database?

  1. Maybe first try to set Impersonate to yes, like this (don't run in system context, impersonate launching user):

    <CustomAction Id="CleanupServer" BinaryKey="CA" DllEntry="CleanupServer"
              Execute="deferred" Return="ignore" Impersonate="yes" />

  2. Alternatively maybe try to run it non-deferred (immediate and unelevated), and maybe set it to run only once:

    <CustomAction Id="CleanupServer" BinaryKey="CA" DllEntry="CleanupServer" 
              Execute="firstSequence" Return="ignore" />

Just suggestions to try, I haven't tested.

Global Logging: First things first, enable global logging on the machine and get yourself a log file that way - please see section: "Globally for all setups on a machine". Essentially just add this section to the registry (but check the link for more details and context):

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmup"
"Debug"=dword:00000007

Suggested Steps:

  1. Add the registry values in question, as described above (Debug and Logging)
  2. Run the install and then the uninstall from ARP
  3. Find the log file - with a random name - in the %TEMP% folder
    • Windows Key + tap R type %TEMP% and press Enter
    • Sort by modify date / time. Your file should show up on top
  4. Let us see the log. Upload to Github, Dropbox, GDisk, or someplace else.

There is also a section on how to interpret log files - in case you want to have a look first yourself. Essentially, search for the custom action names, relevant property values and skim the immediate "surroundings" of the entries you find. Logging is verbose indeed, but helpful.

Persist / Read Back Property Values: Here is an answer showing persisting of properties and how you can read them back with AppSearch. Remember to test such features well in all installation modes (install, uninstall, modify, remove, major upgrade, silent and interactively - there are usually surprises).

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • Thank you for those suggestions! I will implement them asap and see how things go. – Russ R Jun 04 '18 at 15:28
  • Just updated a couple of things. Just so you reload the page. – Stein Åsmul Jun 04 '18 at 15:29
  • So the temp log was the key. The server name being passed as a customActionData is blank, but I think I know how to deal with that. Thank you - so much of your answer was valuable information! – Russ R Jun 04 '18 at 15:46
  • Do you write the server name to the registry? You can read it back with an AppSearch perhaps? – Stein Åsmul Jun 04 '18 at 15:48
  • [Here is an answer showing persisting of properties and how you can read them back with AppSearch](https://stackoverflow.com/a/48652032/129130). Remember to test such features well in all installation modes (`install`, `uninstall`, `modify`, `remove`, `major upgrade`, `silent and interactively` - there are usually surprises). – Stein Åsmul Jun 04 '18 at 16:15
  • To answer your question, the server name is written to an XML file that holds basic config information. So I just called the action that reads the file and everything worked perfectly. – Russ R Jun 05 '18 at 17:13
  • OK, sounds good. If you are in a corporate environment with a client / server application I would be sure to **test distribution via the distribution system as soon as possible** (hope that bolding doesn't look too dramatic). Whatever it might be (for example [**SCCM**](https://en.wikipedia.org/wiki/Microsoft_System_Center_Configuration_Manager) or similar). This is to double-check for any impersonation issues. Maybe try to install to a PC with no user logged on. There can be many surprises, but don't let me scare you :-). – Stein Åsmul Jun 05 '18 at 17:41