What’s New in InstallShield 2012 Spring
InstallShield 2020
New Features
InstallShield includes the following new features.
Ability to Target Windows 8 and Windows Server 2012 Systems
InstallShield enables you to specify that your installation requires Windows 8 or Windows Server 2012. It also lets you build feature and component conditions for these operating systems.
The InstallShield prerequisites that should be installable on Windows 8 and Windows Server 2012 have been updated so that they are installed on those systems if needed. Previously, the prerequisites were not run by default on those systems. This applies to the following InstallShield prerequisites:
| • | FSharp Redistributable Package 2.0 |
| • | Microsoft ReportViewer 2010 |
| • | Microsoft SQL CE 3.5 SP2 |
| • | Microsoft SQL Server 2005 Express SP3 |
| • | Microsoft SQL Server 2008 Express SP1 |
| • | Microsoft SQL Server 2008 Management Objects 10.00.2531 |
| • | Microsoft SQL Server 2008 Native Client 10.00.2531 |
| • | Microsoft SQL Server 2008 R2 Express RTM |
| • | Microsoft SQL Server 2008 R2 Native Client 10.50.1600.1 |
| • | Microsoft SQL Server Native Client 9.00.4035 |
| • | Microsoft SQL Server System CLR Types 10.00.2531 |
| • | Microsoft Visual C++ 2005 SP1 Redistributable MFC Security Update KB2538242 |
| • | Microsoft Visual C++ 2005 SP1 Redistributable Package |
| • | Microsoft Visual C++ 2008 SP1 Redistributable MFC Security Update KB2538243 |
| • | Microsoft Visual C++ 2008 SP1 Redistributable Package |
| • | Microsoft Visual C++ 2010 Redistributable Package |
| • | Microsoft Visual C++ 2010 RTM Redistributable MFC Security Update KB2467173 |
| • | Microsoft Visual C++ 2010 SP1 Redistributable Package |
| • | Microsoft VSTO 2010 Runtime |
Support for a New Contemporary, Customizable End-User Interface in InstallShield Professional Edition
The new Advanced UI project type lets you create a new end-user interface, with redesigned, contemporary wizard pages, for a Windows Installer package or an InstallScript package. This new project type is available in the Professional edition of InstallShield, and it is based on the technology that was previously introduced as the Suite project type (now known as the Suite/Advanced UI project type) in the Premier edition of InstallShield.
The new Advanced UI project type includes built-in wizard pages that you can include and customize in your Advanced UI installations. The 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. All of the new UI functionality that was previously available only through the Premier edition is now available through Advanced UI projects.
Like Suite/Advanced UI projects, an Advanced UI project uses the next-generation setup launcher (Setup.exe) for launching a package on target systems. Also like Suite/Advanced UI projects, an Advanced UI project includes flexible options for specifying the run-time source location of the package that you are including in the Advanced UI installation. The available location 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 Advanced UI source media |
Your end users can quickly download a small Advanced UI Setup.exe file, and the Setup.exe file can download and launch the Windows Installer–based or InstallScript package if needed.
Note that the Advanced UI project type includes support for including only one primary .msi package, one primary .msp package, or one primary InstallScript package. The Suite/Advanced UI project type that is available in the Premier edition of InstallShield includes support for packaging multiple primary installations (including .exe packages) as a single installation.
To learn more, see the following:
| • | Creating Advanced UI and Suite/Advanced UI Installations |
| • | Advanced UI Projects vs. Suite/Advanced UI Projects |
| • | Adding an .msi Package, an .msp Patch, or a Transaction to an Advanced UI or Suite/Advanced UI Project |
| • | Working with the Wizard Interface |
Microsoft Windows Azure SQL Database Support
InstallShield now includes support for running SQL scripts on Microsoft Windows Azure SQL database servers. In addition, InstallShield includes Microsoft Windows Azure 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.
If your installation targets Windows Azure, the SQLBrowse run-time dialog that is displayed when end users choose to browse for a database catalog can now list catalogs on the specified SQL database server.
This support is available in the following project types: Basic MSI, DIM, InstallScript, and InstallScript MSI.
To learn more, see:
| • | Connecting to a Microsoft Windows Azure Database Server and Running SQL Scripts |
| • | Configuring SQL Support |
| • | SQL Scripts View |
This support is available in the following project types: Basic MSI, DIM, InstallScript, and InstallScript MSI.
Beta Support for Microsoft Visual Studio 2012
InstallShield includes support for the beta of Visual Studio 2012. You can create InstallShield projects from within this version of Visual Studio.
Microsoft .NET Framework 4.5 Prerequisites
InstallShield includes two new .NET-related InstallShield prerequisites that you can add to Basic MSI, InstallScript, and InstallScript MSI projects:
| • | Microsoft .NET Framework 4.5 Full |
| • | Microsoft .NET Framework 4.5 Web |
These InstallShield prerequisites install the beta versions of the .NET Framework 4.5 on supported target systems.
The Web prerequisite requires an Internet connection. This prerequisite downloads the required redistributable files if appropriate. The full prerequisite is a stand-alone installation that does not require an Internet connection.
Microsoft SQL Server 2012 Support
InstallShield now includes support for running SQL scripts on SQL Server 2012 database servers. In addition, InstallShield includes SQL Server 2012 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.
If your installation targets SQL Server 2012, the SQLBrowse run-time dialog that is displayed when end users choose to browse for a database server can now list instances of SQL Server 2012, SQL Server 2012 Express, and SQL Server 2012 Express LocalDB. In addition, the SQLBrowse run-time dialog that is displayed when end users choose to browse for a database catalog can now list catalogs on the specified SQL Server 2012 database server.
To learn more, see:
| • | Requirements for Connecting to Instances of SQL Server Express LocalDB |
| • | Configuring SQL Support |
| • | SQL Scripts View |
This support is available in the following project types: Basic MSI, DIM, InstallScript, and InstallScript MSI.
Microsoft SQL Server 2012 Prerequisites
InstallShield includes several new SQL Server 2012–related InstallShield prerequisites that you can add to Basic MSI, InstallScript, and InstallScript MSI projects:
| • | Microsoft SQL Server 2012 Express |
| • | Microsoft SQL Server 2012 Express LocalDB |
| • | Microsoft SQL Server 2012 Native Client |
InstallShield also includes InstallShield prerequisites that install Microsoft .NET Framework 3.5 SP1 Update KB956250, which is a dependency of Microsoft SQL Server 2012 Express.
These InstallShield prerequisites install the technology on supported target systems.
New InstallShield Prerequisites for App-V 4.6 SP1, SQL Server Compact 4.0, and JRE SE 1.7
InstallShield includes new InstallShield prerequisites that you can add to Basic MSI, InstallScript, and InstallScript MSI projects:
| • | Java Runtime Environment Second Edition (JRE SE) 1.7 |
| • | Microsoft App-V 4.6 SP1 Desktop Client (The redistributable files for these InstallShield prerequisites—available in 32-bit and 64-bit versions—are not available for download from within InstallShield, since you must obtain them from Microsoft. Once you obtain them from Microsoft, place them in the location that is displayed when you are editing these prerequisites in the InstallShield Prerequisite Editor.) |
| • | SQL Server Compact 4.0 |
These InstallShield prerequisites install the technology on supported target systems.
Support for the Configuring System Center 2012 Configuration Manager Application Model Data
Accurate identification of deployment metadata is necessary for migrating applications into the System Center 2012 Configuration Manager application model. InstallShield includes several new settings in the General Information view that let you specify some of the application model metadata for an application through a software identification tag. When AdminStudio users import a package into the AdminStudio Application Catalog, AdminStudio Application Manager mines package elements for deployment data such as detection methods, dependencies, requirements, as well as information in the software identification tag. AdminStudio makes this information available to users for review and tests before publishing to Microsoft System Center 2012 Configuration Manager.
This feature is available in Basic MSI projects.
To learn more, see Including Microsoft System Center Configuration Manager Application Model Data About Your Product.
Support for PowerShell Custom Actions
Windows PowerShell is a .NET Framework–based command-line shell and script language that enables system administrators to automate system configuration tasks. InstallShield now has support for custom actions that run PowerShell scripts. You may want to add this type of custom action to a project to perform system configuration tasks at installation run time.
Note that in order for an installation to run a PowerShell custom action, Windows PowerShell must be installed on target systems. InstallShield includes a new predefined PowerShell system search that checks for the presence of PowerShell on target systems. You can include this system search in your project and configure your PowerShell custom action to run only if the system search determines that PowerShell is installed.
The PowerShell execution policy, which determines whether PowerShell scripts can be run on a target system, is set to restricted by default, which does not permit PowerShell scripts to be run. If you want your installation to override the target system’s execution policy with an appropriate one for your installation’s PowerShell custom actions, you can use the new Windows Installer property IS_PS_EXECUTIONPOLICY to indicate the appropriate execution policy.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
To learn more, see Calling a PowerShell Custom Action.
Automatic Update Check and Download Support for Suite/Advanced UI and Advanced UI Installations
Suite/Advanced UI and Advanced UI installations now have the ability to automatically check for an updated Suite/Advanced UI or Advanced UI Setup.exe file that you host on your Web site, and download and launch it if it is available. The updated Suite/Advanced UI or Advanced UI Setup.exe file can be used to deploy upgrades and patches for your latest Suite/Advanced UI and Advanced UI packages.
The Update tab in the Releases view of Suite/Advanced UI and Advanced UI projects has a new Update URL setting that lets you specify the absolute path (including the file name) for an updated Suite/Advanced UI or Advanced UI setup launcher. If the base Suite/Advanced UI or Advanced UI setup launcher is running a non-maintenance operation, the Suite/Advanced UI or Advanced UI setup launcher checks the update URL for a download. If a download is available, the base Suite/Advanced UI or Advanced UI setup launcher downloads it and then verifies its digital signature. If the digital signature in the update setup launcher matches that in the base setup launcher, the update setup launcher runs automatically. If the digital signature does not match, or if the base setup launcher is not digitally signed, a security warning is displayed, allowing the end user to choose whether to proceed with the update setup launcher.
To learn more, see Supporting Downloadable Updates for an Advanced UI or Suite/Advanced UI Installation.
Ability to Detect Whether a Specific Version of a Suite/Advanced UI or Advanced UI Installation Is Already Installed
Suite/Advanced UI and Advanced UI projects now include support for determining whether a particular version of a Suite/Advanced UI or Advanced UI installation is already installed on target systems. This type of condition check is called a Suite Installed condition.
InstallShield now includes two Suite Installed conditions in each Suite/Advanced UI and Advanced UI project by default:
| • | A new Suite Installed exit condition prevents end users from being able to install the current version of the Suite/Advanced UI or Advanced UI installation over a future newer version of the same Suite/Advanced UI or Advanced UI installation. |
| • | A new Suite Installed mode condition may prevent the installation from running in first-time installation mode if the same version of the Suite/Advanced UI or Advanced UI installation is already installed. |
These new default conditions are available in all new Suite/Advanced UI and Advanced UI projects. If you upgrade an InstallShield 2012 Suite project to InstallShield 2020, InstallShield automatically adds these default conditions to the project.
You can edit the default Suite Installed conditions if necessary. You can also add your own Suite Installed conditions to a project as needed.
For more information, see:
| • | Detecting Whether a Specific Version of an Advanced UI or Suite/Advanced UI Installation Is Already Installed |
| • | Triggering Install Mode or Maintenance Mode of an Advanced UI or Suite/Advanced UI Installation |
| • | Suite Installed Condition Settings |
| • | Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects |
Ability to Configure Network Sharing of Folders in an Installation
InstallShield now lets you create, modify, and delete network shares to enable file sharing over networks. When you are configuring a folder in your project, you can indicate that you want to enable network sharing, which is disabled by default. You can also configure other options such as the name of the share, as well as the maximum number of simultaneous users who can access the share.
To enable sharing, use the new Sharing tab on the Properties dialog box, which is displayed when you right-click a folder in the Files and Folders view and then click Properties.
This feature is available in the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, and MSM Database.
For more information, see Folder Properties Dialog Box.
New Built-In Custom Action that Terminates Specific Processes
InstallShield includes support for a new kill-process type of custom action. If you add this type of custom action to your project, you can specify the name or process identifier (PID) of one or more processes that you want to be terminated at run time, and you can schedule the custom action for immediate or deferred mode.
The procedure for creating this type of custom action involves adding and configuring the custom action in the Custom Actions and Sequences view of your project, and using the Property Manager view to define a property with the names or PIDs of the appropriate processes.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
For detailed instructions, see Calling a Kill-Process Custom Action.
Ability to Create Predetermined User Accounts and Groups at Run Time
InstallShield now has built-in support for creating multiple user accounts and corresponding groups at run time without using logon dialogs. To configure the accounts and groups, define values for the properties ISNetApiLogonUsername, ISNetApiLogonGroup, and ISNetApiLogonPassword in your project with the user names, groups, and passwords, respectively. Separate multiple names, groups, or passwords with a tilde enclosed by square brackets: [~].
This feature is available in the following project types: Basic MSI and InstallScript MSI.
To learn more, see Creating Predetermined User Accounts at Run Time.
Ability to Include InstallShield Prerequisites as Packages in Suite/Advanced UI and Advanced UI Projects
InstallShield now lets you import InstallShield prerequisites as .msi and .exe packages into Suite/Advanced UI and Advanced UI projects. You can import the InstallShield prerequisites that are included with InstallShield, as well as any custom InstallShield prerequisites that you have created. When you right-click the Packages explorer in the Packages view and then click the new Import Prerequisite (.prq) command, InstallShield adds to your project an .msi package or an .exe package, depending on the type of file that is configured to run for the prerequisite. InstallShield also automatically configures default values for each of the prerequisite package’s settings, based on the settings that are configured in the .prq file. You can change these settings as needed, just as you can change the settings for packages in your Suite/Advanced UI or Advanced UI project.
If an InstallShield prerequisite has dependencies (that is, if one or more other .prq files are specified as dependencies in the InstallShield prerequisite that you are adding to the Suite/Advanced UI or Advanced UI project), InstallShield automatically adds the dependency prerequisites as separate packages in the Packages explorer.
Previously it was necessary to add the .msi and .exe installations as packages in a Suite project and then manually configure all of the conditions and settings for each of those packages.
For more information, see Including InstallShield Prerequisites (.prq) in an Advanced UI or Suite/Advanced UI Project.
Ability to Include InstallScript Installations as Packages in Suite/Advanced UI and Advanced UI Projects; New Suite/Advanced UI– and Advanced UI–Specific InstallScript Events and Functions
InstallShield now lets you add InstallScript installations as packages in Suite/Advanced UI and Advanced UI projects. When a Suite/Advanced UI or Advanced UI installation launches an InstallScript package, the Suite/Advanced UI or Advanced UI installation displays its own user interface (UI) while automatically suppressing the UI of the InstallScript package. This enables you to provide a contemporary UI experience for the installation. The Suite/Advanced UI or Advanced UI installation also displays progress information for the InstallScript package.
To make these changes possible, Suite/Advanced UI and Advanced UI installations use several new Suite/Advanced UI– and Advanced UI–specific InstallScript events and functions by default, and ignores some of the standard InstallScript events and functions.
New InstallScript Package Support in Suite/Advanced UI and Advanced UI Projects
InstallShield lets you add an InstallScript package to a Suite/Advanced UI or Advanced UI project if the InstallScript package meets the following requirements:
| • | The InstallScript package is uncompressed. |
| • | InstallShield 2012 Spring or later is used to build the InstallScript package and the Suite/Advanced UI or Advanced UI installation. |
| • | The InstallScript package uses an event-based script; it should not use the program...endprogram style script. |
For more information, see Adding an InstallScript Package to an Advanced UI or Suite/Advanced UI Project.
New Suite/Advanced UI– and Advanced UI–Specific InstallScript Events and Functions
In a standard InstallScript installation that is launched via the InstallScript Setup.exe file (that is, not launched from a Suite/Advanced UI or Advanced UI installation), most events are called directly from the OnShowUI event. In a Suite/Advanced UI or Advanced UI installation that launches an InstallScript package, OnShowUI is replaced with OnSuiteShowUI. Depending on the installation state (first-time installation, maintenance, or update), OnSuiteShowUI ignores the UI events such as OnFirstUIBefore and OnFirstUIAfter and instead calls the following events:
| • | First-time installation—OnSuiteInstallBefore, OnSuiteInstallAfter |
| • | Maintenance—OnSuiteMaintBefore, OnSuiteMaintAfter |
| • | Update—OnSuiteUpdateBefore, OnSuiteUpdateAfter |
The InstallScript language includes some new Suite/Advanced UI– and Advanced UI–specific functions that enable interaction between an InstallScript package and the Suite/Advanced UI installation or the Advanced UI installation that is running it. For example, InstallScript includes new functions that let you log InstallScript package information to Suite/Advanced UI and Advanced UI debug logs, set and retrieve Suite/Advanced UI and Advanced UI properties, and pass data from Suite/Advanced UI and Advanced UI installations to the InstallScript package.
To determine whether the InstallScript installation is running as an InstallScript package in a Suite/Advanced UI or Advanced UI installation, use the new SUITE_HOSTED variable in your InstallScript code.
New InstallScript Package Type of Condition Check in 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, you can select from a number of different types of checks that you want to be evaluated on target systems. Use the new InstallScript package type of condition check to check target systems for the presence of a product that was installed by a particular InstallScript installation. The condition checks for a particular product code, and it can also check other information, such as the product version.
To learn more, see the following:
| • | Types of Condition Checks in Advanced UI and Suite/Advanced UI Projects |
| • | InstallScript Package Condition Settings |
| • | Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects |
Dynamic File Link Support for Package Files in Suite/Advanced UI and Advanced UI Projects
When you are adding or configuring an .msi, .msp, or .exe package in an Advanced UI or Suite/Advanced UI project, you can indicate whether the package requires additional files that are located near the package file. For example, if a package that you are adding is an uncompressed .msi package, you may need to include other files—such as .cab files and uncompressed data files in nearby subfolders—along with the package file.
InstallShield now lets you use dynamic links for the additional package files. Dynamic links are useful if the list of additional files that the package requires is likely to change between builds. InstallShield scans the source folder before every build and automatically incorporates any new or changed package files in your release.
InstallShield also lets you define filters that control which additional files InstallShield should include in the dynamic link at build time, and which ones InstallShield should exclude. You can change the order in which InstallShield evaluates any filter criteria that you have defined for a dynamic link. Each time that you build your Advanced UI or Suite/Advanced UI installation, InstallShield includes the appropriate additional files based on the dynamic link’s filters.
Previously, only static links could be used for additional files. If the list of additional files changed between builds, it was necessary to manually update the list of package files.
For more information, see:
| • | Static vs. Dynamic Files for Packages in an Advanced UI or Suite/Advanced UI Project |
| • | Creating a Dynamic Link in an Advanced UI or Suite/Advanced UI Project |
| • | Defining Filters for a Dynamically Linked Folder in an Advanced UI or Suite/Advanced UI Project |
Ability to Give Enhanced Feedback When Validating End-User Input During a Suite/Advanced UI or Advanced UI Installation
Suite/Advanced UI and Advanced UI installations now have support for providing enhanced feedback when validating end-user input at run time. Various interface controls in the Wizard Interface view of a Suite/Advanced UI project and an Advanced UI project have three new subsettings under the existing Text Style setting: Default, Valid, and Invalid. You can configure these subsettings to select different text styles that you want the Suite/Advanced UI or Advanced UI installation to use under different circumstances.
Support for Creating Package Log Files When Launching a Suite/Advanced UI or Advanced UI Installation from the Command Line
When you are configuring the settings for a package in a Suite/Advanced UI or Advanced UI project, you can use the new Enable Logging Support setting to specify whether you want the package to generate a log file if the Suite/Advanced UI or Advanced UI installation is launched from the command line with the new /log command-line parameter. Depending on the type of package (.msi package, .msp package, or some other type of package), you can also configure one or two other settings to specify information such as which log options you want the Suite/Advanced UI or Advanced UI installation to pass to the package when the log file is being created.
The new /log command-line parameter for the Suite/Advanced UI or Advanced UI Setup.exe file lets you specify the path to the directory that contains the package log files. If a path is not specified with the /log parameter, the Suite/Advanced UI or Advanced UI installation creates the package log files in the %TEMP% directory.
The new property ISLogDir in Suite/Advanced UI and Advanced UI installations stores the path to that directory that contains the package log files.
Previously, the only way to enable logging for a Windows Installer–based package in a Suite installation was to use the logging system policy or the MsiLogging property.
For more information, see:
| • | Supporting the Creation of Package Log Files for Command-Line Launching of an Advanced UI or Suite/Advanced UI Installation |
| • | Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters |
| • | Advanced UI and Suite/Advanced UI Property Reference |
Support for 64-Bit Components in InstallScript Installations
InstallScript projects now have support for installing files to WINSYSDIR64 (the InstallScript variable that maps to the 64-bit System32 folder), and for installing registry data to the 64-bit registry locations, without requiring you to modify your InstallScript code. If you have files or registry data that need to be installed to these 64-bit locations, you can add the files and registry data to a component, and select Yes for that component’s new 64-Bit Component setting. At run time, the installation automatically disables file system redirection for the component’s System32 files, and it prevents redirection for the component’s 64-bit registry data.
Previously, to install files to WINSYSDIR64, it was necessary to override the Installing and Installed events for features that contained components that installed to that location. In the Installing event, it was necessary to use the WOW64FSREDIRECTION constant with the Disable function to disable file system redirection; in the Installed event, it was necessary to use WOW64FSREDIRECTION with the Enable function to re-enable file system redirection for other parts of the installation. The same sort of disabling and enabling was necessary for the UnInstalling and UnInstalled events to ensure that those files were removed correctly during uninstallation.
If file system redirection is not disabled when an InstallScript installation installs to WINSYSDIR64, 64-bit Windows automatically redirects the file transfers to the 32-bit System32 folder (SysWOW64).
Also previously, to install registry data to a 64-bit area of the registry, it was necessary to use the InstallScript registry functions to create registry data with REGDB_OPTION_WOW64_64KEY set in REGDB_OPTIONS. Then it was necessary to use REGDB_OPTION_USE_DEFAULT_OPTIONS with REGDB_OPTIONS to re-enable registry redirection for other parts of the installation.
If registry redirection is not disabled when an InstallScript installation installs to a 64-bit registry location (HKEY_LOCAL_MACHINE\Software), 64-bit Windows automatically redirects the registry changes to the equivalent 32-bit registry location (HKEY_LOCAL_MACHINE\Software\Wow6432Node).
The InstallScript log files (.ilg) that InstallScript installations create at run time when installing a product now use a new OPTYPE_FILE64 type to identify files that are installed when file system redirection is disabled. The InstallScript log files use the existing OPTYPE_REGISTRY64 type to identify registry data that are installed when registry redirection is disabled. You can see these OPTYPE_FILE64 and OPTYPE_REGISTRY64 types when viewing an .ilg file in the InstallShield Cabinet and Log File Viewer.
For more information, see the following:
| • | Targeting 64-Bit Operating Systems with InstallScript Installations |
| • | Component Settings |
| • | WINSYSDIR64 |
| • | REGDB_OPTIONS |
| • | InstallShield Cabinet and Log File Viewer |
New Locale Type of Condition Check in 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, you can select from a number of different types of checks that you want to be evaluated on target systems. Use the new locale type of condition check to check for matching one or more locale-related settings on target systems.
To learn more, see:
| • | Using Locale Conditions in Advanced UI and Suite/Advanced UI Projects |
| • | Types of Condition Checks in Advanced UI and Suite/Advanced UI Projects |
| • | Locale Condition Settings |
| • | Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects |
New Wizard Interface Toolbar for Editing the Layout in Suite/Advanced UI and Advanced UI Projects, with Support for Switching Languages in Suite/Advanced UI Projects
If you select a wizard page or secondary window in the Wizard Interface view of a Suite/Advanced UI project, the toolbar that InstallShield shows directly above the wizard interface preview pane includes several different buttons and other controls that let you modify the layout of the selected page or window. InstallShield also displays this toolbar in the Wizard Interface view if you select one or more controls on a wizard page or a secondary window.
The new toolbar has buttons that let you add labels, text boxes, check boxes, and other controls to the installation’s user interface. The toolbar also has buttons that let you easily align selected controls, resize them, and position them in relation to each other. In Suite/Advanced UI projects, the Default Languages list in the new toolbar enables you to switch the strings that InstallShield displays on the wizard pages and secondary windows in this view to those in a different language in your project.
For more information, see:
| • | Adding a Control to a Wizard Page or Secondary Window |
| • | Wizard Interface View Toolbar |
Support for Adding Languages to Suite/Advanced UI Projects
The InstallShield Premier edition includes default run-time strings in 35 supported languages. When you add a supported language to a Suite/Advanced UI project, that language is made available in various language-related settings throughout InstallShield. In addition, InstallShield adds translated string entries for that language to your project. The string entries are for the default wizard pages, messages, and other end-user interface elements.
InstallShield now lets you add unsupported languages, beyond the built-in 35 languages, to Suite/Advanced UI projects through the New Language Wizard. An unsupported language is one in which none of the default run-time strings are translated. When you add an unsupported language to a Suite/Advanced UI project, that language is made available in various language-related settings throughout the project. In addition, InstallShield uses the strings from your project’s default language as placeholders for the strings in that newly added unsupported language; you can use the String Editor view to provide translated strings for the unsupported languages.
To launch the New Language Wizard in a Suite/Advanced UI project, on the Tools menu, click Add New Language.
To learn more, see the following:
| • | New Language Wizard |
| • | Run-Time Language Support in InstallShield |
Ability to Create and Configure Scheduled Tasks on Target Systems at Run Time
InstallShield has a new Scheduled Tasks view that lets you configure one or more tasks that you want to be created through the Windows task scheduler at run time on target systems. The view lets you specify information such as the file that you want to be launched for a task, as well as the start date and time. The file that you want to be launched can be part of your installation, or it can be a file that is already present on target systems.
This feature is available in the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, Transform.
For more information, see:
| • | Scheduling Tasks |
| • | Scheduled Tasks View |
New FlexNet Connect 13.03 Redistributables Available
InstallShield includes support for FlexNet Connect 13.03 in Basic MSI and InstallScript MSI projects. Use the Update Notifications view in InstallShield to include one of the two FlexNet Connect 13.03 merge modules—one has the Common Software Manager, and the other does not.
Enhancements
InstallShield includes the following enhancements.
Enhancements to the InstallScript Language for Operating Systems
The following structure members and predefined constants were added to the InstallScript language:
| • | SYSINFO.WINNT.bWin8—This is a new SYSINFO structure member. If the operating system is Windows 8 or Windows Server 2012, this value is TRUE. |
| • | ISOSL_WIN8—This is a new predefined constant that is available for use with the FeatureFilterOS function and the SYSINFO structure variable. It indicates that the target system is running Windows 8 or Windows Server 2012. |
For more information, see FeatureFilterOS function and the SYSINFO structure variable.
Automation Interface Enhancement: OSFilter Property Value for Windows 8 and Windows Server 2012
The following constants are now available for use with the OSFilter member of the ISWiComponent and ISWiRelease objects in the automation interface:
eosWin8 = &H4000000 (67108864)—These are for Windows 8 and Windows Server 2012.
In addition, the value for the eosAll constant is now &7D100D0 (131137744); previously, it was &3D100D0 (64028880).
The OSFilter member applies to the ISWiComponent object in InstallScript, InstallScript MSI, and InstallScript Object projects. The OSFilter member applies to the ISWiRelease object in InstallScript and InstallScript Object projects.
For more information, see the following:
| • | ISWiComponent Object |
| • | ISWiRelease Object |
Ability to Easily Move Conditions in Suite/Advanced UI and Advanced UI Projects
When you have more than one conditional statement for an exit, detection, eligibility, or feature condition in a Suite/Advanced UI or Advanced UI project, you now can move the conditional statements to reorder conditions or change the hierarchy of a condition tree. For example, if you have a platform conditional statement in a None condition group, and the None condition group is in an All condition group, you can move the platform conditional statement left, so that it is only part of the All condition group.
To move a conditional statement or group, click the new Move Condition button in the setting of the item that you want to move, and then click the appropriate option (Move Up, Move Down, Move Left, or Move Right).
Previously, it was necessary to manually create the new conditional statement in the new location and delete the one in the old location. Or, as an alternative, you could edit the .issuite file in a text editor and change the order of the conditional statements.
For more information, see Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects.
New Extension Condition Support and Enhanced Condition Settings in Suite/Advanced UI and Advanced UI Projects
In Suite/Advanced UI and Advanced UI projects, new extension condition functionality is available. This type of condition lets you browse to a C/C++ DLL that you have created to check for your own custom conditions on target systems.
In addition, many of the condition-related settings that are available in Suite/Advanced UI and Advanced UI projects have been enhanced to make it easier to build conditional statements. For example, instead of manually trying to enter a product code, upgrade code, patch code, or other various types of data in any one of several of the condition settings, you can now click a new ellipsis button (...) in the setting; when you do this, InstallShield displays a browse dialog box that lets you browse to and select the appropriate package. Once you have selected a package, InstallShield enters the appropriate information from that package in the setting of the Suite/Advanced UI or Advanced UI project.
When you are configuring an eligible package condition, you can now select from a list of packages in your Suite/Advanced UI or Advanced UI project instead of having to manually enter the package GUID of the appropriate package.
For more information, see:
| • | Creating a Custom Condition for an Advanced UI or Suite/Advanced UI Installation |
| • | Creating an Extension Condition DLL for an Advanced UI or Suite/Advanced UI Project |
| • | Adding an Extension Condition DLL to an Advanced UI or Suite/Advanced UI Project |
| • | Extension Condition Settings |
Enhancements for Configuring Validation and Actions for a Control on a Wizard Page or Window in Suite/Advanced UI and Advanced UI Projects
In Suite/Advanced UI and Advanced UI projects, the Validation and Action settings for various controls on the wizard interface have been enhanced to make it easier to define validation and trigger various actions. These settings now contain drop-down lists of sample statements that you can enter in these settings; these settings are also still text boxes that let you enter statements manually. For example, the Validation setting lets you specify a format that end users must match when they enter a serial number in a control. As an alternative to manually entering the entire validation statement, you can now select the mask type of validation in the Validation setting and then override the default format in the setting.
Similarly, the Action setting lets you define—for example—a print action for a button control; when an end user clicks the Print button, the Print dialog box opens, enabling the end user to print the license agreement. As an alternative to manually entering the action statement, you can now select the print action in the Action setting and then override the file name with the name of the file that you want to be printed.
The drop-down lists in the Validation and Action settings also now include C/C++ DLL files that you have created and added to your project through the Support Files view. This functionality lets you trigger your own validation or your own action for various controls on the wizard interface.
To learn more, see:
| • | Configuring Validation for a Control on a Wizard Page or Window |
| • | Configuring an Action for an Element in the Wizard Interface |
Ability to Use Custom Folder Names for Packages in Suite/Advanced UI and Advanced UI Releases
When you build an Suite/Advanced UI or Advanced UI installation, InstallShield creates a folder for each package that is included in the installation; these folders are created in the same folder that contains the Suite/Advanced UI or Advanced UI setup launcher. By default, the name of each folder is a GUID that InstallShield generates.
The Packages view in InstallShield now lets you override the GUID name with a user-friendly name for each package folder. To enter a custom folder name in this view, find a Package Files folder under the package whose folder name you want to customize. Right-click that folder, click Rename, and enter a new name. If you customize more than one folder name, ensure that each folder name is different.
Previously, InstallShield used a GUID for the name of each folder and did not have support for customizing the names.
For instructions, see Using Custom Folder Names for Packages in Advanced UI and Suite/Advanced UI Installations.
New Formatted Support for Properties Whose Values Reference Other Properties in Suite/Advanced UI and Advanced UI Projects
Each property that is defined in the Property Manager view in a Suite/Advanced UI or Advanced UI project has a new Formatted check box. This new check box lets you indicate whether you want the properties that are referenced in a property’s value to be resolved and replaced by their property values at run time.
To replace properties that are enclosed within square brackets (such as [PropertyName]) at run time, select this check box. To leave square brackets and the content within them as is, clear this check box.
For more information, see Property Manager View.
Improved Timing for UAC Prompts of Downloaded Packages that Require Elevation for Suite/Advanced UI and Advanced UI Installations that Have an Invoker Manifest
If you build an Advanced UI or Suite/Advanced UI release with an Invoker manifest, and if Yes is selected in the Require Elevated Privileges setting for any of the installation’s packages that need to be downloaded and launched on the target system, the installation triggers the UAC prompt soon after end users click the Install button—before the download occurs.
Previously, the installation triggered the UAC prompt after the download occurred. Thus, if package staging was slow (for example, if the package download took a long time), there could be a big gap between the moment that an end user clicked the Install button and the moment that Windows displayed the UAC prompt for elevation for the package. If an end user did not provide consent or credentials quickly enough, the UAC prompt timed out, and the installation failed.
In some previous cases, using an Administrator manifest was a possible workaround, since the UAC prompt was displayed soon after end users clicked the Install button. However, with this workaround, the entire installation had elevated privileges.
Support for Specifying the Alignment for Text in the Wizard Interface of Suite/Advanced UI and Advanced UI Installations
InstallShield has a number of built-in text styles that define text attributes such as color, size, and font name for the text on the wizard interface of Suite/Advanced UI and Advanced UI projects. You can edit any of the settings for these built-in styles or define your own styles, through the Wizard Interface view in your Advanced UI or Suite/Advanced UI project.
Each built-in or custom text style includes a new Text Alignment setting that lets you select the type of alignment that you want to use for the text in controls that use that particular style.
To learn more, see Using Styles, Brushes, and Control Themes to Customize the Wizard Interface.
Enhanced Combo Box Controls for the Wizard Interface of Suite/Advanced UI and Advanced UI Installations
InstallShield lets you add a combo box control to a wizard page or a secondary window in Suite/Advanced UI and Advanced UI projects. This type of control is a combination of two controls by default:
| • | A box that contains a drop-down list of predefined values |
| • | A text box that lets end users enter a custom value |
Previously, if you added a new combo box control, the control contained a drop-down list, but it was not also a text box; that is, end users could not enter a custom value.
To change this control to a drop-down list without the text box (that is, if end users should be able to select a predefined value but not enter a custom value), set the CBS_DROPDOWNLIST style for this control to True.
Enhancements and Changes to the Aero Format for the Suite/Advanced UI and Advanced UI Wizard Interface
Some enhancements and changes have been made to Aero-formatted wizard pages in Suite/Advanced UI and Advanced UI installations:
| • | The header and navigation areas of wizard pages are now displayed with the Aero glass effect, or translucency. Previously, only the caption bar of wizard pages were displayed with the Aero glass effect. |
| • | The Aero-formatted wizard pages now use the same layout as Wizard 97–formatted wizard pages. That is, the caption bar on Aero-formatted wizard pages is no longer extra tall; it is the same height as the caption bar on Wizard 97–formatted wizard pages. In addition, the Back button on Aero-formatted wizard pages is now displayed in the navigation area, which is consistent with the placement on Wizard 97–formatted wizard pages. Previously, the top-left corner of the caption bar in Aero-formatted wizard pages contained the Back button. |
Ability to Remove a String Value and Its Identifier from a Setting
When you are entering the value of a setting in one of the views in InstallShield and that value is a text string that can be presented to end users, InstallShield automatically uses a string identifier for that setting. InstallShield places the string identifier in curly brackets before the string value. These types of settings now contain a new Delete this string reference button.
If you want to remove the string identifier and its value from a setting, you can now click this new button. The button lets you clear the entry in the setting. Note that if you want to delete the string identifier and its value from your project, you must use the String Editor view.
See Also