wix - Unselected Feature Being Installed

Question

I've been shoved into a DevOps position at work with very little knowledge about InstallShield or what I'm doing. Everything I've learned I've learned by doing and reading Flexera's documentation. One of our tickets is a problem that I haven't been able to find results for when Googling - I'm probably using the wrong search terms, but don't know what the right ones are.

Basically, our installer has a buttload of features. Some of these features have sub-features, which are always installed if you select the main feature. Everything is set to be installed by default, but you can disable any of the features. They're meant to be completely standalone if you want them to be. Feature 1's sub-features are visible in the installer (though you can't deselect them, or select them separately from Feature 1), but Feature 4's are not.

|- FEATURE 1
|---- FEATURE A
|---- FEATURE B
|---- FEATURE C
|- FEATURE 2
|- FEATURE 3
|- FEATURE 4
|---- FEATURE D
|---- FEATURE E
|---- FEATURE F
| ...

Feature F has exactly one component under it. That component installs a whole bunch of DLLs and config files - not best practice, but also not something I can change in the scope of this issue. When looking at the feature list for the component, it's set to only Feature F. It - and it's containing folder - don't show up when looking at the files for any other feature.

Feature F is being installed when you select Feature 1 as the only option. It might happen with other features as well, but Feature 1 is the fastest to install so it's been tested with the most.

It's a Basic MSI project. I tried to get InstallShield to create a log by setting the 'Create MSI Logs' option to yes, but it didn't generate a log file when I ran through a test install by running Setup.exe. I went through the scripts in the UI and Execute install sequences and it didn't look like anything was selecting Feature F.

Am I missing a spot where features can be linked to each other - and if so, where?

Answer 1

Attempted Specific Answer:

Custom Actions: Based on the available information (0 conditions), I would assume one or more custom actions are used to implement the feature logic you describe above. You should be able to find the custom action code in the project's Installscript view I would presume? (with an associated custom action entry in the Custom actions view).

It is also possible that Installscript is not used, but the logic is implemented in some other language (VBScript, C++, JavaScript, PowerShell, etc...) - in which case you should go directly to the Custom actions view instead and look for suspects. Source could be embedded in the custom action (scrips), or stored elsewhere (always the case for C++).

Logging: In order to enable logging, please try to open your project, then go to Build => Settings... => MSI Log File, now click All Error Messages and Verbose Output and type a file name in the Log File box. Click OK. Now try to build and run your project. Here is how to enable logging using msiexec.exe (outside Installshield). Concrete example; the logging command in its simplest form:

msiexec.exe /i C:PathYour.msi /L*v C:Your.log

---

UPDATE: I found this sample in Installshield's KDB (Q208877) (KDB). It uses some very odd feture selection techniques - please see the actual article for details. There is a downloadable ISM file.

I wasn't able to resurrect the above link from Wayback. However, perhaps this is the same article: Change Installation State of a Feature, Based on Another Feature's Selection State.

A slightly better approach in my view is here. Your setup could be using some of these techniques. That link was also not found in archives.

---

Attempted General Answer:

There is a whole list of mechanisms which can affect feature selection, and it is shown below. The below is primarily for Basic MSI projects, for Installscript MSI projects there are even more mechanisms available - largely Installscript functions. Before the list, some important tidbits:

• Feature names are case sensitive!
• The different mechanism below can definitely interfere with each other.

And now the list. To my knowledge feature selection can be affected by (at least) the below mechanisms:

1. Standard msiexec.exe Command Line
   • User can set feature installation options properties via the msiexec.exe command line.
   • Generally ADDLOCAL and REMOVE, but others can also be used (see above link).
   • Sample: msiexec.exe /i MySetup.msi ADDLOCAL="Core,English,German,SDK"
2. User Interaction Setup GUI
   • MSI GUI feature selection dialog (if available in setup).
   • Some setups (not all), have a "Custom" dialog which allows the user to select what features to install and not.
   • Visible features can be directly affected (and their sub-features - visible or not - depending on feature configuration - search for msidbFeatureAttributesFollowParent).
   • There are several possible feature states to set in some setups. Advertise feature, install feature, do not install feature, etc...
   • There could be custom actions running from the setup GUI which affects feature selection state (see custom action section below).
     • For example based on a user interaction selecting one feature, then other features could be selected - or unselected.
     • For Installscript MSI setups the logic for this is built-in (and also customizable). For Basic MSI setups it is possible to do something similar, but there is less automagic available.
3. INSTALLLEVEL
   • This mandatory setup property should be mentioned. It is the baseline determining whether a specific feature is to be installed or not. Every setup has an INSTALLLEVEL.
   • Every feature has its own level attribute and the feature will be installed if its level attribute is set to an equal or lower number than the setup's overall INSTALLLEVEL.
   • As a consequence one can affect the requested installation state for several features by adjusting the setup's INSTALLLEVEL.
   • A bad, but not uncommon practice, is to max out INSTALLLEVEL to 32767 to force all features to be installed. This is wrong because some features may not be compatible with the system (wrong files for wrong system).
4. Feature Conditions
   • As mentioned all features have a level attribute that can be manipulated via conditional statements that are evaluated at runtime.
   • This is related to the previous point, but it is the opposite: now we are changing each feature's level attribute, not the setup's own baseline feature level (INSTALLLEVEL).
   • See the level column in the Feature Table.
   • The actual conditional logic is in the Condition table using Conditional Statement Syntax. So conditions are evaluated and if they evaluate to true this affects the feature's install level.
   • AppSearch can be involved setting the properties that make up the feature conditions.
   • For each feature, if the feature's install level is lower or equal to the setup's INSTALLLEVEL property, then the feature is set to install.
5. Custom Actions
   • Custom actions are armed and dangerous (my propaganda against them), but sometimes they are the only option (you have something very specific you need done).
   • Custom actions can modify feature states in a number of different ways:
     • Feature state properties: they can manipulate properties such as ADDLOCAL, REMOVE, etc.... There is a whole family of properties.
     • MSI Win32 functions: they can call MsiGetFeatureState and MsiSetFeatureState. Common in Installscript.
     • MSI COM automation functions: Session.FeatureRequestState and Session.FeatureCurrentState
   • I believe all feature custom actions must run before CostInitialize. See link directly below.
6. MigrateFeatureStates
   • Finally I want to mention MigrateFeatureStates. A standard MSI action which will attempt to "reproduce" the installation state selected in your original install during a major upgrade scenario.
   • MigrateFeatureStates can be enab