In-Script Execution
InstallShield 2020
Project:This information applies to the following project types:
| • | Basic MSI |
| • | DIM |
| • | InstallScript MSI |
| • | Merge Module |
| • | MSI Database |
| • | MSM Database |
| • | Transform |
When you create a custom action, one setting that must be configured is the In-Script Execution setting on the Respond Options panel of the Custom Action Wizard. Actions are executed in the order in which they appear in a sequence. However, the sequences are run many times during a typical installation. The In-Script Execution setting enables you to select which iteration of the sequence will trigger your action.
(Terminal Server Aware)
If you select a Terminal Server Aware option—for example, Immediate Execution (Terminal Server Aware)—the custom action impersonates the end user during per-machine installations on terminal server machines.
Immediate Execution
As its name implies, Immediate Execution runs when the internal Windows Installer installation script is being compiled. When an .msi file is launched, the Windows Installer service converts all the tables in the installation database into an internal script. (This internal script is not the same as InstallScript code.) This script is built by cycling through all the actions in the installation in the order in which they appear. The building of this script is immediate execution. When an action is encountered whose In-Script Execution setting is set to Immediate Execution, that action is executed. Therefore, this action launches before any file transfers are encountered, possibly even before the end-user interface for the installation is fully loaded.
As a rule, custom actions scheduled for immediate execution do not modify the target system, but only set properties and query the target system (for example, to see if the target system meets your product’s ). Custom actions that set Windows Installer properties must be scheduled for immediate execution, and custom actions that occur in the User Interface sequence must be scheduled for immediate execution.
Because actions of this type run before any changes have been made to the system, they cannot rely on files that are being installed by the installation.
Deferred Execution
Deferred Execution takes place when the internal script generated during Immediate Execution is executed by the Windows Installer service. After that script has been fully generated, the Windows Installer service runs the newly compiled script. The script runs through all of the actions in your sequences and executes them in order. However, if an action is scheduled for immediate execution, the action does not run again during Deferred Execution.
Actions that launch during Deferred Execution have access to files being installed as part of the system. As a result, you can call a custom action that calls a function from a DLL file installed with your product during this phase of the installation. However, Deferred Execution custom actions must take place between InstallInitialize and InstallFinalize in order to work properly.
Custom actions that rely on a file being installed to the target system, or that rely on other system changes to have already been performed, must be scheduled for deferred execution.
Rollback Execution
Rollback occurs when an error is encountered by the installation or the end user cancels the installation before it has a chance to complete. The Rollback Execution option allows you to set your action to execute only during rollback. Therefore, any actions that are enabled for Rollback Execution are written to the installation script, as are Deferred Execution actions. Unlike Deferred Execution actions, Rollback Execution actions launch only during rollback. (Rollback custom actions run only if the installation fails during deferred execution.)
Any custom actions that make changes to the target system during an installation should be undone with a Rollback Execution custom action in the event of rollback. For example, if you have a custom action that creates a file, you should create a second custom action that deletes the file, and schedule the second action for rollback execution. (A rollback custom action should be scheduled before the custom action it reverses.)
Commit Execution
Commit Execution actions do not run until the InstallFinalize action completes successfully. This means that they wait until the installation has completed transferring files, registering COM servers, and creating shortcuts and registry entries. Then, any actions that are set to Commit Execution launch in the order in which they appear in the sequence.
For example, if you have a custom action that creates a temporary file, you should create a second custom action that deletes the file, and schedule it for commit execution.
Deferred Execution in System Context
Like Deferred Execution actions, these actions do not launch until the script generated by the Windows Installer service is run. However, actions of this type execute with no user impersonation.
See Also
Inserting Actions into Sequences
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties