Upgrading Projects from InstallShield 2008 or Earlier

InstallShield 2016

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

General Information about Upgrading Projects that Were 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 .766 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 2016 projects in earlier versions of InstallShield.

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

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: Windows Installer Is Not Included

When you create a new release in a Basic MSI or InstallScript MSI project, the redistributable for the Windows Installer engine is no longer included by default:

This change applies to all new releases that are created in new InstallShield 2016 projects.

If you upgrade a project from InstallShield 2008 or earlier to InstallShield 2016, this change applies to all new releases; InstallShield does not automatically change the value for releases that were originally created in the earlier InstallShield version.

Upgrade and Patch Validation

When you build QuickPatch projects, InstallShield now runs patch and upgrade validation. Therefore, when you build a QuickPatch package in InstallShield 2016, you may see validation errors and warnings. If you built a QuickPatch project in InstallShield 2008 or earlier, InstallShield did not run the upgrade and patch validation; thus, patch or upgrade validation errors or warnings were never displayed at build time.

In addition, the Val0015 warning now checks the ISSelfReg table in QuickPatch projects and in patches that are created through the Patch Design view in Basic MSI and InstallScript MSI projects. If a QuickPatch or patch project adds a row to the ISSelfReg table, Val0015 warns you that the patch will be uninstallable. Previously, Val0015 did not check for entries in this table.

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 or a ISSetup.dll file, InstallShield now compresses files that it streams into the Setup.exe file or the ISSetup.dll 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 Basic MSI and InstallScript MSI projects as well as existing Basic MSI and InstallScript MSI projects that are upgraded from InstallShield 2008 or earlier to InstallShield 2016.

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 and ISSetup.dll.

Previously, InstallShield did not include any support for compressing files that were streamed into the Setup.exe file or the ISSetup.dll file at build time. Thus, if you compare a release that was built in InstallShield 2008 or earlier with the same release that is built with the default compression level in InstallShield 2016, you may notice that the file size of Setup.exe or ISSetup.dll 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 network image release in which the compression type is the standard compression type (not custom compression) and 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 Basic MSI and InstallScript MSI projects as well as existing Basic MSI and InstallScript MSI projects that are upgraded from InstallShield 2008 or earlier to InstallShield 2016.

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.

Automation Interface and Standalone Build

If you have existing automation scripts that work with the InstallShield Automation Interface, you no longer need to change the library name from IswiAutoN to SAAutoN (where N indicates the version number) throughout the scripts in order to use them with the Standalone Automation Interface.

The Standalone Build that is available with InstallShield Premier Edition now uses the same directory structure that InstallShield uses.

The ISCmdBld.exe file that is used for command-line builds with InstallShield is now installed with the Standalone Build. Previously, the Standalone Build used IsSaBld.exe, a different file, for command-line builds.

FlexNet Connect Support in InstallScript Projects

InstallScript projects no longer include an Update Notifications view, which is used to add FlexNet Connect support to an installation. Note that this view is still available in Basic MSI and InstallScript MSI projects.

Note the following details about FlexNet Connect support in InstallScript projects:

Note that if you upgrade an InstallScript project from InstallShield 2008 or earlier to InstallShield 2016 and you had overridden these events in the earlier version of your project, the aforementioned functions are called. This should not cause any problems. The functions now return ISERR_NOT_IMPLEMENTED.

Also, the OnFirstUIAfter event handler was updated to not include the option of calling SdFinishUpdate, which was disabled previously by default.

FlexNet Connect Support in InstallScript MSI Projects

The following FlexNet Connect–related functions have been deprecated for InstallScript MSI projects:

All calls to the SetUpdateStatus and SetUpdateStatusReboot functions were removed from the default InstallScript code.

Multilanguage Support in Basic MSI and InstallScript MSI Projects

If an installation includes multilanguage support and end users launch Setup.exe again (after the product is already installed) to run the installation in maintenance mode, the language selection dialog is no longer displayed. The maintenance dialogs are displayed in the same language that was used to originally install the product.

Similarly, if a multilanguage minor upgrade or small update is run to update an earlier version of an already installed product, the language selection dialog is not displayed. The upgrade dialogs are displayed in the same language that was used to originally install the product.

This behavior helps ensure that the same language that was used to run the original installation and install its features is also used to repair the original installation, as well as to add other features that were not originally installed but are installed during maintenance mode or upgrades.

InstallScript Multi-Instance Support

For an InstallScript multilanguage, multi-instance installation that displays the language selection dialog, the instance selection dialog is now displayed before the language selection dialog. The dialog order change enables end users to select a different language for a new instance of the product. If end users specify in the instance selection dialog that they want to maintain an existing instance, the language selection dialog is not displayed. Note that when the instance selection dialog is displayed, it is displayed in the same language that would be used to display the language selection dialog.

If multiple instances of a non-multi-instance installation are installed through the Setup.exe /ig command-line parameter, the language selection dialog is displayed only during a first-time installation; it is not displayed during maintenance mode. This helps ensure that the same language that was used to run the original installation and install its features is also used to repair the original installation, as well as to add other features that were not originally installed but are installed during maintenance mode.

During an InstallScript full-release installation that does not display the instance selection dialog—such as an installation that is run in silent mode or with the Setup.exe -hide_usd command-line parameter—the installation automatically installs a new instance. This behavior occurs for all new InstallShield 2016 projects, as well as projects that are upgraded from earlier versions to InstallShield 2016. In InstallShield 2008, /hide_usd resulted in the first installed instance being maintained, and silent mode resulted in a new instance being installed. In InstallShield 12 and earlier, the first installed instance would be maintained in both the /hide_usd and silent mode scenarios.

For a differential media, the first instance read is updated.

During a non-multi-instance installation on a system where two or more instances are installed (using the Setup.exe /ig command-line parameter), the instance selection dialog is displayed. The instance selection dialog does not allow a new instance to be installed during a non-multi-instance installation because a non-multi-instance installation does not generate a new random GUID for the new instance. The instance selection dialog includes the “default” instance (the instance whose GUID matches the product code) if it installed and it is one of the instances that can be maintained. This behavior applies to all new InstallShield 2016 projects, as well as projects that are upgraded from earlier versions of InstallShield.

If a single instance is installed, the installation automatically attempts to maintain the installed instance; it does not show the instance selection dialog. Note that is true even if the installed instance is not the default instance. As a result of this behavior, if the default instance is not installed but a non-default instance is installed (using the /ig parameter), it is not possible to install or maintain the default instance without (a) first uninstalling the non-default instance or (b) specifying the GUID of the default instance through the /ig parameter. Therefore, if you support using the /ig parameter to install multiple instances, it is recommended that you always use this parameter. This behavior applies to all new InstallShield 2016 projects, as well as projects that are upgraded from earlier versions of InstallShield.

For InstallShield 2008, if a non-multi-instance installation was run on a target system that had multiple instances installed, the instance selection dialog was not displayed; in this case, the default instance was always used. For InstallShield 12 and earlier, if a non-multi-instance installation was run on a target system that had multiple instances installed, the instance selection dialog was displayed; this dialog did not allow a new instance to be displayed (because a non-multi-instance installation does not generate a new random GUID for the new instance). However, the title bar of the dialog indicated that the end user should select an instance to update; it should have indicated that the end user should select an instance to update or maintain.

Changes for SdRegisterUser, SdRegisterUserEx, SdCustomerInformation, and SdCustomerInformationEx in InstallScript MSI Installations

In an InstallScript MSI installation, the following InstallScript text substitutions now map directly to Windows Installer properties:

Therefore, when these InstallScript variables are set and retrieved, the corresponding Windows Installer properties are set and retrieved. The default values for these variables are no longer read from the registry; instead the Windows Installer properties are used by default. To use the previous functionality, you can set the variables manually through the following sample code:

// Registered Owner (Only load from registry if pre-loaded value (from log file) is "")

if( !StrLengthChars( IFX_PRODUCT_REGISTEREDOWNER ) ) then

    szValue = "";

    RegDBGetItem( REGDB_WINCURRVER_REGOWNER, szValue );

    if( StrLengthChars( szValue ) ) then

        IFX_PRODUCT_REGISTEREDOWNER = szValue;

    endif;

endif;

// Registered Company (Only load from registry if pre-loaded value (from log file) is "")

if( !StrLengthChars( IFX_PRODUCT_REGISTEREDCOMPANY ) ) then

        szValue = "";

        RegDBGetItem( REGDB_WINCURRVER_REGORGANIZATION, szValue );

        if( StrLengthChars( szValue ) ) then

            IFX_PRODUCT_REGISTEREDCOMPANY = szValue;

        endif;

endif;

In an InstallScript MSI installation, the various registration-related dialogs—SdRegisterUser, SdRegisterUserEx, SdCustomerInformation, and SdCustomerInformationEx—now set IFX_PRODUCT_REGISTEREDOWNER, IFX_PRODUCT_REGISTEREDCOMPANY, and IFX_PRODUCT_REGISTEREDCOMPANY as appropriate based on the end users’ selections. This automatically updates the corresponding Windows Installer properties.

When a null string ("") is specified for either svName or svCompany for the any of the registration-related dialog functions (SdRegisterUser, SdRegisterUserEx, SdCustomerInformation, or SdCustomerInformationEx), the functions use the appropriate variable (determined from the corresponding Windows Installer property) as the default. Previously, the variables were used only if both svName and svCompany were null; for SdCustomerInformation and SdCustomerInformationEx, the values were read directly from the Windows Installer properties, bypassing the script variables.

If a null string ("") is specified for the svSerial parameter, the default value for the serial number field is now set to IFX_PRODUCT_REGISTEREDSERIALNUM. Previously in this case, the dialog displayed no value.

The following InstallScript variables are new or have been changed:

The registration dialogs now automatically disable (or hide) the per-user radio button on Windows 9x regardless of the value of DISABLE_ALLUSERBTN. Previously, the per-user radio button was disabled only if DISABLE_PERUSERBTN was FALSE.

Note also that the registration dialogs automatically disable (or hide) the all-users radio button if the end user is not an administrator or power user, regardless of the value of DISABLE_ALLUSERBTN. This behavior has not changed.

These changes apply to all new InstallScript MSI projects that are created in InstallShield 2016, as well as InstallScript MSI projects that were created in earlier versions of InstallShield and then upgraded to InstallShield 2016.

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 2016, as well as all projects that are created in earlier versions and then upgraded to InstallShield 2016.

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:

Web Downloader Option to Wrap a 1.x .msi Package into a .cab File Is No Longer Available

InstallShield no longer includes an option to specify that an .msi package should be wrapped into a .cab file. This option was previously available for the Web Downloader type of media in Basic MSI and InstallScript MSI projects in which the Windows Installer 1.1 or 1.2 was included. The recommended method is to use Windows Installer 2.0 or later and to digitally sign the package.

Status Text in InstallScript MSI Projects

The OnFirstUIBefore, OnMaintUIBefore, OnAdminInstallUIBefore, OnAdminPatchUIBefore, OnPatchUIBefore, OnUninstall, and OnResumeUIBefore event handlers in an InstallScript MSI project now include SetStatusExStaticText calls by default in all new InstallScript MSI projects. This new default code sets status text for the STATUSEX dialog; the status text that is displayed is now appropriate for the type of operation (first-time installation, maintenance, uninstallation, repair, etc.) being performed. Previously, it was necessary to manually add the SetStatusExStaticText calls; otherwise, the status text that was displayed did not correspond with the type of operation being performed.

Note that if you upgrade an InstallScript MSI project from InstallShield 2008 or earlier to InstallShield 2016 and you had overridden one or more of the updated events in the earlier version of your project, you must manually add the SetStatusExStaticText code to these events.

Changes for the InstallScript Variable SHELL_OBJECT_FOLDER

You can specify SHELL_OBJECT_FOLDER (for InstallScript or InstallScript MSI projects) or <SHELL_OBJECT_FOLDER> (for InstallScript projects) in the Display Name setting for a folder in the Shortcuts view. Then you can define the display name for the folder at run time by setting the SHELL_OBJECT_FOLDER variable in your script before the shortcut is created. The shortcut is typically created during file transfer.

To use this functionality in an InstallScript MSI installation, any letters that are specified for the Key Name setting of the folder in the Shortcuts view must be all uppercase (for example, NEWFOLDER1).

SHELL_OBJECT_FOLDER is now initialized to the same value as IFX_PRODUCT_NAME during initialization. Note that these variables are not synchronized once initialized; therefore, if you change one and want the other to change, you must change both manually.

Note that also as part of this change, the default OnFirstUIBefore event handler code in InstallScript MSI projects no longer includes the following line of code:

SHELL_OBJECT_FOLDER = @PRODUCT_NAME;

If you have an InstallScript MSI project that was created in InstallShield 2008 or earlier and you modified the default OnFirstUIBefore code, InstallShield does not remove this line from your code when you upgrade your project to InstallShield 2016.

To learn more, see SHELL_OBJECT_FOLDER.

Change in Behavior for the InstallScript Function FeatureFileEnum

If you use the question mark (?) as a wild-card character for the szQuery parameter of the InstallScript function FeatureFileEnum, the function now uses the question mark as a substitute for exactly one character. If you used the question mark as a wild-card character with FeatureFileEnum in a project that you created in an earlier version of InstallShield, you may need to change your InstallScript code when you upgrade it to InstallShield 2016. In earlier versions of InstallShield, the function used the question mark as a substitute for one or zero characters.

For example, if you create a new InstallScript project with default settings and add the following InstallScript code to your project, the dialog that is displayed at run time does not display anything.

#include "ifx.h"

   LIST listFiles;

program

   listFiles = ListCreate( STRINGLIST );

   FeatureFileEnum( MEDIA, "DefaultFeature", "Default?Component", listFiles, NO_SUBDIR );

   SdShowInfoList( "", "", listFiles );

endprogram

In installations that were created earlier versions of InstallShield, the dialog displayed DefaultComponent.

All InstallScript Installations Now Support Showing Update UI

All InstallScript projects now support showing the update user interface (UI). Previously, the General Information view and the Project Settings dialog box had a confusing option that enabled the update UI to be disabled. If the update UI was disabled, the MEDIA_FLAG_UPDATEMODE_SUPPORTED flag was not set for MEDIA_FIELD_MEDIA_FLAGS, and the OnSetUpdateMode event handler did not set the UPDATEMODE variable when appropriate. As a result, the update UI was not shown.

Note that changing the value of ISShowUpdateUI in the InstallShield table (which the previous option updated) no longer has any effect.

It is possible to duplicate the previous functionality through the following methods:

Changes for the Certified for Windows Vista Validation Suites

The two Certified for Windows Vista validation suites that help you determine whether your installation or merge module meets the requirements for the Windows Vista logo program have been revised. They now consist of only the InstallShield ICEs (ISICEs). The Microsoft-created ICEs (ICE01 through ICE99) have been removed, since they are available in the Full MSI Validation Suite for installation packages and in the Merge Module Validation Suite for merge modules.

In addition, these two suites have been renamed:

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

Updated InstallScript Objects and Object Templates

A number of improvements were made to the InstallScript objects and InstallScript object templates that are available for use with InstallShield 2016 InstallScript projects.

If you have an Internet connection, you can use the Check for Updates feature in InstallShield to obtain the updated InstallScript objects and object templates for the version of InstallShield that you are using. To check for updates: On the Tools menu, click Check for Updates. InstallShield launches FlexNet Connect, which checks for updates.

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.

Unicode and ANSI 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 Basic MSI project. Previously, if your Basic MSI 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 release in a Basic MSI project in InstallShield 2016, the default setup launcher type is Unicode. In addition, if you create a new patch configuration or a new QuickPatch project in InstallShield 2016, the default update launcher type is Unicode.

If you upgrade a Basic MSI project from InstallShield 2008 or earlier to InstallShield 2016, the setup launcher type for any existing releases is ANSI. You can override the type if appropriate.

Similarly, if you upgrade a Basic MSI project or a QuickPatch project from InstallShield 2008 or earlier to InstallShield 2016, 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 Basic MSI, InstallScript MSI, and Merge Module projects.

If you create a new dynamic file link in InstallShield 2016, InstallShield uses the best practice method by default.

All dynamic file links that are created in InstallShield 2008 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 or earlier to InstallShield 2016, 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 and Associated Components

InstallShield now includes support for installing IIS Web sites without any virtual directories. In addition, InstallShield now lets you associate a Web site with a component. As a result of these enhancements, a Web site is created on a target machine if a virtual directory or a component that is associated with it is installed.

If you add a new Web site through the Internet Information Services view in InstallShield 2016, InstallShield automatically associates that Web site with a component. If you upgrade an InstallShield 2008 or earlier project that already has an IIS Web site, InstallShield does not automatically associate that Web site with a component. Use the General tab that InstallShield displays when you select a Web site in the Internet Information Services view if you want to associate the selected Web site with a component.

Note that if a Web site is associated with a component, the Web site’s Delete Web Site on Uninstall check box now corresponds with the Permanent setting for that component in a Basic MSI or InstallScript MSI project, or with the Uninstall setting for that component in an InstallScript project. That is, if you select or clear the Delete Web Site on Uninstall check box for a Web site, InstallShield automatically updates the value of the component’s Permanent setting or Uninstall setting, as appropriate.

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 or earlier to InstallShield 2016, 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 Basic MSI and InstallScript MSI 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 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. To avoid this behavior in a project that you upgrade from InstallShield 2008 or earlier to InstallShield 2016, open the Custom Actions and Sequences view and delete the Not Installed value from the Install Exec Condition setting for this custom action.

New Sequence Location for the MigrateFeatureStates Action

By default, the MigrateFeatureStates action is now sequenced immediately after the CostFinalize action in all new Basic MSI and InstallScript MSI projects. If you use the SQL Scripts view to add SQL support to the new project, InstallShield now schedules the InstallShield built-in custom action ISSQLServerFilteredList after the MigrateFeatureStates action. In InstallShield 2008 and earlier, the ISSQLServerFilteredList was sequenced before the MigrateFeatureStates action, and this caused run-time error 2601. To avoid this error in a project that you upgrade from InstallShield 2008 or earlier to InstallShield 2016, open the Custom Actions and Sequences view and move the ISSQLServerFilteredList action after the MigrateFeatureStates in the Installation User Interface sequence.

Template Summary Property Changes

You can specify a value for the Template Summary property in the General Information view or for a product configuration in the Releases view. If you try to enter an invalid value (for example, if you indicate multiple platforms or you use more than one semicolon), InstallShield displays a warning message box and does not allow you to change the value for the property.

Earlier versions of InstallShield permitted you to enter invalid values. If you upgrade an InstallShield 2008 or earlier project to InstallShield 2016, InstallShield does not automatically change the invalid value. However, you can manually update the value if appropriate. For more information, see Using the Template Summary Property.

Welcome Assistant Removed

The Welcome Assistant, which was displayed the first time that you opened InstallShield, is no longer included.

InstallShield MSIPackageDiff Replaced by InstallShield MSI Diff

The tool called InstallShield MSIPackageDiff is no longer included with InstallShield. It has been replaced by a more powerful tool called InstallShield MSI Diff. You can launch InstallShield MSI Diff from within InstallShield: On the Tools menu, point to Difference, and then click InstallShield MSI Diff.

For more information, see InstallShield MSI Diff.

See Also

What’s New in InstallShield 2009

Upgrading from Earlier InstallShield Versions

Open topic with navigation