Unselected Feature Being Installed

by

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:\Path\Your.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 enabled or disabled for a setup, based on settings in the Upgrade table – and it can hence affect feature states differently in different setups.
    • PhilDW reminded me that MigrateFeatureStates can be disabled by various other mechanisms.

Some Links:

  • Recommended: Here is a short explanation of feature manipulation of various kinds: How to install feature based on the property set in custom action?
  • More on Features: There is a section called “2. MSI Features” in this long answer which deals with a different topic (WiX), but the logic is generic with regards to features – it tries to explain feature conditions: Wix Installer : Setting component condition property when doing a MSIEXEC admin install at command line
  • Some related answers:
    • Unselected Feature Being Installed
    • Manually migrate feature states during upgrade
    • ADDLOCAL=FEATURE1 in MSI installer removes other FEATURES
    • Windows Installer does not install feature and does not report an error. (Request: Null)

Leave a Comment

tech