Frequently Asked Questions about Custom Actions

Any custom action in an MSI package uses a condition which determines if it will run or not. This condition can be null (always execute), Not Installed (only during the first installation), Remove = "ALL" (only during uninstall) etc. In order to execute a custom action during a patch, you can add the condition PATCH. This is a property which is set only when a patch runs.

When Windows Installer tries to launch a custom action, there are two possible scenarios for failure:

• the custom action is launched successfully, but its return code is not "0"
• the custom action cannot be launched

If you use an option which ignores the return code of the custom action, it will work only if the custom action is launched successfully (it returns something). If the custom action cannot be launched, the installation will fail even if the return code is ignored.

You can see a standard action by using the "Show Standard Action" button on the Custom Actions page's toolbar or by using the option "Show Standard Action" from the context menu while an action group is selected. Another context menu will open, specific to the selected element and will display all the available Standard Actions.

BAT files cannot be launched as Installed or Attached custom actions. However, they can be launched through "Launch file or open URL" custom actions. Note that the "Command Line" field of the custom action must contain the full path of the BAT file.

This can be done by using an "Launch EXE with working directory" custom action. The working directory can be set to any folder in the "Files and Folders" page.

Windows Installer allows only "Immediate" custom actions to access installer properties during the installation. Therefore, a "Deferred", "Rollback" or "Commit" custom action will not have access to installer properties (the properties will be empty when the custom action runs). If you want to use properties in a "Deferred" custom action you need to use the Action Data field.

A trailing backslash can be removed through a simple VBScript custom action. For the APPDIR property, the VBScript code can look like this:

path = Session.Property("APPDIR")

If Right(path, 1) = "\" Then
   pathNew = Left(path, Len(path) - 1)
Else
   pathNew = path
End If

Session.Property("APPDIR_NEW") = pathNew 

First, the APPDIR property's value is placed into a variable ("path"). If this value ends in a backslash, the last character is removed, otherwise, the value remains the same. In both cases the resulted value is placed in another variable ("pathNew"). After that, the new variable sets the value of another installer property. This property will contain the original value, but without the trailing backslash.

This can be done by setting the "APPDIR" property with multiple Set installer property  custom actions (one for each custom path). The custom actions can be scheduled before "Wizard Dialogs Stage" -> "Searches" and they can be conditioned with the VersionNT property.

In order to execute the custom actions when there is no UI, you can drag and drop them before "Install Execution Stage" -> "Searches" while the SHIFT key is pressed. Also, the "Execute only once if present in both sequence tables" option should be selected.

For those custom actions which modify the system it is recommended to have Rollback correspondents which undo their actions should a Installer Rollback operation appear.

Due to the fact that properties can not be directly accessed from within a deferred custom action, the value of the properties that need to be passed to the custom action will be placed in the "Action Data" field of that custom action. The content of this field can be accessed from the custom action by retrieving the value of [CustomActionData].

This is determined by the context in which the custom action is used.

Cases when an Immediate Execution for a Custom Action is more appropriate:

• when a property needs to be set from within the custom action

Cases when a Deferred Execution for a Custom Action is more suitable:

• when an Action Text needs to be set
• when the custom action modifies the system in some way

A possible cause could be an error in the script itself. You should first test it outside the installer. If the script works fine, check whether or not you are using the WScript object in your code.

Let's suppose you wanted to display a message box and return an error code. For this, you could use this VBScript code fragment:

MsgBox "Your Message"
WScript.quit 0

This script will work perfectly when you run it outside the installation package. But if you try to use it as a custom action, you will end up with the following error message: "Error 1720: A script required for this install to complete could not be run."

This happens because Windows Installer does not support WScript objects directly. A workaround would be not to use the WScript object inside your scripts. For instance, you can use the "CreateObject" function directly. Here is an example:

Set objFSO = CreateObject("WScript.Shell")

On Windows Vista and above, a custom action which needs Administrator privileges should be set to run without impersonation, usually "Deferred with no impersonation". This way, it will run under the local system account with full privileges. You can read more about custom action execution options in the Custom Action Properties article.

This is a well known Windows Installer limitation. It cannot refresh all controls after a dialog has been loaded. All controls will be reloaded only after switching to a different dialog.

To overcome this you need to schedule the Refresh the current dialog published event after the custom action published event.

For more information you can follow How to refresh a dialog after setting a property article.

For this, you can share the custom action between two standard actions, provided one it is located in the Wizards Dialogs Stage and the other in the Install Execution Stage.

To achieve this, please follow this steps:

• Select your custom action
• Press the [ Shift ] key. While the [ Shift ] key is pressed, simply drag a custom action from one stage to the other
• Use the Advanced execution scenarios option from the custom actions properties to display the Advanced Execution Scenarios Dialog
• Select the Skip action in Install Execution Stage if executed in Dialogs Stage option

Below is a link to a short video depicting the steps explained above.

This may happen if the custom action is executed with a published event. When the DTF C# custom action is called from a UI control with a published event (e.g. button click), the Log and Message methods don't work.

You can activate extended debug logging for custom actions by setting the AI_DEBUGLOG property to “1” during install time. The functionality is available for both EXE and MSI packages.

msiexec.exe /i "D:\Sample.msi" AI_DEBUGLOG=1 /L*V "D:\example.log"

"D:\Sample.exe" AI_DEBUGLOG=1 /L*V "D:\example.log"