What are custom actions?

The Windows Installer provides many built-in standard actions for performing the installation process.

Standard actions are sufficient to execute an installation in most cases. However, there are situations where the developer of an installation package finds it necessary to write a custom action. The actions written to perform specific tasks is called is custom actions.

Standard Action

An action encapsulates a typical function performed during the installation or maintenance of an application. Windows® Installer has many built-in standard actions. Developers of installation packages can also author their own custom 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.

Why & When to write custom actions?

• One want to launch an executable during installation that is installed on the user’s machine or that is being installed with the application.
• One want to call special functions during an installation that are defined in a dynamic-link library (DLL).
• One want to use functions written in the development languages Microsoft Visual Basic Scripting Edition or Microsoft JScript literal script text during an installation.
• One wants to defer the execution of some actions until the time when the installation script is being executed.
• One wants to add time and progress information to a ProgressBar control and a TimeRemaining Text control.

How to write a custom action & Where to place it?

There are 3 ways to write a custom action 1. VBScript 2. Wise Script 3. Jscript

Identifying the Customization (Task)

Now first identify the task to customize. If the customization is needed during installing the application like detecting Operation System Language & then redirecting a particular file or shortcut to a particular folder (E.g. set property or set directory during installation). This can be done in Execute Immediate Section. Immediate custom actions, on the other hand, can be sequenced anywhere within any of the sequence tables. Immediate CA have access to the installation database and can read and set installation properties, modify feature and component states, and add temporary columns, rows, and tables among other things.

For deleting a file or folders (i.e. making the changes to system context) write the custom action in Execute Deferred. Deferred CA can only be sequenced between the InstallInitialize and InstallFinalize actions in execute sequence tables. Deferred custom actions cannot access the installation database. In fact, deferred CA have very limited access to the installation session because an installation script can be executed outside of the installation session that created it. Deferred custom actions are not executed immediately. Instead they are scheduled to run later during the execution script. The execution script isn’t processed until the InstallExecute, InstallExecuteAgain, or InstallFinalize action is run. Deferred custom actions should be used when the custom action must make a change to the system or call another system service. Additionally, only deferred custom actions can run in an elevated context. If the custom action requires elevated privileges in order to run, then that custom action needs to be marked as deferred.

Advanced information about Custom Actions

Additionally, when making a change to the system by means of a custom action, it is recommended to include a rollback custom action that can undo the change. While both deferred and immediate custom actions can run in the context of the user initiating the installation, only deferred custom actions can run elevated using the system context.  The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed. This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table. A deferred execution custom action enables a package author to specify system operations at a particular point within the execution of the installation script. The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead the installer writes the custom action into the installation script. The only mode parameter the installer sets in this case is MSIRUNMODE_SCHEDULED.

A deferred execution custom action must be scheduled in the execute sequence table within the section that performs script generation. Deferred execution custom actions must come after InstallInitialize and come before InstallFinalize in the action sequence. Custom actions that set properties, feature states, component states, or target directories, or that schedule system operations by inserting rows into sequence tables, can in many cases use immediate execution safely. However, custom actions that change the system directly, or call another system service, must be deferred to the time when the installation script is executed. Because the installation script can be executed outside of the installation session in which it was written, the session may no longer exist during execution of the installation script. This means that the original session handle and property data set during the installation sequence is not available to a deferred execution custom action. Deferred custom actions that call dynamic-link libraries (DLLs) pass a handle which can only be used to obtain a very limited amount of information, as described in Obtaining Context Information for Deferred Execution Custom Actions.

Note that deferred custom actions, including rollback custom actions and commit custom actions, are the only types of actions that can run outside the users security context.