0

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.

  • UpCo = Upgrade Code
  • PrCo = Product Code
  • PaCo = Package Code

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.
Sebastian Schülke
  • 93
  • 1
  • 5
  • Can we ask how you decided to solve this issue? If the products aren't that different in size, one option is to merge them to a single installer and use any application license keys to "unlock" the pro features after installation. You can also add a separate feature that is added to the basic installation if the pro version license is entered. – Stein Åsmul Sep 04 '17 at 19:42

1 Answers1

1

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
Michael Urman
  • 15,737
  • 2
  • 28
  • 44
  • Thanks for the answer. So I can use MsiGetProductInfo to get the Package Code by using INSTALLPROPERTY_PACKAGECODE. But I don't know how to get the Product Code of the previous installed version. When I use the UpgradeTable related property it is only working for a major upgrade. Otherwise it is empty. – Sebastian Schülke Feb 01 '17 at 17:03
  • 1
    Why do you care about PackageCode? It must be different for every new MSI you build that is an update, upgrade, patch etc. – PhilDW Feb 01 '17 at 19:09
  • You are right. The package code is always different. So I just have to check for the same Product Code. But how do I get the Product Code. Like I wrote before, the Upgrade Table is empty when MyApp BASIC version 2 ist installed and I run the MyApp PRO version 2 installer. – Sebastian Schülke Feb 02 '17 at 10:22
  • Only product codes other than yours can be found via the Upgrade table (Major upgrade items). When the product code is shared, INSTALLED is true, and you are in small update / minor upgrade land. I will clarify that in my first bullet I assumed that the product code would also be changed. – Michael Urman Feb 02 '17 at 13:11