CODEWITHSUNDEEP
windows-installerinstallshieldinstallscript
Sebastian Schülke
Sebastian Schülke

Reputation: 93

How to detect the change of the package code on updating (Small Update)

I have a product called MyApp. This product comes with different editions, like BASIC and PRO. Both editions have their own installer with the same version.

When I have installed the BASIC edition and run the PRO installer, I want InstallShield to detect this. The overall constellation is illustrated in the following image.

enter image description here

The black arrows are handled as Major Upgrades without a problem. The red arrows illustrate the issue.

Too detect this scenario I thought about checking for the changed package code. By the following link this scenario is defined as Small Update.

http://helpnet.flexerasoftware.com/isxhelp22/isxhelp22.htm#CSHID=helplibrary%2FUpgradeConsiderations.htm|StartTopic=helplibrary%2FUpgradeConsiderations.htm

  1. Is there a property like, IS_MINOR_UPGRADE or IS_MAJOR_UPGRADE, which I can use?
  2. Is it possible to find out the Package Code, Product code and Upgrade code of the previous and current installation? Then I could compare those values and respond to this scenario in InstallScript.

Upvotes: 0

Views: 574

Answers (1)

Michael Urman
Michael Urman

Reputation: 15905

Unless IS_MINOR_UPGRADE is set in this scenario, there is no such property. You might be able to write a custom action that examines the currently recorded information about the installed package (see MsiGetProductInfo), but you might quickly run into the limitations of which Windows Installer APIs you are allowed to call inside a custom action.

Assuming there are different files between your editions (that is, different names, not just different builds of the same file name) I think you're going to have problems moving both "left" and "right". Doing so is likely to orphan components on the machine going at least one of the directions. I would suggest using one of these alternative approaches:

  • Use a different product codes and perhaps also different upgrade codes (you can add multiple major upgrades to employ a similar strategy to the ISPreventDowngrade one in order to prevent side-by-side installs)
  • Refactor to smaller MSIs (e.g. one for shared files and one each for the various per-edition files; the latter may be mutually exclusive like in the previous bullet) perhaps distributed by a Suite/Advanced UI project, or
  • Use non-installer licensing in order to enforce your editions

Upvotes: 1

Related Questions