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?

Prance

Feature Condition is the place where you define the feature will be installed or not. You may create condition which would check if the other feature is marked for installation or not and set appropriate install level. More on Conditional Statement Syntax – Recoil

@SlavaIvanov Thanks! It says that there are 0 conditions for Feature F, as well as for all aspects of Feature 1. We have a dialog where you can select what gets installed using a TreeView, but it doesn't seem to have any events associated with it so I'm not sure where the install levels get set. – Prance

Well, you said Feature 4 and sub-features are not visible to UI, are you? If so you would need to use condition to set install level. Usually default install level is 100, which means if you set for the feature less then 100 it will be installed, if greater than 100 it will not be installed. – Recoil

Are you certain whether Feature F is getting installed, or whether files that you think are only part of Feature F are being installed? (It's possible for components to be multiply linked.) – Brought

I suppose kicking of modify from Add / Remove Programs will show whether the actual feature is installed or not? (if the feature dialog is present in the sequence). Hold Windows Key, tap R, type appwiz.cpl and press Enter. Now right-click your product and click Modify (or equivalent). – Oswaldooswalt

@MichaelUrman Feature F's component is definitely linked to only Feature F. I've triple checked that one, haha. – Prance

Just make sure at least one of those checked the built .msi file, as dependency scanning can result in changes you cannot see in the project. – Brought

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.

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)

Gyro

Still not sure where Feature F was being installed, but used this answer to develop a workaround in our GetFeatureState script until crunch time is done and someone else can take a look. Thanks! – Prance

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...).

Gyro

It's definitely a Basic MSI project. Nothing in Installscript that modifies the UI. It doesn't look like there's anything in the custom actions either - just the same InstallScript files. – Prance

So it says Basic MSI Project in the title bar of the application (top left)? What about the Features view, is there a value called Required Features in the property list in the rightmost pane? I don't think there is any way to modify feature selection like you describe in a Basic MSI Project - then you need a lot more code and logic written by yourself. – Oswaldooswalt

Hold on, what edition of Installshield are you in? Maybe you are in one of the limited editions? Express or Lite or whatever they call it these days? And while we are at it, what version? – Oswaldooswalt

It says Basic MSI Project in the title bar, and there's no value called Required Features in the features view. I'm using 2016 Professional. Looking again there's an InstallScript file that determines what features are selected, but it doesn't have an entry for Feature 4 or any of its sub-features. – Prance

Maybe you have resolved this problem then? If not, is that a big Installscript file? Ideally we would need to see the code. Any mention of ADDLOCAL in the code? Are you sure that is not just a launcher Basic MSI? Do you have a screen shot of the feature selection dialog? I will have a look later, and see if my original answer (that I never posted) makes any sense. It has been ages since I used Installshield. Perhaps also ask for help here: community.flexerasoftware.com (unless you are already there). Does your company have a support agreement with Installshield? – Oswaldooswalt

I have added the long answer I wrote first since you say this is a Basic MSI project. Are you sure it is not just a launcher Basic MSI project though? (and that it kicks off an Installscript MSI setup). If we can see a screen shot from the setup's feature selection dialog - that could be revealing. – Oswaldooswalt