NOTE: The below has not been tested extensively – conditions are notorious for being difficult to get right. Testing conditions requires real-world testing. A few more links:
- Condition debugging
- WiX launch conditions
- Wix Tools update uses old custom actions (example of complex conditions)
- How to add a WiX custom action that happens only on uninstall (via MSI)?
When either of those three “sub”-conditions are true, what do you want to achieve?
- Abort Setup: Abort the whole setup? (LaunchConditions)
- Configure Features: Prevent or enable installation of specific feature(s)? (Feature conditions)
This difference is obviously crucial – and we must know to be able to answer. Your WiX source snippet currently shows the conditions used as feature conditions. I have a feeling this is not what you want.
LaunchConditions: In order to abort the whole setup if one of these conditions are true, you could try to use LaunchCondition entries. Instead of making one complicated condition, you can just split them in three different entries that each check if the setup should be aborted – each entry for a different and specific reason. I suggest you add these LaunchCondition entries after your Package element in your WiX source file:
<Condition Message="Aborting setup: Server OS required for installation.">Installed OR MsiNTProductType=1</Condition>
<Condition Message="Aborting setup: State reason for abortion.">Installed OR MYKEY="MyValue"</Condition>
<Condition Message="Aborting setup: State reason for abortion.">Installed OR (MYSERVICE="MyService" AND MYKEY="")</Condition>
These entries will make it into the LaunchCondition table of your compiled MSI file.
LaunchConditions must always evaluate to true for the setup to be able to install / run.
Accordingly, the Installed parts of the conditions above are there to ensure that the condition is always true after installation – so you don’t get the situation that the setup will not allow itself to be uninstalled or repaired because a launch condition is not met. The condition: Installed – will always be true except for a fresh install and major upgrades.
NOTE: I am not sure whether launch conditions can cause trouble during administrative installations. I don’t think they do (an administrative installation features its own installation sequences). I will test and verify tomorrow. Adding OR ACTION="ADMIN" should make the launch condition true on any box when administrative installation is run.
Feature Conditions: If you don’t want to abort the setup, but rather want to control feature installation status based on evaluating these conditions, you need to use the feature conditions concept instead of the launch condition concept.
When you set the Feature level to 0 in your WiX source, the feature is not show in the setup GUI and it is not going to be installed by default either. A feature condition can change this and set the feature to install if the condition evaluates to true.
You can also go the other way around and set the feature level to 1 as default (this should install the feature) and then use a feature condition to set its Feature level to 0 – if you don’t want the feature installed – when the condition is true.
There are some further details under “Quick Mockup” here: WIX If…else condition using registry.
In the below WiX snippet we set a feature to install by default (Level="1") and then we use a feature condition to set the feature to not install if its associated condition evaluates to true (this is a multi-part condition). So once the condition evaluates to true we assign feature Level="0" (which means do not install feature and hide it from the setup GUI):
<Feature Id="MyFeature" Level="1"> <!--Default to install feature-->
<Condition Level="0"> <!--Do not install feature if condition is true-->
((MsiNTProductType=1) OR (MYKEY="MyValue") OR (MYSERVICE="MyService" AND MYKEY="") AND (NOT ACTION="ADMIN"))
</Condition>
</Feature>
The AND (NOT ACTION="ADMIN") part is to force the feature to be installed in an administrative installation. It effectively shuts off the other conditions from evaluating to true if the setup is run in administrative install mode – which would cause the feature to not be installed during the admin install. This last part I have to test tomorrow.
UPDATE: Testing indicates that any feature set to
Level=0as default will not be extracted during an administrative install at all,
regardless of any feature conditions setting the feature to install. I
guess the tentative conclusion is to not set any features to
Level=0, but setLevel=1and then set them toLevel=0with a
feature condition that evaluates to true. This way the feature may be
hidden in a regular installation, but all features – with associated
files – are extracted during admin installation. TheAND (NOT ACTION="ADMIN")part of the condition appears to not be needed.
Leaving the sample above as it is for now.
Links: