InstallShield 2018
New Features
InstallShield includes the following new features.
Ability to Create Suite Installations that Run Multiple Packages; New Contemporary, Customizable End-User Interface; Ability to Build Hybrid 32-Bit/64-Bit Installations
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.
Following are some highlights of this functionality.
Ability to Package Multiple Installations as a Single Installation
The new Suite project type contains a Packages view that lets you specify one or more of the following types of packages:
| • | Executable files (.exe), including Windows Installer–based and non-Windows Installer–based installations that you want to be run on target systems |
| • | Windows Installer packages (.msi) that you want to be run on target systems |
| • | Windows Installer patches (.msp) that you want to be applied on target systems |
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.
Contemporary, Customizable User Interface for the Installation; New Editor for Customizing Suite Setup.exe Wizard Pages
The Suite project type in InstallShield includes an entirely new end-user interface, with redesigned, contemporary 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 page—adding, moving, and removing a variety of different kinds of controls.
Support for Combining 64-Bit and 32-Bit Windows Installer Packages Into a Single Installation
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.
Support for Displaying a Single Progress Bar that Shows the Overall Status of the Entire Suite of Packages
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.
Optional Add or Remove Programs Entry for the Suite Installation
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.
Support for Running Suite Installations Without a User Interface
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.
Default Setup.exe User Interface Strings Included for All 35 Supported Languages; Ability to Edit the Suite Run-Time Strings
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.
Small Base Setup.exe File with the Ability to Download Only the Required Packages As Needed
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:
| • | On the Web, available for download by Setup.exe if needed |
| • | Embedded in Setup.exe and extracted to the target system if needed |
| • | Uncompressed and stored on the Suite source media |
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:
| • | Creating Advanced UI and Suite/Advanced UI Installations |
| • | Adding an .msi Package, an .msp Patch, or a Transaction to an Advanced UI or Suite/Advanced UI Project |
| • | Adding an Executable Package (.exe) to a Suite/Advanced UI Project |
| • | Working with the Wizard Interface |
| • | Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters |
| • | Advanced UI and Suite/Advanced UI Property Reference |
| • | Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects |
Redesigned, Expanded Support for Modularizing Installation Projects to Enable Reuse and Distribute Development Work
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:
| • | DIMs include support for virtually the same functionality that is available in Basic MSI projects. This gives authors of DIMs all of the flexibility that they need to develop their portions of an installation. |
| • | Release engineers can reuse DIMs in multiple Basic MSI projects, enabling efficiency. |
| • | Working with DIMs enables multiple team members to contribute to the development of the installation simultaneously. Each software developer or other team member can work on a separate DIM that the release engineer can reference in one or more Basic MSI projects. |
Once you have created a DIM, you can add it to a Basic MSI project in one of two ways:
| • | By reference—You can add a reference for a DIM project to your Basic MSI project through the Setup Design view or the DIM References view. With this method, the DIM elements are merged into the Basic MSI project at build time. Each time that you build the Basic MSI installation, InstallShield references the latest version of the DIM project and includes it in the installation that it generates. This method is the more commonly performed method. |
| • | By import—You can import a DIM project into your Basic MSI project by using the new Import DIM Wizard. This method is a one-time, irreversible import that merges the DIM data into the Basic MSI project at design time. |
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 component’s 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:
| • | Modularizing Installation Projects to Distribute Development Work and Enable Reuse |
| • | Including DIMs in a Project |
| • | Determining the Appropriate Method for Incorporating DIMs in Installation Projects |
| • | Using Path Variables in a DIM |
| • | DIM References View |
| • | Import DIM Wizard |
New InstallShield Prerequisites for Internet Explorer 9, SQL Server 2008 R2 Native Client, Windows Identity Foundation, and Other Redistributables
InstallShield includes several new InstallShield prerequisites that you can add to Basic MSI, InstallScript, and InstallScript MSI projects:
| • | Internet Explorer 9.0 |
| • | Microsoft SQL Server 2008 R2 Native Client 10.50.1600.1 |
| • | Windows Identity Foundation |
| • | Microsoft VSTO 2010 Runtime (x64) |
| • | Microsoft Office 2010 PIA (This prerequisite installs the Microsoft Office 2010 Primary Interop Assemblies. To use this prerequisite, download the PrimaryInteropAssembly.exe file from Microsoft’s Web site and run it to extract the .msi file.) |
Support for 64-Bit Dependency Scanning
The Static Scanning Wizard and the Dynamic Scanning Wizard—dependency scanners in InstallShield—now 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:
| • | The Static Scanning Wizard helps you identify a 64-bit .NET assembly’s possible dependencies on demand. This wizard displays a list of the dependencies that it finds, and it lets you specify whether you want to include each one in your project. |
| • | A component’s .NET Scan at Build setting lets you specify whether you want InstallShield to identify a 64-bit .NET assembly’s dependencies each time that you build your project. For InstallScript projects, the component’s .NET Assembly setting must also be set to Local Assembly. If InstallShield detects any possible missing dependencies at build time, InstallShield incorporates them into the release that it generates. |
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:
| • | Developing and Building Installations on 32-Bit vs. 64-Bit Systems |
| • | Scanning for 64-Bit Dependencies |
| • | Identifying Application Dependencies |
| • | Scanning 64-Bit .NET Assemblies for Dependencies |
| • | Identifying Properties and Dependencies of .NET Assemblies |
Support for Setting Permissions for Files, Folders, and Registry Keys in 64-Bit Locations
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.
Using the Custom InstallShield Handling Method in Windows Installer–Based Projects
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.
Using the InstallScript Function SetObjectPermissions in InstallScript-Based Projects and Windows Installer–Based Projects
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.
For more information, see SetObjectPermissions.
Improvements for COM Extraction
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:
| • | 0—Use API hooking to read existing registry entries for the DLL. |
| • | 1—Use registry redirection to prevent making changes to the registered DLLs on the build machine. If the value is not set, this is the default behavior on Windows XP and Windows Server 2003 systems. |
| • | 2—Use the new kernel mode monitoring, which combines the advantages of both of the other methods. If the value is not set, this is the default behavior on Windows Vista and later systems and on Windows Server 2008 and later systems. |
This feature applies to the following project types: Basic MSI, DIM, InstallScript MSI, and Merge Module.
Predefined System Searches for Adobe Reader 10, Internet Explorer 9, and Microsoft Office
InstallShield has new predefined system searches:
| • | Adobe Reader 10 |
| • | Internet Explorer 9 |
| • | Microsoft Office 2010 |
| • | Microsoft Office 2007 |
| • | Microsoft Office 2003 |
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.
Support for Software Identification Tagging
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 product’s 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:
| • | Including a Software Identification Tag for Your Product |
| • | General Information View Settings |
| • | ISWiProject Object |
Enhancements
InstallShield includes the following enhancements.
Merge Module Projects Now Include Built-In Support for IIS, Text File Changes, and XML File Changes
Several existing views are now available in Merge Module projects in InstallShield:
| • | Internet Information Services—This view enables you to create and manage new IIS Web sites, applications, virtual directories, application pools, and Web service extensions. |
| • | Text File Changes—This view lets you configure search-and-replace behavior for content in text files—for example, .txt, .htm, .xml, .config, .ini, and .sql files—that you want to modify at run time on the target system. |
| • | XML File Changes—This view lets you add references for nodes and node sets of XML files that you want to change at run time. |
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:
| • | Managing Internet Information Services |
| • | Modifying Text Files |
| • | Modifying XML Files |
New Application Pool Identity Option for IIS 7.x
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 pool’s 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 pool’s identity.
This feature applies to the following project types: Basic MSI, InstallScript, InstallScript MSI, and Merge Module.
For more information, see Application Pool Settings.
Automation Interface Enhancement: New RequiredExecutionLevel Property for Specifying the Required Execution Level for Setup.exe
The read-write RequiredExecutionLevel property has been added to the ISWiRelease object. 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.
See Also
Upgrading Projects from InstallShield 2011 or Earlier
Upgrading from Earlier InstallShield Versions
InstallShield 2018 Help LibraryJanuary 2018 |
Copyright Information | Flexera |