{"id":1370,"date":"2017-12-04T07:51:21","date_gmt":"2017-12-04T07:51:21","guid":{"rendered":"http:\/\/www.scmgalaxy.com\/tutorials\/?p=1370"},"modified":"2020-01-09T09:37:04","modified_gmt":"2020-01-09T09:37:04","slug":"guidelines-for-nested-installation-custom-actions","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/guidelines-for-nested-installation-custom-actions\/","title":{"rendered":"Guidelines for Nested Installation Custom Actions"},"content":{"rendered":"<p><strong>applicationPackaging created the topic: Guidelines for Nested Installation Custom Actions<\/strong><br \/>\nWhat is Nested Installation<br \/>\nThe 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.<br \/>\n\/\/ See Nested Installation Actions in the Windows Installer SDK Help.<\/p>\n<p>Limitations<br \/>\nNested installations are supported according to the Windows Installer specification. Developers should note the following warnings when authoring nested installations.<br \/>\n\u2022\tNested installations cannot share components.<br \/>\n\u2022\tAn administrative installation cannot also contain a nested installation.<br \/>\n\u2022\tPatching and upgrading may not work with nested installations.<br \/>\n\u2022\tThe installer may not properly cost a nested installation.<br \/>\n\u2022\tIntegrated ProgressBars cannot be used with nested installations.<br \/>\n\u2022\tResources that are to be advertised cannot be installed by the nested installation.<br \/>\n\u2022\tA package that performs a nested installation of an application should also uninstall the nested application when the parent product is uninstalled.<\/p>\n<p>Usage<br \/>\nAccording to the Windows Installer SDK, Install MSI custom actions should be placed between InstallInitialize and InstallFinalize of the main installation&#8217;s action sequence. Install MSI custom actions must be set to run synchronously.<br \/>\nExample: 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.<br \/>\nTo 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.<br \/>\nGuidelines for Custom Action Conditions<br \/>\nPlace 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.<br \/>\nTo Run Only During Initial Installation<br \/>\nThe 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.<\/p>\n<p>Example: If you add a custom action that opens a Readme file and set the action&#8217;s condition to NOT Installed, then the Readme opens during initial installation, but does not open during maintenance installations (reinstall, modify, and repair operations).<br \/>\nTo Run Only During Uninstall<br \/>\nIf 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~=&#8221;ALL&#8221;. (The ~ causes the comparison to be case-insensitive.)<\/p>\n<p>Un-installation<br \/>\nGetting 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~=&#8221;All&#8221;.<\/p>\n<p>Access Nested Installation<br \/>\nWith 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.<br \/>\nA nested installation file can be accessed from the following locations:<br \/>\nl It can be stored within the main installation file. See Install MSI From Installation.<br \/>\nl It can be distributed along with the main installation file. See Install MSI From Relative Path.<br \/>\nl It can be an installed or advertised application that already exists on the destination computer. See Install MSI From Destination.<br \/>\nThe 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.<\/p>\n<p>Guidelines for Using Custom Actions <\/p>\n<p>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.<\/p>\n<p>Caution <\/p>\n<p>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.<\/p>\n<p>Custom Action Return Values<\/p>\n<p>If the msidbCustomActionTypeContinue return processing option is not set, the custom action must return an integer status code as shown in the following table.<\/p>\n<p>Return value Description<br \/>\nERROR_FUNCTION_NOT_CALLED Action not executed.<br \/>\nERROR_SUCCESS Completed actions successfully.<br \/>\nERROR_INSTALL_USEREXIT User terminated prematurely.<br \/>\nERROR_INSTALL_FAILURE Unrecoverable error occurred.<br \/>\nERROR_NO_MORE_ITEMS Skip remaining actions, not an error.<\/p>\n<p>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.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8230; <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_joinchat":[],"footnotes":""},"categories":[49],"tags":[235],"class_list":["post-1370","post","type-post","status-publish","format-standard","hentry","category-general","tag-installation"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1370","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=1370"}],"version-history":[{"count":1,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1370\/revisions"}],"predecessor-version":[{"id":1371,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/1370\/revisions\/1371"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=1370"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=1370"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=1370"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}