8/7/2019 Action Execution Options

1/2

Action Execution Options

InstallShield 2011 Express Edition

Custom actions are executed in the order in which they appear in a sequence. Some actions need to be

scheduled to run immediately at the start of the installation; others need to be deferred for a later time. TheIn-Script Execution setting in the Custom Actions view enables you to select which iteration of the sequence

(deferred, rollback, or commit) should trigger your action. This setting also lets you specify the context for

deferred, rollback, and commit actions: actions can run in user context (with the privileges of the user running

the installation) or in system context (with elevated privileges). If this setting is not displayed for a particular

custom action in the Custom Actions view, that action is scheduled for immediate execution; immediate-

execution custom actions always run in user context.

Immediate Execution

As its name implies, immediate-execution custom actions 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 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 that is set for immediate execution is encountered, 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 that are 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 products

system requirements). 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 that is generated during immediate execution is

executed by the Windows Installer. After that script has been fully generated, the Windows Installer 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 that are being installed as part of the

installation. As a result, you can call a custom action that calls a function from a DLL file that is installed with

your product during this phase of the installation. However, deferred execution custom actions must take placebetween InstallInitialize and InstallFinalize in order to work properly.

Custom actions that rely on a file that is 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

8/7/2019 Action Execution Options

2/2

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 arollback 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 customaction that deletes the file, and schedule it for commit execution.

Deferred, Rollback, or Commit Execution in System Context

Like deferred execution actions, deferred-execution-in-system-context actions do not launch until the script

that generated by the Windows Installer is run. However, actions of this type execute with no user

impersonation.

Similarly, rollback-execution-in-system-context and commit-execution-in-system-context actions execute with

no user impersonation.

Because of the elevation of privileges on Windows Vista and later systems, deferred custom actions must bemade in system context if they need to make system changes that require elevated privileges. Deferred

custom actions in user context may not have elevated privileges even if an administrator runs the installation

on a Windows Vista or later system, and thus should be avoided for custom actions requiring higher-level

privileges.

Note

Custom actions that run in the system context generally do not have access to network resources.