What’s New in InstallShield 2009

InstallShield 2016

New Features

InstallShield includes the following new features.

Ability to Associate InstallShield Prerequisites with Features for Chaining Installations

InstallShield now enables you to associate InstallShield prerequisites with one or more features. This new type of InstallShield prerequisite is called a feature prerequisite. It is installed if a feature that contains the prerequisite is installed and if the prerequisite is not already installed on the system.

Including InstallShield prerequisites in your project enables you to chain multiple installations together, bypassing the Windows Installer limitation that permits only one Execute sequence to be run at a time. The Setup.exe setup launcher serves as a bootstrap application that manages the chaining.

The Redistributables view is where you add InstallShield prerequisites to a project and specify whether you want them to run before your main installation or be associated with one or more features in your main installation.

Previously, all InstallShield prerequisite installations were run before the main installation ran, and the InstallShield prerequisites could not be associated with any features. This type of prerequisite, which is still available, is called a setup prerequisite.

Basic MSI projects include support for this feature.

To learn more, see:

Beta Windows Installer 4.5 Support for Installation of Multiple Packages Using Transaction Processing

InstallShield lets you add Windows Installer packages to Basic MSI and InstallScript MSI projects as chained .msi packages. If your Basic MSI or InstallScript MSI installation includes chained .msi packages and Windows Installer 4.5 is present on the target system, the Windows Installer installs the multiple packages using transaction processing. The packages are chained together and processed as a single transaction. If one or more of the packages in the transaction cannot be installed successfully or if the end user cancels the installation, the Windows Installer initiates rollback for all of the packages to restore the system to its earlier state.

The Chained .msi Packages area of the Releases view is where you add to your project one or more .msi packages that you want to be chained to your main installation. This area is also where you can assign release flags to the chained .msi packages, configure settings such as the properties that should be passed to the chained packages, and specify conditions.

For more information, see:

Beta Windows Installer 4.5 Support for Using the InstallScript Engine as an Embedded User Interface for InstallScript MSI Installations

For InstallScript MSI projects, you now have the option to use the InstallScript engine as an embedded custom user interface (UI) handler, rather than as an external custom UI handler, as it has traditionally been used. Windows Installer 4.5 includes support for this new capability. Use this new embedded option if you want end users to be able to launch your installation directly from an .msi package, but you also want your installation to include a highly customized user interface that you have defined through InstallScript.

To specify whether you want to use the new embedded InstallScript UI functionality or the traditional external InstallScript UI functionality, use the new InstallScript User Interface Type setting; this is a project-wide setting in the General Information view. By default, InstallShield uses the traditional style for all InstallScript MSI projects; a Setup.exe setup launcher is required for this traditional option.

A new INSTALLSCRIPTMSIEEUI variable is available. This variable is set to True at run time if the new style is used; otherwise, it is set to False.

Note that the new style does have some limitations that the traditional style does not. For example, some of the InstallScript functions and command-line parameters are not supported or behave differently with the new style. For detailed information about the two styles, see Using the InstallScript Engine as an External vs. Embedded UI Handler for InstallScript MSI Installations.

For additional information, see:

Beta Windows Installer 4.5 Support for Shared Component Patching

InstallShield includes support for the new shared component patching feature that is available with Windows Installer 4.5. The new Multiple Package Shared Component setting in the Components view lets you specify whether you want to enable shared component patching for the selected component. Selecting Yes sets a new component attribute that is designed to prevent Windows Installer from downgrading files when patches that contain components shared across multiple packages are uninstalled. The intent is to keep the highest version of a component present on the target system, even if the patch that contains that highest version is being uninstalled. The default value for this option is No.

Windows Installer 4.5 supports this new functionality; earlier versions of Windows Installer ignore this new setting. In addition, if the DisableSharedComponent policy is set to 1 on a target system, Windows Installer ignores this setting for all packages.

This feature applies to Basic MSI, InstallScript MSI, Merge Module, and Transform projects.

To learn more, see Specifying Whether Shared Component Patching Should Be Enabled for a Component.

Beta Windows Installer 4.5 Support for Superseding Components

Use the new Uninstall Superseded Component setting in the Components view to specify how you want Windows Installer 4.5 to handle the selected component during installation of a superseding patch under certain conditions. To specify that this component in the current patch should be flagged for uninstallation in order to avoid leaving this component orphaned on the target system after a superseding patch is applied, select Yes. If a subsequent patch is installed and it is flagged to supersede the first patch, Windows Installer can unregister and uninstall this component if appropriate. If you select No, the superseding patch can leave an orphaned component on the target system, and none of the feature’s remaining components can be maintained. The default value for this setting is No.

Windows Installer 4.5 supports this new functionality; earlier versions of Windows Installer ignore this new setting.

This feature applies to Basic MSI, InstallScript MSI, Merge Module, and Transform projects.

For more information, see the description of the Uninstall Superseded Component setting.

To learn more about patch sequences, see Patch Sequencing.

Beta Windows Installer 4.5 Support for Running a Custom Action Only During Patch Uninstallation

Use the new Run During Patch Uninstall setting for a custom action to indicate whether Windows Installer should run the selected custom action only when a patch is being uninstalled. This setting is available in the Custom Actions and Sequences view of Basic MSI, InstallScript MSI, MSI Database, and Transform projects. It is also available in the Custom Actions view of Merge Module and MSM Database projects.

You can also use the Run During Patch Uninstall check box on the Additional Options panel in the Custom Action Wizard to configure the behavior of a custom action.

For details about this new functionality, see Run During Patch Uninstall.

Beta Support for Windows Installer 4.5 Redistributables

InstallShield includes several InstallShield prerequisite files (.prq) for Windows Installer 4.5.

This feature applies to Basic MSI and InstallScript MSI projects.

For more information, see Adding Windows Installer Redistributables to 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 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.

Use the new Setup Launcher Type setting on the Setup.exe tab for a release in the Releases view to specify whether you want to use Unicode or ANSI. Unicode is the default type for all new Basic MSI projects.

InstallShield also now enables you to specify whether you want to create a Unicode version or an ANSI version of the Update.exe update launcher for a patch or a QuickPatch package.

Use the new Update Launcher Type setting on the Advanced tab for a patch configuration in the Patch Design view to specify whether you want to use Unicode or ANSI. For a QuickPatch project, the Update Launcher Type setting is on the Advanced tab in the Build Settings area of the General Information view. Unicode is the default type for all new patch configurations and QuickPatch packages.

Ability to Create a Log File for the Setup.exe Bootstrapper

A new /debuglog command-line parameter is available for the Setup.exe setup launcher for Basic MSI and InstallScript MSI projects. Use this command-line parameter to generate a log file for debugging. For more information, see /debuglog.

Support for Managed-Code Custom Actions

InstallShield lets you add managed-code custom actions to Basic MSI, InstallScript MSI, and Merge Module projects. This type of custom action calls a public method in a .NET assembly that is written in managed code such as Visual Basic .NET or C#.

For detailed information, see:

Support for Installing Multiple Instances of a Product

InstallShield now includes support for creating an installation that allows an .msi package to be used to install multiple instances of a product in the same context on the same machine. Use the new Multiple Instances tab for a product configuration in the Releases view to define different instances of your product and configure the properties that are associated with each instance.

At build time, InstallShield creates a product code–changing instance transform for each instance and streams the instance transforms into the .msi package. At run time, the setup launcher displays a new instance selection dialog that lets end users specify whether they want to install a new instance, or update or maintain an already installed instance.

In addition, if you build a patch in the Patch Design view for a product whose installation includes multiple-instance support, InstallShield now creates a patch that enables end users to update a specific instance or all instances. At run time, the Update.exe file displays a patch version of the instance selection dialog.

A new /instance command-line option is available for Setup.exe and Update.exe. This option lets you specify which instance you want to install, update, or uninstall; it also lets you suppress the instance selection dialog.

Multiple-instance support is available for Basic MSI projects.

For more information, see:

New Microsoft .NET Redistributables Available

InstallShield now includes many new .NET-related InstallShield prerequisites that you can add to Basic MSI and InstallScript MSI projects:

In addition, an updated Microsoft .NET Framework object is available in InstallShield for InstallScript projects. This object includes support for versions 3.5, 3.0 SP1, 3.0, 2.0 SP1, 2.0, 1.1 SP1, and 1.0 SP3 of the .NET Framework, including 32-bit, 64-bit x64, and 64-bit Itanium versions. The object also includes all supported language packs, as well as the Web downloader redistributables where available.

For more information, see:

New .msi Package Tools

InstallShield includes several new tools:

You can launch any of these tools from the InstallShield Tools subfolder on the Windows Start menu.

These InstallShield MSI tools are included with the Premier and Professional editions of InstallShield. The Premier edition also includes a separate installation and extra licenses that let you install just the tools, without InstallShield, on separate machines. For specific terms, see the InstallShield End-User License Agreement.

For more information, see InstallShield MSI Tools.

Ability to Compress Files that Are Streamed into Setup.exe and ISSetup.dll and to Specify the Compression Level

If you build a release that uses a Setup.exe setup launcher or a ISSetup.dll file (which contains the InstallScript engine), InstallShield now compresses files that it streams into the Setup.exe file or the ISSetup.dll file. 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. 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.

By default, InstallShield does not compress any files that have a .cab file extension when it is streaming them into the Setup.exe file at build time, since .cab files are already a compressed type of file. You can modify this default compression exclusion list to include other file types or specific files as needed. The exclusion list is a machine-wide setting.

This feature applies to Basic MSI and InstallScript MSI projects.

For more information, see Configuring the Compression Level for Files that Are Streamed into Setup.exe and ISSetup.dll.

Support for Multi-Part .cab Files

The .cab file type has some limitations. For example, the maximum size of a single .cab file is 2 GB. In addition, some users have had trouble signing large .cab files and verifying the digital signature of large signed .cab files. To work around these limitations, InstallShield now has a new default limit of 600 MB for a .cab file. When InstallShield is creating the .cab files for your release and it reaches the limit, it splits the data into two or more .cab files, creating multi-part .cab files.

You can modify the maximum 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.

This functionality applies to Basic MSI and InstallScript MSI projects. In addition, it is applicable only if you are building a compressed network image release in which all of the files are embedded in the single-file .msi package or the Setup.exe setup launcher. This functionality does not apply to custom compression, where only the files that are associated with one or more features are compressed into .cab files.

For more information, see Configuring the Maximum Size for .cab Files.

Support for Adding an Open Dialog to a Basic MSI Installation to Let End Users Browse to a File

InstallShield includes support for launching the Open dialog from one of the dialogs in your Basic MSI installation. End users click a browse button in one of your dialogs, and this launches the Open dialog. The Open dialog lets the end user browse for a file. When the end user selects the file and clicks the Open button, the Open dialog closes, and the installation writes the full path and file name in an edit field on the dialog. The installation also sets the value of the IS_BROWSE_FILEBROWSED property to the path and file name of the file that the end user selected.

To use this functionality, you must add to your project the new Windows Installer DLL custom action called FileBrowse. This custom action calls the FileBrowse.dll file. In addition, you must add an edit field control and the browse button that launches the Open dialog, and set a related dialog event. For complete instructions, see Launching a File Open Dialog.

Support for Installing IIS 7 Web Sites on Windows Server 2008

InstallShield now lets you create and manage IIS 7 Web sites, virtual directories, Web service extensions, and application pools on Windows Server 2008 systems. This functionality is available in Basic MSI, InstallScript, and InstallScript MSI projects.

Microsoft SQL Server 2005 Express SP2 Prerequisite Available

InstallShield now includes an InstallShield prerequisite for Microsoft SQL Server 2005 Express Edition SP2. You can add this InstallShield prerequisite to Basic MSI and InstallScript MSI projects.

MySQL 5.0 Support

InstallShield now lists the 5.0.x versions of MySQL in the predefined list of database servers that you can select when you are specifying in the SQL Scripts view the target database servers that your product supports. Previously, it was necessary to create a custom version requirement.

Microsoft Visual Studio 2008 Support

InstallShield is now integrated with Visual Studio 2008, enabling development of installations and products within the same Visual Studio interface.

Ability to Convert Visual Studio Setup and Merge Module Projects to InstallShield Projects

InstallShield now lets you convert a Visual Studio 2008, Visual Studio 2005, Visual Studio .NET 2003, or Visual Studio .NET setup project (.vdproj) to a Basic MSI project (.ism). In addition, InstallShield enables you to convert a Visual Studio 2008, Visual Studio 2005, Visual Studio .NET 2003, or Visual Studio .NET merge module project (.vdproj) to an InstallShield Merge Module project (.ism).

Converting these Visual Studio projects to InstallShield projects enables you to modify the layout of dialogs through a visual Dialog Editor, manage features and components, and use other functionality that is available in InstallShield.

To learn more, see Converting or Importing Visual Studio Projects into InstallShield Projects.

Arabic (Saudi Arabia) and Hebrew Language Support, and Dialog Editor Support for Right-to-Left Languages

InstallShield now includes support for Arabic (Saudi Arabia) and Hebrew languages, which are written and read from right to left. All of the default end-user dialog strings are available in these languages.

Since these languages are read from right to left, InstallShield also includes support for mirroring Arabic and Hebrew dialogs; that is, InstallShield uses a right-to-left layout for Arabic and Hebrew dialogs. Thus, for example, buttons that are on the right side of dialogs in English and other left-to-right languages are moved to the left side of right-to-left-language dialogs. In addition, InstallShield uses mirror-image versions of the dialog images that are displayed for the built-in dialog themes.

The right-to-left layouts and reversed images are used in the Dialog Editor pane in the Dialogs view of InstallShield, and also at run time.

The Arabic and Hebrew support is available in the InstallShield Premier Edition. The Premier edition now includes support for 35 different languages.

The following project types include support for this feature: Basic MSI and Merge Module.

For more information, see Dialog Support for Right-to-Left Languages.

String Entry Validation in InstallScript Files (.rul)

When you build a project that includes an InstallScript file (.rul) and the InstallScript code contains one or more references to string entries that use the string constant operator (@), InstallShield now validates the string entries at build time.

If a string identifier in the project’s InstallScript file is not defined for one of the project’s string entries, InstallShield displays build warning -7174.

This applies to the following project types: Basic MSI with InstallScript custom actions, InstallScript, InstallScript MSI, InstallScript Object, and Merge Module with InstallScript custom actions.

To learn more, see:

New FlexNet Connect 11 Redistributables Available

InstallShield includes support for FlexNet Connect 11 in Basic MSI and InstallScript MSI projects. Use the Update Notifications view in InstallShield to include one of the two FlexNet Connect 11 merge modules—one has the Common Software Manager, and the other does not.

Enhancements

InstallShield includes the following enhancements.

Best Practice Dynamic File Linking

When you add or modify a dynamic file link in your project, you can now specify which component creation method you want InstallShield to use: a new best practice method, or the previously available one-component-per-directory method.

When best practices for component creation are followed, InstallShield creates a separate component for each portable executable (PE) file in the dynamically linked folder and sets each PE file as the key file of its component. If you later want to create a patch that updates one of the dynamically linked PE files, it is easier to do so than it would be if you had used the one-component-per-directory method.

Previously, any time that you added dynamic file links to a project, InstallShield automatically created one component for all of the dynamically linked files at build time. However, if your dynamic file link included PE files, Windows Installer best practices for component creation were not followed.

By default, InstallShield considers the following file types to be PE files: .exe, .dll, .ocx, .vxd, .chm, .hlp, .tlb, and .ax. You can modify this list through the new File Extensions tab on the Options dialog box.

The automation interface includes support for this new best practice method. The ISWiDynamicFileLinking object includes a new CreateBestPracticeComponents property that lets you specify whether you want to use the best practice method, or the previously available one-component-per-directory method for a dynamic file link. When you create a new dynamic file link using the AddDynamicFileLinking method, the best practice method is used by default.

The best practice dynamic file linking applies to Basic MSI, InstallScript MSI, and Merge Module projects.

To learn more, see:

Ability to Hide Setup Prerequisites from the List of Prerequisites to Be Installed

If a target system needs one or more setup prerequisites to be installed, the setup prerequisite dialog is displayed at run time before the main installation runs. The Behavior tab in the InstallShield Prerequisite Editor has a new check box that lets you specify whether you want a setup prerequisite to be hidden from the list of prerequisites in the prerequisite dialog. If a prerequisite is hidden, it is installed when the conditions require it, even though it is not listed as one of the prerequisites that needs to be installed.

New prerequisites and existing prerequisites that were created before this functionality was available are not hidden by default. You can change this behavior by selecting the new check box on the Behavior tab.

For more information, see Specifying Whether to Include the Name of a Prerequisite in the List of Setup Prerequisites to Be Installed on the Target System.

Ability to Show the Progress of an InstallShield Prerequisite Installation at Run Time

The Behavior tab in the InstallShield Prerequisite Editor has a new check box that lets you specify whether you want the prerequisite installation to show installation progress messages from Windows Installer at run time. This augments the progress bar to reflect the current progress status of the .msi installation. This functionality is available only if the prerequisite launches an .msi file; it is not possible if the prerequisite launches a Setup.exe file. For more information, see Specifying Whether to Show the Progress of an InstallShield Prerequisite Installation at Run Time.

For new prerequisites and existing prerequisites that were created before this functionality was available, the progress is not shown by default. You can change this behavior by selecting the new check box on the Behavior tab.

Note that if you specify that you want to show the progress, only some of the available command-line parameters are supported. To learn more, see Specifying Command-Line Parameters for an InstallShield Prerequisite.

Ability to Use Windows Installer Properties in Command-Line Statements for InstallShield Prerequisites

Basic MSI and InstallScript MSI installations now can substitute and pass the following properties on setup prerequisite command lines: ProductLanguage, ISPREREQDIR, SETUPEXEDIR, and SETUPEXENAME. You can use these properties to identify the launching installation ("[SETUPEXEDIR]\[SETUPEXENAME]"), to identify full paths to files that are included in the prerequisite ("[ISPREREQDIR]myconfig.ini"), or to pass the selected language to multilingual prerequisites such as an InstallShield setup launcher (/l[ProductLanguage]). The new feature prerequisites include command-line support for any Windows Installer property, including the aforementioned properties.

You can specify the command lines on the Application to Run tab of the InstallShield Prerequisite Editor.

For more information, see Specifying Command-Line Parameters for an InstallShield Prerequisite.

New Option for Reboot Behavior of InstallShield Prerequisites

The Behavior tab of the InstallShield Prerequisite Editor is where you specify how an InstallShield prerequisite installation should proceed if it appears that the target machine needs to be restarted. The If the prerequisite appears to need a reboot list is where you specify the behavior. This list has a new option, called Note it, fail to resume if the machine is rebooted, and reboot after the installation. If it appears that a restart is required at run time but you want to postpone it until the end of the main installation (or until a subsequent prerequisite triggers a restart), select this new option.

For more information, see Behavior Tab.

Support for Single-File, Compressed InstallScript Installations of up to 4 GB

A single-file, compressed InstallScript installation can now be up to 4 GB in size. Previously, when end users ran large single-file, compressed InstallScript installations, the installations crashed during setup initialization.

Note that Setup.exe files cannot exceed 4 GB because Windows will not load an executable file that is larger than 4 GB.

Ability to Install IIS Web Sites Without Virtual Directories and to Associate Web Sites with Components

InstallShield now includes support for installing IIS Web sites without any virtual directories. In addition, the General tab that InstallShield displays when you select a Web site in the Internet Information Services view now has a Component setting; use this setting to associate the selected 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 a Web site is associated with a component, the Web site’s Delete Web Site on Uninstall check box 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.

Previously, InstallShield did not include support for associating Web sites with components. Therefore, if a Web site in an installation did not have any virtual directories, the Web site would not be created at run time.

If you add a new Web site through the Internet Information Services view in InstallShield 2009, 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.

The following project types support these IIS enhancements: Basic MSI, InstallScript, and InstallScript MSI.

Note that if a Web site is associated with a component in an InstallScript project, any virtual directories that are added to that Web site must be associated with the same component. Therefore, if you try to change the component for a Web site that contains one or more virtual directories, InstallShield displays a message box to inform you that it will also make the same component change for all of that Web site’s virtual directories; InstallShield also displays this message box if you try to change the component for any virtual directories in a Web site. In either case, the message box enables you to proceed or cancel the component change. For Basic MSI and InstallScript MSI projects, keeping a Web site in the same component as all of the Web site’s virtual directories is not required, but it is recommended.

To learn more, see:

Simplification of QuickPatch Packages

InstallShield now offers the ability to build streamlined QuickPatch packages, which typically have fewer new subfeatures and built-in InstallShield custom actions than those built in earlier releases of InstallShield. A new Streamline QuickPatch setting on the Advanced tab in QuickPatch projects lets you specify whether InstallShield should create this new simpler type of QuickPatch package.

For more information, see:

Ability to Build a Patch from the Command Line and from MSBuild

The -patch_config command-line parameter is available for command-line builds (including the Standalone Build command-line builds) with ISCmdBld.exe. Use this parameter to build a patch from the command line.

If you use an .ini file to pass parameters to the command line, you can use the new PatchConfigName parameter in the [Project] section of your .ini file to indicate the patch configuration that you want to build.

In addition, the InstallShield task for MSBuild now includes a PatchConfiguration parameter, which you can use to specify the patch configuration that you want to build through MSBuild.

To learn more, see:

Ability to Password-Protect Patches and QuickPatch Packages

InstallShield now has new password settings that let you password-protect patches and QuickPatch packages. These settings are on the Advanced tab in the Patch Design view of Basic MSI and InstallScript MSI projects, and on the Advanced tab of QuickPatch projects.

If you password-protect a patch or QuickPatch package, any end user who wants to install the package must enter a case-sensitive password to launch your update.

To learn more, see the following:

Patch and Upgrade Validation Support in QuickPatch Projects

When you build QuickPatch projects, InstallShield now runs patch and upgrade validation. This validation helps identify some common problems that may be encountered when attempting to upgrade a product with a QuickPatch package.

Previously, the patch and upgrade validation was available only for Basic MSI projects and InstallScript MSI projects, and patches that were created in the Patch Design view.

To learn more, see Validating Upgrades, Patches, and QuickPatch Packages.

Ability to Select Multiple .cub Files for Performing Validation at Build Time

The Validation tab on the Options dialog box in InstallShield now lets you specify more than one .cub file that should be used to validate your installation package or merge module when it is built from within InstallShield.

In addition, you can now pass more than one .cub file through the -m command-line parameter for command-line builds (including the Standalone Build command-line builds) with ISCmdBld.exe. If you use an .ini file to pass parameters to the command line, you can now specify more than one .cub file for the CubFile parameter in your .ini file.

The RunMsiValidator parameter of the InstallShield task for MSBuild has been enhanced to accept more than one .cub file.

For more information, see:

New Validator for the InstallShield Best Practice Suite

ISBP20 is a new validator that is available with the InstallShield Best Practice Suite. ISBP20 verifies that no registry entries contained in the Registry table attempt to remove root-level registry keys or other keys that would cause adverse issues on target machines during uninstallation.

The InstallShield Best Practice Suite is available in the Premier edition of InstallShield for Basic MSI, InstallScript MSI, and MSI Database projects.

Ability to Use the /v Command-Line Parameter More than Once to Pass More than One Parameter from Setup.exe to the .msi File

If you want to pass more than one argument from Setup.exe to Msiexec.exe, you can use the /v option multiple times at the command line, once for each argument. Previously, the /v option could be used only once, and all parameters were passed through this instance.

The following project types include support for this enhancement: Basic MSI and InstallScript MSI.

For more information, see Setup.exe and Update.exe Command-Line Parameters.

Improved Compatibility Between the Standalone Build and InstallShield

The Standalone Build that is available with InstallShield Premier Edition now uses the same directory structure that InstallShield uses for its program files. Therefore, if you need to copy a redistributable or some other file from a machine that has InstallShield to a machine that has the Standalone Build, use the same relative path. Previously, the directory structures were different and inconsistent.

In addition, 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. ISCmdBld.exe now supports parameters that previously only IsSaBld.exe supported:

Also as part of this enhancement, the Standalone Automation Interface uses the same ISWiAutomation15.dll file that InstallShield uses, but it is installed to a different location. 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 throughout the scripts in order to use them with the Standalone Automation Interface. Note that with this change, the ISWiProject object includes support for several properties that were previously available for only the Standalone Automation Interface:

An advantage of these compatibility improvements is that only one set of binaries, rather than two separate sets, is built for the Standalone Build and InstallShield; if an InstallShield hotfix or service pack is released, it can be used to update the Standalone Build and InstallShield. Previously, separate hotfixes and service packs were required.

To learn more, see:

Support for Browsing to Local, Remote, and Alias SQL Servers in the SQLBrowse Run-Time Dialog

The filter functionality of the SQLBrowse dialogs has been enhanced.

To show only remote servers in the SQL Server browse combo box and list box controls in Basic MSI and InstallScript MSI installations, you can set the new Windows Installer property IS_SQLSERVER_REMOTE_ONLY. To show only server aliases in the SQL Server browse combo box and list box controls in Basic MSI and InstallScript MSI installations, you can set the new Windows Installer property IS_SQLSERVER_ALIAS_ONLY. Previously, the only filtering that was available was showing only local servers; this is available if you set the IS_SQLSERVER_LOCAL_ONLY property. You can now set any combinations of these properties to display multiple types of servers in the SQL Server browse combo box and list box controls.

To learn more, see Overriding the Default SQL Run-Time Behavior.

Two new InstallScript functions are available for InstallScript projects:

Ability to Continue an Installation If the Minimum SQL Database Server Requirements Are Not Met

The Requirements tab that is displayed when you select a SQL connection in the SQL Scripts view has a new Allow installation to continue when minimum requirements are not met check box.

If you select this check box and the minimum database server requirements are not met on a target system, the run time skips the SQL connection and all of its SQL scripts, and continues with the installation.

If you clear this check box and the minimum requirements are not met, the installation does not allow the end user to continue with the rest of the installation. This is the default behavior.

This enhancement applies to Basic MSI, InstallScript, and InstallScript MSI projects.

For more information, see Requirements Tab.

SQL Server Alias Support

The SQL run-time support has been enhanced: installations can now list SQL Server alias names in the SQLBrowse dialog. In addition, the SQLLogin dialogs let end users use an alias name to connect to a SQL Server.

This enhancement applies to Basic MSI, InstallScript, and InstallScript MSI projects.

To learn more, see Adding a New SQL Connection.

Predefined System Searches for the .NET Framework

InstallShield has several new predefined system searches:

If your installation requires any of these, you can use the System Search view or the Installation Requirements page in the Project Assistant to add these system searches to your project. When end users launch your installation, Windows Installer checks the target system to see if the requirements are met; if they are not met, the installation displays the error message that is defined for the system search.

This enhancement applies to Basic MSI and InstallScript MSI projects.

Expanded Support for the Error Type of Custom Action

The Custom Action Wizard now includes support for a type 19 custom action, which displays a specified error message, returns failure, and ends the installation. Previously, the only way to create this type of custom action was to right-click the Custom Actions explorer in the Custom Actions and Sequences view and then click Error, or to use the Direct Editor to manually enter the custom action’s table entry.

The following project types now support the error custom action: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform. Previously, only Basic MSI and InstallScript MSI projects included support.

Ability to Specify Whether to Digitally Sign Source Files

The Signing tab in the Releases view has a new Sign files in their original location check box. This check box lets you specify whether you want InstallShield to sign your original source files or just the files that are built into the release. This check box is also available on the Digital Signature Options panel in the Release Wizard. The check box is cleared by default.

The benefit of selecting this check box for a Basic MSI or InstallScript MSI project is that it helps create one patch that updates both compressed and uncompressed versions of a release that contains originally unsigned files.

Previously, the check box was not available, and InstallShield never enabled you to sign the files in their original location.

The automation interface now includes support for this new digital signing functionality. The ISWiRelease object includes a new SignFilesInPlace property that lets you specify whether you want InstallShield to sign your original source files or just the files that are built into the release.

To learn more, see:

Improved Static COM Extraction

If you use static COM extraction, InstallShield now uses an MD5 algorithm when generating primary keys for the Registry table. Therefore, if the COM data does not change, the primary keys do not change between different versions of a package and when the extracted COM data is refreshed.

Previously, InstallShield used random values for the primary keys that it created during static COM extraction. As a result, if the COM data were refreshed or a patch were built, it was possible for new primary keys to be created, even if the COM data had not changed. In the patch scenario, the COM data would be included in the patch if the primary keys changed. If a patch updated a component with unchanged COM data, the COM data could be removed during patch uninstallation, and this could cause issues in the earlier version of the product.

This enhancement applies to Basic MSI and InstallScript MSI projects.

InstallScript Language Enhancements and New Functionality

Some enhancements have been made to the InstallScript language.

Enhancements for .NET Framework 3.5 and .NET Framework 3.0 SP1 Support

A new FOLDER_DOTNET_35 InstallScript variable is available. This variable stores the path of the .NET Framework 3.0 files.

Two new constants are available for use with the function Is:

You can use the REGDB_KEYPATH_DOTNET_30_SP variable when querying whether SP1—or a later service pack—of the .NET Framework 3.0 is installed. To detect whether the RTM version of the .NET Framework 3.0 is installed, use REGDB_KEYPATH_DOTNET_30.

New GetTempFileNameIS Function that Calls the Windows API GetTempFileName to Create a Temporary File

A new InstallScript function called GetTempFileNameIS is available. This function calls the Windows API GetTempFileName to create a temporary file and perform related actions.

To learn more, see GetTempFileName.

See Also

What’s New in InstallShield 2009 SP1

Upgrading Projects from InstallShield 2008 or Earlier

Upgrading Projects from InstallShield 12 or Earlier

Upgrading Projects from InstallShield 11.5 or Earlier

Open topic with navigation