Upgrading Projects from InstallShield 2008 Express Edition or Earlier

InstallShield 2012 Spring Express Edition

The following information describes changes that may affect projects that are upgraded from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition.

Upgrading Projects Created in Earlier Versions of InstallShield Express Edition

If you use InstallShield 2012 Spring Express Edition to open a project that was created with an earlier version, InstallShield 2012 Spring Express Edition 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 .766 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 2012 Spring Express Edition projects in earlier versions of InstallShield Express Edition.

You can migrate projects that were created with the following versions of InstallShield Express Edition to InstallShield 2012 Spring Express Edition: InstallShield 12 Express Edition and earlier and InstallShield Express 5 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal cannot be migrated to InstallShield 2012 Spring Express Edition.

Changes that Affect All Projects (New and Upgraded Projects)

This section describes changes that affect both new projects and projects that are upgraded from earlier versions of InstallShield.

New Default Setup Launcher Value for New Releases and New QuickPatch Projects: Windows Installer Is Not Included

When you create a new Express or QuickPatch project, the redistributable for the Windows Installer engine is no longer included by default:

In Express projects, the default value for the Setup Launcher setting on the Setup.exe tab is now Yes (no MSI engine included). Previously, the default value for this setting was Yes (include Windows NT & Windows 9x MSI engine).
In QuickPatch projects, the Include Windows Installer 2.0 engine and Include Windows Installer 3.0 engine check boxes on the Common tab in the General Information view are cleared by default. Previously, these check boxes were selected by default.

These changes apply to all new Express and QuickPatch projects that are created in InstallShield 2012 Spring Express Edition.

If you upgrade an Express or QuickPatch project from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition, InstallShield does not automatically change the values of the aforementioned settings.

File Compression for Files that Are Streamed into Setup.exe and ISSetup.dll at Build Time

If you build a release that uses a Setup.exe setup launcher, InstallShield now compresses files that it streams into the Setup.exe file at build time. The default compression level that InstallShield uses offers a balance between file size and time that is required to extract the compressed files at run time. This applies to new Express projects as well as existing Express projects that are upgraded from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition.

If you want to change the compression level or you do not want to use any compression, you can override the default level through a machine-wide setting. For more information, see Configuring the Compression Level for Files that Are Streamed into Setup.exe.

Previously, InstallShield did not include any support for compressing files that were streamed into the Setup.exe file at build time. Thus, if you compare a release that was built in InstallShield 2008 Express Edition or earlier with the same release that is built with the default compression level in InstallShield 2012 Spring Express Edition, you may notice that the file size of Setup.exe is slightly different. In addition, the time that is required to extract files may be slightly different.

Multi-Part .cab Files

InstallShield now has a default limit of 600 MB for each .cab file that it creates at build time for a SingleImage release where all of the files are embedded in a single-file .msi package or a Setup.exe setup launcher. When InstallShield is creating the .cab files for this type of release and it reaches this limit, it splits the data into two or more .cab files, creating multi-part .cab files. This applies to new Express projects as well as existing Express projects that are upgraded from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition.

You can modify the .cab size limit if necessary. In addition, if you do not want InstallShield to create multi-part .cab files, you can configure it to create single .cab files. For more information, see Configuring the Maximum Size for .cab Files.

Previously, InstallShield did not create multi-part .cab files, and there was no built-in limit for the .cab file size.

Proxy Server Support

You may want to configure your installation to download certain files only if they are needed on the target system. For example, the Windows Installer engine, the .NET Framework, and some InstallShield prerequisites may already be present on some or most target systems. Instead of embedding these files in your installation (which would increase your overall installation size), you can configure your project so that only the ones that are needed are downloaded at run time.

If your end users access the Internet through a proxy server and your installation is configured to download files, the installation now uses the system proxy settings that are manually configured in Internet Explorer during the download. This occurs even if another browser on the target system is the default browser.

Note that InstallShield does not include support for the Automatically Detect Settings functionality in Internet Explorer. (If end users have the Automatically Detect Settings check box selected in Internet Explorer for their LAN connection and the installation needs to download files, the installation fails because the files cannot be downloaded. If it is possible that your end users may have the Automatically Detect Settings check box selected in Internet Explorer for their LAN connections, you may want to embed all of the files in your installation rather than configure them to be downloaded; if the files are embedded, the failures can be avoided.) However, InstallShield does support the Automatic Configuration Script functionality that is set up for LAN connections in Internet Explorer.

This is the behavior for all new projects in InstallShield 2009, as well as all projects that are created in earlier versions and then upgraded to InstallShield 2009.

In InstallShield 2008 and earlier, the installation attempted to use the proxy server settings that were configured in whatever browser was the default browser. However, this was not always possible, and it caused some problems:

If Netscape 6 or 7 was the default browser, the Netscape 4 settings were used. If Netscape 8 or 9 was the default browser, the system (Internet Explorer) settings were used.
If Netscape 4 settings were used, only the proxy server list was read and imported correctly. The proxy bypass list was read, but it was not imported correctly.
Non–Internet Explorer 4 compatible settings such as the auto-proxy script setting were not imported.
The method that the installation used for determining the default browser was not compatible on Windows Vista. Therefore, on Windows Vista systems, an installation may not have detected the default browser correctly.

Rollback Support for Windows Mobile Device Installations

InstallShield now has support for rolling back a Windows Mobile–powered device installation that is included in a desktop-to-device installation if appropriate. This support is made possible through a built-in InstallShield custom action called RollbackCEApps.

With this new custom action, if an end user clicks the Cancel button during the installation of a product for a Windows Mobile–powered device, the installation is rolled back, and any associated .ini files, .cab files, and .ico files are deleted from the target machine.

When you add a Windows Mobile–powered device installation in the Mobile Devices view of a new Express project in InstallShield 2012 Spring Express Edition, InstallShield automatically adds the RollbackCEApps custom action to your project.

InstallShield also adds this custom action if you upgrade an Express project that already has a Windows Mobile–powered device installation in the Mobile Devices view from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition.

Changes for Windows Mobile Support in Express Projects

Express installations that include installations for Windows Mobile–powered devices no longer require the installation to be launched with elevated privileges on Windows Vista systems; elevated privileges are now required only for the Execute sequence.

If you have previously worked around the issue by setting the Required Execution Level setting on the Setup.exe tab for the release to the Administrator option, you can now set it to Invoker.

Changes that Affect New Projects but Not Upgraded Projects

This section describes changes to InstallShield that may affect new projects but not projects that are upgraded from earlier versions. Note that you may need to make manual changes to upgraded projects.

Ability to Create Unicode Versions of the Setup.exe and Update.exe Bootstrappers

InstallShield now enables you to specify whether you want to create a Unicode version or an ANSI version of the Setup.exe setup launcher for a project. Previously, if your project included a setup launcher, InstallShield always built an ANSI version; it did not include support for building a Unicode version.

A Unicode setup launcher can correctly display double-byte characters in the user interface of the setup launcher, regardless of whether the target system is running the appropriate code page for the double-byte-character language. An ANSI setup launcher displays double-byte characters in the setup launcher dialogs if the target system is running the appropriate code page. However, it displays garbled characters instead of double-byte characters in those dialogs if the target system is not running the appropriate code page.

If you create a new Express project in InstallShield 2012 Spring Express Edition, the default setup launcher type is Unicode. In addition, if you create a new QuickPatch project in InstallShield 2012 Spring Express Edition, the default update launcher type is Unicode.

If you upgrade an Express project or a QuickPatch project from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition, the update launcher type for any existing patch is ANSI. You can override the type if appropriate.

Dynamic File Links

When you add or modify a dynamic file link in a project, you can specify which component creation method you want InstallShield to use: a new best practice method or the previously available one-component-per-directory method. These methods are applicable to dynamic file linking in Express projects.

If you create a new dynamic file link in InstallShield 2012 Spring Express Edition, InstallShield uses the best practice method by default.

All dynamic file links that are created in InstallShield 2008 Express Edition or earlier use the one-component-per-directory method. If you have a project with dynamic file links and you upgrade it from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition, InstallShield continues to use the one-component-per-directory method for creating the components of those already present dynamic file links. For any new dynamic file links that you create in the upgraded project, the best practice method is used by default. For detailed information about the two component creation methods, as well as guidance on which method you should use, see Determining the Appropriate Component Creation Method for Dynamically Linked Files.

IIS Web Sites Without Virtual Directories

InstallShield now includes support for installing IIS Web sites without any virtual directories. This support is available for all new Web sites that are created in new InstallShield 2012 Spring Express Edition projects. This support is also available if you upgrade a project from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition and then add a new Web site.

Note that if you upgrade an InstallShield 2008 or earlier project to InstallShield 2012 Spring Express Edition, and the project already contains a Web site, the Web site cannot be installed if it does not have any virtual directories. In order to be able to install the Web site without virtual directories, you must manually delete it from your InstallShield 2012 Spring Express Edition project, and then re-add it to your project as a new Web site.

Simplification of QuickPatch Packages

The new Streamline QuickPatch setting on the Advanced tab in a QuickPatch project determines how InstallShield builds QuickPatch packages. A streamlined QuickPatch package typically has fewer new subfeatures and custom actions than a non-streamlined QuickPatch package.

In some cases, InstallShield cannot streamline the QuickPatch package. For example, if you configure the QuickPatch package to remove an installed file, InstallShield cannot streamline it.

When you create a new QuickPatch project, the default value for the Streamline QuickPatch setting is Yes. However, when you upgrade a QuickPatch project from InstallShield 2008 Express Edition or earlier to InstallShield 2012 Spring Express Edition, the value for this setting is No. You can change this value if appropriate. For more information, see Specifying Whether to Streamline the QuickPatch Package.

Default Condition for the SetARPINSTALLLOCATION Custom Action

By default, all new Express projects contain the built-in InstallShield custom action SetARPINSTALLLOCATION. This custom action, which sets the value of the ARPINSTALLLOCATION property to the fully qualified path for the product's primary folder, is scheduled for the Installation Execute sequence, and it has no condition. In InstallShield 2008 Express Edition and earlier, the default condition for this custom action was Not Installed. With this default Not Installed condition, the custom action is not run during maintenance mode, and this results in a blank value for the ARPINSTALLLOCATION property.

See Also