2

I am creating an MSI installer, during testing the same if I am running the installer for the first time the installer works as expected. But when I accidentally run the installer, it uninstalled my files.

So, for that, I had modified the condition and added Remove="All" in the condition of the actions.

Which is working fine, but I want to show a message to the User that the product is already installed.

So, for that, I added the below piece of code:

<Upgrade Id='<<Upgrade Code>>'>
  <UpgradeVersion OnlyDetect='yes' Property='SELFFOUND'
    Minimum='1.0.1' IncludeMinimum='yes' Maximum='1.0.1' IncludeMaximum='yes' />
  <UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND'
    Minimum='1.0.1' IncludeMinimum='no' />
</Upgrade>

<CustomAction Id='AlreadyUpdated' Error='[ProductName] is already installed.' />
    .....
    .....
    .....
    .....
    .....
<InstallExecuteSequence>
  <Custom Action='AlreadyUpdated' After='FindRelatedProducts'>SELFFOUND</Custom>
</InstallExecuteSequence>

But when running this, the installer is still running for the second time and not giving the message.

On checking the logs, could see that the "FindRelatedProducts" skipped with the below message:

MSI (c) (F4:1C) [06:18:04:806]: Doing action: FindRelatedProducts
MSI (c) (F4:1C) [06:18:04:806]: Note: 1: 2205 2:  3: ActionText 
Action 6:18:04: FindRelatedProducts. Searching for related applications
Action start 6:18:04: FindRelatedProducts.
MSI (c) (F4:1C) [06:18:04:806]: Skipping FindRelatedProducts action: not run in maintenance mode
Action ended 6:18:04: FindRelatedProducts. Return value 0.

and

MSI (s) (18:14) [06:18:05:500]: Running ExecuteSequence
MSI (s) (18:14) [06:18:05:500]: Doing action: FindRelatedProducts
MSI (s) (18:14) [06:18:05:500]: Note: 1: 2205 2:  3: ActionText 
Action 6:18:05: FindRelatedProducts. Searching for related applications
Action start 6:18:05: FindRelatedProducts.
MSI (s) (18:14) [06:18:05:507]: Skipping FindRelatedProducts action: already done on client side
Action ended 6:18:05: FindRelatedProducts. Return value 0.

The condition in AlreadyUpdated custom action also does not satisfy.

MSI (s) (18:14) [06:18:05:737]: Doing action: PublishProduct
MSI (s) (18:14) [06:18:05:737]: Note: 1: 2205 2:  3: ActionText 
Action 6:18:05: PublishProduct. Publishing product information
Action start 6:18:05: PublishProduct.
PublishProduct: 
MSI (s) (18:14) [06:18:05:752]: Re-publishing product - installing new package with existing product code.
Action ended 6:18:05: PublishProduct. Return value 1.
MSI (s) (18:14) [06:18:05:752]: Skipping action: AlreadyUpdated (condition is false)

Is there any way to achieve this requirement? Am I doing something wrong?

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • An MSI will not automatically uninstall if you run it again. You will instead go into maintenance mode which shows a Repair, Modify or Uninstall dialog selector, unless you have compiled the MSI without any default GUI? Do you include a dialog set such as [Mondo](https://github.com/glytzhkof/all/blob/master/VBScriptWriteToLog/VBScriptWriteToLog/Product.wxs#L12)? (link to a sample WiX source file). – Stein Åsmul Nov 17 '20 at 20:46
  • The reason it was uninstalling because the condition for the custom action for the uninstall was getting satisfied. That is fixed after adding the Remove="All" condition – Aditya Sinha Nov 18 '20 at 06:54
  • You should not use a custom action to uninstall the previous version, but instead author the Upgrade table to implement a major upgrade - as you seem to do, but you set the entries to detect existing installation only, and not to uninstall via the major upgrade mechanism. Why? – Stein Åsmul Nov 18 '20 at 07:58
  • I am not using the uninstall in the custom action the installer was running some of the custom action defined to run during the uninstall sequence, like deleting folder, removing some records..etc. so those custom actions were running when the installer was running for the second time – Aditya Sinha Nov 18 '20 at 09:36
  • Added an answer below. It is a bit too involved perhaps. Using `SELFFOUND` like you do above should make that custom action **only** run when there is an existing, older version on the box? I suppose that is what you want when I read this. [I have something similar here](https://stackoverflow.com/a/48106587/129130) I think. Not recommended to implement in my opinion. Just more that can go wrong. – Stein Åsmul Nov 19 '20 at 00:08

1 Answers1

1

Custom Action Complexity: First a word on custom actions and their complexity. Please read the first paragraphs here: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?


Wrong Conditioning: This basically means your conditions are incorrect so the custom actions run in installation modes where they should not. There are many installation modes you should test in when you try to use complex conditions (or any condition for that matter): 1. fresh install, 2. repair, 3. modify, 4. self-repair, 5. patching, 6. uninstall, 7. major upgrade invoked uninstall, etc...

In your case some custom actions run on maintenance run as well as during fresh / first installation. This is a very common problem. The solution is either to eliminate the custom actions by improving the setup, or to improve conditions so they actually work in any installation mode. Obviously.

Condition Debugging: Conditions are hard to get right. I like to test them using message boxes. The bottom section here shows how you can do so: How to execute conditional custom action on install and modify only? - then you run the setup in different modes and look for the dialog boxes. When they show up the condition on the custom action is true.

Complex Conditions: Here is an answer on why old custom actions are used for a new setup: Wix Tools update uses old custom actions.

Unexpected Behavior: A special note on the properties UPGRADINGPRODUCTCODE and WIX_UPGRADE_DETECTED. Please read this: Run Wix Custom action only during uninstall and not during Major upgrade - these quirks affect how many times a custom action runs during a major upgrade scenario. Some very surprising effects here for people. Use your message box debugging?

Links:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164