Upgrading InstallShield 11.5 or Earlier InstallScript Projects

InstallShield 2016

The following sections explain details about upgrading InstallScript projects that were created in InstallShield 11.5 or earlier to InstallShield 2016.

Including InstallScript Objects in InstallScript Projects

InstallScript installations created in InstallShield 2016 cannot consume objects that were created with InstallShield 11.5 or earlier.

If you upgrade an InstallScript project to InstallShield 2016, all references to any InstallShield objects are updated to point to the InstallShield 2016 versions of the objects. If the new version object is not present on the system, an error indicating that the object could not be found is displayed at build time.

For instructions on acquiring the InstallShield 2016 objects, see Obtaining Updates for InstallShield.

Changes to the DoInstall Function

The DoInstall function now launches the setup executable file of the child installation instead of using the already-running installation engine to run the child installation. This change should be automatic; that is, it should not require any changes to existing InstallScript code. The child installation may take slightly longer to initialize than in previous versions because the installation executable file needs to initialize. For more information, see DoInstall.

Note that now calling DoInstall is similar to calling LaunchAppAndWait. When the installation is run from any removable media, such as a CD-ROM or a DVD, the Setup.exe file on Disk1 may not be available during the entire installation. (If Setup.exe becomes unavailable while it is running, the operating system sometimes displays a prompt to request that the end user insert the correct disk, and this may cause the installation to fail.) Therefore, to avoid this problem, the Setup.exe file is copied to a Temp folder, and the installation is relaunched from there. The original Setup.exe then terminates. However, when this happens, DoInstall (or LaunchAppAndWait, if it is called) behaves as if the installation has completed, and it does not wait.

Several workarounds for this issue exist. One method is to use the /clone_wait parameter when you are launching the child installation; as a result of this workaround, the launched installation keeps the original launched process running, and the parent installation then waits. Note, however, that this may cause problems if the original CD containing Setup.exe is not available throughout the entire installation. This includes multiple-CD installations, where the first CD is not available during some parts of the installation.

The only other way to avoid this problem is to add code that determines the ID of the child processes of the launched process and wait for the child process to complete.

Setup.exe Changes

The /deleter command-line parameter for Setup.exe is no longer needed. If you specify this parameter, the installation will not run. Note that InstallScript installations no longer clone the installation immediately when they are launched (unless, for example, the installation is running from the temp folder because the /runfromtemp parameter is specified), so /deleter is no longer needed.

The /clone_nowait command-line parameter for Setup.exe is no longer needed. If you specify this parameter, Setup.exe ignores it. Note that InstallScript installations no longer wait for the cloned installation to complete by default unless the /clone_wait parameter is specified. For more information on /clone_wait, see Setup.exe and Update.exe Command-Line Parameters.

Like InstallScript MSI and Basic MSI installations, InstallScript’s Setup.exe file returns meaningful return codes. Therefore, if you are checking the return value of Setup.exe, in InstallShield 11.5 and earlier, it would always be 0; in InstallShield 12 and later, Setup.exe returns an appropriate return value. For details on the possible return codes, see Setup.exe Return Values and Run-Time Errors (InstallScript Projects).

Changes to Disk1 Files

InstallShield no longer places the following files on the Disk1 image of the built installation because they are no longer needed:

In InstallShield 12 and later, the following files are placed on the Disk1 image of the built installation:

The Disk1 file changes have not been known to cause any upgrade issues. These changes are reported for informational purposes.

Changes to the InstallScript Engine Files

With InstallShield 12 and later, InstallScript installations no longer install InstallScript engine files to the following directory:

<COMMONFILES>\InstallShield\Professional\Runtime\<MajorVersion>\<MinorVersion>\Intel32

This change has not been known to cause any upgrade issues. This change is reported for informational purposes.

See Also

Upgrading Projects from InstallShield 11.5 or Earlier

Open topic with navigation