Overview of Actions and Action Sequences
An action encapsulates a typical function performed during the installation, uninstall or maintenance of an application.
An Action Sequence is the order in which those actions are executed. Windows Installer has many built-in standard actions.
Developers of installation packages can also author their own custom actions. Install Time™ allows an installation developer
control over action attributes such as text displayed to the user, the order in whcih an action is executed, and any condition
which determines if an action should be executed.
Action sequences specify the order of execution for the standard and custom actions that control the installation
process and display the user interface dialog boxes. There are five execution sequences of installation which are
executed based on privilege or installation state.
The three separate installation modes currently supported by the installer are:
• Install Execute
• User Interface
• Advertised Execution
Install Execute and User Interface action execution varies depending on execution privilege. Each can run as a normal user or elivated with administrative privileges. What actions are executed in each sequence differs depending on privilege level the installation is executed under. Within Install Time™ simply use the "Installation Sequence" drop down to view what actions are executed under each condition. Once you have selected the appropriate sequence actions can be added, deleted or the order of operation can be modified. The sequence templated provided by Install Time™ follow best practices for Windows Installer authored installs and care should be given when modifying the order of operation.
Windows Installer provides many built-in actions for performing the installation process referred to as "standard actions".
Examples of installer standard actions include:
• CreateShortcuts action: Manages the creation of shortcuts to files installed with the current application. This action uses the Shortcut table for its data.
• InstallFiles action: Copies selected files from the source directory to the destination directory. This action uses the File table for its data.
• WriteRegistryValues action: Sets up registry information the application requires in the registry. This action uses the Registry table for its data.
Within Install Time™ any standard action can be deleted from, moved up or moved down within an exection sequence by selecting the action and using the appropriate ribbon bar buttons. If an action is deleted it will become available on the left hand side of the interface in the available actions list. This allows the action to be re-added at some future point in time. In the properties window the action attributes can be modified as desired. This includes the Action text (text displayed to the end user within a progress dialog), A localized format template that is used to format action data records to display during action execution. If a template is not supplied, then the action data is not displayed.
While Windows Installer does provide many built-in actions for performing the installation process it was designed to
be extensible so that when situations arise that require special casing a developer can create custom actions to perform the specialized tasks.
Some of examples include:
• Launching an executable during installation that is installed on the user's machine or that is being installed with the application.
• Calling special functions during an install, uninstall or maintenance that are defined in a dynamic-link library (DLL).
• Call custom scripts such as Visual Basic or JScript during an installation, uninstall or maintenance.
• Defer the execution of some actions until the time when the installation script is being executed.
• Perform custom application level configuration post installation
• Perform custom application clean up at uninstall
• Perform additional health check of the application during maintence
Install Time Actions
Install Time™ actions are custom actions which Savage Fly has written. These actions standardize the approach
to many common tasks that are preformed in real life scenerios and eliminates the need for Install Time™ Users to create their own.
Call Custom DLL action: Allows the installation author to call custom DLL funcitons passing in parameters receiving return values which in turn set Windows Installer properties To configure a custom DLL call, simply select the "Actions" tab and from the left hand list drag the "Call Custom DLL Method" action and postion at the appropriate sequence in the execution sequence. Configure the properties of the DLL cusotm call in the properties window, including: the name of the binary file, the function desired to be called, list any parameters to pass to the function and set the return property name and value type. Additionally the author may set the binary type (32 or 64 bit) by selecting true or false under the "Behavior" section within the property view. Conditions can by applied that will determine if the DLL call will exectue as well as scheduling options are available to determine if the call should be made only during specific installation execution times (i.e. only during deferred, commit or rollback).
A few actions deserve special mention due to their impact on the end user who is installing an application.
It is important that an installation author understand the following actions before including these actions into an installation.
• ForceReboot action: This action prompts the user for a restart of the system during the installation and is different from the ScheduleReboot action in that the ScheduleReboot action is used to schedule a prompt to restart at the end of the installation. If the installation has a user interface, the installer displays a dialog box at each ForceReboot action which prompts the user to restart the system. The user must respond to this prompt before continuing with the installation. If the installation has no user interface, the system automatically restarts at the ForceReboot action. If the installer determines that a restart is necessary, it automatically prompts the user to restart at the end of the installation, whether or not there are any ForceReboot or ScheduleReboot actions in the sequence. For example, the installer automatically prompts for a restart if it needs to replace any files that are in use during the installation.
• ScheduleReboot action: Insert the ScheduleReboot action into the action sequence to prompt the user for a restart of the system at the end of the installation. If the installation has a user interface, by default, the installer displays a message box and button at the end of installation asking whether the user wants to restart the system. The user MUST respond to this prompt before completing installation. If the installation has no user interface, the system automatically restarts at the end.
• RemoveExisitingProducts action: The RemoveExistingProducts action goes through the product codes listed in the ActionProperty column of the Upgrade table and removes the products in sequence by invoking concurrent installations. For each concurrent installation the installer sets the ProductCode property to the product code and sets the REMOVE property to the value in the Remove field of the Upgrade table. The installer only runs the RemoveExistingProducts action the first time it installs a product. It does not run the action during a maintenance installation or uninstallation.
In order to author an installation to remove existing products, select "Project" from the top tabs and the "Properties" button. Under "upgrade entries" an author can select the "Add" button to specify how upgrades will be performed for previous releases. The simplest approach is to select "import" and browse to your previous installation. This will prepopulate the information required for Windows Installer. For each previous version, an author can determine if they would like to migrate the feature state (i.e. only install the features that were previously installed), remove features that were in the prior version, or simply detect if a prior version was installed but not remove it.
Caution should be used when selecting "Continue installation even if previous versions fail to remove" since most applications may not function as expected. Only select this option if you are sure that multiple versions of the product can safly run side by side.
• DisableRollback action: Disables rollback for the remainder of the installation. Rollback is disabled only for the actions that are sequenced AFTER the DisableRollback action. Rollback is disabled for the entire installation if the DisableRollback action is sequenced before the InstallInitialize action. To author the disabling of rolling back actions within Install Time; select the "Actions" tab and add the "DisableRollback" action from the left hand list and position appropriately within your actions sequence. Any action that takes place after this sequence will not be executed if a rollback is required.
• ResolveSource action: determines the location of the installation source files (i.e. cabs) and sets the SourceDir property. This is required for the installation and maintence installations to execute correctly if the source location is not yet set. This action MUST come after the CostInitialize action and should NOT be executed when the source is unavailable, as it may be when uninstalling the application. ResolveSource requires that the original installation source is available whenever it is called. If your installer package is authored correctly, source must only be resolve in cases where the original RTM files are missing or during some patch uninstall scenarios. Before adding ResolveSource Action to your installation it is suggested that you see Preventing a Patch from Requiring Access to the Original Installation Source for more information.
• InstallSFPCatalogFile action: installs the catalogs used by Windows Me for Windows File Protection. If you don't need to support SFP on WinMe, you can generate package for all platforms. If you need to support SFP you must create a second package without SFP support for Win2000 and later. Within Install Time™ you can generate both packages within the same project with the use of automation.