[This is preliminary documentation and subject to change.]
Custom actions obtain information about the current install by using the database access functions. A custom action can obtain a handle to the active database. This handle allows the custom action to query and update the data in the various tables. Some data might be marked as read-only and cannot be updated by actions.
Arguments cannot be passed to custom actions. They must obtain information by querying properties, tables, and session state flags. To effect argument passing, custom actions can set properties used by subsequent custom actions. Using a custom action that sets a property with formatted text is an efficient method to accomplish this.
If a custom action is scheduled to run during script processing as described in Deferred Execution of Custom Actions, the action may be run outside of an install session. Very little information is available to such custom actions. Therefore, the context information must be set beforehand. The command line for an EXE custom action is stored in the install script, so any information the custom action needs should be indicated in the command line.
A DLL custom action receives an install session handle. During script execution, the session may not exist. However, the following functions that require a handle are supported during script processing.
| Function | Functionality during script processing |
|---|---|
| MsiGetProperty | Supports only ProductCode and CustomActionData. Others return NULL. |
| MsiGetMode | Indicates the installation mode. |
| MsiGetLanguage | Returns the numeric language ID for the current product. |
| MsiProcessMessage | Processes messages from the custom action. |
In addition, any function that does not require a session handle is supported.
Except for the properties mentioned in the table above, properties are not available to deferred custom actions. To provide further context information to your custom action, use the CustomActionData property. Put any information you want to pass to the custom action in a property with the same name as the custom action. For example, if the primary key for a custom action entry is named MyAction, set the MyAction property with any needed contextual information. You can then gain access to this information from within the custom action by calling MsiGetProperty with CustomActionData as the property identifier.
One way to set the CustomActionData is with a Formatted Text custom action.
A script custom action receives the install session object, but has the same restrictions that a DLL custom action has. For example, the install session object may not exist if the action is deferred. A few methods are supported to allow the custom action to retrieve its context. The Mode property returns TRUE for only imfOperations. The Property Property (MsiEngine Object) returns properties as described above. The Language Property (MsiEngine Object) is available. And the Message method can be called to handle errors.