InstallShield includes the following new features.
The Premier edition of InstallShield now lets you build a Suite installation that uses the next-generation setup launcher (Setup.exe) to conditionally run multiple installations and apply Windows Installer patches (.msp) as needed on target systems. This support is available through a new Suite project type. Suite installations can be run on systems with Windows XP and later and with Windows Server 2003 and later; they cannot be run on systems with Windows 2000.
Following are some highlights of this functionality.
The new Suite project type contains a Packages view that lets you specify one or more of the following types of packages:
The Packages view also lets you include multiple .msi and .msp packages that you want to be run using transaction processing, a feature of Windows Installer 4.5 and later. The packages are chained together and processed as a single transaction. Each Suite installation can have multiple separate transactions. If one or more of the packages in a transaction cannot be installed successfully or if the end user cancels the installation, Windows Installer initiates rollback for all of the chained packages within the current transaction to restore the system to its earlier state.
The Suite installation launches the appropriate packages at run time based on conditions that you have defined and the order in which you listed the packages in the Packages view.
The Suite project type in InstallShield includes an entirely new end-user interface, with redesigned, modern built-in wizard pages that you can include and customize in your Suite installations. The new wizard page editor in this project type lets you add, sequence, and remove pages as needed; it also lets you modify the layout of any pageadding, moving, and removing a variety of different kinds of controls.
As more and more users move to 64-bit versions of Windows, you may need to now, or in the near future, deliver to customers a single installation that installs to 32-bit locations on 32-bit systems and to 64-bit locations on 64-bit systems. The Suite project type lets you include both 32-bit packages and 64-bit packages in one Suite installation, and run only the appropriate packages on each target system. Previously, other alternatives required delivering two separate installations (one for 32-bit systems and one for 64-bit systems) or creating a custom launcher, a bootstrap application, or an InstallScript installation.
The progress bar on the progress wizard page in a Suite installation shows the status of the entire suite of packages. This integrated progress bar presents end users with a clear visual indication of how far along the Suite installation is overall. To ensure that end users see only the integrated progress bar, you must include only .exe installations for which you have specified command-line parameters that hide the user interface (that is, run silently), .msi packages, and .msp patches.
Suite projects let you specify whether you want to have an entry in Add or Remove Programs for your Suite installation. This entry lets end users perform maintenance for your Suite, modifying or removing if needed. The General Information view in a Suite project has a Show Add or Remove Programs Entry setting that lets you indicate the appropriate behavior.
If you want to show only a single entry for the entire Suite, ensure that you hide the entries from the packages that you include in the Suite project.
End users can run your Suite installations with a user interface or silently, without a user interface. Silent installations run without user intervention; end users can avoid monitoring the installation and providing input through run-time wizard pages.
Translations of all of the default strings that are displayed in the built-in wizard pages of Suite projects are available in all 35 of the run-time languages that InstallShield supports. All of these Suite strings are displayed in the String Editor view of a Suite project. This String Editor view offers the same robust support that other types of projects offer, giving you complete and centralized control over the text strings that are displayed at run time during the Suite installation process.
Suite projects include flexible options for specifying the run-time source location of each package in the Suite installation. When you define the packages that you are including in a Suite project, you can specify the location of each individual package. The available options are:
The base Setup.exe file that is used for Suite installations is much smaller than the base Setup.exe files that are used for Basic MSI, InstallScript MSI, and InstallScript installations. Thus, your end users can quickly download a small Suite Setup.exe file, and the Setup.exe file can download and launch one or more required packages as needed.
For more information, see:
InstallShield includes a new project type called DIM, which is known as a developer installation manifest. A DIM project is a feature-sized collection of related items such as product files, shortcuts, registry entries, text file changes, IIS Web sites, and other elements that together make up a discrete portion of a product installation. Some benefits of using DIMs are as follows:
Once you have created a DIM, you can add it to a Basic MSI project in one of two ways:
This redesigned, expanded DIM support replaces the previous support that required users to create DIMs in a separate tool called InstallShield Collaboration, and then import the DIM files into InstallShield Basic MSI projects. The new DIM support is more robust than the previous support. The new DIM project type lets you have virtually the same complete level of authoring flexibility that is available for Basic MSI projects. For example, the new DIM project type lets you have full control over component creation: you can add components to a new DIM project, set the key file of a component, and configure the components settings. The new DIM project type also lets you configure IIS Web sites. InstallShield Collaboration did not have that sort of flexibility over component design, and it did not have any built-in support for configuring IIS Web sites.
The ability to create DIM projects is available in the Premier edition of InstallShield. This support is also available in the InstallShield Developer Installation Manifest Editor, a new collaboration add-on. The ability to add DIM files to Basic MSI projects is available in the Premier edition of InstallShield.
For more information, see the following:
InstallShield includes several new InstallShield prerequisites that you can add to Basic MSI, InstallScript, and InstallScript MSI projects:
The Static Scanning Wizard and the Dynamic Scanning Wizarddependency scanners in InstallShieldnow include support for identifying 64-bit dependencies of the 64-bit files in your project. If you are using InstallShield on a 64-bit version of Windows Vista or later or a 64-bit version of Windows Server 2008 or later, the scanners can detect the 64-bit dependencies. The wizards let you specify whether you want to include each detected potential dependency in your project.
In addition, if you use InstallShield on a 64-bit version of Windows Vista or later or a 64-bit version of Windows Server 2008 or later, and you use either of the following built-in methods for detecting dependencies, InstallShield can scan for 64-bit dependencies of the 64-bit .NET assemblies in your project:
InstallShield must be installed on a 64-bit operating system in order to scan 64-bit files for 64-bit dependencies. Note that if you use InstallShield on a 32-bit version of Windows, these built-in scans can check for only 32-bit dependencies of the 32-bit files in your project. If your project includes 64-bit files, you can manually add any dependencies to the project as needed.
To learn more, see:
InstallShield has support for setting permissions for files, folders, and registry keys in 64-bit locations. The support varies, depending on which project type you are using.
If you are using the custom InstallShield handling method to set permissions for files, folders, and registry keys, you can now set permissions for these items when they are in 64-bit locations; this includes 64-bit locations in the registry, as well as the 64-bit System32 folder on 64-bit systems. The file, folder, or registry key must be included in a component that is marked as 64 bit (that is, Yes is selected for its 64-Bit Component setting). Previously, if the component was marked as 64 bit, permissions could not be set, and a run-time error was displayed.
This custom InstallShield handling support is available in the following project types: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform. The Locked-Down Permission setting in the General Information view lets you specify which method you want to use for setting permissions: either the custom InstallShield handling method or the traditional Windows Installer handling method.
If the REGDB_OPTION_WOW64_64KEY option is enabled and you use the InstallScript function SetObjectPermissions to set permissions for a 64-bit registry key, the function can set its permissions correctly. To force SetObjectPermissions to set permissions for a 64-bit registry key regardless of whether the REGDB_OPTION_WOW64_64KEY option is enabled, you can use the new IS_PERMISSIONS_OPTION_64BIT_OBJECT constant; pass this constant in the nOptions parameter of SetObjectPermissions. Note that the IS_PERMISSIONS_OPTION_64BIT_OBJECT constant should not be passed on 32-bit target systems.
If file system redirection is disabled using the WOW64FSREDIRECTION constant when SetObjectPermissions is called to set permissions for a file or folder in the 64-bit System32 folder, the function can set the permissions correctly. If file system redirection is not disabled, the permissions cannot be set.
You can use the SetObjectPermissions function in InstallScript events in InstallScript and InstallScript MSI projects. You can also use this function in InstallScript custom actions in the following project types: InstallScript, Basic MSI, InstallScript MSI, and Merge Module.
InstallShield supports a new monitoring method for COM extraction. If you are using InstallShield on a Windows Vista or later system or a Windows Server 2008 or later system, this new method is used by default. The method uses a kernel driver to monitor the areas of the registry that are modified during dynamic COM extraction at build time and static COM extraction at design time. It combines the advantages that the earlier methods provided, allowing the DLL to read existing registries entries and preventing changes to the build machine.
If necessary, you can switch between the three different COM extraction methods by setting the value data of the UseAPIRegistryHooks registry value, which is in the registry key HKEY_LOCAL_MACHINE\SOFTWARE\InstallShield\RegSpy (on 32-bit machines) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\RegSpy (on 64-bit machines). Possible REG_DWORD value data are:
This feature applies to the following project types: Basic MSI, DIM, InstallScript MSI, and Merge Module.
InstallShield has new predefined system searches:
If your installation requires one or more 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.
ISO/IEC 19770-2 is an international standard for the creation of software identification tags. A software identification tag is an XML-based file that contains descriptive information about the software, such as the product name, product edition, product version, and publisher. Software asset management tools collect the data in the tags to provide accurate application identification for software that is installed in an enterprise.
Software identification tagging is evolving as an industry standard, enabling independent software vendors to create smarter applications that give their customers better information for software asset management and license optimization initiatives. Including the identification tag in your products installation makes it possible for your customers to use tools that can monitor their internal usage of your product, allowing them to manage and optimize the number of licenses of your product that they obtain from you, and stay in compliance with your licensing policies.
InstallShield includes several new settings in the General Information view that let you specify information that is required to create an identification tag for your product. This view also contains a new Use Software Identification Tag setting that lets you specify whether you want InstallShield to create the tag at build time and include it in your installation; the default value of this setting is Yes.
Note that if Yes is selected for the Use Software Identification Tag setting but you have not entered values in one or more of the required identification settings (the Unique ID, Tag Creator, and Tag Creator ID settings in the General Information view), build warning -7235 occurs, once for each of the settings that are blank. This build warning explains that the software identification tag could not be created and included in the installation because a specific required setting was left blank. To resolve this warning, enter appropriate value in each specific setting, or select No for the Use Software Identification Tag setting.
The automation interface includes support for the new tag settings. The ISWiProject object includes a new EnableSwidtag property that lets you enable or disable the creation of a software identification tag in a project. It also includes a new SwidtagProperty property that you can use to configure various tag-related settings that are also configurable in the General Information view.
This feature applies to Basic MSI projects.
For more information, see:
InstallShield includes the following enhancements.
Several existing views are now available in Merge Module projects in InstallShield:
Use these views in Merge Module projects to configure IIS, specify text file changes, and specify XML file changes. The same procedures that were used for configuring these changes in installation projects are now supported in Merge Module projects. When you build a merge module that contains project information in these views, add the merge module to an installation project, and then build a release in the installation project, InstallShield includes the applicable run-time support in the installation.
Previously, these views were available only in installation projects.
To learn more, see:
A new ApplicationPoolIdentity option is available in the Identity setting for an application pool that is configured in the Internet Information Services view. If you want a virtual identity account that is unique to the selected application pool to be used for running the application pools worker process, select this option. Support for this option is available on target systems that have IIS 7 and later. If this new option is selected in an installation that is run on a system that has IIS 6, the NetworkService account is used instead for the application pools identity.
This feature applies to the following project types: Basic MSI, InstallScript, InstallScript MSI, and Merge Module.
For more information, see.
The read-write RequiredExecutionLevel property has been added to the. This property corresponds with the Required Execution Level setting on the Setup.exe tab for a release in the Releases view. This property is available for Basic MSI, InstallScript, and InstallScript MSI projects.
Copyright Information | Contact Us