This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Custom Action does not run on Upgrade
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Dec 12, 2008
02:12 PM
Custom Action does not run on Upgrade
IS2009, SP1
I have a Custom Action that runs an external VBScript. The VBScript searches the running processes, displays a list of qualifying programs that are running and then aborts the install. This CA works fine on a fresh installation of the program, but when running and upgrading an existing installation, the CA does not seem to run.
I have tried altering the Execute Sequence, but to no avail. Does anyone have any suggestions?
I have a Custom Action that runs an external VBScript. The VBScript searches the running processes, displays a list of qualifying programs that are running and then aborts the install. This CA works fine on a fresh installation of the program, but when running and upgrading an existing installation, the CA does not seem to run.
I have tried altering the Execute Sequence, but to no avail. Does anyone have any suggestions?
(6) Replies
‎Dec 15, 2008
08:27 AM
Do you have conditions set on the CA? How are you running an upgrade?
‎Dec 15, 2008
09:36 AM
Thank you Kathy. No conditions are being set. The upgrade is a minor upgrade, running the same installation package as installed previously, just changing the version number, delivering a few new files, and I have added this CA. This is a 2009 Install Script project, running as a compressed EXE. Running the upgrade by simply double clicking on teh setup.exe, no command line parameters. Does that make sense?
‎Dec 16, 2008
08:21 AM
Have you tried running it with logging? That may tell you why the CA is being skipped.
If you haven't, you might also want to validate the install to see if that reveals any issues.
If you haven't, you might also want to validate the install to see if that reveals any issues.
‎Dec 30, 2008
08:56 AM
Thanks for your reply Kathy, sorry for the delay in answering, I took a long week off for the Christmas break. Anyway, Yes, I did try logging and the response is;
I have searched for this response and have found little to help me with a fix.
Action 'IsAppRunning' is not permitted in a restricted engine.
I have searched for this response and have found little to help me with a fix.
‎Dec 30, 2008
11:26 AM
The log message you are seeing is due to a limitation in how InstallScript MSI projects run the install UI sequence of the MSI package. Basically, they manually walk through the records in the InstallUISequence table, and each action whose condition evaluates to true is run (with a few exceptions). Unfortunately, the Windows Installer engine will not allow certain things to occur in the environment set up by the InstallScript engine in upgrades for InstallScript MSI setups. Specifically, the engine calls MsiOpenPackageEx to obtain an install handle and access the MSI database. In a minor upgrade, the script engine tells this API to ignore the machine state in order to successfully open the MSI package. Per the MsiOpenPackageEx documentation:
To be able to run this action (or any other DLL, EXE, or Script actions) in a minor upgrade, it would need to be sequenced in the install execute sequence.
Note that if dwOptions is MSIOPENPACKAGEFLAGS_IGNOREMACHINESTATE or 1, MsiOpenPackageEx ignores the current machine state when creating the product handle. If the value of dwOptions is 0, MsiOpenPackageEx is the same as MsiOpenPackage and creates a product handle that is dependent upon whether the package specified by szPackagePath is already installed on the computer.
The restricted handle created by using MsiOpenPackageEx with MSIOPENPACKAGEFLAGS_IGNOREMACHINESTATE only permits execution of dialogs, a subset of the standard actions, and custom actions that set properties ( Custom Action Type 35, Custom Action Type 51, and Custom Action Type 19). The restricted handle prevents the use of custom actions that run Dynamic-Link Libraries, Executable Files or Scripts.
To be able to run this action (or any other DLL, EXE, or Script actions) in a minor upgrade, it would need to be sequenced in the install execute sequence.