What’s New in InstallShield 2013

InstallShield 2016

New Features

InstallShield includes the following new features.

Ability to Create Run-Time Actions That Extend the Behavior of a Suite/Advanced UI Installation

You may require your Suite/Advanced UI installation to perform various run-time tasks that are outside the scope of the packages that you are including in the installation. For example, you may need the Suite/Advanced UI installation to do one or more of the following:

Install an application before the user interface of the Suite/Advanced UI installation is displayed.

One sample scenario in which this may be necessary is when one of the packages in your Suite/Advanced UI installation runs SQL scripts to install an Oracle database. Before this package is run, you may want the Suite/Advanced UI interface to display a wizard page that lets end users select the appropriate server from a list of servers that are available on the network. This type of UI support requires that ODBC drivers be installed on the target system.

Search the target system for the presence or absence of a particular product, technology, folder, file, registry entry, or other item.
Configure the target system before or after running a package in the Suite/Advanced UI installation.

To extend the capabilities of a Suite/Advanced UI installation and make it possible to perform those sorts of tasks and more, you can use the new Events view in your Suite/Advanced UI project to create actions that run executable files, call DLL functions, run PowerShell scripts, or set Suite/Advanced UI properties at run time.

When you add an action to your project, you can schedule when at run time you want it be launched:

Use the Events explorer in the Events view to schedule the action to run during one or more of the built-in events that the Suite/Advanced UI manages. This area of the view lists the events and the actions that occur during each event in chronological order from top to bottom.
Use the settings in the Events area of the Packages view to schedule an action to run before or after the Suite/Advanced UI engine installs, removes, modifies, or repairs a package.

When you schedule an action, you can build conditional statements that control whether the action should be run. You can use the same types of condition checks that are available in other areas of a Suite/Advanced UI project, as well as two additional new types of condition checks:

Package Operation—Check the state (for example, install or remove) in which a particular package in the Suite/Advanced UI installation is running.
Feature Operation—Check the state (for example, install or remove) in which a particular feature in the Suite/Advanced UI installation is running.

These types of conditions are available only for actions that are associated with an event in the Events view, or with a package in the Packages view.

Note that the PowerShell action support requires PowerShell 2.0 or later on target systems.

This new feature is available in the Premier edition of InstallShield.

For more information, see:

Using Actions to Extend the Behavior of a Suite/Advanced UI Installation
Working with an .exe File for an Action in a Suite/Advanced UI Installation
Working with a DLL File for an Action in a Suite/Advanced UI Installation
Working with a PowerShell Script for an Action in a Suite/Advanced UI Installation
Adding an Action to a Suite/Advanced UI Project
Configuring a Suite/Advanced UI Action’s Settings
Scheduling a Suite/Advanced UI Action
Types of Events in a Suite/Advanced UI Installation
Events View
Packages View
Package Operation Condition Settings
Feature Operation Condition Settings

Support for Enabling Windows Roles and Features During a Suite/Advanced UI Installation

If a particular package in your Suite/Advanced UI installation requires that one or more Windows roles and features be enabled on target systems, you can specify this requirement through the new Windows Features setting in the Packages view when you are configuring the package in your Suite/Advanced UI project. At run time, if an eligible package that is being installed requires one or more Windows roles or features that are disabled, the Suite/Advanced UI installation enables those roles and features before launching the package.

For example, your Suite/Advanced UI project may have a package that installs an IIS Web site that requires that the Internet Information Services feature in Windows be turned on. Another package in the same project may require that the PowerShell feature be turned on. When you are configuring the settings of those packages in your project, you can specify the Windows features that are required; at run time, if a package is eligible to be installed on a target system but any of its required Windows features are disabled, the Suite/Advanced UI installation enables those disabled Windows features before launching it. If the package is not eligible, its required Windows features are not enabled.

InstallShield has built-in support for enabling several Windows features:

Internet Information Services
PowerShell
.NET Framework 3.x

InstallShield also lets you specify additional Windows roles and features that a package requires.

This new feature is available in the Premier edition of InstallShield.

To learn more, see:

Enabling Windows Roles and Features During a Suite/Advanced UI Installation
Packages View

Ability to Create Advanced UI and Suite/Advanced UI Project Templates

InstallShield has support for using Advanced UI and Suite/Advanced UI projects as templates. A project template contains default settings and design elements that you want to use as a starting point when you create a new Advanced UI or Suite/Advanced UI project.

You can designate any Advanced UI or Suite Advanced UI project to be a template. Project files and template files have the same file extension: .issuite.

To designate that an .issuite project file is a template file and make the template available for selection in the New Project dialog box, right-click in the All Types tab on the New Project dialog box and then click Add New Template. InstallShield lets you browse to the .issuite file that you want to use as a template, and it adds a new icon for it to the All Types tab.

To create a new Advanced UI or Suite/Advanced UI project using your .issuite file as a template, select the template’s icon on the All Types tab of the New Project dialog box when you are creating the new project.

For instructions, see:

Creating Project Templates
Basing New Projects on Templates

New Built-in Template Available for Creating Installations that Install Multi-tier Applications

InstallShield includes a new Multi-tier Application template that helps you get started with creating a Suite/Advanced UI installation for cloud-based multi-tier applications. You can create this sort of installation to enable end users to easily manage the installation of tiers that install Web sites, databases, and applications. They can use the wizard pages in the Suite/Advanced UI installation to select which tiers they want to install, or they can use the command-line support to select the appropriate features.

The new Multi-tier Application template contains three tiers that are exposed as features. You can customize these features to include the tiers of your product, adding or removing features as needed. The template also contains four releases in the Releases view: one flagged for each of the three predefined features, and one that includes all of the features. This enables you to build separate installations—one for each tier, and one that lets end users install all available tiers.

This feature is available in the Premier edition of InstallShield.

New InstallShield Prerequisites for .NET Framework 3.5 SP1, Microsoft Visual C++ 2012, and SQL Server 2008 R2 Express SP2

InstallShield includes the following InstallShield prerequisites that you can add to Advanced UI, Basic MSI, InstallScript, InstallScript MSI, and Suite/Advanced UI projects:

Microsoft .NET Framework 3.5 SP1 (Windows Feature)
Microsoft SQL Server 2008 R2 Express SP2 (x64)
Microsoft SQL Server 2008 R2 Express SP2 (x86 & x64Wow)
Microsoft SQL Server 2008 R2 Express SP2 (x86)
Microsoft Visual C++ 2012 Update 1 Redistributable Package (x64)
Microsoft Visual C++ 2012 Update 1 Redistributable Package (x86)

These prerequisites install the various technologies on supported target systems.

New Application Virtualization Suitability Tests

Several new validation suites are available in InstallShield for helping you to determine how ready your products are for virtualization. The InstallShield virtualization internal consistency evaluators (ISVICEs) that are included in these suites let you check suitability for Microsoft App-V, Microsoft Server App-V, VMware ThinApp, and Citrix XenApp. The validation suites can enable you to make more informed decisions about how you build your product if you are considering offering your customers a virtualized version.

If you want to configure InstallShield to perform validation with these validation suites each time that a Basic MSI release is successfully built: On the Tools menu, click Options. On the Validation tab, select the appropriate check boxes.

If you want to perform validation separately from the build process: On the Build menu, point to Validation, and then click the appropriate new suite.

The virtualization suites are available in the Premier Edition of InstallShield.

This feature is available in the following project types: Basic MSI and InstallScript MSI.

For more information, see:

InstallShield Virtualization Suitability Suite
Validating Projects

Support for Creating Microsoft App-V 5.x Packages

The Microsoft App-V Assistant in InstallShield includes support for creating virtual applications in the Microsoft App-V 5.x format. The Package Information page in this assistant lets you specify which version of App-V—5.x or 4.x—you want to target.

If you are targeting App-V 5.x, a new version of the App-V Launcher tool is available for testing App-V 5.x packages before moving them to the deployment server. The new version of this tool is capable of launching a Command Prompt window within the virtual environment of the App-V package. Thus, it is no longer necessary to inject diagnostic tool shortcuts for Cmd.exe or Regedit.exe directly into an App-V package beginning with App-V 5.x.

The name of the directory in which InstallShield saves an App-V package at build time varies, depending on which version of App-V you are targeting. For App-V 5.x packages, the directory is ProductName, and it is placed in a folder called App-VPackage. For App-V 4.x packages, InstallShield includes the product version number to the ProductName folder; that is, ProductName_vN, (where N is the product version number).

Note that although you can configure settings for an App-V 5.x package on any version of Windows that InstallShield supports, building an App-V 5.x package from within InstallShield requires Windows 8 or Windows Server 2012. Attempting to build an App-V 5.x package on an earlier version of Windows causes build error -9424.

The Microsoft App-V Assistant is available in the Premier Edition of InstallShield.

For information, see:

Components of an App-V Package
Build Output for App-V Packages

New Property Comparison Type of Condition Check; New Property for Determining the Install Mode for Suite/Advanced UI and Advanced UI Projects

When you are building a conditional statement for an exit, detection, eligibility, or feature condition in a Suite/Advanced UI or Advanced UI project, or for an action in a Suite/Advanced UI project, you can select from a number of different types of checks that you want to be evaluated on target systems. Use the new Property Comparison type of condition check to check the value of a particular built-in Advanced UI or Suite/Advanced UI property, or a property that is defined in the Property Manager view.

In addition, a new read-only property called ISInstallMode is now available. This property stores a value that indicates the mode (first-time installation, maintenance/UI maintenance selection, modify, remove, repair, or stage only) in which the Suite/Advanced UI or Advanced UI installation is running. You can use this property in conditional statements that you configure in your project.

For more information, see:

Types of Condition Checks in Advanced UI and Suite/Advanced UI Projects
Property Comparison Condition Settings
Advanced UI and Suite/Advanced UI Property Reference

Ability to Build Pure 64-Bit .msi and .msm Packages; New Build-Time Architecture Validation

Windows Server Core supports disabling 32-bit Windows-on-Windows (WOW64) support. As this configuration becomes more popular, you may want to ensure that your 64-bit applications can install without any reliance on 32-bit functionality. To make this possible, InstallShield now enables you to build pure 64-bit .msi packages; these can be run on 64-bit Windows-based systems that do not have WOW64 functionality. You can also build pure 64-bit merge modules and include them in InstallShield projects that have 64-bit support. If your installation or merge module project targets a pure 64-bit environment and includes support that requires any built-in InstallShield custom action DLLs, InstallShield includes new 64-bit versions of these DLLs in your releases at build time.

InstallShield now has architecture validation that you can use when building a release in InstallShield. Architecture validation enables you to detect potentially problematic cases in which your installation may try to install product files or use run-time binaries that may not match the architecture of a target system.

For example, if end users may run your installation on 64-bit target systems that do not have WOW64 support, architecture validation can help you identify any 32-bit product files or 32-bit custom action files in your installation. In addition, if you are mixing 64-bit and 32-bit product files (or 64-bit and 32-bit custom actions) in a single project and generating separate 32-bit and 64-bit .msi packages, you can use architecture validation to identify any 64-bit product or custom action files in your 32-bit releases, since these files cannot be loaded on 32-bit target systems.

To specify what type of architecture validation you want to use and identify whether you want to build a pure 32-bit or 64-bit package, use the new Architecture Validation setting, which is available on the General tab when you select a product configuration in the Releases view. Two types of validation are available: strict and lenient.

Strict validation may trigger build errors if the architecture that the Template Summary property specifies does not match the architecture for one or more of the custom action files that are being included in the release. This type of validation may also trigger build warnings if the architecture that the Template Summary property specifies does not match the architecture for one or more of the product files that are being included in the release.

Lenient architecture validation, which is the default type of validation, does not trigger build errors or warnings if the architecture that the Template Summary property specifies does not match the architecture for one or more of the product files or the custom action files that are being included in the release.

The automation interface includes support for the new architecture validation support. The ISWiProductConfig object includes a new read-write ArchitectureValidation property that lets you specify the type of architecture validation that you want to use for a product configuration.

This feature is available in the following project types: Basic MSI and Merge Module.

To learn more, see:

Selecting the Appropriate Type of Architecture Validation for Builds
Targeting 64-Bit Operating Systems
Using the Template Summary Property
ISWiProductConfig Object

Validation for the Windows 8 Logo Program

InstallShield includes two new validation suites: InstallShield Validation Suite for Windows 8 and InstallShield Merge Module Validation Suite for Windows 8. These validation suites contain several new InstallShield internal consistency evaluators (ISICEs): ISICE21 through ISICE26. The suites can help you verify whether your Windows Installer–based installation or merge module meets the installation requirements of the Windows 8 Desktop App Certification Program. If you want to be able to use the Windows 8 logo artwork, your product’s installation must meet the program’s requirements. These suites can also help you verify that your installation or merge module will work on Windows Server 2012 systems.

If you want to configure InstallShield to perform validation with these validation suites each time that a release is successfully built: On the Tools menu, click Options. On the Validation tab, select the appropriate check boxes.

If you want to perform validation separately from the build process: On the Build menu, point to Validation, and then click the appropriate new suite.

For more information, see the following:

Validating Projects
ISICEs
Requirements for the Windows Logo Program

Improvements for Configuring Shortcuts on the Latest Platforms; InstallScript Language Improvements for Shortcut Creation

InstallShield offers enhancements for configuring shortcuts in your projects.

Support for Preventing a Shortcut from Being Pinned to the Windows 8 Start Screen

InstallShield lets you specify whether you want each shortcut in your installation to be pinned by default to the Start screen on Windows 8 target systems. You may want to disable pinning for shortcuts that are for tools and secondary products that are part of your installation. If you disable pinning for a shortcut, the shortcut is still available in the Apps list that contains shortcuts to all of the applications on the system.

To prevent Start Screen pinning for a shortcut, use the new Pin to Windows 8 Start Screen setting for a shortcut in the Shortcuts view.

This feature is available for the following project types: Basic MSI, DIM, InstallScript, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.

The automation interface includes support for specifying whether you want a shortcut to be pinned to the Windows 8 Start screen. The ISWiShortcut object includes a new read-write Boolean EnableWin8StartPin property that indicates whether the shortcut is configured to be pinned by default to the Start screen on Windows 8 target systems.

To learn more, see:

Suppressing Initial Pinning of a Shortcut to the Windows 8 Start Screen
Shortcuts View
ISWiShortcut Object

Support for Preventing End Users from Pinning a Shortcut to the Taskbar or Start Menu

For each shortcut in your installation, InstallShield lets you specify whether you want to let end users pin the shortcut to the taskbar or to the Start menu. If you want to prevent this type of pinning, the installation sets a property that hides the context menu commands for pinning the shortcut to the taskbar and the Start menu. You may want to prevent pinning for shortcuts that are for tools and secondary products that are part of your installation.

Support for preventing end users from pinning a shortcut to the taskbar or Start menu varies, depending on the project type that you are using.

In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform projects: To prevent taskbar and Start menu pinning for a shortcut, use the Shell Properties setting for a shortcut in the Shortcuts view. This setting has a new Prevent Pinning option that lets you disable pinning for the selected shortcut. Windows Installer 5 includes support for this shortcut setting. Previously, it was necessary to manually enter the appropriate property name and value to configure this behavior.

In InstallScript projects: To prevent taskbar and Start menu pinning for a shortcut, use the new Prevent Pinning setting in the Shortcuts view. Windows 7 and later include support for this shortcut setting. Previously, InstallShield did not have support for configuring this functionality in InstallScript projects.

The automation interface includes support for specifying whether you want the context menu commands for pinning a shortcut to the taskbar and to the Start menu to be displayed after end users install your product. The ISWiShortcut object includes a new read-write Boolean PreventPinning property that indicates whether the shortcut is configured to hide the context menu commands for pinning.

For more information, see:

Specifying Whether End Users Should Be Able to Pin a Shortcut to the Taskbar or Start Menu
Shortcuts View
ISWiShortcut Object

Support for Preventing a Shortcut on the Start Menu from Being Highlighted as Newly Installed

InstallShield lets you optionally prevent a shortcut on the Start Menu from being highlighted as newly installed after end users install your product. This has the same effect as clearing the Highlight newly installed programs check box in the Customize Start Menu dialog box for an individual item on a target system. You may want to set this property for shortcuts that are for tools and secondary products that are part of your installation.

Support for the highlighting behavior varies, depending on the project type that you are using.

In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform projects: To prevent the highlighting behavior for a shortcut, use the Shell Properties setting for a shortcut in the Shortcuts view. This setting has a new Do Not Highlight as New option that lets you disable highlighting for the selected shortcut. Windows Installer 5 includes support for this shortcut setting. Previously, it was necessary to manually enter the appropriate property name and value to configure this behavior.

In InstallScript projects: To prevent the highlighting behavior for a shortcut, use the new Do Not Highlight as New setting in the Shortcuts view. Windows 7 and later include support for this shortcut setting. Previously, InstallShield did not have support for configuring this functionality in InstallScript projects.

The automation interface includes support for specifying whether you want a shortcut to be highlighted on the Start menu as new after end users install the product. The ISWiShortcut object includes a new read-write Boolean DoNotHighlightAsNew property that indicates whether you want to prevent the highlighting.

To learn more, see:

Preventing a Shortcut on the Start Menu from Being Highlighted as Newly Installed
Shortcuts View
ISWiShortcut Object

Built-in Support for Configuring Additional Windows Shell Properties for a Shortcut

InstallShield lets you specify one or more additional shortcut properties that need to be set by the Windows Shell at run time. The properties that the Shell can set are defined in propkey.h, which is part of the Windows SDK.

To configure additional properties for a shortcut, use the Shell Properties setting for a shortcut in the Shortcuts view. This setting has a new Custom Property option that lets you specify additional properties and their corresponding values for the selected shortcut.

Windows Installer 5 includes support for configuring Shell properties.

The automation interface includes a new ISWiShellProperty object for custom Windows Shell properties for a shortcut. In addition, the ISWiShortcut object includes two new methods and a collection that let you add a Shell property (AddShellProperty), delete a Shell property (DeleteShellProperty), and retrieve the collection of Shell properties (ISWiShellProperties) for a shortcut.

This support is available in the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.

To learn more, see:

Setting Custom Shell Properties
Shortcuts View
ISWiShellProperty Object
AddShellProperty Method
DeleteShellProperty Method
ISWiShellProperties Collection
ISWiShortcut Object

InstallScript Language Improvements for Setting a Shortcut Property, and for Other Shortcut Functionality

A new InstallScript function called SetShortcutProperty is available. You can use this function in your InstallScript code to set Windows Shell properties for a shortcut. The function lets you prevent end users from pinning a shortcut to the Windows 8 Start screen, prevent end users from pinning a shortcut to the taskbar or Start menu on Windows 7 or later systems, or prevent a shortcut on the Start menu from being highlighted as newly installed on Windows 7 or later systems. You can also use this function to specify additional Shell properties that are defined in propkey.h, which is part of the Windows SDK.

The InstallShield Cabinet and Log File Viewer has been updated to reflect the state of the aforementioned Shell properties.

To reflect the current operating system terminology, some of the existing shortcut functions have been renamed. Note that the old function names will continue to compile and run as they did with earlier versions of InstallShield. The new InstallScript functions are:

CreateShortcut—This function supersedes AddFolderIcon. CreateShortcut accepts the same parameters as AddFolderIcon but adds or replaces the following options for the nFlag parameter:
CS_OPTION_FLAG_REPLACE_EXISTING
CS_OPTION_FLAG_RUN_MAXIMIZED
CS_OPTION_FLAG_RUN_MINIMIZED
CS_OPTION_FLAG_PREVENT_PINNING
CS_OPTION_FLAG_NO_NEW_INSTALL_HIGHLIGHT
CS_OPTION_FLAG_NO_STARTSCREEN_PIN
CreateShortcutFolder—This function supersedes CreateProgramFolder. Both functions use the same parameters.
DeleteShortcut—This function supersedes DeleteFolderIcon. Both functions use the same parameters.
DeleteShortcutFolder—This function supersedes DeleteProgramFolder. Both functions use the same parameters.
GetShortcutInfo—This function supersedes QueryProgItem. Both functions use the same parameters.
ReplaceShortcut—This function supersedes ReplaceFolderIcon. ReplaceShortcut accepts the same parameters as ReplaceFolderIcon but adds or replaces the same options for the nFlag parameter as CreateShortcut.

For more details, see:

CreateShortcut
CreateShortcut Examples
CreateShortcutFolder
CreateShortcutFolder Example
DeleteShortcut
DeleteShortcut Example
DeleteShortcutFolder
DeleteShortcutFolder Example
GetShortcutInfo
GetShortcutInfo Example
ReplaceShortcut
ReplaceShortcut Example
SetShortcutProperty
SetShortcutProperty Example

Usability Improvements for Customizing the Wizard Interface in Advanced UI and Suite/Advanced UI Projects

No More Confusing Syntax Requirements

Various UI settings in the Wizard Interface view in Advanced UI and Suite/Advanced UI projects have been improved to make it much easier to customize the wizard interface of Advanced UI and Suite/Advanced UI installations. For example, the following settings, which are displayed when a wizard page or wizard control is selected in the Wizard Interface view, have been improved:

Visible—This setting lets you specify one or more conditions that the Advanced UI or Suite/Advanced UI installation should use to evaluate whether the selected page or control should be displayed.
Enabled—This setting lets you specify one or more conditions that the Advanced UI or Suite/Advanced UI installation should use to evaluate whether the selected control should be enabled.
Validate—This setting lets you specify one or more validation statements that the Advanced UI or Suite/Advanced UI installation should use to validate an end user’s response to a control. For example, you can use this setting to specify the format that end users should use for entering a serial number in a text box control.
Action—Each instance of this setting has been renamed to better reflect the specific type of trigger that is applicable to the selected control. For example, the Action setting for a list box control has been renamed Selection Changed. The Action setting for a button has been renamed Click. The renamed settings let you select one or more actions that you want to be triggered when an end user uses the selected control.

Now those settings contain drop-down lists and buttons that are similar to the ones that are available in other areas of Advanced UI and Suite/Advanced UI projects for quickly building conditional statements. These settings now make it easy to quickly configure visible/hidden status, enabled/disabled status, validation, and action responses for various parts of the UI, and to build conditional statements for that behavior if appropriate. Previously, these settings were edit fields that required manually entry of statements using a difficult-to-remember syntax.

For more information, see:

Configuring Validation for a Control on a Wizard Page or Window
Configuring an Action for an Element in the Wizard Interface
Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects

Built-In Support for Using Only One Background for the Header, Body, and Navigation Areas of the Wizard Interface

The Wizard Pages node in the Wizard Interface view has a new Full Wizard Background setting. This setting lets you specify a single background that you want to use across the header, body, and navigation areas of your wizard pages. Previously, the only built-in way to specify backgrounds in InstallShield was to use separate background styles in the Default Body Background, Header Background, and Navigation Background settings. If you wanted to use a single background across all three areas of the wizard interface, you had to use the process that was documented in an InstallTalk blog article; the process involved modifying the InstallShield project file (.issuite) in a text editor.

Note that if you select a background in this new Full Wizard Background setting, you should delete any values from the other background settings: Default Body Background, Header Background, and Navigation Background.

To learn more, see Specifying the Background Brush for the Header, Body, and Navigation Areas of the Wizard Interface.

Ability to Specify a Global Text Style for All Navigation Buttons

The Wizard Pages node in the Wizard Interface view has a new Navigation Text Style setting. This setting lets you select a single text style that you want to use for the text on all of the navigation buttons. You can override the global text style for individual navigation buttons as needed.

Logically Organized Setting Grids

In the Wizard Interface view, the setting grids for wizard pages, secondary windows, and wizard controls have been reorganized to make it easier to find the settings that are needed for customizing the wizard interface.

Support for Defining Font Sets with Optional Language-Specific Choices for Advanced UI and Suite/Advanced UI Projects

Advanced UI and Suite/Advanced UI projects have support for a new kind of wizard interface style: a font set. A font set is a collection of fonts (including attributes such as font name, size, and weight). For each font in a font set, you can specify to which language the font is applicable. This enables you to select a different font for each language that your project supports.

Font sets work in conjunction with text styles. Text styles, which are styles that define text attributes such as text color and alignment, now reference a font set but can optionally override various font attributes that are defined at the font set level.

Thus, for example, when you are specifying font information for the body text of your wizard interface, you can use a font set called BodyFonts, and specify a different font for each of the languages that your project supports. You can then select the BodyFonts font set for various text styles—Body, Header, and BodyBold—but with special overrides for smaller sizes and bold where necessary. This enables you to specify a large set of possible fonts once, and change attributes such as text size or color for specific wizard interface uses.

To learn more, see:

Using Styles, Brushes, and Control Themes to Customize the Wizard Interface
Defining a Custom Style for the Wizard Interface

Enhancements

InstallShield includes the following enhancements.

New Services View

InstallShield has a new Services view—under the System Configuration node of the View List—that lets you specify the required information about a Windows service that you are installing, starting, configuring, stopping, or deleting at run time.

This new Services view has been added to make it easier for new users to configure services. The view provides the same functionality as the following existing areas:

The Services area under the Advanced Settings node for a component in the Setup Design view (of installation projects)
The Services area under the Advanced Settings node for a component in the Components view

If you configure service information in any of the three views (the Services view, the Setup Design view, or the Components view), the other views are updated automatically.

The Services view is available in the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.

For more information, see:

Installing, Controlling, and Configuring Windows Services
Services View

New Wizard Format for the Suite/Advanced UI and Advanced UI Wizard Interface

A new Glass wizard format is available for the wizard interface of Suite/Advanced UI and Advanced UI installations. This new format is similar to the existing Aero format. For both formats, the installation uses user-chosen system colors (instead of brush styles that you defined in your project) to display the caption bar, header, and navigation areas of the wizard interface. It also may use the glass effect (translucency) for these same areas of the wizard interface on target systems that have the translucency support that was introduced in Windows Vista.

In some scenarios, an installation uses the Wizard 97 format instead of the Glass or Aero formats:

Windows 8 and Windows Server 2012 systems do not have translucency support. On these systems, a Glass-formatted wizard interface uses the Wizard 97 format. However, an Aero-formatted wizard interface uses Aero (which includes user-chosen system colors), but without the glass effect.
Windows 7, Windows Vista, Windows Server 2008 R2, and Windows Server 2008 have translucency support that end users can enable or disable. On these systems, Glass-formatted wizard interfaces and Aero-formatted wizard interfaces use the Wizard 97 format if translucency is disabled. These wizard interfaces also use the Wizard 97 format if the desktop composition feature on the target system is disabled.
On Windows XP and Windows Server 2003, Glass-formatted wizard interfaces and Aero-formatted wizard interfaces use the Wizard 97 format.

To configure the format, use the Wizard Format setting that is displayed in the Wizard Interface view when the Wizard Pages node is selected. The Glass format is the default option for all new Suite/Advanced UI and Advanced UI projects.

For more information, see Selecting the Format for the Wizard Interface.

Automation Interface Enhancement: New OnUpgrade Property for Minor Upgrades and Small Updates

A new read-write OnUpgrade property has been added to the ISWiProject object in the automation interface. You can set this property to one of the supported values to specify whether you want the installation to display a prompt before installing a minor upgrade or a small update.

This property corresponds with the Small/Minor Upgrade Settings options on the Common tab in the Upgrades view.

For more information, see ISWiProject Object.

See Also