Upgrading Projects from InstallShield 2014 or Earlier

InstallShield 2015

The following information describes possible upgrade issues that may occur when you upgrade projects that were created with InstallShield 2014 and earlier to InstallShield 2015. It also alerts you to possible changes in behavior that you may notice between new InstallShield 2015 projects and projects that are upgraded from InstallShield 2014 or earlier to InstallShield 2015.

General Information about Upgrading Projects that Were Created in Earlier Versions of InstallShield

If you use InstallShield 2015 to open an project that was created with an earlier version, InstallShield 2015 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 .775 (for an .ism project) or .2014 (for an .issuite project) before converting it. Delete the .775 or .2014 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 2015 projects in earlier versions of InstallShield.

You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2015: InstallShield 2014 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 2015.

Changes to the List of Supported Versions of Windows for Target Systems

Windows XP SP3 and Windows Server 2003 SP2 are now the minimum versions of Windows that are required for target systems that run the installations that are created in InstallShield; this applies to all project types.

Removal of Support for Digitally Signing with .spc and .pvk Files

InstallShield no longer has support for using .spc and .pvk files to digitally sign files at build time.

If you configured a release or patch in InstallShield 2014 or earlier to be digitally signed at run time with .spc and .pvk files, and then you try to open that project in InstallShield 2015, InstallShield displays upgrade warning -6048 (for a release), -6049 (for a patch), or -6050 (for a QuickPatch project). The warning explains that InstallShield is removing the .pvk file and the associated password from your project during the upgrade.

Before you can successfully build the release or the patch in InstallShield 2015, you will need to remove the .spc reference from the release or patch configuration. You can replace it with a .pfx certificate, or with a reference to a certificate in a certificate store. To learn more, see:

Digital Signing and Security
Digitally Signing a Release and Its Files at Build Time
Signing a Patch Package
Signing a QuickPatch Package

If you try to build a release or a patch without removing the .spc reference from it, InstallShield displays build error -7347, stating that the .spc file must be removed.

To learn how to convert an .spc file and a .pvk file to a .pfx file, see Digital Signing and Security.

Automation Interface Changes for Digital Signature Support

The ISWiRelease object no longer includes support for the following read-write properties:

CorrespondingPrivateKey
SoftwarePublishingCredentials

If you call those properties, you will encounter an error. Those properties have been replaced with the read-write string property DigitalCertificateInfo.

To learn more, see ISWiRelease Object.

Removal of SignTool.exe and Signcode.exe from InstallShield Installation

SignTool.exe and Signcode.exe are no longer installed on your machine when you install InstallShield. If you want to digitally sign your files manually, consider using SignTool.exe, which is installed with Visual Studio and included in the Microsoft Windows Software Development Kit (SDK).

Changes to the PowerShell Support in Basic MSI and InstallScript MSI Installations

The PowerShell custom action support in Basic MSI and InstallScript MSI installations has been revised. The support no longer uses the Windows Installer property IS_PS_EXECUTIONPOLICY to indicate the name of the PowerShell execution policy that you want to be used to run PowerShell custom actions on target systems. Setting this property at run time no longer has any effect on the installation.

Changes to Default Eligibility Conditions for .msi Packages in Advanced UI and Suite/Advanced UI Projects

To make it possible to support shared packages in Advanced UI and Suite/Advanced UI projects, InstallShield no longer needs the previously required MSI Package eligibility conditions for .msi packages. Now you can limit the use of eligibility conditions of .msi packages to check for run-time environment requirements such as platform.

Now when you add an .msi package to an Advanced UI or Suite/Advanced UI project in InstallShield 2015, InstallShield no longer creates an MSI Package eligibility condition for that package by default. This behavior applies to new InstallShield 2015 projects, as well as projects that you created in InstallShield 2014 or earlier and then upgrade to InstallShield 2015.

In addition, if you upgrade an InstallShield 2014 or earlier project that contains the old default MSI Package eligibility condition for an .msi package to InstallShield 2015, InstallShield removes the unnecessary part of the condition from the Eligibility Condition setting for the package.

In some cases, if you customized the default MSI Package eligibility condition in InstallShield 2014 or earlier, InstallShield 2015 may remove it during the upgrade; in other cases, InstallShield leaves it as is. The actual upgrade behavior depends on the customization. For example, if you simply added a platform condition, InstallShield may be able to remove the original MSI Package part of the condition, leaving just the platform condition. However, if the customization is too complex, InstallShield leaves the condition as is.

It is recommended that you review the eligibility conditions for your .msi packages after upgrading to InstallShield 2015 to ensure that they are configured as expected.

If you have customized or somehow otherwise edited the default MSI Package eligibility condition, InstallShield leaves your custom condition during the upgrade. It is recommended that you review the eligibility conditions for your .msi packages to ensure that they are configured as expected.

Previously, the default MSI Package condition for the Eligibility Condition setting of .msi packages used asterisks (*) in the condition’s Product Code and Product Version settings as placeholders for the package’s own product code and product version.

Changes to the Interpretation of Ampersands in the Wizard Interface of Advanced UI and Suite/Advanced UI Installations

The interpretation of ampersands in certain areas of the wizard interface of Advanced UI and Suite/Advanced UI projects has been modified.

For new InstallShield 2015 projects, as well as projects that you created in InstallShield 2014 or earlier and then upgrade to InstallShield 2015, if you use an ampersand (&) in any of the following areas of the wizard interface of your installation, the installation now displays the ampersand as a literal character instead of interpreting it as a prefix character for a keyboard shortcut. The change also applies if any of these strings include a property that resolves to a value that contains an ampersand.

The string in the header area of a wizard page or secondary window—This is configured in the Title setting for a wizard page or window in the Wizard Interface view.
The caption bar of wizard pages—This is configured in the Wizard Caption setting for the Wizard Pages node in the Wizard Interface view.
The supplemental explanation area of a command link control—This is configured in the Note setting for a wizard page or window.
The alternate text for an image control—This is configured in the Alt Text setting of an image control on a wizard page or window.

Furthermore, for most label controls, True is now selected by default for the SS_NOPREFIX subsetting under the Style setting; previously False was selected by default. A True value for this subsetting ensures that any ampersands that are included in the string entries for such controls are not inadvertently interpreted as keyboard shortcuts, and that ampersands in the control's strings are displayed as ampersands in the wizard interface.

These SS_NOPREFIX changes apply to the built-in default and predefined wizard pages and windows that are available for new InstallShield 2015 projects. If you upgrade an InstallShield 2014 or earlier project to InstallShield 2015, the SS_NOPREFIX settings are changed automatically for the standard built-in default wizard page and windows. However, no changes are made automatically to custom wizard pages and windows—including the predefined wizard pages—when you upgrade these projects to InstallShield 2015; if you want to change the ampersand interpretation of these, you can do so manually

Previously, to work around problems with an ampersand being used inadvertently to designate a keyboard shortcut in any of the aforementioned areas of the wizard interface, and instead show a single ampersand, it was possible to use an escaped ampersand (&&) in place of a single ampersand. However, if you upgrade a project that contains one or more instances of those workarounds to InstallShield 2015, the escaped ampersand is now displayed literally as two ampersands. Thus, it may be necessary to review the use of ampersands in the wizard interface of your projects and make changes as needed.

For more information, see Designating Keyboard Shortcuts and Using Ampersands (&) in the Wizard Interface.

Trialware Support

InstallShield no longer includes support for creating the Try and Die or the Try and Buy/Product Activation types of trialware. The Trialware view is no longer included in InstallShield.

See Also