Installshield 2011 Minor Upgrade Directory bug?

[Peter_Kosenko]

I have converted an InstallShield 2008 InstallScript-MSI project to 2011. Without having done anything to Minor Upgrade, suddenly one of the directories is being RESET to the default INSTALLDIR during Minor Upgrade. It should be something like INSTALLDIR ^ "datadirectory" (properly defined in the directory table). What makes me think this is a giant BUG is that I tested resetting the "CUSTOMDIR" property during OnResumeUIBefore and the directory is being reset AFTER that. This was not happening in any of the InstallShield 2008 installers we have. It is a KILLER bug. It basically ruins any ability to convert 2008 installers without ruining Minor Upgrade in them. And that would mean having to rebuild all installers from scratch?:(

[Peter_Kosenko]

Here's the verbose log entry where the error is occuring.

MSI (s) (0C:24) [20:13:51:148]: PROPERTY CHANGE: Modifying APPDATA property. Its current value is 'C:\Program Files\SEER\SEER-H 7.1\AppData'. Its new value: 'C:\Program Files\SEER\SEER-H 7.1'.

My question is what action is that associated with?

It Occurs after CostFinalize, when there are a bunch of property change actions.

MSI (s) (0C:24) [20:13:51:148]: Doing action: CostFinalize
Action ended 20:13:51: IsolateComponents. Return value 0.

But nothing in the InstallScript actually SETS the APPDATA directory property to the application's ProgramFiles directory. It just seems to be "happening."

[joshstechnij]

This behavior is a function of how CostFinalize resolves Directory table entries for components that have directory or file key paths. If the destination or the keypath of a component has changed in a scenario where the product code does not change, this behavior will occur. For example:
- MSI v1.0 installs test.txt to Directory table entry INSTALLDIR (Component table Directory_ field is set to INSTALLDIR), and INSTALLDIR resolves to C:\Program Files\My Product at runtime

- MSI v1.1 changes the destination of the component installing test.txt from INSTALLDIR to SystemFolder (Component table Directory_ field is now SystemFolder). When CostFinalize runs and MSI v1.0 is installed on a machine (putting this package into a maintenance type install), the SystemFolder directory, which would normally resolve to C:\Windows\System32, will be changed to C:\Program Files\My Product. So any other component that may install to SystemFolder is now going to be installing to C:\Program Files\My Product.

This behavior is mostly a result of breaking component rules for minor upgrades. Existing component destinations and keypaths cannot be changed without also changing the component code, which would necessitate changing the product code.

If the APPDATA directory is resolving incorrectly in this upgrade, get a diff of the latest MSI to the base MSI and look for any changes to the Directory table hierarchy or changes to any existing component Directory_ or KeyPath columns (especially component Directory_ fields that are now APPDATA but were some other value before). Any differences on existing components should be removed unless the product code is changed (to create a major upgrade).

[Peter_Kosenko]

It must have had something to do with migrate feature states during minor upgrade. The installer was not migrating the APPDATA directory value; it was resetting it as default INSTALLDIR. I don't know why. It might be because the one component that used that directory had only one file (the raw INI for the program, which the program then configures for individual users when they start up from their profiles). In any case, I did not notice that we had a problem migrating the directory in InstallShield 2008. The solution here was to just let the installer do what it wanted and then RESET the DIRECTORY as INSTALLDIR ^ "AppData" (this is always the value) with a directory custom action after MigrateFeatureStates.

[joshstechnij]

Please note that resetting the incorrect folder path at runtime with a set property action is not recommended. If this folder has any subfolders, they will not be updated when this property is changed. In addition, this technically indicates a target path is being changed in a maintenance scenario, which is not allowed by Windows Installer.

It is highly recommended that any issues with the Directory and/or Component tables be addressed to resolve this behavior. The MsiDiff utility can be used to determine what changes have occurred in these or other tables between two MSI files. These differences can be used to correct the project file so that the undesired changes are eliminated from the built MSI package.

Also note that if you are seeing Directory or Component table entries changed or dropped during project migration, please let us know so that we can investigate the issue further. Note that a project file that reproduces this behavior would likely be required as we have not seen this behavior in house when migrating any MSI projects.