Guidelines for Nested Installation Custom Actions

applicationPackaging created the topic: Guidelines for Nested Installation Custom Actions
What is Nested Installation
The Process of calling another installation from within the running installation with an Install MSI custom action is called Nested Installation Custom Actions. Use this type of custom action to deploy or uninstall one product from within the installation of another product.
// See Nested Installation Actions in the Windows Installer SDK Help.

Nested installations are supported according to the Windows Installer specification. Developers should note the following warnings when authoring nested installations.
• Nested installations cannot share components.
• An administrative installation cannot also contain a nested installation.
• Patching and upgrading may not work with nested installations.
• The installer may not properly cost a nested installation.
• Integrated ProgressBars cannot be used with nested installations.
• Resources that are to be advertised cannot be installed by the nested installation.
• A package that performs a nested installation of an application should also uninstall the nested application when the parent product is uninstalled.

According to the Windows Installer SDK, Install MSI custom actions should be placed between InstallInitialize and InstallFinalize of the main installation’s action sequence. Install MSI custom actions must be set to run synchronously.
Example: Suppose your main installation, Main.MSI, has a button on a dialog that, if clicked, installs Second.MSI. You can use an Install MSI custom action to run the second .MSI. Then you can use another Install MSI custom action to provide for uninstallation if the main installation is uninstalled.
To specify the circumstances in which a nested .MSI is called, set conditional If Statements around the Install MSI custom action in the sequence. See Guidelines for Custom Action Conditions.
Guidelines for Custom Action Conditions
Place a custom action between conditional If Statements to run it only if a certain condition is true. A condition can check whether the product is installed, the value of a property is true, if specific system requirements are met, and more.
To Run Only During Initial Installation
The Execute sequences under the Normal Installation mode run during initial installation and later during maintenance and uninstall installations. To run a custom action during the initial installation only, set its condition to NOT Installed. Installed is a Windows Installer property that is true if the product is installed.

Example: If you add a custom action that opens a Readme file and set the action’s condition to NOT Installed, then the Readme opens during initial installation, but does not open during maintenance installations (reinstall, modify, and repair operations).
To Run Only During Uninstall
If the product is being uninstalled, the REMOVE property is set to All or ALL. To run a custom action during uninstall only, set its condition to REMOVE~=”ALL”. (The ~ causes the comparison to be case-insensitive.)

Getting a nested installation to install is straightforward, but getting it to uninstall properly when the calling application is uninstalled requires that you add 2 custom actions. Set the first custom action to call the nested installation, and set its condition to NOT Installed (Custom Action Location dialog). Set the second custom action to call the nested installation also, set its Property Settings field to REMOVE=ALL (Custom Action Target dialog), and set its condition to REMOVE~=”All”.

Access Nested Installation
With this type of custom action, you can call only Windows Installer installations. To call an installation that was created with a WiseScript product, use a Run WiseScript custom action. To call an installation that was created with any other installation technology, use an Execute Program custom action type.
A nested installation file can be accessed from the following locations:
l It can be stored within the main installation file. See Install MSI From Installation.
l It can be distributed along with the main installation file. See Install MSI From Relative Path.
l It can be an installed or advertised application that already exists on the destination computer. See Install MSI From Destination.
The return values for nested installation actions are the same as for other custom actions. See Custom Action Return Values in the Windows Installer SDK Help.

Guidelines for Using Custom Actions

When you use Windows Installer to install a file, it takes care of the repair and management of the file. When you use a custom action to change an installation, you take Windows Installer out of the loop. (Example: If you use a custom action to install a file, you must also include custom actions to repair or uninstall the file because Windows Installer is unaware of the file.) Therefore, use custom actions conservatively when making permanent changes on the destination computer, and use them only for actions that cannot be accomplished through Windows Installer. See Uninstalling Changes Made by a WiseScript.


Although you can change the order and conditions for standard actions and dialogs, we recommend that you do not change these settings unless you are proficient in the Windows Installer development environment. Many actions have restrictions that determine where they must appear in the sequence. See Actions with Sequencing Restrictions in the Windows Installer SDK Help for more details.

Custom Action Return Values

If the msidbCustomActionTypeContinue return processing option is not set, the custom action must return an integer status code as shown in the following table.

Return value Description
ERROR_FUNCTION_NOT_CALLED Action not executed.
ERROR_SUCCESS Completed actions successfully.
ERROR_INSTALL_USEREXIT User terminated prematurely.
ERROR_INSTALL_FAILURE Unrecoverable error occurred.
ERROR_NO_MORE_ITEMS Skip remaining actions, not an error.

Note that custom actions that are executable files must return a value of 0 for success. The installer interprets any other return value as failure. To ignore return values, set the msidbCustomActionTypeContinue bit flag in the Type field of the CustomAction table.

Tagged :
0 0 votes
Article Rating
Notify of

Inline Feedbacks
View all comments
Would love your thoughts, please comment.x