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:\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. A slightly better approach in my view is here. Your setup could be using some of these techniques.

---

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)

Answer 2

Short Version:

• Feature F might be set as a required feature for Feature 1 (and possibly others).
• Please check the Required Features value for Feature 1.
• To do so, just go to the Features view and select Feature 1 - then look at the Required Features value. If Feature F is listed there, then that would cause the behavior you see.

---

Error, Error - The Matrix's Got You :-): I wrote a long answer on how feature selection can be affected by many things for Basic MSI projects, but reading your question again I am almost convinced this is an Installscript MSI project and not a Basic MSI project at all, and the reason is the feature dialog behavior that you describe.

Installscript MSI: The top left of the Installshield application window will reveal the project type. It will say something like: "My Project Name-1 - Installshield [InstallScript MSI Project]. Could you please verify what it says? (the last part - inside the brackets - is the key). The handling of features is quite different in the two project types. Installscript MSI projects features custom Installshield dialogs (Win32 dialogs), versus the standard Windows Installer dialogs of Basic MSI projects (defined in tables). I dislike Installscript MSI projects intensely - I find them buggy, but they do have some nice features. I would not use them though. Subjective opinion. Basic MSI projects are standard MSI files and much better for corporate deployment.

"Required Features": When you view the features view in Installshield for an Installscript MSI project, you have more options available than for a Basic MSI project. The Required Features setting in particular wraps a lot of functionality to allow features to be interdependent of each other - something that has to be implemented by yourself in Basic MSI projects in quite a different way. This field is the key to the feature selection behavior you are seeing - I am pretty sure of that. See below for suggested approach forward.

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.

Summary:

1. I would verify what the project type really is. Installscript MSI - probably.
2. Upon verifying that it is an Installscript MSI project, I would open the Feature view and check the Required Features value for each feature in sequence.
3. My guess is that all the logic is "automagic" from Installshield - you simply define for each feature what other features it requires by tweaking the "Required Features" value.
4. It would seem that as long as you don't require any other logic, Installshield takes care of the feature selection "automagically" and you get a fully functional feature selection dialog - provided you have defined feature dependencies correctly.
5. I have not done any customization of Installscript MSI dialogs, so I can't really help you there outright, but I am pretty sure tweaking the "Required Features" value should be a good starting point to figure out what you need.
6. Could you also please check the Installscript view to see if there is any custom code there related to the GUI? And you might want to check the Custom Actions & Sequences view as well - to check for any custom logic implemented in other ways (VBScripts, PowerShell, JavaScript, etc...).