The Advanced - Actions page offers the ability to add custom installation and uninstallation actions. Furthermore, it contains placeholders for all built-in actions, i.e., those actions that Tarma QuickInstall's Setup program performs during the installation or uninstallation process.
The current topic contains detailed information about each of the built-in actions, as well as guidelines for custom actions. The information presented here should help you to assess where to add your custom actions, if any.
Note - If you need further customization of the Setup process, you might consider writing an Extension DLL. Extension DLLs provide an opportunity for seamless extension of the built-in Setup functionality.
The actions list contains placeholders for the following built-in installation actions.
This marks the point where the customer has committed to the installation, i.e., after clicking the Install button in the Tarma QuickInstall installation wizard. Among other things, the Readme and License Agreement pages have been read and accepted, the (primary) installation folder for the application is known, and Tarma QuickInstall is about to commence with the installation. Any remaining project variables can be resolved now.
Note - Prior to version 2.63, the <AppFolder> installation folder had been created and the Setup.exe program copied to the customer's system at this point. Starting with version 2.63, this is no longer the case. The <AppFolder> installation folder is now created after all preparations, including any external actions, are complete. However, its future location is known and fixed at this point.
This is the stage in which all file copying takes place for the files that are marked for installation and not excluded because of target platform restrictions. Most files are simply copied to the customer's computer; those that already exist are only replaced if the version in the Setup package is strictly newer than the existing copy, or if the installation file is marked Always. If an existing file must be replaced but cannot because it is currently in use, a temporary copy of the new version is created on the customer's computer and the file is registered for delayed copying, i.e., replacement at the next system restart.
After completion of this stage, all applicable installation folders exist on the customer's computer and most, if not all, installation files are present.
During this stage, Setup performs registration actions for all files that are marked as such. However, if any delayed file copying (and a system restart) resulted from the previous stage, only external REG File registrations (usually for device drivers) are performed. The remaining file registrations are postponed and Setup registers itself for a post-boot registration run. See Guidelines for custom actions below for the implications this has on custom actions.
After completion of this stage (which, to repeat, may not be until after a system restart), any ActiveX/COM-related file registration has been completed, type libraries are known to Windows, and device driver settings are stored in the Windows registry.
During this stage, Setup creates all shortcuts to files that were actually installed on the customer's computer. This includes files that are registered for delayed copying, but excludes those that were skipped because of platform restrictions.
After completion of this stage, all shortcuts exist on the customer's computer and your application's program group folder, if any, has been created (and possibly populated with shortcuts).
This stage covers all remaining system-related installation actions: modifications to the Windows registry, creation or modification of INI files, and creation or modification of environment variables.
After completion of this stage, the installation process is essentially complete. Only delayed file copying (and attendant registration actions) might remain.
This marks the point when installation is complete. If delayed file copying is necessary, this point is reached after the next system restart and optional Install: File registration; if no delayed file copying was required, it simply follows the previous stage.
At this point, the installation process is complete except for any custom actions that you place immediately after this stage.
This built-in action represents the final cleanup that Setup performs after a successful installation. It is reached after the customer has clicked Finish on the Installation completed wizard page. At this point, no further interaction with the customer takes place and the Setup wizard is about to disappear from the screen.
Custom actions placed immediately after this action are only executed if the installation was successful and no system restart is scheduled. This makes it a good place for custom actions that automatically start, say, your application after installation.
Note - It is recommended that you clear the Wait for finish box for custom actions placed immediately after this built-in action. This ensures that Setup removes itself as quickly as possible from the screen after the custom actions are started.
During the uninstallation process, the following built-in actions are performed.
This marks the point where the customer has committed to the uninstallation, i.e., after clicking the Uninstall button in the Tarma QuickInstall uninstallation wizard.
At this point, your application is still as it was the last time the customer used it. In particular, all files, folders, shortcuts, and system settings are still present.
During this stage, Setup removes all shortcuts that refer to installation files (even if the installation files remain behind due to sharing restrictions).
After completion of this stage, the shortcuts are gone but all files and folders, including your application's program group folder, are still present on the customer's computer.
During this stage, Setup runs all unregistration procedures for files marked for registration, but only if the file will be physically removed from the customer's computer during the Uninstall: File removal stage. File removal is subject to the sharing mode of the file and, if shared, to its SharedDlls reference count. If unregistration is performed for a file, both Register and REG File unregistration take place. (For REG File unregistration, Setup parses the REGEDIT4 registration information in a manner similar to registration, but removes registry keys and values instead of adding them.)
After completion of this stage, no registration-related information should remain on the customer's computer.
During this stage, Setup reverses any modifications to system settings such as the registry, INI files, and environment variables that resulted from the Install: System settings stage.
After completion of this stage, the customer's computer should be "clean", except for the remaining files and folders.
During this stage, Setup removes all files that are marked for uninstallation and whose sharing mode allows them to be removed: either because they are not shared with other applications, or because their SharedDlls reference counts and other information that Tarma QuickInstall maintains about them indicates that it is safe to remove the files.
After completion of this stage, all applicable files have been removed from the system. However, all installation folders are still present.
(This stage does not appear in the actions list because it is performed separately from Setup and no custom actions can be attached to it.)
After all of the previous stages and any associated custom actions have been completed, Setup starts a tiny helper program that takes care of the final cleanup: removing all installation folders plus Setup itself. This helper program runs briefly and invisibly in the background; it in turn is removed from the customer's computer by Windows at the next system restart.
The Install: File registration built-in action is special in the sense that even though its nominal position is third in the list of built-in actions, delayed file copying might cause it to be postponed until after a system restart. If that is the case, then any actions that you place immediately after Install: File registration will move with it. This is by design; it guarantees that any registration-related actions you might add will run after the built-in registration actions have completed.
Installation actions that you place further down the actions list are unaffected by this. The result is that those actions might run in a situation where file registration has not taken place yet (because of delayed file copying). Therefore, we recommend that you use the following guidelines to determine the best position for your own actions.
Uninstallation actions are generally less critical, although any actions that require the presence of installation files should of course be run before those files are removed from the customer's system. In practice, this means that most uninstallation custom actions should be placed immediately after the Uninstall: Preparing for removal built-in action.
Note - System restart requests are suppressed by Setup during the uninstallation process, on the assumption that all visible traces of your application have been removed anyway and that any final cleanup is not so time-critical as to warrant the disruption of a system restart.