What’s New in InstallShield 2011
InstallShield 2024
New Features
InstallShield includes the following new features.
Unicode Support in InstallScript
InstallShield now lets you create InstallScript installations and InstallScript custom actions that support the use of Unicode in run-time strings, files, paths, registry entries, and other installation data. In addition, the InstallScript compiler and the InstallScript engine now let you pass pointers to Unicode strings to functions that are implemented outside script code; they also let you store Unicode strings in structures that are passed outside script code. Other changes in InstallScript offer additional benefits for fully supporting modern multilanguage installations.
As a result of these changes, any language displays correctly on a system that has support for it installed. End users no longer need to match the language that is used on their systems for non-Unicode programs with the language that is used in the installation. Note that the font must be installed on the target system. On some versions of Windows, the fonts for some languages are not installed by default. For example, Japanese fonts are not installed on a Windows XP English system by default; in order for an installation to use Japanese characters on such a system, the fonts would need to be installed.
Unicode Setup Launchers for InstallScript and InstallScript MSI Projects
Now all Setup.exe and Update.exe files that are built in InstallShield are Unicode. Previously, all Setup.exe and Update.exe files that were built in InstallScript and InstallScript MSI projects were ANSI.
A Unicode setup launcher can correctly display characters in the user interface of the setup launcher, regardless of whether the target system is running the appropriate code page for the language. ANSI setup launchers correctly displayed characters in the setup launcher dialogs if the target system was running the appropriate code page. However, it may have displayed garbled characters in those dialogs if the target system was not running the appropriate code page.
End users can launch Setup.exe and Update.exe files from within Unicode paths, regardless of the language on the target system. For example, end users can now launch the installation in the following path on an English system: C:\Users\Japanese characters\Desktop\Setup.exe. Previously, the installation would fail.
Unicode Support for Files, Folders, Registry Entries, and Support Files
Unicode support has been added to key parts of the installation run time, enabling you to use characters from any languages simultaneously in file names, folder names, registry entries, and support file names. This enables you to install, for example, a file that has Japanese characters in its name or target path on an English system. Mixing languages works correctly regardless of the current language of the target system.
Pointer Support
The InstallScript engine and compiler now support a new pointer type called WPOINTER; wpointer and LPWSTR are equivalent names that are also available. Thus, for example, if you have a DLL function that accepts pointers to Unicode strings in its parameters, you can use this new pointer type; when the DLL function is called in the script at run time, the InstallScript engine passes a pointer to a Unicode copy of the strings instead of an ANSI version. Previously, it was possible to pass a pointer to only an ANSI copy of the strings.
Note that passing Unicode strings with the WSTRING data type that was introduced in an earlier version of InstallShield is still supported.
For more information, see:
| • | Pointers |
| • | Data Types and Predefined Structures |
Structure Support
Structures in InstallScript can contain any basic data type, including strings and pointers, or other structures. Now if a structure needs to contain a Unicode string and the structure is passed to an external DLL, the InstallScript engine can distinguish between string member types in that structure, and then size the structure and calculate member offsets correctly. String members that need to be stored and passed as Unicode can be declared with the WSTRING type.
Previously, if a structure needed to contain a Unicode string and the structure was passed to an external DLL, the InstallScript engine assumed that any strings in the structure were ANSI. As a result, the size of the structure and member offsets in the structure could have been wrong, causing the DLL to incorrectly read or write data related to the structure. Attempting to use WSTRING for string members of a structure did not have any effect.
You can leave existing strings as STRING types; the InstallScript engine will continue to treat these as ANSI strings when passing them outside of script code.
Pointer members in structures can also now be declared as WPOINTER. This enables you to store pointers to Unicode strings in a structure.
For more information, see:
| • | Data Structures |
| • | Data Types and Predefined Structures |
String Table Support
InstallShield now uses Unicode encoding to build the string tables for InstallScript projects. Because of this support, string tables for InstallScript projects can now contain multiple languages, and they are not affected by a target system’s code page settings. In addition, string tables can now include strings for languages—such as Hindi—that have no code page.
It is recommended that any strings that will be displayed in the user interface of an installation be stored in the string table. Although strings can be written directly in InstallScript code, they are not stored as Unicode; thus, they are displayed correctly only when the installation is run on systems that have the correct code page. Storing strings in the string table and referencing them from InstallScript code eliminates this issue.
For more information, see:
| • | Using String Entries in InstallShield |
| • | String Constant Operator (@) |
Unicode InstallScript Dialogs
InstallScript dialogs now include support for Unicode. This enables you to mix, for example, Japanese and German, or Russian and Polish, on InstallScript dialogs. These mixed languages work correctly regardless of the current language of the target system.
This feature is available in the following project types: InstallScript and InstallScript MSI.
Unicode Support in the InstallScript Debugger
The InstallScript Debugger now has support for Unicode. Thus, for example, if you are debugging a line of InstallScript code such as szMsg = @ID_MSG, you can now see the value in szMsg, regardless of what language operating system you are using and what language is used for the strings. If the value of ID_MSG contains Chinese characters or characters from mixed languages, you can now see the appropriate characters instead of question marks in various areas of the InstallScript Debugger: in the variable window, in the watch window, and in the tooltip that appears for the variable in the script window.
For information on the InstallScript Debugger, see Debugging InstallScript-Based Installations in the InstallScript Debugger User Guide.
Unicode Support in InstallShield Cabinet and Log File Viewer
The InstallShield Cabinet File Viewer and the InstallShield Log File Viewer have been combined into one new tool—the InstallShield Cabinet and Log File Viewer—which lets you open and review InstallScript cabinet files (.cab), InstallScript header files (.hdr), and InstallScript log files (.ilg). This tool now includes Unicode support. Thus, the tool can correctly display the characters in each file name, registry key, shortcut, and other data in the .cab, .hdr, or .ilg file, regardless of what language operating system you are using and what language is used for the strings. Previously, in some cases, some of the characters were displayed as question marks.
The cabinet and header file support applies to the following project types: InstallScript and InstallScript Object.
The log file support applies to the following project types: InstallScript and InstallScript MSI.
To learn about this tool, see:
| • | InstallShield Cabinet and Log File Viewer |
| • | Viewing InstallScript Cabinet Files (.cab) and Header Files (.hdr) |
| • | Viewing InstallScript Log Files (.ilg) |
Integration with Team Foundation Server (TFS)
InstallShield has enhanced support for integrating with Team Foundation Server (TFS) 2010.
Now when you are using InstallShield from within Visual Studio 2010, you can access the Source Control Explorer to integrate your InstallShield project with Team Foundation version control and manage changes to your InstallShield projects and your Visual Studio solutions.
You can also use Team Foundation Build to compile, test, and deploy your InstallShield projects and your Visual Studio solutions on a regular basis, or on demand. Your installation is automatically updated with your latest source files every time that your solution is built.
In addition, if you install Team Explorer on the same machine that has InstallShield and Visual Studio, you can use Team Explorer from within your InstallShield projects that are open in Visual Studio. This enables you to perform tasks such as the following:
| • | Use Source Control Explorer when you are working on your InstallShield projects. |
| • | Configure builds for your InstallShield projects and Visual Studio solutions. |
| • | Queue new builds. |
| • | Track work items such as bugs and tasks for your InstallShield projects and your Visual Studio solutions. |
For more information, see:
| • | Integrating with Microsoft Visual Studio Team Foundation Server |
| • | Adding InstallShield Projects to Team Explorer |
Microsoft SQL Server 2008 R2 Support
InstallShield now includes support for running SQL script on SQL Server 2008 R2. In addition, InstallShield includes SQL Server 2008 R2 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.
This feature is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
New InstallShield Prerequisites for SQL Server 2008 R2 Express, SQL Server Native Client, Visual C++ 2010, and Other Redistributables
InstallShield includes a number of new InstallShield prerequisites that you can add to Basic MSI, InstallScript, and InstallScript MSI projects:
| • | Microsoft SQL Server 2008 R2 Express |
| • | Microsoft SQL Server 2008 Native Client 10.00.2531 |
| • | Microsoft SQL Server Native Client 9.00.4035 |
| • | Microsoft SQL Server System CLR Types 10.00.2531 |
| • | Microsoft SQL Server 2008 Management Objects 10.00.2531 |
| • | Microsoft Visual C++ 2010 Redistributable Package |
| • | Microsoft Visual C++ 2008 SP1 Redistributable Package |
| • | Microsoft Visual C++ 2005 SP1 Redistributable Package (x64) |
| • | Windows Installer 3.1 - Japanese |
| • | MSXML 6.0 SP1 - Japanese |
| • | Microsoft .NET Framework 4.0 Client Japanese Language Pack |
| • | Microsoft .NET Framework 4.0 Full Japanese Language Pack |
Improved Script Editors for Creating and Modifying InstallScript Code, SQL Scripts, VBScript Custom Actions, and JScript Custom Actions
Several views in InstallShield have an improved script editor that you can use to write code for your projects. The script editors include the following improvements:
| • | Expanded auto completion—When you are typing in a script editor, InstallShield displays a pop-up list of alphabetically ordered functions, keywords, and constants that begin with the letters that you are typing. Instead of manually typing the entire word, you can select it in the pop-up list, and InstallShield adds it to your script. |
If you are using the script editor in the InstallScript view, you can enter the string constant operator (@) to see a pop-up list of the available string identifiers. You can select the appropriate one in the list, and InstallShield adds it to your script.
If auto completion for local variables is also enabled, the pop-up list in the script editor of the InstallScript view also contains local variables.
Auto completion can increase your efficiency because it can reduce the time that you spend typing code. It can also help you avoid typographical errors in your code.
The script editor in the InstallScript view of earlier versions of InstallShield is the only script editor that provided some auto completion support; thus, auto completion functionality was not available for SQL scripts, VBScript code, or JScript code. In addition, the available pop-up list was limited to InstallScript functions; none of the keywords, constants, local variables, or string identifiers were available for auto completion.
| • | Detailed InstallScript Function Call Tips—If function call tips are enabled, InstallShield shows InstallScript function call tips—a type of tooltip—when you are entering function calls in your script in the InstallScript view. A function call tip shows a built-in function’s parameter information. It also shows a description of the built-in function, as well as a description of the parameter that you are entering. The detailed call tips enable you to see help information about a function without switching from the script editor to the help library, and then back to the script editor. |
The InstallScript view in earlier versions of InstallShield included support for call tips, but the call tips did not display as much information. The call tips showed a function call with all of the function’s parameters; however, the call tips did not include a description of the function, or of the parameter that you are entering.
| • | Syntax folding—InstallShield now lets you specify whether you want the script editors in various views in InstallShield to include support for syntax folding. When syntax folding is enabled, InstallShield adds a plus sign (+) or a minus sign (–) in the margin next to each line of code that starts an expandable or collapsible block of script. You can click a plus sign to expand hidden code, or a minus sign to hide visible code. |
Syntax folding can help you minimize the clutter of large scripts and focus on the code that is relevant to the work that you are currently doing. It can also help you see the overall structure of a script.
The views that contain the improved script editor are the InstallScript view, the SQL Scripts view, and the Custom Actions and Sequences view (when you are viewing a VBScript or JScript file in this view).
By default, syntax folding is disabled in the script editors; auto completion, local variable auto completion, and function call tips are enabled. To enable or disable any of the aforementioned functionality, use the Script Editor Properties dialog box. This dialog box also lets you modify other settings in the script editors, such as font, syntax colors, and line numbering. To access this dialog box, right-click in a script editor and then click Properties.
For more information, see the following:
| • | Working with the Script Editor Pane in Various Views |
| • | Using Auto Completion when Writing Code in the Script Editors |
| • | Viewing Function Call Tips for an InstallScript Function in the Script Editor |
| • | Changing Colors for Syntax Highlighting in the Script Editors |
| • | Enabling or Disabling Syntax Folding in the Script Editors |
| • | Keyboard Shortcuts for the Script Editors |
| • | Script Editor Properties Dialog Box |
Ability to Create 64-Bit Microsoft App-V Packages
The Microsoft App-V Assistant in InstallShield includes support for converting a 64-bit Windows Installer package into a 64-bit Microsoft App-V package, which can be deployed on 64-bit Windows systems with the 64-bit Microsoft App-V 4.6 client. This, in combination with the new 64-bit repackaging support that is available with the Repackager, enables you to convert any 64-bit installation into a 64-bit App-V package.
It is recommended that you perform the conversion of 64-bit Windows Installer packages to App-V packages on a 64-bit Windows system. If you attempt the conversion on a 32-bit system, it could result in a failure to extract COM information for 64-bit binaries. Also, in some cases, Windows Installer packages contain shortcuts that target executable files that are not found in the package itself. If these shortcuts target executable files are found in 64-bit locations, these shortcuts are not handled correctly on 32-bit systems.
The Microsoft App-V Assistant is available if you purchase the Premier Edition of InstallShield.
Ability to Specify a Search Path for InstallShield Prerequisites; Path Variable and Relative Path Support for Source Locations of Prerequisite Files
InstallShield now lets you specify the folders where InstallShield should search for InstallShield prerequisite files (.prq files). This functionality makes it easier for teams of users to share InstallShield prerequisites with each other, and for storing prerequisites in source code control. Previously, InstallShield searched for .prq files in the following location only: InstallShield Program Files Folder\SetupPrerequisites.
InstallShield offers several ways for specifying the folders:
| • | If you are editing or building from within InstallShield, use the new Prerequisites tab on the Options dialog box—which is displayed when you click Options on the Tools menu—to specify a comma-delimited list of machine-wide folders and current-user folders. This tab is similar to the Merge Modules tab on the Options dialog box, which lets you specify search paths for merge modules. |
| • | If you are building from the command line with ISCmdBld.exe, use the new -prqpath parameter to specify a comma-delimited list of folders. |
If you use an .ini file to specify ISCmdBld.exe parameters, you can use the new PrerequisitePath parameter in the [Mode] section of your .ini file to specify a comma-delimited list of folders.
| • | If you are building through MSBuild or Team Foundation Server (TFS), use the new PrerequisitePath parameter on the InstallShield task. This parameter is exposed as the ItemGroup InstallShieldPrerequisitePath when the default targets file is used. To specify multiple paths, use an ordered array of paths. |
When you are using the Files to Include tab in the InstallShield Prerequisite Editor to add files to an InstallShield prerequisite, the editor now uses predefined path variables such as <WindowsFolder> and <ISProductFolder> if appropriate. In addition, if the files that you are adding are stored in the same folder as the InstallShield prerequisite’s .prq file—or a subfolder of the folder that contains the .prq file—the InstallShield Prerequisite Editor uses a relative path for the file in the .prq file. Note that if you view the file’s path on the Files to Include tab, the InstallShield Prerequisite Editor lists the full path, not the relative path.
Note that if you use the Save As command in the InstallShield Prerequisite Editor to change the location of a .prq file, the InstallShield Prerequisite Editor updates the paths of the prerequisite’s files if appropriate.
To learn more, see:
| • | Specifying the Directories that Contain InstallShield Prerequisites |
| • | Prerequisites Tab |
| • | ISCmdBld.exe |
| • | Passing Command-Line Build Parameters in an .ini File |
| • | Microsoft Build Engine (MSBuild) |
New Hyperlink Control for Windows Installer–Based Dialogs
The Controls toolbar includes a new hyperlink control that you can use in the Dialogs view for Windows Installer–based dialogs. The hyperlink control displays an HTML link; clicking the link at run time opens a page in the default browser on the target system.
Windows Installer 5 includes support for this new hyperlink control. If this control is used on a dialog that is displayed on a system that has an earlier version of Windows Installer, run-time error 2885 occurs, and the installation aborts. Therefore, if you want to use the hyperlink control on a dialog but your installation targets systems that have Windows Installer 4.5 or earlier, it is recommended that you include two versions of the dialog in your project: one with the hyperlink control, and one without it. Add conditions to the dialogs to show or hide them, depending on the version of Windows Installer that is present.
This feature is available in the following project types: Basic MSI and Merge Module.
To learn more, see Hyperlink Control.
Ability to Specify a Custom Icon and Custom Version Resource Properties for Setup.exe and Update.exe
InstallShield now lets you use a custom icon and custom version resource properties for Setup.exe files that you create at build time. The icon and the version resource properties are displayed on the Properties dialog box for Setup.exe; this Properties dialog box opens when end users right-click the Setup.exe file and then click Properties. End users can also see the icon when they view your Setup.exe file in Windows Explorer. This support is available in Basic MSI, InstallScript, and InstallScript MSI projects.
The same functionality (the ability to specify a custom icon and custom version resource properties) is also now available for Update.exe files that you create in Basic MSI, InstallScript MSI, and QuickPatch projects.
Custom Icon for Setup.exe and Update.exe
The Setup.exe tab in the Releases view has a Setup.exe Icon File setting that lets you specify the icon that should be used for your Setup.exe setup launcher. The icon can be in an .exe, .dll, or .ico file. If you do not specify an icon, InstallShield uses a default icon for your Setup.exe file.
Previously, support for specifying a custom Setup.exe icon was available for InstallScript projects if the Setup.exe file that you were building was a self-extracting, single-file setup launcher. The support was not available in Basic MSI or InstallScript MSI projects. In addition, it was not available for uncompressed InstallScript installations.
A new Icon setting lets you specify the icon that should be used for your Update.exe launcher. This setting is available on the Advanced tab for a patch configuration in the Patch Design view of Basic MSI and InstallScript MSI projects. It is also available on the Advanced tab of the Build Settings area in the General Information view of QuickPatch projects. If you do not specify an icon, InstallShield uses a default icon for your Update.exe file.
Previously, InstallShield did not include any support for specifying a custom icon for Update.exe files.
Custom Version Resource Properties for Setup.exe and Update.exe
When InstallShield is configuring the following version resources of your Setup.exe setup launcher at build time, it now uses the custom information that you entered in the General Information view and the Releases view:
| • | Company name |
| • | Product name |
| • | Product version |
| • | Copyright |
| • | File version |
| • | File description |
To use a custom copyright notice and a custom file description, ensure that you select Yes in the Use Custom Version Properties setting for the release in the Releases view.
Previously, InstallShield did not use any custom information in many cases. For example, the InstallScript Setup.exe files that InstallShield previously created contained details that pertained to the version of InstallShield that was used to build the Setup.exe file. Thus, the product name that was displayed in the Setup.exe Properties dialog box was InstallShield, rather than the name of your product.
Several new settings—Company Name, Product Name, Product Version, Description, and Copyright—let you specify the custom information that you want InstallShield to use when you build an Update.exe file. These settings are available on the Advanced tab for a patch configuration in the Patch Design view of Basic MSI and InstallScript MSI projects.They are also available on the Advanced tab of the Build Settings area in the General Information view of QuickPatch projects.
Previously, InstallShield did not use any custom version resource information for Update.exe files.
To learn more, see:
| • | Specifying the Icon for the Setup Launcher |
| • | Customizing File Properties for the Setup Launcher |
| • | Setup.exe Tab for a Release |
| • | Specifying the Icon for the Update Launcher |
| • | Customizing File Properties for the Update Launcher |
| • | Advanced Tab (in the Patch Design view) |
| • | Advanced Tab (for a QuickPatch project) |
Ability to Specify Commands that Run Before, During, and After Builds
The Premier edition of InstallShield includes new release settings that you can use to specify commands that you want to be run at various stages of the build process. These new settings are available on a new Events tab when you select a release in the Releases view:
| • | Prebuild Event—Use this setting to specify the command that you want to be run before InstallShield starts building the release. This event runs after InstallShield creates the release folder and log file, but before InstallShield starts building the release. |
This setting is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Merge Module.
| • | Precompression Event—Use this setting to specify the command that you want to be run after InstallShield has built the .msi package and the .cab files (if your product’s data files are to be stored in .cab files). Note that this event occurs after .cab files are streamed into the .msi package, but before the .msi package has been digitally signed and streamed into the Setup.exe file. |
This setting is available in the following project types: Basic MSI and InstallScript MSI.
| • | Postbuild Event—Use this setting to specify the command that you want to be run after InstallShield has built and signed the release. |
This setting is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Merge Module.
The new Events tab replaces the previously available Postbuild tab. Note that the settings that were previously available on the Postbuild tab are now displayed on the new Events tab. In addition, the publish-related settings that were previously available on the Build tab in Merge Module projects have been moved to the Events tab.
The automation interface now includes support for the new build event settings. The ISWiRelease object includes three new properties that let you specify commands for various stages of the build process:
| • | PrebuildEvent |
| • | PrecompressionEvent |
| • | PostbuildEvent |
To learn more, see:
| • | Specifying Commands that Run Before, During, and After Builds |
| • | Events Tab for a Release |
| • | ISWiRelease Object |
Ability to Set an Expiration Date for Setup.exe
InstallShield now lets you set an expiration date, as well as an expiration message, for Setup.exe. If end users try to run Setup.exe on or after the date that you have specified in your project, the expiration message is displayed, and the installation exits.
To set an expiration date and a message for your Setup.exe file, use the new Expiration Date and Expiration Message settings on the Setup.exe tab for a selected release in the Releases view. By default, no expiration date is configured for Setup.exe. If you specify an expiration date, you can use the default expiration message, or specify your own custom message.
The automation interface now includes support for these new settings. The ISWiRelease object includes two new properties that let you set the expiration date and message: ExpirationDate and ExpirationMessage.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
For more information, see:
| • | Setup.exe Tab for a Release |
| • | ISWiRelease Object |
Ability to Import Visual Studio Setup and Merge Module Projects into Existing InstallShield Projects; Improvements for the Project Converter
InstallShield now lets you import a Visual Studio setup project (.vdproj) into an InstallShield Basic MSI or Merge Module project (.ism), or import a Visual Studio merge module project (.vdproj) into an InstallShield Basic MSI or Merge Module project (.ism). These tasks enable you to develop InstallShield installation and merge module projects that contain the same data and settings that were in your Visual Studio project. The wizard imports the project outputs, files, registry keys, file extensions, custom actions, target system searches, and launch conditions from your Visual Studio project into your existing InstallShield project.
To import a Visual Studio project into an existing InstallShield project, use the new Visual Studio Deployment Project Import Wizard in InstallShield. The wizard lets you choose whether to import or ignore certain settings in the Visual Studio project.
The existing support for converting a Visual Studio project into a new InstallShield project has been expanded. If your Visual Studio project contains predefined prerequisites, InstallShield now converts them to equivalent InstallShield prerequisites during the conversion process. This same prerequisite conversion functionality is available if you use the new wizard to import a Visual Studio project into an InstallShield project.
If your Visual Studio project contains one or more project outputs, use the import wizard instead of the conversion process. The InstallShield project must be in the same Visual Studio solution that contains the Visual Studio setup or merge module project and all of its project dependencies. Note that you must be using InstallShield from within Visual Studio when you use the import wizard in order for the wizard to import the project outputs into your InstallShield project.
To learn more, see the following:
| • | Converting or Importing Visual Studio Projects into InstallShield Projects |
| • | Visual Studio Deployment Project Import Wizard |
Unicode and UTF-8 Support for SQL Scripts
InstallShield now has design-time and run-time support for SQL scripts that have either Unicode BOM encoding or UTF-8 BOM encoding. You can use the SQL Scripts view to add SQL scripts with either of these encoding types to your project. You can also edit those SQL scripts from within that view as necessary. At run time, the SQL scripts are executed during installation and uninstallation when needed.
Previously, InstallShield had run-time support but not design-time support for SQL scripts with Unicode BOM encoding. Thus, when you added a script with this encoding to the SQL Scripts view of your project, InstallShield prompted you to specify whether you wanted to convert the script to ANSI format. If you allowed InstallShield to convert it to ANSI, you could edit it from within the SQL Scripts view. However, in some cases, it might have displayed and used garbled characters at design time and at run time. If you did not allow InstallShield to convert it to ANSI, the file remained with Unicode BOM encoding. Although this encoding allowed your installation to properly use strings in languages that did not match the code page of the target system at run time, you could not view or edit the script from within InstallShield.
In addition, InstallShield previously did not have adequate support for SQL scripts with UTF-8 BOM encoding. If you added a SQL script with this encoding type to your project and the script contained strings in a language that did not match the code page of the development system, the SQL Scripts view treated the file as an ANSI file, and it may have displayed garbled characters. In addition, garbled characters were used when your SQL script was executed at run time. Also, the byte order mark was represented as garbled characters.
If you create a new SQL script from within the SQL Scripts view, InstallShield uses Unicode BOM encoding for the file. If you prefer to use ANSI or UTF-8 BOM encoding for the SQL scripts view, it is recommended that you create an .sql file with the proper encoding in a different tool, and then import or insert the script in the SQL Scripts view of your project.
This feature is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Predefined System Searches for SQL Server 2008 Express SP1 and Adobe Reader 9
InstallShield has new predefined system searches:
| • | SQL Server 2008 Express SP1 |
| • | Adobe Reader 9 |
If your installation requires one or both 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 feature applies to Basic MSI and InstallScript MSI projects.
Support for 64-Bit Managed-Code Custom Actions
InstallShield now has support for 64-bit managed-code custom actions. When you build a release that includes a managed-code custom action in your project, InstallShield attempts to determine the target architecture (32 bit or 64 bit) of the main .NET assembly that is associated with the custom action. InstallShield configures the release so that the appropriate version of the .NET Framework—32 bit or 64 bit—is used to run your managed code at run time.
If you want to override the new default behavior, use the Direct Editor view to add a new record with the following fields to the ISClrWrap table.
| • | Action_—Indicate the name of the managed-code custom action that you want to modify. |
| • | Name—Enter the following: TargetPlatform |
| • | Value—Specify the appropriate architecture. To use a 32-bit version of the .NET Framework, enter the following: x86 |
To use a 64-bit version of the .NET Framework, enter the following: x64
This feature is available in the following project types: Basic MSI, InstallScript MSI, and Merge Module.
To learn more, see Using 32-Bit vs. 64-Bit Managed-Code Custom Actions.
Support for 64-Bit .NET Installer Classes and COM Interop
InstallShield now has support for 64-bit .NET installer classes and COM interop. If you are using InstallShield on a 64-bit system, the .NET tab on the Options dialog box—which is displayed when you click Options on the Tools menu in InstallShield—now lets you specify different paths for the 32-bit and 64-bit locations of the Regasm.exe and InstallUtilLib.dll files that are included with the .NET Framework. InstallShield uses the paths that you specify at build time for releases that include .NET installer classes and COM interop.
If you are building from the command line with ISCmdBld.exe and you use the existing -t parameter to specify the path of the 32-bit version of the .NET Framework, ISCmdBld.exe now uses the 64-bit location of Regasm.exe and InstallUtilLib.dll when appropriate.
If you are building through MSBuild or Team Foundation Server (TFS) and you use the existing DotNetUtilPath parameter on the InstallShield task to specify the path of the 32-bit version of the .NET Framework, the build now uses the 64-bit location of Regasm.exe and InstallUtilLib.dll when appropriate.
To learn more, see:
| • | .NET Tab (on the Options dialog box) |
| • | ISCmdBld.exe |
| • | Microsoft Build Engine (MSBuild) |
Support for Using the InstallScript Function DotNetCoCreateObject or Managed-Code Custom Actions with DLLs that Target .NET Framework 4
If you create a DLL in Visual Studio 2010 and the DLL uses .NET Framework 4, you can now use the InstallScript function DotNetCoCreateObject to call functions in this DLL. Previously, the installation crashed if the DLL used version 4 of the .NET Framework, but not with earlier versions. This feature is available in the following project types: InstallScript and InstallScript MSI; it is also available in Basic MSI and Merge Module projects with InstallScript custom actions.
In addition, you can now use the same sort of DLL file in a managed-code custom action. Previously, the installation crashed if it contained a managed-code custom action for a DLL that used version 4 of the .NET Framework. This feature is available in the following project types: Basic MSI, InstallScript MSI, Merge Module.
For more information, see:
| • | DotNetCoCreateObject |
| • | Using 32-Bit vs. 64-Bit Managed-Code Custom Actions |
Ability to Override the Values of Path Variables for a Release
InstallShield now lets you override the values of your project’s custom path variables (standard path variables, environment path variables, and registry path variables) for each release in your project. This functionality enables you to essentially replace certain files and folders in your project with others at build time, depending on the particular release that you are building.
For example, you might use this functionality to swap out the binaries for custom actions. If you have set up separate releases for 32-bit and 64-bit target systems, you can override the path variable that is used to refer to the DLL that is selected for a custom action. Then InstallShield could include a 32-bit DLL for your 32-bit release and a 64-bit DLL for your 64-bit release. Note that overriding path variables to swap out files that your installation is installing is not recommended. This is because you should use separate components for 32-bit and 64-bit versions of a file.
To override one or more path variables in your project, use the new Path Variables Overrides setting, which is on the Build tab for a release in the Releases view. Note that if you override a path variable both in the new Path Variables Overrides setting, and with the -l parameter to IsCmdBld.exe or through MSBuild, the command line or MSBuild value takes precedence over the value that is set in the release setting.
The automation interface now includes support for this new setting. The ISWiRelease object includes a new PathVariableOverrides property that lets you override the values of your project’s user-defined path variables, environment variables, and registry variables for a release.
This feature is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, and Merge Module.
To learn more, see the following:
| • | Overriding the Value of a Custom Path Variable for a Release |
| • | Path Variable Overrides setting |
| • | Path Variable Overrides Dialog Box |
| • | ISWiRelease Object |
Ability to Configure MIME Types for IIS Web Sites, Applications, and Virtual Directories
The Internet Information Services view has a new MIME Types setting that you can configure for a Web site, application, or virtual directory in your project. This setting lets you identify the types of content that can be served from the Web server on the target system to a browser or mail client.
This feature applies to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
For more information, see:
| • | MIME Types setting for a Web site |
| • | MIME Types setting for an application or virtual directory |
Ability to Overwrite Existing IIS Application Pool or Only Create It If It Does Not Exist
The Internet Information Services view has a new Overwrite Existing Application Pool setting. This setting is displayed in the right pane when you select an application pool in the Internet Information Services view. This setting lets you specify the behavior that you want to occur if the selected application pool already exists on the target system at run time: the installation can either overwrite the application pool's settings on the target system, or leave the application pool as is. The default value for this setting is Yes, indicating the an existing application pool is overwritten at run time.
This feature applies to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
For more information, see the description of the Overwrite Existing Application Pool setting for an application pool.
New Billboard Style in InstallScript and InstallScript MSI Projects
InstallScript and InstallScript MSI projects include support for a new style of billboard that is displayed above the progress bar on the progress dialog. This style of billboard supports Adobe Flash application files (.swf), as well as image files (.bmp, .gif, .jpg, and .jpeg).
If a project contains both Flash files and image files but a target system does not have the Adobe Flash Player, the installation can detect that and display image billboards in place of the Flash billboard.
Previously, the only available billboard support in InstallScript and InstallScript MSI projects required the use of a background window. The new billboard style does not require a background window.
To add the new style of billboard to a project, use the Support Files/Billboards view to add billboard files to your project. To display this new style of billboard at run time, use the new STATUSBBRD constant with the Enable function.
Note that the new style of billboard is not available in projects that use skinned dialogs.
To learn more, see:
| • | Displaying Billboards in InstallScript and InstallScript MSI Installations |
| • | Billboard Styles and File Types for InstallScript and InstallScript MSI Projects |
| • | Adding or Modifying the Code in an InstallScript or InstallScript MSI Project to Display Billboards |
| • | Adding an Adobe Flash Application File Billboard to an InstallScript or InstallScript MSI Project |
| • | Adding an Image Billboard to an InstallScript or InstallScript MSI Project |
| • | Naming Billboard Files in an InstallScript or InstallScript MSI Project |
Support for Looping Through Image Billboards in Basic MSI Projects
The Billboards view in Basic MSI projects has a new Loop Billboards setting that lets you specify whether you want your installation to continuously loop the image billboards until the file transfer completes and the installation displays the appropriate SetupComplete dialog.
If you select Yes for this setting and the file transfer takes more time than you have allocated for the billboards, the installation restarts the display of billboards from the beginning. The loop continues, if necessary, until the file transfer ends. The default value for this setting is No, which matches the behavior in earlier versions of InstallShield.
Previously, if the file transfer took more time than what you had allocated for the billboards, the installation continued to display the last billboard until the file transfer finished; it did not loop the billboards.
For more information, see:
| • | Run-Time Behavior of a Basic MSI Installation that Includes Billboards |
| • | Billboard Settings |
Windows Installer 5 Support for Configuring Windows Service Permissions
InstallShield now includes support for configuring permissions for Windows services; this support uses the MsiLockPermissionsEx table that was introduced with Windows Installer 5. Windows Installer 5 supports the new service permission settings; earlier versions of Windows Installer ignore them.
To configure the new permission settings for a service, use the Services node in the Advanced Settings area for a component in the Setup Design view (in installation projects) or the Components view. The Services node is where you add new services to your project. When you select a subnode under the Services node, you can configure the settings—including the new permission-related settings—of that service in the right pane.
This functionality is available in the following project types: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.
For more information, see:
| • | Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment |
| • | Services Settings |
Automation Interface Support for Configuring Dynamic File Links in InstallScript Projects
The ISWiDynamicFileLinking object and the ISWiDynamicFileLinkings collection of the automation interface now include support for dynamic file links in InstallScript projects. In addition, two methods and a property of the ISWiComponent object are now applicable to InstallScript projects: the AddDynamicFileLinking method lets you add a new dynamic file link to a component, the RemoveDynamicFileLinking method lets you remove a component’s dynamic file links, and the ISWiDynamicFileLinkings property lets you get a component’s collection of dynamic file links. The read-only DynamicFile property for the ISWiFile object is also now applicable to InstallScript projects: use this property to determine whether the file’s source is linked to the component dynamically or statically.
For more details, see:
| • | ISWiDynamicFileLinking Object |
| • | ISWiDynamicFileLinkings Collection |
| • | ISWiComponent Object |
| • | AddDynamicFileLinking Method |
| • | RemoveDynamicFileLinking Method |
| • | ISWiFile Object |
New FlexNet Connect 12.01 Redistributables Available
InstallShield includes support for FlexNet Connect 12.01 in Basic MSI and InstallScript MSI projects. Use the Update Notifications view in InstallShield to include one of the two FlexNet Connect 12.01 merge modules—one has the Common Software Manager, and the other does not.
Enhancements
InstallShield includes the following enhancements.
Unicode Views in InstallShield
Several views and areas in InstallShield have been enhanced to display and allow you to enter characters from all languages. For example, now you can use Chinese characters in file names, paths, and registry entries if you are configuring system searches in the System Search view on an English machine. Previously, the characters were displayed in these areas of InstallShield as question marks.
The areas in InstallShield that have been enhanced to include the Unicode support are the System Search view, the tabs for a release in the Releases view, and the Multiple Instances tab for a release in the Releases view. Note that Unicode support was previously introduced in many other views in InstallShield 2010.
The improvements for the System Search view are applicable to the following projects: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.
The improvements for the tabs for a release in the Releases view are applicable to the following projects: Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, and Merge Module.
The improvements for the Multiple Instances tab in the Releases view are applicable to Basic MSI projects.
Command-Line Support for Generating a Log File While Using InstallShield MSI Diff
InstallShield MSI Diff includes a new /out command-line parameter. You can use this new parameter while running InstallShield MSI Diff from the command line to generate a log file that identifies the differences between two .msi, .msm, or .pcp files, or that shows the differences that are applied to a Windows Installer database by a transform (.mst) or patch file (.msp). You can also use this tool from the command line to generate a log file that identifies the differences between two InstallShield project files (.ism or .ise) that are saved in binary format.
To learn more, see Running InstallShield MSI Diff from the Command Line to Generate a Log File of Differences.
Support for Listing Local Microsoft SQL Server Instances on 64-Bit Systems
If you add SQL support to a project through the SQL Scripts view in InstallShield and the installation is run on a 64-bit target system, the built-in SQL-related run-time dialogs now list 64-bit local SQL Server instances, as well as 32-bit local SQL Server instances, 32-bit network SQL Server instances, and 64-bit network SQL Server instances. Previously when the installation was run on a 64-bit target system, the built-in SQL-related run-time dialogs did not list any 64-bit local SQL Server instances; they listed only 32-bit local instances, 32-bit network instances, and 64-bit network instances.
This functionality is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
InstallScript Logging and Uninstallation of 64-Bit Registry Changes
By default, the InstallScript engine now logs the changes that it makes to the 64-bit part of the registry during an InstallScript or InstallScript MSI installation on 64-bit target systems. Furthermore, the 64-bit registry changes that are logged by the InstallScript engine are now uninstalled during uninstallation.
Previously, if the InstallScript engine made changes to the 64-bit part of the registry during an installation, those changes were not logged as 64 bit specific, so they were not removed during uninstallation.
Support for Microsoft SQL Server Management Studio
The SQL Scripts view now includes support for Microsoft SQL Server Management Studio. To open a SQL script file of your project in SQL Server Management Studio, right-click the SQL script file in the SQL Scripts view and then click Open Script in Microsoft SQL Server Management Studio. This new command replaces the Open Script in Microsoft Query Analyzer command on the same context menu.
This functionality is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Support for Adding Project Outputs from Visual Studio Web Setup Projects
If you create a Visual Studio solution that includes a Web setup project and an InstallShield installation project and you are using InstallShield from within Visual Studio, you can now add project outputs from the Web setup project to your InstallShield project.
Ability to Select a Windows Installer Property when Configuring a Text File Change
Two settings in the Text File Changes view have been enhanced to make it easier to configure search-and-replace behavior for content in text files. The Find What and Replace What settings, which are displayed in the right pane when you select a replacement node in the Text File Changes view, now let you select a Windows Installer property from a list, or type a string. The list consists of all of the properties that are available in the Property Manager view of your project. Previously, you could manually enter a string or a property in these settings, but the list of properties was not available.
This enhancement is available in the following project types: Basic MSI and InstallScript MSI.
InstallScript Text Substitution Improvements for Resolving Environment Variable Paths in IISROOTFOLDER
InstallScript installations now have support for installing IIS data to IISROOTFOLDER if the IIS PathWWWRoot registry value contains an environment variable. Previously, when text substitution was performed for the IISROOTFOLDER variable in an InstallScript installation that included IIS support, the environment variable part of the path of IISROOTFOLDER was not resolved on Windows Server 2008 and later systems. If any components were configured to be installed to IISROOTFOLDER, they failed to install because the unresolved path was an invalid path.
Ability to Specify the Required Execution Level for Update.exe Manifests
The Required Execution Level setting is now available on the Advanced tab for a patch configuration in the Patch Design view of Basic MSI and InstallScript MSI projects. It is also available on the Advanced tab of the Build Settings area in the General Information view of QuickPatch projects.
Use these new settings to specify the minimum execution level that is required by your installation’s Update.exe file for running the upgrade on Windows Vista and later platforms. InstallShield adds a manifest that specifies the required level. By default, InstallShield uses the level that was configured in the previous setup launcher’s manifest.
Previously, the Required Execution Level setting was available only for the Setup.exe setup launchers. If you created an Update.exe patch, InstallShield used the same required execution level that was configured in the previous setup launcher’s manifest.
To learn more, see:
| • | Advanced Tab (in the Patch Design view) |
| • | Advanced Tab (for a QuickPatch project) |
Ability to Create .cab Files Without Compression
A new Cab Optimization Type setting is available on the Build tab for a release that is selected in the Releases view. If Compressed or one of the custom options is selected for the Compression setting, use the Cab Optimization Type setting to specify the type of compression that InstallShield should use when building the release’s .cab files. The available options are LZX compression, MSZIP compression, or no compression.
The Cab Optimization Type setting replaces the Optimize Size setting, which had support for only LZX compression and MSZIP compression; it did not let you skip compression.
The automation interface now includes support for this new setting. The ISWiRelease object includes a new CabCompressionType property that lets you specify which of the three compression options you want to use when you build a release through the automation interface.
This enhancement is available in the following project types: Basic MSI and InstallScript MSI.
For more information, see Build Tab for a Release.
Expanded List of Predefined Operating System Conditions in the InstallShield Prerequisite Editor
The Prerequisite Condition dialog box, which is displayed when you are adding or modifying a condition for an InstallShield prerequisite in the InstallShield Prerequisite Editor, now has predefined operating system conditions for Windows Server 2008 R2. Some of the Windows 7 options have been renamed to make it more clear which versions of Windows are checked, since some of the options check for the workstation version, the server version, or either version. The Prerequisite Condition dialog box also has new options that check only for Windows 7, not Windows Server 2008 R2. These changes let you quickly define more-targeted operating system conditions for any InstallShield prerequisites.
You can add InstallShield prerequisites to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
New Refresh Button in the Redistributables and Prerequisites Views
The Redistributables view (in Basic MSI, InstallScript MSI, and Transform projects) and the Prerequisites view (in InstallScript projects) contains a new Refresh button that you can use to refresh the list of redistributables that are displayed in the view. Previously, if you added redistributables to your machine when either view was open in InstallShield, it was necessary to close and then reopen the project in order to see an updated list in the view.
This enhancement is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Transform.
Support for Setting Permissions for the IUSR User Account
InstallShield now has support for securing files, folders, and registry keys for the well-known user account IUSR.
If you are using the custom InstallShield handling method of configuring permissions in your project, the User list on the Permissions dialog box has a new IUSR option. To use the custom InstallShield handling method, select this option in the Locked-Down Permissions setting in the General Information view. This functionality is available in the following project types: Basic MSI, InstallScript MSI, Merge Module, and Transform.
If you are using the InstallScript function SetObjectPermissions to set permissions, you can now pass IUSR for the szUser parameter. This functionality is available in InstallScript events in the following project types: InstallScript and InstallScript MSI. This functionality is also available through InstallScript custom actions in Basic MSI, InstallScript MSI, and Merge Module projects.
New IS_PERMISSIONS_OPTION_ALLOW_ACCESS Constant for the SetObjectPermissions Function
A new IS_PERMISSIONS_OPTION_ALLOW_ACCESS constant is available for use with the InstallScript function SetObjectPermissions. You can pass this constant instead of the number 0 in the nOptions parameter of SetObjectPermissions to indicate that the permissions that are being set should allow access to the specified file, folder, or registry key.
This functionality is available in InstallScript events in the following project types: InstallScript and InstallScript MSI. This functionality is also available through InstallScript custom actions in Basic MSI, InstallScript MSI, and Merge Module projects.
For more information, see SetObjectPermissions
New Constants for the DialogSetInfo Function
Two new constants are available for the nParameter parameter of the InstallScript function DialogSetInfo when you are using DLG_INFO_ALTIMAGE for the nInfoType parameter:
| • | DLG_INFO_ALTIMAGE_VERIFY_BMP—This constant specifies that the bitmap that is indicated by szInfoString should be used in subsequent dialogs. Before this bitmap is used, the installation checks for the existence of the bitmap. If the bitmap does not exist, the function returns an error that indicates that the bitmap was not found. |
| • | DLG_INFO_ALTIMAGE_REVERT_IMAGE—This constant specifies that dialogs should display the default bitmap. This constant is an alternative equivalent to the value of -1. The installation does not check for the existence of the bitmap when you use this constant. |
If you pass TRUE in the nParameter parameter, the installation does not check for the existence of the bitmap; if the bitmap does not exist in this scenario, the function does not return an error.
This functionality is available in InstallScript events in the following project types: InstallScript and InstallScript MSI.
For more information, see DialogSetInfo.
Enhancements for .NET Framework 4.0 Support
A new FOLDER_DOTNET_40 InstallScript variable is available. This variable stores the path of the .NET Framework 4.0 files.
Two new constants are available for use with the function Is:
| • | REGDB_KEYPATH_DOTNET_40_CLIENT |
| • | REGDB_KEYPATH_DOTNET_40_FULL |
Path Variable Support for Each Patch Configuration’s Output Location and Cache
The Common tab for a patch configuration that is selected in the Patch Design view contains two settings that let you browse to the appropriate folder: Patch Output Location and Patch Creation Cache. InstallShield now lets you use path variables for the folders instead of absolute paths. This support makes it easier to build releases on different build and development machines that use different directory structures.
This support is available if InstallShield is configured to use path variables on your system. (That is, the Path Variables tab on the Options dialog box must be configured to allow path variable support.) If you configure InstallShield to use absolute paths, the Patch Design view shows the absolute path to folders.
This enhancement is available in the following project types: Basic MSI and InstallScript MSI.
InstallScript Functions ServiceExistsService and ServiceGetServiceState No Longer Require Elevated Privileges
The InstallScript functions ServiceExistsService and ServiceGetServiceState no longer require elevated privileges. Therefore, installations can now call these functions when end users have limited privileges, such as in the Install UI sequence of a Basic MSI installation.
Important Information
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.
Installing More than One Version of InstallShield
InstallShield 2020 can coexist on the same machine with other versions of InstallShield.
The InstallShield 2020 Standalone Build can coexist on the same machine with other versions of the Standalone Build. In most cases, the Standalone Build is not installed on the same machine where InstallShield is installed. If you do install both on the same machine and you want to use the automation interface, review the Installing the Standalone Build and InstallShield on the Same Machine to learn about special registration and uninstallation considerations.
Integrating InstallShield with Visual Studio
Microsoft Visual Studio can be integrated with only one version of InstallShield 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
Upgrading Projects from InstallShield 2010 or Earlier
Upgrading Projects from InstallShield 2009 or Earlier
Upgrading Projects from InstallShield 2008 or Earlier