Accessing the Current Installer Session from Inside a Custom Action
Nondeferred custom actions that call dynamic-link libraries or scripts may access a running installation to query or modify the attributes of the current installation session. Only one Session object can exist for each process, and custom action scripts must not attempt to create another session.
Custom actions can only add, modify, or remove temporary rows, columns, or tables from a database. Custom actions cannot modify persistent data in a database, for example, data that is a part of the database stored on disk.
To access a running installation, custom actions that call dynamic-link libraries (DLL) are passed a handle of the type MSIHANDLE for the current session as the only argument to the DLL entry point named in the Target column of the CustomAction Table. Because the installer provides this handle, the custom action should not close it, for example, to receive the handle hInstall from the installer, the custom action function is declared as follows.
UINT __stdcall CustomAction(MSIHANDLE hInstall)
Custom actions written in VBScript or JScript can access the current installation session by using the Session Object. The installer creates a Session object named "Session" that references the current installation. For read-only access to the current database use the Database property of the Session object.
Because a script is run from the context of the Session object, it is not always necessary to fully qualify properties and methods. In the following example, when using VBScript, the Me reference can replace the Session object, for example, the following three lines are equivalent.
You cannot access the current installer session or all property data from a deferred execution custom action. For more information, see Obtaining Context Information for Deferred Execution Custom Actions.