8

We have created WIX installer for our application. Problem we are facing is: We have defined two different custom action (say ActionForInstall and ActionForUninstall) that we want to perform in following case: ActionForInstall : Should run while installation, product upgrade, maintenancemode (for both repair and modify) ActionForUninstall : Should run only for uninstallation.

But we are not able to set proper condition. You can refer code :

<Custom Action=ActionForInstall After='InstallFinalize' > 
    (NOT Installed) OR (Installed AND ((MaintenanceMode = "Modify") OR (MaintenanceMode = "Repair")) AND (NOT (MaintenanceMode = "Remove"))) OR  ((UPGRADINGPRODUCTCODE) AND NOT(REMOVE ~= "ALL"))
</Custom>
<Custom Action=ActionForUninstall Before='InstallFinalize'>
    Installed AND NOT UPGRADINGPRODUCTCODE
</Custom>

Please let us know what we have done wrong. Above code is calling InstallFinalize even for uninstall.

vrajs5
  • 4,066
  • 1
  • 27
  • 44
  • 1
    Useful cheat sheet: http://www.flexerasoftware.com/webdocuments/PDF/IS-CHS-Common-MSI-Conditions.pdf . I like to disable custom actions for patch-runs of the MSI by adding NOT PATCH to the existing list of conditions as well as NOT UPGRADINGPRODUCTCODE to disable them for major upgrades too. – Stein Åsmul May 28 '14 at 00:37

2 Answers2

10

You can try these conditions:

ActionForInstall:

REMOVE <> "ALL"

ActionForUninstall

REMOVE = "ALL"
Cosmin
  • 21,216
  • 5
  • 45
  • 60
  • Depending on where the custom action is scheduled and how the uninstall is performed, the REMOVE="ALL" condition can fail. For example, when doing a /x for uninstall the REMOVE property is set right away. But when doing a maintenance operation and selecting Uninstall the REMOVE property isn't set until well after costing. Just something to be aware of. I still maintain that it's better to create conditions based on component states. – Christopher Painter Apr 14 '11 at 11:24
  • @christopher You have point.. but we are in tight schedule and we dont have any wix expert.. what you are saying might take more effort to understand and implement.. So we are using solution given by @Cosmin – vrajs5 Apr 15 '11 at 04:49
  • See my comment added to the question above regarding major upgrades and patch installations. These installation types use the same installation sequence as the main install, maintenance and uninstall. It is often beneficial to condition your custom actions to not run during these installation types. – Stein Åsmul May 28 '14 at 00:42
5

Usually conditions that use product level properties such as Not Installed and REMOVE="ALL" don't scale to your expectations. It's generally better to use component action states such as

$COMPONENTNAME=3 <-- component being installed locally

$COMPONENTNAME=2 <-- component was previously installed and is now being removed

This will generally cover all of your install, uninstall, maintenance, repair, upgrade scenarios.

You can do similar things for Features using the "&" operator but generally using components "$" is better as components are physical and can be associated to one or more features which are only logical.

And if you really want to take it to the next level, your custom actions could (should) be data driven using a foreign key join to the Component table. In this scenario your custom action always fires and then queries the tables and evaluates the component action states to decide which operations need to be scheduled.

Conditional Statement Syntax (Windows)

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100