|
|
InstallShield 2009
InstallShield includes the following new features.
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 and Web projects include support for this feature.
To learn more, see:
InstallShield lets you add Windows Installer packages to Basic MSI, InstallScript MSI, and Web projects as chained .msi packages. If your Basic MSI, InstallScript MSI, or Web 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:
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 Project Properties area of 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:
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, Transform, and Web projects.
To learn more, see Specifying Whether Shared Component Patching Should Be Enabled for a Component.
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, Transform, and Web projects.
For more information, see the description of the Uninstall Superseded Component setting.
To learn more about patch sequences, see Patch Sequencing.
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, Transform, and Web 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.
InstallShield includes several InstallShield prerequisite files (.prq) for Windows Installer 4.5.
This feature applies to Basic MSI, InstallScript MSI, and Web projects.
For more information, see Adding Windows Installer Redistributables to Projects.
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 or Web project. Previously, if your Basic MSI or Web 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 and Web 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.
For more information, see:
A new /debuglog command-line parameter is available for the Setup.exe setup launcher for Basic MSI, InstallScript MSI, and Web projects. Use this command-line parameter to generate a log file for debugging. For more information, see /debuglog.
InstallShield lets you add managed-code custom actions to Basic MSI, InstallScript MSI, Merge Module, and Web 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:
InstallShield includes a new Value-Added Services view that lets you incorporate services in your InstallShield installations and be paid when those services are installed or used, according to the services’ terms and conditions.
This release of InstallShield includes support for one value-added service: the Yahoo! Toolbar offering. When you participate in this program, you add the Yahoo! Toolbar to your installation project through the Value-Added Services view. After your end users install the Yahoo! Toolbar with your product, you get paid for every time that they use the Yahoo! Toolbar.
This support is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Web.
To learn more, see the following help topics:
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 and Web projects.
For more information, see:
InstallShield now includes many new .NET-related InstallShield prerequisites that you can add to Basic MSI, InstallScript MSI, and Web 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:
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 Using the InstallShield Tools.
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, InstallScript MSI, and Web projects.
For more information, see Configuring the Compression Level for Files that Are Streamed into Setup.exe and ISSetup.dll.
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, InstallScript MSI, and Web 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.
InstallShield includes support for launching the Open dialog from one of the dialogs in your Basic MSI or Web 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.
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, InstallScript MSI, and Web projects.
InstallShield now includes an InstallShield prerequisite for Microsoft SQL Server 2005 Express Edition SP2. You can add this InstallShield prerequisite to Basic MSI, InstallScript MSI, and Web projects.
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.
InstallShield is now integrated with Visual Studio 2008, enabling development of installations and products within the same Visual Studio interface.
InstallShield now lets you convert a Visual Studio 2008, Visual Studio 2005, Visual Studio .NET 2003, or Visual Studio .NET setup project (.vdprj) 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 (.vdprj) 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 Visual Studio Projects to InstallShield Projects.
InstallShield now enables you to specifically target installations for devices with Windows Mobile 6.x Professional, Windows Mobile 6.x Classic, and Windows Mobile 6.x Standard. This applies to Basic MSI, InstallScript MSI, Smart Device, and Web projects.
InstallShield now lets you use a personal information exchange file (.pfx) for digitally signing .cab files that are included in installations for Windows Mobile–powered devices. In addition, you can now specify the password for the digital signature. The Sign the CAB Files panel in the Windows Mobile Wizard and the Smart Device Setup Wizard is where you specify the .pfx file and the password.
If you specify a .pfx file for signing, InstallShield uses SignTool.exe to sign your files. If you specify an .spc file and a .pvk file, InstallShield uses Signcode.exe to sign your files. Using a .pfx file is often the preferred method, since it is more likely to work in many different environments (such as locked build machines). If you specify the digital signature password in InstallShield, you will never see a password prompt if you are using a .pfx file. However, if you are using .spc and .pvk files, a password prompt may be displayed.
Previously, InstallShield allowed you to specify .spc and .pvk files for Windows Mobile–powered device files, but not .pfx files.
This functionality applies to Basic MSI, InstallScript MSI, Smart Device, and Web projects.
The Windows Mobile Wizard and the Smart Device Setup Wizard let you set platform requirements for files that are to be installed to mobile devices. You can select platforms from a predefined list of platforms. If you want to target a platform that is not in the predefined list, or if you want to modify any of the configuration settings that are associated with one of the predefined platforms, you can now do so by editing the Settings.xml file that is installed with InstallShield. Previously, the platform list was not configurable in the Settings.xml file, so it was necessary to upgrade to a new version of InstallShield that included support for new platforms. This applies to Basic MSI, InstallScript MSI, Smart Device, and Web projects.
For more information, see Modifying the List of Available Windows Mobile Platforms or their Associated Settings.
The Device Files panel in the Windows Mobile Wizard and the Smart Device Setup Wizard now lets you specify whether you want to compress the .cab files that are created for Windows Mobile–powered devices at build time. Previously, InstallShield did not have any support for building compressed .cab files.
This functionality applies to Basic MSI, InstallScript MSI, Smart Device, and Web projects.
Several new redistributables are available for mobile device installations: .NET Compact Framework 3.5, SQL Server Compact 3.5, SQL Server Compact 3.5 Replication, and SQL 3.5 Client. This applies to Basic MSI, InstallScript MSI, Smart Device, and Web projects.
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, Merge Module, and Web.
For more information, see Dialog Support for Right-to-Left Languages.
When you build a project that includes an InstallScript file (.rul) and the InstallScript code contains one or more references to string table entries that use the string constant operator (@), InstallShield now validates the string table entries at build time.
If a string identifier in the project’s InstallScript file is not defined in the project’s string table, InstallShield displays build warning -7174.
This applies to the following project types: Basic MSI with InstallScript custom actions, InstallScript, InstallScript MSI, InstallScript Object, Merge Module with InstallScript custom actions, and Web with InstallScript custom actions.
To learn more, see:
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.
InstallShield includes the following enhancements.
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, Merge Module, and Web projects.
To learn more, see:
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.
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.
Basic MSI, InstallScript MSI, and Web 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.
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.
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.
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, InstallScript MSI, or Web 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, InstallScript MSI, and Web.
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, InstallScript MSI, and Web 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:
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:
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:
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, InstallScript MSI, and Web 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:
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, InstallScript MSI projects, Web projects, and patches that were created in the Patch Design view.
To learn more, see Validating Upgrades, Patches, and QuickPatch Packages.
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:
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, MSI Database, and Web projects.
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, InstallScript MSI, and Web.
For more information, see Setup.exe and Update.exe Command-Line Parameters.
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:
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, InstallScript MSI, and Web 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, InstallScript MSI, and Web 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:
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, InstallScript MSI, and Web projects.
For more information, see Requirements Tab.
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, InstallScript MSI, and Web projects.
To learn more, see Adding a New SQL Connection.
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, InstallScript MSI, and Web projects.
A new DIMs tab on the Options dialog box lets you specify the location where InstallShield should search for DIM dependencies when you add a DIM reference to a project. In addition, InstallShield now automatically adds any of the DIM reference’s dependent DIM files to your project.
To learn more, see:
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, Transform, and Web. Previously, only Basic MSI, InstallScript MSI, and Web projects included support.
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, InstallScript MSI, or Web 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:
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, InstallScript MSI, and Web projects.
InstallShield now includes support for rolling back a Windows Mobile–powered device installation that is included in a desktop-to-device installation. Thus, if an end user clicks the Cancel button during the installation of a product for a Windows Mobile–powered device, the installation is rolled back, and any associated .ini files, .cab files, and .ico files are deleted.
You can save an InstallShield 2009 project as an InstallShield 2008 project (.ism) through the automation interface by using the new epv140 value for the PropertySchemaVersion property of the ISWiProject object. For more information, see the description of the PropertySchemaVersion property.
Some enhancements have been made to the InstallScript language.
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.
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
|
|
Copyright Information | Contact Acresso |