InstallShield 2012 Spring 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. The In-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 product's 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 place between 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
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, 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 be made 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.
See Also
Changing When Custom Actions Are Launched
InstallShield 2012 Spring Express Edition Help LibraryMay 2012 |
Copyright Information | Contact Us |