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?
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 theCustom 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 theCustom 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 clickAll Error Messages
andVerbose Output
and type a file name in theLog File
box. ClickOK
. 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: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:
And now the list. To my knowledge feature selection can be affected by (at least) the below mechanisms:
msiexec.exe
Command Linemsiexec.exe command line
.ADDLOCAL
andREMOVE
, but others can also be used (see above link).msiexec.exe /i MySetup.msi ADDLOCAL="Core,English,German,SDK"
msidbFeatureAttributesFollowParent
).INSTALLLEVEL
.INSTALLLEVEL
.INSTALLLEVEL
.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).INSTALLLEVEL
).Feature Table
.Condition table
usingConditional 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.INSTALLLEVEL property
, then the feature is set to install.ADDLOCAL
,REMOVE
,etc...
. There is a whole family of properties.MsiGetFeatureState
andMsiSetFeatureState
. Common in Installscript.Session.FeatureRequestState
andSession.FeatureCurrentState
CostInitialize
. See link directly below.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 theUpgrade table
- and it can hence affect feature states differently in different setups.MigrateFeatureStates
can be disabled by various other mechanisms.Some Links: