Major upgrade automatically uninstalls the existing version and installs the current one.
Unfortunately Major Upgrade is only available for the following Project types: - Basic MSI - InstallScript MSI - MSI Database - Transform
It is not available for the 'InstallScript' project type. How can we achieve what Major Upgrade offers in the 'InstallScript' project type. We want to basically automatically uninstall existing version before proceeding with the current installation.
I tried to use UninstallApplication InstallScript function as well as invoking msiexec from the InstallScript code to manually uninstall before proceeding with the install but these two approaches present two dialog boxes. One to confirm with the removal of the product and other once done removing where you click on the Finish button to exit the uninstallation.
We want what Major Upgrade offers which is no dialogs popping up.
We cannot use 'InstallScript MSI' project type since we are running into some issues with this project type.
Also, we do not want to convert our existing 'InstallSript MSI' project to 'Basic MSI' since we want to reuse the installscripts we have and converting to 'InstallScript' project type would allow us to do so.
thanks for your response Stein.
For Basic MSI, I see below documented from InstallShield. Its seems a drawback not to be able to preserve information using some global variables. Currently we have the 'InstallScript MSI' project and we have installscripts in place which maintains info using global variables. For example, we may lookup and store something and based on that dynamically change checkboxes in the dialog, etc. We also look up and store info that is used later when installscript functions get executed at different stages. But seems with 'Basic MSI' each custom Action calling an InstallScript function is standalone in the sense that what it discovers and sets cannot be used by another custom Action call to another InstallScript function. Any thoughts?
Basic MSI:
Global variables and pointers are no longer maintained between individual InstallScript custom action calls. In addition, each InstallScript
custom action initializes and uses its own individual SUPPORTDIR. Therefore, you cannot share information across individual calls using files
in SUPPORTDIR. For more information, see Global Variables, Global Pointers, and SUPPORTDIR.
Global Variables, Global Pointers, and SUPPORTDIR
With InstallShield 12 and later, when a Basic MSI installation executes an InstallScript custom action, the compiled InstallScript is loaded
before the action is called, and it is unloaded after the action completes. Thus, each InstallScript custom action executes in its own
session with complete InstallScript engine loading and unloading. This behavior is different than with InstallShield 11.5 and earlier: the
compiled InstallScript was loaded once before the first InstallScript custom action that was used by the InstallScript was executed, and it
was unloaded at the end of the installation after all InstallScript custom actions were completed.
A major implication of this change in behavior is that global variables and pointers are no longer maintained between individual
InstallScript custom action calls:
• If you need to store a value across multiple custom action calls, you must use some external mechanism such as the registry, Windows
Installer properties, or an external data file to store the information between calls. If you choose to use Windows Installer properties in
deferred, commit, or rollback InstallScript custom actions, see the guidelines in Windows Installer Properties and Deferred, Commit, and
Rollback InstallScript Custom Actions. • If you need to use a COM object or some other global object across custom action calls, you must initialize the object for each
individual custom action call in order for the object to be valid. Another implication of this change is that each custom action initializes and uses its own individual SUPPORTDIR. Therefore, you cannot share
information across individual calls using files in SUPPORTDIR, since each custom action invocation will have its own unique SUPPORTDIR. You
can share information using FOLDER_TEMP or some other file location.
Note that FOLDER_TEMP may not be the same path for all of your InstallScript custom actions. If you have some InstallScript custom actions
that run in system context and some that do not, they will have different temp paths if the package is running in an elevated state. The
InstallScript custom actions run in the context of a different user, so storing files in the temp directory and retrieving it later may not
work in certain scenarios.
