Upgrading Projects from InstallShield 2009 or Earlier

InstallShield 2020

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

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

If you use InstallShield 2020 to open a project that was created with an earlier version, InstallShield 2020 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 .768 before converting it. Delete the .768 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 2020 projects in earlier versions of InstallShield.

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

Installing More than One Edition of InstallShield

Only one edition of InstallShield 2020—Premier, Professional, or Express—can be installed on a system at a time. Previously, it was possible to install the Express edition on the same system that had the Premier or Professional edition of the same InstallShield version.

Change to the List of Supported Operating Systems for Running InstallShield

The minimum operating system requirement for systems that run InstallShield (the authoring environment) is now Windows XP or Windows Server 2003. Previously, the minimum operating system requirement was Windows 2000 SP3.

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.

Setup.exe No Longer Runs on Windows 9x, Windows NT 4, or Windows Me Systems

Setup.exe installations that are created in InstallShield can no longer be run on Windows 9x, Windows NT 4, or Windows Me. If an end user tries to launch Setup.exe on a Windows 9x or Windows Me system, Windows displays a message box with the following error: “The FullSetup.exePathAndFileName file expects a newer version of Windows. Upgrade your Windows version.” On Windows NT 4 systems, Windows displays a message box with the following error: “FullSetup.exePathAndFileName is not a valid Windows NT application.”

InstallShield no longer lists these legacy operating systems in any of the areas where target operating systems can be selected. For example, the Installation Requirements tab of the Project Assistant in Basic MSI and InstallScript MSI projects no longer lists these operating systems. In InstallScript projects, the Platforms tab on the Project Settings dialog box no longer lists these operating systems.

If you upgrade an InstallScript project that was created in InstallShield 2009 or earlier to InstallShield 2020, and if the operating system settings in the earlier project contained references to only these legacy operating systems, InstallShield replaces the legacy operating system options with the option for targeting all supported platforms.

Windows Installer 1.x Redistributables Are No Longer Available

InstallShield no longer includes Windows Installer 1.x redistributables, since they target only legacy versions of Windows that are no longer supported. Previously, it was possible to add Windows Installer 1.x redistributables to a project through the Releases view, or through the Release Wizard.

Redistributable for VBScript Runtime Files Is No Longer Available

InstallShield no longer includes the InstallShield object for VBScript Runtime Files. This redistributable targets only legacy versions of Windows that are no longer supported.

InstallScript Dialog Source Code Changes

The InstallScript code for built-in InstallScript dialogs has been moved from individual InstallScript script files (.rul) to a single ISRTScriptDialogs.rul file. In addition, the event class drop-down list in the InstallScript view has a new Dialog Source option. If you select this option, the event handler drop-down list shows all of the built-in InstallScript dialogs. You can select any dialog in this list to customize its code.

InstallShield supports backwards compatibility: If you imported dialog source code into an InstallShield 2009 or earlier project and then you upgrade the project to InstallShield 2020, you can still use that dialog code. However, if you want to use the dialog sources that are now available when you select the dialogs in the event handler drop-down list, you must first make some changes to your upgraded project. Otherwise, you may encounter compile errors. In order to use the dialog code: On the Build menu, click Settings. On the Compile/Link tab, in the Preprocessor Defines box, enter the following:

_ISSCRIPT_NEW_STYLE_DLG_DEFS

After this definition has been added, if any dialogs had previously been imported into the project in earlier versions of InstallShield, the code in these imported .rul files may cause compile errors. These errors would need to be resolved.

If _ISSCRIPT_NEW_STYLE_DLG_DEFS is not defined, a warning message is displayed when the Dialog Source option is selected in the event class drop-down list in the InstallScript view.

The _ISSCRIPT_NEW_STYLE_DLG_DEFS definition is automatically added to all new projects that are created in InstallShield 2020.

This functionality applies to the following project types: InstallScript, InstallScript MSI, and InstallScript Object.

InstallScript Header File Changes

The InstallScript header files (.h) have been reorganized. As a result, some of the .h files are obsolete. If an InstallScript file (.rul) in your project references one or more of these obsolete .h files, a compile warning is displayed whenever you compile your script or build a release. To resolve the warnings, remove any #include statements that reference the obsolete .h files, and rebuild the release. Also, ensure that ifx.h is referenced in an #include statement in your Setup.rul file or in other script files that are referenced by Setup.rul.

InstallScript Changes for Windows API Prototypes

The service-related Windows API prototypes (such as CreateServiceA, StartServiceA, and ControlService) are now prototyped in ISRTWindows.h for all InstallScript, InstallScript MSI, and InstallScript Object projects. They are also now prototyped in ISRTWindows.h for all Basic MSI and Merge Module projects that include InstallScript custom actions.

If you want to use your own definitions for these Windows APIs instead of the ones that are now prototyped for InstallScript, add ISINCLUDE_NO_SERVICEAPI to the list of preprocessor definitions: On the Build menu, click Settings. On the Compile/Link tab, in the Preprocessor Defines box, enter ISINCLUDE_NO_SERVICEAPI. Otherwise, you may encounter compile errors.

Note that the constant ISINCLUDE_NO_WINAPI_H now suppresses only Windows API prototypes, not Windows constants or Windows structure definitions.

Patch Creation (Basic MSI, InstallScript MSI)

InstallShield now uses the Windows Installer 4.5 patching technology to create patches. This change is reported for informational purposes.

New Custom Actions and Database Tables for IIS Support in Basic MSI and InstallScript MSI Projects

If you add IIS support through the Internet Information Services view in a Basic MSI or InstallScript MSI project in InstallShield, InstallShield automatically adds several DLL custom actions to your project to support the IIS functionality. In InstallShield 2020, these custom actions have been enhanced to enable you to add applications to Web sites. In addition, these actions have been renamed to reflect standard naming conventions:

ISIISCosting—This custom action replaces the caExtractIISSuppFiles action.
ISIISRollback—This custom action replaces the caRlbackVRoots action.
ISIISUninstall—This custom action replaces the caRemoveVRoots action.
ISIISInstall—This custom action replaces the caCreateVRoots action.
ISIISCleanup—This custom action replaces the caIISCleanup action.

The entry points of each of the DLL custom actions have been renamed to match the corresponding custom action names.

Note that IIS functionality requires administrative privileges. Therefore, each of these DLL custom actions checks the Privileged property value. The value must be 1; if it is not, an error is displayed at run time. In InstallShield 2009 and earlier, each of the IIS custom actions had a Privileged = 1 condition. In InstallShield 2020, this condition is no longer set when you add new IIS Web sites or other IIS data to your project, since the custom actions check the Privileged property value.

If you upgrade a Basic MSI or InstallScript MSI project that contains IIS support from InstallShield 2009 or earlier to InstallShield 2020, InstallShield automatically updates and renames the custom actions accordingly. In addition, if the condition for an old custom action was not modified from the default condition, InstallShield also removes the Privileged = 1 condition. If a condition was modified, InstallShield leaves the existing condition as is. You can manually modify any of the conditions if appropriate.

In InstallShield 2020, all of the IIS data is stored in the ISIISItem and ISIISProperty tables. In InstallShield 2009 and earlier, the IIS data was stored in the following tables: ISIISAppPool, ISIISCommon, ISIISMetaData, ISIISWebServiceExtension, ISVRoot, ISVRootAppMaps, and ISWebSite. If you upgrade a Basic MSI or InstallScript MSI project that contains IIS support from InstallShield 2009 or earlier to InstallShield 2020, InstallShield automatically moves the IIS data to the new tables; InstallShield also deletes the old tables from the project.

For more information, see:

Managing Internet Information Services
InstallShield Custom Action Reference

Changes for the Redistributables View

The Redistributables view has a new toolbar and group box area that provide robust search and organizational functionality. Use the new Show Details button in this view to show or hide the details pane for the selected redistributable in this view. The details pane provides information such as which files a redistributable installs. The Show Details button replaces the Show Details and Hide Details links that were previously available in the upper-right corner of this view.

The new group box area is below the new toolbar in the Redistributables view. You can drag and drop column headings onto this group box area to organize the list of redistributables in a hierarchical format. If you want InstallShield to separate all of the redistributables in the view into two groups—one whose check box is selected and one whose check box is cleared—drag the check box column to the group box area. This enables you to easily identify all of the redistributables that are included in your project. The result is similar to the behavior that previously occurred if you right-clicked any redistributable and then clicked Show Only Selected Items. Note that the Show Only Selected Items command is no longer available in the Redistributables view.

For more information, see Working with the Group Box Area in Various Views.

Limiting the UI Level of a Chained .msi Package to that of the Main .msi Package

The UI level for a chained .msi package is now limited to be no higher than that of the parent package’s current UI level. For example, in the following scenario, the chained .msi package is launched silently: you add a chained .msi package to your project in the Releases view and select Full UI (/qf) for its UI level setting, but the main installation is launched silently (/qn). Previously, the chained package showed exactly the UI level that was authored in the Releases view of the main installation; to restore this behavior, set the property ISChainExceedUILevel equal to the value 1.

Encoding and Related Differences for XML File Changes

If you use the XML File Changes view to configure changes for a file that is already present on the target machine, or that is being installed as part of your installation, the installation now uses the encoding that is specified in that XML file, rather than the encoding that is specified in the XML File Changes view. This applies to new projects that are created in InstallShield 2020, as well as projects that are upgraded from InstallShield 2009 or earlier.

In addition, if the "Always create this element if it does not already exist" check box is cleared for an element that is not present in the target file, its child elements are no longer created. Thus, for an XML file such as //A/B/C, C is not created on the target system if B is neither present nor set to be created.

Changes to the Major and Minor Version Registry Entries for the Uninstall Key of InstallScript Installations

InstallScript installations now always create VersionMajor and VersionMinor registry values in the Uninstall key; the names of these values now match the entries that are created during Basic MSI and InstallScript MSI installations. This applies to new installations that are created in InstallShield 2020, as well as installations that are upgraded from InstallShield 2009 or earlier. Previously, in InstallShield 2009 and earlier, the names of the values that InstallScript installations created were MajorVersion and MinorVersion; these are no longer created.

In order to use the new registry values, the values of the following InstallScript constants have been changed:

REGDB_VALUENAME_UNINSTALL_MAJORVERSION is now VersionMajor instead of MajorVersion.
REGDB_VALUENAME_UNINSTALL_MINORVERSION is now VersionMinor instead of MinorVersion.

When the MaintenanceStart function is called, it creates the updated value names in the registry. By default, it also deletes the old value names if they exist. If you do not want the old value names to be deleted from target systems, you can use the new REGDB_OPTIONS option called REGDB_OPTION_NO_DELETE_OLD_MAJMIN_VERSION. If you want to continue using only the old value names, you must delete the new versions after MaintenanceStart returns.

If REGDB_UNINSTALL_MAJOR_VERSION or REGDB_UNINSTALL_MINOR_VERSION is used with the RegDBGetItem function, RegDBGetItem first checks for the new value; if the new value is found, the function returns the value data from the new value. If the new value is not found, the function automatically checks for the old value; if the old value is found, the function returns the value data from the old value.

To provide backwards compatibility, the following new constants are available:

REGDB_UNINSTALL_MAJOR_VERSION_OLD
REGDB_UNINSTALL_MINOR_VERSION_OLD

You can specify these constants with the RegDBGetItem, RegDBSetItem, and RegDBDeleteItem functions to get, set, and delete the old values.

The following new string constants are also available:

REGDB_VALUENAME_UNINSTALL_MAJORVERSION_OLD is defined as MajorVersion.
REGDB_VALUENAME_UNINSTALL_MINORVERSION_OLD is defined as MinorVersion.

For more information, see the following in the InstallScript Language Reference:

REGDB_VALUENAME_UNINSTALL_MAJORVERSION
REGDB_VALUENAME_UNINSTALL_MAJORVERSION_OLD
REGDB_VALUENAME_UNINSTALL_MINORVERSION
REGDB_VALUENAME_UNINSTALL_MINORVERSION_OLD
REGDB_UNINSTALL_MAJOR_VERSION_OLD
REGDB_UNINSTALL_MINOR_VERSION_OLD
REGDB_OPTIONS
RegDBSetItem
RegDBGetItem
RegDBDeleteItem

Removal of the SdShowMsg Dialog from the List of Editable Dialogs

The Dialog Editor does not currently support dialogs, such as SdShowMsg, that do not have a title bar; if you try to customize the SdShowMsg dialog, it may get corrupted. Therefore, this dialog is no longer displayed in the Dialogs view as one of the dialogs that you can edit. To customize this dialog, you should use the SdShowMsg call, not the Dialog Editor.

Automation Interface Changes

The value of the eosAll constant for the OSFilter, which is a member of the ISWiComponent and ISWiRelease objects in the automation interface, has been changed. The new value is 64028880; previously, it was 5308624. If you are using the value of this constant to configure the list of operating systems for a component or a release through the automation interface, you must update your script to use the new value.

For more information, see the following:

ISWiComponent Object
ISWiRelease Object

Changes for the Locations of InstallScript Run-Time Script, Library, and Header Files

The InstallScript run-time library files that are installed with InstallShield have been consolidated into a central location, instead of several separate subdirectories. The script, library, and header files are now installed in Src, Lib, and Include folders in the following directory:

InstallShield Program Files Folder\Script\Isrt

The following folders are no longer installed, since the files within them are consolidated in the above location:

InstallShield Program Files Folder\Script\IISRuntime

InstallShield Program Files Folder\Script\SQLRuntime

InstallShield Program Files Folder\Script\XMLRuntime

Note that because of a name conflict, the Assert.h file in the following location is being renamed as ISAssert.h:

InstallShield Program Files Folder\Script\Isrt\Include

If you create a new project in InstallShield 2020, it uses the new locations of the files. If you upgrade a project from InstallShield 2009 or earlier to InstallShield 2020, InstallShield updates the projects to use the new locations.

Changes in the Way that Linked Libraries and Their Locations Are Specified

The Compile/Link tab on the Settings dialog box has a new Additional Library Paths box that lets you specify the locations where the InstallScript compiler should search for InstallScript libraries (.obl files) that are not one of the standard InstallShield locations. For InstallScript and InstallScript Object projects, the standard locations are:

<ISProductFolder>\Script\Ifx\Lib
<ISProductFolder>\Script\Isrt\Lib

For Basic MSI and InstallScript MSI projects, the standard locations are:

<ISProductFolder>\Script\Iswi\Lib
<ISProductFolder>\Script\Isrt\Lib

If you create a new project in InstallShield 2020, InstallShield automatically lists the standard InstallShield script libraries such as ISRT.obl in the Libraries (.obl) box on the Compile/Link tab. However, InstallShield no longer includes the full path in that box. If you want to add your own custom libraries, you can specify the library file name in the Libraries (.obl) box, and the path in the Additional Library Paths box. You do not need to specify the full path and file name in the Libraries (.obl) box.

If you upgrade a project that was created in InstallShield 2009 or earlier to InstallShield 2020, InstallShield automatically removes the path of the standard script libraries that are listed in the Libraries (.obl) box. For more information, see Compile/Link Tab.

Removal of the InstallScript Structure Definition for ISOSVERSIONINFO

The definition of the ISOSVERSIONINFO structure, as well as the corresponding unused global instances of this structure, has been removed. The equivalent OSVERSIONINFO structure is still available. This definition removal does not cause any functionality changes; however, if you attempt to use the ISOSVERSIONINFO structure definition or global structure instances, a compiler error results.

To avoid a compiler error, do either of the following:

Update the script to use the equivalent OSVERSIONINFO structure, and declare a local instance of this structure if needed. Update the script to use the appropriate structure member names. (Note that the OSVERSIONINFO member names are different than the ISOSVERSIONINFO member names.) Following is the definition of OSVERSIONINFO:

typedef OSVERSIONINFO

    begin

        NUMBER nOSVersionInfoSize;

        NUMBER nMajorVersion;

        NUMBER nMinorVersion;

        NUMBER nBuildNumber;

        NUMBER nPlatformId;

        STRING szCSDVersion[128];

    end;

Declare the structure and structure instances locally as follows:

// Data structure that contains operating system version information.

// Used by ISCompareServicePack.

typedef ISOSVERSIONINFO // define a structure

begin

    LONG ISIOSVersionInfoSize;    // Size in bytes of this data structure

    LONG ISIMajorVersion;         // Major version number of the OS.

    LONG ISIMinorVersion;         // Minor version number of the OS.

    LONG ISIBuildNumber;          // Build number of the OS.

    LONG ISIPlatformId;           // Operating system platform.

    STRING szISCSDVersion [128];  // Additional information about OS.

end;

 

// Variable for the operating system version information data structure.

// Used by ISCompareServicePack.

ISOSVERSIONINFO ISVersion;

 

// Pointer that points to the OS version information variable.

// Used by ISCompareServicePack.

ISOSVERSIONINFO POINTER pISVersion;

Obsolete Keys Are No Longer Written to Setup.ini for InstallScript Projects

The following keys are obsolete and are no longer written to the Setup.ini file for InstallScript projects: Resource, EngineVersion, and EngineBinding.

ISCab.exe Is No Longer Available

ISCab.exe is no longer supported. Therefore, it is no longer included with InstallShield.

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.

Changes to Support for Securing Permissions for Files, Folders, and Registry Keys

The General Information view has a new Locked-Down Permissions setting that lets you specify whether you want to use the new custom InstallShield handling or the traditional Windows Installer handling for all new permissions that you set for files, folders, and registry keys in your project. The new custom InstallShield handling option offers several advantages over the traditional Windows Installer handling option.

In all new projects, the default value for this setting is the custom InstallShield handling option. If you upgrade a project from InstallShield 2009 or earlier to InstallShield 2020, the traditional Windows Installer handling option is the default value of this setting.

This new setting is available in the following project types: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.

For more information, see the following:

Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment
Selecting the Locked-Down Permissions Type for a Project

Changes to the ReadyToInstall Dialog for Beta Windows Installer 5 Support of Per-User Installations

The General Information view has a new Show Per-User Option setting. This setting lets you specify whether you want the ReadyToInstall dialog—in certain scenarios—to include buttons that let end users indicate how they want to install the product: for the current user or for all users. The per-user button sets the new Windows Installer property MSIINSTALLPERUSER equal to 1 to indicate that the package should be installed for the current user. The MSIINSTALLPERUSER property is available with the beta of Windows Installer 5.

If you create a new Basic MSI project in InstallShield 2020, the ReadyToInstall dialog includes support for the per-user and per-machine buttons; these buttons are displayed or hidden at run time if appropriate. If you upgrade a Basic MSI project from InstallShield 2009 or earlier to InstallShield 2020, the ReadyToInstall dialog does not have this support automatically. You can manually add these buttons and their associated conditions to the ReadyToInstall dialog if appropriate; use the ReadyToInstall dialog in a new InstallShield 2020 project as a guideline.

Public Directory Properties for Feature Destinations Are Added to SecureCustomProperties

When you specify a location for the Destination setting of a feature and the location includes a public directory property, InstallShield now adds that property to the SecureCustomProperties property to allow end users to change the destination after the product has been advertised. This occurs in new projects that are created in InstallShield 2020. The change is also made for all feature destinations if you upgrade a project from InstallShield 2009 or earlier to InstallShield 2020.

This change applies to the following project types: Basic MSI and InstallScript MSI.

Changes to the Conditions for the InstallWelcome Dialog and the ResolveSource Action

The condition on the InstallWelcome dialog and the ResolveSource action has been changed to Not Installed for all new Basic MSI projects that are created in InstallShield 2020. The conditions were changed so that the InstallWelcome dialog and the ResolveSource action can be used for a first-time installation with a patch. If you upgrade a Basic MSI project from InstallShield 2009 or earlier to InstallShield 2020, the conditions are not changed automatically. If you want the dialog and action to be used for a first-time installation with a patch, you can change the conditions in your upgraded project to Not Installed.

Improvements to the .rtf File Size Limit for the SdLicenseRtf and SdLicense2Rtf Functions

The file size limit for the .rtf files that are used with the InstallScript dialog functions SdLicenseRtf and SdLicense2Rtf is now 16 MB instead of 64 KB. Previously, if the file size was more than 64 KB, part of the EULA text was missing from the license dialog at run time.

Note that if you had overridden the SdLicenseRtf or SdLicense2Rtf functions in your script in InstallShield 2009 or earlier and then upgraded that project to InstallShield 2020, you would need to manually change the size limit by updating the SendMessageTimeout call with the EM_EXLIMITTEXT message in DLG_INIT. The iParam parameter (the fourth parameter) of the SendMessageTimeout call needs to be changed. The SendMessageTimeout call should be changed to this:

SendMessageTimeout( hEdit, EM_EXLIMITTEXT, 0, 0xffffff );

Previously, the code contained this:

SendMessageTimeout( hEdit, EM_EXLIMITTEXT, 0, 0 );

Removal of the OnResolveSource Event Handler from InstallScript MSI Installations

The InstallScript event handler OnResolveSource has been removed from InstallScript MSI projects. The Windows Installer now handles all source resolution. If you added the OnResolveSource event to an InstallScript MSI project in InstallShield 2009 or earlier and then you upgrade that project to InstallShield 2020, that event will no longer be called.

Changes to the Way that a Log File Is Displayed from the SetupCompleteSuccess Dialog in Basic MSI Installations

The ShowMsiLog custom action now launches Notepad.exe from the SystemFolder directory, instead of from the WindowsFolder directory. Thus, if your installation is run on Windows Vista or later and the end user indicates on the SetupCompleteSuccess dialog that they want to view the log file, the installation launches Notepad.exe from the SystemFolder directory. This change was made because on Windows Server 2008 Standard Edition, Notepad.exe is available in the System32 directory, but not the Windows directory.

Note that behavior is available by default in all new Basic MSI projects that are created in InstallShield. If you upgrade an InstallShield 2009 or earlier Basic MSI project to InstallShield 2020, InstallShield does not automatically change the behavior. You can manually change the behavior if necessary: In the Custom Actions and Sequences view, click the ShowMsiLog action. (If this action is not displayed, right-click the Custom Actions node and then click Show All Custom Actions.) Set the Filename & Commandline setting as follows:

[SystemFolder]notepad.exe "[MsiLogFileLocation]"

Thus, the value should contain [SystemFolder] instead of [WindowsFolder].

Changes for ALLUSERS Property in InstallScript MSI Installations

Beginning with InstallShield 2010, the ALLUSERS property is set to 1 by default in all new InstallScript MSI projects. This is the recommended implementation, since most installations must be run in a per-machine context with administrative privileges. This value is also recommended to help avoid ALLUSERS-related issues when an InstallScript MSI installation is run silently.

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

InstallScript Installations No Longer Include _Setup.dll

InstallScript installations no longer include _Setup.dll. Some earlier versions (DevStudio 9 and InstallShield X) did not log _Setup.dll for uninstallation. As a result, this file was left behind in the Disk1 folder location (DISK1TARGET) after uninstallation. If an update was created with a later InstallShield version (InstallShield 10.5 through InstallShield 2009) and the update was for an original installation that was created with DevStudio 9 or InstallShield X, _Setup.dll was deleted during uninstallation because _Setup.dll was logged by the update. Since _Setup.dll is not included in InstallScript installations that are created with InstallShield 2020, the _Setup.dll file may now be left behind. Therefore, if you are updating from an installation that was created with DevStudio 9 or InstallShield X, you may need to delete the _Setup.dll file manually (DISK1TARGET ^ "_Setup.dll") during uninstallation to ensure that the uninstallation is complete.

Saving a Project as an Earlier Version

InstallShield no longer has support for downgrading a project. That is, you cannot save an InstallShield 2020 project as an InstallShield 2009 or earlier project.

Trialware Support

The only edition of InstallShield that includes the Trialware view is the Premier edition. This edition lets you create the Try and Die type of trialware. InstallShield no longer includes support for creating the Try and Buy/Product Activation type of trialware.

Web Projects

The Web project type is no longer listed as one of the types of new projects that you can create in InstallShield. To use the same functionality that was available with a Web project in InstallShield 2009 and earlier, create a Basic MSI project, and then add a Web site in the Internet Information Services view.

The only difference between a Web project and a Basic MSI project was that a new Web project automatically contained a predefined folder for the IISROOTFOLDER directory in the Files and Folders view. All of the files that you add to the IISROOTFOLDER directory are installed to the Web server’s root directory on the target system. InstallShield adds predefined folder for the IISROOTFOLDER directory to a Basic MSI project when you add a Web site to the project. Thus, a Basic MSI project that contains at least one Web site configured in the Internet Information Services view is equivalent to a Web project that was created in InstallShield 2009 or earlier.

Compact Projects

InstallShield no longer has support for Compact projects.

Visual Studio Integration

Microsoft Visual Studio can be integrated with only one version of InstallShield Premier Edition or InstallShield Professional Edition at a time. The last version of InstallShield that is installed or repaired on a system is the one that is used for Visual Studio integration.

See Also