Setup Factory for Windows Installer
The custom action's identifier. This must be unique within all custom actions in your project and should not conflict with any property names.
The execution scheduling of the custom action. Note that below when it refers to "both sequence tables" it is referring to InstallUISequence and InstallExecuteSequence during a normal installation or AdminUISequence and AdminExecuteSequence during an administrative installation. Custom actions cannot be run from the AdvertiseExecuteSequence.
You can choose from:
Always execute immediately. Action may run twice if present in both sequence tables. This is the default setting for custom actions.
Execute once if present in both sequence tables. Skips action in execute sequence if UI sequence has run. No effect in UI sequence. Not affected by install service registration.
Execute only if running on client after UI sequence has run. In other words, causes the action to be run in the execute sequence only if it was not already run in the UI sequence (assuming that it is in both sequences). May be used to provide either/or logic, or to suppress the UI-related processing if already done for the client session.
Execute once per process if in both sequence tables. Skips action in execute sequence if UI sequence has been run in same process, for example both run in the client process. Used to prevent actions that modify the session state, such as property and database data, from running twice.
Queues for execution at scheduled point within script. This means that the action is not run immediately where it is in the excute or UI sequence, but rather later while the actual installation of the software is taking place (a.k.a. "in script"). Note that deferred custom actions have special restrictions as to what data that they have access to. See the "Obtaining Context Information for Deferred Execution Custom Actions" link in the More Information section below for details.
Queues for execution at scheduled point within script. Executes only upon install commit. In other words, the action will be run only after the installation of the software is complete. Note that deferred custom actions have special restrictions as to what data that they have access to. See the "Obtaining Context Information for Deferred Execution Custom Actions" link in the More Information section below for details.
Queues for execution at scheduled point within script. Executes only upon an installation rollback. Note that deferred custom actions have special restrictions as to what data that they have access to. See the "Obtaining Context Information for Deferred Execution Custom Actions" link in the More Information section below for details.
Note: Deferred actions are usually used when the action needs to use or reference something that was done during installation such as a file that was installed or a registry key. It is important to understand that the UI and execute sequences do not actually "install" the software or affect the system. They just prepare the "script" which is run after the execute sequence is complete. In contrast, immediate actions run while in the sequence while the script is being prepared.
The return behavior of the custom action. Choose from:
Indicates that the custom action will run asynchronously and execution may continue after the installer terminates. Only valid for Run Executable custom actions.
Indicates that the custom action will run asynchronously but the installer will wait for the return code at sequence end. Only valid for Run Executable and Call DLL custom actions.
Indicates that the custom action will run synchronously and the return code will be checked for success. This is the default.
Indicates that the custom action will run synchronously and the return code will not be checked.
If checked, suppresses the modularization of this custom action name in merge modules. This should only be necessary for table-driven custom actions because the table name which they interact with cannot be modularized, so there can only be one instance of the table.
Controls whether the custom action will impersonate the installing user during per-machine installs on Terminal Server machines. If unchecked, the deferred custom action will run with no user impersonation on Terminal Server machines during per-machine installations. This attribute is only applicable when installing on the Windows Server 2003 family.
If checked, the installer does not log the CustomActionData for the deferred custom action. Read the "Obtaining Context Information for Deferred Execution Custom Actions" link in the More Information section below to find out more about the CustomActionData property.
Specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. This is only available for deferred custom actions. Typically this should be checked, except when the custom action needs elevated privileges to apply changes to the machine.
This is a list of items that specify when the custom action is run during the various execute and UI sequences. You can schedule a custom action to run from none, one or more sequences. You do not need to create any timing entries if you only want to run the custom action from a user interface event (usually a "DoAction" event published from a PushButton control). If you do not add any timing options for the action and do not call it from a UI event, then the custom action will not be included in your installer.
Click the Add button to open the Custom Action Timing dialog and configure the insertion of your custom action into a sequence.
MSDN Online: Commit Custom Actions
MSDN Online: Custom Action Execution Scheduling Options
MSDN Online: Custom Action Return Processing Options
MSDN Online: CustomAction Table
MSDN Online: Deferred Execution Custom Actions
MSDN Online: Obtaining Context Information for Deferred Execution Custom Actions
MSDN Online: Rollback Custom Actions
MSDN Online: Summary List of All Custom Action Types
WiX Help File: CustomAction Element