CODEWITHSUNDEEP
wixwindows-installercustom-actionwix3.5
Aditya Sinha
Aditya Sinha

Reputation: 23

WIX MSI: I Want to show a message to user "Product is already Installed" if user runs the installer again

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?

Upvotes: 2

Views: 996

Answers (1)

Stein &#197;smul
Stein &#197;smul

Reputation: 42126

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:

Upvotes: 1

Related Questions