InstallShield 2016
Project • This information applies to the following project types:
| • | InstallScript |
| • | InstallScript MSI—if the InstallScript user interface (UI) style is the traditional style (which uses the InstallScript engine as an external UI handler) |
This information does not apply to InstallScript MSI projects in which the InstallScript UI style is the new style (which uses the InstallScript engine as an embedded UI handler). To learn more, see Using the InstallScript Engine as an External vs. Embedded UI Handler for InstallScript MSI Installations.
The BATCH_INSTALL system variable is set to a non-zero value to indicate that one or more operations need to be performed after the target system restarts. For example, BATCH_INSTALL can be set to a non-zero value if the installation determines that a file cannot be installed because the file already exists on the target system and it is locked.
When a file in an installation cannot be installed because it is locked, the installation automatically notifies the operating system that the file needs to be updated the next time that the system restarts. Because the file may need to be updated before additional Windows files are loaded, it is updated when Windows is loaded; it is not updated by the InstallScript installation.
BATCH_INSTALL can be set during an uninstallation in order to remove locked files after the system restarts. However, after the reboot, the cached installation files are no longer present. Therefore, the only reboot-related operations that can occur are those that the operating system can perform.
If BATCH_INSTALL is set to a non-zero value when the file transfer finishes, the following occurs:
| • | The installation does not attempt to self-register any files. This is because it may be necessary for all of the installation’s files to be completely installed and updated before the files can be self-registered successfully. Note that this is true regardless of whether the files that could not be installed are self-registering, since the installation assumes that these files could be dependencies of other self-registering files. In this case, the installation records the files that need to be self-registered so that after the restart, the installation can self-register those files. |
| • | The framework automatically calls SdFinishReboot (in the OnFirstUIAfter or OnMaintUIAfter events) to give the end user the option of automatically restarting the system after the installation completes. |
| • | When the installation finishes, it creates an appropriate RunOnce registry value so that the installation runs after the restart; after the restart, the installation is run with the /reboot parameter. |
If the ALLUSERS script variable is set to 1, the RunOnce entry is created under HKEY_LOCAL_MACHINE; otherwise, the entry is created under HKEY_CURRENT_USER. Windows supports RunOnce entries under both of these locations.
The RunOnce registry value’s name is InstallShield Setup %n, where %n is the lowest integer available to make a unique key name. The registry value’s data is the complete command line for the installation to run after restart; the command line includes the path and file name of Setup.exe.
After restart, the installation is run from the installed Disk1 location—DISK1TARGET. Thus, for the installation to run after restart, the Disk1 files for the installation must be currently installed.
Note that this does not apply to an uninstallation, since after the restart, the cached installation files are no longer present.
When the installation runs after the restart (that is, when it runs with the /reboot parameter), the following occurs:
| • | Any self-registering files that were noted by the installation as needing to be registered are registered. |
| • | The OnRebooted event handler is called. |
Note that for an uninstallation, the installation does not run after the restart; therefore none of these operations can occur.
See Also
InstallShield 2016 Help LibraryAugust 2016 |
Copyright Information | Flexera Software |