Upgrading Projects from InstallShield 12 or Earlier

InstallShield 2016

The following information describes changes that may affect projects that are upgraded from InstallShield 12 or earlier to InstallShield 2016.

Upgrading Projects Created in Earlier Versions of InstallShield

If you use InstallShield 2016 to open a project that was created with an earlier version, InstallShield 2016 displays a message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it, InstallShield creates a backup copy of the project with a file extension such as .765 before converting it. Delete the .765 part from the original project’s file name if you want to reopen the project in the earlier version of InstallShield. Note that you cannot open InstallShield 2016 projects in earlier versions of InstallShield.

You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2008: InstallShield 12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and InstallShield Developer 8 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal cannot be upgraded to InstallShield 2008.

End of Support for Windows 9x, Windows NT 4, and Windows Me on Target Systems

InstallShield no longer supports the creation of installations for Windows 9x, Windows NT 4, and Windows Me systems. If end users have one of these operating systems on their computer and they try to run an installation that was built with InstallShield 2016, unexpected results may occur, unless the project includes launch conditions that prevent end users from running the installation on any of these legacy operating systems.

For Basic MSI and InstallScript MSI projects, you may want to consider adding launch conditions that display a message if end users are running your installation on any of the legacy systems. For InstallScript projects, you may want to consider adding InstallScript code that uses the SYSINFO structure variable to check for these legacy systems, and then display a message if any of these legacy systems are present.

To learn more, see:

COM Extraction

When you use InstallShield to extract COM information from a COM server, InstallShield puts the data in the Registry table, instead of in the TypeLib table. Microsoft strongly advises against using the TypeLib Table.

Unused Directories Automatically Removed from .msi File at Build Time by Default

Note that if you upgrade a Basic MSI, InstallScript MSI, or Merge Module project that was created in InstallShield 12 or earlier to InstallShield 2016, the new Keep Unused Directories setting on the Build tab in the Releases view is set to No. Therefore, if a directory that is listed in the Directory column of the Directory table is not referenced in any known location in the .msi file, InstallShield removes it from the Directory table of the .msi file that it creates at build time. For Basic MSI and InstallScript MSI projects, this occurs after any merge modules are merged, but only directories that are present in the .msi file are removed; therefore, if a merge module contains new unused directories in its Directory table, the new unused directories are added to the installation.

Changes for ALLUSERS and for the CustomerInformation Dialog

Beginning with InstallShield 2008, the ALLUSERS property is set to 1 by default in all new Basic MSI projects. This is the recommended implementation, since most installations must be run in a per-machine context with administrative privileges.

If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2016, InstallShield does not automatically change the value of the ALLUSERS property or add this property if it was not defined in the earlier project.

Also new with InstallShield 2008, by default, the CustomerInformation dialog in all new Basic MSI projects does not display the radio button group that enables end users to specify whether they want to install the product for all users or for only the current user. This is the recommended implementation for this dialog.

If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2016, InstallShield does not automatically change the CustomerInformation dialog.

To learn more, see:

Windows Server 2003 Conditions and 64-Bit Windows XP Conditions for Setup Prerequisites

The operating system version number is 5.2 for both Windows Server 2003 and 64-bit Windows XP. As a result, prerequisites that were created in InstallShield 12 and that required Windows Server 2003 could be installed on 64-bit Windows XP systems, and those that required Windows XP could not be installed on 64-bit Windows XP systems.

To resolve this issue, the Setup Prerequisite Editor in InstallShield 2008 has been enhanced to enable you to specify whether the target system is required to be a workstation, a server, or a domain controller.

To resolve this issue for an existing prerequisite that includes a Windows Server 2003 requirement or a 64-bit Windows XP requirement, open the prerequisite in the Setup Prerequisite Editor in InstallShield 2008. On the Conditions tab, select the condition that needs to be corrected and click Modify. In the Select which platform the prerequisite should be run on box, select the appropriate operating system requirement. Doing this correctly sets the new Product (OS) Type setting to the appropriate workstation, server, or domain controller value.

Automation Interface

The Display Save Options dialog setting was removed from the Releases view. Therefore, the WebSaveOptionsDlg property, which corresponds with that setting, is no longer available for the ISWiRelease object of automation interface.

New Default Value for the Cache Path Setting for a Release

The default value for the Cache Path setting for a compressed release in the Releases view is now set to [LocalAppDataFolder]Downloaded Installations. The previous default value was [WindowsFolder]Downloaded Installations, which may not be available to users on locked-down systems. If you migrate a project from InstallShield 12 or earlier to InstallShield 2016, the Cache Path setting is not automatically changed. Therefore, you may want to change that value.

InstallScript One-Click Install Installations

Setup.exe is no longer used as the setup player for InstallScript One-Click Install installations; Setup.ocx is now used instead. In order for a Setup.ocx file to be included in an installation, the new Generate One-Click Install setting in the Releases view must be set to Yes. If you upgrade an InstallScript project from InstallShield 12 or earlier to InstallShield 2016 and the Create Default Web Page setting in the Releases view is set to Yes, InstallShield sets the Generate One-Click Install setting to Yes automatically during the upgrade. However, if the Create Default Web Page setting is set to No and you intend to distribute the installation over the Internet, you must manually select Yes for the Generate One-Click Install setting after upgrading the project.

All functionality that is related to the Save And/or Run Setup dialog box has been removed from InstallShield. If you want to give end users the option of downloading and saving the installation (or creating an icon on the desktop), you need to implement this within your installation’s Web page, and handle the download and save operations through the Web page.

To pass data to a launched One-Click Install installation, use the is::CmdLine parameter and the CMDLINE script variable. Previously, it was possible to pass data from the Web page to the installation; however, this support has been removed. Note that the only valid value for the first parameter of SetProperty is now is::CmdLine.

To learn more about One-Click Install installations, see One-Click Install Installations in InstallScript Projects.

Patch Creation for Basic MSI and InstallScript MSI Projects

InstallShield now uses version 3.1 of Patchwiz.dll to create patches.

DemoShield Support

DemoShield is no longer being sold. In addition, it is no longer supported. Therefore, InstallShield no longer includes any DemoShield integration.

Changes for the Windows Vista Validation Suites

The validation suites that help you determine whether your installation meets installation requirements for the Windows Vista logo program have been renamed:

In addition, three of the InstallShield ICEs have been moved to the InstallShield Best Practice Suite.

For more information about the validation and the Certified for Windows Vista program, see:

To learn about the validators that are now available as InstallShield Best Practices, see:

See Also

What’s New in InstallShield 2008

Upgrading from Earlier InstallShield Versions

Open topic with navigation