InstallShield2020 UserGuide
InstallShield2020 UserGuide
User Guide
Legal Information
Book Name: InstallShield 2020 User Guide
Copyright Notice
Copyright © 2020 Flexera. All Rights Reserved.
This publication contains proprietary and confidential information and creative works owned by Flexera and its licensors, if any. Any use, copying,
publication, distribution, display, modification, or transmission of such publication in whole or in part in any form or by any means without the prior
express written permission of Flexera is strictly prohibited. Except where expressly provided by Flexera in writing, possession of this publication shall not
be construed to confer any license or rights under any Flexera intellectual property rights, whether by estoppel, implication, or otherwise.
All copies of the technology and related information, if allowed by Flexera, must display this notice of copyright and ownership in full.
Intellectual Property
For a list of trademarks and patents that are owned by Flexera, see https://www.flexera.com/producer/company/about/intellectual-property/. All other
brand and product names mentioned in Flexera products, product documentation, and marketing materials are the trademarks and registered
trademarks of their respective owners.
3 Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
InstallScript Project Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Step 1: Creating, Building, and Testing Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Creating a Project with the Project Assistant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Specifying Application Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Customizing the Installation Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Adding Files to Your Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Creating Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Configuring Registry Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Selecting Dialogs with the Installation Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Choosing a Language for Your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Building Your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Running Your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Working with the InstallShield Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Setting Feature Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Setting Setup Type Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Creating Components and File Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Building a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Naming the Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Selecting the Media Type and General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Specifying a Password and Supported Platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Specifying Setup Languages and Including Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Defining Media Layout and Dialog Appearance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Specifying Internet Options and Digitally Signing Your Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Specifying Update and Postbuild Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Reviewing Your Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Troubleshooting Your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Step 2: Shortcuts and Registry Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Creating Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Creating Registry Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Step 3: Registering COM Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Step 4: Conditions and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Step 5: Working with Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Step 6: Changing the User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Handling User Input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Changing the Dialogs Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Using the Dialog Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Basic MSI Project Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Step 1: Creating, Building, and Testing Your Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Creating a New Basic MSI Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Specifying Application Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Setting Installation Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Removing InstallShield Prerequisites from a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Removing Merge Modules and Objects from a Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Determining the Files in InstallShield Prerequisites, Merge Modules, and Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Working with InstallShield Prerequisites that Are Included in Installation Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Setup Prerequisites vs. Feature Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Associating an InstallShield Prerequisite with a Feature in a Basic MSI Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Disassociating an InstallShield Prerequisite from a Feature in a Basic MSI Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
Specifying the Installation Order of InstallShield Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Configuring a Release that Includes InstallShield Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Specifying the Directories that Contain InstallShield Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Specifying a Run-Time Location for a Specific InstallShield Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Assigning Release Flags to InstallShield Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Building a Release that Includes InstallShield Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Run-Time Behavior for an Installation that Includes InstallShield Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
Uninstalling an Application Whose Installation Included InstallShield Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Working with Merge Modules that Are Included in Installation Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Specifying the Directories that Contain Merge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Overriding a Merge Module’s Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Troubleshooting Merge Module Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Publishing a Merge Module to a Repository from Within an Installation Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Adding Windows Installer Redistributables to Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
Including Microsoft Windows Installer Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Adding .NET Framework Redistributables to Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
Including the Microsoft .NET Framework and Microsoft .NET Framework Language Pack Prerequisites . . . . . . . . . . . . . . . . 704
Including the MySQL Connector ODBC Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Including the InstallShield Prerequisite for the Oracle 11g Instant Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Including the DirectX 9.0 Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Identifying Application Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Static Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Dynamic Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Scanning for 64-Bit Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Reviewing Dependency Scanner Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Filtering Files in Dependency Scanners. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Registering COM Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Traditional COM Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Determining Whether a COM Server Supports Self-Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Extracting COM Information from a COM Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Filtering Registry Changes for COM Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
Self-Registering COM Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Self-Registration Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
InstallShield Self-Registration (ISSelfReg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Registry-Free COM Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Creating and Modifying Reg-Free COM Files for Your Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Sample Manifest File for a Reg-Free COM File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Including DIMs in a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Determining the Appropriate Method for Incorporating DIMs in Installation Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Referencing a DIM in a Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Associating a DIM Reference with a Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Resolving Build-Time Conflicts Between a Basic MSI Project and a DIM Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Viewing Build Instructions for a DIM Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Overriding the Destination for a DIM Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Scheduling Custom Actions and Dialogs from a DIM Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Opening a Referenced DIM Project from Within an Installation Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Importing a DIM into a Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Resolving Design-Time Conflicts While Importing a DIM Into a Basic MSI Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Identifying DIM Elements in an Installation Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Overriding Path Variables in a DIM Project for Use in an Installation Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
Configuring the Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Creating Shortcuts and Program Folders. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Types of Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Creating Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Configuring Shortcut Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
Specifying the Icon for a Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Creating Internet Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Creating Shortcuts to Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Specifying a Keyboard Shortcut for Accessing a Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Renaming Shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Setting Shell Properties for a Shortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Suppressing Initial Pinning of a Shortcut to the Windows 8 Start Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742
Specifying Whether End Users Should Be Able to Pin a Shortcut to the Taskbar or Start Menu . . . . . . . . . . . . . . . . . . . . . . . . . 744
Preventing a Shortcut on the Start Menu from Being Highlighted as Newly Installed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Setting Custom Shell Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Creating Uninstallation Shortcuts for Basic MSI Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Creating Uninstallation Shortcuts for InstallScript and InstallScript MSI Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Configuring the Appearance of a Desktop App’s Tile on the Start Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Editing the Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Filtering Registry Entries by Component or Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Refreshing the Registry View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Creating Registry Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Dragging and Dropping Registry Entries to Create Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
Removing Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Creating Registry Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Modifying Registry Value Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Removing Registry Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Registry Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 760
Searching for Registry Entries in a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Setting Uninstall Behavior for Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Using Environment Variables in Registry Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Writing Property Values to the Registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Importing Registry Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Exporting Registry Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Creating Custom Actions in the Custom Actions and Sequences View (or the Custom Actions View) . . . . . . . . . . . . . . . . . . . . 883
Cloning Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 884
Exporting Custom Actions to Other Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Configuring Custom Action Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885
Custom Action Type Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 886
Custom Action Return Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887
In-Script Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888
Documenting the Behavior of Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 890
Guidelines for Creating Custom Actions that Meet Requirements of the Windows Logo Program . . . . . . . . . . . . . . . . . . . . . . . 891
Conditionally Launching Custom Actions Based on Release Flags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 891
Placing Files in the .msi Database and Extracting Them During Run Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892
Accessing or Setting Windows Installer Properties Through Deferred, Commit, and Rollback Custom Actions . . . . . . . . . . . 894
InstallScript Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 895
Calling Functions in Standard DLL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896
Calling Functions in Windows Installer DLL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897
Passing Parameters to a DLL File Function in a Custom Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Calling a Public Method in a Managed Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 899
Run-Time Requirements for Managed-Code Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 900
Specifying the Signature for a Managed Method in an Assembly Custom Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 901
Using 32-Bit vs. 64-Bit Managed-Code Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 903
Calling a Kill-Process Custom Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904
Calling a PowerShell Custom Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905
Launching Executable Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 907
Using Msiexec.exe to Launch a Second Windows Installer Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 910
Nested Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Creating Nested Installation Custom Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 912
Inserting Nested Installation Custom Actions into Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 913
Removing Child Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914
Calling MessageBoxA in an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
Searching for Files on the Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917
Launching the Application After the Installation Is Complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Exiting the Installation from Within an InstallScript Custom Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 919
Changing ODBC Properties Through Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Using the INSTALLDIR Property in a VBScript Custom Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Using Action Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 920
Specifying an Action Description and a Template for Action Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 921
Displaying Action Descriptions on the Progress Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 922
Displaying Action Data on the Progress Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 923
Removing an Action Description or a Template for Action Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924
Defining Sequences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 925
Installation Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926
Advertisement Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937
Administration Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 939
User Interface Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Execute Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941
Inserting Actions into Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 942
Scanning an IIS Web Site and Importing Its Settings into an InstallShield Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1230
Filtering IIS Data When Importing a Web Site and Its Settings into an InstallShield Project. . . . . . . . . . . . . . . . . . . . . . . . . . 1231
Creating a Nested Virtual Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1233
Configuring the TCP Port and Site Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234
Specifying the IIS Host Header Name for a Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1237
Specifying the SSL Certificate for a Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238
Setting the IIS Certificate File at Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1239
Adding Files to an IIS Virtual Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1240
Removing Applications and Virtual Directories from the Internet Information Services View . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Adding Application Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1241
Removing Application Pools from the Internet Information Services View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242
Adding Web Service Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Removing Web Service Extensions from the Internet Information Services View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1243
Feature and Component Associations for IIS Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1244
Uninstalling Web Sites, Applications, and Virtual Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1245
Uninstalling Web Service Extensions and Application Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1246
Setting the ASP.NET Version for a Web Site or Application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247
Specifying Whether to Perform Recursive or Non-Recursive ASP.NET Registration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
Considerations for Supporting IIS 6 on 64-Bit Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1248
Defining Application Mappings for a Web Site, Application, or Virtual Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Specifying Timeout Parameters for a Web Site, Application, or Virtual Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1251
Determining If a Target System Has IIS 6 or Earlier or the IIS 6 Metabase Compatibility Feature . . . . . . . . . . . . . . . . . . . . . . . 1252
Configuring Advanced IIS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254
Configuring Custom Error Messages for a Web Site, Application, or Virtual Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1254
Using Windows Installer Properties to Dynamically Modify IIS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255
Using InstallScript Text Substitution to Dynamically Modify IIS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257
Deploying Web Services on a Target Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1258
Enabling Forms Authentication on Web Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
Adding IISROOTFOLDER Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1259
IIS_WEBSITE_NAME Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1260
IIS_PORT_NUMBER Property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1260
Preparing Installations for Maintenance and Uninstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Preparing an InstallScript Installation for Uninstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1261
Executing Script Code Only During Uninstallation or Only During Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1262
InstallScript Functions that Are Logged for Uninstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1263
Maintenance/Uninstallation Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Removing Files that Were Created by Your Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1264
Removing Registry Data Created by Your Product. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1265
Configuring Multiple Packages for Installation Using Transaction Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Overview of Multiple-Package Installations that Use Transaction Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267
Adding a New Chained .msi Package to Your Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1268
Assigning Release Flags to a Chained .msi Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1270
Removing a Chained .msi Package from Your Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1270
Building, Testing, and Deploying Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Creating and Building Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
Working with Product Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1273
ISICEs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1370
ISICE01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1373
ISICE02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1374
ISICE03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1375
ISICE04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1376
ISICE05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1376
ISICE06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1377
ISICE07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1378
ISICE08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1380
ISICE09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1381
ISICE10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1381
ISICE11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1382
ISICE12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1384
ISICE16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1385
ISICE17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1385
ISICE18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1386
ISICE19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1387
ISICE20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1389
ISICE21 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1391
ISICE22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1391
ISICE23 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1392
ISICE24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1393
ISICE25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1393
ISICE26 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1394
InstallShield Virtualization Suitability Suite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395
ISVICE01. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1398
ISVICE02. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1398
ISVICE03. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1399
ISVICE04. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1400
ISVICE05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1401
ISVICE06. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1402
ISVICE07. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1402
ISVICE08. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1403
ISVICE09. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1404
ISVICE10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1405
ISVICE11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1406
ISVICE12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1406
ISVICE13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1407
ISVICE14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1408
ISVICE15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1409
ISVICE16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1410
ISVICE17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1410
ISVICE18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1411
ISVICE19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1412
InstallShield MSIX/UWP App Suitability Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413
ISUWP01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1414
ISUWP02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1415
ISUWP03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1415
ISUWP04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1416
ISUWP05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1416
ISUWP06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1417
ISUWP07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1417
ISUWP08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1418
ISUWP09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1418
ISUWP10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1419
ISUWP11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1419
ISUWP12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1420
ISUWP13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1420
ISUWP14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1421
ISUWP15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1421
ISUWP16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1422
ISUWP17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1422
ISUWP18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1423
ISUWP19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1423
ISUWP20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1424
InstallShield Best Practice Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424
ISBP01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1426
ISBP02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1427
ISBP03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1428
ISBP04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1428
ISBP05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1430
ISBP06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1430
ISBP07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1431
ISBP08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1432
ISBP09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1433
ISBP10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1434
ISBP11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1435
ISBP12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1436
ISBP13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1437
ISBP14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1437
ISBP15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1438
ISBP16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1439
ISBP17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1440
ISBP18 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1440
ISBP19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1441
ISBP20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1442
Understanding When an Installation or Uninstallation Restarts the Target System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1443
Debugging Windows Installer–Based Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1444
Starting the MSI Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
Setting Breakpoints in the MSI Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1445
Removing Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
Viewing and Setting Properties in the MSI Debugger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446
Adding a Sideloading Windows App Bundle (.appxbundle | .msixbundle) to a Suite/Advanced UI Project . . . . . . . . . . . . . . . . . . 1496
Static vs. Dynamic Files for Packages in an Advanced UI or Suite/Advanced UI Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497
Creating a Dynamic Link in an Advanced UI or Suite/Advanced UI Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
Defining Filters for a Dynamically Linked Folder in an Advanced UI or Suite/Advanced UI Project . . . . . . . . . . . . . . . . . . . . . 1500
Including InstallShield Prerequisites (.prq) in an Advanced UI or Suite/Advanced UI Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1501
Primary Packages vs. Dependency Packages in Advanced UI and Suite/Advanced UI Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1502
Specifying the Installation Order of Packages and Transactions in an Advanced UI or Suite/Advanced UI Project . . . . . . . . . . 1503
Configuring Settings for a Package in an Advanced UI or Suite/Advanced UI Project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1504
Associating a Package in an Advanced UI or Suite/Advanced UI Project with a Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1505
Sharing Common Packages Among Different Advanced UI and Suite/Advanced UI Installations . . . . . . . . . . . . . . . . . . . . . . . . . . 1506
Specifying a Run-Time Location for a Specific Package in an Advanced UI or Suite/Advanced UI Project . . . . . . . . . . . . . . . . . . 1507
Configuring Package Operations for an Advanced UI or Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508
Using Custom Folder Names for Packages in Advanced UI and Suite/Advanced UI Installations . . . . . . . . . . . . . . . . . . . . . . . . . . 1510
Customizing the Behavior of a Suite/Advanced UI Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1511
Enabling Windows Roles and Features During a Suite/Advanced UI Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1512
Using Actions to Extend the Behavior of a Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1514
Working with an .exe File for an Action in a Suite/Advanced UI Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1515
Working with a DLL File for an Action in a Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1517
Working with a PowerShell Script for an Action in a Suite/Advanced UI Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1520
Working with an Action that Sets a Property in a Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
Working with an Action that Runs InstallScript Code in a Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1522
Working with a Managed-Code Action in a Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1524
Adding an Action to a Suite/Advanced UI Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
Configuring a Suite/Advanced UI Action’s Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528
Scheduling a Suite/Advanced UI Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1529
Types of Events in a Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1531
Defining Exit Conditions for an Advanced UI or Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1533
Triggering Install Mode or Maintenance Mode of an Advanced UI or Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . 1535
Add or Remove Program Entries for an Advanced UI or Suite/Advanced UI Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1536
Passing Command-Line Parameters to a Package in an Advanced UI or Suite/Advanced UI Installation. . . . . . . . . . . . . . . 1537
Using Advanced UI and Suite/Advanced UI Formatted Expressions to Dynamically Configure Command Lines. . . . . . . . . . . . . 1540
Defining the End-User Interface of an Advanced UI or Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1542
Referring to Feature States and Other Feature Data in the UI of an Advanced UI or Suite/Advanced UI Project. . . . . . . . . 1543
Using Formatted Expressions that Advanced UI and Suite/Advanced UI Installations Resolve at Run Time . . . . . . . . . . . . 1544
Writing Object Expressions in Advanced UI and Suite/Advanced UI Projects to Search Target Systems . . . . . . . . . . . . . . . . . . . . 1546
Minimizing the Number of User Account Control Prompts During Advanced UI and Suite/Advanced UI Installations . . . . 1548
Restarting a Target System for an Advanced UI or Suite/Advanced UI Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1550
Specifying the Behavior for an Advanced UI or Suite/Advanced UI Package that Requires a Restart . . . . . . . . . . . . . . . . . . 1551
Supporting Downloadable Updates for an Advanced UI or Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . 1553
Password-Protecting an Advanced UI or Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1559
Troubleshooting Issues with an Advanced UI or Suite/Advanced UI Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1560
Supporting the Creation of Package Log Files for Command-Line Launching of an Advanced UI or Suite/Advanced UI Installa-
tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1565
Building 64-bit Setup Exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1567
7 Modularizing Installation Projects to Distribute Development Work and Enable Reuse . . . . . . . . 1627
Specifying Installation Information for a DIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1627
Saving a DIM Project File in XML or Binary Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
Specifying the Default Destination Folder for a DIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1628
Using Path Variables in a DIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1629
Organizing Files for a DIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
Configuring the Target System for a DIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1633
Customizing Installation Behavior for a DIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
Configuring Servers for a DIM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634
Viewing InstallScript Cabinet Files (.cab) and Header Files (.hdr). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1833
Overview of InstallScript .cab and .hdr Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1834
Opening InstallScript .cab and .hdr Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1834
Extracting a File from an InstallScript .cab or .hdr File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1835
Generating a Report about an InstallScript .cab or .hdr File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1836
Viewing InstallScript Log Files (.ilg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836
Overview of InstallScript Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1837
Opening InstallScript Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1838
Searching InstallScript Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1838
Converting an InstallScript Log File to a Text File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1839
InstallShield MSIX Bundle Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1839
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Overview of Windows Installer Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1841
Windows Installer Property Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1843
SETUPEXEDIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1864
Advanced UI and Suite/Advanced UI Property Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1865
Creating Properties in Windows Installer–Based Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1871
Creating Properties in Advanced UI and Suite/Advanced UI Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1872
Changing an Existing Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1873
Creating a Localizable Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1874
Making an Existing Property Localizable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1874
Preventing a Property Value from Being Written in Windows Installer Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1875
Preventing a Property Value from Being Written in Advanced UI and Suite/Advanced UI Debug Log Files . . . . . . . . . . . . . . . . . . 1876
Specifying that a Public Property Should Be a Restricted Public Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1877
Getting or Setting Windows Installer Properties in InstallScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1878
Removing a Value from a Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1878
Deleting a Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879
Directly Editing .msi and .msm Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1881
Opening Windows Installer Packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1881
Editing .msi and .msm Databases in Direct Edit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1882
Adding Files in Direct Edit Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1882
Adding Merge Modules in Direct Edit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1883
13 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1913
Menu, Toolbar, and Window Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1915
Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1915
File Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916
Home Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1917
Edit Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1918
View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1920
Go Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1921
Project Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1923
Build Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1925
Tools Menu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1929
Window Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1931
Help Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1931
Toolbars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1932
Standard Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1933
Controls Toolbar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1935
Layout Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1937
MSI Debugger Toolbar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1938
Output Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1938
Dialog Box Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1941
.NET Installer Class Arguments Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
Add an Argument/Value Pair Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1945
Add Existing Media Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946
Add Files for This Package Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946
Add MIME Type Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1948
Support Files View (Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI Projects) . . . . . . . . . . . . . . . . . . . . 2658
Support Files/Billboards View (InstallScript and InstallScript MSI Projects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2659
System Search View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2661
Property Manager View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2661
Events View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2665
Events View Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2665
User Interface View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2673
Dialogs View (InstallScript, InstallScript MSI, and InstallScript Object Projects). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2675
Dialogs View (Basic MSI and Other Windows Installer–Based Projects) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2676
Wizard Interface View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2677
Wizard Interface View Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2679
Billboards View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2684
Billboard Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2685
Settings for Adobe Flash Application File Billboards and Image Billboards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2686
String Editor View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2690
Media View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2693
Path Variables View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2695
Upgrades View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2699
Common Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2701
Advanced Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2703
Major Upgrade Item: Common Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2705
Major Upgrade Item: Advanced Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2707
Minor Upgrade/Small Update Item Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2711
Automatic Upgrade Item Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2712
Releases View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2712
Product Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2713
General Tab for a Product Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2713
Multiple Instances Tab for a Product Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2722
Release Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2723
Build Tab for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2724
Setup.exe Tab for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2736
Signing Tab for a Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2751
Internet Tab for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2756
Events Tab for a Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2759
Appx/MSIX Tab for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2768
Updates Tab for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2776
General Tab for MSIX Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2777
Chained .msi Package Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2787
Patch Design View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2791
Patch Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2791
Common Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2792
Identification Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2794
Digital Signature Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2795
Sequence Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2796
Advanced Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2797
Latest Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2805
Previous Setups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2805
Warning -9414: Local App-V Application Specified as a Dependency of the Primary Application . . . . . . . . . . . . . . . . . . . . . . . 3118
Error -9415: Dependency Application Was Not Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3119
Warning -9416: Invalid Primary Application Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3119
Error -9417: Dependency Application’s OSD File Contains an Invalid HREF Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3120
Error -9418: Error While Privatizing Side-By-Side Assemblies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3120
Error -9419: Error Inserting Watermark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3121
Error -9424: Building an App-V 5.x Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3121
Warning -9500: Shortcut Missing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3121
Error -10000: Process Cancelled By User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3122
Warning -10001: Suite File Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3122
Warning -10002: Suite File is Duplicate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3123
Warning -10003: Application File Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3123
Warning -10004: INI File Missing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3123
Fix 11000: Excluding TCPIP Registry Entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3124
Fatal Error 11001: Fail on VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3124
Warning 11003: Control Panel Applet - Citrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3124
Fix 11004: Control Panel Applet - ThinApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3125
Fatal Error 11005: QuickTime 7.4.1 Causes Fatal Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3125
Fix 11006: Adobe Distiller Exclude AdobePDFSettings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3125
Fix 11007: Exclude URL Shortcut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3126
Steps to Take Before Calling Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3126
Application Features Requiring Pre- or Post-Conversion Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3126
Automation Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3129
Automation Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3129
ISWiProject Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3130
AddAdvancedFile Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3144
AddAutomaticUpgradeEntry Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3145
AddComponent Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3146
AddCustomAction Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3147
AddFeature Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3148
AddLanguage Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3150
AddPatchConfig Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3151
AddPathVariable Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3151
AddProductConfig Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3152
AddProperty Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3153
AddSetupFile Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3153
AddSetupType Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3154
AddSQLServerConnection Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3155
AddUpgradeTableEntry Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3156
BuildPatchConfiguration Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3157
BuildPCPFile Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3159
CloseProject Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3160
CreatePatch Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3160
CreateProject Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3161
DeleteAdvancedFile Method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3162
DeleteComponent Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3163
ReleasePackager.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3583
SetupIni.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3584
MsiExec.exe Command-Line Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3585
Setup.exe and Update.exe Command-Line Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3590
Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3606
Setup.exe (InstallScript Projects). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3610
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3617
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3645
InstallShield 2020
You can use InstallShield to rapidly build, test, and deploy installations that target Windows-based systems.
The InstallShield Help Library contains information about the functionality and features of InstallShield. The Help Library
contains the following sections:
Section Description
What’s New in InstallShield 2020 Informs you about the changes in InstallShield 2020.
What Was New in Earlier Versions Informs you about changes that were made in earlier versions of InstallShield.
of InstallShield
Launching InstallShield with vs. Alerts you to functionality that is not available if you are running InstallShield
Without Administrative Privileges without administrative privileges; also describes a potential problem that may
occur if you switch between full Administrator and non-Administrator contexts and
you use mapped-drive locations in your projects.
Developing and Building Alerts you to differences that you may notice if you use InstallShield on some 32-bit
Installations on 32-Bit vs. 64-Bit systems compared to some 64-bit systems.
Systems
Getting Started Contains information to help you become familiar with InstallShield, begin creating
an installation project, and customize the InstallShield user interface.
Tutorials Leads you step-by-step through the process of creating InstallScript and Basic MSI
installation projects, and creating global installations.
Section Description
Creating Installations Explains how to create user-friendly, reliable installations and guides you through
every step of the process—from specifying information for Add or Remove
Programs to building, testing, and deploying an installation.
Creating Advanced UI and Suite/ Contains an overview, plus some detailed how-to information, about Suite/
Advanced UI Installations Advanced UI and Advanced UI projects.
Designing InstallShield Introduces some basic concepts to help you get started designing your own
Prerequisites and Other InstallShield prerequisites, merge modules, and InstallScript objects that can be
Redistributables used in any of your installation projects or distributed for use by other installation
developers.
Modularizing Installation Projects Introduces developer installation manifests (DIMs), a feature-sized collection of
to Distribute Development Work related items such as product files, shortcuts, registry entries, text file changes, IIS
and Enable Reuse Web sites, and other elements that together make up a discrete portion of a
product installation.
Updating Applications Leads you through steps for planning and implementing the various types of
upgrades and patches for updating a product. Also explains how you can use
FlexNet Connect to notify end users about upgrades and patches that are available.
Creating Customized Virtual Explains how to use InstallShield to create customized virtual applications.
Applications
Additional Installation Options Discusses a broad range of options available in InstallShield: creating multilingual
installations, installing multiple instances of a product, building conditional
statements, searching for installed data, editing installation tables, and more.
Integrating InstallShield with Contains details about integrating InstallShield with third-party tools such as
External Applications source code control software, Microsoft Visual Studio, and Microsoft Visual Studio
Team Foundation Server (TFS).
Automating Installation Provides information about the InstallShield automation interface, which enables
Development and Build Processes you to automate processes for creating installation projects without having to
directly open the InstallShield user interface.
Section Description
Reference Contains comprehensive reference information for the InstallShield user interface;
the InstallScript language; errors and warnings that might occur when you create,
compile, build, or run your installation; tools that you can use from the command
line to perform tasks such as building a release and running an installation; the
objects that you can use to embed object expressions in various settings of an
Advanced UI or Suite/Advanced UI project to search target systems; the
InstallShield custom actions that are added to projects; and objects, methods,
properties, and collections used to modify an installation project through the
automation interface.
Frequently Asked Questions Directs you to help topics that answer many commonly asked questions about
InstallShield and project creation.
Note • Because the InstallShield Help Library is designed to interact with InstallShield, it is recommended that you open the
help from within InstallShield. Copying the help files to another folder or system causes many of its features to work
incorrectly.
For answers to many commonly asked questions and new information about InstallShield that do not appear in the
documentation, visit the Knowledge Base.
Legal Information
InstallShield 2020
Copyright Notice
Copyright © 2020 Flexera Software. All Rights Reserved.
This publication contains proprietary and confidential information and creative works owned by Flexera Software and its
licensors, if any. Any use, copying, publication, distribution, display, modification, or transmission of such publication in
whole or in part in any form or by any means without the prior express written permission of Flexera Software is strictly
prohibited. Except where expressly provided by Flexera Software in writing, possession of this publication shall not be
construed to confer any license or rights under any Flexera Software intellectual property rights, whether by estoppel,
implication, or otherwise.
All copies of the technology and related information, if allowed by Flexera Software, must display this notice of copyright
and ownership in full.
Intellectual Property
For a list of trademarks and patents that are owned by Flexera Software, see https://www.revenera.com/legal/
intellectual-property.html. All other brand and product names mentioned in Flexera Software products, product
documentation, and marketing materials are the trademarks and registered trademarks of their respective owners.
• MSIX Fonts
MSIX Fonts
Installshield supports “Windows Shared Fonts” declaration for MSIX project. This declaration can be added to MSIX project
from the “Declaration” view to install and share the custom fonts with other applications in the system.
• MSIX Bundles
MSIX Bundles
Now you can create MSIX Bundles using a new MSIX Bundle Utility. Add your architecture specific packages to the utility,
provide signing information, and create an MSIX Bundle.
6. In Files and Folders view, add any new files you wish to add to the modification package.
7. In Registry view, add or modify any entries, which you wish to include in the modification package.
When you create an MSIX Package in a Basic MSI Project or MSIX Project, set the value in the Release view as below:
1. To create a Pure 64-Bit Installer in the Basic MSI project, navigate to the Product Configuration view and select 64-Bit
Setup Launcher.
2. To create a Pure 64-Bit Installer in the Suite project, navigate to the Releases view and select 64-Bit Setup Launcher.
This section describes features and enhancements that were released in earlier versions of InstallShield:
• What’s New in InstallShield 2010 Expansion Pack for Visual Studio 2010
See Also
Upgrading from Earlier InstallShield Versions
Upgrading from Other InstallShield Editions
Instructions on how to set up an InstallShield 2019 R3 Standalone Build on a Docker container or to download an already
set up InstallShield 2019 R3 Standalone Build on Docker Hub can be found in the Revenera Community Knowledge Base.
The InstallShield 2019 R3 release includes an enhancement that permits you to customize the file redirection fixup
parameter executable name. This applies to executables that launch multiple processes.
In the previous release, the redirection fixup parameter executable was given the same name as the primary process. In
InstallShield 2019 R3, a new field, Executable, has been added to the Package Support Framework area of the
Application Settings view of an MSIX project type to enable you to specify the redirection fixup parameter executable
name. By default, this field is populated with the primary process name.
Now, Microsoft has released a new OLE DB provider called Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL).
InstallShield 2019 R3 now uses Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) to support TLS 1.2 only
environments.
Advanced Note • Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) is included as a prerequisite in InstallShield 2019 R3.
By default, the Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) will appear on the Requirements tab for your new
SQL connection.
In the InstallShield 2019 R3 release, you can now configure Patch Design patches through the automation interface.
It helps your application follow the best practices of the modern runtime environment. It contains an executable, a runtime
manager DLL, and a set of runtime fixes to a package.
When the users start your application, the Package Support Framework launcher is the first executable that runs. It reads
your configuration file and injects the runtime fixes and the runtime manager DLL into the application process. The
runtime manager applies the fix when it's needed by the application to run inside of an MSIX container.
In InstallShield 2019 R2, you can now use the Package Support Framework that contains runtime fixes such as the File
Redirection Fixup and Custom Fixup in MSIX.
• File Redirection Fixup - You can use the File Redirection Fixup to redirect attempts to write or read data in a directory
that isn't accessible from an application that runs in an MSIX container.
• Custom Fixup - You can use the Custom redirection fixup that will solve application compatibility issues with a
configuration file that specifies the fixes that you want to apply to your application.
In InstallShield 2019, you can now use MSIX project type to build MSIX packages. It contains windows applications for side-
loading or distribution via the Windows Store.
• Package Information
• Package Payload
• Media
Package Information
• General Information view to specify details such as the name and format of the project file.
• MSIX VisualAssets explorer to offer an integrated, visual method for describing visual aspects of the MSIX apps.
• Capabilities view that requires to be enabled in app's package manifest to access certain API or resources like
pictures, music, or devices such as the camera or the microphone.
• Declarations view that provides a visual tool for creating and managing the application, package level declarations
and allows to configure their properties.
• Content URIs view to specify the URIs that can use window.external.notify to send a Script-Notify event to the app.
Package Payload
Now you can specify the files that designs your MSIX application:
• Files and Folders view lets you to add files to your InstallShield project. You can organize these files into folders on
the target system.
• Applications view offers an integrated, visual method for designing windows app properties that comprises part of or
all of the functionality delivered in the package.
• Registry view enables you to define registry keys and values to be created by your installation.
Media
Now you can customize the files and folders that you will use to distribute your installation:
• Path Variables view makes your installation easily portable between development systems through the use of
variables.
• Releases view provides a visual tool for each product in your project.
Now in InstallShield, you can include a set of validators called the InstallShield MSIX Suitability Suite.
The InstallShield MSIX Suitability validators in this suite scan an.msi package for signs of items that are unsuitable for the
MSIX package (.msix) format.
There are different tabs in the New Project Wizard which are given below:
• Common Project Types - Use the most commonly used project types.
• InstallScript Project Types - Use the previously built projects which uses the InstallShield setup engine with
InstallShield Professional
• Windows Installer Project Types - Use the previously built projects which uses the Microsoft Windows Installer
(MSI) setup engine with InstallShield
• All Project Types - Use all the available project types and any custom templates.
Required to specify the <DelayBetweenSigning default="1500"/> node in the settings.xml, under <DevStudio/Build> node
in Settings.xml in milliseconds.
Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following locations,
depending on which language version of InstallShield you are using:
• Basis MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
• Advanced UI
In InstallShield 2019 R2, there is a new parameter (cert_password) that specifies the digital certificate password, this is an
optional parameter in the command line build (IsCmdBld.exe).
If it is not specified, the password configured in the project is used to sign the files.
• Basis MSI
• InstallScript
In InstallShield 2019 R2, now when trying to build a modified project, you will be able to link an ISM package using a relative
path.
• Basis MSI
• InstallScript
• InstallScript MSI
In InstallShield 2019 R2, the Microsoft SQL Server 2012 Native Client prerequisites (x86 and x64) which is now included for
the latest versions of 2012 Native Client.
• Basis MSI
• InstallScript
In InstallShield 2019 R2, you can set the Prerequisite Condition to run on a specified platform for Windows Server 2019. You
can set the appropriate PRQ Conditions in the Prerequisite Editor by selecting or deselecting the option.
• Basis MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
• QuickPatch
• MSIX
In InstallShield 2019, the details of the certificate like the general information of the certificate, security details and
certification path is listed on the View Details option in the Certificate Selection dialog box.
• Basis MSI
• InstallScript MSI
In InstallShield 2019, you can add an option for Windows Server 2019 in the operating system requirements section. You
can set the appropriate Install Condition in the project by selecting or deselecting the option.
• Basis MSI
• InstallScript MSI
If your installation requires the above, you can use the System Search view or the Installation Requirements page in the
Project Assistant to add this system search 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.
• Advanced UI
• Basis MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
• SHA-1 to sign the package, the package will get time timestamped using:
<DigitalSignature Timestamp="http://timestamp.verisign.com/scripts/timstamp.dll"/>
• SHA-256 to sign the package, the package will get time timestamped using:
<DigitalSignature TimestampRFC3161="http://sha256timestamp.ws.symantec.com/sha256/timestamp"/>
• Suite/Advanced UI
InstallShield supports the Microsoft Build engine (MSBuild) included with the .NET Framework. MSBuild support enables
you to build Visual Studio solutions with InstallShield projects where Visual Studio is not installed in the build lab
environments.
In InstallShield 2019, you can now build suite projects (.sln) which are created in Visual Studio using MSBuild.
• Suite/Advanced UI
An option, Always Create Debug Log, had been added to the Setup.exe tab of the Releases view for Advanced UI and
Suite/Advanced UI projects.
Now in InstallShield 2019, you can specify the debug log file name which will be generated.
• Basic MSI
• InstallScript MSI
• InstallScript
In InstallShield 2019, you can now override the return code of setup.exe with your own custom values during the runtime.
• Basic MSI
• InstallScript MSI
• InstallScript
• Suite/Advanced UI
In InstallShield 2019, you have the ability to customize the original file name property for setup.exe.
This allows you to install the Automation Interface feature without selecting manually.
• Basic MSI
• InstallScript MSI
In InstallShield 2018 R2, you can now build an MSIX package using the InstallShield IDE.
You can now enable updates for the end users to see the downloadable update support for your Advanced UI or Suite/
Advanced UI setup launcher.
• The end users receive an option to either download a newer version or skip and proceed with the current installation
process.
• The end users can forcibly download and install the new version of the Suite package (if available).
You can now enter a message you want to show the end users to download a newer version or skip and proceed with the
current installation process.
You can also create a new message or select a message from the localized available list of strings.
Note • The end users will see this prompt message with ‘Yes’ and ‘No’ options to download a newer version or skip and
proceed with the current installation process.
In previous releases, you could enter the Absolute Path in an Advanced UI or Suite/Advanced UI installation that you want
to use for the future path to the update setup launcher that you will make available for download to target systems on the
Setup.exe tab of the installer.
In InstallShield 2018 SP1, you could enter the same Absolute Path in an Advanced UI or Suite/Advanced UI installation on
the Updates tab of the installer.
• Certificate Hash
• SHA-1
• SHA-256
In InstallShield 2018 SP1, along with the above signature digest hashing algorithm, you can now choose Dual Signing -
(SHA-1 and SHA-256) digest.
Note • Using both (SHA1 and SHA256) digests are not supported by the Digital signature of msi.
• Advanced UI
• Suite/Advanced UI
In InstallShield 2018, you now have the ability to add a message to the Suite Loading Screen Message for your Advanced UI
or Suite/Advanced UI setup launcher.
The length of the message in the Suite Loading Screen Message is limited to 35 characters.
• Basic MSI
• InstallScript MSI
• QuickPatch
In InstallShield, a new setting is introduced to customize the name of the Update Launcher. By default, InstallShield uses
Update.exe is the name for the Update Launcher. Now, you can create an Update Launcher with a specified name.
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
In InstallShield, a new setting is introduced to specify the number of character space(s) to move forward/backward in a
PowerShell custom action.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
In InstallShield, a new predefined folder is introduced to hold the full path to the Users Public folder.
• New Option to Control Whether to Load User Profile for an Application Pool Entity
• Enhancements
• Advanced UI
• Suite/Advanced UI
In InstallShield 2018, you can now specify the uninstallation order of packages in a suite project using the new
Uninstallation Order property on the Setup.exe tab of the Releases view.
You can use this setting to specify the uninstallation order of the packages in a suite project by selecting one of the
following options:
• Same as Packages Order—Uninstall the packages in the same order that packages were installed (as defined in the
project).
• Reverse of Packages Order—Uninstall the packages in the reverse order that packages were installed (as defined in
the project).
• euoForward(0)—Uninstall the packages in the same order that packages were installed (as defined in the project).
• euoReverse(1)—Uninstall the packages in the reverse order that packages were installed (as defined in the project).
• Advanced UI
• Suite/Advanced UI
In InstallShield 2018, you can now use a new command line parameter to run a suite installation in minimum UI mode, only
displaying a progress panel.
To run a suite installation in minimum UI mode, use the /passive parameter in the command line:
Setup.exe /passive
• Advanced UI
• Suite/Advanced UI
In previous releases, you could set the Visible property of a feature in an Advanced UI or Suite/Advanced UI installation to
Yes or No specify whether the feature should be visible on the InstallationFeatures wizard page of the installer.
In InstallShield 2018, you can conditionally show or hide a feature based upon a property at run time using the new
Condition option under the Visible property on the Features view of the Installation Designer.
You can use the Condition setting to specify one or more conditions that the Advanced UI or Suite/Advanced UI installation
should use to evaluate whether the feature should be visible for installation by default on the InstallationFeatures wizard
page.
For example, if you want a particular feature to be visible by default on target systems that have a particular version of
Windows, you can create a condition that specifies that version of Windows.
1. On the Features view, click in the Condition row under the Visible property. A green plus sign, the New Condition
button, appears at the end of the row.
2. Click the New Condition button. A new row is added under the Condition row.
3. Click the down arrow next to the New Condition button and select the appropriate option—All, Any, or None—from
the list.
4. Then in the same row, click the New Condition button, and select the appropriate option to continue building the
conditional statement.
If one or more conditional statements are configured, the Condition property lists (Condition). If none are
configured, the Condition property lists (Empty).
Method Syntax
DeleteVisibleCondition DeleteVisibleCondition()
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
A new option named ASP.NET Registration has been added to the Application settings on the Internet Information
Services view that enables you to perform recursive or non-recursive ASP.NET registration. Using this feature enables you
to install both ASP.NET applications and ASP.NET Core applications to the same website.
To set the ASP.NET application registration option with Internet Information Services (IIS), set the ASP.NET Registration
property to one of the following options:
• Recursive—Updates script maps and application-pool assignments for the specified application and for all sub-
applications.
• Non Recursive—Updates script maps and application-pool assignments for only the specific application. No sub-
applications are changed.
• Basic MSI
• InstallScript MSI
InstallShield 2018 includes a new option to set forms authentication on web applications. This new option, Forms
Authentication, is displayed under the Authenticated Access section of the Internet Information Services view for a
website.
Set the Forms Authentication option to Yes to enable forms authentication. ASP.NET forms-based authentication works
well for sites or applications on public Web servers that receive many requests. This authentication mode lets you manage
client registration and authentication at the application level, instead of relying on the authentication mechanisms
provided by the operating system.
Important • Forms authentication sends the user name and password to the Web server as plain text. You should use Secure
Sockets Layer (SSL) encryption for the Log On page and for all other pages in your application except the Home page.
New Option to Control Whether to Load User Profile for an Application Pool Entity
• Basic MSI
• InstallScript MSI
In InstallShield 2018, there is a new Application Pool settings property on the Internet Information Services view, named
Load User Profile, that controls whether to load the user profile for an application pool entity.
Set the Load User Profile property to one of the following options:
• Yes—IIS will load the user profile for the application pool.
• No—IIS will not load the user profile for the application pool. This is the same behavior that occurred with IIS 6.0.
• Basic MSI
• InstallScript MSI
• Transform
In previous releases, you were unable to add a Kill Process or PowerShell custom action to a Transform project. In
InstallShield 2018, you can now add a New Kill Process or New PowerShell custom action to a Transform project in the
Custom Actions and Sequences view.
Enhancements
InstallShield 2018 includes the following enhancements:
• New MSBuild Parameters to Set Summary Information Stream Comments and to Set Package File Name
• New Out-of-the-Box Dialog to Set the IIS Certificate File for SSL Certificate at Runtime
• Specify Absolute or Relative Path When Creating New Child Elements in an XML File
• Setting the Default Keyboard Focus for Dialog Box Controls in Suite Projects
• Basic MSI
• QuickPatch
In InstallShield 2018, you can now save a QuickPatch project in XML format, and you can also create a QuickPatch project
from projects saved in XML format. In previous releases, QuickPatch projects could only be saved in binary format.
• Advanced UI
• Suite/Advanced UI
In InstallShield 2018, suite projects now support localizing the Product Name property.
To localize the Product Name property in a suite project, perform the following steps.
1. Open a suite project and go to the User Interface > String Editor view.
2. Create a new string that contains the localized text for each of the languages supported by your suite project, such as
ID_STRING2.
4. Click the browse button next to the Product Name field to open the Select String dialog box.
5. Select the name of the string that you created that contains the localized text.
• Basic MSI
• InstallScript MSI
In InstallShield 2018, you can now include the value of a property from the Property Table in product release configuration
setup and package file names.
For example, you could enter any of the following properties in the Setup File Name or MSI Package File Name field on
the General tab of the Releases > Product Configuration view:
setup[ProductVersion]
setup[CustomVersion]
setup[ProductCode]
setup[ProductCode][ProductVersion]
If you entered setup[ProductVersion] in the Setup File Name field, it would result in a setup named
setup14.10.1234.exe, for example.
New MSBuild Parameters to Set Summary Information Stream Comments and to Set Package File Name
In InstallShield 2018, new MSBuild parameters were added to enable you to set add comments to an installer and to set the
package file name of an installer.
• Basic MSI
• InstallScript
• InstallScript MSI
• Merge Module
You can add comments to an installer in the Summary Information Stream Comments field on the General Information
view.
In InstallShield 2018, you also have the option of entering comments at build time. A new parameter has been added to the
MSBuild.exe task, named SummaryInfoComments, to set the Summary Information Stream comments at build time, such
as including the build number, as shown in the following example:
The comments that are added using the SummaryInfoComments property can be viewed on the Properties dialog box of the
built installer.
• Basic MSI
• InstallScript MSI
You can specify the package file name of an installer in the MSI Package File Name field on the General tab for a Product
Configuration field on the Releases view.
In InstallShield 2018, you also have the option of setting the package file name at build time. A new parameter has been
added to the MSBuild.exe task, named MSIPackageFileName, to set the package file name of the built installer at build
time, as shown in the following example:
When entering the value for the MSIPackageFileName parameter, you need to enter the file name—without the period or
the file extension—that InstallShield should use for the .msi file.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
In your installer, you can configure search-and-replace behavior for content in text files that you want to modify at run time
on the target system. To do this, you open the System Configuration > Text File Changes view and add a text Change Set
that identifies the text files that will be searched at runtime, and also specifies the text to search for (Find What) and the
text to replace it with (Replace With).
In InstallShield 2018, when adding a text Change Set, you can now enter escape sequence characters in the Replace What
field to specify a line break or a tab.
Tab \t
Note • For the Windows operating system, you must enter both \r\n to insert a line break.
When the search-and-replace action is taken at runtime, a line break will be inserted where \r\n was entered in the
Replace With field, and a tab will be entered where \t was entered.
For these characters to be recognized as escape sequences, you also have to set the Parse Escape Sequences option to
Yes.
• Advanced UI
• Suite/Advanced UI
In InstallShield 2018, you now have the ability to control whether or not the Suite Loading Screen is displayed during
installation.
To control whether this screen is displayed, a new property has been added to the Setup.exe tab of the Releases view
named Show Suite Loading Screen. If you want to hide the Suite Loading Screen for your Advanced UI or Suite/Advanced
UI setup launcher, set this property to No.
In InstallShield 2018, you now have the ability to add a message to the Suite Loading Screen Message for your Advanced UI
or Suite/Advanced UI setup launcher.
The length of the message in the Suite Loading Screen Message is limited to 35 characters.
You can use the ShowSuiteLoadingScreen method in the automation interface to set the Show Suite Loading Screen
setting on the Setup.exe tab of the Releases view. The default value is True.
• Advanced UI
• Suite/Advanced UI
In InstallShield 2018, you can now select an option to turn on logging for a suite project without passing debuglog through
the command line.
A new option, Always Create Debug Log, has been added to the Setup.exe tab of the Releases view for Advanced UI and
Suite/Advanced UI projects.
If you want to always create debug logs for your Advanced UI or Suite/Advanced UI setup launcher, set the Always Create
Debug Log option to Yes.
You can use the CreateDebugLog method in the automation interface to set the Always Create Debug Log setting on the
Setup.exe tab in the Releases view. The default value is False.
New Out-of-the-Box Dialog to Set the IIS Certificate File for SSL Certificate at Runtime
• Basic MSI
InstallShield 2018 includes a new out-of-the-box dialog (IISBrowseSSLCertificate) for the installer that enables the end
user to browse to a IIS certificate file that they provide for the SSL Certificate and enter a password at installation runtime.
To add a Configure SSL for IIS dialog to your installer, perform the following steps:
1. In the View List under Server Configuration, click Internet Information Services.
2. Right-click the Web Sites explorer and click Add Web Site. InstallShield adds a new Web site.
3. Select the new web site and locate the SSL Certificate and SSL Certificate Password properties under Security >
Secure Communication.
4. Set the SSL Certificate and SSL Certificate Password properties to the following values:
Property Value
5. Open the User Interface > Dialogs view and add the IISBrowseSSLCertificate dialog to the dialog sequences.
The property name for the SSL Certificate and password configured by the user is required to update in the
IISBrowseSSLCertificate dialog for the Edit boxes (IISWebCertPassword and IISWebCertPath) and the push button
(BrowseCertificate) events.
Specify Absolute or Relative Path When Creating New Child Elements in an XML File
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
In previous releases, when using the System Configuration > XML File Changes view to add a new child element to an XML
file that has the same name as a child element in an existing parent element, the XML file change would fail.
The path of a node in an XML document can be either absolute or relative. Absolute paths start at the root. When adding a
new child element to an XML file that has the same name as a child element in an existing parent element, it is necessary to
use the absolute path.
In InstallShield 2018, a new setting has been added to the XML File Changes view named Use Absolute XPath to enable
you to specify that you want to use an absolute path when creating child elements.
The behavior used when creating a child element depends upon the Use Absolute XPath option setting:
• Selected—If this option is selected, Absolute XPath will be used when adding a child element.
• Not selected—if this option is not selected, Generic XPath will be used when adding a child element. By default, the
Use Absolute XPath option is not selected.
Setting the Default Keyboard Focus for Dialog Box Controls in Suite Projects
• Advanced UI
• Suite/Advanced UI
In InstallShield 2018, when defining the wizard pages for a Suite project, you can now specify which control on a wizard
page will have the default keyboard focus.
On the Wizard Interface view, there is a new property under Appearance named Default Focus, which lists all of the
controls defined on that wizard page. Select a control to set the default keyboard focus to that control.
• Basic MSI
• InstallScript MSI
In InstallShield 2018, the PowerShell script editor is available on the Custom Actions and Sequences > Custom Actions
view for Basic MSI projects, on the new Script tab. In previous releases, the PowerShell Script Editor was only available for
Suite/Advanced UI projects.
• Transform
In InstallShield 2018, you can now open an existing transform file in the InstallShield Transform Wizard (as if it were being
opened in the Transform Wizard for the first time), where you will be prompted to select a base MSI package for the
transform file. This enables you to use the same generic transform file for multiple MSI packages.
To open an existing transform file in the InstallShield Transform Wizard, right-click on the transform file in Windows
Explorer and select Open in InstallShield Transform Wizard from the context menu.
Because Microsoft Visual Studio 2017 has been released, InstallShield now includes the prerequisites for Visual C++ 2017
x86 and x64.
Because Microsoft SQL Server 2014 has had 2 Service Packs released, InstallShield now includes the prerequisites for both
Microsoft SQL Server 2014 SP1 and SP2.
The current release of FlexNet Code Aware supports analysis of the following files:
• Java Packages
• Node Packages
• Nuget Packages
• RPM Packages
• Ruby Packages
Security vulnerabilities are looked up against the National Vulnerability Database (NVD).
To run FlexNet Code Aware from within InstallShield, click Scan Project using FlexNet Code Aware from the InstallShield
Project menu. This menu option is disabled out if you are not currently in an open InstallShield project. A FlexNet Code
Aware icon is also available on the InstallShield standard toolbar.
When FlexNet Code Aware completes the scan of your project, a summary displays showing the number of files scanned,
and the number of open-source packages and vulnerabilities found. A View report button is provided if you have a fully
licensed version of FlexNet Code Aware. For more information about the details provided in this report, refer to Reading the
FlexNet Code Aware Report.
Note • The FlexNet Code Aware Report is not available in trial/evaluation mode. A fully licensed version of FlexNet Code
Aware is required.
To view the FlexNet Code Aware Report, click View report on the summary dialog that appears after FlexNet Code Aware
has scanned your project.
• The initial Summary View presents the user with a Scan Summary, Operational Risk assessment, Security
Vulnerability Exposure, and License Exposure.
• The Scan Summary section provides details regarding the codebase that was scanned, including a breakdown of
file types, percent of files analyzed, and number of findings.
• The Operational Risk section provides a composite risk rating based on the combination of packages with
Intellectual Property (IP) issues and packages with Security Vulnerabilities.
• The Security Vulnerability Exposure and License Exposure sections provide a breakdown of the types and
categories of identified issues.
• The Package Inventory View, available by clicking view full package inventory in the Scan Summary section,
provides a complete list of discovered open source and third-party packages with associated licenses, security
vulnerabilities, dependencies, and detected copyright statements.
The Package Inventory View provides filters that you can use to execute targeted queries to refine the list to various
package types of interest.
• Tile Configurations
• New InstallShield Prerequisites for Microsoft Visual C++ 2015, .NET Framework 4.6, and More
• Predefined System Searches for Adobe Reader, Microsoft Office and the .NET Framework
Not only can you install InstallShield on these operating systems, but you can also create installers that target these
operating systems.
Project • Microsoft SQL Server 2016 support is available in the following project types:
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
InstallShield now includes support for running SQL scripts on SQL Server 2016 database servers. In addition, InstallShield
includes SQL Server 2016 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 2016, 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 2016, SQL Server 2016 Express, and SQL Server 2014
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 2016 database server.
See New InstallShield Prerequisites for Microsoft Visual C++ 2015, .NET Framework 4.6, and More for a complete list of new
InstallShield prerequisites added to InstallShield.
Important • The Windows 10 Anniversary Update is required for installing and testing a Windows App package (.appx) with
desktop extensions (Desktop Bridge). To digitally sign the Windows App package, InstallShield must be installed on a Windows
10 machine or a machine with the Windows 10 SDK installed.
The Windows App package (.appx) format is the simple and secure packaging format used to distribute and install apps on
Windows 8.x and 10 and is the only format allowed for Universal Windows Platform (UWP) apps. Benefits of Windows App
packages include:
• High availability, reliability, and durability, resulting in applications that operate continuously without failure for
extended periods of time
• A smooth installation experience through static builds that require minimal configuration and no customizable UI
• The option to sell or provide the application through the Windows Store
• The ability to leverage UWP functionality such as live tiles as well as the ability to utilize UWP APIs
• The only package format with native support on Windows Nano Server
InstallShield now supports creating the Windows App package format (.appx) and its desktop and server extensions
through an alternate build output and provides suitability testing to help you identify items unsuitable for the Windows
App package format. Refer to the following subsections for details about new functionality added to InstallShield to
support the creation of Windows App packages.
For complete information on these new settings, see Appx/MSIX Tab for a Release.
The InstallShield MSIX/UWP App Suitability Suite provides a report in the Releases view that indicates all tests that found
issues and for each issue, an associated column in the report indicates applicability to the known Windows App variants.
For traditional CUBs, these columns are not populated. You can view this report by navigating to the Releases view and
selecting the Validations folder under your release. For complete information, including descriptions of the new ISUWP
validations included, see InstallShield MSIX/UWP App Suitability Suite.
• Windows App Package Eligible—Check target systems for the run time dependencies of the Windows App package to
prevent any attempts to install a Windows App package onto a version of Windows or Windows Server that does not
support it.
Note • This condition is available only for the eligibility condition of a Windows App package. If it is used in any other
package type, it will not function correctly.
• UWP Type Present—Check target systems for the presence of UWP functionality. For example, to create a conditional
statement that checks for the presence of the Desktop Bridge, check for the type
Windows.ApplicationModel.FullTrustProcessLauncher. This can be used to conditionally block installation, or to
choose between installing .msi and Windows App package (.appx).
Note • This always evaluates as false on operating systems before Windows 10. Use of the Type Name subsetting
Windows.ApplicationModel.FullTrustProcessLauncher requires Windows 10 Anniversary Update or newer.
Edition • The Suite/Advanced UI project type is available in the Premier edition of InstallShield.
SQL servers are integral to many applications, especially those that benefit from the multiple package support provided by
InstallShield Suite installations. Previously, InstallShield SQL support was limited to Basic MSI, InstallScript, and
InstallScript MSI projects. Now, SQL support has been added to Suite/Advanced UI projects, giving you the ability to:
When adding a new predefined page to your project, select the Enter login information for a database server task page
and complete the panels in the wizard as needed. The SQLLogin predefined wizard page is then added to your project. This
SQLLogin wizard page lets end users enter database server login information (database server name, authentication
credentials, database catalog name, etc.) in order to establish a connection to the database server that is targeted by one
or more .msi packages in the suite.
• Specify properties that identify the SQL login settings in the Suite project and then select the .msi package that
receives these properties
• Specify the properties that identify the SQL login settings in the .msi package
• Choose the database technology (Microsoft SQL Server, Microsoft Windows Azure, MySQL, or Oracle) and select the
ODBC driver to be targeted
The SQL query result can then be accessed in a Suite property. To provide this support, a Run a SQL String option is now
available in the New Action menu of UI events. The SQL statement is executed using properties and database metadata
specified by additional new options available in the New Action menu of UI events: Configure Database Metadata and
Override SQL Login Properties.
Tile Configurations
Project • This information applies to Basic MSI, InstallScript MSI, and InstallScript project types.
Windows 8 introduced a grid of application tiles to the Start screen, replacing the usual list of shortcuts, and also presented
tiles in place of shortcuts. InstallShield supports customizing the appearance of a desktop app’s tile on the Start screen.
The following tile configuration settings are available:
• A toggle between light or dark text when including the app name on medium-sized (150x150) tiles
The Tile Configurations node appears in the main Shortcuts view and in each component’s Shortcuts subview. Any
applicable tile configurations are listed.
New InstallShield Prerequisites for Microsoft Visual C++ 2015, .NET Framework 4.6, and
More
Project • InstallShield prerequisites can be added to Advanced UI, Basic MSI, InstallScript, InstallScript MSI, and Suite/
Advanced UI projects.
• Windows Management Framework 4.0 for Windows 7 SP1 and Server 2008 R2 SP1 (x64)
• Windows Management Framework 5.0 for Windows 7 SP1 and Server 2008 R2 SP1 (x64)
• Windows Management Framework 5.0 for Windows 8.1 and Server 2012 R2 (x64)
Note • The Web prerequisite for the .NET Framework requires an Internet connection. This prerequisite downloads the
required redistributable files if appropriate. The Full prerequisite for the .NET Framework is a stand-alone installation that
does not require an Internet connection.
Predefined System Searches for Adobe Reader, Microsoft Office and the .NET
Framework
Project • Predefined System Searches apply to Basic MSI and InstallScript MSI projects.
• Adobe Reader 11
• Adobe Reader DC
If your installation requires one or both 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.
Enhancements
InstallShield 2020 includes the following new enhancements:
• Suite UI Enhancements
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• QuickPatch
• Transform
InstallShield now adds several Direct Editor enhancements that provide visual insights into tables, schema information,
and validation errors designed to boost the productivity of setup authors or packagers who use the Direct Editor for
troubleshooting to identify and resolve advanced problems. These enhancements are described in the following sections:
When showing the Directory table, InstallShield shows a read-only, grayed out column that displays the resolved path of
each row’s directory location. This column is not actually stored in the project file. You can sort by its visible text, but you
cannot insert, update, or delete its values.
InstallShield now provides tooltips added to column headers that display the following schema information to indicate the
column data type allowed:
• small integer—Integer numerical (no decimal), containing a value from -32767 to +32767.
• long integer—Integer numerical (no decimal), containing a value from -2147483647 to +2147483647.
• localizable—This column contains a string that can be translated. Columns without this marker are not localized.
Tip • The Directory, Binary, and CustomAction Direct Editor tables display several of these column types.
Each record may reference one or more other records or be referenced by one or more other records. When a record is
highlighted that refers to other records or is referred from other records, the Reference Tracking pane is populated with a
Reference Tables section showing the tables in which the references reside and an additional section that displays the
actual record references. The record references section includes arrow icons that indicate the direction of the reference,
where:
• A green arrow pointing to the right indicates that the record that is selected in the Direct Editor table references the
record displayed in the Reference Tracking pane.
• A blue arrow pointing to the left indicates that the record selected in the Direct Editor table is referenced by the
record displayed in the Reference Tracking pane.
• Two arrows in both directions (a green arrow pointing right and a blue arrow pointing left) that indicate the record
selected in the Direct Editor table references and is referenced by the record displayed in the Reference Tracking
pane.
Note • When multiple Direct Editor records are selected, only the “focused” record's references are shown. In addition, if
multiple tables appear in the Reference Tables section, this indicates that the record selected in the Direct Editor table
references or is referenced by records in multiple tables. You can click any table in the Reference Tables section to view the
associated records references.
Tip • In the Reference Tracking pane, you can quickly jump between record references by double-clicking within a cell.
There are instances where a Direct Editor table record might reference a foreign key record that no longer exists.
InstallShield now displays the cells of such broken references with a red fill color to call attention to the broken reference.
For example, if the Directory_ column in the in the Component table references a directory name that is not found in the
Directory table, then the Directory_ column is filled in red.
Note • The Direct Editor broken reference indicator is unrelated to the Maintain referential integrity check box on the
Preferences tab of the Options dialog box. While the Maintain referential integrity setting is designed to update the foreign
keys when you modify a primary key, the purpose of the broken reference indicator is to display broken references to help you
easily identify orphaned records. Therefore, broken references are displayed regardless of the selection of the Maintain
referential integrity setting.
Suite UI Enhancements
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
To better support various use cases, InstallShield has added the following functionality to Advanced UI and Suite/
Advanced UI projects:
Close Window This type of action closes a main wizard page or secondary window, or in some
cases, provides conditional closing of a secondary window.
The behavior of the Close Window action differs slightly on wizard pages and
secondary windows, as noted following:
• For wizard pages, the Close Window action prompts the end user to cancel
if its Return Code parameter is set to IDCANCEL (and then interrupts the
wizard if the end user specifies Yes). For all other Return Code IDs, the
wizard immediately closes.
• For secondary windows, the Close Window action closes the secondary
window and in special cases such as with the ISRMFilesInUse and
ISRMFileInUse secondary windows, the specified Return Code value is
returned.
• ISDownloadProgress
• ISPromptForSourceMedia
• ISFilesInUse
• ISRMFilesInUse
• ISUpgradeParcel
• ISSQLBrowse
Stop Event This type of action allows you to conditionally stop further actions from being
processed. For example, this action can be used to prevent the default
behavior of a button from occurring.
To learn more, see Configuring an Action for an Element in the Wizard Interface.
During a suite installation where the loading process takes more than half a second, InstallShield will now display a splash
screen to indicate that the program has launched and that a loading process needs to complete before the Install Welcome
dialog appears. For the splash screen, InstallShield utilizes the largest provided version of the setup.exe icon and includes
a progress bar on it.
• Basic MSI
• InstallScript MSI
A new Processes setting has been added to the Kill-Process Custom Action settings that lets you directly enter executable
file names or PIDs of the processes that you want to terminate without having to create a property using the Property
Manager and format its value correctly for the action to work.
Tip • The value of the Processes setting may be written to the ISTerminateProcesses property. If you have additional kill-
process custom actions that do not specify a value in the Processes setting, such as those migrated from InstallShield 2015 or
earlier, shared use of the ISTerminateProcesses property may result in undesired behavior.
For example, to make new components 64-bit, add 256 to the MsiComponentAttributes value. You can specify 264 (for 64-
bit shared) or optionally enter 256 (for 64-bit unshared). In doing so, the 64-Bit Component setting and Shared settings
(shown on the in the General area of the Components view) will be updated to Yes or No accordingly.
For more information about the bit values used in calculating the Attributes column of the Component table, refer to the
Component Table page in the MSDN Library.
Note • To set the default value used for component attributes, the MsiComponentAttributes property must be updated
manually in the InstallShield table in the Direct Editor of each project. The Template Summary setting for a product
configuration is ignored for this use case.
• Environment Variables View—You can use the View Filter list at the top of this view to show and hide environmental
variables that are associated to a particular feature in your project. You can also select a feature from the View List in
order to associate only that feature with a subsequent event (e.g., the creation, modification, or removal of an
environmental variable). Lastly, to see all of the environmental variables that are in your project, select the All
Application Data option in the View Filter list. For more information, see Environment Variables View.
• Text File Changes View—You can use the View Filter list at the top of this view to show and hide text file change sets
that are associated to a particular feature in your project. You can select a feature from the View List in order to
associate only that feature with a subsequent event (e.g., the creation, modification, ordering, or removal of change
sets). The resulting modification takes place at run time on the target system when the feature is installed. Lastly, to
see all of the text file change sets that are in your project, select the All Application Data option in the View Filter list.
For more information, see Text File Changes View.
• INI File Changes View—You can use the View Filter list at the top of this view to show and hide initialization (.ini) files
that are associated to a particular feature in your project. You can select a feature from the View List in order to
associate only that feature with a subsequent event (e.g., the creation, importing, modification, or removal of .ini
files). The resulting modification takes place at run time on the target system when the feature is installed. Lastly, to
see all of the .ini files that are in your project, select the All Application Data option in the View Filter list. For more
information, see INI File Changes View.
In InstallShield 2016, support for SHA-256 digital certificates has been enhanced for Windows Installer and InstallScript
projects to:
• Give you the ability to specify a digest type using the new Signature Digest drop-down on the Certificate Selection
Dialog Box
• RFC3161 timestamping is now supported and can be specified in settings.xml, noting that:
• DigitalSignature/@Timestamp can be an Authenticode or RFC3161 server for .msi, .exe, and .dll files
• DigitalSignature/@TimestampRFC3161 used for Windows App package files must be an RFC3161 server
Important • Any new signatures created or timestamped after Jan 1, 2016 must be SHA-256-based signatures. Any files
signed with an SHA-1 certificate need to have a timestamp showing a date and time prior to Jan 1, 2016 in order to continue to
be supported. Those files will still be allowed through the 'Mark-of-the-web" system until Jan 14, 2020, when all SHA-1 support
will stop in all current versions of Windows.
New Features
InstallShield includes the following new features.
InstallShield includes a new InstallShield prerequisite that can be used when including a Setup.exe for a generated App-V
5.x package. Note that a Setup.exe setup launcher is required if the InstallShield prerequisite needs to be included in the
release:
The redistributable file for this InstallShield prerequisite is not available for download from within InstallShield, since you
must obtain it from Microsoft. Once you obtain the redistributable from Microsoft, place it in the location that is displayed
when you are editing the prerequisite in the InstallShield Prerequisite Editor. For more information on the prerequisites
necessary, see https://technet.microsoft.com/en-us/library/mt346482.aspx.
Windows 10 Added to Operating System Options in App-V Assistant for App-V 5.x Versions
App-V 5.1 introduced support for Windows 10 32-bit and 64-bit operating systems. Accordingly, on the Package
Information page of the Microsoft App-V Assistant, the list of available operating systems that are displayed when App-V 5.x
is selected has been updated to include:
• Windows 10 32-bit
• Windows 10 64-bit
New InstallShield Prerequisites for Microsoft Visual C++ 2015 and .NET Framework 4.6
InstallShield includes new InstallShield prerequisites that you can add to Advanced UI, Basic MSI, InstallScript, InstallScript
MSI, and Suite/Advanced UI projects:
DLG_INFO_ALTIMAGE_HIDPI—This constant specifies a high DPI image to be displayed in the dialog. High DPI image types
supported include BMP, GIF, JPEG, PNG, and TIFF. If transparency is required, image types that support transparency (such
as PNG) should be used and szInfoString should specify the name of the image to be displayed (optionally including the
path) in the dialog. This parameter applies to all dialogs that display the standard installation image on the left side of the
dialog.
When DLG_INFO_ALTIMAGE_HIDPI is passed in nInfoType, the following parameter values are expected:
• szInfoString—The name of an image file to display, optionally including the path. If no path to the file is specific, the
file is assumed to be in SUPPORTDIR. If this file does not exist, DialogSetInfo returns ISERR_FILE_NOT_FOUND.
• nParameter—The DPI scaling percentage. For example, pass 200 for a 200% image scale, 150 for a 150% scale, etc. The
minimum supported scaling value is 25. If 0 is passed for this value, no image is displayed. If
DLG_INFO_ALTIMAGE_REVERT_IMAGE is passed, the previous image used is displayed.
This functionality is available in InstallScript events in the following project types: InstallScript and InstallScript MSI.
For more information, see Selecting the Appropriate Type of Architecture Validation for Builds.
New Features
InstallShield includes the following new features.
Targeting Windows 10
On systems with Windows 10, the Windows Installer properties VersionNT and VersionNT64 indicate 603, which was
originally introduced as the version number of Windows 8.1. Therefore, it is not possible to create conditions in an .msi
package that specifically target Windows 10.
Since Windows Installer 5.0 and Windows 7, DLL custom actions in .msi packages are shimmed to block obtaining the
operating system version; the APIs GetVersion, GetVersionEx, and RtlGetVersion return a Windows version of 6.0.6000,
which was originally the version number of Windows Vista. Therefore, it is also not possible to obtain the actual version
number of Windows from a DLL custom action or from an InstallScript custom action (which is implemented as a DLL).
Because of the aforementioned behavior in Windows Installer, it is not easily possible to detect what version of Windows
on which an .msi package is running. In areas where you can specify target system OS requirements, such as the
Installation Requirements page in the Project Assistant of Basic MSI and InstallScript MSI projects, the Windows 8.1 option
has been renamed as Windows 8.1 or Windows 10 to reflect the new run-time behavior.
InstallScript, Advanced UI, and Suite/Advanced UI projects provide the ability to properly detect which version of Windows
(including Windows 10) is present on a target system. Thus, if your installation needs to target or exclude Windows 10, you
may want to use these types of projects to create conditions under which .msi packages should be run based on the actual
target system platform.
The InstallShield prerequisites that should be installable on Windows 10 have been updated so that they are installed on
those systems if needed. Previously, the prerequisites may not have run by default on those systems.
The following structure members and predefined constants were added to the InstallScript language:
• SYSINFO.WINNT.bWin10—This is a new SYSINFO structure member. If the operating system is Windows 10, this value
is TRUE. (This is applicable to InstallScript event-driven code; it is not applicable to custom actions.)
• ISOSL_WIN10—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 10.
For more information, see FeatureFilterOS function and the SYSINFO structure variable.
InstallShield now enables you to use digital certificates that use the SHA-256 hashing algorithm for signing your
installations and files at build time.
SHA-256 is favored over SHA-1, which is being deprecated because of the potential for security vulnerabilities. Microsoft
announced that Windows will stop trusting items that were signed and timestamped with SHA-1 certificates after January
1, 2016. In addition, certification authorities—the organizations that issue certificates—are phasing out the creation of
SHA-1 certificates. Thus, it is recommended that you replace any SHA-1 certificates in your InstallShield projects with SHA-
256 certificates. For the latest information and more specific details, check with your certification authority.
In InstallShield, to replace a SHA-1 certificate with a SHA-256 certificate for signing your releases, use the Signing tab in the
Releases view to replace the reference to the current certificate with one for a SHA-256 certificate.
If your project is configured to sign with a SHA-256 certificate, InstallShield uses a SHA-256 hash in the signature of the files
that it signs at build time. If your project is still configured to sign with a SHA-1 certificate, InstallShield uses a SHA-1 hash;
in addition, use of a SHA-1 certificate now triggers build warning -7346 to alert you about the SHA-1 usage.
In earlier versions of InstallShield, InstallShield used a SHA-1 hash in the signature of files when signing with either SHA-1
and SHA-256 certificates.
When you are specifying the digital signature information that you want to use for signing your files and installations,
InstallShield now lets you reference a certificate store that contains the certificate that you want to use. This support is
available as an alternative to specifying a .pfx certificate file on your machine.
To specify whether you want to use a certificate store or a .pfx certificate, use the Digital Certificate File setting on the
Signing tab in the Releases view. When you click the ellipsis button (...) in this setting, a new Certificate Selection dialog box
opens, enabling you to specify certificate information such as the store name (Personal, Trusted Root Certification
Authorities, Enterprise Trust, Intermediate Certification Authorities), the store location (user or machine), and the subject
that identifies the specific certificate that you want to use. As an alternative, you can specify on this dialog box the path and
file name of a .pfx file that you want to use.
If you configure your project to use a certificate that was imported with password protection into a store, Windows
prompts for the password at build time when InstallShield is attempting to sign your project’s files. The strong key
protection that Windows uses does not permit InstallShield to provide the password to the cryptographic provider.
Certificate store support is also available for signing patches and QuickPatch packages:
• To specify certificate store or .pfx certificate information for a patch, use the Digital Signing tab for a patch
configuration in the Patch Design view.
• To specify certificate store or .pfx certificate information for a QuickPatch package, use the Build Settings area of the
General Information view in the QuickPatch project. This area includes a Digital Signature tab that includes the new
support.
In addition, the command-line tool iSign.exe, which is available for signing already-built InstallScript releases, has been
updated to include support for using certificates in certificate stores.
• Digital Signature Tab (for a patch configuration in the Patch Design view)
• iSign.exe
Note that InstallShield no longer has support for signing with .spc and .pvk files. To learn how to convert those files to a .pfx
file, see Digital Signing and Security.
The Signing tab in the Releases view includes a new Signature Description setting. Use this setting to specify the text that
you want to be displayed to the right of the “Program Name:” label on the UAC dialog box for the Setup.exe files, the .msi
file, and other installation files that InstallShield signs at build time. The UAC dialog box opens when an end user launches
the signed file and elevated privileges are required.
If you leave the Signature Description setting blank, InstallShield uses the name of the file without its extension as the text
on the UAC dialog box.
Ability to Digitally Sign Media Header Files with a .pfx File or a Certificate in a Certificate Store
InstallShield now has support for using .pfx files to sign media header files (.hdr files), which are used for the One-Click
Install type of installation for InstallScript projects. As an alternative, you can use a certificate in a certificate store to sign
media header files.
Previously, it was necessary to sign with .spc and .pvk files instead of .pfx files.
The automation interface has support for specifying the .pfx file and the certificate store information. In addition, it also
has support for specifying the signature description.
In Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, and Merge Module projects, the ISWiReleases object
includes two new read-write string properties.
• DigitalCertificateInfo—This property gets or sets either the path to the .pfx file on your machine, or to a string that
indicates certificate store details.
In Advanced UI and Suite/Advanced UI projects, the ISWiSuiteReleases object includes these same new properties. For
more details, see ISWiSuiteRelease Object (Advanced UI and Suite/Advanced UI).
Ability to View Both the 32- and 64-Bit Areas of the Source Machine’s Registry on 64-Bit Development
Systems
If you are using InstallShield on a 64-bit development system, the Registry view in InstallShield now displays both the 32-
bit and 64-bit areas of your machine’s registry:
• HKEY_LOCAL_MACHINE\Software
• HKEY_LOCAL_MACHINE\Software\Wow6432Node
This support makes it easier to develop installations on 64-bit machines, since it enables you to drag and drop entries from
those source areas to the appropriate areas in the destination pane of this view.
Previously, if you were using InstallShield on a 64-bit development system, the source panes in the Registry view in
InstallShield did not show any 64-bit data from the HKLM\Software part of the registry; in addition, the source panes
displayed 32-data from the machine’s HKLM\Software\Wow6432Node area in the HKLM\Software area.
Note that if you want your installation to install registry data to a 64-bit area of the registry on 64-bit target systems without
having it redirected to a 32-bit area, you must place the registry data in a component that is marked as 64 bit. Simply
dragging 64-bit data from the source panes in the Registry view to a location in one of the destination panes of the view
does not mark the component as 64 bit.
This feature is available in the following project types: Basic MSI, DIM, InstallScript, InstallScript MSI, InstallScript Object,
Merge Module, MSI Database, MSM Database, and Transform.
• Registry View
Support for Embedding Formatted Expressions in Advanced UI and Suite/Advanced UI Projects for Run-
Time Resolution
In various areas of Advanced UI and Suite/Advanced UI projects, you can now embed object expressions to query target
systems for information about a file, a registry entry, the operating system, or other details. This enables you to
dynamically configure many of the Advanced UI or Suite/Advanced UI settings at run time based on target system–specific
conditions. Object expressions use this convention:
Each object expression contains a reference to an object, which is a collection of object-specific properties. Objects and
properties may contain parameters.
For example, the following Platform object expression obtains the architecture (x86, x64, IA64, ARM, or Unknown) of the
machine on which the Advanced UI or Suite/Advanced UI installation is running:
[@Platform.Architecture]
The following Registry object expression obtains the value data of the RegisteredOwner value for the HKLM\Software\My
Company Name\My Product Name registry key:
[@Registry(HKLM\Software\[COMPANY]\[PRODUCT], true).KeyValue(RegisteredOwner)]
You can embed object expressions within other formatted expressions, such as within property expressions or other object
expressions. In the following expression, a Registry object expression is embedded as part of the parameter to a File object
expression.
[@File([@Registry(HKLM\Software\MyProduct).KeyValue(MyProductPath)]\MyProduct.exe).Version]
If the MyProduct.exe file is in the location that is specified for the MyProductPath value data, the File object expression
returns the version of the file. If the file is not found in that location, or if the registry value does not exist, the File object
expression returns an empty string.
InstallShield also now enables you to pass literal square brackets as part of strings through the command line to packages
in an Advanced UI or Suite/Advanced UI installation. For example, a command line such as [\[]Text[\]] resolves as
[Text] at run time and is passed to the package with the square brackets. Previously, a string enclosed within square
brackets was treated as a property that the installation attempted to resolve at run time. The only work around was to use
a formatted property expression (such as [PropertyForSquareBracketString]) that would be resolved at run time to a
property value that included the square brackets.
• Using Formatted Expressions that Advanced UI and Suite/Advanced UI Installations Resolve at Run Time
• Writing Object Expressions in Advanced UI and Suite/Advanced UI Projects to Search Target Systems
• Feature Object
• File Object
• Parcel Object
• Platform Object
• Registry Object
Ability to Share Common Packages Among Different Advanced UI and Suite/Advanced UI Installations
When you are configuring a package for an Advanced UI or Suite/Advanced UI installation, you can now mark it as shared.
The shared package functionality helps to ensure that if two or more Advanced UI or Suite/Advanced UI installations are
sharing a package, the package remains on the target system until all of the Advanced UI and Suite/Advanced UI products
are removed.
To mark a package that is selected in the Packages view of an Advanced UI or Suite/Advanced UI project as shared, select
Yes for the new Shared setting. In addition, ensure that the package GUID is the same across all Advanced UI and Suite/
Advanced UI projects that are sharing the package; the Package GUID setting in the Packages view is where you can view
and modify the GUID of a package.
Before this built-in shared support was available, unexpected results may have occurred in various scenarios. For example,
in some scenarios, if two different Advanced UI or Suite/Advanced UI installations installed a shared package on a target
system and then only one was uninstalled, the shared package was removed. The remaining Advanced UI or Suite/
Advanced UI product may have been unusable because of the missing shared package. In other scenarios, the shared
package was erroneously left behind on a target system, even though no Advanced UI or Suite/Advanced UI product
remained.
This feature is available for the following types of packages in Advanced UI and Suite/Advanced UI projects: .msi, .msp,
.exe, .appx, InstallScript, Basic MSI project, and InstallScript project.
• Packages View
Ability to Override the Product Name, Product Version, and Suite GUID for a Release in an Advanced UI or
Suite/Advanced UI Project
InstallShield now lets you override the product name, product version, and Suite GUID values that are specified in the
General Information view of your Advanced UI or Suite/Advanced UI project with a new value for a selected release. To
override the General Information view values, use the new settings that are available on the Build tab for a release in the
Releases view: Product Name, Product Version, and Suite GUID.
Ability to Override the Values of Path Variables for a Release in an Advanced UI or Suite/Advanced UI
Project
InstallShield now lets you override the values of your project’s custom path variables (standard path variables,
environment path variables, and registry path variables) for each release in your project. This functionality enables you to
essentially replace certain files and folders in your project with others at build time, depending on the particular release
that you are building.
For example, you might want to use this functionality to swap out UI elements such as images and EULAs for different
releases in your project; this would enable you to easily generate installations for different editions or branded versions of
your product.
To override one or more path variables in your project, use the Path Variables Overrides setting, which is on the Build tab
for a release in the Releases view.
The top-level automation object for Advanced UI and Suite/Advanced UI projects is the ISWiProject object. Sample
VBScript code that opens, modifies, saves, and closes a project begins and ends like this:
By calling methods, getting and setting properties, and accessing collections, you can also add features and packages to
your project, configure conditions, and more. For more information, see the following sections of the documentation:
Note that the ProgID for the Advanced UI and Suite/Advanced UI automation interface is ISWiAutoSuiteAutomation
Interface Version.ISWiProject; the ProgID for other project types is simply ISWiAutoAutomation Interface
Version.ISWiProject.
New InstallShield Prerequisites for Microsoft Visual C++ 2015, .NET Framework 4.6, and More
InstallShield includes new InstallShield prerequisites that you can add to your projects:
• Microsoft SQL Server 2012 Express SP2 System CLR Types (x86)
• Microsoft SQL Server 2012 Express SP2 System CLR Types (x64)
• Internet Explorer 11.0 for Windows 7 and Windows Server 2008 R2 (x64)
The Microsoft SQL Server 2012 Express SP2 prerequisites replace the Microsoft SQL Server 2012 Express SP1 prerequisites.
Support for Creating Virtual Applications for Microsoft App-V 5.0 SP3; Additional App-V Package
Improvements
InstallShield and the Microsoft App-V Assistant in InstallShield include support for creating virtual applications that can run
on Microsoft App-V 5.0 SP3 clients. In addition, the Microsoft App-V Assistant includes new settings and capabilities—some
of which apply to App-V 5.0 SP3, and some of which apply to earlier versions of App-V.
InstallShield includes new InstallShield prerequisites that you can add to Advanced UI, Basic MSI, InstallScript, InstallScript
MSI, and Suite/Advanced UI projects:
The redistributable files for these InstallShield prerequisites are not available for download from within InstallShield, since
you must obtain them from Microsoft. Once you obtain one of the redistributables from Microsoft, place it in the location
that is displayed when you are editing the prerequisite in the InstallShield Prerequisite Editor.
Ability to Map Files into the Virtual File System Instead of a Primary Application Directory
The Microsoft App-V Assistant now enables you to configure your App-V package to map files into the virtual file system
(VFS). This support is available for App-V 4.x and 5.x packages.
To specify whether you want to map the files to the VFS or use a primary application directory, use the Files page in the
Microsoft App-V Assistant. The More Options area on this page has a new File Mapping link. When you click this new link, a
new File Mapping dialog box opens, enabling you to select the appropriate option.
The File Mapping link and dialog box replace the Primary Application Directory link and dialog box, which previously
enabled you to specify primary application directory.
Ability to Create App-V 5.x Packages that Have Full Write Permissions to the Virtual File System
The Microsoft App-V Assistant now enables you to specify whether you want an App-V 5.x package that you are creating to
have full write permissions to the virtual file system (VFS). To specify whether you want to use this support, use the new
Allow full write permission to the VFS check box. This check box is on the File Mapping dialog box, which is available from
the Files page in the Microsoft App-V Assistant when you click the File Mapping link in the More Options area.
The Microsoft App-V Assistant now enables you to configure advanced settings for COM isolation. This support is available
for App-V 5.x packages.
To configure the new settings, use the Package Information page in the Microsoft App-V Assistant. The More Options area
on this page has a new Isolation Settings link. When you click this new link, a new Isolation Settings dialog box opens. This
dialog box enables you to specify whether you want to isolate the COM objects from the local system, or allow them to
interact with the local system. This dialog box also lets you indicate whether you want to isolate named objects from the
local system, or allow them to interact with the local system.
Enhancements
• To see in this view only files and folders that belong to a particular feature, select that feature in the View Filter list.
• To add a file or folder to a specific feature, select that feature in the View Filter list. Then add the file or folder to the
appropriate location in the Destination computer’s folders pane.
• To see all of the files and folders that are in your project, select the All Application Data option in the View Filter list.
The new View Filter replaces the previous Add new components to the feature filter, which did not have support for
showing and hiding files and folders in the view according to the selected feature.
Ability to Access the Installer Session from PowerShell Scripts in Basic MSI and InstallScript MSI
Installations
The PowerShell custom action support has been enhanced. It now includes support for several cmdlets that let you
interact with the running Basic MSI or InstallScript MSI installation at run time. The cmdlets enable you to get and set
Windows Installer properties, expand the value of formatted expressions, and write information to the log file.
With this revised implementation, you can use the Windows Installer property IS_CLR_VERSION to identify a semicolon-
delimited list of .NET Framework versions that the custom action should attempt to load to run your PowerShell script.
• Upgrades View
• Major Upgrades
• Upgrade Considerations
• Preventing the Current Installation from Overwriting a Future Major Version of the Same Product
Improvements to the ISHiddenProperties Property for Preventing Passwords from Being Written in
Advanced UI and Suite/Advanced UI Log Files
The ISHiddenProperties property stores a semicolon-delimited list of case-sensitive property names whose values you do
not want to be written to the debug log files. This property enables you to prevent properties that contain passwords and
other sensitive information from being logged. The ISHiddenProperties property has been improved. You can now use
this property for prevention of logging for values in the following scenarios:
• The end user sets the value of the property through command line when launching the Advanced UI or Suite/
Advanced UI Setup.exe file.
• The property is configured through a command line that the Advanced UI or Suite/Advanced UI installation passes to a
package. This is configurable in the Packages view, on the Common tab, in the Operation area.
Previously, ISHiddenProperties prevented logging only values that would be logged by changing the property value.
For more information, see Preventing a Property Value from Being Written in Advanced UI and Suite/Advanced UI Debug
Log Files.
Improvements to the Interpretation of Ampersands in the Wizard Interface of Advanced UI and Suite/
Advanced UI Installations
The interpretation of ampersands in certain areas of the wizard interface of Advanced UI and Suite/Advanced UI projects
has been modified.
If you use an ampersand (&) in any of the following areas of the wizard interface of your installation, the installation now
displays the ampersand as a literal character instead of interpreting it as a prefix character for a keyboard shortcut. The
change also applies if any of these strings include a property that resolves to a value that contains an ampersand.
• The string in the header area of a wizard page or secondary window—This is configured in the Title setting for a wizard
page or window in the Wizard Interface view.
• The caption bar of wizard pages—This is configured in the Wizard Caption setting for the Wizard Pages node in the
Wizard Interface view.
• The supplemental explanation area of a command link control—This is configured in the Note setting for a wizard
page or window.
• The alternate text for an image control—This is configured in the Alt Text setting of an image control on a wizard page
or window.
For most label controls, True is now selected by default for the SS_NOPREFIX subsetting under the Style setting; previously
False was selected by default. A True value for this subsetting ensures that any ampersands that are included in the string
entries for such controls are not inadvertently interpreted as keyboard shortcuts, and that ampersands in the control’s
strings are displayed as ampersands in the wizard interface. This applies to the built-in default wizard pages and windows,
as well as the predefined wizard pages. The only exceptions to this SS_NOPREFIX subsetting change are label controls that
may contain keyboard shortcuts. For example, the default predefined Web Deploy wizard page has several text boxes with
corresponding labels that may contain keyboard shortcuts. Therefore, False continues to be default value for the
SS_NOPREFIX subsetting of such controls.
The InstallShield Help Library has a new Designating Keyboard Shortcuts and Using Ampersands (&) in the Wizard Interface
help topic that explains how to configure your project to support the use of ampersands and keyboard shortcuts in your
wizard interface.
Note that when you upgrade an InstallShield 2014 or earlier Advanced UI or Suite/Advanced UI project to InstallShield
2020, many of the aforementioned changes for ampersand interpretation are made automatically made; however, some
changes are not made. To learn more, see Upgrading Projects from InstallShield 2014 or Earlier.
Enhanced File-Related Types of Condition Checks Can Search Multiple Target System Paths in Advanced
UI and Suite/Advanced UI Installations
When you are building a conditional statement for an exit, detection, eligibility, feature, or wizard interface condition in an
Advanced UI or Suite/Advanced UI project, or for an action condition in a Suite/Advanced UI project, you can use the
following file-related types of condition checks:
• File Exists—This type checks target systems for the presence of a particular file.
• File Comparison—This type checks target systems for specific information—date, version number, or component—
for a particular file.
Both of these condition checks have been expanded to enable you to define conditions that check for the file in multiple
paths on target systems. Previously, each condition could check only one specific location on target systems.
To enable this support, the existing Path setting for these condition checks has been expanded to let you enter only the
name of the file (that is, optionally now without the path); if you leave out the path, you can use the new Search Path
setting to specify a semicolon-delimited list of paths that you want the installation to check at run time for the specified
file. You can include in this setting one or more formatted expressions that contain property names, environment variable
references, and other special strings; at run time, the installation expands the values of these expressions.
For example, to search for the specified file in all directories that are defined for the PATH environment variable on a target
system, as well as the path that is defined in the registry, enter the following value in the Search Path setting:
[%PATH];[@Registry(HKLM\SOFTWARE\MyPath).KeyValue(MyValue)]
Improvements for Importing InstallShield Prerequisites with Certain Types of File-Related Condition
Checks in Advanced UI and Suite/Advanced UI Projects
Advanced UI and Suite/Advanced UI projects now have support for the following conditions that InstallShield prerequisites
support:
• If you use the condition A file does or does not exist or A file with a certain date exists in a prerequisite and if you
reference a registry key within square brackets for part of the path to the file, a Basic MSI, InstallScript, or InstallScript
MSI installation resolves the registry key with the registry value. Now that Advanced UI and Suite/Advanced UI
installations have expanded formatted-expression support for conditions, these types of prerequisite conditions are
properly imported into Advanced UI and Suite/Advanced UI projects and resolved at run time. Previously, the registry
key within square brackets was not resolved at run time; therefore, these types of conditions always evaluated as
false.
• If you use the condition A file does or does not exist or A file with a certain date exists in a prerequisite and if you
omit the path to the file, a Basic MSI, InstallScript, or InstallScript MSI installation searches for the specified file in all
directories that are defined for the PATH environment variable on the target system. Now that Advanced UI and Suite/
Advanced UI installations have expanded formatted-expression support for conditions, these types of prerequisite
conditions are properly imported into Advanced UI and Suite/Advanced UI projects and resolved at run time.
Previously, the path to the file could not be resolved; therefore, this type of condition always evaluated as false.
The InstallShield prerequisites for Oracle Instant Client are examples of prerequisites that use the file-related conditions.
Now if you import these types of InstallShield prerequisites into Advanced UI or Suite/Advanced UI projects, those file-
related conditions are configured properly in the Detection Condition setting of the Packages view.
For more information, see Including InstallShield Prerequisites (.prq) in an Advanced UI or Suite/Advanced UI Project.
This enhancement is available for the following project types: Advanced UI, Basic MSI, DIM, InstallScript, InstallScript MSI,
InstallScript Object, Merge Module, and Suite/Advanced UI.
• ISWiProject Object
Ability to Select the Virtual Machine Configuration for a Release Through the Automation Interface
The automation interface has support for selecting the virtual machine configuration for a given release; this enables you
to specify which configuration you want to use for distributing the selected release to a virtual machine (VM) at build time.
In Basic MSI, InstallScript, and InstallScript MSI projects, the ISWiReleases object includes several new read-write
properties. In Suite/Advanced UI projects, the ISWiSuiteRelease object includes the same new read-write properties.
• VMConfig—This property gets or sets the name of the group of VM configuration settings that you want to use when
distributing a release to a VM.
• VMSnapShot—This property optionally gets or sets the name of the snapshot that you want to use for distributing the
release.
If no snapshot is specified for the VM configuration, InstallShield does not revert to a specific snapshot. InstallShield
powers on the VM without reverting it to a specific snapshot, and copies your installation to the VM.
• VMMachineUserName—This property gets or sets the user name for the VM configuration.
• VMStageMachineCopyPath—This property gets or sets the location on the VM where the release is to be distributed.
The last subfolder in the path can be a path that InstallShield creates on the VM; the other folders in the path must
already exist.
• VMStagePostBuild—This Boolean property indicates whether you want InstallShield to automatically distribute the
selected release each time that it is successfully built.
• ISWiRelease Object
Enhancement to ISICE11
InstallShield internal consistency evaluator 11 (ISICE11) has been improved. If an executable file in your project includes a
valid manifest that includes an asm.v2 entry for the trustInfo element, ISICE11 no longer occurs during validation.
Previously, the asm.v3 entry was checked, but not the asm.v2 entry.
Enhanced Dialogs View in Basic MSI, DIM, and Merge Module Projects: All Behavior Settings for Each
Control Are Shown in a Single Grid
The Dialogs view has been enhanced. All of the settings that are available for configuring the behavior (events,
subscriptions, and conditions) of each user interface control on a run-time dialog are now displayed in a single grid.
Previously, the settings were available through separate Events, Subscriptions, and Conditions tabs that were displayed in
the bottom-right corner of the view.
To add an event, a subscription, or a condition to a control, in the Dialogs view, select the Behavior node under the dialog
that contains the control. The controls that are used on the dialog are displayed in the center pane; select the control that
you want to configure. Then use the Events, Subscriptions, and Conditions settings that are displayed in the right pane to
configure the appropriate behavior.
This enhancement applies to the following project types: Basic MSI, DIM, Merge Module.
Enhanced Folder Views Show Total Count of Each Item in the Current Project
The folder views in InstallShield now enable you to see a quick summary of the contents of your project.
For example, the Application Data view—which is the folder view that contains the Files and Folders view and the
Redistributables view in some types of projects—indicates the number of files, the number of merge modules, and the
number of InstallShield prerequisites that are in the current project. The System Configuration view—which is the folder
view that contains views such as Shortcuts and Registry— shows summary data such as the number of shortcuts, the
number of registry keys, and the number of registry values.
When this check box is selected, you delete all of the files in a component, and that component is not required elsewhere,
that component is deleted automatically.
This new check box is a machine-wide setting. This check box is cleared by default; therefore, unused components are not
removed automatically by default.
Enhanced Behavior for Deleting Custom Actions that Use a File in the Binary Table
When you are deleting from your project a custom action that uses a file in the Binary table, InstallShield now determines
whether the file in the Binary table is referenced by any other custom actions in the project. If it is not referenced by any
other custom actions, InstallShield prompts you to specify whether you want to delete the entry from the Binary table
while also deleting the custom action:
• The No button, which is the default selection, enables you to delete only the custom action.
• The Yes button enables you to delete both the custom action and the Binary table entry.
• The Cancel button enables you to avoid deleting the custom action and the Binary table entry.
If one or more other custom actions in the project reference the file in the Binary table, InstallShield deletes only the
custom action that you chose to delete; it does not delete the Binary table entry. In this scenario, InstallShield does not
display any prompt when you are deleting the custom action.
Previously, when you were deleting a custom action in the aforementioned scenario, InstallShield always displayed a
prompt asking whether you wanted to delete the entry in the Binary table—regardless of whether any other custom
actions in the project referenced it. The default button on this prompt was Yes, which resulted in both the custom action
and the Binary table entry being deleted; this default behavior led to some users inadvertently deleting the Binary table
entry.
This enhancement is applicable to the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, and
Transform.
• Product Code—This registry value differs, depending on whether the InstallShield IDE or the Standalone Build is
installed. It is updated for major upgrades of these tools.
• MPIndicator—If applicable, this registry value indicates the maintenance pack—for example, Service Pack 1.
• SP—If applicable, this registry value indicates the number of the service pack—for example, 1.
For InstallShield 2020 and the InstallShield 2020 Standalone Build, the registry values are installed under the following key:
See Also
Upgrading Projects from InstallShield 2014 or Earlier
See Also
What’s New in InstallShield 2014
New Features
InstallShield includes the following new features.
These prerequisites install the .NET Framework 4.5.1 on supported target systems.
If your installation targets SQL Server 2014, 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 2014, SQL Server 2014 Express, and SQL Server 2014
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 2014 database server.
This support is available in the following project types: Basic MSI, DIM, InstallScript, and InstallScript MSI.
The redistributable files for these InstallShield prerequisites are not available for download from within InstallShield, since
you must obtain them from Microsoft. Once you obtain one of the redistributables from Microsoft, place it in the location
that is displayed when you are editing the prerequisite in the InstallShield Prerequisite Editor.
Support for Checking for Updates from Maintenance Mode of Advanced UI and Suite/Advanced UI
Installations
Advanced UI and Suite/Advanced UI installations now have support for enabling end users to check for updates to your
product by clicking a new Update button on the maintenance wizard page. If an update is available from your Web site and
the end user chooses to obtain it, the installation downloads it, verifies its digital signature, and launches it.
To use this functionality, your Advanced UI or Suite/Advanced UI project must have support for automatic updates. At build
time, InstallShield creates a metadata file called isupdate.xml file and places it in an UpdateMetadata subfolder in your
project’s build folder. This metadata file identifies the different versions of your Advanced UI or Suite/Advanced UI
installation and their download locations. When you are ready to release the update for your product, you upload to your
site this isupdate.xml file as well as your updated Advanced UI or Suite/Advanced UI installation.
At run time, if the end user is running maintenance mode, the Suite engine checks the metadata file for updates. If an
update is available for download, the Suite engine sets the new ISUpdateAvailable property to 1 and displays a new
MaintenanceUpdateWelcome wizard page, a maintenance wizard page that includes an Update button. In addition, the
Suite engine sets the new ISUpdateVersion property equal to the version of the Suite/Advanced UI or Advanced UI
installation that is available for download.
If an update is not available, the Suite engine displays the standard MaintenanceWelcome wizard page that does not have
an Update button.
The improved Support Files view is available in the following project types: Advanced UI, Basic MSI, Suite/Advanced UI,
InstallScript, and InstallScript MSI.
The automation interface also includes subfolder functionality for support files. The ISWiSetupFile object includes a new
read-write Target property that you can use to specify or obtain the path of the support file’s target directory within
SUPPORTDIR. For more information, see ISWiSetupFile Object.
Support for Deploying Web Deploy Packages to IIS Web Servers and the Cloud
Suite/Advanced UI installations now have built-in support for deploying Web Deploy packages to IIS Web servers and the
cloud. The Web Deploy packages can be created through IIS or a Web application development environment such as Visual
Studio.
To add a Web Deploy package to your Suite/Advanced UI project, use the Packages view. When you add a package and
select it in the Packages view, InstallShield displays package-related settings in the right pane. The Configuration area on
the Common tab of the right pane includes several configuration-related settings for Web Deploy, such as the destination—
which is often a remote server—and credentials. In addition, the Configuration area also includes settings for the
parameters that are defined in the Web Deploy package’s parameters XML file. By default, InstallShield uses Suite/
Advanced UI properties for all of the configuration settings so that end users can set them at run time through the wizard
interface or the command line.
When you add a Web Deploy package to your project, InstallShield adds a predefined Web Deploy wizard page to your
project for that package. The Web Deploy wizard page enables the end user to specify whether the package will be
deployed to a local IIS server, a remote server, or a cloud-based server. It also enables the end user to load the
configuration settings from a publisher profile file (.publishsettings). If you want end users to be able to configure the
parameters that are defined in your Web Deploy package’s parameters XML file, you can add controls to the wizard
interface as needed, and associate those controls with the properties that are specified for the corresponding parameter
settings in the Packages view.
Note that Web Deploy packages are typically intended to behave similarly to first-time installations or to install over
existing earlier or identical versions. As a side effect, Web Deploy packages do not handle uninstallation. Thus, Suite/
Advanced UI installations do not offer maintenance for this type of package. It is recommended that you avoid creating a
Suite/Advanced UI installation that combines one or more Web Deploy packages with one or more traditional packages
(that do offer maintenance) as primary packages.
• Packages View
When you start a build of a release for a Suite/Advanced UI project that includes one or more InstallShield project
packages, InstallShield first builds the designated releases in the associated InstallShield projects, and includes them as
packages in the Suite/Advanced UI installation that it generates. InstallShield adds the output of the Basic MSI and
InstallScript projects to the Suite/Advanced UI installation as .msi and .hdr packages.
Use the Packages view to add an InstallShield project as a package in your Suite/Advanced UI project. This view is also
where you identify which product configuration (for a Basic MSI project package) and which release (for both Basic MSI
project packages and InstallScript project packages) that you want to include as a package in the Suite/Advanced UI
project.
• Packages View
You can use the InstallScript view that is available now in Suite/Advanced UI projects to add InstallScript files (.rul) to your
project and write functions using the InstallScript language. To have your Suite/Advanced UI action call an InstallScript
function, you must prototype the function with the export keyword, just as you would for InstallScript custom actions in
Basic MSI projects.
Once you have added InstallScript code to your project, use the Events view to add an InstallScript action that calls your
code. Next, you can schedule when at run time you want the action to be launched. For example, you can use the Events
view to schedule an InstallScript action to run during one or more of the built-in events that the Suite/Advanced UI engine
manages.
Note that there are some limitations to the use of InstallScript in Suite/Advanced UI projects. For example, InstallScript UI–
related functions and InstallScript run-time path variables (such as PROGRAMFILES and WINDIR) are not available for use in
a Suite/Advanced UI project.
Ability to Launch Suite/Advanced UI Event Actions that End Users Trigger When Using Wizard Interface
Controls
Suite/Advanced UI installations include support for run-time actions that are defined in the Events view and that are
launched when an end user clicks or performs some other action on a wizard interface control. For example, this capability
enables your installation to run executable files, call DLL functions, run InstallScript code, call managed methods in a
managed assembly, run PowerShell scripts, or set a Suite/Advanced UI property when an end user clicks a button in the
wizard interface.
To schedule an action to run when a wizard interface control is clicked or used, select the control that you want to
configure in the Wizard Interface view, and then use the Click setting or an action-related setting under the Events setting
to select the action that you want to launch.
Ability to Launch Suite/Advanced UI Actions When Wizard Pages and Windows Are Shown or Hidden
Suite/Advanced UI installations include support for run-time actions that are launched when a wizard page or secondary
window is opened or closed. This capability enables your installation to perform any initialization such as dynamically
retrieving values for a combo box. It also lets you schedule actions to occur before the wizard interface is displayed at run
time.
To schedule an action to run when a wizard page opens or closes, select the wizard page that you want to configure in the
Wizard Interface view, and then select the appropriate action in the Page Entered setting or the Page Exited setting.
To schedule an action to run when a secondary window opens or closes, select the secondary window that you want to
configure in the Wizard Interface view, and then select the appropriate action in the Window Entered setting or the Window
Exited setting.
New Property for Preventing Passwords from Being Written in Advanced UI and Suite/Advanced UI
Installation Log Files
If you launch an Advanced UI or Suite/Advanced UI Setup.exe file with the /debuglog parameter, the Suite engine
generates a debuglog file. By default, the debug log file includes the values of changed Advanced UI or Suite/Advanced UI
properties.
In some cases, you may want to prevent the Suite engine from writing the values of specific properties to the debug log file.
For example, you may want to prevent properties that contain passwords and other sensitive information from being
logged. To enable this scenario, Advanced UI and Suite/Advanced UI installations support a new property called
ISHiddenProperties. You can set this property to a semicolon-delimited list of case-sensitive property names whose
values you do not want to be written to debug log files.
Note that ISHiddenProperties is useful for prevention of logging only for values that would be logged by changing the
property value. If the property is logged any other way (such as through ISuiteExtension::LogInfo), the Suite engine cannot
prevent the logging. Therefore, any code that you create to write a property value to the log file should read
ISHiddenProperties to see whether the property value should be logged.
For more information, see Preventing a Property Value from Being Written in Advanced UI and Suite/Advanced UI Debug
Log Files.
• Special characters—Preceding a special character with a backslash and enclosing the resulting string in square
brackets resolves the special character at run time. For example, an entry such as [\[]Text[\]] resolves as [Text].
• Null character—A tilde that is enclosed in square brackets—that is, [~]—resolves as a null character embedded in the
string.
• Environment variables—Preceding the name of an environment variable with a percent sign and enclosing the
resulting string in square brackets resolves the environment variable at run time. For example, [%PATH] resolves as the
value of the PATH environment variable.
• Recursive property resolution—Surrounding a property resolution with additional square brackets resolves the
resolved value of a property. For example [[PROPERTY1]] resolves to the value of the property whose name is stored
in PROPERTY1; if PROPERTY1 holds PROPERTY2, the resolved value is the value stored in PROPERTY2.
For more information, see Using Formatted Expressions that Advanced UI and Suite/Advanced UI Installations Resolve at
Run Time.
You can schedule the removal of a file or folder for one of the following events:
Note that if the item to be removed is a folder, that folder is removed only if it is empty.
InstallShield offers different methods for configuring a file or folder removal in a project:
• In the Files and Folders view, select the destination folder that contains the file or folder that you want to be removed.
Then right-click in the Destination computer’s files pane and click Add File Removal.
• In the Setup Design view (in installation projects) or the Components view, expand the node of the component that
contains the file or folder that you want to be removed, and then click the Files subnode. Next, right-click in the Files
pane and click Add File Removal.
With both methods, InstallShield displays a Properties dialog box that lets you configure the available removal settings.
Previously, the only way to indicate which files and folders should be removed was to use the Direct Editor view to
manually author entries in the RemoveFile table.
This feature is available in the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM
Database, and Transform.
The automation interface includes a new ISWiRemoveFile object and a new ISWiRemoveFiles collection for removing files
and folders. In addition, three new member methods are applicable to the ISWiComponent object: AddRemoveFile, which
enables you to add a file removal entry to the current component; RemoveRemoveFile, which enables you to remove a file
removal entry from the current component; and ISWiRemoveFiles, which returns an ISWiRemoveFiles collection that
contains all of the file removal entries that are associated with the current component.
These automation interface improvements are available in the following project types: Basic MSI, InstallScript MSI, and
Merge Module.
• ISWiRemoveFile Object
• ISWiRemoveFiles Collection
• AddRemoveFile Method
• RemoveRemoveFile Method
• ISWiRemoveFiles Method
• ISWiComponent Object
• Items that are drawn by the engine are scaled according to the target system’s DPI settings. Thus, if a target system
has a DPI of 200%, the check box control is scaled accordingly.
• The engine considers the scale factor and language when displaying images and other resources that you are
including in the wizard interface.
For example, when the engine determines that the scale factor should be 150 and that the appropriate language is English,
it looks for resources that have the string scale-150 in their path or file name. It searches the following paths in the order
listed when searching for image.png on the target system:
1. [SUPPORTDIR]0409\scale-150\image.png
2. [SUPPORTDIR]0409\image.scale-150.png
3. [SUPPORTDIR]0409\image.png
4. [SUPPORTDIR]scale-150\image.png
5. [SUPPORTDIR]image.scale-150.png
6. [SUPPORTDIR]\image.png
Note that matching the language takes precedence over matching the correct DPI.
InstallShield includes scale-150 and scale-200 images for the built-in default images that are included in Advanced UI and
Suite/Advanced UI projects. If you want to include custom resources in your project, use the Support Files view to add
appropriately scaled images.
DPI-awareness in InstallScript and InstallScript MSI projects has the following parts:
• All of the built-in default dialog images have been replaced with images that scale well to 200%.
• The static dialog controls that have a control ID of 1200 now include support for .png images, which allow for
transparency. This applies to the computer image that is displayed by default on the left side of the exterior skinned
dialogs such as the Welcome dialog. It also applies to the banner images on interior dialogs.
In addition, these same controls support a new format for identifying each image and its associated scale factor:
@@ResourceID;ScaleFactor
ResourceID indicates the resource identifier number that should be used to look up either a .png image (stored as
resource type PNG) or a bitmap image (stored as resource type RT_BITMAP). ScaleFactor indicates the DPI scale
percentage for which the image is intended.
For example, this can be 100% (96 DPI), 125% (120 DPI), 150% (144 DPI), or 200% (192 DPI). If the scale factor that is
specified for an image is 200, the image will be shrunk down for display on target systems that are running less than
200% DPI scaling. On a 200% target system, it will be displayed at 1:1. If the scale factor that is specified for the image
is 100, the image will be scaled up for display on target systems that are running 200% DPI scaling.
The previous format for identifying bitmap images (.bmp) still works, but it does not have support for scaling, or for
.png images:
@BitmapResourceID;TransparentFlag;3-DFlag;<unused>;TransparentColorKey
• The new image string format is now used by default on all ID 1200 static controls for the dialog header banner and for
exterior panel icon images. If you upgrade an InstallScript or InstallScript MSI project to InstallShield 2020 and you
edited the dialogs in the earlier version of InstallShield, you will need to edit the image string to use the new format for
all of the languages that your project supports.
• The InstallScript function SdOptionsButtons has been updated to include support for the new string format for
identifying images:
@@ResourceID;ScaleFactor
@BitmapResourceID;BitmapIconFlag;TransparentColor
• The nItem parameter for the InstallScript function GetSystemInfo includes support for two new constants:
• SYSTEM_DPI_SCALING—This returns the system DPI scaling value in the nvResult parameter.
• GetSystemInfo
• SdOptionsButtons
• Background About the Default Images on Dialogs in InstallScript and InstallScript MSI Projects
The built-in images that are displayed on dialogs that the Setup.exe launcher displays at run time have been replaced with
images that scale well to larger areas. This includes images that are displayed on the initialization dialog.
Support for Distributing Your Installation to Virtual Machines that InstallShield Provisions at Build Time
or on Demand
You can configure your projects so that after each successful build of your installation, InstallShield automatically reverts a
virtual machine (VM) to a designated snapshot, powers on the VM, and copies your installation to the VM to make it
available for testing. You can also alternately perform these testing preparation steps on demand at any time. The testing
preparation capability makes it possible to reduce testing time and eliminate manual steps.
The VM can be on a Microsoft Hyper-V Server, a VMware ESX or ESXi Server, or a VMware Workstation.
To specify VM information, use the Virtual Machine area on the Events tab for a release in the Releases view. One of the
settings lets you specify whether you want the release to be distributed to the specified VM each time that it is successfully
built.
To distribute the release to the VM at any time, right-click the release in the Releases view and then click Distribute to VM.
Note that when you use the Configuration setting on the Events tab to configure VM details, InstallShield writes the data
that you specify to a file called VMConfigurations.xml. This VMConfigurations.xml file is a machine-wide file that you can
configure once and then use it in other InstallShield projects, as well as share it with other team members. You can also use
this file with the Standalone Build.
In order to deploy to one of the supported VMs, InstallShield needs to communicate with the virtualization technology that
you are using. If you are using VMware virtualization technology (VMware ESX or ESXi Server or VMware Workstation), the
VMware VIX API needs to be installed on the same machine as InstallShield. You can do this by either installing VMware
Workstation on that machine or by downloading and installing the VMware VIX API from http://www.vmware.com/
support/developer/vix-api.
If you are using VMware Workstation, it is recommended that you install VMware Workstation on the same machine as
InstallShield so that InstallShield uses the version of the VIX API that was designed for that specific version of VMware
Workstation. Although it is likely that newer versions of the VIX API will also work, it seems that the best approach is for
InstallShield to use the version of the VIX API that was bundled with your version of VMware Workstation.
This feature is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Suite/Advanced UI.
• Distributing Releases to a Virtual Machine that InstallShield Provisions at Build Time or on Demand
Enhancements
InstallShield includes the following enhancements.
Usability Improvements for Populating Combo Box and List Box Controls in Advanced UI and Suite/
Advanced UI Projects
InstallShield lets you add combo box controls and list box controls to wizard pages and secondary windows of Advanced UI
and Suite/Advanced UI projects. The process of creating either one of these types of controls involves the use of two
properties: one that defines the list of options that you want to display in the control, and one that the installation uses to
store the option that the end user selects at run time. Now you can configure both of those properties entirely from within
the Wizard Interface view in InstallShield, instead of having to use the Wizard Interface view and the Property Manager
view.
In the Wizard Interface view, the Content Property setting of the combo box or list box control now contains an ellipsis
button (...) that you can click when you want to define the list of options that you want to display in the control. When you
click this button, a simple Edit List Options dialog box opens, enabling you to specify the list of options that you want to
display in the selected control, as well as an associated value.
Previously, it was necessary to use the Property Manager view to define the property that contained the list of options, as
well as their corresponding property values. The format that was required for defining the property (for example,
ID_Option1\rValue1\nID_Option2\rValue2\nID_Option3\rValue3) was difficult to remember and error-prone.
• Populating Combo Box and List Box Controls in the Wizard Interface
• A new Browse for New File action is available for controls on wizard pages and secondary windows. If you add this
action to the Click event of a control such as a button and an end user clicks the button, a browse dialog box opens,
enabling the end user to specify a new file and its location.
When you add this type of action to a control in your project, you can specify the text for the title bar of the dialog box.
You can also specify the file extension filter options that you want to be available for selection, as well as the default
file extension that should be used when creating the file.
• The existing Browse for Folder action has been enhanced. The Browse for Folder dialog box that this action launches
accepts only locations that have file system equivalents. That is, the OK button on this dialog box remains disabled if
the end user selects a location such as This PC or My Computer. Previously, end users were able to select such
locations, and doing so cleared the value of the associated property.
When you add this type of action to a control in your project, you can specify the instructions that you want to be
displayed on this Browse for Folder dialog box.
• The existing Browse for File action has been enhanced to enable you to specify the file extension filter options that you
want to be available for selection on the file browse dialog box.
For more details, see Configuring an Action for an Element in the Wizard Interface.
Support for Offering Printer Selection for the LicenseAgreement Dialog at Run Time
The behavior of the Print button on LicenseAgreement dialogs has been enhanced. Instead of printing directly to the
default printer when an end user clicks the Print button, the printer selection dialog box now opens.
This enhancement is available in the following project types: Basic MSI, InstallScript, InstallScript MSI.
Previously, the Text File Changes view had support for replacing existing text in text files at run time.
This enhancement is available in the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, MSI
Database, Transform.
Support for Enabling End Users to Choose to Which Installed Instances of an Earlier Version of a Product
to Apply a Major Upgrade
The multi-instance support in Basic MSI projects now includes support for major upgrades. At run time, the instance
selection dialog that the Setup.exe setup launcher displays lets end users view a list of all of the currently installed
instances of the product, including different major versions of the product that are installed. End users can now use this
improved instance dialog to install a new instance, maintain an existing instance, or apply a major upgrade for an instance.
Previously, the only instances that the instance selection dialog listed were ones that shared the same product code as the
running multi-instance installation.
See Also
Upgrading Projects from InstallShield 2013 or Earlier
InstallShield 2013 Service Pack 1 (SP1) includes changes that offer support for the final released versions of Windows 8.1,
Windows Server 2012 R2, and Visual Studio 2013.
The InstallShield prerequisites that should be installable on Windows 8.1 and Windows Server 2012 R2 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:
• Microsoft Visual C++ 2005 SP1 Redistributable MFC Security Update KB2538242(x64)
• Microsoft Visual C++ 2005 SP1 Redistributable MFC Security Update KB2538242(x86)
• Microsoft Visual C++ 2008 SP1 Redistributable MFC Security Update KB2538243(x64)
• Microsoft Visual C++ 2008 SP1 Redistributable MFC Security Update KB2538243(x86)
• Microsoft Visual C++ 2010 RTM Redistributable MFC Security Update KB2467173 (x64)
• Microsoft Visual C++ 2010 RTM Redistributable MFC Security Update KB2467173 (x86)
Enhancements to the InstallScript Language for Windows 8.1 and Windows Server 2012
R2
The following structure members and predefined constants were added to the InstallScript language:
• SYSINFO.WINNT.bWin81—This is a new SYSINFO structure member. If the operating system is Windows 8.1 or
Windows Server 2012 R2, this value is TRUE.
• ISOSL_WIN81—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.1 or Windows Server 2012 R2.
For more information, see FeatureFilterOS function and the SYSINFO structure variable.
Automation Interface Enhancement: OSFilter Property Value for Windows 8.1 and
Windows Server 2012 R2
The following constants are now available for use with the OSFilter member of the ISWiComponent and ISWiRelease
objects in the automation interface:
eosWin81 = &H8000000 (134217728)—These are for Windows 8.1 and Windows Server 2012 R2.
In addition, the value for the eosAll constant is now &HFD100D0 (265355472); previously, it was &7D100D0 (131137744).
The OSFilter member applies to the ISWiComponent object in InstallScript and InstallScript MSI projects. The OSFilter
member applies to the ISWiRelease object in InstallScript projects.
• ISWiComponent Object
• ISWiRelease Object
New InstallShield Prerequisites for Microsoft SQL Server 2012 Express SP1
InstallShield includes several new SQL Server–related InstallShield prerequisites that you can add to Basic MSI,
InstallScript, and InstallScript MSI projects:
• Microsoft SQL Server 2012 Express SP1 System CLR Types (x64)
• Microsoft SQL Server 2012 Express SP1 System CLR Types (x86)
Support for Defining Custom Themes for the Controls on Wizard Pages and Windows in
Suite/Advanced UI and Advanced UI Installations
Suite/Advanced UI and Advanced UI projects now enable you to define themes for wizard interface controls. A control
theme is a collection of colors for various parts of controls—text color, background color, and border color—and for various
states of controls—such as clicked and hovered. You can specify the control theme that you want to use for the controls in
your user interface by default. You can also override the theme for specific controls on wizard pages and windows in your
user interface. Control themes give buttons and other items in your installation’s user interface a flat look (without the
three-dimensional effects) that is reminiscent of the style of Windows Store apps.
• Check boxes
• Radio buttons
• Command links
To add a control theme to your project, right-click the Control Themes node in the Wizard Interface view, and then click
Add Control Theme. Then configure the theme’s settings as needed.
To specify the theme that you want to use by default for the controls in your user interface, select the appropriate theme in
the new Default Control Theme setting that is displayed in the Wizard Interface view when the Wizard Pages node is
selected. This setting is blank by default.
To override the control theme for a specific control, select the appropriate theme in the Control Theme setting for that
control.
• Using Styles, Brushes, and Control Themes to Customize the Wizard Interface
New Predefined Path Variable for the Visual Studio Solution Folder
A new predefined path variable called VSSolutionFolder is available in projects to reference a higher-level base directory.
This support enables you to have in your InstallShield projects static links to files in sibling projects that are within the
Visual Studio solution folder; if you work on the projects on a different machine, the static links that use the
VSSolutionFolder path variable can reference the correct paths for the files in sibling projects.
The VSSolutionFolder path variable is defined automatically whenever an InstallShield project is opened from within a
Visual Studio solution. It is also defined automatically if you are using MSBuild to build a solution that contains an
InstallShield project. However, in other scenarios, when the InstallShield project is opened without the Visual Studio
solution, VSSolutionFolder cannot be defined automatically. For example, if you open the InstallShield project in
InstallShield directly, without having Visual Studio open, VSSolutionFolder is not defined. Similarly, if you use the
command-line tool IsCmdBld.exe, or if you use MSBuild with an .isproj file, VSSolutionFolder is not defined. If you are using
IsCmdBld.exe to build a release in InstallShield project, use the -L command-line parameter to set the value of
VSSolutionFolder. If you are using MSBuild, use the PathVariables parameter to set the value of VSSolutionFolder. This
parameter is exposed as the ItemGroup InstallShieldPathVariableOverrides when the default targets file is used.
If you include in your InstallShield project a source file whose path includes the VSSolutionFolder path variable and build it
in an environment that does not support the VSSolutionFolder path variable, build errors such as the following ones may
occur:
• -6271: File <VSSolutionFolder>\MyFile.exe not found. An error occurred building the MsiFileHash table record for this
file. Verify that the file exists in the specified location.
This functionality is available in the following project types: Advanced UI, Basic MSI, InstallScript, InstallScript MSI, Merge
Module, Suite/Advanced UI.
• ISCmdBld.exe
To update the product code of a specific instance, use the new Generate a new GUID command that is available when you
right-click the value in the ProductCode setting for an instance that is defined on the Multiple Instances tab for a product
configuration in the Releases view.
To update the product code of each instance that is defined for a product configuration in your project, use the new
Change ProductCode of Each Instance command that is available when you right-click the Instances node on the Multiple
Instances tab for a product configuration in the Releases view.
For details, see Updating the Product Code of One or More Instances.
See Also
What’s New in InstallShield 2013
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.
• Events View
• Packages View
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.
• PowerShell
InstallShield also lets you specify additional Windows roles and features that a package requires.
• Packages View
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.
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.
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:
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.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
• Validating Projects
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.
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.
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.
• ISWiProductConfig Object
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.
• Validating Projects
• ISICEs
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.
• 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.
• 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.
• 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.
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.
• 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:
• 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.
• 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
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.
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.
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.
• Using Styles, Brushes, and Control Themes to Customize the Wizard Interface
Enhancements
InstallShield includes the following enhancements.
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.
• 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.
See Also
Upgrading Projects from InstallShield 2012 Spring or Earlier
What’s New in InstallShield 2013 SP1
InstallShield 2012 Spring Service Pack 1 (SP1) includes changes that offer support for the final released versions of
Windows 8, Windows Server 2012, and Visual Studio 2012. It also includes additional changes.
Important • If you want to open an InstallShield 2012 Spring Advanced UI or Suite/Advanced UI project (.issuite) in
InstallShield 2012 Spring SP1, you must allow InstallShield to upgrade your project to InstallShield 2012 Spring SP1.
InstallShield 2012 Spring SP1 Advanced UI and Suite/Advanced UI projects include support for functionality that was not
available in these project types in InstallShield 2012 Spring, and this support needs to be added during the upgrade. Note that
it is not possible to open InstallShield 2012 Spring SP1 Advanced UI or Suite/Advanced UI projects in earlier versions of
InstallShield (including InstallShield 2012 Spring without SP1). Therefore, if multiple users need to open and modify your
InstallShield projects, ensure that all of you apply the SP1 patch at the same time.
If you open an InstallShield 2012 Spring Advanced UI or Suite/Advanced UI project in InstallShield 2012 Spring SP1,
InstallShield 2012 Spring SP1 displays a message box that asks you if you want to convert the project to the new version. If you
reply that you do want to convert it, InstallShield creates a backup copy of the project before converting it.
Sideloading an app is the process of installing an app without obtaining it through the Windows Store. This type of app is
sometimes distributed to enterprise environments. Windows 8 and Windows Server 2012 include support for sideloading
apps.
Note that support for creating and building Suite/Advanced UI installations that include sideloading Windows App
packages requires Windows Vista or later or Windows Server 2008 or later on the machine that has InstallShield or the
Standalone Build.
• Packages View
Support for Visual Studio 2012, .NET Framework 4.5, and Visual C++ 2012
InstallShield includes changes that offer support for the final released version of Visual Studio 2012, enabling development
of installations and products within this version of the Visual Studio interface.
In addition, InstallShield includes two updated InstallShield prerequisites for the .NET Framework and two new
InstallShield prerequisites for Visual C++:
You can add any of these prerequisites to Advanced UI, Basic MSI, InstallScript, InstallScript MSI, and Suite/Advanced UI
projects.
The Web prerequisite for the .NET Framework 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.
Additional Changes
For a list of issues that are resolved in InstallShield 2012 Spring SP1, see the release notes. The release notes are available
from the Help menu in InstallShield.
New Features
InstallShield includes the following new features.
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:
• Microsoft Visual C++ 2005 SP1 Redistributable MFC Security Update KB2538242
• Microsoft Visual C++ 2008 SP1 Redistributable MFC Security Update KB2538243
• Microsoft Visual C++ 2010 RTM Redistributable MFC Security Update KB2467173
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:
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.
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.
• Connecting to a Microsoft Windows Azure Database Server and Running SQL Scripts
This support is available in the following project types: Basic MSI, DIM, InstallScript, and InstallScript MSI.
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.
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.
This support is available in the following project types: Basic MSI, DIM, InstallScript, and InstallScript MSI.
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.
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:
• 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.)
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.
To learn more, see Including Microsoft System Center Configuration Manager Application Model Data About Your Product.
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.
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.
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.
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.
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.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
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.
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.
InstallShield lets you add an InstallScript package to a Suite/Advanced UI or Advanced UI project if the InstallScript
package meets the following requirements:
• 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:
• 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.
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.
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.
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.
• Supporting the Creation of Package Log Files for Command-Line Launching of an Advanced UI or Suite/Advanced UI
Installation
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.
• Component Settings
• WINSYSDIR64
• REGDB_OPTIONS
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.
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.
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.
• Scheduling Tasks
Enhancements
InstallShield includes the following enhancements.
• 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.
• ISWiComponent Object
• ISWiRelease Object
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.
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.
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.
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:
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.
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
Upgrading Projects from InstallShield 2012 or Earlier
Upgrading from Earlier InstallShield Versions
Enhancements
InstallShield includes the following enhancement.
For more information, see Including a Software Identification Tag for Your Product.
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.
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.
Suite projects let you specify whether you want to have an entry in Add or Remove Programs for your Suite installation.
This entry lets end users perform maintenance for your Suite, modifying or removing if needed. The General Information
view in a Suite project has a Show Add or Remove Programs Entry setting that lets you indicate the appropriate behavior.
If you want to show only a single entry for the entire Suite, ensure that you hide the entries from the packages that you
include in the Suite project.
End users can run your Suite installations with a user interface or silently, without a user interface. Silent installations run
without user intervention; end users can avoid monitoring the installation and providing input through run-time wizard
pages.
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:
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.
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.
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:
• 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.)
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.
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.
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.
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
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.
Software identification tagging is evolving as an industry standard, enabling independent software vendors to create
smarter applications that give you 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.
• 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.
This feature applies to the following project types: Basic MSI, InstallScript, InstallScript MSI, and Merge Module.
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
New Features
InstallShield includes the following new features.
As a result of these changes, any language displays correctly on a system that has support for it installed. End users no
longer need to match the language that is used on their systems for non-Unicode programs with the language that is used
in the installation. Note that the font must be installed on the target system. On some versions of Windows, the fonts for
some languages are not installed by default. For example, Japanese fonts are not installed on a Windows XP English system
by default; in order for an installation to use Japanese characters on such a system, the fonts would need to be installed.
Now all Setup.exe and Update.exe files that are built in InstallShield are Unicode. Previously, all Setup.exe and
Update.exe files that were built in InstallScript and InstallScript MSI projects were ANSI.
A Unicode setup launcher can correctly display characters in the user interface of the setup launcher, regardless of whether
the target system is running the appropriate code page for the language. ANSI setup launchers correctly displayed
characters in the setup launcher dialogs if the target system was running the appropriate code page. However, it may have
displayed garbled characters in those dialogs if the target system was not running the appropriate code page.
End users can launch Setup.exe and Update.exe files from within Unicode paths, regardless of the language on the target
system. For example, end users can now launch the installation in the following path on an English system:
C:\Users\Japanese characters\Desktop\Setup.exe. Previously, the installation would fail.
Unicode Support for Files, Folders, Registry Entries, and Support Files
Unicode support has been added to key parts of the installation run time, enabling you to use characters from any
languages simultaneously in file names, folder names, registry entries, and support file names. This enables you to install,
for example, a file that has Japanese characters in its name or target path on an English system. Mixing languages works
correctly regardless of the current language of the target system.
Pointer Support
The InstallScript engine and compiler now support a new pointer type called WPOINTER; wpointer and LPWSTR are
equivalent names that are also available. Thus, for example, if you have a DLL function that accepts pointers to Unicode
strings in its parameters, you can use this new pointer type; when the DLL function is called in the script at run time, the
InstallScript engine passes a pointer to a Unicode copy of the strings instead of an ANSI version. Previously, it was possible
to pass a pointer to only an ANSI copy of the strings.
Note that passing Unicode strings with the WSTRING data type that was introduced in an earlier version of InstallShield is
still supported.
• Pointers
Structure Support
Structures in InstallScript can contain any basic data type, including strings and pointers, or other structures. Now if a
structure needs to contain a Unicode string and the structure is passed to an external DLL, the InstallScript engine can
distinguish between string member types in that structure, and then size the structure and calculate member offsets
correctly. String members that need to be stored and passed as Unicode can be declared with the WSTRING type.
Previously, if a structure needed to contain a Unicode string and the structure was passed to an external DLL, the
InstallScript engine assumed that any strings in the structure were ANSI. As a result, the size of the structure and member
offsets in the structure could have been wrong, causing the DLL to incorrectly read or write data related to the structure.
Attempting to use WSTRING for string members of a structure did not have any effect.
You can leave existing strings as STRING types; the InstallScript engine will continue to treat these as ANSI strings when
passing them outside of script code.
Pointer members in structures can also now be declared as WPOINTER. This enables you to store pointers to Unicode
strings in a structure.
• Data Structures
InstallShield now uses Unicode encoding to build the string tables for InstallScript projects. Because of this support, string
tables for InstallScript projects can now contain multiple languages, and they are not affected by a target system’s code
page settings. In addition, string tables can now include strings for languages—such as Hindi—that have no code page.
It is recommended that any strings that will be displayed in the user interface of an installation be stored in the string table.
Although strings can be written directly in InstallScript code, they are not stored as Unicode; thus, they are displayed
correctly only when the installation is run on systems that have the correct code page. Storing strings in the string table
and referencing them from InstallScript code eliminates this issue.
This feature is available in the following project types: InstallScript and InstallScript MSI.
For information on the InstallScript Debugger, see Debugging InstallScript-Based Installations in the InstallScript Debugger
User Guide.
The cabinet and header file support applies to the following project types: InstallScript and InstallScript Object.
The log file support applies to the following project types: InstallScript and InstallScript MSI.
Now when you are using InstallShield from within Visual Studio 2010, you can access the Source Control Explorer to
integrate your InstallShield project with Team Foundation version control and manage changes to your InstallShield
projects and your Visual Studio solutions.
You can also use Team Foundation Build to compile, test, and deploy your InstallShield projects and your Visual Studio
solutions on a regular basis, or on demand. Your installation is automatically updated with your latest source files every
time that your solution is built.
In addition, if you install Team Explorer on the same machine that has InstallShield and Visual Studio, you can use Team
Explorer from within your InstallShield projects that are open in Visual Studio. This enables you to perform tasks such as
the following:
• Use Source Control Explorer when you are working on your InstallShield projects.
• Configure builds for your InstallShield projects and Visual Studio solutions.
• Track work items such as bugs and tasks for your InstallShield projects and your Visual Studio solutions.
This feature is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
New InstallShield Prerequisites for SQL Server 2008 R2 Express, SQL Server Native Client, Visual C++
2010, and Other Redistributables
InstallShield includes a number of new InstallShield prerequisites that you can add to Basic MSI, InstallScript, and
InstallScript MSI projects:
Improved Script Editors for Creating and Modifying InstallScript Code, SQL Scripts, VBScript Custom
Actions, and JScript Custom Actions
Several views in InstallShield have an improved script editor that you can use to write code for your projects. The script
editors include the following improvements:
• Expanded auto completion—When you are typing in a script editor, InstallShield displays a pop-up list of
alphabetically ordered functions, keywords, and constants that begin with the letters that you are typing. Instead of
manually typing the entire word, you can select it in the pop-up list, and InstallShield adds it to your script.
If you are using the script editor in the InstallScript view, you can enter the string constant operator (@) to see a pop-
up list of the available string identifiers. You can select the appropriate one in the list, and InstallShield adds it to your
script.
If auto completion for local variables is also enabled, the pop-up list in the script editor of the InstallScript view also
contains local variables.
Auto completion can increase your efficiency because it can reduce the time that you spend typing code. It can also
help you avoid typographical errors in your code.
The script editor in the InstallScript view of earlier versions of InstallShield is the only script editor that provided some
auto completion support; thus, auto completion functionality was not available for SQL scripts, VBScript code, or
JScript code. In addition, the available pop-up list was limited to InstallScript functions; none of the keywords,
constants, local variables, or string identifiers were available for auto completion.
• Detailed InstallScript Function Call Tips—If function call tips are enabled, InstallShield shows InstallScript function
call tips—a type of tooltip—when you are entering function calls in your script in the InstallScript view. A function call
tip shows a built-in function’s parameter information. It also shows a description of the built-in function, as well as a
description of the parameter that you are entering. The detailed call tips enable you to see help information about a
function without switching from the script editor to the help library, and then back to the script editor.
The InstallScript view in earlier versions of InstallShield included support for call tips, but the call tips did not display
as much information. The call tips showed a function call with all of the function’s parameters; however, the call tips
did not include a description of the function, or of the parameter that you are entering.
• Syntax folding—InstallShield now lets you specify whether you want the script editors in various views in
InstallShield to include support for syntax folding. When syntax folding is enabled, InstallShield adds a plus sign (+) or
a minus sign (–) in the margin next to each line of code that starts an expandable or collapsible block of script. You can
click a plus sign to expand hidden code, or a minus sign to hide visible code.
Syntax folding can help you minimize the clutter of large scripts and focus on the code that is relevant to the work that
you are currently doing. It can also help you see the overall structure of a script.
The views that contain the improved script editor are the InstallScript view, the SQL Scripts view, and the Custom Actions
and Sequences view (when you are viewing a VBScript or JScript file in this view).
By default, syntax folding is disabled in the script editors; auto completion, local variable auto completion, and function
call tips are enabled. To enable or disable any of the aforementioned functionality, use the Script Editor Properties dialog
box. This dialog box also lets you modify other settings in the script editors, such as font, syntax colors, and line numbering.
To access this dialog box, right-click in a script editor and then click Properties.
• Viewing Function Call Tips for an InstallScript Function in the Script Editor
It is recommended that you perform the conversion of 64-bit Windows Installer packages to App-V packages on a 64-bit
Windows system. If you attempt the conversion on a 32-bit system, it could result in a failure to extract COM information for
64-bit binaries. Also, in some cases, Windows Installer packages contain shortcuts that target executable files that are not
found in the package itself. If these shortcuts target executable files are found in 64-bit locations, these shortcuts are not
handled correctly on 32-bit systems.
The Microsoft App-V Assistant is available if you purchase the Premier Edition of InstallShield.
Ability to Specify a Search Path for InstallShield Prerequisites; Path Variable and Relative Path Support
for Source Locations of Prerequisite Files
InstallShield now lets you specify the folders where InstallShield should search for InstallShield prerequisite files (.prq
files). This functionality makes it easier for teams of users to share InstallShield prerequisites with each other, and for
storing prerequisites in source code control. Previously, InstallShield searched for .prq files in the following location only:
InstallShield Program Files Folder\SetupPrerequisites.
• If you are editing or building from within InstallShield, use the new Prerequisites tab on the Options dialog box—which
is displayed when you click Options on the Tools menu—to specify a comma-delimited list of machine-wide folders
and current-user folders. This tab is similar to the Merge Modules tab on the Options dialog box, which lets you specify
search paths for merge modules.
• If you are building from the command line with ISCmdBld.exe, use the new -prqpath parameter to specify a comma-
delimited list of folders.
If you use an .ini file to specify ISCmdBld.exe parameters, you can use the new PrerequisitePath parameter in the
[Mode] section of your .ini file to specify a comma-delimited list of folders.
• If you are building through MSBuild or Team Foundation Server (TFS), use the new PrerequisitePath parameter on the
InstallShield task. This parameter is exposed as the ItemGroup InstallShieldPrerequisitePath when the default targets
file is used. To specify multiple paths, use an ordered array of paths.
When you are using the Files to Include tab in the InstallShield Prerequisite Editor to add files to an InstallShield
prerequisite, the editor now uses predefined path variables such as <WindowsFolder> and <ISProductFolder> if
appropriate. In addition, if the files that you are adding are stored in the same folder as the InstallShield prerequisite’s .prq
file—or a subfolder of the folder that contains the .prq file—the InstallShield Prerequisite Editor uses a relative path for the
file in the .prq file. Note that if you view the file’s path on the Files to Include tab, the InstallShield Prerequisite Editor lists
the full path, not the relative path.
Note that if you use the Save As command in the InstallShield Prerequisite Editor to change the location of a .prq file, the
InstallShield Prerequisite Editor updates the paths of the prerequisite’s files if appropriate.
• Prerequisites Tab
• ISCmdBld.exe
Windows Installer 5 includes support for this new hyperlink control. If this control is used on a dialog that is displayed on a
system that has an earlier version of Windows Installer, run-time error 2885 occurs, and the installation aborts. Therefore, if
you want to use the hyperlink control on a dialog but your installation targets systems that have Windows Installer 4.5 or
earlier, it is recommended that you include two versions of the dialog in your project: one with the hyperlink control, and
one without it. Add conditions to the dialogs to show or hide them, depending on the version of Windows Installer that is
present.
This feature is available in the following project types: Basic MSI and Merge Module.
Ability to Specify a Custom Icon and Custom Version Resource Properties for Setup.exe and Update.exe
InstallShield now lets you use a custom icon and custom version resource properties for Setup.exe files that you create at
build time. The icon and the version resource properties are displayed on the Properties dialog box for Setup.exe; this
Properties dialog box opens when end users right-click the Setup.exe file and then click Properties. End users can also see
the icon when they view your Setup.exe file in Windows Explorer. This support is available in Basic MSI, InstallScript, and
InstallScript MSI projects.
The same functionality (the ability to specify a custom icon and custom version resource properties) is also now available
for Update.exe files that you create in Basic MSI, InstallScript MSI, and QuickPatch projects.
The Setup.exe tab in the Releases view has a Setup.exe Icon File setting that lets you specify the icon that should be used
for your Setup.exe setup launcher. The icon can be in an .exe, .dll, or .ico file. If you do not specify an icon, InstallShield
uses a default icon for your Setup.exe file.
Previously, support for specifying a custom Setup.exe icon was available for InstallScript projects if the Setup.exe file that
you were building was a self-extracting, single-file setup launcher. The support was not available in Basic MSI or
InstallScript MSI projects. In addition, it was not available for uncompressed InstallScript installations.
A new Icon setting lets you specify the icon that should be used for your Update.exe launcher. This setting is available on
the Advanced tab for a patch configuration in the Patch Design view of Basic MSI and InstallScript MSI projects. It is also
available on the Advanced tab of the Build Settings area in the General Information view of QuickPatch projects. If you do
not specify an icon, InstallShield uses a default icon for your Update.exe file.
Previously, InstallShield did not include any support for specifying a custom icon for Update.exe files.
• Company name
• Product name
• Product version
• Copyright
• File version
• File description
To use a custom copyright notice and a custom file description, ensure that you select Yes in the Use Custom Version
Properties setting for the release in the Releases view.
Previously, InstallShield did not use any custom information in many cases. For example, the InstallScript Setup.exe files
that InstallShield previously created contained details that pertained to the version of InstallShield that was used to build
the Setup.exe file. Thus, the product name that was displayed in the Setup.exe Properties dialog box was InstallShield,
rather than the name of your product.
Several new settings—Company Name, Product Name, Product Version, Description, and Copyright—let you specify the
custom information that you want InstallShield to use when you build an Update.exe file. These settings are available on
the Advanced tab for a patch configuration in the Patch Design view of Basic MSI and InstallScript MSI projects.They are
also available on the Advanced tab of the Build Settings area in the General Information view of QuickPatch projects.
Previously, InstallShield did not use any custom version resource information for Update.exe files.
Ability to Specify Commands that Run Before, During, and After Builds
The Premier edition of InstallShield includes new release settings that you can use to specify commands that you want to
be run at various stages of the build process. These new settings are available on a new Events tab when you select a
release in the Releases view:
• Prebuild Event—Use this setting to specify the command that you want to be run before InstallShield starts building
the release. This event runs after InstallShield creates the release folder and log file, but before InstallShield starts
building the release.
This setting is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Merge Module.
• Precompression Event—Use this setting to specify the command that you want to be run after InstallShield has built
the .msi package and the .cab files (if your product’s data files are to be stored in .cab files). Note that this event occurs
after .cab files are streamed into the .msi package, but before the .msi package has been digitally signed and streamed
into the Setup.exe file.
This setting is available in the following project types: Basic MSI and InstallScript MSI.
• Postbuild Event—Use this setting to specify the command that you want to be run after InstallShield has built and
signed the release.
This setting is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Merge Module.
The new Events tab replaces the previously available Postbuild tab. Note that the settings that were previously available
on the Postbuild tab are now displayed on the new Events tab. In addition, the publish-related settings that were
previously available on the Build tab in Merge Module projects have been moved to the Events tab.
The automation interface now includes support for the new build event settings. The ISWiRelease object includes three
new properties that let you specify commands for various stages of the build process:
• PrebuildEvent
• PrecompressionEvent
• PostbuildEvent
• ISWiRelease Object
To set an expiration date and a message for your Setup.exe file, use the new Expiration Date and Expiration Message
settings on the Setup.exe tab for a selected release in the Releases view. By default, no expiration date is configured for
Setup.exe. If you specify an expiration date, you can use the default expiration message, or specify your own custom
message.
The automation interface now includes support for these new settings. The ISWiRelease object includes two new
properties that let you set the expiration date and message: ExpirationDate and ExpirationMessage.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
• ISWiRelease Object
Ability to Import Visual Studio Setup and Merge Module Projects into Existing InstallShield Projects;
Improvements for the Project Converter
InstallShield now lets you import a Visual Studio setup project (.vdproj) into an InstallShield Basic MSI or Merge Module
project (.ism), or import a Visual Studio merge module project (.vdproj) into an InstallShield Basic MSI or Merge Module
project (.ism). These tasks enable you to develop InstallShield installation and merge module projects that contain the
same data and settings that were in your Visual Studio project. The wizard imports the project outputs, files, registry keys,
file extensions, custom actions, target system searches, and launch conditions from your Visual Studio project into your
existing InstallShield project.
To import a Visual Studio project into an existing InstallShield project, use the new Visual Studio Deployment Project
Import Wizard in InstallShield. The wizard lets you choose whether to import or ignore certain settings in the Visual Studio
project.
The existing support for converting a Visual Studio project into a new InstallShield project has been expanded. If your
Visual Studio project contains predefined prerequisites, InstallShield now converts them to equivalent InstallShield
prerequisites during the conversion process. This same prerequisite conversion functionality is available if you use the new
wizard to import a Visual Studio project into an InstallShield project.
If your Visual Studio project contains one or more project outputs, use the import wizard instead of the conversion process.
The InstallShield project must be in the same Visual Studio solution that contains the Visual Studio setup or merge module
project and all of its project dependencies. Note that you must be using InstallShield from within Visual Studio when you
use the import wizard in order for the wizard to import the project outputs into your InstallShield project.
Previously, InstallShield had run-time support but not design-time support for SQL scripts with Unicode BOM encoding.
Thus, when you added a script with this encoding to the SQL Scripts view of your project, InstallShield prompted you to
specify whether you wanted to convert the script to ANSI format. If you allowed InstallShield to convert it to ANSI, you
could edit it from within the SQL Scripts view. However, in some cases, it might have displayed and used garbled
characters at design time and at run time. If you did not allow InstallShield to convert it to ANSI, the file remained with
Unicode BOM encoding. Although this encoding allowed your installation to properly use strings in languages that did not
match the code page of the target system at run time, you could not view or edit the script from within InstallShield.
In addition, InstallShield previously did not have adequate support for SQL scripts with UTF-8 BOM encoding. If you added
a SQL script with this encoding type to your project and the script contained strings in a language that did not match the
code page of the development system, the SQL Scripts view treated the file as an ANSI file, and it may have displayed
garbled characters. In addition, garbled characters were used when your SQL script was executed at run time. Also, the
byte order mark was represented as garbled characters.
If you create a new SQL script from within the SQL Scripts view, InstallShield uses Unicode BOM encoding for the file. If you
prefer to use ANSI or UTF-8 BOM encoding for the SQL scripts view, it is recommended that you create an .sql file with the
proper encoding in a different tool, and then import or insert the script in the SQL Scripts view of your project.
This feature is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Predefined System Searches for SQL Server 2008 Express SP1 and Adobe Reader 9
InstallShield has new predefined system searches:
• Adobe Reader 9
If your installation requires one or both 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.
If you want to override the new default behavior, use the Direct Editor view to add a new record with the following fields to
the ISClrWrap table.
• Action_—Indicate the name of the managed-code custom action that you want to modify.
• Value—Specify the appropriate architecture. To use a 32-bit version of the .NET Framework, enter the following: x86
To use a 64-bit version of the .NET Framework, enter the following: x64
This feature is available in the following project types: Basic MSI, InstallScript MSI, and Merge Module.
To learn more, see Using 32-Bit vs. 64-Bit Managed-Code Custom Actions.
If you are building from the command line with ISCmdBld.exe and you use the existing -t parameter to specify the path of
the 32-bit version of the .NET Framework, ISCmdBld.exe now uses the 64-bit location of Regasm.exe and
InstallUtilLib.dll when appropriate.
If you are building through MSBuild or Team Foundation Server (TFS) and you use the existing DotNetUtilPath parameter
on the InstallShield task to specify the path of the 32-bit version of the .NET Framework, the build now uses the 64-bit
location of Regasm.exe and InstallUtilLib.dll when appropriate.
• ISCmdBld.exe
Support for Using the InstallScript Function DotNetCoCreateObject or Managed-Code Custom Actions
with DLLs that Target .NET Framework 4
If you create a DLL in Visual Studio 2010 and the DLL uses .NET Framework 4, you can now use the InstallScript function
DotNetCoCreateObject to call functions in this DLL. Previously, the installation crashed if the DLL used version 4 of the
.NET Framework, but not with earlier versions. This feature is available in the following project types: InstallScript and
InstallScript MSI; it is also available in Basic MSI and Merge Module projects with InstallScript custom actions.
In addition, you can now use the same sort of DLL file in a managed-code custom action. Previously, the installation
crashed if it contained a managed-code custom action for a DLL that used version 4 of the .NET Framework. This feature is
available in the following project types: Basic MSI, InstallScript MSI, Merge Module.
• DotNetCoCreateObject
For example, you might use this functionality to swap out the binaries for custom actions. If you have set up separate
releases for 32-bit and 64-bit target systems, you can override the path variable that is used to refer to the DLL that is
selected for a custom action. Then InstallShield could include a 32-bit DLL for your 32-bit release and a 64-bit DLL for your
64-bit release. Note that overriding path variables to swap out files that your installation is installing is not recommended.
This is because you should use separate components for 32-bit and 64-bit versions of a file.
To override one or more path variables in your project, use the new Path Variables Overrides setting, which is on the Build
tab for a release in the Releases view. Note that if you override a path variable both in the new Path Variables Overrides
setting, and with the -l parameter to IsCmdBld.exe or through MSBuild, the command line or MSBuild value takes
precedence over the value that is set in the release setting.
The automation interface now includes support for this new setting. The ISWiRelease object includes a new
PathVariableOverrides property that lets you override the values of your project’s user-defined path variables,
environment variables, and registry variables for a release.
This feature is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, and
Merge Module.
• ISWiRelease Object
Ability to Configure MIME Types for IIS Web Sites, Applications, and Virtual Directories
The Internet Information Services view has a new MIME Types setting that you can configure for a Web site, application, or
virtual directory in your project. This setting lets you identify the types of content that can be served from the Web server
on the target system to a browser or mail client.
This feature applies to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Ability to Overwrite Existing IIS Application Pool or Only Create It If It Does Not Exist
The Internet Information Services view has a new Overwrite Existing Application Pool setting. This setting is displayed in
the right pane when you select an application pool in the Internet Information Services view. This setting lets you specify
the behavior that you want to occur if the selected application pool already exists on the target system at run time: the
installation can either overwrite the application pool's settings on the target system, or leave the application pool as is.
The default value for this setting is Yes, indicating the an existing application pool is overwritten at run time.
This feature applies to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
For more information, see the description of the Overwrite Existing Application Pool setting for an application pool.
If a project contains both Flash files and image files but a target system does not have the Adobe Flash Player, the
installation can detect that and display image billboards in place of the Flash billboard.
Previously, the only available billboard support in InstallScript and InstallScript MSI projects required the use of a
background window. The new billboard style does not require a background window.
To add the new style of billboard to a project, use the Support Files/Billboards view to add billboard files to your project. To
display this new style of billboard at run time, use the new STATUSBBRD constant with the Enable function.
Note that the new style of billboard is not available in projects that use skinned dialogs.
• Billboard Styles and File Types for InstallScript and InstallScript MSI Projects
• Adding or Modifying the Code in an InstallScript or InstallScript MSI Project to Display Billboards
• Adding an Adobe Flash Application File Billboard to an InstallScript or InstallScript MSI Project
If you select Yes for this setting and the file transfer takes more time than you have allocated for the billboards, the
installation restarts the display of billboards from the beginning. The loop continues, if necessary, until the file transfer
ends. The default value for this setting is No, which matches the behavior in earlier versions of InstallShield.
Previously, if the file transfer took more time than what you had allocated for the billboards, the installation continued to
display the last billboard until the file transfer finished; it did not loop the billboards.
• Billboard Settings
To configure the new permission settings for a service, use the Services node in the Advanced Settings area for a
component in the Setup Design view (in installation projects) or the Components view. The Services node is where you add
new services to your project. When you select a subnode under the Services node, you can configure the settings—
including the new permission-related settings—of that service in the right pane.
This functionality is available in the following project types: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM
Database, and Transform.
• Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment
• Services Settings
Automation Interface Support for Configuring Dynamic File Links in InstallScript Projects
The ISWiDynamicFileLinking object and the ISWiDynamicFileLinkings collection of the automation interface now include
support for dynamic file links in InstallScript projects. In addition, two methods and a property of the ISWiComponent
object are now applicable to InstallScript projects: the AddDynamicFileLinking method lets you add a new dynamic file link
to a component, the RemoveDynamicFileLinking method lets you remove a component’s dynamic file links, and the
ISWiDynamicFileLinkings property lets you get a component’s collection of dynamic file links. The read-only DynamicFile
property for the ISWiFile object is also now applicable to InstallScript projects: use this property to determine whether the
file’s source is linked to the component dynamically or statically.
• ISWiDynamicFileLinking Object
• ISWiDynamicFileLinkings Collection
• ISWiComponent Object
• AddDynamicFileLinking Method
• RemoveDynamicFileLinking Method
• ISWiFile Object
Enhancements
InstallShield includes the following enhancements.
The areas in InstallShield that have been enhanced to include the Unicode support are the System Search view, the tabs for
a release in the Releases view, and the Multiple Instances tab for a release in the Releases view. Note that Unicode support
was previously introduced in many other views in InstallShield 2010.
The improvements for the System Search view are applicable to the following projects: Basic MSI, InstallScript MSI, Merge
Module, MSI Database, MSM Database, and Transform.
The improvements for the tabs for a release in the Releases view are applicable to the following projects: Basic MSI,
InstallScript, InstallScript MSI, InstallScript Object, and Merge Module.
The improvements for the Multiple Instances tab in the Releases view are applicable to Basic MSI projects.
Command-Line Support for Generating a Log File While Using InstallShield MSI Diff
InstallShield MSI Diff includes a new /out command-line parameter. You can use this new parameter while running
InstallShield MSI Diff from the command line to generate a log file that identifies the differences between two .msi, .msm,
or .pcp files, or that shows the differences that are applied to a Windows Installer database by a transform (.mst) or patch
file (.msp). You can also use this tool from the command line to generate a log file that identifies the differences between
two InstallShield project files (.ism or .ise) that are saved in binary format.
To learn more, see Running InstallShield MSI Diff from the Command Line to Generate a Log File of Differences.
Support for Listing Local Microsoft SQL Server Instances on 64-Bit Systems
If you add SQL support to a project through the SQL Scripts view in InstallShield and the installation is run on a 64-bit target
system, the built-in SQL-related run-time dialogs now list 64-bit local SQL Server instances, as well as 32-bit local SQL
Server instances, 32-bit network SQL Server instances, and 64-bit network SQL Server instances. Previously when the
installation was run on a 64-bit target system, the built-in SQL-related run-time dialogs did not list any 64-bit local SQL
Server instances; they listed only 32-bit local instances, 32-bit network instances, and 64-bit network instances.
This functionality is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Previously, if the InstallScript engine made changes to the 64-bit part of the registry during an installation, those changes
were not logged as 64 bit specific, so they were not removed during uninstallation.
This functionality is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Support for Adding Project Outputs from Visual Studio Web Setup Projects
If you create a Visual Studio solution that includes a Web setup project and an InstallShield installation project and you are
using InstallShield from within Visual Studio, you can now add project outputs from the Web setup project to your
InstallShield project.
Ability to Select a Windows Installer Property when Configuring a Text File Change
Two settings in the Text File Changes view have been enhanced to make it easier to configure search-and-replace behavior
for content in text files. The Find What and Replace What settings, which are displayed in the right pane when you select a
replacement node in the Text File Changes view, now let you select a Windows Installer property from a list, or type a
string. The list consists of all of the properties that are available in the Property Manager view of your project. Previously,
you could manually enter a string or a property in these settings, but the list of properties was not available.
This enhancement is available in the following project types: Basic MSI and InstallScript MSI.
Use these new settings to specify the minimum execution level that is required by your installation’s Update.exe file for
running the upgrade on Windows Vista and later platforms. InstallShield adds a manifest that specifies the required level.
By default, InstallShield uses the level that was configured in the previous setup launcher’s manifest.
Previously, the Required Execution Level setting was available only for the Setup.exe setup launchers. If you created an
Update.exe patch, InstallShield used the same required execution level that was configured in the previous setup
launcher’s manifest.
The Cab Optimization Type setting replaces the Optimize Size setting, which had support for only LZX compression and
MSZIP compression; it did not let you skip compression.
The automation interface now includes support for this new setting. The ISWiRelease object includes a new
CabCompressionType property that lets you specify which of the three compression options you want to use when you
build a release through the automation interface.
This enhancement is available in the following project types: Basic MSI and InstallScript MSI.
Expanded List of Predefined Operating System Conditions in the InstallShield Prerequisite Editor
The Prerequisite Condition dialog box, which is displayed when you are adding or modifying a condition for an InstallShield
prerequisite in the InstallShield Prerequisite Editor, now has predefined operating system conditions for Windows Server
2008 R2. Some of the Windows 7 options have been renamed to make it more clear which versions of Windows are checked,
since some of the options check for the workstation version, the server version, or either version. The Prerequisite
Condition dialog box also has new options that check only for Windows 7, not Windows Server 2008 R2. These changes let
you quickly define more-targeted operating system conditions for any InstallShield prerequisites.
You can add InstallShield prerequisites to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
This enhancement is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, and Transform.
If you are using the custom InstallShield handling method of configuring permissions in your project, the User list on the
Permissions dialog box has a new IUSR option. To use the custom InstallShield handling method, select this option in the
Locked-Down Permissions setting in the General Information view. This functionality is available in the following project
types: Basic MSI, InstallScript MSI, Merge Module, and Transform.
If you are using the InstallScript function SetObjectPermissions to set permissions, you can now pass IUSR for the szUser
parameter. This functionality is available in InstallScript events in the following project types: InstallScript and InstallScript
MSI. This functionality is also available through InstallScript custom actions in Basic MSI, InstallScript MSI, and Merge
Module projects.
This functionality is available in InstallScript events in the following project types: InstallScript and InstallScript MSI. This
functionality is also available through InstallScript custom actions in Basic MSI, InstallScript MSI, and Merge Module
projects.
• DLG_INFO_ALTIMAGE_VERIFY_BMP—This constant specifies that the bitmap that is indicated by szInfoString should
be used in subsequent dialogs. Before this bitmap is used, the installation checks for the existence of the bitmap. If the
bitmap does not exist, the function returns an error that indicates that the bitmap was not found.
• DLG_INFO_ALTIMAGE_REVERT_IMAGE—This constant specifies that dialogs should display the default bitmap. This
constant is an alternative equivalent to the value of -1. The installation does not check for the existence of the bitmap
when you use this constant.
If you pass TRUE in the nParameter parameter, the installation does not check for the existence of the bitmap; if the bitmap
does not exist in this scenario, the function does not return an error.
This functionality is available in InstallScript events in the following project types: InstallScript and InstallScript MSI.
Two new constants are available for use with the function Is:
• REGDB_KEYPATH_DOTNET_40_CLIENT
• REGDB_KEYPATH_DOTNET_40_FULL
Path Variable Support for Each Patch Configuration’s Output Location and Cache
The Common tab for a patch configuration that is selected in the Patch Design view contains two settings that let you
browse to the appropriate folder: Patch Output Location and Patch Creation Cache. InstallShield now lets you use path
variables for the folders instead of absolute paths. This support makes it easier to build releases on different build and
development machines that use different directory structures.
This support is available if InstallShield is configured to use path variables on your system. (That is, the Path Variables tab
on the Options dialog box must be configured to allow path variable support.) If you configure InstallShield to use absolute
paths, the Patch Design view shows the absolute path to folders.
This enhancement is available in the following project types: Basic MSI and InstallScript MSI.
Important Information
The InstallShield 2020 Standalone Build can coexist on the same machine with other versions of the Standalone Build. In
most cases, the Standalone Build is not installed on the same machine where InstallShield is installed. If you do install both
on the same machine and you want to use the automation interface, review the Installing the Standalone Build and
InstallShield on the Same Machine to learn about special registration and uninstallation considerations.
See Also
Upgrading Projects from InstallShield 2010 or Earlier
Upgrading Projects from InstallShield 2009 or Earlier
Upgrading Projects from InstallShield 2008 or Earlier
Upgrading Projects from InstallShield 12 or Earlier
Upgrading Projects from InstallShield 11.5 or Earlier
InstallShield 2010 Expansion Pack for Visual Studio 2010 includes changes that offer support for the final released version
of Visual Studio 2010 and .NET Framework 4. It also includes additional changes.
• The full prerequisites install the .NET Framework runtime and associated files that are required to run and develop
applications that target the .NET Framework 4.
• The client prerequisites install the .NET Framework runtime and associated files that are required to run most client
applications.
• The two Web download prerequisites require an Internet connection. These prerequisites download the required
redistributable files if appropriate. The other two prerequisites are stand-alone installations that do not require an
Internet connection.
The .NET Framework 4.0 requires Windows Installer 3.1 or later, as well as the Windows Imaging Component. Therefore,
the .NET Framework 4.0 Full prerequisites are configured to have dependencies for the following InstallShield
prerequisites:
In addition, the .NET Framework 4.0 Client prerequisites are configured to have dependencies for the following
InstallShield prerequisites:
Thus, if you add any of the .NET Framework 4.0 prerequisites to your project, InstallShield also adds prerequisites for
Windows Installer and Windows Imaging Component to your installation automatically by default. This could increase the
size of your installation. In some cases, you may want to edit the .NET Framework 4 prerequisites in the InstallShield
Prerequisite Editor (which is available in the Premier and Professional editions of InstallShield) to remove some of the
dependencies. For example, if your product requires Windows Vista or later or Windows Server 2008 and later, you may
want to remove the Windows Installer 3.1 dependencies that target earlier versions of Windows.
• Microsoft Office 2007 PIA (This prerequisite installs the Microsoft Office 2007 Primary Interop Assemblies. To use this
prerequisite, download the PrimaryInteropAssembly.exe file from Microsoft’s Web site and run it to extract the
o2007pia.msi file. Note that you may need to change the path of the o2007pia.msi installation in the .prq file,
depending on where the .msi package is located on your system.)
If your installation requires either of these, you can use the Installation Requirements page in the Project Assistant or the
System Search view 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.
See Also
What’s New in InstallShield 2010
Upgrading Projects from InstallShield 2009 or Earlier
InstallShield 2010 Service Pack 1 (SP1) includes changes that offer support for the final released versions of Windows 7,
Windows Server 2008 R2, and Windows Installer 4.5. It also includes additional changes.
Important • If you want to open an InstallShield 2010 project in InstallShield 2010 SP1, you must allow InstallShield to
upgrade your project to InstallShield 2010 SP1. InstallShield 2010 SP1 includes support for tables that were not available in
InstallShield 2010 projects, and these tables need to be added during the upgrade. Note that it is not possible to open
InstallShield 2010 SP1 projects in earlier versions of InstallShield (including InstallShield 2010 without SP1). Therefore, if
multiple users need to open and modify your InstallShield projects, ensure that all of you apply the SP1 patch at the same
time.
If you open an InstallShield 2010 project in InstallShield 2010 SP1, InstallShield 2010 SP1 displays a message box that asks you
if you want to convert the project to the new version. If you reply that you do want to convert it, InstallShield creates a backup
copy of the project before converting it.
Support for Creating App-V Package Upgrades and for Compressing App-V Packages
InstallShield now has support for creating App-V package upgrades. The Package Information page in the Microsoft App-V
Assistant has a new Upgrade Settings link. Click this link to specify whether you want to create an upgrade. If you specify
that you do want to create an upgrade, you can specify additional information about the upgrade, such as whether to
append the version number to the App-V package file name. By default, App-V package upgrades are not created.
The Build Options page in the Microsoft App-V Assistant has a new setting that lets you specify whether you want to use
compression for the data files in the App-V package. If you select Yes for this setting, InstallShield uses zlib compression for
your App-V package.
The App-V upgrade and compression functionality is available in the following project types: Basic MSI and MSI Database.
The Microsoft App-V Assistant is available if you purchase the Premier Edition of InstallShield.
Windows Installer 5 Support for Configuring New Customization Options for Windows
Services, Plus Other Service-Related Improvements
InstallShield now includes support for configuring extended customization options for Windows services. The
customization options include a new delayed auto-start capability to help system startup performance, improved failure
detection and recovery options to improve system reliability, and more. Windows Installer 5 supports these new options;
earlier versions of Windows Installer ignore them.
To configure the new service-related settings, use the new Services node in the Advanced Settings area for a component in
the Setup Design view (in installation projects) or the Components view. All of the services for a component are now
grouped and listed by service name under the Services node. In addition, the previously available service-related settings
are now consolidated in the same grid with the new settings. In earlier versions of InstallShield, these previously available
service-related settings were split among separate subviews for the Install NT Services and Control NT Services nodes. The
consolidated grid of settings makes it easier to create a component that installs, configures, starts, stops, or deletes a new
or existing service during installation or uninstallation.
This functionality is available in the following project types: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM
Database, and Transform.
• Services Settings
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.
Windows Installer 5 Support for Setting Windows Shell Properties for a Shortcut
The Shortcuts view in InstallShield now lets you specify one or more shortcut properties that need to be set by the
Windows Shell at run time. For example, if you do not want the Start menu entry for one of your shortcuts to be highlighted
as newly installed after end users install your product, you can set a property for that shortcut. You might want to use this
property with shortcuts that are for tools and secondary products that are part of your installation.
Windows Installer 5 includes support for setting Shell shortcut properties. Earlier versions of Windows Installer ignore
those properties.
Windows Installer 5 Support for the MsiPrint and MsiLaunchApp Control Events
When you are adding a control to a dialog in your project, you can select one of the new events that is now available for
Windows Installer 5:
• MsiPrint—You can add this event to a push button control that is on a dialog that has a scrollable text control. When
an end user clicks the push button control, the contents of the scrollable text control are printed.
• MsiLaunchApp—You can add this event to a check box control on a dialog, and select the file that you want to be
launched in the event’s Argument setting. The check box enables end users to choose whether to run the file at the
end of the installation. This event is typically used with a check box control that is on the SetupCompleteSuccess
dialog. The check box control should include a condition that prevents the control from being displayed during
uninstallation.
Windows Installer 5 includes support for these control events. Earlier versions of Windows Installer ignore these events.
Therefore, if your installation is run on a system that has Windows Installer 4.5 or earlier and you want to use one or both of
these new events, add a condition to the dialog controls so that they are not displayed on systems that have Windows
Installer 4.5 or earlier.
Note that if you want to add the print or launch support to your project but your installation targets systems that have
Windows Installer 4.5 or earlier, consider using the support that InstallShield provides. For information on adding the print
support, see Specifying Dialogs for Your Installation in the Project Assistant. For information on adding the print support,
see Adding a Print Button to a Dialog. The support that is available with InstallShield does not require Windows Installer 5.
Additional Changes
For a list of issues that are resolved in InstallShield 2010 SP1, see the release notes. The release notes are available from the
Help menu in InstallShield.
See Also
What’s New in InstallShield 2010
Upgrading Projects from InstallShield 2009 or Earlier
New Features
InstallShield includes the following new features.
Virtual applications run in virtual environments that keep the application layer and the operating system layer separate.
Each application includes its own configuration information in its virtual environment. As a result, many applications can
run side-by-side with other applications on the same computer without any conflicts.
To create a virtual application, use the new Microsoft App-V tab that is available in the following project types: Basic MSI
and MSI Database.
InstallShield also includes InstallShield prerequisites for the Microsoft App-V 4.5 Desktop Client installation and the
Microsoft Application Error Reporting installation. The Application Error Reporting prerequisite is a dependency of the App-
V prerequisite. The redistributable files for these InstallShield prerequisites 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.
• About Virtualization
Windows 7 and Windows Server 2008 R2 Support for Displaying Installation Progress on the Taskbar
Installations that are run on Windows 7 and Windows Server 2008 R2 now show a progress bar on the Windows taskbar
during file transfer. This applies to InstallScript and InstallScript MSI installations. In addition, it applies to Basic MSI
installations that display billboards that were configured in the Billboards view. Note that a progress bar is not displayed
on the taskbar on earlier versions of Windows. It is also not displayed during setup initialization or while InstallShield
prerequisites are being installed.
Beta Windows Installer 5 Support for Reducing the Time for Installing Large Packages
Use the new Fast Install setting in the General Information view to select one or more options that may help reduce the
time that is required to install a large Windows Installer package. For example, you can specify that you do not want a
system restore point to be saved for your installation. You can also specify that you want the installation to perform file
costing, but not any other costing.
This setting configures the new Windows Installer property MSIFASTINSTALL, which can be set at the command line.
Windows Installer 5 includes support for this property. Earlier versions of Windows Installer ignore it.
This setting is available in the following project types: Basic MSI, InstallScript MSI, MSI Database, and Transform.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
• Microsoft Hyper-V
• Microsoft Virtual PC
Two new Windows Installer properties are available when you add an MSI DLL custom action to your project to detect
virtual machines: IS_VM_DETECTED and IS_VM_TYPE. The custom action should be configured to call the ISDetectVM
function in the SetAllUsers.dll file, which is installed with InstallShield.
In addition, the InstallScript language has been expanded to support the detection. The structure SYSINFO contains a new
bIsVirtualMachine member, and a new VIRTUAL_MACHINE_TYPE constant is available for use with the InstallScript function
GetSystemInfo.
This feature is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, and
Merge Module.
For more information, see Detecting Whether the Installation Is Being Run on a Virtual Machine.
InstallShield must be installed on a 64-bit operating system in order to perform 64-bit COM extraction.
This feature is available in the following project types: Basic MSI, InstallScript MSI, and Merge Module.
New Support for Setting Permissions for Files, Folders, and Registry Keys
InstallShield offers two new ways to secure files, folders, and registry keys for end users who run your product in a locked-
down environment:
• Custom InstallShield handling—In Windows Installer–based projects, you can choose to use custom support for
setting permissions at run time. With this option, InstallShield stores permission information for your product in the
custom ISLockPermissions table of the .msi database. InstallShield also adds custom actions to your project to set
the permissions. This support is available in the following project types: Basic MSI, InstallScript MSI, Merge Module,
MSI Database, MSM Database, and Transform.
With the custom InstallShield handling option, the file, folder, or registry key for which you are setting permissions must be
installed as part of your installation. With the SetObjectPermissions function, the file, folder, or registry key can be
installed as part of your installation, or it can be already present on the target system.
Previously, the only option that InstallShield offered for setting permissions was to use the traditional Windows Installer
handling. With this option, the permission information is stored in the LockPermissions table of the .msi database. The
new custom InstallShield handling option and the SetObjectPermissions function offer several advantages over the
traditional Windows Installer handling:
• The custom option and the SetObjectPermissions function include support for many well-known security identifiers
(SIDs) that are not supported by the traditional Windows Installer handling option.
• The custom option and the SetObjectPermissions function support the use of localized user names for the supported
SIDs, unlike the traditional option. With the traditional option, if you try to use a localized name to set permissions on
a non-English system, the installation may fail.
• The custom option and the SetObjectPermissions function let you specify that you want to deny a user or group from
having the permissions that you are specifying. The traditional handling does not allow you to do this.
• The custom option and the SetObjectPermissions function let you add permissions to a file, folder, or registry key
that already exists on the target system, without deleting any existing permissions for that object. With the traditional
handling, the existing permissions are deleted.
• The custom option and the SetObjectPermissions function let you configure permissions for a folder (or a registry
key), and indicate whether you want the permissions to be applied to all of the folder’s subfolders and files (or the
registry key’s subkeys). With the traditional handling, if you want to configure permissions for a subfolder or a file in a
folder (or a subkey under a registry key), the parent that is created on the target system automatically inherits the
permissions of its child.
• The custom option and the SetObjectPermissions function let you configure permissions for a new user that is being
created during the installation. The traditional handling does not allow you to do this; the user must already exist on
the target system at run time.
The General Information view has a new Locked-Down Permissions setting that lets you specify whether you want to use
the new custom InstallShield handling or the traditional Windows Installer handling for all new permissions that you set for
files, folders, and registry keys in your project. If you have already configured some permissions in your project and then
you change the value of this setting, InstallShield lets you specify whether you want to use the alternate handling method
for those already-existing permissions. In all new projects, the default value for this setting is the custom InstallShield
handling option. If you upgrade a project from InstallShield 2009 or earlier to InstallShield 2010, the traditional Windows
Installer handling option is the default value of this setting. This new setting is available in the following project types:
Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.
• Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment
• SetObjectPermissions
• SetObjectPermissions Example
InstallShield prerequisites are redistributables that usually install a product or technology framework that is required by
your product. Now you can add any of the InstallShield prerequisites that are provided with InstallShield—or any of your
own custom-designed InstallShield prerequisites—to InstallScript projects. If you work on a mix of different project types,
InstallShield lets you simplify your testing matrix by enabling you to reuse this type of redistributable in all of your Basic
MSI, InstallScript, and InstallScript MSI projects.
To add an InstallShield prerequisite to an InstallScript project, use the new Prerequisites view. InstallScript projects
include support for the setup prerequisite type of InstallShield prerequisite, which is run before the main installation’s user
interface is run. InstallScript projects do not have support for feature prerequisites, which are InstallShield prerequisites
that are associated with features.
• Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
• Prerequisites View
New InstallShield Prerequisites for Windows Installer, .NET Framework, Crystal Reports, and Other
Redistributables
InstallShield includes a number of new InstallShield prerequisites that you can add to Basic MSI, InstallScript, and
InstallScript MSI projects:
• Windows Installer 4.5 (The InstallShield prerequisites for Windows Installer 4.5 include the fix that is described in
Microsoft KB958655.)
• Windows Installer 4.5 Update (The InstallShield prerequisites for the Windows Installer 4.5 Update include the fix that
is described in Microsoft KB958655. Windows Installer 4.5 must already be installed on the target system for this
update.)
• Windows Installer 3.1, Windows Installer 3.0, and Windows Installer 2.0 (These versions of Windows Installer
redistributables were previously available if you added Windows Installer to your project in the Releases view. These
versions were not previously available as InstallShield prerequisites.)
• Internet Explorer 8
• Oracle 11g Instant Client 11.1.0.7 (Oracle does not provide an installer for the Oracle Instant Client files, so you need to
create an .msi package before you can use this InstallShield prerequisite in your projects. You can do so easily by using
the Oracle Instant Client installation project that is installed with InstallShield (InstallShield Program Files
Folder\Support\Oracle Instant Client.)
• Crystal Reports Basic for Visual Studio 2008 (Use this prerequisite with the Crystal Reports Basic installation that is
installed with Visual Studio 2008. Note that you may need to change the path of the Crystal Reports Basic installation
in the .prq file, depending on where the .msi package is located on your system.)
New Tool for Scanning an IIS Web Site, Recording Its Settings, and Importing Those Settings into an
InstallShield Project
InstallShield includes an IIS scanner (IISscan.exe), a new command-line tool for scanning an existing IIS Web site and
recording IIS data about the Web site. The IIS scanner creates an XML file that contains all of the settings for the Web site, its
virtual directories, its applications, and its application pools. You can use the XML file to import the IIS data into the
Internet Information Services view in InstallShield. Once you have imported the IIS data into a project, you can use the
Internet Information Services view to make changes to the IIS settings as needed.
The ability to import the IIS data into an InstallShield project is available only in the Premier edition of InstallShield.
• Scanning an IIS Web Site and Importing Its Settings into an InstallShield Project
• Filtering IIS Data When Importing a Web Site and Its Settings into an InstallShield Project
• IISscan.exe
Ability to Add IIS Web Applications to Web Sites, Plus Other IIS-Related Improvements
InstallShield now lets you add IIS Web applications to Web sites. You can do so by right-clicking a Web site in the Internet
Information Services view and clicking New Application. Once you have added a new application, you can configure its
settings in the right pane.
InstallShield also lets you create a virtual directory without an application. Previously whenever you created a virtual
directory, an application was also created automatically.
• Managed Pipeline Mode—This setting enables you to specify the appropriate request-processing pipeline mode—
either integrated or classic—for an application pool.
• Enable 32-Bit Applications—This setting lets you specify whether you want to allow 32-bit applications in the
selected application pool to be run on 64-bit systems.
• .NET Framework Version—This setting is where you specify the version of the .NET Framework that an application
pool should load.
• ASP.NET Platform—If your installation may be run on a 64-bit version of Windows with the .NET Framework, use this
setting to specify which ASP.NET platform should be used to map a Web site, application, or virtual directory to the
ASP.NET version.
This feature is available in the following project types: Basic MSI, InstallScript, and InstallScript MSI.
You can use Windows Installer properties to specify the names of the text files that you want to include in or exclude from
your search. You can also use properties to specify the search strings and the replacement strings. This enables you to use
data that end users enter in dialogs, or other configuration information that is determined at run time, when your
product’s text files are modified on the target system. For example, if your project includes a dialog in which end users
must specify an IP address, your installation can search a set of files for a token, and replace it with the IP address that end
users enter.
Note that the Text File Changes view offers an alternative for configuring XML file changes in the XML File Changes view.
Using the Text File Changes view offers some advantages. For example, this new view does not have any run-time
requirements; however, changes that are configured through the XML File Changes view require MSXML to be present on
the target system. In addition, configuring changes in the Text File Changes view does not require you to enter XPath
queries, as is required in the XML File Changes view.
The Text File Changes view is available in the following project types: Basic MSI and InstallScript MSI.
• Specifying the Code Page that Should Be Used for Opening ANSI Text Files
• The view has a toolbar with buttons that let you add, edit, delete, find, replace, export, and import string entries. It
also has a button that lets you search the project to identify all of the instances in which a specific string identifier is
used.
• The top of the view has a new group box area; you can drag and drop column headings onto this area to organize the
rows in the view in a hierarchical format. This functionality makes it easy to sort string entries by categories such as
language and by modified date.
• This view has support for dynamic searches—as you are typing a string in the search box, InstallShield hides all of the
string entries that do not contain it.
This feature is available in the following project types: Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, Merge
Module.
The Build tab in the Releases view has a new Build UTF-8 Database setting that lets you specify that a Windows Installer
database, along with any instance or language transforms, be built using the UTF-8 encoding. The UTF-8 encoding
supports characters from all languages simultaneously, enabling you to mix and match, for example, Japanese and
German, or Russian and Polish, both in text shown to end users and in file names and registry keys. These mixed languages
work correctly regardless of the current language of the target system. Unicode support has also been added to key parts
of the installation run times, including IIS support and changes to text and XML files.
The default value for the new Build UTF-8 Database setting is No.
The automation interface now includes support for this new setting. The ISWiRelease object includes a new
BuildUTF8Database property that lets you specify whether you want to use the UTF-8 encoding.
This feature is available in the following project types: Basic MSI, InstallScript MSI, and Merge Module projects.
To learn more, see the description of the Build UTF-8 Database setting.
InstallShield now uses the UTF-8 encoding when saving both binary and XML project files. Because of this change, the files,
registry data, and other strings that are used in the project can include characters from all languages simultaneously. With
this encoding, InstallShield no longer needs to use an unreadable Base64 encoding for strings that are stored in the
ISString table. Instead, as you add or modify strings in a project, InstallShield now saves them as human-readable
Unicode strings that you can easily examine for changes across revisions of your project. Therefore, InstallShield uses only
Unicode strings for all new projects that are created in InstallShield 2010; for upgraded projects, InstallShield uses Unicode
for new and modified strings, as well as for strings that have been exported and reimported.
If you use Unicode values that cannot be represented in the target build (for example, an InstallScript installation, or a
Basic MSI installation in which No is selected for the Build UTF-8 Database setting), a new build error points to the item that
needs to be changed. In some instances, this reveals invalid string entries that were silently allowed in earlier versions of
InstallShield.
Many views in InstallShield have been enhanced to display and allow you to enter characters from all languages. For
example, in the Files and Folders view, Chinese file names from your local English system are no longer displayed with
question marks for their names, and now you can add these files to your project. Similarly, the Registry view no longer
converts Thai registry keys or values to question marks, and you can install them with your Windows Installer–based
projects. In addition, you can view and edit strings from all languages in the String Editor view, a new separate view;
previously, string entries were available from separate language nodes in the General Information view. Examples of other
enhanced views include the Property Manager, Path Variables, Direct Editor, General Information, and Setup Design views.
Note that whenever No is selected for the Build UTF-8 Database setting, all file names, registry keys, and other strings must
still consist of characters from the code page of all target languages that will use it. In this scenario, if an item uses a
character that is not available on the code page of a target language, InstallShield reports a new build error that points to
this item; the Chinese file name cannot be used in an English installation unless Yes is selected for the Build UTF-8
Database setting.
Following are some of the highlights regarding billboard support in Basic MSI projects:
• You can add an Adobe Flash application file (.swf) as a billboard in your project. Flash application files can consist of
videos, movies, sounds, interactive interfaces, games, text, and more—anything that is supported by the .swf type of
file.
• InstallShield lets you use .bmp, .gif, .jpg, and .jpeg files as billboards.
• InstallShield includes a Billboard Type setting that lets you specify which style of billboard you want to use in your
installation. For example, with one style, the installation displays a full-screen background, with billboards in the
foreground, and a small progress box in the lower-right corner of the screen. With another style, the installation
displays a standard-size dialog that shows the billboards. The bottom of this dialog shows the progress bar.
• InstallShield lets you preview a billboard to see how it would be displayed at run time, without requiring you to build
and run a release. Previewing a billboard lets you see how your billboard will look with the background color, position,
and related settings that are currently configured for your billboard.
The Billboards view in InstallShield is where you add billboard files, configure billboard-related settings, and preview
billboards.
Previously, only InstallScript and InstallScript MSI projects included support for billboards. Note that billboard support in
these project types is different than support in Basic MSI projects. For more information, see Displaying Billboards.
Billboard files in InstallScript and InstallScript MSI projects must follow a designated naming convention. Each file name
must begin with bbrd, followed by the number of the billboard (from 1 through 99); each must end with a supported file
extension (.bmp, .gif, .jpg, or .jpeg). Note that it is no longer necessary for the file name numbers to be contiguous; that is,
you can add bbrd1.jpg, bbrd3.jpg, and bbrd5.jpg to your project, and each image is displayed at run time in order.
Previously, there could not be any numbers missing from the file name sequence for your billboards. For example, if you
added bbrd1.bmp, bbrd2.bmp, and bbrd4.bmp to your installation project, then bbrd1.bmp and bbrd2.bmp were displayed at
run time; however, bbrd4.bmp was not displayed, since bbrd3.bmp was missing from the sequence.
Ability to Play an Adobe Flash Application File (.swf) with the InstallScript Function PlayMMedia
The InstallScript function PlayMMedia now includes support for playing an Adobe Flash application file (.swf) on a
background window during InstallScript and InstallScript MSI installations. Flash application files can consist of videos,
movies, sounds, interactive interfaces, games, text, and more—anything that is supported by the .swf type of file.
If you are using a Flash file, you can use SizeWindow and PlaceWindow to control the size and placement of the
background window that displays the Flash file.
• PlayMMedia
• SizeWindow
• PlaceWindow
Support for HTML Controls on Dialogs During InstallScript and InstallScript MSI Installations
InstallShield includes support for HTML controls on dialogs in InstallScript and InstallScript MSI projects. HTML controls
enable you to use HTML markup for dialog controls. You can include on dialogs links to Web pages, installed HTML files,
and HTML support files. If an end user clicks the hyperlink on the run-time dialog, you can have the HTML page open in an
Internet browser, or you can trigger other behavior that you have defined through your InstallScript code. The HTML
control lets you use any valid HTML markup, including styles to control their appearance.
The HTML control also lets you display the HTML content directly on a dialog if the content is an installed HTML file or HTML
support file.
A new InstallScript function called CtrlGetUrlForLinkClicked is available. This function retrieves the URL for a link that an
end user clicked.
• CtrlGetUrlForLinkClicked
• CtrlGetUrlForLinkClicked Example
Ability to Specify Paths for Libraries to Which the InstallScript Compiler Should Link
The Compile/Link tab on the Settings dialog box has a new Additional Library Paths box that lets you specify the locations
where the InstallScript compiler should search for InstallScript libraries (.obl files) that should be linked to your script. In
addition, when you specify your custom libraries on this tab, you can now specify just the file name, without the full path.
These changes enable you to move your libraries to different directories but still successfully compile your script without
manually changing the path for libraries on the Compile/Link tab.
Enhancements
InstallShield includes the following enhancements.
Usability Enhancements
Many of the views in InstallShield have been enhanced to improve productivity and usability. For example, several views
contain new toolbars that make options easier to find. Some of the views that contain grids let you customize how the rows
in a grid are organized. Searches are performed more quickly in the views that offer search capabilities. Following are
examples of some of the highlights:
• Direct Editor view—When you select a table in this view, a new toolbar is displayed. The toolbar has buttons that let
you add, cut, copy, paste, find, and replace data in the table. This view also has support for dynamic searches—as you
are typing a string in the search box, InstallShield hides all of the table records that do not contain it. When you are
adding or editing a record, InstallShield displays help text for each field.
• Property Manager view—This view contains a new toolbar that has buttons for performing tasks such as adding and
deleting properties. This view also has support for dynamic searches—as you are typing a string in the search box,
InstallShield hides all of the table records that do not contain it. The top of the view has a new group box area; you can
drag and drop column headings onto this area to organize the rows in the view in a hierarchical format. You can now
select multiple properties in this view (by using the mouse and the SHIFT or CTRL button) and then delete them all at
once.
• Redistributables view—The new toolbar and the new group box area in this view provide robust search and
organizational functionality. You can drag and drop column headings onto the group box area to organize the list of
redistributables in a hierarchical format. In addition, you can type a string in the toolbar’s search box, and
InstallShield hides all of the redistributables that do not contain it.
• Internet Information Services view—This view has been redesigned to look similar to IIS 7: the settings are now
displayed in grids, instead of on tabs. The grids have buttons that let you sort the grid settings by category or
alphabetically. When you select a setting in one of the grids in this view, InstallShield displays help information for
that setting in the lower-right pane.
• General Information view—All of the settings in this view are displayed in one grid, instead of as separate grids that are
associated with nodes within this view. The settings are grouped into several categories to make it easy to find a
particular setting. In addition, the grid has a button that lets you sort the grid settings by category or alphabetically.
The string tables that were previously in this view have been moved to a new String Editor view.
• Path Variables view—This view contains a new toolbar that has buttons for performing tasks such as adding and
deleting path variables. This view also has support for dynamic searches—as you are typing a string in the search box,
InstallShield hides all of the rows that do not contain it. The top of the view has a new group box area; you can drag
and drop column headings onto this area to organize the rows in the view in a hierarchical format. You can now select
multiple path variables in this view (by using the mouse and the SHIFT or CTRL button) and then delete them all at
once.
In addition, the Output window, which is displayed when you are building a release, performing validation, or compiling
script, has been enhanced. The Output window or its individual tabs can be docked to any side of the workspace in
InstallShield, or they can be dragged to free-floating positions. If you drag the Output window or one of its tabs to the edge
of the InstallShield interface, it becomes a docked window. If you drag the Output window or one of its tabs away from any
of the edges of the InstallShield interface, it becomes undocked.
The Custom Actions and Sequences view has a new Action Text area that lets you specify action descriptions and details.
This is available in the following project types: Basic MSI, InstallScript MSI, MSI Database, and Transform.
Ability to Detect Whether a 64-Bit System Allows 32-Bit IIS Applications to Be Run
At run time, you may need to have your installation check the Enable32bitAppOnWin64 property on systems that have IIS 6.
Depending on the requirements for your product and the results of that check, you may want the installation to skip a
particular component that contains a 32-bit IIS 6 application, or a 64-bit IIS application, for example, and proceed with the
rest of the file transfer.
InstallShield includes a sample Windows Installer DLL file that detects how the Enable32bitAppOnWin64 property is set on
a target system. You can add a custom action for this DLL to your project. If 32-bit applications are allowed, the Windows
Installer property ISIIS6APPPOOLSUPPORTS32BIT is set to a value of 1; if they are not allowed, this property is not set. You
can use this property in conditions to prevent or trigger certain behavior. For example, you can create a launch condition if
you want the installation to exit if the ISIIS6APPPOOLSUPPORTS32BIT is set or not set.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
For instructions on how to add the custom action to your project, see Considerations for Supporting IIS 6 on 64-Bit
Platforms.
For example, Web service extensions can be installed on systems that have IIS 6. On systems that have IIS 7, Web service
extensions can be installed only if the IIS Metabase and IIS 6 Configuration Compatibility feature is installed. Thus, you
might want to configure your installation to verify that IIS 6 is present or the IIS 6 compatibility feature is installed; if either
of those conditions are false, the installation would exit and display an error message.
InstallShield includes a sample Windows Installer DLL file that detects whether the IIS Metabase and IIS 6 Configuration
Compatibility feature is installed. You can add a custom action for this DLL to your project. If the IIS Metabase and IIS 6
Configuration Compatibility feature is installed, the Windows Installer property ISIISMETABASECOMPATPRESENT is set to a
value of 1; if it is not installed, this property is not set. You can use this property in conditions to prevent or trigger certain
behavior. For example, you can create a launch condition if you want the installation to exit if the
ISIISMETABASECOMPATPRESENT is set or not set.
This feature is available in the following project types: Basic MSI and InstallScript MSI.
For instructions on how to add the custom action to your project, see Determining If a Target System Has IIS 6 or Earlier or
the IIS 6 Metabase Compatibility Feature.
This enhancement applies to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Ability to Specify Whether an XML File Should Be Formatted After Run-Time Changes
The Advanced tab for an XML file in the XML File Changes view has a new Format XML after changes check box that lets
you specify whether you want the XML file to be formatted after the run-time changes are made to the file. When formatting
the file, the installation adds indentations to the file and replaces empty-element tags with start tags and end tags. This
may cause problems for web.config files, so you may want to clear this check box for your project.
This enhancement applies to the following project types: Basic MSI, InstallScript, and InstallScript MSI.
Predefined System Searches for the .NET Framework and Internet Explorer 8
InstallShield has two new predefined system searches:
• Internet Explorer 8
If your installation requires any of these, you can use the System Search view or the Installation Requirements page in the
Project Assistant to add these system searches to your project. When end users launch your installation, Windows Installer
checks the target system to see if the requirements are met; if they are not met, the installation displays the error message
that is defined for the system search.
This enhancement applies to the following project types: Basic MSI, InstallScript MSI, Merge Module, and Transform.
Ability to Specify a Maximum Service Pack Number and 64-Bit Locations for InstallShield Prerequisite
Conditions
The Prerequisite Condition dialog box, which is displayed when you are adding or modifying a condition for an InstallShield
prerequisite in the InstallShield Prerequisite Editor, has a new field that lets you specify the maximum service pack
number. Previously, it was possible to specify a minimum service pack number, but not a maximum service pack number.
In addition, the Prerequisite Condition dialog box now includes the following 64-bit locations in the box that is displayed
when you are specifying file-related conditions: [CommonFiles64Folder], [ProgramFiles64Folder], and [System64Folder].
You can select any of these properties if you want to use 64-bit locations in the file path. At run time, the installation checks
these 64-bit locations if the target system is 64 bit. For 32-bit systems, the installation checks the 32-bit location
equivalents.
• RunMsiValidator—Use this parameter to specify the .cub file that you want to use for validation. This parameter is
exposed as the ItemGroup InstallShieldMsiValidators when the default targets file is used.
• PatchConfiguration—Use this parameter to specify the patch configuration that you want to build through MSBuild.
This parameter is exposed as the property InstallShieldPatchConfiguration when the default targets file is used.
• PathVariables—Use this parameter to override the value of a path variable. This parameter is exposed as the
ItemGroup InstallShieldPathVariableOverrides when the default targets file is used.
• PreprocessorDefines—Use this parameter to specify preprocessor definitions for compiling InstallScript. This
parameter is exposed as the ItemGroup InstallShieldPreprocessorDefines when the default targets file is used.
OSFilter Property Values for Windows 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, and Windows
Server 2003
The following constants are now available for use with the OSFilter member of the ISWiComponent and ISWiRelease
objects in the automation interface:
• eosWinServer2003 (8388608)
In addition, the value for the eosAll constant is now 64028880; previously, it was 5308624.
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.
• ISWiComponent Object
• ISWiRelease Object
The list of available property values for the IsPlatformSelected property of the ISWiComponent object has been expanded.
This property now has values for 32-bit, 64-bit Itanium, AMD64, and Windows Server 2003 R2. This applies to the following
project types: InstallScript and InstallScript Object.
Note that some of the values for the existing constants have changed. To learn the new values, see ISWiComponent Object.
The AddSQLScriptEx method has been added to the ISWiSQLConnection object. Use this method to add an ISSQLScriptFile
entry and generate a valid name from the passed string. The method ensures that the names of the entries in the
ISSQLScriptFile table are unique and less than 47 characters in length.
The read-write RunOnLogon property has been added to the ISWiSQLScript object. This property corresponds with the Run
Script During Login check box on the Runtime tab for a SQL script in the SQL Scripts view.
The read-write Condition property has also been added to the ISWiSQLScript object. This property specifies the condition
that is evaluated at run time to determine whether the SQL script should be run during installation or uninstallation. If the
condition evaluates to true, the script is run. This property is available for the following project types: Basic MSI and
InstallScript MSI.
The read-write DisplayName property has been added to the ISWiUpgradeTableEntry object. This property gets or sets the
name of an upgrade entry. This is the internal name that is displayed for an upgrade item in the Upgrades view. This
property is available for the following project types: Basic MSI and InstallScript MSI.
• SYSINFO.bWinServer2003R2—This is a new SYSINFO structure member. If the operating system is Windows Server
2003 R2, this value is TRUE. (Note that the value of SYSINFO.WINNT.bWinServer2003 is also TRUE on this operating
system.)
• ISOSL_WIN7_SERVER2008R2—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 7 or Windows
Server 2008 R2.
• ISOS_ST_SERVER2003_R2—This is a new operating system suite that is available for use with the FeatureFilterOS
function and the SYSINFO structure variable. It indicates that the target system is running Windows Server 2003 R2.
• The SYSINFO.WINNT.bWinVista structure member does not distinguish between Windows Vista or Windows Server
2008. Therefore, the new member SYSINFO.WINNT.bWinVista_Server2008 is now available. The old alias is still
available, but the new one may be preferred for clarity in code.
• The ISOSL_WINVISTA predefined constant does not distinguish between Windows Vista or Windows Server 2008.
Therefore, the new constant ISOSL_WINVISTA_SERVER2008 is now available. The old alias is still available, but the
new one may be preferred for clarity in code.
For more information, see FeatureFilterOS function and the SYSINFO structure variable.
Ability to Easily Override InstallScript Dialog Source Code in the InstallScript View
The event category drop-down list in the InstallScript view has a new Dialog Source option. If you select this option, the
event handler drop-down list shows all of the built-in InstallScript dialogs. You can select any dialog in this list to modify its
code.
This functionality applies to the following project types: InstallScript, InstallScript MSI, and InstallScript Object.
For information about built-in InstallScript dialog functions that are available when you select the Dialog Source option,
see Dialog Functions.
Changes to the Major and Minor Version Registry Entries for the Uninstall Key of InstallScript
Installations
InstallScript installations now create VersionMajor and VersionMinor registry values in the Uninstall key; the names of
these values now match the entries that are created during Basic MSI and InstallScript MSI installations. This applies to
new installations that are created in InstallShield 2010, as well as installations that are upgraded from InstallShield 2009 or
earlier. Previously, in InstallShield 2009 and earlier, the names of the values that InstallScript installations created were
MajorVersion and MinorVersion; these are no longer created.
In order to use the new registry values, the values of the following InstallScript constants have been changed:
When the MaintenanceStart function is called, it creates the updated value names in the registry. By default, it also
deletes the old value names if they exist. If you do not want the old value names to be deleted from target systems, you can
use the new REGDB_OPTIONS option called REGDB_OPTION_NO_DELETE_OLD_MAJMIN_VERSION.
• REGDB_UNINSTALL_MAJOR_VERSION_OLD
• REGDB_UNINSTALL_MINOR_VERSION_OLD
You can specify these constants with the RegDBGetItem, RegDBSetItem, and RegDBDeleteItem functions to get, set, and
delete the old values.
• REGDB_VALUENAME_UNINSTALL_MAJORVERSION
• REGDB_VALUENAME_UNINSTALL_MAJORVERSION_OLD
• REGDB_VALUENAME_UNINSTALL_MINORVERSION
• REGDB_VALUENAME_UNINSTALL_MINORVERSION_OLD
• REGDB_UNINSTALL_MAJOR_VERSION_OLD
• REGDB_UNINSTALL_MINOR_VERSION_OLD
• REGDB_OPTIONS
• RegDBSetItem
• RegDBGetItem
• RegDBDeleteItem
New CtrlGetDlgItem Function for Retrieving the Window Handle of a Control in a Custom InstallScript
Dialog
A new InstallScript function called CtrlGetDlgItem is now available. The CtrlGetDlgItem function retrieves the window
handle of a control in a custom dialog. CtrlGetDlgItem is similar to the Windows API GetDlgItem, except that with
CtrlGetDlgItem, you can specify the InstallScript dialog name instead of the dialog’s window handle. For more
information, see CtrlGetDlgItem.
New InstallScript Constant for Passing a Null Pointer for an InstallScript String to an External DLL
Function
You can use the IS_NULLSTR_PTR variable to pass a null pointer to an external DLL function or Windows API through a
parameter that has been prototyped as an InstallScript string. This functionality works for byval string, byref string,
wstring, and binary data types. For more information, see IS_NULLSTR_PTR.
New StrConvertSizeUnit Function for Converting an InstallScript Size Unit Constant to a Display String
A new InstallScript function called StrConvertSizeUnit is now available. The StrConvertSizeUnit function returns the
appropriate display string for the InstallScript size unit constant that is specified.For more information, see
StrConvertSizeUnit.
New StrTrim Function for Removing Leading and Trailing Spaces and Tabs from a String
A new InstallScript function called StrTrim is now available. The StrTrim function removes the leading and trailing spaces
and tabs from a string. For more information, see StrTrim.
• SdLicenseEx displays a dialog that shows a question in a static text field. The end user responds by clicking the Yes or
No button.
• SdLicense2Ex displays a dialog that has two radio buttons (one for accepting the terms of the license agreement, and
one for not accepting them). The Next button becomes enabled when the end user clicks the appropriate button to
accept the terms of the license agreement.
• AdminAskPath
• CharReplace
• FormatMessage
• LogReadCustomNumber
• LogReadCustomString
• LogWriteCustomNumber
• LogWriteCustomString
You can copy this code from the InstallShield documentation, paste it into your InstallScript code, and customize it as
necessary.
• For features that were built by InstallShield, the viewer has the following new fields: Password Protected, Split Before,
Split After, Split Not Allowed, and Split Before Not Allowed, and Image Index.
• For InstallScript Objects that are included in the InstallScript installation, the viewer has a new Object version field.
• For components, the viewer has the following new fields: Encrypted, Data as Files, and .NET Assembly.
• For media, the viewer has the following new field: Executable File.
See Also
Upgrading Projects from InstallShield 2009 or Earlier
Upgrading Projects from InstallShield 2008 or Earlier
Upgrading Projects from InstallShield 12 or Earlier
Upgrading Projects from InstallShield 11.5 or Earlier
In addition, InstallShield integration with Visual Studio supports Visual Studio 2008 SP1, enabling development of
installations and products within the Visual Studio interface.
In order to support these new prerequisites, the InstallShield Prerequisite Editor has a new registry condition type.
Microsoft SQL Server 2005 Express SP2 (x86 and x64 WOW) Prerequisite Available
InstallShield now includes a new InstallShield prerequisite for Microsoft SQL Server 2005 Express Edition SP2. This
prerequisite installs Microsoft SQL Server 2005 Express Edition SP2 on 32-bit and 64-bit (WOW) systems. You can add this
InstallShield prerequisite to Basic MSI and InstallScript MSI projects.
Additional Changes
For a list of issues that are resolved in InstallShield 2009 SP2, see the release notes. The release notes are available from the
Help menu in InstallShield.
See Also
What’s New in InstallShield 2009 SP1
What’s New in InstallShield 2009
Upgrading Projects from InstallShield 2008 or Earlier
InstallShield 2009 supports a beta version of Windows Installer 4.5. InstallShield 2009 Service Pack 1 (SP1) includes
changes that offer support for the final released version of Windows Installer 4.5:
• Windows Installer 4.5 for Windows Vista and Server 2008 (x86)
• Windows Installer 4.5 for Windows Vista and Server 2008 (x64)
• Windows Installer 4.5 for Windows Vista and Server 2008 (IA64)
• Windows Installer 4.5 for Windows Server 2003 SP1 and later (x86)
You can add these InstallShield prerequisites to Basic MSI and InstallScript MSI projects if you want Windows Installer 4.5
to be installed at run time.
Additional Changes
For a list of issues that are resolved in InstallShield 2009 SP1, see the release notes. The release notes are available from the
Help menu in InstallShield.
See Also
What’s New in InstallShield 2009
Upgrading Projects from InstallShield 2008 or Earlier
New Features
InstallShield includes the following new features.
Including InstallShield prerequisites in your project enables you to chain multiple installations together, bypassing the
Windows Installer limitation that permits only one Execute sequence to be run at a time. The Setup.exe setup launcher
serves as a bootstrap application that manages the chaining.
The Redistributables view is where you add InstallShield prerequisites to a project and specify whether you want them to
run before your main installation or be associated with one or more features in your main installation.
Previously, all InstallShield prerequisite installations were run before the main installation ran, and the InstallShield
prerequisites could not be associated with any features. This type of prerequisite, which is still available, is called a setup
prerequisite.
Beta Windows Installer 4.5 Support for Installation of Multiple Packages Using Transaction Processing
InstallShield lets you add Windows Installer packages to Basic MSI and InstallScript MSI projects as chained .msi packages.
If your Basic MSI or InstallScript MSI installation includes chained .msi packages and Windows Installer 4.5 is present on the
target system, the Windows Installer installs the multiple packages using transaction processing. The packages are
chained together and processed as a single transaction. If one or more of the packages in the transaction cannot be
installed successfully or if the end user cancels the installation, the Windows Installer initiates rollback for all of the
packages to restore the system to its earlier state.
The Chained .msi Packages area of the Releases view is where you add to your project one or more .msi packages that you
want to be chained to your main installation. This area is also where you can assign release flags to the chained .msi
packages, configure settings such as the properties that should be passed to the chained packages, and specify conditions.
Beta Windows Installer 4.5 Support for Using the InstallScript Engine as an Embedded User Interface for
InstallScript MSI Installations
For InstallScript MSI projects, you now have the option to use the InstallScript engine as an embedded custom user
interface (UI) handler, rather than as an external custom UI handler, as it has traditionally been used. Windows Installer 4.5
includes support for this new capability. Use this new embedded option if you want end users to be able to launch your
installation directly from an .msi package, but you also want your installation to include a highly customized user interface
that you have defined through InstallScript.
To specify whether you want to use the new embedded InstallScript UI functionality or the traditional external InstallScript
UI functionality, use the new InstallScript User Interface Type setting; this is a project-wide setting in the General
Information view. By default, InstallShield uses the traditional style for all InstallScript MSI projects; a Setup.exe setup
launcher is required for this traditional option.
A new INSTALLSCRIPTMSIEEUI variable is available. This variable is set to True at run time if the new style is used;
otherwise, it is set to False.
Note that the new style does have some limitations that the traditional style does not. For example, some of the
InstallScript functions and command-line parameters are not supported or behave differently with the new style. For
detailed information about the two styles, see Using the InstallScript Engine as an External vs. Embedded UI Handler for
InstallScript MSI Installations.
• Specifying the InstallScript User Interface Type for InstallScript MSI Installations
• INSTALLSCRIPTMSIEEUI
Windows Installer 4.5 supports this new functionality; earlier versions of Windows Installer ignore this new setting. In
addition, if the DisableSharedComponent policy is set to 1 on a target system, Windows Installer ignores this setting for all
packages.
This feature applies to Basic MSI, InstallScript MSI, Merge Module, and Transform projects.
To learn more, see Specifying Whether Shared Component Patching Should Be Enabled for a Component.
Windows Installer 4.5 supports this new functionality; earlier versions of Windows Installer ignore this new setting.
This feature applies to Basic MSI, InstallScript MSI, Merge Module, and Transform projects.
For more information, see the description of the Uninstall Superseded Component setting.
Beta Windows Installer 4.5 Support for Running a Custom Action Only During Patch Uninstallation
Use the new Run During Patch Uninstall setting for a custom action to indicate whether Windows Installer should run the
selected custom action only when a patch is being uninstalled. This setting is available in the Custom Actions and
Sequences view of Basic MSI, InstallScript MSI, MSI Database, and Transform projects. It is also available in the Custom
Actions view of Merge Module and MSM Database projects.
You can also use the Run During Patch Uninstall check box on the Additional Options panel in the Custom Action Wizard to
configure the behavior of a custom action.
For details about this new functionality, see Run During Patch Uninstall.
A Unicode setup launcher can correctly display double-byte characters in the user interface of the setup launcher,
regardless of whether the target system is running the appropriate code page for the double-byte-character language. An
ANSI setup launcher displays double-byte characters in the setup launcher dialogs if the target system is running the
appropriate code page. However, it displays garbled characters instead of double-byte characters in those dialogs if the
target system is not running the appropriate code page.
Use the new Setup Launcher Type setting on the Setup.exe tab for a release in the Releases view to specify whether you
want to use Unicode or ANSI. Unicode is the default type for all new Basic MSI projects.
InstallShield also now enables you to specify whether you want to create a Unicode version or an ANSI version of the
Update.exe update launcher for a patch or a QuickPatch package.
Use the new Update Launcher Type setting on the Advanced tab for a patch configuration in the Patch Design view to
specify whether you want to use Unicode or ANSI. For a QuickPatch project, the Update Launcher Type setting is on the
Advanced tab in the Build Settings area of the General Information view. Unicode is the default type for all new patch
configurations and QuickPatch packages.
At build time, InstallShield creates a product code–changing instance transform for each instance and streams the
instance transforms into the .msi package. At run time, the setup launcher displays a new instance selection dialog that
lets end users specify whether they want to install a new instance, or update or maintain an already installed instance.
In addition, if you build a patch in the Patch Design view for a product whose installation includes multiple-instance
support, InstallShield now creates a patch that enables end users to update a specific instance or all instances. At run time,
the Update.exe file displays a patch version of the instance selection dialog.
A new /instance command-line option is available for Setup.exe and Update.exe. This option lets you specify which
instance you want to install, update, or uninstall; it also lets you suppress the instance selection dialog.
In addition, an updated Microsoft .NET Framework object is available in InstallShield for InstallScript projects. This object
includes support for versions 3.5, 3.0 SP1, 3.0, 2.0 SP1, 2.0, 1.1 SP1, and 1.0 SP3 of the .NET Framework, including 32-bit, 64-
bit x64, and 64-bit Itanium versions. The object also includes all supported language packs, as well as the Web downloader
redistributables where available.
• Including the Microsoft .NET Framework and Microsoft .NET Framework Language Pack Prerequisites
• InstallShield MSI Diff enables you to quickly compare two .msi, .msm, or .pcp files. It lets you apply one or more .msp
and .mst files to an .msi file and see the changes in the resulting .msi database. You can also use this tool to compare
two InstallShield project files (.ism or .ise) that are saved in binary format. This tool uses color coding to show
additions, modifications, deletions, and schema differences. You can easily integrate it with most source code control
systems.
• InstallShield MSI Query lets you test SQL statements using the Windows Installer version of SQL before you run them
in your build script. You can quickly see if a SQL statement is formatted correctly and view the results that it generates.
• InstallShield MSI Sleuth is a diagnostic tool that lets you view the current installed state of a target system.
InstallShield MSI Sleuth displays a list of all of the .msi packages that are installed. You can click any .msi package in
the list to see the status of its features and components, its known source locations, as well as tables and binary
streams within the database. This tool also helps you identify the installed product or products whose packages
contain a specific component code.
• InstallShield MSI Grep searches a collection of .msi and .msm packages for specific text. You can narrow the search to
show results for only certain tables or columns.
You can launch any of these tools from the InstallShield Tools subfolder on the Windows Start menu.
These InstallShield MSI tools are included with the Premier and Professional editions of InstallShield. The Premier edition
also includes a separate installation and extra licenses that let you install just the tools, without InstallShield, on separate
machines. For specific terms, see the InstallShield End-User License Agreement.
Ability to Compress Files that Are Streamed into Setup.exe and ISSetup.dll and to Specify the
Compression Level
If you build a release that uses a Setup.exe setup launcher or a ISSetup.dll file (which contains the InstallScript engine),
InstallShield now compresses files that it streams into the Setup.exe file or the ISSetup.dll file. The default compression
level that InstallShield uses offers a balance between file size and time that is required to extract the compressed files at
run time. If you want to change the compression level or you do not want to use any compression, you can override the
default level through a machine-wide setting.
By default, InstallShield does not compress any files that have a .cab file extension when it is streaming them into the
Setup.exe file at build time, since .cab files are already a compressed type of file. You can modify this default compression
exclusion list to include other file types or specific files as needed. The exclusion list is a machine-wide setting.
For more information, see Configuring the Compression Level for Files that Are Streamed into Setup.exe and ISSetup.dll.
You can modify the maximum size limit if necessary. In addition, if you do not want InstallShield to create multi-part .cab
files, you can configure it to create single .cab files.
This functionality applies to Basic MSI and InstallScript MSI projects. In addition, it is applicable only if you are building a
compressed network image release in which all of the files are embedded in the single-file .msi package or the Setup.exe
setup launcher. This functionality does not apply to custom compression, where only the files that are associated with one
or more features are compressed into .cab files.
For more information, see Configuring the Maximum Size for .cab Files.
Support for Adding an Open Dialog to a Basic MSI Installation to Let End Users Browse to a File
InstallShield includes support for launching the Open dialog from one of the dialogs in your Basic MSI installation. End
users click a browse button in one of your dialogs, and this launches the Open dialog. The Open dialog lets the end user
browse for a file. When the end user selects the file and clicks the Open button, the Open dialog closes, and the installation
writes the full path and file name in an edit field on the dialog. The installation also sets the value of the
IS_BROWSE_FILEBROWSED property to the path and file name of the file that the end user selected.
To use this functionality, you must add to your project the new Windows Installer DLL custom action called FileBrowse.
This custom action calls the FileBrowse.dll file. In addition, you must add an edit field control and the browse button
that launches the Open dialog, and set a related dialog event. For complete instructions, see Launching a File Open Dialog.
Ability to Convert Visual Studio Setup and Merge Module Projects to InstallShield Projects
InstallShield now lets you convert a Visual Studio 2008, Visual Studio 2005, Visual Studio .NET 2003, or Visual Studio .NET
setup project (.vdproj) to a Basic MSI project (.ism). In addition, InstallShield enables you to convert a Visual Studio 2008,
Visual Studio 2005, Visual Studio .NET 2003, or Visual Studio .NET merge module project (.vdproj) to an InstallShield Merge
Module project (.ism).
Converting these Visual Studio projects to InstallShield projects enables you to modify the layout of dialogs through a
visual Dialog Editor, manage features and components, and use other functionality that is available in InstallShield.
To learn more, see Converting or Importing Visual Studio Projects into InstallShield Projects.
Arabic (Saudi Arabia) and Hebrew Language Support, and Dialog Editor Support for Right-to-Left
Languages
InstallShield now includes support for Arabic (Saudi Arabia) and Hebrew languages, which are written and read from right
to left. All of the default end-user dialog strings are available in these languages.
Since these languages are read from right to left, InstallShield also includes support for mirroring Arabic and Hebrew
dialogs; that is, InstallShield uses a right-to-left layout for Arabic and Hebrew dialogs. Thus, for example, buttons that are
on the right side of dialogs in English and other left-to-right languages are moved to the left side of right-to-left-language
dialogs. In addition, InstallShield uses mirror-image versions of the dialog images that are displayed for the built-in dialog
themes.
The right-to-left layouts and reversed images are used in the Dialog Editor pane in the Dialogs view of InstallShield, and
also at run time.
The Arabic and Hebrew support is available in the InstallShield Premier Edition. The Premier edition now includes support
for 35 different languages.
The following project types include support for this feature: Basic MSI and Merge Module.
If a string identifier in the project’s InstallScript file is not defined for one of the project’s string entries, InstallShield
displays build warning -7174.
This applies to the following project types: Basic MSI with InstallScript custom actions, InstallScript, InstallScript MSI,
InstallScript Object, and Merge Module with InstallScript custom actions.
Enhancements
InstallShield includes the following enhancements.
When best practices for component creation are followed, InstallShield creates a separate component for each portable
executable (PE) file in the dynamically linked folder and sets each PE file as the key file of its component. If you later want
to create a patch that updates one of the dynamically linked PE files, it is easier to do so than it would be if you had used
the one-component-per-directory method.
Previously, any time that you added dynamic file links to a project, InstallShield automatically created one component for
all of the dynamically linked files at build time. However, if your dynamic file link included PE files, Windows Installer best
practices for component creation were not followed.
By default, InstallShield considers the following file types to be PE files: .exe, .dll, .ocx, .vxd, .chm, .hlp, .tlb, and .ax. You can
modify this list through the new File Extensions tab on the Options dialog box.
The automation interface includes support for this new best practice method. The ISWiDynamicFileLinking object includes
a new CreateBestPracticeComponents property that lets you specify whether you want to use the best practice method, or
the previously available one-component-per-directory method for a dynamic file link. When you create a new dynamic file
link using the AddDynamicFileLinking method, the best practice method is used by default.
The best practice dynamic file linking applies to Basic MSI, InstallScript MSI, and Merge Module projects.
• Determining the Appropriate Component Creation Method for Dynamically Linked Files
• ISWiDynamicFileLinking Object
• AddDynamicFileLinking Method
New prerequisites and existing prerequisites that were created before this functionality was available are not hidden by
default. You can change this behavior by selecting the new check box on the Behavior tab.
For more information, see Specifying Whether to Include the Name of a Prerequisite in the List of Setup Prerequisites to Be
Installed on the Target System.
For new prerequisites and existing prerequisites that were created before this functionality was available, the progress is
not shown by default. You can change this behavior by selecting the new check box on the Behavior tab.
Note that if you specify that you want to show the progress, only some of the available command-line parameters are
supported. To learn more, see Specifying Command-Line Parameters for an InstallShield Prerequisite.
Ability to Use Windows Installer Properties in Command-Line Statements for InstallShield Prerequisites
Basic MSI and InstallScript MSI installations now can substitute and pass the following properties on setup prerequisite
command lines: ProductLanguage, ISPREREQDIR, SETUPEXEDIR, and SETUPEXENAME. You can use these properties to identify
the launching installation ("[SETUPEXEDIR]\[SETUPEXENAME]"), to identify full paths to files that are included in the
prerequisite ("[ISPREREQDIR]myconfig.ini"), or to pass the selected language to multilingual prerequisites such as an
InstallShield setup launcher (/l[ProductLanguage]). The new feature prerequisites include command-line support for any
Windows Installer property, including the aforementioned properties.
You can specify the command lines on the Application to Run tab of the InstallShield Prerequisite Editor.
For more information, see Specifying Command-Line Parameters for an InstallShield Prerequisite.
Note that Setup.exe files cannot exceed 4 GB because Windows will not load an executable file that is larger than 4 GB.
Ability to Install IIS Web Sites Without Virtual Directories and to Associate Web Sites with Components
InstallShield now includes support for installing IIS Web sites without any virtual directories. In addition, the General tab
that InstallShield displays when you select a Web site in the Internet Information Services view now has a Component
setting; use this setting to associate the selected Web site with a component. As a result of these enhancements, a Web site
is created on a target machine if a virtual directory or a component that is associated with it is installed.
If a Web site is associated with a component, the Web site’s Delete Web Site on Uninstall check box corresponds with the
Permanent setting for that component in a Basic MSI or InstallScript MSI project, or with the Uninstall setting for that
component in an InstallScript project. That is, if you select or clear the Delete Web Site on Uninstall check box for a Web
site, InstallShield automatically updates the value of the component’s Permanent setting or Uninstall setting, as
appropriate.
Previously, InstallShield did not include support for associating Web sites with components. Therefore, if a Web site in an
installation did not have any virtual directories, the Web site would not be created at run time.
If you add a new Web site through the Internet Information Services view in InstallShield 2009, InstallShield automatically
associates that Web site with a component. If you upgrade an InstallShield 2008 or earlier project that already has an IIS
Web site, InstallShield does not automatically associate that Web site with a component.
The following project types support these IIS enhancements: Basic MSI, InstallScript, and InstallScript MSI.
Note that if a Web site is associated with a component in an InstallScript project, any virtual directories that are added to
that Web site must be associated with the same component. Therefore, if you try to change the component for a Web site
that contains one or more virtual directories, InstallShield displays a message box to inform you that it will also make the
same component change for all of that Web site’s virtual directories; InstallShield also displays this message box if you try
to change the component for any virtual directories in a Web site. In either case, the message box enables you to proceed
or cancel the component change. For Basic MSI and InstallScript MSI projects, keeping a Web site in the same component
as all of the Web site’s virtual directories is not required, but it is recommended.
• Advanced Tab
Ability to Build a Patch from the Command Line and from MSBuild
The -patch_config command-line parameter is available for command-line builds (including the Standalone Build
command-line builds) with ISCmdBld.exe. Use this parameter to build a patch from the command line.
If you use an .ini file to pass parameters to the command line, you can use the new PatchConfigName parameter in the
[Project] section of your .ini file to indicate the patch configuration that you want to build.
In addition, the InstallShield task for MSBuild now includes a PatchConfiguration parameter, which you can use to specify
the patch configuration that you want to build through MSBuild.
• ISCmdBld.exe
If you password-protect a patch or QuickPatch package, any end user who wants to install the package must enter a case-
sensitive password to launch your update.
Previously, the patch and upgrade validation was available only for Basic MSI projects and InstallScript MSI projects, and
patches that were created in the Patch Design view.
Ability to Select Multiple .cub Files for Performing Validation at Build Time
The Validation tab on the Options dialog box in InstallShield now lets you specify more than one .cub file that should be
used to validate your installation package or merge module when it is built from within InstallShield.
In addition, you can now pass more than one .cub file through the -m command-line parameter for command-line builds
(including the Standalone Build command-line builds) with ISCmdBld.exe. If you use an .ini file to pass parameters to the
command line, you can now specify more than one .cub file for the CubFile parameter in your .ini file.
The RunMsiValidator parameter of the InstallShield task for MSBuild has been enhanced to accept more than one .cub file.
• Build Menu
• ISCmdBld.exe
The InstallShield Best Practice Suite is available in the Premier edition of InstallShield for Basic MSI, InstallScript MSI, and
MSI Database projects.
Ability to Use the /v Command-Line Parameter More than Once to Pass More than One Parameter from
Setup.exe to the .msi File
If you want to pass more than one argument from Setup.exe to Msiexec.exe, you can use the /v option multiple times at
the command line, once for each argument. Previously, the /v option could be used only once, and all parameters were
passed through this instance.
The following project types include support for this enhancement: Basic MSI and InstallScript MSI.
In addition, the ISCmdBld.exe file that is used for command-line builds with InstallShield is now installed with the
Standalone Build. Previously, the Standalone Build used IsSaBld.exe, a different file, for command-line builds.
ISCmdBld.exe now supports parameters that previously only IsSaBld.exe supported:
• -o <merge module search path>—Specifies one or more comma-delimited folders that contain the merge module
(.msm) files referenced by your project.
• -t <Microsoft .NET Framework path>—Specifies the path to the Microsoft .NET Framework. The path is the location of
the .NET Framework that is installed on the build machine.
• -h—Indicates that you want to skip the upgrade validators at the end of the build.
• -g <minimum target MSI version>—Specifies the minimum version of Windows Installer that the installation
requires on the target machine.
• -j <minimum target Microsoft .NET Framework version>—Specifies the minimum version of the .NET Framework
that the installation requires on the target machine.
Also as part of this enhancement, the Standalone Automation Interface uses the same ISWiAutomation15.dll file that
InstallShield uses, but it is installed to a different location. If you have existing automation scripts that work with the
InstallShield Automation Interface, you no longer need to change the library name from IswiAutoN to SAAutoN throughout
the scripts in order to use them with the Standalone Automation Interface. Note that with this change, the ISWiProject
object includes support for several properties that were previously available for only the Standalone Automation Interface:
• DotNetFrameworkPath
• MergeModuleSearchPath
• MinimumTargetDotNetVersion
• MinimumTargetMSIVersion
• SelfRegistrationMethod
• SkipUpgradeValidators
An advantage of these compatibility improvements is that only one set of binaries, rather than two separate sets, is built for
the Standalone Build and InstallShield; if an InstallShield hotfix or service pack is released, it can be used to update the
Standalone Build and InstallShield. Previously, separate hotfixes and service packs were required.
• ISCmdBld.exe
• ISWiProject Object
Support for Browsing to Local, Remote, and Alias SQL Servers in the SQLBrowse Run-Time Dialog
The filter functionality of the SQLBrowse dialogs has been enhanced.
To show only remote servers in the SQL Server browse combo box and list box controls in Basic MSI and InstallScript MSI
installations, you can set the new Windows Installer property IS_SQLSERVER_REMOTE_ONLY. To show only server aliases in
the SQL Server browse combo box and list box controls in Basic MSI and InstallScript MSI installations, you can set the new
Windows Installer property IS_SQLSERVER_ALIAS_ONLY. Previously, the only filtering that was available was showing only
local servers; this is available if you set the IS_SQLSERVER_LOCAL_ONLY property. You can now set any combinations of
these properties to display multiple types of servers in the SQL Server browse combo box and list box controls.
• SQLRTSetBrowseOption—This function lets you specify whether the SQL Server browse combo box and list box
controls show local servers, remote servers, server aliases, or a combination of these types.
• SQLRTGetBrowseOption—This function returns the current value of the browse option for the SQL Server browse
combo box and list box controls, which can display local servers, remote servers, server aliases, or a combination of
these types.
Ability to Continue an Installation If the Minimum SQL Database Server Requirements Are Not Met
The Requirements tab that is displayed when you select a SQL connection in the SQL Scripts view has a new Allow
installation to continue when minimum requirements are not met check box.
If you select this check box and the minimum database server requirements are not met on a target system, the run time
skips the SQL connection and all of its SQL scripts, and continues with the installation.
If you clear this check box and the minimum requirements are not met, the installation does not allow the end user to
continue with the rest of the installation. This is the default behavior.
This enhancement applies to Basic MSI, InstallScript, and InstallScript MSI projects.
This enhancement applies to Basic MSI, InstallScript, and InstallScript MSI projects.
If your installation requires any of these, you can use the System Search view or the Installation Requirements page in the
Project Assistant to add these system searches to your project. When end users launch your installation, Windows Installer
checks the target system to see if the requirements are met; if they are not met, the installation displays the error message
that is defined for the system search.
The following project types now support the error custom action: Basic MSI, InstallScript MSI, Merge Module, MSI Database,
MSM Database, and Transform. Previously, only Basic MSI and InstallScript MSI projects included support.
The benefit of selecting this check box for a Basic MSI or InstallScript MSI project is that it helps create one patch that
updates both compressed and uncompressed versions of a release that contains originally unsigned files.
Previously, the check box was not available, and InstallShield never enabled you to sign the files in their original location.
The automation interface now includes support for this new digital signing functionality. The ISWiRelease object includes a
new SignFilesInPlace property that lets you specify whether you want InstallShield to sign your original source files or just
the files that are built into the release.
• ISWiRelease Object
Previously, InstallShield used random values for the primary keys that it created during static COM extraction. As a result, if
the COM data were refreshed or a patch were built, it was possible for new primary keys to be created, even if the COM data
had not changed. In the patch scenario, the COM data would be included in the patch if the primary keys changed. If a
patch updated a component with unchanged COM data, the COM data could be removed during patch uninstallation, and
this could cause issues in the earlier version of the product.
Enhancements for .NET Framework 3.5 and .NET Framework 3.0 SP1 Support
A new FOLDER_DOTNET_35 InstallScript variable is available. This variable stores the path of the .NET Framework 3.0 files.
Two new constants are available for use with the function Is:
• REGDB_KEYPATH_DOTNET_35
• REGDB_KEYPATH_DOTNET_30_SP
You can use the REGDB_KEYPATH_DOTNET_30_SP variable when querying whether SP1—or a later service pack—of the
.NET Framework 3.0 is installed. To detect whether the RTM version of the .NET Framework 3.0 is installed, use
REGDB_KEYPATH_DOTNET_30.
New GetTempFileNameIS Function that Calls the Windows API GetTempFileName to Create a Temporary File
A new InstallScript function called GetTempFileNameIS is available. This function calls the Windows API
GetTempFileName to create a temporary file and perform related actions.
See Also
What’s New in InstallShield 2009 SP1
Upgrading Projects from InstallShield 2008 or Earlier
Upgrading Projects from InstallShield 12 or Earlier
Upgrading Projects from InstallShield 11.5 or Earlier
New Features
InstallShield includes the following new features.
Some of the themes are available in both the Premier and Professional editions of InstallShield, and some are available in
only the Premier edition. For more information, see Available Themes and Corresponding Dialog Sizes.
For more information about this feature, see the Dialog Themes section of this documentation.
The new Signing tab in the Releases view is where you specify the digital signature information—including the digital
certificate files that a certification authority grated to you—that InstallShield should use to sign your files. The Signing tab
is also where you specify which files in your installation should be digitally signed. You can also use the Release Wizard to
specify all of the digital signature information.
If you specify a .pfx file for signing, InstallShield uses SignTool.exe to sign your files. If you specify an .spc file and a .pvk
file, InstallShield uses Signcode.exe to sign your files. Using a .pfx file is often the preferred method, since it is more likely
to work in many different environments (such as locked build machines). If you specify the digital signature password in
InstallShield, you will never see a password prompt if you are using a .pfx file. However, if you are using .spc and .pvk files,
a password prompt may be displayed.
Previously, InstallShield included support for signing only the .msi, .hdr, and Setup.exe files. In addition, InstallShield
allowed you to specify .spc and .pvk files for the digital signature, but not .pfx files.
This feature is available for Basic MSI, InstallScript MSI, and MSI Database projects.
• Specifying Which ICEs, ISICEs, ISVICEs and ISBPs Should Be Run During Validation
In addition, InstallShield lets you include an SSL certificate for a Web site in your installation. Including an SSL server
certificate enables users to authenticate the Web server, check the validity of the Web content, and establish a secure
connection.
• Determining If a Target System Has IIS 6 or Earlier or the IIS 6 Metabase Compatibility Feature
In addition, the object launches and completes the .NET Framework installation as the feature containing the .NET object
installs. This allows the .NET Framework to be available as early as possible, in case it is needed to install or configure files
that are subsequently installed during the installation.
Support for the UAC Shield Icon on Dialog Buttons (Basic MSI Projects)
In the Dialog Editor of Basic MSI projects, a new Show UAC Shield Icon property is available for all button controls. If you
select True for this property, the User Account Control (UAC) icon is displayed on the button when end users run the
installation on Windows Vista systems. If you are using InstallShield on a Windows Vista system, you can see the shield icon
on the button in the Dialog Editor as it will be displayed at run time. The shield icon signals to end users that elevated
privileges may be required.
For any new Basic MSI projects that you create, the Show UAC Shield Icon property is set to True for the Install button on
the ReadyToInstall dialog. If you upgrade a Basic MSI project that was created with InstallShield 12 or earlier to
InstallShield 2008, the default value for the Install button’s Show UAC Shield Icon property is False. You can override the
value for this button, or for any other buttons, as required.
Ability to Require End Users to Scroll Through the EULA in the LicenseAgreement Dialog
InstallShield includes support for disabling the Next button on the LicenseAgreement dialog until the end user reaches the
end of the End-User License Agreement (EULA) text in the scrollable EULA control through mouse or keyboard scrolling.
The end user must also select the I accept the terms in the license agreement option before the Next button is enabled;
this behavior is the same as with earlier releases of InstallShield.
The scroll requirement is not available in the LicenseAgreement dialog by default. To use this functionality, you must add
to your project the new Windows Installer DLL custom action called WatchScroll. This custom action calls the
EulaScrollWatcher.dll file. In addition, you must modify the Next button’s Control conditions and add an event to the
Memo control.
For detailed instructions, see Requiring End Users to Scroll Through the EULA in the LicenseAgreement Dialog.
In addition, some changes have been made to the DirectX 9 Object Wizard for Basic MSI and InstallScript MSI projects. The
wizard now lets you specify whether the redistributable files should be included in the Disk1 folder or streamed into the
.msi file. This change enables you to use the DirectX 9 object in compressed installations. Also, you can now use the DirectX
9 object in silent installations.
For Basic MSI and InstallScript MSI projects, the custom action that launches the DirectX installation is now sequenced in
the Execute sequence and run in deferred system context so that it can be run with elevated privileges on Windows Vista
systems.
• Targeting 64-Bit Operating Systems with Basic MSI and InstallScript MSI Installations
• Conditions Tab
Note that Windows Vista and Windows Server 2008 use the same major and minor version numbers. Therefore, if you want
to use InstallScript to distinguish between Windows Server 2008 and Windows Vista, check whether
SYSINFO.nOSProductType = VER_NT_WORKSTATION; for Windows Vista, this is TRUE; for Windows Server 2008, it is FALSE.
For more information, see SYSINFO.
To learn more about MSXML, see Run-Time Requirements for XML File Changes.
The Update Notifications view in Basic MSI and InstallScript MSI projects lets you select which version of FlexNet Connect
you want to include in your project. You can include version 6.1 or any version that is installed in any of the locations that
are specified in the Merge Module Location area on the Merge Module tab of the Options dialog box.
The Update Notifications view includes a new Vendor Database setting, which FlexNet Connect 6.1 supports.
Enhancements
In addition, you can now select Compressed or Uncompressed for the Compression setting from within the Releases view.
Previously, the only way to modify this setting was to use the Release Wizard. Note that if you want to specify a custom
compression setting (one .cab file per feature or one .cab file per component), you must still use the Release Wizard. The
Compression setting is available in Basic MSI, InstallScript MSI, and Merge Module.
The settings in the Distribution view have been moved to the new Postbuild tab in the Releases view for Basic MSI,
InstallScript MSI, and Merge Module projects. The Postbuild tab lets you configure settings for distributing releases to a
folder or FTP site automatically at build time.
A new Distribute command is available when you right-click a release in the Releases view for Basic MSI, InstallScript MSI,
and Merge Module projects. When you select this command, InstallShield copies all of the relevant files for your release to
the locations that are specified on the Postbuild tab. Note that for InstallScript and InstallScript Object projects,
InstallShield automatically copies the release to the locations that you specify on the Postbuild tab every time that you
build the release.
• To sequence a new custom action, drag it from the Custom Actions explorer to the appropriate location in a sequence
under the Sequences explorer.
• To move a dialog, standard action, or custom action to a different point in a sequence (or from one sequence to
another), drag it from the old location to the new location.
• To copy a custom action from one sequence to another, press and hold CTRL while dragging the custom action from
one sequence to another sequence.
The Custom Actions and Sequences view is available in Basic MSI, InstallScript MSI, MSI Database, and Transform projects.
• Creating Custom Actions in the Custom Actions and Sequences View (or the Custom Actions View)
• Reordering a Sequence
Usability Enhancements for the Files and Folders view, the Registry View, and the Redistributables View
Several enhancements are available for the Files and Folders view:
• You can right-click a file in the Destination computer’s files pane and then click the new Open Containing Folder
command. Doing so opens a Windows Explorer window and displays the folder that contains the file that you right-
clicked.
• A new Add command is available when you right-click the Destination computer’s files pane. Use this command to
display an Open dialog box that lets you browse to the file that you want to add to your project.
• The upper-right corner of this view has a new link (either Show Source Panes or Hide Source Panes). Use this new link
to show or hide the two top panes—the Source computer’s folders pane and the Source computer’s files pane—in
this view. You can hide the two panes, open a Windows Explorer window, and drag and drop files from the Windows
Explorer window to the two remaining panes in InstallShield.
The Registry view also has a new link (either Show Source Panes or Hide Source Panes) in the upper-right corner. Use this
new link to show or hide the two top panes—the Source computer’s folders pane and the Source computer’s files
pane—in this view.
Two enhancements have also been made to the Redistributables view for Basic MSI and InstallScript MSI projects:
• The right pane in this view shows details about the merge module, object, or setup prerequisite that is selected in the
upper-left pane. You can now hide or show the details pane by clicking the Show Details or Hide Details link in the
upper-right corner of this view.
• The Details pane that is displayed for setup prerequisites now shows complete information about the selected setup
prerequisite. This includes conditions, command-line parameters, and other information that is configured for the
prerequisite.
The CreateProject method for the ISWiProject object now enables you to create merge module projects. Previously, this
method supported only Basic MSI, InstallScript, InstallScript MSI, and InstallScript Object projects.
The automation interface includes a new object and a new collection for dynamic file links. In addition, the
ISWiComponent object includes two new methods and a property that let you add (AddDynamicFileLinking) and remove
(RemoveDynamicFileLinking) a component’s dynamic file link, as well as get the collection of dynamic file links
(ISWiDynamicFileLinkings).
• ISWiDynamicFileLinking Object
• ISWiDynamicFileLinkings Collection
• ISWiComponent Object
• AddDynamicFileLinking Method
• RemoveDynamicFileLinking Method
The automation interface includes a new object and a new collection for configuring path variables in a project. In
addition, the ISWiProject object includes two new methods and a property that let you add (AddPathVariable) and remove
(DeletePathVariable) a path variable from a project, as well as get the collection of path variables (ISWiPathVariables).
• ISWiPathVariable Object
• ISWiPathVariables Collection
• ISWiProject Object
• AddPathVariable Method
• DeletePathVariable Method
The automation interface includes new objects and collections for configuring languages and string entries in a project.
The ISWiLanguage object includes two methods and a property that let you add (AddStringEntry) and remove
(DeleteStringEntry) a string entry from a project, as well as get the collection of string entries (ISWiStringEntries). In
addition, the ISWiProject object includes a new property (ISWiLanguages) that gets the collection of languages included in
the current project.
• ISWiLanguage Object
• ISWiLanguages Collection
• ISWiStringEntry Object
• ISWiStringEntries Collection
• AddStringEntry Method
• DeleteStringEntry Method
• ISWiProject Object
The automation interface includes a new object and a new collection for environment variables. In addition, the
ISWiComponent object includes two new methods and a property that let you add (AddEnvironmentVar) and remove
(RemoveEnvironmentVar) a component’s environment variables, as well as get the collection of environment variables
(ISWiEnvironmentVars).
• ISWiEnvironmentVar Object
• ISWiEnvironmentVars Collection
• ISWiComponent Object
• AddEnvironmentVar Method
• RemoveEnvironmentVar Method
ISWiProject Object Properties for Setting the Company Name, Company URL, and Company Phone Number
The ISWiProject object includes several new properties that let you specify values for General Information view settings:
• CompanyName
• CompanyURL
• CompanyPhone
The ISWiRelease object includes several new properties that enable you to configure settings for digitally signing files for
releases at build time. The new properties are:
• CertificatePassword
• SignFiles
• SignFilesExclude
• SignFilesInclude
• SignSignedFiles
ISWiRelease Object Properties for Specifying Whether to Keep Unused Directories in the Directory Table
The ISWiRelease object includes a new KeepUnusedDirectories property that lets you specify whether you want to want
InstallShield to remove unused directories from the Directory table of the .msi file when you build this release.
ISWiRelease Object Property for Configuring Whether to Postpone Any Reboot for Installing or Updating the .NET
Framework
The ISWiRelease object includes a new DotNetDelayReboot property that lets you specify whether you want to postpone
any reboot associated with installing or updating the .NET Framework on the target system until after your installation has
completed.
ISWiRelease Object Property for Specifying Whether to Display a Message Box Asking the End User if They Want to
Install the .NET Framework
The ISWiRelease object includes a new DisplayDotNetOptionDialog property. Use this property to specify if a message box
should be displayed at run time to let end users indicate whether the .NET Framework should be installed.
The ISWiRelease object now includes several new properties that enable you to configure settings for distributing releases
to a folder or FTP site automatically at build time. The new properties are:
• DistributeLoc
• DistributeToURLLoc
• DistributeToURLUserName
• DistributeToURLPassword
• DistributeAfterBuild
The ISWiSequence collection has a new RemoveSequenceRecord method that enables you to delete an item from a
sequence. To learn more, see RemoveSequenceRecord Method.
Basic MSI Projects Now Support Adding and Removing Support Files
The automation interface now includes support for the ISWiSetupFile and ISWiAdvancedFile objects in Basic MSI projects.
These objects include methods (AddSetupFile, DeleteSetupFile, AddAdvancedFile, and DeleteAdvancedFile) that are now
available in Basic MSI projects. Previously, these objects and methods were available in only InstallScript, InstallScript MSI,
and InstallScript Object projects.
• ISWiAdvancedFile Object
• ISWiAdvancedFiles Collection
• AddAdvancedFile Method
• DeleteAdvancedFile Method
• ISWiSetupFile Object
• ISWiSetupFiles Collection
• AddSetupFile Method
• DeleteSetupFile Method
• ISWiProject Object
• Now you can test just the XML file changes that are configured for your project through the XML File Changes view
without having to build and run your entire installation.
• The XML File Changes view now supports namespaces in XML files.
To learn more about XML file changes, see the Modifying XML Files section of the InstallShield Help Library.
Previously, InstallShield always included a Highest Available manifest for InstallScript projects, and the Required Execution
Level setting was available in only Basic MSI and InstallScript MSI projects.
For more information, see Specifying the Required Execution Level for Your Setup Launcher on Windows Vista and Later
Platforms.
• To change the icon that is used for a shortcut, you can right-click the shortcut and then click the new Change
Shortcut icon command. InstallShield opens the Change Icon dialog box, which enables you to select the icon file and
associated icon index that should be used when the shortcut is created on target systems at run time.
• Shortcuts that are listed in the Shortcuts explorer now show the icon image that will be used on the target system.
Previously, the Shortcuts explorer used a different image for all types of shortcuts, even if an icon was specified for the
shortcut.
• Shortcuts View
Windows Vista and Internet Explorer 7 Support for One-Click Install Installations
One-Click Install installations in InstallScript projects can now be used on Windows Vista systems and with Internet
Explorer 7. The One-Click Install setup player is now an external .ocx file, instead of being embedded in the Setup.exe file.
The setup player downloads and then launches the Setup.exe file with the appropriate command line. This enables end
users who are using Windows Vista with limited privileges to run the installation; if elevated privileges are required because
of the required execution level specified in the installation’s manifest, the appropriate User Account Control (UAC) prompt
is displayed when the Setup.exe file is launched.
To support this new behavior, a new Generate One-Click Install setting is available on the Internet tab in the Releases view
and on the Internet Options panel in the Release Wizard. If you select Yes for this setting, InstallShield includes an .ocx file
for the installation.
To learn more about One-Click Install installations, see the Typical Web Installation vs. One-Click Install section of the
documentation. In addition, see the following:
InstallShield now automatically adds to the SecureCustomProperties property properties that may need to be passed
from the user interface sequence to the execute sequence. To learn more, see Specifying that a Public Property Should Be
a Restricted Public Property.
This support applies to Basic MSI, InstallScript MSI, and Merge Module projects.
Automatic Downgrade Prevention Entries in Basic MSI and InstallScript MSI Projects
To prevent end users from being able to install the current version of your product over a future major version of the same
product, the following conditions should be met: The Upgrades view should contain a major upgrade item, the major
upgrade item should be properly configured to prevent the current version of your product from being installed over a
future version, and your project should include a properly configured and scheduled type 19 custom action.
When you create a new Basic MSI or InstallScript MSI project, InstallShield automatically adds support for preventing the
current installation from overwriting a future major version. To learn more, see the following:
• Preventing the Current Installation from Overwriting a Future Major Version of the Same Product
• ISICE19
If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2020, InstallShield does not
automatically change the value of the ALLUSERS property or add this property if it was not defined in the earlier project.
Also new with InstallShield 2008, by default, the CustomerInformation dialog in all new Basic MSI projects does not display
the radio button group that enables end users to specify whether they want to install the product for all users or for only
the current user. This is the recommended implementation for this dialog.
If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2020, InstallShield does not
automatically change the CustomerInformation dialog.
• ALLUSERS
Ability to Change the Product Version from the Command Line or Through an MSBuild Task Parameter
The -y command-line parameter is available for command-line builds with ISCmdBld.exe and IsSaBld.exe. Use this
parameter to specify a product version from the command line.
In addition, the InstallShield task for MSBuild now includes a ProductVersion parameter, which you can use to specify the
product version through MSBuild. This parameter is exposed as the property InstallShieldProductVersion when the default
targets file is used.
Using the -y command-line parameter or the InstallShield task ProductVersion parameter is especially helpful if you want
to increment the build version (the third field) of the product version.
• ISCmdBld.exe
Ability to Override Windows Installer Property Values from the Command Line or Through an MSBuild
Task Parameter
The -z command-line parameter is available for command-line builds with ISCmdBld.exe and IsSaBld.exe. Use this
parameter to override the value of a Windows Installer property or create the property if it does not exist.
In addition, the InstallShield task for MSBuild now includes a PropertyOverrides parameter, which you can use to override
the value of a Windows Installer property or create the property if it does not exist. This property is exposed as the
InstallShieldPropertyOverrides ItemGroup passthrough to the PropertyOverrides property on the InstallShield task.
• ISCmdBld.exe
Windows Installer Properties Used for IIS Data Are Stored in the Registry by Default
Installations that install IIS Web sites and use Windows Installer properties to dynamically set IIS data at run time now write
the property and its value to the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield Uninstall
Information\{ProductCode}
This change was made to make the value available during uninstallation and repair. Therefore, if your Web site is installed
to an end user–specified site number, the Web site and its virtual directories can be successfully uninstalled from that site
number. If you do not want the IIS data to be stored in the registry, set the IS_IIS_DO_NOT_USE_REG property in your
project.
New Setting for Specifying Whether an IIS Web Server Should Allow the CMD Command to Be Used for SSI
#exec Directives
You can configure an IIS Web server to prevent the CMD command for the #exec directive from being used to execute shell
commands, or you can configure it to allow the CMD command to be used to execute this type of command. The
SSIEnableCmdDirective registry value for the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters registry key is what determines whether
the CMD command is permitted.
The Internet Information Services view in InstallShield includes a new SSIEnableCmdDirective registry value setting. This
setting lets you specify how your installation should configure the SSIEnableCmdDirective registry value on target systems.
This setting also lets you specify that the SSIEnableCmdDirective registry value should not be changed at installation run
time; this is the default behavior.
For more information, see Specifying Whether a Web Server Should Allow the CMD Command to Be Used for SSI #exec
Directives.
For more information, see Specifying the IIS Host Header Name for a Web Site.
Ability to Install an IIS Web Site and Its Virtual Directories to the Next Available New Site Number
InstallShield provides support for installing an IIS Web site and its virtual directories to the next available new site number.
The implementation is slightly different, depending on which project type you are using. For more information, see
Configuring the TCP Port and Site Numbers.
Ability to Specify Whether New SQL Connections Should Share the Same Windows Installer Properties
A new SQL Scripts tab on the Options dialog box lets you specify how InstallShield should create new database
connections by default—either by using the same Windows Installer properties that were used by default for the first
connection in your project, or by using a unique set of new Windows Installer properties.
This applies to the following project types: Basic MSI and InstallScript MSI.
• Specifying Whether New SQL Connections Should Share the Same Windows Installer Properties
If you upgrade a Basic MSI project that includes SQL support from InstallShield 12 or earlier to InstallShield 2020, you need
to manually import the SQLLogin.isd and SQLBrowse.isd dialogs into your project to use the new version of the SQLLogin
dialog. The .isd files are installed in the following location: InstallShield Program Files Folder\Support. To use this
updated SQLLogin dialog in InstallScript and InstallScript MSI projects, replace the SQLServerSelectLogin function call in
your InstallScript code with a call to the new SQLServerSelectLogin2 function.
New Windows Installer Property for Specifying SQL Connections That Should Not Be Installed or
Uninstalled
InstallShield includes support for a new Windows Installer property called IS_SQLSERVER_CXNS_ABSENT_FROM_INSTALL. Use
this property to specify one or more SQL connections that should be skipped during installation or uninstallation. To
specify more than one SQL connection, separate each with a semicolon (;). To skip all of the SQL connections, set the value
of this property to ALL. Using this property is helpful if you cannot uninstall a product because of a SQL scripting error.
For details about SQL-related properties, see Overriding the Default SQL Run-Time Behavior.
This setting is available for Basic MSI, InstallScript MSI, and Merge Module projects.
Ability to Specify COM+ Component File Destinations from Within the Component Services View
The Component Services view has two new Destination fields on the Installation tab: one for a server type of installation,
and one for a proxy type of installation. Use these fields to specify the target destination of the selected COM+ component
files. Previously, the only way to specify the destination of the components associated with a COM+ application was in the
Components view or the Setup Design view.
New Windows Installer Property for Specifying COM+ Applications to Be Installed After the
InstallFinalize Action
InstallShield includes support for a new Windows Installer property called IS_COMPLUS_INSTALL_AT_FINALIZE. Use this
property to specify one or more COM+ applications that should be installed by the ISComponentServiceFinalize action,
which is called after the InstallFinalize action. To specify more than one COM+ application, separate each with a semicolon
(;). To specify that all COM+ applications should be installed by the ISComponentServiceFinalize action, set the value of this
property to ALL.
Using this property is helpful if you want to install a COM+ application that contains .NET assemblies to be installed to the
GAC because Windows Installer does not commit the changes made in the in-script session to the GAC until the
InstallFinalize action.
Additional Predefined System Searches for Basic MSI and InstallScript MSI Projects
InstallShield has several new predefined system searches:
• Adobe Reader 7
• Adobe Reader 6
If your installation requires any of these products, 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.
New and Enhanced Setup.exe and Update.exe Command-Line Parameters (InstallScript Projects)
Two new command-line parameters are available for Setup.exe and Update.exe:
• /installfromweb
• /media_path
In addition, the /L parameter now supports both hex and decimal language values.
Downloader Web Release Type Supports More Location Options for .cab Files
The Downloader type of Web release now lets you specify whether InstallShield should create external .cab files that are
downloaded at installation time as needed. Previously, .cab files were always streamed into the .msi package for the
Downloader Web release type.
The new external .cab file options are available on the Downloader Options panel of the Release Wizard. This panel is
displayed in the Release Wizard if the media type is Web and the Web type is Downloader. The Downloader Options panel
has a new Create external .cab files check box. If you clear this check box, the behavior is the same as it was previously: the
.cab files are streamed into the .msi package. If you select this check box, you can specify how .cab files should be created:
one .cab file per feature, one .cab file per component, or multiple .cab files based on a particular size that you specify.
Downloader and Install from the Web Types of Web Releases Embed All Transforms
The Downloader type of Web release and the Install from the Web type of Web release now always embed all .mst and .ini
files in the Setup.exe file.
In addition, the Allow Patch to Be Uninstalled (Requires Windows Installer 3.0) check box is now available on the
Common tab. This setting was previously available on the Uninstall tab.
New LaunchApplication and WaitForApplication Functions to Supersede LaunchAppAndWait for Launching Applications
with Elevated Privileges
The LaunchApplication function uses either the Windows API function CreateProcess or the Windows API function
ShellExecuteEx to launch the specified application. After the application is launched, the installation can optionally call
the new WaitForApplication function to wait for the application to terminate.
The WaitForApplication function waits for a running application, and optionally all child applications that are launched by
the running application, to terminate before returning.
The new LaunchApplicationInit function is available. This function, which was added to match the naming convention of
the LaunchApplication function, has the same behavior as the LaunchAppAndWaitInitStartupInfo function.
• LaunchApplication
• WaitForApplication
• LaunchAppAndWait
• LaunchApplicationInit
• LAAW_OPTION_CHANGEDIRECTORY
• LAAW_OPTION_FIXUP_PROGRAM
• LAAW_OPTION_USE_SHELLEXECUTE
• LAAW_OPTION_WAIT_INCL_CHILD
In addition, the LAAW_OPTION_NO_CHANGEDIRECTORY is now obsolete. Passing this parameter has no effect.
• LAAW_SHELLEXECUTEINFO
• LAAW_SHELLEXECUTEVERB
New SdRMFilesInUse Dialog and OnRMFilesInUse Event Handler for Minimizing Reboots Through the Restart Manager
Infrastructure in InstallScript MSI Projects
A new SdRMFilesInUse function is available. This function displays a dialog that includes a list box containing a list of the
applications that are open and are locking files. The dialog also includes two radio buttons that allow end users to specify
whether the installation should attempt to use the Restart Manager to shut down the applications that are locking files or
overwrite the locked files (which most likely results in the need for a reboot to complete the installation).
For InstallScript MSI projects, the new OnRMFilesInUse event handler displays the new SdRMFilesInUse dialog. This event
handler is called when the Restart Manager is enabled and Windows Installer 4.0 sends an
INSTALLMESSAGE_RMFILESINUSE message to the installation.
• SdRMFilesInUse
• OnRMFilesInUse
The Compile/Link tab on the Settings dialog box, which is available from the Build menu in InstallShield, now has an
Include Paths box. Use this Include Paths box to specify which directories InstallShield should search for source files that
have been included in the main installation’s InstallScript code through #include statements. It corresponds with the -i
option for Compile.exe, the command-line compiler.
A new FOLDER_DOTNET_30 InstallScript variable is available. This variable stores the path of the .NET Framework 3.0. The
corresponding text substitution for this variable is <FOLDER_DOTNET_30>.
The .NET Framework 3.0 writes the value InstallSuccess with value data of 1 to the registry to indicate that it is installed. To
check for this InstallSuccess value, you can now use the Is function and pass the DOTNETFRAMEWORKINSTALLED
constant. You can still pass this constant through the Is function to check for the value of Install, which is used by earlier
versions of the .NET Framework. For more information, see Is.
Two new constants are available for use with the Is function:
• REGDB_KEYPATH_DOTNET_30
• REGDB_VALUENAME_INSTALLSUCCESS
New Is Constant for Checking for the Presence of a Minimum Service Pack Number of the .NET Framework
Use the new DOTNETSERVICEPACKINSTALLED constant with the Is function to determine whether a particular service
pack—or a later version of the service pack—of the .NET Framework is installed. For more information, see Is.
Several InstallScript functions for SQL support have been added or updated.
The following InstallScript functions are now available for InstallScript and InstallScript MSI projects:
• SQLRTInitialize2—Loads the SQLRT.dll file for InstallScript projects and the ISSQLSRV.dll file for InstallScript MSI
projects, and it uses the settings file to initialize the .dll file. This function supersedes the SQLRTInitialize function.
• SQLServerSelectLogin2—Creates a login dialog that lets the targeted end user specify which SQL Server should be
used for the current connection, as well as which login credential should be used. This dialog also optionally shows
the connection name that is associated with the connection information. In addition, it optionally allows the end user
to specify which database catalog should be used for the current connection. This function supersedes the
SQLServerSelectLogin function.
• SQLDatabaseBrowse—Creates a dialog that lets the end user display a list of all database catalogs available on the
specified database server.
• SQLBrowse2—Creates a dialog that lets an end user display a list of all database servers that are available on the
network for the database technologies specified for a connection. This function supersedes the SQLBrowse function.
• SQLRTPutConnectionInfo2—Sets the connection information (the default server, default database catalog, default
user name, and default password). This function supersedes the SQLRTPutConnectionInfo function.
The following InstallScript functions are now available for InstallScript projects:
• SQLRTGetLastError2—Returns detailed information about the last error encountered by the SQL run time and loads
the proper SQL error message.This function supersedes the SQLRTGetLastError function.
• SQLRTGetErrorMessage—Returns the descriptive message of the last error encountered by the SQL run time when a
connection is being opened.
• SQLRTGetScriptErrorMessage—Returns the descriptive message of the last error encountered by the SQL run time
when a SQL script is executing.
The following InstallScript function is now available for InstallScript MSI projects:
The following InstallScript functions, which were previously available only for InstallScript projects, are now also available
for InstallScript MSI projects:
• SQLRTGetConnections
• SQLRTGetConnectionInfo
• SQLRTPutConnectionInfo
• SQLRTGetConnectionAuthentication
• SQLRTPutConnectionAuthentication
InstallShield still supports the functions that are superseded by new versions of the functions. However, if you upgrade a
project that was created in InstallShield 12 or earlier to InstallShield 2020, InstallShield does not automatically update the
existing InstallScript code to use the new functions.
• Using the SQL Run-Time Functions in InstallScript and InstallScript MSI Projects
• SQL Functions
Use the new USER_INADMINGROUP constant with the Is function to determine whether a user is in the Administrators
group, regardless of whether that user is running the installation with a standard access token. For more information, see
Is.
Note that passing the USER_ADMINISTRATOR constant through the Is function now returns FALSE if the user is in the
Administrators group but the group has the SE_GROUP_USE_FOR_DENY_ONLY security identifier (SID) attribute set (that
is, the user is running with a standard access token).
New Functions that Enable a .NET Library Loaded Through InstallScript to Be Unloaded Before the Installation
Completes
• The DotNetCoCreateObject function calls functions in .NET assemblies without the assembly being registered for
COM interoperability. This function lets you specify the .NET application domain in which the .NET assemblies should
be loaded and run.
The DotNetCoCreateObject function is similar to the CoCreateObjectDotNet function. The only difference is that with
DotNetCoCreateObject, you can specify the .NET application domain that should be loaded; the assembly is then run
in this domain.
For CoCreateObjectDotNet, the .NET assembly is loaded into the default application domain after the installation
completes; thus, the .NET assembly file is locked until the installation has finished.
• The DotNetUnloadAppDomain function unloads the specified .NET application domain and releases any assemblies
that are currently loaded into the specified application domain.
A new InstallScript function called RegDBDeleteItem is now available. The RegDBDeleteItem function deletes values
under the per application paths key or the application uninstallation key, depending on the value of nItem. For more
information, see RegDBDeleteItem.
The LWTF_OPTION_APPEND_TO_FILE constant has been added to the InstallScript language. You can pass this constant as
the nOptions parameter for the ListWriteToFileEx function to append a list to an existing file.
To maintain backwards compatibility, the aforementioned two LWFT_* constants are still available, and they are defined
the same way as the corresponding new LWTF_* constants.
• ListWriteToFileEx
• LWTF_OPTION_APPEND_TO_FILE
• LWTF_OPTION_WRITE_AS_ANSI
• LWTF_OPTION_WRITE_AS_UNICODE
An InstallScript text-substitution association can now be embedded in another text-substitution association; for example,
"<MYTEXTSUB1>" can be associated with "My Text Sub 1 Value" and "<MYTEXTSUB2>" with "Text Sub <MYTEXTSUB1>
Embedded". Previously, if a local text-substitution association was embedded in a global text-substitution association, the
local text substitution was not performed.
See Also
Upgrading Projects from InstallShield 12 or Earlier
Upgrading Projects from InstallShield 11.5 or Earlier
InstallShield 12 supports a beta version of Microsoft Windows Vista. InstallShield 12 SP1 includes changes that offer
support for the RTM version of Microsoft Windows Vista.
To learn more about setup prerequisites, see Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI
and InstallScript MSI Projects.
The Advertise If Prerequisites Are Elevated setting is one of several settings in InstallShield that affect whether an
installation triggers UAC consent or credential prompts for elevated privileges. Understanding these different settings will
help you create the appropriate UAC experience for your installation when end users run it on Windows Vista systems. It
will also enable you to try to minimize the number of UAC prompts that are displayed during your installation. To learn
about all of these settings, see Minimizing the Number of User Account Control Prompts During Installation.
When you validate your package, InstallShield lists any validation messages on the Tasks tab of the Output window. Now
you can double-click a validation message on the Tasks tab to jump to the area of the Direct Editor that corresponds to the
validation message. This functionality is available for ISICEs, as well as for standard ICEs. Previously, it was available only
for standard ICEs.
• ISICEs
Additional Changes
For a list of issues that are resolved in InstallShield 12 SP1, see the release notes. The release notes are available from the
Help menu in InstallShield.
New Features
InstallShield includes the following new features.
In addition, InstallShield now lets you customize the list of internal consistency evaluators (ICEs) that should be used for
installation package validation and merge module validation. This is helpful if you do not want to pursue logo certification
but you still want to ensure that your installation or merge module meets specific best practices that are verified during
validation. To configure validation settings: on the Tools menu, click Options and select the Validation tab.
• Specifying Which ICEs, ISICEs, ISVICEs and ISBPs Should Be Run During Validation
• ISICEs
• Specifying the Required Execution Level for Your Setup Launcher on Windows Vista and Later Platforms
To support this quality guideline, an MsiRMFilesInUse dialog is available in all Basic MSI projects. The installation displays
this dialog if one or more files that needs to be updated are currently in use during the installation. To learn more, see
Minimizing Reboots on Windows Vista and Later Systems.
In addition, the Build Installation page in the Project Assistant now offers the ability to specify digital signature information
for your installation.
• Guidelines for Creating Custom Actions that Meet Requirements of the Windows Logo Program
This documentation now describes each of the built-in InstallShield custom actions that are added automatically to
InstallShield projects to support different functionality. See InstallShield Custom Action Reference.
• The user interface has been improved; it now has menus that list easy-to-access commands.
• The new Behavior tab lets you specify whether end users may skip the prerequisite installation. You can also specify
how the prerequisite installation should proceed if it appears that the target machine does or does not need to be
restarted.
• Now you can create prerequisite installation conditions for DWORD registry comparisons. You can also create
conditions for 64-bit machines.
• Behavior Tab
• Planning for Issues that Could Occur with an InstallShield Prerequisite Installation
Redistributing setup prerequisites is now more flexible than ever. You can specify different methods for supplying each
individual setup prerequisite in your installation. This enables you to store some of the setup prerequisite files on the
source media; compress some of the setup prerequisite files into Setup.exe, to be extracted at run time; and download
some of the setup prerequisite files. In addition, you can now assign release flags to setup prerequisites. Then you can
include and exclude any combinations of setup prerequisites when you build different releases.
• Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
For more information, see Specifying Whether Windows Installer Installations Should Be Logged.
• Display Resource ID
• Description Resource ID
These new settings correspond with the four new columns in the Shortcut table for Windows Installer 4.0. To learn more,
see Shortcuts View.
InstallScript Rearchitecture Enhancements for InstallScript MSI Projects and Basic MSI Projects with
InstallScript Custom Actions
The InstallScript MSI architecture has had a number of issues with security (COM/DCOM) and other areas that can cause
some installations to fail for various reasons. The architecture has been improved dramatically for InstallShield 12 to
resolve these issues and to make InstallScript MSI a more reliable project type. The improvements also help increase the
reliability of Basic MSI projects that include InstallScript custom actions.
• Run-Time Behavior for Basic MSI Installations with InstallScript Custom Actions
Registry and File Filtering Enhancements for COM Extraction and Dependency Scanners
To prevent InstallShield from extracting undesired COM data from a COM server, you can edit a new Filters.xml file that is
installed with InstallShield. Editing this Filters.xml file enables you to customize the list of registry keys that will be
excluded from COM extraction.
The Filters.xml file also now lists files that the Static, Dynamic, and Visual Basic dependency scanners will exclude or
include. Previously, two different files—Userscan.ini and Iswiscan.ini—were used to list excluded and included files.
• UNINST
• UNINSTALL_STRING
• DISK1SETUPEXENAME
• SELECTED_LANGUAGE
• INSTALLSCRIPTMSI
• BASICMSI
A new LANGUAGE_SUPPORTED predefined constant is available for use with the Is function. To learn more, see Is.
A new ISOSL_WINVISTA predefined constant is available for use with the FeatureFilterOS function and the SYSINFO
structure variable. For more information, see FeatureFilterOS function and the SYSINFO.
The DoInstall function is now similar to the LaunchAppAndWait function. For more details, see DoInstall.
Upgrade Details
For InstallShield 12, a number of improvements were made to the InstallScript MSI architecture to resolve issues with
security (COM/DCOM) and other areas that can cause some installations to fail for various reasons. The architecture was
improved for InstallShield 12 to resolve these issues and to make InstallScript MSI a more reliable project type. The
improvements also help increase the reliability of InstallScript projects, as well as Basic MSI projects that include
InstallScript custom actions.
In addition, the merge module project type has been enhanced: it now has the same InstallScript view that is available in
Basic MSI projects. This enhanced version of the merge module project type replaces the InstallScript MSI object project
type, which is no longer available in InstallShield.
You can use InstallShield to rapidly build, test, and deploy installations that target Windows-based systems.
Operating System
Project • For all project types except for Suites (Advanced UI, and Suite/Advanced UI project types), Windows XP SP3 and
Windows Server 2003 SP2 are the minimum versions of Windows that are required for target systems that run the installations
that are created in InstallShield. For Suites, Windows Vista and Windows Server 2008 are the minimum versions of Windows
that are required for target systems.
Target systems must meet the following minimum operating system requirement:
• Windows XP SP3
• Windows Vista
• Windows 7
• Windows 8
• Windows 8.1
• Windows 10
Windows Installer 4.5 Windows XP SP2 or later, Windows Server 2003 SP1 or later
Windows Installer 3.1 Windows 2000 SP3 or later, Windows Server 2003 or later
Windows Installer 3.0 Windows 2000 SP3 or later, Windows Server 2003 or later
(Note that InstallShield does not include support for Windows 95, Windows 98,
Windows NT 4, or Windows Me.)
For more information about Windows Installer redistributables, see Adding Windows Installer Redistributables to Projects.
See Also
Settings for Platforms and Platform Suites
Microsoft designed 64-bit versions of Windows to allow existing 32-bit applications to continue to work seamlessly. They
also designed 64-bit versions of Windows in such a way to allow a recompiled version of the same code to work seamlessly
as a 64-bit application. To provide this support, 64-bit versions of Windows isolate the 32-bit and 64-bit from each other in
two main ways: their files are stored in separate locations (Program Files vs. Program Files (x86); System32 vs. SysWow64),
and their registry keys are separated (HKLM\Software vs. HKLM\Software\Wow6432Node).
In some cases, such as installation, what is normally a beneficial separation becomes a challenge. Typically installations
are 32-bit applications themselves (in order to run on 32-bit machines), and accessing 64-bit locations to install a 64-bit
application is more complex than a standard file copy or registry write. Each project type that is available in InstallShield
handles this complexity in different ways.
Windows Installer–based installations disallow access to 64-bit locations except when the installation targets only 64-bit
systems; however, they support running 64-bit DLL code whenever running on a 64-bit system. Note that some target
systems—such as Windows Server Core systems—may not have 32-bit Windows-on-Windows (WOW64) support.
InstallShield lets you create pure 64-bit installations that work on those systems. For more information, see Targeting 64-
Bit Operating Systems with Basic MSI and InstallScript MSI Installations.
InstallScript installations are always 32 bit so they can run only 32-bit DLL code (or launch 32-bit or 64-bit .exe files).
However, all InstallScript installations support accessing 64-bit locations through the 64-bit component setting, as well as
through other methods. For additional details, see Targeting 64-Bit Operating Systems with InstallScript Installations.
Suite/Advanced UI and Advanced UI installations enable you to reference either 32-bit or 64-bit locations, and they can
launch 32-bit or 64-bit installations, depending on the target system. However, all extension DLL code in a Suite/Advanced
UI or Advanced UI project must be 32 bit. To learn more, see Targeting 64-Bit Operating Systems with Suite/Advanced UI
and Advanced UI Installations.
Targeting 64-Bit Operating Systems with Basic MSI and InstallScript MSI
Installations
InstallShield 2020
• Basic MSI
• InstallScript MSI
Note that if you create an InstallScript MSI project and change the Template Summary property from Intel to x64, InstallShield
creates a 64-bit MSI installation combined with a 32-bit InstallScript MSI installation at build time.
Also note that InstallScript MSI projects do not have support for architecture validation.
If you are writing applications for 64-bit Windows-based systems, you will need a way to install your 64-bit files and other
data. Although 32-bit Windows Installer–based installations can run on most 64-bit machines, they cannot install to 64-bit
locations. The Windows Installer service provides support for 64-bit installations. These installations can be designed and
built on 32-bit machines, but they can run only on 64-bit machines. Through the use of release flags, you can build two
installations (one 32 bit and one 64 bit) from a single project.
If your installation targets 64-bit systems, configure the Template Summary property with the appropriate 64-bit value (x64
or Intel64). This allows end users to install your product in 64-bit locations on 64-bit systems; it also prevents end users
from installing your product on 32-bit systems.
You can use the Template Summary setting in the General Information view to configure the Template Summary property.
You can also set the Template Summary setting for a product configuration in the Releases view. Any value entered in the
Releases view overrides the value set in the General Information view.
For more information about the 64-Bit Component setting, as well as additional component settings, see Component
Settings.
Note that if you use InstallShield on a 32-bit system, 64-bit COM extraction is not available.
To learn about extracting COM data, see Extracting COM Information from a COM Server.
InstallShield also supports 64-bit self-registration of dynamically linked COM servers. To enable this, select the Self-
Register all files check box on the Dynamic File Link Settings dialog box when you add the files dynamically to a 64-bit
component. For more information, see Adding Dynamic File Links to Components.
For example, if end users may run your installation on 64-bit Windows Server Core systems that do not have 32-bit
Windows-on-Windows (WOW64) support, architecture validation can help you identify any 32-bit product files or 32-bit
custom action files in your installation; 32-bit binaries cannot be loaded on 64-bit target systems without WOW64 support.
Architecture validation also enables you to generate pure 32-bit .msi packages that contain only 32-bit versions of the
built-in InstallShield custom action DLLs, or pure 64-bit .msi packages that contain only 64-bit versions of the built-in
InstallShield custom action DLLs.
To specify what type of architecture validation you want to use at build time and identify whether you want to build a pure
32-bit or 64-bit package, use the Architecture Validation setting for a product configuration in the Releases view.
For more details, see Selecting the Appropriate Type of Architecture Validation for Builds.
Tips for Building Two Installations—One 32 Bit and One 64 Bit—from a Single Project
If you want to be able to build two installations (one 32 bit and one 64 bit) from a single project, consider using release
flags. You can assign release flags to features, InstallShield prerequisites, and chained .msi packages, as necessary, to
differentiate the 32-bit items from the 64-bit items. Then you can configure each release or product configuration in the
Releases view to include or exclude certain items that have a particular release flag at build time. You can also
conditionally launch certain custom actions based on release flags, so that 32-bit custom actions are launched during a 32-
bit installation and 64-bit custom actions are launched during a 64-bit installation.
• Release Flags
InstallShield lets you override the values of your project’s path variables for each release in your project. This functionality
enables you to essentially replace certain files and folders in your project with others at build time, depending on the
particular release that you are building.
For example, you might use this functionality to swap out the binaries for custom actions. If you have set up separate
releases for 32-bit and 64-bit target systems, you can override the path variable that is used to refer to the DLL that is
selected for a custom action. Then InstallShield could include a 32-bit DLL for your 32-bit release and a 64-bit DLL for you
64-bit release. Note that overriding path variables to swap out files that your installation is installing is not recommended.
This is because you should use separate components for 32-bit and 64-bit versions of a file.
To override one or more path variables in your project, use the Path Variables Overrides setting, which is on the Build tab
for a release in the Releases view. For more information, see Build Tab for a Release.
See Also
Adding .NET Framework Redistributables to Projects
Destination Folders
Using 64-Bit Windows Installer Packages (Windows Installer Help Library)
Using 64-Bit Windows Installer Packages (Windows Installer Help Library)
Targeting 64-Bit Operating Systems
Building 64-Bit Setup Launcher
With a single InstallScript project, you can create one installation that installs to 32-bit locations on 32-bit systems, and to
64-bit and 32-bit locations as needed on 64-bit systems.
InstallScript installations are always 32-bit so they can run only 32-bit DLL code (or launch 32-bit or 64-bit .exe files).
However, all InstallScript installations support accessing 64-bit locations through the 64-bit component setting, as well as
through other methods.
• WINSYSDIR
• WINSYSDIR64
Although the WINSYSDIR64 variable is set to the 64-bit Windows folder, 64-bit Windows includes functionality to
automatically redirect 32-bit applications (such as the InstallScript engine) to the 32-bit System32 folder (SysWOW64).
Therefore, if you are installing files or folders to WINSYSDIR64, you can disable file system redirection by placing the folders
or files in a component that is marked as 64 bit. To specify that a component is 64 bit, select Yes for the component’s 64-Bit
Component setting. For more information about the 64-Bit Component setting, as well as additional component settings,
see Component Settings.
As an alternative, you can use the constant WOW64FSREDIRECTION with the functions Disable and Enable to disable 64-bit
Windows file system redirection while writing to or reading from the WINSYSDIR64 folder through your InstallScript code,
and then re-enable it once the write or read is complete. Since some Windows functionality that could be used by the
installation requires that redirection be enabled to work, Windows documentation recommends that you disable
redirection only for as long as necessary.
• COMMONFILES
• COMMONFILES64
• FOLDER_APPLICATIONS
• FOLDER_APPLICATIONS64
• PROGRAMFILES
• PROGRAMFILES64
If you want to install registry data to a 64-bit area of the registry without having it redirected to a 32-bit area, you can place
the registry data in a component that is marked as 64 bit. To specify that a component is 64 bit, select Yes for the
component’s 64-Bit Component setting. For more information about the 64-Bit Component setting, as well as additional
component settings, see Component Settings.
As an alternative, you can use the REGDB_OPTION_WOW64_64KEY option with the REGDB_OPTIONS variable to avoid
registry redirection while editing the registry or reading from the registry through your InstallScript code, and then use the
REGDB_OPTION_USE_DEFAULT_OPTIONS option with REGDB_OPTIONS to enable changes to the 32-bit area of the
registry. Since some Windows functionality that could be used by the installation requires that redirection be enabled to
work, Windows documentation recommends that you disable redirection only for as long as necessary.
Note that 32-bit self-registering files should not be installed to the 64-bit System32 folder, since file system redirection
cannot be disabled for self-registration. Thus, if you have a 32-bit self-registering COM server that needs to be installed to
the 32-bit System32 folder, ensure that No is selected for the 64-Bit Component setting of the component that contains the
COM server.
See Also
Targeting 64-Bit Operating Systems
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
Note • By default, the Suite/Advanced UI and Advanced UI installations are 32-bit. If required, you can change 64-Bit Setup
Launcher setting under release configuration for 64-bit installation. For 64-Bit Setup Launcher, see Building 64-bit Setup Exe.
Suite/Advanced UI and Advanced UI installations enable you to reference either 32-bit or 64-bit locations, and they can
launch 32-bit or 64-bit installations, depending on the target system.
For example, if you include in your Suite/Advanced UI project one installation that should target 32-bit systems, and
another installation that should target 64-bit systems, you could create an eligibility condition in the Packages view for
both of these packages; for the 32-bit package, the eligibility condition would contain a platform condition that checks for
the x86 architecture, and for the 64-bit package the eligibility condition would contain a platform condition that checks for
the x64 or IA64 architecture. For more information, see Types of Condition Checks in Advanced UI and Suite/Advanced UI
Projects.
See Also
Targeting 64-Bit Operating Systems
Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects
If you launch InstallShield without administrative privileges, the following functionality is not available:
• COM extraction—Extracting COM information from a COM server requires administrative privileges.
If you specify that you want to have COM information extracted from a COM server in your project, and then you try to
build a release while running InstallShield without administrative privileges, build error -6017 occurs.
If you try to download a redistributable from within the Redistributables view but you do not have administrative
privileges, InstallShield displays the following message:
The download failed; make sure you are running as Administrator, and that your machine is connected
to the Internet. Would you like to try again?
• Ability to specify All Users locations for InstallShield prerequisites—The Prerequisites tab on the Options dialog
box is where you specify the folders that contain the InstallShield prerequisites that should be displayed in the
Redistributables view and the Prerequisites view. Modifying the All Users location on that tab requires administrative
privileges, since InstallShield writes the information to a per-machine location in the registry. Therefore, the All Users
location on that tab is disabled if you are running InstallShield without administrative privileges.
• Ability to specify All Users locations for merge modules—The Merge Module tab on the Options dialog box is where
you specify the folders that contain the merge modules that should be displayed in the Redistributables view.
Modifying the All Users location on that tab requires administrative privileges, since InstallShield writes the
information to a per-machine location in the registry. Therefore, the All Users location on that tab is disabled if you are
running InstallShield without administrative privileges.
• Ability to edit the locations for Regasm.exe and InstallUtilLib.dll—The .NET tab on the Options dialog box is where
you specify the locations of Regasm.exe and InstallUtilLib.dll files, which are utilities that are included with the
.NET Framework. These utilities are used for COM interop and .NET custom actions. Modifying these locations on the
.NET tab requires administrative privileges, since InstallShield writes the information to a per-machine location in the
registry. Therefore, these location settings on that tab are disabled if you are running InstallShield without
administrative privileges.
If you switch between full Administrator and non-Administrator contexts and you use mapped-drive locations in your
projects, you may encounter issues. For example, if you map a drive letter to a shared network folder through Windows
Explorer without administrative privileges, you can access this drive letter in a non-administrative instance of InstallShield,
but not in an administrative instance. Likewise, if you map a drive letter to a shared network folder through Windows
Explorer with administrative privileges, you can access this location in an administrative instance of InstallShield, but not
in a non-administrative instance. Thus, if you want to reference network locations in your project, consider using UNC
paths (such as \\server\share) or mapping drive letters both with and without administrative privileges.
Note that if you are using InstallShield from within Visual Studio, you may not have administrative privileges. By default, if
you launch Visual Studio by double-clicking its shortcut on a Windows Vista or later system, you will not have
administrative privileges.
Task To run InstallShield from within Visual Studio with administrative privileges on a Windows Vista or later system:
1. On the Start Menu, right-click the Visual Studio shortcut and then click Run as administrator.
2. Create a new InstallShield project or open an existing one. For more information, see one of the following:
InstallShield is a 32-bit application that runs on both 32-bit and 64-bit systems. In some cases, InstallShield behaves
differently, depending on whether you are using it on a 32-bit system or a 64-bit system; you may also encounter
differences depending on which operating system you are using. The following sections explain these differences.
Note that like InstallShield, the command-line build (ISCmdBld.exe), the Standalone Build, and the automation interface
are also 32-bit applications. Therefore, the same platform-specific differences occur for these tools.
For more information, see Using the Automation Interface on a 64-Bit System.
To add a 64-bit System32 file on your development machine to your InstallShield project, you can browse to the Sysnative
folder on your machine and then select the appropriate file for your project. To learn more, see Adding Files from Your 64-
Bit Source Machine’s 64-Bit System32 Folder.
Viewing Both the 32- and 64-Bit Areas of the Source Machine’s Registry on 64-Bit
Development Systems
If you are using InstallShield on a 64-bit development system, the Registry view in InstallShield displays both the 32-bit and
64-bit areas of your machine’s registry:
• HKEY_LOCAL_MACHINE\Software
• HKEY_LOCAL_MACHINE\Software\Wow6432Node
This support enables you to drag and drop entries from those source areas to the appropriate areas in the destination pane
of this view when you are configuring registry data changes for your project.
Note that if you want your installation to install registry data to a 64-bit area of the registry on 64-bit target systems without
having it redirected to a 32-bit area, you must place the registry data in a component that is marked as 64 bit. Simply
dragging 64-bit data from the source panes in the Registry view to a location in one of the destination panes of the view
does not mark the component as 64 bit. For more information, see the following:
To learn about extracting COM data, see Extracting COM Registration Data at Build Time.
If you are using InstallShield on a 32-bit system, the dependency scanners in InstallShield cannot check 64-bit files in your
project for dependencies. To add 64-bit dependencies to a project on a 32-bit system, consider manually adding the
required files and merge modules to your project.
To learn about scanning files for dependencies, see Identifying Application Dependencies.
These methods also scan for 32-bit dependencies of the 32-bit .NET assemblies in your project.
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.
If you are building from the command line with ISCmdBld.exe on a 64-bit version of Windows, and you use the existing -t
parameter to specify the path of the 32-bit version of the .NET Framework, ISCmdBld.exe uses the 64-bit location of
Regasm.exe and InstallUtilLib.dll for 64-bit .NET installer classes and COM interop.
If you are building through MSBuild or Team Foundation Server (TFS) and you use the existing DotNetUtilPath parameter
on the InstallShield task to specify the path of the 32-bit version of the .NET Framework, the build uses the 64-bit location
of Regasm.exe and InstallUtilLib.dll for 64-bit .NET installer cases and COM interop.
Note that if you are using InstallShield on a 32-bit operating system, the setting for the 64-bit location is disabled, and only
32-bit support for .NET installer cases and COM interop is available. This support also applies to building from the
command line with ISCmdBld.exe, and building through MSBuild or TFS.
• ISCmdBld.exe
See Also
Launching InstallShield with vs. Without Administrative Privileges
Using Help
InstallShield 2020
Revenera understands the importance of having useful information and help resources at your fingertips. In addition to the
inline help embedded within various views of the InstallShield interface, InstallShield includes a help library that is
installed with the product, an online help system that is available on the Web, and documentation that is available in PDF
format.
You can access the InstallShield Help Library from the Help menu in InstallShield, by pressing F1, or by clicking Help
buttons in the interface.
No Internet connectivity is required to view the InstallShield Help Library. Essentially, the online help viewer is a tool that
you can use to display, search, and filter technical information based on your personal needs.
Help information is also available for each of the properties of a selected software object displayed in the Explorer window,
which provides instructions for setting that property.
Documentation as PDF
InstallShield documentation is also available as a PDF at: https://community.revenera.com/.
Contacting Us
InstallShield 2020
Revenera is headquartered in Itasca, Illinois, and has offices worldwide. To contact us or to learn more about our products,
visit our website at:
http://www.revenera.com
InstallShield 2020
InstallShield provides powerful features and time-saving tools that make authoring reliable Windows Installer and
InstallScript installations easy. The InstallShield Help Library is a resource that will help you harness the full potential of
InstallShield. The help topics you might want to read first depend upon your previous experience with InstallShield
installation-authoring software. The table below directs you to various topics based on your level of experience.
You have not created installations To learn general information about installations, refer to the following
previously. topics:
• Installation Fundamentals
• Application Lifecycle
You are new to InstallShield. If you have created installations previously but you do not have experience
using InstallShield, see the following topics:
• Globalization Tutorial
You have used other Revenera If you have used other products from Revenera, refer to any of the following
products. topics:
• Project Assistant
You are an intermediate-level or If you are familiar with InstallShield, you may want to review the following
advanced-level user of InstallShield. topics:
• Command-Line Tools
See Also
Frequently Asked Questions
Installation Fundamentals
InstallShield 2020
An installation, in its simplest terms, is the “package” used to install your files and programs onto your user’s machine. It is
a complete collection of the application files, as well as logic that interacts with the installer engine. The primary task of
any installation is to transfer the application files from the source medium to the end user’s computer. The complexities of
the Windows operating system make it anything but simple to create an effective, coherent installation without the aid of a
utility such as InstallShield.
An installation is divided into three levels: products, features, and components. The following diagram illustrates this
hierarchy:
A product is the highest level of organization in an installation project. A product is usually one main application (for
example, a word processor) and all of the files and data that the application requires; a suite of applications may also be a
product.
A feature is the smallest installable part of a product, from the end user’s perspective. As the designer of an installation
program, you usually allow the user to choose which features to install and which features to leave on the source media. In
a word processor product, the main executable may be one feature, and optional dictionaries may be a separate feature. A
feature should be self-contained, in the sense that a feature should not require sibling features. For example, a thesaurus
feature should not require a dictionary feature that the user can choose not to install. However, you can design features to
contain subfeatures, which allow the end user finer control over which files and data to install.
Each feature in a project is made up of one or more components. A component is the smallest installable part of a product
from the installation developer’s perspective; components are invisible to the end user. Each component contains files
(and other resources) with similar properties. For example, all of the files in a component will be installed in the same
directory on an end user’s machine, and all of the files in a component should apply to the same operating system or
language. A dictionary feature might contain several language-specific dictionary components. In addition to containing
files, components generally contain registry data, shortcuts, file extension information, and other system data to write to a
user’s machine.
When you are designing an installation, the overall task is to separate the product’s files into components based on the
files’ destination, operating system, language, and other properties, and to associate each component with one or more
features.
See Also
Application Lifecycle
Working with Projects
Creating Installations
Application Lifecycle
InstallShield 2020
Your application lifecycle should not end when your customer installs your application. As a software vendor, the success
of your application goes well beyond the initial installation on the customer’s desktop. Customers expect to have easy
access to product updates, enhancements, and critical information. Your ability to communicate with your customers and
monitor the health of your application is vital to your ongoing growth and profitability.
Too often, software vendors require their customers to initiate communication. Vendors who are not proactively creating
an ongoing dialog are missing a tremendous opportunity. Unless the customer is an active visitor to your Web site or public
user communities, they miss important information about updates, upgrades, hot fixes, and general technical bulletins.
You miss revenue and service opportunities.
The above diagram illustrates how FlexNet Connect is used to manage the application lifecycle:
1. Create Install—InstallShield makes it easy for software developers to create installations that run on any platform.
2. Run Install—Installations created with InstallShield technology have successfully installed on over 400 million
machines worldwide.
3. Create Update—InstallShield enables software developers to rapidly build patches and updates.
4. Notify User—FlexNet Connect notifies every user that a new update is ready to be installed.
5. Download & Install—FlexNet Connect downloads the update and installs it in one seamless, integrated process.
6. View Reporting—FlexNet Connect provides immediate feedback on the update’s adoption rate.
See Also
Creating Installations
Updating Applications
Notifying End Users about Upgrades Using FlexNet Connect
General Information View Settings
Starting InstallShield
InstallShield 2020
Each time you open InstallShield (with the exception of the initial launch after installing the product), you are taken
directly to the InstallShield Start Page. The Start Page provides quick access to product information, to recently opened
projects, and to InstallShield resources.
See Also
InstallShield Start Page
The InstallShield Start Page provides quick access to product information, to recently opened projects, and to InstallShield
resources. The Start Page includes the following sections:
Section Description
Project Tasks Click a project task to quickly create a new project, open an existing project, or browse to one
of the sample projects included with the InstallShield installation.
Help Topics Frequently accessed help topics are listed in this section. To access the entire InstallShield
Help Library from the Start Page, press F1 or click the Help Library link in the Resources
section.
(Recently Opened The section in the middle of the Start Page lists your most recently accessed projects, the
Projects) project types, and the dates on which they were last modified.
Getting Started Click the Getting Started heading for guidance on what areas of the InstallShield Help Library
to read, based on your level of experience with InstallShield and installation-authoring tools.
Resources The Resources section contains a number of links to connect you to helpful InstallShield
information.
• Webinars—Directs you to free Web-based seminars that help you evaluate InstallShield
and gain the most from your Revenera products.
• Release Notes—Connects you to the release notes that are posted to the Knowledge
Base on the Revenera Web site.
• Known Issues—Displays the Knowledge Base article that lists the known issues for the
version of InstallShield that you are using and provides information about workarounds
and resolutions.
• Upgrade Alerts—Displays the Knowledge Base article that provides information about
possible issues that may occur when you upgrade projects that were created with earlier
versions of InstallShield to InstallShield 2020. It also alerts you to possible changes in
behavior that you may notice between new InstallShield 2020 projects and projects that
are upgraded from earlier versions.
• RSS Feeds—Directs you to the Web page where you can subscribe to RSS feeds of
InstallShield Knowledge Base articles.
Section Description
Contact Us To access the Support area of the Revenera Web site, click one of the links listed in this
section.
An InstallShield project specifies the files, folders, and operations that make up the project’s output. A project’s output is
one of the following (depending on the project type):
• Redistributable (merge module or InstallShield object): contains logic and files needed to install distinct pieces of
functionality when included in an installation
• Transform: enables an administrator to apply modified settings to an Windows Installer installation when deploying
the installation
A project can be as simple or as complex as you need to meet your requirements. A simple project might consist of files,
components, features, and registry entries. More complex projects might consist of these items plus redistributables,
initialization file changes, and calls to external DLL functions.
See Also
Project Types
With InstallShield, you have the ability to choose between a variety of different installation project types—those that use
InstallShield’s powerful InstallScript programming language (InstallScript), those that use the Windows Installer database
(Basic MSI), or a combination of the two (InstallScript MSI).
The installation project type you choose depends on the needs of your software installation. InstallShield provides the
same intuitive user interface for all project types, so your application’s needs can dictate the project type and your
authoring experience does not change. Additionally, the knowledge gained by learning how to create projects of one type
is applicable to projects of the other types.
Despite the similarities in the project types’ feature sets, there are some important differences between them—especially
between the InstallScript and Basic MSI projects. See Determining Which Installation Project Is Right for You to learn which
of these project types is right for your software installation needs.
See Also
InstallScript Installation Projects
Basic MSI Installation Projects
InstallScript MSI Installation Projects
InstallShield enables you to create different types of projects, but for the beginner there is just one significant choice to
make: Do you want to build your installation with Windows Installer or InstallScript technology? Deciding which project
type is right for you depends on your experience with InstallShield software and installation development and on your
installation and deployment needs. The three main project types are described below.
• You want to maximize compatibility with administrative tools such as Microsoft System Center Configuration
Manager, or if your software will be customized by corporate system administrators prior to deployment. The Basic
MSI project type gives them the flexibility to create transforms for the installation package and its associated
properties, without repackaging your installation.
• You want to avoid writing scripting code and want to instead set properties and make table entries.
InstallScript Projects
InstallScript projects use InstallScript to control the installation. This project type is recommended for any of the following
scenarios:
• You have advanced requirements for the end-user experience (the end-user dialogs), such as multimedia elements.
• You want to use full-screen billboards during the run time of your installation.
• You prefer authoring the project using a procedural language at its core rather than a set of database tables.
• You want to perform actions before or after the main installation has been run.
• You have advanced requirements for the end-user experience (the end-user dialogs), such as multimedia elements.
• You prefer authoring the project using a procedural language at its core rather than a set of database tables.
• You want to perform actions before or after the main installation has been run.
Tip • Repackager is a project conversion tool that is available in AdminStudio. You can use this tool to convert InstallScript
projects and InstallScript MSI projects to Basic MSI projects.
See Also
InstallScript Installation Projects
Basic MSI Installation Projects
InstallScript MSI Installation Projects
Converting from One Project Type to Another Project Type
Project Types
InstallShield 2020
InstallShield offers a number of different project types to assist you in creating the optimal project for your end users.
Advanced UI
Basic MSI A Basic MSI project uses Windows Installer to provide the user interface for
the installation. When you choose this project type, you need to create
features and components, and specify all application files and other
distributable data.
DIM A DIM project is targeted toward engineering teams who want to foster
collaboration, enable distributed installation development, and maximize
efficiency in their organizations. A developer installation manifest (DIM) 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, logically separated portion of a product
installation. You can incorporate one or more DIMs into Basic MSI projects.
InstallScript The InstallScript installation project provides the flexibility afforded by the
InstallScript language and is driven by the proven InstallScript engine.
InstallScript MSI An InstallScript MSI project uses both InstallScript and Windows Installer
tables. With this project type, you need to create features and components,
and specify all application files and other distributable data.
InstallScript Object Using the InstallScript Object project, you can create an InstallShield merge
module that uses InstallScript. This type of merge module, however, can be
consumed only by InstallShield.
Merge Module Select this option to create your own merge modules. You need to create
any components and file associations.
MSI Database Select MSI Database to edit your installation project in Direct Edit mode.
This means that you can directly edit the Windows Installer tables within
InstallShield to configure your installation.
MSM Database Select MSM Database to edit your merge module in Direct Edit mode. This
means that you can directly edit the Windows Installer tables within
InstallShield to configure your merge module.
QuickPatch This project type is recommended for installation authors who want to ship
small, single updates to their end users. QuickPatch authoring provides an
alternative to creating a patch configuration in the Patch Design view even
though it provides less customization. Creation of a QuickPatch begins with
the Create New QuickPatch Wizard.
Suite/Advanced UI
MSIX
MSI to MSIX Conversion The MSI to MSIX Conversion Wizard enables you to convert existing
Wizard Windows Installer files (.msi files) to MSIX packages through a Basic MSI
project.
Visual Basic .NET Wizard Select this option to launch the Visual Studio .NET Wizard for Visual Basic
.NET, C# .NET, and Visual C++ .NET.
C# .NET Wizard Select this option to launch the Visual Studio .NET Wizard for Visual Basic
.NET, C# .NET, and Visual C++ .NET.
Visual C++ .NET Wizard Select this option to launch the Visual Studio .NET Wizard for Visual Basic
.NET, C# .NET, and Visual C++ .NET.
See Also
Creating New Projects
Determining Which Installation Project Is Right for You
Converting from One Project Type to Another Project Type
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
Advanced UI and Suite/Advanced UI installations are bootstrap applications that package together installations and
InstallShield prerequisites as a single installation while providing a unified, fully customizable user interface. They use a
setup launcher (Setup.exe) to conditionally launch packages on target systems as needed.
Note that Advanced UI and Suite/Advanced UI installations require Windows Vista or later or Windows Server 2008 or later.
Also note that the ability to create and build a Suite/Advanced UI installation that includes a sideloading Windows App
package (.appx) requires Windows Vista or later or Windows Server 2008 or later on the machine that has InstallShield or
the Standalone Build.
See Also
Creating Advanced UI and Suite/Advanced UI Installations
Primary Packages vs. Dependency Packages in Advanced UI and Suite/Advanced UI Projects
MSIX Projects
InstallShield 2020
Edition • The MSIX project type is available in the Premiere edition and Professional edition of InstallShield.
MSIX is the Windows app package format that provides a modern packaging experience to all Windows apps. The MSIX
package format preserves the functionality of existing app packages and/or install files in addition to enabling new,
modern packaging and deployment features to Win32, WPF, and WinForm apps.
In InstallShield 2019 and later, you can now use MSIX project type to build MSIX packages. It contains windows applications
for side-loading or distribution via the Windows Store.
• Package Information
• Package Payload
• Media
Package Information
Now you can describe and identify your project by providing:
• General Information view to specify details such as the name and format of the project file.
• MSIX VisualAssets explorer to offer an integrated, visual method for describing visual aspects of the MSIX apps.
• Capabilities view that requires to be enabled in app's package manifest to access certain API or resources like
pictures, music, or devices such as the camera or the microphone.
• Declarations view that provides a visual tool for creating and managing the application, package level declarations
and allows to configure their properties.
• Content URIs view to specify the URIs that can use window.external.notify to send a Script-Notify event to the app.
Package Payload
Now you can specify the files that designs your MSIX application:
• Files and Folders view lets you to add files to your InstallShield project. You can organize these files into folders on
the target system.
Important • If you are packaging your UWP application using MSIX project, you are required to add all the assets in the same
folder structure as expected by the application.
• Applications view offers an integrated, visual method for designing windows app properties that comprises part of or
all of the functionality delivered in the package.
• Registry view enables you to define registry keys and values to be created by your installation.
Media
Now you can customize the files and folders that you will use to distribute your installation:
• Path Variables view makes your installation easily portable between development systems through the use of
variables.
• Releases view provides a visual tool for each product in your project.
Basic MSI is the Windows Installer–based project type in InstallShield. Basic MSI projects are recommended in cases where
the Windows Installer service should drive the entire installation. They allow you to author your installation using only the
native Windows Installer feature set. The geometry of your end user dialogs as well as the flow of your setup user interface
(UI) is authored directly in the MSI package, and the Windows Installer Service uses its native user interface rendering
capabilities to display the UI to your end users. The advantages of this project type are fully realized if you need to author
your installation in an open format.
Note • Create a Basic MSI project if your software will be customized by corporate systems administrators prior to
deployment. It gives them the flexibility to create transforms for the installation package and its associated properties,
without repackaging your installation.
Basic MSI projects have the ability to run InstallScript code in the form of custom actions. As with InstallScript projects,
Basic MSI projects take advantage of other robust features provided by InstallShield such as dialog authoring, the ability to
call custom actions in standard Windows .dll files, and the ability to specify support files.
See Also
Installation Projects Overview
InstallScript Installation Projects
Converting from One Project Type to Another Project Type
Run-Time Behavior for Basic MSI Installations with InstallScript Custom Actions
InstallShield 2020
a. The Windows Installer calls the relevant entry point in ISSetup.dll (loaded from the Binary table).
The run-time behavior for InstallShield 12 and later Basic MSI projects that have InstallScript custom actions is much
different than the behavior for InstallShield 11.5 and earlier because of some architecture enhancements. For more
information about the enhancements, see Upgrading Projects from InstallShield 11.5 or Earlier.
2. Setup.exe launches MsiExec.exe to install the primary .msi file. (Setup.exe must be included in the installation, or it
must already be present on the target system.)
b. ISScriptBridge.dll finds the running IDriver.exe instance using the running object table (ROT).
If you upgrade an InstallShield 11.5 or earlier project to InstallShield 2020, the run-time behavior is updated to the behavior
described for InstallShield 12 and later projects.
See Also
Upgrading InstallShield 11.5 or Earlier Basic MSI Projects that Have InstallScript Custom Actions
Overview of ISSetup.dll
DIM Projects
InstallShield 2020
The DIM support in InstallShield is targeted toward engineering teams who want to foster collaboration, enable distributed
installation development, and maximize efficiency in their organizations. A developer installation manifest (DIM) 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, logically separated portion of a product installation. Some benefits
of using DIMs are as follows:
• 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 installation projects.
• Release engineers can reuse DIMs in multiple installation projects, enabling efficiency.
• 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.
See Also
Modularizing Installation Projects to Distribute Development Work and Enable Reuse
Using Path Variables in a DIM
Specifying the Default Destination Folder for a DIM
The InstallScript installation project type provides the power and flexibility of the InstallScript programming language and
the familiarity of the InstallShield Professional project. Windows Installer is not used at all. The installation is completely
script driven and very flexible, and it uses the InstallScript engine, the same trusted engine used by InstallShield
Professional.
Note • InstallScript installations are generally less desirable to systems administrators because they require the use of
Setup.exe, rather than being self-contained in an .msi file, and may not be fully customizable prior to deployment. If your
software will be customized by corporate systems administrators prior to deployment, create a Basic MSI installation project.
Using InstallScript as the installation driver has many benefits. The first is that InstallScript’s event model enables you to
create a script-driven installation without writing a single line of code. If you want to add custom functionality, you need to
implement only the events whose functionality you want to change.
The user interface abilities for Basic MSI projects are somewhat limited with regard to the types of controls you can use or
the kind of control you have over dialog events. InstallScript projects have no such limitation—offering a wide range of
standard controls along with the ability to add custom dialog controls. Dialog messaging in the script enables you to have
complete control over how your end-user dialogs behave.
Feature Description
Setup Types view This view enables you to easily create different installation configurations for
your application. This view also lets you select the defaults for the Custom setup
type.
Billboard Support Run-time billboard support is available only for InstallScript projects. Billboards
let you show bitmaps to the end user while files are being transferred to their
machine. You can use these bitmaps to entertain or educate user.
See Also
Installation Projects Overview
Basic MSI Installation Projects
Converting from One Project Type to Another Project Type
• The Windows Installer engine runs the standard Execute sequence of the .msi package. This is the sequence that
typically modifies the target system.
• The InstallScript engine serves as the custom user interface (UI) handler of the installation. It also executes the
InstallScript code. The advantage of using the InstallScript engine for the UI is that it offers support for highly
customized run-time dialogs.
In addition, InstallShield offers two different styles for the UI of InstallScript MSI installations:
• Traditional style—This style lets you use the InstallScript engine as an external UI handler for your InstallScript MSI
installation. With this style, your installation must include a Setup.exe setup launcher. The setup launcher serves as a
bootstrap application that initiates the InstallScript engine to display the UI and run the InstallScript code, and the
Windows Installer to run the Execute sequence of the .msi package.
• New style—This style lets you use the InstallScript engine as an embedded UI handler for your InstallScript MSI
installation. For this style, InstallShield embeds the InstallScript engine within the .msi package. The Windows
Installer calls the InstallScript engine to display the UI. The Windows Installer also runs the Execute sequence of the
.msi package.
This option requires Windows Installer 4.5 on the target machine. This option also has some limitations that require
careful planning if you decide to use this style.
For detailed information about these two styles, see Using the InstallScript Engine as an External vs. Embedded UI Handler
for InstallScript MSI Installations.
Note • Because this project type uses two different engines, it is more complex than pure InstallScript or Basic MSI installation
projects. It is recommended only for advanced users.
Traditional-style InstallScript MSI installations are less desirable to systems administrators than Basic MSI installations or
new-style InstallScript MSI installations. That is because traditional-style InstallScript MSI installations require the use of
Setup.exe, rather than being self-contained in an .msi package, and they may not be fully customizable prior to deployment.
If your software will be customized by corporate systems administrators prior to deployment, create a Basic MSI project. As an
alternative, you could consider using the new-style InstallScript MSI installations, but your must ensure that any system
changes that need to be made are done with custom actions in the Installation Execute sequence. To ensure that sufficient
privileges are available, custom actions should have an in-script execution setting of deferred in system context.
Feature Description
Setup Types view This view enables you to easily create different predefined installation
configurations for your application, such as Typical or Compact. This view also
enables you to select the defaults for the Custom setup type.
Billboard Support Run-time billboard support is available for InstallScript MSI installations, but
not Basic MSI installations. Billboards enable you to show bitmaps while files
are being transferred to an end user’s machine. You can use these bitmaps to
entertain or educate end users.
See Also
InstallScript Installation Projects
Basic MSI Installation Projects
Converting a Basic MSI Project to an InstallScript MSI Project
Converting an InstallScript MSI Project to an InstallScript Project
a. Loads Setup.inx.
c. Launches the Windows Installer (and the InstallScript engine for the external user interface).
d. Each InstallShield custom action executes as follows (for example, OnMoved). (Note that this essentially the
same mechanism that is used in Basic MSI with InstallScript custom actions.)
i. The Windows Installer calls the relevant entry point in ISSetup.dll. (This is a different instance of
ISSetup.dll, loaded from the Binary table.)
The run-time behavior for InstallShield 12 and later InstallScript MSI projects is much different than the behavior for
InstallShield 11.5 and earlier because of some architecture enhancements. For more information about the enhancements,
see Upgrading Projects from InstallShield 11.5 or Earlier.
a. Loads Setup.inx.
c. Launches the Windows Installer (and the InstallScript engine for the external user interface).
Each InstallScript custom action executes as follows (for example, OnMoved). (Note that this is the same
mechanism used in Basic MSI installations with custom actions.)
ii. ISScriptBridge.dll finds the running IDriver.exe instance using the running object table (ROT).
See Also
Overview of ISSetup.dll
Merge modules allow you to add existing pieces of functionality to your installation. For example, if your application
requires the VB Run-Time DLL, you can add Microsoft’s Visual Basic Virtual Machine module to your setup application.
Traditionally, you would have to create registry entries, set the target folders, custom actions and any other necessary
steps yourself. With merge modules, all you need to do is associate an existing merge module with your installation and
move on to your next task.
InstallShield provides you with the ability to create your own merge modules to distribute with your installations or give
away to other developers. This can be useful if you are going to include certain pieces of functionality in all of your
installation projects. Rather than having to recreate that part of the installation every time, you can create it once as a
merge module and then associate that module with all of your installation projects.
See Also
Designing Merge Modules
The MSI Database and MSM Database project types allow you to edit Windows Installer installation databases and merge
module databases directly, rather than working through an intermediate project format (.ism file). These project types
extend the Direct Editor functionality to include different views that are supported in standard installation and merge
module projects. The views that are supported in these project types are intended to function as they do for an .ism
project.
Project • There is no string entry or path variable support in an MSI Database or MSM Database project.
You can directly edit an existing .msi file or .msm file, or directly create a new database by opening a new MSI Database or
MSM Database project. The data in this file should match what you would get if you created a blank Basic MSI or Merge
Module project and built a database from that project.
See Also
Adding Files in Direct Edit Mode
Adding Merge Modules in Direct Edit Mode
Using InstallShield objects, you can easily install key Windows technologies. To install a technology, simply include the
corresponding InstallShield object in your installation. If a technology is required by a particular component, you can
associate the corresponding InstallShield object with the feature.
See Also
Creating InstallScript Objects
QuickPatch Projects
InstallShield 2020
A QuickPatch project is a specific type of project recommended for installation authors who want to ship small, single
updates to their users. Changes that are more extensive such as adding custom actions and changing .ini data typically
require a standard patch.
QuickPatch authoring provides a simple alternative to creating a patch configuration in the Patch Design view, even
though it provides less customization. Fundamentally, both patch creation methods produce the same deliverable types:
.msp and .exe files.
• Remove custom actions that were included with the original installation but that do not apply to the current
QuickPatch project.
The creation of a QuickPatch project always begins with the Create New QuickPatch Wizard. After you have completed the
wizard, you can configure the QuickPatch project settings once the project opens in InstallShield.
See Also
Upgrades Overview
Determining the Best Upgrade Solution
Working with Upgrades, Patches, and QuickPatch Projects
Transform Projects
InstallShield 2020
A transform (.mst file) is a simplified Windows Installer database that contains the differences between two .msi databases.
Transforms enable an administrator to apply modified settings to a database when deploying an installation package.
InstallShield has a transform project type that enables you to edit .msi packages without having to convert them to an
InstallShield (.ism) project. You can save the changes made as a transform (.mst) file.
When you create a transform project or open a transform in InstallShield, the Open Transform Wizard launches to gather
information about the base .msi file and any additional transform files that you want applied to the base .msi file.
See Also
Editing Transforms
Using Projects
InstallShield 2020
InstallShield allows you to create, edit, upgrade, and save numerous project types—from installation projects to
InstallShield object projects that allow you to reuse functionality within InstallShield.
The pages in this section cover a variety of topics, including how to create a particular project type, how to create project
templates, and what to expect when you upgrade from a different InstallShield product.
See Also
Working with Projects
Project Types
• Click the New Project button on the toolbar or on the InstallShield Start Page.
• Press Ctrl+N.
Any of these steps launches the New Project dialog box, from which you can select the project that you want to create.
See Also
Project Types
Opening Projects
InstallShield 2020
• On the File menu, click Open. In the Open dialog box, navigate to the project file.
• Press Ctrl+O.
• Click the Open an existing project link or click a recently opened project link on the InstallShield Start Page.
With the exception of clicking a specific file or file link, all of the above options launch the Open dialog box, which enables
you to browse to your project file.
See Also
Opening Projects from Source Code Control
Converting or Importing Visual Studio Projects into InstallShield Projects
Opening Patch Creation Properties Files in Direct Edit Mode
An option on the Open dialog box enables you to get the latest version of a project folder from your source control
application.
1. On the File menu, click Open. The Open dialog box opens.
2. Click the Source Control button. A login dialog box for your source control program opens.
3. Log on to your source control program and browse to your project folder or database.
InstallShield gets the latest versions of every file in that project to a working directory.
Note • If you do not have a source control application on the system that has InstallShield, the Open dialog box does not
display the Source Control button.
See Also
Opening Projects
You can open a previously created patch creation properties file from the Open dialog box.
1. On the File menu, click Open. The Open dialog box opens.
2. In the Files of type list, click Patch Creation Properties Files (*.pcp).
3. Select the .pcp file you want to edit and click Open.
See Also
Opening Projects
InstallShield provides the option to either edit MSI packages directly in the IDE in Direct Edit Mode or convert it to an
InstallShield project (.ism), and then edit it as a Basic MSI project in the IDE.
Note • Some functionality may be limited when editing an MSI package in Direct Edit Mode.
1. Click the Open Project button on the toolbar. A browse dialog opens.
2. Select Windows Installer Packages (*.msi) from the Files of Type list.
4. Ensure that the Open as field is set to Auto, and click Open.
Note • By default, the IDE opens an MSI package in Direct Edit Mode.
The Open MSI/MSM Wizard can convert an existing Windows installer (.msi) package to an InstallShield project (.ism) file,
and open the new project to modify in the IDE.
Note • You can also open Patch Creation Project files (.pcp files) in InstallShield and edit them in the Direct Editor.
The Open MSI/MSM Wizard can convert an existing Windows Installer merge module (.msm file) to an InstallShield project
(.ism) file, and open the new project in the InstallShield IDE.
1. Click the Open Project button on the toolbar. A browse dialog opens.
2. Select Windows Installer Modules (*.msm) from the Files of Type list.
The Open MSI/MSM Wizard prompts for specific information about the project you are creating, and then opens your new
merge module project in the IDE.
You can open an object project (.ipo or .ipr) that you created using InstallShield Professional. When you open this project in
InstallShield, it is migrated to a merge module (.msm) project.
To associate your merge module with InstallShield installation projects, you can automatically place your merge module
project in the Modules folder so it is available in the Redistributables view for use in setup projects.
Task To automatically place your merge module project in the Modules folder:
Select the “Add to local merge module catalog” option in the Merge Module Options panel of the Release Wizard.
Saving Projects
InstallShield 2020
When you create a new project, it is saved automatically with the name and location that you provide in the New Project
dialog box.
InstallShield enables you to save a copy of the open project as a template or as a new project with a different name and
location.
See Also
Project Templates
When you save your project with a new name and location, a copy of the renamed project file and all of its associated files
and folders are saved in the new location. The next time that you save your project, all changes are saved to this new
location.
1. On the File menu, click Save As. The Save As dialog box opens.
3. Select or clear the Create ‘Project Name’ subfolder and save the project in the created folder check box as
appropriate. In both cases, a <Project Name> subfolder is created in the Project Location box (on the File Locations
tab of the Options dialog box).
If you select the Create ‘Project Name’ subfolder and save the project in the created folder check box, the project
file (.ism) is saved in the <Project Name> subfolder. If you clear the check box, the project file is saved in the location
specified in the Project Location box.
4. If the new project’s GUID should be different than the GUID of the original project, select the Create and assign a new
project GUID to the saved project check box. If the new project’s GUID should be the same GUID of the original
project, clear this check box.
5. To use the name that you specified in the File name box as the value for the Product Name setting (in the General
Information view) of the new project, select the Update the project settings appropriately based on the new
project name check box. If the new project’s Name property should be the same as that of the original project, clear
this check box.
Note • When you save a project with external dependencies, such as InstallScript files, your new project points to the original
copies of these files. Duplicate copies are not made. Therefore, before you delete your original project, ensure that you do not
delete any files that may be used by the new project.
See Also
Save As Dialog Box
InstallShield offers support for converting some types of projects to other types of projects.
Convert Basic MSI project to See Converting a Basic MSI Project to an InstallScript MSI Project.
InstallScript MSI project
Convert InstallScript MSI project to See Converting an InstallScript MSI Project to an InstallScript Project.
InstallScript project
Convert InstallScript project to Use Repackager to convert an InstallScript project to a Basic MSI project.
Basic MSI project
Convert InstallScript MSI project to Use Repackager to convert an InstallScript MSI project to a Basic MSI project.
Basic MSI project
Convert Visual Studio setup project See Converting or Importing Visual Studio Projects into InstallShield Projects.
to InstallShield Basic MSI project
Convert Visual Studio merge module See Converting or Importing Visual Studio Projects into InstallShield Projects.
project to InstallShield Merge
Module project
See Also
Project Types
Converting your Basic MSI project to an InstallScript MSI project allows you to take full advantage of the scripting
capabilities that are available in InstallShield.
Caution • This conversion is irreversible. After you convert your Basic MSI project to an InstallScript MSI project and save it,
you cannot easily convert your project back to a Basic MSI project. Before you convert your Basic MSI project, it is generally
good practice to first create a back-up copy of it.
Converting Projects
2. On the Project menu, point to Project Converters, and click Convert to InstallScript MSI project.
Converting Dialogs
Because an InstallScript MSI project uses resource-based dialogs—instead of using the Windows Installer dialog–related
tables—no Windows Installer–based dialogs from your original project are available after the migration. You need to
manually add any custom dialogs.
Your converted installation project contains the default InstallScript MSI dialogs. To review the default dialogs, go to the
InstallScript view and view the dialogs displayed in the OnFirstUIBefore and OnFirstUIAfter events.
InstallScript MSI projects created using InstallShield, InstallShield DevStudio, or InstallShield Developer can be easily
converted to the InstallScript project type.
2. On the Project menu, point to Project Converters, and click Convert to InstallScript project.
GUIDs
InstallShield 2020
GUID stands for globally unique identifier. A GUID is 128 bits long, and the algorithm used to generate a GUID guarantees
each GUID to be unique. Because GUIDs are guaranteed to be unique, they can be used to identify COM classes, Product
Codes, and various other codes.
Package Code The package code uniquely identifies your installation package.
Project • This GUID is available in the following project types: Basic MSI,
InstallScript MSI, and QuickPatch.
Package GUID The package GUID uniquely identifies the installation package in the
Advanced UI or Suite/Advanced UI installation.
Project • This GUID is available in the following project types: Basic MSI,
InstallScript MSI, and QuickPatch.
Suite GUID The Suite GUID uniquely identifies your Advanced UI or Suite/Advanced
UI installation.
Upgrade Code or Upgrade GUID The upgrade GUID uniquely identifies a family of products for upgrade
purposes. It is important for major upgrades.
Project • This GUID is available in the following project types: Basic MSI,
InstallScript MSI, and QuickPatch.
Project • For information on when you need to change GUIDs in a Basic MSI or InstallScript MSI project, see Major Upgrade vs.
Minor Upgrade vs. Small Update.
To specify a new default location for your installation projects, use the File Locations tab on the Options dialog box.
Note • Although this folder is used for all new installation projects, any existing projects remain in the previous location.
You can save several elements in your project to reuse in another project. In some cases, the data must be saved to an
intermediary file and in others you can export it directly to another .ism file. The manner in which you can reuse each
element is described below.
Entire Projects
By saving a project as an InstallShield project template, you can create a project from the template that is almost identical
to the original project.
Registry Entries
When you export registry entries to a REG file, you can import that file into another component’s registry data in the same
project or an entirely different one.
String Entries
You can export a project’s string entries for a specific language to a tab-delimited text file. Typically, you would send the
text file out for translation and then import the string entries back into the project for another language. However, you
could also add the exported string entries to another project by importing the file into the other project.
End-User Dialogs
You can save all of your dialogs to an .rc file, export them individually to InstallShield dialog template files, or export them
directly to another project.
Components
To export a component to another project, right-click on the component and select Export Components Wizard. Follow
through wizard and the component and all of its data are added to the specified project.
Custom Actions
You can export a custom action to another project by right-clicking on the custom action in the Custom Actions explorer
and clicking Export. The Custom Actions explorer is in the Custom Actions and Sequences view (in Basic MSI, InstallScript
MSI, MSI Database, and Transform projects) and the Custom Actions view (in DIM, Merge Module, and MSM Database
projects).
InstallShield supports the use of repositories. A repository is a collection of common elements that can be shared and
reused in different installation projects. Elements that can be stored in a repository include:
• End-user dialogs
• InstallScript files
• Merge modules
• Project templates
• SQL scripts
• System searches
Repositories provide you with the ability to reuse project elements in multiple projects and strive for consistency. They also
save you from having to duplicate work. For example, if many of the installations for your organization’s products include a
particular custom dialog, you can create that custom dialog once and then publish it to your repository. Any time you want
to use that dialog in another installation, simply add the dialog from your repository to your project.
• Local repository—A local repository is your own collection of installation elements that you want to be able to reuse in
multiple projects. A local repository is stored on your local machine, and it is not available to other installation
authors.
• Network repository—A network repository is a collection of installation elements that multiple installation authors
can access and reuse in their projects as needed. A network repository fosters collaboration among installation
authors; it is stored on a network. For information on configuring a network repository, see Setting up a Network
Repository.
Edition • Network repositories are available in the Premier edition of InstallShield only. Local repositories are available in
both the Premier and Professional editions of InstallShield.
See Also
Publishing a Dialog (.isd) File to a Repository
Publishing InstallScript Files (.rul and .h) to a Repository
Publishing a Merge Module to a Repository from Within a Merge Module Project
Publishing Project Templates to a Repository
Publishing SQL Script Files to a Repository
Publishing a System Search to a Repository
Edition • Network repositories are available in the Premier edition of InstallShield only.
To configure a network repository, or to change the network repository settings, use the Repository tab on the Options
dialog box.
Project Templates
InstallShield 2020
A project template contains all of the default settings and design elements that you want to use as a starting point when
you create an installation project or merge module project.
You can open a template in InstallShield and edit it as you would a project. To create a template, save any project as a
template. For more information, see Creating Project Templates.
For instructions on starting a new project based on a template, see Basing New Projects on Templates.
InstallShield project templates serve only as a starting point for new projects. After you have created a project based on a
template, there is no link between the current project and the existing template. If you change an element in the template,
it does not affect the project that you created based on that template. However, you can modify the template and create
another project based on the updated version of the template.
See Also
Creating Project Templates
Reusing Project Elements
The procedure for creating a template file varies, depending on whether you are creating a template for a project type that
uses .ism project files (Basic MSI, InstallScript, InstallScript MSI, Merge Module), or for a project type that uses .issuite
project files.
Creating a Project Template File for Projects that Use .ism Project Files
You can create a project template from any .ism project file; this includes installation projects and merge module projects.
When you create a template from an .ism project file, the template file has an .ist file extension.
1. Edit the project to include the desired default settings, user interface, features, and so on.
2. On the File menu, click Save As. The Save As dialog box opens.
4. Type a file name (with the .ist extension) and select a location for the new template. The recommended location for
templates is a Templates folder within the project location folder.
5. Click OK.
You can open the template in InstallShield and make additional changes. You can use the final version of your template to
create a new project.
Creating a Project Template File for Projects that Use .issuite Project Files
You can designate any Advanced UI or Suite Advanced UI project (.issuite) to be a template. Project files and template files
for these project types have the same file extension: .issuite.
Task 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 save time, you can base multiple projects on a single project template that contains default settings and design
elements. The template can be stored somewhere on your system. It can also be stored in a repository.
1. On the File menu, click New. The New Project dialog box opens.
Note • To display templates that are stored in a repository, right-click in the box of project types and ensure that Show
Templates in Repository is enabled. To add a template to the tab, right-click in the box of project types and then click
Add New Template. Then browse to the desired template file (.ist file).
5. In the Location box, type the path to the directory where you want to store your template, or click the Browse button
to find it.
6. Click OK. InstallShield creates the new project based on the template that you selected, and the new project is opened
in InstallShield.
The new project is virtually identical to the project template, except that InstallShield generates a new product code (for
installation projects), package code, and upgrade code (for Windows Installer–based installation projects), and a module
ID for merge module projects.
See Also
Using a Repository to Share Project Elements
If you have an existing template that you would like to reuse for other projects or share with other users, you can publish it
to a repository.
1. On the File menu, click New. The New Project dialog box opens.
3. Right-click the template that you want to publish and then click Publish Template to Repository. The Publish
Wizard opens.
After you have created a project that is based on a template in your repository, there is no link between the current project
and the existing repository template. If you make a change to the template and then republish it to the repository, it does
not affect the project that you created based on the template. However, you can create a new project based on the
updated version of the template in the repository.
See Also
Basing New Projects on Templates
Using a Repository to Share Project Elements
Sample Projects
InstallShield 2020
A number of example project (.ism) files have been included with the InstallShield installation. These projects are stored in
the Samples folder. The default location is:
C:\Program Files\InstallShield\2020\Samples
These projects show you how a certain aspect of an installation project—such as release flags—can be implemented.
Project Assistant
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
InstallShield provides a Project Assistant to help you quickly and easily build a basic installation project. The Project
Assistant provides a framework of installation project tasks to guide you through the project creation process and provides
pertinent information along the way.
Information that you enter in the Project Assistant is saved directly to the underlying project file. Therefore, you can switch
to the Installation Designer (described below) and view or modify your information using the full power of the InstallShield
Installation Development Environment (IDE). In this way, you can use the Project Assistant to create the foundation for a
more advanced installation where you use the Installation Designer, as needed, to customize your installation.
The Installation Designer and the Project Assistant run simultaneously. Any changes that you make in one are reflected
instantly in the other. For example, if you remove a feature while using the Installation Designer tab, that feature is no
longer present in your installation project and does not appear in the Project Assistant.
See Also
Using the Project Assistant
Showing or Hiding the Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
When you create a new installation project, the Project Assistant is automatically displayed. The home page has an
installation design diagram to help you visualize the steps that are involved in creating an installation. You can work within
the Project Assistant to create your project or click the Installation Designer tab to further define a basic installation
project.
See Also
Project Assistant
Using the More Options, Other Places, and Help Links Sections in the Project
Assistant
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The left column on each Project Assistant page contains one or more lists of links to help you in creating your installation
and finding information:
• More Options—Provides additional configuration options relating to the specific area on the Project Assistant page.
These are less common options that complete the functionality of the Project Assistant.
• Other Places—The view in the Installation Designer that corresponds to the current Project Assistant page. Clicking
the link launches the full Installation Designer and activates that view.
• Help Links—This list provides links to help topics pertinent to the current Project Assistant page.
See Also
Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
Task To navigate from one page of the Project Assistant to another, do one of the following:
• To navigate directly to a specific page, click the appropriate icon in the navigation bar at the bottom of the page.
• Press CTRL+TAB to move to the next page and CTRL+SHIFT+TAB to move to the previous page.
• To move back to the Home page and view the installation design diagram, click the Home button on the navigation
bar.
See Also
Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Installation Designer tab displays the views in the InstallShield Installation Development Environment (IDE). You can
use this tab to add more complex and powerful elements to your installation project than you can with the Project
Assistant. To open a view in the Installation Designer, click the Installation Designer tab.
Note • The Installation Designer and the Project Assistant run simultaneously. Any changes that you make in one are
reflected instantly in the other.
See Also
Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Project Assistant provides a simplified view of installation project tasks. You can perform all of the same tasks—and
also further customize your project—through the Installation Designer.
If you prefer to create your InstallShield project entirely from within the Installation Designer, you can hide the Project
Assistant so that its tab is not displayed in the InstallShield interface. Similarly, if the Project Assistant is hidden, you can
choose to display it.
When the Project Assistant command has a check mark next to it, the tab for the Project Assistant is shown in the
InstallShield interface. When the check mark is not displayed, the Project Assistant is hidden.
If the Project Assistant command does not have a check mark, the Installation Designer becomes the default tab whenever
you create a new project.
See Also
Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Application Information page is where you specify general information about the application your project will install,
including the application’s name and version, your company’s name and Web address, and the application icon.
See Also
Application Lifecycle
Add or Remove Programs in the Control Panel
Company Name and Product Name in Your Installation
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Add or Remove Programs in the Control Panel provides a list of the applications that are installed on a computer
system. You can view information about particular programs and add, modify, or remove programs from Add or Remove
Programs.
The information you provide in the Application Information page of the Project Assistant is used to populate information
for your application’s Add or Remove Programs information when your application is installed.
See Also
General Information View
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
Your company name and product name are used in several places in your installation project.
See Also
General Information View
Setting a Destination Folder for the Component’s Files
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Installation Requirements page enables you to easily set installation requirements for the target system. For example,
if your application requires a specific operating system in order to run properly, you can indicate that in the first section of
this page.
See Also
Specifying Operating System in the Project Assistant
Creating Custom Installation Requirements
Modifying the Run-Time Message for Software Requirements
When Does the Installation Check for Requirements?
Project • The ability to specify operating in the Project Assistant is available in the following project types:
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
When you specify operating on the Installation Requirements page of the Project Assistant, InstallShield creates launch
conditions. These conditions are added to the LaunchCondition table of your .msi file; you can view and edit this table in
the Direct Editor.
For example, if you select only the check box for the latest Windows operating system, InstallShield creates a launch
condition to exclude the operating systems that you did not select on the Installation Requirements page. With this type of
launch condition, future versions of Windows operating systems are supported automatically because they are not
excluded in the launch condition.
See Also
Creating Custom Installation Requirements
When Does the Installation Check for Requirements?
Settings for Platforms and Platform Suites
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
To ensure that the required software or operating system is present on the target system, the installation checks for these
requirements in the beginning of the installation before any files are transferred.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
If your installation has software requirements and the target system does not have the selected software, a run-time
message is displayed during the installation. You can modify the message that is displayed.
3. Select the software that your application requires. The default run-time message is displayed to the right.
See Also
Installation Requirements Page
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
You can create customized installation requirements in the Installation Designer by using the product’s Install Condition
setting. For this setting, you can create conditions that the Windows Installer must evaluate before launching the
installation. For more information, see Setting Product Conditions.
You can also use the System Search Wizard to search for a particular file, folder, registry key, or .ini value on the target
system. The System Search Wizard enables you to create a condition with the search value.
See Also
Conditional Statement Syntax
Specifying Operating System in the Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Installation Architecture page lets you specify the features you want your installation program to display to the end
user. A feature is the smallest separately installable piece of your product from the end user’s standpoint. Individual
features are visible to end users when they select a Custom setup type during installation.
Note • Features can contain subfeatures, subsubfeatures, and so forth, to as many levels as your installation program
requires.
See Also
Creating Installations with Multiple Features
Determining Whether to Create a Multiple-Feature Installation
Default Features
Defining Feature Hierarchy
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
3. To add a main feature, click the Installation Architecture explorer. To add a subfeature, click the feature that you
want to be the parent feature, and then click New. The Project Assistant creates the new feature.
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
Features are the building blocks of an installation, from the end user’s perspective. Because of this, features should
represent distinct and discrete pieces of functionality within your installation.
If your application has different blocks of functionality, you should create a multiple-feature installation. For example, if
your installation contains your application (.exe file) and a help library (.hlp file), your installation project should contain at
least two features—one for each piece of functionality.
To learn more about creating a multiple-feature installation within the Project Assistant, see Creating Installations with
Multiple Features.
See Also
Creating Features
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
You can create an installation with multiple features using the Project Assistant or in the Installation Designer (IDE).
3. Click the Installation Architecture explorer and then click New. The Project Assistant creates a new feature.
4. Press F2 or right-click the feature and select Rename to provide a name for the new feature.
5. To add another feature at the same level, click the Installation Architecture explorer and then click New. To create a
subfeature, click the feature that you want to be the parent feature, and then click New. The Project Assistant creates
the new feature.
To learn about working with features in the Installation Designer, see Creating Features.
See Also
Determining Whether to Create a Multiple-Feature Installation
Features View
Default Features
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The default feature concept exists only in the Project Assistant. All resources (for example, files or registry data) that are
added to an installation project need to be associated with a feature. If a resource is not associated with a feature, it is not
installed to the target system at run time.
Using a default feature simplifies the authoring experience in the Project Assistant. You do not need to worry about
associating project resources with a feature to ensure that they are installed. When you add registry data, create new
shortcuts, or add files when All Application Data is selected, all of these resources are added to the default feature.
See Also
Features View
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
Top-level features are the highest level in the feature hierarchy. Top-level features might include the application you want
to install, a help library feature, and a sample projects feature.
Beneath the top-level features are subfeatures or child features. This is a feature that is dependent upon another feature
for installation purposes. If the parent (or top-level) feature is not installed to the target system, the child feature is not
installed.
See Also
Creating Features
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Application Files page lets you specify the files you want to associate with each of your features.
See Also
Adding Files to a Fixed Folder Location
Viewing Additional Predefined Folders
Adding Files to Features in the Project Assistant
Removing Files from Features in the Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
2. In the feature list at the top of the page, select the feature that should contain the file.
3. In Destination Computer explorer, select the folder to which you want to add the file.
6. Click Open to add the file to the selected feature. The message “The file you have added ... may have dependencies”
appears.
7. Click Yes if you want to have those dependencies automatically added to your installation project.
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
If you know exactly where you want the installation to install your project files on the target system, you can hard-code a
fixed folder destination.
3. For the new folder’s name, type the drive in which the destination is located—for example, C:.
4. Beneath the drive letter folder, further define the destination path by adding subfolders.
See Also
Destination Folders
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The Project Assistant’s Application Files page displays the more commonly used predefined folders. You can view and hide
predefined folders in this page.
3. In the list of predefined folders, select the folder you want to display.
Tip • To hide predefined folders, deselect them in the list of predefined folders.
See Also
Destination Folders
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Application Shortcuts page lets you specify shortcuts for your application’s files on the target system’s desktop or Start
menu. By default, this page displays a shortcut for each executable file that you have added to your project through the
Project Assistant. You can delete these, and add shortcuts to other files that you have included in your installation project.
See Also
File Extensions
Creating Shortcuts to Files That Are Not Included in the Installation
Modifying a Default Shortcut in the Project Assistant
Associating a Shortcut’s Target with a File Extension in the Project Assistant
File Extensions
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
File name–extension associations, or file associations, are registry settings that tell Windows what application to use to
open files of a certain type. For example, Windows typically opens text files (files with the .txt extension) with Windows
Notepad, and opens bitmap files (files with the .bmp extension) with Microsoft Paint.
A file extension allows someone to identify the type of file without accessing the file. A suffix (.abc) is appended to the file
name. The file extension is also useful in that another application can recognize whether the application can work with the
file (for example, open the file or modify it), based on the extension.
In InstallShield, you can register your own file extensions by configuring the settings in the Advanced Settings area of a
component in the Components view or the Setup Design view. Registering your file extension instructs the target
machine’s operating system to use your application to open files with your file extension when an end user clicks on a file.
See Also
Registering a File Extension
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
You can configure your installation to create a shortcut that points to a file that already exists on the target system. This file
does not have to be included in your installation project.
3. In the Shortcuts explorer, right-click the destination directory that you want to contain the shortcut and then click
New Shortcut to Preexisting File. The Browse for Shortcut Target dialog opens.
4. Browse to the target file’s location and enter the file’s name in the File Name setting.
5. Click OK.
See Also
Creating Shortcuts
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
You can associate a shortcut’s target with a file extension. When you do this, Windows will use the target file to launch files
with the specified file extension. For example, if you enter .txt, when the end user opens a .txt file, the target file of this
shortcut is launched to open the .txt file.
4. Type the file extension that you want to associate with this shortcut’s target—for example, txt. You can add multiple
extensions by separating them with a comma.
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The Application Registry page lets you specify any registry data that your application requires.
See Also
Updating the Registry
Associating Registry Data with Features
Using Variable Data Types in Registry Data
Application Paths
Configuring Registry Data in the Project Assistant
Modifying Registry Data Values in the Project Assistant
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The registry is a database for your computer’s configuration information. Information included in a computer’s registry
includes user profiles, hardware and software installed on the computer, and property settings.
The developer can provide a .reg file that you add to your installation. InstallShield allows you to import .reg files into your
installation project.
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
3. Right-click the registry item to which you want to add the data, select New, and point to Key.
5. Right-click the key, select New, and point to the appropriate command. You can pick Default Value, String Value,
Binary Value, DWORD Value, Multi-String Value, or Expandable String Value, depending on the type of data you want to
register.
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
If you double-clicked a multi-line string, the Multi-Line String Value dialog box opens. If you double-clicked any other
type of registry data, the Edit Data dialog box opens.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
All the registry data that you add in the Project Assistant’s Application Registry page is added to your project’s default
feature. You can associate your registry data with another feature in the Installation Designer.
Task To use the Installation Designer to associate registry data with a feature other than the default feature:
2. In the View Filter list, select the feature with which you want to associate the registry data.
3. Create or drag and drop the registry data in the appropriate registry location.
See Also
Updating the Registry
Filtering Registry Entries by Component or Feature
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
InstallShield allows you to use variable data types or properties when creating registry data for your installation project.
Task To use INSTALLDIR as a variable in the registry (Windows Installer-based projects only):
2. Select Yes to indicate that you want to configure the registry data that your application will install.
5. Right-click the Installation Location key, point to New, and select String Value.
7. Double-click the My Installation Location key. The Edit Data dialog box opens.
At run time, the value of [INSTALLDIR] is replaced with the installation directory.
Application Paths
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The application path registry key contains data that Windows uses as a private search path for the specified application’s
.dll files. If you install an application’s .dll files into a directory not found in the PATH environment variable (and not into
the application’s directory), you should set the appropriate application path to include the .dll file directory during
installation. Application path information is stored in the registry under
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AppName.exe.
See Also
Specifying an Application Path for a Component
• Basic MSI
• InstallScript
• MSI Database
The Installation Interview page lets you specify the dialogs you want the end user to see when your installation program
runs. Based on your answers to the questions on this page, the Project Assistant adds the corresponding dialog to your
installation project.
See Also
Specifying Dialogs for Your Installation in the Project Assistant
Allowing End Users to Modify the Installation Location
License Agreements
Creating Selectively Installable Installations
Adding Project Assistant Dialog Support to Projects Upgraded from InstallShield Professional
• Basic MSI
• InstallScript
• MSI Database
Note that the option for launching your application when the installation completes is not available in InstallScript projects.
The questions that are displayed on the Installation Interview page of the Project Assistant help you specify which dialogs
you want the end user to see when your installation program runs.
1. Do you want to display a License Agreement Dialog?—Select Yes to browse to your license agreement file.
2. Do you want to prompt users to enter their company name and user name?—Select Yes to display a dialog
requesting this information.
3. Do you want your users to be prompted to modify the installation location of your application?—Select Yes to
present a dialog that allows end users to change the installation location. See Allowing End Users to Modify the
Installation Location for more information.
4. Do you want users to be able to selectively install only certain parts of your application?—Select Yes to allow end
users to select which parts of the application they want to install. See Creating Selectively Installable Installations for
more information.
5. Do you want to give users the option to launch your application when the installation completes?—Select Yes
and browse to your application file. When this option is set to Yes, the final dialog in the installation presents a check
box that allows end users to immediately launch your application upon clicking the Finish button.
Tip • To add a custom graphic to your installation dialogs, click the link in the More Options section of this page to launch the
Dialog Images dialog box.
If you want to provide end users with control over where your software is installed on their system, you can allow them to
modify the installation location.
In a Windows Installer-based installation, the Windows Installer property INSTALLDIR serves as the default installation
directory. When you allow users to modify the installation location, the CustomSetup dialog is presented during the
installation.
In an InstallScript project, TARGETDIR serves as the default installation directory. When you allow users to modify the
installation location, the SdSetupType2 dialog is presented during the installation.
License Agreements
InstallShield 2020
• Basic MSI
• InstallScript
• MSI Database
In order to install your product, you may require that your end users agree to certain legal requirements. For example,
most software vendors do not allow end users to copy or distribute their software to others.
Your installation can present an End User License Agreement (EULA) in the License Agreement dialog at run time. The EULA
is a legal contract between you and the end user, with regard to the use of your product.
The License Agreement dialog displays your license agreement text and contains a radio button group (Yes or No). If the
end user does not agree to accept the EULA, your software is not installed and the installation ends.
Task To add a License Agreement dialog to your project in the Project Assistant:
2. Select Yes to indicate that you want to add a License Agreement dialog.
3. Type the path to your license agreement file or browse to the file.
Project • For Basic MSI and MSI Database projects, the file must be a rich text file (.rtf).
For InstallScript projects, the file type depends on which license dialog that you are using and which parameters you are
passing to it. The SdLicenseEx and SdLicense2Ex functions have support for .rtf files and text files (.txt).
You can allow your end users to select which portions of your installation they want to install to their systems. This is a
custom installation, which provides a list of the available features within your installation. The end user can select the
features to install in a dialog presented at run time.
For example, your installation might contain your application’s executable (.exe) file, a documentation (.chm) file, and a
samples file. All of these files are contained in different features, which are provided in an option list to the end user. If the
end user needs only the application, they can select to install the executable file, but not the documentation or samples
file.
See Also
Configuring a Feature’s Install Level Setting
• Basic MSI
• InstallScript
• InstallScript MSI
The Installation Localization page lets you specify the languages your installation supports, and specify string values and
associated identifiers, which you can use in your end user interface to make your installation more easily localizable in
other languages.
Note • You can specify the set of string data that you want to edit in the drop-down menu at the top of the page.
See Also
Localizing String Data from the Project Assistant
How Localized String Data Is Used in the Installation
• Basic MSI
• InstallScript
• InstallScript MSI
Much of the text in your installation project is stored as string entries. To make localizing your installation easier,
InstallShield provides the capability to export your strings for translation and import the translated strings back into your
project.
Task To export all of the string data in your project for translation:
2. In the data list at the top of the page, select All String Data.
4. In the More Options area, click Export localizable strings. The File Name dialog box opens.
Task After the strings in your text file are translated, you can import the strings back into your project:
2. In the data list at the top of the page, select All String Data.
3. In the list of languages, click the language that matches the strings that you want to import.
4. In the More Options area, click Import localizable strings. The File Name dialog box opens.
5. Browse to your .txt file and click Open. The translated strings are imported back into your project.
See Also
Translating String Entries
There are two types of string data in an installation project—string data that is specific to your installation and string data
that is specific to your application.
The majority of the string data in an InstallShield project is used at run time when an end user runs the installation.
However, some of the string data is installed to the target system. For example, a localized shortcut is localized string data
that is installed to the end user’s system.
• Basic MSI
• InstallScript
• InstallScript MSI
Tip • The following information applies to releases that are built within InstallShield (without integration with Visual Studio).
For information on building an InstallShield release from within Visual Studio, see Building Releases in Microsoft Visual Studio.
The Build Installation page lets you specify what type of distribution you want to build and, optionally, the location to
which you want to copy the distribution files. It also enables you to digitally sign the package.
See Also
Building Your Installation from the Project Assistant
After Completing the Project Assistant: Next Steps
• Basic MSI
• InstallScript
• InstallScript MSI
Tip • The following information applies to releases that are built within InstallShield (without integration with Visual Studio).
For information on building an InstallShield release from within Visual Studio, see Building Releases in Microsoft Visual Studio.
Note • The Single MSI Package option should be selected for machines that already have Windows Installer installed
them since no attempt will be made to check and install the engine if it is not there.
3. If you want InstallShield to automatically copy your installation to another location after the build finishes, click the
Optional distribution settings link for each build option and specify the location.
If you want InstallShield to distribute your installation after the build finishes, click the Optional distribution settings
link for each build option and select the Distribute After Build check box.
4. To digitally sign your Setup.exe file to assure your end users that the code within your application has not been
modified or corrupted, click the Digitally Sign Setup hyperlink. The Digitally Sign Setup dialog box opens.
Configure the settings as needed.
The Output window opens, and the Build tab displays information about the progress of the build. The build is finished
when the Build tab displays the log file information.
Tip • The Signing tab in the Installation Designer lets you specify which portions of your installation should be digitally signed
at build time. InstallShield enables you to sign any and all of the following files in a release, depending on what type of project
you are using:
• Windows Installer package (.msi file or .msm file) for Basic MSI, InstallScript MSI, and Merge Module projects
• Setup.exe file for Basic MSI and InstallScript MSI projects
• Media header file for InstallScript projects
• Package (self-extracting single-executable file) for InstallScript projects
• Any files in your release, including your application files
To learn more, see Digitally Signing a Release and Its Files at Build Time.
Windows Logo • All executable files (including .exe, .dll, .ocx, .sys, .cpl, .drv, and .scr files) in an installation must be digitally
signed for the Windows logo program.
See Also
Digital Signing and Security
Digitally Sign Setup Dialog Box
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
After going through the Project Assistant pages and completing the fields, you have an installation project framework that
you can use as a functional installation or you can further customize to fit your needs.
Within the Installation Designer, you can see the View List, which is a list of all available views for the project type that you
are creating. To display the View List on the left side of the workspace, press F4.
The InstallShield interface is a graphical user interface with conventional Windows-based elements such as a menu bar, a
toolbar, and dialog boxes. This section includes topics that explain how to perform basic tasks using these elements and
how to customize the interface.
See Also
Showing or Hiding the Project Assistant
View Reference
1. Click the Installation Designer tab at the top of the InstallShield interface.
• On the View menu, click View List. The View List appears on the left side of the InstallShield interface.
See Also
View Reference
The first step in many InstallShield procedures is to open a particular view in the Installation Development Environment
(IDE).
1. Click the Installation Designer tab. The View List is displayed along the left side of the IDE. If the View List is not
displayed, see Displaying the View List.
2. In the View List, select the view you want to open. To see all available views, expand the View List folders.
A number of views in InstallShield have a group box area that lets you organize the rows in the view. The views that contain
this group box support multiple levels of grouping simply by dragging the column headers and dropping them onto the
group box (the area that says, “Drag a column header here to group that column”). InstallShield displays the rows in the
view hierarchically according to column arrangement in the group box. Examples of views that contain the group box are
the String Editor, Property Manager, the Redistributables, Prerequisites, and Path Variables views.
Note the following tips for working with the group box:
• To move a column header to the group box area, drag the column header and drop it onto the group box.
• To copy a column header onto the group box area, press CTRL while dragging the column header and dropping it onto
the group box. When you do this, the column header is displayed as a column header, and in the group box.
• When you are dropping group box headers onto the group box area, you can drop them onto other column headers.
This enables you to organize rows hierarchically.
• To remove a column header from the group box, drag it from the group box area and drop it onto the row of column
headers. When you are dragging it over the row of column headers, InstallShield displays arrows to indicate where in
the row the column header would be displayed if you dropped it.
• To sort the items in the grid by a particular column header, click the column header in the group box or in the row of
column headers.
The following examples demonstrate different ways for using the group box to organize content in views.
Figure 2-5: Sorting Rows by the Check Box Column and Then the Type Column
• Right-click a toolbar and select the toolbar that you want to be displayed or hidden.
• On the Tools menu, click Customize. The Customize dialog box opens. Select the check box for each toolbar that you
want to be displayed. Clear the check box for each toolbar that you want to be hidden.
See Also
Adding Buttons and Menus to a Toolbar
Removing Buttons and Menus from a Toolbar
Showing or Hiding Toolbars
Creating Custom Toolbars
Toolbars
2. On the Tools menu, click Customize. The Customize dialog box opens.
4. In the Categories box, click the category for the button or menu that you want to add.
5. Drag the button or menu from the Commands box to the appropriate toolbar.
Tip • To create your own custom toolbar, drag the button or menu to the empty gray area near the toolbars.
See Also
Removing Buttons and Menus from a Toolbar
Showing or Hiding Toolbars
Creating Custom Toolbars
Toolbars
2. On the Tools menu, click Customize. The Customize dialog box opens.
3. Right-click the button or menu that you want to remove, and then click Delete.
See Also
Adding Buttons and Menus to a Toolbar
Showing or Hiding Toolbars
Creating Custom Toolbars
Toolbars
1. On the Tools menu, click Customize. The Customize dialog box opens.
3. Click the New button. The New Toolbar dialog box opens.
4. In the Toolbar name box, enter a descriptive name for the toolbar, and click OK.
See Also
Showing or Hiding Toolbars
Adding Buttons and Menus to a Toolbar
Removing Buttons and Menus from a Toolbar
Toolbars
The Output window or its individual tabs can be docked to any side of the workspace in InstallShield, or they can be
dragged to free-floating positions.
If you drag the Output window or one of its tabs to the edge of the InstallShield interface, it becomes a docked window. If
you drag the Output window or one of its tabs away from any of the edges of the InstallShield interface, it becomes
undocked.
Drag the title bar of the Output window to the new location. Resize the Output window as needed.
Drag the title bar of the Output window to the left, right, top, or bottom edge of the InstallShield interface.
Drag the tab to the new location. Resize the Output window as needed.
Drag the tab to the left, right, top, or bottom edge of the InstallShield interface.
See Also
Output Window
Several views in InstallShield have a script editor pane that you can use to write code for your projects. Examples of views
that contain the script editor pane are:
• InstallScript view—When you select a script file in this view, InstallShield displays a script editor pane where you can
write InstallScript code.
• SQL Scripts view—When you select a SQL script in this view, the Script tab shows a script editor pane that lets you
edit your SQL file.
• Custom Actions and Sequences view—When you select a VBScript or JScript custom action in this view, the Script
tab shows a script editor pane that lets you edit your VBScript or JScript file.
This section of the documentation describes how to use the script editors in InstallShield.
See Also
InstallScript View
SQL Scripts View
Custom Actions and Sequences View (or Custom Actions View)
Bookmarks are markers that let you jump to specific lines within your script with a minimum number of keystrokes.
Bookmarks are visible in the left margin of the script editor. Note that InstallShield does not save bookmarks when you
close your project.
• Place the insertion point in the line of your script that you want to contain a bookmark.
• Place the insertion point in the line of your script that contains the bookmark that you want to
2. Press ALT+K.
Task To move the insertion point to the next line that contains a bookmark:
Press CTRL+K.
Task To move the insertion point to the previous line that contains a bookmark:
Press CTRL+SHIFT+K.
See Also
Keyboard Shortcuts for the Script Editors
InstallShield lets you specify whether you want to be able to use automatic completion when you are typing in the script
editor in various views (for example, the InstallScript view and the SQL Scripts view). If auto completion is enabled,
InstallShield displays a pop-up list of alphabetically ordered functions, keywords, constants, and string identifiers that
begin with the letters that you are typing in the script editor. Instead of manually typing the entire word, you can select it in
the pop-up list, and InstallShield adds it to your script.
Auto completion can increase your efficiency because it can reduce the time that you spend typing code. It can also help
you avoid typographical errors in your code.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same auto completion settings are used for all script editors. If you change the settings in the SQL Scripts view, the settings
are also changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify whether auto completion should be available in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
• Yes—InstallShield displays a pop-up list of available functions, keywords, constants, and string identifiers that
begin with the letters that you are typing code in the script editors. This is the default option.
• No—InstallShield does not display a pop-up list when you are typing code in the script editors.
• Yes—InstallShield adds local variables that are defined in InstallScript to the pop-up list of available functions
and other script words that begin with the letters that you are typing code in the InstallScript editor. This is the
default option.
• No—InstallShield does not include local variables in the pop-up list when you are typing code in the InstallScript
editor.
Note that if you select No, the Functions, Properties, and Methods folders in the center pane of the InstallScript
view do not list any functions, properties, or methods from your script files.
If Yes is selected for this setting and you notice performance issues when you are typing code in the InstallScript
view, you might want to change this setting to No.
Note • The Include local variables setting applies to the script editor in the InstallScript view; it does not have any effect
on the script editors in other views, such as the SQL Scripts view. This setting is ignored if you select No for the Auto
completion setting.
For details about how auto completion works, see Using Auto Completion when Writing Code in the Script Editors.
See Also
Script Editor Properties Dialog Box
If auto completion is enabled for the script editors in InstallShield, InstallShield displays a pop-up list of alphabetically
ordered functions, keywords, constants, and string identifiers that begin with the letters that you are typing in the script
editor. The pop-up list contains language-appropriate options, depending on which view you are using. For example, the
script editor in the InstallScript view supports auto completion of InstallScript code. The VBScript script editor in the
Custom Actions and Sequences view supports auto completion of VBScript.
In addition, if auto completion for local variables is enabled, the pop-up list in the script editor of the InstallScript view also
contains local variables.
To learn how to enable auto completion, see Enabling or Disabling Auto Completion in the Script Editors.
Task To use auto completion for a function name, a keyword, a constant, or string identifier:
1. Open the view that contains the appropriate script editor, and select the script that you want to edit.
2. Place the insertion point where you want to enter code in your script.
• Type the first characters of the function name, keyword, or other script word.
Depending on the view that you are using and the language that is entered in the script editor in that view,
InstallShield displays a pop-up list of alphabetically ordered functions, keywords, and other script words that
begin with the letters that you are typing in the script editor. The first word that matches the characters that you
typed is selected in the list. If no word matches the characters that you typed, no word in the list is selected.
• If you are using the script editor in the InstallScript view and you want to use auto completion for a list of
available string identifiers, enter the string constant operator (@). InstallShield displays a pop-up list of
alphabetically ordered string identifiers.
4. If the selected word is not the one you want (or no word is selected), select another word in one of the following ways:
• To navigate through the list, use the pop-up list’s scroll bar; then, click the desired word to select it.
• To change the selection to the previous or next word, use the UP ARROW and DOWN ARROW keys.
5. To paste the selected word into your script, double-click the word, or press the ENTER key or the TAB key.
To close the list without pasting the selected word, press ESC or click outside the pop-up list.
See Also
Viewing Function Call Tips for an InstallScript Function in the Script Editor
InstallShield lets you specify whether you want InstallShield to display an InstallScript function call tip—a type of tooltip—
when you are entering a function call in your script in the InstallScript view. A function call tip shows a built-in function’s
parameter information. It also shows a description of the built-in function, as well as a description of the parameter that
you are entering.
Function call tips let you see language information within the script editor, without requiring you to switch to a different
window.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same auto completion settings are used for all script editors. If you change the settings in the SQL Scripts view, the settings
are also changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify whether function call tips should be shown in the script editor of the InstallScript view:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
2. In the Show function call tips setting, select the appropriate option:
• Yes—InstallShield displays function call tips when you are entering function calls in your script. This is the default
option.
• No—InstallShield does not display function call tips when you are entering function calls in your script.
InstallShield enables or disables function call tips in the InstallScript editor as needed.
For details about how function call tips work, see Viewing Function Call Tips for an InstallScript Function in the Script
Editor.
See Also
Script Editor Properties Dialog Box
Viewing Function Call Tips for an InstallScript Function in the Script Editor
InstallShield 2020
If function call tips are enabled, InstallShield shows InstallScript function call tips—a type of tooltip—when you are
entering function calls in your script in the InstallScript view. A function call tip shows a built-in function’s parameter
information. It also shows a description of the built-in function, as well as a description of the parameter that you are
entering.
To learn how to enable function call tips, see Enabling or Disabling InstallScript Function Call Tips in the Script Editor.
Task To view a description of a function, as well as parameter details about that function:
1. Enter a function name in your script by typing it or using automatic function name completion, as described earlier.
2. Type a left parenthesis—(—after the function name. InstallShield displays a function call tip that shows a complete
call to the function, including all of its parameters. The tip also includes a description of the function, as well as a
description of the next parameter that you need to enter. The first parameter appears in blue, by default.
3. Type the parameters as indicated by the call tip. Each time that you type a comma, the next parameter in the function
syntax appears in blue, by default.
4. To close the call tip, type the right parenthesis—). Or, press ESC or click in the script editor pane outside the call tip.
Tip • To view additional details about a particular built-in function, constant, or other InstallScript word, place the insertion
point within that word, and then press F1. The InstallShield Help Library opens, enabling you to learn more about that
particular word.
See Also
Using Auto Completion when Writing Code in the Script Editors
InstallShield lets you specify whether you want the script editors in various views in InstallShield to display script files with
color attributes that identify keywords, comments, strings, and other script elements. Each category is displayed in a
different color so that you can easily identify them.
This functionality—called syntax highlighting—helps to improve the readability and context of code. In addition, it can help
you avoid errors that are caused, for example, when you attempt to use a reserved word as a user-defined identifier. It can
also help you locate other errors in your script, such as misspelled keywords, missing quotation marks at the end of a
string, and missing comment characters.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same syntax highlighting and color settings are used for all script editors. If you change the settings in the SQL Scripts
view, the settings are also changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify whether syntax highlighting should be enabled in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
• Yes—InstallShield uses the syntax highlighting that is defined in the Colors area of the Script Editor Properties
dialog box in all of the script editors. This is the default option.
• No—InstallShield does not use any syntax highlighting in any of the script editors.
InstallShield lets you define the foreground color and background color that is used for each script word category. To learn
how, see Changing Colors for Syntax Highlighting in the Script Editors.
See Also
Script Editor Properties Dialog Box
InstallShield lets you change the colors that are used to differentiate among different script elements in the script editor in
various views (for example, the InstallScript view and the SQL Scripts view). You can change the foreground color (the color
that is used for the text), as well as the background color, for script elements such as comments, functions, and strings.
This functionality—called syntax highlighting—helps to improve the readability and context of code. In addition, it can help
you avoid errors caused, for example, when you attempt to use a reserved word as a user-defined identifier. It can also help
you locate other errors in your script, such as misspelled keywords, missing quotation marks at the end of a string, and
missing comment characters.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same syntax coloring settings are used for all script editors. If you change the settings in the SQL Scripts view, the settings
are also changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To change the syntax highlighting that is used in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
2. In the Colors area, click the setting for the script element that you want to configure. InstallShield displays foreground
and background buttons in the setting.
• Click the foreground button or the background button. The Colors dialog box opens, enabling you to select the
color that you want to use.
• Enter the RGB values for the color that you want to use for the foreground or the background. For example, the
entry 0; 0; 0 / 255; 255; 255 indicates that InstallShield should use black (which has an RGB value of 0; 0; 0)
for the foreground and white (255; 255; 255) for the background. If you do not want to set a color for a particular
area, you can use dashes (-;-;-).
If script highlighting is enabled, InstallShield changes the colors that are used to display text in the script editor as needed.
To learn more, see Enabling or Disabling Syntax Highlighting in the Script Editors.
• Misspelled reserved words are not recognized by the editor and are not displayed with syntax coloring. If you see in
your script a “reserved word” that is not displayed with indicating attributes, it is possible that it is misspelled.
• Coloring of string literals includes both the opening and closing quotation marks. If the closing quotation mark is
missing, string coloring will extend to the end of the line; in that case, text that should have followed the quotation will
be displayed as though it were part of the string literal.
• Syntax coloring makes it easy to identify comments that open with /* and are not closed properly with */. In that
case, all of the text that follows the comment is displayed with the comment color attribute.
• In lines that include comments starting with two slashes (//), all text from the comment character to the end of the
line is recognized as a comment.
• In the script editor that is displayed in the InstallScript view, InstallShield does not use syntax coloring for files that
have an extension other than .rul or .h (for example, log or report files).
See Also
Script Editor Properties Dialog Box
Changing the Font that Is Used to Display Text in the Script Editors
InstallShield 2020
InstallShield lets you change the font that is used in the script editor in various views (for example, the InstallScript view
and the SQL Scripts view).
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same font is used for all script editors. If you change the font in the SQL Scripts view, the font is also changed in the
InstallScript view the next time that the InstallScript is reloaded in that view.
Task To change the font, font style, or font size that is used to display text in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
2. In the General area, click the Font setting, and then click the ellipsis button (...) in this setting. The Font dialog box
opens.
InstallShield changes the font that is used to display text in the script editor as needed.
See Also
Script Editor Properties Dialog Box
InstallShield lets you specify whether you want the left margin of the script editors in InstallShield to contain line numbers.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same line numbering setting is used for all script editors. If you change the setting in the SQL Scripts view, the settings are
also changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify whether line numbering should be enabled in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
• Yes—InstallShield adds line numbers to the left margin of all of the script editors.
• No—InstallShield does not show any line numbers in the left margin of any of the script editors. This is the default
option.
See Also
Going to a Line Number in a Script that Is Displayed in a Script Editor
Script Editor Properties Dialog Box
Task To move the insertion point to a specific line number in your script:
1. On the Edit menu, click Go To. The Go To Line dialog box opens.
2. In the Line box, type the number of the line where you want to move the insertion point.
3. Click OK.
See Also
Showing or Hiding Line Numbering in the Script Editors
Script Editor Properties Dialog Box
InstallShield lets you specify whether you want to use automatic indentation in the script editors when you are writing
code. Auto indentation may help improve readability.
If automatic indentation is enabled, InstallShield indents a new line according to the indentation that is used in the
previous line. When you press ENTER in the script editor pane, the insertion point appears on a new line, positioned
directly beneath the first character of the previous line. To stop indenting a new line, press BACKSPACE; doing so removes
the indentation.
If automatic indention is disabled, a new line is not indented—that is, the insertion point is placed in the first column of the
new line.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same automatic indentation setting is used for all script editors. If you change the setting in the SQL Scripts view, the
settings are also changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify whether automatic indentation should be enabled in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
• Yes—InstallShield adds support for automatic indentation in all of the script editors. This is the default option.
• No—InstallShield does not use automatic indentation in any of the script editors.
See Also
Script Editor Properties Dialog Box
InstallShield lets you specify the width of tabs in the script editor in various views (for example, the InstallScript view and
the SQL Scripts view).
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same tab setting is used for all script editors. If you change the setting in the SQL Scripts view, the settings are also
changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify the width that InstallShield should use for tabs that are entered in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
2. In the Tab width setting, enter the width—as a multiple of the character space size—that you want for tabs in your
scripts. The default value is 4.
See Also
Script Editor Properties Dialog Box
InstallShield lets you specify whether you want the script editors in various views in InstallShield to include support for
syntax folding. When syntax folding is enabled, InstallShield adds a plus sign (+) or a minus sign (–) in the margin next to
each line of code that starts an expandable or collapsible block of script. You can click a plus sign to expand hidden code, or
a minus sign to hide code.
Syntax folding can help you minimize the clutter of large scripts and focus on the code that is relevant to the work that you
are currently doing. It can also help you see the overall structure of a script.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same syntax folding setting is used for all script editors. If you change the setting in the SQL Scripts view, the setting is also
changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify whether syntax folding should be enabled in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
• No—InstallShield does not use any syntax folding in any of the script editors. This is the default option.
See Also
Script Editor Properties Dialog Box
InstallShield lets you specify whether you want the script editors in various views in InstallShield to display a symbol or
other mark in place of each instance of whitespace in your script. For example, if you select Yes, InstallShield displays each
space character in the script as a middle dot (·) and each tab character as an arrow. InstallShield also identifies line breaks
when whitespace is enabled.
Tip • Note that the script editor properties are global per-user settings that affect all InstallShield script editors. For example,
the same whitespace setting is used for all script editors. If you change the setting in the SQL Scripts view, the setting is also
changed in the InstallScript view the next time that the InstallScript is reloaded in that view.
Task To specify whether whitespace should be shown or hidden in the script editors:
1. Right-click in the script editor pane and click Properties. The Script Editor Properties dialog box opens.
• Yes—InstallShield shows whitespace characters and symbols in all of the script editors.
• No—InstallShield does not show whitespace characters and symbols in any of the script editors. This is the
default option.
InstallShield shows or hides whitespace characters and symbols in the script editors as needed.
See Also
Script Editor Properties Dialog Box
The script editors in InstallShield support drag-and-drop text editing, enabling you to move or copy selected text from one
location in your code to another.
Moving Text
4. When you see a small rectangle appear beneath the mouse pointer, move the pointer to the location in your script to
which you want to move the selected text. Continue to hold down the left mouse button while you move the pointer.
5. When the pointer is at the location in which you want to move the text, release the left mouse button.
Copying Text
Task To copy selected text using the drag and drop method:
3. Press CTRL, and then press and hold down the left mouse button.
4. When you see a small rectangle and a plus sign beneath the mouse pointer, move the pointer to the location in your
script to which you want to copy the selected text. Continue to hold down CTRL and the left mouse button while you
move the pointer.
5. When the pointer is at the location in which you want to move the text, release the left mouse button.
InstallShield lets you print a script that is displayed in the script editors in various views (for example, the InstallScript view
and the SQL Scripts view).
Task To print the script that is displayed in the active script editor pane:
1. On the File menu, click Print. Note that this command is enabled only if the insertion point is in the script editor pane.
The Print dialog box opens.
3. Click OK.
The script editors in InstallShield include support for the following keyboard shortcuts.
CTRL+INSERT
SHIFT+DELETE
CTRL+H Displays the Replace dialog box, which lets you search for text or other characters and
replace them.
TAB Indents the selected text to the right one tab stop.
SHIFT+INSERT
ALT+BACKSPACE
CTRL+M Maximize the width of the script editor or restore it to its previous width.
CTRL+I Opens the Function Wizard, which helps you add a function call at the insertion point in
the script that is displayed in the InstallScript view.
ALT+K Switches between adding and removing a bookmark in the line of script that currently
contains the insertion point.
CTRL+K Moves to the line in the script that contains the next bookmark.
CTRL+SHIFT+K Moves to the line in the script that contains the previous bookmark.
See Also
Working with the Script Editor Pane in Various Views
One of the InstallShield program files is a file called Settings.xml. This file exposes some advanced machine-wide settings
for InstallShield. When you install InstallShield, Settings.xml is installed to one of the following locations, depending on
which language version of InstallShield you are using:
The Settings.xml file for the Standalone build is installed in one of the following locations:
In most cases, you should not modify the Settings.xml file. However, in some cases, you may need to make changes in
this file. This section of the documentation describes some scenarios that would require Settings.xml changes:
• Configuring the Compression Level for Files that Are Streamed into Setup.exe and ISSetup.dll
• Modifying the List of Portable Executable Files for the Standalone Build
Caution • The Settings.xml file contains critical data; if this file is edited incorrectly, it can cause InstallShield to fail to work.
Use extreme care when editing this file.
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
When you specify digital signature information for a release, InstallShield uses VeriSign’s server (http://
timestamp.verisign.com/scripts/timstamp.dll) as the default timestamp server during builds. InstallShield includes a
machine-wide setting that lets you replace that default server with a different timestamp server. The setting also lets you
disable timestamping.
InstallShield 2019 R2 and later supports adding a delay between the successive digital signing, this requires only if the
timestamp server fails handle the successive signing requests.
Required to specify the <DelayBetweenSigning default="1500"/> node in the settings.xml, under <DevStudio/Build> node
in Settings.xml in milliseconds.
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
<DigitalSignature Timestamp="http://timestamp.verisign.com/scripts/timstamp.dll"/>
6. To override the timestamp server with a different one, set the value of the Timestamp attribute to the appropriate
URL.
<DigitalSignature Timestamp=""/>
Note • Disabling timestamping may affect how long your digital signature is considered to be valid.
8. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. You should
be able to expand and contract the major elements of the file; if you cannot, check the code for errors.
In InstallShield 2019 and later, the timestamp server is set to a SHA-2 server to:
• <DigitalSignature Timestamp="http://sha256timestamp.ws.symantec.com/sha256/timestamp"/>
Whenever you build a release that includes digital signature information, InstallShield sets the timestamp according to the
setting that you configured.
Tip • If you use the Standalone Build to build a release, update the Settings.xml file that is installed with the Standalone
Build. Settings.xml is installed in one of the following locations, depending on which language version of InstallShield you
are using:
See Also
Digital Signing and Security
• Basic MSI
• InstallScript MSI
This information does not apply to custom compression, where only the files that are associated with one or more features are
compressed into .cab files.
InstallShield includes a machine-wide setting that lets you specify the compression level that you want to use for files that
are streamed into Setup.exe files and ISSetup.dll files at build time. Following are examples of files that may be
streamed into the Setup.exe files and ISSetup.dll files:
• All of your product’s files (if the release is one in which all of the files are compressed into the Setup.exe setup
launcher)
• The Windows Installer installation if it has a location of Extract Engine From Setup.exe
InstallShield also lets you specify particular files (with or without wild-card characters) that should not be compressed
when they are streamed into Setup.exe files or ISSetup.dll files.
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
6. To prevent certain files or file types from being compressed when they are streamed into Setup.exe files or
ISSetup.dll files, set the value of the exclude attribute to the names of those files. Note the following guidelines:
• To specify more than one file, separate each file name with a comma.
For example, to specify that .cab files, .exe files, and a file called test.txt should not be compressed, set the value of
the exclude attribute to as follows:
The default value is *.CAB, since .cab files are a compressed type of file.
• If you want to use a compression level that offers a balance between the size of the compressed file and the time
that is required to extract the compressed files at run time, set the value of the compressionlevel attribute to -1.
This is the default value.
• To specify a particular compression level, set the value of the compressionlevel attribute to a number from 0 to 9,
where 0 indicates no compression and 9 indicates maximum compression.
In general, when you specify a number from 0 to 9, the higher the number that you specify, the smaller the
resulting compressed file is, and the longer it may take to extract the files at run time.
9. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. You should
be able to expand and contract the major elements of the file; if you cannot, check the code for errors.
Whenever you build a compressed release for one of the applicable project types, InstallShield streams files into Setup.exe
files and ISSetup.dll files according to the settings that you configured.
Tip • If you use the Standalone Build to build a release, update the Settings.xml file that is installed with the Standalone
Build. Settings.xml is installed in one of the following locations, depending on which language version of InstallShield you
are using:
See Also
Overview of ISSetup.dll
Configuring Advanced Settings for InstallShield
• Basic MSI
• InstallScript MSI
In addition, it is applicable only if you are building a compressed network image release in which all of the files are embedded
in the single-file .msi package or the Setup.exe setup launcher.
This information does not apply to custom compression, where only the files that are associated with one or more features are
compressed into .cab files.
The .cab file type has some limitations. For example, the maximum size of a single .cab file is 2 GB. In addition, some users
have had trouble signing large .cab files and verifying the digital signature of large signed .cab files.
To work around these limitations, InstallShield enables you to specify on a machine-wide basis the maximum size for each
.cab file that is built for a compressed network image release. When InstallShield is creating the .cab files for your release
and it reaches the .cab file threshold that you configured, it splits the data into two or more .cab files, creating multi-part
.cab files. Note that if you do not want InstallShield to create multi-part .cab files, you can configure InstallShield to store
the data in a single .cab file.
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
Task To specify whether InstallShield should create multi-part .cab files and—if appropriate—specify the maximum .cab file
size:
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
<CompressedNetworkCABSize default="600"/>
• To specify the maximum size for .cab files, type the size in MB as the value of the default attribute. In the
aforementioned example, the maximum size is 600. The value should be 2048 or less, since the maximum size of a
.cab file is 2 GB (2048 MB).
• If you do not want InstallShield to create multi-part .cab files, set the value of the default attribute to -1.
8. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. You should
be able to expand and contract the major elements of the file; if you cannot, check the code for errors.
Whenever you build a compressed network image release for one of the applicable project types, InstallShield creates the
.cab files according to the requirement that you configured in the Settings.xml file. Depending on the value that you
specified in the Settings.xml file, the Media table of the .msi package lists one or more .cab files.
Tip • If you use the Standalone Build to build a release, update the Settings.xml file that is installed with the Standalone
Build. Settings.xml is installed in one of the following locations, depending on which language version of InstallShield you
are using:
See Also
Configuring Advanced Settings for InstallShield
• Basic MSI
• InstallScript MSI
The Virtual Media Memory type has some limitations. For example, the maximum size of Virtual Media Memory 512MB.
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
Task To specify whether InstallShield should specify the maximum Virtual Media Memory size:
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
<CompressedNetworkCABSize default="600"/>
• To specify the maximum size for .cab files, type the size in MB as the value of the default attribute. In the
aforementioned example, the maximum size is 600. The value should be 2048 or less, since the maximum size of a
.cab file is 2 GB (2048 MB).
• If you do not want InstallShield to create multi-part .cab files, set the value of the default attribute to -1.
8. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. You should
be able to expand and contract the major elements of the file; if you cannot, check the code for errors.
Whenever you build a compressed network image release for one of the applicable project types, InstallShield creates the
.cab files according to the requirement that you configured in the Settings.xml file. Depending on the value that you
specified in the Settings.xml file, the Media table of the .msi package lists one or more .cab files.
Tip • If you use the Standalone Build to build a release, update the Settings.xml file that is installed with the Standalone
Build. Settings.xml is installed in one of the following locations, depending on which language version of InstallShield you
are using:
See Also
Configuring Advanced Settings for InstallShield
The File Extensions tab on the Options dialog box in InstallShield lets you modify the file extensions that you would like
InstallShield to consider to be portable executable (PE) files. InstallShield uses this list to determine how it should create
components for dynamically linked files that adhere to the best practice component creation method.
If you are using the Standalone Build to build a release, the Options dialog box is not available. However, you can modify
one of the files that is installed in a subfolder of the InstallShield Standalone Build Program Files folder if you want to
modify the list of file extensions that the Standalone Build considers to be PE files. The following instructions explain how.
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
Task To modify the list of file extensions that the Standalone Build considers to be PE files:
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
<PEFileExtensions default="EXE|DLL|OCX|VXD|CHM|HLB|TLB|AX">
6. Modify the list of file extensions for the default attribute as needed. Note that each file extension is separated with a
vertical bar (|).
8. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. You should
be able to expand and contract the major elements of the file; if you cannot, check the code for errors.
The next time that you use the Standalone Build, it will use the updated list of file extensions.
See Also
File Extensions Tab
Determining the Appropriate Component Creation Method for Dynamically Linked Files
Configuring Advanced Settings for InstallShield
InstallShield lets you specify what type of encoding should be used for an XML file. This setting is available on the Advanced
tab when you select the XML file in the XML File Changes view. If the type of encoding that you want to use is not included in
the list of available encoding options, you can modify one of the files that is installed in a subfolder of the InstallShield
Program Files folder to add additional options. You can add any encoding that is supported by MSXML. The following
instructions explain how.
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
Task To add additional encoding options to the Encoding list on the Advanced tab in the XML File Changes view:
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
5. Search for the ISXML element and its child elements. They look something like this:
<ISXML>
<Encodings>
<Encoding>WINDOWS-1250</Encoding>
<Encoding>WINDOWS-1251</Encoding>
<Encoding>WINDOWS-1252</Encoding>
<Encoding>WINDOWS-1253</Encoding>
<Encoding>WINDOWS-1254</Encoding>
<Encoding>WINDOWS-1255</Encoding>
<Encoding>WINDOWS-1256</Encoding>
<Encoding>WINDOWS-1257</Encoding>
<Encoding>WINDOWS-1258</Encoding>
<Encoding>ISO-8859-1</Encoding>
<Encoding>ISO-8859-2</Encoding>
<Encoding>ISO-8859-3</Encoding>
<Encoding>ISO-8859-4</Encoding>
<Encoding>ISO-8859-5</Encoding>
<Encoding>ISO-8859-6</Encoding>
<Encoding>ISO-8859-7</Encoding>
<Encoding>ISO-8859-8</Encoding>
<Encoding>ISO-8859-9</Encoding>
<Encoding>US-ASCII</Encoding>
<Encoding>UNICODE-1-1-UTF-8</Encoding>
<Encoding>UNICODE-2-0-UTF-16</Encoding>
<Encoding>UNICODE-2-0-UTF-8</Encoding>
<Encoding>ISO-10646-UCS-2</Encoding>
<Encoding>UCS-4</Encoding>
<Encoding>UCS-2</Encoding>
<Encoding>UTF-16</Encoding>
<Encoding Default="true">UTF-8</Encoding>
</Encodings>
</ISXML>
6. Between the opening and closing Encodings tags, add a new line such as this:
<Encoding>Type_of_Encoding</Encoding>
where Type_of_Encoding indicates the encoding that you want to be available. This should be the value that
InstallShield should use for the encoding attribute of your XML document.
8. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. You should
be able to expand and contract the <ISXML> and <Encodings> elements; if you cannot, check the code for errors.
The next time that you open the XML File Changes view in InstallShield, you will see the encoding type that you added as
one of the available options in the Encoding used for a new file list on the Advanced tab for an XML file in the XML File
Changes view.
See Also
Advanced Tab for an XML File
Configuring Advanced Settings for InstallShield
When InstallShield converts an .msi package to a virtual package, it saves the virtual package in a subfolder of the folder
that contains the .msi file by default. In some cases, you may want to specify a different location for generating all of the
virtual packages. For example, if the .msi packages that you are converting are in a read-only location, you may need to
override the default virtual package location with an existing writable location.
InstallShield includes a machine-wide setting that lets you specify an existing writable location where all virtual packages
should be built. The following instructions explain how to configure this global setting.
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
Task To specify the location where all virtual packages should be built:
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
5. Search for the <Virtualization> element and its child element. They look something like this:
<Virtualization>
<!-- Instructions on how to specify a global path -->
<GlobalBuildRedirectFolder></GlobalBuildRedirectFolder>
</Virtualization>
6. Enter the global path as the text content for the <GlobalBuildRedirectFolder> element. For example, to create the
virtual packages in a subfolder of \\NetworkFolder\VirtualPackages, use the following:
<GlobalBuildRedirectFolder>\\NetworkFolder\VirtualPackages</GlobalBuildRedirectFolder>
Note that the path must already exist. Do not enclose the path within quotation marks.
8. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. You should
be able to expand and contract the <Virtualization> element; if you cannot, check the code for errors.
Whenever you convert an .msi package to a virtual package in InstallShield, InstallShield uses the path that you specified.
See Also
Creating Customized Virtual Applications
Configuring Advanced Settings for InstallShield
Caution • The following instructions require that you modify the Settings.xml file that is installed with InstallShield. This file
contains critical data; if it is edited incorrectly, it can cause InstallShield to fail to work. Use extreme care when editing this file.
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
In Installshield 2018, a new setting is introduced in settings.xml for Clone_wait parameter. By default, the original setup is
enabled to wait for the completion of the installation process. If you want to generate the setup launcher without the
embedded Clone_wait option, you can change the setting.
The end users can then override this setting with the command line parameter.
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language version of InstallShield you are using:
3. Create a back-up copy of the Settings.xml file, in case you later need to revert to the original version.
4. Use a text editor or XML file editor to open the Settings.xml file.
5. Search for the <Clone_wait> element and its child element. By default, they look something like this:
<Clone_wait default="Yes"/>
<Clone_wait default="No"/>
8. Ensure that your XML code is well formed; if it is not well formed, you may have problems using InstallShield. In most
cases, you can identify improperly formed XML code by opening the Settings.xml file in Internet Explorer. Check the
code for errors.
See Also
Miscellaneous
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
InstallShield 2020 lets you to select platform architecture for digital signing of files.
1. Close InstallShield.
2. Find the Settings.xml file that is installed with InstallShield. Settings.xml is installed in one of the following
locations, depending on which language of InstallShield that you are using:
3. Create a backup copy of the Settings.xml file, in case you later need to revert to the original version.
5. Search for the tag <DigitalSignature>. The actual tag is <DigitalSignature Platform="X86"/>.
Edition • The ability to distribute releases to virtual machines is available in the Premier edition of InstallShield.
• Basic MSI
• InstallScript
• InstallScript MSI
• Suite/Advanced UI
You can configure releases in your projects so that after each successful build of your installation, InstallShield
automatically reverts a virtual machine (VM) to a designated snapshot, powers on the VM, and copies your installation to
the VM to make it available for testing. You can also alternately perform these testing preparation steps on demand at any
time.
When you use the Configuration setting on the Events tab for a selected release in the Releases view to configure VM
details, InstallShield writes the data that you specify to a file called VMConfigurations.xml. This VMConfigurations.xml
file is a machine-wide file that you can configure once and then use it in other InstallShield projects, as well as share it with
other team members. You can also use this file with the Standalone Build.
The following instructions explain how to share this global file with others.
Task To share the customized VM configuration settings file with another machine that has InstallShield or the Standalone
Build:
1. On your development machine, configure the VM settings for a release in one of your projects. To learn how, see
Distributing Releases to a Virtual Machine that InstallShield Provisions at Build Time or on Demand.
2. Close InstallShield.
3. Find the VMConfigurations.xml file that is installed with InstallShield, and make a copy of it for the other machine.
VMConfigurations.xml is installed in one of the following locations, depending on which language version of
InstallShield you are using:
4. Create a back-up copy of the VMConfigurations.xml file that is on the other machine, in case you later need to revert
to the original version, and then overwrite the installed version with the one from your development machine.
If you use the Standalone Build to build a release, update the VMConfigurations.xml file that is installed with the
Standalone Build. VMConfigurations.xml is installed in one of the following locations, depending on which language
version of InstallShield you are using:
Tip • If you make any manual changes to the XML file in a text editor, ensure that your XML code is well formed; if it is not well
formed, you may have problems using InstallShield. In most cases, you can identify improperly formed XML code by opening
the VMConfigurations.xml file in Internet Explorer. You should be able to expand and contract the <VMConfigurations>
element; if you cannot, check the code for errors.
See Also
Distributing Releases to a Virtual Machine that InstallShield Provisions at Build Time or on Demand
When you start using InstallShield 2020, you can upgrade installation projects that you created using earlier versions or
different InstallShield products. This section discusses those upgrades.
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2014 and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you may
notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2014 or earlier to
InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open an project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .775 (for an .ism project) or .2014 (for an
.issuite project) before converting it. Delete the .775 or .2014 part from the original project’s file name if you want to reopen
the project in the earlier version of InstallShield. Note that you cannot open InstallShield 2020 projects in earlier versions of
InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2014 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and InstallShield Developer 8 and earlier.
Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal cannot be upgraded to
InstallShield 2020.
Removal of Support for Digitally Signing with .spc and .pvk Files
InstallShield no longer has support for using .spc and .pvk files to digitally sign files at build time.
If you configured a release or patch in InstallShield 2014 or earlier to be digitally signed at run time with .spc and .pvk files,
and then you try to open that project in InstallShield 2020, InstallShield displays upgrade warning -6048 (for a release), -
6049 (for a patch), or -6050 (for a QuickPatch project). The warning explains that InstallShield is removing the .pvk file and
the associated password from your project during the upgrade.
Before you can successfully build the release or the patch in InstallShield 2020, you will need to remove the .spc reference
from the release or patch configuration. You can replace it with a .pfx certificate, or with a reference to a certificate in a
certificate store. To learn more, see:
If you try to build a release or a patch without removing the .spc reference from it, InstallShield displays build error -7347,
stating that the .spc file must be removed.
To learn how to convert an .spc file and a .pvk file to a .pfx file, see Digital Signing and Security.
• CorrespondingPrivateKey
• SoftwarePublishingCredentials
If you call those properties, you will encounter an error. Those properties have been replaced with the read-write string
property DigitalCertificateInfo.
Changes to the PowerShell Support in Basic MSI and InstallScript MSI Installations
The PowerShell custom action support in Basic MSI and InstallScript MSI installations has been revised. The support no
longer uses the Windows Installer property IS_PS_EXECUTIONPOLICY to indicate the name of the PowerShell execution
policy that you want to be used to run PowerShell custom actions on target systems. Setting this property at run time no
longer has any effect on the installation.
Changes to Default Eligibility Conditions for .msi Packages in Advanced UI and Suite/
Advanced UI Projects
To make it possible to support shared packages in Advanced UI and Suite/Advanced UI projects, InstallShield no longer
needs the previously required MSI Package eligibility conditions for .msi packages. Now you can limit the use of eligibility
conditions of .msi packages to check for run-time environment requirements such as platform.
Now when you add an .msi package to an Advanced UI or Suite/Advanced UI project in InstallShield 2020, InstallShield no
longer creates an MSI Package eligibility condition for that package by default. This behavior applies to new InstallShield
2020 projects, as well as projects that you created in InstallShield 2014 or earlier and then upgrade to InstallShield 2020.
In addition, if you upgrade an InstallShield 2014 or earlier project that contains the old default MSI Package eligibility
condition for an .msi package to InstallShield 2020, InstallShield removes the unnecessary part of the condition from the
Eligibility Condition setting for the package.
In some cases, if you customized the default MSI Package eligibility condition in InstallShield 2014 or earlier, InstallShield
2020 may remove it during the upgrade; in other cases, InstallShield leaves it as is. The actual upgrade behavior depends
on the customization. For example, if you simply added a platform condition, InstallShield may be able to remove the
original MSI Package part of the condition, leaving just the platform condition. However, if the customization is too
complex, InstallShield leaves the condition as is.
It is recommended that you review the eligibility conditions for your .msi packages after upgrading to InstallShield 2020 to
ensure that they are configured as expected.
If you have customized or somehow otherwise edited the default MSI Package eligibility condition, InstallShield leaves
your custom condition during the upgrade. It is recommended that you review the eligibility conditions for your .msi
packages to ensure that they are configured as expected.
Previously, the default MSI Package condition for the Eligibility Condition setting of .msi packages used asterisks (*) in the
condition’s Product Code and Product Version settings as placeholders for the package’s own product code and product
version.
For new InstallShield 2020 projects, as well as projects that you created in InstallShield 2014 or earlier and then upgrade to
InstallShield 2020, if you use an ampersand (&) in any of the following areas of the wizard interface of your installation, the
installation now displays the ampersand as a literal character instead of interpreting it as a prefix character for a keyboard
shortcut. The change also applies if any of these strings include a property that resolves to a value that contains an
ampersand.
• The string in the header area of a wizard page or secondary window—This is configured in the Title setting for a wizard
page or window in the Wizard Interface view.
• The caption bar of wizard pages—This is configured in the Wizard Caption setting for the Wizard Pages node in the
Wizard Interface view.
• The supplemental explanation area of a command link control—This is configured in the Note setting for a wizard
page or window.
• The alternate text for an image control—This is configured in the Alt Text setting of an image control on a wizard page
or window.
Furthermore, for most label controls, True is now selected by default for the SS_NOPREFIX subsetting under the Style
setting; previously False was selected by default. A True value for this subsetting ensures that any ampersands that are
included in the string entries for such controls are not inadvertently interpreted as keyboard shortcuts, and that
ampersands in the control's strings are displayed as ampersands in the wizard interface.
These SS_NOPREFIX changes apply to the built-in default and predefined wizard pages and windows that are available for
new InstallShield 2020 projects. If you upgrade an InstallShield 2014 or earlier project to InstallShield 2020, the
SS_NOPREFIX settings are changed automatically for the standard built-in default wizard page and windows. However, no
changes are made automatically to custom wizard pages and windows—including the predefined wizard pages—when you
upgrade these projects to InstallShield 2020; if you want to change the ampersand interpretation of these, you can do so
manually
Previously, to work around problems with an ampersand being used inadvertently to designate a keyboard shortcut in any
of the aforementioned areas of the wizard interface, and instead show a single ampersand, it was possible to use an
escaped ampersand (&&) in place of a single ampersand. However, if you upgrade a project that contains one or more
instances of those workarounds to InstallShield 2020, the escaped ampersand is now displayed literally as two
ampersands. Thus, it may be necessary to review the use of ampersands in the wizard interface of your projects and make
changes as needed.
For more information, see Designating Keyboard Shortcuts and Using Ampersands (&) in the Wizard Interface.
Trialware Support
InstallShield no longer includes support for creating the Try and Die or the Try and Buy/Product Activation types of
trialware. The Trialware view is no longer included in InstallShield.
See Also
What’s New in InstallShield 2015
Upgrading from Earlier InstallShield Versions
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2013 and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you may
notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2013 or earlier to
InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open an project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .774 (for an .ism project) or .2013 (for an
.issuite project) before converting it. Delete the .774 or .2013 part from the original project’s file name if you want to reopen
the project in the earlier version of InstallShield. Note that you cannot open InstallShield 2020 projects in earlier versions of
InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2013 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and InstallShield Developer 8 and earlier.
Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal cannot be upgraded to
InstallShield 2020.
See Also
What’s New in InstallShield 2014
Upgrading from Earlier InstallShield Versions
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2012 Spring and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you
may notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2012 Spring or
earlier to InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open an project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .773 (for an .ism project) or .2012.4 (for an
.issuite project) before converting it. Delete the .773 or .2012.4 part from the original project’s file name if you want to
reopen the project in the earlier version of InstallShield. Note that you cannot open InstallShield 2020 projects in earlier
versions of InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2012 Spring and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and InstallShield Developer 8 and
earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal cannot be upgraded
to InstallShield 2020.
For Basic MSI and InstallScript MSI projects, you may want to consider adding a launch condition that displays a message if
end users are running your installation on a Windows 2000 system. For InstallScript projects, you may want to consider
adding InstallScript code that uses the SYSINFO structure variable to check for Windows 2000 systems, and then display a
message if appropriate.
Advanced UI and Suite/Advanced UI installations now require at least Windows Vista and Windows Server 2008.
InstallShield no longer supports the creation of installations for mobile devices. Thus, the Mobile Devices view, the Smart
Device project type, the Palm OS Object, and the Windows Mobile Object are no longer included in InstallShield. If you try
to upgrade a Smart Device project from InstallShield 2012 Spring or earlier to InstallShield 2020, InstallShield 2020 displays
an error message and fails to open the project. If you upgrade a project from InstallShield 2012 Spring or earlier to
InstallShield 2020, and if the project targets desktop platforms and contains other mobile device support, InstallShield
removes the mobile device support during the upgrade and logs a warning.
Changes to the XML Schema for Advanced UI and Suite/Advanced UI Project Files (.issuite)
Advanced UI and Suite/Advanced UI project files (.issuite) are XML-based files. The underlying XML schema for the user
interface part of the file has changed significantly in InstallShield 2020. Many attributes have been moved to child
elements. Conditions, actions, and validations are fundamentally different: element collections are used instead of
attribute strings. The new schema is more explicit about what is configured for the user interface of the installation.
If you create a new Advanced UI or Suite/Advanced UI project in InstallShield 2020, InstallShield automatically uses the
new XML schema for the .issuite file. If you upgrade a project from InstallShield 2012 Spring or earlier to InstallShield 2020,
InstallShield automatically updates the XML schema.
Note that if you install the Standalone Build on the same machine as InstallShield, the last ISWiAutomationAutomation
Interface Version.dll file that is registered is the one that is used.
Changes to the Default Wizard Format for the Suite/Advanced UI and Advanced UI Wizard Interface
If you create a new Suite/Advanced UI or Advanced UI project in InstallShield 2020, the default value for the Wizard Format
setting is Glass, a new option. If you upgrade a Suite/Advanced UI or Advanced UI project from an earlier version of
InstallShield to InstallShield 2020, InstallShield does not change the value of the Wizard Format setting; it leaves whatever
value was selected in the earlier version of InstallShield.
You can configure your project to use to a different wizard format if appropriate. To do so, change the value of the Wizard
Format setting that is displayed in the Wizard Interface view when the Wizard Pages node is selected.
For more information, see Selecting the Format for the Wizard Interface.
Changes to the Font Color of Navigation Button Text in Advanced UI and Suite/Advanced UI Installations
In some scenarios, if you upgrade an Advanced UI or Suite/Advanced UI project from InstallShield 2012 Spring or earlier to
InstallShield 2020, the text on the navigation buttons may no longer be legible: the colors for the text and the buttons may
not have enough contrast. This may occur if light font color is specified for the text style that is used for navigation button
text, and if the target system’s colors are configured to use a light color for buttons on windows.
Beginning with InstallShield 2020, Advanced UI and Suite/Advanced UI installations no longer ignore the font color that is
specified for the text style of text that is used on navigation buttons. Thus, when you upgrade your Advanced UI or Suite/
Advanced UI project to InstallShield 2020, you may need to adjust the color of the text style that is used for the navigation
button text. To do so, in the Wizard Interface view, click the Wizard Pages node, and note the text style that is selected for
the Navigation Text Style setting. Then, find that text style under the Styles node in this view, and adjust its settings as
needed.
In InstallShield 2012 Spring or earlier, Advanced UI and Suite/Advanced UI projects ignored the text style color for
navigation button text. At run time, the installation used the font color that Windows used for navigation buttons; the color
was typically black.
• The Pin to Windows 8 Start Screen setting sets the System.AppUserModel.StartPinOption property by using the
following GUID and property ID combination:
9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3, 12
• The Prevent Pinning option in the Shell Properties setting sets the System.AppUserModel.PreventPinning property by
using the following GUID and property ID combination:
9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3, 9
• The Do Not Highlight as New option in the Shell Properties setting sets the
System.AppUserModel.ExcludeFromShowInNewInstall property by using the following GUID and property ID
combination:
9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3, 8
Windows Installer may generate errors if one or more of these property names (instead of the GUID and property ID) are
used in a package that is run on a version of Windows that does not have support for these properties.
If you used the Shell Properties setting in InstallShield 2012 Spring or earlier to configure Shell properties for a shortcut,
and you upgrade the project to InstallShield 2020, InstallShield does not automatically replace the property names with
the appropriate GUID and property ID combinations. To quickly switch to the GUID and property ID combination, consider
deleting the old configuration in the Shell Properties view after upgrading your project, and then using the new support to
reconfigure one or more of these properties. As an alternative, you can manually override the entry with the appropriate
GUID and property ID. To learn more about the built-in support in InstallShield, see Setting Shell Properties for a Shortcut.
This support is available for the following project types: Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database,
MSM Database, and Transform.
See Also
What’s New in InstallShield 2013
Upgrading from Earlier InstallShield Versions
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2012 and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you may
notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2012 or earlier to
InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open an project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .772 (for an .ism project) or .2012 (for an
.issuite project) before converting it. Delete the .772 or .2012 part from the original project’s file name if you want to reopen
the project in the earlier version of InstallShield. Note that you cannot open InstallShield 2020 projects in earlier versions of
InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2012 and earlier, InstallShield 12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and
InstallShield Developer 8 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield
Universal cannot be upgraded to InstallShield 2020.
New Default Behavior When Launching an Earlier Version or the Same Version of a Suite/Advanced UI
Installation on Target Systems
InstallShield now includes two Suite Installed conditions in each Advanced UI and Suite/Advanced UI project by default:
• A new Suite Installed exit condition prevents end users from being able to install the current version of the Advanced
UI or Suite/Advanced UI installation over a future newer version of the same Advanced UI or Suite/Advanced UI
installation.
• A new Suite Installed mode condition now causes the Advanced UI or Suite/Advanced UI installation to run in first-
time installation mode if end users install a new version of the Advanced UI or Suite/Advanced UI installation over an
older version of the same Advanced UI or Suite/Advanced UI installation.
These new default conditions are available in all new Suite/Advanced UI projects. If you upgrade an InstallShield 2012 Suite
project to InstallShield 2020, InstallShield automatically adds these default conditions to the project. To learn more about
these conditions, see Detecting Whether a Specific Version of an Advanced UI or Suite/Advanced UI Installation Is Already
Installed.
Previously, if an end user installed a particular version of a Suite installation on a target system on which a newer version of
the Suite was already installed, the installation could permit the end user to install the older Suite version over the newer
version. In addition, if an end user installed a particular version of a Suite installation on a target system on which the same
version of the Suite was already installed, the Suite installation could run in first-time installation mode. Furthermore, if an
end user installed a new version of a Suite installation on a target system on which an older version of the Suite was already
installed, the Suite installation could run in maintenance mode.
Note that if you install the Standalone Build on the same machine as InstallShield, the last ISWiAutomationAutomation
Interface Version.dll file that is registered is the one that is used.
Changes to the Default Behavior of New Combo Boxes in the Wizard Interface of Suite/Advanced UI
Projects
If you create a new combo box control on a wizard page or a secondary window in a Suite/Advanced UI project in
InstallShield 2020, the control is a box that contains a drop-down list of predefined values. The box is also a text box that
lets end users enter a custom value. Previously, if you added a new combo box control in InstallShield 2012, 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.
If you upgrade the project from InstallShield 2012 to InstallShield 2020, and if the Suite/Advanced UI wizard interface
includes a combo box, the combo box is left as a drop-down list of predefined values, but it is not also a text box. To change
the control to a drop-down list with the text box, set the CBS_DROPDOWNLIST style for this control to False.
See Also
What’s New in InstallShield 2012 Spring
Upgrading from Earlier InstallShield Versions
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2011 and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you may
notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2011 or earlier to
InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open a project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .771 before converting it. Delete the .771 part
from the original project’s file name if you want to reopen the project in the earlier version of InstallShield. Note that you
cannot open InstallShield 2020 projects in earlier versions of InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2011 and earlier, InstallShield 12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and
InstallShield Developer 8 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield
Universal cannot be upgraded to InstallShield 2020.
Changes in Behavior for Some MSI APIs That Are Called in InstallScript Custom Actions
A change was made to how the InstallScript engine calls Windows Installer API such as MsiGetProperty. The engine now
calls the Windows Installer APIs directly instead of using wrapper APIs that in turn call the Windows Installer APIs. This
change was made to resolve issues with buffer handling and buffer sizes. It applies to all new projects that you create in
InstallShield 2020, as well as projects that you have upgraded from earlier versions of InstallShield to InstallShield 2020.
As a result of this change, you can use the MSI install handle that is passed to a custom action function with all Windows
Installer APIs that require an install handle. Previously, the handle was managed by the InstallScript engine, and it could
not be passed directly to Windows Installer APIs.
Also as a result of this change, any Windows Installer APIs that require a buffer size to be specified now fail if the buffer size
is not correctly specified. Note that 0 is not a valid size; thus, ensure that your code does not pass a zero value for the size of
the buffer.
If you have existing InstallScript custom actions that call Windows Installer APIs, ensure that a large enough buffer size is
specified; if it is not, unexpected results could occur.
The following sample code demonstrates how to retrieve the value of a Windows Installer property value string in
InstallScript and increase the size of the buffer if necessary.
begin
Note that if the script had used if ( ERROR_SUCCESS == nResult ) then instead of if ( ERROR_MORE_DATA == nResult
) then, unexpected results could occur.
If you build a release in a Basic MSI project without entering data in the required identification tag settings (the Unique ID,
Tag Creator, and Tag Creator ID settings in the General Information view), and you leave tagging enabled in the project,
build warning -7235 occurs. 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 in the General Information view.
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 functionality applies to the following project types: Basic MSI, DIM, InstallScript MSI, and Merge Module.
The use of the GUID in string identifiers of Merge Module project string entries helps to minimize or eliminate conflicts that
would occur if the same string identifier is used in a Merge Module project and also in an installation project that contains
that Merge Module, and if different values are assigned to those two string identifiers.
See Also
What’s New in InstallShield 2012
Upgrading from Earlier InstallShield Versions
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2010 and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you may
notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2010 or earlier to
InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open a project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .770 before converting it. Delete the .770 part
from the original project’s file name if you want to reopen the project in the earlier version of InstallShield. Note that you
cannot open InstallShield 2020 projects in earlier versions of InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2010 and earlier, InstallShield 12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and
InstallShield Developer 8 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield
Universal cannot be upgraded to InstallShield 2020.
InstallShield Builds Only Unicode Versions of Setup.exe and Update.exe; Ability to Create ANSI Versions
Is No Longer Available
Now all Setup.exe and Update.exe files that are built in all project types in InstallShield are Unicode. This applies to all
new Basic MSI, InstallScript, InstallScript MSI, and QuickPatch projects that you create in InstallShield 2020. It also applies
to all projects that you have upgraded from earlier versions of InstallShield to InstallShield 2020. Therefore, the settings
that previously enabled you to specify whether you wanted to build a Unicode version or an ANSI version of the setup
launcher have been removed:
• The Setup Launcher Type setting on the Setup.exe tab for a release in the Releases view has been removed from Basic
MSI projects.
• The Update Launcher Type setting was removed from Basic MSI, InstallScript MSI, and QuickPatch projects.
In Basic MSI and InstallScript MSI projects, this setting was on the Advanced tab for a patch configuration in the Patch
Design view.
In QuickPatch projects, this setting was on the Advanced tab in the Build Settings area of the General Information
view.
If you upgrade an InstallShield 2010 or earlier project to InstallShield 2020, it is possible that these new prototypes could
conflict with user-defined prototypes of the same APIs. It is recommended that the InstallScript-provided prototypes be
used if possible. However, if you want to use your own prototypes for these Windows APIs instead of the ones that are now
prototyped for InstallScript, add ISINCLUDE_NO_WINAPI_H to the list of preprocessor definitions: On the Build menu, click
Settings. On the Compile/Link tab, in the Preprocessor Defines box, enter ISINCLUDE_NO_WINAPI_H. Otherwise, you may
encounter compile errors.
Update your script to call W versions of Win32 APIs if it is currently calling A versions.
Note that now that the InstallScript engine has been updated to support Unicode, you may see changes in the return
values for the InstallScript function StrLength. As a result, you may need to make changes to your InstallScript code calls to
this function.
StrLength now behaves the same as StrLengthChars; both of these functions return the number of characters in a given
string variable (that is, the number of code units in the UTF-16-encoded string) up to the first null character. This applies to
all InstallScript projects that are created in InstallShield 2020, as well as all InstallScript projects that you have upgraded
from earlier versions of InstallShield to InstallShield 2020. Previously, StrLength returned the number of characters in a
given string variable before a null character in the ANSI code page. The behavior of StrLengthChars has not changed.
This requirement is necessary because of the Unicode support that is new in the InstallShield 2011 InstallScript engine.
After a differential release is used to update an earlier version of a product on a target system, the earlier version of the
installation (along with the earlier engine run time) is used to run any maintenance operations. Because the InstallShield
2010 and earlier versions of the InstallScript engine cannot read the new Unicode storage format, the installation fails.
Uninstalling 64-Bit Registry Entries that Were Installed by the InstallScript Engine
By default, the InstallScript engine now logs the changes that it makes to the 64-bit part of the registry during an
InstallScript or InstallScript MSI installation on 64-bit target systems. Furthermore, the 64-bit registry changes that are
logged by the InstallScript engine are now uninstalled during uninstallation.
Note that if you created an InstallShield 2010 or earlier installation that wrote 64-bit registry data and you create an
upgrade for your product in InstallShield 2020, the existing 64-bit registry entries that were logged by the base installation
are not removed when the product is uninstalled from a target system. The only way to work around this limitation is to
manually remove the registry data during uninstallation.
The context menu that is displayed when you right-click in a script editor pane is now different than it was in InstallShield
2010 and earlier:
• The context menu no longer contains a Show Whitespace command. To show or hide whitespace characters and
symbols in the script editors, use the Script Editor Properties dialog box. This dialog box also lets you modify other
settings in the script editors, such as font, syntax colors, and line numbering. To access this dialog box, right-click in a
script editor and then click Properties.
• The context menu no longer contains a Make Uppercase command or a Make Lowercase command. To make text in
the script editor uppercase, select it and then press CTRL+SHIFT+U. To make it lowercase, select it and then press
CTRL+U.
• The context menu no longer contains a Find command or a Replace command. To perform a search in a script, press
CTRL+F, and then specify the text that you want to find. To search for a string and replace it with something else, press
CTRL+H and then specify the appropriate information. As an alternative, you can use the Find and Replace commands
on the Edit menu.
For more keyboard shortcuts, see Keyboard Shortcuts for the Script Editors.
The views that contain the revised script editor are the InstallScript view, the SQL Scripts view, and the Custom Actions and
Sequences view (when you are viewing a VBScript or JScript file in this view).
Note that once you have upgraded the project, you can change the DPI value on your machine at any time as needed; if you
do, the dialogs are sized correctly at run time. Also note that if you upgrade an InstallShield 2020 or later project that
contains one or more edited InstallScript dialogs to a future version of InstallShield, you do not need to use the same DPI
value during the upgrade.
If you move any InstallShield prerequisites from the InstallShield Program Files Folder\SetupPrerequisites folder
to a new custom location that you have defined on the Prerequisites tab of the Options dialog box (or any of the other
places where search paths can be defined now), you may need to perform the following steps in InstallShield 2010 or
earlier projects when you upgrade them to InstallShield 2020:
1. In the Redistributables view or the Prerequisites view, clear the check box for each InstallShield prerequisite that is
included in your project but is located in a custom location. Also clear the check box for each InstallShield prerequisite
whose data files or dependencies were moved from the default location to a custom location.
3. Select the check box for each InstallShield prerequisite that you removed from your project in step 1.
InstallShield removes the path of the prerequisite from the ISSetupPrerequisites table of your project. The full path
was stored in this table in InstallShield 2010 and earlier projects. Note that if you only clear a prerequisite’s check box and
then reselect it without clicking the Refresh button, InstallShield continues to use the full path, rather than just the file
name, in the ISSetupPrerequisites table.
If you upgrade an InstallShield 2010 or earlier project to InstallShield 2020, change the location of an InstallShield
prerequisite, and then add that prerequisite to your project, you do not need to perform the refresh procedure. Also, if you
create a new project in InstallShield 2020, you do not need to perform the refresh procedure. In both cases, InstallShield
does not include the path in the ISSetupPrerequisites table of your project, which enables you to use the custom
search path, instead of the default path.
Preventing an InstallScript MSI Installation from Overwriting a Future Major Version of the Same
Product
The Upgrades view in new InstallScript MSI projects now contains a major upgrade item called ISPreventDowngrade. This
item prevents end users from being able to install the current version of your product over a future major version of the
same product. If you upgrade an InstallScript MSI project from InstallShield 2010 or earlier to InstallShield 2020, the
ISPreventDowngrade item is not added automatically. You can manually add an ISPreventDowngrade item if appropriate.
To learn how, see the Preventing the Current Installation from Overwriting a Future Major Version of the Same Product.
See Also
What’s New in InstallShield 2011
Upgrading from Earlier InstallShield Versions
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2009 and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you may
notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2009 or earlier to
InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open a project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .768 before converting it. Delete the .768 part
from the original project’s file name if you want to reopen the project in the earlier version of InstallShield. Note that you
cannot open InstallShield 2020 projects in earlier versions of InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2009 and earlier, InstallShield 12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and
InstallShield Developer 8 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield
Universal cannot be upgraded to InstallShield 2020.
InstallShield no longer lists these legacy operating systems in any of the areas where target operating systems can be
selected. For example, the Installation Requirements tab of the Project Assistant in Basic MSI and InstallScript MSI projects
no longer lists these operating systems. In InstallScript projects, the Platforms tab on the Project Settings dialog box no
longer lists these operating systems.
If you upgrade an InstallScript project that was created in InstallShield 2009 or earlier to InstallShield 2020, and if the
operating system settings in the earlier project contained references to only these legacy operating systems, InstallShield
replaces the legacy operating system options with the option for targeting all supported platforms.
InstallShield supports backwards compatibility: If you imported dialog source code into an InstallShield 2009 or earlier
project and then you upgrade the project to InstallShield 2020, you can still use that dialog code. However, if you want to
use the dialog sources that are now available when you select the dialogs in the event handler drop-down list, you must
first make some changes to your upgraded project. Otherwise, you may encounter compile errors. In order to use the
dialog code: On the Build menu, click Settings. On the Compile/Link tab, in the Preprocessor Defines box, enter the
following:
_ISSCRIPT_NEW_STYLE_DLG_DEFS
After this definition has been added, if any dialogs had previously been imported into the project in earlier versions of
InstallShield, the code in these imported .rul files may cause compile errors. These errors would need to be resolved.
If _ISSCRIPT_NEW_STYLE_DLG_DEFS is not defined, a warning message is displayed when the Dialog Source option is
selected in the event class drop-down list in the InstallScript view.
The _ISSCRIPT_NEW_STYLE_DLG_DEFS definition is automatically added to all new projects that are created in
InstallShield 2020.
This functionality applies to the following project types: InstallScript, InstallScript MSI, and InstallScript Object.
If you want to use your own definitions for these Windows APIs instead of the ones that are now prototyped for
InstallScript, add ISINCLUDE_NO_SERVICEAPI to the list of preprocessor definitions: On the Build menu, click Settings. On
the Compile/Link tab, in the Preprocessor Defines box, enter ISINCLUDE_NO_SERVICEAPI. Otherwise, you may encounter
compile errors.
Note that the constant ISINCLUDE_NO_WINAPI_H now suppresses only Windows API prototypes, not Windows constants
or Windows structure definitions.
New Custom Actions and Database Tables for IIS Support in Basic MSI and InstallScript MSI Projects
If you add IIS support through the Internet Information Services view in a Basic MSI or InstallScript MSI project in
InstallShield, InstallShield automatically adds several DLL custom actions to your project to support the IIS functionality.
In InstallShield 2020, these custom actions have been enhanced to enable you to add applications to Web sites. In addition,
these actions have been renamed to reflect standard naming conventions:
The entry points of each of the DLL custom actions have been renamed to match the corresponding custom action names.
Note that IIS functionality requires administrative privileges. Therefore, each of these DLL custom actions checks the
Privileged property value. The value must be 1; if it is not, an error is displayed at run time. In InstallShield 2009 and earlier,
each of the IIS custom actions had a Privileged = 1 condition. In InstallShield 2020, this condition is no longer set when you
add new IIS Web sites or other IIS data to your project, since the custom actions check the Privileged property value.
If you upgrade a Basic MSI or InstallScript MSI project that contains IIS support from InstallShield 2009 or earlier to
InstallShield 2020, InstallShield automatically updates and renames the custom actions accordingly. In addition, if the
condition for an old custom action was not modified from the default condition, InstallShield also removes the Privileged =
1 condition. If a condition was modified, InstallShield leaves the existing condition as is. You can manually modify any of
the conditions if appropriate.
In InstallShield 2020, all of the IIS data is stored in the ISIISItem and ISIISProperty tables. In InstallShield 2009 and
earlier, the IIS data was stored in the following tables: ISIISAppPool, ISIISCommon, ISIISMetaData,
ISIISWebServiceExtension, ISVRoot, ISVRootAppMaps, and ISWebSite. If you upgrade a Basic MSI or InstallScript MSI
project that contains IIS support from InstallShield 2009 or earlier to InstallShield 2020, InstallShield automatically moves
the IIS data to the new tables; InstallShield also deletes the old tables from the project.
The new group box area is below the new toolbar in the Redistributables view. You can drag and drop column headings
onto this group box area to organize the list of redistributables in a hierarchical format. If you want InstallShield to
separate all of the redistributables in the view into two groups—one whose check box is selected and one whose check box
is cleared—drag the check box column to the group box area. This enables you to easily identify all of the redistributables
that are included in your project. The result is similar to the behavior that previously occurred if you right-clicked any
redistributable and then clicked Show Only Selected Items. Note that the Show Only Selected Items command is no longer
available in the Redistributables view.
For more information, see Working with the Group Box Area in Various Views.
Limiting the UI Level of a Chained .msi Package to that of the Main .msi Package
The UI level for a chained .msi package is now limited to be no higher than that of the parent package’s current UI level. For
example, in the following scenario, the chained .msi package is launched silently: you add a chained .msi package to your
project in the Releases view and select Full UI (/qf) for its UI level setting, but the main installation is launched silently (/qn).
Previously, the chained package showed exactly the UI level that was authored in the Releases view of the main
installation; to restore this behavior, set the property ISChainExceedUILevel equal to the value 1.
In addition, if the "Always create this element if it does not already exist" check box is cleared for an element that is not
present in the target file, its child elements are no longer created. Thus, for an XML file such as //A/B/C, C is not created on
the target system if B is neither present nor set to be created.
Changes to the Major and Minor Version Registry Entries for the Uninstall Key of InstallScript
Installations
InstallScript installations now always create VersionMajor and VersionMinor registry values in the Uninstall key; the names
of these values now match the entries that are created during Basic MSI and InstallScript MSI installations. This applies to
new installations that are created in InstallShield 2020, as well as installations that are upgraded from InstallShield 2009 or
earlier. Previously, in InstallShield 2009 and earlier, the names of the values that InstallScript installations created were
MajorVersion and MinorVersion; these are no longer created.
In order to use the new registry values, the values of the following InstallScript constants have been changed:
When the MaintenanceStart function is called, it creates the updated value names in the registry. By default, it also
deletes the old value names if they exist. If you do not want the old value names to be deleted from target systems, you can
use the new REGDB_OPTIONS option called REGDB_OPTION_NO_DELETE_OLD_MAJMIN_VERSION. If you want to
continue using only the old value names, you must delete the new versions after MaintenanceStart returns.
• REGDB_UNINSTALL_MAJOR_VERSION_OLD
• REGDB_UNINSTALL_MINOR_VERSION_OLD
You can specify these constants with the RegDBGetItem, RegDBSetItem, and RegDBDeleteItem functions to get, set, and
delete the old values.
For more information, see the following in the InstallScript Language Reference:
• REGDB_VALUENAME_UNINSTALL_MAJORVERSION
• REGDB_VALUENAME_UNINSTALL_MAJORVERSION_OLD
• REGDB_VALUENAME_UNINSTALL_MINORVERSION
• REGDB_VALUENAME_UNINSTALL_MINORVERSION_OLD
• REGDB_UNINSTALL_MAJOR_VERSION_OLD
• REGDB_UNINSTALL_MINOR_VERSION_OLD
• REGDB_OPTIONS
• RegDBSetItem
• RegDBGetItem
• RegDBDeleteItem
• ISWiComponent Object
• ISWiRelease Object
Changes for the Locations of InstallScript Run-Time Script, Library, and Header Files
The InstallScript run-time library files that are installed with InstallShield have been consolidated into a central location,
instead of several separate subdirectories. The script, library, and header files are now installed in Src, Lib, and Include
folders in the following directory:
The following folders are no longer installed, since the files within them are consolidated in the above location:
Note that because of a name conflict, the Assert.h file in the following location is being renamed as ISAssert.h:
If you create a new project in InstallShield 2020, it uses the new locations of the files. If you upgrade a project from
InstallShield 2009 or earlier to InstallShield 2020, InstallShield updates the projects to use the new locations.
Changes in the Way that Linked Libraries and Their Locations Are Specified
The Compile/Link tab on the Settings dialog box has a new Additional Library Paths box that lets you specify the locations
where the InstallScript compiler should search for InstallScript libraries (.obl files) that are not one of the standard
InstallShield locations. For InstallScript and InstallScript Object projects, the standard locations are:
• <ISProductFolder>\Script\Ifx\Lib
• <ISProductFolder>\Script\Isrt\Lib
For Basic MSI and InstallScript MSI projects, the standard locations are:
• <ISProductFolder>\Script\Iswi\Lib
• <ISProductFolder>\Script\Isrt\Lib
If you create a new project in InstallShield 2020, InstallShield automatically lists the standard InstallShield script libraries
such as ISRT.obl in the Libraries (.obl) box on the Compile/Link tab. However, InstallShield no longer includes the full path
in that box. If you want to add your own custom libraries, you can specify the library file name in the Libraries (.obl) box,
and the path in the Additional Library Paths box. You do not need to specify the full path and file name in the Libraries (.obl)
box.
If you upgrade a project that was created in InstallShield 2009 or earlier to InstallShield 2020, InstallShield automatically
removes the path of the standard script libraries that are listed in the Libraries (.obl) box. For more information, see
Compile/Link Tab.
• Update the script to use the equivalent OSVERSIONINFO structure, and declare a local instance of this structure if
needed. Update the script to use the appropriate structure member names. (Note that the OSVERSIONINFO member
names are different than the ISOSVERSIONINFO member names.) Following is the definition of OSVERSIONINFO:
typedef OSVERSIONINFO
begin
NUMBER nOSVersionInfoSize;
NUMBER nMajorVersion;
NUMBER nMinorVersion;
NUMBER nBuildNumber;
NUMBER nPlatformId;
STRING szCSDVersion[128];
end;
Changes to Support for Securing Permissions for Files, Folders, and Registry Keys
The General Information view has a new Locked-Down Permissions setting that lets you specify whether you want to use
the new custom InstallShield handling or the traditional Windows Installer handling for all new permissions that you set for
files, folders, and registry keys in your project. The new custom InstallShield handling option offers several advantages
over the traditional Windows Installer handling option.
In all new projects, the default value for this setting is the custom InstallShield handling option. If you upgrade a project
from InstallShield 2009 or earlier to InstallShield 2020, the traditional Windows Installer handling option is the default
value of this setting.
This new setting is available in the following project types: Basic MSI, InstallScript MSI, Merge Module, MSI Database, MSM
Database, and Transform.
• Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment
Changes to the ReadyToInstall Dialog for Beta Windows Installer 5 Support of Per-User Installations
The General Information view has a new Show Per-User Option setting. This setting lets you specify whether you want the
ReadyToInstall dialog—in certain scenarios—to include buttons that let end users indicate how they want to install the
product: for the current user or for all users. The per-user button sets the new Windows Installer property
MSIINSTALLPERUSER equal to 1 to indicate that the package should be installed for the current user. The
MSIINSTALLPERUSER property is available with the beta of Windows Installer 5.
If you create a new Basic MSI project in InstallShield 2020, the ReadyToInstall dialog includes support for the per-user and
per-machine buttons; these buttons are displayed or hidden at run time if appropriate. If you upgrade a Basic MSI project
from InstallShield 2009 or earlier to InstallShield 2020, the ReadyToInstall dialog does not have this support automatically.
You can manually add these buttons and their associated conditions to the ReadyToInstall dialog if appropriate; use the
ReadyToInstall dialog in a new InstallShield 2020 project as a guideline.
This change applies to the following project types: Basic MSI and InstallScript MSI.
Changes to the Conditions for the InstallWelcome Dialog and the ResolveSource Action
The condition on the InstallWelcome dialog and the ResolveSource action has been changed to Not Installed for all new
Basic MSI projects that are created in InstallShield 2020. The conditions were changed so that the InstallWelcome dialog
and the ResolveSource action can be used for a first-time installation with a patch. If you upgrade a Basic MSI project from
InstallShield 2009 or earlier to InstallShield 2020, the conditions are not changed automatically. If you want the dialog and
action to be used for a first-time installation with a patch, you can change the conditions in your upgraded project to Not
Installed.
Improvements to the .rtf File Size Limit for the SdLicenseRtf and SdLicense2Rtf Functions
The file size limit for the .rtf files that are used with the InstallScript dialog functions SdLicenseRtf and SdLicense2Rtf is
now 16 MB instead of 64 KB. Previously, if the file size was more than 64 KB, part of the EULA text was missing from the
license dialog at run time.
Note that if you had overridden the SdLicenseRtf or SdLicense2Rtf functions in your script in InstallShield 2009 or earlier
and then upgraded that project to InstallShield 2020, you would need to manually change the size limit by updating the
SendMessageTimeout call with the EM_EXLIMITTEXT message in DLG_INIT. The iParam parameter (the fourth parameter)
of the SendMessageTimeout call needs to be changed. The SendMessageTimeout call should be changed to this:
Changes to the Way that a Log File Is Displayed from the SetupCompleteSuccess Dialog in Basic MSI
Installations
The ShowMsiLog custom action now launches Notepad.exe from the SystemFolder directory, instead of from the
WindowsFolder directory. Thus, if your installation is run on Windows Vista or later and the end user indicates on the
SetupCompleteSuccess dialog that they want to view the log file, the installation launches Notepad.exe from the
SystemFolder directory. This change was made because on Windows Server 2008 Standard Edition, Notepad.exe is
available in the System32 directory, but not the Windows directory.
Note that behavior is available by default in all new Basic MSI projects that are created in InstallShield. If you upgrade an
InstallShield 2009 or earlier Basic MSI project to InstallShield 2020, InstallShield does not automatically change the
behavior. You can manually change the behavior if necessary: In the Custom Actions and Sequences view, click the
ShowMsiLog action. (If this action is not displayed, right-click the Custom Actions node and then click Show All Custom
Actions.) Set the Filename & Commandline setting as follows:
[SystemFolder]notepad.exe "[MsiLogFileLocation]"
If you upgrade a project that was created with InstallShield 2009 or earlier to InstallShield 2020, InstallShield does not
automatically change the value of the ALLUSERS property or add this property if it was not defined in the earlier project.
Trialware Support
The only edition of InstallShield that includes the Trialware view is the Premier edition. This edition lets you create the Try
and Die type of trialware. InstallShield no longer includes support for creating the Try and Buy/Product Activation type of
trialware.
Web Projects
The Web project type is no longer listed as one of the types of new projects that you can create in InstallShield. To use the
same functionality that was available with a Web project in InstallShield 2009 and earlier, create a Basic MSI project, and
then add a Web site in the Internet Information Services view.
The only difference between a Web project and a Basic MSI project was that a new Web project automatically contained a
predefined folder for the IISROOTFOLDER directory in the Files and Folders view. All of the files that you add to the
IISROOTFOLDER directory are installed to the Web server’s root directory on the target system. InstallShield adds
predefined folder for the IISROOTFOLDER directory to a Basic MSI project when you add a Web site to the project. Thus, a
Basic MSI project that contains at least one Web site configured in the Internet Information Services view is equivalent to a
Web project that was created in InstallShield 2009 or earlier.
Compact Projects
InstallShield no longer has support for Compact projects.
See Also
What’s New in InstallShield 2010
Upgrading from Earlier InstallShield Versions
The following information describes possible upgrade issues that may occur when you upgrade projects that were created
with InstallShield 2008 and earlier to InstallShield 2020. It also alerts you to possible changes in behavior that you may
notice between new InstallShield 2020 projects and projects that are upgraded from InstallShield 2008 or earlier to
InstallShield 2020.
General Information about Upgrading Projects that Were Created in Earlier Versions of
InstallShield
If you use InstallShield 2020 to open a project that was created with an earlier version, InstallShield 2020 displays a
message box that asks you if you want to convert the project to the new version. If you reply that you do want to convert it,
InstallShield creates a backup copy of the project with a file extension such as .766 before converting it. Delete the .766 part
from the original project’s file name if you want to reopen the project in the earlier version of InstallShield. Note that you
cannot open InstallShield 2020 projects in earlier versions of InstallShield.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2020: InstallShield
2008, InstallShield 12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and InstallShield
Developer 8 and earlier. Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal
cannot be upgraded to InstallShield 2020.
New Default Setup Launcher Value for New Releases: Windows Installer Is Not Included
When you create a new release in a Basic MSI or InstallScript MSI project, the redistributable for the Windows Installer
engine is no longer included by default:
• If you use the Release Wizard to create a new release, the Setup Launcher panel is where you specify whether to
include the Windows Installer. The default value for the Support these operating systems setting is Do not install
Windows Installer. Previously, the default value was Both Windows 9X and NT.
• If you create a new release by right-clicking the Releases explorer in the Releases view, the default value for the Setup
Launcher setting on the Setup.exe tab is now Yes (no MSI engine included). Previously, the default value for this
setting was Yes (include Windows NT & Windows 9x MSI engine).
This change applies to all new releases that are created in new InstallShield 2020 projects.
If you upgrade a project from InstallShield 2008 or earlier to InstallShield 2020, this change applies to all new releases;
InstallShield does not automatically change the value for releases that were originally created in the earlier InstallShield
version.
In addition, the Val0015 warning now checks the ISSelfReg table in QuickPatch projects and in patches that are created
through the Patch Design view in Basic MSI and InstallScript MSI projects. If a QuickPatch or patch project adds a row to the
ISSelfReg table, Val0015 warns you that the patch will be uninstallable. Previously, Val0015 did not check for entries in
this table.
File Compression for Files that Are Streamed into Setup.exe and ISSetup.dll at Build Time
If you build a release that uses a Setup.exe setup launcher or a ISSetup.dll file, InstallShield now compresses files that it
streams into the Setup.exe file or the ISSetup.dll file at build time. The default compression level that InstallShield uses
offers a balance between file size and time that is required to extract the compressed files at run time. This applies to new
Basic MSI and InstallScript MSI projects as well as existing Basic MSI and InstallScript MSI projects that are upgraded from
InstallShield 2008 or earlier to InstallShield 2020.
If you want to change the compression level or you do not want to use any compression, you can override the default level
through a machine-wide setting. For more information, see Configuring the Compression Level for Files that Are Streamed
into Setup.exe and ISSetup.dll.
Previously, InstallShield did not include any support for compressing files that were streamed into the Setup.exe file or the
ISSetup.dll file at build time. Thus, if you compare a release that was built in InstallShield 2008 or earlier with the same
release that is built with the default compression level in InstallShield 2020, you may notice that the file size of Setup.exe
or ISSetup.dll is slightly different. In addition, the time that is required to extract files may be slightly different.
You can modify the .cab size limit if necessary. In addition, if you do not want InstallShield to create multi-part .cab files,
you can configure it to create single .cab files. For more information, see Configuring the Maximum Size for .cab Files.
Previously, InstallShield did not create multi-part .cab files, and there was no built-in limit for the .cab file size.
The Standalone Build that is available with InstallShield Premier Edition now uses the same directory structure that
InstallShield uses.
The ISCmdBld.exe file that is used for command-line builds with InstallShield is now installed with the Standalone Build.
Previously, the Standalone Build used IsSaBld.exe, a different file, for command-line builds.
Note the following details about FlexNet Connect support in InstallScript projects:
• InstallShield does not add ISUS.obl to the list of libraries (or enable any other FlexNet Connect functionality) when
ISEnableUpdateService is changed to 1 in the InstallShield table. The ISUS.obl library is no longer supported.
• If you upgrade an InstallScript project from InstallShield 2008 or earlier to InstallShield 2020, InstallShield
automatically disables FlexNet Connect support and removes the ISUS.obl from the list of linked script libraries.
• The InstallScript constants and functions for FlexNet Connect still compile. However, all of the functions—except for
UpdateServiceGetAgentTarget—now return ISERR_NOT_IMPLEMENTED. UpdateServiceGetAgentTarget returns
null ("").
• All calls to the InstallScript functions for FlexNet Connect were removed from the default InstallScript code. In the
OnUpdateUIBefore event handler, the code for UpdateServiceOnEnabledStateChange was removed. In the
OnMoveData event handler, the code blocks for UpdateServiceRegisterProduct and UpdateServiceCreateShortcut
were removed.
Note that if you upgrade an InstallScript project from InstallShield 2008 or earlier to InstallShield 2020 and you had
overridden these events in the earlier version of your project, the aforementioned functions are called. This should not
cause any problems. The functions now return ISERR_NOT_IMPLEMENTED.
Also, the OnFirstUIAfter event handler was updated to not include the option of calling SdFinishUpdate, which was
disabled previously by default.
• All FlexNet Connect–related run-after-reboot functionality was removed. Therefore, the product is not registered with
FlexNet Connect after a reboot.
• When you build an InstallScript project, InstallShield no longer adds any FlexNet Connect–related files to the media.
• ISUS.obl will no longer be supported and thus will not be provided with the product.
All calls to the SetUpdateStatus and SetUpdateStatusReboot functions were removed from the default InstallScript
code.
Similarly, if a multilanguage minor upgrade or small update is run to update an earlier version of an already installed
product, the language selection dialog is not displayed. The upgrade dialogs are displayed in the same language that was
used to originally install the product.
This behavior helps ensure that the same language that was used to run the original installation and install its features is
also used to repair the original installation, as well as to add other features that were not originally installed but are
installed during maintenance mode or upgrades.
If multiple instances of a non-multi-instance installation are installed through the Setup.exe /ig command-line
parameter, the language selection dialog is displayed only during a first-time installation; it is not displayed during
maintenance mode. This helps ensure that the same language that was used to run the original installation and install its
features is also used to repair the original installation, as well as to add other features that were not originally installed but
are installed during maintenance mode.
During an InstallScript full-release installation that does not display the instance selection dialog—such as an installation
that is run in silent mode or with the Setup.exe -hide_usd command-line parameter—the installation automatically
installs a new instance. This behavior occurs for all new InstallShield 2020 projects, as well as projects that are upgraded
from earlier versions to InstallShield 2020. In InstallShield 2008, /hide_usd resulted in the first installed instance being
maintained, and silent mode resulted in a new instance being installed. In InstallShield 12 and earlier, the first installed
instance would be maintained in both the /hide_usd and silent mode scenarios.
During a non-multi-instance installation on a system where two or more instances are installed (using the Setup.exe /ig
command-line parameter), the instance selection dialog is displayed. The instance selection dialog does not allow a new
instance to be installed during a non-multi-instance installation because a non-multi-instance installation does not
generate a new random GUID for the new instance. The instance selection dialog includes the “default” instance (the
instance whose GUID matches the product code) if it installed and it is one of the instances that can be maintained. This
behavior applies to all new InstallShield 2020 projects, as well as projects that are upgraded from earlier versions of
InstallShield.
If a single instance is installed, the installation automatically attempts to maintain the installed instance; it does not show
the instance selection dialog. Note that is true even if the installed instance is not the default instance. As a result of this
behavior, if the default instance is not installed but a non-default instance is installed (using the /ig parameter), it is not
possible to install or maintain the default instance without (a) first uninstalling the non-default instance or (b) specifying
the GUID of the default instance through the /ig parameter. Therefore, if you support using the /ig parameter to install
multiple instances, it is recommended that you always use this parameter. This behavior applies to all new InstallShield
2020 projects, as well as projects that are upgraded from earlier versions of InstallShield.
For InstallShield 2008, if a non-multi-instance installation was run on a target system that had multiple instances installed,
the instance selection dialog was not displayed; in this case, the default instance was always used. For InstallShield 12 and
earlier, if a non-multi-instance installation was run on a target system that had multiple instances installed, the instance
selection dialog was displayed; this dialog did not allow a new instance to be displayed (because a non-multi-instance
installation does not generate a new random GUID for the new instance). However, the title bar of the dialog indicated that
the end user should select an instance to update; it should have indicated that the end user should select an instance to
update or maintain.
Therefore, when these InstallScript variables are set and retrieved, the corresponding Windows Installer properties are set
and retrieved. The default values for these variables are no longer read from the registry; instead the Windows Installer
properties are used by default. To use the previous functionality, you can set the variables manually through the following
sample code:
// Registered Owner (Only load from registry if pre-loaded value (from log file) is "")
if( !StrLengthChars( IFX_PRODUCT_REGISTEREDOWNER ) ) then
szValue = "";
RegDBGetItem( REGDB_WINCURRVER_REGOWNER, szValue );
if( StrLengthChars( szValue ) ) then
IFX_PRODUCT_REGISTEREDOWNER = szValue;
endif;
endif;
// Registered Company (Only load from registry if pre-loaded value (from log file) is "")
if( !StrLengthChars( IFX_PRODUCT_REGISTEREDCOMPANY ) ) then
szValue = "";
RegDBGetItem( REGDB_WINCURRVER_REGORGANIZATION, szValue );
if( StrLengthChars( szValue ) ) then
IFX_PRODUCT_REGISTEREDCOMPANY = szValue;
endif;
endif;
When a null string ("") is specified for either svName or svCompany for the any of the registration-related dialog functions
(SdRegisterUser, SdRegisterUserEx, SdCustomerInformation, or SdCustomerInformationEx), the functions use the
appropriate variable (determined from the corresponding Windows Installer property) as the default. Previously, the
variables were used only if both svName and svCompany were null; for SdCustomerInformation and
SdCustomerInformationEx, the values were read directly from the Windows Installer properties, bypassing the script
variables.
If a null string ("") is specified for the svSerial parameter, the default value for the serial number field is now set to
IFX_PRODUCT_REGISTEREDSERIALNUM. Previously in this case, the dialog displayed no value.
• DISABLE_PERUSERBTN—This existing variable indicates that the per-user radio button should be disabled (or
hidden) in cases that it would normally be enabled. This variable is always initialized to FALSE. Previously, this value
was initialized to TRUE on Windows 9x systems; otherwise, it was FALSE.
• DISABLE_ALLUSERBTN—This existing variable indicates that the all-user radio button should be disabled (or hidden)
in cases that it would normally be enabled. This variable is always initialized to FALSE. Previously, this value was
initialized to TRUE if the operating system was not Windows 9x and the end user was not an administrator or power
user.
• HIDE_DISABLED_BTNS—This new variable indicates that the all-user and per-user radio buttons should be hidden
instead of being disabled. The default value is TRUE. Note that if this variable is set to TRUE, both radio buttons are
hidden if either button is determined to be disabled.
The registration dialogs now automatically disable (or hide) the per-user radio button on Windows 9x regardless of the
value of DISABLE_ALLUSERBTN. Previously, the per-user radio button was disabled only if DISABLE_PERUSERBTN was
FALSE.
Note also that the registration dialogs automatically disable (or hide) the all-users radio button if the end user is not an
administrator or power user, regardless of the value of DISABLE_ALLUSERBTN. This behavior has not changed.
These changes apply to all new InstallScript MSI projects that are created in InstallShield 2020, as well as InstallScript MSI
projects that were created in earlier versions of InstallShield and then upgraded to InstallShield 2020.
If your end users access the Internet through a proxy server and your installation is configured to download files, the
installation now uses the system proxy settings that are manually configured in Internet Explorer during the download.
This occurs even if another browser on the target system is the default browser.
Note that InstallShield does not include support for the Automatically Detect Settings functionality in Internet Explorer. (If
end users have the Automatically Detect Settings check box selected in Internet Explorer for their LAN connection and the
installation needs to download files, the installation fails because the files cannot be downloaded. If it is possible that your
end users may have the Automatically Detect Settings check box selected in Internet Explorer for their LAN connections,
you may want to embed all of the files in your installation rather than configure them to be downloaded; if the files are
embedded, the failures can be avoided.) However, InstallShield does support the Automatic Configuration Script
functionality that is set up for LAN connections in Internet Explorer.
This is the behavior for all new projects in InstallShield 2020, as well as all projects that are created in earlier versions and
then upgraded to InstallShield 2020.
In InstallShield 2008 and earlier, the installation attempted to use the proxy server settings that were configured in
whatever browser was the default browser. However, this was not always possible, and it caused some problems:
• If Netscape 6 or 7 was the default browser, the Netscape 4 settings were used. If Netscape 8 or 9 was the default
browser, the system (Internet Explorer) settings were used.
• If Netscape 4 settings were used, only the proxy server list was read and imported correctly. The proxy bypass list was
read, but it was not imported correctly.
• Non–Internet Explorer 4 compatible settings such as the auto-proxy script setting were not imported.
• The method that the installation used for determining the default browser was not compatible on Windows Vista.
Therefore, on Windows Vista systems, an installation may not have detected the default browser correctly.
Web Downloader Option to Wrap a 1.x .msi Package into a .cab File Is No Longer Available
InstallShield no longer includes an option to specify that an .msi package should be wrapped into a .cab file. This option
was previously available for the Web Downloader type of media in Basic MSI and InstallScript MSI projects in which the
Windows Installer 1.1 or 1.2 was included. The recommended method is to use Windows Installer 2.0 or later and to
digitally sign the package.
Note that if you upgrade an InstallScript MSI project from InstallShield 2008 or earlier to InstallShield 2020 and you had
overridden one or more of the updated events in the earlier version of your project, you must manually add the
SetStatusExStaticText code to these events.
To use this functionality in an InstallScript MSI installation, any letters that are specified for the Key Name setting of the
folder in the Shortcuts view must be all uppercase (for example, NEWFOLDER1).
SHELL_OBJECT_FOLDER is now initialized to the same value as IFX_PRODUCT_NAME during initialization. Note that these
variables are not synchronized once initialized; therefore, if you change one and want the other to change, you must
change both manually.
Note that also as part of this change, the default OnFirstUIBefore event handler code in InstallScript MSI projects no longer
includes the following line of code:
SHELL_OBJECT_FOLDER = @PRODUCT_NAME;
If you have an InstallScript MSI project that was created in InstallShield 2008 or earlier and you modified the default
OnFirstUIBefore code, InstallShield does not remove this line from your code when you upgrade your project to
InstallShield 2020.
For example, if you create a new InstallScript project with default settings and add the following InstallScript code to your
project, the dialog that is displayed at run time does not display anything.
#include "ifx.h"
LIST listFiles;
program
endprogram
In installations that were created earlier versions of InstallShield, the dialog displayed DefaultComponent.
Note that changing the value of ISShowUpdateUI in the InstallShield table (which the previous option updated) no longer
has any effect.
• Override the OnSetUpdateMode event and update the function to return before setting the UPDATEMODE variable.
The installation never shows the update UI.
• Override the OnMaintUIBefore event and change the call for FeatureRemoveAllInMediaAndLog to
FeatureRemoveAllInMedia.
• The new name for the Certified for Windows Vista Validation Suite (plus InstallShield ICEs) is InstallShield Certified for
Windows Vista Validation Suite.
• The new name for the Certified for Windows Vista Merge Module Validation Suite (plus InstallShield ICEs) is
InstallShield Certified for Windows Vista Merge Module Validation Suite.
For more information about the validation and the Certified for Windows Vista program, see:
• Validating Projects
If you have an Internet connection, you can use the Check for Updates feature in InstallShield to obtain the updated
InstallScript objects and object templates for the version of InstallShield that you are using. To check for updates: On the
Tools menu, click Check for Updates. InstallShield launches a window or dialog, which checks for updates.
A Unicode setup launcher can correctly display double-byte characters in the user interface of the setup launcher,
regardless of whether the target system is running the appropriate code page for the double-byte-character language. An
ANSI setup launcher displays double-byte characters in the setup launcher dialogs if the target system is running the
appropriate code page. However, it displays garbled characters instead of double-byte characters in those dialogs if the
target system is not running the appropriate code page.
If you create a new release in a Basic MSI project in InstallShield 2020, the default setup launcher type is Unicode. In
addition, if you create a new patch configuration or a new QuickPatch project in InstallShield 2020, the default update
launcher type is Unicode.
If you upgrade a Basic MSI project from InstallShield 2008 or earlier to InstallShield 2020, the setup launcher type for any
existing releases is ANSI. You can override the type if appropriate.
Similarly, if you upgrade a Basic MSI project or a QuickPatch project from InstallShield 2008 or earlier to InstallShield 2020,
the update launcher type for any existing patch is ANSI. You can override the type if appropriate.
If you create a new dynamic file link in InstallShield 2020, InstallShield uses the best practice method by default.
All dynamic file links that are created in InstallShield 2008 or earlier use the one-component-per-directory method. If you
have a project with dynamic file links and you upgrade it from InstallShield 2008 or earlier to InstallShield 2020,
InstallShield continues to use the one-component-per-directory method for creating the components of those already
present dynamic file links. For any new dynamic file links that you create in the upgraded project, the best practice method
is used by default. For detailed information about the two component creation methods, as well as guidance on which
method you should use, see Determining the Appropriate Component Creation Method for Dynamically Linked Files.
If you add a new Web site through the Internet Information Services view in InstallShield 2020, InstallShield automatically
associates that Web site with a component. If you upgrade an InstallShield 2008 or earlier project that already has an IIS
Web site, InstallShield does not automatically associate that Web site with a component. Use the General tab that
InstallShield displays when you select a Web site in the Internet Information Services view if you want to associate the
selected Web site with a component.
Note that if a Web site is associated with a component, the Web site’s Delete Web Site on Uninstall check box now
corresponds with the Permanent setting for that component in a Basic MSI or InstallScript MSI project, or with the Uninstall
setting for that component in an InstallScript project. That is, if you select or clear the Delete Web Site on Uninstall check
box for a Web site, InstallShield automatically updates the value of the component’s Permanent setting or Uninstall
setting, as appropriate.
In some cases, InstallShield cannot streamline the QuickPatch package. For example, if you configure the QuickPatch
package to remove an installed file, InstallShield cannot streamline it.
When you create a new QuickPatch project, the default value for the Streamline QuickPatch setting is Yes. However, when
you upgrade a QuickPatch project from InstallShield 2008 or earlier to InstallShield 2020, the value for this setting is No.
You can change this value if appropriate. For more information, see Specifying Whether to Streamline the QuickPatch
Package.
Earlier versions of InstallShield permitted you to enter invalid values. If you upgrade an InstallShield 2008 or earlier project
to InstallShield 2020, InstallShield does not automatically change the invalid value. However, you can manually update the
value if appropriate. For more information, see Using the Template Summary Property.
See Also
What’s New in InstallShield 2009
Upgrading from Earlier InstallShield Versions
The following information describes changes that may affect projects that are upgraded from InstallShield 12 or earlier to
InstallShield 2020.
You can upgrade projects that were created with the following versions of InstallShield to InstallShield 2008: InstallShield
12 and earlier, InstallShield DevStudio, InstallShield Professional 7 and earlier, and InstallShield Developer 8 and earlier.
Note that projects that were created with InstallShield MultiPlatform or InstallShield Universal cannot be upgraded to
InstallShield 2008.
End of Support for Windows 9x, Windows NT 4, and Windows Me on Target Systems
InstallShield no longer supports the creation of installations for Windows 9x, Windows NT 4, and Windows Me systems. If
end users have one of these operating systems on their computer and they try to run an installation that was built with
InstallShield 2020, unexpected results may occur, unless the project includes launch conditions that prevent end users
from running the installation on any of these legacy operating systems.
For Basic MSI and InstallScript MSI projects, you may want to consider adding launch conditions that display a message if
end users are running your installation on any of the legacy systems. For InstallScript projects, you may want to consider
adding InstallScript code that uses the SYSINFO structure variable to check for these legacy systems, and then display a
message if any of these legacy systems are present.
• Platforms Tab
COM Extraction
When you use InstallShield to extract COM information from a COM server, InstallShield puts the data in the Registry table,
instead of in the TypeLib table. Microsoft strongly advises against using the TypeLib table.
Unused Directories Automatically Removed from .msi File at Build Time by Default
Note that if you upgrade a Basic MSI, InstallScript MSI, or Merge Module project that was created in InstallShield 12 or
earlier to InstallShield 2020, the new Keep Unused Directories setting on the Build tab in the Releases view is set to No.
Therefore, if a directory that is listed in the Directory column of the Directory table is not referenced in any known location
in the .msi file, InstallShield removes it from the Directory table of the .msi file that it creates at build time. For Basic MSI
and InstallScript MSI projects, this occurs after any merge modules are merged, but only directories that are present in the
.msi file are removed; therefore, if a merge module contains new unused directories in its Directory table, the new unused
directories are added to the installation.
If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2020, InstallShield does not
automatically change the value of the ALLUSERS property or add this property if it was not defined in the earlier project.
Also new with InstallShield 2008, by default, the CustomerInformation dialog in all new Basic MSI projects does not display
the radio button group that enables end users to specify whether they want to install the product for all users or for only
the current user. This is the recommended implementation for this dialog.
If you upgrade a project that was created with InstallShield 12 or earlier to InstallShield 2020, InstallShield does not
automatically change the CustomerInformation dialog.
• ALLUSERS
Windows Server 2003 Conditions and 64-Bit Windows XP Conditions for Setup
Prerequisites
The operating system version number is 5.2 for both Windows Server 2003 and 64-bit Windows XP. As a result, prerequisites
that were created in InstallShield 12 and that required Windows Server 2003 could be installed on 64-bit Windows XP
systems, and those that required Windows XP could not be installed on 64-bit Windows XP systems.
To resolve this issue, the Setup Prerequisite Editor in InstallShield 2008 has been enhanced to enable you to specify
whether the target system is required to be a workstation, a server, or a domain controller.
To resolve this issue for an existing prerequisite that includes a Windows Server 2003 requirement or a 64-bit Windows XP
requirement, open the prerequisite in the Setup Prerequisite Editor in InstallShield 2008. On the Conditions tab, select the
condition that needs to be corrected and click Modify. In the Select which platform the prerequisite should be run on
box, select the appropriate operating system requirement. Doing this correctly sets the new Product (OS) Type setting to
the appropriate workstation, server, or domain controller value.
Automation Interface
The Display Save Options dialog setting was removed from the Releases view. Therefore, the WebSaveOptionsDlg
property, which corresponds with that setting, is no longer available for the ISWiRelease object of automation interface.
New Default Value for the Cache Path Setting for a Release
The default value for the Cache Path setting for a compressed release in the Releases view is now set to
[LocalAppDataFolder]Downloaded Installations. The previous default value was [WindowsFolder]Downloaded
Installations, which may not be available to users on locked-down systems. If you migrate a project from InstallShield 12
or earlier to InstallShield 2020, the Cache Path setting is not automatically changed. Therefore, you may want to change
that value.
All functionality that is related to the Save And/or Run Setup dialog box has been removed from InstallShield. If you want to
give end users the option of downloading and saving the installation (or creating an icon on the desktop), you need to
implement this within your installation’s Web page, and handle the download and save operations through the Web page.
To pass data to a launched One-Click Install installation, use the is::CmdLine parameter and the CMDLINE script variable.
Previously, it was possible to pass data from the Web page to the installation; however, this support has been removed.
Note that the only valid value for the first parameter of SetProperty is now is::CmdLine.
To learn more about One-Click Install installations, see One-Click Install Installations in InstallScript Projects.
DemoShield Support
DemoShield is no longer being sold. In addition, it is no longer supported. Therefore, InstallShield no longer includes any
DemoShield integration.
• The new name for the Windows Vista Quality Validation Suite (plus InstallShield ICEs) is Certified for Windows Vista
Validation Suite (plus InstallShield ICEs).
• The new name for the Windows Vista Quality Merge Module Validation Suite (plus InstallShield ICEs) is Certified for
Windows Vista Merge Module Validation Suite (plus InstallShield ICEs).
In addition, three of the InstallShield ICEs have been moved to the InstallShield Best Practice Suite.
For more information about the validation and the Certified for Windows Vista program, see:
• Validating Projects
To learn about the validators that are now available as InstallShield Best Practices, see:
See Also
What’s New in InstallShield 2008
Upgrading from Earlier InstallShield Versions
For InstallShield 12, a number of improvements were made to the InstallScript MSI architecture to resolve issues with
security (COM/DCOM) and other areas that can cause some installations to fail for various reasons. The architecture was
improved for InstallShield 12 to resolve these issues and to make InstallScript MSI a more reliable project type. The
improvements also help increase the reliability of InstallScript projects, as well as Basic MSI projects that include
InstallScript custom actions.
The following table compares the earlier design with the current design:
Each InstallScript custom action is handled by Each InstallScript custom action is handled by
ISScriptBridge.dll (a C++ MSI DLL), which forwards ISSetup.dll (a single C++ MSI DLL), which contains the full
actual script execution to the ongoing IDriver.exe InstallScript engine.
process.
A set of engine files is required. They must be installed by No engine files or ISScript.msi file is required.
ISScript.msi before the primary installation begins. ISSetup.dll is self-contained.
All InstallScript custom actions execute in a shared Each InstallScript custom action is independent and has
IDriver.exe process. The IDriver.exe process remains its own self-contained lifecycle. From the custom action
resident until a final shutdown custom action is required. entry point, ISSetup.dll starts the script engine, executes
the relevant script, and shuts down the engine.
• End users no longer encounter error 1607, error 1608, or other COM/DCOM run-time errors that are related to finding
the running IDriver.exe file. When these errors occurred under the earlier model, they were difficult to resolve, often
requiring changes to DCOM settings. Also, the reliance on the running object table made the model brittle across the
spectrum of usage scenarios, including Fast User Switching and Windows Terminal Services.
• The engine binding is static. No shared engine files are installed to Program Files\Common Files\InstallShield.
The reliance in InstallShield 11.5 and earlier on shared engine files made the model brittle because separate
installations were not isolated. Changes to one engine version could break an existing installation. Isolation,
especially for an installer, is one key to reliability.
• The ISScript.msi file (the InstallScript engine installer) is no longer needed. The earlier model required an
ISScript.msi file to execute prior to the primary .msi file. Because the full application was not contained in a single
.msi file, the installation essentially required a bootstrap for Basic MSI installations that had InstallScript custom
actions. This was very inflexible for enterprises that use Active Directory for managed environments. Also, it was
confusing for advanced users who expect the main .msi file to be self-contained. InstallScript MSI installations still
require a bootstrap, so that requirement is no different than the earlier architecture; however, Basic MSI installations
with InstallScript custom actions no longer require a bootstrap.
• Fewer InstallShield custom actions are needed to run the installation. The earlier model relied on a deep coupling
between startup and shutdown custom actions that could easily fail. If one of the required custom actions was
deleted or moved, the installation would not work properly.
• InstallScript events are not available in Basic MSI and merge module projects; therefore, all InstallScript code for these
project types must be run by InstallScript custom actions. Global variables do not share state between these custom
action invocations. Therefore, you can declare a global variable in one InstallScript custom action script and then use
that global variable throughout the script. However, if your Basic MSI installation has a second InstallScript custom
action, the global variable declared in the first script is not available to the second script.
With the earlier model, InstallScript developers were able to use script code in any of the InstallScript events in Basic
MSI projects, and any InstallScript global variables shared state. This allowed setup authors to write custom actions
with a more holistic view and sense of continuity across the installation. However, because global variables are
generally discouraged in programming, the new limitation should actually result in better-written InstallScript code.
• In-memory objects must be serialized in order to be shared between custom action invocations. With the earlier
model, InstallScript developers could store complex object-based data in global variables. As with the
aforementioned disadvantage, this may actually result in better InstallScript code.
1. Before you convert your project, create a backup version of your project file and any InstallScript files.
3. On the File menu, click Open. The Open dialog box opens.
4. Browse to select the project file (.ism) of the InstallShield 11.5 or earlier project that you want to upgrade. A dialog box
opens, prompting you to specify whether you want to upgrade the project.
5. Click Yes.
InstallShield upgrades your project and saves a backup copy of the project file (.ism).
To learn about possible manual changes that you may need to make to upgraded projects, see the following:
• Upgrading InstallShield 11.5 or Earlier Basic MSI Projects that Have InstallScript Custom Actions
• Upgrading InstallShield 11.5 or Earlier QuickPatch Projects that Have InstallScript Custom Actions
• Creating Standard Patches for InstallShield 11.5 and Earlier InstallScript MSI Projects
• Upgrading InstallShield 11.5 or Earlier InstallScript MSI Object Projects or Projects that Contain This Type of Object
See Also
Global vs. Local Variables
The following sections explain details about upgrading Basic MSI projects that were created in InstallShield 11.5 or earlier
to InstallShield 2020.
A major implication of this change in behavior is that global variables and pointers are no longer maintained between
individual InstallScript custom action calls:
• If you need to store a value across multiple custom action calls, you must use some external mechanism such as the
registry, Windows Installer properties, or an external data file to store the information between calls. If you choose to
use Windows Installer properties in deferred, commit, or rollback InstallScript custom actions, see the guidelines in
Windows Installer Properties and Deferred, Commit, and Rollback InstallScript Custom Actions.
• If you need to use a COM object or some other global object across custom action calls, you must initialize the object
for each individual custom action call in order for the object to be valid.
Another implication of this change is that each custom action initializes and uses its own individual SUPPORTDIR. Therefore,
you cannot share information across individual calls using files in SUPPORTDIR, since each custom action invocation will
have its own unique SUPPORTDIR. You can share information using FOLDER_TEMP or some other file location.
Note that FOLDER_TEMP may not be the same path for all of your InstallScript custom actions. If you have some InstallScript
custom actions that run in system context and some that do not, they will have different temp paths if the package is
running in an elevated state. The InstallScript custom actions run in the context of a different user, so storing files in the
temp directory and retrieving it later may not work in certain scenarios.
Windows Installer Properties and Deferred, Commit, and Rollback InstallScript Custom
Actions
Deferred, commit, and rollback InstallScript custom actions in Basic MSI installations have access to only some of the built-
in Windows Installer properties: CustomActionData, ProductCode, and UserSID. If you want an InstallScript custom action
to access any other properties (such as SUPPORTDIR) during deferred, commit, or rollback execution, you need to pass them
as CustomActionData. You can do so by scheduling an immediate set-a-property type of custom action (or, for example, an
immediate InstallScript custom action with the MsiSetProperty function) to set a property that matches the name of the
custom action. The value of this property is then available in the CustomActionData property within the deferred custom
action.
For example, if you want to access a property such as SUPPORTDIR, you could create an immediate custom action that is
called MyCustomActionName and that sets the MyCustomActionName property to [SUPPORTDIR], and then substitute
"SUPPORTDIR" with "CutomActionData" in the MsiGetProperty call:
• Accessing or Setting Windows Installer Properties Through Deferred, Commit, and Rollback Custom Actions
Note that failure to compensate for an unavailable Windows Installer property may cause unexpected results during
installation. For example, since in a deferred action, MsiGetProperty(hMSI, "INSTALLDIR", szInstallDir, nLen) sets
szInstallDir to the empty string, szInstallDir ^ szFile may refer to a file in the current directory instead of a file in
[INSTALLDIR]. The current directory for a deferred custom action is often [SystemFolder].
Deferred, commit, and rollback InstallScript custom actions do not have access to the ProductLanguage property. If your
installation includes multilanguage support and it also has a deferred, commit, or rollback InstallScript custom action that
needs access to the language in which the end user is running the installation, the installation assumes that this language
is the installation’s default language. This could be a problem if an end user runs the installation in a language other than
the default language. However, deferred, commit, and rollback custom actions do not typically display any user interface,
so this would usually not be a problem.
• OnBegin
• OnMoving
• OnMoved
• OnEnd
InstallShield no longer supports these event handler functions for Basic MSI projects that have InstallScript custom
actions. They are not called once the project is rebuilt with InstallShield 12 and later. Note that these event handler
functions still compile in InstallShield 12 and later; they are just not called.
If you use these event handler functions in your project, you need to manually schedule custom actions that call these
functions. To learn how, see Creating and Scheduling InstallScript Custom Actions that Call InstallScript Event Handlers for
Basic MSI Projects.
If you use InstallShield 2020 to try to build a release for a project that has this merge module, you may encounter a build
error such as the following one:
ISDEV : error -4075: File not found. An error occurred merging Module
'InstallShieldScriptingEngine.4F635B62_07BF_4779_B74E_D80C29D508E3:0' for Feature 'NewFeature1'.
To resolve this build error, remove this merge module from your project; you can do so by clearing its check box in the
Redistributables view.
<COMMONFILES>\InstallShield\Driver\<Version>\Intel 32
For InstallShield 11.5 and earlier Basic MSI projects with InstallScript custom actions, several files were stored in the
Binary table:
• Setup.inx
• Isconfig.ini
• Isrt.dll
• ISScriptBridge.dll
• _isresXXXX.dll (where XXXX is the language—one .dll was included for each language included in the installation)
• StringxXXXX.txt (where XXX is the language—one .txt was included for each language in the installation)
For InstallShield 12 and later, all of these files (except ISScriptBridge.dll, which is no longer used) are stored inside the
ISSetup.dll file, and that is the only file that is stored in the Binary table.
The InstallScript engine file changes have not been known to cause any upgrade issues. These changes are reported for
informational purposes.
See Also
Run-Time Behavior for Basic MSI Installations with InstallScript Custom Actions
Upgrading Projects from InstallShield 11.5 or Earlier
Creating and Scheduling InstallScript Custom Actions that Call InstallScript Event Handlers for
Basic MSI Projects
InstallShield 2020
For InstallShield 12 and later, the predefined InstallScript event handler functions are no longer available in Basic MSI
projects with InstallScript custom actions. In InstallShield 11.5 and earlier, the following InstallScript event handler
functions were available for Basic MSI projects and InstallScript MSI object projects:
• OnBegin
• OnMoving
• OnMoved
• OnEnd
InstallShield no longer supports these event handler functions for Basic MSI projects that have InstallScript custom
actions. They are not called once the project is rebuilt with InstallShield 2020. Note that these event handler functions still
compile in InstallShield 2020; they are just not called.
Similarly, these same predefined InstallScript event handler functions are not supported in InstallScript MSI object projects
that are converted to merge module projects automatically when they are opened in InstallShield 2020. The functions are
not called once the converted merge module project is built in InstallShield 2020.
If you have these events in your Basic MSI or InstallScript MSI object project and you upgrade your project to InstallShield
2020, you need to manually schedule custom actions that call the event handler functions. The following instructions
explain how to do so.
Task To manually schedule InstallScript custom actions that call the predefined InstallScript event handler functions:
b. Find the OnBegin, OnMoving, OnMoved, and OnEnd event handler functions in your script. You can quickly find a
function by clicking the function name in the center pane of the view.
c. Rename the functions to an alternate name to avoid conflicts with existing function prototypes automatically
included in ifx.h. For example:
• MyOnBegin
• MyOnMoving
• MyOnMoved
• MyOnEnd
d. Update the existing functions to take a single HWND parameter. For example:
3. Add InstallScript custom actions that call your renamed InstallScript event handler functions:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI projects) or
Custom Actions (in merge module projects).
b. In the center pane, right-click the Custom Actions explorer and then click New InstallScript. InstallShield adds
an InstallScript custom action.
c. Type a name for the custom action; use the same name that you used to rename the InstallScript functions. For
example:
• MyOnBegin
• MyOnMoving
• MyOnMoved
• MyOnEnd
e. Set the Function Name setting to the name of the InstallScript function.
f. For the In-Script Execution setting, specify the value that is indicated in the table below.
4. Schedule the InstallScript custom action for the appropriate part of the installation:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences.
b. Right-click the action or dialog that you want your InstallScript custom action to follow and click Insert. The
Insert Action dialog box opens, providing a list of all the actions and dialogs that are currently associated with
your project.
c. Select the InstallScript custom action that you created. If appropriate, enter a condition in the Condition box for
launching the InstallScript event.
d. Click OK.
To match the previous functionality as closely as possible, set the in-script execution in step 3f and schedule the
InstallScript custom actions in step 4b as follows:
MyOnBegin Immediate (default) One of the first actions in the Installation User Interface sequence.
MyOnMoving Deferred in system In the Installation Execution sequence, between the InstallInitialize and
context AllocateRegistrySpace actions.
MyOnMoved Deferred in system In the Installation Execute sequence, between the ScheduleReboot and
context InstallFinalize actions.
MyOnEnd Immediate (default) The last event in the Installation Execute sequence after the InstallFinalize
action. (In previous releases, OnEnd was called after all other events as a
result of the installation completing.)
• Global variables and pointers are no longer maintained between individual InstallScript custom action calls. In
addition, each InstallScript custom action initializes and uses its own individual SUPPORTDIR. Therefore, you cannot
share information across individual calls using files in SUPPORTDIR. For more information, see Global Variables, Global
Pointers, and SUPPORTDIR.
• Most Windows Installer properties are not available to deferred, commit, and rollback InstallScript custom actions.
For more information, see Windows Installer Properties and Deferred, Commit, and Rollback InstallScript Custom
Actions.
The following sections explain details about upgrading InstallScript MSI projects that were created in InstallShield 11.5 or
earlier to InstallShield 2020.
However, for InstallShield 12 and later, when a function within the InstallScript is called by the Windows Installer engine as
an InstallScript custom action, the custom action behaves like an InstallScript custom action in a Basic MSI installation.
That is, the function is executed in a completely separately loaded script instance; the script is loaded before the action is
called and unloaded after the action completes. Thus, each InstallScript function that is called by the Windows Installer
engine as an InstallScript custom action executes in its own session with complete InstallScript engine loading and
unloading. This behavior is different than with InstallShield 11.5 and earlier: the custom actions were called in the single
main loaded script file instance that was loaded during initialization and unloaded at the end of the installation.
A major implication of this change in behavior is that InstallScript functions that are called as InstallScript custom actions
no longer have access to global variables and pointers that are maintained by the main executing script file:
• If you need to interact with the main executing InstallScript file to perform tasks such as using or changing global
variables or modifying objects that are maintained by the main executing script file (which includes updating the
status bar or logging script operations for uninstallation), your function must be called from an InstallScript event—
not as an InstallScript custom action. Functions that are called from InstallScript events are executed in the main
InstallScript instance. (Exception: Some InstallScript error events such as OnFilesInUse are called as a result of an
error message from the Windows Installer engine. The Windows Installer engine launches these InstallScript error
events as InstallScript custom actions; thus, the limitations of InstallScript custom actions also apply to these
InstallScript events.)
• If you need to store a value across multiple InstallScript custom action calls, you must use some external mechanism
such as the registry, Windows Installer properties, or an external data file to store the information between calls. If you
choose to use Windows Installer properties in deferred, commit, or rollback InstallScript custom actions, see the
guidelines in Windows Installer Properties and Deferred, Commit, and Rollback InstallScript Custom Actions.
• If you need to use a COM object or some other global object across custom action calls, you must initialize the object
for each individual custom action call in order for the object to be valid.
Another implication of this change is that each custom action initializes and uses its own individual SUPPORTDIR. Therefore,
you cannot share information across individual calls using files in SUPPORTDIR, since each custom action invocation will
have its own unique SUPPORTDIR. You can share information using FOLDER_TEMP or some other file location.
Note that FOLDER_TEMP may not be the same path for all of your InstallScript custom actions. If you have some InstallScript
custom actions that run in system context and some that do not, they will have different temp paths if the package is
running in an elevated state. The InstallScript custom actions run in the context of a different user, so storing files in the
temp directory and retrieving it later may not work in certain scenarios.
Windows Installer Properties and Deferred, Commit, and Rollback InstallScript Custom
Actions
Deferred, commit, and rollback InstallScript custom actions in InstallScript MSI installations have access to only some of
the built-in Windows Installer properties: CustomActionData, ProductCode, and UserSID. If you want an InstallScript
custom action to access any other properties (such as SUPPORTDIR) during deferred, commit, or rollback execution, you
need to pass them as CustomActionData. You can do so by scheduling an immediate set-a-property type of custom action
(or, for example, an immediate InstallScript custom action with the MsiSetProperty function) to set a property that
matches the name of the custom action. The value of this property is then available in the CustomActionData property
within the deferred custom action.
For example, if you want to access a property such as SUPPORTDIR, you could create an immediate custom action that is
called MyCustomActionName and that sets the MyCustomActionName property to [SUPPORTDIR], and then substitute
"SUPPORTDIR" with "CutomActionData" in the MsiGetProperty call:
• Accessing or Setting Windows Installer Properties Through Deferred, Commit, and Rollback Custom Actions
Note that failure to compensate for an unavailable Windows Installer property may cause unexpected results during
installation. For example, since in a deferred action, MsiGetProperty(hMSI, "INSTALLDIR", szInstallDir, nLen) sets
szInstallDir to the empty string, szInstallDir ^ szFile may refer to a file in the current directory instead of a file in
[INSTALLDIR]. The current directory for a deferred custom action is often [SystemFolder].
Deferred, commit, and rollback InstallScript custom actions do not have access to the ProductLanguage property. If your
installation includes multilanguage support and it also has a deferred, commit, or rollback InstallScript custom action that
needs access to the language in which the end user is running the installation, the installation assumes that this language
is the installation’s default language. This could be a problem if an end user runs the installation in a language other than
the default language. However, deferred, commit, and rollback custom actions do not typically display any user interface,
so this would usually not be a problem.
Note that now calling DoInstall is similar to calling LaunchAppAndWait. When the installation is run from any removable
media, such as a CD-ROM or a floppy disk, the Setup.exe file on Disk1 may not be available during the entire installation. (If
Setup.exe becomes unavailable while it is running, the operating system sometimes displays a prompt to request that the
end user insert the correct disk, and this may cause the installation to fail.) Therefore, to avoid this problem, the Setup.exe
file is copied to a Temp folder, and the installation is relaunched from there. The original Setup.exe then terminates.
However, when this happens, DoInstall (or LaunchAppAndWait, if it is called) behaves as if the installation has completed,
and it does not wait.
Several workarounds for this issue exist. One method is to use the /Clone_wait parameter when you are launching the
child installation; as a result of this workaround, the launched installation keeps the original launched process running,
and the parent installation then waits. Note, however, that this may cause problems if the original CD containing
Setup.exe is not available throughout the entire installation. This includes multiple-CD installations, where the first CD is
not available during some parts of the installation.
The only other way to avoid this problem is to add code that determines the ID of the child processes of the launched
process and wait for the child process to complete.
ISScript<version>.msi
In InstallShield 12 and later, the following file is placed on the Disk1 image of the built installation:
ISSetup.dll
The Disk1 file changes have not been known to cause any upgrade issues. These changes are reported for informational
purposes.
<COMMONFILES>\InstallShield\Professional\Runtime\<MajorVersion>\<MinorVersion>\Intel32
For InstallShield 11.5 and earlier InstallScript MSI projects, several files were stored in the Binary table:
• Setup.inx
• Isconfig.ini
• Isrt.dll
• ISScriptBridge.dll
• _isresXXXX.dll (where XXXX is the language—one .dll was included for each language included in the installation)
• StringxXXXX.txt (where XXX is the language—one .txt was included for each language in the installation)
For InstallShield 12 and later, all of these files (except ISScriptBridge.dll, which is no longer used) are stored inside the
ISSetup.dll file, and that is the only file that is stored in the Binary table.
The InstallScript engine file changes have not been known to cause any upgrade issues. These changes are reported for
informational purposes.
For more information, see Creating and Scheduling InstallScript Custom Actions that Call InstallScript Event Handlers for
InstallScript MSI Projects.
See Also
Run-Time Behavior for InstallScript MSI Installations
Upgrading Projects from InstallShield 11.5 or Earlier
Creating and Scheduling InstallScript Custom Actions that Call InstallScript Event Handlers for
InstallScript MSI Projects
InstallShield 2020
Several built-in InstallScript-related custom actions were eliminated in InstallShield 12 for InstallScript MSI projects. If you
upgrade an InstallScript MSI project from InstallShield 11.5 or earlier to InstallShield 2020, InstallShield removes these
built-in custom actions from your project. Because these custom actions have been removed, some existing InstallScript
events that were previously called by the custom actions are now called directly from InstallScript. This article identifies
the eliminated custom actions and explains how add custom actions that call these InstallScript events so that the
scheduling is similar to the scheduling used in InstallShield 11.5 and earlier.
The eliminated custom actions also may affect your InstallScript MSI installation if you allow the installation to run without
the Setup.exe file so that the packages can be deployed through technologies such as Active Directory. The procedure for
implementing this is described in Knowledge Base article Q108166 - HOWTO: Deploying an MSI Wrapped with an
InstallShield Script-Based Setup.exe. Note that if you follow the procedure that is described in that article and end users
launch the .msi file directly, some of the InstallScript events are never called. The reason that they are not called is that
some of the InstallScript event handler functions that were previously called by built-in InstallScript-related custom
actions are not called, since the InstallScript-related custom actions have been removed. If you configure your installation
according to the Q108166 article, you may also need to follow the instructions below to add custom actions that call the
built-in InstallScript events.
The following built-in InstallScript-related custom actions were eliminated in InstallShield 12. They are removed from
InstallScript MSI projects when they are upgraded from InstallShield 11.5 or earlier to InstallShield 2020:
• ISCleanupSuccess
• ISCleanUpSuspend
• ISCleanUpUserTerminate
• ISCleanupFatalExit
• ISMsiServerStartup
• ISRebootPatchHandler
• ISRollbackCleanup
• ISStartup
• OnCheckSilentInstall (For details about changes for this custom action, see OnCheckSilentInstall.)
• OnFeaturesInstalled
• OnFeaturesInstalling
• OnInstallFilesActionAfter
• OnInstallFilesActionBefore
• OnMoved
• OnMoving
Because these custom actions have been removed, some existing InstallScript event handlers that were previously called
by the custom actions are now called directly from InstallScript. This includes the following InstallScript event handlers
that are called immediately before file transfer:
• OnGeneratedMSIScript
• OnGeneratingMSIScript
• OnInstallFilesActionBefore
• OnMoving
It also includes the following InstallScript event handlers that are called immediately after file transfer:
• OnMoved
• OnInstallFilesActionAfter
These changes were made to make global variables and global pointers available for these InstallScript event handler
functions. However, because previously the events were called from custom actions, the sequence of these events in
relation to other custom actions that are called directly by Windows Installer has changed. Therefore, you may need to
adjust your InstallScript code appropriately to account for these changes.
Except in the case of the feature event handlers, it is also possible to add custom actions that call these event handler
functions so that the scheduling is similar to the scheduling used in InstallShield 11.5 and earlier. However, global variables
and global pointers are not maintained between calls, as discussed in the Global Variables, Global Pointers, and
SUPPORTDIR section.
Task To manually schedule an InstallScript custom action that calls a predefined InstallScript event handler function:
b. Find the event handler function in your script. You can quickly find a function by clicking the function name in the
center pane of the view.
c. Rename the function to an alternate name to avoid conflicts with existing function prototypes automatically
included in ifx.h. For example:
• MyOnGeneratingMSIScript
• MyOnMoving
• MyOnMoved
d. Update the existing function to take a single HWND parameter. For example:
3. Add an InstallScript custom action that calls your renamed InstallScript event handler function:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences.
b. In the center pane, right-click the Custom Actions explorer and then click New InstallScript. InstallShield adds
an InstallScript custom action.
c. Type a name for the custom action; use the same name that you used to rename the InstallScript function. For
example:
• MyOnGeneratingMSIScript
• MyOnMoving
• MyOnMoved
e. Set the Function Name setting to the name of the InstallScript function.
f. For the In-Script Execution setting, specify the value that is indicated in the table below.
4. Schedule the InstallScript custom action for the appropriate part of the installation:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences.
b. Right-click the action or dialog that you want your InstallScript custom action to follow and click Insert. The
Insert Action dialog box opens, providing a list of all the actions and dialogs that are currently associated with
your project.
c. Select the InstallScript custom action that you created. If appropriate, enter a condition in the Condition box for
launching the InstallScript event.
d. Click OK.
To match the previous functionality as closely as possible, set the in-script execution in step 3f and schedule the
InstallScript custom actions in step 4b as follows:
In-Script
Custom Action Execution Location in the Sequence
OnMoving Deferred in In the Installation Execute sequence between the InstallInitialize and
system context AllocateRegistrySpace actions
OnFeaturesInstalling, Deferred in In the Installation Execute sequence between the InstallInitialize and
which calls all the feature system context AllocateRegistrySpace actions (after OnMoving)
Installing and Uninstalling
events that are defined.
Note: This will not have any
effect, as explained above.
OnInstallFilesActionBefore Deferred in In the Installation Execute sequence between the MoveFiles and
system context InstallFiles actions
OnFeaturesInstalled, which Deferred in In the Installation Execute sequence between the ScheduleReboot
calls all the feature system context and InstallFinalize actions (before OnMoved)
Installed and Uninstalled
events that are defined.
Note: This will not have any
effect, as explained above.
OnInstallFilesActionAfter Deferred in In the Installation Execute sequence between the InstallFiles and
system context PatchFiles actions
In-Script
Custom Action Execution Location in the Sequence
• Global variables and pointers are no longer maintained between individual InstallScript custom action calls. In
addition, each InstallScript custom action initializes and uses its own individual SUPPORTDIR. Therefore, you cannot
share information across individual calls using files in SUPPORTDIR. For more information, see Global Variables, Global
Pointers, and SUPPORTDIR.
• Most Windows Installer properties are not available to deferred, commit, and rollback InstallScript custom actions.
For more information, see Windows Installer Properties and Deferred, Commit, and Rollback InstallScript Custom
Actions.
OnCheckSilentInstall
In InstallShield 11.5 and earlier, the OnCheckSilentInstall custom action automatically called the OnMsiSilentInstall
InstallScript event if the InstallScript MSI installation was being installed silently without using Setup.exe (for example, if
the following command-line was used: Msi.exe /i<Package> /qn). In InstallShield 12 and later, this event is not called in
InstallScript MSI installations. However, you can add a custom action that calls the OnMsiSilentInstall event handler
function. To do so, use the aforementioned instructions, noting the following scheduling requirements in steps 3f and 4b:
In-Script
Custom Action Execution Location in the Sequence
Also, to require that the InstallScript event run only in the expected scenario, add the following code to the event:
cchValueBuf = MAX_PATH;
// Check whether Setup.exe is being used, if so just return.
MsiGetProperty(nHandle, "ISSETUPDRIVEN", szValueBuf, cchValueBuf);
if(StrLengthChars(szValueBuf)) then
return ISERR_SUCCESS;
endif;
The following sections explain details about upgrading InstallScript projects that were created in InstallShield 11.5 or
earlier to InstallShield 2020.
If you upgrade an InstallScript project to InstallShield 2020, all references to any InstallShield objects are updated to point
to the InstallShield 2020 versions of the objects. If the new version object is not present on the system, an error indicating
that the object could not be found is displayed at build time.
For instructions on acquiring the InstallShield 2020 objects, see Obtaining Updates for InstallShield.
Note that now calling DoInstall is similar to calling LaunchAppAndWait. When the installation is run from any removable
media, such as a CD-ROM or a DVD, the Setup.exe file on Disk1 may not be available during the entire installation. (If
Setup.exe becomes unavailable while it is running, the operating system sometimes displays a prompt to request that the
end user insert the correct disk, and this may cause the installation to fail.) Therefore, to avoid this problem, the Setup.exe
file is copied to a Temp folder, and the installation is relaunched from there. The original Setup.exe then terminates.
However, when this happens, DoInstall (or LaunchAppAndWait, if it is called) behaves as if the installation has completed,
and it does not wait.
Several workarounds for this issue exist. One method is to use the /Clone_wait parameter when you are launching the
child installation; as a result of this workaround, the launched installation keeps the original launched process running,
and the parent installation then waits. Note, however, that this may cause problems if the original CD containing
Setup.exe is not available throughout the entire installation. This includes multiple-CD installations, where the first CD is
not available during some parts of the installation.
The only other way to avoid this problem is to add code that determines the ID of the child processes of the launched
process and wait for the child process to complete.
Setup.exe Changes
The /deleter command-line parameter for Setup.exe is no longer needed. If you specify this parameter, the installation
will not run. Note that InstallScript installations no longer clone the installation immediately when they are launched
(unless, for example, the installation is running from the temp folder because the /runfromtemp parameter is specified), so
/deleter is no longer needed.
The /clone_nowait command-line parameter for Setup.exe is no longer needed. If you specify this parameter, Setup.exe
ignores it. Note that InstallScript installations no longer wait for the cloned installation to complete by default unless the /
Clone_wait parameter is specified. For more information on /Clone_wait, see Setup.exe and Update.exe Command-Line
Parameters.
Like InstallScript MSI and Basic MSI installations, InstallScript’s Setup.exe file returns meaningful return codes. Therefore,
if you are checking the return value of Setup.exe, in InstallShield 11.5 and earlier, it would always be 0; in InstallShield 12
and later, Setup.exe returns an appropriate return value. For details on the possible return codes, see Setup.exe Return
Values and Run-Time Errors (InstallScript Projects).
• Engine32.cab
• Setup.ibt
In InstallShield 12 and later, the following files are placed on the Disk1 image of the built installation:
• ISSetup.dll
• _Setup.dll
The Disk1 file changes have not been known to cause any upgrade issues. These changes are reported for informational
purposes.
<COMMONFILES>\InstallShield\Professional\Runtime\<MajorVersion>\<MinorVersion>\Intel32
This change has not been known to cause any upgrade issues. This change is reported for informational purposes.
See Also
Upgrading Projects from InstallShield 11.5 or Earlier
QuickPatch projects that are created in InstallShield 12 and later for InstallScript MSI projects can only patch media that
were also created with InstallShield 12 and later. If you want to use InstallShield 2020 to create an update for an
application whose previous InstallScript MSI installation was created with InstallShield 11.5 or earlier, you should create a
create a minor-upgrade package instead of a QuickPatch, and use the Patch Design view to create a standard patch.
Subsequent patches from this version can be created as QuickPatch projects.
Creating a QuickPatch for a Basic MSI project (with or without InstallScript custom actions) has not been known to cause
any issues.
See Also
Upgrading Projects from InstallShield 11.5 or Earlier
Creating Standard Patches for InstallShield 11.5 and Earlier InstallScript MSI
Projects
InstallShield 2020
InstallShield 12 and later does not support the creation of InstallScript MSI patches (using the Patch Design view) where
both the latest and previous setups were created with InstallShield 11.5 or earlier. Creating a patch where the latest setup
is created with InstallShield 12 or later and the previous setup was created with InstallShield 11.5 or earlier has not been
known to cause any issues.
See Also
Upgrading Projects from InstallShield 11.5 or Earlier
InstallShield 11.5 and earlier included the InstallScript MSI Object type of project. This project type is no longer available in
InstallShield.
Predefined InstallScript event handlers are not available in merge module projects that have InstallScript custom actions.
Therefore, if you have an InstallShield 11.5 or earlier InstallScript MSI object project that uses InstallScript event handler
functions, you must manually schedule custom actions that call these functions when the project is converted to a merge
module project in InstallShield 2020. To learn how, see Creating and Scheduling InstallScript Custom Actions that Call
InstallScript Event Handlers for Basic MSI Projects.
Note that InstallShield 2020, as well as earlier and later versions of InstallShield, can consume InstallShield 2020 merge
modules that have InstallScript custom actions.
ISDEV : error -4075: File not found. An error occurred merging Module
'InstallShieldMSIObjectName.4F635B62_07BF_4779_B74E_D80C29D508E3:0' for Feature 'NewFeature1'.
See Also
Merge Module Projects
Build Errors and Warnings
If you have an InstallShield project that was created using versions 2.1 through 5.x of InstallShield Express, that project is
automatically upgraded to a Basic MSI project when you open it in InstallShield 2020. InstallShield 2020 converts
InstallShield Express projects to a Basic MSI project because it is the comparable project type.
To learn how to convert your upgraded project to an InstallScript MSI project, see Converting a Basic MSI Project to an
InstallScript MSI Project.
Open the project in InstallShield. A dialog box opens to ask if you would like to upgrade your project.
A backup copy of your original project is created and stored in the location specified in the dialog box.
InstallShield 2020 preserves the logic and dialog of the Setup Types view when it migrates Express 2.x projects (.iwz) to a
Basic MSI project in InstallShield 2020. In earlier versions of Express, setup types were based on components. In Express 2.x
projects (.iwz), components were replaced by features, and file groups are now mapped to destination folders instead of
components.
When you upgrade an Express 2.x project (.iwz) to a Basic MSI project in InstallShield 2020, you can edit setup types by
changing a feature’s Install Level property and dialog control events.
Note • Billboard properties from Express projects will not be migrated since they are not supported in Basic MSI projects. You
will receive warning 701 when the billboards property is specified in earlier Express projects.
If you migrate an Express project with a language that is not installed with your current version of InstallShield, you will lose
support for that language. Language support is available in the Premier edition of InstallShield.
See Also
Converting a Basic MSI Project to an InstallScript MSI Project
You can upgrade projects that were created using InstallShield Professional. When you are using InstallShield 2020 and you
open an installation project that was created with InstallShield Professional, your project is automatically upgraded. This
enables you to immediately work with your project in InstallShield 2020.
Projects that were created using InstallShield Professional were composed of several .ini files referenced by an .ipr file. In
InstallShield 2020, your installation project is one file—an .ism file.
1. Open InstallShield.
2. On the File menu, click Open. The Open dialog box opens.
3. Select the InstallShield Professional project file (.ipr) that you would like to open.
4. Click Open.
Your project opens in InstallShield, and the extension changes from .ipr to .ism. A backup of your original .ipr project is
saved as ProjectName.ipr.bak in the same folder.
You may also need to make changes to the upgraded project; see Migrating from InstallShield Professional 6.x and
Migrating from InstallShield Professional 5.x.
Note • In InstallShield 2020, support files are linked to a subfolder of the project folder; in InstallShield Professional, support
files were physically copied to a subfolder of the project folder.
See Also
Script Changes: Lexicon Conversion
Adding Project Assistant Dialog Support to Projects Upgraded from InstallShield Professional
Upgrade Errors (Upgrading from InstallShield Professional)
Upgrade Warnings (Upgrading from InstallShield Professional)
ISAlias Table
When you upgrade an InstallShield Professional 6.x installation to InstallShield 2020, note the following:
• You can quickly convert a script that uses a program...endprogram block to an event-based script that calls all
appropriate event handler functions except the user interface and file transfer functions. For details, see OnShowUI.
• The new simplified model for Internet installations eliminates many of the Ether object’s methods and all of its
properties and subobjects (while providing InstallScript enhancements that let you handle any Internet-specific
requirements). If your Internet installation used any of these properties and methods, see Replacing Obsolete
Properties and Methods.
• Installations created in version 6.x contained a number of automatically created string entries; the installation used
these string entries to get information. These string entries were redundant—they contained the same information
contained in the Project Settings property sheet. InstallShield 2020 simplifies matters by allowing the information
specified in the project settings to be used at runtime.
Note that using this information is not required; you can continue using your existing string entries as before by simply
leaving them intact in your project.
If you want your migrated installation to automatically use the information from your project’s Project Settings
property sheet, delete the following string entries from your project:
COMPANY_NAME
PRODUCT_NAME
PRODUCT_KEY
PRODUCT_VERSION
TITLE_CAPTIONBAR
FOLDER_NAME
TITLE_MAIN
Also, update any script code that may be using one of these string entries to use the new corresponding system
variable instead, as shown in the following table:
PRODUCT_NAME IFX_PRODUCT_NAME
PRODUCT_KEY IFX_PRODUCT_KEY
PRODUCT_VERSION IFX_PRODUCT_VERSION
TITLE_CAPTIONBAR IFX_SETUP_TITLE
FOLDER_NAME IFX_PRODUCT_NAME
TITLE_MAIN IFX_SETUP_TITLE
Note that you can remove only a subset of these string values if you want some values to be read from the string
entries and some to be read from the project settings. If you retain any of these string values, be sure to modify them
as required, rather than changing the unused project settings; in particular, when creating an update installation, be
sure to update the value of the PRODUCT_VERSION string entry if it exists.
• If your installation uses an event-based script and you have overridden the default OnSetUpdateMode event handler
code, a message such as the following may be displayed at run time: “The installed version of the application could
not be determined. The setup will now terminate.” If this error occurs, add code that manually sets
IFX_INSTALLED_VERSION during the OnSetUpdateMode event. For sample code, see the default code that is included
in the OnSetUpdateMode event of a new InstallShield 2020 InstallScript project.
• If your installation uses an event-based script and you have overridden the default OnFirstUIBefore event handler
code, you must replace the following code (from the 6.x version of OnFirstUIBefore) in order to install files to the
appropriate default location:
with the following code (from the new default OnFirstUIBefore code) to set TARGETDIR:
/* Handles both end users with administrative or power user privileges and
end users without such privileges. */
if ( ALLUSERS ) then
TARGETDIR = PROGRAMFILES ^ IFX_COMPANY_NAME ^ IFX_PRODUCT_NAME;
else
TARGETDIR = FOLDER_APPDATA ^ IFX_COMPANY_NAME ^ IFX_PRODUCT_NAME;
endif;
If you are using a procedural script (one with a program…endprogram block), you need to update the code in which
you set TARGETDIR in order to set the default target directory appropriately for users without administrator privileges.
• If your installation uses an event-based script and you have overridden the default OnMaintUIBefore event handler
code, and during uninstallation you want to remove all features including those that are not listed in the media but
only in the log file (see FeatureRemoveAllInMediaAndLog for more information), then you must replace the following
code (from the 6.x version of OnMaintUIBefore):
with the following code (from the new default OnMaintUIBefore code):
case REMOVEALL:
/* Properly handles updating. */
if( nMediaFlags & MEDIA_FLAG_UPDATEMODE_SUPPORTED ) then
FeatureRemoveAllInMediaAndLog();
else
FeatureRemoveAllInMedia();
endif;
If you are using a procedural script that supports script-based uninstallation you need to update your call to
ComponentRemoveAll appropriately.
• If your script calls RegDBSetItem to alter the registry entries that are created by MaintenanceStart (or DeinstallStart),
and it makes those calls to RegDBSetItem in an event handler that is called before the OnMoved handler (for example,
OnMoving or <feature name>_OnInstalled), you must move those calls to RegDBSetItem. MaintenanceStart is now
called in the OnMoveData event handler’s default code, whereas previously MaintenanceStart was called
automatically immediately after the maintenance/uninstallation feature was installed and before any other features
were installed.
• The InstallShield Professional 6.x default event handler code included the following lines in both OnFirstUIBefore and
OnMaintUIBefore:
SetStatusWindow( 0, "" );
Enable( STATUSEX );
StatusUpdate( ON, 100 );
In InstallShield 2020, this code has been relocated to the default OnMoveData event handler code, so you have the
following options:
• If you have not customized this code, you do not need to do anything because the redundant calls will not cause
a problem. You can safely remove this code from OnFirstUIBefore and OnMaintUIBefore if you want to avoid code
duplication.
• If you have customized this code and you want these customizations to apply regardless of what user interface
(UI) event is called, you should remove the code from OnFirstUIBefore and OnMaintUIBefore, then override the
OnMoveData event and place the customized code in place of the default code.
• If you have customized the code and you want specific code depending on what UI event is called, you should
override OnMoveData, comment out the default code, and continue to use your existing code. Note that in this
case, if your installation supports updating you may also want to customize OnUpdateUIBefore.
• The 6.x default event handler code included the following commented-out code in the OnFirstUIBefore and
OnMaintUIBefore events:
// TO DO: if you want to enable background, window title, and caption bar title
// SetTitle( @TITLE_MAIN, 24, WHITE );
// SetTitle( @TITLE_CAPTIONBAR, 0, BACKGROUNDCAPTION );
// Enable( FULLWINDOWMODE );
// Enable( BACKGROUND );
// SetColor( BACKGROUND, RGB( 0, 128, 128 ) );
If you activated this code and would like to provide a consistent UI experience regardless of what UI event is called,
you can remove this code from OnFirstUIBefore and OnMaintUIBefore and then override OnShowUI and customize
the code appropriately.
• Many Windows API functions are declared in included header files (.h files) in InstallShield 2020. If any of these
functions are also explicitly declared in your script code, do one of the following:
• Remove your function declaration and use the declaration provided by InstallShield Professional.
• If you are creating a script that needs to be compilable in both InstallShield 2020 and earlier versions, surround
your declaration with code like the following:
You may also need to update code that calls a Windows API function, if the declaration defined by InstallShield
Professional is different than your declaration.
• In order that the end user interface flows smoothly, by default the installation initialization dialog box remains
displayed until the script displays a dialog box. To close the installation initialization dialog box, call
Disable(DIALOGCACHE) or any dialog box function.
Script Changes
The basic structure of an InstallShield Professional 5.x script is supported in the InstallScript project type in InstallShield
2020. To compile a Professional 5.x script in InstallShield, you must first make the following changes:
Preprocessor Directives
• Include the following statement at the beginning of your script:
#include "ifx.h"
• Remove any #define statements for SD_SINGLE_DIALOGS and its associated SD_<dialog name> constants.
• You may need to remove some #define statements that define Windows constants if those statements result in
compiler errors. Many Windows constants are defined in Ifx.h (which is in the InstallShield Program Files
Folder\Script\Isrt\Include subfolder) or its included files.
Built-In Functions
• Remove the following functions, which were supported in Professional 5.x but are not supported in InstallShield 2020.
Some of these functions will compile, but they will not give the expected results. Where possible, supported
alternatives are suggested.
AppCommand None. (Appropriate only for platforms using the Program Manager shell,
which are no longer supported.)
AddProgItemEx AddFolderIcon
CmdGetMsg Windows API function GetMessage (call CmdGetHwndDlg to get the dialog
handle)
CmdGetParam1 Windows API function GetMessage (call CmdGetHwndDlg to get the dialog
handle)
CmdGetParam2 Windows API function GetMessage (call CmdGetHwndDlg to get the dialog
handle)
CommitSharedFiles The actions performed by this function in Professional 5.x are done
automatically in InstallShield 2020.
CreateProgGroupEx AddFolderIcon
DeleteGroup DeleteProgramFolder
DeleteProgItem DeleteFolderIcon
ExitProgMan None. (Appropriate only for platforms using the Program Manager shell,
which are no longer supported.)
GetGroupNameList GetFolderNameList
GetItemNameList None. (Appropriate only for platforms using the Program Manager shell,
which are no longer supported.)
QueryProgGroup None. (Appropriate only for platforms using the Program Manager shell,
which are no longer supported.)
RegDBCreateKey RegDBCreateKeyEx
RegDBCreateKeyValue RegDBCreateKeyValueEx
RegDBGetKeyValue RegDBGetKeyValueEx
RegDBSetKeyValue RegDBSetKeyValueEx
ReloadProgGroup None. (Appropriate only for platforms using the Program Manager shell,
which are no longer supported.)
ReplaceProgItem None. (Appropriate only for platforms using the Program Manager shell,
which are no longer supported.)
ShowGroup None. (Appropriate only for platforms using the Program Manager shell,
which are no longer supported.)
• Call Disable(LOGGING) before any code that makes changes to the target system that you do not want logged for
uninstallation, and call Enable(LOGGING) after that code. This is necessary because logging of changes for
uninstallation is automatically enabled before any script code is executed.
Note that this is different from Professional 5.x installations in which logging did not begin until DeInstallStart was
called. If you have any installation actions that previously were not logged because they occurred before
DeInstallStart, you will need to add an additional Disable(LOGGING) call before these installation actions to disable
logging manually.
If you want your installation to display a background, you must call Enable(BACKGROUND). In InstallShield 2020, the
background is disabled by default, whereas in Professional 5.x it was enabled by default. (In event-based scripts, code
for customizing and displaying a background exists in comment lines at the beginning of the default code for
OnFirstUIBefore. To activate this code, remove the slash characters at the beginnings of the desired lines.)
Note that some user-interface functions, such as PlaceBitmap, will not work properly (nor return a negative value to
let you know they failed) if the installation background is not enabled.
• It is no longer necessary to call RegDBSetItem with the argument REGDB_UNINSTALL_NAME to set the value of
[DisplayName] under the uninstallation key. This is now done when MaintenanceStart or DeinstallStart is called.
• Calling SetColor with STATUSBAR as its argument will not have any effect in InstallShield 2020; status bars are drawn
using system colors.
• When you call StrGetTokens, if the first (or last) character of szString matches a character in szDelimiterSet, a null
string ("") is not inserted in the list as the first (or last) element. Instead, the characters between the first and second
(or last and next to last) delimiters are inserted in the list as the first (or last) element.
• When you call StrGetTokens, if a wildcard character is included in the filename specified by szSrcFile, the filename
part of szTargetFile is not ignored as in previous versions of InstallShield Professional; instead, all of szTargetFile is
treated as the target path to which each source file is copied to with its existing name. For example, CopyFile(
"C:\\*.*", "D:\\File.txt" ) copies files to a folder named File.txt on the D drive.
• WaitOnDialog now returns IDCANCEL when the end user selects the system menu’s Close command or clicks the title
bar’s Close button from a custom dialog. In previous versions, DLG_CLOSE was returned in these cases.
• If you pass GetSystemInfo a first argument of DRIVE and a third argument that is a UNC path, the function correctly
returns a negative value. Previously it returned zero, falsely indicating success, although due to operating system
limitations UNC paths are not supported in that case.
• When you call ParsePath with its third argument set to PATH and its second argument set to a UNC path that includes
only a server name without a trailing backslash (for example, "\\\\TheServer"), the function correctly sets the first
argument equal to a double backslash ("\\\\"). In Professional 5.x, the function would set the first argument equal to a
single backslash ("\\").
• The Professional 5.x Help Library listed specific numeric return values, other than 0 (zero) for success, for some
functions. Some of these numeric values have changed for InstallShield 2020; a script used in InstallShield 2020
should compare a function’s return value only to the constants that are currently listed in that function’s help.
• In order for the end-user interface to flow smoothly, by default the installation initialization dialog remains displayed
until the script displays a dialog. To close the installation initialization dialog, call Disable(DIALOGCACHE) or any
dialog function.
• Passing a pointer to a string as the fourth argument of SendMessageTimeout no longer gives the expected result. To
pass string data to SendMessageTimeout, see the Additional Information section of the SendMessageTimeout topic.
Predefined Constants
• Remove the following constants, which were supported in Professional 5.x but are not supported in InstallShield 2020:
COMPONENT_VALUE_ALWAYSOVERWRITE
COMPONENT_VALUE_NEVEROVERWRITE
COMPONENT_VALUE_NEWERDATE
COMPONENT_VALUE_NEWERVERSION
COMPONENT_VALUE_OLDERDATE
COMPONENT_VALUE_OLDERVERSION
COMPONENT_VALUE_SAMEORNEWDATE
COMPONENT_VALUE_SAMEORNEWERVERSION
COMPONENT_FIELD_DESTINATION
COMPONENT_FIELD_OVERWRITE
• Remove statements that assign values to the following predefined variables (for example, TARGETDISK="C:\\";). Such
statements will not compile in InstallShield 2020; these constants are now read-only.
CMDLINE
COMMONFILES
ERRORFILENAME
FOLDER_DESKTOP
FOLDER_PROGRAMS
FOLDER_STARTMENU
FOLDER_STARTUP
ISRES
ISUSER
ISVERSION
MODE
PROGRAMFILES
SUPPORTDIR
TARGETDISK (The value of this variable is automatically updated when TARGETDIR is changed.)
UNINST
WINDIR
WINDISK
WINSYSDIR
WINSYSDISK
DLLs
• When you called a DLL function in Professional 5.x, all string arguments were passed by reference; in InstallShield
2020, you can pass a string argument by value. To specify the method for passing an argument, in the function
prototype, precede the argument’s data type with the BYREF or BYVAL keyword; for example, MyDLL.MyFunc(BYREF
NUMBER, BYVAL STRING). The InstallShield 2020 compiler includes the following compiler warnings to encourage the
use of the appropriate keyword.
• If your script includes DLL function calls where neither BYREF nor BYVAL has been specified, you receive compiler
warning W7507. To eliminate this warning, add the appropriate keyword to the function prototype.
• If you specify a literal string for a string argument that is passed by reference, you receive compiler warning
W7511. To eliminate this warning, add the BYVAL keyword to the function prototype.
When you call a function in an external DLL, make sure the same calling convention is used in the script and the DLL. In
Professional 5.x, the installation engine always used the stdcall convention but would sometimes overlook an
inconsistent DLL convention. The InstallShield 2020 engine does not; it generates an error (exception 0x80040704)
when the wrong calling convention is used.
In your script, you can declare a calling convention, either cdecl or stdcall, when declaring a DLL function. For
example:
• In InstallShield 2020, InstallScript arrays are internally formatted as OLE Automation safe arrays, not native C or C++
arrays. To pass an InstallScript array to a DLL function that expects a C or C++ array, you must place the array data in
the expected format by calling GetCArrayFromISArray.
• In InstallShield 2020, a string variable whose address is stored in a pointer variable cannot be changed by passing the
pointer to a DLL function. To allow a DLL function to change the value of a string variable, pass the variable itself as an
argument to the function, after declaring the data type of that argument specifying the BYREF operator.
• You no longer need to call the UseDLL function before calling a DLL that is located on Windows’ DLL search path. The
DLL search path is the following:
Use this feature with caution; the values of the current folder and PATH environment variable on an end user’s
machine are not predictable.
Miscellaneous
• The undocumented array syntax ArrayName[nArrayIndex] is no longer supported. In InstallShield 2020, the syntax for
all arrays is ArrayName(nArrayIndex).
• If you explicitly declare a return type for a script-defined function, you must specify the same return type in the
function definition, after the keyword "function", or the script will not compile. (If you do not explicitly declare a
return type, the return type is assumed to be NUMBER.) In previous versions of InstallShield Professional, return types
were assumed to be NUMBER regardless of explicit specifications of other return types, so this issue did not arise.
• To place uninstall information under HKEY_CURRENT_USER, set the value of the ALLUSERS system variable to FALSE.
• To pass a literal character as an argument to a built-in or user-defined function, you must pass its numeric ASCII value.
• When processing the system variable CMDLINE, be aware that the following command line switches are no longer
used by Setup.exe and so are included in CMDLINE: -SMS, -z, -c, -e, -q, -t, and -x. The -SMS switch is obsolete because
now Setup.exe always stays in memory until the installation is complete. The -z switch is obsolete because now
Setup.exe initializes correctly even on systems with more than 256 megabytes of memory.
• Remove Professional 5.x’s ODBC Template code, which will not compile in InstallShield 2020. This is because the
following function call is nested within the code:
In InstallShield 2020 this function call does not compile because the Destination property is a file group property, not
a component property.
Other Changes
• Pressing F3 no longer works to exit an installation.
• InstallShield 2020 installations do not support including special billboards for low-resolution systems.
• If neither a source file nor the already-existing target file has a version number, and the source file’s file group’s
Overwrite property is "Newer Version", "Same or Newer Version", or "Older Version", then the file on the target system
is not overwritten. In Professional 5.x installations, the target file would be overwritten.
• The Lang key in a silent installation’s response (.iss) file’s [Application] section no longer has any effect.
• In Professional 5.x installations, any registry key logged by the installer would be removed during uninstallation in any
case. In InstallShield 2020, keys created by RegDBCreateKeyEx and non-shared keys in registry sets are removed only
if the installer created the key, that is, the key did not exist when the installation was run.
Terminology Change
In InstallShield Professional, the functional building blocks of your installation from the end user’s perspective were called
components. With InstallShield 2020, these building blocks are called features.
Because of this change in terminology, a number of InstallScript function names have also changed. When you upgrade a
project that you created using InstallShield Professional, some items in your script might undergo a lexicon change or be
aliased.
• Function Names
Function Names
Any InstallScript function name that referred to component now refers to feature. For example, ComponentDialog is now
FeatureDialog. The parameters for these functions have not changed. Click a feature function to view the corresponding
help topic.
ComponentAddItem FeatureAddItem
ComponentCompareSizeRequired FeatureCompareSizeRequired
ComponentDialog FeatureDialog
ComponentError FeatureError
ComponentErrorInfo FeatureErrorInfo
ComponentFileEnum FeatureFileEnum
ComponentFileInfo FeatureFileInfo
ComponentFilterLanguage FeatureFilterLanguage
ComponentFilterOS FeatureFilterOS
ComponentGetData FeatureGetData
ComponentGetItemSize FeatureGetItemSize
ComponentGetTotalCost FeatureGetTotalCost
ComponentInitialize FeatureInitialize
ComponentIsItemSelected FeatureIsItemSelected
ComponentListItems FeatureListItems
ComponentLoadTarget FeatureLoadTarget
ComponentMoveData FeatureMoveData
ComponentPatch FeaturePatch
ComponentReinstall FeatureReinstall
ComponentRemoveAll FeatureRemoveAll
ComponentRemoveAllInLogOnly FeatureRemoveAllInLogOnly
ComponentRemoveAllInMedia FeatureRemoveAllInMedia
ComponentRemoveAllInMediaAndLog FeatureRemoveAllInMediaAndLog
ComponentSaveTarget FeatureSaveTarget
ComponentSelectItem FeatureSelectItem
ComponentSelectNew FeatureSelectNew
ComponentSetData FeatureSetData
ComponentSetTarget FeatureSetTarget
ComponentSetupTypeEnum FeatureSetupTypeEnum
ComponentSetupTypeGetData FeatureSetupTypeGetData
ComponentSetupTypeSet FeatureSetupTypeSet
ComponentTotalSize FeatureTotalSize
ComponentTransferData FeatureTransferData
ComponentUpdate FeatureUpdate
ComponentValidate FeatureValidate
SdComponentDialog SdFeatureDialog
SdComponentDialogAdv SdFeatureDialogAdv
SdComponentMult SdFeatureMult
SdComponentTree SdFeatureTree
COMPONENT_INFO_ATTRIBUTE FEATURE_INFO_ATTRIBUTE
COMPONENT_INFO_LANGUAGE FEATURE_INFO_LANGUAGE
COMPONENT_INFO_OS FEATURE_INFO_OS
COMPONENT_INFO_ORIGSIZE FEATURE_INFO_ORIGSIZE
COMPONENT_INFO_COMPSIZE
COMPONENT_INFO_DATE
Note • The flags that are not available return -137,
COMPONENT_INFO_DATE_EX which indicates that the option is not functional.
You can use the FeatureError function to provide
COMPONENT_INFO_TIME
more information about the return value.
COMPONENT_INFO_VERSIONLS FEATURE_INFO_VERSIONLS
COMPONENT_INFO_VERSIONMS FEATURE_INFO_VERSIONMS
COMPONENT_INFO_VERSIONSTR FEATURE_INFO_VERSIONSTR
COMPONENT_FIELD_CDROM_FOLDER FEATURE_FIELD_CDROM_FOLDER
COMPONENT_FIELD_DESCRIPTION FEATURE_FIELD_DESCRIPTION
COMPONENT_FIELD_DISPLAYNAME FEATURE_FIELD_DISPLAYNAME
COMPONENT_FIELD_FILENEED FEATURE__FIELD_FILENEED
COMPONENT_FIELD_FTPLOCATION FEATURE_FIELD_FTPLOCATION
COMPONENT_FIELD_HTTPLOCATION FEATURE_FIELD_HTTPLOCATION
COMPONENT_FIELD_IMAGE FEATURE_FIELD_IMAGE
COMPONENT_FIELD_MISC FEATURE_FIELD_MISC
COMPONENT_FIELD_PASSWORD FEATURE_FIELD_PASSWORD
COMPONENT_FIELD_SELECTED FEATURE_FIELD_SELECTED
COMPONENT_FIELD_SIZE FEATURE_FIELD_SIZE
COMPONENT_FIELD_STATUS FEATURE_FIELD_STATUS
COMPONENT_FIELD_VISIBLE FEATURE_FIELD_VISIBLE
COMPONENT_VALUE_CRITICAL FEATURE_VALUE__CRITICAL
COMPONENT_VALUE_HIGHLYRECOMMENDE FEATURE_VALUE__HIGHLYRECOMMENDED
D
COMPONENT_VALUE__STANDARD FEATURE_VALUE_STANDARD
See Also
ISAlias Table
When you upgrade an installation project from InstallShield Professional to InstallShield and the project contains a
Setup.rul file that was created in InstallShield Professional, some questions may not be available on the Installation
Interview page of the Project Assistant. This is because the Setup.rul file is missing the portions of the OnFirstUIBefore
event code that InstallShield uses to key on script tags.
If you create a new InstallScript project and look at the OnFirstUIBefore event, you will see the following code that the
Project Assistant requires in order to support dialog functions:
//{{IS_SCRIPT_TAG(FunctionName)
InstallScript code...
//}}IS_SCRIPT_TAG(FunctionName)
3. In the event category list at the top of the InstallScript pane, select the OnFirstUIBefore event. InstallShield re-adds
this event to your script.
4. Copy the pertinent dialog code to the commented-out code for the OnFirstUIBefore event.
If you have an InstallShield project (.ism file) that was created using InstallShield—Windows Installer Edition, that project is
automatically upgraded to a Basic MSI project when you open it in InstallShield. See Converting a Basic MSI Project to an
InstallScript MSI Project to learn how to convert your upgraded project to an InstallScript MSI project.
Task When you open the project, a dialog box appears to ask if you would like to upgrade your project.
• Click Yes to upgrade your project. Your project opens in the IDE.
• Click No to leave the project unopened.
A backup copy of your original project is created and stored in the location specified in the dialog.
See Also
Converting a Basic MSI Project to an InstallScript MSI Project
Post-Upgrade Changes in the Property Manager
Properties in the Property Manager with an empty value (no value) are invalid for MSI. Because of this,
***DO_NOT_BUILD*** appears in place of the empty value for these properties. In this way, properties with empty values
are preserved as placeholders after the upgrade, but are not built into the .msi package.
See Also
Converting a Basic MSI Project to an InstallScript MSI Project
Upgrading Projects Created with InstallShield—Windows Installer Edition
• Ability to create and build Suite/Advanced UI installations—Create a bootstrap application with a contemporary,
customizable user interface for multiple .msi packages, .msp packages, InstallScript packages, .exe packages,
sideloading Windows App packages (.appx), and Windows Installer transactions, as well as multiple InstallShield
prerequisites. A Suite/Advanced UI installation packages together multiple separate installations as a single
installation while providing a unified user interface; it uses a setup launcher (Setup.exe) to conditionally launch
packages on target systems as needed.
• Support for InstallScript actions and other types of actions in Suite/Advanced UI installations—Suite/Advanced
UI installations have built-in support for launching different types of actions to perform various run-time tasks that are
outside the scope of the packages that you are including in the installation. The actions can run executable files, call
DLL functions, run PowerShell scripts, set a Suite/Advanced UI property, run InstallScript code, or call a public method
in a managed assembly at run time.
• Virtualization support—The Microsoft App-V Assistant is included in the Premier Edition of InstallShield. Use this
assistant to create customized virtual applications in the Microsoft App-V format. Virtualization enables you to isolate
an application in its own environment so that it does not conflict with existing applications or modify the underlying
operating system.
• Application Virtualization Suitability Suites—Several 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 4.x, Microsoft App-V
5.x, Microsoft Server App-V, VMware ThinApp, and Citrix XenApp. The validation suites can enable you to make more
informed decisions about how you should build your product if you are considering offering your customers a
virtualized version.
• Support for DIM files—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 collaboration add-on. The ability
to add DIM files to Basic MSI projects is available in the Premier edition of InstallShield.
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. 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.
• Multilingual installations—Create a single installation that displays end-user text in multiple languages and can
handle conditional installation of language-specific files. Change dialogs and messages to any one of 34 additional
languages using pre-translated strings.
Project • Note that support for two of those languages—Arabic (Saudi Arabia) and Hebrew—is available in only Basic
MSI and Merge Module projects.
• Arabic (Saudi Arabia) and Hebrew language support—InstallShield Premier Edition includes support for Arabic
(Saudi Arabia) and Hebrew languages, which are written and read from right to left. All of the default end-user dialog
strings are available in these languages.
Since these languages are read from right to left, the Premier edition also includes support for mirroring Arabic and
Hebrew dialogs; that is, InstallShield uses a right-to-left layout for Arabic and Hebrew dialogs. Thus, for example,
buttons that are on the right side of dialogs in English and other left-to-right languages are moved to the left side of
right-to-left-language dialogs.
• Ability to specify commands that run before, during, and after builds—InstallShield Premier Edition includes
release settings that you can use to specify commands that you want to be run at various stages of the build process.
You can schedule commands that run at the following build events: (a) before InstallShield starts building the release,
(b) after InstallShield has built the .msi package and the .cab files (if your product’s data files are to be stored in .cab
files), but before the .msi package has been digitally signed and streamed into the Setup.exe file, and (c) after
InstallShield has built and signed the release.
• Ability to distribute installations to virtual machines that InstallShield provisions at build time or on demand—
You can configure your projects so that after each successful build of your installation, InstallShield automatically
reverts a virtual machine (VM) to a designated snapshot, powers on the VM, and copies your installation to the VM to
make it available for testing. You can also alternately perform these testing preparation steps on demand at any time.
The testing preparation capability makes it possible to reduce testing time and eliminate manual steps. The VM can be
on a Microsoft Hyper-V Server, a VMware ESX or ESXi Server, or a VMware Workstation.
• Extra licenses for InstallShield MSI tools—InstallShield includes several tools: InstallShield MSI Diff, InstallShield
MSI Query, InstallShield MSI Sleuth, and InstallShield MSI Grep. You can use these tools to troubleshoot issues with
Windows Installer packages. InstallShield Premier Edition includes a separate installation and extra licenses that let
you install just the InstallShield MSI tools, without InstallShield, on separate machines. For specific terms, see the
End-User License Agreement for the InstallShield MSI tools.
• Ability to import IIS data from existing IIS Web sites into a project—InstallShield includes an IIS scanner
(IISscan.exe), a command-line tool for scanning an existing IIS Web site and recording IIS data about the Web site.
The IIS scanner creates an XML file that contains all of the settings for the Web site, its virtual directories, its
applications, and its application pools. You can use the XML file to import the IIS data into the Internet Information
Services view in InstallShield Premier Edition. Once you have imported the IIS data into a project, you can use the
Internet Information Services view to make changes to the IIS settings as needed.
• Support for deploying Web Deploy packages—Suite/Advanced UI installations, available in the Premier edition of
InstallShield, have built-in support for deploying Web Deploy packages to IIS Web servers and the cloud.
• InstallShield Collaboration—InstallShield Premier Edition includes licenses for InstallShield Collaboration for Visual
Studio.
• Network repository—A network repository is a collection of installation elements that multiple installation authors
can access and reuse in their projects as needed. A network repository fosters collaboration among installation
authors; it is stored on a network.
• InstallShield Best Practice Suite—InstallShield includes a set of validators called the InstallShield Best Practice
Suite. The InstallShield Best Practice (ISBP) validators in this suite alert you if your installation violates best-practice
guidelines.
• Additional dialog themes—Several dialog themes are available only in the Premier edition of InstallShield.
• Ability to create and build Advanced UI installations—Create a bootstrap application with a contemporary,
customizable user interface for a single .msi package, .msp package, or InstallScript package, as well as multiple
InstallShield prerequisites. An Advanced UI installation uses a setup launcher (Setup.exe) to conditionally launch
packages on target systems as needed.
(Note that the Suite/Advanced UI functionality in the Premier edition of InstallShield includes extended support for
this functionality: The Suite/Advanced UI functionality enables you to package multiple .msi packages, .msp
packages, InstallScript packages, .exe packages, sideloading Windows App packages (.appx), and Windows Installer
transactions, as well as multiple InstallShield prerequisites into a single installation with a contemporary, unified,
customizable user interface.)
• Standalone Build—This tool, which is available with the Premier and Professional editions of InstallShield, enables
you to install only the part of InstallShield that builds the installations, plus any redistributables that you want to
include, on a build machine. Extra licenses of the Standalone Build are available for purchase.
• Dialog Editor—The Dialog Editor enables you to modify the layout of existing end-user dialogs or create new custom
dialogs. Import and export dialogs to share them across projects. Construct different dialogs for each language
supported in the project.
• InstallShield MSI tools—The Premier and Professional editions of InstallShield includes several tools: InstallShield
MSI Diff, InstallShield MSI Query, InstallShield MSI Sleuth, and InstallShield MSI Grep. You can use these tools to
troubleshoot issues with Windows Installer packages.
• Automation interface—Use script to add new files, add or delete features, change the product name and upgrade
code, change release settings, change summary information stream items, change release flags, change any property,
initiate the build process, and more.
• Release customization—Define which project segments to compress, which features to place on which disk, and
which languages to include. Choose to filter application data based on language to support localization efforts.
• Source code control integration—Simplify the process of checking projects in and out of your source code control
system and save space when differencing projects. The SCC integration in the Premier and Professional editions of
InstallShield supports integration with various source code control systems.
• Flexible localization support—The Premier and Professional editions of InstallShield include a String Editor view,
which gives you complete and centralized control over the localizable text strings that are displayed at run time
during the installation process. You can use this view to edit the strings for everything from button text to feature
descriptions. This view also includes support for exporting string entries (which you can have translated) and for
importing translated string entries back into your project.
• Project validation—Use standard .cub files to validate installations and merge modules. Use the upgrade and
patching validation to find out about potential upgrade problems and resolve them before you release your upgrades
and patches.
• Patch creation—In addition to enabling you to create QuickPatch projects, the Premier and Professional editions let
you create standard patches that contain updates to a previous version of your product.
• Manage multiple product versions—Build versions such as Evaluation, Debug, Standard, and Advanced—from a
single project. Allow specific features, InstallShield prerequisites, and other elements to be chosen for inclusion in (or
exclusion from) a release through user-defined flags.
• Support for InstallScript—The Premier and Professional editions of InstallShield include support for InstallScript, a
simple but powerful programming language. You can add InstallScript custom actions to Windows Installer–based
installations or create InstallScript projects, which use the InstallScript engine instead of the Windows Installer engine
to control the entire installation.
• Flexible custom action support—The Premier and Professional editions of InstallShield include support for several
custom action types that are not available in the Express edition. These extra custom action types enable you to do
the following: set a property, set a directory, call a public method in a managed assembly, or display error message
under certain conditions and abort the installation.
• Flexible shortcut support—The Premier and Professional editions of InstallShield include support for configuring
various advanced settings for shortcuts that are not configurable in the Express edition. For example, the Premier and
Professional editions let you prevent a shortcut in your project from being pinned to the taskbar or to the Start menu.
They also let you prevent a shortcut on the Start menu from being highlighted as newly installed after end users install
your product. These shortcut options are often used for tools or secondary products that are part of an installation.
• Merge module authoring and editing—Package pieces of a project for reuse across application installations. Reuse
those you create or any of the ones included in the product. Edit and open modules for greater customization.
• Project templates—Create project templates that contain all of the default settings and design elements that you
want to use as a starting point when you create an installation project or merge module project.
• Multiple IIS Web sites—The Express and Limited editions of InstallShield let you install only one Web site per
installation. The Premier and Professional editions let you install more than one Web site per installation.
• Support for IIS application pools and Web service extensions—Install and manage IIS application pools and Web
service extensions.
• Advanced support for Windows services—Although the Express edition of InstallShield includes some support for
working with services, the Premier and Professional editions of InstallShield include additional flexibility for services.
For example, the Premier and Professional editions enable you to start, stop, or delete a service during installation or
uninstallation; the service can be part of your installation, or it can be already present on target systems. These
editions also let you configure extended service customization options that were introduced in Windows Installer 5.
• SQL support—Connect to SQL servers, import database schema and data, associate SQL scripts with features, and
more with SQL support.
• Ability to modify text files or XML files—Use the Text File Changes view or the XML File Changes view to configure
files that you want to modify on the target system at run time.
• Pure 64-bit support—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, the Premier and Professional editions of InstallShield include
support for building pure 64-bit .msi packages; these can be run on 64-bit Windows-based systems that do not have
WOW64 functionality.
• InstallShield Prerequisite Editor—Use this tool to create new InstallShield prerequisites and modify existing ones.
• Custom icons for Setup.exe and Update.exe—Specify a custom icon (.exe, .dll, or .ico file) that you want to use for
Setup.exe and Update.exe files that you create at build time. The icon is displayed on the Properties dialog box for
Setup.exe; this Properties dialog box opens when end users right-click the Setup.exe file and then click Properties.
End users can also see the icon when they view your Setup.exe file in Windows Explorer.
• Expiration dates for Setup.exe—Set an expiration date, as well as an expiration message, for Setup.exe. If end users
try to run Setup.exe on or after the date that you have specified in your project, the expiration message is displayed,
and the installation exits.
• Support for installation of multiple packages using transaction processing—Windows Installer 4.5 and later
include support for installing multiple packages using transaction processing. The Premier and Professional editions
of InstallShield let you add chained .msi packages to an installation project. Your package, plus the added .msi
packages, are chained together and processed as a single transaction. If one or more of the packages in the
transaction cannot be installed successfully or if the end user cancels the installation, the Windows Installer initiates
rollback for all packages to restore the system to its earlier state.
• Ability to export and reuse various project elements—Increase efficiency by moving pieces of an existing project
(dialogs, custom actions, or features) to a merge module or another installation project.
• Multiple-instance support—Create an installation that lets end users install multiple instances of a product on the
same machine and in the same user context.
• Device driver support—Device driver support in the Premier and Professional editions simplifies the process of
installing device drivers from installation using the Driver Installation Frameworks for Applications (DIFxApp) from
Microsoft.
• Additional Dialog Themes—Several dialog themes are available only in the Premier and Professional editions of
InstallShield. The Limited and Express editions contain only two themes.
• Conversion of Visual Studio merge module projects—The Premier and Professional editions of InstallShield let you
convert a Visual Studio merge module project to an InstallShield merge module project; this is necessary if you want
to build a merge module for consumption in other projects.
• COM+ application proxy support—Manage COM+ application proxies during your installation. A COM+ application
proxy consists of a subset of the attributes of the server application, and it enables remote access from a client
machine to the machine where the application resides.
For additional details about the features that are included with each edition, contact InstallShield Sales, or visit http://
www.installshield.com.
To learn about upgrading from one edition to another, see the appropriate topic:
If you have an Express project type that was created using the Express edition of InstallShield, that project is upgraded to a
Basic MSI project when you open it in the Premier or Professional edition of InstallShield. This upgrade is done because
Basic MSI is the comparable project type for the Express project type. QuickPatch projects created with the Express edition
remain as QuickPatch projects in the Premier and Professional editions of InstallShield.
When you open any project created with the Express edition in the Premier or Professional edition, InstallShield converts
the file from an .ise file to an .ism file. A backup of your .ise file is saved before the conversion takes place.
Billboard properties from Express edition projects will not be migrated since they are not supported in Basic MSI projects.
You will receive warning 701 when the billboards property is specified in Express edition projects.
Open the project in the Premier or Professional edition of InstallShield. A dialog box opens to ask if you would like to
upgrade your project.
A backup copy of your original project is created and stored in the location specified in the dialog box.
When you open a Professional edition project in the Premier edition, your project does not need to be converted. It opens
seamlessly in the Premier edition, enabling you to take advantage of Premier edition–only features. To learn about the
specific features, see Upgrading from Other InstallShield Editions.
For additional information about the features included with each edition, visit http://www.installshield.com.
Visual Studio includes limited support for creating setup and merge module projects. InstallShield lets you convert or
import these types of Visual Studio projects into InstallShield projects so that you can use the advanced features and
functionality in InstallShield to create installations and merge modules.
• Import a Visual Studio setup project (.vdproj) into an InstallShield Basic MSI or Merge Module project (.ism), or import
a Visual Studio merge module project (.vdproj) into an InstallShield Basic MSI or Merge Module project (.ism). These
tasks enable you to create InstallShield installation and merge module projects that contain the same data and
settings that were in your Visual Studio project. During the import process, you can choose to import or ignore certain
settings in the Visual Studio project.
• Convert a Visual Studio setup project to an InstallShield Basic MSI project, or convert a Visual Studio merge module
project to an InstallShield merge module project. Converting a Visual Studio merge module project to an InstallShield
Merge Module project is necessary if you want to build a merge module for consumption in other projects.
Note • If your Visual Studio project contains one or more project outputs, you can use InstallShield to import that Visual
Studio project into an InstallShield project; however, InstallShield cannot convert that Visual Studio project into an
InstallShield project.
Following is a list of a few of the tasks that you can perform in InstallShield projects but not in Visual Studio projects:
• Store custom actions in the Binary table of the .msi or .msm database. (With Visual Studio, all custom actions must be
installed with the product.)
• Manage SQL-related tasks, such as connecting to a SQL server and running SQL scripts.
• Manage IIS Web sites, applications, virtual directories, application pools, and Web service extensions.
• Modify XML files or other text files on the target system at run time.
Import Process
InstallShield lets you import a Visual Studio setup or merge module project into an InstallShield Basic MSI or Merge Module
project.
Note • If the Visual Studio setup or merge module project that you want to import into an InstallShield project contains one or
more project outputs, the InstallShield project must be in the same Visual Studio solution that contains the Visual Studio setup
or merge module project and all of its project dependencies.
In order to import a Visual Studio project that contains project outputs, you must be using InstallShield from within Visual
Studio. If your InstallShield project is open in InstallShield, but not from within Visual Studio, and you try to import a Visual
Studio project that contains project outputs into the InstallShield project, an error occurs.
Task To import a Visual Studio project (.vdproj) into an InstallShield project (.ism):
2. On the Project menu, click the Visual Studio Deployment Project Wizard button.
InstallShield imports the Visual Studio project into your open InstallShield project based on the settings that you
configured in the wizard. As InstallShield imports the project, it displays the status of the project import in the Output
window. The Output window shows each step of the conversion process, and it lists any conversion errors and warnings.
Conversion Process
If you use InstallShield to convert a Visual Studio setup project, InstallShield creates an InstallShield Basic MSI project
(.ism).
If you use InstallShield to convert a Visual Studio merge module project, InstallShield creates an InstallShield Merge
Module project (.ism).
1. Open InstallShield.
2. On the File menu, click Open. The Open dialog box opens.
3. In the Files of type box, select Visual Studio Setup Projects (*.vdproj).
4. Browse to the location of the Visual Studio project that you want to open, and select the project file.
InstallShield creates an InstallShield project based on the settings in the Visual Studio project. InstallShield stores the .ism
file in the same folder as the .vdproj file. As InstallShield creates the .ism file, it displays the status of the project conversion
in the Output window. The Output window shows each step of the conversion process, and it lists any conversion errors
and warnings.
Once the conversion process finishes successfully, the new InstallShield project is displayed in InstallShield.
Prerequisite Tasks
Visual Studio lets you add one or more predefined prerequisites to one or more configurations in a Visual Studio setup
project. The import and conversion processes in InstallShield attempt to convert all of the prerequisites in all of the
configurations to equivalent InstallShield prerequisites. If InstallShield does not include a corresponding InstallShield
prerequisite, warning -9071 occurs, alerting you that the prerequisite could not be converted. To resolve this warning,
consider creating an InstallShield prerequisite that installs the required redistributable, and add that InstallShield
prerequisite to your project. For more information, see Defining InstallShield Prerequisites and Working with InstallShield
Prerequisites that Are Included in Installation Projects.
User-Interface Tasks
The import and conversion processes do not incorporate the dialogs from a Visual Studio project into the InstallShield
project. Once you have imported or converted your project, you can use the Dialogs view in InstallShield to configure
settings for the dialogs in your project.
Language Tasks
If you imported a Visual Studio project into an InstallShield project and the following conditions exist, InstallShield
replaces the existing string entry values in your project with default string entry values for the language of your Visual
Studio project:
• You indicate in the Visual Studio Deployment Project Wizard that you would like to import the language of the Visual
Studio project.
• The language of your Visual Studio project does not match the default language in your InstallShield project. (In Visual
Studio, the Localization property indicates the project’s language. In InstallShield, the Default Language setting in the
String Editor view indicates the project’s default language.)
• InstallShield has support for the language that is used in your Visual Studio project. (If you are using the Professional
edition of InstallShield, you may not have support for the language that is used in your Visual Studio project.)
For example, if you indicate in the Visual Studio Deployment Project Wizard that you would like to import the language of
the Visual Studio project, if the language of your InstallShield project is Spanish, if the language of your Visual Studio
project is German, and if you are using the Premier edition of InstallShield, InstallShield replaces the Spanish run-time
strings in your project with the default German translations. Thus, if you edit a string entry value by revising a setting such
as the Publisher setting in the General Information view, and then you indicate in the wizard that you want to import the
language of a Visual Studio project, InstallShield overwrites the value of the Publisher setting—as well as values for other
settings—with the default German string entry values.
Therefore, if you change the project language while importing your Visual Studio project, review the settings in the General
Information view and the String Editor view, and modify the string entry values if appropriate.
Additional Tasks
You can also use the other views in InstallShield to make additional changes to your project.
Note • Visual Studio lets you specify a directory path that contains multiple formatted properties, such as
[ProgramFilesFolder][Manufacturer]\[ProductName], for the application folder. Visual Studio projects use a directory custom
action to resolve the path at run time. However, InstallShield does not support this type of directory path. Therefore,
InstallShield resolves the path during the conversion process and uses the INSTALLDIR property for the path.
See Also
Working with Dialogs in Basic MSI Projects
Visual Studio Deployment Project Import Wizard
If you have an Internet connection, you can view the updates and obtain the latest InstallShield prerequisites, merge
modules, and objects; service packs; patches; and other updates for the version of InstallShield that you are using.
InstallShield shows an update dialog when an update is available. To obtain the updates, perform the following steps:
See Also
Including Redistributables in Your Installation
Standalone Build
Important • Language support varies, depending on the edition of InstallShield that you are using, the project type, and the
language of the InstallShield interface (English or Japanese).
Note that support for Arabic (Saudi Arabia) and Hebrew is available only in Basic MSI, Merge Module, and Suite/Advanced UI
projects in the Premier edition.
The InstallShield Premier edition includes default run-time strings in 35 supported languages. When you add a supported
language to a 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
dialogs, messages, and other end-user interface elements. For a list of the supported languages, see Language Identifiers.
The InstallShield Premier edition also lets you add unsupported languages, beyond the built-in 35 languages, to Basic MSI,
InstallScript, InstallScript MSI, and 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
project, that language is made available in various language-related settings throughout InstallShield. 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.
The English version of the InstallShield Professional edition lets you select one of 33 languages (any of the supported
languages, except for Arabic or Hebrew) to use as the run-time language for all of the projects that you create. The English
version of the InstallShield Professional edition includes default run-time strings for the one language that you have
selected.
The Japanese version of the InstallShield Professional edition lets you select English plus one additional supported
language; that is, if you are using the Japanese version of the InstallShield Professional edition, you can create projects
with English run-time strings as well as projects with run-time strings from one other supported language. The Japanese
version of the InstallShield Professional edition includes default run-time strings in English, plus the one additional
supported language that you have selected.
If you want to modify the default run-time strings or you are adding custom dialogs, messages, and other end-user
interface elements to your project, you can enter the custom run-time strings directly in your InstallShield project. As an
alternative, you can export a language’s string entries to a file, translate the string values in the file, and then import the
translated file into your project. This support is available in all editions of InstallShield.
To learn more about language support in InstallShield, see the following sections of the documentation:
If you plan on creating releases that include run-time strings in a language that includes double-byte characters (for
example, Japanese, Greek, or Korean), determine whether you need to install any code pages on your build machine.
Unicode encoding is used to display run-time strings throughout InstallShield. With Unicode encoding, double-byte
characters are displayed correctly within InstallShield, even if InstallShield is on a system that does not have a project’s
target languages installed. In addition, you can build releases on a system that does not have the release’s target
languages.
However, if you use ANSI encoding for run-time strings (for example, if you export the string entries from a project as an
ANSI text file and then import the translated ANSI text file into your project), you need to install the code pages for those
languages on your build machine. The code pages allow your system to accurately represent the characters of those
languages. If your build machine does not have the code pages installed, InstallShield reports a build error when you try to
build a release, and the installation does not display double-byte characters properly at run time.
Tip • It is recommended that you use Unicode encoding instead of ANSI encoding when you are exporting string entries to a
file for translation.
See Also
Exporting and Importing String Entries
Installing Supplemental Language Support on a Build Machine
The following instructions explain how to install code pages on a build machine that has Windows XP. This may be
necessary if you want to build releases that contain Chinese, Japanese, and Korean languages. On later operating systems,
the code pages are typically installed by default.
Task To install code pages on a build machine that has Windows XP:
5. Select the language for which you want to add a code page.
6. Click OK.
The following instructions explain how to install files for right-to-left languages such as Arabic and Hebrew on a build
machine that has Windows XP. On later operating systems, these files are typically installed by default. If these files are not
installed, the String Editor view may display the strings left to right instead of right to left.
Task To install right-to-left language support on a build machine that has Windows XP:
3. In the Supplemental language support area, select the Install files for complex script and right-to-left languages
check box.
5. Select the language for which you want to add a code page.
6. Click OK.
7.
See Also
Code Page Requirements for Language Support
InstallShield allows you to create installations for applications created in any programming language—including
applications created with Java, Pascal, C++, Visual Basic, Delphi, C# .NET, Visual Basic .NET, ASP .NET, and Cobol.
Even if you created your application using a language other than those listed above, you can use InstallShield to create an
installation for your application. In addition—if you are not deploying an application, but want to package files or a
database—you can use InstallShield to assist with those tasks.
See Also
Project Types
InstallShield 2020
This section contains tutorials that walk you through the process of creating an installation using InstallShield.
Tutorial Description
InstallScript Leads you step-by-step through the process of creating an InstallScript installation project. The
Project Tutorial tutorial also provides information about the various tasks associated with installation projects and
introduces you to the views in the InstallShield interface in which you can accomplish these tasks.
Basic MSI Teaches you how to a Basic MSI installation project. The tutorial also provides information about the
Project Tutorial various tasks associated with installation projects and introduces you to the views in the
InstallShield interface in which you can accomplish these tasks.
Globalization Shows you how to add languages and language-specific components to your project. Additionally, it
Tutorial shows you how to conditionally install components based on the target system’s language.
Note • The Premier edition of InstallShield must be installed on your development system in order to
successfully complete this tutorial.
This tutorial guides you through the process of creating, building, running, and enhancing an InstallScript installation
using InstallShield.
The tutorial is divided into several steps. After the first step—Step 1: Creating, Building, and Testing Projects—the other
steps can be performed independently, and in any order, so you can focus on the information relevant to your work.
In this tutorial, you will learn how to handle many of the tasks that an installation needs to address, including:
• Installing files
Throughout the tutorial are links to related topics in the Help Library.
This step demonstrates how to create an installation project, build a release image, and test the installation. After
completing this step, you will know how to:
Level Description
Components A component is the smallest separately installable piece of your product from the
developer’s viewpoint. A component specifies files, shortcuts, registry data, and other data
to be installed on the target system. The end user never directly interacts with
components.
A component can be placed in more than one feature, and the component’s data will be
installed if the user selects at least one feature associated with the component.
Level Description
Features A feature is the smallest separately installable piece of your product from the user’s
viewpoint. If the user selects the Custom setup type, a dialog is displayed in which the user
can choose which features to install.
Setup Types Setup types are predefined collections of features. By default, an installation offers
Complete and Custom setup types, and the end user selects which setup type to install in
the SetupType dialog.
The installation that you will create in this tutorial installs and configures an application called Tutorial App. The source
files for Tutorial App are located in one of the Samples subfolders within the InstallShield Program Files folder. The default
installation location is:
Continue
After launching InstallShield, create a new InstallScript project by doing the following:
1. Open the New Project dialog box by doing one of the following:
• Click the Create a new project link in the Start Page’s Project Tasks section (on the left of the page).
3. In the InstallScript tab’s list view, select the InstallScript Project icon.
4. In the Project Name edit box, type the project name Tutorial.
5. Click OK.
There are many other ways to create a project, such as updating a project created using InstallShield Professional. For
more information, see Creating New Projects.
InstallShield creates a project file called ProjectName.ism, in this case Tutorial.ism. The project file stores all the settings
you make in the InstallShield user interface. To move a project to another machine, copy the .ism file (and the installation
source files) to the other system.
Tip • You can change the directory where new project files are created by choosing Options from the Tools menu, selecting
the File Locations tab, and entering the new location in the “Project Location” field.
Your new project is opened to its Project Assistant tab. To begin using the Project Assistant, click the Next button in the
lower right corner.
Tip • You can do the Project Assistant’s steps in any order, and switch at any time (by clicking the appropriate tab) between
the Project Assistant and the Installation Designer, in which you can add more complex and powerful elements to your
installation project.
Continue
The Application Information page lets you specify general information about the application that you are installing.
1. In the Specify your company name edit box, type the name Tutorial Co.
2. In the Specify your application name edit box, type the name Tutorial App.
The value you enter in the application name field is used in dialogs displayed to the end user, as the display name for your
application in Add or Remove Programs in the Control Panel. The application name and company name you enter
determine the default location of application shortcuts on the Windows Start menu, and the default value for the
TARGETDIR system variable, which specifies the default destination for components’ files.
Continue
The Installation Architecture page lets you specify the features you want to be displayed by your installation. A feature is
the smallest separately installable piece of your product from the end user’s standpoint. Individual features are visible to
end users when they select a Custom setup type.
Note • Features can contain subfeatures, subsubfeatures, and so forth, to as many levels as your installation requires.
1. For the Do you want to customize your Installation Architecture? question, select Yes.
3. Create a new feature called HelpFiles. To do so, click Installation Architecture and then click the New button.
Continue
The Application Files page lets you specify the files you want to link with each of your features.
First, select from the list of features the feature in which you want to insert files. To add file links, click the Add Files button,
and then browse for the file or files you want to include in the selected feature.
Task For this tutorial, add the Tutorial.exe file to the ProgramFiles feature by doing the following:
2. In the tree control (with top node Destination Computer), select Application Target Folder.
5. When the "The file you have added ... may have dependencies" message appears, click No; Tutorial.exe has no
dependencies.
Continue
Creating Shortcuts
InstallShield 2020 » InstallScript Project Tutorial
The Application Shortcuts page lets you specify shortcuts for your application’s files on the target system’s desktop or Start
menu. By default, this page displays a shortcut for each executable that you have included in your installation project; you
can delete these, and add shortcuts to other files that you have included in your installation project.
For this tutorial, leave this page’s default specifications unchanged: a shortcut to Tutorial.exe on the Start menu.
Continue
The Application Registry page lets you specify any registry entries that your application requires.
Note • An InstallScript project includes script code that by default creates the application uninstallation key
(Software\Microsoft\Windows\CurrentVersion\Uninstall\<GUID> under the HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER
root key as appropriate) and its values and data; you do not need to specify these registry entries.
For this tutorial, do not specify any registry entries in this page. Registry entries are covered in
Continue
The Installation Interview page lets you specify the dialogs that you want the end user to see when your installation runs.
Based on your answers to the questions on this page, the Project Assistant adds the corresponding dialog function to your
installation script. Script changes related to dialogs are covered in Step 6 of the tutorial.
1. Select the No option button under the text "Do you want to display a License Agreement Dialog?"
Continue
The Installation Localization page lets you specify the languages that your installation supports. It also lets you specify
string values and associated identifiers, which you can use in your end user interface to make your installation more easily
localizable in other languages.
Task For this tutorial, change the display name of the HelpFiles feature by doing the following:
1. In the list box, select Feature String Data. The table on the right displays all of the feature string entries.
2. In the Value column, click HelpFiles (the value associated with the identifier IDS_FEATURE_DISPLAY_NAME2), and
change it to Help Files; that is, add a space.
Continue
The Build Installation page lets you specify what type of distribution you want to build (and, optionally, the location to
copy the distribution files to).
The output window opens with the Build tab uppermost and displays information about the progress of the build. The
build is finished when the Build tab displays the line "Build finished at date and time".
Continue
To run your installation from within InstallShield, click the Run toolbar button or press CTRL+F5.
The installation displays the dialogs that you specified in the Installation Interview Page of the Project Assistant. The values
you entered in the Project Assistant are displayed to the end user in the appropriate dialogs. For example, at run time, the
default value of TARGETDIR that you specified in the Project Assistant appears in the Choose Destination Location dialog. If
the end user browses for a different destination directory, TARGETDIR stores the new value.
After the installation is complete, you can browse for the directory and find the files installed by your setup program. If the
installation was successful, you will see the tutorial files installed.
Maintenance Mode
When a user runs an installation a second (or later) time for a product installed on their system, the installation runs in
maintenance mode. Maintenance mode allows the user to modify feature selections from the first-time installation, repair
the features already installed, or remove the entire program.
Now that you have created a basic installation project, click the Installation Designer tab (near the top of the window) to
expand and fine-tune your installation as illustrated in the next step of the tutorial.
See Also
Troubleshooting Your Installation
Configuring the Enable Maintenance Setting
Now that you have created a basic installation project, click the Installation Designer tab (near the top of the window) to
expand and fine-tune your project in the InstallShield user interface. The InstallShield user interface is arranged in
functional categories that help you add or edit information in your project. This and later steps of the tutorial explore
several of the different InstallShield views.
Continue
See Also
Automation Interface
First, you will set additional properties for the features you created in the Project Assistant, such as the feature display
name and description. To edit the feature properties, go to the Features view in the IDE.
2. In the Features explorer, click the DefaultFeature feature and set its Description property to This feature contains
the Tutorial App program files.
3. Select the New Feature feature and set its Description property to This feature contains the Tutorial App help
files. As you enter each description, InstallShield creates a string entry—displayed as {ID_STRINGn}—to represent
each value.
4. Rename the features in the Features view to have the same names as their respective display names. To rename a
feature, click the feature twice to highlight its name, then type the new name.
At run time, if the end user chooses the Custom setup type, the installation displays a dialog that prompts the user to select
which features to install. This dialog displays features using the display name and description you specified here.
Continue
See Also
Features View
Setup types are collections of features to be installed. A typical installation offers Complete and Custom setup types—
where the Complete setup type installs all features, and a Custom setup type displays a dialog that lets the end user choose
which features to install.
You modify setup type properties in the Setup Types view of the IDE (under the View List’s Organization node).
Task For each setup type, select the features to be installed by selecting the boxes in front of the features’ names:
Continue
See Also
Setup Types View
You can add links to additional files in the Files and Folders view. In this step, you will add a file to your HelpFiles feature. As
you add files in the Files and Folders view, the IDE creates components for you according to Setup Best Practices rules.
Task To add the source file Tutorial.html to a new component in the Help Files feature:
1. Go to the Files and Folders view (under the View List’s Application Data node).
2. Select Help Files from the feature list at the top of the view.
3. In the “Destination computer’s folders” area, right-click the Destination Computer icon and verify that Show
Components is selected.
4. Right-click the Application Target Folder icon and select New Component.
6. In the “Source computer’s folders” area, browse for the source folder containing TutorialHelp.html.
7. Drag the TutorialHelp.html icon from the “Source computer’s files” area and drop it on the HelpComponent icon.
This type of file linking, where the list of files linked to a component does not change, is called static file linking. To link to a
directory (and possibly its subdirectories) whose contents might change between builds, see Dynamic File Linking.
Tip • You can use the InstallShield dependency scanners to determine additional files required by your application that are
currently not included in your project. For example, Tutorial App uses MFC, so it will be necessary to add the MFC Runtime
object to your project in the Redistributables view if you intend to target systems that do not have the MFC run-time libraries
installed.
The next step of the tutorial explains how to build a release image for your installation project.
See Also
Files and Folders View
Redistributables
Static Scanning Wizard
Dynamic Scanning Wizard
Building a Release
InstallShield 2020 » InstallScript Project Tutorial
Before testing an installation, it is necessary to build a release. A release image contains all of the files to be distributed to
the end user on a CD-ROM or floppy disk or from a network location.
The simplest way to build a new release is to use the Release Wizard. The Release Wizard is where you specify release
properties, such as the type of media (CD-ROM, for example) to use and whether to compress files on the media. You can
launch the Release Wizard by clicking the Release Wizard toolbar button, or by choosing Release Wizard from the Build
menu.
Click Next in the Welcome panel to specify your release settings. You can click Help in any panel for more information about
the current step.
Continue
In the Specify a Release panel, specify a release name. The release name is used as the name of a folder in which your built
release will be placed. For this example, create a new release called cdrom.
Continue
• Select whether to place the compiled script file (.inx file) in a cabinet file
Continue
Password Panel
In the Password panel, you can specify a password for your installation, and, if you do, whether to execute the password-
checking code in the OnCheckMediaPassword event handler function’s default code.
Click Next to specify the operating systems you want to support in the current release.
Platforms Panel
In the Platforms panel, you can specify the operating systems you want to support in the current release.
For this tutorial, do not change the default selection: Use platforms specified by the Platforms project property.
Continue
The wizard will build into your installation only those language-specific elements, including string entries and dialogs, that
you select in this panel. All language-independent resources, such as product properties and built-in actions, are included
as a matter of course.
Click Next to specify which features you want to include in the current release.
Features Panel
In the Features panel, you can specify which features are included in the built release.
For this tutorial, do not change the default selection: Use the ‘Include in Build’ feature property to determine inclusion.
Continue
For this tutorial, do not change the default selection: "Cabinet File(s)".
Continue
For this tutorial, check the Create a default Web page for the setup box and leave the other default selections unchanged.
Continue
Update Panel
The Update panel lets you specify the release format and the existing releases for which the current release can be run as
an update.
Continue
The Summary panel displays the Release Wizard settings for the current release. If the settings are correct, select the Build
the Release check box and click Finish to build your release. If not, click Back to modify the settings.
Status messages for the build in progress are displayed in the output window.
When the build is complete, the files to copy onto the CD are placed in the following directory:
<ProjectFolder>\Tutorial\cdrom\DiskImages\DISK1.
After making changes to your project in later steps of the tutorial, you can rebuild the latest release by clicking the Build
toolbar button, choosing Build from the Build menu, or pressing F7.
You can now run the installation as you did previously in this tutorial. To run the installation as an Internet installation,
click the toolbar’s Open Release Folder button and launch Setup.htm.
The next step of the tutorial explains how to create shortcuts and registry data for an installation.
See Also
Release Wizard
Troubleshooting Your Installation
Building a Release from the Command Line
After running your installation, if files are not installed, check the following parts of your project:
• Verify that TARGETDIR is set to the proper value. This is set in the General Information view.
[ProgramFilesFolder]TutorialCo\TutorialApp
• Verify that your setup types have features associated with them.
• Verify that your features have components and files associated with them.
• After making any changes to your installation, it is necessary to rebuild your project by clicking the Build button or
pressing F7.
See Also
Build Errors and Warnings
Setup.exe Return Values and Run-Time Errors (Basic MSI and InstallScript MSI Projects)
Validating Projects
Continue
Creating Shortcuts
InstallShield 2020 » InstallScript Project Tutorial
You create and modify shortcuts in the Shortcuts view. The properties of a shortcut include its display name, its target
executable and arguments, and the icon it displays. Using the Project Assistant, you have already created a shortcut to
Tutorial App in the end user’s Programs folder, under the Start menu.
Task In this step you create a shortcut on the end user’s desktop.
2. Right-click the Desktop icon and select New Shortcut. The Browse for Shortcut Target dialog box opens.
3. In the dialog box, select Application Target Folder from the Look in drop-down menu and select Tutorial.exe from
the files list.
4. Click Open to close the Browse for Shortcut Target dialog box.
Display Name Tutorial App InstallShield adds the display name to the project’s
strings (and displays the string identifier in curly braces
in the Display Name field) so that the name can be
easily localized to other languages.
Target <TARGETDIR>\Tutorial.exe
Icon Index 0
Tip • To create a shortcut to a file already located on the user’s machine, enter the path to the file—using system variables to
represent the path to the file, when possible. For example, to launch a copy of Windows Notepad located in the user’s Windows
or WinNT folder, enter the shortcut target as <WINDIR>\Notepad.exe.
Continue
See Also
Shortcuts View
Another common requirement for installations is to write information to the target system’s registry. To add registry data
to a component, you can use the Registry view.
2. In the Destination computer’s Registry view area, right-click Destination Computer and select New Registry Set.
4. Under the tutorial registry set, right-click HKEY_LOCAL_MACHINE and from the New submenu select Key.
6. Repeat the process for subkeys named Tutorial Co, Tutorial, and 1.00.0000.
7. In the Destination computer’s Registry data area, right-click and select New String Value.
9. Double-click the TutorialData value and enter <TARGETDIR> in the Value data field.
10. Click the tutorial registry set, and in the Registry Set Install Conditions pane check DefaultComponent.
At run time, if the end user selects a setup type or collection of features that includes the Tutorial.exe component, the
registry data is created on the target system.
1. Rebuild your project by clicking the Build toolbar button or pressing F7.
2. Run the project by clicking the Run button or pressing CTRL+F5 (first removing any existing version of the program
from your system). A shortcut to Tutorial App should be present in the Programs folder of your Start menu.
2. From the Tutorial menu, choose Verify Registry Data. If the registry data was created, a message box displaying the
text <TARGETDIR> is displayed.
The next step of the tutorial explains how to register a COM server (self-registering file).
For many files, the installation’s only requirement is to copy the files from the source media to the target system. For
others, the installer also needs to register the files with the target system. One category of file that needs extra handling is a
self-registering file.
In this step you will create a component that installs and registers Tutorial.ocx and an HTML file that uses it.
A COM server is usually a DLL or .ocx file that requires extra information to be written to the target system’s registry before
applications and Web pages that use the self-registering file can find it.
2. At the top of the Files and Folders view, in the View Filter list, select the ProgramFiles feature.
3. In the Source computer’s folder pane, browse for Tutorial.ocx in your source directory.
4. Drag Tutorial.ocx from the Source computer’s folders pane and drop it into the Destination computer’s folders
pane’s Application Target Folder. The component SelfRegFiles is created under Application Target Folder; this
component contains Tutorial.ocx and has its Self-Register property set to Yes, as you can verify by right-clicking the
component and selecting Properties.
Next, add the HTML file to a new component also associated with the ProgramFiles feature.
Task To add the HTML file to a new component associated with the ProgramFiles feature:
1. In the Destination computer’s folders pane of the Files and Folders view, right-click Application Target Folder and
select New Component.
3. Drag the file TutorialCtrl.html from the Source computer’s files view into the OcxHTML component.
Task After rebuilding your release (by pressing F7) and running the installation (by pressing CTRL+F5), you can verify that the
file was registered properly:
1. Launch Tutorial App using its shortcut in the Programs menu, or by double-clicking its icon.
3. If the COM server was registered correctly, the HTML page displays a “success” message.
The next step of the tutorial demonstrates how to install files conditionally.
In this step, you will learn how to conditionally install data on a target system.
A common requirement for installations is to install certain files on a system only if particular conditions are met. For
example, files may be specific to an operating system or language, or should be installed only if the user has appropriate
privileges.
To install a component (and its files and other data) only on particular operating systems, you can use the component’s
Operating Systems property. You can modify a component’s properties by opening the Setup Design view, expanding the
feature icon that contains the feature, and selecting the desired component.
Task To create a component that will be installed only on systems that have Windows 8:
4. Click the Files icon for the component and add the file ReadmeNT.txt from your source folder by right-clicking in the
Files pane and browsing to the file.
6. Select the component’s Operating Systems setting and click the browse button. The Platforms dialog opens.
8. Click OK.
After you rebuild (by pressing F7) and run the installation (by pressing CTRL+F5), and any files or other data contained in
the component will be installed only if the target system is running Windows 8.
The next step of the tutorial describes how to modify your project’s script.
See Also
FeatureSelectItem Function
InstallShield uses the InstallScript language to drive an installation. You can modify the project’s script in the InstallScript
view.
Tip • Press CTRL+M to maximize the Script Editor; press CTRL+M again to restore it.
InstallScript project scripts use an event-driven model, where a series of predefined functions are called in a specific order.
For information about the built-in categories of event handlers and the order in which event handler functions are called,
see Event Handlers.
The functions already defined in your script appear in the Functions tree. To view or edit an existing function, click its name
in the Functions tree.
Note • Event handler functions are called even if they do not explicitly appear in your script. If an event handler function does
not appear in your script, its default code is used.
To add and edit an event handler function, select the desired event category (such as Before Move Data) from the script
editor’s left drop-down list, and then select the name of the desired event (such as Begin) from the right drop-down list.
Event handler functions that are already explicitly defined in your script appear in boldface text.
For example, the OnBegin event handler is the first function called in an installation script, for both a first-time installation
and maintenance mode.
Task To add your own code to the OnBegin event handler, begin by creating the function:
1. Select Before Move Data from the event category list on the left.
//////////////////////////////////////////////////////////////////////////////
//
// FUNCTION: OnBegin
//
// EVENT: Begin event is always sent as the first event during
// installation.
//
//////////////////////////////////////////////////////////////////////////////
function OnBegin( )
begin
// TO DO: you may change default non-UI settings, for example
//
// You may also perform your custom initialization steps, check requirements, etc.
end;
You can place any code you want to execute at the beginning of your installation in the OnBegin function.
1. Delete the comments (lines beginning with //) between the lines reading begin and end;, and place the text insertion
point between the lines.
5. Click Next.
6. In the szMsg field—which contains the message you want to display—type "Welcome to the Tutorial installation!"
(including the quotation marks).
7. In the nType drop-down list—which specifies the type of message box to display—select INFORMATION.
function OnBegin( )
begin
MessageBox ( "Welcome to the Tutorial installation!" , INFORMATION );
end;
Tip • If compiling the script results in any errors or warnings, you can double-click the error message to highlight the script
line where the error occurred.
When you run the installation (by clicking the Run toolbar button, or by pressing CTRL+F5), the message box appears
before the Welcome dialog is displayed.
InstallScript defines a system variable called MAINTENANCE, which is true if the installation is running in maintenance mode
and false otherwise. To display your message box only for a first-time installation, change the OnBegin function to read as
follows:
function OnBegin( )
begin
if (!MAINTENANCE) then
MessageBox("Welcome to the Tutorial installation!", INFORMATION);
endif;
end;
After you compile and run the installation, the message box appears only for a first-time installation, and not for
maintenance mode.
InstallScript
The InstallScript language contains hundreds of functions for performing installation-related tasks, such as working with
the registry and INI files, testing characteristics of the target operating system, and displaying dialogs. For details and
examples, see the InstallScript Language Reference.
The next step of the tutorial explains how to modify the dialogs that are displayed by your installation.
This step describes three ways you can modify the user interface of your installation:
3. Modifying the layout and properties of a dialog using the Dialog Editor.
Continue
See Also
Displaying Billboards
In your InstallScript code, the event handler functions that contain the dialog functions displayed at run time are:
• OnFirstUIBefore, which contains the dialogs to be displayed before data transfer for a first-time installation.
• OnFirstUIAfter, which contains the dialogs to be displayed after data transfer for a first-time installation.
• OnMaintUIBefore, which contains the dialogs to be displayed before data transfer for a maintenance-mode
installation.
• OnMaintUIAfter, which contains the dialogs to be displayed after data transfer for a maintenance-mode installation.
Note • The OnMaintUIBefore and OnMaintUIAfter event handler functions are not called if the project’s Maintenance
Experience property is set to "No uninstall or maintenance".
A default InstallScript project created with the Project Assistant defines the OnFirstUIBefore event handler function,
which defines the user interface for a first-time installation. OnFirstUIBefore calls dialog functions to display the dialogs
that you specified in the Project Assistant’s Installation Interview page. For example, the following code displays a dialog
that prompts the end user to enter a user name and company name:
szMsg = "";
szTitle = "";
nResult = SdRegisterUser( szTitle, szMsg, szName, szCompany );
The end user’s user name and company name are returned in the last two variables, which you can then use in any way you
want, for example, to create a registry key or check against information you have stored in a file.
Continue
The InstallScript language includes many predefined dialogs that you can display in your installation’s user interface.
Task To replace the default user information dialog with one that also prompts the user for a serial number, you can replace
the SdRegisterUser function with a call to SdRegisterUserEx:
2. Declare the string script variable szSerial by adding the following to the declarations before begin in the
OnFirstUIBefore() function:
string szSerial;
Dlg_SdRegisterUser:
szMsg = "";
szTitle = "";
nResult = SdRegisterUser( szTitle, szMsg, szName, szCompany );
if (nResult = BACK) goto Dlg_SdLicense2;
Dlg_SdRegisterUserEx:
szMsg = "";
szTitle = "";
szSerial = "";
nResult = SdRegisterUserEx(szTitle, szMsg, szName, szCompany, szSerial );
if (nResult = BACK) goto Dlg_SdLicense2;
Using this approach, you can insert additional dialog in your installation’s user interface, or replace existing ones.
Continue
See Also
Dialog Functions
Dialog Customization Functions
The Dialog Editor allows you to modify the appearance of dialog displayed by your installation.
As shown in the previous step, the serial number entered by the end user is displayed in the SdRegisterUserEx dialog as
plain text.
Task To modify the dialog so the password is hidden as the end user types it:
1. In the Dialogs view (which is under the List View’s User Interface node), right-click the SdRegisterUserEx icon and
select Edit.
3. In the Dialog Editor, select the edit field under the Serial Number label.
4. Change the Password property of the Edit control from False to True.
After rebuilding the project (by pressing F7) and running it (by pressing CTRL+F5), the serial number entered by the user will
be hidden.
Tip • To restore a dialog to its default appearance, right-click the dialog’s icon and select Revert Dialog to Default.
End of Tutorial
This tutorial guides you through the process of creating, building, running, and enhancing a Basic MSI installation project
using InstallShield.
The tutorial is divided into several steps. After the first step—Step 1: Creating, Building, and Testing Your Project—the other
steps can be performed independently, and in any order, so you can focus on the information relevant to your work.
In this tutorial, you will learn how to handle many of the tasks that an installation needs to address, including:
• Installing files
• Building releases
Throughout the tutorial are links to related topics in the InstallShield Help Library.
This step demonstrates how to create an installation project, build a release image, and test the installation. After
completing this step, you will know how to:
Level Description
Components A component is the smallest separately installable piece of your product from the developer’s
viewpoint. A component contains files, shortcuts, registry data, and other data to be installed
on the target system. The end user never directly interacts with components.
A component can be placed in more than one feature, and the component’s data will be
installed if the user selects at least one feature associated with the component.
Features A feature is the smallest separately installable piece of your product, from the end user’s
viewpoint. If the end user selects the Custom setup type during the installation, a dialog with
which the user can choose which features to install is displayed.
Tutorial Files
The installation that you will create in this tutorial installs and configures an application called Tutorial App. The source
files for Tutorial App are located in one of the Samples subfolders within the InstallShield Program Files folder. The default
installation location is:
Continue
The first step in the tutorial is to create a new Basic MSI project.
1. On the File menu, click New, or click the New Project button in the toolbar. The New Project dialog box opens.
2. Click the Windows Installer tab and select the Basic MSI project type.
5. Select the Create the project in ‘Project Name’ subfolder check box.
6. Click OK.
InstallShield creates a project file called ProjectName.ism, or in this case, Tutorial.ism. The project file stores all of the
settings that you configure in InstallShield. To move a project to another machine, copy the .ism file (and the installation
source files) to the other system.
Tip • To change the default directory where new project files are created, open the Options dialog box (available when you
click Options on the Tools menu). On the File Locations tab, in the Location setting, enter a new path.
Continue
After you create a new project, the Project Assistant launches to help you specify project and application information. The
first page in the Project Assistant provides a graphical overview of the installation creation process. To begin using the
Project Assistant, click the Application Information icon at the bottom of the view.
The Application Information page is where you specify general information about the application that your project will
install.
1. In the Specify your company name setting, enter TutorialCo. This automatically updates the information in the
Specify your company Web address setting.
2. In the Specify your application name setting, enter TutorialApp. The value that you enter is used on dialogs that are
displayed to end users. It is also used as the display name for your application in Add or Remove Programs.
3. In the Specify your application version and Specify your company Web address settings, leave the default values.
4. Click the Browse button under the Application Icon setting, and browse to the Tutorial.exe location. The default
location is C:\Program Files\InstallShield\2020\Samples\WindowsInstaller\Tutorial Project. Open the .exe
file and select the Icon Index:0.
The Application Information panel will look like the following when you are finished.
The application name and company name you enter determine the default location of application shortcuts on the
Windows Start menu, and the default value for the INSTALLDIR property, which specifies the default destination for your
program’s files.
Note • The default value of INSTALLDIR is [ProgramFilesFolder]Your Company Name\Your Product Name. The special form
[ProgramFilesFolder] expands to the location of the user’s Program Files folder at run time. For a list of the other directory
properties that are defined by Windows Installer, see the System Folders Set by the Installer section in Windows Installer
Property Reference.
Continue
The Installation Requirements page allows you to easily set installation requirements for the target system. For example, if
your application requires a specific operating system in order to run properly, you can indicate that in the first section of
this panel.
Operating
If your application required a certain version of Windows or later to run on the target system, you would select Yes and then
select the operating systems with which your application can run properly.
Software Requirements
If your application’s installation requires that a particular piece of software be installed on the target system, select Yes
and select the required software. To customize the run-time message that will be displayed if the required software is not
present on the target system, click on the run-time message and edit.
Note • The run-time message is not displayed in this section until a software requirement is selected.
Continue
The Installation Architecture page lets you specify the features that you want your installation to display to end users. A
feature is the smallest separately installable piece of your product from the end user’s standpoint. Individual features are
visible to end users when they select a Custom setup type during installation.
Note • Features can contain subfeatures, subsubfeatures, and so forth, to as many levels as your installation requires.
Your installation architecture currently contains a default feature, Tutorial_Files. The default feature is always installed
when an end user runs your installation. In this step, you will add another feature to the installation architecture.
1. Select Yes for the Do you want to customize your Installation Architecture? option.
When you finish this step, your installation architecture will look like this:
Continue
The next step is to add your application’s files to the installation project. The Application Files page lets you specify the files
you want to associate with each of your features.
In this step, you will add the Tutorial executable file to the Tutorial_Files feature.
1. Select the Tutorial_Files feature from the drop-down list of features at the top of the page.
2. In the tree control (with top node Destination Computer), select the INSTALLDIR node.
6. When the file you have added ... may have dependencies message appears, click No. Tutorial.exe has no
dependencies. The file is added to the feature and appears in the file list panel on the right.
Note • The key icon next to the file indicates that this file is the key file of the feature’s component. Windows Installer requires
that most components have a single key file. The Windows Installer service uses a component’s key file for several purposes,
including checking for the file’s existence to determine if a component needs to be repaired and using the key file as the
default target for a shortcut. When you add an executable file to a feature in a Basic MSI project, the Project Assistant
automatically sets it as the key file of the component it creates behind the scenes for the file. For more information, see Setting
Component Key Files.
Continue
Creating Shortcuts
InstallShield 2020 » Basic MSI Tutorial
The Application Shortcuts page lets you specify shortcuts for your application’s files on the target system’s desktop or Start
menu. By default, this page displays a shortcut for each executable that you have included in your installation project. You
can delete these, and add shortcuts to other files that you have included in your installation project.
Click the Launch Tutorial.exe icon. Leave the default setting, Create shortcut in Start menu, selected. InstallShield will
create a shortcut to Tutorial.exe on the end user’s Start menu when the installation is run.
Continue
The Application Registry page lets you specify any registry entries that your application requires.
For the tutorial, do not specify any registry entries in this page. Registry entries are covered in Step 2: Shortcuts and
Registry Data.
Continue
The Installation Interview page lets you specify the dialogs that you want end users to see when your installation runs.
Based on your answers to the questions on this page, the Project Assistant adds the corresponding dialog to your
installation project.
1. Do you want to display a License Agreement Dialog?—Select No. If you selected Yes for this option, you would be
able to browse to your license agreement file.
2. Do you want to prompt users to enter their company name and user name?—Select Yes. The installation displays
a dialog requesting this information.
3. Do you want your users to be prompted to modify the installation location of your application?—Select Yes. For
more information, see Allowing End Users to Modify the Installation Location.
4. Do you want users to be able to selectively install only certain parts of your application?—Select Yes. For more
information, see Creating Selectively Installable Installations.
5. Do you want to give users the option to launch your application when the installation completes?—Select Yes
and browse to the Tutorial.exe file (located in [ProgramFilesFolder]TutorialCo\Tutorial). When this option is set to
Yes, the final dialog in the installation presents a check box that allows the end user to immediately launch your
application upon clicking the Finish button.
Continue
The Installation Localization page lets you specify the languages your installation supports, and specify string values and
associated identifiers, which you can use in your end user interface to make your installation more easily localizable in
other languages.
Edition • For language options in addition to the language that you chose when you installed InstallShield, you must have
the Premier edition of InstallShield.
Task For this tutorial, leave English (United States) selected and change the display names of the installation’s features by
doing the following:
1. In the list box, select Feature String Data. The table on the right displays all of the feature string entries.
2. In the Value column, click Tutorial_Files (the value associated with the identifier IDS_FEATURE_DISPLAY_NAME2)
and change it to Tutorial Files.
3. Click Help_Files (the value associated with the identifier IDS_FEATURE_DISPLAY_NAME3) and change it to Help
Files.
Continue
After defining your installation project’s architecture, adding your application files, creating shortcuts, and selecting
dialogs, you are ready to build the installation.
The Build Installation page lets you specify what type of distribution you want to build and, optionally, the location to
which you want to copy the distribution files.
The Output window opens and displays information about the progress of the build.
Note • The build generates warning -7235. This is expected. You can continue to the next step without resolving this warning,
or to resolve this warning, configure the settings in the Software Identification Tag area of the General Information view as
needed. 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. For more information, refer to Including a Software
Identification Tag for Your Product.
Continue
After completing the Project Assistant steps in this tutorial, you have created a fully functional installation that installs the
Tutorial executable.
The installation displays the dialogs that you specified in the Installation Interview page of the Project Assistant. The values
you entered in the Project Assistant are displayed to the end user in the appropriate dialogs. For example, at run time, the
default value of INSTALLDIR that you specified in the Project Assistant appears in the Choose Destination Location dialog
box. If the end user browses for a different destination directory, INSTALLDIR stores the new value.
After the installation is complete, you can browse for the directory and find the files installed by your installation. If the
installation was successful, you will see the tutorial files installed.
Maintenance Mode
When a user runs an installation a second (or later) time for an application installed on their system, the installation runs in
maintenance mode. Maintenance mode allows the user to modify feature selections from the first-time installation, repair
the features already installed, or remove the entire application.
Click Uninstall.
Now that you have created a basic installation project, click the Installation Designer tab (near the top of the InstallShield
window) to expand and fine-tune your installation as illustrated in the next step of the tutorial.
See Also
Troubleshooting Your Installation
After creating a project, you set properties of the project in the InstallShield installation development environment, or IDE.
The IDE is arranged in functional categories that help you add or edit information in your project. This and later steps of the
tutorial explore several of the IDE views.
Note • The views displayed in the IDE differ, depending on the project type you create.
Continue
See Also
Automation Interface
First, you will set additional properties for the features you created in the Project Assistant, such as the feature display
name and description. To edit the feature properties, go to the Features view in the IDE.
1. Open the Features view. The Features view is located in the Organization section of the View List.
2. In the Features view, select the Tutorial_Files feature to display its property grid on the right.
3. Type the following text in the Description field: This feature contains the Tutorial application files.
5. Type the following text in the Description field: This feature contains the Tutorial help files
As you enter the display names and descriptions, InstallShield creates a string entry—displayed as {ID_STRINGn}—to
represent each value.
At run time, if the end user chooses the Custom setup type, the installation displays a dialog that prompts the user to select
which features to install. This dialog displays features using the display name and description you specified here.
Continue
See Also
Features View
You can add links to additional files in the Files and Folders view. In this step, you will add a file to your Help_Files feature.
As you add files in the Files and Folders view, the IDE creates components for you according to Setup Best Practices rules.
2. In the Destination computer’s folders pane, right-click the Destination Computer icon and verify that Show
Components is selected.
3. Select Help_Files from the feature list at the top of the view.
4. Expand the tree in the Destination computer’s folders pane to see the [INSTALLDIR] folder.
5. Right-click the [INSTALLDIR] folder and select New Component. Name the component Help_Component.
6. In the Source computer’s folders pane, browse for the Tutorial files source folder containing TutorialHelp.html.
7. Drag the TutorialHelp.html icon from the Source computer’s files pane to the Help_Component component in the
Destination computer’s folders. InstallShield adds the file to Help_Component component in the Help_Files feature.
8. Click the Help_Component icon to display the component’s files in the Destination computer’s files pane.
9. Because each component should have a key file, right-click the TutorialHelp.html file and select Set Key File.
This type of file linking, where the list of files linked to a component does not change, is called static file linking. To link to a
directory (and possibly its subdirectories) whose contents might change between builds, see Dynamic File Linking.
The next step of the tutorial explains how to build a release image for your installation project.
See Also
Files and Folders View
Redistributables View
Static Scanning Wizard
Dynamic Scanning Wizard
Building a Release
InstallShield 2020 » Basic MSI Tutorial
Before testing an installation, it is necessary to build a release to update your project settings. A release contains all of the
files to be distributed to end users on a CD-ROM or from a network location.
The simplest way to build a release is to configure settings in the Release Wizard. The Release Wizard is where you specify
release properties, such as the type of media (CD-ROM, for example) to use and whether to compress files on the media.
1. Click the Release Wizard button on the toolbar or choose Release Wizard from the Build menu.
2. In the Welcome panel, click Next to begin defining your release settings.
Continue
2. Click Next.
Continue
Use the default settings (no filtering), and click Next to continue.
Setup Languages
In the Setup Languages panel, you specify which languages (from among the project languages) the user interface of your
installation should display, and whether to display a dialog from which the user can select the installation language.
Use the default settings (include English in the user interface), and click Next to continue.
Continue
Select Automatic, which lets the Release Wizard determine the disk image on which to place each feature’s files.
For more information, see Spanning Installations over Multiple Disks or CDs.
Continue
Continue
Continue
• Optimize size
• Generate Autorun.inf—This generates a file that enables AutoPlay for your CD-ROM image.
For information about the other settings, click the Help button on the Advanced Settings panel.
Continue
Summary
The Summary panel displays all of the Release Wizard settings for the current release.
Status messages for the build in progress are displayed in the output window. When the build is complete, the files to copy
onto the CD are placed in the directory:
<ProjectFolder>\Tutorial\cdrom\DiskImages\DISK1.
You can have InstallShield copy your built disk images to another directory using the Events tab in the Releases view.
The next step of the tutorial explains how to create shortcuts and registry data for an installation.
See Also
Release Wizard
Building a Release from the Command Line
After running your installation, if files are not installed, check the following parts of your project:
• Verify that INSTALLDIR is set to the proper value. This is set in the General Information view.
• Verify that your features have components and files associated with them.
• After making any changes to your installation, it is necessary to rebuild your project by clicking the Build button or
pressing F7.
See Also
Build Errors and Warnings
Setup.exe Return Values and Run-Time Errors (Basic MSI and InstallScript MSI Projects)
Validating Projects
Continue
The processes for creating other types of system data are similar to the items described in this step. For more information,
view the topics listed below.
See Also
ODBC Resources View
INI File Changes View
Environment Variables View
Registering a File Extension
Creating Shortcuts
InstallShield 2020 » Basic MSI Tutorial
You create and modify shortcuts in the Shortcuts view. The properties of a shortcut include its display name, its target
executable and arguments, and the icon it displays.
Task In this step you will create a shortcut to Tutorial App in the user’s Programs folder, under the Start menu.
1. Open the Shortcuts view. The Shortcuts view is located in the System Configuration section of the View List.
2. Right-click the Programs Menu folder icon, and select New Advertised Shortcut. The Browse for a Component
dialog appears.
3. In the dialog, select Tutorial_Files from the Feature drop-down menu and select Tutorial.exe from the files list and
click Open to close the dialog.
Display Name Tutorial Application To accommodate target systems that do not support long file
names, the IDE will create an expression that includes a short
file name, as in “TUTORI~1|Tutorial App”. If you want, you can
modify the short file name part of the expression, as in
“TUTORIAL|Tutorial App”.
Advertised Yes At run time, if the user advertises the product or the feature
containing the shortcut, the shortcut is created but the
component’s files are not installed until the user launches the
shortcut.
Target Advertised shortcut to Automatically set to the component’s key file for an advertised
[INSTALLDIR]Tutorial.ex shortcut.
e
Icon File <TutorialSource>\Tutori Browse for Tutorial.exe in the source location, and select its only
al.exe icon.
Icon Index 0 The icon index identifies a particular icon if there is more than
one icon resource in the executable file.
Working Directory [INSTALLDIR] The working directory should be set to the default directory for
your Save As and Open dialogs.
Tip • To create a shortcut to a file already located on the end user’s machine, set the Advertised property to No, and enter the
path to the file—using Windows Installer directory properties to represent the path to the file, when possible. For example, to
launch a copy of Windows Notepad located in the user’s Windows or WinNT folder, enter the shortcut target as
[WindowsFolder]Notepad.exe.
Continue
See Also
Shortcuts View
Another common requirement for installations is to write information to the target system’s registry. To add registry data
to a component, you can use the Registry view.
The Registry view is located in the System Configuration section of the View List.
2. Select Tutorial.exe from the View Filter at the top of the view.
3. In the Destination computer’s Registry view pane, right-click HKEY_LOCAL_MACHINE, select New, and point to Key.
5. Repeat the process for subkeys named Tutorial Co, Tutorial, and 1.00.0000.
6. In the Destination computer’s Registry data pane, right-click and select New String Value.
8. Double-click the TutorialData value and enter [INSTALLDIR] in the Value data field.
Tip • To write the value of a Windows Installer property to the registry, you can use the form [PropertyName]. In this example,
creating a registry value whose data is [INSTALLDIR] writes the value of INSTALLDIR to the registry.
At run time, if the end user selects a setup type or collection of features that includes the Tutorial.exe component, the
registry data is created on the target system.
1. Rebuild your project by clicking the Build toolbar button or pressing F7.
2. Run the project by clicking the Run button or pressing CTRL+F5 (first removing any existing version of the program
from your system). A shortcut to the Tutorial application should be present in the Programs folder of your Start
menu.
2. From the Tutorial menu, choose Verify Registry Data. If the registry data was created, a message box displaying the
value of INSTALLDIR is displayed.
The next step of the tutorial explains how to register a COM server (self-registering file).
For many files, the installation’s only requirement is to copy the files from the source media to the target system. For
others, the installer also needs to register the files with the target system. One category of file that needs extra handling is a
COM server, commonly known as a self-registering file or ActiveX control. A COM server is usually a DLL or OCX that requires
extra information to be written to the target system’s registry before applications and Web pages that use the self-
registering file can find it.
1. Open the Files and Folders view. The Files and Folders view is located in the Application Data section of the View
List.
2. At the top of the Files and Folders view, in the View Filter list, select the Tutorial_Files feature.
3. In the Destination computer’s folders pane, right-click the [INSTALLDIR] folder and select Launch Component
Wizard.
4. In the Welcome panel of the Component Wizard, select the Let me select a type and define the component myself
option and click Next.
5. In the Component Type panel, select the COM Server icon, type Tutorial.ocx in the Component Name field, and click
Next.
6. In the COM Server—Destination panel, verify that the destination is set to [INSTALLDIR].
7. In the COM Server File panel, click the browse button next to the COM Server File field and browse for Tutorial.ocx in
your tutorial files source directory. Click Next.
8. After the Component Wizard has extracted the COM information, review the COM information and click Finish to
create the component.
The next step is adding the HTML file to the component you just created.
1. In the Destination computer’s folders pane of the Files and Folders view, select the new Tutorial.ocx component.
2. Drag the file TutorialCtrl.html from the Source computer’s files pane to the Destination computer’s files pane.
Note • See Registering COM Servers for other options for registering self-registering files, including extracting COM
information each time that you rebuild the release—for COM servers with interfaces that change between builds—or calling
the file’s self-registration functions.
Task After rebuilding your release (by pressing F7) and running the installation (by pressing CTRL+F5), you can verify that the
COM server was registered properly:
1. Launch Tutorial App using its shortcut in the Programs menu, or by double-clicking its icon.
3. If the COM server was registered correctly, the HTML page displays a “success” message.
The Component Wizard can also create components that install and configure fonts and Windows NT services.
The next step of the tutorial demonstrates how to install files conditionally.
See Also
Component Wizard
In this step, you will learn how to conditionally install data on a target system.
To install a component (and its files and other data) only on particular operating systems, you can use the component’s
Operating Systems property. You can modify a component’s properties by opening the Setup Design view, expanding the
feature icon that contains the feature, and selecting the desired component.
Task To create a component that will be installed only on systems running Windows 7 or later:
1. Open the Setup Design view. The Setup Design view is located in the Organization section of the View List.
4. Expand the Windows_7_Files component, click the Files icon for the component, and add the file ReadmeNT.txt from
your tutorial files source folder by right-clicking in the Files pane and browsing to the file.
7. Select the component’s Condition property and click the browse button to launch the Condition Builder dialog.
8. Create the following condition: VersionNT>=601. For information on creating conditions, see Building Conditional
Statements.
9. Click OK to close the Condition Builder dialog and add the condition.
After you rebuild (by pressing F7) and run the installation (by pressing CTRL+F5), and any files or other data contained in
the component will be installed only if the target system is running Windows 7 or later.
• AdminUser, which is set if the user running your installation has administrative privileges.
• VersionNT, numeric values describing the operating system version the user is running.
• PhysicalMemory, which contains the amount of RAM—in megabytes—on the user’s system.
A Windows Installer condition is a statement of logic that compares a property value against a constant value, or tests if a
property exists. For example, Windows Installer defines properties called ScreenX and ScreenY, which contain the user’s
monitor resolution in pixels. A Windows Installer condition that checks that the user has at least 800 by 600 resolution
would read “(ScreenX>=800) And (ScreenY>=600)”.
Conditions can also test if a property is defined. For example, the AdminUser property is set only if the user has
administrative privileges, and a condition that tests if a user has administrative privileges is simply “AdminUser”.
Task To create a component that will be installed only if the user has administrative privileges:
4. Add the file AdminOnly.txt from your tutorial files source folder, and set it as the key file of the component.
5. Click the browse button in the component’s Condition property to display the Condition Builder dialog.
7. Click OK.
At run time, the component’s data are installed only if the user has administrative privileges.
The next step of the tutorial describes how to modify your installation’s user interface.
See Also
Building Conditional Statements
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
This step describes three ways you can modify the end-user interface of your installation:
• Modifying the layout and properties of a dialog using the Dialog Editor.
Continue
The Basic MSI project includes many dialogs that you can display in your installation’s user interface. The topic, Running
Your Installation, in this tutorial, showed the dialogs your installation displays based on your selections in the Project
Assistant’s Installation Architecture page.
1. Open the Dialogs view. The Dialogs view is located in the User Interface section of the View List.
2. Right-click the All Dialogs explorer and then click New Dialog. The Dialog Wizard opens. Click Next to dismiss the
Welcome panel.
3. In the Dialog Template panel, click Interior Wizard Panel, and select the Let me insert this dialog in a User
Interface sequence check box.
4. In the User Interface panel, select Installation in the User Interface Sequence list. In the list of dialogs, select
InstallWelcome. Based on these selections, InstallShield will insert your new dialog in sequence immediately
following the InstallWelcome dialog.
5. In the Dialog Position and Condition panel, leave the default settings, and click Finish. Your new dialog appears in
the Dialogs list.
6. Right-click the dialog and select Rename. Rename the dialog WelcomeBitmap.
Using the same technique, you can insert additional dialogs in your installation’s user interface.
Continue
See Also
Creating New Dialogs in Basic MSI Projects
The Dialog Editor allows you to modify the appearance of dialogs displayed by your installation.
Task In this step, you will modify the WelcomeBitmap dialog that you just created:
1. First, create a bitmap (using a program like Microsoft Paint) that measures 300 by 150.
3. Expand the WelcomeBitmap dialog’s node. Click English (United States) to open the Dialog Editor.
4. Click the Dialog Bold Title text box at the top of the dialog. In the Text field, type Welcome Bitmap. This changes the
dialog’s main title.
5. Click the Dialog Normal Description text box at the top of the dialog. In the Text field, type Displays my welcome
bitmap. This changes the dialog’s description.
6. Click the Bitmap button on the Dialog Control toolbar and use the cursor to drag a box on the dialog. Set the Height
to 150 and the Width to 300.
7. In the File field browse to the bitmap file that you created in step 1.
After rebuilding the project (by pressing F7) and running it (by pressing CTRL+F5), the Welcome Bitmap dialog will appear
after the Install Welcome dialog.
End of Tutorial
See Also
Editing Dialog Layout in Basic MSI Projects
Globalization Tutorial
InstallShield 2020
The Globalization tutorial introduces you to the tools and options that InstallShield provides for creating a global
installation package. A global installation is one that has the potential to run in many different languages. Depending on
how you choose to build your installation, you can either include all the languages in one package and let the end user
select the language, or you can build individual installation packages for each language that you target. This tutorial walks
you through the process of creating an all-encompassing installation.
Edition • The Premier edition of InstallShield must be installed on your development system in order to successfully complete
this tutorial.
If you have not already done so, you may want to run through the Basic MSI tutorial to familiarize yourself with how to
create an installation package. When finished with the Basic MSI Tutorial, you will have a Basic MSI installation project that
is ideal for adding additional languages. The complete project file for the Basic MSI tutorial was installed with this product
in one of the Samples subfolders within the InstallShield Program Files folder. The default location is:
Project • Almost all of the information in the tutorial also applies to InstallScript installation projects. Differences are
explicitly noted in the tutorial text.
This tutorial uses Othello.ism, which is a sample project file that is installed with InstallShield.
Open Othello.ism, which is located in one of the Samples subfolders within the InstallShield Program Files folder. The
default location is:
Project • Othello.ism is a Basic MSI installation project. Almost all of the information in this tutorial also applies to
InstallScript installation projects; differences are explicitly noted in the tutorial text.
Continue
The first step in creating a global installation is to select the languages that you want to target. For this tutorial, you will
add two languages to your installation project: German and Polish.
2. In the Setup Languages setting, click the ellipsis button (...). The Setup Languages dialog box opens.
3. Select the English (United States), German, and Polish check boxes.
InstallShield adds string entries for English, German, and Polish to your project. Each string entry consists of a language-
independent identifier and a corresponding language-specific value. The string entries include the built-in user-interface
string resources that are already translated. To view all of the string entries, you can use the String Editor view. (In the View
List under User Interface, click String Editor.)
Every time that you add a new string entry to your default language, a parallel entry is made to the string entries for all of
the other languages that are in your project.
Continue
The next step is to edit string entries in your installation project. You will edit string entries for three different settings: The
feature’s display name, the shortcut’s display name, and the shortcut’s description. (The shortcut’s description will be
created as part of the next step in this tutorial.)
3. In the Display Name setting in the right pane, enter Program Files if it is not already there.
If you click anywhere else within the Setup Design view, you will see that the text that you entered has been preceded by a
string identifier, which is enclosed within curly brackets ({}). You can view all of your project’s string entries by clicking the
ellipsis button (...) that is displayed when you click the Display Name setting.
1. In the Setup Design explorer, expand the ProgramFiles feature, and then expand the Program_Executables
component.
3. In the Shortcuts explorer, click the Othello shortcut. InstallShield displays the shortcut’s settings in the right pane.
Currently, the Display Name setting is set to Othello. The value is preceded by a string identifier, which is enclosed
within curly brackets ({}).
4. To change the display name, enter the new name in the Display Name setting.
Continue
Because many of your text strings might be used in multiple places in your project, it is inefficient to store each instance of
these strings in the project. Instead, you can create the string once, and use it anywhere a string is needed. To help
streamline the process of localizing a project, all of the text strings that may be displayed at run time during the installation
process are available in one consolidated view: the String Editor view. You can use this view to create new string entries.
For the shortcut’s Description setting, you are going to enter your new string entry through the String Editor view. Then,
you will associate that string with the shortcut’s description.
Task To create a new string entry and use it for the shortcut’s Description setting:
MYSTRING
5. In the Comments box, you can optionally specify an internal note about the string entry. The comments are not
displayed at run time.
6. Click OK. InstallShield adds new rows in the String Editor view, one for each language (English, German, and Polish).
8. In the Shortcuts explorer, click the Othello shortcut. InstallShield displays the shortcut’s settings in the right pane.
9. In the Description setting, click the ellipsis setting (...). The Select String dialog box opens.
Your new string is now entered as the value for the Description setting.
Continue
The next step in creating a global installation involves including language-specific files and components within your
installation project. For example, although many of your program files may be language-independent, your help files and
run-time strings are both language-specific. For the purpose of this exercise, you will add three new components to your
project. Each component contains a Readme file that is localized in all of your supported languages.
2. In the Setup Design explorer, right-click the feature called ProgramFiles, and then click New Component.
4. Repeat this process two more times. Name these components Polish_Readme and German_Readme.
Translated versions of a simple Readme file are included with InstallShield. These files are located in one of the Samples
subfolders within the InstallShield Program Files folder:
1. Expand the new English_Readme component, and then click the Files icon under the English_Readme component.
Repeat these steps for the German and Polish components, adding Deutsch.txt to and Polski.txt, respectively.
Continue
Now that you have created your language-specific components, you need to include logic that will let the installer know
which of these components should be installed. By specifying a component condition, you can determine the default
language of the target system and then install the appropriate file. Each of the three language-specific components that
you created will need a condition. If that condition evaluates to True, the component is installed.
2. In the right pane, click the Condition setting, and then click the ellipsis button (...) for this setting. The Condition
Builder dialog box opens.
3. In the Properties list, select SystemLanguageID, and then click the Add button.
4. In the Operators list, select the equals sign (=), and then click the Add button.
The Condition(s) box contains SystemLanguageID =, which reflects the selections you previously made.
5. Next you need to provide a value that will be checked when the installation is run. Because you are currently editing
the German component, enter 1031 after the equal sign. 1031 is the language ID for German. Since the component is
installed only if this equation evaluates to true (that is, the target system’s language is German), this component is not
installed on any machine that is not running in German.
Follow the same steps from above to add a condition to the Polish_Readme component. Instead of using 1031 as the
language value, use 1045, which is the language ID for Polish.
You need to choose one language as your default language. For this example, English is the default. Therefore, the
condition that you use for the English_Readme component differs from the other two. The condition for the
English_Readme component should appear as follows:
With this logic, if the language of the target machine is not German or Polish, the English_Readme component is installed.
Project • To learn how to specify which language-dependent components are installed at run time for InstallScript and
InstallScript object projects, see Installing Components Based on Language.
Continue
Before you can build your installation project, you need to translate the English strings that you entered for the feature’s
display name, the shortcut’s display name, and the shortcut’s description. For this tutorial, they have been translated for
you. All you have to do is enter the correct text for the German and Polish string entries. You can use the String Editor view
to do this.
Identifier Value
FEAT_DISPLAYNAME Programmdateien
SHORTCUT_DISPLAYNAME Othello-Verknuepfung
Identifier Value
In most translation situations, you export your string entries for translation. To learn more, see Translating String Entries.
However, for the purposes of this tutorial, it is easier to edit the string entries within the String Editor view.
Continue
Your installation project has been fully globalized and is ready to test. Before you can test the installation, however, you
need to build it.
2. In the first two panels, specify a product configuration and release name.
3. Accept the default settings for every other panel in the wizard except the Setup Languages panel.
4. The Setup Languages panel enables you to choose which languages to include in your installation. Only the
languages that you specified in the General Information view appear in the list of available languages—English, Polish,
and German. Select the check box next to each language.
5. Also, ensure that you select the Display the Setup Languages Dialog check box. This dialog allows end users to select
the language in which they want the installation to run.
7. When you reach the Summary panel, ensure that the Build the Release check box is selected, and then click the
Finish button.
Continue
1. Click the Run Setup button on the toolbar. The Choose Setup Language dialog appears.
2. To run your installation, select German (Standard) and click OK. From this point forward, every dialog is displayed in
German.
Note • After an installation is run in a particular language, Windows Installer caches this information and always runs the
installation in that language.
As the installation wizard progresses, you may notice that some buttons are not properly sized. You can easily fix this
problem by opening the Dialog Editor and resizing the controls so the text fits in the control.
In the Custom Setup panel (in German it is called Angepasstes Setup), the feature name is now Programmdateien. Your
localized string entries are a part of the installation.
Continue
The last step is testing the globalized installation that you created.
1. Open the Start menu and select Programs. The Othello shortcut is displayed as Othello Verknpfung. You can see the
shortcut’s description, which also appears in German.
2. Navigate to the installation directory for Othello. It should be in <Program Files Folder>\Shakespeare Inc\Othello. The
readme file that you installed is called Deutsch.txt.
End of tutorial
InstallShield 2020
If you have ever installed an application onto your computer, you have seen an installation in action—from the end user’s
perspective. An installation’s primary task is to transfer files from the source medium to the local drive. An installation
often also displays a user interface to obtain end user selections, configures the target system (for example, makes any
required registry entries and creates shortcuts), and enables modification or uninstallation of the installed application.
Creating an installation involves performing some or all of the following tasks.
Organize the files to be installed into setup types and features to help your end users select the most appropriate files.
Within each feature, organize the files into components according to their type and purpose, for example, files that are
installed to the same target folder.
based installations can use custom actions to run InstallScript, VBScript, or JavaScript code; call DLL functions; run
executable files; call a managed method in a managed assembly; set a property or a directory; trigger an error and end the
installation; run PowerShell scripts; terminate a process; or run other installation packages.
The user interface can be customized to meet the needs of your installation. For example, you can prompt a user for a serial
number before starting the installation to protect your software against illegal use. During file transfer, an installation can
display billboards that provide product information such as new features or usability tips. A status bar may also be
displayed to show the progress of the file transfer process.
Configure Servers
A server-side installation may need to create and manage new Internet Information Services (IIS) Web sites, manage COM+
applications and components, or manage and organize SQL scripts by server connections and settings.
Much of the information registered in this process is available to the end user through Add or Remove Programs in the
Control Panel. For example, technical support contact information, product update information, product version, and
product publisher information are registered in this process.
See Also
Before You Begin
The “Before You Begin” section of the InstallShield Help Library contains information that is helpful to installation authors
as they create new installation projects with InstallShield. The topics provide background information on Windows
Installer, the Windows logo program, INSTALLDIR, TARGETDIR, and other areas of installation development.
See Also
Getting Started
Microsoft established a list of requirements that a product and its installation must fulfill in order to participate in the
Windows 8 Desktop App Certification Program. The requirements outline criteria that help make a product more
compatible, reliable, and secure when running on Windows systems. Products that meet the Windows 8 Desktop App
Certification Program requirements can carry the Compatible with Windows 8 logo.
Therefore, if you are interested in being able to use the Windows logo, consider using both of the following suites to
validate your installation package:
• InstallShield Validation Suite for Windows 8—This suite consists of a number of InstallShield internal consistency
evaluators (ISICEs) that help you identify issues that may make your installation behave unexpectedly on Windows
systems. This suite checks for issues that may not be revealed in the Full MSI Validation Suite.
• Full MSI Validation Suite—This suite consists of ICEs that Microsoft created.
If you create a merge module in InstallShield, use the following suites to validate your merge module:
• InstallShield Merge Module Validation Suite for Windows 8—This suite consists of a number of InstallShield ISICEs
that help you identify issues that may make your merge module behave unexpectedly on Windows systems. This suite
checks for issues that may not be revealed in the Merge Module Validation Suite.
• Merge Module Validation Suite—This suite consists of ICEs that Microsoft created.
Windows Logo • The Windows Logo Guideline alert appears throughout the InstallShield Help Library whenever the
information relates to complying with the Windows logo program guidelines.
See Also
Guidelines for Creating Custom Actions that Meet Requirements of the Windows Logo Program
Digital Signing and Security
Windows Installer and Logo Requirements (Windows Installer Help Library)
Windows Installer and Logo Requirements (Windows Installer Help Library)
A Windows Installer–based installation is distributed as an .msi package, which consists of a Windows Installer database
(.msi database) and related data files (.cab files, uncompressed data files, etc.). The .msi databases, implemented as COM
structured storage, contain dozens of tables that describe the changes that are to be performed on the target system. For
example, some of the .msi tables are:
Other .msi database tables describe the appearance and behavior of the installation’s user interface, install and configure
Windows services and ODBC information, determine characteristics of the target system, and store icons and other binary
data for use during installation.
From a developer’s perspective, perhaps the greatest change in Windows Installer installation programs is that there is no
explicit script to write. Instead, Windows Installer–based installations perform standard and custom actions, where an
action displays a dialog, queries the target system, or makes changes to the target system. These actions are arranged into
sequences, which are ordered collections of actions.
Windows Installer includes a collection of application program interface functions, or APIs, dedicated to managing product
installations. Applications must call the Windows Installer APIs in order to take advantage of features available with
Windows Installer.
An integral part of Windows operating systems, Windows Installer provides a standard format for component management
as well as an interface for managing applications and system tools. Various versions of Windows Installer are available as
redistributables for Windows operating systems.
Although it is possible to create a Windows Installer package by editing .msi database tables directly, the large number of
tables and relationships among them makes doing so a formidable task. InstallShield organizes the process of developing
an installation for Windows Installer into various views, providing graphical editors and wizards that shield the developer
from much of the implementation detail that is associated with .msi databases.
For more information on Windows Installer technology, see the Windows Installer Help Library.
See Also
Adding Windows Installer Redistributables to Projects
• Basic MSI
• InstallScript
• InstallScript MSI
Some of the specific details apply to only some of these project types. These differences are noted where appropriate.
One of the goals of Windows Vista and later, as well as User Account Control (UAC), is to allow users to run as standard users
all of the time. Elevation should rarely be required; if it does occur, it should occur for as short of a duration as possible.
Several different areas of InstallShield affect whether an installation triggers UAC consent or credential prompts for
elevated privileges. Understanding these different settings will help you create the appropriate UAC experience for your
installation when end users run it on Windows Vista and later systems. It will also offer guidance if you are trying to
minimize the number of UAC prompts that are displayed during your installation.
Depending on how it is configured, an installation that includes InstallShield prerequisites may prompt for elevated
privileges on Windows Vista and later systems at several different points during the installation:
2. When the Setup.exe file launches a setup prerequisite that requires elevated privileges
3. When the ISInstallPrerequisites custom action relaunches the Setup.exe file in feature prerequisite installation mode
because one or more of the features being installed has an associated feature prerequisite
Note that the ISInstallPrerequisites custom action does not verify whether any feature prerequisites require elevated
privileges before the prompt for elevated privileges is displayed. In addition, the ISInstallPrerequisites custom action
does not check the conditions on any of the feature prerequisites to determine whether the feature prerequisites need
to be installed. The prompt for elevated privileges is always displayed.
4. When the Windows Installer begins the Execute sequence of the .msi package
Project • This last installation point applies to Basic MSI and InstallScript MSI projects, but not InstallScript projects.
• Required Execution Level—Use this setting in the Releases view to specify the minimum execution level required by
your installation’s Setup.exe file. InstallShield uses the value that you select (Administrator, Highest available, or
Invoker) in the application manifest that it embeds in the Setup.exe launcher. For more information, see Specifying
the Required Execution Level for Your Setup Launcher on Windows Vista and Later Platforms.
• The prerequisite requires administrative privileges—If you are creating or modifying an InstallShield prerequisite
for your installation, use this check box to indicate whether administrative privileges are required in order to install
this prerequisite. This check box is on the Behavior tab in the InstallShield Prerequisite Editor. For more information,
see Specifying that an InstallShield Prerequisite Requires Administrative Privileges.
• Require Administrative Privileges—Use this setting in the General Information view to specify whether the Execute
sequence of your installation’s .msi package requires administrative privileges. If you set this to No, InstallShield sets
bit 3 in the Word Count Summary property to indicate that elevated privileges are not required to install your product.
For more information, see Entering Summary Information Stream Data.
Project • The Require Administrative Privileges setting does not apply to InstallScript projects.
• Advertise If Prerequisites Are Elevated—Use this setting in the Releases view to specify whether the .msi package
should be advertised—and if so, whether it should be run silently or with the full user interface (UI)—after the
InstallShield prerequisites in the installation have been successfully installed with elevated privileges on Windows
Vista and later machines. The advertisement may allow end users to avoid the UAC prompt that would otherwise be
displayed for an .msi package that requires elevated privileges. For more information, see Specifying Whether a
Product Should Be Advertised If Its InstallShield Prerequisites Are Run with Elevated Privileges.
Project • The Advertise If Prerequisites Are Elevated setting does not apply to InstallScript projects.
In addition, the type of InstallShield prerequisite—either setup prerequisite or feature prerequisite—may affect whether
UAC prompts are displayed during an installation on Windows Vista and later systems. To learn more about these two
types of InstallShield prerequisites, see Setup Prerequisites vs. Feature Prerequisites.
• If Required Execution Level is set to Invoker, any InstallShield prerequisites in your installation do not require
administrative privileges, and Require Administrative Privileges is set to No, end users should see no UAC prompts
during installation.
• If Required Execution Level is set to Invoker, your installation includes setup prerequisites that require administrative
privileges, and Require Administrative Privileges is set to No, end users should see one UAC prompt—plus up to one
additional UAC prompt for each reboot—during installation.
• If the full user interface of the setup launcher is displayed and the installation includes setup prerequisites that need
to be installed, the setup launcher typically displays the setup prerequisite dialog before the main installation starts. If
one or more of the setup prerequisites that need to be installed require administrative privileges, the Install button on
the message box has the shield icon to alert the end user that elevated privileges are required.
• If the installation is continuing after a reboot and privileges must be elevated, the OK button of the continuation
message box has the shield icon. If privileges do not need to be elevated, the shield button is not displayed.
• If your installation includes more than one setup prerequisite that must be installed on a target machine and one or
more of those setup prerequisites requires administrative privileges, the UAC prompt is displayed before the first
setup prerequisite is installed. This may allow elevated privileges to be used for all prerequisites without requiring
separate UAC prompts for each prerequisite installation. Note, however, that if a setup prerequisite installation
causes a reboot, administrative privileges are lost, and a UAC prompt may be displayed if any of the remaining
prerequisites require administrative privileges.
A slightly different behavior applies to feature prerequisites. If your installation is going to install any features that are
associated with prerequisites, the UAC prompt is displayed when the ISInstallPrerequisites custom action relaunches
Setup.exe in feature prerequisite installation mode. This occurs regardless of whether any of the feature prerequisites
require elevated privileges. It also occurs before any of the feature prerequisites’ conditions are evaluated to
determine whether the feature prerequisites need to be installed. Note that if a feature prerequisite installation
causes a reboot, administrative privileges are lost. After the reboot, the ReadyToInstall dialog is displayed again, and
the end user needs to click the Install button to proceed with the rest of the installation. In this case, the UAC prompt
is displayed again when the ISInstallPrerequisites custom action relaunches Setup.exe in feature prerequisite
installation mode.
• Note that if Require Administrative Privileges is set to No but your .msi package tries to perform a task for which it
does not have adequate privileges, Windows Installer may display a run-time error.
• If privileges are elevated at the end of an installation and the SetupCompleteSuccess dialog launches the product,
elevated privileges are carried over to your product. In most cases, running an application with elevated privileges is
discouraged.
Sample Scenarios
The following sections contain examples that illustrate different combinations of values for the aforementioned settings in
InstallShield. The diagrams show when Windows Vista and later request elevated privileges for standard users or
administrative users who have limited privileges. The examples are based on the default UAC settings on Windows Vista
and later systems.
Example 1: UAC Prompt Is Displayed for a Prerequisite that Requires Administrative Privileges; .msi File
Is Advertised
The example 1 diagram shows an installation that requires elevation for a setup prerequisite, a feature prerequisite, and
for the Execute sequence of the .msi package. Windows Vista and later display one UAC prompt for the setup prerequisite,
and another one for the feature prerequisite.
If the feature prerequisite was not included or if it was a setup prerequisite instead of a feature prerequisite, the second
UAC prompt (which is labeled as UAC prompt #2 in the diagram) would not be displayed. In these cases, UAC prompt #2
would not be needed because the .msi package is successfully advertised after the setup prerequisite is installed with
elevated privileges.
Figure 4-1: Example 1—Diagram of an Installation that Has Invoker as the Required Execution Level and that Advertises
the .msi Package
Example 2: UAC Prompt Is Displayed for Setup.exe and After a Reboot for a Prerequisite that Requires
Administrative Privileges
The example 2 diagram shows an installation that requires elevation for Setup.exe, two setup prerequisites, a feature
prerequisite, and the Execute sequence of the .msi package. Because the Setup.exe file has a manifest that specifies
Administrator as the required execution level, elevated privileges are used for each part of the installation. The second UAC
prompt is displayed because elevated privileges are lost during a reboot.
Figure 4-2: Example 2—Diagram of an Installation that Has Administrator as the Required Execution Level
See Also
Run-Time Behavior for an Installation that Includes InstallShield Prerequisites
Setup Prerequisites vs. Feature Prerequisites
Using Windows Installer with UAC (Windows Installer Help Library)
Using Windows Installer with UAC (Windows Installer Help Library)
Guidelines for Packages (Windows Installer Help Library)
Guidelines for Packages (Windows Installer Help Library)
Authoring Packages without the UAC Dialog Box (Windows Installer Help Library)
Authoring Packages without the UAC Dialog Box (Windows Installer Help Library)
Installing a Package with Elevated Privileges for a Non-Admin (Windows Installer Help Library)
Installing a Package with Elevated Privileges for a Non-Admin (Windows Installer Help Library)
Windows Installer uses a process called file costing to determine the total disk space a current installation requires. This
encompasses costs for files that will be installed or removed, registry entries, shortcuts, and other components of an
installation.
File Costing
File costing takes into account the fact that some files are overwritten by newer versions, which decreases the file cost.
These values are dependent on the volume to which each file is to be installed or removed, and they are recalculated when
a component’s directory association is changed.
File costs are determined for each component, depending on whether it is installed locally, installed to run from the source
media, such as a CD, or removed.
With InstallShield, you can set your application’s disk usage. This allows you to control file costing by choosing to run your
application from the source media, from the local machine, or to install it when required. Note that running your
application from the source enhances application resiliency and conserves space on an end user’s system.
Application Resiliency
If Windows Installer cannot provide a component, the Windows Installer technology enables applications to try to repair
the component or to reinstall the component if the corresponding file is corrupted or the current file is older than the
available version.
Source Resiliency
In addition to supporting application resiliency, the Windows Installer supports source resiliency through the Source List,
which can include network locations, URLs, or compact discs from which applications are installed on-demand.
Administrators can use the Group Policy Editor to disable this functionality.
INSTALLDIR represents the main product installation directory for a Basic MSI and InstallScript MSI installations, such as
the end user launching Setup.exe or your .msi database.
TARGETDIR represents the installation directory for an InstallScript installation, or for an administrative Windows Installer–
based installation (when the user runs Setup.exe or MsiExec.exe with the /a command-line switch).
In an InstallScript MSI project, the InstallScript variable MSI_TARGETDIR stores the target of an administrative installation.
See Also
Setting the Default Product Destination Folder (INSTALLDIR)
Setup.exe and Update.exe Command-Line Parameters
TARGETDIR (InstallScript Variable)
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
To prevent end users from being able to install the current version of your product over a future major version of the same
product, the Upgrades view should contain a major upgrade item, the major upgrade item should be properly configured
to prevent the current version of your product from being installed over a future version, and your project should include a
properly configured and scheduled type 19 custom action.
When you create a new Basic MSI or InstallScript MSI project, InstallShield automatically adds support for preventing the
current installation from overwriting a future major version:
The Products sharing my Upgrade Code option is selected on the Common tab of the major upgrade item. The value
of the Upgrade Code setting on the Advanced tab is {000000000000-0000-0000-0000-00000000}. When you build a
release, InstallShield uses the appropriate upgrade code value instead of the placeholder value in the .msi package
that it generates at build time. For more information on the upgrade code, see Setting the Upgrade Code.
InstallShield sets the Detect Property setting of this major upgrade item to ISFOUNDNEWERPRODUCTVERSION and
configures the other settings as appropriate.
• The Custom Actions and Sequences view contains a custom action called ISPreventDowngrade, a type 19 custom
action that Windows Installer launches when an end user tries to install the current version of your product over a
future major version.
InstallShield schedules the ISPreventDowngrade custom action for the user interface and execute sequences of the
installation sequence so that Windows Installer runs it if appropriate, regardless of what user interface level is used. In
addition, InstallShield uses ISFOUNDNEWERPRODUCTVERSION as the condition for this custom action.
The following instructions explain how to manually add this support for projects that you created in InstallShield 12 or
earlier and then upgraded to InstallShield 2020.
Task To manually add support for preventing end users from being able to install the current version of your product over a
future major version:
1. Use the Upgrades view to add a major upgrade item to your project.
2. On the Common tab, select the Products using my Upgrade Code option.
3. Configure the settings on the Advanced tab for the major upgrade item as follows:
a. In the Minimum Version setting, specify the product version that you are using for your current project.
***ALL_VERSION***
That value is a placeholder value. If you use that extract string in the Minimum Version setting, InstallShield uses
the product version of the currently open project instead of the placeholder value in the .msi package that it
generates at build time.
b. Leave the Maximum Version setting blank. If a value is listed for this setting, delete it.
c. If your project includes multiple languages, specify the language identifiers in the Language setting.
d. In the Detect Only setting, select Yes; for all of the other Yes-No settings, select No.
e. In the Detect Property setting, type a descriptive name such as the following one:
FOUNDNEWERVERSION
4. Add and schedule a type 19 custom action for your project to handle scenarios where an end user tries to install the
current version of your product over a future major version:
a. In the Custom Actions and Sequences view, right-click the Custom Actions explorer and click New Error.
c. In the Error Message setting, type the error message text that should be displayed when an end user tries to
install the current version of your product over a future major version.
d. In the Install UI Sequence and Install Exec Sequence settings, select After FindRelatedProducts.
e. In the Install UI Condition and Install Exec Condition settings, type the value that you specified in step 3e.
See Also
ISICE19
Preventing an Old Package from Installing Over a Newer Version (Windows Installer Help Library)
Preventing an Old Package from Installing Over a Newer Version (Windows Installer Help Library)
Windows Installer 3.0 and later enables you to create patches that can be installed by non-administrators. Non-
administrator patches can be used if strict criteria are met. For example, the base installation that the patch will update
must include the certificate that will be used to sign the patch package. To learn about the other criteria that must be met,
see Non-Administrator Patches.
Task To prepare a base installation that can later be updated by non-administrator patches:
2. In the Releases explorer, click the release whose digital signature information you want to configure.
InstallShield automatically adds the necessary information to the MsiDigitalCertificate table and the
MsiPatchCertificate table. This enables you to create patches that can be installed by non-administrators.
Tip • The digital signature settings are also available in the Releases view.
The Windows Installer design enables you to sign a package with one certificate and also allow patches that are signed with
a different certificate. The following instructions explain how to add to the base installation the additional certificates for
the patches.
1. Use a tool such as SignTool.exe to sign a dummy file. SignTool.exe is part of the Windows SDK.
6. Click the CertData field. The Edit Binary Stream dialog box opens.
7. In the File name box, enter the path and name of the file that you signed in step 1. You can click the browse button to
find the file.
8. Click OK.
10. Click the last row in the table to add a new entry.
11. In the PatchCertificate field, type a unique name for your patch certificate.
12. In the DigitalCertificate field, select the entry that you created for the MsiDigitalCertificate table in step 4.
See Also
Signing a Patch Package
Signing a QuickPatch Package
Digital Signing and Security
User Account Control (UAC) Patching (Windows Installer Help Library)
User Account Control (UAC) Patching (Windows Installer Help Library)
MsiDigitalCertificate Table (Windows Installer Help Library)
MsiDigitalCertificate Table (Windows Installer Help Library)
MsiPatchCertificate Table (Windows Installer Help Library)
MsiPatchCertificate Table (Windows Installer Help Library)
• InstallScript
• InstallScript MSI
Note that some of the settings apply to both of these project types, but some apply only to one of these project types.
InstallShield includes several settings for platforms, platform suites, and languages.
• Platform Filtering—Use this setting to specify the platforms that you want to be available when you select operating
system requirements for components or releases in your project. In general, if a platform is not listed for this setting at
the project level, you cannot designate that a particular component or release in your project is targeted for that
platform.
The Platforms setting is available for InstallScript projects. To access this setting, open the General Information view.
You can also configure this setting through the Project Settings dialog box: on the Project menu, click Settings, and
click the Platforms tab.
Note • Specifying platforms at the project level does not create target system requirements for running the installation. If you
want to create target system requirements in an InstallScript project, use the SYSINFO structure to identify the operating
platform of the target system.
For information on how to specify target system requirements for InstallScript MSI projects, see Specifying Operating System
in the Project Assistant.
• Operating Systems—If a component is specific to one or more operating systems, use this setting to indicate those
operating systems. If the target machine’s operating system does not match one of the operating systems that are
specified for this setting, the component is not installed.
By default, components are operating system independent, meaning that none of the component’s data are specific
to certain operating systems.
The Operating Systems setting is available for InstallScript and InstallScript MSI projects. To access this setting, open
the Components view and select a component.
• Platform Suite(s)—If a component is specific to one or more platform suites, use this setting to indicate the suites. If
you specify more than suite, you can indicate whether all or any of the suites must be present on the target machine in
order for the component to be installed.
By default, components are platform suite independent, meaning that none of the component’s data are specific to a
particular platform suite.
This setting provides an additional layer of filtering beyond the Operating Systems setting. Set the Platform Suite(s)
setting only if necessary, and be sure to select only those platform suites that are required for the proper functioning
of your application. For example, if a component should be installed on both the Home and Professional editions of
Windows XP, you can leave Suite Independent as the value for this setting; selecting Windows XP for the Operating
Systems setting encompasses both editions.
The Platform Suite(s) setting is available for InstallScript projects. To access this setting, open the Components view
and select a component.
• Platform(s)—If a release is specific to one or more platforms, use this setting to indicate the platforms. If the platform
specified for a component does not match one of the platforms that is selected for this setting, InstallShield does not
include the component in the release.
The default value for this setting is Use Project Setting. This value indicates that the release supports the platforms
that are specified at the project level.
The Platform(s) setting is available for InstallScript projects. To access this setting, open the Releases view and select
a release. You can also configure this setting through the Platforms panel in the Release Wizard.
Controlling Support for Platforms and Platform Suites at Run Time for InstallScript
Projects
During run time of InstallScript installations, you can control the platforms and platform suites that your installation
supports by calling the FeatureFilterOS function.
In the OnFilterComponents event handler, the framework typically calls this function with the platforms and platform
suites that match the target system so that only the appropriate components are installed. By calling FeatureFilterOS, you
can override this default behavior to install or prevent the installation of components based on any platform or platform
suite criteria that you specify.
See Also
Specifying Operating System in the Project Assistant
Platforms Tab
Platforms Dialog Box
Modify Property Dialog Box/Release Wizard—Platforms Panel
As you begin creating your installation project, you will need to specify important installation information at the outset.
This includes specifying product and project settings and configuring Add or Remove Programs settings.
InstallShield stores your project settings in a single installation project file (.ism file). This file stores all of the information
about your project. In the General Information view, you can edit basic information about your installation project—
including the author’s name, the languages that the project supports, and any comments that you want to include.
The General Information view is also where you configure general product information such as the product name, the
product code (GUID), and the version number. A product is the top level of organization in an installation project. The
installation is further divided into features and components, which are subsets of your product. Although an installation
can contain multiple features and components, it can have only one product.
For detailed information about each of the project and projects settings that are available, see General Information View.
InstallShield lets you save your .ism project file in XML or binary format.
2. In Project File Format setting, select the appropriate option. Available options are:
• Binary—To save the project file as a database file, select this option. This format is best for the speed of opening
and saving the project file.
• XML—To save the project file as a hierarchical text-based format, select this option. This project file format is best
for use with source code control systems.
Note • Your InstallShield project file (.ism) retains the .ism file extension when you save it in XML or binary format.
Advanced UI and Suite/Advanced UI projects (.issuite) are always saved as XML files.
Enter the name of your product in the Product Name setting of the General Information view. The name that you enter
should be the name of the product for which you are creating an installation. This value is used throughout your project, in
various instances; for example:
• The name of the source file folder under the project location
• In Basic MSI and InstallScript MSI projects: the name of the Windows Installer package (.msi file) that InstallShield
builds by default
• In run-time dialogs
• Under the informational registry key in accordance with Windows logo requirements. The informational values are
found in the following location and are used in Add or Remove Programs to enable an end user to change or remove
your product.
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\ProductCode
Since it will be incorporated into the paths for your source files, the product name cannot contain any of the following
characters: \ / : * ? " < > | . -
Tip • In an InstallScript or InstallScript MSI project, you can use the UNINSTALL_DISPLAYNAME variable to specify a different
product display name in Add or Remove Programs.
For Basic MSI and InstallScript MSI projects—If you do not want to use the product name for the .msi package file name, you
can use the MSI Package File Name setting on the General tab for a product configuration in the Releases view and specify a
different .msi file name. Note that if you want to be able to release minor upgrades or small updates to update your product,
the previous and latest versions of your installation must have the same .msi package name. Attempting to perform a minor
upgrade or a small update when the .msi file name has changed can lead to Windows Installer run-time error 1316.
Caution • If you want to include an ampersand (&) in your product name, you must use two ampersands (&&) to display the
name properly in end user dialogs. For example, to display New & Improved Product, you should enter the product name as
New && Improved Product.
See Also
Designing Merge Modules
General Information View
UNINSTALL_KEY
When you are specifying the version number for your product, you must ensure that you enter a valid product version. The
version must contain only numbers. It is typically in the format aaa.bbb.ccccc or aaa.bbb.ccccc.ddddd, where aaa
represents the major version number, bbb represents the minor version number, ccccc represents the build number, and
ddddd represents the revision number. The maximum value for the aaa and bbb portions is 255. The maximum value for
ccccc and ddddd is 65,535.
At run time, the installation registers the version number of the product that is being installed. The entire version string is
displayed in Add or Remove Programs. The product version number is important because the installation engine uses it in
part to determine whether to apply an upgrade.
To configure the product version, use the General Information view. This product version can be overridden in other areas
of InstallShield—for example, for a product configuration in the Releases view of a Basic MSI project. You can also specify
the version number that you want an upgrade to target in other areas of InstallShield—for example, in the Upgrades view of
a Basic MSI or InstallScript MSI project.
Note that although you can include the fourth field (ddddd) when you specify your product’s version, the installation does
not use this part of the product version to distinguish between different product versions.
Project • For Advanced UI, Basic MSI, InstallScript, InstallScript MSI, and Suite/Advanced UI projects—If your release includes
a Setup.exe file, the product version that you specify is displayed on the Properties dialog box for Setup.exe. For more
information, see Customizing File Properties for the Setup Launcher.
For InstallScript and InstallScript Object projects—Instead of hard-coding a value, you can use a path variable that is defined
in the Path Variables view. At build time, InstallShield replaces the path variable with the appropriate value. (To use a path
variable: On the Project menu, click Settings. Then select the appropriate path variable on the Application tab.)
See Also
ProductVersion Property (Windows Installer Help Library)
ProductVersion Property (Windows Installer Help Library)
Designing Merge Modules
General Information View
Product Version Numbers in InstallScript and InstallScript Object Projects
• InstallScript
• InstallScript Object
By default, InstallScript projects use version numbers in packed DWORD format—that is, as a four-byte value whose first
byte is the major version, second byte is the minor version, and last two bytes are the build number. Packed DWORDS are
entered and displayed in the format major.minor.build; for example, 1.2.3 or 255.255.65535. Packed DWORD version
numbers are assumed in the default script code for registering the version number of the product that is being installed,
and for comparing that version number to that of the already installed product during an update installation.
If any of these version numbers are not in packed DWORD format, you must modify the script code as discussed in the
following sections.
variable to the string equivalent of the data in the Version value under the application uninstallation registry key. If that
value does not exist, or its data is not a packed DWORD, then the value of IFX_INSTALLED_VERSION is a null string (""), in
which case the default OnSetUpdateMode code displays an error message and aborts the installation. One solution is to
insert code that checks the version information on the system and sets IFX_INSTALLED_VERSION equal to an appropriate
packed DWORD value. For example, if previous installations stored a version string in the MyVersion value under
HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany\MyProduct, you could insert code like the following:
if (IFX_INSTALLED_VERSION="") then
/* Get the registered version information. */
RegDBSetDefaultRoot( HKEY_LOCAL_MACHINE );
RegDBGetKeyValueEx( "Software\\MyCompany\\MyProduct",
"MyVersion", REGDB_STRING, szVersionString, nSize );
See Also
Creating an InstallScript Release to Update Previous Versions
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The product code is a string that uniquely identifies your product. An installation uses a product code at run time to
determine whether the product has already been installed.
Enter a GUID that uniquely identifies your product, or click the Generate a new GUID button ({...}) in the Product Code
setting in the General Information view to let InstallShield generate a new GUID. The installation registers this GUID at run
time.
Caution • Because the product code uniquely identifies your product, changing the code after distributing a release of your
product is not recommended.
See Also
GUIDs
General Information View
• InstallScript
• InstallScript Object
The product code is a GUID string that uniquely identifies your product. An installation uses a product code at run time to
determine whether the product has already been installed.
Enter a GUID that uniquely identifies your product, or click the Generate a new GUID button ({...}) in the Product Code
setting in the General Information view to let InstallShield generate a new GUID. The installation registers this GUID at run
time.
Caution • The project GUID is used to associate uninstallation or maintenance with the original installation. A new GUID is
automatically generated for each new project that you create, including copies of existing projects. Once you have changed a
project's GUID, its previous GUID cannot be recovered. For these reasons, changing a project's GUID is typically not necessary
and should be approached with caution.
See Also
GUIDs
General Information View
• Basic MSI
• InstallScript MSI
• MSI Database
• QuickPatch
• Transform
The upgrade code is a GUID that uniquely identifies the product family to which the product belongs. In most cases, the
upgrade code should be consistent across different versions and languages of a family of related products so that Windows
Installer can use it to search for related versions of the product that are already installed.
To configure the GUID for a new product, use the Upgrade Code setting in the General Information view. This upgrade code
value can be overridden in other areas of InstallShield—for example, for a product configuration in the Releases view, or for
each instance that is defined on the Multiple Instances tab for a product configuration in the Releases view.
When you are working on an upgrade for a new version of your product, use the upgrade code that was configured in the
General Information view (or overridden in one of the aforementioned other areas of InstallShield) as the GUID that you
specify in the Upgrades view of your upgrade project or in your QuickPatch project; when these upgrade codes match, the
upgrade or patch can target the base version, and Windows Installer can update it as needed.
See Also
Major Upgrade vs. Minor Upgrade vs. Small Update
GUIDs
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The Installation Requirements page in the Project Assistant lets you specify some commonly used installation
requirements for the target system. For example, if your application requires a specific operating system in order to run
properly, you can indicate that on the Installation Requirements page.
InstallShield also enables you to define your own custom conditions that Windows Installer must evaluate before your
product can be installed. Conditions that you create in the General Information view and on the Installation Requirements
page in the Project Assistant apply to the entire product; if one or more of the conditions are false on the target system, the
installation exits and an error message is displayed.
For example, if your product requires 64 MB of RAM in order to run properly, you can use the Product Condition Builder
dialog box to create a condition. At run time, the Windows Installer checks the target system to determine how much RAM
is installed. If it is less than 64 MB, or if any of the other product conditions are false, the Windows Installer displays an error
message and exits the installation.
Tip • You cannot guarantee the order in which Windows Installer evaluates product launch conditions. If it is necessary to
control the order in which the conditions are evaluated, you can create an error custom action in the Custom Actions and
Sequences view for each condition, and schedule them in the appropriate order.
2. Click the Install Condition setting and then click the ellipsis button (...). The Product Condition Builder dialog box
opens.
3. Click the New Condition button. InstallShield adds a new condition row to the Conditions box.
• Use the Properties list, the Operators list, and the Add buttons to build your conditional statement:
a. In the Properties list, select a property and then click the Add button. InstallShield adds the property to the
Condition column.
b. If your conditional statement should contain an operator, select an operator in the Operators list and then
click the Add button. InstallShield adds the operator to the conditional statement.
c. If your conditional statement should contain a value, double-click the condition field, press END so that the
insertion point is at the end of the condition statement, and enter the value.
5. In the Message column, enter the error message that you would like to be displayed if the condition evaluates to false.
When you type a value for this column, you are creating a string entry and setting its initial value for all of the
languages that are currently in the project. As an alternative to typing a new value, you can double-click this setting
and then click the ellipsis button (...) in this setting to select an existing string. For more information, see Using String
Entries in InstallShield.
Note • Windows Installer dialogs, which display the text that you specify in the Message column, do not recognize the
escape sequences \r (carriage return), \n (new line), or \t (tab).
6. Click OK.
Important • InstallShield performs basic condition validation; however, you should still double-check that your condition
statements evaluate to the expected outcome. For more information and example conditions, see Building Conditional
Statements.
See Also
Conditional Statement Syntax (Windows Installer Help Library)
Conditional Statement Syntax (Windows Installer Help Library)
Installation Requirements Page
Product Condition Builder Dialog Box
Conditional Statement Syntax
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Your project’s INSTALLDIR property serves as the default folder for all of your product’s files. Its value is assigned to the
Windows Installer folder property INSTALLDIR, which is the default feature and component destination folder.
Windows Logo • According to the Windows logo program requirements, the default destination of your product’s files must
be a subfolder of the Program Files folder or the end user’s Application Data folder, regardless of the language of the target
system. If you use ProgramFilesFolder as the parent folder for your product’s destination folder setting, your files are installed
to the correct location. The default value for the INSTALLDIR setting is:
2. To use a built-in Windows Installer directory as part of your path: In the INSTALLDIR setting, click the ellipsis button
(...) . The Set INSTALLDIR dialog box opens. In the Destination Directories box, select a destination folder.
As an alternative, you can manually enter the path in the INSTALLDIR setting.
Note • Selecting a new folder property in the Set INSTALLDIR dialog box overwrites the contents of the value in the
INSTALLDIR setting. You can specify a subfolder of any folder property by separating subfolders with a backslash—for
example, [ProgramFilesFolder]My Company\Program.
Each feature and component has a Destination setting. The feature’s Destination setting overrides the product’s
Destination Folder setting, and the component’s Destination setting overrides the feature’s. Therefore, if you want all of
your product’s files to be installed by default to the product’s destination folder, enter [INSTALLDIR] for all of your
features’ and components’ Destination settings.
When using an installer folder property such as INSTALLDIR, you are specifying a default value. An end user could change
this value by setting a property when launching Msiexec.exe at the command line or by selecting a new destination folder
for a feature in the CustomSetup dialog.
See Also
Component Destination vs. Feature Destination
InstallShield offers several ways to secure files, folders, registry keys, and Windows services for end users who run your
product in a locked-down environment:
• Traditional Windows Installer handling—In Windows Installer–based projects, you can choose to use the built-in
Windows Installer support for setting permissions for files, folders, and registry keys at run time. With this option,
InstallShield stores permission information for your product in the LockPermissions table of the .msi database.
This type of permission handling cannot be combined with the new Windows Installer handling; if you try to build a
release that contains the MsiLockPermissionsEx table and the LockPermissions table, build error -7207 occurs.
• New Windows Installer handling—In Windows Installer–based projects, you can choose to use the latest Windows
Installer support for setting permissions for files, folders, registry keys, and Windows services at run time. With this
option, InstallShield stores permission information for your product in the MsiLockPermissionsEx table of the .msi
database.
This option requires Windows Installer 5 or later on the target system; earlier versions of Windows Installer ignore
settings for this type of handling.
This type of permission handling cannot be combined with the traditional Windows Installer handling; if you try to
build a release that contains the MsiLockPermissionsEx table and the LockPermissions table, build error -7207
occurs.
• Custom InstallShield handling—In Windows Installer–based projects, you can choose to use custom support for
setting permissions at run time. With this option, InstallShield stores permission information for your product in the
custom ISLockPermissions table of the .msi database. InstallShield also adds custom actions to your project.
All of these methods enable you to assign permissions for a file, folder, or registry key to specific groups and users. For
example, you may assign Read, Write, and Delete permissions for a particular file to the Administrators group, but only
Read permissions for all of the users in a different group. The new Windows Installer handling option also lets you assign
permissions for a Windows service.
Project type • Traditional Windows Installer handling, New Windows Installer handling, and
Custom InstallShield handling—Available in the following project types: Basic MSI,
DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform.
Also available through InstallScript custom actions in the following project types: Basic
MSI, DIM, InstallScript MSI, and Merge Module.
Localized names for • Traditional Windows Installer handling—Does not support localized names for SIDs;
SIDs if you try to use a localized name, the installation fails.
Ability to deny specific • Traditional Windows Installer handling—Not supported. This handling lets you set
permissions specific permissions; you cannot deny permissions. Thus, you can give a user read-only
access to a file. However, you cannot prevent a user from having read-only access.
Table 4-1 • Comparison of Different Ways to Secure Objects in a Locked-Down Environment (cont.)
Effect on permissions • Traditional Windows Installer handling—Existing permissions may be deleted. For
that already exist example, if permissions are already set for a folder on the target system for the
Everyone user, and your installation needs to set permissions for the Administrators
user, this option would allow you to set permissions for the Administrators user.
However, the existing permissions for Everyone would be deleted.
Ability to propagate • Traditional Windows Installer handling—Not supported. If you want to configure
permissions to child permissions for a subfolder or a file in a folder (or a subkey under a registry key), the
objects (subfolders, parent that is created on the target system automatically inherits the permissions of its
files, and subkeys) child.
Ability to set • Traditional Windows Installer handling, New Windows Installer handling, and
permissions for objects Custom InstallShield handling—Not supported.
that are not being
• SetObjectPermissions function—Supported. You can secure permissions for a file,
installed as part of your
folder, or registry key that is installed as part of your installation, or it can be already
installation
present on the target system.
Learning More about the Custom InstallShield Handling Option or the Traditional
Windows Installer Handling Option
In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform projects, you need to
specify whether you want to use the custom InstallShield handling or the Windows Installer handling. To learn how, see
Selecting the Locked-Down Permissions Type for a Project.
To learn how to set permissions for a file or folder using either of these options, see Configuring Permissions for Files and
Folders. For information on setting permissions for a registry key using either of these options, see Configuring Permissions
for Registry Keys.
To use the new Windows Installer handling option for files, folders, or registry keys, use the MsiLockPermissionsEx table
in the Direct Editor view.
See Also
LockPermissions (Windows Installer Help Library)
LockPermissions (Windows Installer Help Library)
MsiLockPermissionsEx (Windows Installer Help Library)
MsiLockPermissionsEx (Windows Installer Help Library)
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield includes a project-wide setting that lets you specify how your installation should configure permissions for
files, folders, and registry keys for end users in a locked-down environment.
• Custom InstallShield handling—InstallShield adds a custom table and custom actions to your project to set
permissions on the target system. This is the default value.
• Traditional Windows Installer handling—InstallShield uses the LockPermissions table in the .msi database to
store permissions information for your product.
For a detailed comparison of these two options, see Securing Files, Folders, Registry Keys, and Windows Services in a
Locked-Down Environment.
The next time that you configure permissions for a file, folder, or registry key in your project, InstallShield uses the locked-
down permission type that you selected:
• If you selected the traditional Windows Installer handling option, InstallShield uses the LockPermissions table in
your project.
• If you selected the custom InstallShield handling option, InstallShield uses the ISLockPermissions table in your
project; InstallShield also adds the ISLockPermissionsCost and ISLockPermissionsInstall custom actions to your
project.
If you change the value of the Locked-Down Permissions setting but your project already contains permission settings for
files, folders, or registry keys, InstallShield displays a message box that lets you specify whether you want to migrate the
permission data to the appropriate table. If you choose to migrate the data, InstallShield moves the data to the table that
corresponds with the option that you selected; if you are switching from the custom InstallShield handling option to the
traditional Windows Installer handling option, InstallShield also deletes the ISLockPermissionsCost and
ISLockPermissionsInstall custom actions from your project.
See Also
LockPermissions (Windows Installer Help Library)
LockPermissions (Windows Installer Help Library)
InstallShield enables you to specify on a project-wide basis whether Windows Installer 4.0 or later should log your
installation. You can also customize the types of messages that are logged.
Task To specify project-wide logging information for Windows Installer 4.0 or later:
2. Click the Create MSI Logs setting, and then click the ellipsis button (...). The Logging Options for Windows Installer
4.0 and Later dialog box opens.
3. Select the appropriate option. If you select the custom option, enter the MsiLogging value.
For a list of valid parameters for the MsiLogging value, see MsiLogging Property in the Windows Installer Help Library.
4. Click OK.
The results vary, depending on which option you select in the Logging Options for Windows Installer 4.0 and Later dialog
box:
• If you select No, installations are not logged. This is the default value.
• If you select Yes, InstallShield populates the MsiLogging property with the default value of voicewarmup. If the
installation is run on a target system that has Windows Installer 4.0, the following occurs:
• The installer creates a log file according to the default logging mode of voicewarmup.
• The installer populates the MsiLogFileLocation property with the log file’s path.
• A Show the Windows Installer log check box is added to the SetupCompleteSuccess, SetupCompleteError, and
SetupInterrupted dialogs. If the end user selects that check box and then clicks Finish, the log file is opened in a
text file viewer or editor.
• If you select Custom, InstallShield populates the MsiLogging property with the value that you specify in the box. If the
installation is run on a target system that has Windows Installer 4.0, the following occurs:
• The installer creates a log file according to the custom value that you specified in the box.
• The installer populates the MsiLogFileLocation property with the log file’s path.
• A Show the Windows Installer log check box is added to the SetupCompleteSuccess, SetupCompleteError, and
SetupInterrupted dialogs. If the end user selects that check box and then clicks Finish, the log file is opened in a
text file viewer or editor.
Earlier versions of Windows Installer ignore the MsiLogging setting. The Show the Windows Installer log check box is not
visible in run-time dialogs that are displayed on systems running earlier versions of Windows Installer.
Important • The MsiLogFileLocation property is read-only; it cannot be used to set or change the log file location.
See Also
Logging Options for Windows Installer 4.0 and Later Dialog Box
The InstallScript project type offers several options for the behavior of your installation when a target machine already has
your product installed and the end user reruns the installation.
Multi-Instance Only when the installation is rerun Multiple—a separate entry for each
from the Add or Remove Programs instance
You can select these options from the Maintenance Experience setting in the General Information view.
For the default behavior—the standard option—the maintenance user interface is displayed if end users rerun an
installation on machines.
The multi-instance option lets your end users rerun an installation multiple times as a first-time installation rather than as
a maintenance installation. By default, this option lets end users install the product to a different location each time that
they run the installation. Each time that they run the installation as a first-time installation, the components that they
select (whether directly or by selecting a setup type) are installed.
If one or more instances of your product are present on a machine when an end user reruns the multi-instance installation
with a user interface, the installation displays the Qualifying Product(s) Detected dialog. This dialog enables the end user to
select the instance to which the update should be applied. However, if the end user reruns the installation silently, the
installation suppresses the Qualifying Product(s) Detected dialog and creates a new instance on the machine.
Project • For information on multiple-instance support in Basic MSI projects, see Installing Multiple Instances of Products.
Use the Enable Maintenance setting in the General Information view to indicate whether you want to display the full
maintenance user interface (UI) or the uninstallation UI when end users rerun the installation on a system on which the
product is already present.
The following table shows the available options for the Enable Maintenance setting.
Option Description
Yes Unless the /removeonly command-line parameter is passed to Setup.exe, the system variable
REMOVEONLY is set to FALSE when an end user reruns the installation, and the standard
maintenance UI is displayed.
No The system variable REMOVEONLY is set to TRUE when an end user reruns the installation, and
the uninstallation UI is displayed.
Note • Selecting No for the Enable Maintenance setting does not cause the OnUninstall event
handler to be called. If you want the OnUninstall event handler to be called, you must use the /
uninst command-line parameter for Setup.exe. Note that this is applicable only if the InstallScript
UI style is the traditional style, which uses the InstallScript engine as an external UI handler. The /
uninst command-line parameter is not supported if the InstallScript UI style is the new style (which
uses the InstallScript engine as an embedded UI handler). To learn more, see Using the InstallScript
Engine as an External vs. Embedded UI Handler for InstallScript MSI Installations.
Note • InstallScript MSI installations show separate Change and Remove buttons in Add or Remove Programs in the Control
Panel by default. Clicking the Change button always displays the maintenance UI, and clicking the Remove button always
displays the uninstallation UI.
The Enable Maintenance setting has no effect on the behavior that occurs if end users initiate maintenance for your product by
clicking the Change button for your product’s entry in Add or Remove Programs.
If you want to prevent end users from being able to run maintenance from within Add or Remove Programs, select Yes for the
Disable Change Button setting in the General Information view.
See Also
General Information View
Setup.exe and Update.exe Command-Line Parameters
REMOVEONLY
• The Windows Installer engine runs the standard Execute sequence of the .msi package. This is the sequence that
typically modifies the target system.
• The InstallScript engine serves as the custom user interface (UI) handler of the installation. It also executes the
InstallScript code. The advantage of using the InstallScript engine for the UI is that it offers support for highly
customized run-time dialogs.
Traditionally, Windows Installer has had support for only external custom UI handlers; therefore, InstallScript MSI
installations have always required a Setup.exe setup launcher. The setup launcher serves as a bootstrap application that
initiates the InstallScript engine to display the UI and run the InstallScript code, and the Windows Installer to run the
Execute sequence of the .msi package.
Windows Installer 4.5 introduces support for embedded custom UI handlers. If the InstallScript engine is embedded within
the .msi package, an InstallScript MSI installation does not require the Setup.exe setup launcher; end users can launch the
installation by launching the .msi package. In this case, the .msi package contains the information that the Windows
Installer needs to know about launching the InstallScript engine for the installation’s UI.
Thus, InstallShield offers two different styles for the UI of InstallScript MSI installations:
• Traditional style (requires a Setup.exe setup launcher)—This style lets you use the InstallScript engine as an external
UI handler for your InstallScript MSI installation. This is the default style.
• New style (requires Windows Installer 4.5 on the target machine)—This style lets you use the InstallScript engine as an
embedded UI handler for your InstallScript MSI installation. With this style, InstallShield embeds the InstallScript
engine within the .msi package. Note that this option has some limitations.
The following sections provide detailed information about these two styles; review this information to determine which
style would best meet your requirements.
2. All actions in the Installation UI sequence are run with the exception of the ExecuteAction. The actions are run in
ascending sequence order.
3. The InstallScript engine performs its own internal component costing to determine the space required for all features
and components in the installation.
4. The InstallScript engine launches the compiled script contained in ISSetup.dll. The event sequence for the events
that are run before the .msi package installation is as follows:
a. OnBegin
c. OnGeneratingMsiScript
d. OnMoving
e. OnFeaturesInstalling (Any feature installing and uninstalling events are run at this point.)
f. OnInstallFilesActionBefore
g. OnGeneratedMsiScript
5. The InstallScript engine launches the .msi package installation through MsiInstallProduct. The following factors
determine the command line that the InstallScript engine passes through MsiInstallProduct: installation mode (for
example, first-time installation, maintenance mode, minor upgrade, patch), internal feature selections, and current
property values.
6. If the .msi package installation is successful, the InstallScript engine writes the secondary uninstall key
(InstallShield_{ProductCode}) to the machine and then launches the following events:
a. OnInstallFilesActionAfter
b. OnFeaturesInstalled (Any feature installed and uninstalled events are run at this point.)
c. OnMoved
e. OnEnd
7. After the script has completed, the InstallScript engine writes the InstallScript log to the machine.
1. The .msi package is launched directly or by Setup.exe (which then launches Msiexec.exe, which is the same behavior
for a Basic MSI installation).
2. The Windows Installer engine extracts all files that are in the MsiEmbeddedUI table and calls the initialize embedded
UI function in the DLL that contains the embedded UI handler attribute. (In the InstallScript MSI case, this is
ISSetup.dll).
3. The InstallScript engine initializes and manually launches the ISSetupFilesExtract action if it is present and its
condition in the InstallUISequence evaluates to true.
4. The InstallScript engine performs manual resolution of all entries in the Directory table.
5. The InstallScript engine performs its own internal component costing to determine the space required for all features
and components in the installation.
6. The InstallScript engine launches the compiled script contained in ISSetup.dll. The event sequence for the events
that are run before the .msi package installation is as follows:
a. OnBegin
c. OnGeneratingMsiScript
d. OnMoving
e. OnFeaturesInstalling (Any feature installing and uninstalling events are run at this point.)
f. OnInstallFilesActionBefore
g. OnGeneratedMsiScript
7. The InstallScript engine returns control to the Windows Installer engine, which then begins running the installation’s
Execute sequence.
8. If the .msi package installation is successful, the Windows Installer engine calls back into ISSetup.dll. ISSetup.dll
then launches the following events:
a. OnInstallFilesActionAfter
b. OnFeaturesInstalled (Any feature installed and uninstalled events are run at this point.)
c. OnMoved
e. OnEnd
9. The InstallScript engine shuts down and returns control to the Windows Installer.
For the new-style InstallScript MSI installations, the Install UI sequence is not run. If any custom actions are sequenced in
the Install UI sequence, they will not run, similar to how such actions would not run in a Basic MSI that is launched with /qb
or /qn.
The InstallScript engine does not log any changes that are made to the system from InstallScript events.
Most command-line parameters that are supported by traditional-style InstallScript MSI installations are also supported
for new-style InstallScript MSI installations. If an end user launches the .msi package directly, these parameters can be
passed through the ISSCRIPTCMDLINE property.
The traditional style does not have support for creating uninstallable patches.
Limitations and Known Issues with the New Style (InstallScript Engine as an Embedded UI Handler)
If you are considering the new style, note the following details.
If Windows Installer 4.5 is not installed on a target system at run time, and the installation is launched with Setup.exe, the
setup launcher displays error 1713 and indicates that the installation requires Windows Installer 4.5 or later in order to run.
The installation aborts after the end user dismisses this error message. If the .msi package is launched directly, the
installation displays an error indicating that the package needs to be launched from the Setup.exe file.
InstallShield does not include any built-in support for creating an upgrade that uses the new style if the upgrade updates a
product that was installed with the traditional style. Therefore, if you use the traditional style to build a release of your
product and then you later create an upgrade, consider using the traditional style again for the upgrade. This applies to all
types of upgrades (major upgrades, minor upgrades, and small updates) that are packaged as full-installations or as
patches.
Note that if the previous setups that a patch is targeting use the traditional style, the patch should also use the traditional
style. Also note that a QuickPatch project maintains the UI style from the original installation. Therefore, if the original
installation used the traditional style, the QuickPatch package also uses the traditional style. If the original installation
used the new style, the QuickPatch package also uses the new style.
As a workaround for the major upgrade scenario, you could consider having your new-style major-upgrade installation
read the uninstall string of the earlier product from the registry, and launching it with the InstallScript function
LaunchApplication to uninstall the earlier version of your product before installing the new version. Note that you may
need to set LAAW_SHELLEXECUTEVERB to runas before using LaunchApplication in your script.
MsiDoAction
Attempting to call the MsiDoAction function from one of the events that are run before the .msi package installation
returns an error. This error occurs because of the handle that the Windows Installer passes to the InstallScript engine. The
handle does not support running standard or custom actions in the .msi package. This function can be called from
InstallScript custom actions if needed.
The Windows Installer MsiGetTargetPath and MsiSetTargetPath functions do not work correctly in the new style if they
are in event-driven script. These functions rely on the Directory Manager having been initialized by the Windows Installer
costing actions. In new-style InstallScript MSI installations, Windows Installer costing is not performed. Thus,
MsiGetTargetPath fails to return any path information, and MsiSetTargetPath fails to set the requested target path. In
both cases, Windows Installer logs messages in a verbose log if either of these functions are called.
Note that MsiGetTargetPath and MsiSetTargetPath can be called through InstallScript custom actions that are
sequenced after CostFinalize in the Installation Execute sequence.
The behavior of the InstallScript functions FeatureTransferData and ComponentTransferData is undefined for the new
style of InstallScript MSI installations and should not be used.
program…endprogram
New-style InstallScript MSI installations cannot use procedural scripts (that is, those with a program…endprogram block).
The program function is not called in this case. An event-driven script should be used to customize the behavior of the
installation.
/uninst
New-style InstallScript MSI installations do not support the /uninst command-line parameter.
BATCH_INSTALL
Attempting to reboot by setting the BATCH_INSTALL variable does not work correctly. To perform a reboot, use the
ScheduleReboot action for the REBOOT property.
Reboot Support
Reboots for new-style InstallScript MSI installations are handled in the same manner as they are handled for Basic MSI
installations—not as they are handled for InstallScript-based installations (where the installation resumes after the restart
and the OnRebooted event handler is called).
New-style InstallScript MSI installations should be authored similarly to Basic MSI installations to handle reboots; the
installation does not run after a scheduled reboot occurs, and the OnRebooted event handler is not called.
If an end user tries to uninstall the product through the command line using the statement Msiexec.exe /x
{ProductCode}, the uninstallation may be successful. However, the Windows Installer displays an error dialog near the end
of the uninstallation. The error dialog indicates that the Windows Installer service could not be accessed.
To perform an uninstallation from the command line, the current recommended method is to use one of the following:
Recommendations
For new-style InstallScript MSI installations, the UI functionality may be run without administrator privileges. Therefore,
the following points are recommended (and, in general, also apply to all Windows Installer–based installations):
• Do not assume that administrator privileges will be available from any InstallScript events.
• Any system changes that need to be made should be done with custom actions in the Installation Execute sequence.
InstallScript custom actions can be used. To ensure that sufficient privileges are available, custom actions should
have an in-script execution setting of deferred in system context.
• Custom actions that modify the system should have corresponding rollback actions that restore the system to its
earlier state if the installation fails.
• Custom actions that modify the system should also have corresponding actions that run during uninstallation to
remove the installed items from the system.
• If changes are made to the system from InstallScript events, the changes are not logged by the InstallScript engine and
would need additional script code to clean up these resources during uninstallation.
See Also
Event Handlers
Installation Sequence
User Interface Sequence
Execute Sequence
MsiDoAction (Windows Installer Help Library)
MsiDoAction (Windows Installer Help Library)
MsiGetTargetPath (Windows Installer Help Library)
MsiGetTargetPath (Windows Installer Help Library)
MsiSetTargetPath (Windows Installer Help Library)
MsiSetTargetPath (Windows Installer Help Library)
Specifying the InstallScript User Interface Type for InstallScript MSI Installations
InstallShield 2020
In InstallScript MSI projects, you have the choice of two different types of InstallScript user interface (UI). For detailed
information about these two styles, including any limitations, see Using the InstallScript Engine as an External vs.
Embedded UI Handler for InstallScript MSI Installations.
Task To specify the InstallScript user interface type for an InstallScript MSI project:
2. For the InstallScript User Interface Type setting, select the appropriate option.
• Traditional Style (Requires Setup.exe)—If you want to use the InstallScript engine as an external UI handler for
your InstallScript MSI installation, select this option. With this style, your installation must include a Setup.exe
setup launcher. The setup launcher serves as a bootstrap application that initiates the InstallScript engine to
display the UI and run the InstallScript code, and the Windows Installer to run the Execute sequence of the .msi
package.
• New Style (Requires Windows Installer 4.5)—If you want to use the InstallScript engine as an embedded UI
handler for your InstallScript MSI installation, select this option. With this style, InstallShield embeds the
InstallScript engine within the .msi package. The Windows Installer calls the InstallScript engine to display the UI.
The Windows Installer also runs the Execute sequence of the .msi package.
This option requires Windows Installer 4.5 on the target machine. This option also has some limitations that
require careful planning if you decide to use this style.
See Also
General Information View
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Some of the Summary Information Stream settings are available in DIM projects. In this project type, the values in these
settings are not displayed or used at run time. You can use these settings in this project type as a reference for internally
identifying the project.
Windows Installer databases (.msi and .msm files) are implemented as COM structured storage, and COM structured
storage files usually contain a Summary Information Stream. The Summary Information Stream contains information
about your company and the software being installed. For more information, see Accessing the Summary Information
Stream Panel to learn how to view your file’s summary information.
For a description of each Summary Information Stream setting, see General Information View.
See Also
Setting Summary Information Stream Properties
Using the Template Summary Property
Accessing the Summary Information Stream Panel
1. Right-click the .msi file or .msm file and click Properties. The Properties dialog box opens.
Tip • The General Information view is where you populate the information for the Properties dialog box for your installation.
See Also
Setting Summary Information Stream Properties
Entering Summary Information Stream Data
See Also
General Information View
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
You can use the Template Summary setting in the General Information view to essentially establish conditions for
processor type and language; if a target system does not meet these requirements, the installer displays an error message
and exits the installation.
Tip • You can also set the Template Summary setting for a product configuration in the Releases view. Any value entered in
the Releases view overrides the value set in the General Information view.
Syntax
List the processor type first, followed by your installation’s default language. For language, enter any four-digit language ID
or 0 (zero) for language neutral.
• If your installation supports multiple products and you want to have multiple entries in the language category—for
example, 1033 for English and 1031 for German—separate them with a comma.
Caution • If your installation targets 64-bit machines, do not enter both Intel and Intel64 in this field. Doing so causes your
installation to fail. Also, if you enter Intel64, your installation will not run on 32-bit operating systems.
• Intel
• Intel64
• x64
Intel;1033
If the processor-type condition fails, the installer displays an error message and then exits.
If your product runs on x64 processors and supports English and German, enter the following:
x64;1033,1031
To specify that the package is language-independent, you can use the syntax Intel; or Intel;0.
;1036
Leaving the first portion empty indicates that the target processor is Intel. If a language is not specified, InstallShield
provides the release languages in the Summary Information Stream.
See Also
Targeting 64-Bit Operating Systems
Selecting the Appropriate Type of Architecture Validation for Builds
General Information View
Setting Product Conditions
Template Summary Property (Windows Installer Help Library)
Template Summary Property (Windows Installer Help Library)
The settings in the Add or Remove Programs area of the General Information view describe the information that appears in
Add or Remove Programs tool in the Control Panel.
If you have not entered a value for a particular Add or Remove Programs setting, a sample value appears in grey text. This
value is meant to serve as an example and is not included in the final Windows Installer database.
The General Information view enables you to set much of the information that is displayed to the end user through Add or
Remove Programs.
Project • In Basic MSI and InstallScript MSI projects—Most of the values that you specify are stored in Windows Installer
properties with names beginning with ARP, such as ARPPRODUCTICON or ARPHELPLINK. One exception to this is the Publisher
setting. This value should be set with your company name and is stored in the Manufacturer property.
In a Basic MSI project—To prevent your product from appearing in the Add or Remove Programs, you can set the Windows
Installer property ARPSYSTEMCOMPONENT to 1 in the Property Manager. Note that setting this property simply suppresses the
display of your product in Add or Remove Programs. An end user can still remove your product by running the installation in
maintenance mode or from the command line.
In an InstallScript MSI project—To prevent your product from appearing in the Add or Remove Programs, select Yes for the
Hide Add/Remove Panel Entry setting in the Releases view.
See Also
Requirements for the Windows Logo Program
General Information View
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• MSI Database
• Suite/Advanced UI
• Transform
In the Read Me setting in the General Information view, enter the name of the Readme file for your product. On some
versions of Windows, this information is displayed on the Support Info dialog box for your product’s entry in Add or
Remove Programs. Alternatively, you can link to a Readme file located on the Internet by specifying a valid URL.
Project • In a Windows Installer–based project (Basic MSI or InstallScript MSI project), special formatting is required to
properly display a path when the Readme file is installed as part of your installation; see the following section. In an
InstallScript or InstallScript Object project, enter a hard-coded path or a URL, or specify a path relative to a system variable
enclosed by angle brackets, for example, <TARGETDIR>\Readme.txt. This data is written to the target system’s registry by the
default OnMoveData event handler.
Displaying the Readme File Path in Basic MSI and InstallScript MSI Projects
You can enter a hard-coded path or a URL for the Readme file. However, the name of a folder, such as [MyDirectory], or of
a component, such as [$MyComponent], is not resolved. That means that the Readme value in the Support Information
dialog box would be displayed as [INSTALLDIR]Readme.txt or [$MyComp]Readme.htm. The path is not resolved because
this property is merely setting the initial value of the Windows Installer property ARPREADME, and formatted strings are
never resolved for Windows Installer properties.
InstallShield’s solution is to use a custom action to set ARPREADME with the value that you enter in the Read Me setting. By
setting it with the SetARPReadme custom action, the path is resolved during the installation. For example, Readme.doc
might be a file in the component Help_Files. In this case, enter [$Help_Files]Readme.doc for the Read Me setting.
Assuming Help_Files is installed to C:\Program Files\MyCompany\MyProduct\Help, the path that would be displayed in
Add or Remove Programs on the target system would be C:\Program Files\MyCompany\MyProduct\Help\Readme.doc.
Instead of the component name, you can use the file key. Do not use a folder from the Directory table because it will not
be resolved at run time. The file key is not as reliable as the component name, because it is subject to change if the files are
dynamically linked or the release uses patch optimization. Continuing the example above, if Readme.doc has a file key of
F501_Readme.doc, enter [#F501_Readme.doc] for the Read Me setting. If it is installed to the same folder, Add or Remove
Programs displays the following path on the target system:
C:\Program Files\MyCompany\MyProduct\Help\Readme.doc
The custom action SetARPReadme is added every time that the Read Me setting in the General Information view contains a
string and the Installation Execute sequence contains the CostFinalize action. SetARPReadme is inserted into the
Installation Execute and User Interface sequences directly after CostFinalize.
See Also
General Information View
ISO/IEC 19770-2 is an international standard for the creation of software identification tags. A software identification tag is
a small 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 understand, manage, and optimize the number of
licenses of your product that they obtain from you.
Proper tag creation requires that you configure standard General Information settings such as Product Name and Product
Version. It also requires that you configure a few identification-specific settings, which are also in the General Information
view.
2. In the Software Identification Tag area of the view, modify the values of the settings as needed.
The Use Software Identification Tag setting lets you specify whether you want to include a tag in your installation.
Select Yes, which is the default value, and then configure the other settings in the Software Identification Tag area
as needed.
When you use tagging in your project, InstallShield adds the tag to two new components that it creates, and it associates
the components with one of your project’s features. The components are:
Use the Setup Design view if you want to associate these components with a different feature in your project. For more
information, see Component-Feature Associations.
At build time, if the following conditions are true, InstallShield includes the software identification tag with the installation
that it builds:
• Yes, the default value, is selected for the Use Software Identification Tag setting in the General Information view.
• The Unique ID, Tag Creator, and Tag Creator ID settings in the General Information view have values.
Note that if tagging is enabled but you have not entered values in one or more of the three aforementioned tag
identification settings, InstallShield generates a build warning to inform you that the tag could not be included in your
release. To resolve this warning, configure the settings in the Software Identification Tag area of the General Information
view as needed.
If you configure your project to include a software identification tag and you also configure the release in the Releases view
to use a .pfx file to digitally sign your release, InstallShield digitally signs the tag at build time. Note that the .NET
Framework 3.5 must be installed on your build machine in order to sign a tag file.
See Also
General Information View Settings
Microsoft System Center 2012 Configuration Manager is a solution that helps IT administrators manage and deploy
applications to users throughout an enterprise. It takes a user-centric approach to application delivery, allowing IT
administrators to define each application so that it can be deployed to users on a variety of devices in the most appropriate
format, with the required application dependencies.
Accurate identification of deployment metadata is necessary for migrating applications into the Configuration Manager
application model. InstallShield includes the ability to 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.
Task To include application model data for System Center Configuration Manager in your installation:
1. Ensure that you are including a software identification tag in your project. For more information, see Including a
Software Identification Tag for Your Product.
4. Configure the subsettings under the Add SCCM App Model Data setting as needed. For more information, see General
Information View Settings.
When you include tagging and application model data in your project, InstallShield adds the tag with the application
model data to two new components that it creates, and it associates the components with one of your project’s features.
The components are:
Use the Setup Design view if you want to associate these components with a different feature in your project. For more
information, see Component-Feature Associations.
At build time, if the following conditions are true, InstallShield includes the software identification tag with the installation
that it builds; it also includes the application model data in the tag:
• Yes, the default value, is selected for the Use Software Identification Tag setting in the General Information view.
• The Unique ID, Tag Creator, and Tag Creator ID settings in the General Information view have values.
• Yes is selected for the Add SCCM App Model Data setting in the General Information view.
If you configure your project to include a software identification tag and you also configure the release in the Releases view
to use a .pfx file to digitally sign your release, InstallShield digitally signs the tag at build time. Note that the .NET
Framework 2.0 or later must be installed on your build machine in order to sign a tag file.
See Also
General Information View
The primary task of an installation is to transfer files from your distribution media to your end user’s hard drive. In an
InstallShield installation, files are organized in a hierarchy: files are included in components; components are associated
with features (and optionally subfeatures); and, in InstallScript and InstallScript MSI installations, features are associated
with setup types.
At run time, your end user simply selects the setup type—or, if you allow it, the features and subfeatures—that he or she
wishes to install. End users do not see components, which you use to group your files according to their type and purpose.
For example, files that are installed to the same target folder can be placed in the same component, as can self-registering
files.
A file often relies on functions in other files to perform a task. However, you may not be aware of all these other files—
known as dependencies—when you include your application’s files in your project. To help you identify dependencies,
InstallShield offers three dependency scanners that automatically add these files to your project.
In addition to including individual files in your project, you can also include redistributables (InstallShield prerequisites,
merge modules, and objects), which contain logic and files needed to install distinct pieces of functionality. For example,
to include the Java Runtime Environment (JRE) files in your installation, you can add the InstallShield prerequisite for JRE
to your installation project.
See Also
Files and Folders View
Components View
Features View
Setup Types View
Dependency Scanners
Redistributables View
DIM References View
Designing Installations
InstallShield 2020
There are two main perspectives in an installation project—that of the developer and that of the end user. In InstallShield,
these perspectives are addressed in detail in the Components and Features views, respectively.
Components
Components represent the developer’s view of the product. They are installation authoring tools that help the developer
organize similar application data—such as files, registry entries, and shortcuts—into logical groups.
To enable the end user to choose which features to install, you should divide your application into components that
correspond with the features of your application.
Note • The conditions that you specify for the Publish Components, Publish Features, or Publish Product actions are not
validated during design time, so use proper syntax and check to ensure that the condition produces the expected outcome.
Features
Features are the building blocks of an application from the end user’s perspective. Each feature represents a specific piece
of functionality for your product—such as the help files. End users should be able to install and uninstall discrete features
of your product.
For example, an end user with limited hard drive space could elect not to install a product tutorial. If the user subsequently
purchases another computer or frees resources on an existing one, the previously uninstalled product tutorial could then
be installed.
You should separate your application into features that correspond to the components of your application.
See Also
Components View
Features View
• Windows Installer requires that every file in a component be installed to the same directory. If you need to install a
directory structure, each subdirectory must correspond to a separate component.
• To take full advantage of Windows Installer repair functionality, each .exe, .dll, and .ocx file should be placed in its own
component, and each should be the component’s key file. The Best Practices option of the Component Wizard can
create components for you using this rule.
• Similarly, each .chm or .hlp file should be placed in its own component, along with any corresponding .chi or .cnt file.
• No resource should be included in more than one component, even across products. If a component’s resources are
required by more than one product, consider creating a merge module with the shared resources.
• When mapping a component to one or more features, ensure that all parts of a component map to the features.
• When testing your installation, you may want to divide your application into several components to thoroughly
measure its performance.
See Also
Setting Component Key Files
• Separate your application into independent parts, such as help, clip art, and program files. This gives the end user
combination options when installing your application. For instance, if your application contains a large, graphic-
intensive clip art file, you could make the clip art file a feature. This gives the end user the option of installing or not
installing the file—a vital ability for users with limited available resources.
• In separating your application into features, ensure that end users can recombine the parts in several ways to fulfill
specific needs. When doing this, consider the needs of all users, from system administrator to customer service
representative to developer and everyone in between. By addressing all groups of users, you are promoting increased
distribution and usage of your application.
• Each feature should have one function—such as help files—and should be clearly defined according to this
functionality to facilitate recognition and comprehension. Features should possess an independent functionality,
such that users can install and use the feature by itself, if they so choose.
• If one feature requires another, make the dependent feature a child of the other.
• To eliminate confusion, keep any information pertaining to the management of the system or application transparent
to the user.
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
Traditionally, to link to source files in an installation project, you would need to create a reference to that file using a hard-
coded path. For example, you might have a source file called Program.exe located at C:\Work\Files that you want to
include in your installation. However, if you used hard-coded paths, you needed to enter the entire path every time that
you want to associate a source file from that directory. If you moved the file to another directory, you needed to change the
hard-coded path as it appears in your installation project. If your installation consisted of a small number of source files,
this might not have been a problem. Unfortunately, some installations contain thousands of files that all would need to be
remapped if you change the folder structure or migrate the project to a different machine.
With path variables, you can define commonly used paths in a central location so that you do not need to change every
source file’s path each time you move the project or change the directory structure.
All path variables can be viewed and modified in the Path Variables view. You can use path variables in almost any location
in InstallShield where you link to source files, such as in the Dialog Editor, dynamic file links, and the release location.
Instead of entering the path variables yourself, you can have InstallShield recommend them whenever you browse to a
path. To have InstallShield automatically recommend path variables, select the Always display the Path Variable
Recommendation dialog to me option on the Path Variables tab of the Options dialog box.
Note • Path variables are used during the development of your installation project. These paths do not apply to the target
machines where the application is being installed. Rather, they are used to link to source files for your installation project.
When the project is built, those links are evaluated and the files they point to will be built into the installation.
See Also
Path Variables View
Path Variables Tab (on the Options dialog box)
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
Predefined path variables define standard Windows directories; this type of variable cannot be renamed or modified. The
standard, registry, and environment types of path variables are custom variables that you can create and define as needed.
See Also
Path Variables View
Path Variables Tab (on the Options dialog box)
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
Predefined path variables are variables that are set to certain standard Windows directories. These variables cannot be
renamed or modified, but they can be used in your installation project to point to predefined directories. Following is a list
of predefined path variables, their typical values, and the corresponding InstallScript path variables. (In an InstallScript
project, InstallScript path variables are used in InstallShield, for example, as options in the list for the Destination property
of a component. InstallScript path variables also correspond to system variables that can be used in the installation script.)
InstallScript Path
Predefined Path Variable Value Variable
<ISRedistPlatformDependentExpressFolder> C:\Program
Files\InstallShield\2020\Redist\Language
Independent\i386 Express
<ISRedistPlatformDependentFolder> C:\Program
Files\InstallShield\2020\Redist\Language
Independent\i386
Project • Windows Installer based projects only: The Path Variable Recommendation dialog box enables you to specify
whether you want to use predefined path variables. This dialog box is launched if you enter a hard-coded path when inserting
a source file into your installation and you have selected the Always display the Path Variable Recommendation dialog to me
check box on the Path Variables tab of the Options dialog box. If you enter a path that is included in a predefined path variable,
InstallShield suggests that you use the path variable rather than the hard-coded path.
You can also use predefined path variables when defining the value for a standard path variable. You may want to define a
standard path variable to a subfolder of a predefined variable. For example, <ProgramFilesFolder>\InstallShield could
be used as the value for a standard path variable.
Predefined path variables are smart variables. This means they are set to the correct directory, even if your Windows
directory is located on your D drive instead of your C drive. If you change the default project location on the File Locations
tab of the Options dialog box, InstallShield updates this variable to reflect the new directory.
See Also
Path Variables View
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
Standard path variables are sometimes referred to as user-defined variables. These variable types are native to
InstallShield. That is, they do not rely upon outside resources, as do registry or environment variables.
To have InstallShield automatically recommend path variables, select the Always display the Path Variable
Recommendation dialog to me option on the Path Variables tab of the Options dialog box.
Tip • To override the value of a user-defined path variable, an environment variable, or a registry value for a particular
release at build time, use the Path Variable Overrides setting on the Build tab for that release. To learn more, see Overriding
the Value of a Custom Path Variable for a Release.
See Also
Path Variables View
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
Registry path variables enable you to define your own variables based on the default value of a specified registry key.
Once you have created a registry path variable, you can use it every time that you add a source file to your project. When
you add a file to a component from a folder that contains the value of MyRegVar, it is recommended that you use the
variable rather than hard-coding the path. This recommendation is displayed in the Path Variable Recommendation dialog
box.
To have InstallShield automatically recommend path variables, select the Always display the Path Variable
Recommendation dialog to me option on the Path Variables tab of the Options dialog box.
Tip • To override the value of a user-defined path variable, an environment variable, or a registry value for a particular
release at build time, use the Path Variable Overrides setting on the Build tab for that release. To learn more, see Overriding
the Value of a Custom Path Variable for a Release.
See Also
Path Variables View
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
Environment path variables enable you to define your own path variables based on certain values on the Environment
dialog box.
1. Right-click My Computer and click Properties. The System Properties dialog box opens.
A common scenario where environment path variables may be useful is when performing a build from the command line. If
you do nightly builds on a machine dedicated to that purpose, you may need to change the path variables from the
command line. As long as you use environment path variables, you can define the paths to your project’s files from either a
batch file or the command line. These paths are evaluated when the installation project is built, and the correct paths to
the files will be used.
To have InstallShield automatically recommend path variables, select the Always display the Path Variable
Recommendation dialog to me option on the Path Variables tab of the Options dialog box.
Tip • To override the value of a user-defined path variable, an environment variable, or a registry value for a particular
release at build time, use the Path Variable Overrides setting on the Build tab for that release. To learn more, see Overriding
the Value of a Custom Path Variable for a Release.
See Also
Path Variables View
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
The Path Variables view is where you create and define standard path variables, environment path variables, and registry
path variables.
• In QuickPatch projects: In the View List under Patch Settings, click Path Variables.
• In all other project types: In the View List under Media, click Path Variables.
• To create a standard path variable, click the New Path Variable button.
• To create an environment variable, click the arrow next to the New Path Variable button, and then click
Environment.
• To create a registry variable, click the arrow next to the New Path Variable button, and then click Registry.
Tip • To override the value of a user-defined path variable, an environment variable, or a registry value for a particular
release at build time, use the Path Variable Overrides setting on the Build tab for that release. To learn more, see Build Tab for
a Release.
See Also
Standard Path Variables
Registry Path Variables
Environment Path Variables
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
InstallShield lets you override the values of your project’s standard path variables, environment path variables, and
registry path variables for each release in your project. This functionality enables you to essentially replace certain files and
folders in your project with others at build time, depending on the particular release that you are building.
For example, in a Basic MSI project, you could use this functionality to swap out the custom action DLL files—a 32-bit
version for your project’s 32-bit release, and a 64-bit version for your project’s 64-bit release. Or perhaps for a Suite/
Advanced UI project, you might want to use this functionality to swap out UI elements such as images and EULAs for
different releases in your project; this would enable you to easily generate installations for different editions or branded
versions of your product.
2. In the Releases explorer, select the release that you want to configure.
3. On the Build tab, in the Path Variable Overrides setting, click the ellipsis setting (...). The Path Variable Overrides
dialog box opens.
The Path Variable Overrides dialog box shows check boxes for the path variables, environment path variables, and
registry path variables that are configured in the Path Variables view. Note that it does not include check boxes for any
predefined path variables, or for path variables that are already overridden for the same release in the Releases view.
4. Select the check box of each path variable that you would like to override for the selected release.
5. Click OK. InstallShield closes the dialog box. Under the Path Variable Overrides setting, InstallShield adds a new
subsetting for each path variable that you selected.
6. For each path variable subsetting, specify the appropriate new value.
At build time, InstallShield uses the new values that you specified in the Releases view to override the default values that
are set in the Path Variables view.
• If you are building from the command line with IsCmdBld.exe, use the -l parameter to specify a path variable and a
new value.
• If you are building through MSBuild or Team Foundation Server (TFS), use the PathVariables parameter on the
InstallShield task. This parameter is exposed as the ItemGroup InstallShieldPathVariableOverrides when the default
targets file is used.
Note those methods take precedence over any value that you set in the Path Variable Overrides setting in the Releases
view.
See Also
Overriding Path Variables in a DIM Project for Use in an Installation Project
Targeting 64-Bit Operating Systems
Path Variable Overrides Dialog Box
Path Variables View
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
You might not need to use path variables when you begin your installation project, but you may realize the benefits they
provide well after you have started. Rather than going through each file link and changing it to a path variable, you can use
the Converting Source Paths Wizard.
This wizard scans your project for static links and converts them all to path variables. If any of your static links can be
replaced with existing path variables, the wizard does this automatically. For all other links, the wizard provides a list of the
possible variables. After you choose the variables that you want to use, the wizard converts all of the links.
See Also
Convert Source Paths Wizard
• Advanced UI
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• QuickPatch
• Suite/Advanced UI
• In QuickPatch projects: In the View List under Patch Settings, click Path Variables.
• In all other project types: In the View List under Media, click Path Variables.
To select multiple consecutive path variables, select the first path variable, press and hold SHIFT, and select the last
path variable. To select multiple nonconsecutive path variables, select the first path variable, press and hold CTRL,
and select each additional path variable.
See Also
Path Variables View
Your files, the core of your product, are also the core of your installation. Files are added to a project only at the component
level. In installation projects, components are associated with features, which are what end users see when they run your
installation. If the component’s feature is selected for installation, the component’s files are installed to the target system.
When you are adding files to components in Windows Installer–based projects, you should be aware of Setup Best
Practices. By default, the Setup Best Practices Wizard monitors your setup design and alerts you if you have violated Best
Practices.
You can add files to your project in the Setup Design view (for installation projects) or the Components view, and in the
Files and Folders view.
See Also
Files and Folders View
Setting Component Key Files
Specifying Hard-Coded Destination Directories
Adding Files to Components
Tips for Managing Files and Folders in Your Project
You can use the Files and Folders view to add files to your project.
1. In the View list under Application Data, click Files and Folders.
2. In the View Filter list, select the feature that should contain the file that you want to add.
3. Windows Installer–based projects only: In the Destination computer’s folders pane, right-click Destination
Computer, point to Show Predefined Folder, and then click the predefined folder that you want to use.
4. In the Destination computer’s folders pane, click the folder into which you want to place the file.
5. In the Source computer’s folders pane, navigate to the folder containing the file you want to add.
INSTALLDIR (for Windows Installer–based projects) or Application Target Folder (for InstallScript projects) is the most
commonly used target location, because this is the default root directory for your application’s files.
6. Select and drag the file you want to add from the Source computer’s files pane to the Destination computer’s files
pane.
Tip • You can specify how INSTALLDIR is displayed in the Destination computer’s folders pane of the Files and Folders view by
setting your preference on the Directory tab of the Options dialog box.
The Destination computer’s folders pane contains a list of predefined destinations. You can add a file to either a predefined
destination or to a destination that you create.
If no features exist, you have the option of creating one when you first add files in this view.
In an InstallScript project, InstallShield creates components based on the file types—for example, all self-registering files
are contained in one component, all non-self-registering files in another component, and all .NET files in a different
component. The components appear as subfolders in the Files and Folders view.
Tip • To display components in the Files and Folders view, right-click a destination folder (in the lower-left pane of the view)
and click Show Components.
See Also
Files and Folders View
Adding Files to Components
Setting Component Key Files
Specifying Hard-Coded Destination Directories
Setup Best Practices
Tips for Managing Files and Folders in Your Project
The files explorer in the Files and Folders view enables you to drag and drop folders from your source computer to
destinations on the target system. You have a number of options when you drag files from the Source computer’s folders
pane to the Destination computer’s folders pane.
Tip • When you are using InstallShield on a 64-bit system and you want to add to your project a system file whose source
location is the 64-bit System folder (System32) on your development machine, it is not possible to drag the file from one of the
source computer panes at the top of the Files and Folders view to the appropriate location in one of the destination computer
panes. To learn more, see Adding Files from Your 64-Bit Source Machine’s 64-Bit System32 Folder.
1. In the View list under Application Data, click Files and Folders.
2. In the Source computer’s folders pane or the Source computer’s files pane, right-click a folder or file and drag it to
the Destination computer’s folders pane or the Destination computer’s files pane. Then release the mouse button.
If the predefined folder to which you adding the folder or file is not displayed in the Destination computer’s folders
pane, you can add it. To learn how, see Displaying Predefined Folders in the Files View.
Table 4-2 • Commands that Are Available on the Context Menu in the Files and Folders View
Command Description
Add Adds the folder, subfolders, and/or files selected. This is the same as the default
drag-and-drop behavior.
Add Preserving Source Structure Adds the selected folder, subfolders, and/or files while preserving the file/folder
structure found on the source computer.
Add Folder(s) Only Adds only the folders selected and any subfolders contained in the selected
folder. Does not add any files contained within the selected folders or subfolders.
Add Folder(s) Only Preserving Adds only the folders selected and any subfolders contained in the selected
Source Structure folder. Does not add any files contained within the selected folders or subfolders.
This option also preserves the folder structure found on the source computer.
This option is available only if the source folder matches a predefined Windows
destination folder. In addition, the destination on which you drop the file or folder
must be the Destination Computer.
Adding Files from Your 64-Bit Source Machine’s 64-Bit System32 Folder
InstallShield 2020
On 64-bit systems, the System32 folder is reserved for 64-bit applications. When you try to view your development
machine’s 64-bit System folder from within the Files and Folders view in InstallShield, Windows redirects the view to
instead display the SysWOW64 folder—the 32-bit version of the folder. Thus, when you are using InstallShield on a 64-bit
system and you want to add to your project a system file whose source location is the 64-bit System folder (System32) on
your development machine, it is not possible to drag the file from one of the source computer panes at the top of the Files
and Folders view to the appropriate location in one of the destination computer panes.
To work around the redirection and add a 64-bit System32 file on your development machine to your InstallShield project,
you can browse to the Sysnative folder on your machine and then select the appropriate file for your project. The following
instructions explain how.
Caution • Note that in many cases, including system files in an installation is not recommended, since the system folder is
protected by Windows. In these cases, the preferred way to deliver and update system files is to use a Microsoft redistributable,
if one is available for the technology, or to have end users obtain the updates through Windows Update.
Task To add to your project a file in the 64-bit System32 folder of a development system that has 64-bit Windows:
1. In the View list under Application Data, click Files and Folders.
2. In the Destination computer’s folders pane, click the folder into which you want to place the file.
3. Right-click in the Destination computer’s folders pane, and then click Add File. The Open dialog box opens.
4. Specify the following path (but replace the drive letter with the applicable drive letter if appropriate):
C:\Windows\Sysnative
5. Select the appropriate file that you want to add to your project, and then click the Open button.
InstallShield adds the file to your project. InstallShield uses the Sysnative folder as part of the path for the source file that
you added. WOW64 sees the Sysnative folder as a special alias; the file system does not redirect access away from this
folder.
Tip • Note that you can also add 64-bit System32 files through the Components view or the Setup Design view: in these views,
expand the node of the component that you want to contain the 64-bit System32 file. Select the Files node under that
component. Then, right-click the Files pane on the right, and then click Add File. Specify the C:\Windows\Sysnative path, as
described in the aforementioned procedure.
If you are using the automation interface with InstallShield or the Standalone Build to create, edit, or build an installation
on a 64-bit machine that has Sysnative support, you can use the Sysnative folder in paths when you are specifying the
source folder for system files that are in the 64-bit System folder.
See Also
Developing and Building Installations on 32-Bit vs. 64-Bit Systems
1. In the View list under Application Data, click Files and Folders.
2. In the Destination computer’s folders pane, right-click a folder and click New Folder.
3. Rename your new folder by selecting it, pressing F2, and typing the new name.
Alternately, you can drag an entire folder onto one of the destination folders, thereby adding a new subfolder to the target
folder that contains the source folders files. This new subfolder has the same name as the source folder.
In the Files and Folders view, you can specify hard-coded destination directories.
1. In the View list under Application Data, click Files and Folders.
2. In the Destination computer’s folders pane, right-click Destination Computer and click New Folder, or click
Destination Computer and press INSERT. InstallShield adds a new folder.
3. For the name of the folder, type the drive letter followed by a colon (for example, C:).
4. Press ENTER.
1. Right-click the drive folder (for example, C:) under which you want to add a folder or—to add a subfolder—right-click
the folder under which you want to add a subfolder. You can also click the folder and press INSERT.
2. For the name of the folder, type the folder name, and then press ENTER.
1. Right-click a folder and click New Folder, or click a folder and press INSERT.
2. For the name of the folder, type the destination path—for example, a\b\c. This creates a folder structure with a at the
top, b below a, and c below b.
See Also
Files and Folders View
Tips for Managing Files and Folders in Your Project
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield has built-in support that makes it easy to specify files and folders that you want to be removed from target
systems at run time. This file and folder removal capability is useful for scenarios such as removing application-created
files that your installation does not otherwise track.
You can schedule the removal of a file or folder for one of the following events:
Note that if the item to be removed is a folder, that folder is removed only if it is empty.
InstallShield offers different methods for configuring a file or folder removal in a project.
Using the Files and Folders View to Specify Files and Folders to Be Removed
Task To configure file and folder removals through the Files and Folders view:
1. In the View list under Application Data, click Files and Folders.
2. In the Destination computer’s folders pane, select the destination folder that contains the file or folder that you
want to be removed.
3. Right-click in the Destination computer’s files pane and click Add File Removal. The Properties dialog box opens.
4. Configure the settings as needed. For details, see File Removal Properties Dialog Box.
InstallShield adds a file or folder icon to the Destination computer’s files pane. The icon has a red X through it to indicate
that it is referencing an item to be removed.
Using the Setup Design View or Components View to Specify Files and Folders to Be
Removed
Task To configure file and folder removals through the Setup Design view or the Components view:
1. In the View list under Organization, click Setup Design (in installation projects) or Components.
2. In the Setup Design or Components tree, expand the node of the component that contains the file or folder that you
want to be removed, and then click the Files subnode.
3. Right-click in the Files pane and click Add File Removal. The Properties dialog box opens.
4. Configure the settings as needed. For details, see File Removal Properties Dialog Box.
InstallShield adds a file or folder icon to the Files pane. The icon has a red X through it to indicate that it is referencing an
item to be removed.
See Also
Files and Folders View
Setup Design View
Components View
Tips for Managing Files and Folders in Your Project
Through drag-and-drop operations, common keyboard shortcuts such as CTRL+C and CTRL+P, and context menus that are
available when you right-click items, you can easily move the files and folders to different destination folders and to
different features.
1. In the View list under Application Data, click Files and Folders.
• To change the settings for a file or folder, right-click the item and then click Properties. The Properties dialog
box opens, enabling you to edit the settings as needed.
• To move a file from one destination folder to another, drag it from one location in the Destination computer’s
files pane to the appropriate folder in the Destination computer’s folders pane.
• To move a folder from one destination folder to another, drag it from one location in the Destination computer’s
folders pane to the appropriate folder in the same pane.
• To copy a file or folder from one location to another, press and hold CTRL while dragging the item from one
location to another.
As an alternative, you can copy an item to your Clipboard and then paste it into the appropriate location. Right-
click the item and click Copy, or click it and press CTRL+C. Next, select another folder that you want to contain
the file. Then right-click its folder and click Paste, or click the folder and press CTRL+P.
• To delete a file or folder from your project, right-click it and then click Delete.
1. In the View list under Application Data, click Setup Design (in installation projects) or Components.
2. Expand the node of the component that contains the file whose feature association you want to manage, and then
click the Files subnode. InstallShield displays its files in the Files pane on the right.
• To copy a file from one feature to another, you can copy a file to your Clipboard and then paste it into the
appropriate feature. Right-click the file and click Copy, or click it and press CTRL+C. Next, select another feature
that you want to contain the file. Then right-click its Files pane, and click Paste, or click it and press CTRL+P.
• To remove a file from a feature, right-click the file and then click Remove.
If you have added numerous folders and files to your project, you may have trouble finding a particular folder or file. You
can perform a search for folders and files in the Files view; InstallShield locates any matches and highlights the first one.
You can keep searching until you find all matches for your search criteria.
1. In the View list under Application Data, click Files and Folders.
3. On the Edit menu, click Find. The Find dialog box opens.
4. In the Find What box, type the text to be found. You can use wildcard expressions, such as *.exe.
5. In the Look at area, specify whether you want to search for files, folders, or both.
7. Click Find Next. The first item (if any) that matches your search criteria is selected in either the Destination
computer’s folders pane or the Destination computer’s files pane.
8. To find the next item (if any) that matches your criteria, press the F3 key. Repeat this step as necessary.
Task To display the components in your installation and the files that are associated with them:
1. In the View list under Application Data, click Files and Folders.
2. In the Destination computer’s folders pane, right-click any folder and click Show Components (in Windows
Installer–based projects) or Show Components and Subfolders (in InstallScript-based projects).
Components in installation projects that are not associated with a feature are displayed with the orphaned component
icon ( ).
In the folders explorer of the Files and Folders view, you can right-click a component and click Properties to display the
Component Properties dialog box. Through this dialog box, you can modify the component’s properties, add dynamic file
links, and change that features contain the component.
Note • (Windows Installer–based projects only) You can launch the Component Wizard by right-clicking a folder icon and then
clicking Launch Component Wizard.
You can set a number of properties for each file that is to be installed on the target system.
1. In the View list under Application Data, click Files and Folders.
2. In the Destination computer’s folders pane, click the folder that contains the file whose properties you want to
configure.
3. In the Destination computer’s files pane, right-click the file and then click Properties. The Properties dialog box
opens.
To see a description of each property that you can set, see File Properties Dialog Box.
File Associations
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
File associations are registry settings that tell Windows what application to use to open files of a certain type. For example,
Windows typically launches Notepad.exe when a text (.txt) file is opened.
To view and modify registered file types on your system, open Windows Explorer, and on the Tools menu, click Folder
Options. Use the File Types tab of the Folder Options dialog box to see how the file associations are configured.
Similarly, you can identify the application that is associated with a given file by right-clicking the file in Windows Explorer
and then clicking Properties.
File associations are stored in both HKLM\SOFTWARE\Classes and HKCU\SOFTWARE\Classes; you can see a merged view of
the data under HKEY_CLASSES_ROOT.
See Also
Registering a File Extension
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If your application manipulates files with a unique file extension, you can register your file type. For example, if your
application manipulates files with the .xyz extension, registering the file type instructs the operating system to open the file
with your application when the user double-clicks its icon.
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
5. In the File Types explorer, right-click Extensions and click New Extension. InstallShield creates a new extension with
the default name New ExtensionN, where N is a unique number.
6. Type your extension without the dot (for example, enter ext instead of .ext).
See Also
File Type Settings
Registering a File Extension
Project • This information does not apply to InstallScript or InstallScript Object projects.
1. Open the Setup Design view (for installation projects only) or the Components view.
5. In the File Types explorer, right-click the extension and click Delete.
Project • This information does not apply to InstallScript or InstallScript Object projects.
The extension properties determine the registry entries for your file extension, as well as the ProgID associated with it.
Detailed help is available in the help pane in InstallShield when you click each property.
See Also
Registering a File Extension
InstallShield 2020
Project • This information does not apply to InstallScript or InstallScript Object projects.
1. Open the Setup Design view (for installation projects only) or the Components view.
5. In the File Types explorer, right-click the extension and click New Verb. InstallShield creates a new verb with the
default name New VerbN, where N is a unique number.
6. Type the name of your new verb. You can use any of the canonical verbs, such as open, print, find, and properties.
7. Select the new verb to edit its properties. Its property sheet opens to the right.
InstallShield 2020
Project • This information does not apply to InstallScript or InstallScript Object projects.
1. Open the Setup Design view (for installation projects only) or the Components view.
InstallShield 2020
Project • This information does not apply to InstallScript or InstallScript Object projects.
1. Open the Setup Design view (for installation projects only) or the Components view.
5. In the File Types explorer, right-click the extension and click New MIME Type. InstallShield creates a new MIME type
with the default name MIME TypeN, where N is a unique number.
Click the MIME type to view its Class ID property. Click the Class ID property to edit it in the lower pane. Press CTRL+V to
paste a class ID into the property field.
See Also
Registering a File Extension
InstallShield 2020
Project • This information does not apply to InstallScript or InstallScript Object projects.
1. Open the Setup Design view (for installation projects only) or the Components view.
Creating ProgIDs
InstallShield 2020
Project • This information does not apply to InstallScript or InstallScript Object projects.
The ProgIDs item in the File Types explorer contains all of the programmatic identifiers—ProgIDs, also known as
application identifiers or tag names when they support file types—that you want to associate with file extensions. A file
type’s ProgID is an arbitrary string, but it should be unique on the target system. One ProgID naming convention is to
append the word file to your extension without a dot—the .ext extension might use the ProgID extfile. Another convention
is to name a file-type ProgID after the application used to open the file type, as in SampleApp.Document.
For example, an .xyz file extension could point to a xyzfile ProgID, and all of the .xyz file-type information would be
registered under xyzfile.
1. Open the Setup Design view (for installation projects only) or the Components view.
5. In the File Types explorer, click the extension. The extension properties are displayed in the right pane.
6. In the ProgID property, type the name of your ProgID. InstallShield adds your ProgID under ProgIDs in the File Types
explorer.
7. In the File Types explorer, click the new ProgID and then set its properties.
See Also
Registering a File Extension
Removing ProgIDs
InstallShield 2020
Project • This information does not apply to InstallScript or InstallScript Object projects.
1. Open the Setup Design view (for installation projects only) or the Components view.
5. In the File Types explorer, click the extension. The extension properties are displayed in the right pane.
If you want to add the contents of an entire directory to your project, you can do so through the use of dynamic file linking.
When you select a source folder for dynamic linking, InstallShield adds the files within that folder to your release at build
time. InstallShield scans the source folder before every build and automatically incorporates any new or changed files into
your release. Dynamic file linking is useful when the list of files in a folder—and possibly the list of files in its subfolders—
might change between builds.
Important • Dynamic file linking should be used with caution. If you inadvertently delete a dynamically linked file from the
source folder that your dynamic link references, that file is not included in your release the next time you build it, and
InstallShield does not display any build warning or error. Your product may install without any issues, but it may not work as
expected, since the dynamically linked file that was inadvertently deleted is no longer being installed. Therefore, it is
recommended that you avoid using dynamic file links for critical executable files—such as .exe, .dll, or .ocx files—especially if
your product requires them in order to run successfully.
Whenever possible, it is better to use the best practice method, instead of the by-directory method, for creating components
for dynamically linked files. Note that with both methods, however, a minor upgrade, a small update, or a patch may not
install correctly if a file that was present in a target image is removed from the dynamic link for the upgrade or patch.
For example, if all of your image files are in one folder along with sound files and you want to dynamically link only the
image files, you could specify that you would like to include only .bmp and .ico files in the dynamically linked folder. To do
so, you would use an asterisk (*) in your include pattern, as in the following example:
*.bmp, *.ico
To include or exclude a specific file, you would enter the full file name in the include or exclude pattern box. For more
details, see Creating a Dynamic Link.
Distinguishing Dynamically Linked Files and Folders from Static Files and Folders in the
InstallShield Interface
When a dynamic file is displayed within the InstallShield interface, the lower-left corner of the file’s icon includes an image
that indicates that it is a dynamically linked file:
InstallShield includes that same dynamic file image on the icon of subfolders that are included in dynamic file links:
Furthermore, InstallShield adds an arrow to the folder image—in addition to the dynamic file image—on the component
icon of subfolders that are included in dynamic file links:
The icons that the InstallShield interface displays for static files and folders do not include this dynamic link image.
See Also
Limitations of Dynamic File Linking
Determining the Appropriate Component Creation Method for Dynamically Linked Files
Working with Releases
Setting Component Key Files
Using Path Variables
Important • Dynamic file linking should be used with caution. If you inadvertently delete a dynamically linked file from the
source folder that your dynamic link references, that file is not included in your release the next time you build it, and
InstallShield does not display any build warning or error. Your product may install without any issues, but it may not work as
expected, since the dynamically linked file that was inadvertently deleted is no longer being installed. Therefore, it is
recommended that you avoid using dynamic file links for critical executable files—such as .exe, .dll, or .ocx files—especially if
your product requires them in order to run successfully.
Whenever possible, it is better to use the best practice method, instead of the by-directory method, for creating components
for dynamically linked files. Note that with both methods, however, a minor upgrade, a small update, or a patch may not
install correctly if a file that was present in a target image is removed from the dynamic link for the upgrade or patch.
• You cannot set any properties such as Shared, Permanent, or Never Overwrite for a dynamically linked file.
• You cannot use the .NET installer class functionality for a dynamically linked file.
• You cannot specify that COM interop should be enabled for a dynamically linked file.
• For Basic MSI projects: You cannot launch a dynamically linked file from the SetupCompleteSuccess end-user dialog.
Any file that you add directly (not through dynamic linking) to your project has an internal name (FileKey). When you create
a custom action, a file extension, shortcut, or other type of item, it actually points to this internal name.
When you add files to your project through dynamic links, the files are not physically added to the project. This means that
these files do not have any FileKeys that can be associated with custom actions, file extensions, etc.
See Also
Working with Releases
Setting Component Key Files
Using Path Variables
Determining the Appropriate Component Creation Method for Dynamically Linked Files
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
InstallShield provides two methods for creating components for dynamically linked files: the best practice method and the
one-component-per-directory method.
• InstallShield creates a separate component for each portable executable (PE) file in the dynamically linked folder.
Each PE file is the key file of its component.
• InstallShield adds all non-PE files at the root level of the dynamic link to the component that contains the link.
• If the dynamic link includes a subfolder, InstallShield creates a new component for all of the non-PE files in that
subfolder. If the dynamic link includes more than one subfolder, InstallShield creates a separate component for all of
the non-PE files in each subfolder.
Tip • The File Extensions tab on the Options dialog box is where you specify which file types are PE files.
• InstallShield creates one component for all of the files that are in the root-level dynamically linked folder, regardless
of the file types.
• If the dynamic link includes one or more subfolders, InstallShield creates a separate component for all of the files in
each subfolder, regardless of the file types. The first dynamically linked file in a subfolder’s component is the key file of
that component.
This method of component creation is the traditional method that was available in InstallShield before the best practice
method was introduced.
Tip • When you are configuring an upgrade, use the patch optimization functionality in your build settings. Using patch
optimization helps you keep component names, component codes, File table keys, and Directory table keys synchronized
from the earlier release. For more information, see Upgrade Considerations.
Note that if you want to create a patch for an earlier version of your product, and the earlier installation includes dynamic
links that used the by-directory method, you must continue to use the by-directory method for the same dynamic links.
However, if you add new dynamic links in your upgrade project, you can use the best practice method for those new
dynamic links. That is, you can mix both types of dynamic linking in the same project and create a patch to deliver the
upgrade.
Important • Whenever possible, it is better to use the best practice method, instead of the by-directory method, for creating
components for dynamically linked files. Note that with both methods, however, a minor upgrade, a small update, or a patch
may not install correctly if a file that was present in a target image is removed from the dynamic link for the upgrade or patch.
Note • For information on the rules that Windows Installer uses when determining whether a file included in a package
should overwrite a file that already exists on the target system, see Overwriting Files and Components on the Target System.
See Also
Creating a Dynamic Link
Limitations of Dynamic File Linking
Setting Component Key Files
Project • The procedure for creating dynamic file links differs, depending on which project type you are using. Note that parts
of the procedure apply to the following Windows Installer–based projects:
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• InstallScript
• InstallScript Object
You can use the Files and Folders view to create a dynamic link.
1. In the View List under Application Data, click Files and Folders.
2. In the View Filter list, select the feature that should contain components with the dynamically linked files.
3. Ensure that components are displayed in the Destination computer’s folders pane.
If components are not displayed: In the Destination computer’s folders pane, right-click Destination Computer and
click Show Components (in Windows Installer–based projects) or Show Components and Subfolders (in
InstallScript-based projects).
4. For a Windows Installer–based project: right-click a component and click Dynamic File Linking. The Component
Properties dialog box opens, and the File Linking tab is displayed.
For an InstallScript-based project: right-click a component and click File Linking. The Link Type dialog box opens.
Tip • You can also use the Components view to add dynamic file links. For more information, see Adding Dynamic File Links to
Components.
See Also
Limitations of Dynamic File Linking
Files and Folders View
You can use the Components view to add dynamic file links to components in both Windows Installer–based and
InstallScript-based projects. The procedure for creating dynamic file links differs, depending on which project type you are
using.
2. In the Components explorer, expand the component for which you want to add dynamic file links, and then click the
Files item under that component.
3. Right-click the Files pane and click Dynamic File Linking. The Modify Dynamic File Links dialog box opens.
4. Click the New Link button. The Dynamic File Link Settings dialog box opens. This dialog box is where you set the
source folder for your link, indicate whether to include its subfolders and whether the files are self-registering, and
specify which file types to include and exclude.
5. Click OK. Any file conflicts are resolved with prompts to overwrite existing files with the new versions. Click Yes to
overwrite, No to retain the existing file version, or Cancel to exit the dialog box without saving any of your dynamic file
link settings. You will also be warned if the folder contains no files, or if it is already in use in another dynamic link.
InstallScript-Based Projects
The following procedure applies to InstallScript and InstallScript Object projects.
2. In the Components explorer, click the component that should contain the dynamic link.
3. Select the value of the Link Type property and click the ellipsis button (...). The Link Type dialog box opens.
4. Specify the folder that contains the files to include, and specify any other desired options.
5. Click OK.
Tip • You can also use the Files and Folders view to add dynamic file links. For more information, see Creating a Dynamic Link.
See Also
Limitations of Dynamic File Linking
Creating a Dynamic Link
Project • This information applies to dynamic links that use the one-component-per-directory method of component creation
(as described in Determining the Appropriate Component Creation Method for Dynamically Linked Files) in the following
Windows Installer–based projects:
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
This information does not apply to dynamic links that use the best practice method of component creation.
A dynamically linked file whose component uses the one-component-per-directory method of component creation cannot
be the key file of a component.
To set a key file for a component containing a dynamic link, add a static link to the desired file, and then set the static link
to be the key file of the component. In the dynamic link settings, enter the full name of the key file in the Exclude files with
the following extensions field.
For example, you might have a source directory containing several .txt files, and you want the file called Key.txt to be the
key file. First, add a static link to Key.txt to a component, and set Key.txt as the key file. Next, create a dynamic link with the
same source folder, setting the Include files with the following extensions setting to *.txt and the Exclude files with
the following extensions setting to Key.txt.
For a dynamic link that includes subdirectories, the build process sets the first file in a subdirectory’s component as the key
file of the dynamically generated component.
See Also
Dynamic File Linking
• Basic MSI
• InstallScript MSI
At run time, Windows Installer considers the following questions when determining whether files should be overwritten on
the target system:
The following sections explain how Windows Installer evaluates these questions.
If one or both of those conditions are false for a component that has a registry key path, Windows Installer does not install
the component at run time.
If a component has a key file instead of a key path, Windows Installer checks the target system for the presence of that file.
Windows Installer installs the component in all of the following scenarios:
• The file is present on the target system, and the key file of the component has a higher or equal version number
compared to the version number of the file on the target system.
• The file is present on the target system, and the key file of the component and the file on the target system are
unversioned.
If the key file of the component has a lower version number than the file on the target system, Windows Installer does not
install the component at run time. In addition, Windows Installer does not install the component at run time if the key file
of the component is unversioned but the file on the target system is versioned. Thus, Windows Installer does not install a
component if its key file could be downgraded at run time.
• Always Overwrite—If the Always Overwrite check box for the file is selected, the file on the target system is
overwritten, regardless of version number.
• Versioned Files—In all cases, the file with the highest version is maintained, even if the file already on the target
system has a higher version than the one being installed. Additionally, a file of any version is maintained over
unversioned files.
• File Language—All other things being equal, the file that is the same language as the installation is maintained over
different language versions of the file. The only exception to this rule applies to multiple language files. Files with
multiple languages are maintained over single language versions of a file.
• Date—If the modified date of a file already present on the target system is later than the creation date of that file, the
file is not overwritten. This rule protects user preference files from being overwritten during an upgrade or
reinstallation.
If a file is in the component that is being installed but it is not present on the target system, Windows Installer always
installs that file.
Note • The REINSTALLMODE property can be set to modify the default file-versioning rules. For more information, see
Understanding File Overwrite Rules.
See Also
Checking File Versions Before Installing
Setting Component Key Files
File Versioning Rules (Windows Installer Help Library)
File Versioning Rules (Windows Installer Help Library)
2. In the Destination computer’s folders pane, right-click Destination Computer, point to Show Predefined Folders,
and then click the type of predefined folder that you want to use.
See Also
Destination Folders
Companion Files
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The use of companion files enables you to bind the installation action of one file to another file. For example, if your
installation project has two files—FileA.exe and FileB.dat—companion files let you bind FileB.dat to FileA.exe so that if
FileA.exe needs to be installed or reinstalled, then FileB.dat is also installed or reinstalled. If FileA.exe needs to be
uninstalled, then FileB.dat is also uninstalled.
1. In the Files and Folders view, add the versioned file to your project.
3. In the Components explorer, expand the component that contains the file that you just added, and then click Files.
Note the value in the Key column for that file.
6. Right-click the second file and then click Properties. The Properties dialog box opens.
8. In the Version box, type the name of the value noted in the Key column from step 3.
Note • InstallShield generates a unique file key every time you add a file. Therefore, if you remove the file that you have
created a binding to, it is possible that the file key will not persist. You would need to update the version of the unversioned file.
See Also
Overwriting Files and Components on the Target System
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield lets you configure settings for securing files and folders for end users who run your product in a locked-down
environment. You can assign permissions for a file or folder to specific groups and users. For example, you may assign
Read, Write, and Delete permissions for a particular file to the Administrators group, but only Read permissions for all of
the users in a different group.
1. In the View List under Application Data, click Files and Folders.
2. For a file: In the Destination computer’s files pane, right-click the file and then click Properties. The Properties
dialog box opens.
For a folder: In the Destination computer’s folders pane, right-click the folder and then click Properties. The
Properties dialog box opens.
4. Add, modify, and remove permissions entries as needed. For more information, see Permissions Dialog Boxes for Files
and Directories.
Depending on what is selected for the Locked-Down Permissions setting in the General Information view of your project,
InstallShield adds permissions data to either the ISLockPermissions table or the LockPermissions table. To learn more,
see Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment.
Tip • You can also configure permissions for a component’s destination folder. To do so, first click a component in the
Components view. Next, click the value for the Destination Permissions setting, and then click the ellipsis button (...). The
Permissions dialog box opens. On this dialog box, you can configure permissions as needed.
See Also
Configuring Permissions for Registry Keys
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
When you drag and drop new files in the Files and Folders view or in the Files subview under a component, you can
statically extract COM data for self-registering files. This is an alternative to extracting COM registration data at build time.
This option is also available in the COM Registration node under Advanced Settings in the Components view.
Right-click the file (or in the COM Registration node, right-click COM Registration) and click Extract COM Data for Key
File.
Note • This option is enabled only if the file is an .exe file or a file that is self-registering, and if the file is the component’s key
file.
Tip • If you are using InstallShield on a 64-bit system, InstallShield can extract COM data from a 64-bit COM server. In order to
install the data to the correct locations, the component must be marked as 64 bit. To learn more about 64-bit support, see
Targeting 64-Bit Operating Systems.
The installer uses “traditional” self-registration to register your self-registering files when the files are marked as self-
registering and (in a Windows Installer–based project) they are in a component that has the COM Extract at Build property
set to No. The files are unregistered when they are uninstalled. The self-registration functions supported are
DllRegisterServer and DllUnregisterServer.
Before setting a file’s Registration property, make sure the file is self-registering. According to Setup Best Practices, there
should be only one .dll file, .ocx file, or .exe file per component.
Tip • The recommended method for installing self-registering files with Windows Installer is to write the registration
information to the .msi database tables (Class, ProgID, and others). Instead of marking a file as self-registering, you can use
the component’s advanced settings, extract the COM information at build time, or extract the COM information when you add
a file in the Files and Folders view in order to register the ProgIDs, type libraries, and so on. Using the advanced settings works
whether you are installing the file in the installation or advertising it for “just-in-time installation.” A further advantage is that
the file can be unregistered if the installation fails.
Even if you set the component’s COM Extract at Build property to No, any information that is contained in the COM
Registration advanced setting will nonetheless be registered during installation. You might want to check the COM
Registration advanced setting and the component’s registry data to verify that the entries are intentional and do not
conflict with those made by the self-registration functions.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield offers support for identifying the properties and dependencies of .NET assemblies. The functionality depends
on the project type that you are using.
When a .NET assembly is the key file of its component, you can use one of the following methods to identify its
dependencies:
• If you know which files and merge modules are required for the .NET assembly, you can manually add them to the
same feature that contains the .NET assembly component in your project. This method is recommended, since it gives
you the most control over what is included in your project.
• If you do not know which files and merge modules are required for the .NET assembly, use one of the following built-in
methods:
• To identify the .NET assembly’s dependencies on demand, use the Static Scanning Wizard to detect possible
dependencies. 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. Note that this method is available in Basic MSI and InstallScript MSI
projects, but not in DIM or Merge Module projects.
• To identify the .NET assembly’s dependencies each time that you build your project, select Dependencies and
Properties for the component’s .NET Scan at Build setting. If InstallShield detects any possible missing
dependencies at build time, InstallShield incorporates them into the release that it generates.
Configuring the properties of a .NET assembly makes it possible for Windows Installer to update and uninstall the assembly
when needed. When a .NET assembly is the key file of its component, you can use either of the following methods to
identify its properties:
• Manually enter the properties and their values: In the Components view, under the Advanced Settings area for the
component that contains the .NET assembly, select .NET assembly subnode under the Assembly node, and configure
the properties as needed. Note that the properties and values that you enter must match the information in the
assembly’s manifest file. If they do not match, the assembly might be left on the target system when the feature that
contains the .NET component is uninstalled.
• To identify the .NET assembly’s properties each time that you build your project, select the Properties Only option or
the Dependencies and Properties option for the component’s .NET Scan at Build setting. If InstallShield detects any
possible missing properties at build time, InstallShield incorporates them into the release that it generates.
InstallScript Projects
In InstallScript projects, when you add a .NET assembly to a component in your project, you can use the component’s .NET
Assembly setting to identify the assembly as a local .NET assembly. You can also use one of the following methods for
identifying the dependencies of the .NET assembly:
• If you know which files and merge modules are required for the .NET assembly, you can manually add them to the
same feature that contains the .NET assembly component in your project. This method is recommended, since it gives
you the most control over what is included in your project.
• If you do not know which files and merge modules are required for the .NET assembly, use one of the following built-in
methods:
• To identify the .NET assembly’s dependencies on demand, use the Static Scanning Wizard to detect possible
dependencies. 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.
• To identify the .NET assembly’s dependencies each time that you build your project, select Dependencies for the
component’s .NET Scan at Build setting. If InstallShield detects any possible missing dependencies at build time,
InstallShield incorporates them into the release that it generates.
If Not an Assembly is selected for the component’s .NET Assembly setting, InstallShield does not scan for dependencies of
the component’s assembly.
Note that when Local Assembly is selected for the component’s .NET Assembly setting, the installation performs COM
interop registration and configures .NET installer class information for the component at run time.
See Also
Scanning 64-Bit .NET Assemblies for Dependencies
Reviewing .NET Dependency Scanner Results
Filtering Files in Dependency Scanners
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
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:
• To identify a 64-bit .NET assembly’s dependencies on demand, use the Static Scanning Wizard to detect possible
dependencies. 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.
• To identify a 64-bit .NET assembly’s dependencies each time that you build your project, select one of the dependency
options for the component’s .NET Scan at Build setting. 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.
These methods also scan for 32-bit dependencies of the 32-bit .NET assemblies in your project.
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.
Platform-independent .NET InstallShield uses the following order InstallShield uses the following order
assembly in the GAC when scanning for dependencies: when scanning for dependencies:
64-bit .NET assembly in the GAC InstallShield does not detect any InstallShield uses the following order
dependencies. when scanning for dependencies:
1. 64-bit-specific .NET
dependencies
2. Platform-independent .NET
dependencies
32-bit .NET assembly in the GAC InstallShield uses the following order InstallShield uses the following order
when scanning for dependencies: when scanning for dependencies:
If a .NET assembly is not in the GAC, InstallShield checks the same folder that contains the assembly when scanning for
dependencies, and then it checks any subfolders.
See Also
Identifying Properties and Dependencies of .NET Assemblies
Reviewing .NET Dependency Scanner Results
Filtering Files in Dependency Scanners
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield offers different built-in methods for identifying dependencies of .NET assemblies. If you use these built-in
methods, the scanning may identify as a dependency a file or merge module that is not required by your product. If you are
using the Static Scanning Wizard and that occurs, you can specify in the wizard that you do not want to add that
dependency to your project. If you are using the .NET scan at build functionality to automatically include any possible .NET
dependencies in your project at build time, you can change the values of the component’s settings so that the .NET
assembly is not scanned for dependencies automatically:
• In Basic MSI, InstallScript MSI, and Merge Module projects, InstallShield scans each component’s .NET assembly for
dependencies automatically at build time by default. You can override this default behavior by changing the value of a
component’s .NET Scan at Build setting as needed.
• In InstallScript projects, InstallShield does not scan each component’s .NET assembly for dependencies at build time
by default. You can override this default behavior by changing the values of a component’s .NET Assembly setting and
its .NET Scan at Build setting as needed.
In addition, InstallShield enables you to specify on a machine-wide basis any files that you want to be included or excluded
automatically any time that you perform a dependency scan through InstallShield. For more information, see Filtering Files
in Dependency Scanners.
To obtain the best results when you are trying to identify dependencies, it is recommended that you thoroughly test your
product and its installation on a clean machine. If your product does not behave as expected, determine whether any
dependencies are missing from the machine, and if so, whether they should be included in the installation.
See Also
Identifying Properties and Dependencies of .NET Assemblies
Scanning 64-Bit .NET Assemblies for Dependencies
• InstallScript
• InstallScript Object
When you include a font file—.ttf, .ttc, or .fon file—in your installation project (using either the Components view or the
Files and Folders view), the file is automatically marked internally to be registered on the target machine if you have
enabled global font registration. At run time, the OnInstalledFontFile event handler function is called immediately after
each font file is installed; the default code for this event handler function calls the RegisterFontResource function to
register the font if it is internally marked for registration.
Font Titles
InstallShield determines the font title that the installation registers for the font in the following manner:
• For an .fon file, InstallShield—by default—reads the font title from the registry of the source system. If no title can be
found in the registry, InstallShield stores the file name as the font title. For an .fon file in a component whose Link Type
property is set to Static, InstallShield displays the font title in the Font title box on the file’s File Properties dialog box.
• For a TrueType file (.ttf or .ttc file), by default the installation reads the font title from the file at run time, and at design
time no text is displayed in the Font title box.
• For all three types of files, in a component whose Link Type property is set to Static, if you enter non-default text in the
Font title box, the installation registers that text as the font title.
• InstallScript
• InstallScript Object
Task To install a font file to the Windows Fonts folder, do either of the following:
• In the Files and Folders view, place the font file in the Destination computer’s folders pane’s Fonts Folder folder,
which is a subfolder of the Windows folder.
• In the Components view, place the font file in a component whose Destination property is set to <FOLDER_FONTS>.
• InstallScript
• InstallScript Object
• InstallScript
• InstallScript Object
You can enable or disable automatic registration of font files for individual files.
1. Open the Components view, Setup Design view, or Files and Folders view.
2. Right-click the font file and click Properties. The Properties dialog box opens.
3. To enable automatic registration of the font file, select the Register Font File check box.
To disable automatic registration, clear the Register Font File check box.
4. Click OK.
Using Components
InstallShield 2020
Components are elements of the application from the installation developer’s perspective. Components are not visible to
the end user. When the user selects a feature for installation, the installer determines which components are associated
with that feature and then those components are installed. Components of an application would contain the executable
binary files, data files, shortcuts, help system files, and registry entries.
You can create and modify components in the Setup Design view (for installation projects) or the Components view.
Component-Feature Relationships
Components are associated with features in the Setup Design view. For more information, see Associating New
Components with Features.
Files
Expand a component’s tree in the Setup Design view or the Components view and click Files to view a list of all files
associated with that component. To learn how to add files, see Adding Files to Components.
See Also
Setup Design View
Components View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield makes adhering to Setup Best Practices easier by alerting you to Best Practices violations while you are
creating components in the Setup Design view and in the Component Wizard. By following these guidelines, you can create
clean installations that distribute reusable components efficiently and avoid problems that result from file incompatibility.
When you are creating components in the Setup Design view, the Setup Best Practices Wizard monitors the files that you
add to the components, alerts you when you have done anything that conflicts with Best Practices, and then gives you the
opportunity to correct the action in the wizard. To turn off the wizard’s automatic scanning of your setup design, select
Options from the Tools menu.
InstallShield checks for compliance with the following Setup Best Practices:
Components should not contain Each component should contain only one portable executable file (an .exe, .dll, or
multiple .exe, .dll, .ocx, .chm, or .ocx file) or WinHelp file (.hlp file). Windows Installer components are designed
.hlp files such that all of the advanced settings and component settings, such as the GUID
code, refer ideally to a single portable executable file or help file. Place other .exe,
.dll, .ocx, and .hlp files into new components.
One reason for this rule is that, at run time, if the user chooses Repair for an
installed product, Windows Installer checks for the existence of each installed
component’s key file. If the key file is missing, Windows Installer reinstalls the
missing component. Therefore, if a file that is not the key file of a component is
missing, it may not be restored during repair mode.
Use merge modules Merge modules contain all of the files, registry entries, and logic necessary to
install a distinct piece of functionality. You should not distribute a file for which a
merge module is available. Using merge modules also helps you comply with two
related requirements—the Best Practice to avoid associating a file with more than
one component and the Windows logo guideline not to ship any core
components.
If the Best Practices monitoring option is enabled, the Setup Best Practices
Wizard alerts you whenever you try adding to a component any file that is part of
the merge modules that InstallShield provides.
You should also be aware of the following component creation Setup Best Practices, to which InstallShield does not
automatically alert you:
Table 4-5 • Setup Best Practices for which InstallShield Does Not Automatically Provide Alerts
Put a shortcut target in its own Any file that serves as the target for a shortcut requires its own component. That
component file must be the key file for the component.
Group other files into Organize all files that do not fall into any of the above categories in components
components according to the files’ requirements, such as a common destination folder or
version checking.
Table 4-5 • Setup Best Practices for which InstallShield Does Not Automatically Provide Alerts (cont.)
Do not self-register files Instead of calling self-registration functions to register and unregister COM server
information, you should register this information for the component during
installation (and the installer will unregister it during uninstallation).
See Also
Overwriting Files and Components on the Target System
Component Creation
InstallShield 2020
• Use the Setup Design view (in installation projects only) or the Components view to create a new component and
manually configure it. For more information, see Using the Setup Design or Components Views to Create a
Component.
• Use the Component Wizard to allow InstallShield to define components for you according to Setup Best Practices.
This wizard is available in the following project types: Basic MSI, DIM, InstallScript MSI, and Merge Module. For more
information, see Using the Best Practices Option with the Component Wizard.
• If you are creating a component for a COM server, or a font, it is recommended that you use the Component Wizard.
This wizard is available in the following project types: Basic MSI, DIM, InstallScript MSI, and Merge Module. For more
information, see Using the Component Type Option with the Component Wizard.
For installation projects, you can create a new component in the Components view and then associate it later with a
feature, or you can create a component under a specific feature in the Setup Design view, as described below. Note that the
Setup Design view is not available in DIM or Merge Module projects.
2. In the Setup Design explorer, right-click a feature or subfeature and click New Component, or press CRTL+INSERT.
InstallShield adds a new component with the default name New Component n (where n is a successive number).
3. Enter a new name, or right-click it later and click Rename to give it a new name.
2. Right-click the Components explorer and click New Component, or press INSERT. InstallShield adds a new
component with the default name New Component n (where n is a successive number).
3. Enter a new name, or right-click it later and click Rename to give it a new name.
4. For installation projects, associate the component with one or more features.
Note • In installation projects, components that are not associated with a feature are displayed with the orphaned
component icon ( ).
When you create a component, its property sheet is displayed to the right. You should immediately specify the
component’s properties, including the required Component Code (Windows Installer–based projects only) and Destination
properties.
After you have created a component and specified its properties, you can associate your application’s files, registry entries,
and shortcuts with it.
See Also
Component Settings
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The fastest way to create components is to launch the Component Wizard and have InstallShield organize your files into
components for you. Select the Create components for me using best practices option to have the wizard generate
components by applying Setup Best Practices to the files you specify.
• For installation projects only: Right-click a feature in the Setup Design view and select Component Wizard.
• For installation projects, DIM projects, and Merge Module projects: Right-click Components in the explorer of the
Components view and click Component Wizard.
See Also
Best Practice Rules for Creating Components
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
When you select the Best Practices option for creating a component through the Component Wizard, the wizard
automatically organizes your files into components based on Setup Best Practices. It creates components according to the
following rules:
• The wizard looks at every file that you add to see if it is already included in your project. If the file is a duplicate, the
wizard does not create a component for it.
• A new component must be created for each portable executable file (.exe, .dll, or .ocx file). The component bears the
name of the portable executable file. The wizard creates a GUID for the Component Code property and sets the
portable executable file as the component’s key file.
• The Component Wizard attempts to extract registration information for each portable executable file. If it succeeds,
the wizard creates a COM server component and writes the data to the component’s COM Server advanced setting.
• Every help (.hlp) file that you specify will reside in its own component along with its associated contents (.cnt) file. The
component is named after its help file. The wizard creates a GUID for the Component Code property and makes the
help file the component’s key file. The same rule applies to HTML Help (.chm) files and the .chi files that accompany
them.
• The Component Wizard puts all font (.ttf and .ttc) files into a single component called Font Files. The wizard creates a
GUID for the Component Code property and sets the first file in the list as the key file. Any .fon files that you specify will
automatically be included in the AllOtherFiles component that is created. Since .fon files do not have a title, they will
not be added to the Font table in the .msi package. To have these files added as fonts, you will need to use the Fonts
option in the Component Wizard.
• Any files that do not fall into the above categories are grouped into a single component named All Other Files. The
wizard creates a GUID for the Component Code property and sets the first file in the list as the key file.
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If you select the Create components for me using Best Practices option on the Welcome panel of the Component Wizard,
InstallShield automatically creates a separate component for each portable executable file that you specify. The wizard
also attempts to extract registration information for each portable executable file.
If it succeeds, all of the registration information that maps to the COM Registration advanced setting is written there. The
wizard creates any additional entries, such as the InProcServer32 ThreadingModel value, in the component’s registry data.
Note • If your COM server is an executable, you must put an OLESelfRegister attribute with the value of 1 into the Version
section of the component’s resource file.
See Also
Editing the Registry
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If you select the Create components for me using Best Practices option on the Welcome panel of the Component Wizard,
InstallShield automatically creates a separate component for all font (.ttf and .ttc) files that you specify. Any .fon files are
added to the AllOtherFiles component that is created due to the fact that these files do not have an embedded font title. To
have .fon files added to your setup as fonts, use the Fonts option in the Component Wizard.
The destination folder for the font component is set to the destination folder that you chose in the Component Wizard.
After the component is created, you can set its Destination Folder to the Windows Installer folder property FontsFolder
(that is, use [FontsFolder] as the destination), the usual default location for fonts. Place square brackets around
FontsFolder, as you would when specifying [INSTALLDIR].
Task If the font was not registered on your system, you must specify the font title by doing the following:
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
2. In the explorer, expand the component that contains the font file and click Files. The Files view opens.
3. Right-click the font file and click Properties. The Properties dialog box opens.
4. In the Font title box, type a font title in the format FontName (FontType)—for example, Roman (All res).
5. Click OK.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If you have files with special installation requirements, using the Let me select a type and define the component myself
option of the Component Wizard is the recommended method for organizing them into components.
• For installation projects only: In the Setup Design view, right-click a feature and click Component Wizard.
• For installation projects, DIM projects, and Merge Module projects: In the Components view, right-click the
Components explorer and click Component Wizard.
The Let me select a type and define the component myself option of the Component Wizard supports the following
component types:
• COM servers
• Font files
• Install services
• Control services
Note • If you want to create a component that installs, starts, stops, or deletes a service during installation or uninstallation,
you can use the Services view. You can also use this view to configure extended service customization options, which are not
configurable through the Component Wizard. For more information, see Installing, Controlling, and Configuring Windows
Services.
See Also
Component Wizard
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Although you can create a component in one of several ways, the recommended method for installing a COM server (.exe,
.dll, or .ocx) file in an installation is to create a COM server component in the Component Wizard.
The wizard panels displayed depend on the selections you made in previous panels. For example, the Classes panel is not
displayed if the wizard succeeds in extracting the registration information in the COM Server Executable panel.
Tip • InstallShield includes support for 64-bit COM extraction. For more information, see Targeting 64-Bit Operating Systems.
See Also
Registering COM Servers
Component Wizard
Installing Fonts
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Although you can create a component in one of several ways, the easiest way to install a font (a .ttf, .fon, or .ttc file) in an
installation is to create a Fonts component in the Component Wizard.
In the Component Wizard, the panels that are displayed depend on the selections made in previous panels. For example,
the Add New Fonts panel is not displayed unless you selected I also want to add fonts not installed on this system in the
Add Installed Fonts panel.
See Also
Component Wizard
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
Tip • You can also access the Export Components Wizard from the Project menu in InstallShield.
When you export a component into a project, a copy of this component is added to the specified .ism file, along with all of
the component’s data, such as its files, shortcuts, registry entries, and advanced settings. Any string entries, properties,
and path variables used in the dialog are also copied to your new project.
If the target .ism file already has a component of the same name with different properties, the Resolve Conflict dialog box
opens to offer you options for resolving the conflicts.
See Also
Reusing Project Elements
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
You can permanently delete components in both the Setup Design view and the Components view.
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
See Also
Associating New Components with Features
Component-Feature Associations
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• MSI Database
• Transform
A component can be associated with as many features or subfeatures as necessary. For example, a text editor product
might have two features—an editor and a spell checker. Both the editor and spell checker have dependencies that are in a
System .dll files component. When designing this installation, you should associate the System .dll files component with
both the editor and the spell checker features.
You can associate components with features in the Setup Design view. There are two ways to associate components with
features in the Setup Design view, depending on whether or not the component already exists. For more information, see
Associating New Components with Features and Associating Existing Components with Features.
Note • Components that are not associated with a feature are displayed with the orphaned component icon:
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• MSI Database
• Transform
2. Right-click the feature or subfeature and click New Component or Component Wizard. InstallShield creates a
component and associates it with the selected feature.
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• MSI Database
• Transform
3. Select the components you want to associate with this feature from the list of components, and click OK.
You can move or copy existing components from one feature to another using a drag-and-drop operation:
• To move an existing component, drag the component from one feature to another.
• To copy an existing component, press CTRL while you drag the component from one feature to another.
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• MSI Database
• Transform
2. Right-click the component that you want to dissociate from the feature, and click Remove from feature.
Even though the component is no longer associated with this feature, it is still present in your project.
See Also
Setup Design View
You can use the Components view to add files, registry data, and shortcuts to components.
All of the files in a component must share the same component settings.
• All files should be installed with the same conditions (including operating system and language).
Create new components organized around your files’ installation needs and component properties. You should also be
aware of Setup Best Practices when adding files to a component. Setup Best Practices helps you to write clean installations
and distribute reusable components effectively.
Task Use one of the following methods to associate files with this component:
• Drag and drop files from Windows Explorer onto the file list.
• Right-click in the file list and click Add. In the resulting dialog box, browse to select as many files as you want to add
from that folder. Click Open.
Task Use one of the following methods to associate files with this component:
• Drag and drop files from Windows Explorer onto the file list.
• Right-click in the file list and click Add. In the resulting dialog box, browse to select as many files as you want to add
from that folder. Click Open.
InstallShield creates links to your application’s files. These links are used to locate the files when you build a release of your
installation. If any of these links becomes invalid, File Not Found appears next to the file.
All of the above methods for adding files link the files statically, which means that the file links do not change if new files
are added to or removed from the source folder. For an alternative to static linking, see Adding Dynamic File Links to
Components.
See Also
Setup Best Practices
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
In the Components view, you can expand a component to display the Files node, which shows the files associated with that
component. In the Files explorer, the Link To column provides the directory or the path variable that you used when you
added the file. You can use the Direct Editor to change what appears in this column.
3. Locate the file and edit the value in the ISBuildSourcePath column.
See Also
Direct Editor
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
2. In the Components explorer, expand the component that contains the file that you want to delete, and then click
Files item under it. The files associated with that component are displayed in the right pane.
3. Right-click the file that you want to delete and click Delete.
You can use the Registry view to add registry keys and values to a component. This information is written to the target
system’s registry if the component is installed. To learn how to add registry keys and values, see the following:
Project • For installation projects, you can create shortcuts in the Shortcuts view.
Before you can create a shortcut, you must create a component that contains the file to which the shortcut is going to link.
2. In the Components explorer, expand the component that should be associated with the shortcut that you are
creating, and then click Shortcuts. The Shortcuts explorer opens in a new pane.
3. In the Shortcuts explorer, right-click a destination folder and click either New Folder or New Shortcut. You can
create a program folder if you want your shortcut to appear under your company name, for example.
If you created a folder for your shortcut, create the shortcut by right-clicking your new folder and clicking New
Shortcut.
See Also
Shortcuts View
Creating Shortcuts and Program Folders
In the Components or Setup Design view, right-click the component’s Static File Links subnode and then click New
Folder.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
One of your component’s files can serve as its key file. A key file is a file that the Windows Installer uses to detect the
component’s presence on the target machine and determine whether it needs to be updated. In order to create advanced
component settings or shortcuts, a key file must be specified.
Caution • If your project includes dynamically linked files, InstallShield may automatically set some of the dynamically linked
files as the key file of a component. For more information, see Determining the Appropriate Component Creation Method for
Dynamically Linked Files.
See Also
Setting Key Paths for Components
Overwriting Files and Components on the Target System
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
3. Right-click in the files list and click Set Key File. The file icon ( ) for that file is replaced with a key icon ( ).
A component can have either one key file or one key path. If you have already set a key file or a key path for a component, a
warning message box appears if you try to set another key file. Click Yes in the message box to replace the existing key file
or key path with the new key file.
Note • You cannot specify a key file in the Files and Folders view. Key files must be set in either the Setup Design or
Components view.
See Also
Setting Key Paths for Components
Overwriting Files and Components on the Target System
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If you no longer want a file to serve as the component’s key file, you can clear the key file from that component.
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
Component Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
When you create a component, its settings have default values, depending on whether you created the component using a
view, or using a wizard.
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
2. Click the component that you want to configure, and modify its settings as needed.
See Also
Components View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Note that DIM, Merge Module, and MSM Database projects do not include features. These types of projects are added to
features in Basic MSI projects. Thus, components in DIM, Merge Module, and MSM Database projects are associated with the
features in the installation projects that consume them.
Both components and features have a destination setting, but there are some differences in how they are used when an
end user runs your installation.
Note • If you want all the components in a feature to be installed to the feature’s destination, you must set all of the
components’ destinations to match the feature’s destination.
See Also
Setting a Destination Folder for the Component’s Files
Setting a Feature’s Destination
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
Each component can have a different destination location for its files. The default value for the Destination setting is as
follows:
• For Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, and MSM Database, and Transform projects—
INSTALLDIR, initialized to [ProgramFilesFolder]Company Name\Product Name in the product’s INSTALLDIR property
Windows Logo • According to Windows logo requirements, the default destination of your application’s files must be a
subfolder of the end user’s Program Files folder. If you use INSTALLDIR or ProgramFilesFolder as the parent folder for your
feature’s Destination setting, your files will be installed to the correct location.
1. In the View List under Organization, click Setup Design (installation projects only) or Components.
3. In the Destination setting, select one of the options from the list, or click the ellipsis button (...) to select or create a
directory.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Note • If the component’s destination is set to something other than INSTALLDIR, the components are installed to the
destination specified for each component and changing INSTALLDIR has no effect on the components’ destinations.
An installer folder property such as INSTALLDIR specifies a default value. An end user can change this value by setting a
property when launching Msiexec.exe at the command line or by selecting a new destination folder for a feature in the
CustomSetup dialog.
In general, it is preferable to install assemblies to the local application directory. This increases application isolation.
Note • To install an assembly to the Global Assembly Cache, the .NET Scan at Build setting for the assembly’s component
must be set to either Properties Only or Dependencies and Properties.
See Also
MsiExec.exe Command-Line Parameters
CustomSetup Dialog Options
Windows Installer Property Reference
Scanning for .NET Dependencies and Properties
InstallShield 2020
Specifying the target destination of a component’s files from the script lets you change that destination at run time based
on end-user input or other conditions.
Task To specify the target destination of a component’s files from the script:
1. In the View List under Application Data, click Files and Folders.
2. In the Destination computer’s folders pane, right-click Script-defined Folders and click New Folder. InstallShield
adds a subfolder with the default name <NEW VARIABLE N>, where N is a successive number. You can rename this
subfolder to any string that is enclosed in angle brackets; for example, <My Script-defined Folder>.
c. In the component’s property grid, click the value of the Destination property and in the list, select the name of
the subfolder that you created in step 1.
To create a new component and specify the target destination of its files:
a. In the Files and Folders view, drag the desired file or files from the Source computer’s folders pane and drop
them on the subfolder that you created in step 1. InstallShield creates a new component with the default name
FilesN.
b. In your script, call FeatureSetTarget to assign a target location to the subfolder that you created in step 1; for
example:
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Declaring a Directory Identifier in uppercase letters makes that value a public property that can be set from the user
interface. In order to allow the end user or administrator to change the destination via the user interface or from the
command line, the Directory Identifier for the component’s destination must be a public property.
Using mixed-case or lowercase letters for the Directory Identifier defines the directory entry as a private property. Private
properties cannot be changed from the user interface.
Specifying Whether a Component’s Files and Other Associated Data Are Uninstalled During
Uninstallation
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
You may need to ensure that a component’s files, registry entries, shortcuts, and other data are not uninstalled when end
users uninstall your product. Following are examples of scenarios where it may be appropriate to ensure that a
component’s data are not uninstalled:
• You want to prevent the uninstallation of files that may be used by other products.
• The component is being installed to [SystemFolder]. According to validation rules, if a component is installed to this
location, it should not be uninstalled during uninstallation.
The setting that controls whether the component’s data are uninstalled depends on which project type you are using.
Task To specify whether a component’s files, registry entries, and other data are uninstalled:
1. In the Setup Design view (installation projects only) or the Components view, select the component that you want to
configure. InstallShield displays its settings in the right pane.
2. In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and Transform projects—Configure
the Permanent setting as appropriate:
• If the component data should not be uninstalled when end users uninstall the product, select Yes.
• If the component data should not be uninstalled when end users uninstall the product, select No.
The Permanent and Uninstall settings apply to all types of data that are associated with a component. This includes files,
registry entries, shortcuts, XML file changes, and SQL scripts.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Conditional installation of your components can be useful if you are creating different versions of the same product—for
example, a trial version and a full version. You might not want to provide full functionality in the trial version, therefore you
would not install all of the components. Another use for conditional component installation is to save disk space. If the
target system does not have enough disk space for all of the components, you can set non-required components to install
conditionally.
Using the component’s Condition setting, you can enter a statement that the installation must evaluate before setting up
your component’s data on the target system. The component is not installed if its condition evaluates to false. However,
the component is installed or advertised if its condition evaluates to true, assuming that its feature is selected for
installation.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
3. Click the Condition setting and then click the ellipsis button (...). The Condition Builder dialog box opens.
• Use the Properties list, the Operators list, and the Add buttons to build your condition:
a. In the Properties list, select a property and then click the Add button. InstallShield adds the property to the
Condition column.
b. If your conditional statement should contain an operator, select an operator in the Operators list and then
click the Add button. InstallShield adds the operator to the conditional statement.
5. Click OK.
Important • InstallShield performs basic condition validation; however, you should still double-check that your condition
statements evaluate to the expected outcome. For more information and example conditions, see Building Conditional
Statements.
See Also
Condition Builder Dialog Box
Reevaluating Component Conditions During Reinstallation
Conditional Statement Syntax
Setting Feature Conditions
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Windows Installer evaluates a component’s condition again when a product is reinstalled if you select Yes for the
component’s Reevaluate Condition setting. If the condition evaluates to true upon reinstallation, the component is
reinstalled—or installed for the first time if the condition initially evaluated to false or if the component was never selected
for installation.
Transitive Components
Components that were installed but whose conditions evaluate to false upon reinstallation are removed. Because of this
special feature, which allows you, in effect, to swap components during reinstallation, components with Yes selected for
the Reevaluate Condition setting are considered transitive components.
Consider an application that requires a different .dll file depending on whether it is installed on Windows XP or Windows
Vista. You could create a component for each file and attach a condition to each component to check the version of the
operating system. The component for Windows Vista would have the following condition:
VersionNT=600
VersionNT<600
When the product is installed on a Windows XP system, the appropriate version of the .dll file is installed and the Windows
Vista version is not. What happens if the end user upgrades to Windows Vista? When the product is reinstalled, the Windows
XP–specific component is uninstalled, and the Windows Vista–specific component is installed (as long as these
components are both transitive).
See Also
Configuring Component Conditions
Using Transitive Components (Windows Installer Help Library)
Using Transitive Components (Windows Installer Help Library)
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
A file’s reference count (also referred to as refcount) is the number of products on a target system that use the file.
Reference counts help to ensure that if multiple products are sharing a file, the file remains on the target system until all of
the products that share it are removed.
Reference counts for shared files are stored in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
Both Windows Installer–based projects and InstallScript-based projects include support for managing the reference counts
for shared files. The functionality is slightly different, depending on the project type.
Windows Logo • Windows logo guidelines require that the reference count be incremented when installing shared files and
decremented when uninstalling. Core component files (which they recommend you not install) should not be reference
counted.
You can call the InstallScript function GetFileInfo with the FILE_SHARED_COUNT constant to determine an existing file’s
reference count.
Task To specify that a component’s key file (in a Windows Installer–based project) or that a component (in an InstallScript-
based project) is shared:
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
Tip • One example of when you should always mark a component as shared is if its files are to be installed to a shared
directory such as the System folder or the Common Files folder.
Note • Note that the installation increments any existing reference count for any file in a component regardless of whether
you mark the component as shared. However, if no reference count exists, the installation does not create one unless you
select Yes for this Shared setting.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
For InstallScript projects, this functionality is handled by the component’s Overwrite setting. When you click the ellipsis button
(...) in this setting, the Overwrite dialog box opens, enabling you to specify whether files of the component should overwrite
existing files on the target system.
The Never Overwrite setting for a component enables you to indicate whether you want your installation to overwrite a
file if it already exists on the target system:
• If you select Yes, the file—if it exists on the target system—is never overwritten, regardless of the file version. Selecting
Yes for this setting overrides file versioning rules.
• If you select No and the file version on the target system is newer than the version being installed, the file on the target
system is not overwritten. However, if the version being installed is newer, the file on the target system is overwritten.
Windows Installer checks for the existence of the component’s key file when determining if it should install the component.
For more information, see Overwriting Files and Components on the Target System.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The Source Location setting for a component identifies a subfolder where the component’s files will be stored in the source
disk images, if the component’s files are not compressed. The component’s files will be copied to this subfolder in your
release image.
The Source Location setting does not require a value, and in most cases, it can be left blank. If you enter a value, it must be
a valid Windows folder name.
One instance where the Source Location setting could be used is when you are creating an installation that contains more
than one language. In this scenario, you can have multiple files with the same name. You can create a component for each
language and configure the Source Location setting as needed for each one. When you use the Source Location setting, any
file with the same name can be copied onto the disk in two different locations, without the risk of being overwritten.
For example, create two components called German and English. For the first component’s Source Location setting, enter
GermanVersion. For the second component’s Source Location setting, enter EnglishVersion. Create two files called
Test.txt, giving them slightly different contents. Assign each file to a component.
When you build your installation with uncompressed files, two separate folders on the disk images will be created, one
called GermanVersion and one called EnglishVersion. Separate versions of Test.txt will be copied to each of these folders,
but neither copy will be overwritten.
Note • The Source Location setting is not the same as the destination location. While it is conceivable that you might want to
copy both versions of the file to the end user’s machine, it is more likely that you would want to filter the files by language.
See Also
Adding Files to Components
Working with Releases
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The Remote Installation setting for a component determines whether the component’s files are installed on the target
system or run from the source medium, such as a CD-ROM or network server. The default value for a new component is
Favor Local, which means that the component’s files are installed on the target system.
Task To change this value so the component’s files run only from the source medium:
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
3. In the Remote Installation setting, select Favor Source. Selecting Optional gives this component the Remote
Installation setting of its feature.
The component’s Remote Installation setting overrides the feature’s. For more information, see Component’s Remote
Installation Setting vs. Feature’s Remote Installation Setting.
Caution • If the component contains a Windows service, select the Favor Local option. Although an end user could change the
feature’s installation state through the CustomSetup dialog, the Windows Installer cannot install a service remotely.
See Also
Setting a Feature’s Remote Installation Setting
CustomSetup Dialog Options
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• Transform
The component’s Remote Installation setting always overrides the feature’s Remote Installation setting. For example, if a
component’s Remote Installation setting is set to Favor Local, its files are installed on the target system regardless of the
feature’s Remote Installation setting.
The files are run from the source medium when a component’s Remote Installation setting is set to Favor Source. If you
want a component’s feature to dictate whether the files run from the source medium, select Optional for the component’s
Remote Installation setting.
When a component is associated with more than one feature and Optional is selected for the component’s Remote
Installation setting, the files are installed locally if any of its features is set to Favor Local. If the component is set to Favor
Local or Favor Source, the files are installed accordingly.
See Also
Setting a Component’s Remote Installation Setting
Setting a Feature’s Remote Installation Setting
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
By selecting Yes for a component’s COM Extract at Build setting, you indicate that you want InstallShield to scan the
component’s key file for COM registration data whenever you build a release that contains that component. The extracted
information is placed into the release so that Windows Installer registers the COM server when it is installed or advertised.
All the necessary registry settings made by the component are extracted when you select Yes for this setting.
Unlike the Component Wizard, the build process does not write the extracted COM information to the project (.ism) file.
Instead, it is dynamic, in that it is updated each time that you rebuild. It also means that you can rebuild an existing release
through InstallShield or the command line even when you do not have write access to the project file.
Note • The PATH system variable on the build machine must be set to include the directories of all of the .dll files to which the
COM server links; otherwise, the file will fail to register and COM information will not be extracted.
The build feedback (displayed in the Output window and in the build log files) details the registration information that was
extracted.
Tip • If you are using InstallShield on a 64-bit system, InstallShield can extract COM data from a 64-bit COM server. In order to
install the data to the correct locations, the component must be marked as 64 bit. To learn more about 64-bit support, see
Targeting 64-Bit Operating Systems.
Resolving Conflicts
Despite selecting Yes for the COM Extract at Build setting, you can still specify COM information under the component’s
COM Registration advanced setting and in the component’s Registry explorer. The existing information will always be
registered when the component is installed.
If entries are detected under COM Registration, InstallShield asks you if you want to delete them if Yes is selected for the
COM Extract at Build setting. If any conflicts are found during the build, you receive a warning about the item in the
advanced setting that was overwritten with the dynamically acquired data.
Even with these safeguards, you might want to check the COM Registration advanced setting and the component’s registry
data to verify that the entries are intentional and do not conflict with the data extracted at build time.
See Also
Working with Releases
Building a Release from the Command Line
Registering COM Servers
Extracting COM Data When Files Are Added
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
InstallShield lets you indicate that a component should be scanned for .NET dependencies and properties at build time.
The functionality depends on the project type that you are using.
Note • The build-time scan does not scan the key file of a component if the key file is not a .NET assembly file.
Several options are available from the .NET Scan at Build setting for a component:
Table 4-6 • Options for the .NET Scan at Build Setting in Windows Installer–Based Projects
Option Description
None InstallShield does not scan the key file of this component for .NET dependencies
or properties.
Properties Only At build time, InstallShield scans the key file of this component for .NET
properties. InstallShield populates the MsiAssembly and MsiAssemblyName
tables with the assembly properties, as needed.
Dependencies and Properties At build time, InstallShield scans the key file of this component for .NET
dependencies and properties. InstallShield populates the MsiAssembly and
MsiAssemblyName tables with the assembly properties, as needed. In addition,
InstallShield adds the missing files, components, and merge modules that are
required by the .NET assembly to the release.
Note • To install an assembly to the Global Assembly Cache, the .NET Scan at Build setting must be set to either Properties
Only or Dependencies and Properties.
This setting affects how the Static Scanning Wizard scans the files in your project.
InstallScript-Based Projects
In InstallScript and InstallScript Object projects, you can use the .NET Scan at Build setting to indicate whether you want a
component’s files to be scanned for .NET dependencies at build time.
Several options are available from the .NET Scan at Build setting for a component:
Table 4-7 • Options for the .NET Scan at Build Setting in InstallScript-Based Projects
Option Description
None InstallShield does not scan the files of this component for .NET dependencies.
Dependencies InstallShield scans the files of this component for .NET dependencies.
InstallShield adds the missing dependencies to the release.
See Also
Identifying Properties and Dependencies of .NET Assemblies
MsiAssembly Table (Windows Installer Help Library)
MsiAssembly Table (Windows Installer Help Library)
MsiAssemblyName Table (Windows Installer Help Library)
MsiAssemblyName Table (Windows Installer Help Library)
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The .NET Application File setting is used when the component is scanned at build time (based on the .NET Scan at Build
setting) or by the Static Scanning Wizard. The scanner uses this setting—along with the component destination—to
determine the value of the File Application setting for the assembly.
The scanning algorithm works in the following way to configure the .NET assembly’s File Application setting:
1. The scanning algorithm checks the component’s Destination setting. If the value is [GlobalAssemblyCache], the .NET
assembly’s File Application setting is set to null.
2. If the component’s destination is something other than [GlobalAssemblyCache], the scanning algorithm checks the
component’s .NET Application File setting. If this value is not null, the value of this setting is used to set the assembly’s
File Application setting.
3. If the component’s destination is something other than [GlobalAssemblyCache] and the .NET Application File setting
is null, the component’s key file is used to set the assembly’s File Application setting.
See Also
Static Scanning
Static Scanning Wizard
Component Settings
This is an example of a .NET class that implements the installer class and demonstrates how to read properties that are
passed to the installer class from the installation.
using System;
using System.Configuration.Install;
using System.Windows.Forms;
using System.Collections;
namespace MyInstall
{
///
/// Summary description for Class1.
///
[System.ComponentModel.RunInstallerAttribute(true)]
public class MyInstallClass : Installer
{
public MyInstallClass()
{
}
public override void Install(IDictionary stateSaver)
{
base.Install(stateSaver);
foreach(string strKey in Context.Parameters.Keys)
{
MessageBox.Show(strKey + " is " + Context.Parameters[strKey]);
}
}
See Also
.NET Installer Class Arguments Dialog Box
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• Transform
Registry reflection keeps the 32-bit registry view and the 64-bit registry view in sync on the target machine.
Note • Only 64-bit systems with Windows Installer 4 and later support registry reflection. In addition, only Windows Vista and
later and Windows Server 2008 and later support it.
If an end user installs a 64-bit application that has a component with registry reflection enabled, Windows Installer makes
the associated registry changes in the 64-bit view of the registry, and the reflector copies the registry changes to the 32-bit
registry view. Similarly, if an end user then installs a 32-bit application that modifies the same registry key or value,
Windows Installer makes the associated registry changes in the 32-bit view of the registry, and the reflector copies the
registry changes to the 64-bit registry view.
If registry reflection is disabled, Windows Installer calls the RegDisableReflectionKey function on each key being accessed
by the component. This function disables registry reflection for the specified key. Disabling reflection for a key does not
affect reflection of any subkeys.
Task To enable or disable registry reflection for all new and existing registry keys that are affected by a component:
2. In the Components explorer, select the component for which you want to configure the registry reflection setting.
3. To enable registry reflection, set the Disable Registry Reflection setting to No. This is the default value.
To disable registry reflection, set the Disable Registry Reflection setting to Yes.
For more information about registry reflection, see Registry Reflection in the MSDN Library.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
InstallShield lets you specify whether you want to enable shared component patching for a component. By default, it is
disabled.
If this multiple-package sharing feature were enabled in at least one package that is installed on the target system,
Windows Installer 4.5 treats the component as shared among all of those packages. If a patch that shares this component is
uninstalled, Windows Installer can continue to share the highest version of the component’s files on the system.
The purpose of this multiple-package component sharing is to prevent files from being downgraded during the
uninstallation of a patch that contains a component that is shared with one or more other installed packages. The intent is
to keep the highest version of the component’s files present on the machine after uninstallation of that patch.
Note • If the DisableSharedComponent policy is set to 1 on a target system, Windows Installer ignores this setting for all
packages.
The following diagram illustrates an example of two products, ABC and XYZ, that share a component that contains a file
called file.dll. An end user installs product ABC first, and version 1.0.0.0 of file.dll in the shared component is installed. Next,
the end user installs product XYZ, which includes version 1.1.0.0 of file.dll. Since this version is higher than the file that was
installed for product ABC, Windows Installer overwrites the current version with version 1.1.0.0. Then, the end user installs
an uninstallable patch for product ABC. This patch contains version 1.2.0.0 of file.dll. Since this version is higher than the
one that is already present on the target system, Windows Installer overwrites the current version with version 1.2.0.0. If
the end user uninstalls the patch, either of the following results may occur:
• If the value of the Multiple Package Shared Component setting is Yes for either product ABC or product XYZ and if
Windows Installer 4.5 is present, uninstalling the patch from product ABC could restore version 1.1.0.0 to the target
system.
• If the value of this setting is No for product ABC and product XYZ, the file would be downgraded to version 1.0.0.0, even
though product XYZ used 1.1.0.0. As a result, if product XYZ requires version 1.1.0.0, product XYZ may no longer work
properly.
Figure 4-1: If the Multiple Package Shared Component setting for the shared component is set to Yes in either package
and if Windows Installer 4.5 is present, version 1.1.0.0 of the file may be restored. Otherwise, the file may be unintentionally
downgraded to version 1.0.0.0.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
3. Select the appropriate value for the Multiple Package Shared Component setting:
• To enable shared component patching, select Yes. InstallShield sets the msidbComponentAttributesShared
attribute of the selected component to indicate that it should be shared.
• To disable shared component patching, select No. InstallShield does not set the
msidbComponentAttributesShared attribute of the selected component. However, if this component is shared
with another package, the msidbComponentAttributesShared attribute may be set for this component in that
package. Therefore, Windows Installer 4.5 would consider the multiple-package component to be shared.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The Advanced Settings area under a component in the Components view (and in the Setup Design view) enables you to
fulfill installation requirements for special component types. For example, when you copy an .ocx file to the target system,
you must register its classes, ProgIDs, and type libraries so that the file’s methods can be properly accessed. Advanced
settings use Windows Installer’s built-in functionality for registering COM servers; setting up ODBC drivers, data sources,
and translators; installing, controlling, and configuring Windows services; and registering a file association.
By specifying the advanced settings, you can publish your component and register COM servers, file extension servers, and
MIME types. If the component is selected, an advanced setting is made on the target system when the component is
installed or advertised. That way, the file is ready to execute once it is installed. Publishing components—a type of
advertising—is accomplished through the Publishing advanced setting.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Important • The recommended method for installing a COM server is to have Windows Installer register its classes, ProgIDs,
and so on. Calling self-registration functions violates Setup Best Practices.
It is recommended that you avoid using the TypeLib table. For more information, see TypeLib Table in the Windows Installer
Help Library.
The easiest way to populate the COM Registration advanced setting is to have the Component Wizard extract the necessary
information or extract COM data for a key file. (You can also have it extracted dynamically at build time, in which case you
do not need to use this advanced setting.) It is recommended that you modify the COM Registration advanced setting or
create COM entries in the component’s Registry explorer only if you are familiar with the technical details behind your file’s
registration.
Task To install a COM server solely through editing the component’s advanced settings:
1. Ensure that a single COM server is added to the component. The file must be a single portable executable file (such as
an .exe, .dll, or .ocx file), according to Setup Best Practices.
4. Expand the component’s Advanced Settings item to view all of the advanced settings.
Right-click one of the items in the COM Registration explorer to modify or to create registration information for your COM
server. Right-click an item and click Rename to rename the new item.
Note • The PATH system variable on the build machine must be set to include the directories of all of the .dll files to which the
COM server links; otherwise, the file will fail to register and COM information will not be extracted.
Configure the settings for each registration item or subitem that you create. More help is available in the help pane in
InstallShield when you click each registration setting.
See Also
Setup Best Practices
Setting Component Key Files
Extracting COM Data When Files Are Added
Installing COM Servers
Extracting COM Registration Data at Build Time
Registering COM Servers
COM Registration Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select COM Registration. The COM
Registration explorer appears in a separate pane.
3. In the COM Registration explorer, right-click COM Classes and click New COM Class.
4. Type a new name for the COM class if needed. The name that you give the COM class will be registered as the default
value under HKEY_CLASSES_ROOT\CLSID\<GUID>. To give the class a new name, right-click it and click Rename.
6. Specify a context type for this class. The following list tells you which server context is appropriate for which type of
COM server:
If the server context is LocalServer or LocalServer32, click the context to configure the Default Inproc Handler and
Argument settings.
See Also
Configuring COM Registration Settings Manually
COM Registration Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select COM Registration. The COM
Registration explorer appears in a separate pane.
3. In the COM Registration explorer, right-click ProgIDs and click New ProgID.
4. Type a new name for the ProgID. Use the format Component.Class.N. To give the class a new name, right-click it and
click Rename.
Version-Independent ProgIDs
A version-independent progID is a string used to identify a class in the format Component.Class, which is constant for all
versions of a class.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select COM Registration. The COM
Registration explorer appears in a separate pane.
3. In the COM Registration explorer, right-click Version-Independent ProgIDs and click New ProgID.
4. Type a new name for the ProgID. Use the format Component.Class. To give the class a new name, right-click it and
click Rename.
See Also
Configuring COM Registration Settings Manually
COM Registration Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Important • It is recommended that you avoid using the TypeLib table. For more information, see TypeLib Table in the
Windows Installer Help Library.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select COM Registration. The COM
Registration explorer appears in a separate pane.
3. In the COM Registration explorer, right-click Type Libraries and click New Type Library.
4. Type a new name for the type library, or libID, referenced by this COM server. The name that you give the type library
item is registered as the default value under HKEY_CLASSES_ROOT\TYPELIB\<libID>\<version>. Use the format
Component.Class. To give the class a new name, right-click it and click Rename.
See Also
Configuring COM Registration Settings Manually
COM Registration Settings
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If your application manipulates files with a unique file extension, you can register your file type in the File Types area, which
is available as an advanced setting within the Components view and the Setup Design view (for installation projects only).
For example, if your application manipulates files with the .xyz extension, registering the file type instructs the operating
system to open the file with your application when the user double-clicks its icon.
This advanced setting registers the following information about a file type on the target system when the component is
installed or advertised:
File Extensions You can associate file extensions (such as .doc and .txt) with the component’s key
file.
ProgIDs By setting the ProgID property in the extension, you can name a ProgID—for
example, extfile—that will contain the file type registration.
Verbs You can register command verbs (such as Open and Print) that appear in the
context menu that Windows Explorer displays when an end user right-clicks a file
with the current extension.
MIME Type You can also register multipurpose Internet mail extension (MIME) types, also
known as media types or content types, for the component’s key file. You can also
associate a MIME type with a class ID.
Note • File associations are stored in both HKLM\SOFTWARE\Classes and HKCU\SOFTWARE\Classes; you can see a merged
view of the data under HKEY_CLASSES_ROOT. It is recommended that you use the File Types editor instead of writing directly
to the registry to support Windows Installer feature advertisement.
Note also that Windows Installer writes file-extension advertisement information to the registry, which appears to be a string
of random characters. This behavior is normal.
See Also
File Associations
File Type Settings
Adding New File Extensions
Creating ProgIDs
Installing Assemblies
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Note • The recommended way to add a .NET assembly to your project is to add an assembly as a component’s key file and
select Properties Only for the component’s .NET Scan at Build setting.
In the Assembly section of a component’s Advanced Settings, you can add a private or global Win32 assembly or .NET
assembly to be registered when the current component is installed. Using assemblies helps you install products that are
self-contained, without affecting other applications on the system.
See Also
Adding Assemblies
Testing for .NET Assembly Support on the Target System
Assembly Settings
Scanning for .NET Dependencies and Properties
Static Scanning Wizard
Adding Assemblies
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
When you add a .NET assembly as the key file of a component, InstallShield automatically adds values to the .NET
assembly settings when the component is scanned at build time, or when you run the Static Scanning Wizard.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
4. Right-click Assembly and then click New Win32 Assembly or New .NET Assembly.
5. Click the assembly and then configure the Manifest, File Application, and related settings.
InstallShield adds the information that you enter for the assembly to the MsiAssembly and MsiAssemblyName tables of
your Windows Installer database. You can view and edit these tables using the Direct Editor.
See Also
Assembly Settings
Scanning for .NET Dependencies and Properties
Static Scanning
Static Scanning Wizard
Deleting Assemblies
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
To see if a target system supports .NET assemblies, you can test the MsiNetAssemblySupport property. To see if a target
system supports Win32 assemblies, you can test the MsiWin32AssemblySupport property. (Win32 assemblies are
supported only on Windows XP and later.) The assembly tables, actions, and properties require Windows Installer version
2.0 or later.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The App Paths registry key is a useful installation-related key that helps an executable file find its .dll files without having to
modify the PATH environment variable. An executable file’s App Paths key looks like this:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Filename.exe
A program’s App Paths key typically contains a value named Path, which should contain a semicolon-delimited list of
directories where the program’s .dll files could be located. Windows uses this key to find your application and its .dll files if
their locations are not already in the system’s path. If an end user moves or renames your application’s executable file
through the Explorer shell, Windows automatically updates the file’s App Paths key.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. Select the component that you want to configure, and expand its Advanced Settings item.
4. Select the check box of the file for which you would like to create a key.
5. In the Application Path column, enter the paths to the file’s dependencies, or select a Windows Installer folder
property from the list rather than hard-coding a path. Separate multiple paths with a semicolon (;).
6. Click OK.
See Also
Application Path Settings
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
For information on installing device drivers in InstallScript projects, see Installing Device Drivers.
Once you run the Device Driver Wizard, which adds the table and entries, custom actions, features, and components
needed to include device drivers in your installation, you can set properties associated with a component that includes a
device driver. The following information describes the various options that you can set within InstallShield.
The Device Driver advanced setting’s Common tab within the Components view enables you to specify whether the current
component includes a device driver and, if so, select desired run-time installation options. The Sequence tab enables you
to specify the order in which the project’s device drivers (not just the current component’s device drivers) should be
installed.
See Also
Device Driver Settings
Publishing Components
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The Publishing advanced setting for a component enables you to specify publishing information for your component.
Publishing is a type of advertising (just-in-time installation) in which no user-interface elements are created for the
component during installation, but the component can be installed through Add or Remove Programs or when an installed
component requests the published component from the installer.
You must create at least one component ID for each advertised component.
Important • Do not confuse the component ID with the GUID that is entered in the Component Code setting for the
component; they must be unique values. The component ID that you use for the Publishing advanced setting is a category
identifier that represents the category of components that are being grouped together as a qualified component.
Each component ID must have at least one qualifier. The qualifier is a string that you can use to distinguish this language or
version of the component from any other (for example, to specify a language). It must be unique for the component.
At run time, the installation registers the component IDs and qualifiers and uses these unique values to manage the
published components. By calling the Windows Installer functions, your installed component—or another installed
component (known as cross-product advertisement)—can request information about an advertised component and install
it.
See Also
Specifying Publishing Information
Publishing Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The Publishing advanced setting for a component enables you to specify publishing information for your component.
Publishing is a type of advertising (just-in-time installation) in which no user-interface elements are created for the
component during installation, but the component can be installed through Add or Remove Programs or when an installed
component requests the published component from the installer.
1. In the View List under Organization, click Setup Design (in installation projects only) or Components.
2. In the explorer, expand the component that you want to publish, and under Advanced Settings, select Publishing.
The Publishing explorer appears in a separate pane.
3. Right-click the Publishing explorer and then click New ComponentID to generate an ID for your new component.
InstallShield adds a unique componentID and a corresponding qualifier.
4. In the Publishing explorer, click the new qualifier and configure its value.
In the Custom Actions and Sequences view of an installation project, you can set the conditions that need to be fulfilled in
order for your product to be advertised on the target system.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, expand the Advertisement item, and then the Execute item.
3. Click the appropriate Execute action, and then configure its Conditions setting as needed.
See Also
Publishing Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
You must add at least one componentID to the Publishing advanced setting of a component if you want the component to
be published.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component that should have the new componentID, and under Advanced Settings, select
Publishing. The Publishing explorer appears in a separate pane.
3. Right-click the Publishing explorer and then click New ComponentID. InstallShield adds a unique componentID and
a corresponding qualifier.
See Also
Specifying Publishing Information
Publishing Settings
Removing ComponentIDs
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select Publishing. The Publishing explorer
appears in a separate pane.
See Also
Specifying Publishing Information
Publishing Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Each componentID must have at least one qualifier. When you create a componentID, by default it has a qualifier. To
rename this qualifier, right-click it and click Rename.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select Publishing. The Publishing explorer
appears in a separate pane.
3. In the Publishing explorer, right-click the componentID and click New Qualifier. InstallShield creates a new qualifier
with a default name.
See Also
Specifying Publishing Information
Publishing Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select Publishing. The Publishing explorer
appears in a separate pane.
See Also
Specifying Publishing Information
Publishing Settings
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
You have the option of specifying an informational string, called application data, for each qualifier.
1. In the View List under Organization, click Setup Design (for installation projects only) or Components.
2. In the explorer, expand the component, and under Advanced Settings, select Publishing. The Publishing explorer
appears in a separate pane.
When you type a value for this setting, you are creating a string entry and setting its initial value for all of the languages
that are currently in the project. As an alternative to typing a new value, you can click the ellipsis button (...) in this
setting to select an existing string. For more information, see Using String Entries in InstallShield.
See Also
Specifying Publishing Information
Publishing Settings
Defining Features
InstallShield 2020
A feature is the smallest installable part of a product, from the end user’s perspective. It represents a specific capability of
your product—such as its help files or a part of a product suite that can be installed or uninstalled based on the end user’s
selections. Your entire installation should be divided into features, each of which performs a specific purpose.
Subfeatures are further divisions of a feature. Because features should be self-contained elements of a product or product
suite that an end user can selectively install, it might make sense for you to organize portions of your installation as
subfeatures of a parent feature.
Tip • Although you can create many levels of subfeatures, you should keep the design as simple as possible for organizational
purposes.
See Also
Features View
Creating Features
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• MSI Database
• Transform
You can use the Setup Design view or the Features view to create features, as well as subfeatures, for your project.
2. Right-click the top-level item in the explorer and click New Feature. InstallShield adds a new feature with the default
name New Feature_n (where n is a successive number).
3. Enter a new name, or right-click it later and click Rename to give it a new name.
Project • In Basic MSI, InstallScript MSI, MSI Database, and Transform projects, feature names must contain only letters,
digits, underscores (_), and periods (.), and they must begin with a letter or an underscore.
In InstallScript and InstallScript Object projects, the following characters are invalid in feature names:
\/:*?"’<>|
Tip • To add a subfeature, right-click the parent feature and click New Feature.
You can create multiple nested features at one time by adding a new feature and typing Feature 1\Feature 2\Feature 3 for
the feature’s name. InstallShield creates a nested feature structure where Feature 3 is a subfeature of Feature 2, which is a
subfeature of Feature 1.
After you have created all of your product’s features and subfeatures, you need to create components and then associate
them with your features.
See Also
Features View
Setup Design View
Associating New Components with Features
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• MSI Database
• Transform
See Also
Features View
Setup Design View
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Each feature and subfeature can have a different destination location for its files. The default value for a new feature’s
Destination setting is INSTALLDIR, which is set in the General Information view.
Windows Logo • According to the Windows logo program requirements, the default destination of your product’s files must
be a subfolder of the Program Files folder or the end user’s Application Data folder, regardless of the language of the target
system.
3. In the Destination setting, select one of the options from the list, or click the ellipsis button (...) to select or create a
directory.
If you want the destination to be configurable at run time, the destination folder that you select must be a public
property (containing all uppercase letters).
For more information about changing a directory’s target location, see Changing the Target Location for a Directory in the
Windows Installer Help Library.
Note • If the component’s destination is set to something other than INSTALLDIR, the component is installed to the
destination that is specified for the component; changing INSTALLDIR has no effect on the component’s destination.
A directory property such as INSTALLDIR specifies a default value. An end user can change this value by setting a property
when launching Msiexec.exe at the command line or by selecting a new destination folder for a feature in the CustomSetup
dialog.
See Also
Setting the Default Product Destination Folder (INSTALLDIR)
Windows Installer Property Reference
Component Destination vs. Feature Destination
MsiExec.exe Command-Line Parameters
CustomSetup Dialog Options
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Conditional installation of your features can be useful if you are creating different versions of the same product—for
example, a trial version and a full version. You might not want to provide full functionality in the trial version; therefore, you
would not install all of the features. Another use for conditional feature installation is to save disk space. If the target
system does not have enough disk space for all of the features, you can set non-required features to install conditionally.
3. Click the Condition setting and then click the ellipsis button (...). The Feature Condition Builder dialog box opens.
4. Click the New Condition button. InstallShield adds a new condition row to the Conditions box.
5. In the Level column, type the install level that should be used for the feature if the condition is met.
Note that if the condition is met, this value overrides the value that is specified for the feature’s the Install Level
setting.
• Use the Properties list, the Operators list, and the Add buttons to build your condition:
a. In the Properties list, select a property and then click the Add button. InstallShield adds the property to the
Condition column.
b. If your conditional statement should contain an operator, select an operator in the Operators list and then
click the Add button. InstallShield adds the operator to the conditional statement.
c. If your conditional statement should contain a value, double-click the condition field, press END so that the
insertion point is at the end of the condition statement, and enter the value.
7. Click OK.
Important • InstallShield performs basic condition validation; however, you should still double-check that your condition
statements evaluate to the expected outcome. For more information and example conditions, see Building Conditional
Statements.
Each feature’s install level value is compared to the value of the global public property INSTALLLEVEL; only those features
with install level values less than or equal to INSTALLLEVEL are selected for installation.
For example, if you have a feature that you want to be selected by default only if the end user has elevated privileges, you
can give the feature a condition of Not Privileged and set the install level for that condition to 200. If the end user does
not have elevated privileges, the condition is true, and the feature will be given the install level 200. Because 200 is greater
than the default product install level (100), the feature will not be selected by default.
Tip • You can conditionally hide a feature by giving the feature a condition that sets the install level to the number 0. If the
condition is true, the feature will be deselected, and it will not be displayed in the CustomSetup dialog.
See Also
Feature Condition Builder Dialog Box
Conditional Statement Syntax
Configuring a Feature’s Install Level Setting
Configuring Component Conditions
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
InstallShield enables you to indicate how you want a feature to be presented to the end user in the custom setup type
dialog that corresponds with your project type:
The Display setting for a feature in the Features view or the Setup Design view is where you indicate whether and how the
feature should be displayed. Available options are:
Table 4-9 • Options that Are Available for the Display Setting
Option Description
Visible and Collapsed The feature is displayed in the run-time dialog with its subfeatures collapsed by
default.
Visible and Expanded The feature is displayed in the run-time dialog with its subfeatures expanded by
default.
Not Visible The feature and subfeatures are not displayed in the run-time dialog.
Note • Selecting Not Visible for this setting does not have any direct impact on whether a feature is installed. A feature is not
automatically installed if it is invisible—it just cannot be deselected if it would otherwise be installed, or selected if it should
not be installed.
See Also
Conditionally Selecting Features
Conditionally Hiding Features
Requiring Features to Be Installed
Features View
CustomSetup Dialog Options
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The procedure for conditionally selecting features at run time depends on the project type that you are using.
Task For example, to deselect a feature if the end user does not have administrator privileges:
3. Click the Condition setting and then click the ellipsis button (...). The Feature Condition Builder dialog box opens.
4. Click the New Condition button. InstallShield adds a new condition row to the Conditions box.
7. Click OK.
At run time, if the end user does not have administrator privileges (that is, if the condition succeeds), the Install Level
property for the feature is set to 200. Because the default INSTALLLEVEL property for a project is 100, the feature is
deselected.
Task You can change the INSTALLLEVEL property in the Property Manager.
See Also
Property Manager View
FeatureSelectItem
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
The procedure for conditionally hiding features at run time depends on the project type that you are using.
Task For example, to hide a feature if the end user running your installation does not have administrative privileges:
3. Click the Condition setting and then click the ellipsis button (...). The Feature Condition Builder dialog box opens.
4. Click the New Condition button. InstallShield adds a new condition row to the Conditions box.
7. Click OK.
After rebuilding your project and running the installation, the feature will not be displayed or installed if the end user does
not have administrative privileges.
FeatureSetData (MEDIA,
"HiddenFeature",
FEATURE_FIELD_VISIBLE, FALSE,
"");
Note • Hiding a feature does not automatically deselect it. To deselect the feature so that its data is not installed, call the
following:
See Also
FeatureSetData
FeatureSelectItem
• Advanced UI
• Suite/Advanced UI
You can conditionally show or hide a feature of a suite project based upon a property at run time using the Condition
option under the Visible property on the Features view of the Installation Designer.
You can use the Condition setting to specify one or more conditions that the Advanced UI or Suite/Advanced UI installation
should use to evaluate whether the feature should be visible for installation by default on the InstallationFeatures wizard
page.
For example, if you want a particular feature to be visible by default on target systems that have a particular version of
Windows, you can create a condition that specifies that version of Windows.
1. On the Features view, click in the Condition row under the Visible property. A green plus sign, the New Condition
button, appears at the end of the row.
2. Click the New Condition button. A new row is added under the Condition row.
3. Click the down arrow next to the New Condition button and select the appropriate option—All, Any, or None—from
the list.
4. Then in the same row, click the New Condition button, and select the appropriate option to continue building the
conditional statement.
If one or more conditional statements are configured, the Condition property lists (Condition). If none are
configured, the Condition property lists (Empty).
For more information, see Building Conditional Statements in Advanced UI and Suite/Advanced UI Projects.
Table 4-10 • Automation Interface Methods to Support Conditional Visibility in Suite Projects
Method Syntax
DeleteVisibleCondition DeleteVisibleCondition()
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
When you select Yes for a feature’s Required setting, the end user cannot deselect it in the CustomSetup dialog (for Basic
MSI, MSI Database, and Transform projects), or the SdFeatureDialog2, SdFeatureMult, or SdFeatureTree dialogs (for
InstallScript MSI projects). The feature will be installed to the target system.
If the value for the Required setting is No, the feature is installed by default, but the end user can deselect it.
In InstallScript MSI projects, the Required setting is applicable to root-level features during a first-time installation. It is also
applicable to subfeatures in an upgrade or patch. This setting is ignored for subfeatures during a first-time InstallScript MSI
installation.
See Also
CustomSetup Dialog Options
Using the Required Features Setting
Features View
Advertising Features
InstallShield 2020
• Basic MSI
• MSI Database
• Transform
InstallShield enables you to selectively enable or disable a feature for advertisement. Advertised features are not installed
immediately during the installation process. Instead, they are installed when requested. If the feature is assigned, the
feature appears to be already installed, although it is not installed until the end user requests it. (Assigned features have
their shortcuts installed, and they can be installed from Add or Remove Programs in the Control Panel. However, an
assigned feature is advertised until a user requests it.) A published feature does not appear on the target system until it is
requested from the installer. (Published features lack any end user–interface elements. They are installed
programmatically or through an associated MIME type.)
Use the Advertised setting in the Features view to specify whether advertisement should be allowed. Available options for
this setting are:
Table 4-11 • Options that Are Available for the Advertisement Setting
Option Description
Allow Advertise End users have the ability to select the advertisement option for this feature in the
CustomSetup dialog. Although advertisement is allowed, it is not the default
option when the installation is run.
Favor Advertise The feature is advertised by default. End users can change the advertisement
option for a feature in the CustomSetup dialog.
Disallow Advertise Advertising is not allowed for this feature. End users cannot elect to have the
feature advertised in the CustomSetup dialog.
Disable Advertise if Not Advertisement works only on systems with Internet Explorer 4.01 or later. If the
Supported target system does not meet this criterion, advertising is not allowed. If the target
system can support advertisement, advertising is allowed.
When you allow feature advertisement, the feature is advertised, regardless of the mode in which the installation is
running, as long as no other factors prevent it from being advertised. In the CustomSetup dialog, the end user can control
which features are immediately installed and which are available later.
Advertisement usually requires support from the application. For example, your product’s spell checker can be advertised.
The application interface offers use of the spell checker through a menu command or toolbar button. You must write to
check the feature’s installation state and install it when the customer clicks the Spell Check command or button.
See Also
Features View
CustomSetup Dialog Options
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
For InstallScript MSI projects, this information applies only if no setup types are defined in the project.
The Install Level setting for a feature is compared against the INSTALLLEVEL property at run time to determine which
features are available for installation. You can use this setting to create specific feature configurations.
Unless the end user deselects features in the CustomSetup dialog, all features with an install level less than or equal to the
value of the package’s INSTALLLEVEL property are installed to the target system.
Note • You can change the package’s INSTALLLEVEL property in the Property Manager.
3. For the Install Level setting, type an integer for this feature’s install level. The recommended value is 100.
See Also
CustomSetup Dialog Options
Feature Settings
Windows Installer Property Reference
Property Manager View
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The Remote Installation setting for a feature determines whether the feature’s files are installed on the target system or
run from the source medium, such as a CD-ROM or network server. The default value for a new feature is Favor Local, which
means that the files in the selected feature are installed on the target system.
Task To change the Remote Installation setting so that the feature’s files run only from the source medium:
Tip • Selecting Favor Parent gives a subfeature the same value as its parent feature.
Caution • If any of the feature’s components contain a Windows service, select Favor Local for the Remote Installation
setting. Although an end user could change the installation state through the CustomSetup dialog, the Windows Installer
cannot install a service remotely.
See Also
Component’s Remote Installation Setting vs. Feature’s Remote Installation Setting
Setting a Component’s Remote Installation Setting
Installing, Controlling, and Configuring Windows Services
CustomSetup Dialog Options
Project • The following project types include support for release flags:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
Release flags enable you to create different versions of your product without having to create more than one project. There
are two steps for filtering features according to release flags: assigning release flags and specifying which flags to include in
the release.
See Also
Assigning Release Flags to Features
Removing Release Flags
Release Flags
Project • The following project types include support for release flags:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
Release flags must be set on features that you want to exclude from certain builds. For example, if you have a feature called
Add-ons that should be included only in a special edition of your product, you can flag that feature and include it only when
needed.
3. For the Release Flags setting, type a string. The string can be any combination of letters or numbers. To have more
than one flag on a feature, use a comma to separate the flags.
To learn how to filter features based on release flags, see Release Flags.
Project • The following project types include support for release flags:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
Reordering Features
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• MSI Database
• Transform
When your end users install your product, the CustomSetup dialog (in Basic MSI, MSI Database, or Transform installations)
or one of the feature selection dialogs (in InstallScript or InstallScript MSI installations) displays the features in the same
order that they are displayed in the Features view in InstallShield. You can change the order in which the features are
displayed.
2. Right-click the feature that you want to move and click Move Up or Move Down. You can also move a feature left or
right, thereby making it a subfeature of another feature or a top-level feature.
Tip • You can also reorder your features by dragging and dropping. Any feature or subfeature can be moved in this way.
See Also
CustomSetup Dialog Options
• InstallScript
• InstallScript MSI
• InstallScript Object
The Required Features setting enables to you specify features that are required by the selected feature. For example, you
might have an installation with two features—ProgramFiles and HelpFiles. If it is necessary that end users install
ProgramFiles whenever the HelpFiles feature is selected, you need to use the Required Features property.
3. Click the Required Features property and then click the ellipsis button (...). The Required Features dialog box opens.
5. Click OK.
At run time, if the user selects a Custom setup type, feature-selection dialogs such as SdFeatureTree will not allow the user
to deselect the ProgramFiles feature if the HelpFiles feature is selected.
• InstallScript
• InstallScript MSI
To create setup types for a Basic MSI project, use the feature’s Install Level setting.
Setup types enable you to provide different versions of your product to your end users. For example, the default setup
types are Complete and Custom. The Complete setup type installs all of the files included in your installation. The Custom
setup type lets the end user select which features are installed.
Setup types are based on features. You select the features that you would like to associate with each setup type. Then,
when an end user selects a certain setup type, only those features that you associated with that setup type are installed.
By default, each project that you create contains predefined setup types. In the Setup Types view, you can add or remove
setup types, rename existing setup types, and change which features are associated with each one.
See Also
Setup Types View
• InstallScript
• InstallScript MSI
To create setup types for a Basic MSI project, use the feature’s Install Level setting.
2. Right-click the Setup Types explorer and click Add. InstallShield adds a new setup type.
See Also
Setup Types View
• InstallScript
• InstallScript MSI
To create setup types for a Basic MSI project, use the feature’s Install Level setting.
2. In the Setup Types explorer, click the setup type that you want to edit. All of the features in your installation project
appear in the lower-left pane.
3. Clear the check boxes next to the features that should not be included in the selected setup type. Select the check
boxes next to those features that you want included.
Any setup types listed in the Setup Types pane are automatically added to your installation project.
Note • The SetupType2 function displays only the standard setup types—Complete and Custom—with fixed description text
for both. If you want greater flexibility, call SdSetupTypeEx in your script instead of SetupType2. (The default code for the
OnFirstUIBefore event handler includes a call to the SetupType2 function.)
Tip • To provide an accelerator key for your setup type, include an ampersand (&) before a letter in the name. For example,
the name Cu&stom becomes the label Custom, and the end user can select it during installation by pressing the S key.
See Also
Setup Types View
• InstallScript
• InstallScript MSI
To create setup types for a Basic MSI project, use the feature’s Install Level setting.
2. In the Setup Types explorer, right-click the setup type that you want to edit and then click Rename.
This updates the Display Name setting for the selected setup type. The name is displayed in the SetupTypes dialog at run
time.
See Also
Setup Types View
• InstallScript
• InstallScript MSI
To create setup types for a Basic MSI project, use the feature’s Install Level setting.
2. In the Setup Types explorer, right-click the setup type that you want to delete and then click Remove.
See Also
Setup Types View
InstallShield includes many commonly used third-party redistributables, making it easy to add support for popular
technologies such as the .NET Framework to your installation. When you add redistributables to your project, the
redistributables, plus all of the associated dependencies, are added to your installation. This simplifies the process of
packaging redistributables and helps to facilitate consistency for internal or external use.
The Redistributables view (or in InstallScript and InstallScript Object projects, the Objects view) contains all of the
InstallShield objects and third-party merge modules that are included with InstallShield. In Basic MSI and InstallScript MSI
projects, this view also contains InstallShield prerequisites that you can add to your installation. In InstallScript projects,
you can use the Prerequisites view to add InstallShield prerequisites to your installation.
InstallShield Prerequisites
An InstallShield prerequisite is an installation for a product or technology framework that is required by your product. You
can add any of the existing InstallShield prerequisites to your installation projects and configure many of their settings. You
can also create your own InstallShield prerequisites, and add them to your projects.
InstallShield includes a base set of InstallShield prerequisites. You can also use the InstallShield Prerequisite Editor in
InstallShield to define custom InstallShield prerequisites or to edit settings for any existing InstallShield prerequisites.
• Setup prerequisite—The installation for this type of prerequisite runs before your installation runs.
• Feature prerequisite—This type of prerequisite is associated with one or more features. It is installed if the feature
that contains the prerequisite is installed and if the prerequisite is not already installed on the system. Thus, if a
feature has a condition that is not met on the target system, or if the end user chooses not to install the feature, the
feature is not installed. As a result, none of its associated feature prerequisites are installed, unless the feature
prerequisites are also associated with other features that are installed.
InstallShield also includes support for including InstallShield prerequisites as packages in Advanced UI and Suite/Advanced UI
projects. For more information, see Including InstallShield Prerequisites (.prq) in an Advanced UI or Suite/Advanced UI Project.
Merge Modules
A merge module (or .msm file) contains all of the logic and files needed to install distinct pieces of functionality. For
example, some applications require Microsoft C++ run-time libraries. Instead of having to include the file in a feature and
figure out its installation requirements, you can simply attach the Microsoft C++ runtime library merge module to one of
your project’s features.
Note • Many of the merge modules included in the Redistributables view are authored by Microsoft or another third party.
InstallShield distributes these modules as a courtesy to assist you in creating your installation project. However, InstallShield
cannot modify or fix any problems that may exist within third party-authored modules. You are encouraged to contact the
vendor regarding issues with specific third party-authored modules.
Objects
Like merge modules, objects contain logic and files needed to install distinct pieces of functionality. Some objects, such as
the DirectX object included with InstallShield, require customization through a wizard. As soon as you add such an object
to your installation, its customization wizard opens. You can either customize your object at the time you add it, or cancel
the wizard and customize your object later by right-clicking the object and selecting Change Objects Settings.
Redistributables Gallery
Because the file size of many of the redistributables is so large, some that are available for use in your projects are not
added to your computer when you install InstallShield. However, these redistributables are still available for download
from the Internet to your computer.
See Also
Redistributables View
Prerequisites View
ModuleConfiguration Table (Windows Installer Help Library)
ModuleConfiguration Table (Windows Installer Help Library)
ModuleSubstitution Table (Windows Installer Help Library)
ModuleSubstitution Table (Windows Installer Help Library)
Designing InstallShield Prerequisites and Other Redistributables
InstallShield provides third-party redistributables that you can incorporate into your installation projects. If you include
redistributable technology in your projects—for example, Crystal Reports—that redistributable must be licensed from the
vendor. You cannot legally redistribute these technologies without the appropriate licensing. For details, consult the
vendor’s documentation.
When you build releases in an InstallShield project, InstallShield includes various InstallShield redistributable files in the
build output. You may use these InstallShield redistributable files in the build output according to the InstallShield End-
User License Agreement. Most of these files are installed in the InstallShield Program Files Folder\Redist folder and
included in builds as needed. Following is a list of the InstallShield redistributable files.
• _isres_LanguageID.dll
• AppxStub.exe
• ClrSuitePSHelper.dll
• ClrWrap.dll
• CommonHelper.dll
• corecomp.ini
• default.pal
• DLLWrap.dll
• dotnetfx.exe
• DotNetInstaller.exe
• EulaScrollWatcher.dll
• FileBrowse.dll
• IISHelper.dll
• IISRT.dll
• InstallShield.ClrHelper.dll
• InstallShield.Interop.Msi.dll
• ISBEW64.exe
• ISChain.exe
• ISChainPackages.dll
• ISComSrv.dll
• ISExpHlp.dll
• isexternalui.dll
• IsLockPermissions.dll
• ISNetAPI.dll
• ISNetApiRT.dll
• ISNetworkShares.dll
• ISRegSvr.dll
• Isrt.dll
• ISScheduledTasks.dll
• IsSchRpl.dll
• ISSetup.dll
• ISSQLSrv.dll
• IsWebDeploy.dll
• ISWindowsFeaturesAction.dll
• ISWindowsFeaturesAction64.dll
• ISXmlCfg.dll
• Layout.bin
• PowerShellWrap.dll
• PrqLaunch.dll
• QuickPatchHelper.dll
• SerialNumCAHelper.dll
• SetAllUsers.dll
• Setup.exe
• Setup.ini
• setup.inx
• setup.isn
• setup.ocx
• setup.skin
• Setup_UI.dll
• setupPreReq.exe
• SetupSuite.exe
• SetupSuite64.exe
• SFHelper.dll
• SQLRT.dll
• SuiteAppxHelper.exe
• SuiteSQLRT.dll
• XMLRT.dll
• Image files that are installed in the subfolders in the following folder:
• Image and icon files that are installed in the following folder, as well in this folder’s scale-150 and scale-200
subfolders:
Because the file size of many of the redistributables is so large, some that are available for use in your projects are not
added to your computer when you install InstallShield. However, these redistributables are still available for download
from the Internet to your computer.
You can identify the status of a redistributable by its icon. Following is a list of the possible icons in the Redistributables
view (or in InstallScript projects, the Objects view or the Prerequisites view) and a description of each:
Basic MSI, This InstallShield prerequisite is not installed on your computer but it is available
InstallScript, for download.
InstallScript MSI
Basic MSI, This InstallShield prerequisite is included in your project but its location is not
InstallScript, listed in one of the directories that is specified on the Prerequisites tab of the
InstallScript MSI Options dialog box.
Basic MSI, This merge module is stored in a repository and is available for inclusion in your
InstallScript MSI project. For more information about repositories, see Using a Repository to Share
Project Elements.
Basic MSI, This merge module is not installed on your computer but it is available for
InstallScript, download.
InstallScript MSI
Basic MSI, An old version of this merge module is installed on your computer. A new version
InstallScript MSI is available for download.
Basic MSI, This object is not installed on your computer but it is available for download.
InstallScript MSI
Basic MSI, An old version of this object is installed on your computer. A new version is
InstallScript MSI available for download.
Project • If you add to your project a redistributable that is not installed on your computer, one or more build errors are
generated when you build a release. To eliminate the build errors, either remove the redistributable from your project or
download it before rebuilding the release. If a redistributable is not installed on your computer, Needs to be downloaded is
specified in the Location column for that redistributable.
InstallShield does not permit you to add a redistributable in the Objects view to an InstallScript project if it is not installed on
your computer.
InstallShield Prerequisites
Many InstallShield prerequisites are available in InstallShield. In addition, the InstallShield Prerequisite Editor in
InstallShield enables you to modify these prerequisites and create your own. All InstallShield prerequisite (.prq) files are
stored in the following location:
Merge Modules
Merge modules are available from a variety of sources. Although InstallShield includes many redistributable modules, new
versions may be available or other software developers may have released a module that you need. In addition,
InstallShield enables you to create your own merge modules and add them to your redistributables gallery.
The source of the merge module files listed in the Redistributables view is the folder or folders specified on the Merge
Modules tab of the Options dialog box. To access the Options dialog box, on the Tools menu, click Options.
The following directory is the default location for the modules that come with InstallShield:
Objects
InstallShield provides many redistributable objects and lets you create your own for inclusion in your installations.
Furthermore, you may want to add to your projects the objects that other developers created with InstallShield.
The default location for the objects that come with InstallShield is:
The objects that are included in the above location are listed in the Redistributables view.
See Also
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Redistributables View
Creating InstallScript Objects
The procedures for downloading redistributables to your computer differ, depending on what type of project you are
using.
2. Right-click the InstallShield prerequisite, merge module, or object that you would like to download and then click
Download Selected Item.
Task To download all of the InstallShield prerequisites, merge modules, and objects that are needed for your installation
project:
2. Right-click any InstallShield prerequisite, merge module, or object and then click Download All Required Items.
2. Right-click the InstallShield prerequisite that you would like to download and then click Download Selected Item.
Task To download all of the InstallShield prerequisites that are needed for your installation project:
2. Right-click any InstallShield prerequisite and then click Download All Required Items.
The Objects view enables you to download the latest merge modules and objects from the Revenera Web site to your
computer. If a merge module is not installed on your computer, its icon ( ) indicates that it is not installed. InstallShield
does not permit you to add a merge module to your InstallScript project if the merge module is not installed on your
computer. If an object is not installed on your computer, it is not listed in the Objects view.
2. In the InstallShield Objects/Merge Modules pane, right-click the merge module that you would like to download and
then click Download Selected Item.
2. In the InstallShield Objects/Merge Modules pane, right-click any object and click Check Web. The downloads page
at the Revenera Web site opens in an Internet browser.
3. Select the object that you would like to download and install. You are prompted during the installation to close
InstallShield in order to complete the object installation.
See Also
Obtaining Updates for InstallShield
Managing the Redistributables Gallery
Determining the Files in InstallShield Prerequisites, Merge Modules, and Objects
• Basic MSI
• InstallScript
• InstallScript MSI
2. Using Windows Explorer, copy the new prerequisite to the following location:
4. Launch InstallShield.
The modifications that you made are reflected in the Redistributables view (in Basic MSI and InstallScript MSI projects) and
in the Prerequisites view (in InstallScript projects).
See Also
InstallShield Prerequisite Editor Reference
Designing InstallShield Prerequisites and Other Redistributables
• Basic MSI
• InstallScript
• InstallScript MSI
1. Close InstallShield.
2. Using Windows Explorer, locate and delete the InstallShield prerequisite that you want to remove from the gallery.
InstallShield prerequisites are located in the following directory:
3. Launch InstallShield.
The modifications that you made are reflected in the Redistributables view (in Basic MSI and InstallScript MSI projects) or
in the Prerequisites view (in InstallScript projects).
• Basic MSI
• InstallScript MSI
If a merge module that you would like to add to your project is not listed in the Redistributables view, you can browse to
find it and also add it to your project and this view.
2. Right-click an item and click Browse for Merge Module. The Open dialog box opens.
4. Click OK.
See Also
What Happens When You Browse for a Merge Module
Redistributables View
InstallShield does not maintain references to merge modules as explicit paths. Instead, it generates a key for a merge
module based on the merge module GUID and the merge module locale. When InstallShield needs to access the merge
module, it looks in the folders specified in the Merge Module Locations box for a file that matches that key. The Merge
Module Locations box is on the Merge Modules tab of the Options dialog box.
When you browse for a merge module, the path to the folder containing the merge module is added to the list of paths in
the Merge Module Locations box. In addition, a GUID:Locale key is added to your installation project based on the selected
file.
• Using Windows Explorer, copy the merge module that you want into one of the folders that is already listed in the
Merge Module Locations box.
• Remove the default folders from the search path so that you are referencing only the shared location.
See Also
Browsing for Merge Modules
• Basic MSI
• InstallScript
• InstallScript MSI
2. Using Windows Explorer, copy the new module to one of the folders specified on the Merge Modules tab of the
Options dialog box.
The default location for the modules that come with InstallShield is:
4. Launch InstallShield.
The modifications that you made are reflected in the Redistributables view (in Basic MSI and InstallScript MSI projects) and
in the Objects view (in InstallScript projects).
See Also
Downloading Redistributables to Your Computer
• Basic MSI
• InstallScript
• InstallScript MSI
1. Close InstallShield.
2. Using Windows Explorer, locate and delete the merge module that you want to remove from the gallery. Ensure that
you search each directory specified on the Merge Modules tab of the Options dialog box.
3. Launch InstallShield.
The modifications that you made are reflected in the Redistributables view (in Basic MSI and InstallScript MSI projects) and
in the Objects view (in InstallScript projects).
Note • If you delete a merge module that is currently associated with your installation, the message [Merge Module Not
Found] is displayed to inform you that the module cannot be included in your installation.
See Also
Managing the Redistributables Gallery
Downloading Redistributables to Your Computer
When you register an object from within an InstallScript project, InstallShield adds that object to the redistributables
gallery, which makes it available for inclusion in other projects.
2. Right-click an item, point to Advanced, and click Register new object. The Project Settings dialog box opens.
3. On the Language-Independent Object Properties tab, specify a media file (Data1.hdr file).
See Also
Distributing an Object
InstallShield includes many third-party redistributables that are packaged as InstallShield prerequisites, merge modules,
and objects. You can add these built-in redistributables to your installation projects. To learn how, see this section of the
documentation.
Tip • For information on creating your own InstallShield prerequisites, merge modules, and objects, see Designing
InstallShield Prerequisites and Other Redistributables.
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript
MSI Projects
InstallShield 2020
• Basic MSI
• InstallScript MSI
For information on adding redistributables to InstallScript projects, see Adding InstallShield Prerequisites, Merge Modules,
and Objects to InstallScript Projects.
Two types of redistributables—merge modules and objects—must be associated with a feature in order to be installed. You
can associate a single merge module or object with as many features or subfeatures as needed. If no features exist in your
installation project when you attempt to add a merge module or object, the Create a New Feature dialog box opens,
enabling you to create a feature. If you do not create a feature, these two types of redistributables cannot be added to your
installation project.
When you add an InstallShield prerequisite to an InstallScript MSI project, you cannot associate it with one or more
features.
When you add an InstallShield prerequisite to a Basic MSI project, it is not associated with any feature by default, and it is
called a setup prerequisite, since it is run before your main installation runs. If appropriate, you can associate an
InstallShield prerequisite with one more features that are currently in your project.
Task To add an InstallShield prerequisite, merge module, or object to a Basic MSI or InstallScript MSI project:
2. If you want merge modules that have been published to a repository to be displayed, right-click a redistributable and
ensure that Show Merge Modules in Repository is enabled.
3. Select the check box in front of the redistributable that you want to add. If you select an object, the associated wizard
opens to guide you through the customization process.
4. For a merge module or an object: In the Conditional Installation pane, select the check box for each feature that
should contain this redistributable.
If you are working with a Basic MSI project and you want to associate a prerequisite with a feature: In the Conditional
Installation pane, select the check box for each feature that should contain this prerequisite. If you do not want to
associate the prerequisite with a feature, leave the Install before feature selection check box selected. This check
box is selected by default when you add an InstallShield prerequisite to a Basic MSI project.
Tip • The right pane in the Redistributables view shows details about the merge module, object, or InstallShield prerequisite
that is selected in the list of available redistributables. Review this details pane to find out information such as which files a
redistributable installs. You can hide or show the details pane by clicking the Show Details button in this view.
Note • If Needs to be downloaded is specified in the Location column for an InstallShield prerequisite that you added to your
project, that InstallShield prerequisite is not installed on your computer. You can download the InstallShield prerequisite from
the Internet to your computer if you would like to include it in your project. If you build a release without first downloading one
or more required InstallShield prerequisites, and if you specify that the InstallShield prerequisites should be extracted from
Setup.exe or copied from the source media (instead of being downloaded from the Web to the end user’s computer), one or
more build errors may be generated. To eliminate the build errors, remove the InstallShield prerequisite from your project,
download it to your computer, or change the InstallShield prerequisite location for the release to the download option; then
rebuild the release.
Also note that if you have an installation (for example, a Setup.exe file or an .msi package) that you want to launch during
your installation, you can create your own custom InstallShield prerequisite, and then add that InstallShield prerequisite
to your projects as needed. To learn how to create your own InstallShield prerequisite, see Defining InstallShield
Prerequisites.
See Also
Downloading Redistributables to Your Computer
Managing the Redistributables Gallery
Working with InstallShield Prerequisites that Are Included in Installation Projects
Specifying the Installation Order of InstallShield Prerequisites
Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
Using a Repository to Share Project Elements
For information on adding redistributables to Basic MSI and InstallScript MSI projects, see Adding InstallShield Prerequisites,
Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects.
Merge modules and objects must be associated with a feature in order to be installed during an InstallScript installation.
You can associate a single merge module or object with as many features or subfeatures as needed. If no features exist in
your installation project when you attempt to add a merge module or object, the Create a New Feature dialog box opens,
enabling you to create a feature. If you do not create a feature, these two types of redistributables cannot be added to your
installation project.
When you add an InstallShield prerequisite to an InstallScript project, you cannot associate it with one or more features.
2. Select the check box in front of the InstallShield prerequisite that you want to add.
Tip • The right pane in the Prerequisites view shows details about the InstallShield prerequisite that is selected in the list of
available redistributables. Review this details pane to find out information such as which files a redistributable installs. You
can hide or show the details pane by clicking the Show Details button in this view.
Note • If Needs to be downloaded is specified in the Location column for an InstallShield prerequisite that you added to your
project, that InstallShield prerequisite is not installed on your computer. You can download the InstallShield prerequisite from
the Internet to your computer if you would like to include it in your project. If you build a release without first downloading one
or more required InstallShield prerequisites, and if you specify that the InstallShield prerequisites should be included with the
media (instead of being downloaded from the Web to the end user’s computer), one or more build errors may be generated. To
eliminate the build errors, remove the InstallShield prerequisite from your project, download it to your computer, or change
the InstallShield prerequisite location for the release to the download option; then rebuild the release.
2. In the Features pane, select the feature to which you want to add an object or merge module.
3. Right-click the object or merge module that you want to add and select Add to selected feature. (You can instead
drag the object or merge module and drop it on the feature.) For some objects, an associated wizard appears to guide
you through the customization process.
Note • Merge modules that are added to a feature in an InstallScript project appear in the Features pane as subitems of the
Merge Module Holder object. This object requires the Windows Installer engine. For more information, see Adding Windows
Installer Redistributables to Projects.
Tip • To see information about an object or merge module, such as files it installs and other actions it performs, select the
object or merge module name. The information is displayed in the pane on the right.
Obtaining Objects
Note that some of the objects are not installed with InstallShield. You may need to download them. For more information,
see Obtaining Updates for InstallShield.
See Also
Managing the Redistributables Gallery
Downloading Redistributables to Your Computer
Working with InstallShield Prerequisites that Are Included in Installation Projects
Specifying the Installation Order of InstallShield Prerequisites
Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
• Basic MSI
• InstallScript
• InstallScript MSI
1. In the View List under Application Data, click Redistributables (in Basic MSI and InstallScript MSI projects) or
Prerequisites (in InstallScript projects).
2. Clear the check box in front of the InstallShield prerequisite that you want to remove.
Tip • If an InstallShield prerequisite is included in your installation as a dependency of another InstallShield prerequisite but
you want to remove that dependency prerequisite from the installation, you must remove the corresponding dependency from
the InstallShield prerequisite. For more information, see Removing a Dependency from an InstallShield Prerequisite.
See Also
Specifying the Installation Order of InstallShield Prerequisites
• Basic MSI
• InstallScript
• InstallScript MSI
• In Basic MSI and InstallScript MSI projects: In the Redistributables view, clear the check box in front of the
redistributable.
• In InstallScript projects: In the Objects view, right-click the redistributable in the Features window and click Delete
from project.
InstallShield moves the merge module or object from your project. In addition, InstallShield automatically removes from
the project any dependencies that are associated with that redistributable.
• Basic MSI
• InstallScript
• InstallScript MSI
If you need to see a list of files in an InstallShield prerequisite, a merge module, or an object, you can do so from within the
Redistributables view in Basic MSI and InstallScript MSI projects. The right pane in this view shows details about the
InstallShield prerequisite, merge module, or object that is selected in the list of available redistributables. This details pane
provides information such as which files a redistributable installs. You can hide or show the details pane by clicking the
Show Details button in this view. Clicking the Show Details button in the Prerequisites view of an InstallScript project lets
you see the files in the selected InstallShield prerequisite.
If you are using an InstallScript project and you want to see details about a merge module or object that is listed in the
Objects view, select that object; InstallShield displays a list of the redistributable’s files, as well as additional information,
in the right pane.
Tip • For another way to see the files contained in a merge module or object, see Knowledge Base article Q106474. This article
contains a link to a downloadable Merge Module Dependency Viewer.
• Basic MSI
• InstallScript
• InstallScript MSI
An InstallShield prerequisite is an installation for a product or technology framework that is required by your product.
Some examples of InstallShield prerequisites that are included with InstallShield are Java Runtime Environment (JRE) and
SQL Server Express Edition. You can add any of the existing InstallShield prerequisites to your installation projects and
configure many of their settings. You can also create your own InstallShield prerequisites, and add them to your projects.
Project • Including InstallShield prerequisites in Windows Installer–based projects enables you to chain multiple installations
together, bypassing the Windows Installer limitation that permits only one Execute sequence to be run at a time. The
Setup.exe setup launcher serves as a bootstrap application that manages the chaining.
Note • Unlike Windows Installer 4.5 chaining, the InstallShield prerequisite installations are not processed as a single
transaction; that is, successful installations are not rolled back after failures in later prerequisites. To learn more about
Windows Installer 4.5 chaining support, see Configuring Multiple Packages for Installation Using Transaction Processing.
The Redistributables view is where you add InstallShield prerequisites to Basic MSI and InstallScript MSI projects. The
Prerequisites view is where you add InstallShield prerequisites to InstallScript projects.
See Also
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
Specifying the Installation Order of InstallShield Prerequisites
Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
Defining InstallShield Prerequisites
The following project types include support for setup prerequisites but not feature prerequisites:
• InstallScript
• InstallScript MSI
An InstallShield prerequisite that is run before the main installation’s user interface sequence begins is called a setup
prerequisite. Setup prerequisites are useful for base applications and technology frameworks that must be installed for all
configurations of the installed product or that provide functionality that is used during the installation itself. When you add
an InstallShield prerequisite to a project, it is the setup prerequisite type of InstallShield prerequisite by default.
Basic MSI projects enable you to associate InstallShield prerequisites with features in your main installation. When an
InstallShield prerequisite is associated with one or more features, it is called a feature prerequisite. Feature prerequisites
are installed after an end user has chosen which features to install; like merge modules, a feature prerequisite is installed
only if one or more of the features that contain it are installed. Thus, feature prerequisites are useful for applications or
components that are used by only some configurations of the installed product and are not used during the installation
itself.
Review the following sections for more information that will help you determine which type of InstallShield prerequisite
will best fit your requirements.
If your installation includes the .NET Framework redistributable and a setup prerequisite that requires that the .NET
Framework be present on the target machine—for example, if it installs files to the GAC—you can specify that the .NET
Framework should be installed before the setup prerequisite is installed. To learn more, see Specifying Parameters for
Installing an InstallShield Prerequisite.
Displaying an Error If an End User Launches the .msi Package Instead of the Setup Launcher
If your Basic MSI or InstallScript MSI installation includes a setup prerequisite and end users launch the .msi package for
your product directly, rather than launch the Setup.exe setup launcher, the setup prerequisite installation will not run. If
the prerequisite is not already present on a target system, your product may not work as expected. This scenario may occur
if you build an uncompressed release, where the .msi package is not streamed into the Setup.exe file.
To prevent this issue from occurring, you may want to add a type 19 custom action to your Basic MSI or InstallScript MSI
project. This custom action would evaluate the same conditions that were configured for the prerequisite on the
Conditions tab in the InstallShield Prerequisite Editor. The custom action would verify whether the setup prerequisite is
still needed; if it is needed, the type 19 error custom action would display an error message and end the installation.
To prevent file-costing issues for a feature prerequisite in your project, you may want to add a custom action that evaluates
the same conditions that were configured for the feature prerequisite on the Conditions tab in the InstallShield
Prerequisite Editor. This custom action would detect whether the feature prerequisite needs to be run if its associated
feature is selected to be installed.
If the feature prerequisite would need to be run, the custom action would add a temporary row to the ReserveCost table.
See Also
Associating an InstallShield Prerequisite with a Feature in a Basic MSI Project
Disassociating an InstallShield Prerequisite from a Feature in a Basic MSI Project
Designing InstallShield Prerequisites and Other Redistributables
Project • Basic MSI projects include support for associating prerequisites with features.
To learn about the differences between setup prerequisites and feature prerequisites (which are the two types of InstallShield
prerequisites), see Setup Prerequisites vs. Feature Prerequisites.
If an InstallShield prerequisite is associated with a feature in a project, it is considered to be a feature prerequisite. If it is not
associated with a feature, it is considered to be a setup prerequisite.
Whenever you add an InstallShield prerequisite to an installation project, it is automatically added as a setup prerequisite
by default. You can make it a feature prerequisite by associating it with one or more features that already exist in your
project.
2. In the list of redistributables, select the InstallShield prerequisite that you want to associate with a feature.
Note • The InstallShield prerequisite’s check box must already be selected; this indicates that it is being included in your
project. For more information, see Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and
InstallScript MSI Projects.
3. In the Conditional Installation pane, select the check box of each feature to which you want to add this InstallShield
prerequisite.
If you want to associate the prerequisite with a new feature, you must first create it. To learn how to create a new feature,
see Creating Features.
If you associate a prerequisite with all of the features in your project and then you later add a new feature, InstallShield
does not automatically associate the feature prerequisite with the new feature.
Note • Feature prerequisites have some limitations that setup prerequisites do not have. For more information, see Setup
Prerequisites vs. Feature Prerequisites.
Project • Basic MSI projects include support for associating prerequisites with features.
To learn about the differences between setup prerequisites and feature prerequisites (which are the two types of InstallShield
prerequisites), see Setup Prerequisites vs. Feature Prerequisites.
If an InstallShield prerequisite is associated with a feature in a project, it is considered to be a feature prerequisite. If it is not
associated with a feature, it is considered to be a setup prerequisite.
2. In the list of redistributables, select the InstallShield prerequisite that you want to disassociate from a feature.
3. In the Conditional Installation pane, select the Install before feature selection check box. This check box is selected
by default when you add an InstallShield prerequisite to a Basic MSI project.
Note • Setup prerequisites have some advantages over feature prerequisites. For more information, see Setup Prerequisites
vs. Feature Prerequisites.
The following project types include support for setup prerequisites but not feature prerequisites:
• InstallScript
• InstallScript MSI
To learn about the differences between setup prerequisites and feature prerequisites (which are the two types of InstallShield
prerequisites), see Setup Prerequisites vs. Feature Prerequisites.
The Redistributables view is where you specify the order in which InstallShield prerequisites should be installed if you
include more than one in a Basic MSI project or an InstallScript MSI project. The Prerequisites view is where you specify the
order in which InstallShield prerequisites should be installed if you include more than one in an InstallScript project.
Task To specify the order in which the InstallShield prerequisites should be installed on the target machine:
1. In the View List under Application Data, click Redistributables (in a Basic MSI or InstallScript MSI project) or
Prerequisites (in an InstallScript project).
2. Add the necessary InstallShield prerequisites to your project if you have not already done so.
3. Right-click any redistributable and click Set InstallShield Prerequisite Order. The InstallShield Prerequisite
Installation Order dialog box opens.
4. Select a prerequisite in the list and then click the up or down arrow to move it up or down in the order for installation.
Project • Note that when you are specifying the order in a Basic MSI project, InstallShield does not distinguish between setup
prerequisites and feature prerequisites. Thus, if your project contains a mix of setup prerequisites and feature prerequisites,
they are all listed in one combined list on the InstallShield Prerequisite Installation Order dialog box. At run time, before the
main installation launches, the Setup.exe setup launcher evaluates only the setup prerequisites and—if appropriate—installs
them in the order that you specified on the InstallShield Prerequisite Installation Order dialog box. Then later during the
installation, the Windows Installer engine evaluates only the feature prerequisites and—if appropriate—installs them in the
order that you specified.
Tip • If the Windows Installer engine, the .NET Framework, or both must be installed before an InstallShield prerequisite is
installed, you can open the InstallShield prerequisite in the InstallShield Prerequisite Editor and specify this requirement. For
more information, see Specifying Parameters for Installing an InstallShield Prerequisite.
See Also
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
Minimizing the Number of User Account Control Prompts During Installation
• Basic MSI
• InstallScript
• InstallScript MSI
When you package a Basic MSI or InstallScript MSI installation that includes InstallShield prerequisites, you can use any
one of the following methods for supplying the InstallShield prerequisite files to end users:
• Compress the InstallShield prerequisite files into Setup.exe, to be extracted at run time, as needed.
• If necessary, your installation can download the InstallShield prerequisite files that are included in your project from
the URL that is specified in the InstallShield prerequisite file (.prq) for each prerequisite.
For InstallScript installations that include InstallShield prerequisites, the methods that are available are slightly different:
• Store the InstallShield prerequisite files on the source media or in Setup.exe, depending on how you configure the
settings for the release.
• If needed, your installation can download the InstallShield prerequisite files included in your project from the URL
specified in the InstallShield prerequisite (.prq) file for each prerequisite.
You can specify different methods for each InstallShield prerequisite in your project. To learn more, see Specifying a Run-
Time Location for a Specific InstallShield Prerequisite.
You can also override individual methods at the release level if you want all of the InstallShield prerequisites in a release to
be available through the same method. For more information, see Specifying the Run-Time Location for InstallShield
Prerequisites at the Release Level.
You can configure an InstallShield prerequisite so that it is installed either before or after any installation of the Windows
Installer engine and the .NET Framework. For more information, see Specifying Parameters for Installing an InstallShield
Prerequisite.
See Also
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
Specifying the Installation Order of InstallShield Prerequisites
Defining InstallShield Prerequisites
• Basic MSI
• InstallScript
• InstallScript MSI
InstallShield lets you specify additional or alternative locations on your local machine, or on a network. This flexibility
enables you to store InstallShield prerequisites in source code control and to share a common set of InstallShield
prerequisites with other team members.
InstallShield offers several ways for specifying the search paths for InstallShield prerequisite files (.prq):
• If you are editing or building from within InstallShield, use the Prerequisites tab on the Options dialog box—which is
displayed when you click Options on the Tools menu—to specify a comma-delimited list of machine-wide folders and
current-user folders.
InstallShield saves the paths that you specify on the Prerequisites tab in the registry on your machine. The paths that
you specify for the current user are stored in the following location:
HKEY_CURRENT_USER\Software\InstallShield\Version\Professional\Project Settings\PrerequisiteSearchPath
The paths that you specify for all users are stored in the following location:
HKEY_LOCAL_MACHINE\Software\InstallShield\Version\Professional\PrerequisiteSearchPath
The Options dialog box is not available if you are using the Standalone Build to build a release; however, if you want,
you can manually add the paths to the registry on a machine that has the Standalone Build.
• If you are building from the command line with ISCmdBld.exe, use the -prqpath parameter to specify a comma-
delimited list of folders.
If you use an .ini file to specify ISCmdBld.exe parameters, you can use the PrerequisitePath parameter in the [Mode]
section of your .ini file to specify a comma-delimited list of folders.
• If you are building through MSBuild or Team Foundation Server (TFS), use the PrerequisitePath parameter on the
InstallShield task. This parameter is exposed as the ItemGroup InstallShieldPrerequisitePath when the default targets
file is used. To specify multiple paths, use an ordered array of paths.
Instead of using hard-coded paths, you can use path variables in paths, as in the following example:
<ISProductFolder>\SetupPrerequisites,<ISProjectFolder>\MyCustomPrerequisites
The Redistributables view and the Prerequisites view list the names of the InstallShield prerequisites that correspond with
the .prq files that are present in the various search paths that are specified on the Prerequisites tab of the Options dialog
box. If the same .prq file is in multiple search paths, InstallShield shows only the first instance that it encounters.
InstallShield first searches each path that is listed in the per-user setting on the Prerequisites tab. Then, InstallShield
checks each path that is listed in the machine-wide setting.
At build time, if your project includes one or more InstallShield prerequisites, InstallShield (or the Standalone Build)
searches the specified locations and includes the appropriate InstallShield prerequisites in your release as needed. If the
same .prq file is in multiple search paths, InstallShield includes in the build only the first instance that it encounters. It uses
the following order to search for .prq files:
1. InstallShield (or the Standalone Build) checks the paths that are specified through the -prqpath command-line
parameter, the PrerequisitePath .ini file parameter, or the PrerequisitePath parameter on the InstallShield task.
2. InstallShield checks each path that is listed in the per-user setting on the Prerequisites tab. The paths are saved in the
following location in the registry.
HKEY_CURRENT_USER\Software\InstallShield\Version\Professional\Project Settings\PrerequisiteSearchPath
Note that the Prerequisites tab is not applicable to the Standalone Build, but the registry path is applicable.
3. InstallShield checks each path that is listed in the machine-wide setting on the Prerequisites tab. The paths are saved
in the following location in the registry.
HKEY_LOCAL_MACHINE\Software\InstallShield\Version\Professional\PrerequisiteSearchPath
Note that the Prerequisites tab is not applicable to the Standalone Build, but the registry path is applicable.
4. If no paths are specified in any of the aforementioned locations, InstallShield checks the default location
(InstallShield (or Standalone Build) Program Files Folder\SetupPrerequisites).
Tip • If you are using the Standalone Build to build a release that includes InstallShield prerequisites but you do not specify
one or more search paths, the Standalone Build searches the default path (<ISProductFolder>\SetupPrerequisites) for
the InstallShield prerequisite files. However, if you specify one or more search paths and do not explicitly include the default
path, the Standalone Build does not search the default path.
See Also
Using Path Variables
• Basic MSI
• InstallScript
• InstallScript MSI
InstallShield enables you to specify a different run-time location for each InstallShield prerequisite in your project.
Task To specify a different run-time location for each InstallShield prerequisite in your installation:
1. In the View List under Application Data, click Redistributables (in a Basic MSI or InstallScript MSI project) or
Prerequisites (in an InstallScript project).
2. Select the check box for one of the InstallShield prerequisites that you want to include in your installation.
3. Right-click the InstallShield prerequisite and click Properties. The InstallShield Prerequisites Properties dialog box
opens.
Note that the location that you specify can be overridden at the release level. To avoid overriding the value that you
selected for an individual InstallShield prerequisite, the InstallShield Prerequisites Location setting at the release level
must be set to Follow Individual Selections. For more information, see Specifying the Run-Time Location for InstallShield
Prerequisites at the Release Level.
Tip • If an InstallShield prerequisite is added to a project as a dependency of another prerequisite, the location for the
InstallShield prerequisite dependency follows the location setting of the InstallShield prerequisite that requires it.
See Also
Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
InstallShield Prerequisite Properties Dialog Box
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
You can set release flags for InstallShield prerequisites that you want to exclude from certain builds. For example, if you
have an InstallShield prerequisite that should be included only in a special edition of your product that contains a special
add-on that requires the InstallShield prerequisite, you can flag that InstallShield prerequisite and include it only when it is
needed.
Task To add a release flag to an InstallShield prerequisite that you have added to your installation project:
2. Right-click the InstallShield prerequisite and click Properties. The InstallShield Prerequisites Properties dialog box
opens.
3. In the Release Flags box, type a string. The string can be any combination of letters or numbers. To have more than
one flag on a prerequisite, use a comma to separate the flags.
To learn more about filtering InstallShield prerequisites based on release flags, see Release Flags.
See Also
InstallShield Prerequisite Properties Dialog Box
• Basic MSI
• InstallScript MSI
When InstallShield builds a Setup.exe file for a project that does not include any prerequisites, it starts with the base
Setup.exe file that is stored in the following location:
However, when InstallShield builds a Setup.exe file for a project that includes prerequisites, the aforementioned files
cannot be used as the base because it does not have the capability of including prerequisites. A slightly larger file called
SetupPrereq.exe is used instead. The base SetupPrereq.exe file is located in the same directory as the base Setup.exe
file. Since different base files—Setup.exe and SetupPrereq.exe—are used, only installation authors who are actually
including prerequisites in their projects incur the additional size overhead in the final, built Setup.exe file that is
distributed to end users.
See Also
Creating a Setup Launcher
Project • The following project types include support for both setup prerequisites and feature prerequisites:
• Basic MSI
The following project types include support for setup prerequisites but not feature prerequisites:
• InstallScript
• InstallScript MSI
To learn about the differences between setup prerequisites and feature prerequisites (which are the two types of InstallShield
prerequisites), see Setup Prerequisites vs. Feature Prerequisites.
1. The setup launcher (typically called Setup.exe) displays the language selection dialog if appropriate.
2. The setup launcher displays the setup prerequisite dialog and launches the setup prerequisite installations if
appropriate.
3. The installation displays the installation UI, which may allow the end user to select features or configure items. The
installation UI shows a progress dialog.
4. In Basic MSI installations, the setup launcher launches the feature prerequisite installations if appropriate:
a. The built-in InstallShield custom action ISInstallPrerequisites, which is scheduled between the SetupProgress
dialog and the ExecuteAction action, compares the features that were selected for installation against the list in
the Windows Installer property IsPrerequisiteFeatures. If there are no matches, no feature prerequisites are
installed.
b. The ISInstallPrerequisites action attempts to find and launch the setup launcher, and it provides the list of
features that are being installed. The path to the setup launcher is identified by the Windows Installer properties
SETUPEXEDIR and SETUPEXENAME:
[SETUPEXEDIR]\[SETUPEXENAME]
If ISInstallPrerequisites cannot find the setup launcher in that location, it searches elsewhere. For a first-time
installation, ISInstallPrerequisites checks SourceDir. For maintenance mode, ISInstallPrerequisites checks paths
that are related to the installation source path.
If ISInstallPrerequisites still cannot find the setup launcher, or if it finds multiple .exe files, the installation
prompts the end user to browse to the setup launcher file. If the end user identifies the file, the installation
continues. Otherwise, the installation ends.
c. The setup launcher evaluates the list of features to select which feature prerequisites to install, and it launches
their installations as appropriate.
5. The installation finishes making changes on the target system according to the end user’s selections.
6. The installation switches from the progress dialog to the SetupCompleteSuccess dialog.
Figure 4-2: Sample Setup Prerequisite Dialog that Shows the List of Setup Prerequisites that Need to Be Installed
If a setup prerequisite is configured to be hidden, it is not listed in the setup prerequisite dialog, but it is still installed. If all
of the setup prerequisites in an installation are hidden, the installation displays the setup launcher’s standard initialization
dialog instead of the setup prerequisite dialog.
Tip • For instructions on how to show or hide the setup prerequisite in the setup prerequisite dialog, see Specifying Whether to
Include the Name of a Prerequisite in the List of Setup Prerequisites to Be Installed on the Target System.
If the file that a setup prerequisite installation launches is an .msi package and the prerequisite is marked to show
progress, the user interface shows a status bar, along with installation progress messages from Windows Installer, while
the prerequisite is being installed. This is applicable only if the main installation is a Basic MSI or InstallScript MSI
installation. For more details, see Specifying Whether to Show the Progress of an InstallShield Prerequisite Installation at
Run Time.
If a setup prerequisite is configured to be optionally installed by the end user, the setup launcher displays a message box
that enables end users to choose whether to install the setup prerequisite. For more information, see Allowing End Users to
Choose Whether to Install an InstallShield Prerequisite.
If an installation includes feature prerequisites, the setup launcher does not list them in any prerequisite dialog. However,
the user interface does show progress messages if appropriate. In addition, the setup launcher displays the optional
prerequisite message box if the feature prerequisite is marked as optional.
• Silent setup launcher and visible .msi package—The user interface for the setup launcher is suppressed, but the
user interface for the .msi package is visible. For example, the end user might use the following command-line
statement:
Setup.exe /s
In this scenario, the language selection dialog and the setup prerequisite dialog are not displayed.
• Visible setup launcher and silent .msi package—The user interface for the setup launcher is displayed, but the user
interface for the .msi package is suppressed. For example, the end user might use the following command-line
statement:
Setup.exe /v“/qn”
In this scenario, the feature selection dialog and all of the other dialogs of the main installation are not displayed.
However, the end user can set Windows Installer properties such as ADDLOCAL, ADDSOURCE, ADDDEFAULT, and ADVERTISE
from the command line to indicate which features should be installed.
• Silent setup launcher and silent .msi package—The user interface for the setup launcher and the .msi package are
suppressed. For example, the end user might use the following command-line statement:
Setup.exe /s /v“/qn”
In this scenario, all of the setup launcher and .msi package dialogs are suppressed.
If the UI sequence of the main installation’s .msi package is skipped, the setup launcher evaluates Windows Installer
properties such as ADDLOCAL, ADDSOURCE, ADDDEFAULT, and ADVERTISE to determine if any feature prerequisites should be
installed, and it installs feature prerequisites accordingly.
Setup.exe /s
Note that a response file (Setup.iss) is required. To learn more, see Creating the Response File.
The language selection dialog and the setup prerequisite dialog are not displayed.
UAC Prompts
Depending on how it is configured, an installation that includes InstallShield prerequisites may prompt for elevated
privileges on Windows Vista and later systems at several different points during the installation:
2. When the Setup.exe file launches a setup prerequisite that requires elevated privileges
3. When the Setup.exe file launches a feature prerequisite that requires elevated privileges
4. When the Windows Installer begins the Execute sequence of the .msi package
For more information, see Minimizing the Number of User Account Control Prompts During Installation.
You can configure an InstallShield prerequisite so that it is installed either before or after any installation of the Windows
Installer engine and the .NET Framework. For more information, see Specifying Parameters for Installing an InstallShield
Prerequisite.
See Also
Restarting a Target Machine for InstallShield Prerequisite Installations
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
Specifying the Installation Order of InstallShield Prerequisites
Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
• Basic MSI
• InstallScript
• InstallScript MSI
Your installation may consist of your application plus one or more InstallShield prerequisites. If end users uninstall your
application through Add or Remove Programs in the Control Panel, the InstallShield prerequisites are still installed on their
machines. If an InstallShield prerequisite installation added an entry to Add or Remove Programs, an end user would be
able to remove that InstallShield prerequisite through Add or Remove Programs.
See Also
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
Specifying the Installation Order of InstallShield Prerequisites
Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
This section of the documentation offers guidance for working with merge modules from within installation projects.
For information on creating or modifying your own merge modules, see Designing Merge Modules.
See Also
Adding Dependencies to Merge Modules
Adding Exclusions to Merge Modules
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
Determining the Files in InstallShield Prerequisites, Merge Modules, and Objects
• Basic MSI
• InstallScript
• InstallScript MSI
InstallShield lets you specify the locations on your local machine, or on a network, where you are storing merge modules
(.msm files). This flexibility enables you to store merge modules in source code control and to share a common set of
merge modules with other team members.
InstallShield offers several ways for specifying the search paths for merge modules:
• If you are editing or building from within InstallShield, use the Merge Modules tab on the Options dialog box—which is
displayed when you click Options on the Tools menu—to specify a comma-delimited list of machine-wide folders and
current-user folders.
InstallShield saves the paths that you specify on the Merge Modules tab in the registry on your machine. The paths
that you specify for the current user are stored in the following location:
HKEY_CURRENT_USER\Software\InstallShield\Version\Professional\Project Settings\MMSearchPath
The paths that you specify for all users are stored in the following location:
HKEY_LOCAL_MACHINE\Software\InstallShield\Version\Professional\MMSearchPath
The Options dialog box is not available if you are using the Standalone Build to build a release; however, if you want,
you can manually add the paths to the registry on a machine that has the Standalone Build.
• If you are building from the command line with ISCmdBld.exe, use the -o parameter to specify a comma-delimited list
of folders.
If you use an .ini file to specify ISCmdBld.exe parameters, you can use the MergeModulePath parameter in the [Mode]
section of your .ini file to specify a comma-delimited list of folders.
• If you are building through MSBuild or Team Foundation Server (TFS), use the MergeModulePath parameter on the
InstallShield task. This parameter is exposed as the ItemGroup InstallShieldMergeModulePath when the default
targets file is used. To specify multiple paths, use an ordered array of paths.
Instead of using hard-coded paths, you can use path variables in paths, as in the following example:
<ISProductFolder>\MergeModules,<ISProjectFolder>\MyCustomMergeModules
The Redistributables view and the Objects view list the names of the merge modules that correspond with the merge
modules that are present in the various search paths that are specified on the Merge Modules tab of the Options dialog box.
If the same merge module is in multiple search paths, InstallShield shows only the first instance that it encounters.
InstallShield first searches each path that is listed in the per-user setting on the Merge Modules tab. Then, InstallShield
checks each path that is listed in the machine-wide setting.
At build time, if your project includes one or more merge modules, InstallShield (or the Standalone Build) searches the
specified locations and includes the appropriate merge modules in your release as needed. If the same merge module is in
multiple search paths, InstallShield includes in the build only the first instance that it encounters. It uses the following
order to search for merge modules:
1. InstallShield (or the Standalone Build) checks the paths that are specified through the -o command-line parameter,
the MergeModulePath .ini file parameter, or the MergeModulePath parameter on the InstallShield task
2. InstallShield checks each path that is listed in the per-user setting on the Merge Modules tab. The paths are saved in
the following location in the registry.
HKEY_CURRENT_USER\Software\InstallShield\Version\Professional\Project Settings\MMSearchPath
Note that the Merge Module tab is not applicable to the Standalone Build, but the registry path is applicable.
3. InstallShield checks each path that is listed in the machine-wide setting on the Merge Modules tab. The paths are
saved in the following location in the registry.
HKEY_LOCAL_MACHINE\Software\InstallShield\Version\Professional\MMSearchPath
Note that the Merge Module tab is not applicable to the Standalone Build, but the registry path is applicable.
4. If no paths are specified in any of the aforementioned locations, InstallShield checks the following default directories,
in order:
Tip • If you are using the Standalone Build to build a release that includes merge modules but you do not specify one or more
search paths through any of the user-defined methods (that is, in the registry, through the command line or the .ini file, or
through the InstallShield task), the Standalone Build searches the aforementioned default directories for the merge modules.
However, if you specify one or more search paths and do not explicitly include the default directories, the Standalone Build
does not search the default directories.
See Also
Using Path Variables
Although you should not alter a third-party merge module, you can override the destination for an InstallShield-created
merge module and some third-party merge modules.
Note • This procedure redirects only the TARGETDIR directory in the merge module, or directories that derive directly from
TARGETDIR. If the merge module is configured to send files to a predefined folder (for example, SystemFolder), you cannot
override the module’s destination.
2. Select the check box next to the merge module to add it to your installation.
3. Right-click the module and click Properties. The Merge Module Properties dialog box opens.
4. In the Destination box, type a destination or select one from the list of predefined destinations.
5. Click OK.
6. In the Conditional Installation pane, select the feature or features that should contain the merge module.
See Also
Redistributables View
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
If the language identifier of a merge module file is changed after the file is added to the redistributables gallery,
InstallShield cannot find the file.
To locate the correct merge module file, you can browse to it from within the Redistributables view. To learn how, see
Browsing for Merge Modules.
See Also
What Happens When You Browse for a Merge Module
Redistributables View
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
• Basic MSI
• InstallScript MSI
If you have an existing merge module that you would like to reuse in Windows Installer–based installation projects or share
with other users, you can publish it to a repository.
Task To publish a merge module to a repository when you are working on a Windows Installer–based installation project:
2. Right-click the merge module and then click Publish Wizard. The Publish Wizard opens.
Merge modules are built into an installation at build time. If you make a change to a repository merge module and then
republish it to the repository, any project that has the old version of the repository merge module will be updated the next
time that a release of the project’s installation is rebuilt.
See Also
Publishing a Merge Module to a Repository from Within a Merge Module Project
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Using a Repository to Share Project Elements
• Basic MSI
• InstallScript
• InstallScript MSI
Although the Windows Installer is built into most versions of Windows, a Windows Installer–based installation may depend
on certain functionality that is available in only the latest versions of Windows Installer. In addition, some InstallScript
installations may require a particular version of Windows Installer.
InstallShield enables you to include a redistributable for Windows Installer in your project. The method for adding a
Windows Installer redistributable to your project depends on the project type that you are using, as well as the version of
Windows Installer that your installation requires.
For a list of the minimum operating for each version of Windows Installer, see Target System Requirements.
For a list of which versions of Windows Installer were released with which versions of Windows, see Released Versions of
Windows Installer in the Windows Installer Help Library.
Note that Windows Installer 5 and Windows Installer 4 are not available as redistributables.
If you want to include the Windows Installer redistributable in a Basic MSI or InstallScript MSI project, do one of the
following:
• For Windows Installer 4.5—Add one or more Microsoft Windows Installer prerequisites to your project. InstallShield
includes several versions that target different versions of Windows. For more information, see Including Microsoft
Windows Installer Prerequisites.
• For Windows Installer 3.1, 3.0, or 2.0—The Setup.exe tab for a release in the Releases view is where you specify
information such as whether you want to use a Setup.exe launcher, whether you want to include one of these
versions of the Windows Installer redistributable, and which version of Windows Installer you want to include. To learn
more, see Setup.exe Tab for a Release.
As an alternative, you can add one or more Microsoft Windows Installer prerequisites to your project. For more
information, see Including Microsoft Windows Installer Prerequisites.
Tip • You can also specify setup launcher requirements in the Setup Launcher panel of the Release Wizard.
InstallScript Projects
In some cases, you may want to add a Windows Installer redistributable to an InstallScript project. For example, you may
be using an InstallScript project to chain together multiple Windows Installer–based installations that require a particular
minimum version of Windows Installer. In addition, if you add a merge module to an InstallScript project, that merge
module must be added as a subitem of the Merge Module Holder object in the Objects view. This Merge Module Holder
object requires the Windows Installer engine, so if target systems may not have the Windows Installer present, you need to
add the Windows Installer redistributable to your InstallScript project.
If you want to include the Windows Installer redistributable in an InstallScript project, add one or more Microsoft Windows
Installer prerequisites to your project. InstallShield includes several versions that target different versions of Windows. For
more information, see Including Microsoft Windows Installer Prerequisites.
See Also
Creating a Setup Launcher
Setup.exe Return Values and Run-Time Errors (Basic MSI and InstallScript MSI Projects)
SETUPEXEDIR
• Basic MSI
• InstallScript
• InstallScript MSI
InstallShield includes InstallShield prerequisites for several versions of Windows Installer. You can use the Redistributables
view (in Basic MSI and InstallScript MSI projects) or the Prerequisites view (in InstallScript projects) to add these
InstallShield prerequisites to your project.
Checking for the Presence of Windows Installer 4.5 During Basic MSI or InstallScript
MSI Installations
You may want your installation to check the target system to determine if Windows Installer 4.5 is installed; if it is not
installed, the installation would display an error message box and prevent the installation from continuing. This may be
helpful under the following conditions:
• It is possible that the .msi file might be used to install your product, rather than the Setup.exe setup launcher (which
would install Windows Installer 4.5 if appropriate).
For example, if you deploy your installation as an uncompressed release, end users would be able to launch the .msi
file directly rather than the Setup.exe file. In addition, if systems administrators want to customize your installation
for deploying your product throughout an enterprise environment, they might create an administrative installation
version and deploy that.
To determine whether Windows Installer 4.5 is installed and display an error message if it is not, create an error custom
action (a type 19 custom action). The following procedure explains how.
Task To determine whether Windows Installer 4.5 is installed and display an error message if it is not:
1. In the Custom Actions and Sequences view, right-click the Custom Actions explorer and click New Error.
3. In the Error Message setting, type the error message text that should be displayed when an end user launches your
installation without Windows Installer 4.5 being already installed.
4. In the Install UI Sequence and Install Exec Sequence settings, select an option that would schedule the error
message somewhere before the LaunchConditions action. For example, a common sequence for this error action is
<First Action>.
5. In the Install UI Condition and Install Exec Condition settings, type the following condition:
On Windows XP and Windows Server 2003 systems, the Windows Installer 4.5 engine files are updated immediately and the
requirement for a reboot is noted and delayed until the end of the main installation (or any reboot that precedes it). The
main installation uses the updated Windows Installer 4.5 engine, and it requests a reboot at the end of the installation.
On Windows Vista and Windows Server 2008 systems, the Windows Installer 4.5 engine files are not updated until after a
reboot, so a reboot is requested immediately. If the end user allows the machine to be rebooted, the installation continues
after the reboot. If the end user does not allow the machine to be rebooted, the installation ends. While the reboot is
pending, the Windows Installer 4.5 engine appears as not installed, and subsequent attempts to run the prerequisite would
result in a failure and would not allow installation to continue. Rebooting the machine completes the installation of
Windows Installer 4.5 and allows the installation to continue as planned.
See Also
Adding Windows Installer Redistributables to Projects
Modifying an Existing InstallShield Prerequisite
InstallShield Prerequisite Editor Reference
• Basic MSI
• InstallScript
• InstallScript MSI
If your product requires that the .NET Framework be installed on the target system, you can add the .NET Framework
redistributable to your project. If the target system does not have the .NET Framework, it is installed during your
installation.
You can also include redistributables for .NET Framework language packs in your project. The language packs contain
translated text, such as error messages, for languages other than English.
The method for adding the .NET Framework and .NET Framework language packs to your project depends on the project
type that you are using, as well as the version of .NET Framework that your product requires.
Note • Some .NET Framework versions include earlier .NET Framework versions:
• .NET Framework 3.5 includes .NET Framework 3.0 SP1 and .NET Framework 2.0 SP1.
• .NET 3.0 Framework SP1 includes .NET Framework 2.0 SP1.
• .NET 3.0 Framework RTM includes .NET Framework 2.0 RTM .
Note • This includes .NET Framework 4.5 Full, 4.5 Web, 4.0 Full, 4.0 Client, 3.5 SP1, 3.5, 3.0 SP1, 3.0, 2.0 SP2, 2.0 SP1, or 2.0 (only
x64, IA64) redistributables.
To test whether the .NET Framework is already installed on the target system, you can use the built-in
MsiNetAssemblySupport property. It is set to the version of a particular .NET DLL (fusion.dll) if the .NET Framework is
installed, and it is not set if the .NET Framework is not installed.
InstallScript Projects
InstallScript projects support two methods for adding the .NET Framework redistributables to your project:
• Use the Prerequisites view to add one or more .NET Framework prerequisites to your project.
• Use the Objects view to add the Microsoft .NET Framework object to your installation. This object also enables you to
add one or more language packs to an InstallScript project. To learn more, see Microsoft .NET Framework Object
Wizard.
To determine whether a particular version of the .NET Framework or a language pack is installed, use the Is function and
pass the DOTNETFRAMEWORKINSTALLED predefined constant.
See Also
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Including the Microsoft .NET Framework and Microsoft .NET Framework Language Pack
Prerequisites
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
InstallShield includes InstallShield prerequisites for some versions of the .NET Framework and the .NET Framework
language packs. You can include these InstallShield prerequisites in Basic MSI, InstallScript, and InstallScript MSI projects if
you want to redistribute these versions of the .NET Framework and the language packs.
Following is a list of the .NET Framework redistributables that are available as InstallShield prerequisites. The associated
language pack prerequisites are included if available.
• Microsoft .NET Framework 4.5. (One InstallShield prerequisite is for the full package, and one is for the Web package.
The Web package is smaller in size, but it requires an Internet connection on the target system at run time.)
• Microsoft .NET Framework 4 Full, which installs the .NET Framework runtime and associated files that are required to
run and develop applications that target the .NET Framework 4. (One InstallShield prerequisite is for the full package,
and one is for the Web Download package. The Web Download package is smaller in size, but it requires an Internet
connection on the target system at run time.)
• Microsoft .NET Framework 4 Client, which installs the .NET Framework runtime and associated files that are required
to run most client applications. (One InstallShield prerequisite is for the full package, and one is for the Web Download
package. The Web Download package is smaller in size, but it requires an Internet connection on the target system at
run time.)
• Microsoft .NET Framework 3.5 SP1 (One InstallShield prerequisite is for the full package, and one is for the Web
Download package. The Web Download package is smaller in size, but it requires an Internet connection on the target
system at run time.)
• Microsoft .NET Framework 3.5 (One InstallShield prerequisite is for the full package, and one is for the Web Download
package. The Web Download package is smaller in size, but it requires an Internet connection on the target system at
run time.)
• Microsoft .NET Framework 3.0 SP1 (This is a Web Download package, which requires an Internet connection on the
target system at run time.)
Tip • For information on other versions of the .NET Framework redistributables, see Adding .NET Framework Redistributables
to Projects.
These InstallShield prerequisite installations are run in silent mode. Therefore, the language in which the .NET Framework
installation runs is not an issue.
Since there currently is no way to install Windows Installer 3.x on 64-bit Itanium systems running Windows XP, and since
.NET Framework 2.0 and later require Windows Installer 3.x or later, the 64-bit .NET Framework 2.0 prerequisites cannot be
installed on 64-bit Itanium systems running Windows XP.
The InstallShield prerequisite installations determine if the corresponding version of the .NET Framework is already
installed on the target machine by checking the Install or InstallSuccess value data for a particular HKEY_LOCAL_MACHINE
key. For more details, you can open any InstallShield prerequisite in the InstallShield Prerequisite Editor and note the
conditions that are set.
See Also
Adding .NET Framework Redistributables to Projects
Modifying an Existing InstallShield Prerequisite
InstallShield Prerequisite Editor Reference
• Basic MSI
• InstallScript
• InstallScript MSI
You can include in your installation an InstallShield prerequisite that installs MySQL Connector/ODBC 3.51. It enables end
users to connect to a MySQL database server that uses ODBC. Before you can add this InstallShield prerequisite to your
projects, you must download the MySQL Connector/ODBC driver and configure the InstallShield prerequisite on your
system.
Task To add the MySQL Connector ODBC 3.51 prerequisite to your system so that you can add it to your projects:
1. Open Windows Explorer and browse for the InstallShield prerequisite template folder. The default location is:
C:\Program Files\InstallShield\2020\SetupPrerequisites\Templates
2. Copy the MySQL Connector ODBC 3.51.prq file that is in the Templates folder, and paste it in the InstallShield
prerequisite folder. The default location is:
C:\Program Files\InstallShield\2020\SetupPrerequisites
3. Visit http://dev.mysql.com/downloads/connector/odbc/3.51.html and download the MSI installer for the MySQL
Connector/ODBC 3.51 driver for Windows.
The next time that you launch InstallShield, the MySQL Connector ODBC prerequisite is available in the Redistributables
view.
If you want to change the location on your machine where you store the installer for the MySQL Connector/ODBC 3.51
driver, you can do so by opening the MySQL Connector ODBC 3.51.prq file in the InstallShield Prerequisite Editor and
modifying the settings. To open the InstallShield Prerequisite Editor, click Prerequisite Editor on the Tools menu. For more
information, see Specifying Files for an InstallShield Prerequisite.
See Also
Installing the MySQL ODBC Driver
Including the InstallShield Prerequisite for the Oracle 11g Instant Client
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
If you want to install the Oracle 11g Instant Client before your installation is run, you can include the Oracle 11g Instant
Client prerequisite in your project. Before you can add this InstallShield prerequisite to your projects, you must download
Oracle Instant Client and create an .msi package on your system. For more information, see Connecting to an Instance of
Oracle and Running SQL Scripts.
Note • If you want your installation to download the Oracle 11g Instant Client whenever it needs to be installed on a target
system, check with Oracle to ensure that it is allowed. If it is allowed, you must host the download on your own Web site and
add its download path to the InstallShield prerequisite. Revenera does not make this installation available for download.
See Also
Working with InstallShield Prerequisites that Are Included in Installation Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
DirectX provides supporting API libraries for multimedia applications and hardware, including the latest graphics cards. If
your product requires DirectX to be installed on the target system, you can add the DirectX object—either the Windows
Installer–based object for Basic MSI and InstallScript MSI projects, or the InstallScript object for InstallScript projects—to
your project. If the target system does not have DirectX, it is installed during your installation.
After installation, the DirectX runtime cannot be uninstalled. DirectX is a system component; end users cannot uninstall it
without reinstalling the operating system.
Tip • The DirectX object is not installed with InstallShield; you need to download it. To include the DirectX object in Basic MSI
or InstallScript MSI projects, obtain the MSI object download. To include the DirectX object in InstallScript projects, obtain the
InstallScript object download. To learn more, see Obtaining Updates for InstallShield.
Redistributable Files
The DirectX objects install all DirectX 9.0c core and optional components, including 32-bit- and 64-bit-specific components.
Including the DirectX Object in Basic MSI and InstallScript MSI Projects
When you add the DirectX object to a Basic MSI or InstallScript MSI project, InstallShield launches the DirectX Object
Wizard.
You can use the DirectX object in compressed or uncompressed installations; the DirectX Object Wizard lets you specify
whether the DirectX files should be in a folder in the Disk1 folder, or they should be streamed into the .msi file:
• If you specify that the files should be in a folder in the Disk1 folder, InstallShield creates a DirectX folder for your
installation at build time and places it in the Disk1 folder of your release. InstallShield lists the DirectX folder in the
Disk1 area of the Support Files view (in Basic MSI projects) or the Support Files/Billboards view (in InstallScript MSI
projects).
• If you specify that the files should not be in the Disk1 folder, InstallShield embeds the files in your installation’s .msi
file. InstallShield lists these files in the Language Independent area of the Support Files view (in Basic MSI projects) or
the Support Files/Billboards view (in InstallScript MSI projects).
Note • The custom action that launches the DirectX installation is sequenced in the Execute sequence and run in deferred
system context so that it can be run with elevated privileges on Windows Vista and later systems.
Updating the DirectX Object Files for Basic MSI and InstallScript MSI Projects
If you obtain updates for any of the DirectX files and you want to include them in your DirectX object, place them in the
appropriate InstallShield Program Files subfolder with the other DirectX files. The location is:
You can also remove files from that folder if your product does not require them and you do not need to include them in
your installation. For more information about the DirectX redistributable files, including details about any updates that
Microsoft may have released since the current version of InstallShield was released, see the latest DirectX SDK or
Microsoft’s MSDN Web site.
At build time, InstallShield uses whatever redistributable files are in that DirectX folder to build your release.
See Also
DirectX Object Wizard
• Basic MSI
• InstallScript
• InstallScript MSI
A file often relies on functions in other files to perform a task. However, you may not be aware of all these other files—
known as dependencies—when you include your application’s files in your installation project. InstallShield offers scanning
wizards to assist you in identifying and working with these files. You can access these scanners in the Dependency
Scanners view.
Scanner Description
Static Scanning Wizard Looks at portable executable files (for example, .exe, .ocx, .com, .tlb, .hlp, and
.chm) in your project and checks for dependencies that they may require.
Dynamic Scanning Wizard Monitors your system while an executable file is running and checks for .dll or .ocx
files that may be required by the executable file.
Any files that are added to a Basic MSI or InstallScript MSI project through one of these scanners are added in accordance
with Setup Best Practices.
If you use the Static and Dynamic scanning wizards, you can specify files that you want to be included or excluded
automatically any time that you perform a static or dynamic scan through InstallShield. For more information, see Filtering
Files in Dependency Scanners.
See Also
Reviewing Dependency Scanner Results
Scanning for 64-Bit Dependencies
Dependency Scanners
Opening InstallShield Projects in Microsoft Visual Studio
Static Scanning
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
The Static Scanning Wizard enables you to scan the files already added to your project for any dependencies that they may
require. This wizard scans all portable executable files (.exe, .dll, .ocx, .sys, .com, .drv, .scr, and .cpl files) in your project and
checks for dependencies that they may require. The 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.
The new files added to your project are added to the same feature as the file that depends upon them, thereby ensuring
that they are installed when needed.
Table 4-14 • Determining How the Static Scanning Wizard Scans Files in a Component
Value of a
Component’s .NET
Scan at Build Setting Description
None The Static Scanning Wizard does not scan the .NET portion of the component for
dependencies or properties. For example, if your component contains Notepad.exe and a
.NET assembly file, the Static Scanning Wizard scans Notepad.exe for dependencies and
does not scan the .NET assembly file for dependencies or properties.
Properties Only The Static Scanning Wizard scans the entire component—all files in the component,
including .NET assemblies—for properties, but it does not identify dependencies for the .NET
portion of the component. For example, if your component contains Notepad.exe and a .NET
assembly file, the Static Scanning Wizard scans both files for properties, but it does not
identify dependencies for the .NET assembly file.
Table 4-14 • Determining How the Static Scanning Wizard Scans Files in a Component (cont.)
Value of a
Component’s .NET
Scan at Build Setting Description
Dependencies and The Static Scanning Wizard scans the entire component—all files in the component,
Properties including .NET assemblies—for dependencies and properties. Any dependencies that are
found during the scan are presented in the File Selection panel. If any properties are found
for .NET files, InstallShield adds the properties to the .NET Assembly subnode under the
Assembly node in the Advanced Settings area of a component.
See Also
Static Scanning Wizard
Reviewing Dependency Scanner Results
Scanning for 64-Bit Dependencies
Dynamic Scanning
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
The Dynamic Scanning Wizard is an easy-to-use tool that monitors your system while an executable file runs. The wizard
displays a list of .dll and .ocx files that may be required by the executable file, and it lets you specify whether you want to
include each one in your project.
The executable file you want to scan can already be included to your project, or it can be added by the wizard.
See Also
Reviewing Dependency Scanner Results
Scanning for 64-Bit Dependencies
• Basic MSI
• InstallScript
• InstallScript MSI
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, the
Static Scanning Wizard and the Dynamic Scanning Wizard can scan for 64-bit dependencies of the 64-bit files in your
project. These wizards can also scan for 32-bit dependencies of the 32-bit files in your project.
Note that if you use InstallShield on a 32-bit version of Windows, these wizards can scan 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.
See Also
Reviewing Dependency Scanner Results
Dependency Scanners
• Basic MSI
• InstallScript
• InstallScript MSI
The Static Scanning Wizard and the Dynamic Scanning Wizard scan your project to help you identify other files that your
product may require. Each of these wizards displays a list of possible files and merge modules that you may need to add to
your project. Review the scan results carefully, and determine whether it is appropriate to add each specified file and
merge module to your project.
Both of the scanners works differently to identify dependencies. In some cases, one of the scanners may identify a
dependency that the other does not identify. Therefore, you may want to try using both the static and dynamic scanning
wizards for a more complete list of potential dependencies. In some scenarios, a dependency scanner may identify as a
dependency a file or merge module that is not required by your product. If that occurs, you can exclude that file or merge
module, since the wizards let you include or exclude each identified dependency as needed. In addition, InstallShield
enables you to specify on a machine-wide basis any files that you want to be included or excluded automatically any time
that you perform a static or dynamic scan through InstallShield. For more information, see Filtering Files in Dependency
Scanners.
To obtain the best results when you are trying to identify dependencies, it is recommended that you thoroughly test your
product and its installation on a clean machine. If your product does not behave as expected, determine whether any
dependencies are missing from the machine, and if so, whether they should be included in the installation.
See Also
Scanning for 64-Bit Dependencies
When you run the Static and Dynamic scanning wizards, you may find that they list as dependencies certain files that you
do not want added to your installation. To avoid having these files added every time you run the scanner, you can edit
Filters.xml. This file enables you to specify any files that you want the scanners to ignore or include.
The file must remain in this location after you edit it; otherwise, the scanners will not work properly.
Tip • You can also use the Filters.xml file to control which registry items should be excluded during COM extraction. For
more information, see Filtering Registry Changes for COM Extraction.
The Filters.xml file also lets you control which IIS settings should be excluded when you are importing an IIS Web site. For
more information, see Filtering IIS Data When Importing a Web Site and Its Settings into an InstallShield Project.
Excluding Files
The <Exclude> element in the Filters.xml file is where you add subelements for each of the files that you want the
scanners to exclude. Any files that are listed here will not be added to your installation project by the scanners.
By default, the <Exclude> element has subelements for common system files that are present on all Windows–based
machines.
Including Files
The <Include> element in the Filters.xml file gives you the ability to override individual files that are subelements of the
<Exclude> element. Any files that are listed in subelements of the <Include> element will be added to your installation
project by the scanners, even if the files are also listed in subelements of the <Exclude> element.
Note • The following vital operating system files are never recognized by the scanner, even if you add them as subelements of
the <Include> element:
• kernel32.dll
• ntdll.dll
• user32.dll
• gdi32.dll
• advapi32.dll
• shell32.dll
• ole32.dll
Attribute Description
name This attribute must be lowercase. The value of this attribute (for example, myfile.dll in the above
example) indicates the name of the file that you want to include or exclude.
path This attribute is optional. The value of this attribute (for example, [SystemFolder] in the above
example) indicates the path of the file.
Any other attributes are optional and are not recognized by the scanners. You may want to add additional attributes—such
as the We attribute in the example above and the corresponding "needthis" value—to identify why an item is being
excluded or included.
Important • Ensure that your XML code is well formed; if its not well formed, all of the filters fail. In most cases, you can
identify improperly formed XML code by opening the Filters.xml file in Internet Explorer. You should be able to expand and
contract the <Filters>, <Include>, and <Exclude> elements; if you cannot, check the code for errors.
If you add subelements to the <Exclude> or <Include> elements, be sure that you do not place them within the commented-out
section, since InstallShield ignores that area of the Filters.xml file.
The following sample XML code shows the format of the Filters.xml file:
<Filters>
<Include>
<!--Instructions on how to add files to this element.
-->
<File name="mfc42.dll" We="needthis"/>
</Include>
<Exclude>
<!--Instructions on how to add files to this element.
-->
<Registry key="HKEY_CLASSES_ROOT\Interface\{00020404-0000-0000-C000-000000000046}"/>
<File name="12520437.cpx" path="[SystemFolder]" wrp="4.0-10.0" />
<File name="12520850.cpx" path="[SystemFolder]" wrp="4.0-10.0" />
</Exclude>
</Filters>
See Also
Reviewing Dependency Scanner Results
Dependency Scanners
Static Scanning Wizard
Dynamic Scanning Wizard
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
Most applications require certain COM servers in order to operate properly. In order for the operating system to recognize
these COM servers, you need to register them.
With traditional COM, COM data is written directly to the registry. Registry-free COM, or Reg-Free COM, offers a simple
alternative to the traditional method. With Reg-Free COM, COM data is written to an application manifest file.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
InstallShield supports multiple methods for registering a COM server on a target machine. The following methods are the
ones used traditionally:
• The COM information can be extracted from the file at build time (or design time) and written to the COM-related
tables of your .msi database.
The first method listed—extracting the COM information and writing it to the .msi database—is preferred over the self-
registration method. The first method writes the COM class information to the Class, ProgID, and Registry tables of the
.msi database.
Not all COM servers support self-registration. Although it is likely that you will know which files in your installation are self-
registering, there may be times when you do not know. Because you must handle self-registering files differently than non-
self-registering files, you need to be able to determine if a file is self-registering.
In most cases, you can determine whether a file is self-registering if you add it to an InstallShield project. InstallShield tests
COM server files when they are added to a project to determine if they are self-registering files. If InstallShield determines
that a COM server added to your project is self-registering:
• For Windows Installer–based projects: InstallShield sets the COM Extract at Build property of the file’s component to
Yes (if you have specified on the Preferences tab of the Options dialog box that COM extraction should occur at build
time).
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
Note that for MSI Database and MSM Database projects, COM information cannot be extracted at build time; it is extracted at
design time.
The recommended method for registering COM servers is to use Windows Installer tables in the .msi database to make the
necessary registry entries for your COM server. With this method, Windows Installer is capable of registering files when they
are advertised, and it can safely roll back the registration information in case of a failed installation.
Since each component should have only one portable executable file, the assumption is that all of the registration
information belongs to a single file, marked as the key file of its component.
InstallShield supports several methods for extracting COM information from a COM server:
• Use the Component Wizard. You can use this wizard to create a new COM server component. With this method, the
wizard performs a one-time scan of COM information from the component’s key file.
• For a component’s COM Extract at Build setting, select Yes. Since InstallShield extracts the COM data every time that
you build a release, this method is helpful if your COM server’s interfaces change frequently. The COM server must be
the key file of its component for this method.
• Extract the information by right-clicking the file in the Files and Folders view and then clicking Extract COM Data for
Key File. Use this method if you have already added the COM server file to a component.
As an alternative to having InstallShield extract the COM data, you can manually add COM information to a component in
the component’s Advanced Settings.
If you do not want InstallShield to extract COM information every time that you build a release, select No for the COM
Extract at Build setting of the component. Use this method if you want InstallShield to register the file according to the
information that is statically contained in the component’s COM Registration advanced setting. This advanced setting
stores information about the file’s COM classes, ProgIDs, and so on, that were either extracted in the Component Wizard or
entered manually in the Advanced Setting area.
When InstallShield extracts COM information from a COM server, the COM class information is written to the Class,
ProgId, and Registry tables of the .msi database.
If you are using InstallShield on a 64-bit operating system, InstallShield can extract COM data from a 64-bit COM server. In
order to install the data to the correct locations, the component must be marked as 64 bit. To learn more about 64-bit
support, see Targeting 64-Bit Operating Systems.
InstallShield employs a special technique to find all COM information on a COM server without actually registering it.
Therefore, COM extraction does not affect the system registry. However, some COM servers’ registration processes depend
on existing registry entry values. Although InstallShield has developed an algorithm to avoid this scenario, it may not be
foolproof in some extreme cases.
Caution • Some applications, like WinRunner, insert hook .dll files into the COM extraction engine. This causes COM
extraction to fail and displays the following message: "ISRegSpy detects following module %1 hooked into this process, which
causes ISRegSpy to malfunction. You need to shut the application down and restart COM extraction." If you encounter this
message, shut down the application and restart COM extraction, as the dialog box instructs.
Do not select the self-registering property for .exe files that are not self-registering. To self-register an .exe file, you need to
launch the .exe file with the /regserver command. However, if the .exe file does not support the command line switch, the .exe
file will be launched during extraction at build time.
Note • The definitions of the COM-related Windows Installer tables prevent a COM server from being placed in more than one
feature. If a COM server needs to be placed in more than one feature, the following are two available options:
• Make the second feature that requires the COM server a child of the first, and place the file in the parent feature.
• Use self-registration on the COM server instead of using the COM-related Windows Installer database tables.
See Also
Setup Best Practices
Setting Component Key Files
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
To prevent InstallShield from extracting undesired COM data from a COM server (either at build or design time), you can
edit the Filters.xml file and specify the registry keys to be excluded. Filters.xml is in the following location:
The file must remain in this location after you edit it; otherwise, COM extraction will not work properly.
Tip • You can also use the Filters.xml file to control which files should be included or excluded during dependency
scanning. For more information, see Filtering Files in Dependency Scanners.
The Filters.xml file also lets you control which IIS settings should be excluded when you are importing an IIS Web site. For
more information, see Filtering IIS Data When Importing a Web Site and Its Settings into an InstallShield Project.
By default, the <Exclude> element has subelements for common system registry keys that are required.
Following is a sample of a properly formatted registry subelement that blocks changes to an InprocServer32 registry key,
all of its values, and all of its subkeys:
<Registry key="HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000231-0000-0010-8000-
00AA006D2EA4}\InprocServer32"/>
Following is a sample of a properly formatted registry subelement that blocks changes to only the default value of an
InprocServer32 registry key:
<Registry key="HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000231-0000-0010-8000-
00AA006D2EA4}\InprocServer32" value=""/>
Following is a sample of a properly formatted registry subelement that blocks changes to only the ThreadingModel value
name for an InprocServer32 registry key:
<Registry key="HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000231-0000-0010-8000-
00AA006D2EA4}\InprocServer32" value="ThreadingModel"/>
Attribute Description
key This attribute must be lowercase. The value of this attribute (for example,
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{00000231-0000-0010-8000-
00AA006D2EA4}\InprocServer32 in the above examples) indicates the name of the registry key that
you want to filter.
• To block changes to an entire registry key, do not include the value attribute.
• To block changes to the default value of the specified key, set the value of this attribute to a null
value.
• To block changes to the name of a value of the specified key, set the value of this attribute to the
name of that registry value.
Any other attributes for the <Registry> subelement are optional and are not recognized by the COM extraction process. You
may want to add additional attributes to identify why an item is being excluded.
Important • Ensure that your XML code is well formed; if its not well formed, all of the filters fail. In most cases, you can
identify improperly formed XML code by opening the Filters.xml file in Internet Explorer. You should be able to expand and
contract the <Filters>, <Include>, and <Exclude> elements; if you cannot, check the code for errors.
If you add subelements to the <Exclude> or <Include> elements, be sure that you do not place them within the commented-out
section, since InstallShield ignores that area of the Filters.xml file.
The following sample XML code shows the format of the Filters.xml file:
<Filters>
<Include>
<!--Instructions on how to add files to this element.
-->
</Include>
<Exclude>
<!--Instructions on how to add files to this element.
-->
<Registry key="HKEY_CLASSES_ROOT\Interface\{00020404-0000-0000-C000-000000000046}"/>
<File name="12520437.cpx" path="[SystemFolder]" wrp="4.0-10.0" />
<File name="12520850.cpx" path="[SystemFolder]" wrp="4.0-10.0" />
</Exclude>
</Filters>
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
If you have a COM server that is self-registering, you can call the COM server’s self-registration functions at installation time
to register the COM server on the target machine.
InstallShield supports different methods for indicating that a COM-related file (.ocx, .dll, .exe, .tlb, or .olb) is self-registering:
• You can specify that a particular file is self-registering. For more information, see File Properties Dialog Box.
• You can specify that a dynamic link is self-registering. For more information, see Dynamic File Link Settings Dialog
Box.
Tip • If the self-registering file is part of a 64-bit component, 64-bit self-registration occurs on the target machine. For more
information, see Targeting 64-Bit Operating Systems.
When you mark a COM server .dll or .ocx file as self-registering, the file’s own registration function (DllRegisterServer) is
called during installation to register it with the target system, and its unregistration function (DllUnregisterServer) is
called during uninstallation to unregister the file.
• Because DllRegisterServer is .dll code, its effects cannot reliably be rolled back during a failed installation.
• Self-registration may require COM servers to be registered in a particular order. InstallShield self-registration
(ISSelfReg) enables you to overcome this limitation.
• DllRegisterServer generally does not register a file with a relative path, as needed by systems that support side-by-
side sharing.
In addition, if you use any type of self-registration in a patch, the patch will not be uninstallable.
When you mark one or more files as self-registering, InstallShield adds data to a table of your .msi database, and adds
some custom actions related to self-registration to your installation Execute sequence. For details, see Self-Registration
Methods and InstallShield Self-Registration (ISSelfReg).
Per-machine self-registration information is stored in the registry key HKLM\SOFTWARE\Classes\CLSID, and per-user self-
registration information is stored in HKCU\SOFTWARE\Classes\CLSID; a merged view of the data is available under
HKCR\CLSID.
See Also
Determining Whether a COM Server Supports Self-Registration
Self-Registration Methods
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
On the Preferences tab of the Options dialog box, you can select whether you want to use the InstallShield self-registration
method (ISSelfReg) or the Windows Installer self-registration method (SelfReg).
Note • If you use any type of self-registration in a patch, the patch will not be uninstallable.
• Can register 64-bit files if the self-registering file is part of a 64-bit component.
InstallShield Self-Registration
InstallShield self-registration does the following:
• Uses batch mode registration to handle any registration dependencies at run time.
• Can register 64-bit files if the self-registering file is part of a 64-bit component.
Note • With InstallShield self-registration, you can specify the order in which the files are registered at run time. You can set
the order in the ISSelfReg table (Order column) in the Direct Editor.
See Also
Direct Editor
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
If you have selected ISSelfReg as the self-registration method for COM servers, and if your project contains any files (or
dynamic links) marked as self-registered, InstallShield adds information about those files to the ISSelfReg table of your
.msi database. You can view and edit the ISSelfReg table in the Direct Editor. To learn about the fields in this table, see
ISSelfReg Table.
In addition, if your project contains any files (or dynamic links) marked as self-registered, InstallShield adds the following
custom actions to the Execute sequence of your installation.
Table 4-17 • Custom Actions Added to Projects that Have Self-Registering COM Servers
Action Description
ISSelfRegisterCosting Immediate-execution action that reads the ISSelfReg table and determines which
files need to be registered or unregistered. A file will be registered when its
component is scheduled to be installed, and unregistered when its component is
scheduled to be uninstalled.
ISUnSelfRegisterFiles Deferred-execution custom action that unregisters each file whose component is
scheduled to be removed.
ISSelfRegisterFiles Deferred-execution custom action that registers each file whose component is
scheduled to be installed.
See Also
Direct Editor
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
With Reg-Free COM, COM data is written to an application manifest file that is stored in the application folder. The manifest
file is an XML file that contains information about an application and the libraries that are associated with it. Note that the
Reg-Free COM manifest file, the executable file, and the COM libraries should all be installed to the same folder on the
target machine.
Problems may occur with traditional COM registration if multiple versions of shared libraries exist on a target system. For
example, an installation may overwrite a new version of a shared library with an older version, or a new version might not
be backwardly compatible with older versions. This may cause applications that require features of a specific version to
crash. These types of situations are commonly known as DLL Hell. With Reg-Free COM, you can avoid these problems
because other applications cannot access your application’s COM component.
In addition, Reg-Free COM streamlines the upgrade and uninstallation processes. For an upgrade, simply replace the
application folder. For an uninstallation, simply remove that folder.
• A component is not suitable for Reg-Free COM if it is a system component or part of the operating system. In addition,
it is not suitable if it is a data access component such as Microsoft Data Access Components (MDAC). These types of
components should not be isolated.
• A COM component can be isolated only once per application. Consider grouping COM components in a single class
library as a workaround to this limitation.
See Also
Reg-Free COM Wizard
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
Use the Reg-Free COM Wizard to create and modify Reg-Free COM manifest files to be included in your installation. Before
you use the Reg-Free COM Wizard, you should add the COM libraries (.dll and .ocx files) and the executable file that uses
them to your InstallShield project.
The wizard extracts COM information from the libraries that you specify and adds them to the application manifest files. It
also creates a new component with the manifest file set as the key file. The manifest component has the same destination
and condition as the associated executable-file component.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The contents of the manifest file include the name of the executable file, the file names of the libraries that are associated
with the executable files, and the COM information. For the following sample manifest file, the name of the executable file
is Sample.exe, and the name of the library is SampleCircle.dll.
On a Windows XP system, the presence of the manifest file enables the application to use methods from the COM library
without the libraries having been registered in the target system’s registry. Windows XP uses the COM libraries in the
current directory before using any other versions of the libraries that may be registered on the target system.
A developer installation manifest (DIM) 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. DIM projects enables release engineers to efficiently reuse functional portions of an installation.
Working with DIMs also enables multiple developers to contribute to the development of the installation simultaneously.
Each software developer can work on a separate DIM that the release engineer can reference in one or more installation
projects.
This section of the documentation explains how to include a DIM project in a Basic MSI installation project. It also offers
guidance on how to work with a Basic MSI project that includes one or more DIMs.
Tip • To learn how to create a DIM project, see Modularizing Installation Projects to Distribute Development Work and Enable
Reuse.
A developer installation manifest (DIM) 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. 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. 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.
Using DIM references in Basic MSI projects enables multiple software developers to contribute to the development of
the installation simultaneously. Each software developer can work on a separate DIM that the release engineer can
reference in one or more installation projects.
If you want to modify any portion of a DIM project, open the DIM project in InstallShield, make the required changes,
and then rebuild any Basic MSI projects that reference that DIM.
• By import—You can import a DIM project into your Basic MSI project. This method is a one-time, irreversible import
that merges the DIM data into the Basic MSI project at design time.
Any further changes that need to be made to the DIM data are made from within the Basic MSI project. Modifying the
original DIM project does not modify the corresponding data in the Basic MSI project.
You may want to import a DIM project to troubleshoot problems with a product or its installation. When you are
importing a DIM project, you have the option to back up your Basic MSI project (.ism) before the import; this option
enables you to revert back to the base Basic MSI project without the imported DIM project.
DIM projects enables developers and release engineers to reuse functional portions of an installation efficiently.
See Also
Modularizing Installation Projects to Distribute Development Work and Enable Reuse
When you add a reference for a DIM project to your Basic MSI project, 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.
Task To add a reference for a DIM to a specific feature in a Basic MSI project:
2. In the Setup Design explorer, right-click the feature that you want to contain the DIM reference, and then click Add
DIM Reference. The Open dialog box opens.
3. Browse to the DIM project file (.dim) that you want to reference, and then select that file.
InstallShield adds to the appropriate feature a component node for each component in the DIM project.
Tip • You can also use the DIM References view to add a reference for a DIM to your Basic MSI project. In this view, right-click
the DIMs explorer and then click Add DIM Reference. When you add a reference through this method, the DIM is not associated
with any features in the Basic MSI project. To learn how to set up the association, see Associating a DIM Reference with a
Feature. Each referenced DIM must be associated with a feature in the Basic MSI project; otherwise, InstallShield does not
include it in the Basic MSI installation that it generates at build time.
See Also
Importing a DIM into a Project
When you are including a DIM reference in a Basic MSI project, the DIM reference must be associated with at least one
feature; otherwise, InstallShield does not include it in the Basic MSI installation that it generates at build time.
You can associate a DIM reference with one or more features through the DIM References view or the Setup Design view of
the Basic MSI project.
Task To use the DIM References view of a Basic MSI project to associate a DIM reference with a feature:
2. In the DIMs explorer, select the DIM that you want to configure.
4. Select the check box of each feature that you want to contain the selected DIM. Clear the check box of each feature
that should not contain the selected DIM.
Task To use the Setup Design view of a Basic MSI project to associate a DIM reference with a feature:
2. In the Setup Design explorer, right-click the feature that you want to contain the DIM reference, and then click
Associate DIM References. The Associate DIM References dialog box opens; it lists all of the DIM references that are
not associated with a feature in the Basic MSI project.
3. Select each DIM that you want to associate with the selected feature, and then click OK.
See Also
Referencing a DIM in a Project
Resolving Build-Time Conflicts Between a Basic MSI Project and a DIM Reference
InstallShield 2020
When you build a Basic MSI release that contains a DIM reference, InstallShield merges the DIM data into the Basic MSI
release that it generates. If data conflicts exist, InstallShield needs to determine which data takes precedence: the values in
the DIM project or those in the Basic MSI project.
InstallShield lets you specify how you want to resolve conflicts between settings in a DIM project with those in a Basic MSI
project that contains a reference to that DIM. Following are examples of different types of conflicts that may occur:
• Both projects contain a property that has the same name but different values.
• Both projects contain a string entry that has the same string identifier but different values for a particular language.
• Both projects contain a path variable that contains the same name but different values.
• Both projects contain a component that has the same name but different values for one or more of its settings.
In most cases, conflicts do not occur, since InstallShield automatically includes a DIM project–specific GUID in the names of
items such as properties, string entries, path variables, and components when you create these in a DIM project, but not in
a Basic MSI project. If you create a property called MYPROPERTY in a Basic MSI project, the property is called MYPROPERTY. If
you create a property called MYPROPERTY in a DIM project, InstallShield internally calls the property MYPROPERTY.DIM_GUID,
where DIM_GUID is the identifier that is defined in the DIM GUID setting of the General Information view of the DIM project.
Thus, the name of the property in the DIM becomes, for example,
MYPROPERTY.8356F8B7_8DE5_4E04_A77A_6FA722CBE1CC. For this particular example, you can use the Direct Editor to
see the internal name of the property in the Property table of the DIM project.
Task To indicate how you want InstallShield to resolve conflicts between a Basic MSI project and one of its DIM references:
2. In the DIMs explorer, select the DIM that you want to configure.
4. For the Conflict Resolution setting, select the appropriate value. Available options are:
• Use Base Project Value—If InstallShield encounters a conflict when merging the DIM data into the Basic MSI
installation at build time, InstallShield uses the value that is in the Basic MSI project instead of the value that is in
the DIM project.
• Use DIM Project Value—If InstallShield encounters a conflict when merging the DIM data into the Basic MSI
installation at build time, InstallShield uses the value that is in the DIM project instead of the value that is in the
Basic MSI project.
One possible but unlikely scenario for encountering conflicts is if you import a DIM into a Basic MSI project, modify an item
in the DIM project, and then try to add a reference to the same DIM in the Basic MSI project. In this scenario, InstallShield
overrides the value of the DIM setting or the value of the Basic MSI setting, depending on how you have the Conflict
Resolution setting configured, to avoid a conflict.
See Also
Referencing a DIM in a Project
Identifying DIM Elements in an Installation Project
If you add a DIM reference to a Basic MSI project, it is recommended that you check to see whether the author of the DIM
included any build instructions that indicate guidance, tips, or other comments that may help you determine whether
additional steps may be required for the specific DIM.
Task To view build instructions for a DIM reference in a Basic MSI project:
1. Open the Basic MSI project that contains the DIM reference.
3. In the DIMs explorer, select the DIM that you want to configure.
On the Instructions tab, InstallShield displays any comments that the author of the DIM project entered when creating or
editing it.
If you create a DIM project, you have the ability to specify the default location on target systems for the files in the DIM
project. The location is typically the value of the property INSTALLDIR or a subfolder of that folder. When you add a DIM
reference to a Basic MSI project, you can choose to use the destination location that the author of the DIM project
configured, or you can override the location and specify a different location.
Task To view the default destination that is specified for a DIM reference’s files and override it if appropriate in a Basic MSI
project:
1. Open the Basic MSI project that contains the DIM reference.
3. In the DIMs explorer, select the DIM that you want to configure.
4. Click the Build Options tab. The Destination setting shows the value that author of the DIM project configured.
Instead of hard-coding a path, you can enter a directory property as part of the path. To select a directory property,
click the ellipsis button (...) in this setting. This enables you to select the appropriate directory from a list, or to create
a new directory within a predefined directory. Separate further levels of subdirectories with a backslash—for example,
[ProgramFilesFolder]MyApp\Bin.
Note that it is also possible to override destinations at the feature and component levels. For more information, see Setting
the Default Product Destination Folder (INSTALLDIR).
See Also
Viewing Build Instructions for a DIM Reference
If you create a DIM project, you have the ability to create custom actions and dialogs. When you add a DIM reference to a
Basic MSI project, you can schedule when you want the custom actions in that DIM to be run during the Basic MSI
installation. You can also specify when during the Basic MSI installation the dialogs in that DIM should be run.
Task To insert custom actions and dialogs from a DIM reference into a Basic MSI project:
1. Open the Basic MSI project that contains the DIM reference.
3. In the DIMs explorer, select the DIM that you want to configure.
5. In the Sequences explorer, right-click the action or dialog that you want your action to follow and click Insert. The
Insert Action dialog box opens, providing a list of all the actions and dialogs that can be added to the sequence.
6. In the list at the top of the dialog box, select the type of action that you want to insert.
7. In the box that shows a list of actions, select the action that you want to insert.
8. Click OK.
See Also
Viewing Build Instructions for a DIM Reference
If you are modifying a Basic MSI project that contains one or more DIM references and you want to edit the DIM project or
see detailed information about it, you can open that project with the click of a link. Note that you must be able to access
the DIM project from the machine on which you are modifying the Basic MSI project.
Task To open a referenced DIM project from within a Basic MSI project:
2. In the DIMs explorer, select the DIM that you want to open.
A new instance of InstallShield launches, and the DIM project opens within InstallShield.
See Also
Viewing Build Instructions for a DIM Reference
When you import a DIM project into a Basic MSI project, InstallShield merges the DIM data into the Basic MSI project. The
import is a one-time, irreversible action.
You may want to import a DIM project to troubleshoot problems with a product or its installation. When you are importing
a DIM project, you have the option to back up your Basic MSI project (.ism) before the import; this option enables you to
revert back to the base Basic MSI project without the imported DIM project.
2. In the Setup Design explorer, right-click the feature that you want to contain the DIM, and then click Import DIM
Wizard. The Import DIM Wizard dialog box opens.
See Also
Import DIM Wizard
Resolving Design-Time Conflicts While Importing a DIM Into a Basic MSI Project
InstallShield 2020
When you import a DIM project into an installation project, InstallShield merges the DIM data into the installation project. If
data conflicts exist, InstallShield needs to determine which data takes precedence: the values in the DIM project or those in
the Basic MSI project.
InstallShield lets you specify how you want to resolve conflicts between settings in the two projects when you are
importing. Following are examples of different types of conflicts that may occur:
• Both projects contain a property that has the same name but different values.
• Both projects contain a string entry that has the same string identifier but different values for a particular language.
• Both projects contain a path variable that contains the same name but different values.
• Both projects contain a component that has the same name but different values for one or more of its settings.
If InstallShield encounters a conflict when importing a DIM project, the Resolve Conflict dialog box opens. This dialog box is
where you specify how you want to proceed. To learn more, see Resolve Conflict Dialog Box.
In most cases, conflicts do not occur, since InstallShield automatically includes a DIM project–specific GUID in the names of
items such as properties, string entries, path variables, and components when you create these in a DIM project, but not in
a Basic MSI project. If you create a property called MYPROPERTY in a Basic MSI project, the property is called MYPROPERTY. If
you create a property called MYPROPERTY in a DIM project, InstallShield internally calls the property MYPROPERTY.DIM_GUID,
where DIM_GUID is the identifier that is defined in the DIM GUID setting of the General Information view of the DIM project.
Thus, the name of the property in the DIM becomes, for example,
MYPROPERTY.8356F8B7_8DE5_4E04_A77A_6FA722CBE1CC. For this particular example, you can use the Direct Editor to
see the internal name of the property in the Property table of the DIM project.
See Also
Importing a DIM into a Project
Import DIM Wizard
When you create a DIM project in InstallShield, InstallShield assigns the project a GUID. This GUID helps to differentiate
separate DIM projects. InstallShield also includes this GUID throughout various areas of the DIM project and any Basic MSI
project that contains the DIM to identify the data as originating in the DIM.
For example, if you include a file called MyFile.exe in a DIM project that has a GUID of
8356F8B7_8DE5_4E04_A77A_6FA722CBE1CC, InstallShield writes the following value for this file in the File table of the
DIM project:
MyFile.exe.8356F8B7_8DE5_4E04_A77A_6FA722CBE1CC
If you include that same MyFile.exe source file in a different DIM project, InstallShield would append a different GUID to
the end of the file’s File table entry. If you import the DIM project into a Basic MSI project, InstallShield also imports this
file-GUID entry into the File table of a Basic MSI project. If you add MyFile.exe directly to a Basic MSI project, InstallShield
does not append a GUID to the end of the file name. If you import the DIM that contains MyFile.exe into a Basic MSI project,
you will see the
InstallShield uses the DIM GUID for files, components, path variables, and other types of installation data. This helps to
make it easy to identify which parts of a Basic MSI project are included directly in the Basic MSI project, and which originate
from various DIM projects that are referenced in or imported into the Basic MSI project.
The use of GUIDs also helps prevent conflicts. For example, if you use different values for a specific path variable in multiple
DIM projects, import those DIMs into a Basic MSI project that uses another different value for the path variable, you will not
encounter any conflicts. InstallShield uses the appropriate values for each path variable instance when building your Basic
MSI installation.
See Also
Resolving Build-Time Conflicts Between a Basic MSI Project and a DIM Reference
Resolving Design-Time Conflicts While Importing a DIM Into a Basic MSI Project
Depending on how the author of a DIM project defined the project’s path variables, it may be necessary for you to override
their values when you build a Basic MSI release that includes that DIM. Otherwise, when you build the installation, you may
encounter errors because of missing files, or the wrong files may be included in your build.
InstallShield offers several ways for overriding the path variables in a DIM project:
• If you are building a Basic MSI release and you want to override a path variable for a DIM that was imported into the
Basic MSI project, you can use the Path Variable Overrides setting on the Build tab in the Releases view.
• If you are building from the command line with ISCmdBld.exe, use the -l parameter to specify a path variable name
and new value. Use this method if you are building an installation for a Basic MSI project that contains one or more
DIMs.
• If you are building through MSBuild or Team Foundation Server (TFS), use the PathVariables parameter on the
InstallShield task. This parameter is exposed as the ItemGroup InstallShieldPathVariableOverrides when the default
targets file is used.
• You can open the DIM project and update values of path variables as needed. To learn how to open the DIM project
from within an open Basic MSI project, see Opening a Referenced DIM Project from Within an Installation Project.
At build time, InstallShield (or the Standalone Build) uses the path variable overrides that you set when obtaining the
source files for your project and building the release.
For more information as well as tips on using path variables in DIM projects, see Using Path Variables in a DIM.
See Also
Using Path Variables
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
Every installation changes the target system in some way. The simplest installations might only copy files. More in-depth
installations make registry changes, edit .ini files, create shortcuts, configure ODBC resources, use environment variables,
modify XML files, modify text files, schedule tasks, and install and control Windows services. For more information on how
to configure the target system, refer to this section of the documentation.
See Also
Shortcuts View
Registry View
INI File Changes View
ODBC Resources View
Environment Variables View
XML File Changes View
Text File Changes View
Scheduled Tasks View
Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
You can create shortcuts and program folders on the Windows desktop and on the Start menu by using the Shortcuts
explorer in the Shortcuts view. Like files, shortcuts are associated with components. In installation projects, they are
created on the target system only if the feature to which the component belongs is selected for installation.
See Also
Shortcuts View
Types of Shortcuts
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
New Shortcut Basic MSI, DIM, Creates a new shortcut to a file that exists in your project.
InstallScript,
InstallScript MSI,
Merge Module, MSI Note • This option is disabled when there is no file specified for a
Database, MSM component.
Database,
Transform
New Advertised Shortcut Basic MSI, DIM, Creates an advertised shortcut. The component’s files are not
InstallScript MSI, installed to the target system until the end user launches the
Merge Module, MSI shortcut.
Database, MSM
Database,
Transform
New Internet Shortcut InstallScript Creates an Internet shortcut (one whose Internet Shortcut setting is
set to Yes) with a default value of http://
www.YourCompanyName.com for the Target setting; change this
value to the desired URL.
New Shortcut to Basic MSI, DIM, Creates a shortcut to a file that already exists on the target system.
Preexisting File InstallScript,
InstallScript MSI,
Merge Module, MSI
Database, MSM
Database,
Transform
New Folder Basic MSI, DIM, Creates a program folder. You can create a program folder if you
InstallScript, want your shortcut to appear under your company name, for
InstallScript MSI, example.
Merge Module, MSI
Database, MSM
Database,
Transform
Creating Shortcuts
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
Before you create a shortcut, you should create at least one feature and component. If you have not created a component
when you create your first shortcut, InstallShield creates a component for you. You can change the component to which
the shortcut belongs by configuring the shortcut’s Component setting.
2. In the Shortcuts explorer, right-click one of the destination directories and then click the appropriate command. For a
list of available commands, see Types of Shortcuts.
InstallShield adds a new shortcut with the default name NewShortcutN (where N is a successive number).
3. Enter a new name, or right-click it later and click Rename to give it a new name.
For details about each of the settings that you can configure for shortcuts and folders, see:
• Shortcut Settings
• Folder Settings
Note • You can create a program folder if you want your shortcut to appear under your company name, for example. When
you have created a folder for your shortcut, you can create the shortcut by right-clicking your new folder and then clicking New
Shortcut.
You cannot create shortcuts to a dynamically linked file. For more information, see Limitations of Dynamic File Linking.
Tip • You can also use the Components view or—in installation projects only—the Setup Design view to create a shortcut. If
you use either the Components view or the Setup Design view, click the Shortcuts item in the explorer; a separate Shortcuts
explorer opens in a new pane.
See Also
Shortcuts View
Specifying the Icon for a Shortcut
Creating Shortcuts and Program Folders
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
When you have created a shortcut, you need to configure its settings. Shortcut settings enable you to link your shortcut to
a file, provide a description of the shortcut, or pass arguments.
2. In the Shortcuts explorer, click the shortcut. The shortcut’s settings are displayed in the right pane.
For details about each of the settings that you can configure for shortcuts and folders, see:
• Shortcut Settings
• Folder Settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield enables you to specify the icon that should be used for a shortcut that is created on the target system at run
time.
2. In the Shortcuts explorer, click the shortcut whose icon you want to specify. The shortcut’s settings are displayed in
the right pane.
3. In the Icon File setting, specify the file that contains the icon for the shortcut that you are creating. You must specify
an .ico file or the executable file (.dll or .exe) that contains the icon resource.
For Basic MSI, InstallScript MSI, or Merge Module projects: You can either type the fully qualified path to the file
that contains the icon, or click the ellipsis (...) button to browse to it.
For InstallScript projects: Type the fully qualified path to the file on the target system that contains the icon.
4. If the icon file that you specify contains more than one icon resource, enter the index in the Icon Index setting.
A nonnegative integer refers to the order of the icon resources in the executable file. For example, 0 refers to the first
icon in the file, 1 refers to the second icon, and 2 refers to the third icon.
InstallShield changes the icon that is displayed for the shortcut in the Shortcuts explorer to the one that you specified,
unless either of the following conditions is true:
For both of the aforementioned conditions, the icon file is not known until run time. Therefore, InstallShield shows the
following icon for each shortcut in the Shortcuts explorer, instead of displaying the icon that is used at run time on target
systems.
InstallShield also uses this icon for a shortcut in the Shortcuts explorer if the file that is selected in the Icon File setting does
not contain an icon.
Project • For Basic MSI, InstallScript MSI, and Merge Module projects: Since Windows Installer requires a separate icon when
the component is advertised, InstallShield extracts the icon from any executable file that you specify.
Tip • For Basic MSI, InstallScript MSI, and merge module projects: You can also right-click the icon in the Shortcuts view and
then click Change Shortcut icon to specify a different shortcut icon. InstallShield updates the value in the Icon settings with the
values that you specify using this method.
See Also
Shortcuts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
[InternetShortcut]
URL=http://www.MySite.com
Otherwise, if you simply right-click and click Add, you will add what the shortcut points to and not the shortcut itself.
When the end user launches the shortcut, the specified Web site (www.MySite.com) opens in the default browser.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield lets you create a shortcut to a folder. The method that you use to create a shortcut to a folder depends on the
project type that you are using.
Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, and
Transform Projects
The Target setting of a shortcut can contain a directory identifier inside square brackets. For example, to create a shortcut
to INSTALLDIR, create a shortcut with the following settings:
• Advertised: No
• Target: [INSTALLDIR]
For example, this code creates a shortcut to the Common Files folder in the end user’s Program Files folder:
ProgDefGroupType(COMMON)
szFolder = TARGETDIR;
LongPathToQuote(szFolder, TRUE);
AddFolderIcon(
ProgramMenuFolder, // where shortcut will appear
"Shortcut to TARGETDIR", // shortcut display name
szFolder, // what shortcut launches
""// working directory
TARGETDIR ^ "Sample.exe", 0, // icon file, index
"", // shortcut key
NULL); // special settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
Keyboard shortcuts—also sometimes called hot keys—enable you to perform tasks quickly by pressing a combination of
keys, such as CTRL+ALT+A, instead of using the mouse. You can assign a keyboard shortcut to your product’s shortcut so
that end users can press the appropriate hot keys to launch the shortcut.
Caution • It is recommended that you avoid configuring keyboard shortcuts for your shortcuts because they may conflict with
existing keyboard shortcuts on the target system.
2. In the Shortcuts explorer, select the shortcut for which you are specifying a hot key.
3. In the Hot Key setting, click the ellipsis button (...). The Hot Key dialog box opens.
4. Press the keyboard shortcut that you want to use for this shortcut.
5. Click OK.
In the Hot Key setting, InstallShield displays the appropriate decimal value that represents the combination of keys that
you pressed.
For example, if your key combination is CTRL+ALT+A, InstallShield displays 1601 in this setting. This number is obtained by
combining the hex value of CTRL (200) and the hex value of ALT (400) with the logical Or operator. Then, that number (600)
is added to the hex value for the A key (41) and converted to a decimal value. In this example, the number that is converted
to decimal is 641. After the conversion, it is 1601.
Renaming Shortcuts
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
When you create a shortcut, your shortcut appears with a default internal name. This name is not displayed to end users,
but you can change it to something that is relevant to your project.
2. In the Shortcuts explorer, right-click the shortcut that you want to rename and click Rename.
See Also
Shortcuts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield lets you specify one or more shortcut properties that you want the Windows Shell to set at installation run
time. For example, InstallShield has built-in support for enabling you to set Shell properties that control the following
behavior:
• Specifying Whether End Users Should Be Able to Pin a Shortcut to the Taskbar or Start Menu
• Preventing a Shortcut on the Start Menu from Being Highlighted as Newly Installed
InstallShield also lets you set additional properties that the Windows Shell supports. To learn more, see Setting Custom
Shell Properties.
See Also
Shortcuts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield lets you specify whether you want to suppress the initial pinning of a shortcut to the Start screen on Windows
8 target systems.
If you specify that you want shortcut pinning to be suppressed, the installation sets a Windows Shell property that was
introduced in Windows 8. You may want to disable pinning for shortcuts that are for tools and secondary products that are
part of your installation.
Task To specify whether pinning a shortcut to the Windows 8 Start screen should be suppressed by default:
2. In the Shortcuts explorer, select the shortcut that you want to configure. The shortcut’s settings are displayed in the
right pane.
3. In the Shell Properties setting, click the Add New Shell Shortcut Property button, and then click Suppress Initial
Pin to Windows 8 Start Screen. InstallShield adds a new Key Name setting, plus additional rows of related settings
under it, and configures them as needed.
Windows Installer 5 introduced support for shortcut properties. Earlier versions of Windows Installer ignore these setting.
Note that Windows 8 maintains information about shortcut pinning to the Start screen after a shortcut is removed by
uninstalling the application. Therefore, this setting has no effect on the target system if the shortcut has already been
installed on it. Thus, when you are testing this functionality, ensure that you test on a clean machine—one on which this
shortcut and its target have never been installed.
For Windows Installer–based projects (Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database,
Transform), some end users have reported run-time warnings or errors with a message such as the following one when
Windows Installer is installing a shortcut that configures Shell properties:
In the aforementioned message, [1] is the name of the Shell property that Windows Installer is attempting to set, and
[2].lnk is the name of the shortcut file. In such cases, it appears that the .lnk file could be locked by a different process.
• CreateShortcut
• SetShortcutProperty
See Also
Shortcuts View
Setting Shell Properties for a Shortcut
Specifying Whether End Users Should Be Able to Pin a Shortcut to the Taskbar or Start Menu
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield lets you specify whether you want the context menu commands for pinning a shortcut to the taskbar and to
the Start menu are to be displayed after end users install your product. You may want to disable pinning for shortcuts that
are for tools and secondary products that are part of your installation. Note that if you configure the shortcut to prevent
this pinning, the target of the shortcut is ineligible for inclusion in the most frequently used list on the Start menu.
If you configure a shortcut to prevent this pinning functionality, the installation sets a Windows Shell property. By default,
the property is not set for new shortcuts, so end users are able to pin the shortcut to the taskbar and to the Start menu.
Note that shortcuts that contain certain strings cannot be pinned to the taskbar or the Start menu, and they cannot be
displayed in the most frequently used list. Examples are:
• Documentation
• Help
• Install
• Remove
• Setup
• Support
Note that the method for hiding the context menu commands varies, depending on the project type that you are using.
Task To hide the context menu commands for pinning a shortcut to the taskbar or Start menu:
2. In the Shortcuts explorer, select the shortcut that you want to configure. The shortcut’s settings are displayed in the
right pane.
3. In the Shell Properties setting, click the Add New Shell Shortcut Property button, and then click Prevent Pinning.
InstallShield adds a new Key Name setting, plus additional rows of related settings under it, and configures them as
needed.
To allow the context menu commands to be displayed, find the Key Name setting that has a Property subsetting with either
of the following, and click the Delete this shortcut shell property button in the Key Name setting:
• System.AppUserModel.PreventPinning
• {9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}, 9
Windows Installer 5 introduced support for this shortcut property. Earlier versions of Windows Installer ignore this setting.
Note that for Windows Installer–based installations, some end users have reported run-time warnings or errors with a
message such as the following one when Windows Installer is installing a shortcut that configures Shell properties:
In the aforementioned message, [1] is the name of the Shell property that Windows Installer is attempting to set, and
[2].lnk is the name of the shortcut file. In such cases, it appears that the .lnk file could be locked by a different process.
Task To hide the context menu commands for pinning a shortcut to the taskbar or Start menu:
2. In the Shortcuts explorer, select the shortcut that you want to configure. The shortcut’s settings are displayed in the
right pane.
Windows 7 introduced support for this setting. Earlier versions of Windows ignore this setting.
• CreateShortcut
• SetShortcutProperty
See Also
Shortcuts View
Setting Shell Properties for a Shortcut
Preventing a Shortcut on the Start Menu from Being Highlighted as Newly Installed
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
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.
If you specify that you want to prevent the highlight functionality for a shortcut, the installation sets a Windows Shell
property. By default, the property is not set for new shortcuts.
Note that the method for preventing the highlight behavior varies, depending on the project type that you are using.
Task To prevent the Start menu entry for a shortcut from being highlighted as newly installed:
2. In the Shortcuts explorer, select the shortcut that you want to configure. The shortcut’s settings are displayed in the
right pane.
3. In the Shell Properties setting, click the Add New Shell Shortcut Property button, and then click Do Not Highlight
as New. InstallShield adds a new Key Name setting, plus additional rows of related settings under it, and configures
them as needed.
To enable the Start menu entry to be highlighted, find the Key Name setting that has a Property subsetting with either of
the following, and click the Delete this shortcut shell property button in the Key Name setting:
• System.AppUserModel.ExcludeFromShowInNewInstall
• {9F4C2855-9F79-4B39-A8D0-E1D42DE1D5F3}, 8
Windows Installer 5 introduced support for this shortcut property. Earlier versions of Windows Installer ignore this
property.
Note that for Windows Installer–based installations, some end users have reported run-time warnings or errors with a
message such as the following one when Windows Installer is installing a shortcut that configures Shell properties:
In the aforementioned message, [1] is the name of the Shell property that Windows Installer is attempting to set, and
[2].lnk is the name of the shortcut file. In such cases, it appears that the .lnk file could be locked by a different process.
Task To prevent the Start menu entry for a shortcut from being highlighted as newly installed:
2. In the Shortcuts explorer, select the shortcut that you want to configure. The shortcut’s settings are displayed in the
right pane.
Windows 7 introduced support for this setting. Earlier versions of Windows ignore this setting.
• CreateShortcut
• SetShortcutProperty
See Also
Shortcuts View
Setting Shell Properties for a Shortcut
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield lets you specify one or more 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.
Note that the method for preventing the highlight behavior varies, depending on the project type that you are using.
2. In the Shortcuts explorer, select the shortcut that you want to configure. The shortcut’s settings are displayed in the
right pane.
3. In the Shell Properties setting, click the Add New Shell Shortcut Property button, and then click Custom Property.
InstallShield adds a new Key Name setting, plus additional rows of related settings under it, with placeholder text.
Windows Installer 5 introduced support for the Shell shortcut properties. Earlier versions of Windows Installer ignore these
properties.
For more information about configuring shortcut properties, see MsiShortcutProperty Table in the Windows Installer Help
Library.
Note that for Windows Installer–based installations, some end users have reported run-time warnings or errors with a
message such as the following one when Windows Installer is installing a shortcut that configures Shell properties:
In the aforementioned message, [1] is the name of the Shell property that Windows Installer is attempting to set, and
[2].lnk is the name of the shortcut file. In such cases, it appears that the .lnk file could be locked by a different process.
• CreateShortcut
• SetShortcutProperty
See Also
Shortcuts View
Setting Shell Properties for a Shortcut
Windows Logo • According to current Windows logo guidelines, best practice is to not place shortcuts to remove the
application in the Start menu. An uninstallation shortcut is unnecessary because your application’s uninstaller is in Add or
Remove Programs.
You can create an uninstallation shortcut to make it easier for end users to uninstall your product from their systems. When
launched, the shortcut automatically starts the uninstallation process.
2. In the Shortcuts explorer, right-click the destination directory that should contain the uninstallation shortcut, and
then click New Shortcut to Preexisting file. InstallShield adds a new shortcut with the default name NewShortcutN
(where N is a successive number).
3. Enter a new name, or right-click it later and click Rename to give it a new name.
4. In the Arguments field, type /x [ProductCode]. Separate the two arguments with a space.
Msiexec.exe is the command-line engine for the Windows Installer service. The /x argument instructs the Windows
Installer service to uninstall the product referenced by the product code.
6. In the Target field, select [SystemFolder], and then append msiexec.exe to this location.
7. In the Component field, select the component with which you want this shortcut associated. If the shortcut should
always be installed, associate it with the component containing your application’s main executable file.
See Also
Creating Shortcuts and Program Folders
Files and Folders View
Creating Uninstallation Shortcuts for InstallScript and InstallScript MSI Projects
• InstallScript
• InstallScript MSI
Note • You may not want to create an uninstallation shortcut. An uninstallation shortcut is unnecessary because your
application’s uninstaller is in Add or Remove Programs.
You can create an uninstallation shortcut to make it easier for end users to uninstall your product from their systems. When
end users launch the shortcut, the uninstallation process automatically starts.
The following InstallScript code creates a shortcut called Uninstall Application on the desktop after file transfer.
Launching this shortcut runs your installation in maintenance mode. This code works for both InstallScript and
InstallScript MSI projects.
function OnMoved()
begin
if( !REMOVEALLMODE ) then
AddFolderIcon( FOLDER_DESKTOP, "Uninstall Application", UNINSTALL_STRING +
ADDREMOVE_STRING_REMOVEONLY, "", "", 0, "", REPLACE );
endif;
end;
Tip • If you include ADDREMOVE_STRING_REMOVEONLY, -removeonly is added to the command line. As a result,
REMOVEONLY is set, and the OnMaintUIBefore event handler shows only the uninstallation option. To display the standard
maintenance user interface, do not include ADDREMOVE_STRING_REMOVEONLY.
See Also
Using InstallScript
AddFolderIcon
ADDREMOVE_STRING_REMOVEONLY
OnMaintUIBefore
OnMaintUIBefore
Files and Folders View
Creating Uninstallation Shortcuts for Basic MSI Projects
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
Windows 8 introduced a grid of application tiles to the Start screen, replacing the usual list of shortcuts, and also presented
tiles in place of shortcuts. InstallShield supports customizing the appearance of a desktop app's tile on the Start screen.
The following tile configuration settings are available:
• A toggle between light or dark text when including the app name on medium-sized (150x150) tiles
The Tile Configurations node appears in the main Shortcuts view and in each component’s Shortcuts subview. Any
applicable tile configurations are listed. For a component, Tile Configurations only applies if it is a configuration for an
.exe file in that component. For the main view, it only applies if the filtering includes the component targeting the
configured .exe file.
Note • While there is a relation between shortcuts and tiles, they are different. You can configure shortcuts individually, and
even create multiple shortcuts to the same .exe file that use different icons; however, you can only create one tile configuration
per .exe file.
Task To configure the appearance of a desktop app's tile on the Start screen:
1. In the Shortcuts view, or in the Shortcuts node of the Setup Design or Components view, click Shortcuts.
2. Right-click Tile Configurations and choose the Add Tile Configuration context menu option.
Note • This step assumes an .exe file has been added to the project. If an .exe file does not exist in the project, the Add
Tile Configuration context menu option is disabled.
Tip • Alternatively, you can right-click the shortcut that targets the .exe file for which you want to configure a Start
screen tile and then choose the Configure Tile context menu option. A new tile configuration is added (and selected). If a
configuration has already been added for the shortcut, the Configure Tile option is disabled.
3. In the resulting Browse for Tile Target dialog box, navigate to and select the .exe file for the app whose tile appearance
you want to configure. A new tile configuration is added.
4. Use any of the settings available for Tile Configurations to customize the appearance of a desktop app's tile on the
Start screen. For additional information regarding available settings, refer to Tile Configuration Settings.
See Also
Shortcuts View
Tile Configuration Settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
The Windows registry is a system-wide database that contains configuration information used by applications and the
operating system. The registry stores all kinds of information, including the following:
• Application information such as company name, product name, and version number
• Uninstallation information that enables end users to uninstall the application easily without interfering with other
applications on the system
• License information
• HKEY_LOCAL_MACHINE
• HKEY_USERS
• HKEY_CURRENT_USER
• HKEY_CLASSES_ROOT
A key is a named location in the registry. A key can contain a subkey, a value name and value pair, and a default (unnamed)
value. A value name and value pair is a two-part data structure under a key. The value name identifies a value for storage
under a key, and the value is the actual data associated with a value name. When a value name is unspecified for a value,
that value is the default value for that key. Each key can have only one default (unnamed) value.
Note that the terms key and subkey are relative. In the registry, a key that is below another key can be referred to as a
subkey or as a key, depending on how you want to refer to it relative to another key in the registry hierarchy.
All registry data (except the <Default> registry set in a InstallScript project) must be associated with a component. In
installation projects, if the component’s feature is selected for installation, the component’s registry data are set up on the
target system.
Caution • It is important not to modify or delete registry keys indiscriminately because the registry is a vital part of the
Windows operating system, and the system may fail to function if vital registry keys are altered.
Note • The installer automatically creates certain registry entries based on values that you provide in the General
Information view.
Windows Logo • These “informational keys” are required if you want to meet the requirements for the Windows logo
program.
Also, all of a component’s advanced settings are used to register files on the target system.
See Also
Registry View
Special Considerations for Searching the Registry at Run Time
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Several project types (DIM, Merge Module, and MSM Database) do not include support for features; these project types have
support for by filtering by component, but not by feature.
The Registry view includes a View Filter. This filter enables you to select a component or feature whose registry data you
want to display in the view.
The View Filter lists your project’s hierarchy of features, subfeatures, and components. Selecting a feature shows the
registry data for all of the components in that feature, but it allows you only to modify and delete existing entries. You need
to select a component in order to add a new registry key.
If the feature hierarchy contains a subfeature, selecting a parent feature displays only the registry entries in that feature. It
does not display the registry entries in the subfeature.
If the View Filter is set to All Application Data, you can right-click a registry hive in the Destination computer’s registry view
pane and click Browse for Component to display the dialog box.
Note • You can modify, rename, or delete registry keys and values while filtering the view by All Application Data.
When you click a registry key in the Destination computer’s Registry view pane of the Registry view, InstallShield displays
all of the registry data for that key in the lower-right pane of the Registry view. The Component column shows the
component with which the registry data is associated. If the same value exists for more than one component, the last
component that was associated with the registry data is displayed.
If you have not set a value for a key, no registry data is displayed for that key when you select All Application Data in the
View Filter.
See Also
Registry View
Special Considerations for Searching the Registry at Run Time
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
Press F12.
See Also
Registry View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
Task To specify a registry key to be created on the target system when a component is installed:
2. In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, Transform, and QuickPatch projects—
In the View Filter list, click the component with which you want to associate the registry data.
In InstallScript and InstallScript Object projects—In the Destination computer’s Registry view pane, open an existing
registry set or create one by right-clicking the Destination Computer folder. Associate the registry set with one or
more components by clicking the registry set and selecting the desired components in the Registry Set Install
Conditions pane.
3. In the Destination computer’s Registry view pane, right-click a registry hive or key, point to New, and then click Key.
InstallShield adds a new key with the name New Key-n (where n is a successive number).
4. Enter a meaningful name to rename the key, or right-click the key and click Rename to give it a new name later.
InstallShield adds your new key with an empty default string value.
By default, all keys that you create are set for automatic installation and uninstallation. This means that they are installed if
the component they belong to is installed, and they are uninstalled when that component in uninstalled. For more
information on registry key flags, see Registry Flags.
Tip • You can create multiple nested keys at one time by creating a new key and typing, for example, Key 1\Key 2\Key 3 in
the key’s name. InstallShield creates a nested key structure where Key 3 is a subkey of Key 2, which is a subkey of Key 1.
See Also
Writing Property Values to the Registry
Special Considerations for Searching the Registry at Run Time
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
The quickest way to add registry entries to your installation project is to drag them from one of the source panes in the
Registry view and drop them into one of the destination panes. When you drop an entire key onto the Destination
computer’s Registry view pane, all of that key’s subkeys and values are added to the selected component or, in a
InstallScript project, to the registry set on which you drop the entry.
Table 4-2 • Commands Available from the Registry Entry Context Menu
Option Description
All keys & values Adds all selected keys, subkeys, and values.
Key and its values only Adds only the selected key and the key’s values. No subkeys are added.
Only this key Adds only the selected key, not any of its subkeys or values.
Cancel Ends the drag and drop operation without making any changes.
Viewing Both the 32- and 64-Bit Areas of the Source Machine’s Registry on 64-Bit
Development Systems
If you are using InstallShield on a 64-bit development system, the Registry view in InstallShield displays both the 32-bit and
64-bit areas of your machine’s registry:
• HKEY_LOCAL_MACHINE\Software
• HKEY_LOCAL_MACHINE\Software\Wow6432Node
This support enables you to drag and drop entries from those source areas to the appropriate areas in the destination pane
of this view when you are configuring registry data changes for your project.
Note that if you want your installation to install registry data to a 64-bit area of the registry on 64-bit target systems without
having it redirected to a 32-bit area, you must place the registry data in a component that is marked as 64 bit. Simply
dragging 64-bit data from the source panes in the Registry view to a location in one of the destination panes of the view
does not mark the component as 64 bit. For more information, see Targeting 64-Bit Operating Systems.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
2. In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, Transform, and QuickPatch projects—
In the View Filter list, click the component that contains the registry key, or select All Application Data to view all of
the registry keys for your product.
In InstallScript and InstallScript Object projects—In the Destination computer’s Registry view pane, open the existing
registry set that contains the registry key.
3. In the Destination computer’s Registry view pane, right-click the registry key that you want to remove and then click
Delete.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
2. In the Destination computer’s Registry view pane, click the key to which you want to add a value. All existing
registry values for that key are listed in the Destination computer’s registry data pane.
3. Right-click in the list of values and then click the type of data you want to register. Available options are as follows:
Option Description
DWORD Value Data represented by a number that is four bytes (32 bits) long.
Multi-String Value Multiple text strings formatted as an array of null-terminated strings, and terminated
by two null characters. Selecting this command launches the Multi-Line String Value
dialog box.
Expandable String Value The value is interpreted and stored as an expandable string. According to the
Microsoft Developer Network (MSDN), an expandable string registry value is a null-
terminated string that contains unexpanded references to environment variables (for
example, %PATH%).
InstallShield adds a new value with the name New Value n (where n is a successive number). Enter a meaningful name now
to rename the value, or right-click the value name and then click Rename to give it a new name later.
Project • In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, Transform, and QuickPatch
projects, any registry value can serve as the component’s key path.
See Also
Setting Key Paths for Components
Entering Multi-Line String Values for Registry Keys
Special Considerations for Searching the Registry at Run Time
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
Task To modify the data for a registry value to be created on the target system:
2. In the Destination computer’s Registry view pane, click the registry key that has the value that you want to modify.
All registry values are listed in the Destination computer’s registry data pane.
3. Double-click the value that you want to modify. The Edit Registry Data dialog box or the Multi-Line String Value dialog
box opens.
4. Complete the information in the dialog box, and then click OK.
Project • In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, Transform, and QuickPatch
projects—To add value data that contains square brackets ([]), you must precede each bracket with a backslash (\) and
surround it with an opening and closing bracket. Otherwise, Windows Installer treats the value as a property. For example, if
you wanted to write [stuff] to the registry, you would use [\[]stuff[\]] as the value data.
See Also
Entering Multi-Line String Values for Registry Keys
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
2. In the Destination computer’s Registry view pane, click the registry key that has the value that you want to delete.
All registry values are listed in the Destination computer’s registry data pane.
3. In the Destination computer’s Registry data pane, right-click the registry value that you want to remove and then
click Delete.
Registry Flags
InstallShield 2020
Project • Support for registry flags differs, depending on what project type you are using.
Registry flags enable you to control the installation of your registry entries.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
By default, your registry entries are created on the target system if the component to which they belong is installed. They
are then removed from the target system when that component is removed. If you would like your registry entries to
remain on the target system even after the product has been uninstalled, or if you want to create registry entries only if
they do not already exist, you need to set the installation flag for that key.
In InstallShield, installation behavior is set at the subkey level. All values beneath the key must have the same installation
and uninstallation behavior.
To change the registry flag of a key, right-click one of your project’s keys in the Registry view, and then click any of the
commands that are listed in the following table.
Automatic This is the default option for all registry keys. If the key is not already present, the installation
creates it. During an uninstallation, if the key is empty, it is removed.
Install only (+) If the key does not already exist, it is created. The key is left on the target system when the
component to which this key belongs is uninstalled.
This option is available only for keys that do not contain subkeys or values.
Uninstall entire If this flag applies to an empty key, the key is not created at installation. If this flag applies to
key (–) a key that contains values and the key does not exist on the target system, the key and values
are created at installation. In both cases, the key, all subkeys, and values are removed at
uninstallation—even if the subkeys and values were added after the installation.
Install if absent, This option is similar to the default behavior (the Automatic registry flag), with one exception.
Uninstall if For the Automatic registry flag, if the key is not empty during uninstallation, it is not removed.
present (*) For the Install if absent, Uninstall if present (*) flag, if the registry key is present during
uninstallation, the key is removed, regardless of whether its subkeys or values remain.
• InstallScript
• InstallScript Object
After your installation has created registry keys on the target system by installing a registry set, subkeys or values may be
created under those keys by other installations or applications (or directly by the end user). You can prevent a registry key
that your installation installed from being uninstalled if it has any subkeys or values that were not created by the
installation. To accomplish this, you can change the registry flag of the key. To do so, right-click one of your project’s keys
in the Registry view and then click the following command.
Shared among When the component to which this key belongs is uninstalled, the key is not removed from
several the target system if the key has any subkeys or values. (Note that a value that was created by
applications your installation will have already been uninstalled unless you unset its Remove during
Uninstall flag.) If the key does not have any subkeys or values, the key is removed from the
target system regardless of whether it was created by the installation—that is, whether it
already existed at the time of installation.
You may want your uninstallation to leave some of your product’s registry values on the end user’s system—for example,
registry values that are used by the operating system and are modified by your installation. To do this, right-click the key
that contains the registry value that you do not want to be uninstalled. Select the Shared among several applications flag
for that key. Then right-click the value of the key and ensure that the Remove during Uninstall command is not selected.
See Also
Registry View
Special Considerations for Searching the Registry at Run Time
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
Task To search for a registry entry within a certain component (in Windows Installer projects) or registry set (in InstallScript
projects):
2. In Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, MSM Database, Transform, and QuickPatch projects—
In the View Filter list, select the component that you would like to search. Note that if View All Entries is selected, the
Registry view is read only.
In InstallScript and InstallScript Object projects—Open the registry set that you would like to search.
3. Right-click a registry entry and click Find. The Find dialog box opens.
In a Windows Installer project, InstallShield searches only the registry entries for the current component, not all the
registry data for the project.
The search starts from the top item and works its way down, regardless of which item is selected. It stops at the first match,
highlighting this key. To continue the search, right-click and select Find Next, or press F3. The Find Next feature finds the
next match, moving down the explorer.
See Also
Special Considerations for Searching the Registry at Run Time
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
In InstallShield, uninstall behavior for registry entries is set at the key level.
2. In the Destination computer’s Registry view pane, right-click a key and click the appropriate uninstall behavior.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
With REG_EXPAND_SZ string values, you can use environment variables for paths that are stored in the registry. These
entries require special formatting in order to be recognized by the operating system as environment variables. The format
for a REG_EXPAND_SZ value as it appears in the registry is %TEMP%. TEMP is the standard environment variable for the
TEMP directory.
Syntax
When creating registry entries of this type, you need to begin the entry with a pound sign followed by a percent sign (#%).
Then, you can enter your environment variable, complete with the beginning and ending percent sign. Therefore, if you
enter #%%TEMP% in the Registry view in InstallShield, it appears as %TEMP% when written to the registry.
The Type field for this entry appears as REG_EXPAND_SZ, and the Data field is %TEMP%.
See Also
Registry View
Special Considerations for Searching the Registry at Run Time
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
For Windows Installer–based projects, you can use Windows Installer properties in registry values to store information for
later use by your product. At run time, Windows Installer automatically expands expressions of the form [PropertyName]
in registry data to the value of the property called PropertyName. Any property defined in the Property Manager view can
be used in this way.
For example, if you would like to store the destination location of your software, create a registry value whose data is
[INSTALLDIR]. At run time, when your installation creates the registry value, the data for that registry value is set to the
location where your application is installed.
You can use the same format for registry key names and value names. For example, if you want a key name to be the name
of your company, enter [Manufacturer] for the name of the key. When the registry key is created on the target system, the
name of this key will be the value of the Publisher setting, as entered in the General Information view.
See Also
Special Considerations for Searching the Registry at Run Time
Registry View
Property Manager View
RegDBSetKeyValueEx
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield enables you to import any existing registry (.reg) files that you may have from other installation projects or
that you have created outside InstallShield
2. Follow the instructions in the wizard panels to import your .reg file.
When you import a .reg file into a component or registry set, that registry data is added to the component’s or registry set’s
registry data and written to the end user’s system if the component or registry set is installed.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
When you export a registry (.reg) file, you are copying a portion of your program’s registry data to a registry file.
2. In the Destination computer’s Registry view pane, right-click the registry entry that you want to export and click
either Export REG File or Export Selected Branch.
• Export Selected Branch exports only the current registry key and any subkeys.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
A key path is a unique registry value for each component that the Windows Installer uses to detect the component’s
presence. This value must contain a file or a folder.
2. In the Destination computer’s Registry view pane, click the registry entry that contains the registry data that you
want to use for the key path.
3. In the Destination computer’s registry data pane, right-click the registry key’s value name and then click Set Key
Path.
The value’s string, binary, or DWORD icon is replaced with a key icon.
Note • A component can have either one key path or one key file. If you have already set a key file or a key path for a
component, you will get a warning prompt if you try to set another key path. Click Yes in the dialog box to replace the existing
key file or key path with the new key path.
See Also
Setting Component Key Files
Overwriting Files and Components on the Target System
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield lets you configure settings for securing registry keys for end users who run your product in a locked-down
environment. You can assign permissions for a registry key to specific groups and users. For example, you may assign Read,
Write, and Delete permissions for a particular registry key to the Administrators group, but only Read permissions for all of
the users in a different group.
2. In the Destination computer’s Registry view pane, right-click the registry key and then click Permissions button.
The Permissions dialog box opens.
3. Add, modify, and remove permissions entries as needed. For more information, see Permissions Dialog Boxes for
Registry Keys.
Depending on what is selected for the Locked-Down Permissions setting in the General Information view of your project,
InstallShield adds permissions data to either the ISLockPermissions table or the LockPermissions table. To learn more,
see Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment.
See Also
Configuring Permissions for Files and Folders
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Windows Installer requires a unique primary key for each registry key and value that you add to the Registry table. To
enable you to create registry entries in a completely visual environment, InstallShield assigns a unique name to every entry
in the database’s Registry table at build time.
You may need to know the entry’s primary key when authoring a custom action. InstallShield supports specifying a primary
key on a registry key or value in the Registry Data explorer in the Setup Design view or the Components view. Note that it is
not possible to assign the key or value a primary key in the Registry view.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
1. Right-click the key or value and click MSI Value. The MSI Value dialog box opens.
2. Enter the name of the key. Since the primary key must be a Windows Installer identifier, the name may contain only
letters, numbers, underscores (_) and periods (.), and it must begin with a letter or underscore.
To view or modify the primary key, right-click the registry key or value and click MSI Value again.
If you do not specify a value, InstallShield generates a unique primary key for this entry in the Registry table.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
The Registry view provides multi-line string support when you want to add a value to a particular registry key.
1. Right-click the registry key to which you want to add the multi-line value, point to New, and click Multi-String Value.
The Multi-Line String Value dialog box opens.
2. Select how you want to modify the registry value, and then enter a line for each null-delimited string.
3. Click OK.
Note • Strings can contain just spaces, but they cannot be empty or [~], which is the delimiter for the strings.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
• QuickPatch
Since the current user may not have sufficient privileges for modifying keys under HKEY_LOCAL_MACHINE, you may need
to write the entries under HKEY_CURRENT_USER.
When you select HKEY_USER_SELECTABLE in the Registry view, the entries are created under the appropriate registry hive,
according to the type of installation and the end user’s access rights. In a per-user installation, which means that the
ALLUSERS property is set to 2 or that the installation is being run by someone with user-level access privileges, these entries
would be made under HKEY_CURRENT_USER. In a per-machine installation, which means that ALLUSERS is not null and
that the end user is an administrator, the entries would be written under HKEY_LOCAL_MACHINE.
Note • Windows does not allow a new key to be created directly under HKEY_LOCAL_MACHINE. For this reason, any
information that you create under HKEY_USER_SELECTABLE must be placed under the SOFTWARE subkey, which is the only
subkey common to HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER.
1. Initialize the string to contain each of the substrings, separated by space characters.
2. Assign the ASCII value for a null string to the string positions after each line.
3. Assign an additional null character (ASCII value 0) to the end of the string.
For example:
svValue = "This is line one. This is line two. This is line three. ";
svValue[17] = 0;
svValue[35] = 0;
svValue[55] = 0;
svValue[56] = 0;
See Also
Using Null-Delimited Strings
RegDBSetKeyValueEx
RegDBGetKeyValueEx
SdShowInfoList
Project • For InstallScript MSI and Basic MSI projects, it is recommended that you use the Registry view in InstallShield instead
of creating registry keys and values through InstallScript code. Handling all of your registry changes in this way allows for a
clean uninstallation through the Windows Installer service.
The InstallScript language includes many built-in functions that help you configure an installation so that it accesses the
registry; reads, creates, and deletes registry keys; and establishes registry-related parameters for uninstallation.
For example, you can sometimes determine if an application is present on the target system by detecting registry keys used
by the application. Many applications store data in the registry key
HKLM\SOFTWARE\CompanyName\ProductName\ProductVersion. To detect if a registry key exists, you can call the
RegDBKeyExist function in your InstallScript code as follows:
if (RegDBKeyExist("Software\\ThisCo\\ThisApp") = 1) then
MessageBox("ThisApp is on the system.", INFORMATION);
endif;
To learn more about the built-in registry functions available with InstallScript, see the following:
• Registry Functions
See Also
RegDBKeyExist
RegDBSetDefaultRoot
Signature_ registry_sig
Root 2 HKEY_LOCAL_MACHINE
Key Software\Microsoft\Windows
NT\CurrentVersion
Name RegisteredOwner
After the AppSearch action runs, the REGISTERED_OWNER property will contain the data read from the registry. If the value is
not found, the property will be undefined (empty).
For more information regarding the AppSearch and RegLocator tables, see the Windows Installer Help Library.
For Windows Installer-based projects, you can use the System Search Wizard to find data.
function readRegisteredOwner( )
STRING svRegisteredOwner;
NUMBER nvType, nvSize;
begin
RegDBSetDefaultRoot(HKEY_LOCAL_MACHINE);
RegDBGetKeyValueEx(
"Software\\Microsoft\\Windows NT\\CurrentVersion",
"RegisteredOwner",
nvType,
svRegisteredOwner,
nvSize);
MessageBox(
"Registered owner is: " + svRegisteredOwner,
INFORMATION);
end;
You can set a Windows Installer property equal to the value you read using the MsiSetProperty function.
See Also
Special Considerations for Searching the Registry at Run Time
RegDBGetKeyValueEx
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes .ini file functions for
modifying .ini file data. You can use these functions in InstallScript projects.
Initialization (.ini) files serve as a database in which you can store and retrieve information between the uses of your
applications. Some .ini files, such as Boot.ini and Wininit.ini, are used by the operating system. The INI File Changes
view enables you to specify changes that should be made to .ini files on the target system. Although you can edit any .ini
file found on the target system, editing system .ini files is not recommended.
Before you can create an .ini file reference, you must have at least one component created. If no components exist when
your .ini file reference is created, the Create a New Component dialog box is displayed, enabling you to create a
component.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes .ini file functions for
modifying .ini file data. You can use these functions in InstallScript projects.
The first step in creating an .ini file change is to create a reference to the file that you would like to edit. In order to do this,
you need to know the name and location of the file on the target system that you would like to edit. If the file is not in the
location that you specify, the installation cannot make changes to this file.
1. In the View List under System Configuration, click INI File Changes.
2. Right-click the INI Files explorer and then click Add INI File.
InstallShield adds a new reference for the .ini file to the INI Files explorer. Configure the .ini file’s settings in the right pane.
For details about each setting, see .ini File Settings.
After you have created a reference to an .ini file, you can move on to the next step, which is to add a section to your .ini file.
See Also
INI File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes .ini file functions for
modifying .ini file data. You can use these functions in InstallScript projects.
InstallShield lets you import an existing .ini file into your project. Once you have imported the .ini file, you can use the INI
File Changes view to configure the changes that you want to be made on the target system as needed.
1. In the View List under System Configuration, click INI File Changes.
2. Right-click the INI Files explorer and then click Import INI File. The Open dialog box opens.
3. Select the .ini file that you want to import, and then click Open.
InstallShield imports the .ini file, along with all of its sections, keywords, and values, into your project.
See Also
INI File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes .ini file functions for
modifying .ini file data. You can use these functions in InstallScript projects.
Once you have specified the .ini file that you would like to edit, you can move onto the second step: specifying which
section of that file you want to change. The .ini files are divided into sections, with each section containing keywords.
Sections are identified by the square brackets surrounding them—for example, [SectionName].
1. In the View List under System Configuration, click INI File Changes.
3. In the INI Files explorer, right-click the .ini file that should contain the section and click Add Section.
InstallShield adds a section to the INI Files explorer. Configure the section’s settings in the right pane. For details about
each setting, see Section Settings for an .ini File.
After you have specified a section in your .ini file, you can add a keyword.
See Also
INI File Changes View
Using String Entries in InstallShield
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes .ini file functions for
modifying .ini file data. You can use these functions in InstallScript projects.
The keywords in an .ini file are the lowest level of organization in the .ini file. Keywords store data that must persist
between uses of an application.
Once you have added an .ini file to your project and set up one or more sections, you can add keywords to the sections and
then configure the keyword’s properties. The properties of a keyword include the value for the keyword, as well as the
action that should be performed (such as replace a data value or append to an existing data value).
1. In the View List under System Configuration, click INI File Changes.
2. In the INI Files explorer, right-click a section and click Add Keyword.
InstallShield adds a keyword to the INI Files explorer. Configure the keyword’s settings in the right pane. For details about
each setting, see Keyword Settings for an .ini File.
See Also
INI File Changes View
You can use the GetProfString function to read data (such as key names) from an .ini file, regardless of where the .ini file is
located (for example, on a network). The following example script provides a guide:
/*
Assuming the .ini file is called Test.ini, and contains the following:
[ProductSettings]
Key1=One
Key2=2
Key3=III
Key4=....
[OtherSettings]
Key1=Value1
Key2=Value2
*/
function OnBegin( )
STRING svKey1Value; // filled in by GetProfString
begin
end;
See Also
GetProfString
To read all of the key names from a section in an .ini file, use the following script:
function OnBegin( )
STRING svAllKeyNames; // filled in by GetProfString
LIST listKeyNames; // string list containing key names
begin
listKeyNames = ListCreate(STRINGLIST);
// if desired, you can loop over the key names in the list and read each
key's value...
ListDestroy(listKeyNames);
end;
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
One of the more complex areas of system configuration involves setting up ODBC drivers, data source names (DSNs), and
translators. The ODBC resource must be properly registered on the system with all of the required attributes and, in the
case of drivers and translators, install the necessary files, including any installation .dll files. This process is simplified in the
ODBC Resources view, in which you can select the drivers, data sources, and translators installed on your development
system.
See Also
ODBC Resources View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
All of the ODBC drivers, data source names (DSNs), and translators registered on your system are displayed in the ODBC
Resources view. DSNs are shown as children of their associated driver. Expand the explorer to view all of the existing ODBC
resources.
To include an ODBC resource in your installation, select the check box next to its name in the ODBC Resources pane in the
upper-left corner of the view. In installation projects, the resource must then be associated with at least one feature so that
it can be installed. Then, you can set the attributes for the selected resource.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
You can also install ODBC resources not listed in the explorer. Where you add them depends on the type of resource.
Task To add a driver that is not listed in the ODBC Resources explorer in the ODBC Resources view:
1. In the ODBC Resources explorer, right-click Drivers and DSNs and click New Driver.
2. Enter a new name for the driver, or press the F2 key later to rename it.
3. Select the check box next to the new driver to include it in your installation.
Task To add a data source that is not listed in the ODBC Resources explorer in the ODBC Resources view:
1. In the ODBC Resources explorer, right-click a driver and click New DSN.
2. Enter a new name for the DSN, or press the F2 key later to rename it.
3. Select the check box next to the new DSN to include it in your installation.
Note • You cannot add a translator to the list. Instead, you must install it on the development system and then select it.
See Also
ODBC Resources View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Like most of the data in your project, ODBC resources must be associated with a feature. When the feature is installed to
the target system, the ODBC resource is installed as a part of the feature.
After you choose to install a driver, DSN, or translator for installation, the Features list is enabled on the right side of the
ODBC Resources explorer. Select all of the features to which the ODBC resource belongs. InstallShield creates a new
component and associates it with each selected feature. The resource will be installed only once even if it is associated
with multiple features, but the resource cannot be installed if none of its features is installed.
In an InstallScript MSI project, if no other feature exists, the resource is added to the DefaultFeature. In a Basic MSI project,
if a feature does not exist when you add an ODBC resource to your installation, the Create a New Feature dialog box is
displayed. This dialog box prompts you to create a feature. If only one feature is associated with an ODBC resource, it
cannot be deselected until you select at least one additional feature.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
When an ODBC resource is registered on the development system, its current attributes are displayed in the Properties list
of the ODBC Resources view. You can edit the attributes in the Properties pane after you have selected the driver, data
source name (DSN), or translator.
2. In the ODBC Resources explorer, click the driver or DSN that should contain the new attribute entry.
3. Click in the last row of the property sheet, and add the appropriate information for the Property and Value columns.
2. In the ODBC Resources explorer, click the driver or DSN that should contains the attribute entry that you want to
delete.
3. In the property sheet, right-click the row that you want to delete and then click Delete.
See Also
ODBC Resource Settings
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The InstallScript language includes the GetEnvVar function for retrieving the current value of an environment variable, and it
enables you to create an environment variable.
Environment variables are name and value pairs that can be set on the target system with your installation and can be
accessed by your application and by other running programs. Environment variables are stored in the registry.
In the Environment Variables view, you can create, set (or modify), and remove environment variables on the target system
through your installation. You can also specify environment variable properties in this view.
See Also
Environment Variables View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The InstallScript language includes the GetEnvVar function for retrieving the current value of an environment variable, and it
enables you to create an environment variable.
Task To create a new environment variable or modify the value of an existing environment variable:
2. Right-click the Environment Variables explorer and click Add Environment Variable.
3. InstallShield adds a new environment variable with the default name NewEnvironmentVariableX (where X is a
number). Type the name of the variable that you want to modify, remove, or create.
4. In the pane on the right, configure the environment variable’s settings. For details about each setting, see
Environment Variable Settings.
See Also
Environment Variables View
/********************************************************************\
* The following code creates an environment variable under Windows
* for an entire system. You can modify the OnEnd event handler
* function block (or any other function block) to include this example
* code.
*
* NOTE: The current user must have administrator privileges for this
* code to work.
\********************************************************************/
begin
/********************************************************************\
* The following code creates an environment variable under Windows
* for the current user. You can modify the OnEnd event handler
* function block (or any other function block) to include this example
* code.
*
* NOTE: The current user must have administrator privileges for this
* code to work.
\********************************************************************/
NUMBER nResult;
begin
szKey="Environment";
RegDBSetDefaultRoot(HKEY_CURRENT_USER);
nResult=RegDBSetKeyValueEx(szKey,"Fame",REGDB_STRING,"C:\\test",-1);
if (nResult < 0) then
MessageBox("Failed to Set Environment Variable",WARNING);
else
MessageBox("Successfully Set Environment Variable",INFORMATION);
// Flush the registry to all applications.
szEnv = "Environment";
pEnv = &szEnv;
SendMessage (HWND_BROADCAST, WM_WININICHANGE, 0, pEnv );
endif;
//RebootDialog("","",SYS_BOOTMACHINE);
end;
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
You may need to modify .xml files that store settings related to your product, or you may need to modify standard
configuration files such as web.config and machine.config. InstallShield includes support for modifying XML files on the
target system at run time. The XML files can be part of your installation, or they can be files that are already present on
target systems.
For instructions on how to modify an XML file during installation, consult this section of the documentation.
For background information about XML, see the following Web sites:
• W3 Schools (http://w3schools.com)
Tip • Support for XML files extends into other areas of InstallShield product functionality. The System Search feature in
InstallShield enables you to search for an attribute value, contents, or existence of the element in the XML file that you specify.
For more information, see Searching for XML Data.
See Also
XML File Changes View
Import XML Settings Wizard
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
Design-Time Tasks
The XML File Changes view enables you to define modifications that should be made to an XML file at run time. The typical
process for defining those modifications is as follows:
1. If the XML file that you are modifying is part of your installation, add the base XML file to a component in your project
through the Files and Folders view.
2. In the XML File Changes view, create an XML file reference for the file that you want to modify.
3. Specify the location for the XML file on the target machine.
4. Specify which feature or features should contain the XML file changes. This may be the same feature that contains the
component in step 1, or it may be a different feature.
You may need to add an MSXML redistributable to your project. For more information, see Run-Time Requirements for XML
File Changes.
Run-Time Behavior
The XML File Changes view enables you to configure run-time behavior such as the following:
• Add a namespace mapping to an XML file, and add namespace prefixes to elements and attributes.
• Modify only the first element in the XML file that matches the specified XPath expression, or modify all matching
instances.
• Append a string to an existing attribute value during installation, during uninstallation, or both.
• For Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, and Transform projects: Replace Windows Installer
properties in elements, attributes, attribute values, and element content with the appropriate values at run time.
• For InstallScript projects: Substitute InstallScript string variables for elements, attributes, attribute values, and
element content with the appropriate values at run time.
When an installation that contains XML file changes runs on a target system, MSXML parses the XML file and executes the
XPath expressions that are associated with the changes that you configured. The Advanced tab in the XML File Changes
view for an XML file shows the XPath expressions that are executed on target systems.
When MSXML finds an area of the XML file that matches the XPath expression, the changes that were configured in the XML
File Changes view are made.
For examples of how to create some basic XPath expressions, see Using XPath Expressions to Find XML Data in an XML File.
Note • If the XML file does not exist on the target system at run time and the Always create XML file if it does not already
exist check box is selected on the Advanced tab for the XML file, the XML file is created with the XML data that is configured in
the XML File Changes view.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
The run-time functionality for XML file changes requires the presence of Microsoft XML Core Services (MSXML) 3.0 or later
on the target system.
When an installation that contains XML file changes runs on a target system, MSXML parses the XML file and executes the
XPath expressions that are associated with the changes that you configured. When MSXML finds an area of the XML file that
matches the XPath expression, the changes that were configured in the XML File Changes view are made.
InstallShield includes redistributables for different versions of MSXML. If it is possible that target systems may not have
MSXML, or they may not have the appropriate version of MSXML, you can add the appropriate MSXML redistributable to
your project in either the Redistributables view (for Basic MSI and InstallScript MSI projects) or the Prerequisites view (for
InstallScript projects).
See Also
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
The recommended way to add an XML file that you want to modify at run time is to add the base XML file to a component in
your project through the Files and Folders view. Then add an XML file reference to the XML File Changes view, where you
can specify the changes that should be made to that file at run time. The easiest way to add the XML file reference is to
import the file into the XML File Changes view.
Important • The XML File Changes view is not designed to list a node for every node in an XML file. To improve performance,
the XML File Changes view should show only the settings that differ from the base XML file:
• If the XML file that you are modifying is part of your installation, the XML File Changes view should list only the nodes and
node sets that should be added, changed, or deleted after the XML file is installed at run time.
• If the XML file that you are modifying is a file that is already present on the target system, the XML File Changes view
should list only the nodes and node sets that need to be added, changed, or deleted at run time.
Therefore, when you are importing a file, import only the nodes in the XML file that you want to modify at run time.
Note that the XML File Changes view does not enable you to specify the order in which new elements should be listed in the XML
file. Therefore, importing only the nodes that you want to modify at run time helps to avoid issues that may occur if your
product requires that the elements be listed in a particular order.
Task To import an XML file into the XML File Changes view:
1. In the View List under System Configuration, click XML File Changes.
2. Right-click the XML Files explorer and then click Import. The Import XML Settings Wizard opens.
3. Complete the panels in the wizard, selecting only the XML file nodes that you want to change.
4. Click Import.
InstallShield adds a new node for the XML file that you imported. The XML file node contains each of the nodes that you
selected in the wizard. Each node represents an XPath query that occurs at run time. InstallShield also adds a new
component for the XML file that you have imported through the XML File Changes view.
Now you can configure the XML file’s settings and specify any element, attribute, and content changes for it.
Tip • You can also add an XML file by right-clicking the XML Files explorer and then clicking New File. However, in most cases,
you may want to create your XML file in a third-party XML editor or text editor. Next, add this file to your project through the
Files and Folders view. Then, import the file, as described in the aforementioned procedure, and configure the changes that
should be made to the file at run time.
See Also
Import XML Settings Wizard
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
When you add an XML file reference in the XML File Changes view, you need to specify the location of the XML file. If the XML
file is part of your installation, the location should match the destination that you specified for the base XML file when you
added it to your project through the Files and Folders view.
Task To specify the location of the XML file on the target system:
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, click the XML file whose location you want to specify.
4. In the XML File Destination area, click the Browse button. The Browse for Directory dialog box opens.
6. Click OK.
InstallShield adds the destination that you specified to the Specify the location of the XML file on the target machine
box.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
When you add an XML file reference in the XML File Changes view, InstallShield automatically creates a new component for
it. In addition, InstallShield associates the component with the feature that is at the top of your feature list by default. To
change this association, you can use the XML File Changes view.
Note • If your project does not contain any features when you add an XML file reference, InstallShield displays the Create a
New Feature dialog box, which lets you to create a new feature.
Task To associate an XML file change reference with a feature in your project:
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, click the file whose component you want to associate with a feature.
4. In the Select Features the XML file belongs to box, select the check box of any feature that should contain the
selected XML file change reference. This may be the same feature that contains the base XML file that you added to
your project through the Files and Folders view, or it may be a different feature.
If an end user chooses to install the feature that contains the XML file changes, the XML file changes are performed at run
time.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
If you are adding an XML file reference in the XML File Changes view, you can add a root element. Note that an XML file can
contain only one root element.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the XML file to which you want to add a new root element and click New Root
Element.
InstallShield adds the new root element. Use the tabs that are displayed in the right pane to configure its settings.
Tip • To add a root element and one or more levels of subelements in one step, type the name of the root element plus the
subelements, with each separated by a slash. For example, to add a root element called Root, a Sub element under the Root
element, and a Sub2 element under the Sub element, type the following:
Root/Sub/Sub2
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
You can add a new element to the root element or any element in your XML file.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the XML file to which you want to add a new element and click New Element.
InstallShield adds the new element. Rename it as appropriate, and use the tabs that are displayed in the right pane to
configure its settings.
Tip • When you are adding elements and subelements under the root element in the XML File Changes view, you can type the
full XPath expression for the name of the element, and it will automatically expand in the explorer.
To add a root element and one or more levels of subelements in one step, type the name of the root element plus the
subelements, with each separated by a slash. For example, to add a root element called Root, a Sub element under the Root
element, and a Sub2 element under the Sub element, type the following:
Root/Sub/Sub2
InstallShield automatically expands it in the explorer so that each element has its own node.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
If you define .NET configuration settings for your product in a web.config file, you can specify those settings through the
XML File Changes view.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the XML file to which you want to add a configuration element, click Add
Predefined Element, point to .NET Configuration Files, point to Web Configuration File, point to a given set of
settings, and click the appropriate command.
For detailed reference information about the different elements and attributes in .NET configuration files, see
Configuration File Schema on the MSDN Web site (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
cpgenref/html/gngrfnetframeworkconfigurationfileschema.asp).
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
You can add attributes to an element in your XML file and then specify whether the attribute should be created at run time,
the attribute should be removed at run time, or the attribute value should be appended to the existing value at run time.
You can also schedule whether the task should occur during installation, uninstallation, or both.
If an attribute that you add already exists in the XML file on the target machine but the attribute has a different value than
the one that you specified in the XML File Changes view, the installation updates the value at run time.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, click the XML file to which you want to add an attribute.
InstallShield adds a new row—with default values for the Attribute, Value, Operation, and Scheduling columns—to the
attribute table. Change any of the settings as needed. To learn more about each of the columns, see General Tab for an XML
Element.
Tip • If you configure your installation so that the XML file remains on the target system when its component is uninstalled,
you may want to create installation/uninstallation attribute pairs in the attribute table.
For example, to add a key attribute during installation and remove that same key attribute during uninstallation, add two
rows with the key attribute to the attribute table; schedule one row for installation, and the other for uninstallation.
See Also
Using Reserved Characters (<, >, &, ', and ") Inside Elements
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
InstallShield enables you to edit the value of an attribute if it is already present on the target machine at run time. To do so,
add the attribute to the element in the XML File Changes view, and configure the value for the attribute as needed. The
procedure for editing an attribute value is the same as adding an attribute value. To learn more, see Adding an Attribute to
an Element.
At run time, if a different value exists for the attribute, the installation replaces the value with the one that you configured
in the XML File Changes view.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
XML elements can contain text content. For example, in the following XML code, feature is the content for the element
product:
<product>feature</product>
Task To add content to one of the elements listed in the XML File Changes view:
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, select the element to which you want to add content.
When you type a value for this setting, you are creating a string entry and setting its initial value for all of the languages
that are currently in the project. As an alternative to typing a new value, you can click the ellipsis button (...) next to
this setting to select an existing string. For more information, see Using String Entries in InstallShield.
See Also
General Tab for an XML Element
Advanced Tab for an XML Element
Using Reserved Characters (<, >, &, ', and ") Inside Elements
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
In order for your installation to add a new element or attribute to an XML file, or to perform some other change to an XML
file at run time, MSXML must use the XPath expressions that are defined in the XML File Changes view to navigate through
the XML file and locate the areas that need to be modified.
For detailed information about writing XPath expressions, see the following Web sites:
• W3 Schools (http://w3schools.com)
The following sections show examples of how to create some basic XPath expressions.
To add those elements, the following XPath expressions are added under the Biographies node in the XML File Changes
view:
Book[@Author="John Smith"]
Book[@Author="Bill Smith"]
The following screen shots show the settings in the XML File Changes view.
Figure 4-2: Settings for the Biographies Node, which Contains the Child Nodes to Be Added
Figure 4-3: General Settings for One of the Child Nodes to Be Added
Figure 4-4: Advanced Settings for One of the Child Nodes to Be Added
Figure 4-5: General Settings for One of the Child Nodes to Be Added
Figure 4-6: Advanced Settings for One of the Child Nodes to Be Added
The following screen shot shows the settings in the XML File Changes view.
To update the value, the following XPath expression is added under the Biographies node in the XML File Changes view:
Book[@Copyright="2006"]
The following screen shot shows the settings in the XML File Changes view.
See Also
Searching for XML Data
XML File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
For Basic MSI, DIM, InstallScript MSI, Merge Module, MSI Database, and Transform projects, you can use a Windows Installer
property to specify an XML element, an attribute, an attribute value, or an element’s content. At run time, Windows
Installer uses MsiFormatRecord to resolve the property value, and it uses that value as the data in your XML file. This
enables you to use data that end users enter in dialogs, or other configuration information that is determined during the
installation, in your product’s XML files.
For example, your installation may include the SQL Login dialog, which lets end users select a SQL Server. The name of the
server that they select is typically stored in the IS_SQLSERVER_SERVER property. If you want an XML file to contain the name
of the SQL server that an end user selects, you can use this property, surrounded by brackets (that is,
[IS_SQLSERVER_SERVER]), when you configure your XML file changes in the XML File Changes view. Then at run time,
Windows Installer automatically replaces the property with its associated value.
Tip • Use a Windows Installer property for an element, an attribute, or element content only if the value of the property would
make a well-formed XML document. If a property value would lead to syntax errors in the XML document, your product or
installation may not behave as expected.
For example, if you set the name of an element to [INSTALLDIR]—a Windows Installer property whose value is a path on the
target system—the result at run time is an element name that contains backslashes. Element names cannot contain
backslashes, and XML documents that contain element names with backslashes are not valid.
Note • If test your XML file from within the XML File Changes view, any Windows Installer properties that are used for XML data
are not replaced with the appropriate values during testing. For more information about testing, see Testing Installation
Changes to an XML File or Testing Uninstallation Changes to an XML File.
Example
The following procedure demonstrates how to use the name of the SQL Server that an end user selects in the SQL Login
dialog as the content for one of the elements in your XML file. Note that you can substitute a hard-coded value with a
property for any of the elements, attributes, attribute values, or element content in the XML File Changes view. The
property that you specify in this view must be enclosed within square brackets, and the property name must be in all
uppercase letters; for example, [MYPROPERTY].
Task To use the name of the SQL Server that end users select as the content for an XML element:
1. Configure the SQL connection and any associated SQL scripts if you have not already done so, and determine the
name of the server property name:
b. Add a SQL connection and SQL scripts as needed. For instructions, see Configuring SQL Support.
e. Note the name that is selected for the Target Server Property Name setting. The default value is typically
IS_SQLSERVER_SERVER.
2. In the View List under System Configuration, click XML File Changes.
3. In the XML Files explorer, select the element to which you want to add content.
6. In the Content box, type the name that is selected in step 1e, and enclose it within brackets. For example:
[IS_SQLSERVER_SERVER]
See Also
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
For InstallScript projects, you can use a text substitution string variable for an XML element, an attribute, an attribute
value, or an element’s content. When the XML file changes occur at run time, the InstallScript run-time code uses the
TextSubSubstitute function to replace the string variable with the appropriate value. This enables you to use data that
end users enter in dialogs, or other configuration information that is determined during the installation, in your product’s
XML files.
Tip • Use text substitution for an element, an attribute, or element content only if the value of the property would make a
well-formed XML document. If a property value would lead to syntax errors in the XML document, your product or installation
may not behave as expected.
For example, if you set the name of an element to a text substitution string variable that will be replaced with text that
includes one or more spaces, end users may have problems with your product or your installation. Element names cannot
contain spaces, and XML documents that contain element names with spaces are not valid.
Note • If test your XML file from within the XML File Changes view, any text substitution string variables that are used for XML
data are not replaced with the appropriate values during testing. For more information about testing, see Testing Installation
Changes to an XML File or Testing Uninstallation Changes to an XML File.
Example
The following procedure demonstrates how to use the name of the SQL Server that an end user selects in the SQL Login
dialog as the content for one of the elements in your XML file. Note that you can substitute a hard-coded value with a text
substitution string variable for any of the elements, attributes, attribute values, or element content in the XML File Changes
view. The string variable that you specify in this view must be enclosed within angle brackets; for example,
<MYPROPERTY>. The string variable that you specify is case-sensitive.
Task To use the name of the SQL Server that end users select as the content for an XML element:
1. Configure the SQL connection and any associated SQL scripts if you have not already done so:
b. Add a SQL connection and SQL scripts as needed. For instructions, see Configuring SQL Support.
2. In the View List under System Configuration, click XML File Changes.
3. In the XML Files explorer, select the element to which you want to add content.
<MYPROPERTY>
8. Find the dialog code in the OnSQLLogin event for the SQL Login dialog that contains the SQL Server control, and add a
call to the InstallScript function TextSubSetValue. For example:
See Also
Text Substitutions
Using Reserved Characters (<, >, &, ', and ") Inside Elements
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
If you use a reserved character such as a less than symbol (<) inside an XML element, the MSXML parser converts it at run
time on target systems to its predefined entity (<). Using the less than symbol instead of its entity would generate an
error because XML parsers would interpret it as the start of a new element, and it would result in invalid XML code. Note
that if you open the resulting XML file in a browser such as Internet Explorer, the character—not its entity—is displayed
inside the XML element.
The following table lists the reserved XML characters and their entity equivalents. The table also indicates whether each
reserved character is replaced by its entity at run time.
< < Less than This character cannot be used as content in an XML element
because it is reserved to be used to indicate the start of an XML
element.
> > Greater than This character is automatically replaced by its entity at run time.
& & And This character cannot be used as content in an XML element
unless it indicates the start of an entity.
’ ' Apostrophe This character is not automatically replaced by its entity at run
time.
" " Quotation mark This character is not automatically replaced by its entity at run
time.
See Also
Adding an Attribute to an Element
Adding Content to an Element
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
XML namespaces provide a method for avoiding element name conflicts. When you are specifying XML file changes in
InstallShield, you can specify the namespace mappings that should be declared in the XML file and then specify namespace
prefixes for any of the file’s elements.
Tip • If you use the Import XML Settings Wizard to import an XML file into the XML File Changes view, InstallShield imports any
namespaces that are declared for the file.
See Also
Namespace Tab for an XML File
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
You can declare namespace mappings for an XML file in the XML File Changes view.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, click the XML file that should contain the namespace.
5. In the Prefix column, type the prefix that should be used for any elements that are associated with the corresponding
namespace.
6. In the URI column, type a URL or a string of characters that identifies the Internet resource.
See Also
Namespace Tab for an XML File
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
If you have declared a namespace mapping for an XML file, you can associate any element in the file with that namespace
by adding the corresponding prefix to the element.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the element to which you want to add a prefix and then do one of the following:
• To add a prefix to only the selected element, point to Namespace Prefix, and then click to the appropriate
namespace mapping.
• To add a prefix to the element and all of its subelements, point to Namespace Prefix (include all subelements),
and then click to the appropriate namespace mapping.
InstallShield adds the prefix to the element (and all of its subelements, if appropriate) in the XML Files explorer.
Tip • You can also add a namespace prefix by right-clicking an element, clicking Rename, and adding the prefix and the colon
(:) before the element name.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
If you have declared a namespace mapping for an XML file, you can associate any attribute in the file with that namespace
by adding the corresponding prefix to the attribute.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, click the element that contains the attribute.
4. In the grid, double-click the attribute to which you want to add the prefix, and then place the cursor at the start of the
attribute name.
5. Add the prefix and a colon (:) before the attribute name.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, click the element that contains the attribute.
4. In the grid, double-click the attribute from which you want to remove the prefix, and then place the cursor at the start
of the attribute name.
5. Delete the prefix and a colon (:) before the attribute name.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the element whose prefix you want to remove, and then do one of the following:
• To remove the prefix from only the selected element, point to Namespace Prefix, and then click <None>.
• To remove the prefix from the element and all of its subelements, point to Namespace Prefix (include all
subelements), and then click <None>.
InstallShield removes the prefix from the element (and all of its subelements, if appropriate) in the XML Files explorer.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, click the XML file that contains the namespace that you want to remove.
4. Click the row that contains the namespace mapping that you want to remove, and then click the Delete button.
See Also
Namespace Tab for an XML File
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
InstallShield enables you to test just the XML file changes that are configured for your project through the XML File Changes
view without requiring you to build and run your entire installation. When you test the installation changes, InstallShield
uses the latest version of MSXML that you have on your machine to parse the XML file and execute the XPath expressions
that you configured. When MSXML finds an area of the XML file that matches the XPath expression, the changes that were
configured in the XML File Changes view are made.
Note • If your XML file changes include Windows Installer properties or InstallScript text substitutions, they are not replaced
with the appropriate values during testing.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the XML file that you want to test and then click Test XML File Install Changes.
The Select Test XML File dialog box opens.
3. In the File name box, select the target file to which you want the installation changes applied, or specify a new target
file name and location:
• If you are modifying an XML file that is installed as part of your installation, select a copy of that file. (Do not select
the actual file in your installation because testing the XML installation changes would modify it.)
• If you are modifying an XML file that already exists on the target system, select a copy of that file.
• To test what happens if the XML file does not exist at run time and it is not installed as part of your installation,
specify a new file name and location.
The default file name is the name of the test file that you right-clicked in step 2.
4. Click Open.
If the target file already exists, InstallShield applies the changes from the test file to the target file. If the target file that you
specified does not exist and the Always create XML file if it does not already exist check box is selected on the Advanced
tab for the XML file, InstallShield creates the file and applies the changes from the test file.
InstallShield displays details about the installation test on the Results tab of the Output window. The details include a
hyperlink to the test file.
Tip • If the target file is open in a browser window when you perform the testing, you may need to refresh the browser to see
the test changes.
See Also
Using Windows Installer Properties to Dynamically Modify XML Files
Using InstallScript Text Substitution to Dynamically Modify XML Files
XML File Changes View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
After you have tested the XML file installation changes that you have configured through the XML File Changes view, you
may want to test the XML file changes that occur during uninstallation. This enables you to determine whether the changes
that you configured behave as you expected during uninstallation.
When you test the uninstallation changes, InstallShield uses the latest version of MSXML that you have on your machine to
parse the XML file and execute the XPath expressions that you configured. When MSXML finds an area of the XML file that
matches the XPath expression, the changes that were configured in the XML File Changes view are made.
Note • If your XML file changes include Windows Installer properties or InstallScript text substitutions, they are not replaced
with the appropriate values during testing.
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the XML file that you want to test and then click Test XML File Uninstall Changes.
The Select Test XML File dialog box opens.
3. In the File name box, select the target file to which you want the uninstallation changes applied.
The default value is the name of the file whose installation changes you last tested.
4. Click Open.
InstallShield applies the uninstallation changes that are configured in the XML File Changes view to the test file.
InstallShield displays details about the uninstallation test on the Results tab of the Output window. The details include a
hyperlink to the test file. Note that if you have configured the XML file to be removed during uninstallation, the hyperlink
may not work, since the file may no longer be present.
Tip • If the target file is open in a browser window when you perform the testing, you may need to refresh the browser window
to see the test changes.
See Also
XML File Changes View
Removing an Element or an XML File from the XML File Changes View
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
Task To remove an element or an XML file from the XML File Changes view:
1. In the View List under System Configuration, click XML File Changes.
2. In the XML Files explorer, right-click the XML file or XML element that you want to remove and click Delete.
If you delete an XML file, InstallShield displays a message that explains that the component associated with the XML file will
be deleted along with the file itself.
See Also
XML File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes string functions for
finding and modifying string variables and literals. You can use these functions in InstallScript projects.
InstallShield enables you to 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. The text files can be part of your
installation, or they can be files that are already present on target systems.
The Text File Changes view is where you define the changes that you want to be made to the text files. This view lets you do
the following:
• Add one or more text change sets to your project. A text change set is a reference to one or more text files that you
want to search at run time.
• Add one or more text change items to a text change set. A text change item identifies the search-and-replace criteria.
For more information on how to modify a text file at run time, consult this section of the documentation.
See Also
Specifying the Code Page that Should Be Used for Opening ANSI Text Files
Text File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes string functions for
finding and modifying string variables and literals. You can use these functions in InstallScript projects.
The first step in configuring text file changes is to create a reference to the file (or files) that you would like to edit; this
reference is called a text change set. The file can be any non-binary file—for example, a .txt, .htm, .xml, .config, .ini, or .sql
file. The file can be part of your installation (that is, one that you added to your project in the Files and Folders view), or it
can be a file that is already present on target systems.
Note • Each text change set must be associated with a component in your project. Therefore, before you can create a text
change set, your project must have at least one component. If no components exist when you are creating a text change
reference, the Create a New Component dialog box is displayed, enabling you to create a component.
Task To create a text change set to reference one or more text files that you want to change at run time:
1. In the View List under System Configuration, click Text File Changes.
2. Right-click the Text File Changes explorer and then click Add Change Set.
3. Enter a new name, or right-click it later and click Rename to give it a new name.
The name is not displayed at run time; it is an internal name that is used to differentiate between various change sets
in your project.
4. In the right pane, configure the settings for the change set. For details about each setting, see Change Set Settings.
After you have created a reference to a text file and configured its settings, you can move on to the next step, which is to
specify the search-and-replace criteria.
Tip • You can use Windows Installer public properties to specify the names of the text files that you want to include in or
exclude from your search. This enables you to use data that end users enter in dialogs, or other configuration information that
is determined at run time, when your product’s text files are modified at run time. To learn more, see Using Windows Installer
Properties to Dynamically Modify Text Files.
See Also
Specifying the Code Page that Should Be Used for Opening ANSI Text Files
Text File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes string functions for
finding and modifying string variables and literals. You can use these functions in InstallScript projects.
Once you have specified the text file that you would like to edit, you can move onto the next step of configuring text file
changes: specifying the search-and-replace criteria. Each set of criteria is known as a change item.
Task To specify the change that you want to be made for a text file:
1. In the View List under System Configuration, click Text File Changes.
2. In the Text File Changes explorer, right-click the change set item whose text changes you want to define, and then
click Add Change.
3. Enter a new name, or right-click it later and click Rename to give it a new name.
The name is not displayed at run time; it is an internal name that is used to differentiate between various change items
in your project.
4. In the right pane, configure the settings for the change. For details about each setting, see Change Set Settings.
To modify additional strings in the text file, add additional change items to the change set in this view—one for each string
change.
Tip • You can use Windows Installer public properties to specify the search strings and the replacement strings. This enables
you to use data that end users enter in dialogs, or other configuration information that is determined at run time, when your
product’s text files are modified at run time. To learn more, see Using Windows Installer Properties to Dynamically Modify Text
Files.
See Also
Text File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes string functions for
finding and modifying string variables and literals. You can use these functions in InstallScript projects.
Text file changes are made on the target system in the order in which they are listed in the Text File Changes view.
Task To change the order in which text file changes are made at run time:
1. In the View List under System Configuration, click Text File Changes.
2. In the Text File Changes explorer, right-click one of the change set items or change items that you want to move, and
then click either Move Up or Move Down.
Repeat the last step until all of the text file changes are correctly sorted.
See Also
Text File Changes View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes string functions for
finding and modifying string variables and literals. You can use these functions in InstallScript projects.
You can use a Windows Installer property to specify text strings for which you are searching or modifying. You can also use
a property to specify the text files that you are including or excluding in your search.
At run time, Windows Installer uses MsiFormatRecord to resolve the property value, and it uses that value to modify your
text file. This enables you to use data that end users enter in dialogs, or other configuration information that is determined
at run time, when your product’s text files are modified at run time.
Example
The following procedure demonstrates how to let end users specify during installation an IP address that must be written
to an XML-based web.config file at run time. The web.config file is installed with the product to INSTALLDIR, and it
contains XML such as the following:
The default value in bold must be replaced by the IP address that an end user enters.
Note that you can substitute a hard-coded value with a property for the following change set settings in the Text File
Changes view:
• Include Files
• Exclude Files
In addition, you can use a property for the following change item settings in the Text File Changes view:
• Find What
• Replace With
• Insert Text
The property that you specify in any of these settings must be enclosed within square brackets, and the property name
must be all uppercase; for example, [MYPROPERTY].
Step 4 of the procedure is slightly different, depending on the project type, since Windows Installer controls the user
interface of Basic MSI installations, and the InstallScript engine controls the user interface of InstallScript MSI installations.
1. In the View List under System Configuration, click Text File Changes.
2. Add and configure a change set item, which identifies the file for which you want the installation to search:
a. Right-click the Text File Changes explorer and then click Add Change Set.
InstallShield adds a new change set item. Steps 2b through 2d explain how to configure its settings, which are
displayed in the right pane.
web.config
3. Add and configure a change item, which identifies the search-and-replace criteria:
a. In the Text File Changes explorer, right-click the change set item that you created in step 2, and then click Add
Change.
InstallShield adds a new change item. Steps 3b through 3e explain how to configure its settings, which are
displayed in the right pane.
4. Use the property in a dialog. This part of the procedure depends on which project type you are using.
b. In the Dialogs explorer, expand the All Dialogs folder, and click the language under the dialog that should
contain the User Name control. As an alternative, you can add a new dialog.
c. Add an Edit Field control to the dialog, and set its Property property to the following:
MYPROPERTY
b. Find the dialog code in the OnFirstUIBefore event for the dialog that should contain the User Name control,
and add a call to the Windows Installer API function MsiSetProperty. For example, if you want end users to
enter the IP address in an edit box on the SdShowDlgEdit1 dialog that you have added to your project, you
would add an MsiSetProperty call as shown in the following lines of code:
Dlg_SdShowDlgEdit1:
nResult = SdShowDlgEdit1 (szTitle, szMsg, szField1, svEdit1);
MsiSetProperty (ISMSI_HANDLE, "MYPROPERTY", svEdit1);
if (nResult = BACK) goto Dlg_SdWelcome;
Tip • If you are creating a multilanguage project and you want to use a property that can have different values based on the
language that your installation uses, you can use a localizable property. For more information, see Creating a Localizable
Property.
See Also
MsiFormatRecord (Windows Installer Help Library)
MsiFormatRecord (Windows Installer Help Library)
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
Working with Dialogs in Basic MSI Projects
Working with Dialogs in InstallScript and InstallScript MSI Projects
Dialog Functions
Dialog Customization Functions
Specifying the Code Page that Should Be Used for Opening ANSI Text Files
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes string functions for
finding and modifying string variables and literals. You can use these functions in InstallScript projects.
When an installation opens an ANSI text file to make the changes that are configured in the Text File Changes view, the
installation uses the code page that is specified in the CodePage column of the ISSearchReplaceSet table of your project.
The default value of this column is the number 0, which is CP_ACP, the code page that is currently configured to be the
system Windows ANSI code page on the target system. You can use the Direct Editor view to override this value with a
specific code page.
CodePage column is of 2-byte (signed). In order to provide a CodePage value greater than 32,767, you have to provide in
the form of 2's complement.
For example:
Task To override the default code page that should be used to open an ANSI text file:
2. In the Tables explorer, click the ISSearchReplaceSet table. InstallShield displays the table in the right pane.
3. In the grid, find the row that corresponds with the change set item whose code page you want to configure.
The ISSearchReplaceSet column in this grid shows all of the names of the change sets that are available in the Text
File Changes explorer in the Text File Changes view.
See Also
Direct Editor
Text File Changes View
Removing a Change Item or a Change Set from the Text File Changes View
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
This information does not apply to InstallScript projects; however, the InstallScript language includes string functions for
finding and modifying string variables and literals. You can use these functions in InstallScript projects.
If you no longer want a particular change to be performed to a text file, you can remove its change item from the Text File
Changes view. In addition, if you no longer want a file or group of text files to be searched, you can remove the
corresponding change sets from the Text File Changes view.
Task To remove a change item or a change set from the Text File Changes view:
1. In the View List under System Configuration, click Text File Changes.
2. In the Text File Changes explorer, right-click the change set item or change item that you want to remove, and then
click Delete.
InstallShield removes the item from the Text File Changes view.
See Also
Text File Changes View
Scheduling Tasks
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
You can have your installation create and configure automated tasks through the Windows task scheduler at run time on
target systems. The scheduled tasks can launch files that are part of your installation, or files that are already present on
target systems.
See Also
Adding a Scheduled Task
Scheduled Tasks View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
Note • Each scheduled task must be associated with a component in your project. Therefore, before you can add a scheduled
task, your project must have at least one component. If no components exist when you are adding a scheduled task, the Create
a New Component dialog box is displayed, enabling you to create a component.
2. Right-click the Scheduled Tasks explorer and then click Add Scheduled Task. InstallShield adds a new task with a
default name.
3. Enter a new name, or right-click it later and click Rename to give it a new name.
The name is not displayed at run time; it is an internal name that is used to differentiate between various scheduled
tasks in your project.
4. In the right pane, configure the settings for the task. For details about each setting, see Scheduled Tasks Settings.
See Also
Scheduled Tasks View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
You can use a Windows Installer property to specify information such as the account information that should be used to
run the file that a scheduled task launches.
At run time, Windows Installer uses MsiFormatRecord to resolve the property value, and it uses that value to configure
your scheduled task. This enables you to use data that end users enter in dialogs, or other configuration information that is
determined at run time, when your product’s scheduled tasks are created at run time.
Example
The following procedure demonstrates how to let end users specify during installation an account and password that
should be used to run the scheduled task. The properties that you specify must be enclosed within square brackets, and
the property names must be all uppercase; for example, [MYPROPERTY].
Step 4 of the procedure is slightly different, depending on the project type, since Windows Installer controls the user
interface of Basic MSI installations, and the InstallScript engine controls the user interface of InstallScript MSI installations.
Task To let end users specify account and password information for the scheduled task:
2. In the Scheduled Tasks explorer, select the task that you want to configure.
[DOMAINNAME]\[USERNAME]
[PASSWORD]
5. Use the properties in a dialog. This part of the procedure depends on which project type you are using.
b. In the Dialogs explorer, expand the All Dialogs folder, and click the language under the dialog that should
contain Domain Name, User Name, and Password controls. As an alternative, you can add a new dialog.
c. Add an Edit Field control to the dialog, and set its Property property to the following:
DOMAINNAME
b. Find the dialog code in the OnFirstUIBefore event for the dialog that should contain the Domain Name, User
Name, and Password controls, and add a call to the Windows Installer API function MsiSetProperty. For
example, if you want end users to enter the information in edit boxes on the SdShowDlgEdit3 dialog that
you have added to your project, you would add MsiSetProperty calls as shown in the following lines of
code:
Dlg_SdShowDlgEdit3:
nResult = SdShowDlgEdit3
(szTitle, szMsg, szField1, szField2, szField3, svEdit1, svEdit2, svEdit3);
MsiSetProperty (ISMSI_HANDLE, "DOMAINNAME", svEdit1);
MsiSetProperty (ISMSI_HANDLE, "USERNAME", svEdit2);
MsiSetProperty (ISMSI_HANDLE, "PASSWORD", svEdit3);
if (nResult = BACK) goto Dlg_SdWelcome;
See Also
Scheduled Tasks View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• Transform
2. In the Scheduled Tasks explorer, right-click the task that you want to remove and then click Delete.
See Also
Scheduled Tasks View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Windows services are executable files that Windows–based systems run in the background to manage various system
tasks, even if no user is currently logged in. A service is an executable file, but it must be designed as a service; you cannot
automatically use an arbitrary executable file as a service. Windows services can be installed to run every time that the
system starts or on demand when needed. InstallShield enables you to install new Windows services and configure existing
services. Windows has a Services administrative tool with which you can view and configure the services that are installed
on a system.
You can use the Services view to configure a component that installs, starts, stops, or deletes a service during installation
or uninstallation. You can also use this view to configure extended service customization options that are available with
Windows Installer 5. As an alternative to using the Services view, you can use the Services area under the Advanced
Settings node of the Components view or the Setup Design view. If you configure service information in any of these areas,
the other areas are automatically updated accordingly.
• The service that you are starting, stopping, deleting, or configuring can either be already present on the target system
during installation or uninstallation, or it can be installed as part of your installation.
• The service executable file should be the key file of its component. For more information, see Component Key Files.
• The Remote Installation setting for the service’s component must be set to Favor Local. For more information, see
Setting a Component’s Remote Installation Setting.
Tip • The View Filter at the top of the Services view lets you select a component or feature whose service data you want to
display in the view, and hide the ones whose service data you do not want to display in the view. The View Filter lists your
project’s hierarchy of features, subfeatures, and components.
1. If your installation is installing the service, add the service executable file to a component in your project, and make it
the key file of the component. For more information, see Adding Files to Components.
3. Right-click the Services node and then click Add Service. InstallShield adds a new service.
4. Type a new name for the service now, or click it and then press F2 later to rename it.
The name that you enter must match the name that is shown on the service’s Properties dialog box. (To access an
installed service’s properties: In the Services administrative tool, right-click the service and then click Properties.)
5. Select the service that you added, and then configure the settings that are displayed in the right pane as needed. For
information about each of the settings, see Services View.
Repeat the process for each service in this component’s key file.
Note • You must be familiar with the technical details of your service before you can configure its settings.
Tip • If configuring the service fails at run time, the installation may fail with an error message. ICE102 validates some of the
service-related settings to help avoid such configuration failures. Therefore, it is recommended that you perform validation for
your release.
See Also
Services View
• Basic MSI
• InstallScript MSI
InstallShield has support for creating one or more Windows user accounts in groups without using logon dialogs. This
support requires using three Windows Installer properties for the user account, group, and password of each account that
you want to be set up at run time.
• ISNetApiLogonUsername—Set the value of this property to the user account that you want the installation to create.
Use either of the following formats:
• MachineName\UserName
• DomainName\UserName
• ISNetApiLogonGroup—Set the value of this property to the group to which you want the user account to belong.
• ISNetApiLogonPassword—Set the value of this property to the password that you want to be configured for the user
account.
To configure the required properties and their values, use the Properties view. For instructions on how to do this, see
Creating Properties in Windows Installer–Based Projects.
Domain1\User1[~]Machine2\User2
Each user account that you specify for the ISNetApiLogonUsername property must have a corresponding group in the
ISNetApiLogonGroup property and a corresponding password in the ISNetApiLogonPassword property. If these three
properties do not have the same number of entries, a run-time error occurs.
The following table shows sample properties and their corresponding values for the creation of three different user
accounts:
ISNetApiLogonUsername Domain1\User1[~]Domain1\User2[~]Domain2\User3
ISNetApiLogonGroup Users[~]Users[~]Administrators
ISNetApiLogonPassword Password1![~]Password1![~]Password1!
In this example, User1 is part of the Users group and has a password of Password1! for the Domain1 domain. User2 is part
of the Users group and has a password of Password1! for the Domain1 domain. User3 is part of the Administrators group
and has a password of Password1! for the Domain2 domain.
• [PROPERTYNAME]—At run time, this resolves to the value of the specified property.
• [%EnvironmentVariable]—At run time, this resolves to the value of the specified environment variable.
• [#FileKey]—At run time, this resolves to the full path of the file that has the specified file key in the File table.
• [$ComponentName]—At run time, this resolves to the installation location of the specified component.
See Also
Adding the Ability to Create or Set an Existing User Account
Two Windows Installer properties, along with the current user’s privileges, affect where the configuration information such
as your product’s shortcuts and registry entries are stored on a target machine—to the All Users profile or the current user’s
profile:
• MSIINSTALLPERUSER indicates that the Windows Installer should install the package for only the current user.
The MSIINSTALLPERUSER property is available with Windows Installer 5 and on Windows 7 or Windows Server 2008 R2.
Earlier versions of Windows Installer and Windows ignore this property.
You can set the ALLUSERS and MSIINSTALLPERUSER properties for your project through the Property Manager. You can also
set these properties using the following methods:
During a per-machine installation, the Windows Installer requires elevated privileges, and it directs files and registry
entries to per-machine locations. If User Account Control (UAC) is available on the target system, a per-machine
installation typically prompts for consent or credentials, depending on the access level of the user. During a per-user
installation, the Windows Installer does not prompt for credentials, and it redirects files and registry entries to per-user
locations.
For more information, see Single Package Authoring on the MSDN Web site.
When a per-user installation (that is, one where ALLUSERS is not set) is run, deferred-in-system-context actions run in the
same context in which normal deferred or immediate custom actions run, which is with user impersonation. This can
potentially cause a run-time issue with the custom action in the following circumstances:
• The user who launches the Windows Installer installation is not an administrator; or the user is running the installation
on Windows Vista or later, the user is part of the Administrators group, and the user does not have administrator
privileges by default.
• The custom action attempts to modify a resource in a per-machine location on the machine, such as a file in the
Program Files folder, or a registry key or value in HKEY_LOCAL_MACHINE.
While this may not be an issue with Windows XP or earlier versions of Windows, Windows Vista and later do not give users
full administrator privileges by default. Therefore, since a deferred-in-system-context action runs with user impersonation
when ALLUSERS is not set, the custom action could fail.
The recommended method for preventing this behavior is to specify that a per-machine installation should always be
performed by setting ALLUSERS to 1 in the Property Manager. Per-machine installations are generally easier to manage than
per-user installations.
• No—InstallShield does not set any related properties. At run time, the ReadyToInstall dialog does not include the
buttons that let end users specify how they want to install the product. This is the default value.
If the following conditions are true at run time, the ReadyToInstall dialog includes the per-user and per-machine buttons:
• The target system has Windows 7 or later, or Windows Server 2008 R2 or later.
The buttons on the ReadyToInstall dialog let end users specify how they want to install the product. If elevated privileges
are required, the shield icon is included on the all-users button. If an end user selects the per-user button, the ALLUSERS
property is set to 2, and the MSIINSTALLPERUSER property is set to 1. If an end user selects the all-users button, the
ALLUSERS property is set to 1, and the MSIINSTALLPERUSER property is not set.
Note • Selecting No for the Show Per-User Option setting in the General Information view does not prevent end users from
setting MSIINSTALLPERUSER from the command line when they run your installation. If your installation does not support this,
you may want to add a launch condition or other run-time check to prevent this from occurring.
Task To display the radio button group that lets end users set ALLUSERS from the CustomerInformation dialog:
2. In the Dialogs explorer, under All Dialogs, expand the CustomerInformation dialog, and then click Behavior.
InstallShield displays the list of controls for the CustomerInformation dialog.
3. At the bottom of the lower-right pane, click the Conditions tab. In the upper-right pane, InstallShield displays the
conditions for the selected control.
4. In the list of controls, click DlgRadioGroupText. InstallShield displays this control’s conditions in the upper-right
pane.
5. In the upper-right pane, right-click the row that contains the condition whose value is 1 and whose action is Hide, and
then click Delete.
See Also
Creating Properties in Windows Installer–Based Projects
SdCustomerInformation
SdCustomerInformationEx
ALLUSERS Property (Windows Installer Help Library)
ALLUSERS Property (Windows Installer Help Library)
InstallShield enables you to create InstallScript installations that can be run by end users who do not have administrative
privileges. The proper locations of registry entries, folders, and Start Menu items are dynamically determined at run time.
The InstallScript system variable ALLUSERS is the key to such installations; if an installation is run by an end user who does
not have administrative privileges, ALLUSERS is initialized to FALSE, and assigning it a new value in the script has no effect.
• Automatic registration of files (which are included in components that have Yes selected for the Self-Register setting)
requires administrative privileges.
• InstallScript objects typically require administrative privileges, since they usually install or register files in locations
that require administrative privileges.
• Installing the Setup Player for a One-Click Install installation requires administrative privileges.
• If an end user who is not an administrator or power user attempts to maintain an InstallScript installation that was
installed when ALLUSERS was set to TRUE, the installation displays an error message during initialization. The error
message indicates that a user with administrator rights installed the product, and similar privileges are needed to
modify or uninstall the product.
See Also
ALLUSERS
An important aspect of creating an installation is customizing it for your end users’ needs. The “Customizing Installation
Behavior” section of the documentation discusses various features of InstallShield that help you extend the functionality of
your installation. For example, you may find it useful to create custom actions to add support for something not directly
supported by Windows Installer. Furthermore, you may set up custom actions to call any script that you write in the
InstallScript view’s script editor. Refer to this section of the documentation for more information on how you can
customize the installation behavior in your project.
Using InstallScript
InstallShield 2020
You can leverage the power and ease of InstallScript to extend the functionality of your installation package. The
InstallScript view includes a script editor pane for you to author your InstallScript code.
Project • You must have a file named Setup.rul in your project if you are using InstallScript. InstallScript and InstallScript
MSI projects contain a Setup.rul file by default. You must add a Setup.rul file in Basic MSI, DIM, and Merge Module projects if
you want to use InstallScript custom actions in these types of projects.
1. Add a blank Setup.rul to your project in the InstallScript view if it does not already exist.
2. Write an entry-point function. Note that you cannot call an entry-point function in the User Interface sequence for an
InstallScript MSI installation project.
5. Invoke the InstallScript custom action by either including it in a sequence (InstallScript MSI, Basic MSI, and merge
module projects) or executing it as a control event (Basic MSI and merge module projects).
6. Debug if necessary.
Note • As with other custom actions, changes made to the system through InstallScript custom actions are not automatically
restored when the package is uninstalled. Because InstallScript custom actions are not logged and removed by the
uninstaller, you must write a corresponding custom action to uninstall any changes that your custom action makes.
See Also
Event Handlers
InstallScript View
InstallScript Functions that Are Logged for Uninstallation
Defining Sequences
InstallScript Limits
Working with the Script Editor Pane in Various Views
Overview of ISSetup.dll
InstallShield 2020
ISSetup.dll is a C++ MSI DLL that contains the full InstallScript scripting run-time engine. For InstallScript MSI, Basic MSI,
DIM, and Merge Module projects, ISSetup.dll executes InstallScript custom actions. For InstallScript projects,
ISSetup.dll must be in the Disk1 folder.
Your installation always uses the InstallScript scripting run-time engine with which it was built, even if more a more recent
version is installed on a target machine by another installation.
• ISSetup.dll allows you to add only 1,000 InstallScript custom actions to your InstallScript MSI, Basic MSI, DIM, or Merge
Module project. If your project includes more than 1,000 InstallScript custom actions, a build error is generated.
• The version of ISSetup.dll that is used for InstallScript projects is different than the one that is used in InstallScript MSI,
Basic MSI, DIM, and Merge Module projects. These two versions are not interchangeable.
See Also
Redistributable Files that Are Distributed with an InstallScript Installation
Upgrading Projects from InstallShield 11.5 or Earlier
InstallScript Limits
Script Files
InstallShield 2020
When you create an installation project, InstallShield creates two script files and stores them in the Script Files folder of
your project folder.
Initially, these two files are empty; the default event handlers defined by InstallShield do not appear in these files unless
you select them from within the InstallScript view in InstallShield. When you do so, they are inserted into the appropriate
script file and displayed in the script pane in the InstallScript view, where you can edit them.
Note that if you change the default feature event handler code in FeatureEvents.rul, you must put the following
statement in Setup.rul to include your changes in the installation:
#include "FeatureEvents.rul"
See Also
Working with the Script Editor Pane in Various Views
InstallScript Limits
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
You must have a file named Setup.rul in your project if you are using InstallScript. InstallScript and InstallScript MSI projects
contain a Setup.rul file by default. You must add a Setup.rul file in Basic MSI, DIM, and Merge Module projects if you want to
use InstallScript custom actions in these types of projects.
2. In the InstallScript explorer, right-click Files and click New Script File.
New script files are named Setup.rul by default. If you already have a file called Setup.rul, a new file is added with the
name Setupn.rul, where n is a successive number. You can rename the file by right-clicking it and then clicking Rename.
The new script file is placed in the Link To folder. InstallShield attempts to use a path variable in case you move your
project. You cannot edit the Link To value.
You can also include additional header files (.h files) and script files. Repeat the above procedure to add a new script file to
your project.
See Also
InstallScript View
Predefined Path Variables
Working with the Script Editor Pane in Various Views
InstallScript Limits
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
Task To open a script file in your project so that you can edit it:
2. In the InstallScript explorer, click the file that you want to open.
See Also
Working with the Script Editor Pane in Various Views
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
InstallShield enables you to reuse InstallScript files (.rul) and InstallScript header files (.h) in multiple projects. You can
insert or import script files into a project through the InstallScript view:
• Inserting a script file creates a link to the script file in its current location.
• Importing a script file copies the script file to the folder containing the script files for your project. The script files that
you import can be stored somewhere on your system, or they can be stored in a repository.
InstallShield supports all path variable types that you define in the Path Variables view for the location of these script files.
However, it is important to be aware that a corresponding folder structure exists in your source code database so that your
source code control software can resolve paths.
2. In the InstallScript explorer, right-click Files and then click Insert Script Files. The Open dialog box opens.
3. Select the InstallScript file (.rul) or InstallScript header file (.h) that you want to insert.
4. Click Open.
2. In the InstallScript explorer, right-click Files and then click Import Script Files. The Import InstallScript Files dialog
box opens.
• In the Repository Items box, click the InstallScript file (.rul) or InstallScript header file (.h) that you want to add
to your project.
• If the script file that you want to import is not stored in the repository, click the Browse button to select it.
4. Click OK.
See Also
Debugging Scripts
Using a Repository to Share Project Elements
Working with the Script Editor Pane in Various Views
Compiling Scripts
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
You must compile your script before your InstallScript code can be called in your installation.
InstallShield searches only for a file named Setup.rul when compiling the script. You can include files with different
names, but they must be included in Setup.rul or in an include file with the #include preprocessor statement.
• Press CTRL+F7.
Before compiling, InstallShield saves any changes that you have made to your script files. The compiler’s status, including
any error or warning messages, is displayed in the Output window. Double-click a compiler message to go to the line in
your script where the error was found.
If you compile your script file after making changes to it, it is not necessary to rebuild your release. Note that InstallShield
automatically compiles your script whenever you build a release.
If your script compiled successfully, InstallShield creates Setup.inx (the object code that the setup engine executes) and
streams it into your Windows Installer package when you build a release.
You may also need to uninstall the release that you previously ran to test your InstallScript custom action before you can
see the changes to the script.
You can set compiler options on the Compile/Link tab of the Settings dialog box.
See Also
Debugging Scripts
InstallScript Error Information
Working with Releases
InstallScript Limits
Debugging Scripts
InstallShield 2020
The InstallScript Debugger is useful for stepping through your InstallScript code and checking the progress of your code.
Before you can debug your script, you must first compile it, execute it as a custom action (if applicable), and build a release.
Task To debug your script directly from within InstallShield, do one of the following:
• Press F5.
InstallShield will run the installation and open the InstallScript Debugger when the custom action is executed.
While you are in the InstallScript Debugger, press F1 at any point to view the InstallScript Debugger Help.
For information about debugging on a test system, see Debugging an Installation on any Computer.
See Also
Compiling Scripts
InstallShield 2020
Use the #define and #ifdef statements to create an internal debugger in the script.
1. Wherever you want to insert a debug statement in the script, start with the following #ifdef directive:
#ifdef DEBUG
#endif
DDEBUG=1
#ifdef DEBUG
if nResult < 0 then
WriteLine (LogFileHandle, "PlaceBitmap failed");
endif;
#endif
The InstallScript Debugger enables you to trace program execution and inspect variables as your installation executes.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
Project • InstallScript projects must contain a source file named Setup.rul; that file is the main compilation unit of an
installation script. If your InstallScript project does not include a script file with that name, error C8503 occurs when you
compile your script or build a release.
You can use string identifiers in your script in place of any value that accepts a string literal. When the custom action is
executed, the installation replaces the string identifier with the corresponding string value for the language in which the
installation is running.
String identifiers must follow an at symbol (@) in your script. The Select String dialog box lets you browse the list of string
entries in your project. It also lets you modify string entries for the default language before inserting the selected string
identifier into your script.
For example, assuming your project contains a string identifier called MSG_ACTION_SUCCEEDED, you could display its
value in a message box as demonstrated below:
szMsg = @MSG_ACTION_SUCCEEDED;
nType = INFORMATION;
MessageBox (szMsg, nType);
See Also
Localizing the End-User Interface
String Editor View
How an Installation Determines Which Language to Use for the User Interface
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
When you remove a script file from your installation, you are deleting the reference to that file from your project, but not
the file itself. If you later decide to insert it into your installation, you do not need to rewrite your script.
Note that the script file may, in fact, still be compiled if it is included in another file.
Caution • You cannot rename a file to the name of an existing file under the project location, even if the script file has been
removed through the above procedure. For example, assume you have a script file called Setup.rul in your project. Next,
remove that file and add a new script file, called Script1.rul by default. You cannot rename Script1.rul to Setup.rul,
because doing so would overwrite the first Setup.rul. To avoid this, you should move your original Setup.rul out of your
project folder, rename it, or delete it through Windows Explorer.
InstallScript’s built-in functions are defined in library files (.obl files) to which a script is linked when the script is compiled.
Task To create a library file for functions that you have defined:
1. Create one or more .rul files containing the definitions of your functions.
2. At the command line, for each of your .rul files, run Compile.exe with the -c switch to compile the file without linking
it to any existing library file. This will create an .obs file (rather than the .inx file that is created by compiling without
the -c switch). For example, enter the following command line to create the file MyFunc.obs in the current folder.
Compile MyFunc.rul -c
To create an .obs file with a different name or location, use the -o switch.
3. Run Compile.exe with the -l switch, and one or more .obs files as parameters, to create the library file. For example,
enter the following command line to create the file MyFunc.obl in the current folder.
Compile MyFunc.obs -l
Entering the following command line creates the file MyFunc1.obl in the current folder.
To create an .obs file with a different name or location, use the -o switch.
Tip • If you have many .obs files, you can shorten the command line by using a command file as in the following example:
Compile @MyObsFiles.txt -l
To quickly create the command file, you can use the MS-DOS command DIR with its /b (bare format) switch and redirect the
output to a file. For example:
To compile an installation script using your library file, specify the library file on the command line or—when compiling
within InstallShield—on the Compile/Link Tab of the Settings dialog box.
See Also
Compile.exe
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
If you have an existing InstallScript file (.rul) or InstallScript header file (.h) that you would like to reuse in other projects or
share with other users, you can publish it to a repository.
2. In the InstallScript explorer, right-click the script file that you would like to publish, and then click Publish Wizard.
The Publish Wizard opens.
After you have imported a script file from a repository into a project, there is no link between the current script file and the
existing repository script file. If you make a change to the script file and then republish it to the repository, it does not affect
the script file in the project to which it was imported. However, you can reimport the script file from the repository into
your project.
See Also
Inserting and Importing Script Files
Using a Repository to Share Project Elements
InstallScript Lists
InstallShield 2020
Lists are used to store related information, such as strings or numbers. InstallScript lists are very similar to single-linked
lists in the C language. InstallScript list functions are very flexible, enabling you to return information in an order different
from the order in which it was stored and access and use that information in a variety of ways.
List Functions
InstallShield provides a number of functions for creating and manipulating lists. There are three types of InstallScript list
functions:
InstallShield also has many secondary list-related functions that use or create lists.
List Structure
Lists are used to store related information—either strings or numbers. All the information in a list must be of the same data
type, and the number of elements is limited only by the available memory.
An InstallScript list has two parts. The first part is the head, which InstallShield uses internally. The head of the list contains
general information about the list, such as whether it contains strings or numbers. The head also contains pointers to the
beginning and end of the list.
The second part of the list is the list body. The list body contains the actual strings or numbers. You can have as many
strings or numbers in a list as the memory in the system will allow.
Remember that lists cannot contain both numbers and strings. A list must have only strings or only numbers.
Variables representing lists can be declared as type LIST or type LONG. Lists exist only in memory, meaning they are
destroyed when the installation is complete. If a list is local to a function, the list is destroyed when the function returns
control to the calling code.
See Also
List Processing Functions
InstallShield 2020
Before creating a list, decide which type of list you want to build: a string list or a number (item) list. To create the list, call
the ListCreate function:
–or–
ListCreate automatically builds the head of the list and returns its ID number. The ID is used in all subsequent functions
that operate on the list. Therefore, you must always create a list using ListCreate before you use any other list function.
You must store the return value from ListCreate in a variable of type LIST or type LONG.
This fragment creates a number list and then a string list. It also tests each one to make sure that the lists were created
successfully.
When you are finished using a list, you will typically want to destroy the list to free the memory for other uses. ListDestroy
destroys the list and its contents. This example creates a list referenced by listID, adds a string to the list, and then destroys
the entire list.
If you do not destroy a list using ListDestroy, the list will be destroyed when the installation is complete. If the list is local
to a function, the list is destroyed when the function returns control to the calling code.
See Also
ListCreate
ListDestroy
InstallShield 2020
Function Description
Table 4-1 • Functions that Are Used to Add Elements to Lists (cont.)
Function Description
ListAddString and ListAddItem add a single element to the list that you specify. Remember that, regardless of where you
place the new string in the list, it becomes the current string. Use the options BEFORE and AFTER to indicate where you
want to place the new element in the list relative to the current element. If you are working with a newly created list, using
either BEFORE or AFTER will add the string to the first element position in the list.
Adding elements to a list and the resulting effects on the list order and the element in the current position are most easily
explained by example. The examples below use string lists and ListAddString, but the same principles and steps apply to
using ListAddItem and number lists. Consider these scenarios:
InstallShield 2020
The first string that you add to the list goes immediately after the head of the list. This string (String 1 in the sample code)
becomes the current string in the list. The script fragment shown below results in a list like that depicted after it:
InstallShield 2020
If the current string is the first string in the list and you add a new string before it, the new string becomes the first string in
the list. The string that was formerly in the first element position now resides in the second element position. The new
string at the first element position is now the current string:
InstallShield 2020
If the current string is the first string in the list, and you add the new string after the current string, the new string becomes
the second string in the list, as well as the new current string. Refer to the script fragment below and to the illustration
following it:
InstallShield 2020
As another example, the code segment shown below creates a new list and puts String 1 in the first position. String 2 is then
added before String 1, leaving String 2 in the first position as the current string. Next, String 3 is added after the current
string, resulting in the list depicted below.
Figure 4-4: String 1 is added. Then String 2 is added before String 1. Last, String 3 is added after String 2.
In the example above, if String 3 were added before the current string, the result would be as shown below, with String 3
becoming the current string. This code segment is shown below:
Figure 4-5: String 1 is added. Then String 2 is added before String 1. Last, String 3 is added before String 2.
InstallShield 2020
Call the ListSetCurrentString function to change the value of an element in a string list. Remember that only the current
element may be changed, so be sure to make the string you want to update the current string in the list.
Call the ListSetCurrentItem function to change the value of an element in a number list. Again, the item that you want to
update must be the current element in the list.
The example below demonstrates calling ListSetCurrentItem to change the value of the current item in a number list. The
ListSetCurrentString function works in the same manner, but with a string list and string variables.
See Also
ListSetCurrentString
ListSetCurrentItem
InstallShield 2020
Call the ListDeleteString function to delete the current string from a list. Or, call the ListDeleteItem function to delete the
current number from a list. If there are no more elements to delete, these functions return the END_OF_LIST constant.
Note that since ListDeleteString and ListDeleteItem delete the current element, you must reset the current element to
the element that you want deleted. After deletion, the next element in the list becomes the current element. You reset the
element by any of the methods described in Traversing Lists.
The example below illustrates the use of several list functions, including ListDeleteString. The ListDeleteItem function is
used in the same manner, except that the list is a number list and the variables are number variables.
See Also
ListDeleteString
ListDeleteItem
InstallShield 2020
You can traverse lists non-incrementally. Call the ListFindString function or the ListFindItem function when you want to
search for a specific string or number element in a list. These two functions begin their search at the current element and
continue forward through the list from that point.
To start a search from the beginning of a list, call the ListGetFirstString or the ListGetFirstItem function before calling the
ListFindString or the ListFindItem function.
When the ListFindString or the ListFindItem function finds the specified string or number, it becomes the current element
in the list.
In the script fragment below, a number list is created, and the number 1 (in nItem) is added as the first element. Then,
ListFindItem searches the list for the number 1, and deletes it, if found. Finally, the list is destroyed.
nItem = 1;
ListAddItem (listID, nItem, AFTER);
ListDestroy (listID);
Note • The ListFindString and ListFindItem functions look for only the first instance of the specified string or number at or
after the current element.
See Also
ListFindString
ListFindItem
ListGetFirstString
ListGetFirstItem
InstallShield 2020
Call the ListGetFirstString function or the ListGetFirstItem function to return the first string element or number element,
respectively, from a list. The element that you retrieve then becomes the current element in the list.
Call the ListGetNextString function or the ListGetNextItem function to return the string element or number element after
the current element in a list. The element that you retrieve then becomes the current element in the list.
endwhile;
See Also
ListGetFirstString
ListGetFirstItem
ListGetNextString
ListGetNextItem
InstallShield 2020
Call the ListReadFromFile function to read an entire file into a string list. Each line in the file becomes an element in the
list. The ListReadFromFile function provides an easy way to load a list, rather than building it one item at a time.
See Also
ListReadFromFile
InstallShield 2020
InstallShield provides the ListSetIndex function, which lets you make an element the current element using an index
number. If you know the location of a particular element in a list, you can call the ListSetIndex function to access that
element immediately. You can traverse a list in either direction by using the index to set a specific element in a list to the
current element. The index of the list starts at 0 (zero).
The ListSetIndex function works on both string and number lists. After you set the indexed element as the current
element, call either the ListCurrentItem function or the ListCurrentString function to return the value of the indexed
item.
ListDestroy (listID);
The ListCount function tells you how many elements are in a list. The ListCount function is used mainly for general
information purposes, although it can be used to establish an upper index value in conjunction with ListSetIndex. For
example, you can call ListCount to get the number of elements in a list, and use that value with ListSetIndex to traverse a
list. The above example, which uses a while loop, is rewritten below using an InstallScript for loop based on the number of
elements in the list.
ListDestroy (listID);
See Also
ListSetIndex
ListCurrentItem
ListCurrentString
ListCount
Traversing Lists
InstallShield 2020
InstallShield provides these functions for traversing lists incrementally and non-incrementally:
Function Description
ListGetNextItem Retrieves the element after the current element from a number list.
ListGetNextString Retrieves the element after the current element from a string list.
Function Description
InstallShield uses single-linked lists, which means that unless you use functions that set indices or search for specific
elements in lists, you can traverse lists incrementally in one direction only: from the first element to the last.
InstallShield allows you to traverse lists in non-incremental fashion by means of indices and by searching for particular
elements in lists. Refer to the individual function descriptions for more details.
Most list traversing and list access operations are carried out relative to the current list element. Furthermore, most of the
functions used to traverse and access lists establish a current element as a result of their action. Therefore, making an
element the current element in a list is not an isolated action; it is a byproduct of another action.
If a list is empty, adding an element to the list will establish a current element. If a list is not empty, then making an element
the current element is best accomplished by traversing the list or searching for a particular element in the list.
Tip • Lists are often processed within while loops, usually checking for END_OF_LIST. An infinite loop can result if the list is not
valid. If you are processing lists in a while loop, make sure that you have created the list with the ListCreate function, and that
you have not destroyed the list with the ListDestroy function.
InstallShield 2020
Call the ListWriteToFile function to write the contents of a string list to a file. Each element in the list becomes a line in the
file.
The example script below reads the Autoexec.bat file into the listFile string list and then writes that string list to a file
named Autoexec.bak.
All open script files are saved automatically when you click Save on the File menu in InstallShield.
System Restore
InstallShield 2020
System Restore is a Windows feature that enables end users to restore PCs corrupted during software installation. The
System Restore feature automatically monitors and records key system changes to the end user’s PC. System Restore
reduces support costs and increases customer satisfaction by letting the end user easily undo a change that may have
harmed their system or revert to a time when they knew that their system was performing optimally.
InstallScript installations support System Restore by setting a restore point before starting the file transfer; the end user
can then use System Restore to restore the system to the state it was in before the file transfer.
Note • Installation actions (for example, registry changes and file modifications) that take place before file transfer cannot be
undone by System Restore.
Your installations are System Restore compatible by default. You can disable System Restore compatibility by placing the
following code in your script’s OnBegin event handler:
Disable( PCRESTORE );
If the file Wininit.ini exists in the target machine’s Windows folder, the installation cannot set a restore point. To handle
Wininit.ini, put code like the following in the OnFirstUIBefore and OnMaintUIBefore event handler functions:
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
Windows Installer properties can contain useful information about the product, the setup, the operating system, and the
user. By calling MsiGetProperty and MsiSetProperty, you can directly interact with these properties in your immediate
InstallScript custom action.
Note • Note that the MsiGetProperty and MsiSetProperty properties cannot be used for deferred InstallScript custom
actions, which do not have access to the active .msi database and do not recognize any Windows Installer properties. They can
access only the information that has been written into the execution script.
The following example retrieves the user name from the Windows Installer setup package, confirms the value, gives the
user the opportunity to change it, and then writes the new value back into the database.
Note • It may be necessary to specify a proper buffer size if the property value exceeds 1024 characters. For an example of
how to write code for this scenario, refer to Changes in Behavior for Some MSI APIs That Are Called in InstallScript Custom
Actions in the “Upgrading Projects from InstallShield 2011 or Earlier” topic.
function Func1(hMSI)
STRING svName;
NUMBER nvSize, nResponse;
begin
// Retrieve the user's name from the MSI database
nvSize = 256;
MsiGetProperty (hMSI, "USERNAME", svName, nvSize);
if nResponse = NO then
AskText ("Enter the name that will be registered for " +
"this product.", svName, svName);
MsiSetProperty(hMSI, "USERNAME", svName);
endif;
end;
See Also
Accessing or Setting Windows Installer Properties Through Deferred, Commit, and Rollback Custom Actions
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
MsiGetProperty (Windows Installer Help Library
MsiGetProperty (Windows Installer Help Library
MsiSetProperty (Windows Installer Help Library
MsiSetProperty (Windows Installer Help Library
Bit flags are one or more (up to 32) Boolean values stored in a single number variable.
Each bit flag typically has a corresponding predefined constant associated with it; this constant has the bit for this flag set
to 1 and all other bits set to 0. For example, the following constant identifies the bit flag for bit 0, that is, the right-most bit
in the number:
Note that 0x00000003 is not a valid bit flag, since this value corresponds to two bits in the number being set to 1.
All bits other than the rightmost bit are set to 0 by the & operation; the rightmost bit is 1 since it is 1 in both the constant
BITFLAG_TEST_1 and nFlags.
The following expression evaluates to FALSE since the third bit of nFlags is 0 and all other bits are set to 0 by the &
operation:
String Comparisons
InstallShield 2020
When InstallShield compares two strings, it starts by comparing the initial character in the first string with the initial
character in the second string. If those characters are equal, InstallShield then compares the characters in the next position
of each string. If those characters are also equal, it moves on to the characters in the next position, continuing in sequence
until it encounters one of the following conditions:
• Two characters in the same relative position in the two strings do not match. In this case, InstallShield bases its
resolution on the comparison of those two characters. If the character in string one has a greater value than the
character in the corresponding position of string two, then string one is greater; otherwise string two is greater.
• The end of one string is encountered without finding unequal characters in corresponding positions. In this case, the
strings are of unequal length and therefore they are not equal.
• The end of both strings is reached without finding unequal characters in corresponding positions. In this case, the
strings are equal in length and all characters match; therefore the strings are equal.
svString1 = "trusting";
svString2 = "TRUTHFUL";
String comparisons are not case-sensitive. Because an uppercase character is equal to its lowercase counterpart,
InstallShield finds that the first three characters of trusting and the first three characters of TRUTHFUL are equivalent. The
comparison ends with the test of the characters in the fourth position of each string. Since s is lower than t in the ASCII
character table, svString1 does not equal svString2. The remaining characters are not compared and the else branch is
executed.
Note • The value of each character is based on its ASCII value. For information about the ASCII values of specific characters
and symbols, refer to a basic programming manual.
Note the following when using a null-delimited, double-null-terminated string (for example, abc\0def\0ghi\0\0; such
strings are also sometimes referred to as multiple null-delimited strings or multiple null-terminated strings):
• When declaring a variable that will be set to a null-delimited string value, explicitly size the variable; for example:
STRING szString[1024];
Do not use autosizing; the installation engine expects autosized strings to not include null characters within the string.
• Do not try to create arrays of null-delimited strings; since array elements must always be autosized, string arrays do
not currently support this type of string.
• The specified size of a null-delimited string should be at least the number of characters to be stored plus two for the
two terminating null characters.
• Since strings are automatically initialized to all null characters, you do not need to explicitly set the second-to-last
character to null (though this will not cause any adverse effects) unless you have previously set the second-to-last
character to something other than null.
• The best way to determine the length of a null-delimited string is to call the CharReplace function to replace the null
characters and then call the StrLengthChars function to determine the size of the resulting string.
• The StrGetTokens and StrPutTokens functions may be useful when working with null-delimited strings.
• Most InstallScript functions other than the ones noted above do not work with multiple null-delimited strings. If you
want to use a multiple null-delimited string with a built-in function, use the CharReplace function first to replace the
null characters with another character, such as an underscore (_).
Relative Path
InstallShield 2020
A relative path includes all of the information necessary to locate a file by starting at the current folder on the current drive,
for example, Support\Validation. That folder can be located along that relative path only if it exists in the current
directory.
Windows operating systems that are 32 bit support long file names. Long file names enable end users to give directories
and files more meaningful names. The term long file name refers to both long file names and long paths.
InstallShield provides the long file name functions to facilitate the installation of 16-bit applications and 32-bit
applications that do not recognize long file names. It is your responsibility to determine your application’s requirements.
InstallShield provides the tools to help you install any kind of application.
See Also
Long File Name Functions
InstallShield 2020
You can launch 16-bit applications using long file names, but you cannot pass long file names as arguments to 16-bit
applications; 16-bit applications require the short file name versions of long file names to function correctly.
If your installation passes a file name to a 16-bit application, you must provide a valid short file name to the application.
Long file names will not work.
If your installation writes file names to files such as .ini files, and if 16-bit applications are expected to use the files, you
must write short file names that the 16-bit applications can use.
See Also
Long File Name Functions
InstallShield 2020
Under 32-bit operating systems, if you pass a long file name containing one or more space characters to the command line
(such as in a DOS shell or in the Command Line setting for an icon), you must enclose the long file name in double
quotation marks. This is necessary because the command line recognizes the space character as a delimiter separating a
command from other arguments. The double quotation marks convert the long file name to a string literal, allowing the
command line to receive it as a single argument.
Under 32-bit operating systems, if you pass a long file name containing one or more space characters to the command line,
it must be enclosed in double quotation marks. However, due to the manner in which Windows NT accesses icon files, if a
long file name in double quotation marks is used in the Command Line setting for an icon, the default Windows icon may
display instead of the application’s icon.
To display your product’s icon, you can specify the icon’s path in the parameter szIconPath of the function
Double quotation marks must be removed from long file names before they can be converted to short file names in
InstallShield. Refer to the LongPathToQuote and LongPathToShortPath functions.
See Also
Long File Name Functions
InstallShield 2020
Long file names contain names longer than the conventional 8.3 (eight characters plus a three-digit extension) short file
name limit. Long file names allow the use of all the characters used in short file names. In addition, long file names can
contain plus signs (+), commas (,), semicolons (;), equal signs (=), left and right square brackets ([ ]), and spaces.
Leading and trailing spaces are ignored. The fully qualified long file name (including null terminating character) can be up
to 256 characters long on NTFS file systems and 260 characters long on VFAT file systems.
By default, the operating system creates a short file name for every long file name. The short file name consists of the first
six characters of the long file name, a tilde (~), and a number.
See Also
Long File Name Functions
You can define InstallScript constants on the Compile/Link tab of the Settings dialog box instead of in the script.
• If you define a constant that you defined with a #define statement in the script, a compile error occurs.
• If you define a constant that you defined as a variable in the script, the value of the constant is lost at run time.
See Also
Constant Data
Some Windows constants are predefined in the ISRTWindows.h file that is provided in the InstallShield Program Files
Folder\Script\Isrt\Include folder. This file is automatically included in your installation when you include Ifx.h in
your script. You do not need to redefine any constants that are defined in ISRTWindows.h; doing so will result in a compiler
warning. To determine which constants are predefined, refer to the ISRTWindows.h file.
To use constants that are not defined in ISRTWindows.h, you must define them (using #define) in the declaration block of
your installation script. You cannot simply include the Windows.h file that is usually part of a C++ program. The values that
you need to assign to the undefined constants can generally be found in an include file that is provided with the
appropriate Windows SDK or development tool. (For Microsoft Visual C++, most constants can be found in the Winuser.h
file, which is located in the InstallShield Program Files Folder\Script\Resource folder.)
To make a very long string literal more easily readable in a script, split the long string into two or more shorter strings,
place them on consecutive lines, and concatenate them. In InstallScript, concatenation is performed with the plus sign (+).
The example below shows how to split a long string literal across several lines of code in this way:
See Also
Concatenate Operator (+)
Absolute Path
InstallShield 2020
An absolute path includes all of the information necessary to locate a file by starting at the root directory of a specified
drive. For example, C:\Program Files\InstallShield\2020 is the absolute path to the InstallShield folder when installed
on drive C.
Building Functions
InstallShield 2020
Typically, functions are declared at the top of the file, and the body is defined at the bottom of the file. After you declare a
function prototype, you need to define the function itself in the function block. Each function block contains only one
function.
2. Type the return value data type used in the function prototype, or type void if the function prototype specifies a return
type of void (which indicates that the function does not return a value). If the function prototype does not specify a
return type, it is not necessary to enter one here.
4. To the right of the function name, type the names of the arguments that you are using in parentheses. The arguments
must correspond in data type to the parameters that you declared in the declare block.
Note • InstallScript functions do not allow you to pass an assignment statement as a parameter. In addition, you cannot
use the && or || operators within an argument to a function.
Steps 1 and 2 create the function header. Function headers do not end with a semicolon in InstallScript.
5. Declare any local variables that you will use in the function. Then type the keyword begin on a line by itself, without
punctuation.
6. After the begin line, add whichever statements you need in order to accomplish your particular task.
You can also use a return statement, particularly if you want to return a specific value from the function. See below for
information on returning values from a function.
if (lResult = 0) then
lResult = ParsePath(svPath, szFullPath, DIRECTORY);
endif;
if (lResult = 0) then
lResult = ParsePath(svName, szFullPath, FILENAME);
endif;
return lResult;
end;
Note • User-defined functions can return a value with a return statement. Other types of data can be returned in parameters
that have been declared with the BYREF operator.
See Also
#include (including the contents of another script in the main installation script)
Declarations
Calling Functions
InstallShield 2020
All functions—whether user-defined, built-in, Sd, or external—are called in the same way. Type the name of the function,
followed by the parameters that you want to pass to the function. For example:
Note • InstallScript functions do not allow you to pass an assignment statement as a parameter. In addition, you cannot use
the && or || operators within an argument to a function.
An autosized string variable that is passed by reference to a function is not autosized within the called function. If the function
attempts to assign a value whose length is greater than the current size of that parameter, run-time error 401 occurs. To avoid
this error, declare strings with a specific size when they are to be passed by reference to a function.
See Also
BYREF Operator
Declarations
return
String Size and Autosize
There are three rules you must remember when you are calling DLL file functions from your InstallScript installation script:
• The maximum length of the DLL file name is 33 characters; the maximum length of the function name is 63 characters.
• The installation cannot accept a composite parameter (that is, a parameter with a width exceeding 4 bytes) when
calling a DLL file. However, a parameter can be a pointer that points to a composite structure.
• A string variable whose address is stored in a pointer variable cannot be changed by passing the pointer to a DLL file
function. To allow a DLL file function to change the value of a string variable, pass the variable itself as an argument to
the function, after declaring the data type of that argument specifying the BYREF operator.
1. Add the DLL file to your project as a support file if you have not already done so. For more information, see Adding
Support Files.
2. In the InstallScript explorer, click the InstallScript file (.rul) that should call the DLL function.
3. At the beginning of the script, prototype the function using the following syntax:
For example:
You can specify the calling convention to be cdecl or stdcall. If you do not specify a calling convention, InstallShield
uses stdcall.
Note that the DLL file name is case-sensitive; for example, the script compiler treats MyDLL.MyFunction and
mydll.MyFunction as different functions. When prototyping functions from User32.dll, Gdi32.dll, or Kernel32.dll,
you may use the keywords USER, GDI, and KERNEL in place of the DLL file name.
You can specify the return type to be any InstallScript data type except LIST. If you are declaring a DLL file function call
in which a wide-character string argument or a Unicode string argument is expected, use the wstring data type. If you
do not specify a return type, the installation assumes that the DLL file function returns a 4-byte value.
4. Load the DLL file by calling the UseDLL function. For example:
Note • You do not need to load _isuser.dll, _isres.dll, or Windows API DLL files, such as User32.dll, Gdi32.dll,
and Kernel32.dll. Do not call UseDLL and UnUseDLL to load and unload these DLL files.
5. Call the function as you would call any other function. For example:
It is recommended that you include the DLL file name in the function call, as in the preceding example. If your script
declares functions with the same name from different DLL files, calling the function without including the DLL file
name results in a compiler error.
If the installation does not find the called function in the DLL file, the installation raises an exception, which you can
handle by using a try...catch...endcatch block.
6. After all script calls to the DLL have been made, unload the DLL file by calling UnUseDLL. For example:
Note • You can use the IS_NULLSTR_PTR variable to pass a null pointer to an external DLL function or Windows API through a
parameter that has been prototyped as an InstallScript string. For more information, see IS_NULLSTR_PTR.
See Also
Creating InstallScript Files
Inserting and Importing Script Files
Compiling Scripts
Debugging Scripts
UseDLL
UnUseDLL
InstallScript arrays are internally formatted as OLE Automation safe arrays, not native C or C++ arrays. To pass an
InstallScript array to a DLL function that expects a C or C++ array, you must place the array data in the expected format by
calling GetCArrayFromISArray.
Declaring Functions
InstallShield 2020
The first step in creating a user-defined function is to declare the function. The keyword prototype tells the InstallShield
script compiler that the line contains a function definition.
2. Type the function’s return type. (This step is optional. If you do not enter a return type, it is assumed that the function
returns a NUMBER value or no value.) To specify that the function does not return a value, type void.
4. After the function name, type the data types of the parameters, and enclose them in parentheses and separate them
by commas.
5. If there are no parameters, put empty parentheses to the right of the function name.
In the following examples, FunctionName is a function containing three parameters. The arguments passed when calling
FunctionName must be, in order, INT, STRING, and SHORT. CopyBitmapExample has no parameters. FileTransfer has
five parameters—three LONG variables and two STRING variables—and returns a NUMBER value.
When you are declaring DLL functions, use the format <DLL file name>.<function name> for the name of the DLL file
function. For example:
The above declaration signals to the InstallScript compiler that the program will call a function named MyFunction, with
two INT parameters, in a file named Mydll.dll.
You can also optionally declare a calling convention, either cdecl or stdcall, when declaring a DLL file function. For
example:
If you do not explicitly declare a calling convention, InstallShield uses stdcall. If you explicitly declare both a calling
convention and a return type, place the calling convention before the return type.
Note • Most Windows API functions use the stdcall calling convention, but some C or C++ development environments build
DLL file functions with the cdecl calling convention unless you prototype your C or C++ function with the __stdcall modifier. For
more information, consult your compiler documentation.
Many Windows API functions are declared in the header file ISRTWindows.h, which is automatically included when you include
Ifx.h in your script. (You can prevent the automatic definition of Windows APIs by placing the preprocessor constant
ISINCLUDE_NO_WINAPI_H in the Preprocessor Defines box on the Compile/Link tab of the Settings dialog box.)
See Also
Declarations
Data Types and Predefined Structures
Pointers
Like InstallScript’s built-in functions, user-defined functions can be designed to return a value to the caller. To return a
value from a function, you must include a return statement, followed by the value to be returned, before the function’s end
statement. If you do not include a return statement or if you do not specify a value after the keyword return, the value
returned by the function is unpredictable. (If the function prototype specifies a return type of void, the function cannot
return a value.)
Many programmers use return statements to return error codes that indicate the success or failure of a function call. Most
of InstallScript’s built-in functions use a return statement for that purpose. The return statement also is used commonly to
create functions that return the result of an operation performed on parameters passed to the function, as in the example
below, which returns the area of a rectangle:
The keyword return can be followed by a constant, a variable, a numeric or string expression, or a function call. In the
example below, RectangleArea has been modified to eliminate the assignment statement; the arithmetic expression
follows the keyword return:
The value returned by a function can be ignored by the calling program or function, tested in a conditional expression, or
assigned to a variable. In the following example, the return value from RectangleArea is assigned to the variable nArea:
To return more than one value or non-numeric values, use the BYREF operator to define parameters that are passed by
reference.
See Also
BYREF Operator
Declarations
return
Unsupported Functions
InstallShield 2020
Some of the functions that were available in InstallShield Professional and InstallShield—Windows Installer Edition are not
supported in InstallShield.
Component Functions
In InstallShield, features are the top-most level of project organization from the end user’s perspective. Because of this,
component functions are now feature functions. For example, ComponentDialog is now FeatureDialog. Nearly all of the
component functions are available to you as feature functions in InstallShield.
Project • Feature functions are available for use in InstallScript and InstallScript MSI project types. If you have a Basic MSI
project, you must convert your project to the InstallScript MSI project type in order to use feature functions in your installation.
Because feature functions are not supported for use in Basic MSI projects, the PreShowComponentDlg and
PostShowComponentDlg functions are no longer necessary and are not supported.
When Windows Installer executes an InstallScript custom action, InstallShield calls the function that you specified when
you created the custom action. Every InstallScript custom action must have an exported, user-defined function as an entry
point into the script.
• Its prototype must include the keyword export to declare it as an exported function.
• The function can accept only one argument, which must be a handle to the .msi database.
• It should return a value meaningful to Windows Installer, if your custom action is designed to wait for a return value.
These custom action return values are defined in IsMsiQuery.h and available to you if you include IsMsiQuery.h or
Iswi.h in your script.
The following example script declares an entry-point function, which returns success if it succeeded:
// Include Iswi.h for Windows Installer API function prototypes and constants.
#include "iswi.h"
function MyFunction(hMSI)
STRING szKey, svValue, svPath;
NUMBER nvType, nvSize, nReturn;
begin
RegDBSetDefaultRoot (HKEY_LOCAL_MACHINE);
// The App Paths key contains the folder where InstallShield was
// installed, followed by a semicolon.
StrSub (svPath, svValue, 0, StrFind(svValue, ";"));
if nReturn = 0 then
MessageBox ("InstallShield is installed to " + svPath, INFORMATION);
return ERROR_SUCCESS;
else
MessageBox ("Cannot determine where InstallShield is installed.", SEVERE);
return ERROR_INSTALL_FAILURE;
endif;
end;
You can use the Function Wizard to select a function, specify its arguments, and insert the function in your script.
Windows API functions are declared in the header file ISRT.h, which is automatically included in your installation when you
include Ifx.h in your script. If this function is also explicitly declared in your script code, do one of the following:
• Remove your function declaration and use the declaration that is provided by InstallShield.
• If you are creating a script that needs to be compatible in both InstallShield 2020 and versions of InstallShield
Professional earlier than 7, surround your declaration with code such as the following:
You may also need to update code that calls the Windows API function, if the declaration that is defined by InstallShield is
different than your declaration.
You can prevent the automatic definition of Windows APIs by placing the preprocessor constant ISINCLUDE_NO_WINAPI_H
in the Preprocessor Defines box on the Compile/Link tab of the Settings dialog box.
By default, if the file Setup.rul exists in the InstallScript view and defines a function <feature name>_<event name> (for
example, NewFeature1_Installing), then that function is the handler for that event of that feature.
You can select a different function to be the handler for the feature event. It can be any function defined in any script file in
the InstallScript view, as long as it takes no arguments and is declared using the export keyword, for example:
• Declare and define the function that you want to specify as a feature event handler.
• In the Event Category and Event lists at the top of the script editor pane, select the feature and select an event
handler. InstallShield automatically creates the event handler (for example, Feature1Installing).
Note • If you put parentheses in a feature’s name, event handler functions with names of the default form <feature
name>_<event name> will not compile properly.
A global variable is data declared outside of a function and available to any module in the script. By using global variables,
you can share persistent data with event handlers, entry-point functions, and user-defined functions.
For example, if you retrieve the value of the operating system’s version in your OnBegin event handler, you can later access
that global value in an entry-point function. The following script excerpt illustrates this:
function OnBegin()
// Declare local variable
STRING svResult;
begin
GetSystemInfo (WINMAJOR, nvResult, svResult);
end;
function MyFn(hMSI)
begin
if nvResult > 4 then
// Code for version of Windows later than 4.0
else
Important • Global variables share state across all event handlers. However, if you create an InstallScript custom action for
your project, global variables will not share state from the InstallScript custom action to the event-driven InstallScript code, or
vice versa. Thus, if you declare a global variable in your event-driven InstallScript code, that variable would not be available to
your InstallScript custom action. Similarly, if you declare a variable in your InstallScript custom action, that variable would not
be available to your event-driven InstallScript code.
The uninstallation removes modifications that are made with the InstallScript initialization file functions while logging is
enabled. For more details, see the information in this section of the documentation.
See Also
InstallScript Functions that Are Logged for Uninstallation
The following limitations apply to uninstalling .ini file entries and modifications automatically:
• Logging must be enabled when the .ini file functions are called.
• If an .ini file was created by any of the .ini file functions, it is not removed.
• If a section name was created by any of the .ini file functions, it is not removed, even if no more keys are present.
• If a key value is completely replaced by an InstallScript function (not appended to, or prepended to), the key values
that existed before the installation are not restored. In this case InstallShield considers the replaced key a newly
created key and will uninstall it as if it is a new key that was created by the installation.
• The uninstallation does not restore keys or values that were deleted using WriteProfString.
• To append a value to existing key (for example, network under [386Enh]), the new entry must either be appended at
the end or prepended in the very beginning of the existing string, but never inserted in the middle.
• Only the comma (,) and semicolon(;) are considered valid delimiters. If a string value to be uninstalled is found as a
part of longer string, the value and the delimiter before or after it is also removed appropriately (based on the string’s
position) only if the delimiter is a comma or a semicolon. For example, if the uninstallation removes pqr from the
string Key=pqr,rst,uvw, it also removes the comma after pqr. A character other than a comma or a semicolon in its
place will not be removed. As a rule, avoid adding spaces around delimiters.
See Also
InstallScript Functions that Are Logged for Uninstallation
The uninstallation removes the keyname and value pair completely if the following conditions are true:
• The keyname and the value pair that exist when the uninstallation is run exactly match the installed keyname and
value pair. If another installation or program modifies the installed key between the installation and uninstallation,
the keyname and value pair will not be removed completely. Only the value that was created by the original
installation will be removed; the key itself and any additional values will not be removed by the uninstaller.
[386Enh]
device=votc.386
device=*vmpcd
[386Enh]
device=*vmp32
device=votc.386
device=*vmpcd
If another installation had added a value to the existing line, only the value from the installation that is being uninstalled
will be removed. The original keyname and the new value will be left in the file. For example, if you had added the line Test
Values=votc.386 in Test.ini under the [Test] section:
[Test]
Test Values=votc.386
Continuous Test=No
and another installation had added a new value to Test Values after your installation had run:
[Test]
Test Values=votc.386,pctcp.386
Continuous Test=No
when your application is uninstalled, votc.386 will be removed and TestValues=pctcp.386 will be left in the file:
[Test]
Test Values=pctcp.386
Continuous Test=No
See Also
General Limitations of Uninstalling Initialization (.ini) File Entries
The uninstallation removes the keyname and value pair completely if the following conditions are true:
• The keyname and value pair that exist when the uninstallation is run exactly match the installed keyname and value
pair. If another installation or program modifies the installed key between the installation and uninstallation, the
keyname and value pair will not be removed completely. Only the value that was created by the original installation
will be removed; the key itself and any additional values will not be removed by the uninstaller.
[386Enh]
device=votc.386
device=*vmpcd
[386Enh]
device=*vmp32
device=votc.386
device=*vmpcd
See Also
General Limitations of Uninstalling Initialization (.ini) File Entries
The uninstallation removes the keyname and value pair completely if the following conditions are true:
• The keyname and value pair that exist when the uninstallation is run exactly match the installed keyname and value
pair. If another installation or program modifies the installed key between the installation and uninstallation, the
keyname and value pair will not be removed completely. Only the value that was created by the original installation
will be removed; the key itself and any additional values will not be removed by the uninstaller.
See Also
General Limitations of Uninstalling Initialization (.ini) File Entries
Important • Do not confuse COM objects with InstallShield objects. They are two separate features.
Instead of using DLLs or other executable files, you can extend your installation with COM objects. COM objects can be
integrated into your installation fairly easily. Use the following procedure to assign COM objects in your script.
OBJECT oMyCOMObject
2. Get a reference to your COM object and assign it to the variable by using the set keyword. For example:
The value of szMyProgID is a valid program ID for your COM object. If you leave the set keyword out, the script engine
attempts to set the default property of oMyCOMObject to szProgID. Because there is no default property, since
oMyCOMObject does not contain a reference to your COM object yet, the script will fail.
Important • By default, once a COM object is loaded by the installation using CoCreateObject, CoCreateObjectDotNet,
CoGetObject, or DotNetCoCreateObject, it remains loaded until the installation is finished. The COM object remains loaded
regardless of whether the COM object variable goes out of scope or is set to NOTHING.
Consequently, the library referenced by the COM object is also not released until the installation is finished. However, it is
possible to unload the library referenced by the COM object by calling the Windows API CoFreeLibrary. CoFreeLibrary
unloads the library regardless of whether any object variables still reference it. Therefore, you should only call CoFreeLibrary
after all objects that reference the library have gone out of scope or are set to NOTHING. See the following example code:
program
else
endif;
endprogram
CoFreeUnusedLibraries can also be used to unload the library. However, by default, the system waits 10 minutes before
unloading the library, and in most cases, the installation requires the library to be unloaded immediately. If your installation
will run on Windows XP and later only, you can call CoFreeUnusedLibrariesEx, which includes the option of unloading the
library immediately.
Below is an example COM object that validates a serial number. It has one method, Validate, and one property, IsEval.
function OnFirstUIBefore()
OBJECT oObj;
STRING szProgID, szMsg, szTitle, svName, svCompany, svSerial;
BOOL bValidSerialNumber, bEval, bValidate;
NUMBER nResult;
begin
szProgID = "MySerialValidation";
set oObj = CreateObject( szProgID );
if ( !IsObject( oObj ) ) then
MessageBox( "Object " + szProgID + " is invalid!", SEVERE );
return ISERR_GEN_FAILURE;
endif;
bValidSerialNumber = FALSE;
while (!bValidSerialNumber)
szMsg = "Please enter your name, company name, and product serial number.";
szTitle = "Enter info";
nResult = SdRegisterUserEx( szTitle, szMsg, svName, svCompany, svSerial );
if ( nResult < 0 ) then
MessageBox( "Failed to display dialog box.", INFORMATION );
return ISERR_GEN_FAILURE;
endif;
return ISERR_SUCCESS;
end;
Note • You can pass a data structure to your COM object as long as it has the members that your COM object expects. The
following is an example of passing a data structure:
typedef PERSON
begin
STRING Name[PERSON_NAME_SIZE];
NUMBER Age;
end;
function OnBegin()
PERSON pPerson;
NUMBER nPhoneNumber;
OBJECT oMyCOMObject;
STRING szMyProgID;
begin
/* Assign a value to szMyProgID in this line. */
set oMyCOMObject = CreateObject ( szMyProgID );
if ( !IsObject( oMyCOMObject ) ) then
MessageBox( "Object " + szMyProgID + " is invalid!", SEVERE );
return ISERR_GEN_FAILURE;
endif;
nPhoneNumber = oMyCOMObject.GetPhoneNumber( pPerson );
return ISERR_SUCCESS;
end;
Note • The standard COM return value HRESULT is not visible to an automation client such as InstallScript. To return a value
from your COM object method, you should have an [out,retval] parameter in your method’s parameter list, as illustrated in the
following code samples.
IDL:
C++:
InstallScript:
function OnBegin()
NUMBER nObjReturn;
begin
set oMyCOMObject = CreateObject("MyProgID");
if (IsObject(oMyCOMObject) then
nObjReturn = oMyCOMObject.DoSomething(10);
/*nObjReturn will contain the value 1, returned from your implementation*/
endif;
end;
See Also
Object Functions
• InstallScript
• InstallScript MSI
Feature is a general term that refers to a set of components or subfeatures in InstallShield. A subfeature is a feature that is
located below another feature—similar to the relationship between a folder and a subfolder.
Top-level features are the highest features in the hierarchy. Top-level features are never referred to as subfeatures.
For example, if you pass a null string to the SdFeatureMult function, the corresponding dialog displays all the top-level
features in your script-created component set in the left window on the SdFeatureMult dialog, depending on the value of
the MEDIA system variable. All subfeatures appear in the right window on this dialog.
See Also
Feature Functions
Dialog Functions
Dialog Customization Functions
• InstallScript
• InstallScript MSI
You can call a Windows API function from within your InstallScript code.
1. At the beginning of the script, prototype the function using the following syntax:
For example:
Use Dumpbin.exe with the /EXPORTS option to determine which functions reside in any of the Windows API DLLs
Kernel32.dll, User32.dll, and GDI32.dll. To determine the return type and parameter types for a function, consult
a Windows programming reference such as the Microsoft Development Library (MSDL).
Note • You can specify the return type to be one of the following InstallScript data types: BOOL, CHAR, HWND, INT, LONG,
LPSTR, NUMBER, POINTER, or SHORT. If a return type is not specified, InstallShield assumes that the DLL function returns
a 4-byte value.
2. Call the function as you would call any other function. For example:
3. To get extended error information if the function fails, check the value of the Err object’s LastDllError property. (It is
not possible to call the Windows API function GetLastError to get extended error information, since the setup itself
changes this value before returning control to the script.)
In InstallShield, you can embed additional file transfer operations during the standard file transfer of the installation. Also,
the progress bar is updated smoothly and appropriately during these operations. There are a few different common
scenarios in which you would use this functionality.
This table provides an overview of what functions are called for each scenario.
Table 4-3 • Determining Which Functions Are Appropriate for Common Custom Transfer File Operations
FeatureMoveData None
These procedures include step-by-step information about how to use custom file transfer operations for each scenario.
Task To install additional files during the standard file transfer operation using XCopyFile or CopyFile:
1. Before file transfer, determine the size of the files to be installed, taking into account the cluster size on the target
folder for the files. You can accomplish this using the GetAndAddFileCost, CalculateAndAddFileCost, and/or
GetAndAddAllFilesCost functions.
2. Using the FeatureAddCost function, add the cost determined in Step 1 to the cost for the feature that these files are
associated with. Note that all cost must be associated with a particular feature. Therefore, if the files to be installed
are not associated with an existing feature, you must create a dummy feature or use an existing feature.
3. During file transfer, call the XCopyFile function to install the files. Typically, this would be done during the Installing
event of the feature associated with the additional files or in the OnMoving or OnMoved events. The progress bar is
updated smoothly and appropriately during the call. Note that you should disable the Cancel button in the status
dialog during the XCopyFile operation. See the description for the XCopyFile function for more information.
Note • There is no additional action required for the uninstallation. The files are uninstalled while the uninstallation progress
is updated appropriately.
Task To call an external installation that installs additional files during the standard file transfer operation:
1. Before file transfer, determine the size and number of the files to be installed (or other operations) by the external
installation by examining the external installation and taking note of what operations occur.
2. Using the FeatureAddCost function, add the cost determined in Step 1 to the cost for the feature that this installation
is associated with. Note that all cost must be associated with a particular feature. Therefore, if the files to be installed
are not associated with an existing feature, you must create a dummy feature or use an existing feature. Review the
two scenarios below.
3. If the external installation is called during uninstallation, add the number of operations and size of the operations to
the uninstallation cost using FeatureAddUninstallCost.
4. During file transfer, use the LaunchApplication event to launch the installation, typically in silent mode. Typically,
this would be done during the Installing event of the feature associated with the additional files or in the OnMoving or
OnMoved events. Use the LAAW_USE_CALLBACK option so that your script regains control periodically during the
installation and uninstallation.
5. Override the OnLaunchAppAndWaitCallback event, and add code to poll the running installation to determine its
progress. Then call the FeatureSpendCost (Installation) function or the FeatureSpendUninstallCost (Uninstallation)
function to spend the appropriate amount of cost that the installation has completed. Repeat this process while the
external installation is running. The progress bar is updated smoothly and appropriately during the call. Note that you
might have to adjust the LAAW_PARAMETERS.nCallbackInterval so that the OnLaunchAppAndWaitCallback event is
called often enough to keep the progress updated smoothly.
See Also
FeatureAddCost
FeatureSpendCost
FeatureAddUninstallCost
FeatureSpendUninstallCost
When a number is stored in an InstallScript integer, only 31 bits of data are available to store the value. Therefore, the
maximum value that can be expressed is 2^31 (2 GB). Note also that since InstallScript integers are always considered to be
signed, the 32 bit is interpreted as the sign bit and cannot be used to store numeric data. This limits the values that can be
expressed to 2^31 (2 GB) instead of 2^32 (4 GB), which could be stored in an unsigned data type.
In some cases, it is necessary or desirable to be able to specify larger values. To accomplish this in InstallShield, a number
of functions support the specification of large numbers as a pair of 32-bit numbers with the sign bit (32 bit) of each number
always being set to 0 to indicate a positive number. Using this format, it is possible to specify and retrieve a number with up
to 62 bits of data or 2^62 of size.
Note however that since the language does not have a data type that can express the number as a single variable, the
operations that can be performed on this data are limited. This data is typically passed between functions that support
these values. The data can also be converted to a single value expressed in a larger size unit (such as KB or MB) using the
ConvertSizeToUnits function or passed to an external DLL function that can handle larger data types.
When a number is specified as a high/low pair, the lower 32-bit value specifies the lower 31 bits of data (with the sign bit
always set to 0 and ignored) of the full value. The upper 32-bit value specifies the upper 31 bits of data (again with the sign
bit always set to 0 and ignored). For example, an upper value of 4 actually indicates 4 * 2^31 or 8589934592 (8 GB) of size.
This, combined with a lower value of 100, would indicate a total size of 8589934692 units.
Note that in the case of numbers less than 2^31, the high value will always be 0 and thus can be ignored if you are sure that
the size of the value will never exceed 2^31. However, it is recommended that if you need to use this data for computations,
you use the ConvertSizeToUnits function to convert this data to a single value of the most appropriate units with minimal
amount of rounding to express the data in a single value.
Note • Note that convention differs from the unsigned high/low value pairs used by Windows in which the lower value stores
the lower 32 bits of data and the high value stores the upper 32 bits of data. The ConvertWinHighLowSizeToISHighLowSize
function is provided for easy conversion of data returned by Windows API functions.
• GetDiskInfo
• GetFileInfo
• GetAndAddFileCost
• CalculateAndAddFileCost
• GetAndAddAllFilesCost
• FeatureFileInfo
• FeatureGetCostEx
• FeatureAddCost
• FeatureSpendCost
• ConvertWinHighLowSizeToISHighLowSize
• ConvertSizeToUnits
InstallShield supports installing device drivers in InstallScript installations using Windows Driver Install Frameworks (DIFx),
which includes the DIFxAPI component. This component allows drivers to be installed or uninstalled without using the
Windows Installer.
Project • This information applies to InstallScript projects. Installing device drivers is supported in InstallScript MSI and Basic
MSI projects using the DIFx Windows Installer functionality. For information on configuring device drivers using the Windows
Installer, see Configuring Device Driver Settings.
2. For the DIFx Support (for 32-bit platforms) setting, select Enabled.
4. Override the feature event for the feature containing the DIFx driver files and either call the DIFxDriverPackageInstall
function for non-Plug and Play (PnP) drivers or the DIFxDriverPackagePreinstall function for PnP drivers.
2. For the DIFx Support (for 64-bit Itanium platforms) setting or the DIFx Support (for 64-bit AMD platforms) setting,
select Enabled.
4. Override the feature event for the feature containing the DIFx driver files and either call the DIFxDriverPackageInstall
function for non-Plug and Play (PnP) drivers or the DIFxDriverPackagePreinstall function for PnP drivers.
See Also
General Information View
Device Driver Functions
In InstallShield, _ISCRIPT_VER is defined as 0xVVM, where VV is the major version of the product and M is the maintenance
pack release number. For example, 0x900 evaluates as InstallShield DevStudio version 9.0 and maintenance pack 0 (the
first release). This preprocessor constant was defined in InstallShield Professional 7 as 0x700 and in InstallShield
Professional 6 as 0x600, but is undefined and evaluates as zero in InstallShield Professional 5.x.
You can use this constant to test whether the InstallShield compiler is being used by including code like the following in
your script. This code tests for the existence of the first release of InstallShield DevStudio (version 9.0, maintenance pack
number 0) or later.
See Also
Preprocessor Directives
#if. . .#else. . .#endif
#elif
The preprocessor constant _ISCRIPT_ISPRO is defined in InstallScript projects (and in InstallShield Professional projects)
but is undefined and evaluates as zero in InstallScript MSI and Basic MSI projects. The preprocessor constant
_ISCRIPT_ISDEV is defined in InstallScript MSI and Basic MSI projects but is undefined and evaluates as zero in InstallScript
projects (and in InstallShield Professional projects).
You can use _ISCRIPT_ISDEV and _ISCRIPT_ISPRO to write a single script that produces different behavior in the different
project types by including code like the following in your script:
#ifdef _ISCRIPT_ISPRO
// code specific to InstallShield Professional and InstallScript projects
#else
#ifdef _ISCRIPT_ISDEV
// code specific to Basic MSI and InstallScript MSI projects
#endif
#endif
See Also
Preprocessor Directives
#if. . .#else. . .#endif
#elif
You can launch a complete installation by calling the LaunchApplication function. For example, if you placed the child
installation’s files on a CD-ROM, you could call LaunchApplication as follows:
As an alternative, you can include the child installation in your project as a support file. If you do this, your main installation
copies the child installation to the target system, runs the installation, and deletes the installation along with any other
support files. Use the SUPPORTDIR variable in the path of your child installation:
Alternatively, you could insert links to the child installation into your file groups, install the child installation onto the
target system, and then launch the installation from the target location. (With these methods, the child installation is left
on the target system until the parent installation is uninstalled.)
See Also
LaunchApplication
The table below shows the languages supported by the Premier edition of InstallShield. Following are descriptions of each
of the columns:
• Windows English Equivalent—Name that the English version of Windows uses to refer to the language.
If you are experiencing problems with color distortion in your InstallScript custom action, it is most likely due to shifts in
the color palette. This section explains how colors are apportioned on Windows systems and offers troubleshooting tips to
help you minimize any distortion in your installation’s end-user interface.
On systems operating in 256-color mode, there is one 256-color palette for displaying all available colors; in 16-color mode,
there is a 16-color palette, regardless of the number of colors that the video driver supports. Systems operating in high-
color or true-color mode do not use a color palette of any type. The colors are displayed directly, so color distortion should
not occur on these systems. On systems using a color palette, entries are allocated and used as needed when an object—
such as a bitmap—is displayed.
Once the current color palette has been allocated, to display a new color Windows attempts to use a color similar to one
that was already allocated. Therefore, distortion may result on a 256-color system if multiple objects that contain several
different colors are displayed simultaneously.
Also, Windows allocates 16 static colors (VGA colors) and four additional shades of gray during startup. These colors are
used by the system to display 16-color images and are never de-allocated by Windows. See the Windows platform SDK for
more information on color palette handling.
Use the tips below to minimize any color distortion related to color palette shifts. Color palette tips apply to all images that
you display during installation, including the background color, .avi files, metafiles, and bitmaps.
• Try using a 16-color gradient background, which requires only 16 palette entries. Call the SetColor function with one
of the gradient color constants to create this type of background.
• Try using a tiled or a centered bitmap background. Call the PlaceBitmap function to create one of these backgrounds.
• Avoid using a 256-color gradient background, which requires about 80 palette entries.
• Try to use similar colors (including the 16 static colors, which are always allocated) for bitmaps and billboards
displayed during the installation to reduce the number of color palette entries needed.
• You can determine the maximum colors available on the target system by calling the GetSystemInfo function with
the COLORS option. Perhaps you will want to display bitmaps of different resolutions based on the return value.
• Note that 24-bit bitmaps do not include a custom color palette in the bitmap file. When displaying a 24-bit bitmap on a
256-color system, only the currently available palette entries will be used, even if there are additional color palette
entries available. If you are displaying 24-bit bitmaps in your installation and you expect it to run on 256-color
systems, it is recommended that you also include 256-color versions of your bitmaps.
• Since metafiles are drawn instead of placed, additional color palette entries are not allocated when a metafile is
drawn; only the existing color palette entries are used to display the metafile. If you expect your installation to run on
256 color systems, it is recommended that you use only the standard 16 static colors in your metafile, because these
colors will be available, regardless of the current color palette’s availability.
• Verify that the system’s video driver supports 256 or more colors. If the video driver does not support 256 colors, the
bitmap will not display properly, even if your video card and monitor support 256 colors.
• If a monitor is not capable of displaying 256-color bitmaps, only the 16 static colors are used. This can cause severe
distortion problems. If you are using 256-color images in your installation, it is recommended that you require end
users to run it on systems that support 256 colors.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield supports the use of custom actions to run InstallScript, VBScript, or JavaScript code; call DLL functions; run
executable files; call a managed method in a managed assembly; set a property or a directory; trigger an error and end the
installation; run PowerShell scripts; terminate a process; or run other installation packages.
Task InstallShield divides the task of creating and implementing custom actions into the following steps:
1. Create a custom action in the Custom Actions and Sequences view (or the Custom Actions view) or by using the
Custom Action Wizard.
3. Launch a custom action by inserting it into a sequence or placing it as the result of a dialog’s control event (Basic MSI
projects).
For details about each of the InstallShield custom actions that are added automatically to InstallShield projects to support
different functionality, see InstallShield Custom Action Reference.
Project • Merge module projects only: You can control the launch of custom actions in a merge module by modifying the
ModuleInstallExecuteSequence table in the Direct Editor. When you add the merge module to your installation project, all
custom actions and dialogs included in the merge module are available for you to insert in the installation’s sequences via the
Custom Actions and Sequences view.
See Also
Inserting Actions into Sequences
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Custom Actions and Sequences View (or Custom Actions View)
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
You can use the Custom Action Wizard to create a custom action or modify an existing one.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI, InstallScript MSI, MSI
Database, and Transform projects) or Custom Actions (in DIM, Merge Module, and MSM Database projects).
2. Right-click the Custom Actions explorer and click Custom Action Wizard. The Custom Action Wizard launches.
Alternatively, you can create a custom action in the Custom Actions and Sequences view (or the Custom Actions view)
without using the Custom Action Wizard. For more information, see Creating Custom Actions in the Custom Actions and
Sequences View (or the Custom Actions View).
To learn about displaying action information on the progress dialog and in the installation’s log file, see Using Action Text.
See Also
Cloning Custom Actions
Creating Custom Actions in the Custom Actions and Sequences View (or the
Custom Actions View)
InstallShield 2020
Project • The Custom Actions and Sequences view is available in the following project types:
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The view is called the Custom Actions view in the following project types:
• DIM
• Merge Module
• MSM Database
The recommended way to create a custom action is with the Custom Action Wizard. The wizard walks you through all the
required steps to create a custom action and prompts for information. You can also create your custom action in the
Custom Actions and Sequences view (or the Custom Actions view)—without using this wizard—by configuring all of its
settings directly in the view.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI, InstallScript MSI, MSI
Database, and Transform projects) or Custom Actions (in DIM, Merge Module, and MSM Database projects).
2. Right-click the Custom Actions explorer and then click the type of custom action that you want to add.
3. Rename the new custom action by selecting it, pressing the F2 key, and typing the new name.
To learn about displaying action information on the progress dialog and in the installation’s log file, see Using Action Text.
See Also
Cloning Custom Actions
InstallShield Custom Action Reference
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
InstallShield provides the ability to copy or clone your custom actions. Cloning creates a new custom action of the same
type and with all of the same properties and values as the original custom action. You can use cloning to create multiple
custom actions that have similar attributes without having to manually set every custom action attribute.
Note that the clone operation clones only the custom action. It does not insert the custom action into any of the
installation sequences.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI, InstallScript MSI, MSI
Database, and Transform projects) or Custom Actions (in DIM, Merge Module, and MSM Database projects).
2. In the Custom Actions explorer, right-click the custom action that you want to clone and click Clone.
InstallShield adds a copy of the cloned custom action to the Custom Actions explorer. The name of the custom action is the
same name as the cloned custom action, except that the copy has a 1 at the end of the name.
See Also
Using Custom Actions
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI and InstallScript MSI
projects) or Custom Actions (in DIM and Merge Module projects).
2. In the Custom Actions explorer, right-click your custom action and click Export. The Export into dialog box opens.
3. Browse to the location of an existing InstallShield project file (.ism file). It can be either an installation project or a
merge module project, but the file cannot be open in another instance of InstallShield.
4. Click Open.
A copy of this custom action is added to the specified .ism file. If the other .ism file already has a custom action of that name
with different properties, the Resolve Conflict dialog box opens to offer you options for resolving the conflicts.
See Also
Reusing Project Elements
Project • The Custom Actions and Sequences view is available in the following project types:
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The view is called the Custom Actions view in the following project types:
• DIM
• Merge Module
• MSM Database
When you create a custom action, you need to configure its settings. You may also need to later modify its settings. For
example, you might want to edit the condition that is assigned to a custom action.
Depending on the type of custom action that you want to create, the settings for that action may have different meanings.
For example, if your action calls an executable file that is stored in the .msi package, the Source setting needs to have the
name of the entry in the table that points to the executable file that you want to call. The target setting is a command-line
argument in this case.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI, InstallScript MSI, MSI
Database, and Transform projects) or Custom Actions (in DIM, Merge Module, and MSM Database projects).
2. In the Custom Actions explorer, click the custom action whose settings you want to configure.
To learn about displaying action information on the progress dialog and in the installation’s log file, see Using Action Text.
See Also
Summary List of All Custom Action Types (Windows Installer Help Library)
Summary List of All Custom Action Types (Windows Installer Help Library)
InstallShield Custom Action Reference
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
The value that is displayed in the MSI Type Number setting for a custom action represents a combination of the type of
custom action (such as standard DLL, executable file, or InstallScript), the location (such as stored in the Binary table or
installed with the product) as well as several of the custom action’s settings, such as Return Processing, In-Script
Execution, and Execution Scheduling. It is the numeric value that is calculated by using the OR operator to combine several
bits that are available for the Type column in the Windows Installer CustomAction table. InstallShield also offers support
for extended custom action types, such as InstallScript custom actions and standard DLL file functions.
The Windows Installer Help Library refers to custom actions by a numeric type. When you add a custom action to your
project in the Custom Actions and Sequences view (or the Custom Actions view), the custom action type number is
calculated automatically, and the MSI Type Number setting is set to this number. For example, launching an executable file
whose fully qualified path is stored in the Property table is calculated as custom action type 50. To learn what value is
used for any of the basic types of custom actions, see Summary List of All Custom Action Types in the Windows Installer
Help Library.
For more information about each of the types of custom actions that are available in InstallShield, see Custom Action
Types.
See Also
Custom Action Type 50 (Windows Installer Help Library)
Custom Action Type 50 (Windows Installer Help Library)
Inserting Actions into Sequences
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Depending on your selections in the Custom Action Wizard’s Additional Options panel, Windows Installer will wait for a
successful return code before continuing with the installation. Your custom action must return one of these values
according to its status.
If you are authoring an InstallScript custom action, your entry-point function can return either ERROR_SUCCESS or
ERROR_INSTALL_FAILURE. These constants are defined for you when you include Iswi.h in your script. The InstallScript
engine reports any of the other exceptions to Windows Installer.
In-Script Execution
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
When you create a custom action, one setting that must be configured is the In-Script Execution setting on the Respond
Options panel of the Custom Action Wizard. Actions are executed in the order in which they appear in a sequence. However,
the sequences are run many times during a typical installation. The In-Script Execution setting enables you to select which
iteration of the sequence will trigger your action.
Immediate Execution
As its name implies, Immediate Execution runs when the internal Windows Installer installation script is being compiled.
When an .msi file is launched, the Windows Installer service converts all the tables in the installation database into an
internal script. (This internal script is not the same as InstallScript code.) This script is built by cycling through all the
actions in the installation in the order in which they appear. The building of this script is immediate execution. When an
action is encountered whose In-Script Execution setting is set to Immediate Execution, that action is executed. Therefore,
this action launches before any file transfers are encountered, possibly even before the end-user interface for the
installation is fully loaded.
As a rule, custom actions scheduled for immediate execution do not modify the target system, but only set properties and
query the target system (for example, to see if the target system meets your product’s ). Custom actions that set Windows
Installer properties must be scheduled for immediate execution, and custom actions that occur in the User Interface
sequence must be scheduled for immediate execution.
Because actions of this type run before any changes have been made to the system, they cannot rely on files that are being
installed by the installation.
Deferred Execution
Deferred Execution takes place when the internal script generated during Immediate Execution is executed by the
Windows Installer service. After that script has been fully generated, the Windows Installer service runs the newly compiled
script. The script runs through all of the actions in your sequences and executes them in order. However, if an action is
scheduled for immediate execution, the action does not run again during Deferred Execution.
Actions that launch during Deferred Execution have access to files being installed as part of the system. As a result, you can
call a custom action that calls a function from a DLL file installed with your product during this phase of the installation.
However, Deferred Execution custom actions must take place between InstallInitialize and InstallFinalize in order to work
properly.
Custom actions that rely on a file being installed to the target system, or that rely on other system changes to have already
been performed, must be scheduled for deferred execution.
Rollback Execution
Rollback occurs when an error is encountered by the installation or the end user cancels the installation before it has a
chance to complete. The Rollback Execution option allows you to set your action to execute only during rollback.
Therefore, any actions that are enabled for Rollback Execution are written to the installation script, as are Deferred
Execution actions. Unlike Deferred Execution actions, Rollback Execution actions launch only during rollback. (Rollback
custom actions run only if the installation fails during deferred execution.)
Any custom actions that make changes to the target system during an installation should be undone with a Rollback
Execution custom action in the event of rollback. For example, if you have a custom action that creates a file, you should
create a second custom action that deletes the file, and schedule the second action for rollback execution. (A rollback
custom action should be scheduled before the custom action it reverses.)
Commit Execution
Commit Execution actions do not run until the InstallFinalize action completes successfully. This means that they wait until
the installation has completed transferring files, registering COM servers, and creating shortcuts and registry entries. Then,
any actions that are set to Commit Execution launch in the order in which they appear in the sequence.
For example, if you have a custom action that creates a temporary file, you should create a second custom action that
deletes the file, and schedule it for commit execution.
See Also
Defining Sequences
Inserting Actions into Sequences
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Windows Logo • The intended behavior of each custom action must be documented for the Windows logo program. This is
especially helpful if system administrators deploy your product to enterprise environments; they sometimes need to know
what the custom actions do. If you validate your installation package but you have not specified a value for the Help File Path
setting, InstallShield generates validation error ISICE10. For more information, see ISICE10.
1. Create a file that describes the intended behavior of the custom action. The file should be a text-based file such as a
.txt, .htm, or .rtf file. Note that each custom action should have its own document.
2. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI, InstallScript MSI, MSI
Database, and Transform projects) or Custom Actions (in DIM, Merge Module, and MSM Database projects).
3. In the Custom Actions explorer, click the action that you are documenting.
4. For the Help File Path setting, click the ellipsis button (...) to browse to the file that describes the behavior of the
custom action.
Tip • You can specify whether InstallShield should stream the contents of each of the custom action help files into the .msi file
at build time. For more information, see the description of the Include Custom Action Help setting for a product configuration
in the Releases view.
See Also
ISCustomActionReference Table
Validating Projects
Guidelines for Creating Custom Actions that Meet Requirements of the Windows Logo Program
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If you are applying for the Windows logo, your application must meet Microsoft’s Windows logo program requirements.
You can use the validation suite to verify whether your installation package meets most of the custom action–related logo
requirements. However, some of the requirements cannot be verified through the validation suites.
Following is a list of the requirements that are not validated through the validation suites or the associated ISICEs but still
must be met to achieve logo compliance for the Windows logo program:
• Do not call the Global Assembly Cache tool (Gacutil.exe) from a custom action. This tool was not designed to be used
during installations.
• All custom actions must record success or failure in the Windows Installer log by calling MsiProcessMessage.
• Custom actions that change system state during installation must remove or restore the system state during
uninstallation. In addition, custom actions that change system state must be written as a deferred and rollback
custom action pair.
This does not apply to custom action types 19 (displays an error, returns failure, and ends the installation), 35 (sets the
installation directory), or 51 (sets a property)
• The intended behavior of each custom action in your installation must be documented. This does not apply to custom
action types 19 (displays an error, returns failure, and ends the installation), 35 (sets the installation directory), or 51
(sets a property). For more information, see Documenting the Behavior of Custom Actions.
For information about all of the InstallShield custom actions that are added automatically to InstallShield projects to
support different functionality, see InstallShield Custom Action Reference.
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
When your installation is built, InstallShield automatically adds a property called ISReleaseFlags to the Property table.
This property contains all of the release flags that are included in the build. These flags appear exactly as they do in the
Release Flags setting in the Releases view. Multiple flags are separated by a comma.
A custom action can be conditionally launched based on release flags in the following ways.
Calling MsiGetProperty
A more robust way to set a condition on your custom action based on release flags is to author a call to MsiGetProperty
within the custom action. In addition to determining if the action should launch, you can also indicate what code is
executed by the action. For example, you can use one function from a DLL file for all scenarios, yet provide different
functionality for each scenario through conditional logic within your function.
The drawback to conditionally launching your custom action in this way is that you can use only a script or DLL custom
action. Additionally, your custom action still launches behind the scenes. When the custom action launches, it can check if
a specified release flag has been included in the build. If that flag exists, the custom action continues. If the flag is not there,
the action exits.
See Also
Conditional Statement Syntax
Release Flags
Getting and Setting Properties
Placing Files in the .msi Database and Extracting Them During Run Time
InstallShield 2020
• Basic MSI
• InstallScript MSI
The Support Files view (in Basic MSI projects) and the Support Files/Billboards view (in InstallScript MSI projects) enable
you to store temporary files that are to be used by your installation program but are not to be installed. Examples are
license text files (as displayed by SdLicense) or DLL files called by your installation. The location to which the support files
are extracted at run time is stored in the Windows Installer property SUPPORTDIR.
Note • Deferred, commit, and rollback custom actions in Basic MSI and InstallScript MSI installations have access to only
some of the built-in Windows Installer properties: CustomActionData, ProductCode, and UserSID. If you want a custom action
to access any other properties (such as SUPPORTDIR) during deferred, commit, or rollback execution, you need to pass them as
CustomActionData. To learn more, see Accessing or Setting Windows Installer Properties Through Deferred, Commit, and
Rollback Custom Actions.
Project • Note that the value of the Windows Installer property SUPPORTDIR is not the same as the value of the InstallScript
system variable SUPPORTDIR.
InstallScript
To access a particular support file during installation, Basic MSI projects and InstallScript MSI projects should reference the
Windows Installer property SUPPORTDIR. You can use MsiGetProperty to query the path, and then append the file name to
the SUPPORTDIR value to obtain the complete path of the file. In the settings for a custom action, this is just [SUPPORTDIR].
In an InstallScript custom action, you could use code such as the following:
In this example, the name of the support file that is being used is stored in the MYFILE property.
C++
In C++, you could use the following code:
VBScript
In VBScript, you could use the following code:
dim strSupportDir
strSupportDir = Session.Property("SUPPORTDIR")
See Also
Using Support Files
MsiGetProperty
MsiGetProperty
• Basic MSI
• InstallScript MSI
Deferred, commit, and rollback custom actions in Basic MSI and InstallScript MSI installations have access to only some of
the built-in Windows Installer properties: CustomActionData, ProductCode, and UserSID. If you want a custom action to
access any other properties during deferred, commit, or rollback execution, you can pass them as CustomActionData. You
can do so by scheduling an immediate set-a-property type of custom action to set a property that matches the name of the
custom action. The value of this property is then available in the CustomActionData property within the deferred, commit,
or rollback custom action.
1. In the Custom Actions and Sequences view, create a set-a-property custom action (type 51) called GetSUPPORTDIR.
Configure the Property Name, Property Value, and Install Exec Sequence settings for the custom action as follows,
and leave all of the other settings blank.
3. Add the following code to display a message box containing the value of SUPPORTDIR:
function DisplaySupportDir(hMSI)
STRING supportDirPath;
NUMBER supportDirPathBuffer;
begin
supportDirPathBuffer = MAX_PATH;
if(MsiGetProperty(hMSI, "CustomActionData", supportDirPath, supportDirPathBuffer) ==
ERROR_SUCCESS) then
SprintfBox(INFORMATION,"Deferred Execution","The value of SUPPORTDIR is %s",supportDirPath);
4. In the Custom Actions and Sequences view, create an InstallScript custom action called DisplaySupportDir.
Configure the Function Name, In-Script Execution, and Install Exec Sequence settings for the custom action as
follows, and leave all of the other settings blank.
Important • The property name that you enter in step 1 must match the name of the custom action that you create in step 4.
For example, if you want to retrieve the values of [INSTALLDIR], [SUPPORTDIR], and [SetupType], you would set the
Property Value setting of your type 51 custom action to this:
[INSTALLDIR];[SUPPORTDIR];[SetupType]
You can use code such as the following VBScript to “unpack” the values from the CustomActionData property:
Dim PropArray
PropArray = Split(Session.Property("CustomActionData"), ";")
INSTALLDIR = PropArray(0)
SUPPORTDIR = PropArray(1)
SetupType = PropArray(2)
'Now do something with these variables...
• Basic MSI
• InstallScript MSI
• Merge Module
In order to use your InstallScript functions in a Windows Installer installation, you first need to create a custom action that
calls your script. The easiest way to create a custom action is to use the Custom Action Wizard.
When you complete the wizard, a custom action of type 65536 is created. This custom action type is not defined in the
Windows Installer Help Library. Because InstallScript is not natively supported by Windows Installer, InstallShield created
action type 65536.
Project • You should not use an InstallScript custom action in the User Interface sequence of an InstallScript MSI project. You
can use the event-driven script to provide the user interface in an InstallScript MSI project.
• Basic MSI
• InstallScript MSI
Although Windows Installer restricts the parameters that you can pass to a functions in a DLL file written for a custom
action, InstallShield offers a solution that enables you to pass any number of parameters to a function and store the return
value. Note that the function must use the __stdcall calling convention. Functions with more than one parameter will not
work properly if this convention is not used.
You can specify that you are calling a function in a standard DLL file in the Custom Action Wizard’s Action Type panel by
selecting Call a function in a standard dynamic-link library for the Type option. The next panel, the Function Definition
panel, allows you to specify the function’s parameters and return value.
Note • If you call a function in a standard DLL file that is installed with the product and the action is scheduled as deferred (for
the In-Script Execution setting), the DLL file that you are calling must be the component’s key file.
A custom action that calls a function in a standard DLL file stored in the Binary table cannot be scheduled for deferred
execution.
If you want a Windows Installer property to be set to the function’s return value, the action must be configured for immediate
execution. If you try to specify a return property for an action that is scheduled for deferred, rollback, or commit execution, the
return property is ignored at run time.
Argument Description
DllName Specify the name of the DLL file, without the dot or file extension.
FuncName Enter the name of the function that you are calling.
in DataType2="Value" This is the format for an argument that is a constant. DataType1 is of type
STRING, BOOL, NUMBER, HWND, HANDLE, or POINTER. Value is the data that
you want to pass for this argument. The constant’s data type is always
preceded by in.
Direction This is the format for an argument that references a Windows Installer
DataType3=[PropertyName2] property’s value. Direction can be in, inout, or out. For a discussion of these
property types, see the Function Definition panel under the argument’s source.
Example
For the custom action created in Calling MessageBoxA in an Installation, the Target value reads:
In this example, the data type is void, in HWND=0 represents a numeric value of 0, and MESSAGEPROP is a property that
contains a string that will be passed to the function MessageBoxA in User32.dll.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
A DLL file function specifically written for a Windows Installer custom action can accept only the handle to the installer
database as a parameter. The steps below explain how you can retrieve information from the .msi database for use in your
custom action.
You specify that your custom action resides in a Windows Installer DLL file (custom action types 1 and 17) by selecting Call
a function in a Windows Installer dynamic-link library in the Custom Action Wizard’s Action Type panel.
An alternative is to select Call a function in a standard dynamic link library in the Action Type panel. In this case,
InstallShield allows you to specify the function’s parameters.
Task There are three major steps involved in passing a parameter to a function in a DLL file written for Windows Installer:
3. Pass the parameter using the Property Manager view. These steps are explained in greater detail below.
MessageBox(GetForegroundWindow( ),
szValue,
TEXT("Value of MYPROPERTY"), MB_OK | MB_ICONINFORMATION);
return ERROR_SUCCESS;
}
For more information, see MsiGetProperty in the Windows Installer Help Library.
If you use a C++ compiler to build your DLL file, ensure that the compiler does not change the function names exported
from the DLL file. With Microsoft Visual C++, for example, you can create a .def file that specifies the function names to be
exported from your DLL file. A typical .def (called MyActions.def) file looks like the following:
LIBRARY MyActions
EXPORTS
MyActionName
For more information about function name decoration, see your compiler documentation.
1. In the View List under Behavior and Logic, click Property Manager.
2. Click the New Property button. InstallShield adds a new row at the bottom of the view.
3. In the Name column, type the name of the property that you would like to retrieve with MsiGetProperty (MYPROPERTY,
in this example).
4. In the Value column, type the value that you want to pass. For example, if you want to pass the URL to your Web site,
type http://www.mycompany.com.
See Also
Custom Action Return Values
• Basic MSI
• InstallScript MSI
There are a number of reasons why you might pass a parameter to a function in a custom action. For example, you might
want to pass a URL for Web registration or the UserName property for a custom user interface. However, Windows Installer
does not directly support passing parameters to DLL file functions.
The entry-point function for a Windows Installer DLL file can have only one argument, which is the handle to the database.
To learn about a suggestion for passing parameters to a DLL file written for Windows Installer, see Calling Functions in
Windows Installer DLL Files.
1. In the Custom Wizard’s Action Type panel, select Call a function in a standard dynamic-link library.
2. In the Function Definition panel, specify the parameters that you want InstallShield to pass to the function.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The managed-code type of custom action calls a public method in a .NET assembly that is written in managed code such as
Visual Basic .NET or C#.
If you include a managed-code custom action in your project, InstallShield creates a C++ Windows Installer wrapper DLL for
your .NET assembly. The wrapper DLL includes your assembly, as well as the information that is required to mediate, load,
and run the assembly.
Note • If you specify that the location of your managed assembly should be the Binary table, InstallShield stores the wrapper
DLL—which includes your assembly—in the Binary table.
See Also
Run-Time Requirements for Managed-Code Custom Actions
Specifying the Signature for a Managed Method in an Assembly Custom Action
Using 32-Bit vs. 64-Bit Managed-Code Custom Actions
Using the Custom Action Wizard
Creating Custom Actions in the Custom Actions and Sequences View (or the Custom Actions View)
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The managed-code type of custom action requires the Microsoft .NET Framework on the target system.
InstallShield includes redistributables for the .NET Framework. If it is possible that target systems may not have the .NET
Framework, you can add the appropriate .NET Framework redistributable to your project. For instructions, see Adding .NET
Framework Redistributables to Projects.
You can use the property IS_CLR_VERSION to identify a semicolon-delimited list of .NET Framework versions that the
custom action should attempt to load to run your managed code. In most scenarios, this property is not set in the
installation package. It is set at the command line. To specify that version 1.1 is required, use the following command-line
parameter:
IS_CLR_VERSION=v1.1.4322
Note that the complete version number of the .NET Framework should be specified for the property value. If more than one
version is acceptable, you can specify a semicolon-delimited list of versions. The first one that can be loaded is used. For
the following example command-line parameter, the custom action attempts to load version 2.0. If that version is not
present, the custom action attempts to load version 1.1. If version 1.1 is not present, the custom action fails.
IS_CLR_VERSION=v2.0.50727;v1.1.4322
To specify that the custom action should attempt to load whatever is the latest version of the .NET Framework that is
installed if none of the specified versions are installed, add a semicolon to the end of the property value, as shown in the
following example:
IS_CLR_VERSION=v2.0.50727;v1.1.4322;
The semicolon at the end of the property value also indicates that if none of the specified versions are present but a version
of the .NET Framework is already loaded, the custom action uses the currently loaded version, even if it is not the latest
version that is installed.
Note • If the execution of your managed-code custom action is set to deferred mode, you must use the Windows Installer
property CustomActionData to pass the IS_CLR_VERSION property and value. To learn more, see Specifying the Signature for
a Managed Method in an Assembly Custom Action.
Tip • If issues with the custom action occur at run time because of .NET Framework version mismatches, you may want to
instruct end users to set the IS_CLR_VERSION property at the command line when they run your installation. Note that for
deferred custom actions, you must have already used the CustomActionData property to pass the IS_CLR_VERSION property.
For more information, see Specifying the Signature for a Managed Method in an Assembly Custom Action.
See Also
Using 32-Bit vs. 64-Bit Managed-Code Custom Actions
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The Managed Method Definition panel in the Custom Action Wizard is where you specify arguments for the method that
your managed assembly custom action should call. You can also specify this information on the Method Signature dialog
box.
For more information, see Custom Action Return Values in the Windows Installer Help Library.
Note that if you use a custom signature, the custom action’s return value is not passed to Windows Installer. However, if
the managed code throws an unhandled exception, the custom action returns ERROR_INSTALL_FAILURE to Windows
Installer. Therefore, in order for the custom action to indicate failure and for Windows Installer abort the installation, the
managed code must throw an unhandled exception.
Using a Custom Method Signature for a Deferred, Commit, or Rollback Custom Action
Deferred, commit, and rollback custom actions have access to only some of the built-in Windows Installer properties:
CustomActionData, ProductCode, and UserSID. Therefore, if you use a custom method signature and you want your
managed assembly custom action to access or pass any other properties during deferred, commit, or rollback execution,
you must pass them through the CustomActionData property. Note the following guidelines for deferred, commit, and
rollback managed assembly custom actions:
• Custom signatures that pass properties need to have their values passed in as CustomActionData in the following
format:
PROPERTYNAME="Property Value"
Separate multiple property name–property value pairs with a space, as in the following example:
• If the managed assembly for your deferred, commit, or rollback custom action is installed with the product, use
CustomActionData to identify the location of the managed assembly, and use the following format:
#filekey.dll="location of assembly"
• If the path for the managed assembly references one or more properties, use CustomActionData to pass each of the
properties and their corresponding values.
IS_CLR_VERSION="[IS_CLR_VERSION]"
If run-time issues occur because your custom action attempts to load the wrong version of the .NET Framework to run
your managed code, you can have end users set the value of the IS_CLR_VERSION property at the command line when
they run your installation. For deferred, commit, and rollback managed-code custom actions, IS_CLR_VERSION must
be passed to CustomActionData in order for end users to use this run-time override. To learn more about the
IS_CLR_VERSION property, see Run-Time Requirements for Managed-Code Custom Actions.
• A single property that is enclosed within square brackets—for example, [ProductName]. Note that immediate-mode
managed assembly custom actions can update ref and out parameters. InstallShield does not support combining
multiple properties or mixing properties with strings for a parameter value.
• An explicit string that is enclosed within quotation marks—for example, “My Project Name-1”.
At run time, after a property has been resolved or a string has been isolated from within its quotation marks, the custom
action attempts to convert the string to an instance of the type of the method’s appropriate parameter. A parameter of
type String is passed as is, and all normal numeric types are handled by calling the public static Parse(string) method to
turn the string into the type. In addition, the custom action calls any type’s public static Parse(string) method and uses the
return value as the passed parameter value. IntPtr is also handled despite the lack of a Parse method.
See Also
Accessing or Setting Windows Installer Properties Through Deferred, Commit, and Rollback Custom Actions
Custom Action Wizard
Method Signature Dialog Box
Using 32-Bit vs. 64-Bit Managed-Code Custom Actions
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
When you build a release that includes a managed-code custom action in your project, InstallShield attempts to determine
the target architecture (32 bit or 64 bit) of the main .NET assembly that is associated with the custom action. InstallShield
does this by examining the portable executable (PE) file for the assembly and determining if the PE file is 32 bit or 64 bit. If
the PE file uses Microsoft intermediate language (MSIL) code, InstallShield treats it as 32 bit. InstallShield configures the
release so that the appropriate version of the .NET Framework—32 bit or 64 bit—is used to run your managed code at run
time.
If you want to override the built-in default behavior, use the Direct Editor view to add a new record with the following fields
to the ISClrWrap table.
Table 4-7 • Overriding the Default Architecture for a Managed-Code Custom Action
Action_ Enter the name of the managed-code custom action that you want to modify.
• To use a 32-bit version of the .NET Framework, enter the following: x86
• To use a 64-bit version of the .NET Framework, enter the following: x64
See Also
Run-Time Requirements for Managed-Code Custom Actions
• Basic MSI
• InstallScript MSI
• Transform
The kill-process type of custom action terminates one or more processes at run time. The following procedure describes
how to include and configure this type of custom action in your project.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. Right-click the Custom Actions explorer and then click New Kill Process. InstallShield adds a kill-process custom
action with a default name.
3. Enter a new name, or right-click it later and click Rename to assign it a new name. Use a name that helps you
distinguish this custom action from other actions in your project.
a. In the In-Script Execution setting, select the iteration of the sequence that should trigger the action. For details
about each option, see In-Script Execution.
b. Use the settings in the Sequences area to schedule the custom action at the point where you want the process to
be terminated. As an alternative, you can drag the custom action from the Custom Actions explorer to the
appropriate node under the Sequences explorer.
• KillProcess—If you selected one of the immediate options in the In-Script Execution setting and you want
to kill a process that has a particular name, select this option.
• KillProcessByID—If you selected one of the immediate options in the In-Script Execution setting and you
want to kill a process that has a particular process identifier (PID), select this option.
• KillProcessDeferred—If you selected one of the deferred, commit, or rollback options in the In-Script
Execution setting and you want to kill a process that has a particular name, select this option.
• KillProcessByIDDeferred—If you selected one of the deferred, commit, or rollback options in the In-Script
Execution setting and you want to kill a process that has a particular PID, select this option.
d. In the Processes setting, enter executable file names or PIDs of the processes that you want to terminate.
If you want to terminate more than one process, use a semicolon (;) to separate each file name or PID. For
example, to terminate processes that have names such as myfile1.exe and myfile2.exe, enter the following:
myfile1.exe;myfile2.exe
Tip • The value of the Processes setting may by written to the ISTerminateProcesses property. If you have
additional kill-process custom actions that do not specify a value in the Processes setting, such as those migrated
from InstallShield 2015 or earlier, shared use of the ISTerminateProcesses property may result in undesired
behavior.
See Also
Using the Custom Action Wizard
• Basic MSI
• InstallScript MSI
• Transform
Windows PowerShell is a .NET Framework–based command-line shell and script language that enables system
administrators to automate system configuration tasks. InstallShield lets you include in your installations custom actions
that run PowerShell scripts (.ps1). You may want to add this type of custom action to a project to perform system
configuration tasks at installation run time. Note that PowerShell actions require PowerShell 2.0 or later on target systems.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. Right-click the Custom Actions explorer, point to New PowerShell, and click one of the following commands:
• Stored in Binary table—To have your code base stored in the Binary table, select this command. This location is
useful if you do not want the file to be installed on the target system.
• Installed with product—To call code from a script file that is going to be installed on the target system, select
this command.
3. Enter a new name, or right-click it later and click Rename to assign it a new name. Use a name that helps you
distinguish this custom action from other actions in your project.
4. In the PowerShell Script File Name setting, select the PowerShell script file (.ps1) in the list of files that are stored in
the Binary table or that are included in your project. If the location that you specified is stored in the Binary table,
you can click this ellipsis button (...) in this setting to browse to the file.
Once you have added the custom action to your project, schedule it as needed. For more information, see Inserting Actions
into Sequences.
To check that PowerShell is installed on a target system, you can add the predefined system search for PowerShell to your
project, and configure your PowerShell custom action to run only if the system search determines that PowerShell is
installed. You can also use this system search to determine which version of PowerShell is installed, and you can include a
condition for the custom action that triggers its launching only on appropriate target systems. By default, the predefined
system search for PowerShell sets the value of the POWERSHELLVERSION property to the version of PowerShell.
You can use the Windows Installer property IS_CLR_VERSION to identify a semicolon-delimited list of .NET Framework
versions that the custom action should attempt to load to run your PowerShell script.
To learn more about the POWERSHELLVERSION and IS_CLR_VERSION properties, see Windows Installer Property Reference.
Table 4-8 • Cmdlets that Interact with a Running Basic MSI or InstallScript MSI Installation
Cmdlet Description
get-property -name [Property Name] This cmdlet gets the value of a Windows Installer property. The Name
parameter is a positional parameter.
The following sample code gets the value of the property called MYPROPERTY:
set-property -name [Property Name] - This cmdlet sets the value of a Windows Installer property. The Name and
value [value] Value parameters are positional parameters.
The following sample code uses the value of the MYPROPERTY property to set
the value of a second property called NEWPROPERTY:
Table 4-8 • Cmdlets that Interact with a Running Basic MSI or InstallScript MSI Installation (cont.)
Cmdlet Description
format-properties -Value [format This cmdlet expands the value of a formatted expression. The Value
string] parameter is a positional parameter.
The following sample code formats a string that contains a Windows Installer
property called NEWPROPERTY. The property name and its surrounding square
brackets are replaced by the value of the property at run time.
trace-info -LogMessage [log string] This cmdlet writes any information that is needed to the Windows Installer
log, making it available for debugging or other information purposes. The
LogMessage parameter is a positional parameter.
To indicate that your script has succeeded, ensure that it returns 0. For example, you may want to end your script with the
following:
exit(0)
See Also
Using the Custom Action Wizard
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Launching an executable file from your installation is useful to install third-party tools, display a readme file, or display a
Web page that contains the most up-to-date information about the product being installed. To launch an executable file
from within your installation, you need to add a custom action in the Custom Actions and Sequences view (in Basic MSI,
InstallScript MSI, MSI Database, and Transform projects) or the Custom Actions view (in DIM, Merge Module, and MSM
Database projects).
You can use the Custom Action Wizard to create the custom action that launches an executable file from your installation.
Each wizard panel is listed below, with the entries that you need to make in order to launch an executable file.
Table 4-9 • Settings for the Basic Information Panel in the Custom Action Wizard
Name Provide a meaningful name for your custom action. This name is used internally in your product and
is for identification purposes only.
Action Type
Table 4-10 • Settings for the Action Type Panel in the Custom Action Wizard
Type Select the type of custom action that you want to create. For this example, select Launch an
executable.
Location The selection that you make depends on where the target executable file will be during the
installation. Because Notepad is on everyone’s machine, it is the target for this custom action.
Because Notepad is practically guaranteed to be present in the target machine’s Windows folder,
you can point to it using the Directory table. Therefore, select Stored in the Directory table.
Action Parameters
Table 4-11 • Settings for the Action Parameters Panel in the Custom Action Wizard
Source Since you choose to launch an executable file stored in the Directory table, you are given a list of
choices that reflect all of your current entries in the Directory table. One of these options is
WindowsFolder. Choose this option to point to Notepad without having to hard-code a path.
Target For this option, you need to enter the target file within the specified directory from the Source
option. Enter Notepad.exe and click the Next button to continue.
Additional Options
Table 4-12 • Settings for the Additional Options Panel in the Custom Action Wizard
Return Specify how Windows Installer should control the processing of the custom action thread. You can
Processing have the main and custom action threads run synchronously (the installation waits for the custom
action thread to complete before resuming the main installation thread) or asynchronously (the
installation runs the custom action simultaneously as the main installation continues).
Respond Options
Table 4-13 • Settings for the Respond Options Panel in the Custom Action Wizard
In-Script Select Immediate execution to have your action executed as soon as it is encountered in the script.
Execution
Execution Select Always execute so that your custom action launches every time that it is encountered.
Scheduling
See Also
Launching an Installation from Another InstallScript Installation
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
An alternative to launching a second .msi package using the nested installation custom action type is to create a custom
action that launches Msiexec.exe instead. Launching a second installation in this manner causes it to run in its own
process and creates the proper entries on the target system. In addition, the uninstallation process is much more effective
when you launch your second installation in this way. Registry entries are properly cleaned up and reference counts are
incremented and decremented accurately.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI, InstallScript MSI, MSI
Database, and Transform projects) or Custom Actions (in DIM, Merge Module, and MSM Database projects).
2. Right-click the Custom Actions explorer and click Custom Action Wizard. The Custom Action Wizard opens.
3. On the Basic Information panel, specify a name and comment for your custom action and click Next.
4. On the Action Type panel, in the Type list, select Launch an executable. In the Location list, select Stored in the
Directory table. The Directory table allows you to choose from predefined folders, such as SystemFolder, which is
where Msiexec.exe is located.
5. On the Action Parameters panel, browse for the executable file (Msiexec.exe) of that you are launching. The Target
box enables you to specify the name of the executable file that you would like to launch, as well as any command-line
parameters that you would like to pass to it. For example:
The first part of this entry, msiexec.exe, is the name of the executable file that you would like to launch. The next
section, /i "[SOURCEDIR]AnotherSetup\SecondSetup.msi", tells Msiexec.exe which package to run. In this case, it
is pointing to a file one folder below that of the source folder of the initial installation. Finally, /qb tells the Windows
Installer service to run the installation with minimal user interface. Only a progress bar is displayed.
6. On the Additional Options panel, select the default options and click Next until you finish the wizard.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI, InstallScript MSI, MSI
Database, and Transform projects) or Custom Actions (in Merge Module and MSM Database projects).
2. In the Sequences explorer, under the Installation sequence, expand the User Interface item. The actions and dialogs
that are scheduled for this sequence are listed.
3. Right-click CostFinalize and click Insert. The Insert Action dialog box opens.
5. Click OK.
Next, verify that the installation package that you want to launch is located in the folder that you specified in the Action
Parameters panel, build your installation, and run it.
Note • A custom action that launches Msiexec.exe must be placed in the User Interface sequence, which means that the
custom action will not run if the end user runs the installation silently.
See Also
Nested Installations
MsiExec.exe Command-Line Parameters
Nested Installations
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Important • Nested installations is a deprecated feature of the Windows Installer. Applications installed with nested
installations sometimes fail because they are difficult for end users to service correctly. Microsoft Corporation recommends
that you avoid using nested installations and nested-installation custom actions to install products that are intended to be
released to the public. To learn more, see Concurrent Installations in the Windows Installer Help Library.
A nested installation is a type of custom action that installs or removes another .msi package (sometimes called the child
product) from within a running installation (called the parent product).
Note • Before using nested-installation custom actions, you should be aware of the following restrictions:
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Important • Nested installations is a deprecated feature of the Windows Installer. Applications installed with nested
installations sometimes fail because they are difficult for end users to service correctly. Microsoft Corporation recommends
that you avoid using nested installations and nested-installation custom actions to install products that are intended to be
released to the public. To learn more, see Concurrent Installations in the Windows Installer Help Library.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. Right-click the Custom Actions explorer and click Custom Action Wizard. The Custom Action Wizard opens.
3. On Basic Information panel, specify a name and comment for your custom action and click Next.
4. On the Action Type panel, in the Type list, select Launch another .msi package. In the Location list, select Included
within your main setup.
5. On the Action Parameters panel, browse for the location of the .msi file that you are launching. (For simplicity,
assume that the child product is packaged with all files compressed into the .msi package.) The Target box enables
you to specify command-line switches to pass to the child installation. For example, to install all of the features of the
child installation with their default settings, and to use the same value for the ALLUSERS property used by the parent
installation, type the following in the Target box:
You can use similar expressions to use the same value of INSTALLDIR in the child as in the parent.
6. Accept the default options on the Additional Options panel and click Next until you finish the wizard.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Important • Nested installations is a deprecated feature of the Windows Installer. Applications installed with nested
installations sometimes fail because they are difficult for end users to service correctly. Microsoft Corporation recommends
that you avoid using nested installations and nested-installation custom actions to install products that are intended to be
released to the public. To learn more, see Concurrent Installations in the Windows Installer Help Library.
After you have created the custom action, you need to insert it into a sequence.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, under the Installation sequence, expand the User Interface item. The actions and dialogs
that are scheduled for this sequence are listed.
3. Right-click CostFinalize and click Insert. The Insert Action dialog box opens.
5. In the Condition box, type Not Installed. This indicates that the nested installation should be performed only the
first time that the parent product is installed.
6. Click OK.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Important • Nested installations is a deprecated feature of the Windows Installer. Applications installed with nested
installations sometimes fail because they are difficult for end users to service correctly. Microsoft Corporation recommends
that you avoid using nested installations and nested-installation custom actions to install products that are intended to be
released to the public. To learn more, see Concurrent Installations in the Windows Installer Help Library.
A child product is not automatically removed when the parent product is removed. However, you can create a second
nested-installation custom action that does this.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. Right-click the Custom Actions explorer and click Custom Action Wizard. The Custom Action Wizard opens.
3. On the Basic Information panel, specify a name and comment for your custom action and click Next.
4. On the Action Type panel, in the Type list, select Launch another .msi package. In the Location list, select An
application that is advertised or already installed.
5. On the Action Parameters panel, browse for the location of the .msi file that you want to remove. In the Target box,
leave the default properties:
ALLUSERS=[ALLUSERS] REMOVE=ALL
6. Accept the default options on the Additional Options panel and click Next until you finish the wizard.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, under the Installation sequence, expand the Execute item. The actions and dialogs that
are scheduled for this sequence are listed.
3. Right-click InstallValidate and click Insert. The Insert Action dialog box opens.
REMOVE="ALL"
6. Click OK.
This custom action will uninstall the child product when the parent product is uninstalled.
Note • When you are creating a nested-installation custom action of type Launch another .msi package with the Location
setting set to Stored on the source media, be aware of the following:
• The child installation must not be compressed inside a Setup.exe installation launcher.
• If the child installation’s files are not compressed inside the child .msi database, you must manually copy the child
installation’s files to the Disk1 folder of the parent installation’s release folder.
See Also
Using Msiexec.exe to Launch a Second Windows Installer Installation
DoInstall
Action Parameters Panel (in the Custom Action Wizard)
• Basic MSI
• InstallScript MSI
Task To call the Windows API function MessageBoxA() in a custom action to display a message box:
2. Right-click the Custom Actions explorer and click Custom Action Wizard.
2. In the Action Type panel, for the custom action’s type, select Call a function in a standard dynamic-link library.
3. Since MessageBoxA is exported in User32.dll, which is found on every supported Windows platform, select
Destination machine search path in the Location list. Click Next to continue.
2. Click the last row in the Arguments box to specify the first parameter. Edit the fields for each parameter until they
mirror the following list:
NUMBER Constant 1
In the Value list for the HWND type, select MsiWindowHandle. If you set the HWND type to this value, your message
box will not hide behind the installation window. The properties MESSAGEPROP and CAPTIONPROP are not available in
the list. When you enter these names in the Value list, they are added to the Property Manager.
3. In the Return Type list, select void. (Although MessageBoxA() does return a number, checking that value in a
property is outside the scope of this example.)
In the next panel of the wizard, click Next to accept the defaults, and then click Finish in the Summary panel to dismiss the
wizard and add CA_Example to your project.
1. In the View List under Behavior and Logic, click Property Manager to view the installer properties in your project.
The properties MESSAGEPROP and CAPTIONPROP were created as a result of referencing these properties in the Custom
Action Wizard.
2. Locate MESSAGEPROP and click in its Value column to supply a value. Enter Can you see this text? for the value.
Follow the steps below to insert CA_Example into the Installation sequence of the installation project:
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, under the Installation sequence, expand the User Interface item. The actions and dialogs
that are scheduled for this sequence are listed.
3. Right-click the MigrateFeatureStates action (the action right before the InstallWelcome dialog) and click Insert. The
Insert Action dialog box opens.
4. In the list at the top of the dialog box, select Custom Actions (for installation projects).
6. Click OK.
InstallShield runs your installation. After the Welcome dialog is displayed, a Custom Action Example message box opens.
See Also
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
For example, to search for a file called FindMe.exe, use the Direct Editor to add the following record to the Signature
table.
Signature findme_sig
FileName FindMe.exe
Note that other fields in the Signature table enable you to specify optional version, size, date, and language information.
There are four locator tables in which you can specify where Windows Installer should begin searching for the file:
CompLocator, RegLocator, IniLocator, and DrLocator. To search for a file in a specific directory, use the DrLocator
table. For example, to search for FindMe.exe in the user’s Program Files directory, we add the following record to the
DrLocator table.
Signature findme_sig
Parent
Path [ProgramFilesFolder]
Depth 2
After the AppSearch action runs, the public property LOCATION_OF_FINDME will contain the full path to FindMe.exe on the
end user’s system if it exists; if the file is not located, this property will be undefined.
function OnAppSearch( )
STRING svFoundFile;
begin
end;
See Also
System Search View
Direct Editor
The LaunchApplication function launches an executable file. For example, the following code launches a copy of
Program.exe in the end user’s INSTALLDIR folder, returning execution to the script when the end user closes the program’s
window.
An InstallScript entry-point function that returns the value ERROR_INSTALL_FAILURE causes the installation to exit.
See Also
exit
abort
If you want to change ODBC properties (such as DBQ and SystemDB) through script, you must configure these options to
use installer properties. Then from the script you can set those installer properties at run time. For example, you would set
SystemDB to [SYSTEM_DB_DIR]\MyDatabase in the InstallShield interface. Then from the script, you could call
MsiSetProperty to set the value of SYSTEM_DB_DIR.
Tip • Set the property value before the OnMoving event, preferably in OnFirstUIBefore. After that, it is too late because the
installer has already built up its internal script information, which cannot be modified.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
If you need to use the INSTALLDIR property in a VBScript custom action, use the Property property of the Session object.
This object is accessible in every VBScript custom action.
szInstallDir = Session.Property("INSTALLDIR")
For more information, see Session Object in the Windows Installer Help Library.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
To keep end users informed, installations commonly display text on the progress dialog to describe the installation’s
current activity. This usually accompanies the progress bar as a means of installation status. As each standard action and
custom action is encountered, a message about the action is displayed on the progress dialog. This may be especially
useful for actions that take a long time to execute. The same action text is also written to the installation’s log file if one is
created.
An action can also send action data that needs to be processed to the Windows Installer; once the data is processed, it can
be displayed on the progress dialog.
For example, when the InstallFiles action is executing, the action text “Copying new files” is displayed by default on the
progress dialog. This action text is also written to the installation’s log file. If you want to provide additional detailed
information about what is occurring as actions are encountered, you can add a control to the progress dialog to show
action details; the control would need to subscribe to the ActionData event. For the InstallFiles action, this could include
the name, directory, and size of each file as it is being installed on the target system.
Project • InstallScript MSI installations cannot display action data on the status dialog. However, the template is written to
the installation’s log file.
See Also
Specifying an Action Description and a Template for Action Data
Displaying Action Descriptions on the Progress Dialog
Displaying Action Data on the Progress Dialog
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
InstallShield includes default action descriptions for standard actions and built-in InstallShield custom actions.
InstallShield also includes default templates for many of those actions where appropriate. The templates indicate the
format that should be used for the action data.
You may want to modify the default descriptions or templates of the standard actions and built-in InstallShield custom
actions in your project. In addition, you may want to specify action text and action data format for your own custom
actions.
Task To specify a description and an action data template for an action in your project:
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. Right-click the Action Text explorer and click New. InstallShield adds a new action text item.
3. For the name of the action text item, enter the name of the action.
Important • The names of the action text items under the Action Text explorer should match the names of standard and
custom actions that are in your project. If you change the name of a custom action, you must also change the name of its
action text item; otherwise, the action’s text is not displayed at run time or written to the installation’s log file. Note,
however, that you are not required to create action text for every action in your project.
4. In the right pane, specify the description and the template. For more information, see Action Text Settings.
Tip • If you want to edit the description or template of an action that is already listed under the Action Text explorer, select the
action and then specify the appropriate values in the right pane.
See Also
Displaying Action Descriptions on the Progress Dialog
Displaying Action Data on the Progress Dialog
Custom Actions and Sequences View (or Custom Actions View)
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
In InstallScript MSI installations, the action text is automatically displayed on the progress dialog (that is, the STATUSEX
dialog) if the dialog is enabled through a call to Enable (STATUSEX). This dialog is not available for editing.
By default, if a description has been specified for an action in your installation, that description is displayed above the
progress bar on the progress dialog. Therefore, unless you have made some changes to this dialog in your project, you do
not need to perform the following steps.
1. On the SetupProgress dialog, add a control that will display the action description:
b. In the Dialogs explorer, expand the All Dialogs folder, and then expand the SetupProgress dialog.
c. Click a language under the SetupProgress dialog. The Dialog Editor in the center pane shows the dialog in the
selected language.
e. Draw a rectangle on the dialog in the location where you want the action description to be displayed.
2. With the control selected, configure its settings in the right pane:
ActionText
a. In the Dialogs explorer under the SetupProgress dialog, click the Behavior item. The grid in the center pane
shows all of the controls on the SetupProgress dialog.
b. Select the ActionText control that you just created, and then click the Subscriptions tab in the lower-right pane.
c. In the upper-right pane, add a record with the following information: For the Event field, select ActionText. For
the Attribute field, enter Text.
At run time, if the installation is run with a full or reduced user interface, the progress dialog shows the description of each
action as it is encountered. If a description has not been defined for an action, no description is displayed on the progress
dialog when that action is launched.
See Also
Displaying Action Data on the Progress Dialog
Dialogs View (Basic MSI and Other Windows Installer–Based Projects)
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
In InstallScript MSI installations, the action data cannot be displayed on the progress dialog (that is, the STATUSEX dialog).
However, you can call Enable (INDVFILESTATUS) in your InstallScript to achieve a similar result. If you call the INDVFILESTATUS
constant with the Enable function, the STATUSEX dialog shows the fully qualified file name of each file as it is transferred when
FeatureMoveData, CopyFile, or XCopyFile is called and the progress indicator is enabled. Note that if a template is specified
for an action in an InstallScript MSI project, the template is written to the installation’s log file.
If you want to provide detailed information about what is occurring as actions are launched at run time, you can add a
control to the progress dialog to show action details; the control would need to subscribe to the ActionData event. For
example, when the InstallFiles action is executing, the control that shows the action details could include the name,
directory, and size of each file as it is being installed on the target system.
1. On the SetupProgress dialog, add a control that will display the action details:
b. In the Dialogs explorer, expand the All Dialogs folder, and then expand the SetupProgress dialog.
c. Click a language under the SetupProgress dialog. The Dialog Editor in the center pane shows the dialog in the
selected language.
e. Draw a rectangle on the dialog in the location where you want the action description to be displayed.
2. With the control selected, configure its settings in the right pane:
ActionData
a. In the Dialogs explorer under the SetupProgress dialog, click the Behavior item. The grid in the center pane
shows all of the controls on the SetupProgress dialog.
b. Select the ActionData control that you just created, and then click the Subscriptions tab in the lower-right pane.
c. In the upper-right pane, add a record with the following information: For the Event field, select ActionData. For
the Attribute field, enter Text.
At run time, if the installation is run with a full user interface, the progress dialog shows the details of each action as it is
launched. If a template has not been defined for an action, the details are not displayed on the progress dialog when that
action is launched.
See Also
Enable
Displaying Action Descriptions on the Progress Dialog
Dialogs View (Basic MSI and Other Windows Installer–Based Projects)
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Task To remove a description or an action data template for an action in your project:
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Action Text explorer, select the action whose description or template you want to delete.
Note • If you want neither the action description or the action template to be used, you can delete the action text record from
your project: In the Action Text explorer, right-click the action text item that you want to remove, and then click Delete.
Note that the action text for the following actions cannot be deleted:
• GenerateScript
• Rollback
• RollbackCleanup
In addition, the value of the Template setting for each of these actions must always be [1].
See Also
Custom Actions and Sequences View (or Custom Actions View)
Defining Sequences
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Defining the sequences of an installation is an important part of developing an installer package. Sequences specify the
order in which Windows Installer launches the standard and custom actions that control the installation process.
Project • In Basic MSI and Transform projects, sequences also specify the order in which the dialogs are displayed.
In InstallScript MSI projects, the user-interface dialogs are defined in the InstallScript code, and the InstallScript engine
controls the user interface part of the installation.
The Custom Actions and Sequences view in InstallShield is where you define the sequences of your project. The Sequences
explorer in this view lists all of the actions and dialogs in your project in chronological order, according to when they are
launched during the applicable sequence. Each action and dialog is given a number in the sequence, and Windows Installer
runs the sequence from the lowest number to the highest number.
Rather than having to manually provide a numeric value for every custom action and dialog that you add to your project,
you can use the Custom Actions and Sequences view to insert actions or dialogs into a sequence or edit the sequence
timeline. Refer to this section of the help for information about sequences.
Project • If you create a custom action or a custom dialog in a merge module, you need to first import that module into an
installation project and then add it to a sequence through the Custom Actions and Sequences view.
See Also
Custom Actions and Sequences View (or Custom Actions View)
Installation Sequence
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The installation sequence is the series of actions that are executed when the installation runs in the default installation
mode, such as when an end user double-clicks a new .msi file. These actions are broken down into two types:
• User Interface
• Execute
Project • The User Interface dialogs described below are those for a Basic MSI project. For an InstallScript MSI project, your
InstallScript code performs the user interface of the installation.
An InstallScript MSI project automatically includes the ISVerifyScriptingRuntime custom action. For details, see
ISVerifyScriptingRuntime.
User Interface
The User Interface sequence contains all of the actions and dialogs needed to support a full user interface. This sequence is
skipped if an installation is run in silent mode.
For complete technical details about each standard action, see the Standard Actions Reference in the Windows Installer
Help Library.
SetupInterrupted Dialog This dialog is displayed at the end of an installation that was
ended by the user.
ISSetupFilesExtract Custom action This custom action extracts any files that you have added in the
Support Files view. For more information, see Using Support
Files.
ISSetAllUsers Custom action The ISSetAllUsers custom action is inserted in the both the User
Interface and Execute installation sequences only if one or
more records are in the Upgrade table.
AppSearch Standard action This action can be used to identify and locate files on the target
system. The Signature table that this action requires is available
in the Direct Editor. Knowledge Base article Q103147 provides
detailed information on using this action.
LaunchConditions Standard action This action evaluates a set of conditions that must return True if
the installation is to continue. If any conditions fails, the user is
presented with an error message and the installation ends.
Launch conditions can be edited in the General information
view.
SetupInitialization Dialog This dialog is displayed while the setup is preparing to begin.
The default text for this dialog is "Preparing to install..."
FindRelatedProducts Standard action When this action is executed, the installer compares each
installed product’s upgrade code to that listed in the package’s
Upgrade table. If a match is found, the installed package’s
product code is added to the ActionProperty column of the
Upgrade table.
CCPSearch Standard action The CCPSearch action allows you to check the end user’s
system for products qualifying for upgrade. The Signature table
that this action requires is available in the Direct Editor.
Table 4-18 • User-Interface Actions and Dialogs in the Installation Sequence (cont.)
RMCCPSearch Standard action The RMCCPSearch action allows you to check an end user’s
system for products qualifying for competitive upgrade. The
Signature table that this action requires is available in the
Direct Editor.
ValidateProductID Standard action Use the Validate Product ID action to set the ProductID property
to the complete product identifier. This validation allows you to
protect your software from illegal use by requiring users to
enter the product ID.
CostInitialize Standard action This action is the first step in determining how much disk space
is required by the current configuration of the installation. In
order to complete costing, you need to use the CostInitialize
action in conjunction with the CostFinalize action.
FileCost Standard action The FileCost action determines how much disk space is
required by the current configuration of the installation. It
checks to see if any files will be overwritten with later versions,
and it calculates how overwriting those files affects disk space.
To complete costing, you need to use the CostInitialize action in
conjunction with the CostFinalize action.
setUserProfileNT Custom action This custom action initializes the USERPROFILE directory
identifier.
SetAllUsersProfileNT Custom action This custom action initializes the ALLUSERSPROFILE directory
identifier.
setAllUsersProfile2K Custom action This custom action initializes the ALLUSERSPROFILE directory
identifier.
ResolveSource Standard action Finds the location of the source and sets the SourceDir
property.
CostFinalize Standard action The Calculate Disk Space action determines the total amount of
disk space required by the installation in its current
configuration. This action also verifies that all target directories
are writable. The actions Initialize Disk Space Calculations and
Initialize Dynamic Disk Space Calculations must be called
before the Calculate Disk Space action; otherwise, the action
will fail.
Table 4-18 • User-Interface Actions and Dialogs in the Installation Sequence (cont.)
SetARPReadme Custom action The SetARPReadme custom action resolves the directory
identifier used in the Read Me setting in the General
Information view. This custom action is required because
ARPREADME is a Windows Installer property and these
properties do not format automatically.
MigrateFeatureStates Standard action This action is used during application upgrade. The feature
states of the original installation are read from the target
machine and applied to the upgraded features.
InstallWelcome Dialog The InstallWelcome dialog displays your Welcome panel when
an InstallScript MSI installation is run.
MaintenanceWelcome Dialog This dialog opens when the end user tries to change a
program’s installed features, remove the program, reinstall the
program, run an installation for the second time, or select the
current product in Add or Remove Programs.
ExecuteAction Standard action This action queries the EXECUTEACTION property to determine
which top-level action should be called first, and then calls that
top-level action. Top-level actions include the INSTALL,
ADVERTISE, and ADMIN actions. Typically, this action starts the
Installation Execute sequence.
ISSetupFilesCleanup Custom action This custom action appears when you add a file in the Support
Files view. For more information, see Using Support Files.
Execute
The Execute sequence contains all of the actions that can change the machine’s state and do not rely upon the user
interface in order to function properly. These actions include file transfer, publishing components and features, and
registering COM servers. Most of the Execute sequence is skipped when you run your installation in test mode, except for
custom actions that have been inserted into the sequence.
ISSetupFilesExtract Custom action This custom action extracts any files that you have added in the
Support Files view. For more information, see Using Support
Files.
ISSetAllUsers Custom action The ISSetAllUsers custom action is inserted in the both the
User Interface and Execute installation sequences only if one or
more records are in the Upgrade table.
AppSearch Standard action This action can be used to identify and locate earlier versions of
your product. The Signature table that this action requires is
available in the Direct Editor. Knowledge Base article Q103147
provides detailed information on using this action.
LaunchConditions Standard action This action evaluates a set of conditions that must return True
if the installation is to continue. If any condition fails, the
installation displays an error message and the installation
ends. You can edit launch conditions in the General
Information view.
FindRelatedProducts Standard action When this action is executed, the installer compares each
installed product’s upgrade code to that listed in the package’s
Upgrade table (supported in the Direct Editor). If a match is
found, the installed package’s product code is added to the
ActionProperty column of the Upgrade table.
CCPSearch Standard action The CCPSearch action enables you to check the end user’s
system for products qualifying for upgrade. The Signature
table that this action requires is available in the Direct Editor.
RMCCPSearch Standard action The RMCCPSearch action enables you to check an end user’s
system for products qualifying for competitive upgrade. The
Signature table that this action requires is available in the
Direct Editor.
ValidateProductID Standard action Use the ValidateProductID action to set the ProductID property
to the complete product identifier. Validation allows you to
protect your software from illegal use by requiring end users to
enter the product ID.
Table 4-19 • Execute Actions and Dialogs in the Installation Sequence (cont.)
CostInitialize Standard action This action is the first step in determining how much disk space
is required by the current installation configuration.
FileCost Standard action This action determines how much disk space will be required
by the current installation configuration. This action checks to
see if any files will be overwritten with newer versions and
calculates how overwriting those files will affect disk space.
CostFinalize Standard action The CostFinalize action determines the total amount of disk
space required by the current installation configuration. This
action also verifies that all target directories are writable.
SetARPINSTALLLOCATION Custom action The SetARPINSTALLLOCATION custom action sets the value of
the ARPINSTALLLOCATION property to the fully qualified path
for the application’s primary folder.
SetODBCFolders Standard action The SetODBCFolders action checks for existing ODBC drivers
on the target system and sets the target directory of each new
driver to the location of an existing driver.
MigrateFeatureStatus Standard action This action is used during application upgrade. The feature
states of the original installation are read from the target
machine and applied to the upgraded features.
InstallValidate Standard action The InstallValidate action determines if there is enough disk
space available for the current installation configuration.
InstallInitialize Standard action The InstallInitialize action signals the beginning of the actions
that make changes to the end user’s system.
AllocateRegistrySpace Standard action The installer makes sure that the system has at least as much
free registry space available as specified in the
AVAILABLEFREEREG property when it performs this action.
Table 4-19 • Execute Actions and Dialogs in the Installation Sequence (cont.)
StopServices Standard action This action stops the Windows services that are configured to
be stopped. For more information, see Installing, Controlling,
and Configuring Windows Services.
DeleteServices Standard action This action removes the Windows services that are configured
to be deleted. For more information, see Installing, Controlling,
and Configuring Windows Services.
SelfUnregModules Standard action This action unregisters files registered by data in the SelfReg
table.
UnregisterTypeLibraries Standard action During uninstallation, this action unregisters every file in the
TypeLib table that is marked for uninstallation. This table is
populated when you create a new TypeLib through the COM
Registration advanced setting.
RemoveODBC Standard action During uninstallation, this action queries the ODBCDataSource
table, ODBCTranslator table, and ODBCDriver table to find
which ODBC resources should be removed during
uninstallation. The resources that are marked for removal are
uninstalled.
UnregisterFonts Standard action This action unregisters information about all the fonts that are
set for uninstallation.
Table 4-19 • Execute Actions and Dialogs in the Installation Sequence (cont.)
RemoveRegistryValues Standard action The RemoveRegistryValues action removes values from the
end user’s registry if all of the following conditions are met:
UnregisterClassInfo Standard action This action manages system registry information removal for
COM classes that belong to features that are being uninstalled.
UnregisterExtensionInfo Standard action This action unregisters all extension-related information from
the end user’s system during uninstallation.
UnregisterProgIdInfo Standard action This action unregisters all of the ProgIDs created in the File
Types advanced setting.
UnregisterMIMEInfo Standard action This action queries the MIME table of the current feature that is
being uninstalled, and unregisters the MIME information for
the servers found therein. This information is created through
the File Types advanced setting.
RemoveIniValues Standard action This action removes only the .ini information that has been
associated with a component in the IniFile table—or using
the INI File Changes view. After verifying the presence in the
IniFile table, this action removes all .ini files that are listed in
the RemoveIniFile table if the component with which those
files are associated is marked for uninstallation and the
component was installed locally or set to run from source. The
RemoveIniValues action also removes all .ini files that were
written with the WriteIniValues action if the components with
which they are associated are marked to be uninstalled.
RemoveShortcuts Standard action This action removes all advertised shortcuts to features that
are marked for uninstallation. It also removes all non-
advertised shortcuts to components that are marked for
uninstallation.
RemoveEnvironmentStrings Standard action When a component is removed, this action reverses any
changes made to environment variables by the
WriteEnvironmentStrings action during installation or
reinstallation. You can specify environment variable changes
using the Environment Variables view.
Table 4-19 • Execute Actions and Dialogs in the Installation Sequence (cont.)
RemoveDuplicateFiles Standard action This action removes files that were created by the
DuplicateFiles action. For this action to succeed, the
component associated with the duplicate file must be marked
for uninstallation.
RemoveFiles Standard action This action removes files that were originally installed by the
InstallFiles action, if those files were set to run from source or
installed locally, and the component with which they are
associated is marked for uninstallation.
RemoveFolders Standard action The Remove Folders action unregisters and removes any
empty folders that are associated with components that are
marked for uninstallation and run from source.
CreateFolders Standard action This action creates empty folders for components that are set
to be installed locally. These new folders are then registered
with the associated component GUID (found in the
component’s Component Code property).
MoveFiles Standard action This action enables you to move or copy files that already exist
on the target system. The MoveFiles table, used by this action,
is available in the Direct Editor.
InstallFiles Standard action The InstallFiles action copies all of the selected feature’s files
to the target machine if the component feature to which those
files belong is marked for installation. Only files that are
associated with components that are to be installed locally are
copied to the target machine.
PatchFiles Standard action This action queries the Patch table to determine which
installed files have patches available. Those files undergo the
bit-wise patching process.
DuplicateFiles Standard action The DuplicateFiles action creates copies of certain files
installed with the InstallFiles action. These files can be copied
to the same directory as the original and given a different
name, or they can be copied to a separate directory while
maintaining the original name. The DuplicateFiles table,
used by this action, is available in the Direct Editor.
BindImage Standard action Writes the virtual address of imported DLL file functions in the
file’s import address table, as specified in the BindImage table,
which is available in the Direct Editor.
Table 4-19 • Execute Actions and Dialogs in the Installation Sequence (cont.)
CreateShortcuts Standard action This action creates the shortcuts that you specified in the
Shortcuts explorer in the Shortcut view or the Setup Design
view.
RegisterClassInfo Standard action This action registers all of the COM class info that you specified
in the COM Registration advanced setting, or which was
extracted by the Component Wizard or a component’s COM
Extract at Build setting.
RegisterExtensionInfo Standard action The RegisterExtensionInfo action registers all the extensions
that you specified in the File Types advanced setting.
RegisterProgIdInfo Standard action This action registers all of the ProgIDs that you defined in the
Advanced Settings and that are linked to class servers or
extension servers marked for installation.
RegisterMIMEInfo Standard action This action registers all of the MIME types that you defined in
the File Types advanced setting that are linked to class servers
or extension servers marked for installation.
WriteRegistryValues Standard action This action writes registry data to the target system if the
associated component is marked for installation and set to run
from source or installed locally. This registry information is the
same data that you created in the Registry view.
WriteIniValues Standard action This action writes information to .ini files if the component
with which this action is associated is set to be installed locally
or run from source. This action and its corresponding tables are
exposed in the INI File Changes view.
WriteEnvironmentStrings Standard action When a component is installed, this action changes the
environment variables on the system specified in the
Environment table or the Environment Variables view.
RegisterFonts Standard action The RegisterFonts action registers any fonts that you included
in your installation. In most cases, they were included using the
Component Wizard.
InstallODBC Standard action This action installs all of the drivers, translators, and data
sources for the ODBC resources that you specified through the
ODBC Resources view.
RegisterTypeLibraries Standard action This action registers any type libraries that you may have
created in your installation, either through the COM
Registration advanced setting or the Component Wizard.
Table 4-19 • Execute Actions and Dialogs in the Installation Sequence (cont.)
SelfRegModules Standard action This action registers self-registering modules listed in the
SelfReg table. This action is performed with the default user
privileges.
InstallServices Standard action This action installs the Windows services that are configured to
be installed. For more information, see Installing, Controlling,
and Configuring Windows Services.
MsiConfigureServices Standard action This action configures extended customization options for
Windows services. For more information, see Installing,
Controlling, and Configuring Windows Services.
StartServices Standard action This action starts all services that are configured to be started.
For more information, see Installing, Controlling, and
Configuring Windows Services.
RegisterUser Standard action This action registers user information to identify the user of the
program.
RegisterProduct Standard action This action registers the product with the installer and saves
the installer database on the target machine.
PublishComponents Standard action This action publishes all components that are associated with
advertised features.
PublishFeatures Standard action This action registers each feature’s installation state. This state
can be absent, advertised, or installed. If the feature is
installed, the PublishFeatures action writes the feature-
component relationship to the registry.
ScheduleReboot Standard action Insert the ScheduleReboot action into the action sequence to
prompt the end user to reboot the system at the end of an
installation. The ScheduleReboot action is typically placed at
the end of the sequence.
Table 4-19 • Execute Actions and Dialogs in the Installation Sequence (cont.)
RemoveExistingProducts Standard action This action loops through all the product codes listed in the
Upgrade table and removes those products.
ISSetupFilesCleanup Custom action This custom action appears when you add a file in the Support
Files view. For more information, see Using Support Files.
Advertisement Sequence
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The Advertisement sequence is the list of actions that occur when an end user launches your installation with the /j
command-line option for MsiExec.exe. The built-in actions in this sequence are described in the table below.
User Interface
Validation rule ICE78 requires the Advertisement User Interface sequence to be empty.
Execute
The Execute sequence contains all the actions that do not rely upon the user interface in order to function properly. These
actions include file transfer, publishing components and features, and registering COM servers.
For complete technical details about each standard action, see the Standard Actions Reference in the Windows Installer
Help Library.
CostInitialize Standard action The first step in determining how much disk space is required
by the current configuration of the installation.
CostFinalize Standard action Determines the total amount of disk space required by the
installation in its current configuration.
InstallValidate Standard action Determines if there is enough disk space available for the
current configuration.
InstallInitialize Standard action Marks the beginning of the actions that make changes to the
end user’s system.
CreateShortcuts Standard action Creates the shortcuts specified in the Shortcuts view or the
Setup Design view.
RegisterClassInfo Standard action Registers all of the COM class information specified in the COM
Registration advanced setting.
RegisterExtensionInfo Standard action Registers all of the extensions specified in the File Types
advanced setting.
RegisterProgIdInfo Standard action Registers all of the ProgIDs that defined in the COM
Registration advanced setting if its component is being
advertised.
RegisterMIMEInfo Standard action Registers all of the MIME types that are defined in the File Types
advanced setting if its component is being advertised.
RegisterTypeLibraries Standard action Registers any type libraries that were created in the
installation, either through the COM Registration advanced
setting or the Component Wizard.
PublishComponents Standard action Publishes all components that are associated with features
that are being advertised.
PublishFeatures Standard action Registers each feature’s installation state. This state can be
absent, advertised, or installed. If the feature is installed, this
action writes the feature-component relationship to the
registry.
See Also
MsiExec.exe Command-Line Parameters
Administration Sequence
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The Administration sequence is the list of actions that execute when a user launches your setup program with the /a
command-line option. The built-in actions and dialogs for this sequence are defined in the tables below.
User Interface
The User Interface sequence contains all of the actions and dialogs needed to support a full user interface. This sequence is
skipped if an installation is run in silent mode.
Project • The User Interface actions described below are those for a Basic MSI project. For an InstallScript MSI project, your
InstallScript code performs the user interface of the installation.
For complete technical details about each standard action, see the Standard Actions Reference in the Windows Installer
Help Library.
SetupInterrupted Dialog This dialog is displayed at the end of an installation that was
ended by the end user.
CostInitialize Standard action This action is the first step in determining how much disk space
is required by the current configuration of the installation.
FileCost Standard action This action determines how much disk space will be required
by the current configuration of the installation. This action
checks to see if any files will be overwritten with newer
versions, and it calculates how overwriting those files will affect
disk space.
CostFinalize Standard action The CostFinalize action determines the total amount of disk
space required by the installation in its current configuration.
This action also verifies that all target directories are writable.
AdminWelcome Dialog This is the first dialog displayed during the Administration
sequence.
ExecuteAction Standard action This action runs the Administration Execute sequence.
Execute
The Execute sequence contains all the actions that do not rely upon the user interface in order to function properly. These
actions include file transfer, publishing components and features, and registering COM servers.
CostInitialize Standard action This action is the first step in determining how much disk space
is required by the current installation configuration.
FileCost Standard action This action determines how much disk space will be required
by the current installation configuration. This action checks to
see if any files will be overwritten with newer versions and
calculates how overwriting those files will affect disk space.
CostFinalize Standard action The CostFinalize action determines the total amount of disk
space required by the installation in its current configuration.
This action also verifies that all target directories are writable.
InstallValidate Standard action The InstallValidate action determines if there is enough disk
space available for the current setup configuration.
InstallInitialize Standard action The InstallInitialize action marks the beginning of the actions
that make changes to the end user’s system.
InstallAdminPackage Standard action This action copies the installation database to the
administrative installation point.
InstallFiles Standard action The InstallFiles action copies all of the files to the target
machine if the feature that those files belong to is slated for
installation. Only files that are associated with components
that are to be installed locally will be copied to the target
machine.
Table 4-22 • Execute Actions and Dialogs in the Administration Sequence (cont.)
InstallFinalize Standard action This action is the final step of the installation or uninstallation.
See Also
MsiExec.exe Command-Line Parameters
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The User Interface sequence contains all of the actions and dialogs required for the default user interface. These actions
and dialogs do not make changes to the target system. Generally, they gather information about the system environment
and the end user for use later in the installation.
By default, the Administration and Installation sequences each contain a User Interface sequence.
Project • InstallScript custom actions are not supported in the User Interface sequence for InstallScript MSI projects.
Execute Sequence
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The Execute sequence is executed after the User Interface sequence, unless your installation is run in silent mode. The
Execute sequence contains all the standard and custom actions that change the target system. For example, file transfer is
handled during the Execute sequence. Typically, this sequence is the part of the installation where changes are made to
the target machine.
Each sequence (Installation, Advertisement, and Administration) has different actions that occur in the Execute sequence.
This discrepancy is due to the fact that each of those sequences achieves different goals. For example, the Installation
sequence installs the product on the target machine. The Advertisement sequence installs the product’s advertised
shortcuts, file-type information, and COM-server data on the target machine, but it does not transfer the product’s files
until the end user selects the shortcut, opens a registered document, or invokes an advertised COM server. As can be
gathered from the name of the sequence, the product is advertised.
See Also
Advertising Features
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Sequences dictate when all of the actions that are associated with an installation will be executed. You can add, remove, or
reorder actions in any sequence. For example, if you want to display a readme file as part of the installation, you can add to
your installation a custom action that launches the readme file. This action must be inserted into a sequence.
Inserting actions into a sequence is governed by when actions in that sequence launch. Many actions rely on other actions
executing before they can function. For example, if you want to launch an executable file that will be installed as part of
your installation, you cannot execute the action that relies upon that executable file until the point in the sequence when
the files have been installed.
Note • InstallShield does not provide any validation on your sequences. If an action is placed in a sequence where it cannot
function properly, an error will not occur until the installation is run.
Inserting an Action
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, right-click the action or dialog that you want your action to follow and click Insert. The
Insert Action dialog box opens, providing a list of all the actions and dialogs that can be added to the sequence.
3. In the list at the top of the dialog box, select the type of action that you want to insert.
4. In the box that shows a list of actions, select the action that you want to insert.
5. Click OK.
InstallShield also includes drag-and-drop support that enables you to drag and drop custom actions from the Custom
Actions explorer to a sequence in the Sequences explorer.
Task To insert a custom action into a sequence using the drag-and-drop method:
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. Drag the custom action from the Custom Actions explorer to the appropriate location in a sequence under the
Sequences explorer. When you drop it, drop it onto the item that should be directly before it in the sequence.
Note • A custom action cannot be called twice in the same sequence, since the custom action name is the key in the
CustomAction table. Therefore, you cannot insert a custom action to a sequence that already contains that custom action.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
InstallShield enables you to copy a custom action in one sequence to another sequence through a drag-and-drop
operation.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, find the action that you want to copy.
3. Press and hold CTRL while dragging the custom action from one sequence to another sequence, and drop it onto the
action or dialog that should be directly before it.
Note • A custom action cannot be called twice in the same sequence, since the custom action name is the key in the
CustomAction table. Therefore, you cannot move or copy a custom action to a sequence that already contains that custom
action.
Dialogs and standard actions cannot be moved to a different type of sequence through a drag-and-drop operation.
See Also
Inserting Actions into Sequences
Reordering a Sequence
Reordering a Sequence
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
The actions and dialogs in the Sequences explorer in the Custom Actions and Sequences view are organized by
chronological order, according to when they are launched. Each action and item also has a number that identifies its
location in the sequence in relation to other items’ sequence numbers. The items are launched in order from the lowest
number to the highest number.
When you add a dialog (to Basic MSI, MSI Database, and Transform projects) or a custom action to your project, you can
specify when it should be launched by adding it to the appropriate place in a sequence.
Task To change the order in which actions and dialogs in a sequence execute:
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
• To sequence a new custom action, drag it from the Custom Actions explorer to the appropriate location in a
sequence under the Sequences explorer. When you drop it, drop it onto the item that should be directly before it
in the sequence.
• To move an action or a dialog to a different point in a sequence (or from one sequence to another), drag it from
the old location and drop it onto the item that should be directly before it in the sequence.
Note • A custom action cannot be called twice in the same sequence, since the custom action name is the key in the
CustomAction table. Therefore, you cannot move or copy a custom action to a sequence that already contains that custom
action.
Dialogs and standard actions cannot be moved to a different type of sequence through a drag-and-drop operation.
If you change a custom action after adding it to a sequence, you do not need to reassociate it with that sequence. The action
that you put in the sequence is a pointer to the real action, and it is dynamically updated whenever you make changes to the
action in the Custom Actions and Sequences view.
Tip • You can also move actions and dialogs in the Sequences explorer using any of the following methods:
See Also
Displaying Dialogs During Basic MSI Installations
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, expand the sequence that contains the action that you want to remove.
The action is removed from that sequence only, not from all sequences or from the project. You can permanently remove
an action from an installation project through the Custom Actions explorer in the Custom Actions and Sequences view.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Any custom action that is in your installation project and that makes direct changes to the target system should have a
rollback equivalent custom action. The rollback custom action can undo those changes in the event of rollback. For
example, if you have a custom action that deletes files from the target system, and you do not include a rollback custom
action to restore those deleted files, the computer could be left in an unstable state even after rollback has completed.
Rollback custom actions behave in a similar way to deferred custom actions. That is, they do not launch when first
encountered in a sequence. Instead, they are written to the rollback script, which launches only in the event of a rollback.
When inserting a rollback custom action into a sequence, note the following:
• A rollback can occur only during the Execute sequence and not at any point during the User Interface sequence.
Therefore, the rollback action must be placed after InstallInitialize and before InstallFinalize in the Execute sequence.
• The rollback custom action must be sequenced before the action it rolls back. In all other instances, the Windows
Installer service runs through sequences from top to bottom—the lower the sequence number, the sooner the action
launches. In the rollback script, however, the service runs in the opposite direction. Therefore, to launch your rollback
action when it is needed, sequence it before the action that it rolls back.
See Also
Using Custom Actions
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
Launching an executable file as your custom action can be a little trickier than calling a DLL file function in terms of where
that action can be inserted into the sequence. You should consider things such as when the .exe file will be launched during
the installation and which sequences you want the custom action to occur in.
Table 4-23 • Settings for Actions that Launch an .exe File in the .msi Package
Table 4-24 • Settings for Actions that Launch an Installed .exe File
Table 4-25 • Settings for Actions that Launch an .exe File that Is Already Installed
If you want to sequence a custom action that calls a function in a DLL file, there are three different ways to reference the
DLL file, depending on where the DLL file is located during the installation:
• The DLL file can be streamed into the .msi file, but it is not installed.
• The DLL file can be in the target system’s path (applies to a standard DLL file but not a Windows Installer DLL file).
• The DLL file can be installed with the rest of the installation files.
Other considerations include scheduling. The two main scheduling choices are Immediate Execution and Deferred
Execution. Immediate Execution means that Windows Installer will execute your custom action as it processes the .msi file.
Deferred Execution tells the installer to queue the action and perform it in sequence in the script.
Table 4-26 • Settings for Actions that Call a Function in a DLL File that is stored in the .msi Package
Table 4-27 • Settings for Actions that Call a Function in a DLL File that Is Found in the System’s Path
Table 4-28 • Settings for Actions that Call a Function in a DLL File that Is Already Installed
Project • The VBScript and JScript information applies to the following project types:
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
• Basic MSI
• InstallScript MSI
• Merge Module
Using script inside your custom action enables you to perform virtually any task. For example, you can launch external
applications or create registry entries.
Table 4-29 • Settings for Actions that Call a VBScript or JScript File that Is Installed with the Product
Table 4-30 • Settings for Actions that Call a VBScript or JScript File that Is Stored in the Binary Table
Table 4-31 •
InstallScript Code
InstallScript custom actions differ from JScript or VBScript custom actions because the source files for InstallScript actions
are always streamed into the .msi package. Therefore, the custom action can be inserted into a sequence anywhere after
the action that has 2 as its sequence number. This limitation occurs because the script engine launches during sequence
number 2. Therefore, if you call your script before the script engine launches, the system is not able to process it.
If your custom action contains feature functions or setup type dialog functions, you must insert the custom action after the
CostInitialize, FileCost, and CostFinalize actions.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
• MSI Database
• MSM Database
• Transform
When you are sequencing a custom action that sets a property or directory, the primary guideline that you need to follow is
to make sure that the custom action runs before that directory or property is needed. For example, if you want to launch an
executable file that is present on the target machine, the installation will probably need to search for it first.
Once the installation finds the executable file, its path can be added to the Directory table, and the executable file can be
launched. However, if you call the custom action after you launch the executable file, the executable file will not be found.
• Validation rule ICE12 requires any type-35 custom action (called Set a directory in the Custom Action Wizard) to be
sequenced after the standard CostFinalize action in the sequences.
• Similarly, ICE12 requires any type-51 custom action (called Set a property in the Custom Action Wizard) that sets the
value of a property found in the Directory table to be scheduled before the standard CostFinalize action.
• Any custom action that sets a property should be scheduled for immediate execution.
• Basic MSI
• InstallScript MSI
• MSI Database
• Transform
Important • Nested installations is a deprecated feature of the Windows Installer. Applications installed with nested
installations sometimes fail because they are difficult for end users to service correctly. Microsoft Corporation recommends
that you avoid using nested installations and nested-installation custom actions to install products that are intended to be
released to the public. To learn more, see Concurrent Installations on the MSDN Web site.
When you are sequencing a nested-installation custom action (called Launch another .msi package in the Custom Action
Wizard), you must place the action in the Execute sequence after the standard CostFinalize action.
Additionally, ensure that the custom action launches before any of the files contained within the installation are needed by
your main installation, if applicable. For example, if you later want to launch an executable file that is installed as part of
the second .msi file, ensure that the package is installed before you try to launch the executable file.
See Also
Nested Installations
The ALLUSERS property is indicated in the Customer Information dialog (for Basic MSI projects) and in either the
SdCustomerInformation or SdCustomerInformationEx dialog (for InstallScript MSI projects) by the end user during the
initial installation. The ISSetAllUsers custom action compares the value in the installed version to the value in the new
version. If the values differ, then ISSetAllUsers sets the ALLUSERS property of the new version to match that of the installed
version.
Note that for upgrades, the ALLUSERS property is configurable only through a custom action.
The new installation’s ALLUSERS property must match the installed version’s property in order for the FindRelatedProducts
action to succeed for the upgrade installation. In addition, if the previous version is installed for only one particular user
and the upgrade is installed for all users, the resulting installation is corrupted and might not uninstall properly.
ISSetAllUsers eliminates these problems by resetting the ALLUSERS property.
1. My Application 1.0 is installed with the ALLUSERS property set to 1 (the end user selected Install for All Users in the
end-user dialog during installation).
2. My Application 2.0 is authored as an upgrade to version 1.0 and has an entry in the Upgrade table to upgrade version
1.0.
3. The end user installs version 2.0 on the target system as an upgrade.
4. During the installation, ISSetAllUsers checks the value of the ALLUSERS property in the installed version and compares
it to the new version’s property by doing the following:
a. ISSetAllUsers iterates through each entry in the Upgrade table of version 2.0.
b. For every upgrade code in the Upgrade table, ISSetAllUsers searches for the related products on the target
system.
c. If the version and language constraints in the Upgrade table match one of the installed products (found in step
4b), ISSetAllUsers checks the ALLUSERS property of the installed version.
d. If the value of ALLUSERS for the installed version differs from that of the new version, ISSetAllUsers sets the new
installation’s ALLUSERS property to this value.
Note • If no matching product is installed on the target system, ISSetAllUsers does nothing.
See Also
Upgrades View
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Suite/Advanced UI
Support files are files that are available on the target system only during your product’s installation process. Support files
are copied to a temporary directory on the target system when installation begins. The support files are deleted when the
installation is complete. The support directory is a dynamic file location and might be different on every target system and
even on the same system for different installation instances.
In the Support Files view (in Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI projects) or the Support
Files/Billboards view (in InstallScript projects and InstallScript MSI projects), you can add and remove files that you want to
be available on the target system only during installation.
See Also
SUPPORTDIR
Placing Files in the .msi Database and Extracting Them During Run Time
Support Files/Billboards View (InstallScript and InstallScript MSI Projects)
Support Files View (Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI Projects)
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Suite/Advanced UI
1. In Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI projects: In the View List under Behavior and
Logic, click Support Files.
In InstallScript and InstallScript MSI projects: In the View List under Behavior and Logic, click Support Files/
Billboards.
2. Optionally, to create one or more subfolders for your files, in the Support Files explorer, right-click the Language
Independent node or one of the language-specific nodes in this view, and then click New Folder. InstallShield adds a
folder. Enter the name that you want to use for the folder.
3. In the Support Files explorer, click the item that should contain the support file that you are adding.
4. Right-click anywhere in the Files pane and then click Insert Files. The Open dialog box opens.
5. Browse to the file that you want to include. To select multiple files, hold down the CTRL key while clicking files.
6. Click OK.
Tip • You can also drag files from Windows Explorer and drop them into the Files pane.
• InstallScript
• InstallScript MSI
You can add a text file containing a license agreement in the Support Files/Billboards view.
1. In the View List under Behavior and Logic, click Support Files/Billboards.
2. Optionally, to create one or more subfolders for your license files, in the Support Files explorer, right-click the
Language Independent node or one of the language-specific nodes in this view, and then click New Folder.
InstallShield adds a folder. Enter the name that you want to use for the folder.
3. In the Support Files explorer, click the item that should contain the license file that you are adding.
4. Right-click anywhere in the Files pane and then click Insert Files. The Open dialog box opens.
5. Browse to the file that you want to include. To select multiple files, hold down the CTRL key while clicking files.
6. Call the file in the szLicenseFile parameter in one of the SdLicense* functions in your script.
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• Suite/Advanced UI
You can sort the files in the Files pane of the Support Files view (in Advanced UI, Basic MSI, and Suite/Advanced UI projects)
or the Support Files/Billboards view (in InstallScript projects and InstallScript MSI projects) by clicking the heading of the
column by which you want to sort the files. You can sort by any of the columns.
• Basic MSI
• InstallScript
• InstallScript MSI
The Disk1 node enables you to indicate files and folders that you want to go on Disk1 of your installation media. These files
and folders are not automatically installed to the target system when your installation is run. Rather, you can link to the
installation media from your application or from the installation.
For example, you might include a large redistributable file with your application. You may want end users to be able to
access the redistributable, but you do not want to include in the application installation. If this is the case, this file can be
placed in the Disk1 folder.
1. In Basic MSI projects: In the View List under Behavior and Logic, click Support Files.
In InstallScript and InstallScript MSI projects: In the View List under Behavior and Logic, click Support Files/
Billboards.
3. Right-click anywhere in the Files pane and then click Insert Files. The Open dialog box opens.
4. Browse to the file that you want to include. To select multiple files, hold down the CTRL key while clicking files.
5. Click OK.
See Also
Support Files/Billboards View (InstallScript and InstallScript MSI Projects)
Support Files View (Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI Projects)
• Basic MSI
• InstallScript
• InstallScript MSI
1. In Basic MSI projects: In the View List under Behavior and Logic, click Support Files.
In InstallScript and InstallScript MSI projects: In the View List under Behavior and Logic, click Support Files/
Billboards.
3. In the Files pane, right-click the file or folder and then click Delete.
The Last Disk node enables you to indicate files and folders that you want to go on the last disk of your installation media.
These files or folders are not automatically installed to the target system when your installation is run. Rather, you can link
to the installation media from your application or from the installation.
For example, you might include a large redistributable file with your application. You may want end users to be able to
access the redistributable, but you do not want to include in the application installation. If this is the case, this file can be
placed in the last disk folder.
1. In the View List under Behavior and Logic, click Support Files/Billboards.
3. Right-click anywhere in the Files pane and then click Insert Files. The Open dialog box opens.
4. Browse to the file that you want to include. To select multiple files, hold down the CTRL key while clicking files.
5. Click OK.
See Also
Support Files/Billboards View (InstallScript and InstallScript MSI Projects)
Task To remove a file or folder from the last disk image folder:
1. In the View List under Behavior and Logic, click Support Files/Billboards.
3. In the Files pane, right-click the file or folder and then click Delete.
The Other node enables you to indicate files or folders that you want to go on a disk of your installation media other than
the first or last disk. These files or folders are not automatically installed to the target system when your installation is run.
Rather, you can link to the installation media from your application or from the installation.
1. In the View List under Behavior and Logic, click Support Files/Billboards.
3. Right-click anywhere in the Files pane and then click Insert Files. The Open dialog box opens.
4. Browse to the file that you want to include. To select multiple files, hold down the CTRL key while clicking files.
5. Click OK.
Tip • To specify the disk, run the Release Wizard; in the General Options panel, click the Other Disk Files button.
See Also
Support Files/Billboards View (InstallScript and InstallScript MSI Projects)
1. In the View List under Behavior and Logic, click Support Files/Billboards.
3. In the Files pane, right-click the file or folder and then click Delete.
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Suite/Advanced UI
1. In Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI projects: In the View List under Behavior and
Logic, click Support Files.
In InstallScript and InstallScript MSI projects: In the View List under Behavior and Logic, click Support Files/
Billboards.
2. In the Support Files explorer, click the item that contains the support file that you want to delete.
3. In the Files pane, right-click the file or folder and then click Delete.
This section of the documentation covers different features of InstallShield that enable you to define different aspects of
the end-user interface. Some portions of the “Defining the End-User Interface” section discuss how to create and work with
dialogs for the end-user interface of your installation. Others discuss topics such as strings, which let you localize your
installation.
See Also
Run-Time Language Support in InstallShield
This section of the documentation covers some of the basic and more advanced aspects of working with end-user dialogs
for various project types in InstallShield.
Project • In Basic MSI installations, Windows Installer typically controls the run-time user interface. In InstallScript and
InstallScript MSI installations, the InstallScript engine typically controls the run-time user interface. Therefore, some portions
of this section of the documentation apply to Basic MSI installations, some apply to InstallScript and InstallScript MSI
installations, and some apply to all three project types.
Dialogs provide the user interface for your installation. They request information from the end user and provide feedback
about the progress of the installation process.
The way in which you work with the dialogs in your project depends on the type of installation that you are creating.
Adding dialogs to an InstallScript or InstallScript MSI project requires different steps than adding dialogs to a Basic MSI
project.
Common Operations
Some of the dialog operations are common to Basic MSI, InstallScript, and InstallScript MSI projects.
See Also
Working with Dialogs in InstallScript and InstallScript MSI Projects
Working with Dialogs in Basic MSI Projects
InstallShield provides a Dialog Wizard that enables you to add a new dialog to your installation and configure it by stepping
through the wizard panels.
• Basic MSI
• InstallScript
• InstallScript MSI
Many server applications require the specification of a user account during installation. Having a user account available is
often necessary because it enables a server application to access resources that are restricted to other users. InstallShield
offers support for setting an existing Windows user account or creating a new one during installation by enabling you to
add the appropriate run-time dialogs to your installation.
Basic MSI For Basic MSI projects, the specified user name, password, and group information
entered in the LogonInformation dialogs are stored in the following properties:
• IS_NET_API_LOGON_USERNAME
• IS_NET_API_LOGON_GROUP
• IS_NET_API_LOGON_PASSWORD
InstallScript For InstallScript projects, the specified user name, password, and group
information entered by the end user in the LogonInformation dialogs are stored in
the following global variables:
• IFX_NETAPI_USER_ACCOUNT
• IFX_NETAPI_PASSWORD
• IFX_NETAPI_GROUP
InstallScript MSI For InstallScript MSI projects, the specified user account, group, and password
are stored in the following global variables and properties:
• IFX_NETAPI_USER_ACCOUNT
• IFX_NETAPI_GROUP
• IFX_NETAPI_PASSWORD
• IS_NET_API_LOGON_USERNAME
• IS_NET_API_LOGON_GROUP
• IS_NET_API_LOGON_PASSWORD
2. In the Dialogs explorer, right-click All Dialogs, and click New Dialog. The New Dialog Wizard opens.
3. Complete each panel of the wizard. In the Dialog Template panel, select Logon Information Panel and Associated
Child Dialogs.
When you are done completing each panel of the New Dialog Wizard, build and run your installation project. When the
dialog sequence in which the LoginInformationDialog dialog is executed, the appropriate dialogs are displayed.
Task To add support for the LogonInformation dialogs to either an InstallScript or InstallScript MSI project:
1. Navigate to the location in your InstallScript code where you want to insert the LogonInformation dialog set. In most
situations, you will add it within OnFirstUIBefore. For example:
Dlg_SdLogon:
nResult = SdLogonUserInformation(szTitle, szMsg, szAccount, szPassword);
if (nResult = BACK) goto Dlg_SdWelcome;
2. In InstallScript MSI projects, add the following function so that the Windows Installer properties are set to the same
value as the InstallScript global variables. You can add it after calling SdLogonUserInformation.
OnLogonUserSetMsiProperties();
3. On the Build menu, click Settings. The Settings dialog box opens.
5. In the Libraries (.obl) box, enter the name of your new library file (*.obl):
NetApiRT.obl
Note • You should add the new library file name before the isrt.obl file name.
Once you have added the InstallScript code, build and run your installation. When the script is executed, the appropriate
dialogs are displayed.
See Also
Creating Predetermined User Accounts at Run Time
Settings Dialog Box
SdLogonUserInformation
SdLogonUserListGroups
SdLogonUserListServers
SdLogonUserListUsers
SdLogonUserBrowse
SdLogonUserCreateUser
If you want to reuse an end-user dialog in other projects, you can export the dialog as an .isd file and then import it into
other projects as needed. The .isd file contains the behavior and layout information for the dialog.
2. In the Dialogs explorer, right-click the dialog and then click Export to Dialog File. The Save As dialog box opens.
3. Browse to the folder to which you want to save the .isd file. You can rename the file if required.
4. Click OK.
You can now use the .isd file to import the dialog into another installation project.
See Also
Reusing Project Elements
Using a Repository to Share Project Elements
InstallShield enables you to import a dialog into your installation project. The file for the dialog (.isd file) can be stored in a
repository, or it can be stored in some other location.
2. In the Dialogs explorer, right-click the dialog and then click Import Dialog. The Import Dialog dialog box opens.
• In the Repository Items box, click the dialog that you want to add to your project.
• If the file for the dialog box (.isd file) that you want to import is not stored in the repository, click the Browse
button to select it.
4. Click OK.
Note • When you import a dialog, make sure that any string identifiers, properties, and actions referenced by the dialog are
present in the new installation project.
Resolving Conflicts
When you import a dialog, InstallShield checks to make sure that the name of the dialog and its controls are unique—as
required by Windows Installer. You cannot import a dialog with the same name as an existing dialog because InstallShield
assumes that you are trying to import an identical dialog.
If you try to import an .isd file that uses the names of controls or string identifiers that already exist in your installation
project, InstallShield asks how you want to resolve those conflicts. You can either overwrite the existing values or skip the
imported values in order to leave the existing ones.
See Also
Using a Repository to Share Project Elements
Selecting the Installation Languages
If you have an existing dialog (.isd) file that you would like to reuse in other projects or share with other users, you can
publish it to a repository.
2. In the Dialogs explorer, right-click the dialog and then click Publish Wizard. The Publish Wizard opens.
After you have imported a dialog from a repository into a project, there is no link between the current dialog and the
existing repository dialog. If you make a change to the dialog and then republish it to the repository, it does not affect the
dialog in the project to which it was imported. However, you can reimport the dialog from the repository into your project.
See Also
Using a Repository to Share Project Elements
If you would like to edit your dialogs’ resources in a resource editor such as Visual Studio, you can export the dialogs to an
.rc file.
2. In the Dialogs explorer, right-click All Dialogs and click Export Dialogs to Resource Script.
InstallShield copies all of the dialogs’ resources for the default language to a file named <project name>.rc in the project
location.
Every attempt is made to preserve each dialog’s layout as much as possible. However, since some information in the Dialog
Editor has no counterpart in a resource editor, InstallShield exports the resources as they appear in the Dialog Editor with
the following exceptions:
Exception Description
String entries All strings entries are resolved to the value of the default language.
Paths The paths, including any path variables, to any resources, such as text files or
bitmaps, are preserved to make it easier to import the dialog at a later point.
Selection trees A Windows Installer selection tree becomes a standard tree control in the .rc file.
Text style While the Dialog Editor maintains separate properties for font information (base
text style and text style) and maximum character length, these properties are
grouped together as they are in the Windows Installer tables.
Table 4-2 • Resources that Are Not Exported to an .rc File (cont.)
Exception Description
Behavior Unlike .isd files, which contain complete copies of the dialog’s layout and
behavior, .rc files store only the resources.
Before importing the dialogs back into your project, you must compile the .rc file into a .res file and then build it into a .dll
file.
Task Assuming again that you use Visual Studio, follow the steps below to build MyProject.rc into MyProject.dll:
1. Use the Resource Compiler (Rc.exe) to compile MyProject.rc into MyProject with the following command-line
statement:
rc MyProject.rc
2. Run the Incremental Linker (Link.exe) to build a .dll file with the following command:
See Also
Reusing Project Elements
2. In the Dialogs explorer, right-click All Dialogs and click Import Dialogs from Resource Dlls. The Open dialog box
opens.
3. Browse to the .dll file that contains the dialog resources that you want to import.
4. Click Open.
InstallShield adds each dialog to your project. Naming conflicts are resolved by adding a number to the imported dialog to
make it unique.
If an imported control displays text that is already found as a string entry, InstallShield uses the existing string entry for the
control’s Text property.
Note • When you are importing a dialog, ensure that any properties referenced by the dialog are present in the new
installation project.
Adding a dialog to a project does not mean that the dialog will be displayed during the installation run time. For
information on inserting the dialog into one or more of the installation’s sequences, see Displaying Dialogs During Basic
MSI Installations.
Even though dialogs can be exported to an .rc file, you must build the resources into a .dll file before you can import them
into InstallShield. For more information, see Exporting All Dialogs to an .rc File.
InstallShield enables you to insert a dialog from the current project into another existing project by exporting it.
2. In the Dialogs explorer, right-click the dialog and click Export to Project File. The Export Into dialog box opens.
3. Browse to the location of an existing .ism file. It can be either an installation project or a merge module project, but
the file cannot be open in another instance of InstallShield.
4. Click Save.
A copy of this dialog is added to the specified .ism file, along with every control and all of the dialog’s behavior. Any string
entries, properties, and path variables used in the dialog are also copied to your new project.
If the target .ism file already has a dialog of that name with different properties, the Resolve Conflict dialog box opens to
offer you options for resolving the conflicting dialogs.
You can also publish dialogs to a repository and reuse them in other installation projects. For more information, see Using
a Repository to Share Project Elements.
See Also
Reusing Project Elements
Note • Right-clicking a dialog in the Custom Actions and Sequences view and clicking Remove does not delete the dialog from
your project. It only removes it from that sequence.
4. Delete the script that adds the dialog to your installation’s end-user interface.
Consider the following tips when you create and configure custom dialogs in different project types.
In the Direct Editor, you can specify a value for the ISResourceId field for the new dialog. This ISResourceId value is used
within the script to identify this dialog.
Once you have added the dialog to your project, you need to call functions such as EzDefineDialog and WaitOnDialog to
load this dialog in memory and display it at run time. The corresponding ISResourceId value in the Dialog table is used as
the fourth argument of EzDefineDialog to reference the custom dialog. Also, in the second argument of EzDefineDialog, it
is advantageous to specify ISUSER as opposed to a null string. The EzDefineDialog function should look like the following:
In the above example, 12005 is the ISResourceId of this custom dialog, as specified in the Dialog table.
Custom dialog functions can then be called to manipulate the custom dialog to your needs. These functions are
documented in the InstallScript Language Reference.
See Also
Creating New Custom Dialogs in InstallScript and InstallScript MSI Projects
Creating New Dialogs in Basic MSI Projects
The Dialog Editor remembers up to 50 actions for each dialog and allows you to restore each change starting from the most
recent one. Additionally, you can undo changes even after saving the project. However, if you close a project and reopen it,
the undo history is purged.
Undoing Changes
• Press CTRL+Z.
Task To place an undone change back into effect, do one of the following:
• Press CTRL+Y.
The Undo and Redo buttons and menu commands are enabled while you are using the Dialog Editor. When you undo an
action, you move back through the history of actions you performed on that dialog. When you redo, you move forward.
For example, if you resized a button and then changed its Tab Index property, clicking Undo would restore the previous
value of the Tab Index property. Clicking Undo a second time returns the button to its original size. Clicking Redo twice puts
the changes back into effect on the button’s size and then its tab index.
Note • You cannot undo changes made to a string entry through the Dialog Editor.
InstallShield enables you to call specific functions in your script to display end-user dialogs. The Dialogs view contains a list
of standard dialogs as well as any custom dialogs that you have added to your project.
This section of the documentation discusses how to create and perform basic functions with dialogs in InstallScript and
InstallScript MSI projects.
• InstallScript
• InstallScript MSI
Most of the user interface of an InstallScript or InstallScript MSI installation is defined in event handlers such as
OnFirstUIBefore and OnFirstUIAfter. The following sample InstallScript code in OnFirstUIBefore is for the SdWelcome
and SdLicense2 dialogs:
Dlg_SdWelcome:
szTitle = "";
szMsg = "";
nResult = SdWelcome( szTitle, szMsg );
if (nResult = BACK) goto Dlg_Start;
Dlg_SdLicense2:
szTitle = "";
szOpt1 = "";
szOpt2 = "";
szLicenseFile = SUPPORTDIR ^ "License.rtf";
nResult = SdLicense2Ex( szTitle, szOpt1, szOpt2, szLicenseFile, bLicenseAccepted, TRUE );
if (nResult = BACK) then
goto Dlg_SdWelcome;
else
bLicenseAccepted = TRUE;
endif;
Every dialog function returns a constant indicating which button the end user clicked to exit the dialog. To handle the end
user clicking the Back button on a dialog, directly after the dialog is an if statement that compares the dialog’s return value
to the constant BACK, using a goto statement to jump to a label just before the previous dialog. In the aforementioned
code example, if the end user clicks the Back button on the SdLicense2 dialog, the goto statement jumps to the
Dlg_SdWelcome label, and the SdWelcome dialog is displayed to the end user. Therefore, if you insert a dialog function
between two dialogs such as SdWelcome and SdLicense2, you need to adjust the if statements, labels, and goto
statements as appropriate.
Task To display a dialog to the end user as part of the installation’s user interface:
3. Modify the dialog function’s parameters according to how you want the dialog to behave.
To learn about the available parameters, refer to the dialog function documentation:
• Dialog Functions
4. Use the script to direct the flow of the dialogs—for example, by using if and goto statements.
See Also
OnFirstUIBefore
OnFirstUIAfter
OnMaintUIBefore
OnMaintUIAfter
Event Handlers
• InstallScript
• InstallScript MSI
Most dialog functions accept a string argument called szTitle that defines the text appearing in the title area of the dialog.
For example, the call to SdRegisterUser appears as follows:
By default, the parameter szTitle is defined as a null string (""), which indicates that the dialog should use the default title
text. For SdRegisterUser, the default title appears as shown in the following screen shot.
To modify the title, you can enter specific strings to display for the szTitle parameter. The title is divided into two
sections—the bold text at the top of the title area, and the regular text under the main title.
To specify the two sections in the value of szTitle, place a newline character \n between the two sections.
After recompiling the script and running the installation, the title is displayed as shown in the following sample screen
shot.
To change other text displayed on a dialog, there are usually one or more parameters (such as szMsg) that contain the text
to be displayed. As with dialog box titles, a null string in a message parameter indicates that the dialog should use the
default message text provided by InstallShield.
If your installation contains more than one UI language, you can use string identifiers instead of hard-coded strings in your
InstallScript. For more information, see Using String Entries in InstallShield.
Background About the Default Images on Dialogs in InstallScript and InstallScript MSI Projects
InstallShield 2020
• InstallScript
• InstallScript MSI
Two types of images—the default banner images on interior dialogs, as well as the computer image on the left side of the
exterior skinned dialogs such as the Welcome dialog—are used for static dialog user interface controls that have a control
identifier of 1200. The default images are .png images, which allow for transparency. The Text field for these controls uses
the following syntax by default to identify the image:
@@ResourceID;ScaleFactor
ResourceID indicates the resource identifier number that should be used to look up either a .png image (stored as resource
type PNG) or a bitmap image (stored as resource type RT_BITMAP). ScaleFactor indicates the DPI scale percentage for
which the image is intended.
For example, the scale factor can be 100% (96 DPI), 125% (120 DPI), 150% (144 DPI), or 200% (192 DPI). If the scale factor
that is specified for an image is 200, the image will be shrunk down for display on target systems that are running less than
200% DPI scaling. On a 200% target system, it will be displayed at 1:1. If the scale factor that is specified for the image is100,
the image will be scaled up for display on target systems that are running 200% DPI scaling.
The previous format for identifying bitmap images (.bmp) still works, but it does not have support for scaling, or for .png
images:
@BitmapResourceID;TransparentFlag;3-DFlag;<unused>;TransparentColorKey
BitmapResourceID indicates the resource identifier number for the bitmap image. TransparentFlag is 1 (true) or 0 (false),
indicating whether the color that is specified in the TransparentColorKey field will be transparent when the bitmap is
displayed. TransparentColorKey specifies an RGB value that is a transparent color for the bitmap.
See Also
DialogSetInfo
SdOptionsButtons
• InstallScript
• InstallScript MSI
To create a custom dialog, you need to perform the following general steps:
1. Use the New Dialog Wizard to add a new custom dialog to your project. For more information, see Using the New
Dialog Wizard to Add a New Custom Dialog to an InstallScript or InstallScript MSI Project.
2. Add controls to the dialog. For more information, see Adding a Control to a Dialog in an InstallScript or InstallScript
MSI Project.
3. Create a script function that loads the dialog into memory, displays it on the screen, handles the end user’s interaction
with the dialog’s controls, and closes the dialog when the user is finished with it. For more information, see Using
InstallScript to Implement Custom Dialogs.
See Also
Using InstallScript to Process Dialog Controls
Using the New Dialog Wizard to Add a New Custom Dialog to an InstallScript or InstallScript
MSI Project
InstallShield 2020
• InstallScript
• InstallScript MSI
2. In the Dialogs explorer, right-click All Dialogs, and click New Dialog. The New Dialog Wizard opens.
3. Follow the wizard panels to create the new dialog. In the Dialog Template panel, select the NewScriptBasedDialog
template or the NewSkinnableDialog template.
The NewScriptBasedDialog and NewSkinnableDialog templates include a hidden control that has a Control Identifier
value of 2. To enable end users to cancel the installation by clicking the close button in the upper-right corner of the
InstallScript dialog, the dialog must have a button control whose Control Identifier property is set to this value. The
Blank Dialog template does not include this control. For more information, see Using InstallScript to Implement
Custom Dialogs.
Once you have added a new custom dialog to your project, you can add dialog controls.
See Also
Creating New Custom Dialogs in InstallScript and InstallScript MSI Projects
Editing Dialog Behavior in an InstallScript or InstallScript MSI Project
Using InstallScript to Implement Custom Dialogs
• InstallScript
• InstallScript MSI
You can use the Dialog Editor to add, remove, and rearrange controls on a selected dialog. You can also use the Dialog
Editor to modify the properties of the dialog or its controls. The InstallShield Dialog Editor functions much in the same way
as other resource editors.
When you use the Dialog Editor to change the layout or appearance of a dialog, you are changing only the current project’s
copy of the dialog; the changes do not affect any other projects.
• In the Dialogs view, click a dialog and then in the dialog preview pane on the right, click the link for the language of the
dialog that you want to edit.
Note • When an end user runs your installation on a Windows platform that uses a desktop display theme, the theme is used
to display your installation’s end-user dialogs.
See Also
Adding a Control to a Dialog in an InstallScript or InstallScript MSI Project
Setting a Control’s Properties
Displaying Controls on Top of a Bitmap
Reverting to the Default Dialog
InstallShield 2020
• InstallScript
• InstallScript MSI
You can use the Controls toolbar in InstallShield to add controls to a dialog.
2. In the Dialogs explorer, expand the All Dialogs folder, and then expand the dialog item that should have the new
dialog control.
3. Click a language under the dialog item that you expanded. The Dialog Editor in the center pane shows the dialog in the
selected language.
4. In the Controls toolbar, click the control that you want to add.
5. Draw a rectangle on the dialog in the location where you want the control to be displayed.
After adding the control in the Dialog Editor, you need to use InstallScript to process the end user’s interaction with the
control. To learn more, see Using InstallScript to Process Dialog Controls.
Note • For projects created in Microsoft Visual Studio, you can use the Toolbox to add dialog controls.
See Also
Showing or Hiding Toolbars
Configuring the Controls’ Settings
Creating InstallShield Projects in Microsoft Visual Studio
Using the Toolbox to Add Dialog Controls
InstallShield 2020
• InstallScript
• InstallScript MSI
The dialog itself and every control on it has a property sheet in the Dialog Editor. These properties determine such things as
a control’s size and position, its default text (as a string identifier), or whether the dialog is modal.
To edit one of the property sheets, select the control on the dialog, or select a control’s or dialog’s name from the box
above the property sheet. The properties vary depending on the type of control:
• Dialog
• Check Box
• Push Button
• Edit Field
• Combo Box
• Text Area
• List Box
• Radio Button
• Bitmap
• Group Box
• Line
• Selection Tree
• Progress Bar
• List View
• Icon
See Also
Using an HTML Control on a Dialog
InstallShield 2020
• InstallScript
• InstallScript MSI
When you are setting the properties of a bitmap and other dialog controls, you can indicate that the controls should be
placed on top of the bitmap.
• The value for the Tab Index property of the bitmap must be lower than the value for the Tab Index property of any
controls that are to be placed on top of the bitmap. The easiest way to configure this is to set the bitmap control’s Tab
Index property to 0.
• All controls—including the bitmap—must have their Tab Stop properties set to True.
See Also
Setting a Control’s Properties
Editing Dialog Behavior in an InstallScript or InstallScript MSI Project
Showing or Hiding Toolbars
• InstallScript
• InstallScript MSI
The next step in creating a custom dialog is to write an InstallScript function that processes the end user’s interaction with
the dialog controls.
1. Begin by creating a new InstallScript source file to contain the custom dialog code. Name the file CustomDialog.rul.
Tip • To be able to use the dialog script in other projects, copy the .rul file to another location. In your other projects,
open the InstallScript view, right-click the Files item in the InstallScript explorer, and click Insert Script Files.
2. Inside CustomDialog.rul, place the prototype and implementation for your custom dialog function. Add the
following code to CustomDialog.rul.
3. When you compile your script, indicate that the main script Setup.rul should include the code for your CustomDialog
function by inserting the following line near the top of Setup.rul:
#include "CustomDialog.rul"
4. In the CustomDialog.rul script, define the constants that store the numeric IDs of the controls that you added to the
dialog. If you copied the Back, Next, and Cancel buttons from a standard dialog, you can add the following lines near
the top of CustomDialog.rul:
// control identifiers
#define BUTTON_NEXT 1
#define BUTTON_BACK 12
In general, the numeric ID of a control on a dialog is the number listed in the control’s Control Identifier property,
displayed in the property list when you select the control in the Dialog Editor.
Important • To enable end users to cancel the installation by clicking the close button in the upper-right corner of the
InstallScript dialog, the dialog must have a button control with a value of 2 for the Control Identifier property. You can
place this button anywhere on the dialog, and if necessary, you can make this button invisible. This is necessary because
the InstallScript engine passes the WM_CLOSE message to the script only if it comes from a valid control in the dialog. If
the dialog does not have a button with this identifier, the installation does not pass through the message that is
generated when the dialog’s close button is clicked.
You need to define additional constants for every other control (for example, check box, edit field, or list box) with
which the end user can interact.
5. Your CustomDialog function loads the custom dialog into memory using the EzDefineDialog function:
EzDefineDialog(
"CustomDialog", // nickname for dialog
ISUSER, // DLL containing the dialog’s resources
"CustomDialog", // name of dialog in Dialogs view
0); // numeric resource ID for dialog; not used here
Tip • The resource ID of a dialog is the dialog’s name, as it appears in the Dialog Editor. If you need to specify a numeric
resource ID, you can add a numeric ID to the ISResourceId column in the Dialog table for the custom dialog. You can
access the Dialog table in the Direct Editor.
6. Create a message loop in your script for the custom dialog. The message loop repeatedly calls the function
WaitOnDialog, which returns the numeric control ID for the control with which user interacts with. A typical message
loop appears as follows.
case CONTROL1:
// do something when user clicks CONTROL1
case CONTROL2:
// do something when user clicks CONTROL2
endswitch;
endwhile;
For example, CustomDialog currently contains Next, Back, and Cancel buttons. Its message loop might appear as
follows:
while (!bDone)
nControl = WaitOnDialog("CustomDialog");
switch (nControl)
case DLG_INIT:
// Initialize the back, next, and cancel button enable/disable
// states for this dialog and replace %P, %VS, %VI with
case BUTTON_BACK:
// user clicked Back
nReturn = BUTTON_BACK;
bDone = TRUE;
case BUTTON_NEXT:
// user clicked Next
nReturn = BUTTON_NEXT;
bDone = TRUE;
default:
// check standard control handling
if (SdIsStdButton(nControl) && SdDoStdButton(nControl)) then
bDone = TRUE;
endif;
endswitch;
endwhile;
7. When the end user exits the dialog by clicking Back or Next, you should remove the dialog from the screen and from
memory using EndDialog and ReleaseDialog:
EndDialog("CustomDialog");
ReleaseDialog("CustomDialog");
To use the dialog in the main script, add a call to the CustomDialog function in, for example, the OnFirstUIBefore
event handler of Setup.rul.
Dlg_SdWelcome:
szTitle = "";
szMsg = "";
nResult = SdWelcome(szTitle, szMsg);
Dlg_CustomDlg:
nResult = CustomDialog( );
if (nResult = BUTTON_BACK) goto Dlg_SdWelcome;
// etc.
If the end user clicks Back or Next, the script displays the previous or following dialog. If the user clicks Cancel, the
standard confirmation dialog (handled by the OnCanceling event handler) is displayed.
Note • For information on implementing dialog control functionality, see Using InstallScript to Process Dialog Controls.
Special Messages
In addition to returning control identifiers, the WaitOnDialog function returns some special messages.
• Immediately before the dialog is displayed on the screen, WaitOnDialog returns the message constant DLG_INIT. In
the DLG_INIT case statement, you can set the default states of check boxes and radio buttons, populate and set the
current selection in a list box or combo box control, or set the initial text of an edit field.
• InstallScript
• InstallScript MSI
In InstallScript and InstallScript MSI installation projects, you use InstallScript to process the controls that you add to your
custom dialogs.
Note • InstallShield has a standard dialog called AskOptions. This dialog displays up to nine check boxes or radio buttons,
and therefore it is not necessary to create a custom dialog to display only check boxes to the end user.
As with push buttons, for each check box control that you add to a dialog, you generally add a #define statement to your
script that assigns a symbolic name to the numeric control ID. For example, if you add a check box control to a custom
dialog, the control’s numeric ID will appear in the Control Identifier property of the control. If the numeric ID is 1302, you
would add the following line to your script.
For most types of controls, InstallScript defines CtrlGet and CtrlSet functions with which you can get or set the current
state or data for a control. For example, you can get and set the current state of a check box control using CtrlGetState and
CtrlSetState. In the DLG_INIT case of your dialog’s message loop, you can call CtrlSetState to set the initial selection state
of the check box. The following code causes the check box to appear initially selected.
case DLG_INIT:
// Initialize the back, next, and cancel button enable/disable states for this dialog
// and replace %P, %VS, %VI with IFX_PRODUCT_DISPLAY_NAME, IFX_PRODUCT_DISPLAY_VERSION,
// and IFX_INSTALLED_DISPLAY_VERSION, respectively, on control IDs 700-724 and 202.
hwndDlg = CmdGetHwndDlg("CustomDialog");
SdGeneralInit("CustomDialog", hwndDlg, 0, "");
CtrlSetState("CustomDialog", MYCHECKBOX1, BUTTON_CHECKED);
Similarly, you can add the following code outside the dialog’s message loop to detect the final selection state of the check
box.
else
// check box unselected
endif;
You can read the text stored in an Edit control with CtrlGetText. For example, to read the text from an Edit control with
resource ID 10000 into a string variable called svEdit, you can use the following code:
Similarly, you can set the initial text stored in an Edit control (in the DLG_INIT block of the message-loop’s switch
statement) with CtrlSetText.
Tip • You can use the Password attribute of an edit control to hide the characters that the end user types into the edit field.
You can use the Number attribute to allow the end user to enter only numbers in the edit field.
To set the initial selection in a list box or combo box control, you can call CtrlSetCurSel in the dialog’s DLG_INIT handler;
and to retrieve the user’s current selection call CtrlGetCurSel. For example, the following code populates a list variable
with the drive letters of every available drive (using GetValidDrivesList), associates the list with a combo-box control, and
then reads the end user’s selection from the combo box before exiting the dialog.
bDone = FALSE;
while (!bDone)
nControl = WaitOnDialog("CustomDialog");
switch (nControl)
case DLG_INIT:
// Initialize the back, next, and cancel button enable/disable states
// for this dialog and replace %P, %VS, %VI with IFX_PRODUCT_DISPLAY_NAME,
// IFX_PRODUCT_DISPLAY_VERSION, and IFX_INSTALLED_DISPLAY_VERSION,
// respectively, on control IDs 700-724 and 202.
hwndDlg = CmdGetHwndDlg("CustomDialog");
SdGeneralInit("CustomDialog", hwndDlg, 0, "");
CtrlSetState("CustomDialog", MYCHECKBOX1, BUTTON_CHECKED);
// associate the list with the combo box
CtrlSetList("CustomDialog", MYCOMBOBOX1, listDrives);
// get the first drive letter from the list...
ListGetFirstString(listDrives, svDrive);
// ...and make it the current selection
CtrlSetCurSel("CustomDialog", MYCOMBOBOX1, svDrive);
// ...cases for other controls...
endswitch;
endwhile;
EndDialog("CustomDialog");
ReleaseDialog("CustomDialog");
return nReturn;
end;
List box and combo box controls have a Sorted property, which you can set to Yes to sort the contents of the list controls by
the items’ display names.
• InstallScript
• InstallScript MSI
To change the behavior of a dialog, you can modify the dialog function’s parameters according to how you want the dialog
to behave. To learn about the available parameters, refer to the dialog function documentation:
• Dialog Functions
See Also
OnFirstUIBefore
OnFirstUIAfter
OnMaintUIBefore
OnMaintUIAfter
Event Handlers
Adding a Field That Contains a Product Name, Product Version, or Installed Version in Sd
Dialog Static Text Fields
InstallShield 2020
• InstallScript
• InstallScript MSI
InstallShield enables you to place your product name, product version, or installed version globally in Sd dialog static text
fields containing the placeholder %P, %VS, or %VI (sometimes appearing as an extra space). At run time, the values of the
system variables IFX_PRODUCT_DISPLAY_NAME, IFX_PRODUCT_DISPLAY_VERSION, and
IFX_INSTALLED_DISPLAY_VERSION are displayed in place of %P, %VS, and %VI in the static text fields.
If you are adding a static text field containing a placeholder, give the static text field a unique (to that dialog) ID in the range
of 701 through 799. IDs in the 701 through 799 range instruct InstallShield to scan the static text field for the existence of
the placeholders. If a placeholder is found, InstallShield replaces it with the value of the corresponding system variable.
• InstallScript
• InstallScript MSI
InstallShield includes support for HTML controls on dialogs in InstallScript and InstallScript MSI projects. HTML controls
enable you to use HTML markup for dialog controls. You can include on dialogs links to Web pages, installed HTML files,
and HTML support files. If an end user clicks the hyperlink on the run-time dialog, you can have the HTML page open in an
Internet browser, or you can trigger other behavior that you have defined through your InstallScript code. The HTML
control lets you use any valid HTML markup, including styles to control their appearance.
The HTML control also lets you display the HTML content directly on a dialog if the content is an installed HTML file or HTML
support file.
To create an HTML control, you need to start with a static text control. Once you have placed the static text control on a
dialog, you can convert it to be an HTML control.
Task To convert any static text control on a dialog to be an HTML control, do one of the following:
• In the Dialogs view, set the Text property of the control as follows:
• Use InstallScript to set the text of a control to be [html], followed by the HTML markup.
At run time, the InstallScript engine converts the control to an HTML control.
Example
The following example demonstrates how to convert a static text control to an HTML control. The sample HTML code
enables you to set the colors and fonts of the control so that they match those of the dialog.
Task To convert a static text control to an HTML control by using the control’s Text property:
2. In the Dialogs explorer, right-click the dialog that you want to contain the HTML control, and then click Edit.
InstallShield displays the dialog in the Dialog Editor, using the project’s default language.
3. Click the static text control that you want to convert to an HTML control. InstallShield displays its properties in the
right pane.
4. In the Text property, click the ellipsis button (...). InstallShield displays a list of all of the current strings in the project.
At run time, the installation uses the default InstallScript dialog font (8 point MS Sans Serif) and sets the background color
to the Windows dialog color, which is usually gray. If the content is on a dialog area that is white, you can omit the
background-color:ButtonFace style part so that the background of the HTML control becomes white.
Tip • As an alternative to converting the static control through the Dialogs view, you could edit the dialog’s script function in
the InstallScript view. For example, add the following code to the DLG_INIT case in the dialog message loop:
To handle click events for links in HTML controls, the WaitOnDialog function returns the control ID of the HTML control
(which is also the control ID of the original static text control). A custom dialog script function can contain a case statement
that handles the HTML control ID, and then calls the CtrlGetUrlForLinkClicked function to obtain the URL for the link that
was clicked. With this link, the script can take any action (such as launching an Internet browser to navigate to the link).
The following behavior occurs when an end user clicks a link for an HTML control that uses the anchor tag:
• If the anchor tag does not include the target attribute, or if the target value does not result in a new window, the
control ID is returned to the dialog script. This allows for the script to handle link clicks itself.
• If the anchor tag does include the target attribute and its value is _blank or some other equivalent value that results in
a new window, no message is sent to the script, and the URL is automatically launched.
When an end user clicks such a link, a new email message is automatically opened in the target system’s email application.
Note that with the mailto link, no message is sent to the script.
Character Count Limits for the Text Property of Static Text Controls
The Text property of static text controls has a maximum limit of 256 characters. Therefore, if you convert a static text
control to an HTML control by adding [html] to the beginning of the text content for a control, the maximum number of
characters that you can enter is 256; this includes the hyperlinked text as well as all characters for any HTML markup that
you specify. If you need to enter more than 256 characters for the content, use the CtrlSetText function to create the
control.
See Also
Adding Support Files
CtrlSetText
CtrlGetUrlForLinkClicked
• InstallScript
• InstallScript MSI
If you have edited a dialog and you later decide that you want to undo all of your changes, you can revert back to the
original default dialog.
• InstallScript
• InstallScript MSI
To modify dialogs in InstallScript or InstallScript MSI projects, you must have a resource compiler and resource linker
installed on your system. InstallShield includes both of these types of tools.
1. On the Tools menu, click Options. The Options dialog box opens.
The Resource tab lists the locations of the compiler and linker.
Task To replace the resource compiler or resource linker with one that is already on your system:
1. On the Tools menu, click Options. The Options dialog box opens.
3. Click the Browse button next to the Resource compiler location box or the Resource linker location box to navigate
to the program file.
Dialog Sampler
InstallShield 2020
• InstallScript
• InstallScript MSI
The Dialog Sampler is an InstallShield wizard that displays samples of all built-in dialogs as well as dialogs called by script
dialog (sd) functions in InstallScript and InstallScript MSI projects. You can launch two different varieties of the Dialog
Sampler.
On the Tools menu, point to InstallScript, and then click either Standard Dialog Sampler or Skinned Dialog Sampler.
You can also launch these samplers using the shortcut in the InstallShield program folder on the Programs menu.
Dialog Skins
InstallShield 2020
• InstallScript
• InstallScript MSI
Overview
Dialog skins enable you to display end-user dialogs with a different look and color scheme. Skinned dialogs are slightly
larger than standard dialogs, and the controls are located differently. For skinned dialogs to display properly, the desktop
area on the target machine must be at least 800 by 600 pixels (or if large fonts are used, 1024 by 768 pixels), and the system
must display at least 16-bit color.
Limitations
There are limitations when using dialog skins in your project:
• A dialog skin cannot be applied to or removed from a standard dialog once you have edited that dialog in the Dialog
Editor. Therefore, if you want to specify skins for dialogs that you want to modify, specify the skin first, and then edit it.
• The location of the standard navigation buttons (Next, Cancel, Back, Finish) are the same for all skins. The .skin file
controls their position. Moving them in the Dialog Editor has no effect on the run-time positioning. There are also
some Browse buttons on a few dialogs (for example, SdAskDestPath) that cannot be repositioned.
• Skinned dialogs cannot use windowed billboards. To learn more about the windowed style of billboard, see Billboard
Styles and File Types for InstallScript and InstallScript MSI Projects.
• If you add custom dialogs to your project, the new dialogs should be the same size as the other end-user dialogs. If the
custom dialogs are a different size, they may not be displayed correctly; for example, the navigation buttons might not
be visible to the end user during run time, due to the positioning issue described above.
Note • If you want to specify a dialog skin for a custom dialog, you must set the skin before creating the custom dialog in the
Dialog Editor in order for the skin to appear properly.
InstallShield 2020
• InstallScript
• InstallScript MSI
You can use a dialog skin to change the look of the end-user dialogs in your installation. You can specify one skin per
installation project. All of the dialogs in your project are displayed using the selected skin.
Note • A dialog skin cannot be applied to or removed from a standard dialog once you have edited that dialog in the Dialog
Editor. Therefore, if you want to specify skins for dialogs that you want to modify, specify the skin first, and then edit it.
If you want to specify a dialog skin for a custom dialog, you must set the skin before creating the custom dialog in the Dialog
Editor in order for the skin to appear properly.
2. In the Dialogs explorer, expand the Skins item to see the available dialog skin options.
4. To select a displayed skin, click Select in the preview pane. A red check mark appears on the selected skin’s icon in the
Dialogs explorer.
All of the dialog skins use .gif files for the fade graphic, with the exception of the Blue skin. The Blue skin uses a .bmp file,
which results in a larger file size. The Blue skin’s appearance on a 16-bit color system is not as clean as the other colors
when a .gif file is used. If you want to use a Blue skin that supports 16-bit color systems and file size is not an issue, select
the Blue option. For a smaller file size, select the BlueTC (True Color) option, which uses a .gif file for the graphic.
2. In the Dialogs explorer, expand the Skins item to see the available dialog skin options, and select the <None> item.
See Also
Dialog Skins
The information in this section of the documentation explains how to create and perform other basic functions with
dialogs in Basic MSI projects.
Task The process of creating a new dialog and displaying it in your installation can be broken down into the following tasks:
3. Define the controls’ behavior (under what conditions they should be displayed, the events that their interaction
should trigger, and the events that they should subscribe to).
4. Display the dialog with a NewDialog or SpawnDialog event in another dialog’s control or by inserting the dialog into
your project’s sequences.
See Also
Dialogs View (Basic MSI and Other Windows Installer–Based Projects)
You can display an end-user dialog in one of two ways, as described below:
Project • When you create a dialog in a merge module, you cannot insert it into a sequence until you associate that module
with an installation project.
1. In the View List under Behavior and Logic, click Custom Actions and Sequences.
2. In the Sequences explorer, expand one of the two high-level sequences in which dialogs are usually displayed—
Installation, Advertisement, or Administration—to view its User Interface sequence.
3. Expand the User Interface sequence to see how the existing actions, dialogs, and custom actions are ordered.
4. Right-click the existing action or dialog that you want your dialog to follow in the sequence, and then click Insert. The
Insert Action dialog box opens.
7. Click OK.
When your installation runs with a full user interface (determined by the /q command-line parameter) and all conditions
are met for this dialog, it will be displayed within the selected sequences.
While InstallShield lets you insert a dialog into an Execute sequence, doing so violates ICE13.
Task For example, to display a WelcomeBitmap dialog after the InstallWelcome dialog:
2. In the Dialogs explorer, expand the InstallWelcome dialog, and then click its Behavior subnode.
3. In the pane that contains a list of controls and the corresponding control types, select the Next button.
4. In the Events setting, click the New Event button, and then click NewDialog. InstallShield adds some NewDialog
subsettings under the Event setting.
A condition of 1 indicates that the dialog should be created under all conditions.
Note • If the InstallWelcome dialog had launched a different dialog from the Next button, you would repeat the above
procedure for the WelcomeBitmap’s Next button to show the next dialog.
To learn about viewing your new dialog in the Custom Actions and Sequences view, see Viewing End-User Dialog Order in
the Custom Actions and Sequences view (Basic MSI Projects).
2. In the Dialogs explorer, right-click All Dialogs and click New Dialog. The Dialog Wizard launches to help you create a
new dialog.
The next step is to edit the dialog’s layout and the controls’ behavior.
Tip • You can also add a dialog by importing one from another project.
See Also
Removing Dialogs from Projects
Using the Dialog Editor, you can modify a dialog, edit its controls, and set display properties for the dialog and its controls,
all in a visual environment.
Note • When an end user runs your installation on a Windows platform that uses a desktop display theme, the theme is used
to display your installation’s end-user dialogs.
The Dialogs view manages versions of the dialog for each of your project’s supported languages. You must select a
language-specific version in order to edit the layout. These versions remain identical except for changes you make to a
control’s size. For more information, see Modifying Dialogs for Each Language.
InstallShield 2020
• Select the language-specific version of the dialog under the dialog’s name in the Dialogs view.
• In the Custom Actions and Sequences view, right-click the dialog and click Edit Layout.
The Dialog Editor opens in the right pane of the Dialogs view.
InstallShield 2020
You can use the Controls toolbar in InstallShield to add controls to a dialog.
2. In the Dialogs explorer, expand the All Dialogs folder, and then expand the dialog item that should have the new
dialog control.
3. Click a language under the dialog item that you expanded. The Dialog Editor in the center pane shows the dialog in the
selected language.
4. In the Controls toolbar, click the control that you want to add.
5. Draw a rectangle on the dialog in the location where you want the control to be displayed.
Tip • If you are editing an InstallShield project from within Microsoft Visual Studio, you can use the Toolbox to add controls.
See Also
Showing or Hiding Toolbars
Creating InstallShield Projects in Microsoft Visual Studio
Using the Toolbox to Add Dialog Controls
InstallShield 2020
The dialog itself and every control on it has a grid of settings in the Dialog Editor. These settings determine characteristics
such as a control’s size and position, its default text (as a string identifier), or whether the dialog is modal.
To edit the settings of a control, select the control on the dialog. The settings vary depending on the type of control:
• Bitmap
• Dialog
• Check Box
• Push Button
• Edit Field
• Combo Box
• Text Area
• List Box
• Radio Button
• Bitmap
• Group Box
• Billboard
• Line
• Selection Tree
• Progress Bar
• List View
• Scrollable Text
• Icon
• Directory List
• Directory Combo
• Masked Edit
• Path Edit
InstallShield 2020
• The value for the Tab Index property of the bitmap must be lower than the value for the Tab Index property of any
controls that are to be placed on top of the bitmap. The easiest way to configure this is to set the bitmap control’s Tab
Index property to 0.
• All controls—including the bitmap—must have their Tab Stop properties set to True.
See Also
Copying and Pasting Controls
Undoing Changes in the Dialog Editor
In the Dialogs view, you can configure settings to specify how controls will behave at run time. The behavior-related
settings for a control enable you to configure the following types of functionality:
• Events that an end user interacting with the control will trigger
• In the Dialogs view, expand the dialog node for the dialog that you want to modify, and then click its Behavior
subnode.
• In the Custom Actions and Sequences view, right-click the dialog and click Edit Behavior.
2. In the center pane, which shows a list of all of the controls on the selected dialog, click the control that you want to
configure. Its settings are displayed in the right pane.
See Also
Using Control Events in Basic MSI Dialogs
Using Subscriptions in Basic MSI Dialogs
Triggering Control Events in Basic MSI Dialogs
Reordering a Dialog Control’s Events
Control events enable you to provide custom functionality for each control on your dialogs. With control events, you can
launch custom actions, spawn new dialogs, or display a progress bar. Many control events make use of published
information. In some cases, your controls must subscribe to control-event information in order to make use of it.
To associate an event with a control, use the Behavior area for a dialog in the Dialogs view. For more information, see
Editing Dialog Behavior in Basic MSI Projects. To learn about subscriptions for controls, see Using Subscriptions in Basic
MSI Dialogs.
To specify a condition for any event, click the ellipsis button (...) in the event setting.
AddLocal Sets the specified feature (or all features, if ALL is specified) to be installed locally.
AddSource Sets the specified feature (or all features, if ALL is specified) to be installed to run from
source.
CheckExistingTargetPat Verifies that the specified path can be written to, and prevents additional control events
h from being triggered unless the specified path exists.
To specify the property that contains the path, configure this setting's subsetting.
CheckTargetPath Prevents additional control events from being triggered unless the specified value is a valid
path.
To specify the property that contains the path, configure this setting’s subsetting.
DirectoryListNew Notifies the directory list control that a new folder must be created. The installer then
creates a new folder and allows the user to enter a new name for the folder.
DirectoryListOpen Notifies the directory list control to open the selected directory. If none is selected, it
prevents additional control events from being triggered.
DirectoryListUp Notifies the directory list control to go up a level, selecting the parent of the current
directory.
To specify whether you want the event to enable rollback, configure this setting’s
subsetting. A value of True enables rollback; False disables it.
EndDialog Dismisses a modal dialog. You can use this event for a push button control or a selection
tree control.
To specify the behavior that should occur for this event, configure this setting’s subsetting.
• Exit—The dialog sequence closes and control is returned to the installer with the
UserExit value. This option cannot be used with child windows.
• Retry—The dialog sequence closes and control is returned to the installer with the
Suspend value. This option cannot be used with child windows.
• Ignore—The dialog sequence closes and control is returned to the installer with the
Finished value. This option cannot be used with child windows.
• Return—The dialog exits and control is returned to the parent window. If no parent
exists, control is returned to the installer with the Success value.
• ErrorOK
• ErrorCancel
• ErrorAbort
• ErrorRetry
• ErrorIgnore
• ErrorYes
• ErrorNo
MsiLaunchApp
Note • Windows Installer 5 includes support for this event. Earlier versions of Windows
Installer ignore this event. Therefore, if your installation is run on a system that has Windows
Installer 4.5 or earlier and you want to use this event, add a condition to the dialog control so
that it is not displayed on systems that have Windows Installer 4.5 or earlier.
This event is typically used for a check box control on the SetupCompleteSuccess dialog.
The check box enables end users to choose whether to run the application at the end of the
installation. The check box control should include a condition that prevents the control
from being displayed during uninstallation.
To specify the command line for launching the file, configure this setting’s subsetting.
MsiPrint
Note • Windows Installer 5 includes support for this event. Earlier versions of Windows
Installer ignore this event. Therefore, if your installation is run on a system that has Windows
Installer 4.5 or earlier and you want to use this event, add a condition to the dialog control so
that it is not displayed on systems that have Windows Installer 4.5 or earlier.
You can add this event to a push button control that is on a dialog that has a scrollable text
control. When an end user clicks the push button control, the contents of the scrollable text
control are printed.
Reinstall Reinstalls the specified feature (or all features, if ALL is specified).
Remove Indicates that the specified feature (or all features, if ALL is specified) is selected for
removal.
Reset Resets all of the property changes that all of the controls on the dialog have performed to
their original values.
RMShutdownAndRestart Indicates that the Restart Manager should shut down all applications that have files in use
and restart them at the end of the installation.
SelectionBrowse Launches the specified Browse dialog that enables the end user to modify the path of the
highlighted item.
To specify the property that contains the path, configure this setting’s subsetting.
SpawnDialog Launches the specified dialog of a modal dialog without closing the current dialog.
SpawnWaitDialog Launches a dialog that waits until the conditional expression evaluates as True; then the
dialog closes.
See Also
Adding New Events to a Dialog Control
Reordering a Dialog Control’s Events
Using Subscriptions in Basic MSI Dialogs
Triggering Control Events in Basic MSI Dialogs
The Windows Installer service provides volumes of information to the installation during the run time. One of the most
useful ways to gather information during installation is to use subscriptions. To subscribe to something is commonly
defined as entering one’s name for a publication or service. In Windows Installer terms, actions generally publish
information, and dialog controls generally subscribe to information.
Windows Installer tracks progress through what are called ticks. When your progress bar subscribes to this information, it is
passed the ticksSoFar and totalTicks values. The progress bar uses this information to display the total progress of the
installation.
Subscriptions are not used only for progress bars. You might have a custom action that validates a serial number as part of
your installation. This action could publish the failure or success of validation. On a dialog, you could have a Next button
that subscribes to this information. If the action publishes the failure of the validation, the button remains disabled. If the
action publishes success, the button is enabled.
Types of Subscriptions
To set up a subscription for a control, use the Behavior area for a dialog in the Dialogs view. For more information, see
Editing Dialog Behavior in Basic MSI Projects.
Event Description
A text control can subscribe to this event to display information such as the names of files
that are being copied during the installation.
A text control can subscribe to this event to display a description of the current action that
is being performed during the installation.
IgnoreChange Highlights a folder in the current directory without opening the folder.
ScriptInProgress Displays informational text while Windows Installer is compiling the installation's
execution script.
SelectionDescription Displays a UI string in a text control. The UI string describes the feature that is selected in
the selection tree control.
SelectionPath Publishes the path of the item that is selected in the selection tree control.
SelectionPathOn Publishes a Boolean value that indicates whether a selection path is associated with the
currently selected feature.
TimeRemaining Publishes the approximate number of seconds that remain for the current progress
sequence.
A text control can subscribe this event to display the remaining time.
See Also
Using Action Text
Using Control Events in Basic MSI Dialogs
An event is a predefined action that occurs when an end user interacts with a control. Events are defined in the Behavior
area of the Dialogs view. For more information on each of the events that are available, see Using Control Events in Basic
MSI Dialogs.
To view a control’s events, select it in the list of control names and then configure the Events setting in the right pane.
InstallShield 2020
2. In the Dialogs explorer, expand the dialog node for the dialog that you want to modify, and then click its Behavior
subnode.
3. In the center pane, which shows a list of all of the controls on the selected dialog, click the control that you want to
configure. Its settings are displayed in the right pane.
4. In the Events setting, click the New Event button, and then select the type of event that you want to add. InstallShield
adds a new set of rows under the Events setting.
5. To specify a condition for the event, click the ellipsis button (...) in the new event setting. The Condition Builder
dialog box opens, enabling you to specify the conditions that must be met for the action.
If you want the event to be triggered under any conditions, enter the following condition:
InstallShield 2020
The events that are configured for a user interface control are launched at run time in the order in which they are displayed
for that control’s Events setting.
2. In the Dialogs explorer, expand the dialog node for the dialog that you want to modify, and then click its Behavior
subnode.
3. In the center pane, which shows a list of all of the controls on the selected dialog, click the control that has the events
that you want to reorder. Its settings are displayed in the right pane.
4. In the Events area of the grid of settings, find the event setting of an event that you want to move.
5. In the event setting for an event that you want to move, click the Move Event button, and then click Move Up or Move
Down.
InstallShield 2020
2. In the Dialogs explorer, expand the dialog node for the dialog that you want to modify, and then click its Behavior
subnode.
3. In the center pane, which shows a list of all of the controls on the selected dialog, click the control that has the event
that you want to remove. Its settings are displayed in the right pane.
4. In the Events area of the grid of settings, find the event setting of the event that you want to remove.
To launch a custom action from a button on a dialog, use the button control’s DoAction event. Before you can set up a
DoAction event, you need to create a custom action.
When you have created a custom action, you can set up a DoAction event to launch this action.
2. In the Dialogs explorer, expand the dialog node for the dialog that you want to modify, and then click its Behavior
subnode.
3. In the center pane, which shows a list of all of the controls on the selected dialog, click the push button control that
you want to trigger the custom action. Its settings are displayed in the right pane.
4. In the Events setting, click the New Event button, and then click DoAction. InstallShield adds a new set of rows under
the Events setting.
5. To specify a condition for the event: In the DoAction setting, click the ellipsis button (...). The Condition Builder
dialog box opens, enabling you to specify the conditions that must be met for the action.
6. In the Action subsetting, specify the name of the action that you want to associate with the control.
Viewing End-User Dialog Order in the Custom Actions and Sequences view (Basic MSI Projects)
InstallShield 2020
Project • This information applies to Basic MSI projects. To view the order of your end-user dialogs in an InstallScript project
or an InstallScript MSI project, use the InstallScript view to review your script.
In the Custom Actions and Sequences view, you can view primary and next dialogs in the order in which they appear to the
end user during the run time of your installation. Primary dialogs are top-level dialogs that have been inserted into the
installation sequence. You can change the order of a primary dialog within the Custom Actions and Sequences view.
Next dialogs are dialogs that are triggered by the action of a previous dialog’s Next button control events. Although you can
view next dialogs in the Custom Actions and Sequences view, they are not a part of the installation sequence, and you
cannot change their order in the Custom Actions and Sequences view. To change the order of a next dialog, you must use
the Behavior node under a dialog in the Dialogs view. To learn more, see Editing Dialog Behavior in Basic MSI Projects.
When you click the plus sign (+) next to a primary dialog, the list expands to display the order in which the primary dialog’s
next dialogs—if any—will appear during the run time. If a particular dialog has more than one Next button control event, all
possible next dialogs are displayed under the dialog.
Edit Behavior
Task To move to the Dialog Behavior Editor from within the Sequences explorer in the Custom Actions and Sequences view,
do either of the following:
• Right-click the next dialog that you want to edit and click Edit Behavior.
• Click the name of the dialog that you want to edit. Then, in the Action Items section of the right pane, click Edit dialog
behavior.
For more information, see Editing Dialog Behavior in Basic MSI Projects.
Edit Layout
Task To move to the Dialog Layout Editor from within the Sequences explorer in the Custom Actions and Sequences view, do
either of the following:
• Right-click the next dialog that you want to edit and click Edit Layout.
• Click the name of the dialog that you want to edit. Then, in the Action Items section of the right pane, click Edit dialog
layout.If you have written your installation in more than one language, you must select the appropriate language in
the list.
For more information, see Editing Dialog Layout in Basic MSI Projects.
• Basic MSI
• MSI Database
• Transform
The CustomSetup dialog has a sophisticated end-user interface that is tightly integrated with information about the target
system, the features in your installation, and Windows Installer installation options. It provides the end user with the most
control over the installation.
Many of the options and information it offers are determined by the feature properties that you set in your setup design, as
described below.
Advertisement Option
Feature advertisement enables files to be installed on demand after the installation has initially run. In the CustomSetup
dialog, when end users click a feature, they can specify that they want it installed later by selecting the Will be installed
when required option.
However, that default option is present only if you select Allow Advertise or Favor Advertise for the feature’s Advertised
setting. To prevent Windows Installer from displaying the option to advertise the feature, select Disallow Advertise for this
setting.
Hiding Features
When you set a feature’s Display setting to Not Visible, the end user cannot see the feature or its subfeatures in the
CustomSetup dialog and therefore cannot change any of its installation options.
Option Description
Visible and Collapsed The feature is displayed in the CustomSetup dialog with its subfeatures collapsed
by default.
Visible and Expanded The feature is displayed in the CustomSetup dialog with its subfeatures expanded
by default.
For a complete discussion of the factors that affect where a feature is installed, see Setting a Feature’s Destination.
Naming Features
Specify a different name to appear in the CustomSetup dialog by setting its Display Name.
See Also
Advertising Features
Dialog Themes
InstallShield 2020
Dialog themes are predefined sets of images that give your end-user dialogs a unified and distinctive look.
With the click of a button, you can select one of the available themes for your project, and InstallShield applies that theme
to all of the interior and exterior dialogs, as well as the Setup.exe initialization dialog, in your project. You can easily
preview each dialog from within the Dialogs view to see how it looks with the selected theme.
Note • InstallShield does not currently let you create your own dialog themes. However, InstallShield includes many themes.
For more information, see Available Themes and Corresponding Dialog Sizes.
See Also
Dialogs View (Basic MSI and Other Windows Installer–Based Projects)
InstallShield 2020
If you use one of the wide dialog themes, the screen resolution on target systems must be a minimum of 800×600 pixels (or,
if large fonts are used, 1024×768 pixels). If the resolution is lower than that, a horizontal scrollbar is added at run time to the
bottom of each of the dialogs that is displayed with the wide theme.
See Also
Available Themes and Corresponding Dialog Sizes
Circles Theme (Wide)
Cooperation Theme (Wide)
Filmstrip Theme (Wide)
InstallShield Blue Theme (Wide)
Theater Theme (Wide)
InstallShield 2020
When you select a different theme for your project, InstallShield applies that theme to all of the interior and exterior
dialogs in the Dialogs view. You do not need to build and run your installation in order to view the dialogs.
In the right pane, InstallShield shows a screen shot of a sample exterior dialog with the selected theme.
Task To preview how a dialog in your project looks with the selected theme:
2. In the Dialogs explorer, expand the All Dialogs folder, and then expand the dialog item that you want to preview.
In the center pane, InstallShield displays a preview of the dialog with the selected theme applied.
See Also
Dialogs View (Basic MSI and Other Windows Installer–Based Projects)
InstallShield 2020
You can use a dialog theme to change the look of the end-user dialogs in your installation. You can select one theme per
project.
Tip • If you switch from one of the wide-style themes to a standard-width theme, the positions of any controls that are placed
along the far left or far right sides of the dialog may change.
If you want to change the theme for your project and you also want to add a custom exterior dialog, change the theme first,
and then add the custom exterior dialog. Otherwise, the dialog may not appear properly.
3. Right-click the theme that you want to use, and then click Select.
InstallShield applies the selected theme to the dialogs in your project. In addition, InstallShield displays a red check mark
on the selected theme’s icon in the Dialogs explorer.
Tip • You can also change the theme by clicking a button: In the Dialogs explorer, click the theme that you want to use. Then,
in the right pane, click the Select button.
For example, if you switch from a standard width theme to any other theme, InstallShield applies the theme to any dialogs
that have a standard width and height: 374×266. If you switch from a wide theme to any other theme, InstallShield applies
the theme to any dialogs that are 584×274.
If you add a custom exterior dialog to your project after you have selected a theme, InstallShield uses the selected theme
for the new custom exterior dialog. However, if you later change the theme for your project, the theme may not be
displayed properly in your custom exterior dialog. To resolve this type of issue, see Applying a Theme to a Custom Exterior
Dialog.
See Also
Available Themes and Corresponding Dialog Sizes
Dialogs View (Basic MSI and Other Windows Installer–Based Projects)
InstallShield 2020
If you want to change the theme for your project and you also want to add a custom exterior dialog, it is easier to change
the theme first, and then add the custom exterior dialog. Otherwise, the dialog may not appear properly; parts of newly
selected theme’s interior dialog images are added to your custom exterior dialog.
If you want to change the theme after you have added a custom exterior dialog to your project, you must add the name of
your custom exterior dialog to the appropriate .theme file that is installed in the InstallShield Program Files folder. Then
you can apply the theme to your project.
Task To change the theme after you have added a custom exterior dialog to your project:
1. Close InstallShield.
2. In the InstallShield Program Files folder, find the .theme file for the theme that you want your dialogs to use. The
default location is:
C:\Program Files\InstallShield\2020\Support\Themes
3. Open the .theme file in a text editor such as Notepad. For example, if you want to use the Global theme, open the
Global.theme file.
4. In the <Include> and <Exclude> sections of the file, add the following line:
<Name>NameOfDialog</Name>
8. Right-click the theme that you want to use, and then click Select.
See Also
Available Themes and Corresponding Dialog Sizes
InstallShield 2020
Exterior dialogs are dialogs that are displayed first and last by an installation—typically, the Welcome and Completion
dialogs. The exterior dialogs for some themes have places for you to put the logo of your company or product. For example,
the exterior dialogs of the Monitor theme and the Circles theme have a blank area on the left side of the dialog; you can add
a bitmap control to these dialogs to customize your end-user interface.
2. In the Dialogs explorer, expand the All Dialogs folder, and then expand the dialog item for a dialog that should have
the image.
3. Click a language under the dialog item that you expanded. The Dialog Editor in the center pane shows the dialog in the
selected language.
5. In the Dialog Editor, click where you want the bitmap control to start, and holding the left mouse button down, drag
the mouse to the place where you want it to end. Then release the left mouse button.
Click the File Name property, and then click the ellipsis button (...) to browse to the bitmap file that you want to use.
You may want to repeat the procedure for each language and each exterior dialog in your project. The exterior dialogs that
are available by default in all new Basic MSI projects are:
• AdminWelcome
• InstallWelcome
• MaintenanceWelcome
• PatchWelcome
• SetupCompleteError
• SetupCompleteSuccess
• SetupInitialization
• SetupInterrupted
• SetupResume
• SplashBitmap
InstallShield 2020
Project • Some of the themes are available in both the Premier and Professional editions of InstallShield, and some are
available in only the Premier edition.
Some of the themes set the size of the dialogs to a standard width and height: 374×266. The wide themes set the dialog size
to 584×274. The following table shows the size of each dialog, plus which editions of InstallShield contain the theme.
InstallShield 2020
Following are sample exterior and interior dialogs with the Circle Theme (Wide).
Figure 4-4: Sample Exterior Dialog with the Circle Theme (Wide)
Figure 4-5: Sample Interior Dialog with the Circle Theme (Wide)
To learn how to add your company or product logo to the exterior dialogs, see Adding a Logo or Other Image to the Exterior
Dialogs.
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
Classic Theme
InstallShield 2020
Following are sample exterior and interior dialogs with the Classic Theme.
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
InstallShield 2020
Following are sample exterior and interior dialogs with the Cooperation Theme (Wide).
Figure 4-8: Sample Exterior Dialog with the Cooperation Theme (Wide)
Figure 4-9: Sample Interior Dialog with the Cooperation Theme (Wide)
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
InstallShield 2020
Following are sample exterior and interior dialogs with the Filmstrip Theme (Wide).
Figure 4-10: Sample Exterior Dialog with the Filmstrip Theme (Wide)
Figure 4-11: Sample Interior Dialog with the Filmstrip Theme (Wide)
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
Global Theme
InstallShield 2020
Following are sample exterior and interior dialogs with the Global Theme.
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
InstallShield 2020
Following are sample exterior and interior dialogs with the InstallShield Blue Theme.
Figure 4-14: Sample Exterior Dialog with the InstallShield Blue Theme
Figure 4-15: Sample Interior Dialog with the InstallShield Blue Theme
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
InstallShield 2020
Following are sample exterior and interior dialogs with the InstallShield Blue Theme (Wide).
Figure 4-16: Sample Exterior Dialog with the InstallShield Blue Theme (Wide)
Figure 4-17: Sample Interior Dialog with the InstallShield Blue Theme (Wide)
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
InstallShield 2020
Following are sample exterior and interior dialogs with the InstallShield Silver Theme.
Figure 4-18: Sample Exterior Dialog with the InstallShield Silver Theme
Figure 4-19: Sample Interior Dialog with the InstallShield Silver Theme
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
Monitor Theme
InstallShield 2020
Following are sample exterior and interior dialogs with the Monitor Theme.
To learn how to add your company or product logo to the exterior dialogs, see Adding a Logo or Other Image to the Exterior
Dialogs.
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
InstallShield 2020
Following are sample exterior and interior dialogs with the Pastel Wheat Theme.
Figure 4-22: Sample Exterior Dialog with the Pastel Wheat Theme
Figure 4-23: Sample Interior Dialog with the Pastel Wheat Theme
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
InstallShield 2020
Following are sample exterior and interior dialogs with the Theater Theme (Wide).
Figure 4-24: Sample Exterior Dialog with the Theater Theme (Wide)
Figure 4-25: Sample Interior Dialog with the Theater Theme (Wide)
To learn how to add your company or product logo to the exterior dialogs, see Adding a Logo or Other Image to the Exterior
Dialogs.
See Also
Available Themes and Corresponding Dialog Sizes
Dialog Themes
Edition • The Premier edition of InstallShield includes dialog support for languages such as Arabic and Hebrew, which are
read from right to left.
Project • The following project types include dialog support for right-to-left languages:
• Basic MSI
• Merge Module
InstallShield includes support for Arabic (Saudi Arabia) and Hebrew languages, which are written and read from right to
left. All of the default end-user dialog strings are available in these languages.
Since these languages are read from right to left, InstallShield also includes support for mirroring Arabic and Hebrew
dialogs; that is, InstallShield uses a right-to-left layout for Arabic and Hebrew dialogs. Thus, for example, buttons that are
on the right side of dialogs in English and other left-to-right languages are moved to the left side of right-to-left-language
dialogs. This occurs in the Dialog Editor pane in the Dialogs view of InstallShield; it also occurs at run time.
Reversed versions of the dialog images are displayed for the built-in dialog themes if appropriate. The reversed versions
have _mirror in the image file name immediately before the .bmp or .jpg portion of the file name. For example, the name of
an image for left-to-right languages might be banner.jpg; the name of the right-to-left equivalent for that image would be
banner_mirror.jpg. These two files would be located in the same folder, and InstallShield would automatically use the
banner_mirror.jpg file for the right-to-left-language versions of the dialogs. If an image should not be reversed, a
*_mirror.jpg or *_mirror.bmp version of the image is not included, and the right-to-left versions of the dialogs do not show
mirrored versions of the images.
Tip • If you use custom images for your run-time dialogs and your project includes support for right-to-left languages, you
may need to create mirror-image versions for those right-to-left languages. You can preview the right-to-left layout of the
dialogs in the Dialogs view to see how your custom images look. Add *_mirror.jpg or *_mirror.bmp versions of your images to
the folder that contains the left-to-right versions of your custom images if appropriate.
See Also
Creating Multilingual Installations
InstallShield includes support for launching the Open dialog from one of the dialogs in your Basic MSI installation. End
users click a browse button in one of your dialogs, and this launches the Open dialog. The Open dialog lets the end user
browse for a file. When the end user selects the file and clicks the Open button, the Open dialog closes, and the installation
writes the full path and file name in an edit field on the dialog. The installation also sets the value of the
IS_BROWSE_FILEBROWSED property to the path and file name of the file that the end user selected.
When you incorporate support for the Open dialog in your installation, you can define several properties to specify the
following functionality:
• You can specify the default path that is displayed in this dialog.
• You can specify the string that should be displayed in the Files of type drop-down list on the Open dialog.
• You can specify the file extensions of the files that should be displayed when the end user is browsing through folders
to select a file. All files that have other file extensions are hidden and cannot be selected to open.
• You can specify the default file extension that the Open dialog should use. If the end user does not type an extension,
the Open dialog appends this default extension to the file name.
• The Open dialog does not allow end users to create a new file. That is, if a file does not exist, an end user cannot
manually type a new file name in the Open dialog.
• If the dialog that launches the Open dialog has more than one edit field control, the edit field control that will contain
the full path to the file must have the lowest value for the Tab Stop property.
1. Add to your project a new MSI DLL custom action called FileBrowse:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences.
b. Right-click the Custom Actions explorer, point to New MSI DLL, and then click Stored in Binary table.
InstallShield adds a new custom action called NewCustomActionN, where N is a successive number.
d. In the pane on the right, configure the following settings for this custom action:
For all other settings, leave the default values. The value of the MSI Type Number setting should be 65.
2. Create or edit the dialog that should launch the Open dialog, and configure its behavior and layout:
Note that if you select an existing dialog and it has more than one edit field control, the edit field control that will
contain the full path to the file must have the lowest value for the Tab Stop property.
d. Under this dialog, click the language whose layout you want to configure.
e. Add the edit field control that will contain the full path and file name that the end user selects at run time. When
InstallShield prompts you for the property name associated with the control, enter IS_BROWSE_FILEBROWSED.
f. Next to the edit field control, add a push button control. This is the button that will launch the Open dialog.
g. Select the push button control and then edit its properties in the grid on the right as needed. For example, to
specify the text that you want to be displayed on the button, add a value for the Text property.
h. In the Dialogs explorer, click the Behavior item under the dialog that you are configuring.
i. In the center pane that lists the dialog controls, click the push button control that you just created. Its settings are
displayed in the right pane.
j. In the Events setting, click the New Event button, and then click DoAction. InstallShield adds a new set of rows
under the Events setting.
FileBrowse
m. In the Events setting, click the New Event button, and then click SetProperty. InstallShield adds a new set of
rows under the Events setting.
IS_BROWSE_FILEBROWSED
[IS_BROWSE_FILEBROWSED]
Note • The SetProperty Event refreshes the MSI property value displayed in the Edit field control on the dialog, so
that the displayed MSI property value is updated after selecting a file in the file browse window.
3. Configure several properties to specify behavior of the Open dialog and the dialog that launches the Open dialog:
a. In the View List under Behavior and Logic, click Property Manager.
b. Find the IS_BROWSE_FILEBROWSED property. Its default value is 0. Do one of the following:
• To leave the edit field control blank in your dialog when the end user first displays it, right-click the row that
has the IS_BROWSE_FILEBROWSED property and then click Delete Property.
• To display a default path and file name in the edit field control, change the value of the
IS_BROWSE_FILEBROWSED property to the path and file name.
Note • If you do not manually change the value of this property or delete this property, the default value for the edit
field control on the dialog that launches the Open dialog is set to 0.
c. Optionally, add a property called IS_BROWSE_FILEEXT, and set its value to a filter string that identifies the file
extensions that should be displayed when the end user is browsing through folders to select a file. All files that
have other file extensions are hidden and cannot be selected to open.
A filter string can be a combination of valid file name characters and the asterisk (*) as a wild-card character.
To specify multiple file extensions, separate each with a semicolon. Do not include spaces. For example, to let
end users select .exe and .dll files, enter the following string as the value of the IS_BROWSE_FILEEXT property:
*.exe;*.dll
In this example, the Open dialog lets end users select .exe and .dll files. It hides all other file types.
If you do not set this property, the Open dialog lets end users select any file type.
d. Optionally, add a property called IS_BROWSE_FILETYPE, and set its value to the string that you want to be
displayed in the Files of type drop-down list on the Open dialog. Note that only one option can be displayed in
this drop-down list.
For example, if you want end users to be able to select .txt or .doc files, enter the following string as the value of
the IS_BROWSE_FILETYPE property:
If you do not set this property, the Files of type drop-down list in the Open dialog is blank.
e. Optionally, add a property called IS_BROWSE_DEFAULTEXTENSION, and set its value to the default file extension
that the Open dialog should use. If the end user does not type an extension, the Open dialog appends this default
extension to the file name. For example, to use .exe as the default file extension, enter the following string as the
value of the IS_BROWSE_DEFAULTEXTENSION property:
exe
f. Optionally, add a property called IS_BROWSE_INITIALDIR, and set its value to the default path that the Open
dialog should use. For example, to use C:\Program Files\My Product, enter the following string as the value of
the IS_BROWSE_INITIALDIR property:
At run time, when the end user clicks the new push button control, the Open dialog opens. The end user can browse to and
select a file. The installation sets the value of the IS_BROWSE_FILEBROWSED property to the path and file name of the file that
the end user selected, and then it displays that path and file name in the edit field control on the dialog that launched the
Open dialog.
Requiring End Users to Scroll Through the EULA in the LicenseAgreement Dialog
InstallShield 2020
InstallShield includes support for disabling the Next button on the LicenseAgreement dialog until the end user reaches the
end of the End-User License Agreement (EULA) text in the scrollable EULA control through one of the following methods:
• Pressing PAGE DOWN when the scrollable EULA control has focus.
• Pressing CTRL+PAGE DOWN when the scrollable EULA control has focus.
• Pressing the DOWN ARROW key when the scrollable EULA control has focus.
The end user must also select the I accept the terms in the license agreement option before the Next button is enabled.
The LicenseAgreement dialog requires end users to select the I accept option by default. If you also want to require end
users to reach the end of the EULA text, perform the following task.
Task To require end users to reach the end of the EULA text in the scrollable EULA control:
1. Add to your project a new MSI DLL custom action called WatchScroll:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences.
b. Right-click the Custom Actions explorer, point to New MSI DLL, and then click Stored in Binary table.
InstallShield adds a new custom action called NewCustomActionN, where N is a successive number.
d. In the pane on the right, configure the following settings for this custom action:
For all other settings, leave the default values. The value of the MSI Type Number setting should be 129.
2. Edit the LicenseAgreement dialog so that it launches the appropriate custom action:
b. In the Dialogs explorer, expand the All Dialogs folder, and expand the LicenseAgreement item, and then click
Behavior.
c. In the center pane that lists the LicenseAgreement controls, click the ScrollableText control named Memo. This is
the control that contains the text of the EULA. Its settings are displayed in the right pane.
d. In the Events setting, click the New Event button, and then click DoAction. InstallShield adds a new set of rows
under the Events setting.
WatchScroll
g. In the center pane that lists the LicenseAgreement controls, click the push button control named Next.
h. In the Conditions setting, click the New Condition button, and then click Disable. InstallShield adds a Disable
setting.
j. In the Conditions setting, click the New Condition button, and then click Enable. InstallShield adds an Enable
setting.
At run time, the installation monitors the EULA control in an asynchronous custom action. While the custom action is
running, the ISLicenseWatching property is set. Once the custom action is finished, it removes the ISLicenseWatching
property. This avoids the hourglass flicker otherwise seen when end users scroll through the EULA text. Once the end user
reaches the bottom of the EULA text, the installation sets the LicenseViewed property and manually enables the Next
button if necessary according to the Next button’s conditions. The Next button is found via its text as stored in the Control
table; therefore, you can use the aforementioned procedure with any language transform as long as the control is named
Next.
See Also
License Agreements
In Basic MSI projects that are created in InstallShield X or later, the LicenseAgreement dialog includes a Print button. This
button enables the end user to print the content of the dialog’s ScrollableText control. This button’s event executes the
custom action ISPrint, which is included in a new Basic MSI project. Following are directions for adding a Print button to
another dialog, and to an existing project that was created with InstallShield DevStudio 9.0 or earlier.
1. Create a button control in the dialog and optionally set its Text property to &Print. For details, see Editing Dialog
Layout in Basic MSI Projects.
2. Add a DoAction event to the Print button, and in the event’s Action subsetting, select ISPrint. For details, see
Triggering Control Events in Basic MSI Dialogs.
3. Modify the value of IS_PRINT_DIALOG from the events of the Back and Next buttons of the dialog and its next and
previous dialogs:
a. Determine which dialog is displayed before the dialog to which you are adding a Print button. You can do this by
either checking the argument of the NewDialog event for the dialog’s Back button, or viewing next dialog order in
the expanded Custom Actions and Sequences view.
b. Add a SetProperty event. In the SetProperty setting, specify the following as the event condition:
IS_PRINT_DIALOG
d. In the Value setting, specify the name of the dialog to which you are adding a Print button
e. If a Print button is included on any dialog that is displayed after the dialog to which you are adding a Print button,
do the following:
i. Determine which dialog is displayed after the dialog to which you are adding a Print button. You can do this
by either checking the argument of the NewDialog event for the dialog’s Next button, or viewing the next
dialog order in the expanded Custom Actions and Sequences view.
ii. Add a SetProperty event to that next dialog’s Back button, and set its Property Name setting to
IS_PRINT_DIALOG, and its Value setting to the name of the dialog to which you are adding a Print button.
If the next dialog does not have a Print button, or if it is the LicenseAgreement dialog, add a SetProperty event to
the Next button of the dialog to which you are adding a Print button, and set its Property Name setting to
IS_PRINT_DIALOG, and its Value setting to LicenseAgreement.
f. If a Print button is included on any dialog that is displayed before the dialog to which you are adding a Print
button, and the previous dialog does not have a Print button or it is the LicenseAgreement dialog, add a
SetProperty event to the Back button of the dialog to which you are adding a Print button, and set its Property
Name setting to IS_PRINT_DIALOG, and its Value setting to LicenseAgreement.
Task To add a Print button to an existing project that was created with InstallShield DevStudio 9.0 or earlier:
c. In the Action Type panel’s Type box, select Call a function in a Windows Installer dynamic-link library.
d. In the Action Parameters panel, click the Browse button and browse to the file SetAllUsers.dll in the
InstallShield folder’s Redist\Language Independent\i386 subfolder. Click Open.
If your project is configured to use path variables, InstallShield uses the predefined path variable
<ISRedistPlatformDependentFolder> for part of the path.
2. Create a button control in the dialog and optionally set its Text property to &Print. For details, see Editing Dialog
Layout in Basic MSI Projects.
3. Add a DoAction event to the Print button, and in the event’s Action subsetting, select ISPrint. For details, see
Triggering Control Events in Basic MSI Dialogs.
4. Create the Windows Installer property IS_PRINT_DIALOG and set its value to the name of the dialog. For details, see
Creating Properties in Windows Installer–Based Projects.
Note • If the ISPrint custom action is executed by a control event, the custom action’s logging information cannot be recorded
to the installer log in the usual manner (because of a Windows Installer limitation); the information is logged to the values of
properties that have the form ISPrintLogmNoten.
Windows Logo • Restarting the system after an installation is inconvenient for end users. One of the Windows logo program
requirements is that all installations must contain an option that enables end users to automatically close applications and
attempt to restart them after the installation is complete.
To support this requirement, all Basic MSI projects include the MsiRMFilesInUse dialog by default. An installation displays
the MsiRMFilesInUse dialog on a Windows Vista or later system if one or more files that need to be updated are currently in
use during the installation. The dialog contains two options to allow end users to specify how to proceed:
• End users can choose to have the installation close the applications that are using those files and then attempt to
restart the applications after the installation is complete.
• End users can avoid closing the applications. A reboot will be required at the end of the installation.
For the best end-user experience, your application should be instrumented to use the Restart Manager API; doing so allows
the Restart Manager to effectively pause and resume your application exactly where the end user left it. For detailed
information, see About Restart Manager and the other Restart Manager documentation on the MSDN Web site.
See Also
Using Windows Installer with Restart Manager (Windows Installer Help Library)
Using Windows Installer with Restart Manager (Windows Installer Help Library)
Dialog Controls
InstallShield 2020
Whether your dialog is part of a Basic MSI, InstallScript, InstallScript MSI, InstallScript Object, or Merge Module project, you
can use many of the same controls to modify the layout and behavior of your predefined and custom dialogs.
Billboard Basic MSI, Merge A billboard control is used to display data that can be updated in
Module response to control events. You can use a billboard, for example, to
display the progress of a protracted custom action.
Check box Basic MSI, A check box control displays a check box that end user can select or
InstallScript, clear.
InstallScript MSI,
InstallScript Object,
Merge Module
Combo box Basic MSI, A combo box control is a box that contains a drop-down list of
InstallScript, predefined values; the box is also an edit field in which an end user
InstallScript MSI, can enter a value.
InstallScript Object,
Merge Module
Dialog Basic MSI, A dialog control is associated with a series of settings that you
InstallScript, configure.
InstallScript MSI,
InstallScript Object,
Merge Module
Directory combo Basic MSI, Merge A directory combo is used in conjunction with a directory list and a
Module path edit control to create a browse dialog. The directory combo
displays the list of drives mapped on the current system.
Directory list Basic MSI, Merge A directory list is used in conjunction with a directory combo and a
Module path edit control to create a browse dialog. The directory list displays
the folders below the drive that is selected in the directory combo
control, and it populates the value of the path edit control.
Edit Field Basic MSI, An edit field control is a text box in which end users can enter a string
InstallScript, or an integer.
InstallScript MSI,
InstallScript Object,
Merge Module
Group box Basic MSI, A group box can be used to enclose various controls in one area. A
InstallScript, group box also provides a label that you can use to express the
InstallScript MSI, relationship between the controls that are contained within it.
InstallScript Object,
Merge Module
Hyperlink Basic MSI, Merge The hyperlink control displays an HTML link; clicking the link at run
Module time opens a page in the default browser on the target system.
Line Basic MSI, The line control creates lines of adjustable length and thickness. You
InstallScript, can use lines on a dialog to separate areas of the dialog or add
InstallScript MSI, graphical touches.
InstallScript Object,
Merge Module
List box Basic MSI, The list box control is a standard list box that lets end users select a
InstallScript, single option from a list of predetermined options.
InstallScript MSI,
InstallScript Object,
Merge Module
List view Basic MSI, The list view control displays a single column of options; an icon is
InstallScript, displayed next to each option.
InstallScript MSI,
InstallScript Object,
Merge Module
Masked edit Basic MSI, Merge The masked edit control is essentially an edit field control that lets
Module end users enter information in a specified format.
Path edit Basic MSI, Merge A path edit control is used in conjunction with a directory combo
Module control and a directory list control to create a browse dialog. The path
edit displays the complete path that is assembled from selections that
the end user makes in the directory combo and directory list, along
with or instead of edits that the end user makes.
Progress bar Basic MSI, A progress bar is a dynamic, graphical bar that fills up in response to
InstallScript, control events.
InstallScript MSI,
InstallScript Object,
Merge Module
Push button Basic MSI, A push button control is a button that carries out a command when an
InstallScript, end user clicks it.
InstallScript MSI,
InstallScript Object,
Merge Module
Radio button Basic MSI, A radio button control is one of two or more mutually exclusive
InstallScript, options that end users can select. A radio button must be inserted into
InstallScript MSI, a radio button group; it functions as part of that control.
InstallScript Object,
Merge Module
Radio button group Basic MSI, A radio button group control is a container for radio button controls. A
InstallScript, radio button group and its radio buttons behave as a single control.
InstallScript MSI,
InstallScript Object,
Merge Module
Scrollable text Basic MSI, Merge A scrollable text control displays a long string of text that cannot fit on
Module the dialog; the control includes scroll bars that enable end users to
scroll through the text. The LicenseAgreement dialog is an example of
a dialog that typically contains a scrollable text control.
Selection tree Basic MSI, A selection tree is a special control that lets end users change the
InstallScript, selection state of your features, like in the CustomSetup dialog.
InstallScript MSI,
InstallScript Object,
Merge Module
Volume cost list Basic MSI, Merge A volume cost list control displays the disk space requirements that
Module are associated with each volume or drive.
Volume select combo Basic MSI, Merge A volume select combo control enables the end user to select from an
Module alphabetical list of volumes, or drives.
Billboard Control
InstallShield 2020
• Basic MSI
• Merge Module
If your installation includes a Setup.exe launcher, you can have the launcher display billboards during the file transfer
process; this is an alternative to the billboard control, which is a Windows Installer control. This Setup.exe billboard support is
available in Basic MSI, InstallScript, and InstallScript MSI installations. To learn more about this type of billboard, see
Displaying Billboards.
A billboard control is used to display data that can be updated in response to control events. Billboards can contain other
controls for displaying this information, but they must be static controls—including text, bitmaps, and icons—that are not
linked to a Windows Installer property. You can use a billboard, for example, to display the progress of a protracted custom
action.
Billboards are not fully supported in the Dialog Editor. In order to have the billboard interact with Windows Installer actions
and display other controls, you must make changes to the Billboard and BBControl tables in your project; you can use
the Direct Editor view to modify these tables.
When you select a billboard control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Setting Description
Name Enter a name for this billboard. The name must be unique among all of the
controls in your project.
Base Text Style This font style is used for the control’s label if you specify nothing for the Text
Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True.
Clicking the cancel control has the same effect as pressing the ESC key or clicking
the Close button on the title bar. The Cancel or Finish button is usually the cancel
control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog
that contains this control.
Context Help This setting is reserved for future use. Windows Installer does not currently
support launching context-sensitive help topics from the installation.
Default If this is the only control on the dialog that you want to be the default control,
which means that it is activated when the end user presses the ENTER key, select
True. The Next or OK button is usually the default control.
Height Specify the height of the control in Windows Installer user interface units (1/12 of
the height of the system font).
Left Specify the distance from the left edge of the dialog to the start of the control in
installer units (1/12 of the height of the system font).
Tab Index Assign an integer that—along with the other controls on this dialog but excluding
controls such as static text—specifies the order in which each control on the
dialog receives focus when the end user presses the TAB key. The lowest tab index
that you can use is the number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates
that the control receives focus; False indicates that the control does not receive
focus.
Setting Description
Text This setting contains the text that is used for the initial value of the billboard’s
control (see the BBControl table).
When you type a value for this setting, you are creating a string entry and setting
its initial value for all of the languages that are currently in the project. As an
alternative to typing a new value, you can click the ellipsis button (...) in this
setting to select an existing string. For more information, see Using String Entries
in InstallShield.
If the billboard’s control contains a bitmap or icon, this value must be a foreign
key into the Binary table to the file that is initially displayed on the control.
Text Style Select the font style, size, and color (if available) in which you want the billboard’s
label to be displayed. Leaving the value as <Default> displays the font that is
contained in the DefaultUIFont property.
Tooltip Enter the text that you want to be displayed when the end user places the mouse
pointer over the control.
When you type a value for this setting, you are creating a string entry and setting
its initial value for all of the languages that are currently in the project. As an
alternative to typing a new value, you can click the ellipsis button (...) in this
setting to select an existing string. For more information, see Using String Entries
in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer
units (1/12 of the height of the system font).
Visible True means that the control is visible, and False means that it is hidden. You can
also make the control visible by editing its condition in the Behavior area for the
dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of
the height of the system font).
See Also
Billboard Table (Windows Installer Help Library)
Billboard Table (Windows Installer Help Library)
BBControl Table (Windows Installer Help Library)
BBControl Table (Windows Installer Help Library)
Dialog Controls
Bitmap Control
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
When you select a bitmap control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Name Basic MSI, Enter a name for this bitmap. The name must be unique among all of the
InstallScript, controls in your project.
InstallScript MSI,
InstallScript Object,
Merge Module
Cancel Basic MSI, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript MSI, key or clicking the Close button on the title bar. The Cancel or Finish button
InstallScript Object, is usually the cancel control.
Merge Module
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not currently
Module support launching context-sensitive help topics from the installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in Visual
InstallScript Object, C++. You should not change the control identifiers for any of the controls
Merge Module that are included with a dialog by default.
Default Basic MSI, Select True if this is the only control on the dialog that you want to be the
InstallScript, default control, which means that it will be activated when the end user
InstallScript MSI, presses the ENTER key. The Next or OK button is usually the default control.
InstallScript Object,
Merge Module
File Name Basic MSI, Enter the path to and the name of the image file that you want to use for
InstallScript, this control, or click the ellipsis button (...) in this setting to browse to it.
InstallScript MSI, InstallShield adds the file to your release at build time. The file must be
InstallScript Object, stored as a binary resource in the installation.
Merge Module
Height Basic MSI, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript, in Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
Merge Module
the height of the control in dialog units.
Left Basic MSI, Specify the distance from the left edge of the dialog to the start of the
InstallScript, control in installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog box.
Styles InstallScript MSI,
InstallScript Object,
Merge Module
Stretch to Fit Basic MSI, Merge If you want the image to be resized to fill the area of the control, select True.
Module
To have the image centered if it is smaller than the control or to have the
image cropped if it is bigger than the control, select False.
Sunken Basic MSI, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript, select True. To use the default visual style for the control, select False.
InstallScript MSI,
InstallScript Object,
Merge Module
Tab Index Basic MSI, Assign an integer that—along with the other controls on this dialog but
InstallScript, excluding controls such as static text—specifies the order in which each
InstallScript MSI, control on the dialog receives focus when the end user presses the TAB key.
InstallScript Object, The lowest tab index that you can use is the number 0.
Merge Module
Tab Stop Basic MSI, Indicate whether this control receives focus within the tab order. True
InstallScript, indicates that the control receives focus; False indicates that the control
InstallScript MSI, does not receive focus.
InstallScript Object,
Merge Module
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more information,
see Using String Entries in InstallShield.
Top Basic MSI, Specify the distance from the top of the dialog to the top of the control in
InstallScript, installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Visible Basic MSI, True means that the control is visible, and False means that it is hidden. You
InstallScript, can also make the control visible by editing its condition in the Behavior
InstallScript MSI, area for the dialog.
InstallScript Object,
Merge Module
Width Basic MSI, For Basic MSI and Merge Module projects: Specify the width of the control in
InstallScript, Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
Merge Module
the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
A check box control displays a check box that end user can select or clear.
When you select a check box control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Project • (For Basic MSI and Merge Module projects) When you first draw this type of control on a dialog, InstallShield prompts
you for the name of a Windows Installer property. InstallShield uses the name that you enter as the value for this control’s
Property setting. At run time, the installation sets the value of this property based on the end user’s selection. For more details,
see Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties.
Name Basic MSI, InstallScript, Enter a name for this check box. The name must be unique among all of the
InstallScript MSI, controls in your project.
InstallScript Object,
Merge Module
Base Text Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Style Module Text Style setting.
This setting is enabled if Text is selected for the Control Style setting.
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish button
Merge Module is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not currently
Module support launching context-sensitive help topics from the installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in Visual
InstallScript Object C++. You should not change the control identifiers for any of the controls
that are included with a dialog by default.
Control Style Basic MSI, Merge Specify whether this control is marked with a text label, an icon, or a
Module bitmap.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
Enabled Basic MSI, InstallScript, Indicate whether the control is enabled. True means that this control is
InstallScript MSI, available (the end user can interact with it). False means that it is not
InstallScript Object, available (grayed out).
Merge Module
File Name Basic MSI, Merge This setting is enabled if you select Bitmap or Icon for the Control Style
Module setting.
Enter the path to and the name of the image file that you want to use for
this control, or click the ellipsis button (...) in this setting to browse to it.
InstallShield adds the file to your release at build time. The file must be
stored as a binary resource in the installation.
This setting is enabled if Bitmap or Icon are selected for the Control Style
setting.
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
the height of the control in dialog units.).
Icon Size Basic MSI, Merge Assuming that your icon file has more than one resource, specify the size of
Module the image that you want to use for the control. The Use first image option
causes the first image in the file to be displayed and makes it stretch to fit
the size of the control, regardless of what you specify for the Stretch to Fit
setting.
This setting is enabled if Bitmap or Icon are selected for the Control Style
setting.
Indirect Basic MSI, InstallScript, If the property that is associated with this control is referenced indirectly,
Property InstallScript MSI, select True; otherwise, select False.
InstallScript Object,
When True is selected for an indirect property is set to True, Windows
Merge Module
Installer resolves the referenced property at run time. For example, this
check box might use the property _BROWSE, whose value is INSTALLDIR. If
you select True for the Indirect Property setting, the value of _BROWSE will
be the current value of the INSTALLDIR property. If you select False for the
Indirect Property setting, the value of _BROWSE will contain the string
INSTALLDIR.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog box.
Styles InstallScript MSI,
InstallScript Object
Property Basic MSI, Merge Enter the name of a property that is set when an end user selects this check
Module box. This property can be unique to this control; it does not need to be
present in the Property Manager view.
To set a default value for this control, make sure the property is a public
property by giving it a name that contains only uppercase letters, use the
Property Manager view to add the public property, and then assign to it the
Value setting.
Property Is Basic MSI, InstallScript, If the property for this control (specified in the Property setting) has an
Integer InstallScript MSI, integer value, select True. If the property’s value is a string, select False.
InstallScript Object,
Merge Module
Push Button Basic MSI, InstallScript, To turn this check box into a push button control, select True; otherwise,
InstallScript MSI, select False.
InstallScript Object,
Merge Module
Right-Aligned Basic MSI, InstallScript, The default value of False aligns the text to the left of the control. Set it to
InstallScript MSI, True to align the text to the right.
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, InstallScript, For English and other languages that are written from left to right, select
InstallScript MSI, False. For Hebrew and those languages that are read from right to left,
InstallScript Object, select True.
Merge Module
Stretch to Fit Basic MSI, Merge If you want the image to be resized to fill the area of the control, select
Module True.
To have the image centered if it is smaller than the control or to have the
image cropped if it is bigger than the control, select False.
This setting is enabled if Bitmap or Icon are selected for the Control Style
setting.
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB key.
Merge Module The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the control
InstallScript Object, does not receive focus.
Merge Module
Text Basic MSI, InstallScript, This setting contains the text that is used for the control’s label.
InstallScript MSI,
When you type a value for this setting, you are creating a string entry and
InstallScript Object,
setting its initial value for all of the languages that are currently in the
Merge Module
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more information,
see Using String Entries in InstallShield.
This setting is enabled if Text is selected for the Control Style setting.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays the
font that is contained in the DefaultUIFont property.
This setting is enabled if Text is selected for the Control Style setting.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more information,
see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control in
InstallScript MSI, installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Value Basic MSI, Merge When the check box is selected, the property that is specified for the
Module Property setting is set to this value.
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
A combo box control is a box that contains a drop-down list of predefined values; the box is also an edit field in which an
end user can enter a value.
When you select a combo box control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Project • (For Basic MSI and Merge Module projects) When you first draw this type of control on a dialog, InstallShield prompts
you for the name of a Windows Installer property that identifies all of the items that belong to this combo box. InstallShield
uses the name that you enter as the value for this control’s Property setting. At run time, the installation sets the value of this
property based on the end user’s selection. For more details, see Working with Windows Installer and Advanced UI or Suite/
Advanced UI Properties. (Note that Windows Installer combo boxes allow the end user to select only a single item.)
Name Basic MSI, InstallScript, Enter a name for this combo box. The name must be unique among all of
InstallScript MSI, the controls in your project.
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge Module This font style is used for the control’s label if you specify nothing for the
Text Style setting.
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish
Merge Module button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Code Page Basic MSI, Merge Module If you want the control to use fonts from the code page that is defined in
the installation’s package, select Database. If you want the control to use
fonts from the target system’s default code page, select User’s System.
Context Help Basic MSI, Merge Module This setting is reserved for future use. Windows Installer does not
currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
Drop-Down List Basic MSI, InstallScript, If you want the control to be a drop-down list, select True. If you want the
InstallScript MSI, control to be an editable combo box, select False.
InstallScript Object,
Merge Module
Enabled Basic MSI, InstallScript, Indicate whether the control is enabled. True means that this control is
InstallScript MSI, available (the end user can interact with it). False means that it is not
InstallScript Object, available (grayed out).
Merge Module
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of the
InstallScript Object, system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Indirect Basic MSI, InstallScript, If the property that is associated with this control is referenced
Property InstallScript MSI, indirectly, select True; otherwise, select False.
InstallScript Object,
When True is selected for an indirect property is set to True, Windows
Merge Module
Installer resolves the referenced property at run time. For example, this
check box might use the property _BROWSE, whose value is INSTALLDIR. If
you select True for the Indirect Property setting, the value of _BROWSE will
be the current value of the INSTALLDIR property. If you select False for
the Indirect Property setting, the value of _BROWSE will contain the
string INSTALLDIR.
Items Basic MSI, InstallScript, To specify the options that you want to be listed in this control, click the
InstallScript MSI, ellipsis button (...) in this setting; this opens the List Items dialog box.
InstallScript Object,
To add a new item to the list, click the Add button on the List Items dialog
Merge Module
box. For each item, you must enter the text that is displayed in the
combo box, and a value, which is the value that is assigned to the
property if this item is selected.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Left Scrollbar Basic MSI, InstallScript, If you want the arrow and vertical scrollbar to be displayed on the left
InstallScript MSI, side of the control, select True. This option should be selected only when
InstallScript Object, True is selected for the Right-to-Left setting.
Merge Module
Max. Length Basic MSI, Merge Module Specify how many characters the end user can enter in the combo box.
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Property Basic MSI, Merge Module Enter the name of a property that is set when the end user enters a value
into or selects one from this combo box. This property can be unique to
this control; it does not need to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public
property by giving it a name that contains only uppercase letters, use the
Property Manager view to add the public property, and then assign to it
the value of the default selection (specified in the Items setting).
Property Is Basic MSI, InstallScript, If the property for this control (specified in the Property setting) has an
Integer InstallScript MSI, integer value, select True. If the property’s value is a string, select False.
InstallScript Object,
Make sure that all of the values in the Item setting are either integers or
Merge Module
strings, depending on the value that you select in the Property Is Integer
setting.
Right-Aligned Basic MSI, InstallScript, The default value of False aligns the text to the left of the control. Set it to
InstallScript MSI, True to align the text to the right.
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, InstallScript, For English and other languages that are written from left to right, select
InstallScript MSI, False. For Hebrew and those languages that are read from right to left,
InstallScript Object, select True.
Merge Module
Sorted Basic MSI, InstallScript, Selecting True causes the items in the combo box to be sorted
InstallScript MSI, alphabetically. A value of False makes them retain the order that you set
InstallScript Object, for each item in the List Items dialog box.
Merge Module
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB
Merge Module key. The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the control
InstallScript Object, does not receive focus.
Merge Module
Text Style Basic MSI, Merge Module Select the font style, size, and color (if available) in which you want the
control’s label to be displayed. Leaving the value as <Default> displays
the font that is contained in the DefaultUIFont property.
Tooltip Basic MSI, Merge Module Enter the text that you want to be displayed when the end user places
the mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control in
InstallScript MSI, installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of the
InstallScript Object, system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Dialog Controls
Dialog Control
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
When you select a dialog in the Dialog Editor of the Dialogs view, InstallShield displays the following settings in the right
pane.
Unlike its controls, you cannot change the name of a dialog in the Dialog Editor. To change the name, right-click the dialog
in the Dialogs view and click Rename.
Caption Basic MSI, Merge Module Specify the name that you want to use as the title for the dialog.
When you type a value for this setting, you are creating a string entry
and setting its initial value for all of the languages that are currently in
the project. As an alternative to typing a new value, you can click the
ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Comment Basic MSI, Merge Module Enter comments for the dialog. Your comments are saved in the project
file for your reference and are not used in the installation at any time.
Custom Palette Basic MSI, Merge Module A custom palette is necessary only if the dialog contains images that use
a color palette that is different from the default one that is created by
Windows Installer. If the dialog does not contain any images that use a
different color palette, leave this value as False.
Error Dialog Basic MSI, Merge Module If this dialog serves as an error dialog, select True.
Height Basic MSI, InstallScript, Specify the height of the dialog in installer units (1/12 of the height of
InstallScript MSI, the system font).
InstallScript Object,
Merge Module
Keep Modeless Basic MSI, Merge Module When this value is set to True and this dialog is spawned through a
DoAction event, all other dialogs remain. If the Keep Modeless setting is
False in this case, the other dialogs are not displayed.
Left Basic MSI, InstallScript, Specify the percentage from the left edge of the screen where you want
InstallScript MSI, the dialog to be placed. A value of 50 centers the dialog horizontally.
InstallScript Object,
This value is ignored if this dialog is part of an installation wizard, and
Merge Module
the previous dialog was in a different location or was moved by the end
user.
Left Scrollbar Basic MSI, InstallScript, Select True to set the scroll bar, if present, at the left side of the dialog.
InstallScript MSI, The default value, False, keeps it at the right side.
InstallScript Object,
If you want the vertical scrollbar, if present, to be displayed on the left
Merge Module
side of the dialog, select True. The default value, False, keeps the
scrollbar on the right side.
Minimize Basic MSI, InstallScript, True means that the end user can minimize this dialog. False means that
InstallScript MSI, the option is not present on the title bar.
InstallScript Object,
Merge Module
Modal Basic MSI, InstallScript, Select True if this dialog is part of the installation wizard and no other
InstallScript MSI, dialogs should be placed on top of it.
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Resource InstallScript, This read-only setting shows the dialog’s resource ID—the unique
Identifier InstallScript MSI, numeric identifier for the dialog.
InstallScript Object
Right-Aligned Basic MSI, InstallScript, The default value of False aligns the caption to the left of the control. Set
InstallScript MSI, it to True to align the caption to the right.
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, InstallScript, For English and other languages that are written from left to right, select
InstallScript MSI, False. For Hebrew and those languages that are read from right to left,
InstallScript Object, select True.
Merge Module
Top Basic MSI, InstallScript, Specify the percentage from the top of the screen where you want the
InstallScript MSI, dialog to be placed. A value of 50 centers the dialog vertically.
InstallScript Object,
This value is ignored if this dialog is part of an installation wizard, and
Merge Module
the previous dialog was in a different location or was moved by the end
user.
Track Disk Space Basic MSI, Merge Module Select True if this dialog has a control that alerts the end user that a
drive is out of space or that checks the value of the OutOfDiskSpace
property before performing some action.
Visible Basic MSI, InstallScript, True means that the dialog is visible, and False means that it is hidden.
InstallScript MSI,
InstallScript Object,
Merge Module
Width Basic MSI, InstallScript, Specify the width of the dialog in installer units (1/12 of the height of the
InstallScript MSI, system font).
InstallScript Object,
Merge Module
See Also
Dialog Controls
• Basic MSI
• Merge Module
A directory combo is used in conjunction with a directory list and a path edit control to create a browse dialog. The
directory combo displays the list of drives mapped on the current system.
When you first draw a directory combo on a dialog, InstallShield prompts you for the name of a Windows Installer property.
This property should be the same for the accompanying directory list and path edit. At run time, the installation sets the
value of this property based on the end user’s selection. For more details, see Working with Windows Installer and
Advanced UI or Suite/Advanced UI Properties.
When you select a directory combo control in a dialog of the Dialogs view, InstallShield displays the following settings in
the right pane.
Setting Description
Name Enter a name for this directory combo. The name must be unique among all of the
controls in your project.
Base Text Style This font style is used for the control’s text if you specify nothing for the Text Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True. Clicking the
cancel control has the same effect as pressing the ESC key or clicking the Close button on
the title bar. The Cancel or Finish button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog that
contains this control.
Context Help This setting is reserved for future use. Windows Installer does not currently support
launching context-sensitive help topics from the installation.
Setting Description
Default If this is the only control on the dialog that you want to be the default control, which
means that it is activated when the end user presses the ENTER key, select True. The Next
or OK button is usually the default control.
Enabled Indicate whether the control is enabled. True means that this control is available (the end
user can interact with it). False means that it is not available (grayed out).
Height Specify the height of the control in Windows Installer user interface units (1/12 of the
height of the system font).
Indirect Property If the property that is associated with this control is referenced indirectly, select True;
otherwise, select False.
When True is selected for an indirect property is set to True, Windows Installer resolves
the referenced property at run time. For example, this check box might use the property
_BROWSE, whose value is INSTALLDIR. If you select True for the Indirect Property setting,
the value of _BROWSE will be the current value of the INSTALLDIR property. If you select
False for the Indirect Property setting, the value of _BROWSE will contain the string
INSTALLDIR.
Left Specify the distance from the left edge of the dialog to the start of the control in installer
units (1/12 of the height of the system font).
Left Scrollbar If you want the arrow and vertical scrollbar to be displayed on the left side of the control,
select True. This option should be selected only when True is selected for the Right-to-
Left setting.
Property Enter the name of a property that is set when an end user end user selects a value from
this directory combo. This control populates the first part of the path that is displayed in
the directory list, so you must use the same property for the directory combo, the
directory list, and path edit when using them together on a browse dialog. This property
can be unique to this control; it does not need to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public property by
giving it a name that contains only uppercase letters, use the Property Manager view to
add the public property, and then assign to it the value of the default selection.
Right-Aligned The default value of False aligns the text to the left of the control. Set it to True to align the
text to the right.
Right-to-Left For English and other languages that are written from left to right, select False. For
Hebrew and those languages that are read from right to left, select True.
Show CD-ROM To include CD-ROM volumes in the directory combo, select True.
Show Fixed To include hard drives in the directory combo, select True.
Setting Description
Show Floppy To include floppy drives in the directory combo, select True.
Show RAMDisk To include RAM volumes in the directory combo, select True.
Show Remote To include mapped network drives in the directory combo, select True.
Show Removable To include removable drives in the directory combo, select True.
Sunken To give the control’s edges a recessed, three-dimensional appearance, select True. To use
the default visual style for the control, select False.
Tab Index Assign an integer that—along with the other controls on this dialog but excluding controls
such as static text—specifies the order in which each control on the dialog receives focus
when the end user presses the TAB key. The lowest tab index that you can use is the
number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates that the
control receives focus; False indicates that the control does not receive focus.
Text This setting contains the text that is used for the control’s text.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a
new value, you can click the ellipsis button (...) in this setting to select an existing string.
For more information, see Using String Entries in InstallShield.
Text Style Select the font style, size, and color (if available) in which you want the control’s label to
be displayed. Leaving the value as <Default> displays the font that is contained in the
DefaultUIFont property.
Tooltip Enter the text that you want to be displayed when the end user places the mouse pointer
over the control.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a
new value, you can click the ellipsis button (...) in this setting to select an existing string.
For more information, see Using String Entries in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer units
(1/12 of the height of the system font).
Visible True means that the control is visible, and False means that it is hidden. You can also
make the control visible by editing its condition in the Behavior area for the dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of the
height of the system font).
See Also
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
Dialog Controls
• Basic MSI
• Merge Module
A directory list is used in conjunction with a directory combo and a path edit control to create a browse dialog. The
directory list displays the folders below the drive that is selected in the directory combo control, and it populates the value
of the path edit control.
When you first draw a directory list on a dialog, InstallShield prompts you for the name of a Windows Installer property.
This property should be the same for the accompanying directory combo and path edit. At run time, the installation sets
the value of this property based on the end user’s selection. For more details, see Working with Windows Installer and
Advanced UI or Suite/Advanced UI Properties.
When you select a directory list control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Setting Description
Name Enter a name for this directory list. The name must be unique among all of the controls in
your project.
Base Text Style This font style is used for the control’s label if you specify nothing for the Text Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True. Clicking the
cancel control has the same effect as pressing the ESC key or clicking the Close button on
the title bar. The Cancel or Finish button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog that
contains this control.
Context Help This setting is reserved for future use. Windows Installer does not currently support
launching context-sensitive help topics from the installation.
Default If this is the only control on the dialog that you want to be the default control, which
means that it is activated when the end user presses the ENTER key, select True. The Next
or OK button is usually the default control.
Enabled Indicate whether the control is enabled. True means that this control is available (the end
user can interact with it). False means that it is not available (grayed out).
Setting Description
Height Specify the height of the control in Windows Installer user interface units (1/12 of the
height of the system font).
Indirect Property If the property that is associated with this control is referenced indirectly, select True;
otherwise, select False.
When True is selected for an indirect property is set to True, Windows Installer resolves the
referenced property at run time. For example, this check box might use the property
_BROWSE, whose value is INSTALLDIR. If you select True for the Indirect Property setting,
the value of _BROWSE will be the current value of the INSTALLDIR property. If you select
False for the Indirect Property setting, the value of _BROWSE will contain the string
INSTALLDIR.
Left Specify the distance from the left edge of the dialog to the start of the control in installer
units (1/12 of the height of the system font).
Left Scrollbar If you want the arrow and vertical scrollbar to be displayed on the left side of the control,
select True. This option should be selected only when True is selected for the Right-to-Left
setting.
Property Enter the name of a property that is set when an end user selects a value from this
directory list. This control populates the path that is displayed in the path edit and
changes depending on the selection in the directory combo, so you must use the same
property for all three controls when using them together on a browse dialog. This property
can be unique to this control; it does not need to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public property by giving
it a name that contains only uppercase letters, use the Property Manager view to add the
public property, and then assign to it the value of the default selection.
Right-Aligned The default value of False aligns the text to the left of the control. Set it to True to align the
text to the right.
Right-to-Left For English and other languages that are written from left to right, select False. For Hebrew
and those languages that are read from right to left, select True.
Sunken To give the control’s edges a recessed, three-dimensional appearance, select True. To use
the default visual style for the control, select False.
Tab Index Assign an integer that—along with the other controls on this dialog but excluding controls
such as static text—specifies the order in which each control on the dialog receives focus
when the end user presses the TAB key. The lowest tab index that you can use is the
number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates that the
control receives focus; False indicates that the control does not receive focus.
Setting Description
Text This setting contains the text that is used for the control’s text.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a
new value, you can click the ellipsis button (...) in this setting to select an existing string.
For more information, see Using String Entries in InstallShield.
Text Style Select the font style, size, and color (if available) in which you want the control’s label to be
displayed. Leaving the value as <Default> displays the font that is contained in the
DefaultUIFont property.
Tooltip Enter the text that you want to be displayed when the end user places the mouse pointer
over the control.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a
new value, you can click the ellipsis button (...) in this setting to select an existing string.
For more information, see Using String Entries in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer units (1/
12 of the height of the system font).
Visible True means that the control is visible, and False means that it is hidden. You can also make
the control visible by editing its condition in the Behavior area for the dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of the height
of the system font).
See Also
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
An edit field control is a text box in which end users can enter a string or an integer.
When you select an edit field control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Project • (For Basic MSI and Merge Module projects) When you first draw this type of control on a dialog, InstallShield prompts
you for the name of a Windows Installer property. InstallShield uses the name that you enter as the value for this control’s
Property setting. At run time, the installation sets the value of this property based on the end user’s selection. For more details,
see Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties.
Name Basic MSI, Enter a name for this edit field. The name must be unique among all of
InstallScript, the controls in your project.
InstallScript MSI,
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Module Text Style setting.
Cancel Basic MSI, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript MSI, key or clicking the Close button on the title bar. The Cancel or Finish
InstallScript Object, button is usually the cancel control.
Merge Module
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control Identifier InstallScript, This setting contains a numeric identifier for the control that is unique
InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, If this is the only control on the dialog that you want to be the default
InstallScript, control, which means that it is activated when the end user presses the
InstallScript MSI, ENTER key, select True. The Next or OK button is usually the default
InstallScript Object, control.
Merge Module
Enabled Basic MSI, Indicate whether the control is enabled. True means that this control is
InstallScript, available (the end user can interact with it). False means that it is not
InstallScript MSI, available (grayed out).
InstallScript Object,
Merge Module
Height Basic MSI, For Basic MSI and Merge Module projects: Specify the height of the
InstallScript, control in Windows Installer user interface units (1/12 of the height of
InstallScript MSI, the system font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Merge Module
Specify the height of the control in dialog units.
Indirect Property Basic MSI, Merge If the property that is associated with this control is referenced
Module indirectly, select True; otherwise, select False.
Left Basic MSI, Specify the distance from the left edge of the dialog to the start of the
InstallScript, control in installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Left Scrollbar Basic MSI, If you want the arrow and vertical scrollbar to be displayed on the left
InstallScript, side of the control, select True. This option should be selected only
InstallScript MSI, when True is selected for the Right-to-Left setting.
InstallScript Object,
Merge Module
Max. Length Basic MSI, Merge Specify the maximum number of characters that the end user can enter
Module in this control.
MultiLine Basic MSI, If you want this control to be multiline control, select True.
InstallScript,
InstallScript MSI,
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Password Basic MSI, If you want this control to behave like a password control, only showing
InstallScript, an asterisk (*) in place of each character, select True. If you want this
InstallScript MSI, control to behave like a normal edit field control, select False.
InstallScript Object,
Merge Module
Property Basic MSI, Merge Enter the name of a property that is set when an end user enters text in
Module this control. This property can be unique to this control; it does not need
to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public
property by giving it a name that contains only uppercase letters, use
the Property Manager view to add the public property, and then assign
to it the value of the default selection.
Property Is Integer Basic MSI, Merge If the property for this control (specified in the Property setting) has an
Module integer value, select True. If the property’s value is a string, select False.
Right-Aligned Basic MSI, The default value of False aligns the text to the left of the control. Set it
InstallScript, to True to align the text to the right.
InstallScript MSI,
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, For English and other languages that are written from left to right, select
InstallScript, False. For Hebrew and those languages that are read from right to left,
InstallScript MSI, select True.
InstallScript Object,
Merge Module
Sunken Basic MSI, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript, select True. To use the default visual style for the control, select False.
InstallScript MSI,
InstallScript Object,
Merge Module
Tab Index Basic MSI, Assign an integer that—along with the other controls on this dialog but
InstallScript, excluding controls such as static text—specifies the order in which each
InstallScript MSI, control on the dialog receives focus when the end user presses the TAB
InstallScript Object, key. The lowest tab index that you can use is the number 0.
Merge Module
Tab Stop Basic MSI, Indicate whether this control receives focus within the tab order. True
InstallScript, indicates that the control receives focus; False indicates that the control
InstallScript MSI, does not receive focus.
InstallScript Object,
Merge Module
Text Basic MSI, Merge This setting contains the text that is used in the control.
Module
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays
the font that is contained in the DefaultUIFont property.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places
Module the mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, Merge Specify the distance from the top of the dialog to the top of the control
Module in installer units (1/12 of the height of the system font).
Visible Basic MSI, Merge True means that the control is visible, and False means that it is hidden.
Module You can also make the control visible by editing its condition in the
Behavior area for the dialog.
Width Basic MSI, Merge Specify the width of the control in Windows Installer user interface units
Module (1/12 of the height of the system font).
See Also
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
A group box can be used to enclose various controls in one area. To move and align the group box along with any individual
control that it encloses, hold the CTRL key as you select the group box and each control that you want to select. A group
box also provides a label that you can use to express the relationship between the controls that are contained within it.
When you select a group box control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Name Basic MSI, InstallScript, Enter a name for this group box. The name must be unique among all of
InstallScript MSI, the controls in your project.
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Module Text Style setting.
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish
Merge Module button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
Enabled Basic MSI, InstallScript, Indicate whether the control is enabled. True means that this control is
InstallScript MSI, available (the end user can interact with it). False means that it is not
InstallScript Object, available (grayed out).
Merge Module
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of the
InstallScript Object, system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Right-Aligned Basic MSI, InstallScript, The default value of False aligns the text to the left of the control. Set it to
InstallScript MSI, True to align the text to the right.
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, InstallScript, For English and other languages that are written from left to right, select
InstallScript MSI, False. For Hebrew and those languages that are read from right to left,
InstallScript Object, select True.
Merge Module
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB
Merge Module key. The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the control
InstallScript Object, does not receive focus.
Merge Module
Text Basic MSI, InstallScript, This setting contains the text that is used for the group box label.
InstallScript MSI,
When you type a value for this setting, you are creating a string entry and
InstallScript Object,
setting its initial value for all of the languages that are currently in the
Merge Module
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays
the font that is contained in the DefaultUIFont property.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places
Module the mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control in
InstallScript MSI, installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of the
InstallScript Object, system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Dialog Controls
Hyperlink Control
InstallShield 2020
• Basic MSI
• Merge Module
To learn how to add an HTML control to a dialog in an InstallScript project or in an InstallScript MSI project, see Using an HTML
Control on a Dialog.
Use the hyperlink control to add a hyperlink to a dialog in your project. The hyperlink control displays an HTML link;
clicking the link at run time opens a page in the default browser on the target system.
Important • Windows Installer 5 and later include support for the hyperlink control. If this control is used on a dialog that is
displayed on a system that has an earlier version of Windows Installer, run-time error 2885 occurs, and the installation aborts.
Therefore, if you want to use the hyperlink control on a dialog but your installation targets systems that have Windows
Installer 4.5 or earlier, it is recommended that you include two versions of the dialog in your project: one with the hyperlink
control, and one without it. Add conditions to the dialogs to show or hide them, depending on the version of Windows Installer
that is present.
Following is a sample condition that you could use for the dialog that contains the hyperlink control:
Following is a sample condition that you could use for the alternate dialog that does not contain any hyperlink control:
When you select a hyperlink control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Setting Description
Name Enter a name for this hyperlink control. The name must be unique among all of the controls in
your project.
Base Text Style This font style is used for the control’s label if you specify nothing for the Text Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True. Clicking the
cancel control has the same effect as pressing the ESC key or clicking the Close button on the
title bar. The Cancel or Finish button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog that contains
this control.
Code Page If you want the control to use fonts from the code page that is defined in the installation’s
package, select Database. If you want the control to use fonts from the target system’s default
code page, select User’s System.
Context Help This setting is reserved for future use. Windows Installer does not currently support launching
context-sensitive help topics from the installation.
Default If this is the only control on the dialog that you want to be the default control, which means that
it is activated when the end user presses the ENTER key, select True. The Next or OK button is
usually the default control.
Setting Description
Enabled Indicate whether the control is enabled. True means that this control is available (the end user
can interact with it). False means that it is not available (grayed out).
Format as Bytes If you want the installation to attempt to display the value that is entered in the Text setting in
bytes, select True. If you select True, the Text setting must contain only a number, without the
unit. Then, at run time, it is divided by 512 and displayed as the correct number of kilobytes,
megabytes, or gigabytes, depending on the size.
Height Specify the height of the control in Windows Installer user interface units (1/12 of the height of
the system font).
Left Specify the distance from the left edge of the dialog to the start of the control in installer units
(1/12 of the height of the system font).
No Prefix If the Text setting contains an ampersand that should be displayed as an ampersand character
(&), select True.
If you are using the ampersand in the Text setting to indicate that the letter that follows the
ampersand should be underlined (for example, &Click would be displayed as Click), select
False.
No Text Wrap Indicate whether you want to allow the text to wrap in this control. If you select True and the
text expands beyond the width of the text area, the end of the string is cut off and replaced with
an ellipsis button (...). Otherwise, the text wraps and can extend beyond the height of the text
area, if it is not long enough.
Property Enter the name of a property that is set when an end user clicks this hyperlink. This property
can be unique to this control; it does not need to be present in the Property Manager view.
Right-Aligned The default value of False aligns the text to the left of the control. Set it to True to align the text
to the right.
Right-to-Left For English and other languages that are written from left to right, select False. For Hebrew and
those languages that are read from right to left, select True.
Sunken To give the control’s edges a recessed, three-dimensional appearance, select True. To use the
default visual style for the control, select False.
Tab Index Assign an integer that—along with the other controls on this dialog but excluding controls such
as static text—specifies the order in which each control on the dialog receives focus when the
end user presses the TAB key. The lowest tab index that you can use is the number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates that the control
receives focus; False indicates that the control does not receive focus.
Setting Description
Text This setting contains the text that is used for the control. Use HTML markup in this setting for
your hyperlink. Following is a sample entry for this setting:
To learn about the latest offerings from ABC Company, visit the <a href="http://
www.abccompany.com">ABC Company Web site</a>.
For this sample, the ABC Company Web site text is displayed as a hyperlink that points to the
http://www.abccompany.com Web site.
Note that the only protocol that is supported for the hyperlink is HTML.
When you type a value for this setting, you are creating a string entry and setting its initial value
for all of the languages that are currently in the project. As an alternative to typing a new value,
you can click the ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Select the font style, size, and color (if available) in which you want the control’s label to be
displayed. Leaving the value as <Default> displays the font that is contained in the
DefaultUIFont property.
Tooltip Enter the text that you want to be displayed when the end user places the mouse pointer over
the control.
When you type a value for this setting, you are creating a string entry and setting its initial value
for all of the languages that are currently in the project. As an alternative to typing a new value,
you can click the ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer units (1/12 of
the height of the system font).
Transparent If you want the background to show through this control, select True.
Note that you may want to avoid making this control transparent if you are placing it on top of a
colored bitmap. The text may not be visible if end users change the color scheme of their
display. For example, the text in this control may become invisible if an end user sets the high-
contrast parameter for accessibility reasons.
Visible True means that the control is visible, and False means that it is hidden. You can also make the
control visible by editing its condition in the Behavior area for the dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of the height of
the system font).
See Also
Dialog Controls
Icon Control
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
When you select an icon control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Name Basic MSI, InstallScript, Enter a name for this icon. The name must be unique among all of the
InstallScript MSI, controls in your project.
InstallScript Object,
Merge Module
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the
InstallScript Object, ESC key or clicking the Close button on the title bar. The Cancel or
Merge Module Finish button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control Identifier InstallScript, This setting contains a numeric identifier for the control that is unique
InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
File Name Basic MSI, InstallScript, Enter the path to and the name of the icon file that you want to use for
InstallScript MSI, this control, or click the ellipsis button (...) in this setting to browse to it.
InstallScript Object, InstallShield adds the file to your release at build time. The file must be
Merge Module stored as a binary resource in the installation.
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of
InstallScript Object, the system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Icon Size Basic MSI, InstallScript, Assuming that your icon file has more than one resource, specify the
InstallScript MSI, size of the image that you want to use for the control. The Use first
InstallScript Object, image option causes the first image in the file to be displayed and
Merge Module makes it stretch to fit the size of the control, regardless of what you
specify for the Stretch to Fit setting.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Stretch to Fit Basic MSI, Merge If you want the icon to be resized to fill the area of the control, select
Module True.
To have the icon centered if it is smaller than the control or to have the
icon cropped if it is bigger than the control, select False.
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB
Merge Module key. The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the
InstallScript Object, control does not receive focus.
Merge Module
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places
Module the mouse pointer over the control.
When you type a value for this setting, you are creating a string entry
and setting its initial value for all of the languages that are currently in
the project. As an alternative to typing a new value, you can click the
ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control
InstallScript MSI, in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of
InstallScript Object, the system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Dialog Controls
Line Control
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
The line control creates lines of adjustable length and thickness. You can use lines on a dialog to separate areas of the
dialog or add graphical touches.
When you select a line control in a dialog of the Dialogs view, InstallShield displays the following settings in the right pane.
Name Basic MSI, InstallScript, Enter a name for this line. The name must be unique among all of the
InstallScript MSI, controls in your project.
InstallScript Object,
Merge Module
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish
Merge Module button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge Module This setting is reserved for future use. Windows Installer does not
currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of
InstallScript Object, the system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB
Merge Module key. The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the control
InstallScript Object, does not receive focus.
Merge Module
Tooltip Basic MSI, Merge Module Enter the text that you want to be displayed when the end user places
the mouse pointer over the control.
When you type a value for this setting, you are creating a string entry
and setting its initial value for all of the languages that are currently in
the project. As an alternative to typing a new value, you can click the
ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control
InstallScript MSI, in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of
InstallScript Object, the system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
The list box control is a standard list box that lets end users select a single option from a list of predetermined options.
When you select a list box control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Project • (For Basic MSI and Merge Module projects) When you first draw this type of control on a dialog, InstallShield prompts
you for the name of a Windows Installer property that identifies all of the items that are displayed in this list box. InstallShield
uses the name that you enter as the value for this control’s Property setting. At run time, the installation sets the value of this
property based on the end user’s selection. For more details, see Working with Windows Installer and Advanced UI or Suite/
Advanced UI Properties.
Name Basic MSI, InstallScript, Enter a name for this list box. The name must be unique among all of the
InstallScript MSI, controls in your project.
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Module Text Style setting.
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish
Merge Module button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Code Page Basic MSI, Merge If you want the control to use fonts from the code page that is defined in
Module the installation’s package, select Database. If you want the control to use
fonts from the target system’s default code page, select User’s System.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
Enabled Basic MSI, InstallScript, Indicate whether the control is enabled. True means that this control is
InstallScript MSI, available (the end user can interact with it). False means that it is not
InstallScript Object, available (grayed out).
Merge Module
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Indirect Basic MSI, InstallScript, If the property that is associated with this control is referenced indirectly,
Property InstallScript MSI, select True; otherwise, select False.
InstallScript Object,
When True is selected for an indirect property is set to True, Windows
Merge Module
Installer resolves the referenced property at run time. For example, this
check box might use the property _BROWSE, whose value is INSTALLDIR. If
you select True for the Indirect Property setting, the value of _BROWSE will
be the current value of the INSTALLDIR property. If you select False for the
Indirect Property setting, the value of _BROWSE will contain the string
INSTALLDIR.
Items Basic MSI, Merge To specify the options that you want to be listed in this control, click the
Module ellipsis button (...) in this setting; this opens the List Items dialog box.
To add a new item to the list, click the Add button on the List Items dialog
box. For each item, you must enter the text that is displayed in the list
box, and a value, which is the value that is assigned to the property if this
item is selected.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Left Scrollbar Basic MSI, InstallScript, If you want the arrow and vertical scrollbar to be displayed on the left side
InstallScript MSI, of the control, select True. This option should be selected only when True
InstallScript Object, is selected for the Right-to-Left setting.
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Property Basic MSI, Merge Enter the name of a property that is set when an end user selects an
Module option from this control. This property can be unique to this control; it
does not need to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public
property by giving it a name that contains only uppercase letters, use the
Property Manager view to add the public property, and then assign to it
the text of the default selection.
Property Is Basic MSI, InstallScript, If the property for this control (specified in the Property setting) has an
Integer InstallScript MSI, integer value, select True. If the property’s value is a string, select False.
InstallScript Object,
Merge Module
Right-Aligned Basic MSI, InstallScript, The default value of False aligns the text to the left of the control. Set it to
InstallScript MSI, True to align the text to the right.
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, InstallScript, For English and other languages that are written from left to right, select
InstallScript MSI, False. For Hebrew and those languages that are read from right to left,
InstallScript Object, select True.
Merge Module
Sorted Basic MSI, InstallScript, Selecting True causes the items in the list box to be sorted alphabetically.
InstallScript MSI, A value of False makes them retain the order that you set for each item in
InstallScript Object, the List Items dialog box.
Merge Module
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB
Merge Module key. The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the control
InstallScript Object, does not receive focus.
Merge Module
Text Basic MSI, Merge This setting contains the text that is used for screen readers.
Module
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays
the font that is contained in the DefaultUIFont property.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control in
InstallScript MSI, installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
The list view control displays a single column of options; an icon is displayed next to each option.
When you select a list view control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Project • (For Basic MSI and Merge Module projects) When you first draw this type of control on a dialog, InstallShield prompts
you for the name of a Windows Installer property that identifies all of the items that are displayed in this list view. InstallShield
uses the name that you enter as the value for this control’s Property setting. At run time, the installation sets the value of this
property based on the end user’s selection. For more details, see Working with Windows Installer and Advanced UI or Suite/
Advanced UI Properties.
Name Basic MSI, Enter a name for this list view. The name must be unique among all of the
InstallScript, controls in your project.
InstallScript MSI,
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Module Text Style setting.
Cancel Basic MSI, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript MSI, key or clicking the Close button on the title bar. The Cancel or Finish
InstallScript Object, button is usually the cancel control.
Merge Module
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, If this is the only control on the dialog that you want to be the default
InstallScript, control, which means that it is activated when the end user presses the
InstallScript MSI, ENTER key, select True. The Next or OK button is usually the default
InstallScript Object, control.
Merge Module
Enabled Basic MSI, Indicate whether the control is enabled. True means that this control is
InstallScript, available (the end user can interact with it). False means that it is not
InstallScript MSI, available (grayed out).
InstallScript Object,
Merge Module
Height Basic MSI, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript, in Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Merge Module
Specify the height of the control in dialog units.
Icon Size Basic MSI, Merge Assuming that your icon file has more than one resource, specify the size
Module of the image that you want to use for the control. The Use first image
option causes the first image in the file to be displayed and makes it
stretch to fit the size of the control, regardless of what you specify for the
Stretch to Fit setting.
Indirect Basic MSI, If the property that is associated with this control is referenced indirectly,
Property InstallScript, select True; otherwise, select False.
InstallScript MSI,
When True is selected for an indirect property is set to True, Windows
InstallScript Object,
Installer resolves the referenced property at run time. For example, this
Merge Module
check box might use the property _BROWSE, whose value is INSTALLDIR. If
you select True for the Indirect Property setting, the value of _BROWSE will
be the current value of the INSTALLDIR property. If you select False for the
Indirect Property setting, the value of _BROWSE will contain the string
INSTALLDIR.
Items Basic MSI, Merge To specify the options that you want to be listed in this control, click the
Module ellipsis button (...) in this setting; this opens the List Items dialog box.
To add a new item to the list, click the Add button on the List Items dialog
box. For each item, you must enter the text that is displayed in the list
view control, and a value, which is the value that is assigned to the
property if this item is selected.
Left Basic MSI, Specify the distance from the left edge of the dialog to the start of the
InstallScript, control in installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Left Scrollbar Basic MSI, If you want the arrow and vertical scrollbar to be displayed on the left side
InstallScript, of the control, select True. This option should be selected only when True
InstallScript MSI, is selected for the Right-to-Left setting.
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Property Basic MSI, Merge Enter the name of a property that is set when an end user selects a value
Module from this control. This property can be unique to this control; it does not
need to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public
property by giving it a name that contains only uppercase letters, use the
Property Manager view to add the public property, and then assign to it
the value of the default selection.
Property Is Basic MSI, If the property for this control (specified in the Property setting) has an
Integer InstallScript, integer value, select True. If the property’s value is a string, select False.
InstallScript MSI,
InstallScript Object,
Merge Module
Right-Aligned Basic MSI, The default value of False aligns the text to the left of the control. Set it to
InstallScript, True to align the text to the right.
InstallScript MSI,
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, For English and other languages that are written from left to right, select
InstallScript, False. For Hebrew and those languages that are read from right to left,
InstallScript MSI, select True.
InstallScript Object,
Merge Module
Sorted Basic MSI, Selecting True causes the items in the combo box to be sorted
InstallScript, alphabetically. A value of False makes them retain the order that you set
InstallScript MSI, for each item in the List Items dialog box.
InstallScript Object,
Merge Module
Stretch to Fit Basic MSI, Merge If you want the image to be resized to fill the area of the control, select
Module True.
To have the image centered if it is smaller than the control or to have the
image cropped if it is bigger than the control, select False.
Sunken Basic MSI, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript, select True. To use the default visual style for the control, select False.
InstallScript MSI,
InstallScript Object,
Merge Module
Tab Index Basic MSI, Assign an integer that—along with the other controls on this dialog but
InstallScript, excluding controls such as static text—specifies the order in which each
InstallScript MSI, control on the dialog receives focus when the end user presses the TAB
InstallScript Object, key. The lowest tab index that you can use is the number 0.
Merge Module
Tab Stop Basic MSI, Indicate whether this control receives focus within the tab order. True
InstallScript, indicates that the control receives focus; False indicates that the control
InstallScript MSI, does not receive focus.
InstallScript Object,
Merge Module
Text Basic MSI, Merge This setting contains the text that is used in the control.
Module
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays
the font that is contained in the DefaultUIFont property.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, Specify the distance from the top of the dialog to the top of the control in
InstallScript, installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Visible Basic MSI, True means that the control is visible, and False means that it is hidden.
InstallScript, You can also make the control visible by editing its condition in the
InstallScript MSI, Behavior area for the dialog.
InstallScript Object,
Merge Module
Width Basic MSI, For Basic MSI and Merge Module projects: Specify the width of the control
InstallScript, in Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Merge Module
Specify the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• Merge Module
The masked edit control is essentially an edit field control that lets end users enter information in a specified format.
When you select a masked edit control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Setting Description
Name Enter a name for this masked edit control. The name must be unique among all of the controls
in your project.
Base Text Style This font style is used for the control’s label if you specify nothing for the Text Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True. Clicking the
cancel control has the same effect as pressing the ESC key or clicking the Close button on the
title bar. The Cancel or Finish button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog that contains
this control.
Context Help This setting is reserved for future use. Windows Installer does not currently support launching
context-sensitive help topics from the installation.
Default If this is the only control on the dialog that you want to be the default control, which means that
it is activated when the end user presses the ENTER key, select True. The Next or OK button is
usually the default control.
Enabled Indicate whether the control is enabled. True means that this control is available (the end user
can interact with it). False means that it is not available (grayed out).
Height Specify the height of the control in Windows Installer user interface units (1/12 of the height of
the system font).
Indirect Property If the property that is associated with this control is referenced indirectly, select True;
otherwise, select False.
When True is selected for an indirect property is set to True, Windows Installer resolves the
referenced property at run time. For example, this check box might use the property _BROWSE,
whose value is INSTALLDIR. If you select True for the Indirect Property setting, the value of
_BROWSE will be the current value of the INSTALLDIR property. If you select False for the Indirect
Property setting, the value of _BROWSE will contain the string INSTALLDIR.
Left Specify the distance from the left edge of the dialog to the start of the control in installer units
(1/12 of the height of the system font).
Mask Enter the formatting for the mask. To learn more, see MaskedEdit Control in the Windows
Installer Help Library.
Max. Length Specify the maximum number of characters that the end user can enter in this control.
Setting Description
Property Enter the name of a property that is set with the value that an end user enters in the masked
edit control. This property can be unique to this control; it does not need to be present in the
Property Manager view.
To set a default value for this control, make sure the property is a public property by giving it a
name that contains only uppercase letters, use the Property Manager view to add the public
property, and then assign to it the value of the default selection.
Right-to-Left For English and other languages that are written from left to right, select False. For Hebrew and
those languages that are read from right to left, select True.
Sunken To give the control’s edges a recessed, three-dimensional appearance, select True. To use the
default visual style for the control, select False.
Tab Index Assign an integer that—along with the other controls on this dialog but excluding controls such
as static text—specifies the order in which each control on the dialog receives focus when the
end user presses the TAB key. The lowest tab index that you can use is the number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates that the control
receives focus; False indicates that the control does not receive focus.
Text Style Select the font style, size, and color (if available) in which you want the control’s label to be
displayed. Leaving the value as <Default> displays the font that is contained in the
DefaultUIFont property.
Tooltip Enter the text that you want to be displayed when the end user places the mouse pointer over
the control.
When you type a value for this setting, you are creating a string entry and setting its initial value
for all of the languages that are currently in the project. As an alternative to typing a new value,
you can click the ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer units (1/12 of
the height of the system font).
Visible True means that the control is visible, and False means that it is hidden. You can also make the
control visible by editing its condition in the Behavior area for the dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of the height of
the system font).
See Also
Dialog Controls
• Basic MSI
• Merge Module
A path edit control is used in conjunction with a directory combo control and a directory list control to create a browse
dialog. The path edit displays the complete path that is assembled from selections that the end user makes in the directory
combo and directory list, along with or instead of edits that the end user makes.
When you select a path edit control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Setting Description
Name Enter a name for this path edit control. The name must be unique among all of the
controls in your project.
Base Text Style This font style is used for the control’s label if you specify nothing for the Text
Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True.
Clicking the cancel control has the same effect as pressing the ESC key or clicking
the Close button on the title bar. The Cancel or Finish button is usually the cancel
control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog
that contains this control.
Context Help This property is reserved for future use. Windows Installer does not currently
support launching context-sensitive help topics from the installation.
Default If this is the only control on the dialog that you want to be the default control,
which means that it is activated when the end user presses the ENTER key, select
True. The Next or OK button is usually the default control.
Enabled Indicate whether the control is enabled. True means that this control is available
(the end user can interact with it). False means that it is not available (grayed out).
Height Specify the height of the control in Windows Installer user interface units (1/12 of
the height of the system font).
Setting Description
Indirect Property If the property that is associated with this control is referenced indirectly, select
True; otherwise, select False.
When True is selected for an indirect property is set to True, Windows Installer
resolves the referenced property at run time. For example, this check box might
use the property _BROWSE, whose value is INSTALLDIR. If you select True for the
Indirect Property setting, the value of _BROWSE will be the current value of the
INSTALLDIR property. If you select False for the Indirect Property setting, the
value of _BROWSE will contain the string INSTALLDIR.
Left Specify the distance from the left edge of the dialog to the start of the control in
installer units (1/12 of the height of the system font).
Property Enter the name of a property that is set when an end user enters a value into this
path edit or selects one from the directory list. This property can be unique to this
control; it does not need to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public property
by giving it a name that contains only uppercase letters, use the Property Manager
view to add the public property, and then assign to it the value of the default
selection.
Right-Aligned The default value of False aligns the text to the left of the control. Set it to True to
align the text to the right.
Right-to-Left For English and other languages that are written from left to right, select False.
For Hebrew and those languages that are read from right to left, select True.
Tab Index Assign an integer that—along with the other controls on this dialog but excluding
controls such as static text—specifies the order in which each control on the
dialog receives focus when the end user presses the TAB key. The lowest tab index
that you can use is the number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates
that the control receives focus; False indicates that the control does not receive
focus.
Text This setting contains the text that is used for the control’s label.
When you type a value for this setting, you are creating a string entry and setting
its initial value for all of the languages that are currently in the project. As an
alternative to typing a new value, you can click the ellipsis button (...) in this
setting to select an existing string. For more information, see Using String Entries
in InstallShield.
Setting Description
Text Style Select the font style, size, and color (if available) in which you want the control’s
label to be displayed. Leaving the value as <Default> displays the font that is
contained in the DefaultUIFont property.
Tooltip Enter the text that you want to be displayed when the end user places the mouse
pointer over the control.
When you type a value for this setting, you are creating a string entry and setting
its initial value for all of the languages that are currently in the project. As an
alternative to typing a new value, you can click the ellipsis button (...) in this
setting to select an existing string. For more information, see Using String Entries
in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer
units (1/12 of the height of the system font).
Visible True means that the control is visible, and False means that it is hidden. You can
also make the control visible by editing its condition in the Behavior area for the
dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of
the height of the system font).
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
A progress bar is a dynamic, graphical bar that fills up in response to control events.
When you select a progress bar control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Name Basic MSI, Enter a name for this progress bar. The name must be unique among all of
InstallScript, the controls in your project.
InstallScript MSI,
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control if you specify nothing for the Text
Module Style setting.
Cancel Basic MSI, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript MSI, key or clicking the Close button on the title bar. The Cancel or Finish
InstallScript Object, button is usually the cancel control.
Merge Module
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Default Basic MSI, If this is the only control on the dialog that you want to be the default
InstallScript, control, which means that it is activated when the end user presses the
InstallScript MSI, ENTER key, select True. The Next or OK button is usually the default
InstallScript Object, control.
Merge Module
Height Basic MSI, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript, in Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Merge Module
Specify the height of the control in dialog units.
Left Basic MSI, Specify the distance from the left edge of the dialog to the start of the
InstallScript, control in installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog box.
Styles InstallScript MSI,
InstallScript Object
Sunken Basic MSI, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript, select True. To use the default visual style for the control, select False.
InstallScript MSI,
InstallScript Object,
Merge Module
Tab Index Basic MSI, Assign an integer that—along with the other controls on this dialog but
InstallScript, excluding controls such as static text—specifies the order in which each
InstallScript MSI, control on the dialog receives focus when the end user presses the TAB
InstallScript Object, key. The lowest tab index that you can use is the number 0.
Merge Module
Tab Stop Basic MSI, Indicate whether this control receives focus within the tab order. True
InstallScript, indicates that the control receives focus; False indicates that the control
InstallScript MSI, does not receive focus.
InstallScript Object,
Merge Module
Text Basic MSI, Merge This setting contains the text that is displayed by the control.
Module
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays the
font that is contained in the DefaultUIFont property.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, Specify the distance from the top of the dialog to the top of the control in
InstallScript, installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Visible Basic MSI, True means that the control is visible, and False means that it is hidden.
InstallScript, You can also make the control visible by editing its condition in the
InstallScript MSI, Behavior area for the dialog.
InstallScript Object,
Merge Module
Width Basic MSI, For Basic MSI and Merge Module projects: Specify the width of the control
InstallScript, in Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Merge Module
Specify the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
A push button control is a button that carries out a command when an end user clicks it.
When you select a push button control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Name Basic MSI, InstallScript, Enter a name for this push button. The name must be unique among all of
InstallScript MSI, the controls in your project.
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Module Text Style setting.
This setting is enabled if Text is selected for the Control Style setting.
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish
Merge Module button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
Control Style Basic MSI, Merge Specify whether this control is marked with a text label, an icon, or a
Module bitmap.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
Enabled Basic MSI, InstallScript, Indicate whether the control is enabled. True means that this control is
InstallScript MSI, available (the end user can interact with it). False means that it is not
InstallScript Object, available (grayed out).
Merge Module
File Name Basic MSI, Merge Enter the path to and the name of the image file that you want to use for
Module this control, or click the ellipsis button (...) in this setting to browse to it.
InstallShield adds the file to your release at build time. The file must be
stored as a binary resource in the installation.
This setting is enabled if you select Bitmap or Icon for the Control Style
setting.
This setting is enabled if Bitmap or Icon are selected for the Control Style
setting.
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Icon Size Basic MSI, Merge Assuming that your icon file has more than one resource, specify the size
Module of the image that you want to use for the control. The Use first image
option causes the first image in the file to be displayed and makes it
stretch to fit the size of the control, regardless of what you specify for the
Stretch to Fit setting.
This setting is enabled if Bitmap or Icon are selected for the Control Style
setting.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog box.
Styles InstallScript MSI,
InstallScript Object
Right-to-Left Basic MSI, InstallScript, For English and other languages that are written from left to right, select
InstallScript MSI, False. For Hebrew and those languages that are read from right to left,
InstallScript Object, select True.
Merge Module
Show UAC Basic MSI, Merge If you want the control to include a User Account Control (UAC) shield icon
Shield Icon Module when end users run the installation on Windows Vista or later systems,
select True. The shield icon signals to end users that elevated privileges
may be required.
If the UAC shield icon should not be included on the control, select False.
Stretch to Fit Basic MSI, Merge If you want the image to be resized to fill the area of the control, select
Module True.
To have the image centered if it is smaller than the control or to have the
image cropped if it is bigger than the control, select False.
This setting is enabled if Bitmap or Icon are selected for the Control Style
setting.
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB
Merge Module key. The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the control
InstallScript Object, does not receive focus.
Merge Module
Text Basic MSI, InstallScript, This setting contains the text that is used on the control.
InstallScript MSI,
When you type a value for this setting, you are creating a string entry and
InstallScript Object,
setting its initial value for all of the languages that are currently in the
Merge Module
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
This setting is enabled if Text is selected for the Control Style setting.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays the
font that is contained in the DefaultUIFont property.
This setting is enabled if Text is selected for the Control Style setting.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control in
InstallScript MSI, installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
A radio button control is one of two or more mutually exclusive options that end users can select. A radio button must be
inserted into a radio button group; it functions as part of that control.
A radio button group and its radio buttons behave as a single control. It is not possible to hide or disable individual buttons
within a radio button group. All the buttons in a group must be the same style—for example, either all of them have text or
all of them have bitmaps.
Note that when you delete a radio button group, all of its radio buttons are also deleted. In addition, when you change the
name of the radio button group control, all of its radio buttons are deleted.
When you select a radio button control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Base Text Style Basic MSI, Merge Module This font style is used for the control’s label if you specify nothing for the
Text Style setting.
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish
Merge Module button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge Module This setting is reserved for future use. Windows Installer does not
currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
The control identifier for the first radio button in a group is the control
identifier for the radio button group. The control for each subsequent
radio button is the radio button group identifier incremented by one.
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the
InstallScript MSI, control in Windows Installer user interface units (1/12 of the height of the
InstallScript Object, system font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Order Basic MSI, InstallScript, Specify the number that indicates the order in which this radio button is
InstallScript MSI, listed in the radio button group. This setting must contain a unique,
InstallScript Object, positive integer, but it does not need to be consecutive with the Order
Merge Module setting of the other radio buttons in this group.
Text Basic MSI, InstallScript, This setting contains the text that is used for the radio button’s label.
InstallScript MSI,
When you type a value for this setting, you are creating a string entry and
InstallScript Object,
setting its initial value for all of the languages that are currently in the
Merge Module
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Module Select the font style, size, and color (if available) in which you want the
control’s label to be displayed. Leaving the value as <Default> displays
the font that is contained in the DefaultUIFont property.
Tooltip Basic MSI, Merge Module Enter the text that you want to be displayed when the end user places the
mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control in
InstallScript MSI, installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Value Basic MSI, InstallScript, Enter the value that you want to be associated with this radio button
InstallScript MSI, when end users select it.
InstallScript Object,
Merge Module
Project • For Basic MSI projects: To make one of the radio buttons selected
by default, enter the radio button group’s Windows Installer property in the
Property Manager view. Type the property in all uppercase letters if you
want it to be public in scope.Then, specify the value of the button that you
want to appear as the default. For example, if one of your radio buttons has
a value of 104 and the radio button group uses the property
GRP_PROPERTY1, enter the following information in the Property Manager
view to make this radio button the default selection.
• Name: GRP_PROPERTY1
• Value: 104
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
Note that in Basic MSI and Merge Module projects, it is not possible to hide or disable individual buttons within a radio button
group. All the buttons in a group must be the same style—for example, either all of them have text or all of them have bitmaps.
A radio button group control is a container for radio button controls. A radio button group and its radio buttons behave as
a single control. Note that when you delete a radio button group, all of its radio buttons are also deleted. In addition, when
you change the name of the radio button group control, all of its radio buttons are deleted.
When you select a radio button group control in a dialog of the Dialogs view, InstallShield displays the following settings in
the right pane.
Project • (For Basic MSI and Merge Module projects) When you first draw this type of control on a dialog, InstallShield prompts
you for the name of a Windows Installer property that identifies all of the buttons that are displayed in this radio button group.
InstallShield uses the name that you enter as the value for this control’s Property setting. At run time, the installation sets the
value of this property based on the end user’s selection. For more details, see Working with Windows Installer and Advanced UI
or Suite/Advanced UI Properties.
Name Basic MSI, InstallScript, Enter a name for this radio button group. The name must be unique
InstallScript MSI, among all of the controls in your project.
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Module Text Style setting.
This setting has no effect on a radio button group with an image for a
label.
Cancel Basic MSI, InstallScript, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript MSI, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript Object, key or clicking the Close button on the title bar. The Cancel or Finish
Merge Module button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not
Module currently support launching context-sensitive help topics from the
installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in
InstallScript Object Visual C++. You should not change the control identifiers for any of the
controls that are included with a dialog by default.
The control identifier for the first radio button in a group is the control
identifier for the radio button group. The control for each subsequent
radio button is the radio button group identifier incremented by one.
Default Basic MSI, InstallScript, If this is the only control on the dialog that you want to be the default
InstallScript MSI, control, which means that it is activated when the end user presses the
InstallScript Object, ENTER key, select True. The Next or OK button is usually the default
Merge Module control.
Enabled Basic MSI, InstallScript, Indicate whether the control is enabled. True means that this control is
InstallScript MSI, available (the end user can interact with it). False means that it is not
InstallScript Object, available (grayed out).
Merge Module
Has Border Basic MSI, InstallScript, To display a border around the radio button group, select True. To omit a
InstallScript MSI, border, select False.
InstallScript Object,
Use the Sunken setting to further modify the appearance of the border.
Merge Module
Height Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the height of the control in dialog units.
Indirect Basic MSI, InstallScript, If the property that is associated with this control is referenced indirectly,
Property InstallScript MSI, select True; otherwise, select False.
InstallScript Object,
When True is selected for an indirect property is set to True, Windows
Merge Module
Installer resolves the referenced property at run time. For example, this
check box might use the property _BROWSE, whose value is INSTALLDIR. If
you select True for the Indirect Property setting, the value of _BROWSE will
be the current value of the INSTALLDIR property. If you select False for the
Indirect Property setting, the value of _BROWSE will contain the string
INSTALLDIR.
Left Basic MSI, InstallScript, Specify the distance from the left edge of the dialog to the start of the
InstallScript MSI, control in installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog
Styles InstallScript MSI, box.
InstallScript Object
Property Basic MSI, Merge Enter the name of a property that is set when an end user selects one of
Module the radio buttons in this group. This property can be unique to this
control; it does not need to be present in the Property Manager view.
For information on using this setting to set a default selection in the radio
button group, see the radio button’s Value setting.
Right-Aligned Basic MSI, InstallScript, The default value of False aligns the text to the left of the control. Set it to
InstallScript MSI, True to align the text to the right.
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, InstallScript, For English and other languages that are written from left to right, select
InstallScript MSI, False. For Hebrew and those languages that are read from right to left,
InstallScript Object, select True.
Merge Module
Sunken Basic MSI, InstallScript, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript MSI, select True. To use the default visual style for the control, select False.
InstallScript Object,
Merge Module
Tab Index Basic MSI, InstallScript, Assign an integer that—along with the other controls on this dialog but
InstallScript MSI, excluding controls such as static text—specifies the order in which each
InstallScript Object, control on the dialog receives focus when the end user presses the TAB
Merge Module key. The lowest tab index that you can use is the number 0.
Tab Stop Basic MSI, InstallScript, Indicate whether this control receives focus within the tab order. True
InstallScript MSI, indicates that the control receives focus; False indicates that the control
InstallScript Object, does not receive focus.
Merge Module
Text Basic MSI, Merge This setting contains the text that is used for the radio button group’s
Module label.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
This setting has no effect on a radio button group with an image for a
label.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays
the font that is contained in the DefaultUIFont property.
This setting has no effect on a radio button group with an image for a
label.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Basic MSI, InstallScript, Specify the distance from the top of the dialog to the top of the control in
InstallScript MSI, installer units (1/12 of the height of the system font).
InstallScript Object,
Merge Module
Visible Basic MSI, InstallScript, True means that the control is visible, and False means that it is hidden.
InstallScript MSI, You can also make the control visible by editing its condition in the
InstallScript Object, Behavior area for the dialog.
Merge Module
Width Basic MSI, InstallScript, For Basic MSI and Merge Module projects: Specify the width of the control
InstallScript MSI, in Windows Installer user interface units (1/12 of the height of the system
InstallScript Object, font).
Merge Module
For InstallScript, InstallScript MSI, and InstallScript Object projects:
Specify the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• Merge Module
A scrollable text control displays a long string of text that cannot fit on the dialog; the control includes scroll bars that
enable end users to scroll through the text. The LicenseAgreement dialog is an example of a dialog that typically contains a
scrollable text control.
When you select a scrollable text control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Note • Unlike the text values for most controls, Windows Installer does not resolve property names or other values within the
Scrollable Text control. As a result, the text in the file is displayed exactly as it is written.
Setting Description
Name Enter a name for this scrollable text control. The name must be unique among all
of the controls in your project.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True.
Clicking the cancel control has the same effect as pressing the ESC key or clicking
the Close button on the title bar. The Cancel or Finish button is usually the cancel
control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog
that contains this control.
Context Help This setting is reserved for future use. Windows Installer does not currently
support launching context-sensitive help topics from the installation.
Default If this is the only control on the dialog that you want to be the default control,
which means that it is activated when the end user presses the ENTER key, select
True. The Next or OK button is usually the default control.
Enabled Indicate whether the control is enabled. True means that this control is available
(the end user can interact with it). False means that it is not available (grayed out).
Setting Description
File Name Enter the path to and the name of the .rtf file that you want to use for this control,
or click the ellipsis button (...) in this setting to browse to it. InstallShield adds the
file to your release at build time. The file must be stored as a binary resource in
the installation.
Height Specify the height of the control in Windows Installer user interface units (1/12 of
the height of the system font).
Left Specify the distance from the left edge of the dialog to the start of the control in
installer units (1/12 of the height of the system font).
Left Scrollbar If you want the arrow and vertical scrollbar to be displayed on the left side of the
control, select True. This option should be selected only when True is selected for
the Right-to-Left setting.
Right-Aligned The default value of False aligns the text to the left of the control. Set it to True to
align the text to the right.
Right-to-Left For English and other languages that are written from left to right, select False.
For Hebrew and those languages that are read from right to left, select True.
Tab Index Assign an integer that—along with the other controls on this dialog but excluding
controls such as static text—specifies the order in which each control on the
dialog receives focus when the end user presses the TAB key. The lowest tab index
that you can use is the number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates
that the control receives focus; False indicates that the control does not receive
focus.
Tooltip Enter the text that you want to be displayed when the end user places the mouse
pointer over the control.
When you type a value for this setting, you are creating a string entry and setting
its initial value for all of the languages that are currently in the project. As an
alternative to typing a new value, you can click the ellipsis button (...) in this
setting to select an existing string. For more information, see Using String Entries
in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer
units (1/12 of the height of the system font).
Setting Description
Visible True means that the control is visible, and False means that it is hidden. You can
also make the control visible by editing its condition in the Behavior area for the
dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of
the height of the system font).
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
A selection tree is a special control that lets end users change the selection state of your features, like in the CustomSetup
dialog.
When you select a selection tree control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Name Basic MSI, Enter a name for this selection tree. The name must be unique among all of
InstallScript, the controls in your project.
InstallScript MSI,
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the control’s label if you specify nothing for the
Module Text Style setting.
Cancel Basic MSI, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript, True. Clicking the cancel control has the same effect as pressing the ESC key
InstallScript MSI, or clicking the Close button on the title bar. The Cancel or Finish button is
InstallScript Object, usually the cancel control.
Merge Module
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not currently
Module support launching context-sensitive help topics from the installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in Visual
InstallScript Object C++. You should not change the control identifiers for any of the controls
that are included with a dialog by default.
Default Basic MSI, If this is the only control on the dialog that you want to be the default
InstallScript, control, which means that it is activated when the end user presses the
InstallScript MSI, ENTER key, select True. The Next or OK button is usually the default control.
InstallScript Object,
Merge Module
Enabled Basic MSI, Indicate whether the control is enabled. True means that this control is
InstallScript, available (the end user can interact with it). False means that it is not
InstallScript MSI, available (grayed out).
InstallScript Object,
Merge Module
Height Basic MSI, For Basic MSI and Merge Module projects: Specify the height of the control in
InstallScript, Windows Installer user interface units (1/12 of the height of the system font).
InstallScript MSI,
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
InstallScript Object,
the height of the control in dialog units.
Merge Module
Indirect Basic MSI, If the property that is associated with this control is referenced indirectly,
Property InstallScript, select True; otherwise, select False.
InstallScript MSI,
When True is selected for an indirect property is set to True, Windows
InstallScript Object,
Installer resolves the referenced property at run time. For example, this
Merge Module
check box might use the property _BROWSE, whose value is INSTALLDIR. If
you select True for the Indirect Property setting, the value of _BROWSE will be
the current value of the INSTALLDIR property. If you select False for the
Indirect Property setting, the value of _BROWSE will contain the string
INSTALLDIR.
Left Basic MSI, Specify the distance from the left edge of the dialog to the start of the
InstallScript, control in installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Left Scrollbar Basic MSI, If you want the arrow and vertical scrollbar to be displayed on the left side of
InstallScript, the control, select True. This option should be selected only when True is
InstallScript MSI, selected for the Right-to-Left setting.
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog box.
Styles InstallScript MSI,
InstallScript Object
Property Basic MSI, Merge Enter the name of a property for the selection tree. The end user can set the
Module property in a browse dialog (a dialog that uses a path edit, directory combo,
and directory list control).
Right-Aligned Basic MSI, The default value of False aligns the text to the left of the control. Set it to
InstallScript, True to align the text to the right.
InstallScript MSI,
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, For English and other languages that are written from left to right, select
InstallScript, False. For Hebrew and those languages that are read from right to left, select
InstallScript MSI, True.
InstallScript Object,
Merge Module
Sunken Basic MSI, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript, select True. To use the default visual style for the control, select False.
InstallScript MSI,
InstallScript Object,
Merge Module
Tab Index Basic MSI, Assign an integer that—along with the other controls on this dialog but
InstallScript, excluding controls such as static text—specifies the order in which each
InstallScript MSI, control on the dialog receives focus when the end user presses the TAB key.
InstallScript Object, The lowest tab index that you can use is the number 0.
Merge Module
Tab Stop Basic MSI, Indicate whether this control receives focus within the tab order. True
InstallScript, indicates that the control receives focus; False indicates that the control
InstallScript MSI, does not receive focus.
InstallScript Object,
Merge Module
Text Basic MSI, Merge This setting contains the text that is used for screen readers.
Module
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more information,
see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays the
font that is contained in the DefaultUIFont property.
This setting is enabled if Text is selected for the Control Style setting.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more information,
see Using String Entries in InstallShield.
Top Basic MSI, Specify the distance from the top of the dialog to the top of the control in
InstallScript, installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Visible Basic MSI, True means that the control is visible, and False means that it is hidden. You
InstallScript, can also make the control visible by editing its condition in the Behavior
InstallScript MSI, area for the dialog.
InstallScript Object,
Merge Module
Width Basic MSI, For Basic MSI and Merge Module projects: Specify the width of the control in
InstallScript, Windows Installer user interface units (1/12 of the height of the system font).
InstallScript MSI,
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
InstallScript Object,
the width of the control in dialog units.
Merge Module
See Also
Dialog Controls
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
When you select a text area control in a dialog of the Dialogs view, InstallShield displays the following settings in the right
pane.
Name Basic MSI, Enter a name for this text area. The name must be unique among all of the
InstallScript, controls in your project.
InstallScript MSI,
InstallScript Object,
Merge Module
Base Text Style Basic MSI, Merge This font style is used for the text if you specify nothing for the Text Style
Module setting.
Cancel Basic MSI, If this is the only control on the dialog that will dismiss the dialog, select
InstallScript, True. Clicking the cancel control has the same effect as pressing the ESC
InstallScript MSI, key or clicking the Close button on the title bar. The Cancel or Finish button
InstallScript Object, is usually the cancel control.
Merge Module
This value is ignored if True is selected for the ErrorDialog setting of the
dialog that contains this control.
Code Page Basic MSI, Merge If you want the control to use fonts from the code page that is defined in the
Module installation’s package, select Database. If you want the control to use fonts
from the target system’s default code page, select User’s System.
Context Help Basic MSI, Merge This setting is reserved for future use. Windows Installer does not currently
Module support launching context-sensitive help topics from the installation.
Control InstallScript, This setting contains a numeric identifier for the control that is unique
Identifier InstallScript MSI, within the dialog. This identifier is the same as a resource identifier in Visual
InstallScript Object C++. You should not change the control identifiers for any of the controls
that are included with a dialog by default.
Default Basic MSI, If this is the only control on the dialog that you want to be the default
InstallScript, control, which means that it is activated when the end user presses the
InstallScript MSI, ENTER key, select True. The Next or OK button is usually the default control.
InstallScript Object,
Merge Module
Enabled Basic MSI, Indicate whether the control is enabled. True means that this control is
InstallScript, available (the end user can interact with it). False means that it is not
InstallScript MSI, available (grayed out).
InstallScript Object,
Merge Module
Format as Bytes Basic MSI, Merge If you want the installation to attempt to display the value that is entered in
Module the Text setting in bytes, select True. If you select True, the Text setting
must contain only a number, without the unit. Then, at run time, it is
divided by 512 and displayed as the correct number of kilobytes,
megabytes, or gigabytes, depending on the size.
Height Basic MSI, For Basic MSI and Merge Module projects: Specify the height of the control
InstallScript, in Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
Merge Module
the height of the control in dialog units.
Left Basic MSI, Specify the distance from the left edge of the dialog to the start of the
InstallScript, control in installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Other Window InstallScript, Click the ellipsis button (...) to display the Other Window Styles dialog box.
Styles InstallScript MSI,
InstallScript Object
No Prefix Basic MSI, If the Text setting contains an ampersand that should be displayed as an
InstallScript, ampersand character (&), select True.
InstallScript MSI,
If you are using the ampersand in the Text setting to indicate that the letter
InstallScript Object,
that follows the ampersand should be underlined (for example, &Click
Merge Module
would be displayed as Click), select False.
No Text Wrap Basic MSI, Indicate whether you want to allow the text to wrap in this control. If you
InstallScript, select True and the text expands beyond the width of the text area, the end
InstallScript MSI, of the string is cut off and replaced with an ellipsis button (...). Otherwise,
InstallScript Object, the text wraps and can extend beyond the height of the text area, if it is not
Merge Module long enough.
Property Basic MSI, Merge Enter the name of a property that can supply the initial value for the text.
Module This property can be unique to this control; it does not need to be present in
the Property Manager view.
Right-Aligned Basic MSI, The default value of False aligns the text to the left of the control. Set it to
InstallScript, True to align the text to the right.
InstallScript MSI,
InstallScript Object,
Merge Module
Right-to-Left Basic MSI, For English and other languages that are written from left to right, select
InstallScript, False. For Hebrew and those languages that are read from right to left,
InstallScript MSI, select True.
InstallScript Object,
Merge Module
Sunken Basic MSI, To give the control’s edges a recessed, three-dimensional appearance,
InstallScript, select True. To use the default visual style for the control, select False.
InstallScript MSI,
InstallScript Object,
Merge Module
Tab Index Basic MSI, Assign an integer that—along with the other controls on this dialog but
InstallScript, excluding controls such as static text—specifies the order in which each
InstallScript MSI, control on the dialog receives focus when the end user presses the TAB key.
InstallScript Object, The lowest tab index that you can use is the number 0.
Merge Module
Tab Stop Basic MSI, Indicate whether this control receives focus within the tab order. True
InstallScript, indicates that the control receives focus; False indicates that the control
InstallScript MSI, does not receive focus.
InstallScript Object,
Merge Module
Text Basic MSI, This setting contains the text that is shown inside the control.
InstallScript,
When you type a value for this setting, you are creating a string entry and
InstallScript MSI,
setting its initial value for all of the languages that are currently in the
InstallScript Object,
project. As an alternative to typing a new value, you can click the ellipsis
Merge Module
button (...) in this setting to select an existing string. For more information,
see Using String Entries in InstallShield.
Text Style Basic MSI, Merge Select the font style, size, and color (if available) in which you want the
Module control’s label to be displayed. Leaving the value as <Default> displays the
font that is contained in the DefaultUIFont property.
This setting is enabled if Text is selected for the Control Style setting.
Tooltip Basic MSI, Merge Enter the text that you want to be displayed when the end user places the
Module mouse pointer over the control.
When you type a value for this setting, you are creating a string entry and
setting its initial value for all of the languages that are currently in the
project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more information,
see Using String Entries in InstallShield.
Top Basic MSI, Specify the distance from the top of the dialog to the top of the control in
InstallScript, installer units (1/12 of the height of the system font).
InstallScript MSI,
InstallScript Object,
Merge Module
Transparent Basic MSI, If you want the background to show through this control, select True.
InstallScript,
Note that you may want to avoid making this control transparent if you are
InstallScript MSI,
placing it on top of a colored bitmap. The text may not be visible if end
InstallScript Object,
users change the color scheme of their display. For example, the text in this
Merge Module
control may become invisible if an end user sets the high-contrast
parameter for accessibility reasons.
Visible Basic MSI, True means that the control is visible, and False means that it is hidden. You
InstallScript, can also make the control visible by editing its condition in the Behavior
InstallScript MSI, area for the dialog.
InstallScript Object,
Merge Module
Width Basic MSI, For Basic MSI and Merge Module projects: Specify the width of the control in
InstallScript, Windows Installer user interface units (1/12 of the height of the system
InstallScript MSI, font).
InstallScript Object,
For InstallScript, InstallScript MSI, and InstallScript Object projects: Specify
Merge Module
the width of the control in dialog units.
See Also
Dialog Controls
• Basic MSI
• Merge Module
A volume cost list control displays the disk space requirements that are associated with each volume or drive.
The list has five possible columns. The headings for each column are configurable in the UIText table, which you can
access in the Direct Editor view. The UIText table identifies the values of string entries so that localized strings are
displayed at run time when appropriate. Following is a list of the keys in the UIText table for each column, along with their
default English values:
• VolumeCostVolume—Volume
• VolumeCostSize—Disk Size
• VolumeCostAvailable—Available
• VolumeCostRequired—Required
• VolumeCostDifference—Differences
When you select a volume list cost control in a dialog of the Dialogs view, InstallShield displays the following settings in the
right pane.
Setting Description
Name Enter a name for this volume cost list. The name must be unique among all of the controls
in your project.
Available Col Width Specify the default width in installer units (1/12 of the height of the system font) for the
Available column. This column is hidden if the value is the number 0 or it is left blank.
Base Text Style This font style is used for the contents of the volume cost list if you specify nothing for the
Text Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True. Clicking the
cancel control has the same effect as pressing the ESC key or clicking the Close button on
the title bar. The Cancel or Finish button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog that
contains this control.
Context Help This setting is reserved for future use. Windows Installer does not currently support
launching context-sensitive help topics from the installation.
Setting Description
Default If this is the only control on the dialog that you want to be the default control, which
means that it is activated when the end user presses the ENTER key, select True. The Next
or OK button is usually the default control.
Differences Col Width Specify the default width in installer units (1/12 of the height of the system font) for the
Differences column. This column is hidden if the value is the number 0 or it is left blank.
Disk Size Col Width Specify the default width in installer units (1/12 of the height of the system font) for the
Disk Size column. This column is hidden if the value is the number 0 or it is left blank.
Enabled Indicate whether the control is enabled. True means that this control is available (the end
user can interact with it). False means that it is not available (grayed out).
Height Specify the height of the control in Windows Installer user interface units (1/12 of the
height of the system font).
Left Specify the distance from the left edge of the dialog to the start of the control in installer
units (1/12 of the height of the system font).
Left Scrollbar If you want the arrow and vertical scrollbar to be displayed on the left side of the control,
select True. This option should be selected only when True is selected for the Right-to-Left
setting.
Required Col Width Specify the default width in installer units (1/12 of the height of the system font) for the
Required column. This column is hidden if the value is the number 0 or it is left blank.
Right-Aligned The default value of False aligns the text to the left of the control. Set it to True to align the
text to the right.
Right-to-Left For English and other languages that are written from left to right, select False. For
Hebrew and those languages that are read from right to left, select True.
Show Remote To include mapped network drives in the control, select True.
Sunken To give the control’s edges a recessed, three-dimensional appearance, select True. To use
the default visual style for the control, select False.
Setting Description
Tab Index Assign an integer that—along with the other controls on this dialog but excluding controls
such as static text—specifies the order in which each control on the dialog receives focus
when the end user presses the TAB key. The lowest tab index that you can use is the
number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates that the
control receives focus; False indicates that the control does not receive focus.
Text This setting contains the text that is used for the control’s label. Although you cannot see
the label, it is available for screen readers.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a
new value, you can click the ellipsis button (...) in this setting to select an existing string.
For more information, see Using String Entries in InstallShield.
Text Style Select the font style, size, and color (if available) in which you want the control’s label to
be displayed. Leaving the value as <Default> displays the font that is contained in the
DefaultUIFont property.
This setting is enabled if Text is selected for the Control Style setting.
Tooltip Enter the text that you want to be displayed when the end user places the mouse pointer
over the control.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a
new value, you can click the ellipsis button (...) in this setting to select an existing string.
For more information, see Using String Entries in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer units (1/
12 of the height of the system font).
Visible True means that the control is visible, and False means that it is hidden. You can also
make the control visible by editing its condition in the Behavior area for the dialog.
Volume Col Width Specify the default width in installer units (1/12 of the height of the system font) for the
Volume column. This column is hidden if the value is the number 0 or it is left blank.
Width Specify the width of the control in Windows Installer user interface units (1/12 of the
height of the system font).
See Also
String Editor View
Dialog Controls
• Basic MSI
• Merge Module
A volume select combo control enables the end user to select from an alphabetical list of volumes, or drives.
When you select a volume select combo control in a dialog of the Dialogs view, InstallShield displays the following settings
in the right pane.
Setting Description
Name Enter a name for this volume select combo. The name must be unique among all of the
controls in your project.
Base Text Style This font style is used for the control’s text if you specify nothing for the Text Style setting.
Cancel If this is the only control on the dialog that will dismiss the dialog, select True. Clicking the
cancel control has the same effect as pressing the ESC key or clicking the Close button on the
title bar. The Cancel or Finish button is usually the cancel control.
This value is ignored if True is selected for the ErrorDialog setting of the dialog that contains
this control.
Context Help This setting is reserved for future use. Windows Installer does not currently support launching
context-sensitive help topics from the installation.
Default If this is the only control on the dialog that you want to be the default control, which means
that it is activated when the end user presses the ENTER key, select True. The Next or OK
button is usually the default control.
Enabled Indicate whether the control is enabled. True means that this control is available (the end user
can interact with it). False means that it is not available (grayed out).
Height Specify the height of the control in Windows Installer user interface units (1/12 of the height of
the system font).
Indirect Property If the property that is associated with this control is referenced indirectly, select True;
otherwise, select False.
When True is selected for an indirect property is set to True, Windows Installer resolves the
referenced property at run time. For example, this check box might use the property _BROWSE,
whose value is INSTALLDIR. If you select True for the Indirect Property setting, the value of
_BROWSE will be the current value of the INSTALLDIR property. If you select False for the Indirect
Property setting, the value of _BROWSE will contain the string INSTALLDIR.
Setting Description
Left Specify the distance from the left edge of the dialog to the start of the control in installer units
(1/12 of the height of the system font).
Left Scrollbar If you want the arrow and vertical scrollbar to be displayed on the left side of the control,
select True. This option should be selected only when True is selected for the Right-to-Left
setting.
Property Enter the name of a property that is set when an end user selects a value from this control. This
control populates the first part of the path that is displayed in the directory list, so you must
use the same property for the volume select combo, the directory list, and path edit when
using them together in a browse dialog. This property can be unique to this control; it does not
need to be present in the Property Manager view.
To set a default value for this control, make sure the property is a public property by giving it a
name that contains only uppercase letters, use the Property Manager view to add the public
property, and then assign to it the value of the default selection.
Right-Aligned The default value of False aligns the text to the left of the control. Set it to True to align the text
to the right.
Right-to-Left For English and other languages that are written from left to right, select False. For Hebrew
and those languages that are read from right to left, select True.
Show Remote To include mapped network drives in the control, select True.
Sunken To give the control’s edges a recessed, three-dimensional appearance, select True. To use the
default visual style for the control, select False.
Tab Index Assign an integer that—along with the other controls on this dialog but excluding controls
such as static text—specifies the order in which each control on the dialog receives focus when
the end user presses the TAB key. The lowest tab index that you can use is the number 0.
Tab Stop Indicate whether this control receives focus within the tab order. True indicates that the
control receives focus; False indicates that the control does not receive focus.
Setting Description
Text This setting contains the text that is used in the control.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a new
value, you can click the ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Text Style Select the font style, size, and color (if available) in which you want the control’s label to be
displayed. Leaving the value as <Default> displays the font that is contained in the
DefaultUIFont property.
This setting is enabled if Text is selected for the Control Style setting.
Tooltip Enter the text that you want to be displayed when the end user places the mouse pointer over
the control.
When you type a value for this setting, you are creating a string entry and setting its initial
value for all of the languages that are currently in the project. As an alternative to typing a new
value, you can click the ellipsis button (...) in this setting to select an existing string. For more
information, see Using String Entries in InstallShield.
Top Specify the distance from the top of the dialog to the top of the control in installer units (1/12
of the height of the system font).
Visible True means that the control is visible, and False means that it is hidden. You can also make the
control visible by editing its condition in the Behavior area for the dialog.
Width Specify the width of the control in Windows Installer user interface units (1/12 of the height of
the system font).
See Also
Dialog Controls
In the Dialog Editor, you can copy and paste controls within a dialog or from one dialog to another by using standard
Windows keyboard shortcuts or context menus.
1. Open the layout for the dialog that contains the button you want to copy.
3. Open the second dialog in the Dialog Editor and press CTRL+V to paste the control in the dialog.
The push button is pasted with the same relative size and position as the original. Its other properties are also identical to
the original’s. The copy of the push button is given a unique name based on the type of control it is. However, you must edit
the new control’s behavior, since that information is not copied over (Basic MSI projects).
Note • Radio button groups are a special case. When you copy the group, all of its radio buttons are copied for you. You
cannot copy a radio button by itself.
See Also
Editing Dialog Behavior in Basic MSI Projects
In the Dialog Editor, you can move a control from one dialog to another by using standard Windows keyboard shortcuts or
context menus.
1. Right-click the control and click Cut, or press CTRL+X. A Delete Control dialog box opens to inform you that deleting
the control also deletes any associated conditions and actions.
2. Click Yes to continue cutting the control from the current dialog.
3. Open the second dialog in the Dialog Editor and press CTRL+V to paste the control in the dialog.
When you are done pasting the control into the new location, specify the control’s properties and behavior.
See Also
Dialogs View (Basic MSI and Other Windows Installer–Based Projects)
Dialogs View (InstallScript, InstallScript MSI, and InstallScript Object Projects)
Exporting a Dialog to an .isd File for Use in Other Projects
Importing Dialogs from an .isd File
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
This section of the documentation covers aspects of working with the wizard interface of Advanced UI and Suite/Advanced
UI projects. The elements of the wizard interface consist of wizard pages and secondary windows (also known as pop-up
windows). InstallShield lets you define and customize various styles, brushes, and control themes to make formatting the
wizard interface efficient. InstallShield also lets you add, modify, and delete wizard pages and secondary windows, and
schedule when each should be displayed.
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
The following two screen shots show the basic elements of the wizard interface.
InstallShield lets you use your own wizard icon, header image, and wizard caption. InstallShield also lets you define and
customize styles, brushes, and more for the header, body, and navigation areas of the user interface of an Advanced UI or
Suite/Advanced UI project.
See Also
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield lets you define and customize various user interface–related styles, brushes, and control themes to easily
change the look and feel of the wizard interface without requiring you to manually edit each user interface element
individually. Using styles, brushes, and control themes helps to ensure that the wizard interface is formatted consistently
throughout the installation.
conjunction with text styles. Text styles reference a font set but can optionally override various font attributes that are
defined at the font set level. You can modify any of the built-in text styles and font sets and create your own as needed. To
learn more, see:
• Specifying the Background Brush for the Header, Body, and Navigation Areas of the Wizard Interface
• Overriding the Default Background Brushes for a Wizard Page or Secondary Window
• Check boxes
• Radio buttons
• Command links
Use page-specific and control-specific settings such as the Body Background setting that is available for specific wizard
pages, secondary windows, and wizard controls if you want to override a specific use of a style. For example, the Body
Background setting for the InstallationWelcome wizard page lets you override the project’s default background on just the
InstallationWelcome wizard page.
See Also
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield lets you add custom font sets and text styles to your project and then apply those font sets and text styles to
various wizard interface elements. The use of font sets and text styles is helpful for maintaining format consistency and for
applying text formatting changes to the wizard interface globally.
2. In the Wizard Interface explorer, right-click Styles and then click Add Font Set or Add Text Style.
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.
Text styles reference a font set but can optionally override various font attributes that are defined at the font set level.
InstallShield adds a a new style under Styles. Rename the style as needed.
3. Select the style and then configure its settings in the right pane.
Once you have added a font set, you can select it for the Font List setting of any of the text styles that are defined in the
Wizard Interface view. If you later want to change the list of fonts that are used for text styles that are based on that font
set, select the font set and edit its settings.
Once you have added a text style, you can select it for various style-related settings in the Wizard Interface view. If you later
want to change the appearance of the wizard interface elements that use that style, select the style and edit the values for
its settings.
Changes that you make to a style affect all of the wizard interface elements that use that style.
See Also
Applying a Text Style to Text in the Wizard Interface
Using Styles, Brushes, and Control Themes to Customize the Wizard Interface
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield enables you to apply text styles to various wizard interface elements. If you later want to change the
appearance of the wizard interface elements that use that text style, you can easily make changes to the text style, rather
than separately editing each element that uses the text style.
When you are applying a text style to text, you can apply it at the global level, or you can apply it at the individual wizard
page control level.
2. In the Wizard Interface explorer, click Wizard Pages. InstallShield displays the global wizard interface settings in the
right pane.
InstallShield changes the text style of the applicable UI elements throughout the project.
2. In the Wizard Interface explorer, expand the Wizard Pages node or the Secondary Windows node, and find the
wizard page or window that contains the text to which you want to apply a style.
3. Select the control that contains the text to which you want to apply a style.
4. In the right pane, expand the Text Style setting, and use its subsettings to specify the appropriate text styles. For
more information, see the inline help that is displayed in the bottom right pane when you select these settings.
See Also
Defining a Custom Style for the Wizard Interface
Using Styles, Brushes, and Control Themes to Customize the Wizard Interface
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
A brush specifies a solid color, a gradient, or an image for various elements of the wizard interface, such as the background
of wizard pages and controls. InstallShield lets you add custom brushes to your project and then apply those brushes to
various wizard interface elements.
2. In the Wizard Interface explorer, right-click Brushes and then click Add Brush. InstallShield adds a a new brush
under Brushes. Rename the brush as needed.
3. Select the brush and then configure its settings in the right pane.
Once you have added a brush, you can select it for various background-related settings in the Wizard Interface view. For
example, to specify the brush that you want to use by default for the background of the navigation area of the wizard
pages, use the Navigation Background setting.
See Also
Specifying the Background Brush for the Header, Body, and Navigation Areas of the Wizard Interface
Overriding the Default Background Brushes for a Wizard Page or Secondary Window
Using Styles, Brushes, and Control Themes to Customize the Wizard Interface
Wizard Interface View
Specifying the Background Brush for the Header, Body, and Navigation Areas of the Wizard
Interface
InstallShield 2020
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
By default, InstallShield enables you to use different brushes for the header, body, and navigation areas of your wizard
pages. In some cases, though, you may want to use only one brush (for example, a single background image or a vertical
gradient) that spans all three of those areas. The following instructions explain how to customize using three different
brushes or one brush.
Tip • For information on defining brushes, see Defining a Custom Brush for the Wizard Interface.
Using Three Different Brushes for the Header, Body, and Navigation Areas
Task To use three different brushes for the header, body, and navigation areas:
2. In the Wizard Interface explorer, click Wizard Pages. The global wizard interface settings are available in the right
pane.
3. In the Default Body Background setting, select the brush that you want to use as the background for the body area of
the wizard interface.
4. In the Header Background setting, select the brush that you want to use as the background for the header area of the
wizard interface.
5. In the Navigation Background setting, select the brush that you want to use as the background for the navigation
area of the wizard interface.
Important • Note that if you select a brush in the aforementioned background settings, you should delete any value in the
Full Wizard Background setting. The wizard interface supports use of a single brush for the full wizard background, or
separate brushes for the header, body, and navigation areas; it does not support specification of brushes for all four of those
areas simultaneously.
Using One Brush that Spans the Header, Body, and Navigation Areas
Task To use a single brush for the header, body, and navigation areas:
2. In the Wizard Interface explorer, click Wizard Pages. The global wizard interface settings are available in the right
pane.
3. In the Full Wizard Background setting, select the brush that you want to use as the background for the navigation,
body, and navigation areas of the wizard interface.
Important • Note that if you select a brush in the aforementioned setting, you should delete any values from the other
background settings: Default Body Background, Header Background, and Navigation Background. The wizard interface
supports use of a single brush for the full wizard background, or separate brushes for the header, body, and navigation areas;
it does not support specification of brushes for all four of those areas simultaneously.
See Also
Selecting the Format for the Wizard Interface
Defining a Custom Brush for the Wizard Interface
Overriding the Default Background Brushes for a Wizard Page or Secondary Window
Wizard Interface View
Overriding the Default Background Brushes for a Wizard Page or Secondary Window
InstallShield 2020
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
In most cases, each wizard page and secondary window in the user interface of an Advanced UI or Suite/Advanced UI
project has the same background. In some cases, you may want to override the default background for a specific wizard
page or secondary window in your project. You can do so by selecting a different brush for the background of that wizard
page or window.
2. In the Wizard Interface explorer, expand the Wizard Pages node or the Secondary Windows node, and then click the
wizard page or window to which you want to apply a brush. InstallShield displays the settings for the selected wizard
page or window in the right pane.
3. In the Body Background setting, select the brush that you want to use for the selected wizard page or secondary
window.
InstallShield changes the background of the selected wizard page or secondary window.
See Also
Selecting the Format for the Wizard Interface
Defining a Custom Brush for the Wizard Interface
Specifying the Background Brush for the Header, Body, and Navigation Areas of the Wizard Interface
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield enables you to define themes for wizard interface controls. A control theme is a collection of colors for various
parts of controls—text color, background color, and border color—and for various states of controls—such as clicked and
hovered. You can specify the control theme that you want to use for the controls in your user interface by default; this is
also the theme that is used for all of the navigation buttons (for example, Back buttons and Next buttons) in your user
interface. You can also override the theme for specific controls on wizard pages and windows in your user interface.
Control themes give buttons and other items in your installation’s user interface a flat look (without the three-dimensional
effects) that is reminiscent of the style of Windows Store apps.
• Check boxes
• Radio buttons
• Command links
2. In the Wizard Interface explorer, right-click Control Themes and then click Add Control Theme. InstallShield adds a
a new control theme under Control Themes. Rename the control theme as needed.
3. Select the control theme and then configure its settings in the right pane.
Once you have added a control theme, you can select it for various theme-related settings in the Wizard Interface view. If
you later want to change the appearance of controls that are based on that control theme, select the control theme and
edit its settings.
Changes that you make to a control theme affect all of the wizard interface elements that use that control theme.
See Also
Applying a Theme to a Control in the Wizard Interface
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield enables you to apply control themes to buttons, check boxes, radio buttons, and command links. If you later
want to change the appearance of the wizard interface elements that use a control theme, you can easily make changes to
the control theme, rather than separately editing each element that uses the control theme.
You can apply a control theme to a few individual controls and leave the remaining ones alone, or you can specify a global
theme for your project and override it for a few individual controls. Changing the theme at the global level does not change
the theme of the controls that have a per-control theme specified.
Note that you can apply control themes to navigation buttons at the global project level, but not at the individual control
level.
2. In the Wizard Interface explorer, click Wizard Pages. InstallShield displays the global wizard interface settings in the
right pane.
3. In the Default Control Theme setting, select the appropriate theme that you want to use by default for controls such
as buttons (including navigation buttons), check boxes, radio buttons, and command links.
InstallShield changes the theme of all of the controls that do not have a per-control theme selected.
Tip • If you want the installation to use user-chosen system colors for controls instead of the colors that are defined for a
particular control theme, select the (No Theme) option in the Default Control Theme setting.
2. In the Wizard Interface explorer, expand the Wizard Pages node or the Secondary Windows node, and find the
wizard page or window that contains the control (button, check box, radio button, or command link) to which you
want to apply a theme.
4. In the right pane, find the Control Theme setting, and select the theme that you want to use for the selected control.
Tip • To avoid overriding the default control theme for a selected control, select the (No Theme) option in the Control Theme
setting, or leave this setting blank.
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield lets you select from several different wizard formats for your installation’s wizard interface:
• Glass—The installation uses user-chosen system colors to display the caption bar, header, and navigation areas of the
wizard interface. It also uses the glass effect (translucency) that was introduced in Windows Vista for these same areas
of the wizard interface. Note that with this format, the installation ignores any brushes that you have defined for the
caption bar, header, and navigation areas of your wizard interface.
Note that some operating systems do not fully support this format. Thus, in some cases, the installation may use the
Wizard 97 format instead of the Glass format.
• Aero—This format typically has the same look and feel as the Glass format.
Note that some operating systems do not fully support this format. Thus, in some cases, the installation may use the
Wizard 97 format instead of the Aero format.
• Wizard 97—This format is the traditional wizard format. The installation uses the brushes that you have defined for
the various areas of your wizard interface.
• Wizard Lite—This format is similar to the Wizard 97 format, except that it does not include a header (the area that
shows the title, plus sometimes an image near the upper corner of the wizard page). The installation uses the brushes
that you have defined for the other areas of your wizard interface.
Note that 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, 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.
Note that the wizard interface editor in the Wizard Interface view in InstallShield does not use the Glass format or the Aero
format to show editable previews of the interface. If you select either of these formats for your Advanced UI or Suite/
Advanced UI project, the wizard interface editor uses the Wizard 97 format to show editable previews.
Task To select the format that you want to use for wizard pages in your wizard interface:
3. In the right pane, find the Wizard Format setting and select the appropriate option.
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield enables you to add a new blank wizard page to your project.
2. In the Wizard Interface explorer, right-click Wizard Pages and then click Add Blank Page.
InstallShield adds a a new wizard page under Wizard Pages. Rename the wizard page as needed. Configure its settings in
the right pane, and use the center pane to preview it and modify its layout.
See Also
Sequencing Wizard Pages
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield enables you to add various predefined wizard pages to your Advanced UI or Suite/Advanced UI project.
Examples include:
• A page that allows end users choose the installation directory for an .msi package
• A page that lets end users enter customer information and serial numbers
• A page that shows a feature tree, as well as feature descriptions and sizes, and allows end users to select which
features to install
• A database login page that allows end users to enter database server login information (database server name,
authentication credentials, database catalog name, etc.) in order to establish a connection to the database server that
is targeted by one or more .msi packages in the suite
2. In the Wizard Interface explorer, right-click Wizard Pages and then click Add Predefined Page. The User Interface
Wizard opens.
InstallShield adds the new predefined page to your project. Configure its settings in the right pane, and use the center pane
to preview it and modify its layout.
Note • When you add the browse-for-installation-folder type of wizard page (called BrowseFolder) to your project,
InstallShield adds a placeholder image control to it so that you can display a lock image on the page. Ensure that you either
configure the control’s Resource setting to indicate the file that you want to display with this control, or, to exclude an image,
delete the image control.
See Also
Sequencing Wizard Pages
User Interface Wizard
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield enables you to add a new blank secondary window to your project.
2. In the Wizard Interface explorer, right-click Secondary Windows and then click Add Blank Window.
InstallShield adds a new window at the end of the list of secondary windows. Rename the window as needed. Configure its
settings in the right pane, and use the center pane to preview it and modify its layout.
See Also
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
Use the Wizard Interface view to indicate the order in which your Advanced UI or Suite/Advanced UI installation should
display the wizard pages at run time. The wizard pages are listed under the Wizard Pages node in this view in the order that
the installation displays them at run time.
2. In the Wizard Interface explorer, under the Wizard Pages node, right-click the wizard page whose order you want to
change, and then click Move Up or Move Down.
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
Use the Wizard Interface view to edit the layout and behavior of wizard pages and secondary windows in your installation.
See Also
Defining a Custom Style for the Wizard Interface
Adding a Control to a Wizard Page or Secondary Window
Changing the Tab Order of Controls on a Wizard Page or Secondary Window
Populating Combo Box and List Box Controls in the Wizard Interface
Configuring an Action for an Element in the Wizard Interface
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
If you select a wizard page or secondary window in the Wizard Interface view, the toolbar that InstallShield shows directly
above the wizard interface preview pane includes several different buttons and other controls that let you add new
controls.
2. In the Wizard Interface explorer, click the wizard page or secondary window that you want to modify. The wizard
editor in the center pane shows the page or secondary window.
3. In the toolbar above the wizard interface preview pane, click the appropriate New Control button (the Label, Text Box,
Button, or Combo Box button), or select one of the control types that are listed in the drop-down list next to the
control buttons. For information about each of the available types of controls, see Wizard Interface View Toolbar.
InstallShield adds the control near the upper-left corner of the body area of the page or secondary window. In
addition, InstallShield adds a subnode for the control under the selected wizard page or window.
4. Place the cursor in the middle of the control, and then drag it to move it to the appropriate location.
Tip • The order in which the controls are listed under the a wizard page’s node matches the tab order.
If you are using more than one group of radio button controls on a page, ensure that the Style setting includes WS_GROUP for
the first radio button of each group.
See Also
Wizard Interface View Toolbar
Wizard Interface View
Control Description
Billboard A billboard control is used to display data that can be updated in response to control
events. You can use a billboard, for example, to display the progress of a protracted
custom action.
Button
Check List
Combo Box
Frame
Group Box
Hyperlink
Image
Image Button
Label
List Box
Password
Progress Bar
Radio Button
Control Description
Text Box
Tree View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
In most cases, end users can use the TAB key to move the focus from one control on a wizard page or window to another.
By default, the tab order is the order in which the controls were added to the wizard page or window.
Task To change the tab order of the controls on a wizard page or window:
2. In the Wizard Interface explorer, expand the node of the wizard page or secondary window whose tab order you want
to modify.
Each control on the page or window has its own subnode. The controls are listed in tab order. That is, the first control
under a page node is the first control that receives focus on that page.
3. Right-click the control that you want to resequence in the tab order, and then click Move Up or Move Down.
4. Continue moving the controls as needed until the order that the controls are listed under the page reflects the
appropriate tab order.
Note that in some cases, a control may not be included in the tab order. For example, a disabled control would not receive
focus as an end user tabs from one control to another control.
See Also
Wizard Interface View
Designating Keyboard Shortcuts and Using Ampersands (&) in the Wizard Interface
InstallShield 2020
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
In wizard interface strings, an ampersand (&) is a special character that sometimes designates a keyboard shortcut, but
other times indicates that a literal ampersand should be displayed. For button, check box, and radio button controls, a
single ampersand always designates the keyboard shortcut that is used to click or select the control; a double ampersand
(&&) indicates that a single ampersand should be displayed. For label controls, the interpretation of an ampersand
depends on the style of the label control in which the ampersand is used.
Enter your &serial SS_NOPREFIX = False Enter your serial When an end user presses the ALT key, the
number for New && number for New & “s” in the string is underlined. The
Improved Product Improved Product keyboard shortcut of ALT+s moves the
focus to the control that appears directly
after this label in the tab order.
Enter your serial SS_NOPREFIX = True Enter your serial The True value for the SS_NOPREFIX
number for New & number for New & constant prevents any ampersands in the
Improved Product Improved Product control’s string from being used to
designate a keyboard shortcut.
By default, when you add a new label control to your wizard interface, the SS_NOPREFIX subsetting under the label
control’s Style setting is set to False. You can change this value as needed.
If your wizard interface includes a label control that should never contain a keyboard shortcut, consider selecting True for
the SS_NOPREFIX subsetting of that control. This ensures that any ampersands that are included in the string entries for
such controls are not inadvertently interpreted as keyboard shortcuts.
If your product name includes an ampersand, you may want to use two separate product name properties in your wizard
interface—one property whose value uses a single ampersand, and one property whose value uses the escaped ampersand
(a double ampersand). Depending on the type and style of each control that contains the product name, you would use the
appropriate product name property as needed—for example:
Table 4-35 • Sample Usage of Two Different Properties for a String that Includes an Ampersand
See Also
Changing the Tab Order of Controls on a Wizard Page or Secondary Window
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
Each wizard page in an Advanced UI or Suite/Advanced UI project can have one or more of the following built-in navigation
buttons:
Next Move to the next wizard page in the interface, skipping any pages whose Visible conditions
evaluate to false.
Clicking this button has no effect if the current wizard page is the last page in the interface.
The Next navigation button behaves similarly to controls that use a Set Active Page action, which
triggers a move to a specific page.
Back Move to the previous wizard page in the interface, skipping any pages whose Visible conditions
evaluate to false.
Clicking this button has no effect if the current wizard page is the first page in the interface.
The Back navigation button behaves similarly to controls that use a Set Active Page action, which
triggers a move to a specific page.
Cancel Display a message box with question IDS_SUITE_CONFIRMCANCEL; on Yes, cancel the wizard and
move to the last wizard page.
In most cases, the last wizard page should not show a Cancel button, since cancelling the
installation at that point does not have any effect. If a Cancel button is displayed, clicking it would
result in closing the wizard.
Install Start the installation and move to the next wizard page.
The Install navigation button behaves similarly to controls that use an Install action, which start
the installation and then move to a specific wizard page.
Finish After a successful installation or maintenance, if a restart is required, ask whether to restart
(message IDS_SUITE_ASKREBOOT), and then trigger the appropriate response. In either case
(required or not required, immediate restart or delayed restart), close the wizard.
2. In the Wizard Interface explorer, click the wizard page whose buttons you want to modify.
3. In the Navigation area of the grid on the right side of the view, do the following:
• To include a specific button on the wizard page, select Yes in that button’s setting, and then configure the
subsettings under that button’s setting as needed.
• To exclude a specific button from a wizard page, select No in that button’s setting, and then configure the
subsettings under that button’s setting as needed.
To learn about changing the default behavior of navigation buttons, see Overriding the Default Behavior of a Navigation
Button on a Wizard Page.
See Also
Wizard Interface View
InstallShield 2020
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
If the Click event of a navigation button includes either a Set Active Page action or an Install action, and if that action moves
through the wizard interface, this prevents the default behavior described above. The default behavior is prevented even if
the scheduled action is skipped because of a false condition for the action.
For example, you may want to override the default behavior for the Install button: instead of moving to the next wizard
page in the interface, you may want the installation to proceed to a specific wizard page. In this scenario, you must add an
Install action to the Install button’s Click setting, and specify the specific subsequent page. If you then add a condition to
the action, and the condition prevents the Install action from running, the default behavior for the Install button is
suppressed. That is, the installation does not start when the end user clicks the Install button. (Note that in this case, you
may want to define a condition for the navigation button’s Enabled setting to ensure that the Install button is disabled if
appropriate. Otherwise, end users may become confused when they are able to click an Install button that has no effect.)
Note that extension DLLs actions cannot prevent the default action except by actually calling the corresponding methods
on the ISuiteUIExtension interface. The Advanced UI or Suite/Advanced UI engine cannot determine whether the extension
chose to call the method. If you need an extension action to override the default behavior, but only navigate or install
under certain conditions, add a Set Active Page or Install action with a false condition such as the empty None group.
See Also
Using Navigation Buttons on Wizard Pages
Wizard Interface View
Populating Combo Box and List Box Controls in the Wizard Interface
InstallShield 2020
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield lets you add to the wizard interface one or more combo box controls and list box controls with predefined
selectable options. The process involves configuring the control’s settings to define the content for the selectable options.
The process also involves the use of two properties: one that defines the list of options that you want to display in the
control, and one that the installation uses to store the option that the end user selects at run time.
Task To populate a combo box control or a list box control with predefined options:
1. Associate the control with two properties: one that defines the list of options that you want to display in the control,
and one that the installation uses to store the option that the end user selects at run time:
b. In the Wizard Interface explorer, expand the wizard page or secondary window that you want to modify, and
then select the combo box control or list box control that you want to configure.
c. In the Property setting, enter the name of the Advanced UI or Suite/Advanced UI property—for example,
SELECTIONPROPERTY—that you want to associate with the control. At run time, the installation uses this property
to store the value that the end user selects.
d. In the Content Property setting, enter the name of the Advanced UI or Suite/Advanced UI property that you want
to use to identify the options that you want to list in this control—for example, CONTROLOPTIONS.
2. Define the list of options that you want to display in the combo box control or the list box control:
a. In the Content Property setting, click the ellipsis button (...). The Edit List Options dialog box opens.
b. In the Text column, enter one of the options that you want to display in the control.
When you type a value for this setting, you are creating a string entry and setting its initial value for all of the
languages that are currently in the project. As an alternative to typing a new value, you can click the ellipsis
button (...) in this setting to select an existing string. For more information, see Using String Entries in
InstallShield.
c. In the Value column, enter the value that you want to associate with the list option text that you entered in step
2b. This is the property value that is stored in SELECTIONPROPERTY—the property that you entered in step 1c—if
the end user selects the list option that you entered in the Text column.
d. To add additional text-value pairs, click the New button, and then complete the fields in the row that
InstallShield adds.
Text Value
ID_Option1 Value1
ID_Option2 Value2
ID_Option3 Value3
The installation displays the list options in the order that you list them on this dialog box. To change the order of
the list options, select a row, and then click the Up or Down buttons as needed. To select multiple consecutive
rows, click the first row, press and hold Shift, and then click the last row. To select multiple non-consecutive
rows, click one of the rows, press and hold down CTRL, and then click each additional row.
3. Click OK.
Specifying the Default Option for the Combo Box Control or the List Box Control
If you want to specify the default option for a combo box control or a list box control, use the Property Manager view to set
the value of the Advanced UI or Suite/Advanced UI property equal to the property value that corresponds with the default
selectable option. Thus, if you want ID_Option3 to be selected by default, add the SELECTIONPROPERTY property to the
Property Manager view, and set its value to Value3. To leave the control blank by default, do not define the property in the
Property Manager view.
Using the Proper Syntax for Identifying the Control Options Through a Property Value
In the first step in the aforementioned procedure, it is necessary to create a new Advanced UI or Suite/Advanced UI
property, and to set its value to the options that you want to be listed in the combo box control or the list box control. It is
also necessary to associate each option with a corresponding value. The following format is used:
ID_Option1\rValue1\nID_Option2\rValue2\nID_Option3\rValue3
ID_Option1 corresponds with Value1, ID_Option2 corresponds with Value2, and ID_Option3 corresponds with Value3.
ID_Option1, ID_Option2, and ID_Option3 represent string identifiers that are defined in the String Editor view. The strings
that are associated with those string identifiers indicate the selectable options that you want to be displayed in the control;
the order in which you specify these options is the same order that the installation uses to list the options in the control at
run time.
\r is the separator between the name of each selectable option and the corresponding property value that you want to
associate with it.
Value1, Value2, and Value3 are the possible property values that you want to be stored in SELECTIONPROPERTY—the
property that you entered in step 4.
Thus, if the end user selects ID_Option2 in the control, the installation sets the value of SELECTIONPROPERTY as Value2.
Note that there are no spaces before or after the separators (\r or \n).
Working with End-User Data from a Combo Box Control or a List Box Control
At run time, end users can make a single selection from the combo box or the list box; this sets the control’s property
(which is SELECTIONPROPERTY in the aforementioned procedure) to the value that is associated with the selected option—
for example, Value1, Value2, or Value3. You can trigger different types of behavior based on the value of the
SELECTIONPROPERTY property. Examples are:
• You can enable or disable a control on the wizard page or secondary window. To do this, use the control’s Enabled
setting to define a Property type of condition and tie the enabled state of the control to a particular value of the
property.
• You can display or hide a particular control on a wizard page or secondary window. To do this, use the control’s Visible
setting to define a Property type of condition and tie the enabled state of the control to a particular value of the
property.
• You can display or skip a particular wizard page or secondary window. To do this, use the wizard page’s or secondary
window’s Visible setting to define a Property type of condition and tie the enabled state of the wizard interface to a
particular value of the property.
• You can use the value of the Advanced UI or Suite/Advanced UI property to set a particular property in a package in the
Advanced UI or Suite/Advanced UI installation. To do this, use the command line and silent command line settings
that are available as subsettings in the Operation area of the grid in the Packages view. For more information, see
Using Advanced UI and Suite/Advanced UI Formatted Expressions to Dynamically Configure Command Lines.
See Also
Adding a Control to a Wizard Page or Secondary Window
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield lets you implement validation for some of the various wizard interface controls. For example:
• You can ensure that end users enter a serial number in a text box in a specified format.
• You can configure validation for a text box control to check whether the folder an end user specifies in the text box is
valid.
• You can prevent end users from selecting certain combinations of check boxes that do not work together.
Validation for a control checks the property that is associated with that control. When an end user clicks a check box, for
example, the associated property is potentially changed to one of two new values. Validation offers a method for checking
whether the new value is appropriate.
Text box, Validation occurs when the entry in the control changes.
password box
Button, Validation occurs when the end user clicks the control.
command link,
check box,
radio button,
image button
Combo box, Validation occurs when the selection for the control changes.
list box,
checked list box,
feature selection tree
You can use the subsettings under the Text Style setting to specify different text styles for the control to give end users a
visual indication when the control is in various states (default, valid, or invalid).
You can also use the subsettings in the Events area to trigger an action when the end user clicks or uses the control. If you
have actions and validation configured for a control, the validation runs before the actions. For more information about
actions, see Configuring an Action for an Element in the Wizard Interface.
2. In the Wizard Interface explorer, select the wizard page or secondary window that you want to modify.
4. In the Validate setting, click the Validation button and then point to the type of validation that you want to occur.
One of the types of validation lets you call a function in a DLL file that you have created. If your project includes any
DLL files in the Support Files view, InstallShield makes them available in this list, and lets you overwrite the validation
function name with the function in the DLL that you want to call.
The following table describes the types of validation that are available. Note that some types of validation are applicable to
only certain types of controls. For example, the value length validation is applicable only to the text box and password box
controls.
Existing File This type of validation checks whether the value of the property that is
associated with this control contains the fully qualified path and name of a file
that is present. The end user typically sets the value of the property when
entering the path and file name in this control.
Existing Folder This type of validation checks whether the value of the property that is
associated with this control contains the fully qualified path and name of a
folder that is present. The end user typically sets the value of the property
when entering the path and folder name in this control.
New File in Existing Folder This type of validation checks whether the value of the property that is
associated with this control contains the fully qualified path and name of a file
that is not present. The end user typically sets the value of the property when
entering the path and file name in this control.
Note that the path for the file must exist for this type of validation.
Value Length This type of validation checks whether the value of the property that is
associated with this control contains a certain number of characters. The end
user typically sets the value of the property when entering text in this control.
To configure this type of validation, specify the minimum and maximum values
in the subsettings under this setting.
Value Mask This type of validation checks whether the value of the property that is
associated with this control matches a particular format. The end user typically
sets the value of the property when entering information such as a serial
number in this control.
To configure this type of validation, specify the required format in the Pattern
setting under this setting. Enter any of the following characters in place of a
digit:
# % @
& ^ ? ’
Browse for DLL Action This type of validation calls a function in a DLL file that you have created and
added to your project through the Support Files view. For example, you can use
a DLL file to check the validity of the property’s value—that is, the input that the
end user enters for the control.
See Also
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield lets you define actions that are launched when a wizard page or secondary window is opened or closed. This
capability enables your installation to perform any initialization such as dynamically retrieving values for a combo box. It
also lets you schedule actions to occur before the wizard interface is displayed at run time.
In addition, InstallShield lets you define actions that an end user triggers when using some of the various wizard interface
controls. For example, you can add a Print button to a LicenseAgreement wizard page, and define a print action for that
button control; when an end user clicks the Print button, the Print dialog box opens, enabling the end user to print the
license agreement.
If you have actions and validation configured for a control, the validation runs before the actions. The actions run for both
validation success and validation failure. They also run when the splash page is dismissed, when an image button gets or
loses focus, or when an end user scrolls to the bottom of a rich text box. For more information about validation, see
Configuring Validation for a Control on a Wizard Page or Window.
2. In the Wizard Interface explorer, select the wizard page or secondary window that you want to modify.
• To configure the action of one of the navigation controls (the Next, Back, Cancel, Install, or Finish buttons)—In the
right pane, expand the settings for the control whose action you want to modify.
• To configure the action of any of the other controls—In the wizard editor, select the control whose action you
want to modify.
• To schedule an action to run when the selected wizard page or window opens: In the Page Entered setting, point
to the New Action button, and then click the type of action that you want to configure.
• To schedule an action to run when the selected wizard page or window closes: In the Page Exited setting, point
to the New Action button, and then click the type of action that you want to configure.
• To schedule an action for a control: In the Click setting, or in an action-related setting under the Events setting,
point to the New Action button, and then click the type of action that you want to configure.
If you enter more than one action statement, the actions are run in the order in which they are listed in the action setting.
One of the types of actions lets you call a function in a DLL file that you have created. If your project includes any DLL files in
the Support Files view, InstallShield makes them available in this list, and lets you overwrite the action function name with
the function in the DLL that you want to call.
The following table describes the types of actions that are available.
Set Property This type of action sets a specific property to a specific value.
Install This type of action starts the installation and moves to a specific wizard page.
Print This type of action launches the Print dialog box, enabling an end user to print
the specified file.
Browse for Folder This type of action launches the Browse for Folder dialog box when an end user
clicks the control.
When the end user selects a folder in this dialog box and clicks the OK button,
the dialog box closes, and the installation sets the value of a specific property
to the full path of the folder that the end user selected.
To configure this type of action, configure the subsettings under this action.
Browse for File This type of action launches the file browse dialog box when an end user clicks
the control.
When the end user selects a file in this dialog box and clicks the Open button,
the dialog box closes, and the installation sets the value of a specific property
to the full path and file name of the file that the end user selected.
To configure this type of action, configure the subsettings under this action.
Browse for New File This type of action launches the new-file browse dialog box when an end user
clicks the control. The dialog box lets the end user browse to a location where a
new file should be saved.
When the end user specifies a file in this dialog box and clicks the Save button,
the dialog box closes, and the installation sets the value of the property that
you have specify in the Property subsetting to the full path and file name of the
file that the end user specifies.
To configure this type of action, configure the subsettings under this action.
Set Active Page This type of action moves to a specific wizard page.
Show Window This type of action shows a secondary window as a modal window.
Close Window This type of action closes a main wizard page or secondary window, or in some
cases, provides conditional closing of a secondary window.
The behavior of the Close Window action differs slightly on wizard pages and
secondary windows, as noted following:
• For wizard pages, the Close Window action prompts the end user to cancel
if its Return Code parameter is set to IDCANCEL (and then interrupts the
wizard if the end user specifies Yes). For all other Return Code IDs, the
wizard immediately closes.
• For secondary windows, the Close Window action closes the secondary
window and in special cases such as with the ISRMFilesInUse and
ISRMFileInUse secondary windows, the specified Return Code value is
returned.
• ISDownloadProgress
• ISPromptForSourceMedia
• ISFilesInUse
• ISRMFilesInUse
• ISUpgradeParcel
• ISSQLBrowse
Stop Event This type of action allows you to conditionally stop further actions from being
processed. For example, this action can be used to prevent the default
behavior of a button from occurring.
This type of action launches an action in the installation. The action can be any
of the ones that are defined in the Events view of the Suite/Advanced UI
project. For more information, see Using Actions to Extend the Behavior of a
Suite/Advanced UI Installation.
This type of action launches a secondary window that lets end users browse to
and load a publisher profile file (.publishsettings) that contains the
configuration settings that they want to use for the Web Deploy package. For
more information, see Adding a Web Deploy Package to a Suite/Advanced UI
Project.
Database
Browse for DLL Action This type of action calls a function in a DLL file that you have created and added
to your project through the Support Files view. For example, you can use a DLL
file to trigger custom behavior.
See Also
Wizard Interface View
Referring to Feature States and Other Feature Data in the UI of an Advanced UI or Suite/Advanced UI Project
Using Images, Text Files, and Other Objects in the Wizard Interface
InstallShield 2020
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
Any images, text files (such as End-User License Agreements), and other files that you want to use in the wizard interface of
your Advanced UI or Suite/Advanced UI project are included in your project as support files. Support files are files that are
installed to the target system for use only during the installation process. These files are automatically removed from
target system when the installation is complete.
If your project supports multiple languages, you can add language-specific support files to the appropriate language-
specific areas of the Support Files view. At run time, the Advanced UI or Suite/Advanced UI installation displays the
appropriate language-specific support files.
See Also
Support Files View (Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI Projects)
Wizard Interface View
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
• Items that are drawn by the engine are scaled according to the target system’s DPI settings. Thus, if a target system
has a DPI of 200%, the check box control is scaled accordingly.
• The engine considers the scale factor and language when displaying images and other resources that you are
including in the wizard interface.
For example, when the engine determines that the scale factor should be 150 and that the appropriate language is English,
it looks for resources that have the string scale-150 in their path or file name. It searches the following paths in the order
listed when searching for image.png on the target system:
1. [SUPPORTDIR]0409\scale-150\image.png
2. [SUPPORTDIR]0409\image.scale-150.png
3. [SUPPORTDIR]0409\image.png
4. [SUPPORTDIR]scale-150\image.png
5. [SUPPORTDIR]image.scale-150.png
6. [SUPPORTDIR]\image.png
Note that matching the language takes precedence over matching the correct DPI.
InstallShield includes scale-150 and scale-200 images for the built-in default images that are included in Advanced UI and
Suite/Advanced UI projects. If you want to include custom resources in your project, use the Support Files view to add
appropriately scaled images.
See Also
Support Files View (Advanced UI, Basic MSI, InstallScript Object, and Suite/Advanced UI Projects)
Wizard Interface View
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
InstallShield has many settings that let you specify text strings that should be displayed to end users. For example, when
you enter a value for the Display Name and Description settings for a feature, you are configuring the feature name and
description that may be displayed in the CustomSetup dialog at run time. Whenever you enter a value for such a setting
that may need to be localized for one or more languages, InstallShield automatically creates a string entry for each
language that your project supports. Each string entry consists of a language-independent identifier and a corresponding
language-specific value. At run time, the installation displays the appropriate translated string values. Using string entries
instead of hard-coded text enables you to keep the code for your installation completely separate from any language-
specific strings that you may want to be displayed during the installation.
To help streamline the process of localizing a project, all of the text strings that may be displayed at run time during the
installation process are available in one consolidated view: the String Editor view. You can use this view to edit the strings
for everything from button text to feature descriptions. You can also use this view to export each language’s string entries
to a file, translate the values that are listed in the file, and then import the translated file into your project.
See Also
Translating String Entries
Run-Time Language Support in InstallShield
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
Edition • The Premier edition of InstallShield includes support for creating multilingual installations.
Note • To add additional languages to your project, use the Setup Language setting in the General Information view.
Your project contains a string entry for every localizable text string and for each language that your project supports. The
String Editor view shows the collection of language-independent identifiers and corresponding language-specific values
for your project.
Note the following details about string entries in projects that include support for multiple languages:
• The values for all of the localizable settings throughout InstallShield—such as the Display Name and Description
settings for a feature—use the project’s default language (which you can specify in the String Editor view). If you edit
the value of one of these localizable settings, InstallShield simultaneously updates the string entry’s value in the
String Editor view for the default language.
Likewise, if you use the String Editor view to modify a string value for your project’s default language, InstallShield
simultaneously updates the settings in the other InstallShield views that display the value of that string entry.
• Each language that is supported by your project uses the same set of string identifiers.
Therefore, if you add a string entry to a project, InstallShield uses the same string identifier for each language. If you
rename a string identifier, InstallShield renames the string identifier for all languages. If you delete a string entry,
InstallShield deletes it from each language.
• If you add a new language to your project, InstallShield adds to that language the same string identifiers that are
available in the other languages that are in your project. For default string entries—that is, those that are available for
the built-in dialogs and other user-interface elements—InstallShield adds the already-translated string values. For
custom string entries that you have created, InstallShield uses the string values from the default language for the new
language. You can modify any string values as needed for the new language.
When you finish authoring your project, you can export the string entries for each language to text files, and send the text
files out for translation. Once the string entries in the text file are translated, you can import them into your project.
See Also
String Editor View
Setting the Default Project Language
Translating String Entries
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
Note • Localization of Windows App packages requires the Windows 10 SDK be installed on the same machine as
InstallShield. If it is not present, InstallShield will build a Windows App package (.appx) containing only the default language.
Instead of hard-coding strings throughout your project, you can use string entries in areas of InstallShield that accept
localizable text. The manner in which you select a string entry differs depending on where you need to use it.
In this example, ID_STRING24 is the string identifier that is used for the Display Name setting. My New Feature is the string
value for the project’s default language.
Task To work with a setting that accepts a localizable text string entry, do one of the following:
• To enter a new text string that is not present anywhere else in the project, type the text string that you want to use.
InstallShield automatically assigns a new string identifier to the value that you enter.
If your project includes support for multiple languages, InstallShield adds the new string identifier to all of your
project’s languages, and uses the string value that you entered as the value for all languages.
• To look at a list of existing string entries that are used in the project, click the ellipsis button (...) that is displayed on
the right when you click the setting’s value. InstallShield opens the Select String dialog box, which lets you select an
existing string entry or create a new string entry.
Caution • Do not confuse editing an existing string value with entering a new string identifier by entering text in an
InstallShield setting. Once you have selected a string identifier for a setting, deleting the localizable text in the setting merely
deletes the current string value; it does not replace the current string identifier with a new one.
Dialog Editor
Many of the controls in the Dialog Editor accept strings that are displayed to the end user. For example, the Text and
Tooltip properties always require localizable text.
Using a string entry in the Dialog Editor is similar to selecting string identifiers in other areas of InstallShield.
Task To work with the Dialog Editor and a control’s property that uses localizable text, do one of the following:
• Click the control’s property sheet and edit the string. Doing so changes the value of the string entry for the current
language. When you enter a text value without first selecting a string, InstallShield creates a new string identifier for
your project.
If your project includes support for multiple languages, InstallShield adds the new string identifier to all of your
project’s languages, and uses the string value that you entered as the value for all languages.
• When you click a localizable property’s value to edit it, an ellipsis button (...) appears inside the property sheet. Click
the ellipsis button to view the string entries for the current language.
The major difference between the dialog control properties and the settings in other views in InstallShield is that the other
views always display the string value for the default language. When you edit a dialog’s layout, however, you must first
select the language of the dialog. Then, all strings displayed in the dialog and in the property sheet are from the current
language of the dialog that you are editing.
1. Place the cursor at the point in your script where you want the string identifier to be inserted.
2. On the Edit menu, point to Insert and click String Entry. The Select String dialog box opens.
• To use an existing string entry, click the row that contains the string entry that you want to use in your script.
• To create a new string entry, click the New button. The String Entry dialog box opens, enabling you to create a
new string identifier and value.
4. Click OK.
InstallShield places the string identifier in your script preceded by the at (@) symbol.
Tip • Although you can include hard-coded user-interface strings directly in InstallScript code, it is recommended that you
avoid doing this. Strings that are hard coded in InstallScript code are not stored as Unicode; thus, they are displayed correctly
only when the installation is run on systems that have the correct code page. Adding strings to a project through the String
Editor view and referencing the associated string identifiers from InstallScript code eliminates this issue.
What Happens with String Entries at Build Time and Run Time
InstallShield stores string entries in the ISString table of your InstallShield project file (.ism). At build time, InstallShield
uses the string values instead of the string identifiers when it is creating your release in most cases. That is, the string
identifiers are not built into the release, and the string identifiers are not available at run time.
The one exception of when InstallShield does use string identifiers in a build is if your project includes InstallScript code. In
this scenario, the release that InstallShield builds includes string tables that contain all of the string entries. These string
tables make it possible for you to use string identifiers in your InstallScript code instead of hard-coded text strings. At run
time, the installation replaces string identifiers with string values as needed.
See Also
String Editor View
Select String Dialog Box
Setting the Default Project Language
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
The String Editor view lets you create a new string entry that you can later reference in one of the settings in InstallShield,
in one of your project’s dialogs, and in your InstallScript code.
3. In the String Identifier box, specify the language-independent string identifier that you want to use for your string
entry, or leave the new default string identifier that InstallShield enters in this box for you.
4. In the Value box, specify the localizable text string that you want to use for the string entry.
5. In the Comments box, you can optionally specify an internal note about the string entry. The comments are not
displayed at run time.
6. Click OK.
InstallShield adds a new row in the String Editor view for the new string entry.
Tip • If your project includes support for multiple languages, InstallShield adds the string entry to all of your project’s
languages, and it uses the string value that you entered as the value for all languages. You can edit the string values for
languages as needed.
Note • Since you must use a string identifier throughout InstallShield for settings that accept localizable text, InstallShield
adds a new string entry to your project whenever you try typing a value into a setting without selecting an existing string
identifier.
See Also
String Editor View
Translating String Entries
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
The String Editor view contains a spreadsheetlike table that lets you modify string entries in your project.
• To overwrite all of the text in a table cell, click the table cell and then type your new identifier, value, or
comments.
• To place the cursor at a particular place within a table cell, double-click that place. Then type your change.
Note that if you rename a string identifier, InstallShield renames the string identifier for all languages in your project.
When you edit a string entry, InstallShield updates the Modified column with the date and time that you made the change.
You can sort the string entries in the String Editor view by modified date. This is helpful if you want to identify which strings
have been modified since the strings were last translated.
Tip • If you are editing a localizable setting from within one of the other views in InstallShield, you can click the ellipsis button
(...) in that setting. Doing so opens the Select String dialog box, which lets you specify which string entry you want to use for the
selected setting.
Project • In Basic MSI, InstallScript MSI, and Merge Module projects, some of the string values contain Windows Installer
properties inside square brackets—for example, Install [ProductName]. At run time, the property and brackets are replaced
by the property value.
String values may also contain font information in curly brackets—for example, {&MSSansBold8}OK. The font information
indicates style details that should be used to display the strings at run time.
See Also
String Editor View
Select String Dialog Box
Translating String Entries
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
String identifiers are used throughout InstallShield projects. If you want to see where a particular string identifier is used in
your project, you can perform a search in the String Editor view.
Task To find all the occurrences of a particular string identifier within your project:
2. Select the row that contains the string identifier for which you want to search.
To select multiple consecutive rows, click the first row, and then press SHIFT while clicking the last row. To select
multiple nonconsecutive rows, click the first row, and then press CTRL while clicking each additional row.
InstallShield displays the search results on the Results tab in the Output window. The Results tab indicates how many
times the string identifier is used. In addition, it indicates the location in the Direct Editor view where the string identifier is
used.
If the string identifier is not used in the project, the Results tab shows that zero occurrences were found.
Note • InstallShield does not search the project’s InstallScript files (.rul) for instances of the string identifier.
See Also
String Editor View
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
The String Editor includes support for standard find-and-replace functionality. This functionality may be useful if you want
to search for specific strings in your project and replace them with revised strings.
2. Click the Find String button. The Find dialog box opens.
3. In the Find what box, type the string that you want to find.
InstallShield finds the first instance of the string that you specified.
2. Click the Find and Replace button. The Replace dialog box opens.
3. In the Find what box, type the string that you want to replace.
See Also
String Editor View
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
If you no longer need a particular string entry in your project, you can delete it.
Note that if you delete a string entry, InstallShield deletes it from each language in your project.
See Also
String Editor View
Setting the Default Project Language
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
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.
If you try to delete the setting’s value, you are actually deleting the string value for the current language. In that case, the
string identifier with an empty value is used for the setting.
Therefore, if you want to remove a string identifier from a localizable setting, you must replace it with a different string
identifier, or add a new string identifier.
For information on replacing a string identifier, see Editing a String Entry. To learn how to create a new string identifier, see
Adding a String Entry.
Displaying Billboards
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
You can add billboards to your projects to display information to end users during the installation process. The billboards
can be used to communicate, advertise, educate, and entertain end users. For example, billboards can present overviews
on new features of the product being installed or other products from your company. Each billboard is a file that you or
your company’s graphics department creates for complete control over the look and feel of the file transfer.
Project • Support for billboards differs, depending on which project type you are using. To learn more about billboards, see
the appropriate section:
You can add billboards to your projects to display information to end users during the installation process. The billboards
can be used to communicate, advertise, educate, and entertain end users. For example, billboards can present overviews
on new features of the product being installed or other products from your company. Each billboard is a file that you or
your company’s graphics department creates for complete control over the look and feel of the file transfer.
See Also
Billboards View
Types of Billboards for Basic MSI Projects
Adding an Adobe Flash Application File Billboard to a Basic MSI Project
Adding Image Billboards to a Basic MSI Project
If a target system does not have the Adobe Flash Player, which is used to display Flash application files, the installation can
detect that and display image billboards in place of the Flash billboard. Therefore, if you include a Flash billboard in your
project, it is recommended that you also include one or more image billboards in your project.
Note • You can add more than one image billboard to a project, but only one Adobe Flash application file billboard.
See Also
Adding an Adobe Flash Application File Billboard to a Basic MSI Project
Adding Image Billboards to a Basic MSI Project
Setting the Billboard Order in a Basic MSI Project
InstallShield offers support for three different billboard styles. For example, with one style, the installation displays a full-
screen background, with billboards in the foreground, and a small progress box in the lower-right corner of the screen.
With another style, the installation displays a standard-size dialog that shows the billboards. The bottom of this dialog
shows the progress bar.
Following are descriptions and sample screen shots of each type of billboard.
Figure 4-28: Fullscreen Billboard with Small Progress (Displayed in Lower Right)
In the sample screen shot, the billboard is the blue-green rectangle image in the center. Some of the configurable billboard
settings were set as follows:
• Origin—Centered
• Title—A B C
• Background Color—Yellow
In the sample screen shot, the billboard is the blue-green rectangle image. Its size is 544 pixels wide by 281 pixels high.
As shown in the sample screen shot, the progress bar is shown, but no billboard is displayed. The black background is the
end user’s desktop.
See Also
Specifying Which Type of Billboard to Use in a Basic MSI Project
InstallShield 2020
Task To specify which type of billboard you want to use in your installation:
2. In the center pane, click the Billboards explorer. InstallShield displays the Billboard Type setting in the right pane.
To see samples of each type of billboard, see Types of Billboards for Basic MSI Projects.
See Also
Billboard File Types for Basic MSI Projects
InstallShield lets you display a Flash application file billboard during the file transfer process. Flash application files can
consist of videos, movies, sounds, interactive interfaces, games, text, and more—anything that is supported by the .swf
type of file. It is recommended that files such as Flash video files (.flv) and MP3 audio files be embedded in the .swf file so
that they are available locally on the target system during file transfer. Although .swf files can reference external files that
you can post on a Web site, this external implementation would require that end users have an Internet connection.
Task To add an Adobe Flash Application File billboard to your installation project:
2. In the Billboards explorer, right-click Adobe Flash Application File (.swf) and then click New Billboard. InstallShield
adds a new billboard item with the name NewBillboard1.
3. Type a name for the billboard item. This name is used to help you identify the item while you are creating your
installation; the name is not displayed during the installation.
Note • If the version of Flash or other tool that you use to create your .swf file is newer than the version of the Flash Player that
is installed on a target system, it is possible that some of the Flash features may not work as expected on that target system.
If a target system does not have the Adobe Flash Player, which is used to display Flash application files, the installation can
detect that and display image billboards in place of the Flash billboard. Therefore, if you include a Flash billboard in your
project, it is recommended that you also include one or more image billboards in your project.
See Also
Billboard File Types for Basic MSI Projects
Run-Time Behavior of a Basic MSI Installation that Includes Billboards
You can choose to display only one image billboard during the file transfer process, or you can include a series of image
billboards, each one designed to be displayed for a specific amount of time. InstallShield includes support for .bmp, .gif,
.jpg, and .jpeg image files.
Note • Animated .gif files are not supported. If you want to use animation in a billboard, consider using an Adobe Flash
application file billboard.
2. In the Billboards explorer, right-click Images and then click New Billboard. InstallShield adds a new billboard item
with the name NewBillboard1.
3. Type a name for the billboard item. This name is used to help you identify the item while you are creating your
installation; the name is not displayed during the installation.
See Also
Billboard File Types for Basic MSI Projects
Run-Time Behavior of a Basic MSI Installation that Includes Billboards
When you add an Adobe Flash application file billboard or an image billboard to your project, you need to configure its
settings.
2. In the Billboards explorer in the center pane, click the billboard that you want to configure. InstallShield displays the
billboard settings in the right pane.
For information about each of the billboard settings, see Settings for Adobe Flash Application File Billboards and Image
Billboards.
See Also
Billboard Settings
Adding an Adobe Flash Application File Billboard to a Basic MSI Project
Adding Image Billboards to a Basic MSI Project
InstallShield lets you preview a billboard to see how it would be displayed at run time, without requiring you to build and
run a release.
Previewing a billboard lets you see how your billboard will look with the background color, position, and related settings
that are currently configured for your billboard.
2. In the Billboards explorer in the center pane, right-click the billboard that you want to preview, and then click
Preview Billboard.
To stop previewing a billboard, click the Cancel button in the preview window.
Tip • Previewing a billboard is especially helpful if you want to see how your Flash or image billboard will look with different
selected billboard types. You can preview a billboard, change the billboard type, and then preview a billboard again.
See Also
Types of Billboards for Basic MSI Projects
Image billboards are displayed in the order in which they are listed in the Billboards view, from top to bottom.
Task To change the order in which image billboards are displayed at run time:
2. In the Billboards explorer, right-click one of the billboard items that you want to move, and then click either Move Up
or Move Down.
Repeat the last step until all of the billboards are correctly sorted.
See Also
Adding Image Billboards to a Basic MSI Project
Important • If your installation includes billboards, your installation must include a Setup.exe setup launcher. The setup
launcher is required because it displays the billboards at run time. The Setup.exe tab for a release in the Releases view is
where you specify information such as whether you want to use a setup launcher. To learn more, see Setup.exe Tab for a
Release.
If your installation includes a Flash billboard and one or more image billboards, only one billboard type is displayed at run
time during the file transfer process: the Flash billboard or the image billboards.
• If the Flash Player is present on the target system, the installation displays the Flash billboard.
• If the Flash Player is not present, the installation displays the image billboards.
The run-time behavior is slightly different, depending on whether the installation is displaying a Flash billboard or image
billboards:
• If the installation is displaying a Flash billboard—When the file transfer is complete, the installation continues
showing the Flash billboard until its duration has elapsed. Once the duration has elapsed, the installation stops
displaying the billboard and shows the appropriate SetupComplete dialog.
If the file transfer takes more time than you have allocated for the duration of the Flash billboard, the installation
continues displaying the Flash billboard until file transfer ends.
• If the installation is displaying image billboards—When the file transfer is complete, the installation stops
displaying the image billboards, even if other billboards are scheduled or the current billboard’s duration has not
elapsed. The installation then shows the appropriate SetupComplete dialog.
If the file transfer takes more time than you have allocated for the billboards, the installation continues displaying the
billboards until file transfer ends. If No is selected for the Loop Billboard setting in the Billboards view and the
installation reaches the last billboard before the file transfer ends, the installation continues displaying that last
image billboard until file transfer ends. Then the installation shows the appropriate SetupComplete dialog. If Yes is
selected for this setting and the installation reaches the last billboard before the file transfer ends, the installation
restarts the display of billboards from the beginning. The loop continues, if necessary, until the file transfer ends, and
the SetupComplete dialog is displayed.
Note • If the version of Flash or other tool that you use to create your .swf file is newer than the version of the Flash Player that
is installed on a target system, it is possible that some of the Flash features may not work as expected on that target system.
See Also
Types of Billboards for Basic MSI Projects
Previewing Billboards Without Building and Launching a Release
Setting the Billboard Order in a Basic MSI Project
2. In the Billboards explorer, right-click the billboard that you would like to remove, and then click Delete.
• InstallScript
• InstallScript MSI
You can add billboards to your projects to display information to end users during the installation process. The billboards
can be used to communicate, advertise, educate, and entertain end users. For example, billboards can present overviews
on new features of the product being installed or other products from your company. Each billboard is a file that you or
your company’s graphics department creates for complete control over the look and feel of the file transfer.
See Also
Displaying a Background Window in InstallScript and InstallScript MSI Installations
Billboard Styles and File Types for InstallScript and InstallScript MSI Projects
InstallShield 2020
• InstallScript
• InstallScript MSI
InstallShield offers support for two different billboard styles. One includes a full-screen background window, and the other
does not. Both styles show a progress bar.
Following are descriptions and sample screen shots of both types of billboard, along with applicable supported file types.
You can use the following types of files for this style of billboard:
If a target system does not have the Adobe Flash Player, which is used to display Flash application files, the installation can
detect that and display image billboards in place of the Flash billboard. Therefore, if you include a Flash billboard in your
project, it is recommended that you also include one or more image billboards in your project.
Note • For windowed billboards that show progress, you can add more than one image billboard to a project, but only one
Adobe Flash application file billboard.
In the sample screen shot, the billboard is the blue-green rectangle image. Its size is 544 pixels wide by 281 pixels high.
Note • Skinned dialogs cannot display windowed billboards. To learn more about skins, see Dialog Skins.
You can use image files (.bmp, .gif, .jpg, and .jpeg) for this style of billboard.
In the sample screen shot, the billboard is the blue-green rectangle image behind the progress dialog but in front of the
background window.
See Also
Adding or Modifying the Code in an InstallScript or InstallScript MSI Project to Display Billboards
Naming Billboard Files in an InstallScript or InstallScript MSI Project
Adding an Adobe Flash Application File Billboard to an InstallScript or InstallScript MSI Project
Adding an Image Billboard to an InstallScript or InstallScript MSI Project
Setting the Billboard Order in an InstallScript or InstallScript MSI Project
• InstallScript
• InstallScript MSI
Note • The Adobe Flash application file support that is described here is applicable if the billboard style that you are using is
the windowed style with progress, not the billboard style with a full-screen background window. If you want to use Flash file
support with a full-screen background window, use the PlayMMedia function; with this support, the following naming
conventions do not apply to the Adobe Flash file. For more information, see PlayMMedia. To learn how to display the
background window for this implementation, see Displaying a Background Window in InstallScript and InstallScript MSI
Installations.
You can add more than one image billboard to a project, but only one Adobe Flash application file billboard.
Note that if a target system does not have the Adobe Flash Player, which is used to display Flash application files, the
installation can detect that and display image billboards in place of the Flash billboard. Therefore, if you include a Flash
billboard in your project, it is recommended that you also include one or more image billboards in your project.
The first step in adding billboards to your project is to create the Adobe Flash application file (if applicable) and image files
(.bmp, .gif, .jpg, or .jpeg) that serve as your installation’s billboards. When your files are properly named, you can add your
billboards to your project. Note that if a target system does not have the Adobe Flash Player, which is used to display Flash
application files, the installation can detect that and display image billboards in place of the Flash billboard. Therefore, if
you include a Flash billboard in your project, it is recommended that you also include one or more image billboards in your
project.
Billboard files must follow a designated naming convention. Each file name must begin with bbrd, followed by the number
of the billboard (from 1 through 99); each must end with a supported file extension (.swf, .bmp, .gif, .jpg, or .jpeg). You can
include a maximum of one Adobe Flash file (.swf) in your project; if you do include an .swf file, its name must contain the
lowest number in the list of billboard files (for example, bbrd1.swf) that you are including in your project.
The billboards are displayed according to the sequential order of their file names. For example, a billboard file named
bbrd2.bmp is displayed before bbrd4.gif.
Note that it is not necessary for the file name numbers to be contiguous; that is, you can add bbrd1.jpg, bbrd3.jpg, and
bbrd5.jpg to your project, and each image is displayed at run time in order.
Tip • The length of time that an image billboard is displayed depends upon the number of image billboards in your
installation project. The percentage of the display time is approximately 1 divided by the number of billboards. For example, if
you have four billboards in your installation, each billboard is displayed for 25% of the file-transfer time.
Adding an Adobe Flash Application File Billboard to an InstallScript or InstallScript MSI Project
InstallShield 2020
• InstallScript
• InstallScript MSI
Note • The Adobe Flash application file support that is described here is applicable if the billboard style that you are using is
the windowed style with progress, not the billboard style with a full-screen background window. If you want to use Flash file
support with a full-screen background window, use the PlayMMedia function. For more information, see PlayMMedia. To
learn how to display the background window for this implementation, see Displaying a Background Window in InstallScript
and InstallScript MSI Installations.
InstallShield lets you display a Flash application file billboard during the file transfer process. Flash application files can
consist of videos, movies, sounds, interactive interfaces, games, text, and more—anything that is supported by the .swf
type of file. It is recommended that files such as Flash video files (.flv) and MP3 audio files be embedded in the .swf file so
that they are available locally on the target system during file transfer. Although .swf files can reference external files that
you can post on a Web site, this external implementation would require that end users have an Internet connection.
Task To add an Adobe Flash Application File billboard to your installation project:
1. In the View List under Behavior and Logic, click Support Files/Billboards.
2. In the Support Files explorer, click the Billboards item that should contain the billboard: either Language
Independent or a language-specific item. The Files pane is displayed on the right.
3. Right-click anywhere in the Files pane and click Insert Files, or place your cursor in the Files pane and press the Insert
key. The Open dialog opens.
4. Select your Adobe Flash application file billboard file named bbrd1.swf, and click OK.
Note • If the version of Flash or other tool that you use to create your .swf file is newer than the version of the Flash Player that
is installed on a target system, it is possible that some of the Flash features may not work as expected on that target system.
If a target system does not have the Adobe Flash Player, which is used to display Flash application files, the installation can
detect that and display image billboards in place of the Flash billboard. Therefore, if you include a Flash billboard in your
project, it is recommended that you also include one or more image billboards in your project.
See Also
Adding or Modifying the Code in an InstallScript or InstallScript MSI Project to Display Billboards
• InstallScript
• InstallScript MSI
You can choose to display only one image billboard during the file transfer process, or you can include a series of image
billboards, each one designed to be displayed for a specific amount of time. InstallShield includes support for .bmp, .gif,
.jpg, and .jpeg image files.
Note • Animated .gif files are not supported. If you want to use animation in a billboard, consider using an Adobe Flash
application file billboard.
1. In the View List under Behavior and Logic, click Support Files/Billboards.
2. In the Support Files explorer, click the Billboards item that should contain the billboard: either Language
Independent or a language-specific item. The Files pane is displayed on the right.
3. Right-click anywhere in the Files pane and click Insert Files, or place your cursor in the Files pane and press the Insert
key. The Open dialog opens.
Tip • The length of time that an image billboard is displayed depends upon the number of image billboards in your
installation project. The percentage of the display time is approximately 1 divided by the number of billboards. For example, if
you have four billboards in your installation, each billboard is displayed for 25% of the file-transfer time.
See Also
Adding or Modifying the Code in an InstallScript or InstallScript MSI Project to Display Billboards
• InstallScript
• InstallScript MSI
The InstallScript code that is needed to display billboards at run time varies, depending on the style of billboard that you
are using.
• Windowed Billboards with Progress—To use windowed billboards that show progress at run time, use the
STATUSBBRD constant with the Enable function.
• Billboards with a Full-Screen Background Window—To use billboards that are displayed with a full-screen
background window, use the FULLWINDOWMODE and BACKGROUND constants with the Enable function. To learn
how, see Displaying a Background Window in InstallScript and InstallScript MSI Installations.
Note that if you want to use an Adobe Flash billboard with this style of billboard, you must also use the PlayMMedia
function.
For details about these different styles of billboards, see Billboard Styles and File Types for InstallScript and InstallScript
MSI Projects.
See Also
Enable
PlayMMedia
Adding an Adobe Flash Application File Billboard to an InstallScript or InstallScript MSI Project
Adding an Image Billboard to an InstallScript or InstallScript MSI Project
Displaying a Background Window in InstallScript and InstallScript MSI Installations
• InstallScript
• InstallScript MSI
Image billboards are displayed according to the numeric order of their file names. A billboard file named bbrd2.bmp is
displayed to the end user before a file named bbrd3.bmp, and after a file named bbrd1.bmp. For specific guidelines on
naming conventions, see Naming Billboard Files in an InstallScript or InstallScript MSI Project.
1. Remove the billboard files whose order should change. (For more information, see Removing a Billboard from an
InstallScript or InstallScript MSI Project.)
2. Using Windows Explorer, rename the billboard files so that they are in the appropriate numeric order.
3. Add the renamed files, as explained in Adding an Image Billboard to an InstallScript or InstallScript MSI Project.
Note that it is not necessary for the file name numbers to be contiguous; that is, you can add bbrd1.jpg, bbrd3.jpg, and
bbrd5.jpg to your project, and each image is displayed at run time in order.
• InstallScript
• InstallScript MSI
The SetDisplayEffect function enables you to display your billboards with different special effects when they first appear
on the main installation window. Choose one of this function’s options before you display a bitmap with PlaceBitmap or
display billboards during file transfer.
See Also
Adding an Image Billboard to an InstallScript or InstallScript MSI Project
Billboard Styles and File Types for InstallScript and InstallScript MSI Projects
SetDisplayEffect
PlaceBitmap
Moving Billboards to a Different Screen Location for an InstallScript or InstallScript MSI Project
InstallShield 2020
• InstallScript
• InstallScript MSI
Note • The Adobe Flash application file support that is described here is applicable if the billboard style that you are using is
the billboard style with a full-screen background window (which uses the PlayMMedia function), not for the windowed style
with progress (which uses the STATUSBBRD constant with the Enable function). For more information about these two styles
of billboards, see Billboard Styles and File Types for InstallScript and InstallScript MSI Projects.
By default, the installation displays billboards in the center of the main installation window. To specify a different location,
call the PlaceWindow function with the BILLBOARD option. For example, to place your billboards 10 pixels from the upper-
left corner of the screen, make the following call:
Since billboards are displayed only during file transfer, ensure that you call PlaceWindow before you begin file transfer.
See Also
PlaceWindow
• InstallScript
• InstallScript MSI
1. In the View List under Behavior and Logic, click Support Files/Billboards.
2. In the Support Files explorer, click the Billboards item that contains the billboard that you want to remove: either
Language Independent or a language-specific item. The Files pane is displayed on the right.
• InstallScript
• InstallScript MSI
By default, installations do not display a background window. If you want to use the PlayMMedia function to display an
Adobe Flash application file (.swf) or AVI files, your installation must display a background window. You may also want to
display a background window for one type of billboard.
Tip • You can display a Flash file billboard and image billboards without a background window. For more information, see
Billboard Styles and File Types for InstallScript and InstallScript MSI Projects.
The method for displaying a background window depends on which project type you are using.
InstallScript Projects
To display a background window in an InstallScript project, modify the script’s OnShowUI event handler by removing the
double slashes from the beginnings of the following lines of code:
//if ( LoadStringFromStringTable( "TITLE_MAIN", szTitle ) < ISERR_SUCCESS ) then // Load the title
string.
// szTitle = IFX_SETUP_TITLE;
//endif;
//SetTitle( szTitle, 24, WHITE );
//Enable( FULLWINDOWMODE );
//Enable( BACKGROUND );
//SetColor( BACKGROUND, RGB( 0, 128, 128 ) );
See Also
Enable
PlayMMedia
Script Editor in the InstallScript View
function FillListBox( )
LIST listDays;
begin
listDays = ListCreate(STRINGLIST);
ListAddString(listDays, "Monday", AFTER);
ListAddString(listDays, "Wednesday", AFTER);
ListAddString(listDays, "Friday", AFTER);
See Also
CtrlSetList
For an example of calling the GetOpenFileName API to display a file browse dialog, see Knowledge Base article Q104325.
You can use the SelectDirEx function to display a dialog with which the user can browse the Network Neighborhood.
prototype NetBrowse( );
function NetBrowse( )
STRING svSelectedDir[MAX_PATH + 1];
NUMBER nReturn;
begin
svSelectedDir = PROGRAMFILES;
Configuring Servers
InstallShield 2020
When you are creating an installation, you may find it necessary to provide server-side support for some technology that
will be installed on a target system. InstallShield makes it easy to configure server-side installations or manage COM+
server applications and application proxies. InstallShield provides support for Internet Information Services, SQL, and
component services.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
Note • For information about configuring SQL support in Suite/Advanced UI projects, refer to Adding a SQLLogin Predefined
Wizard Page in a Suite/Advanced UI Project.
InstallShield provides SQL support for Microsoft SQL Server, Microsoft Windows Azure, MySQL, and Oracle. The SQL Scripts
view provides a central location for managing and organizing all SQL scripts by server connections and settings within the
user interface. SQL support within InstallShield enables you to do the following:
• Set required SQL server/script properties (server name, database name, authentication method, etc.).
• Open scripts in Microsoft SQL Server Management Studio or Microsoft SQL Server Query Analyzer.
Note • The import database functionality applies to the Microsoft SQL Server Database. Oracle users should refer to the
Oracle Web page on Oracle Database Utilities for information on utilities that may work in conjunction with InstallShield.
If you have Microsoft SQL Server Management Studio or Microsoft SQL Server 2000 SQL Query Analyzer installed on your
system, you can open a new SQL script that you have added to your project to test, edit, and syntax-check the script. To launch
one of those tools and open your script from within InstallShield, right-click the script file in the SQL Scripts view and then click
Open Script in Microsoft SQL Server Management Studio. InstallShield searches your system for the following tools in order
and launches the first one that it finds:
1. Microsoft SQL Server 2008 Management Studio (any edition, including Express; ssms.exe)
2. Microsoft SQL Server 2005 Management Studio (SqlWb.exe)
3. Microsoft SQL Server 2005 Management Studio Express (ssmsee.exe)
4. Microsoft SQL Server 2000 Query Analyzer (isqlw.exe)
See Also
SQL Scripts View
• Basic MSI
• DIM
• InstallScript MSI
When you use the SQL Scripts view to add a new SQL database connection to your project, InstallShield adds the following
Windows Installer properties to the project by default.
Property Description
IS_SQLSERVER_AUTHENTICATION This property identifies the type of authentication that you want to use to
connect to the specified catalog. The default property is
IS_SQLSERVER_AUTHENTICATION. The following numbers are valid property
values:
• 1—Server authentication
This property is the default value for the Authentic Type Property Name
setting on the Advanced tab for the selected SQL connection.
IS_SQLSERVER_DATABASE This property identifies the name of the SQL catalog to which you want to
create a connection during the installation. This property is the default value
for the Target Catalog Property Name setting on the Advanced tab for the
selected SQL connection.
IS_SQLSERVER_PASSWORD This property identifies the password that should be used for server
authentication. This property is the default value for the Server
Authentication Password Property Name setting on the Advanced tab for the
selected SQL connection.
Property Description
IS_SQLSERVER_SERVER This property identifies the name of the target server instance (for Microsoft
SQL Server and MySQL) or the connect URL string or local net service name
(for Oracle). This property is the default value for the Target Server Property
Name setting on the Advanced tab for the selected SQL connection.
IS_SQLSERVER_USERNAME This property identifies the login ID that should be used for server
authentication. This property is the default value for the Server
Authentication Login ID Property Name setting on the Advanced tab for the
selected SQL connection.
If you want to override one of these Windows Installer property for an existing connection, add a new property in the
Property Manager. Then, in the SQL Scripts view, select the connection. On the Advanced tab, select the name of the new
property in the appropriate list.
If you want to store the values of any of these properties on the target system for later use by your product, you can do so.
Following are examples of ways you can use these properties:
• In the Registry view, create a registry value whose data is [IS_SQLSERVER_SERVER]. At run time, when your installation
creates the registry value, the data for that registry value is set to the name of the SQL catalog.
• Use the Text File Changes view to configure text string replacements that you want to occur at run time. In this view,
add a text file reference that describes a file that is installed with your product, and then specify the search-and-
replace criteria. For the search-and-replace criteria, you can enter [IS_SQLSERVER_DATABASE] in place of the name of
the SQL Server machine. At run time, when your installation edits the text file, the name of the SQL Server machine is
written in the text file.
Tip • For a list of additional Windows Installer properties that you can define in your project to override default SQL run-time
behavior, see Overriding the Default SQL Run-Time Behavior.
Project • In a Basic MSI installation, the built-in SQLLogin dialog lets end users configure the aforementioned properties. If
you change any of the SQL properties on the Advanced tab of a SQL connection in a Basic MSI project, the corresponding
properties are not automatically updated in the SQLLogin dialog in the Dialogs view. Therefore, you must manually change
the properties in the dialog to match the properties that selected on the Advanced tab of the SQL connection.
See Also
Specifying Whether New SQL Connections Should Share the Same Windows Installer Properties
SQL Scripts View
Specifying Whether New SQL Connections Should Share the Same Windows Installer
Properties
InstallShield 2020
• Basic MSI
• DIM
• InstallScript MSI
InstallShield lets you specify whether new SQL database connections that you add to your project should share the same
Windows Installer properties by default.
For example, if you want connections to share the same default Windows Installer properties, you could add one
connection to your project in the SQL Scripts view, and specify a catalog name of MyConnection. If you add a second
connection to your project, InstallShield uses the same catalog name of MyConnection for that second connection. If you
change the catalog name of either connection, InstallShield automatically updates the catalog name of the other
connection, since both are based on the same Windows Installer property.
Task To specify whether SQL connections should share the same Windows Installer properties:
1. On the Tools menu, click Options. The Options dialog box opens.
3. Select or clear the Generate unique Windows Installer properties for new connections check box:
• To share Windows Installer properties between any new connections that you add, clear this check box.
• To use different Windows Installer properties for any new connections that you add, select this check box.
If you select the check box and then add a second connection to your project, InstallShield creates a new set of Windows
Installer properties for the second connection.
If you clear the check box and then add a second connection, InstallShield uses the default Windows Installer properties for
the second connection. The default Windows Installer properties are the ones that were added for the first connection that
you added to your project.
Tip • If you want to override a Windows Installer property for an existing connection, add a new property in the Property
Manager. Then, in the SQL Scripts view, select the connection. On the Advanced tab, select the name of the new property in the
appropriate list.
Project • For Basic MSI projects, the built-in SQLLogin dialog is designed to work with the default Windows Installer properties
for the first SQL connection that was added to the project. If you select the Generate unique Windows Installer property for
new connections option, you need to duplicate the dialog for each connection to work with the new Windows Installer
properties.
See Also
Options Dialog Box
SQL Scripts View
• InstallScript
• InstallScript MSI
The InstallScript language includes many built-in SQL run-time (SQLRT) functions that begin with a prefix of SQLRT. Some
of the functions are available only in InstallScript projects, some are available only in InstallScript MSI projects, and some
are available in both project types.
The SQLRT functions require that you configure SQL information through the SQL Scripts view; the configuration
information is written to the SQLRT.ini file so that the SQL run-time functions work properly. For InstallScript projects, the
SQLRT functions are in the SQLRT.obl file, and they call the SQLRT.dll file. For InstallScript MSI projects, the SQLRT
functions are in the SQLCONV.obl file, and they call the ISSQLSRV.dll file. These support files are added automatically to
your project when you use the SQL Scripts view.
The SQLRTInitialize2 function initializes the SQL server run time. In InstallScript projects, the SQLRTInitialize2 function is
called automatically during the OnSQLServerInitialize event handler. In InstallScript MSI projects, the SQLRTInitialize2
function is called automatically during the OnSQLLogin event handler. If you need to call one of the SQLRT functions
before the OnSQLServerInitialize or OnSQLLogin events, you must first call the SQLRTInitialize2 function.
Note • In earlier versions of InstallShield, the SQLRTInitialize function was used to initialize the SQL server run time in
InstallScript projects. This function has been superseded by the SQLRTInitialize2 function.
See Also
SQL Functions
SQLRTInitialize2
OnSQLServerInitialize
OnSQLLogin
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
In the SQL Scripts view, scripts are organized by connection, since no script can run on a server until a connection has been
established. Therefore, before you can add any SQL scripts to your project, you must first create a SQL connection.
2. Right-click the SQL Scripts explorer and click New SQL Connection.
InstallShield adds a new connection in the explorer. Use the tabs in the right pane to configure the settings that are
associated with this connection.
Note • The SQLLogin and SQLBrowse dialogs let end users use alias names for connecting and browsing to SQL Server
databases.
Microsoft has released a new OLE DB provider called Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL). Going forwar,
the new provider will be updated with the most recent server features. This provider also supports TLS 1.2 only
environments.
InstallShield 2019 R3 and later now uses MSOLEDBSQL as the default provider for all new SQL Server connections. This can
be changed by choosing different SQL Driver from 'Choose a Driver for Database Server' drop down present in the
Requirements tab.
Important • Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) is included as a prerequisite in InstallShield 2019 R3 and
later.
For more information, see Choose SQL Driver for Database Server in Requirements Tab.
See Also
Requirements for Connecting to Instances of SQL Server Express LocalDB
Overriding the Default TCP/IP Network Library with a Different Protocol for a SQL Server Database
SQL Scripts View
Overriding the Default TCP/IP Network Library with a Different Protocol for a SQL Server
Database
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
By default, InstallShield installations use the TCP/IP network library when connecting to a SQL Server database. You can
override this default behavior as needed if you want to use a different protocol.
Task To override the default TCP/IP network library when connecting to a SQL Server database:
2. Right-click the SQL Scripts explorer and click New SQL Connection. InstallShield adds a new connection in the
explorer. Use the tabs in the right pane to configure the settings that are associated with this connection.
Network Library=DBMSSOCN
DBMSSOCN refers to the name of the module for the TCP/IP network library, without the file extension.
At run time, the installation uses the protocol that you specified when connecting to a SQL Server database.
See Also
Direct Editor
SQL Scripts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
If you want your installation to support connections to instances of SQL Server Express LocalDB, the target system must
have the SQL Server Native Client 11 ODBC driver. To ensure that it is present on target systems, you can include the
Microsoft SQL Server 2012 Native Client prerequisite in your installation. You also must configure your project to use the
driver.
Task To include the appropriate SQL Server Native Client prerequisite in your project for connecting to instances of SQL
Server Express LocalDB:
1. For Basic MSI and InstallScript MSI projects: In the View List under Application Data, click Redistributables.
For InstallScript projects: In the View List under Application Data, click Prerequisites.
2. In the list of redistributables, select the appropriate Microsoft SQL Server 2012 Native Client check box.
The InstallShield prerequisite is launched only if the conditions that are defined in the InstallShield prerequisite file (.prq)
are met. To see the list of conditions, click the SQL Server Native Client prerequisite in the Redistributables view or the
Prerequisites view, and then review the details that are listed in the details pane on the right. You can hide or show the
details pane by clicking the Show Details button in these views.
Task To configure your InstallShield installation project so that your installation uses the SQL Server Native Client 11 ODBC
driver:
sqlncli11
At run time, the installation uses the SQL Server Native Client 11 ODBC driver when connecting to a SQL Server Express
LocalDB database.
See Also
Direct Editor
SQL Scripts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
Task To add a new SQL script once you have created a new SQL connection:
When you add a new script to your project, InstallShield adds a new component for the script. You must associate the script
with a feature. If one does not exist, the Create a New Feature dialog box opens when you add the SQL script, prompting
you to create a new feature. You can change the script-feature association later by using the Select Features the SQL
Script Belongs to area on the General tab in the SQL Scripts view for the SQL script.
Tip • You can also add scripts to your project by importing or inserting them. For more information, see Inserting and
Importing SQL Scripts.
Note • If you have Microsoft SQL Server Management Studio or Microsoft SQL Server 2000 SQL Query Analyzer installed on
your system, you can open a new SQL script that you have added to your project to test, edit, and syntax-check the script. To
launch one of those tools and open your script from within InstallShield, right-click the script file in the SQL Scripts view and
then click Open Script in Microsoft SQL Server Management Studio. InstallShield searches for one of the following tools and
launches the first one that it finds:
• Microsoft SQL Server 2008 Management Studio (any edition, including Express; ssms.exe)
• Microsoft SQL Server 2005 Management Studio (SqlWb.exe)
• Microsoft SQL Server 2005 Management Studio Express (ssmsee.exe)
• Microsoft SQL Server 2000 Query Analyzer (isqlw.exe)
See Also
Database Import Wizard
SQL Scripts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
InstallShield enables you to reuse SQL script files (.sql) in multiple projects. You can insert or import script files into a
project through the SQL Scripts view:
• Inserting a script file creates a link to the script file in its current location.
• Importing a script file copies the script file to the folder containing the script files for your project. The script files that
you import can be stored somewhere on your system, or they can be stored in a repository.
2. In the SQL Scripts explorer, add a SQL connection if you have not already done so.
3. Right-click the SQL connection and then click Insert Script Files. The Open dialog box opens.
4. Select the SQL script file (.sql) that you want to insert.
5. Click Open.
2. In the SQL Scripts explorer, add a SQL connection if you have not already done so.
3. Right-click the SQL connection and then click Import Script Files. The Import SQL Script Files Dialog Box opens.
• In the Repository Items box, click the SQL script file (.sql) that you want to add to your project.
• If the script file that you want to import is not stored in the repository, click the browse button to select it.
5. Click OK.
When you insert or import a new script to your project, InstallShield adds a new component for the script. You must
associate the script with a feature. If one does not exist, the Create a New Feature dialog box opens when you add the SQL
script, prompting you to create a new feature. You can change the script-feature association later by using the Select
Features the SQL Script Belongs to area on the General tab in the SQL Scripts view for the SQL script.
See Also
Importing a SQL Server Database and Generating a SQL Script File
Using a Repository to Share Project Elements
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
Task To import an existing Microsoft SQL Server database and then generate a script file from it:
2. Right-click the SQL Scripts explorer and then click Database Import Wizard. The Database Import Wizard opens.
The Database Import Wizard will guide you through the process of importing your database settings and generating a SQL
script file based on those settings and other options that you determine.
Note • The import database functionality applies to the Microsoft SQL Server Database. The script generated by the Database
Import Wizard is not compatible with other database types.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
Once you have created, inserted, or imported a script file, you can edit it from within InstallShield.
Project • In an InstallScript project, if you are working on a script that had overridden OnFirstUIBefore before upgrading to
InstallShield and it is not calling OnSQLServerInitialize, you should add that code to your script file.
2. In the SQL Scripts explorer, click the script file that you want to edit.
3. Click the Script tab, which displays the contents of your script file.
If you want to re-create your script each time that you build your project, you can select the Regenerate SQL Script at Build
check box on the Database Import tab for the script in the SQL Scripts view. A backup of any existing script file is always
saved first.
Note • If you have Microsoft SQL Server Management Studio or Microsoft SQL Server 2000 SQL Query Analyzer installed on
your system, you can open a new SQL script that you have added to your project to test, edit, and syntax-check the script. To
launch one of those tools and open your script from within InstallShield, right-click the script file in the SQL Scripts view and
then click Open Script in Microsoft SQL Server Management Studio. InstallShield searches for one of the following tools and
launches the first one that it finds:
• Microsoft SQL Server 2008 Management Studio (any edition, including Express; ssms.exe)
• Microsoft SQL Server 2005 Management Studio (SqlWb.exe)
• Microsoft SQL Server 2005 Management Studio Express (ssmsee.exe)
• Microsoft SQL Server 2000 Query Analyzer (isqlw.exe)
See Also
Working with the Script Editor Pane in Various Views
SQL Scripts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
You can assign a schema version number to a SQL script file after you have a created or imported a script file in the SQL
Scripts view. Specifying schema version information helps you to trigger the launching of the SQL script only when it is
appropriate.
Task To specify the schema version for your SQL script file:
2. In the SQL Scripts explorer, click the SQL script that you want to configure.
4. In the Schema Version (xxxxx.xxxxx.xxxxx.xxxxx) box, type the schema version number for your SQL script
The installation checks the current schema version that is on the target database. The schema version is stored in the
ISSchema column of the custom table named InstallShield. When you specify a schema version for a SQL script, the
installation runs the script only if the script schema version number is greater than the current schema version number.
Once the script is executed, the installation updates the current schema version on the target database to reflect the new
schema version number.
If you do not specify a schema version number for a SQL script, the script is always launched.
For example, your installation may create a new connection to a database called TestDB and then create a script that is
called TestScript and that has a schema version number of 12345.54321.12345.54321. The installation creates the
custom InstallShield table in the TestDB database and stores the schema version in the ISSchema column of that table.
If another installation is run on that system, and this installation also has a SQL script called TestScript, the SQL script is
executed only if the schema version number of this other script is greater than the version number that is stored in the
ISSchema column in the InstallShield table of the target database. If the script is executed, the installation updates the
ISSchema column with the new schema version number.
Tip • When you specify a number for the Schema Version setting and InstallShield adds the custom InstallShield table for
storing the schema version number on the target database, the data is not automatically removed upon uninstallation.
Therefore, if you want the installation to be able to roll back the changes, you need to create a custom script upon
uninstallation to drop the InstallShield table.
Specifying the Order for Running Multiple SQL Scripts That Are Associated
with a Connection
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
If you add more than one SQL script to a SQL connection in your project, you can specify the order in which the installation
runs those SQL scripts on the target machine. The procedure for specifying the order differs for Windows Installer–based
and InstallScript-based projects.
Specifying the SQL Script Order in Basic MSI, DIM, and InstallScript MSI Projects
The order in which a connection’s SQL scripts are listed in the SQL Scripts view of a Basic MSI, DIM, and InstallScript MSI
project is the order in which the installations run the SQL scripts. For example, if you create a connection in the SQL Scripts
view and add two SQL scripts to that connection, the script that is listed first under the SQL connection is the one that the
installation runs first.
Task To change the order in which a connection’s SQL scripts are run:
2. In the SQL Scripts explorer, right-click the SQL script that you want to move and click Move Up or Move Down.
The next time that you build and run the installation, the order is updated.
If you want to be able to override this default behavior and specify a particular order for running the SQL scripts, you can do
so by enabling the batch mode in the SQL Scripts view.
Batch mode is enabled if the Batch Mode command has a check mark; it is disabled if the command does not have a check
mark.
The SQLRTGetBatchList function returns the list of components that are associated with SQL scripts that need to be run
when batch mode is enabled. For more information, see SQLRTGetBatchList.
• Basic MSI
• DIM
• InstallScript MSI
You can define the following Windows Installer properties to override default run-time behavior:
Property Description
Property Description
IS_SQLSERVER_LOCAL_ONLY Specifies to show only the local SQL Server in the SQL
Server browse combo box and list box controls.
Note • To show only the local SQL Server and either remote
SQL Servers or SQL Server aliases, you can set the
IS_SQLSERVER_LOCAL_ONLY property, as well as either the
IS_SQLSERVER_REMOTE_ONLY property or the
IS_SQLSERVER_ALIAS_ONLY property.
IS_SQLSERVER_REMOTE_ONLY Specifies to show only the remote SQL Servers in the SQL
Server browse combo box and list box controls.
Note • To show only the remote SQL Servers and either the
local SQL Server or SQL Server aliases, you can set the
IS_SQLSERVER_REMOTE_ONLY property, as well as either the
IS_SQLSERVER_LOCAL_ONLY property or the
IS_SQLSERVER_ALIAS_ONLY property.
IS_SQLSERVER_ALIAS_ONLY Specify to show only the SQL Server aliases in the SQL
Server browse combo box and list box controls.
Note • To show only the SQL Server aliases and either the
local SQL Server or remote SQL Servers, you can set the
IS_SQLSERVER_ALIAS_ONLY property, as well either the
IS_SQLSERVER_LOCAL_ONLY property or the
IS_SQLSERVER_REMOTE_ONLY property.
Project • For Basic MSI projects, all connections are linked to the SQLLogin dialog. To display multiple SQLLogin dialogs, you
can copy the SQL dialogs from the Dialogs view and modify their behavior and events similar to the default SQL dialogs.
Remember to create new properties, and set them in the connection’s Advanced tab of the SQL Scripts view. You can use those
new properties when you modify the copies of the SQL dialogs that you made.
See Also
Using Windows Installer Properties for SQL Login Settings
Specifying Whether New SQL Connections Should Share the Same Windows Installer Properties
SQL Scripts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
2. In the SQL Scripts explorer, click the SQL script file for which you want to add error handling.
4. In the Script Error Handling area, select one of the options listed, or click the Custom button to override the script’s
default error handling. Available options are:
See Also
SQL Scripts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
InstallShield enables you to create a single connection that targets both Microsoft SQL Server and MySQL and that has
multiple SQL scripts specific to each database server technology. However, a connection is created based on whichever
database type is detected first. Therefore, scripts are run only for the detected database type, and the scripts that are
specific to the non-detected database server type fail. For example, if the run time detects a Microsoft SQL Server, then the
scripts associated with Microsoft SQL Server run, and the scripts that are specific to MySQL fail.
As a workaround to this behavior, it is recommended that you set a condition in your SQL script so that a SQL scripting
error occurs when the installation is running a non-detected database server type script. Then you can set up custom error
handling for the scripting error and skip to the next script for the connection. The following instructions discuss how you
can set this database server type condition for scripts.
Task To set up a database server type condition for a script that targets Microsoft SQL Server:
2. In the SQL Scripts explorer, click the script file for which you are creating the condition.
SELECT @@ROWCOUNT
6. In the Script Error Handling area, click the Custom button. The Custom Error Handling dialog box opens.
8. In the Error Number column, type 1193. This is the error number that MySQL returns when it does not have the
specified system variable that you added at the beginning of the script.
Task To set up a database server type condition for a script that targets MySQL:
2. In the SQL Scripts explorer, click the script file for which you are creating the condition.
SELECT @@table_cache
6. In the Script Error Handling area, click the Custom button. The Custom Error Handling dialog box opens.
8. In the Error Number column, type 137. This is the error number that Microsoft SQL Server returns when it does not
have the specified system variable that you added at the beginning of the script.
• Basic MSI
• DIM
• InstallScript MSI
You may want your installation to launch a SQL script only if certain conditions are met on the target system. For example,
your SQL script may require that the end user have administrator rights. If an end user does not have administrator rights,
the SQL script is not launched.
2. In the SQL Scripts explorer, click the script file for which you are creating the condition.
4. In the Script Condition area, select the Specify a Conditional Statement check box.
5. Click the ellipsis button (...). The Condition Builder dialog box opens.
The SQL scripts are tied to component states. The condition that is set in the SQL Scripts view is the condition for the SQL
script’s component. If the component conditions are met on the target system, the installation installs the SQL script. If the
installation installs a SQL script that you did not expect to be installed on a target system, generating a log file for your
installation may help you determine why the SQL script was installed.
Tip • For information on conditions and on condition syntax, see Building Conditional Statements and Conditional Statement
Syntax.
See Also
Condition Builder Dialog Box
You may want your installation to launch a SQL script only if certain conditions are met on the target system.
InstallShield generates a set of default global event handlers, each of which is a function scripted in the InstallScript
language. The following SQL-related events are automatically called by the InstallShield framework:
• OnSQLServerInitialize
• OnSQLComponentInstalled
OnSQLServerInitialize is called by OnFirstUIBefore, and OnSQLComponentInstalled is called during file transfer, for each
component installed.
Note • If you are working on a script that had overridden OnFirstUIBefore before upgrading to InstallShield and it is not
calling OnSQLServerInitialize, you should add that code to your script file.
In your script, you can modify OnSQLServerInitialize and OnSQLComponentInstalled to perform checks for different things.
For example, you can check for a user with administrator rights in the sample code below.
function OnSQLComponentInstalled(szComponent)
string sMessage;
string sData;
number nResult;
begin
endif;
else
//User does not have administrator rights, so we do not run scripts
endif;
end;
Note • You can configure the behavior for script failure in the InstallShield interface when you click a SQL script in the SQL
Scripts explorer, and then go to the Runtime tab. The Script Error Handling section lets you select one of the following options:
See Also
SQL Scripts View
Requiring that SQL Scripts Be Run Only Against a Full SQL Server
InstallShield 2020
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
Installations that include SQL script support allow end users to run the SQL scripts on Microsoft SQL Server Desktop Engine
(MSDE) and on SQL Server Express Edition, by default. If you want end users to be able to run SQL scripts on only a full SQL
Server, you can use the SQL Scripts view to configure that for any database connection in your installation.
Task To prevent your SQL script files from running on target systems that have MSDE or SQL Server Express Edition:
2. In the SQL Scripts explorer, click the SQL connection that you want to configure.
3. On the Requirements tab, clear the Allow Installation to Microsoft SQL Server Desktop Engine/SQL Server
Express check box.
• Basic MSI
• DIM
• InstallScript MSI
For Basic MSI, DIM, and InstallScript MSI projects, you can specify a replacement for text in a SQL script at run time through
the use of Windows Installer properties. This enables you to let end users specify information that is then used in the SQL
script that is launched on the target system. Windows Installer uses MsiFormatRecord to resolve the properties in the SQL
script at run time.
Example
The following procedure demonstrates how to create a database at run time using a custom SQL script that contains
information that end users enter on the built-in SQL login dialog: the SQLLogin dialog in a Basic MSI installation or the
SQLServerSelectLogin2 dialog in an InstallScript MSI installation. Windows Installer properties are used for the database
name and its target location.
Task To create a database using a SQL script that contains information that end users specify at run time:
2. Right-click the SQL Scripts explorer and click New SQL Connection. InstallShield adds a new SQL connection.
3. Click the SQL connection, and then click the General tab.
5. In the SQL Scripts explorer, right-click the new connection and click New Script. InstallShield adds a new SQL script
to the SQL connection.
6. Click the SQL script, and then click the Script tab.
a. Click the Text Replacement tab, and then click the Add button. The Find and Replace dialog box opens.
%DBNAME%
[IS_SQLSERVER_DATABASE]
e. Click the Add button. The Find and Replace dialog box opens.
%DBPATH%
[INSTALLDIR]
10. Clear the Run Script During Install check box and select the Run Script During Login check box.
See Also
MsiFormatRecord (Windows Installer Help Library)
MsiFormatRecord (Windows Installer Help Library)
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
Working with Dialogs in Basic MSI Projects
Working with Dialogs in InstallScript and InstallScript MSI Projects
Dialog Functions
Dialog Customization Functions
For InstallScript projects, you can specify a replacement for text in a SQL script at run time through the use of text
substitution string variables. This enables you to let end users specify information that is then used in the SQL script that is
launched on the target system. The InstallScript run-time code uses the TextSubSubstitute function to replace the string
variable with the appropriate value in the SQL script.
Example
The following procedure demonstrates how to create a database at run time using a custom SQL script that contains
information that end users enter on the SQLServerSelectLogin2 dialog. InstallScript text substitution is used for the
database name and its target location.
Task To create a database using a SQL script that contains information that end users specify at run time:
2. Right-click the SQL Scripts explorer and click New SQL Connection. InstallShield adds a new SQL connection.
3. Click the SQL connection, and then click the General tab.
5. In the SQL Scripts explorer, right-click the new connection and click New Script. InstallShield adds a new SQL script
to the SQL connection.
6. Click the SQL script, and then click the Script tab.
a. Click the Text Replacement tab, and then click the Add button. The Find and Replace dialog box opens.
%DBNAME%
<MYDATABASENAME>
e. Click the Add button. The Find and Replace dialog box opens.
%DBPATH%
<TARGETDIR>
10. Clear the Run Script During Install check box and select the Run Script During Login check box.
11. In the View List under Behavior and Logic, click InstallScript.
12. Find the dialog code in the OnSQLServerInitialize event for the dialog that should contain the Database Name control,
and add a call to the InstallScript function TextSubSetValue. For example, if you want the user name to be the name
that the end user specifies on the SQLServerSelectLogin2 dialog, you would add a TextSubSetValue call as shown in
the following lines of code:
See Also
Text Substitutions
Working with Dialogs in InstallScript and InstallScript MSI Projects
Dialog Functions
Dialog Customization Functions
• Basic MSI
• DIM
• InstallScript MSI
One way to configure your installation so that it runs only on SQL Server machines is to perform a system search for registry
information, store the result in a property, and then use the property in a condition that you set. The following step-by-step
instructions show how to do this.
Task To configure a Windows Installer–based installation to run only on SQL Server machines:
1. In the View List under Behavior and Logic, click System Search.
2. Right-click the grid and click Add. The System Search Wizard opens.
3. In the What do you want to find panel, click Registry entry and click Next.
InstalledInstances
d. Click Next.
5. In the What do you want to do with the value panel, do the following:
a. In the Store the value in this property box, type the following:
SQLSERVERFOUND
b. In the Additional Options area, select the Store the value in the property and use the property in an Install
Condition option.
6. Verify the condition, and type a message that you want end users to see if the registry entry is not found on the system.
For example, you can type the following message:
Microsoft SQL Server was not found on this machine. This installation was designed to run only on the
server machine.
7. Click OK.
See Also
Requiring a Server-Side Installation for an InstallScript Project
SQL Scripts View
One way to enforce a server-side installation in an InstallScript project is to set up your installation project so that it
searches for a specific registry key and value and only installs the installation project if the value is found. See the sample
code below for an example of how you can do this in your InstallScript project.
function OnBegin()
string sKey, sValue, sData;
string sMsg;
number nType, nSize, nResult;
begin
RegDBSetDefaultRoot( HKEY_LOCAL_MACHINE );
sKey = "Software\\Microsoft\\Microsoft SQL Server";
sValue = "InstalledInstances";
nResult = RegDBGetKeyValueEx( sKey, sValue, nType, sData, nSize );
endif;
end;
See Also
Requiring a SQL Server-Side Installation for a Windows Installer-Based Project
SQL Scripts View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
If you have an existing SQL script file that you would like to reuse in other projects or share with other users, you can
publish it to a repository.
2. In the SQL Scripts explorer, right-click the script file that you would like to publish, and then click Publish Wizard. The
Publish Wizard opens.
After you have imported a script file from a repository into a project, there is no link between the current script file and the
existing repository script file. If you make a change to the script file and then republish it to the repository, it does not affect
the script file in the project to which it was imported. However, you can reimport the script file from the repository into
your project.
See Also
Inserting and Importing SQL Scripts
Using a Repository to Share Project Elements
• Basic MSI
• InstallScript
• InstallScript MSI
If you want to install and launch the MySQL ODBC driver before your installation is run, you can include the InstallShield
prerequisite for MySQL Connector 3.51 in your project.
Task To install and launch the MySQL ODBC driver before your installation is run:
1. For Basic MSI and InstallScript MSI projects: In the View List under Application Data, click Redistributables.
For InstallScript projects: In the View List under Application Data, click Prerequisites.
2. In the list of redistributables, select the MySQL Connector ODBC 3.51 check box.
Tip • The MySQL Connector ODBC 3.51 prerequisite is available only if you have downloaded the installer and added the
InstallShield prerequisite to your system. For detailed instructions, see Including the MySQL Connector ODBC Prerequisite.
See Also
Working with InstallShield Prerequisites that Are Included in Installation Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
Note • You cannot delete a database to which you are currently connected.
If you need to remove a SQL database during uninstallation, you can do so through your SQL script. The following
procedure demonstrates how to configure your project and SQL script to delete a Microsoft SQL Server database.
Master is the name of the system database that exists on all Microsoft SQL Server systems; since you cannot delete a
database to which you are currently connected, you can connect to the Master database and then delete a different
database to which you are not connected.
Tip • As an alternative to the aforementioned procedure, you can perform the same operation completely in SQL script. To do
so, enter the following code in your SQL script:
USE Master
DROP DATABASE DatabaseName
GO
• Basic MSI
• InstallScript
• InstallScript MSI
Task To include the Microsoft SQL Server 2008 Native Client 10.00.2531 prerequisite in your project:
1. For Basic MSI and InstallScript MSI projects: In the View List under Application Data, click Redistributables.
For InstallScript projects: In the View List under Application Data, click Prerequisites.
2. In the list of redistributables, select the appropriate Microsoft SQL Server 2008 Native Client 10.00.2531 check box
or check boxes, depending on whether the architecture of target systems is 32 bit or 64 bit.
The InstallShield prerequisite is launched only if the conditions that are defined in the InstallShield prerequisite file (.prq)
are met. To see the list of conditions, click the SQL Server Native Client prerequisite in the Redistributables view or the
Prerequisites view, and then review the details that are listed in the details pane on the right. You can hide or show the
details pane by clicking the Show Details button in these views.
Specifying the User Name for the Windows Azure SQL Database Connection at Run-
Time
If you use the SQLLogin dialog in your installation and your installation is targeting a Windows Azure SQL database, end
users should use the following format to enter a string in the Login ID box on the SQLLogin dialog:
DatabaseUserName@ServerName
Following is an example:
MyUserName@wbzdh64drd
See Also
Adding a New SQL Connection
• Basic MSI
• InstallScript
• InstallScript MSI
Note • If you want your installation to download the Oracle 11g Instant Client whenever it needs to be installed on a target
system, check with Oracle to ensure that it is allowed. If it is allowed, you must host the download on your own Web site and
add its download path to the InstallShield prerequisite. Revenera does not make this installation available for download.
Connecting to an instance of Oracle requires the following elements on the end-user machine that is running the
installation:
• 32-bit version of the Oracle Instant Client software (even on 64-bit target systems)
The latest Microsoft Data Access Components (MDAC) include support for the Microsoft ODBC for Oracle drivers. However,
the Microsoft ODBC for Oracle driver requires Oracle Instant Client software to communicate with Oracle database servers.
Therefore, you may want to include the Oracle 11g Instant Client prerequisite to help configure the Oracle Instant Client on
target machines upon installation. Oracle does not provide an installation for the files; you can do so easily by using the
Oracle Instant Client installation project that is available in the InstallShield Program Files folder. For instructions, see
Downloading the Oracle Instant Client and Creating an .msi Package for It.
Note that if your SQL script contains Unicode characters, you may want to use the Oracle ODBC Instant Client, since it has
support for running SQL scripts that contain Unicode characters, but Microsoft ODBC for Oracle does not. You may want to
include an ODBC Instant Client installation with the Oracle 11g Instant Client prerequisite to help configure the Oracle
Instant Client on target machines, and to also set up the ODBC Instant Client. For more information, see Downloading the
Oracle Basic Instant Client and the Oracle ODBC Instant Client and Creating an .msi Package and InstallShield Prerequisite
for Both. If you plan on using the ODBC Instant Client instead of Microsoft ODBC for Oracle, ensure that you configure your
project accordingly. For more information, see Running SQL Scripts with Unicode Characters on an Oracle Database
Server.
Downloading the Oracle Instant Client and Creating an .msi Package for It
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
Before you can add Oracle 11g Instant Client support to your Basic MSI, InstallScript, or InstallScript MSI project, you must
download the Oracle Instant Client from Oracle’s Web site. Oracle does not provide an installation for the files, so you also
need to create an .msi package; you can do so easily by using the Oracle Instant Client installation project that is available
in the InstallShield Program Files folder.
Once you have created the .msi package, you can add it to the appropriate folder on your machine, and then add the
InstallShield prerequisite that uses this Oracle Instant Client .msi package.
Note • Note that if your SQL script contains Unicode characters, you may want to use the Oracle ODBC Instant Client, since it
has support for running SQL scripts that contain Unicode characters, but Microsoft ODBC for Oracle does not. You may want to
include an ODBC Instant Client installation with the Oracle 11g Instant Client prerequisite to help configure the Oracle Instant
Client on target machines, and to also set up the ODBC Instant Client. For more information, see Downloading the Oracle Basic
Instant Client and the Oracle ODBC Instant Client and Creating an .msi Package and InstallShield Prerequisite for Both.
Task To download the Oracle Instant Client and create an .msi package:
Important • The Oracle support in InstallShield requires that the target system have the 32-bit version of the Oracle
Instant Client, regardless of whether the target system is a 32-bit or 64-bit system.
2. Unzip the files to the root of your C drive. Unzipping the files adds all of the files to the following location:
C:\instantclient_11_1
3. Open the Oracle Instant Client installation project in InstallShield. The path for the project is as follows:
Revenera created this project for the 11.1.0.7 version of the Oracle Instant Client; however, you can use this same
project for more-recent versions of the Oracle 11g Instant Client, such as 11.2.01, for example.
4. The name that is displayed at run time during the Oracle 11g Instant Client installation is Oracle11g Instant Client
11.1.0.7; this name is also used for the .msi file. If you want to change this name to something else to reflect a different
version number, such as 11.2.0.1 or 11.2.0.x, you can do so:
5. If you are using a version that was released after 11.1.0.7 and it requires any dependencies, add the files or merge
modules to the project.
InstallShield builds an Oracle 11g Instant Client .msi file and adds it to the following directory so that you can include the
Oracle 11g Instant Client in your InstallShield projects:
Tip • If you are using a version that was released after 11.1.0.7, open the Oracle 11g Instant Client 11.1.0.7 prerequisite in the
InstallShield Prerequisite Editor. Rename the prerequisite to reflect the appropriate version number. In addition, update the
conditions to reflect the appropriate version number.
For instructions on how to add the Oracle 11g Instant Client to installations, see Installing the Oracle 11g Instant Client.
See Also
Modifying an Existing InstallShield Prerequisite
Setting Installation Conditions for an InstallShield Prerequisite
Downloading the Oracle Basic Instant Client and the Oracle ODBC Instant Client and Creating
an .msi Package and InstallShield Prerequisite for Both
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
Before you can add support for the Oracle 11g Instant Client and the Oracle ODBC Instant Client to your Basic MSI,
InstallScript, or InstallScript MSI project, you must download the Oracle Basic Instant Client and the Oracle ODBC Instant
Client from Oracle’s Web site. Oracle does not provide an installation for the files, so you also need to create an .msi
package; you can do so easily by using the Oracle Instant Client installation project that is available in the InstallShield
Program Files folder.
Once you have created the .msi package, you can add it to the appropriate folder on your machine, and then add the
InstallShield prerequisite that uses this Oracle .msi package.
Task To download the Basic Instant Client and the ODCBC Instant Client and create an .msi package:
version of the Instant Client Package for ODBC. The download files are called instantclient-basic-win32-
11.1.0.7.0.zip and instantclient-odbc-win32-11.1.0.7.0.zip.
Important • The Oracle support in InstallShield requires that the target system have the 32-bit version of the Basic
Instant Client and of the ODBC Instant Client, regardless of whether the target system is a 32-bit or 64-bit system.
2. Unzip the files to the root of your C drive. Unzipping the files adds all of the files to the following location:
C:\instantclient_11_1
3. Make a copy of the Oracle Instant Client installation project. The path for the project is as follows:
Name the copy instantclient-win32-odbc11_1.ism, and put it in the same directory as the original .ism file. The
path for this new file is:
Revenera created the instantclient-win32-11_1.ism project for the 11.1.0.7 version of the Oracle Instant Client;
however, you can use this same project for more-recent versions of the Oracle 11g Instant Client and ODBC Instant
Client, such as 11.2.01, for example.
5. Update the product code, the upgrade code, and the product name:
b. In the Product Code setting, click the Generate a new GUID button ({..}).
c. In the Upgrade Code setting, click the Generate a new GUID button ({..}).
The name that you enter is displayed at run time during the Oracle installation. If you want to change this name
to something else to reflect a different version number, such as 11.2.0.1 or 11.2.0.x, you can do so.
6. If you are using a version that was released after 11.1.0.7 and it requires any dependencies, add the files or merge
modules to the project.
7. Add a custom action that launches the ODBC Instant Client installation:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences.
b. In the center pane, right-click the Custom Actions explorer, point to New EXE, and click Path referencing a
directory. InstallShield adds a new custom action.
8. Add a custom action that uninstalls the ODBC Instant Client when end users uninstall the Instant Client:
a. In the View List under Behavior and Logic, click Custom Actions and Sequences.
b. In the center pane, right-click the Custom Actions explorer, point to New EXE, and click Path referencing a
directory. InstallShield adds a new custom action.
b. In the center pane, in the Releases explorer, click the product configuration called Product Configuration 1.
c. In the MSI Package File Name setting, enter the following name:
InstallShield will use the name that you enter for the .msi package that it creates for the Basic Instant Client and
ODBC Instant Client. This is the file that will be launched by the InstallShield prerequisite that you create.
InstallShield builds an Oracle .msi file and adds it to the following directory so that you can include the Oracle11g Instant
Client - ODBC 11.1.msi file in your InstallShield projects:
Task To create an InstallShield prerequisite that launches the .msi package that you created in the aforementioned
procedure:
1. Make a copy of the existing InstallShield prerequisite (.prq) for the Oracle11g Instant Client. The path for the
prerequisite is as follows:
Name the copy Oracle11g Instant Client - ODBC 11.1.0.7.prq, and put it in the same directory as the original
.prq file. The path for this new file is:
2. On the Tools menu, click Prerequisite Editor. The InstallShield Prerequisite Editor opens.
3. On the File menu, click Open. The Open dialog box opens.
4. Browse to the new Oracle11g Instant Client - ODBC 11.1.0.7.prq file, and then click the Open button.
5. On the Properties tab, in the Unique identifier for InstallShield prerequisite setting, enter:
b. Click each existing condition and then click the Remove button.
c. Click the Add button. The Prerequisite Condition dialog box opens.
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Oracle in instantclient11_1
g. Select the If the specified registry key DOES NOT EXIST option, and then click OK.
b. Select the existing Oracle11g Instant Client 11.1.msi file, and then click the Modify button. The New File dialog
box opens.
c. Select the Oracle11g Instant Client - ODBC 11.1.msi file that you built in the aforementioned procedure,
and then click OK.
b. In the Specify the application you wish to launch setting, select the .msi file.
For instructions on how to add the Oracle 11g Instant Client and the ODBC Instant Client to installations, see Installing the
Oracle 11g Instant Client.
If you plan on using the Oracle ODBC Instant Client instead of Microsoft ODBC for Oracle, ensure that you configure your
project accordingly. For more information, see Running SQL Scripts with Unicode Characters on an Oracle Database
Server.
See Also
Modifying an Existing InstallShield Prerequisite
Setting Installation Conditions for an InstallShield Prerequisite
• Basic MSI
• InstallScript
• InstallScript MSI
If you want to install the Oracle 11g Instant Client when your installation is run, you can include the Oracle 11g Instant
Client prerequisite in your project.
Note that before you can include the InstallShield prerequisite, you must download the Oracle Basic Instant Client and
create an .msi package. If you also want the Oracle ODBC Instant Client to be installed—for example, if you need to use
Unicode support with Oracle—you must download the Basic Instant Client and the ODBC Instant Client, build an .msi
package, and create an InstallShield prerequisite; you can use the Oracle 11g Instant Client prerequisite as a template, and
modify the settings as needed. For more information, see:
• Downloading the Oracle Instant Client and Creating an .msi Package for It
• Downloading the Oracle Basic Instant Client and the Oracle ODBC Instant Client and Creating an .msi Package and
InstallShield Prerequisite for Both
Important • The Oracle support in InstallShield requires that the target system have the 32-bit version of the Oracle Instant
Client, regardless of whether the target system is a 32-bit or 64-bit system.
Task To include the Oracle 11g Instant Client prerequisite in your project:
1. For Basic MSI and InstallScript MSI projects: In the View List under Application Data, click Redistributables.
For InstallScript projects: In the View List under Application Data, click Prerequisites.
2. In the list of redistributables, select the Oracle11g Instant Client 11.1.0.7 check box (or the check box for whatever
Oracle prerequisite that you are using).
The InstallShield prerequisite is launched only if the conditions that are defined in the InstallShield prerequisite file (.prq)
are met. To see the list of conditions, click the Oracle prerequisite in the Redistributables view or the Prerequisites view,
and then review the details that are listed in the details pane on the right. You can hide or show the details pane by clicking
the Show Details button in these views.
Note • If you want your installation to download the Oracle 11g Instant Client whenever it needs to be installed on a target
system, check with Oracle to ensure that it is allowed. If it is allowed, you must host the download on your own Web site and
add its download path to the InstallShield prerequisite. Revenera does not make this installation available for download.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
For installations that use the default SQL script support that is available in the SQL Scripts view of InstallShield, Microsoft
ODBC for Oracle is used to connect to an Oracle database server on a target system. In some cases, you may want to
override the default behavior, and use the Oracle ODBC Instant Client instead of Microsoft ODBC for Oracle.
For example, if your SQL script contains Unicode characters, you may want to use the Oracle ODBC Instant Client, since it
has support for running SQL scripts that contain Unicode characters, but Microsoft ODBC for Oracle does not.
Task To configure your InstallShield project so that your installation uses the Oracle ODBC Instant Client instead of Microsoft
ODBC for Oracle:
{Oracle in instantclient11_1}
DBQ=
At run time, the installation uses the Oracle ODBC Instant Client for connecting to the Oracle database and running SQL
scripts.
Tip • The Oracle ODBC Instant Client is available on a target system if the ODBC package of the Oracle Instant Client software
is installed. To learn how to add it to your installation, see Downloading the Oracle Basic Instant Client and the Oracle ODBC
Instant Client and Creating an .msi Package and InstallShield Prerequisite for Both.
• Basic MSI
• InstallScript MSI
The following procedure demonstrates how to create an installation that creates a SQL Server database through
customized SQL script.
Task To create an installation that creates a SQL Server database on the target machine by running customized SQL script:
2. In the View List under Behavior and Logic, click Property Manager.
IS_SQLSERVER_DATABASE2
a. Right-click the SQL Scripts explorer and click New SQL Connection. InstallShield adds a new connection with
the name NewConnection1 as the default name.
b. In the SQL Scripts explorer, click the NewConnection1 item, and then click the General tab.
e. In the Connect using area, select the Server authentication using the Login ID and password below option.
f. In the Login ID box, type sa. Leave the Password box blank.
h. Ensure that the Microsoft SQL Server check box is selected and the MySQL and Oracle check boxes are cleared.
a. In the SQL Scripts explorer, right-click NewConnection1 and click New Script.
c. In the SQL Scripts explorer, click NewScript1, and then click the Script tab.
CREATE DATABASE [TestDB] ON (NAME = N' TestDB', FILENAME = N'C:\Program Files\Microsoft SQL
Server\MSSQL\data\testdb.mdf' , SIZE = 3, FILEGROWTH = 10%) LOG ON (NAME = N' TestDB_log',
FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL\data\testdb.ldf' , SIZE = 1, FILEGROWTH
= 10%)
COLLATE SQL_Latin1_General_CP1_CI_AS
f. In the Script Execution area, select the Run Script During Login check box and ensure that the Run Script
During Install and Run Script During Uninstall check boxes are cleared.
a. Right-click the SQL Scripts explorer and click New SQL Connection. InstallShield adds a new connection with
the name NewConnection2 as the default name.
b. In the SQL Scripts explorer, click the NewConnection2 item, and then click the Advanced tab.
h. In the Connect using area, select the Server authentication using the Login ID and password below option.
i. In the Login ID box, type sa. Leave the Password box blank.
k. Ensure that the Microsoft SQL Server check box is selected and the MySQL and Oracle check boxes are cleared.
a. In the SQL Scripts explorer, right-click NewConnection2 and click New Script.
c. In the SQL Scripts explorer, click NewScript2, and then click the Script tab.
f. In the Script Execution area, select the Run Script During Install check box and ensure that the Run Script
During Login and Run Script During Uninstall check boxes are cleared.
When you run the installation, it creates the TestDB database and adds a table called TestTable to that database.
Project • You can achieve the same outcome when following the above procedure but using a DIM project, and then adding
the DIM to an installation project.
• Basic MSI
• InstallScript MSI
The following procedure demonstrates how to create an installation that creates an Oracle schema through customized
SQL script.
Task To create an installation that creates an Oracle schema on the target machine by running customized SQL script:
2. In the View List under Behavior and Logic, click Property Manager.
IS_SQLSERVER_DATABASE2
IS_SQLSERVER_USERNAME2
IS_SQLSERVER_PASSWORD2
a. Right-click the SQL Scripts explorer and click New SQL Connection. InstallShield adds a new connection with
the name NewConnection1 as the default name.
b. In the SQL Scripts explorer, click the NewConnection1 item, and then click the General tab.
c. In the Default Target Server Name (optional) box, type the following:
//sch01jsmith.installshield.com:1521/orcl
e. In the Connect using area, select the Server authentication using the Login ID and password below option.
i. Ensure that the Oracle check box is selected and the Microsoft SQL Server and MySQL check boxes are cleared.
a. In the SQL Scripts explorer, right-click NewConnection1 and click New Script.
c. In the SQL Scripts explorer, click NewScript1, and then click the Script tab.
CREATE TABLESPACE TEST_TS LOGGING DATAFILE 'test01.dbf' SIZE 1M AUTOEXTEND ON NEXT 2M MAXSIZE
UNLIMITED
Go
CREATE USER TEST_USER IDENTIFIED BY MYPSWD DEFAULT TABLESPACE TEST_TS QUOTA UNLIMITED on TEST_TS
Go
GRANT CONNECT TO TEST_USER
Go
GRANT DBA TO TEST_USER
Go
f. In the Script Execution area, select the Run Script During Login check box and ensure that the Run Script
During Install and Run Script During Uninstall check boxes are cleared.
a. Right-click the SQL Scripts explorer and click New SQL Connection. InstallShield adds a new connection with
the name NewConnection2 as the default name.
b. In the SQL Scripts explorer, click the NewConnection2 item, and then click the Advanced tab.
i. In the Default Target Server Name (optional) box, type the following:
//sch01jsmith.installshield.com:1521/orcl
j. In the Connect using area, select the Server authentication using the Login ID and password below option.
n. Ensure that the Oracle check box is selected and the Microsoft SQL Server and MySQL check boxes are cleared.
a. In the SQL Scripts explorer, right-click NewConnection2 and click New Script.
c. In the SQL Scripts explorer, click NewScript2, and then click the Script tab.
f. In the Script Execution area, select the Run Script During Install check box and ensure that the Run Script
During Login and Run Script During Uninstall check boxes are cleared.
When you run the installation, it creates the TEST_USER user and a TestTable table on the TEST_USER schema.
Project • You can achieve the same outcome when following the above procedure but using a DIM project, and then adding
the DIM to an installation project.
Edition • The Suite/Advanced UI project type is available in the Premier edition of InstallShield. For information about the
differences between these two project types, see Advanced UI Projects vs. Suite/Advanced UI Projects.
SQL servers are integral to many applications, especially those that benefit from the multiple package support provided by
InstallShield Suite installations. Previously, InstallShield SQL support was limited to Basic MSI, InstallScript, and
InstallScript MSI projects. Now, SQL support has been added to Suite/Advanced UI projects, giving you the ability to:
The SQLLogin wizard page lets end users enter database server login information (database server name, authentication
credentials, database catalog name, etc.) in order to establish a connection to the database server that is targeted by one
or more .msi packages in the suite.
• Specify properties that identify the SQL login settings in the Suite project and then select the .msi package that
receives these properties
• Specify the properties that identify the SQL login settings in the .msi package
• Choose the database technology (Microsoft SQL Server, Microsoft Windows Azure, MySQL, or Oracle) and select the
ODBC driver to be targeted
• Ensure that updated SQL drivers will be scheduled for installation via an action in OnBegin
In addition, Suite/Advanced UI projects now support directly executing SQL statements on SQL database servers from the
user interface, helping to examine SQL database servers before proceeding the installation. The SQL query result can then
be accessed in a Suite property.
The following shows how to add a SQLLogin predefined wizard page to your project. Alternatively, you can manually
configure SQL support in your Suite project in order to customize the UI based upon your installation’s needs.
Task To add a SQLLogin predefined wizard page and optionally execute a SQL statement directly in a Suite/Advanced UI
project:
2. In the Wizard Interface explorer, right-click Wizard Pages and then click Add Predefined Page. The User Interface
Wizard opens.
3. In the Task page list, select Enter login information for a database server.
4. In the Subsequent page list, indicate where in the wizard page sequence you want to schedule the database server
wizard page. The page that you select in this list will be displayed immediately after the new database server wizard
page at run time.
a. Specify properties that identify the SQL login settings in the Suite project.
Note • A suite project may have multiple packages that require different SQL servers or they may need to share.
InstallShield adds corresponding Page Entered settings for the Task Configuration properties you specify.
6. To optionally add a SQL statement to be directly executed from the Suite/Advanced UI project at runtime, add a Run a
SQL String action to your project and specify its subsettings as needed. The SQL query result will be accessible from
the Suite property that you specify in the Data Property subsetting.
See Also
Sequencing Wizard Pages
User Interface Wizard
Wizard Interface View
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The Component Services view enables you to manage COM+ applications and components for your installation package.
You can manage both COM+ server applications and application proxies. A COM+ application proxy consists of a subset of
the attributes of the server application, and it enables remote access from a client machine to the machine where the
application resides.
• Only non-system COM+ applications can be added to your project. Therefore, InstallShield displays only non-system
COM+ applications under the COM+ Applications explorer in the Component Services view.
• Only the COM+ applications that are installed on the local machine are included in the Component Services view and
available for you to add to your projects.
• An application proxy is available for COM+ server applications only, not for library applications.
The look and feel of the Component Services view is similar to that of the Component Services administrative tool in the
Control Panel.
See Also
Managing COM+ Server Applications
Managing COM+ Application Proxies
Including a COM+ Application that Targets Servers and Client Machines
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
2. In the Component Services explorer, select the COM+ application that you would like to configure if you have not
already done so.
Note • You must select the Proxy check box, the Server check box, or both check boxes. Once you clear one of these
check boxes, the other check box remains selected but it is no longer available; this prevents you from clearing both check
boxes.
4. Select the Refresh the COM+ settings from the client machine at build check box if appropriate.
5. If your installation does not include the COM+ application proxy support, clear the Proxy check box
When you add a COM+ server application to your project, InstallShield creates a corresponding component for each of the
features that are associated with the proxy component. This component has the COM+ application’s server .dll files.
Note • If the selected COM+ application includes both server and proxy installations, you can add installation conditions so
that the appropriate COM+ application is installed on the target machine. For more information, see Including a COM+
Application that Targets Servers and Client Machines.
See Also
Component Services View
Managing COM+ Application Proxies
Including a COM+ Application that Targets Servers and Client Machines
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
The COM+ application proxy support configures the system settings that enable remote access from a client machine to the
machine where the server application resides. You may also need to add the client application to your installation.
2. In the Component Services explorer, select the COM+ application that you would like to configure if you have not
already done so.
4. Clear the Server check box if your installation does not include the COM+ server application.
Note • You must select the Proxy check box, the Server check box, or both check boxes. Once you clear one of these
check boxes, the other check box remains selected but it is no longer available; this prevents you from clearing both check
boxes.
5. In the Remote Server Name box, specify the name of the remote server computer where the application resides. You
can type the exact name or use the default [REMOTESERVERNAME] property, which is automatically created when you
select the Proxy check box for a COM+ application in your installation.
Note • The default value for the [REMOTESERVERNAME] property is the name of the machine used to add the COM+
application to the installation project in InstallShield. To change the value of the [REMOTESERVERNAME] property, use the
Property Manager view.
If you would like the end user to be able to specify the remote server, add a Remote Server edit field control to an end-user
dialog in the Dialogs view. Set the Property value of this control to REMOTESERVERNAME.
6. Select the Enable distributed COM on the client machine check box if appropriate. Clear this check box if you know
that distributed component object model (DCOM) is already enabled on all client machines and you will not have
administrative privileges on them.
If you select this check box, Y is written at installation time to the EnableDCOM entry of the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole registry key to enable DCOM.
Note • End users can enable or disable DCOM on their machines using the Component Services administrative tool in the
Control Panel. However, the application proxy will not work on a client machine if DCOM is disabled on that machine. For
this reason, you may want to select the Enable distributed COM on the client machine check box.
If an end user uninstalls the application proxy support, the EnableDCOM registry entry is not changed, even if the
installation process involved changing this registry entry to Y on the target machine.
When you add a COM+ application proxy to your project, InstallShield creates a corresponding component for each of the
features that are associated with the server component. This component has the COM+ application’s server .dll files. These
server files are installed on the client machine for the type libraries.
Note • If the selected COM+ application includes both server and proxy installations, you can add installation conditions so
that the appropriate COM+ application is installed on the target machine. For more information, see Including a COM+
Application that Targets Servers and Client Machines.
See Also
Component Services View
Managing COM+ Application Proxies
Including a COM+ Application that Targets Servers and Client Machines
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
If you want your installation to install the server application on the server as well as the application proxy support on client
machines, you can create installation conditions so that the appropriate component is installed on the target machine. The
following example procedure illustrates how you can do this.
Task To include a COM+ application in an installation that targets both servers and client machines:
2. In the Dialogs view, add a radio button group control to a new or existing end-user dialog, and set the Property value
of this control to COMPLUSTYPE. This radio button group will enable end users to specify which installation they would
like to run: server or proxy.
3. Add a radio button for the Server option to the radio button group, and set the Value property of this control to
Server.
4. Add a radio button for the Proxy option to the radio button group, and set the Value property of this control to Proxy.
5. In the Component Services view, select the COM+ application that you would like to configure.
6. On the Installation tab, set the parameters for server installations and application proxies.
7. In the Condition box under the Server check box, type the following:
COMPLUSTYPE="Server"
8. In the Condition box under the Proxy check box, type the following:
COMPLUSTYPE="Proxy"
See Also
Component Services View
Managing COM+ Application Proxies
Including a COM+ Application that Targets Servers and Client Machines
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
Internet Information Services (IIS) is a Web server developed by Microsoft. It provides a secure platform for building and
deploying Web-based applications, managing Web sites, and publishing information to the Internet or an intranet.
The Internet Information Services view in InstallShield enables you to create and manage new IIS Web sites, applications,
virtual directories, application pools, and Web service extensions.
See Also
Internet Information Services View
Creating a Web Site and Adding an Application or a Virtual Directory
Feature and Component Associations for IIS Support
Configuring Advanced IIS Settings
Uninstalling Web Sites, Applications, and Virtual Directories
Adding IISROOTFOLDER Support
Adding Project Output from a Web Service or Web Application Project
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
• IIS is included with Windows 2000 Server and later and Windows XP and later systems. IIS 6 is available only on
Windows Server 2003 systems. IIS 7 is available on Windows Vista and Windows Server 2008 systems. IIS 7.5 is
available on Windows 7 and Windows Server 2008 R2 systems. IIS is not installed automatically by default.
• Some of the Web site and virtual directory settings in the Internet Information Services view apply to specific versions
of IIS. Version-specific information is noted for these settings in the inline help panes in InstallShield. If you configure a
version-specific property but a target system does not have the corresponding version of IIS, IIS ignores the version-
specific property.
For example, IIS 7 and IIS 6 do not support the Application Protection property for applications or virtual directories.
In the Internet Information Services view, this property is configured through a setting in the Application Settings area
for an application or a virtual directory. When you select this setting in the Internet Information Services view, the help
pane that is displayed in the lower-right corner indicates that the setting does not apply to IIS 6 or later. If you
configure this setting and an end user installs your product on a target system that has IIS 6 or later, the Application
Protection setting is ignored.
• Web service extensions, application pools, and all of the associated properties are available only on machines with IIS
6 or later.
On systems with IIS 7, Web service extensions require that the IIS Metabase and IIS 6 Configuration Compatibility
feature be installed. If it is not installed, the installation’s log file may show error -2147467259 to inform you that this
feature may be required.
For information on how to determine whether a Windows Vista or Windows Server 2008 system has the IIS Metabase
and IIS 6 Configuration Compatibility feature installed, see Determining If a Target System Has IIS 6 or Earlier or the
IIS 6 Metabase Compatibility Feature.
• Windows Vista and later and Windows Server 2008 and later systems store settings for individual Web sites,
applications, and virtual directories in configuration files that are located at the physical path that you specify in your
installation project—in the Content Source Path (Local or UNC) setting in the Internet Information Services view.
Therefore, each Web site, application, or virtual directory should have a unique physical path. Otherwise, you may
notice unexpected behavior, especially in testing environments, if you have two different applications or virtual
directories with the same physical path.
For example, if you have two virtual directories that have the same physical path, and directory browsing is enabled in
one but not the other, the directory browsing setting for the second virtual directory that is created overrides the
setting for the first virtual directory.
• On systems that have Windows Server 2003, if IIS 6 is not installed, other IIS directories and sites are still created. IIS 6-
specific settings are skipped.
• IIS 5.1 for Windows XP Professional can service only one Web site at a time. This is a limitation of IIS 5.1.
See Also
Web Site Settings
Application and Virtual Directory Settings
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
When you add a Web site in the Internet Information Services view, an entry is added to the System Search view to search
for the version of IIS that is installed on the target system. The IIS_VERSION property is set by entries in the RegLocator
and AppSearch tables (available in the Direct Editor), which determine the version of IIS that is installed.
The IIS_VERSION property contains the IIS version number. If you need to determine the IIS version that is installed, check
the value of this property.
See Also
Managing Internet Information Services
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
IIS support in InstallShield installations works only if IIS is installed on the target machine and the end user has
administrative privileges.
During the installation of a package that includes IIS settings, an InstallShield installation checks for the existence of IIS on
the target machine. If IIS is not installed, the installation displays a dialog informing the end user that they do not have IIS
installed. The dialog gives the end user the option to abort, retry, or ignore:
• If the end user installs IIS and then chooses to retry, the installation checks for IIS again, and continues with the
installation. If the end user does not install IIS but still chooses to retry, the installation checks for IIS again and then
displays the dialog again.
• If the end user chooses to ignore, the installation continues, but IIS Web sites, applications, virtual directories, and
other IIS elements are not configured.
Note • InstallShield does not support the creation of Web sites on target machines other than the one on which the
installation is running.
Project • If you are creating an application pool in an InstallScript project and you want the application pool to be associated
with a virtual directory, application, or Web site, you must create the application pool and the virtual directory, application, or
Web site within the same component. If you do this, the application pool is created before the virtual directory, application, or
Web site is created. This is a requirement of IIS 6 and later, and it is not a limitation for Basic MSI, DIM, InstallScript MSI, or
Merge Module projects.
See Also
Determining Which Version of IIS Is Installed
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
Server-side include (SSI) directives instruct a Web server to insert content into a Web page. The #exec type of directive
enables the Web server to include the output of a shell command in a Web page.
You can configure an IIS Web server to prevent the CMD command for the #exec directive from being used to execute shell
commands, or you can configure it to allow the CMD command to be used to execute this type of command. The
SSIEnableCmdDirective registry value for the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters registry key is what determines whether
the CMD command is permitted.
InstallShield lets you specify how your installation should configure the SSIEnableCmdDirective registry value on target
systems. If you do not want your installation to change the SSIEnableCmdDirective registry value, you can also specify that.
Because of security concerns, the default SSIEnableCmdDirective registry value is FALSE (0); the FALSE (0) value prevents
end users from running unauthorized server-side executable files.
Task To specify whether a Web server should allow the CMD command to be used for SSI #exec directives:
1. In the View List under Server Configuration, click Internet Information Services.
2. In the center pane, click the Web Sites explorer. InstallShield displays the Web server settings in the right pane.
3. For the SSIEnableCmdDirective registry value setting, select the appropriate option:
• Ignore—Do not change the SSIEnableCmdDirective registry value on the target system. This is the default option.
• FALSE (0)—Set the SSIEnableCmdDirective registry value on the target system to 0. This prevents the #exec CMD
directive of server-side includes to be used to execute shell commands. Note that if you select this value and an
IIS Web server has applications that rely on #exec CMD directives, those applications may stop working properly
after your installation project’s Web site and virtual directory are installed.
• TRUE (1)—Set the SSIEnableCmdDirective registry value on the target system to 1. This allows the #exec CMD
directive of server-side includes to be used to execute shell commands.
If you select the FALSE or TRUE options, InstallShield stores the value—either 0 for FALSE or 1 for TRUE—in the
INSTALLSHIELD_SSI_PROP property.
If one or more Web sites, virtual directories, application pools, or Web service extensions in your installation are installed
on a target system and you selected the FALSE or TRUE options for the SSIEnableCmdDirective registry value setting, the
SSIEnableCmdDirective registry value is updated on the target system.
Note • If your product is uninstalled from a target system, the SSIEnableCmdDirective registry value is not changed, even if its
value was changed during installation.
See Also
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
The Internet Information Services view in InstallShield is where you add an IIS Web site to your project. It is also where you
can add applications and virtual directories to a Web site. Note that you can add a Web site without any applications or
virtual directories if you associate the Web site with a component.
1. In the View List under Server Configuration, click Internet Information Services.
2. Right-click the Web Sites explorer and click Add Web Site. InstallShield adds a new Web site.
Tip • InstallShield lets you specify the TCP port and site numbers for a Web site in your project. These settings help determine
whether a new Web site is created or an existing one is updated at run time. To learn more, see Configuring the TCP Port and
Site Numbers.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, right-click the Web site that should contain the application and click New Application.
InstallShield adds a new application.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, right-click the Web site that should contain the virtual directory and click New Virtual
Directory. InstallShield adds a new virtual directory.
Note • To learn how Web sites, applications, and virtual directories are associated with components and features, see
Feature and Component Associations for IIS Support.
See Also
Internet Information Services View
Adding Files to an IIS Virtual Directory
Scanning an IIS Web Site and Importing Its Settings into an InstallShield Project
Deploying Web Services on a Target Machine
Specifying Whether a Component’s Files and Other Associated Data Are Uninstalled During Uninstallation
Scanning an IIS Web Site and Importing Its Settings into an InstallShield Project
InstallShield 2020
Edition • The ability to import IIS data into an InstallShield project is available only in the Premier edition of InstallShield.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield includes support for scanning an existing IIS Web site, recording IIS data about the Web site, and importing
those settings into the Internet Information Services view of an InstallShield project. Once you have imported the data into
a project, you can make changes to the IIS settings as needed, and build an installation that creates or maintains an IIS Web
site.
The IIS scanner (IISscan.exe) is a command-line tool that scans an IIS Web site and records the values of the settings that
you can configure in the Internet Information Services view in InstallShield. IISscan.exe creates an XML file that contains
all of the values. You can use this XML file to import the values into the Internet Information Services view.
Task To scan an existing Web site and record all of the IIS data that can be configured in the Internet Information Services
view:
1. Place the IISscan.exe tool on the server that has the IIS Web site that you want to scan.
2. At the command prompt, enter the command-line statement that launches the IIS scanner to scan a specific Web site.
Following is a sample statement:
The IIS scanner creates an XML file that contains the IIS data for the specified Web site.
Task To import the data from the XML file into an InstallShield project:
1. Obtain the XML file that the IIS scanner created, and place it in a location that can be accessed from the machine that
has InstallShield.
2. In the View List under Server Configuration, click Internet Information Services.
3. Right-click the Web Sites explorer and click Import Web Site. The Open dialog box opens.
4. Select the XML file that the IIS scanner created, and then click Open.
InstallShield imports the Web site and its settings into the Internet Information Services view. All of the Web site’s settings,
virtual directories, and applications are configured in this view during the import.
Tip • InstallShield lets you configure filters if you want to prevent certain IIS data—such as Web sites, applications, virtual
directories, application pool, or any of their settings—from ever being imported into the Internet Information Services view. To
learn more, see Filtering IIS Data When Importing a Web Site and Its Settings into an InstallShield Project.
See Also
Internet Information Services View
Creating a Web Site and Adding an Application or a Virtual Directory
Filtering IIS Data When Importing a Web Site and Its Settings into an InstallShield Project
InstallShield 2020
Edition • The ability to import IIS data into an InstallShield project is available only in the Premier edition of InstallShield.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
When you use an XML file that is generated by the IIS scanner to import an IIS Web site and its settings into the Information
Services view, you may find that certain IIS settings are imported, even though you do not need them to be configured in
your installation. To avoid having these settings configured every time that you use an XML file to import IIS settings, you
can edit Filters.xml. This file enables you to specify any IIS settings that you want the import to ignore.
The file must remain in this location after you edit it; otherwise, the IIS import will not work properly.
Tip • You can also use the Filters.xml file to control which registry items should be excluded during COM extraction. For
more information, see Filtering Registry Changes for COM Extraction.
The Filters.xml file also lets you control which files should be included or excluded during dependency scanning. For more
information, see Filtering Files in Dependency Scanners.
The type is required. The following table shows the available IIS item types:
Table 4-3 • Recognized Attributes for the type Attribute of the <IisScanItem> Subelement
1 Web site
2 Application
3 Virtual directory
4 Application pool
To prevent an IIS setting with a specific value from being imported into the Internet Information Services view, add the
following line within the <Exclude> element.
If this line is within the <Exclude> element, InstallShield blocks a setting named PropertyName with a value that equals or
contains PropertyValue.
Note • The property names and values are not Windows Installer properties and values. They are abbreviations for the names
and values of settings that InstallShield lets you configure in the Internet Information Services view.
Important • Ensure that your XML code is well formed; if its not well formed, all of the filters fail. In most cases, you can
identify improperly formed XML code by opening the Filters.xml file in Internet Explorer. You should be able to expand and
contract the <Filters>, <Include>, and <Exclude> elements; if you cannot, check the code for errors.
If you add subelements to the <Exclude> or <Include> elements, be sure that you do not place them within the commented-out
section, since InstallShield ignores that area of the Filters.xml file.
The following sample XML code shows the format of the Filters.xml file:
<Filters>
<Include>
<!--Instructions on how to add files to this element.
-->
<File name="mfc42.dll" We="needthis"/>
</Include>
<Exclude>
<!--Instructions on how to add files to this element.
-->
<Registry key="HKEY_CLASSES_ROOT\Interface\{00020404-0000-0000-C000-000000000046}"/>
<File name="12520437.cpx" path="[SystemFolder]" wrp="4.0-10.0" />
<File name="12520850.cpx" path="[SystemFolder]" wrp="4.0-10.0" />
<IisScanProperty name="AppMappings" value="*;;*;0" />
<IisScanProperty name="CustomErrors" value="C:\WINDOWS\help\iisHelp\common" />
</Exclude>
</Filters>
See Also
IISscan.exe
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
You can also create a virtual subdirectory under a virtual directory that is being installed as part of your installation. The
parent virtual directory must be installed before the virtual subdirectory.
Project • For InstallScript projects, if a parent virtual directory should be installed before its child virtual subdirectory, the
component that contains the parent virtual directory must be installed before the component that contains the child virtual
subdirectory.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site that should contain the nested virtual directory.
3. Right-click the new Web site and click New Virtual Directory. InstallShield adds a new virtual directory.
5. In the Name setting, indicate the name of the existing directory, as well as the name of the nested virtual subdirectory
that you want to create. Separate both names with a slash.
For example, to create a virtual directory called MySubDirectory under the existing virtual directory called
VirtualDirectory, enter the following:
VirtualDirectory/MySubDirectory
Note • If the parent directory does not already exist on the target system, the target system displays an error when the end
user opens the directory in the IIS Manager.
See Also
Internet Information Services View
Creating a Web Site and Adding an Application or a Virtual Directory
Adding Files to an IIS Virtual Directory
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield lets you specify the TCP port and site numbers for a Web site in your project. These settings help determine
whether a new Web site is created or an existing one is updated at run time. They also affect whether the Web site settings
that are configured in the Internet Information Services view are applied to a Web site on the target system.
Task To specify the TCP port and site numbers for a Web site:
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site that you want to configure.
4. In the TCP Port Number and Site Number boxes, enter the appropriate numbers.
Run-Time Behavior
At run time, the installation creates the Web site, applications, and virtual directories according to the following rules:
Table 4-4 • Run-Time Results for Various Sample TCP Port Number and Site Number Setting Values
0 Any non-zero number Since the TCP Port Number setting is 0 but the Site
Number setting is not 0, the installation installs the Web
site’s applications and virtual directories to the first site
number on the system. The specified site number is
ignored.
The installation does not apply any of the Web site settings
that are configured in the Internet Information Services
view to the Web site on the target system.
80 (a non-zero number) 0 (the default value) If the specified TCP port exists on the target system, the
installation installs the applications and virtual directories
to the Web site that is running on the TCP port—in this
example, port 80. The installation does not apply any of
the Web site settings that are configured in the Internet
Information Services view to the Web site on the target
system.
If the TCP port does not exist on the target system, a new
Web site is created with the Web site settings that are
configured in the project. In addition, the installation
installs the Web site’s applications and virtual directories.
Table 4-4 • Run-Time Results for Various Sample TCP Port Number and Site Number Setting Values (cont.)
81 (a non-zero number) 3 (a non-zero number) If the specified TCP port and site number exist on the
target system, the installation installs the applications and
virtual directories under the Web site whose site number
matches the specified one—in this example, site number 3.
The installation does not apply any of the Web site settings
that are configured in the Internet Information Services
view to the Web site on the target system.
If the TCP port exists on the target system but the site
number does not, the installation installs the new Web
site, plus its applications and virtual directories, to the
existing port with the new site number. In addition, the
installation configures the Web site’s properties that are
set in the Internet Information Services view.
If the TCP port does not exist on the target system but the
site number does, the installation installs the new Web
site, plus its applications and virtual directories, to this
TCP port. In addition, the installation configures the Web
site’s properties that are set in the Internet Information
Services view.
Installing an IIS Web Site and Its Applications and Virtual Directories to the Next
Available New Site Number
The following procedures demonstrate how to install an IIS Web site and its applications and virtual directories to the next
available new site number. Note that the procedure differs, depending on the project type.
Task To install to the next available new site number for a Basic MSI, DIM, InstallScript MSI, or Merge Module project:
1. Create a new Windows Installer property and set its value to INSTALLSHIELD_IIS_NEXT_NEW_SITE_NUMBER:
a. In the View List under Behavior and Logic, click Property Manager.
b. Click the New Property button. InstallShield adds a new row at the bottom of the view.
MYPROPERTY
INSTALLSHIELD_IIS_NEXT_NEW_SITE_NUMBER
a. In the View List under Server Configuration, click Internet Information Services.
b. In the Web Sites explorer, select the Web site that you want to configure.
c. For the Site Number setting, enter the property that you created in step 1c. It must be in uppercase letters and
enclosed within brackets; for example:
[MYPROPERTY]
At run time, the installation installs the Web site and its applications and virtual directories to the next available new site
number.
Task To install to the next available new site number during an InstallScript installation:
b. Click the New String Entry button. The String Entry dialog box opens.
c. In the String Identifier box, enter a new variable name; the variable name must be in uppercase letters; for
example:
MYPROPERTY
INSTALLSHIELD_IIS_NEXT_NEW_SITE_NUMBER
a. In the View List under Server Configuration, click Internet Information Services.
b. In the Web Sites explorer, select the Web site that you want to configure.
c. For the Site Number setting, enter the variable that you created in step 1c. It must be in uppercase letters.
At run time, the installation installs the Web site and its applications and virtual directories to the next available new site
number.
See Also
Web Site Settings
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield lets you specify the host header name to identify an IIS Web site that is installed during your installation. Host
headers (also known as domain names) enable you to assign more than one Web site to an IP address on a Web server.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site whose host header name you want to specify.
3. For the Host Header Name setting, type the host header name that you want to use. For example:
www.mycompany.com
See Also
Determining If a Target System Has IIS 6 or Earlier or the IIS 6 Metabase Compatibility Feature
Web Site Settings
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
A server certificate enables users to authenticate your Web server, check the validity of the Web content, and establish a
secure connection. InstallShield lets you include a server certificate for a Web site in your installation so that it can be
installed at run time.
Task To specify a SSL certificate that should be installed for a Web site:
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site whose SSL certificate you want to specify.
3. For the SSL Certificate setting, click the ellipsis button (...). The Open dialog box opens.
4. Select the security certificate file (.cer or .pfx) that you want to be installed, and then click Open.
5. If the certificate requires a password, specify it for the SSL Certificate Password setting.
InstallShield stores the .cer file in the Binary table. At run time, when the installation installs the Web site and its virtual
directories, it also installs the SSL certificate.
See Also
Internet Information Services View
• Basic MSI
You can choose to include a Configure SSL for IIS dialog (IISBrowseSSLCertificate) in your installer that enables the end
user to browse to a IIS certificate file that they provide for the SSL Certificate and enter a password at installation runtime.
To add a Configure SSL for IIS dialog to your installer, perform the following steps:
1. In the View List under Server Configuration, click Internet Information Services.
2. Right-click the Web Sites explorer and click Add Web Site. InstallShield adds a new Web site.
3. Select the new web site and locate the SSL Certificate and SSL Certificate Password properties under Security >
Secure Communication.
4. Set the SSL Certificate and SSL Certificate Password properties to the following values:
Property Value
5. Open the User Interface > Dialogs view and add the IISBrowseSSLCertificate dialog to the dialog sequences.
The property name for the SSL Certificate and password configured by the user is required to update in the
IISBrowseSSLCertificate dialog for the Edit boxes (IISWebCertPassword and IISWebCertPath) and the push button
(BrowseCertificate) events.
See Also
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
1. Add an IIS Web site to your project if you have not already done so. InstallShield automatically adds the predefined
path [IISROOTFOLDER] to the Files and Folders view.
2. In the View List under Application Data, click Files and Folders.
3. In the Feature list, select the feature with which you want the file associated.
4. In the Destination computer’s folders pane, add the file to the [IISROOTFOLDER] folder, or a subfolder of the
[IISROOTFOLDER] folder.
5. In the View List under Server Configuration, click Internet Information Services.
7. In the Web Sites explorer, click the virtual directory that you created.
8. In the Content Source Path (Local or UNC) setting, click the ellipsis button (...). The Browse for Directory dialog box
opens. In a Basic MSI or InstallScript MSI project, this dialog box enables you to select a Windows Installer property
(such as [IISROOTFOLDER]) or create a new one. In an InstallScript project, this dialog box enables you to select an
InstallScript variable (such as <IISROOTFOLDER>) or create a new one. By default, the files are stored in
IISROOTFOLDER.
9. Enter the same target directory as the one that contains the new file that you added in the Files and Folders view.
At installation, files are copied to the target directory folder. In addition, the virtual directory is configured for that folder on
the target system if IIS is present.
See Also
Creating a Web Site and Adding an Application or a Virtual Directory
Adding IISROOTFOLDER Support
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, right-click the application or virtual directory and click Delete.
See Also
Uninstalling Web Sites, Applications, and Virtual Directories
Managing Internet Information Services
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
An application pool is a group of configuration settings that specify how one or more Web applications are routed to one or
more worker processes. InstallShield lets you create application pools and associate Web sites, applications, and virtual
directories with those application pools.
Project • If you are creating an application pool in an InstallScript project and you want the application pool to be associated
with a virtual directory, application, or Web site, you must create the application pool and the virtual directory, application, or
Web site within the same component. If you do this, the application pool is created before the virtual directory, application, or
Web site is created. This is a requirement of IIS 6 and later, and it is not a limitation for Basic MSI, DIM, InstallScript MSI, or
Merge Module projects.
Note • Application pools are available only on machines with IIS 6.0 or later installed.
Task To add a new application pool in the Internet Information Services view:
1. In the View List under Server Configuration, click Internet Information Services.
2. Right-click the Application Pools explorer and click Add Application Pool. InstallShield adds a new application pool
item.
3. Rename the new application pool item, and configure its settings.
See Also
Feature and Component Associations for IIS Support
Application Pool Settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Application Pools explorer, right-click the application pool and click Delete.
See Also
Uninstalling Web Service Extensions and Application Pools
Application Pool Settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
A Web service extension is an IIS feature that extends the basic IIS functionality beyond serving static content. Examples of
Web service extensions are active server pages (.asp), ASP.NET, and server-side includes (SSI).
Note • Web service extensions are available only on machines with IIS 6.0 or later installed.
On systems with IIS 7, Web service extensions require that the IIS Metabase and IIS 6 Configuration Compatibility feature be
installed. For more information, see Version-Specific Information for IIS Support in InstallShield.
1. In the View List under Server Configuration, click Internet Information Services.
2. Right-click the Web Service Extensions explorer and click Add Web Service Extension. InstallShield adds a new Web
service extension.
3. Rename the new Web service extension item, and configure its settings.
See Also
Web Service Extension Settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Service Extension explorer, right-click the Web service extension and click Delete.
See Also
Uninstalling Web Service Extensions and Application Pools
Web Service Extension Settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
There is a one-to-many relationship between components and IIS data (that is, Web sites, applications, virtual directories,
application pools, or Web service extensions). Therefore, you can associate more than one IIS element with a single
component. If a component is being installed, any Web sites, applications, virtual directories, application pools, and Web
service extensions that are associated with the component are created at run time.
Project • If a Web site is associated with a component in an InstallScript project, any applications or virtual directories that
are added to that Web site must be associated with the same component. Therefore, if you try to change the component for a
Web site that contains one or more applications or virtual directories, InstallShield displays a message box to inform you that
it will also make the same component change for all of that Web site’s applications and virtual directories; InstallShield also
displays this message box if you try to change the component for any applications or virtual directories in a Web site. In either
case, the message box enables you to proceed or cancel the component change.
Note that for Basic MSI, DIM, InstallScript MSI, and Merge Module projects, keeping a Web site in the same component as all of
the Web site’s applications and virtual directories is not required, but it is recommended.
If you are creating an application pool in an InstallScript project and you want the application pool to be associated with a
virtual directory, application, or Web site, you must create the application pool and the virtual directory, application, or Web
site within the same component. If you do this, the application pool is created before the virtual directory, application, or Web
site is created. This is a requirement of IIS 6 and later, and it is not a limitation for Basic MSI, DIM, InstallScript MSI, or Merge
Module projects.
At any time, you can use the Internet Information Services view to change which component contains the Web site,
application, virtual directory, application pool, or Web service extension.
Task To associate a Web site, application, virtual directory, application pool, or Web service extension with a different
component in your project:
1. In the View List under Server Configuration, click Internet Information Services.
2. In the explorer, click the Web site, application, virtual directory, application pool, or Web service extension that you
want to associate with a component.
3. In the Component setting, select the name of the existing component that should contain the selected IIS data. You
can click the ellipsis button (...) to select an existing component or create a new one for the IIS data.
Tip • If you delete a component in your project, any Web sites, applications, virtual directories, application pools, and Web
service extensions that are associated with the component are simultaneously removed from your project.
See Also
Specifying Whether a Component’s Files and Other Associated Data Are Uninstalled During Uninstallation
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
Web sites that are created by an installation are never removed unless both of the following conditions are true:
• The value for the Delete on Uninstall setting for the Web site in the Internet Information Services view is Yes.
Note • If a Web site is associated with a component, the Delete on Uninstall setting for the Web site corresponds with
the Permanent setting for that component in a Basic MSI, DIM, InstallScript MSI, or Merge Module project, or with the
Uninstall setting for that component in an InstallScript project. That is, if you select or clear the Delete on Uninstall
setting for a Web site, InstallShield automatically updates the value of the component’s Permanent setting or Uninstall
setting, as appropriate.
If a component is uninstalled, all of its Web sites, applications, and virtual directories are uninstalled. A component is not
uninstalled if it is configured to be permanent. For more information, see Specifying Whether a Component’s Files and
Other Associated Data Are Uninstalled During Uninstallation.
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
Note • Web service extensions, application pools, and associated properties are available only on machines with IIS 6.0 or
later installed.
On systems with IIS 7, Web service extensions require that the IIS Metabase and IIS 6 Configuration Compatibility feature be
installed. For more information, see Version-Specific Information for IIS Support in InstallShield.
Any Web service extensions and application pools installed in the IIS Manager that have identical names as the Web service
extensions and application pools in an installation will always be uninstalled when the features with which they are
associated are uninstalled unless their components are marked as permanent. Even if the Web service extension or
application pool was originally created by something other than the installation, it will be removed from the target system
upon uninstallation if the names (of the Web service extensions and application pools) match those in the installation. One
exception is that the default application pool, named DefaultAppPool, will never be removed by the uninstallation.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Service Extensions explorer, select the Web service extension.
1. In the View List under Server Configuration, click Internet Information Services.
If Yes is selected for the Mark Component as Permanent setting, the Web service extension or application pool is left on the
target system after uninstallation.
Tip • Changing the value of the Mark Component as Permanent setting affects the value of the Permanent setting (in Basic
MSI, DIM, InstallScript MSI, and Merge Module projects) or the Uninstall setting (in InstallScript projects) for the component
that contains the Web service extension or the application pool. Therefore, if you select Yes for the Mark Component as
Permanent and the component contains other data, such as files, shortcuts, and registry entries, the IIS data, as well as the
other data in the component, are not uninstalled during uninstallation.
See Also
Specifying Whether a Component’s Files and Other Associated Data Are Uninstalled During Uninstallation
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield lets you set the ASP.NET version for a Web site or application in your installation. If you specify the ASP.NET
version, after the Web site or application is created, the installation runs the ASP.NET IIS Registration tool
(Aspnet_regiis.exe) to map the Web site or application to the version that you specify.
If you specify the ASP.NET version for a Web site, IIS uses that value for the Web site that is created at run time, as well as for
any of its applications.
Important • Microsoft does not recommend using the Aspnet_regiis.exe tool on Windows Vista and Windows Server 2008
systems because it has limited capabilities. As a result, you may need to manually define application mappings in the Internet
Information Services view. To learn more, see Defining Application Mappings for a Web Site, Application, or Virtual Directory.
ASP.NET 3.0 does not include the Aspnet_regiis.exe tool. Therefore, you cannot set the ASP.NET version to version 3 of
ASP.NET.
Task To specify the ASP.NET version for a Web site or application in your project:
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site or application whose ASP.NET version you want to specify. The settings
for the Web site or application are displayed on the right.
3. For the ASP.NET Version setting, enter the complete version number of the .NET Framework that is required by your
application, or select it from the list.
For example, to specify version 2 of ASP.NET, type 2.0.50727. To specify version 1.1 of ASP.NET, type 1.1.4322.
Tip • If the installation may be run on a 64-bit version of Windows with the .NET Framework, you can use the ASP.NET Platform
setting for a Web site or application to specify which ASP.NET platform (32 bit or 64 bit) should be used to map the Web site or
application to the ASP.NET version. Note that it is not possible to register 32-bit ASP.NET on a 64-bit system unless the
Enable32BitAppOnWin64 property is set to true on the system.
See Also
Web Site Settings
Considerations for Supporting IIS 6 on 64-Bit Platforms
Application and Virtual Directory Settings
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
You can use the ASP.NET Registration setting on the Application settings of the Internet Information Services view to
specify whether to perform recursive or non-recursive ASP.NET registration. Using this feature enables you to install both
ASP.NET applications and ASP.NET Core applications to the same website.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the application whose ASP.NET registration you want to specify. The settings for the
application are displayed on the right.
3. For the ASP.NET Registration setting, select one of the following options:
• Recursive—Updates script maps and application-pool assignments for the specified application and for all sub-
applications.
• Non Recursive—Updates script maps and application-pool assignments for only the specific application. No sub-
applications are changed.
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
If your IIS installation may be run on a 64-bit version of Windows with the .NET Framework, you can use the ASP.NET
Platform setting in the Internet Information Services view for a Web site or application. This setting lets you specify which
ASP.NET platform should be used to map the Web site or application to the ASP.NET version. By default, this setting is not
configured in InstallShield; if you do not change the value of this setting, the installation assumes that 32-bit support is
needed.
Depending on the value that you configure for the ASP.NET Platform and ASP.NET Version settings, the following behavior
occurs by default at run time:
• If the target system has a 32-bit version of Windows, the 32-bit version of the specified ASP.NET version is used.
• If the target system has a 64-bit version of Windows, and 64 bit was specified for the ASP.NET platform, the
Enable32bitAppOnWin64 property on the target system needs to be set to False. Otherwise, using the 64-bit version of
ASP.NET on a system that is configured to support the 32-bit version would cause ASP.NET to become corrupted.
Thus, the installation is aborted to prevent damage to ASP.NET services.
• If the target system has a 64-bit version of Windows, and 32 bit was specified for the ASP.NET platform, the
Enable32bitAppOnWin64 property on the target system needs to be set to True. Otherwise, using the 32-bit version of
ASP.NET on a system that is configured to support the 64-bit version would cause ASP.NET to become corrupted.
Thus, the installation is aborted to prevent damage to ASP.NET services.
You can set the Enable32bitAppOnWin64 property on a target system that has IIS 7 by configuring the Enable 32-Bit
Applications setting for an application pool in the Internet Information Services view. At run time, the installation sets the
Enable32bitAppOnWin64 property as appropriate for the application pool that is being installed.
On systems with IIS 6, the Enable32bitAppOnWin64 property is a global property that affects all Web sites and applications
on an IIS server. Since changing the value of that property at installation run time might cause other already installed Web
sites and applications on that server to fail, installations that are created with InstallShield do not modify the
Enable32bitAppOnWin64 property at run time if the target system has IIS 6.
At run time, you can have your installation check the Enable32bitAppOnWin64 property on systems that have IIS 6.
Depending on the requirements for your product and the results of that check, you may want the installation to skip a
particular component that contains a 32-bit IIS 6 application, or a 64-bit IIS application, for example, and proceed with the
rest of the file transfer.
InstallShield includes a sample Windows Installer DLL file that detects how the Enable32bitAppOnWin64 property is set.
Release and debug versions of the DLL file, as well as the Visual Studio 2008 C++ project that was used to create the file, are
installed to the following location:
To use the Windows Installer DLL file in your project, you first need to create a custom action that calls the
DetectIIS6AppPool32BitSupport function in the DetectIIS6Compat.dll file.
Task To add a custom action that checks for support for 32-bit applications on systems that have IIS 6:
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI or InstallScript MSI
projects) or Custom Actions (in DIM or Merge Module projects).
2. In the center pane, right-click the Custom Actions explorer, point to New MSI DLL, and click Stored in Binary table.
InstallShield adds a new custom action.
• In the DLL Filename setting, specify the path to the DetectIIS6Compat.dll file. The typical path is:
DetectIIS6AppPool32BitSupport
• Schedule the custom action as needed by selecting the appropriate option in one or more sequence settings.
VersionNT<600
This condition ensures that the custom action is not run on Windows Server 2008 or later or on Windows Vista or
later, since these operating systems would have IIS 7 or later.
At run time, the custom action sets the Windows Installer property ISIIS6APPPOOLSUPPORTS32BIT under certain
conditions:
Table 4-5 • Windows Installer Property for Checking for 32-Bit Application Support on IIS 6 Systems
You can use the ISIIS6APPPOOLSUPPORTS32BIT property in conditional statements. For example, if your product cannot be
used on an IIS 6 server without 64-bit application support, enter the following conditional statement in the Install
Condition setting of the General Information view:
Not ISIIS6APPPOOLSUPPORTS32BIT
As an alternative, you can create an error custom action. At run time, an error would be displayed if the condition for that
custom action is true. Thus, if your product cannot be used on an IIS 6 server without 64-bit application support, use the
following condition for an error custom action:
ISIIS6APPPOOLSUPPORTS32BIT=1
If you have a component that should be installed only on IIS 6 servers that have 32-bit application support enabled, enter
the following conditional statement in the Condition setting of the Components view:
ISIIS6APPPOOLSUPPORTS32BIT=1
See Also
Setting Product Conditions
Version-Specific Information for IIS Support in InstallShield
Determining Which Version of IIS Is Installed
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield lets you define mappings between file name extensions and the applications that process those files.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site, application, or virtual directory that you want to configure.
3. In the Application Mappings setting, click the ellipsis button (...). The Application Mappings dialog box opens.
• To add a new mapping, click the Add button. The Application Extension Mapping dialog box opens. For more
information, see Application Extension Mapping Dialog Box.
• To change an existing mapping, select the one that you want to edit, and then click the Edit button.
• To delete an existing mapping, select it and then click the Delete button.
See Also
Application Mappings Dialog Box
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
InstallShield lets you specify timeout parameters for a Web site, application, or virtual directory.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site, application, or virtual directory that you want to configure.
3. In the Application settings area, click the Configuration button. The Application Mappings dialog box opens.
4. In the Session Timeout (minutes) and the ASP Script Timeout (seconds) settings, specify the appropriate timeout
values.
See Also
Application Mappings Dialog Box
• Basic MSI
• DIM
• InstallScript MSI
• Merge Module
At run time, you can have your installation detect if the IIS Metabase and IIS 6 Configuration Compatibility feature is
installed on a target system, or if IIS 6 or earlier is installed. Depending on the requirements for your product and the
results of that detection, you may want the installation to exit and display an error message.
For example, Web service extensions can be installed on systems that have IIS 6. On systems that have IIS 7, Web service
extensions can be installed only if the IIS Metabase and IIS 6 Configuration Compatibility feature is installed. Thus, you
might want to configure your installation to verify that IIS 6 is present or the IIS 6 compatibility feature is installed; if either
of those conditions are false, the installation would exit and display an error message.
InstallShield includes a sample Windows Installer DLL file that detects if either of the following are true:
• The target system has IIS 7 and the IIS Metabase and IIS 6 Configuration Compatibility feature is installed.
Release and debug versions of the DLL file, as well as the Visual Studio 2008 C++ project that was used to create the file, are
installed to the following location:
To use the Windows Installer DLL file in your project, you first need to create a custom action that calls the
DetectIIS6Interfaces function in the DetectIIS6Compat.dll file.
Task To add a custom action that checks for the IIS Metabase and IIS 6 Configuration Compatibility feature and for IIS 6 and
earlier:
1. In the View List under Behavior and Logic, click Custom Actions and Sequences (in Basic MSI or InstallScript MSI
projects) or Custom Actions (in DIM or Merge Module projects).
2. In the center pane, right-click the Custom Actions explorer, point to New MSI DLL, and click Stored in Binary table.
InstallShield adds a new custom action.
• In the DLL Filename setting, specify the path to the DetectIIS6Compat.dll file. The typical path is:
DetectIIS6Interfaces
• Schedule the custom action as needed by selecting the appropriate option in one or more sequence settings.
If the IIS Metabase and IIS 6 Configuration Compatibility feature is installed or the target system has IIS 6 or earlier, the
Windows Installer property ISIISMETABASECOMPATPRESENT is set to a value of 1. If the target system has IIS 7 or later and the
compatibility feature is not installed, the property is not set.
You can use the ISIISMETABASECOMPATPRESENT property in conditional statements. For example, if your product cannot be
used on a system without the IIS Metabase and IIS 6 Configuration Compatibility feature or IIS 6 or earlier, enter the
following conditional statement in the Install Condition setting of the General Information view:
ISIISMETABASECOMPATPRESENT
As an alternative, you can create an error custom action. At run time, an error would be displayed if the condition for that
custom action is true. Thus, if your product cannot be used on a system without the IIS Metabase and IIS 6 Configuration
Compatibility feature or IIS 6 or earlier, use the following condition for an error custom action:
Not ISIISMETABASECOMPATPRESENT
If you have a component that should be installed only on systems that have the IIS Metabase and IIS 6 Configuration
Compatibility feature or IIS 6 or earlier, enter the following conditional statement in the Condition setting of the
Components view:
ISIISMETABASECOMPATPRESENT=1
See Also
Setting Product Conditions
Version-Specific Information for IIS Support in InstallShield
Determining Which Version of IIS Is Installed
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
Note • The advanced IIS settings apply to IIS 6 and earlier. IIS 7 ignores these settings.
When you select a Web site, application, or a virtual directory in the Web Sites explorer in the Internet Information Services
view, the right pane exposes the most common IIS settings. You can use the Advanced area at the bottom of the right pane
to configure other IIS settings that are not exposed in the other areas.
Task To configure a setting that is not exposed in the Internet Information Services view:
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, select the Web site, application, or virtual directory whose advanced settings you want to
configure.
3. In the Other IIS Properties setting, click the ellipsis button (...). The Other IIS Properties dialog box opens.
4. In the property list, select the property whose value you want to change, and then click the Change Value button. The
Edit IIS Metabase Value dialog box opens.
If you change the default value for any advanced property, InstallShield adds the property, the value that you specify, and
the additional required information to the ISIISProperty table. For more information, see ISIISProperty Table.
See Also
Edit IIS Metabase Value Dialog Box
Internet Information Services View
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
When an end user tries to connect to a Web site and a hypertext transfer protocol (HTTP) error occurs, the end user’s
browser displays a default message describing the error. You can have your installation configure IIS so that it uses custom
error messages instead of the default error messages by mapping the HTTP error codes to a file or a URL.
Task To configure custom error messages for a Web site, application, or virtual directory:
1. Create a file that contains your custom error message and add it to your installation.
2. In the View List under Server Configuration, click Internet Information Services.
3. Select the Web site, application, or virtual directory for which you want to customize HTTP error messages. The
settings for the Web site, application, or virtual directory are displayed on the right.
4. In the Custom Errors setting, click the ellipsis button (...). The Custom Errors dialog box opens.
5. Select the HTTP error code that you want to change and then click the Edit Properties button. The Error Mapping
Properties dialog box opens.
b. In the File box, type the path and file name that points to the custom error message in your installation, or click
the browse button to locate the file.
b. In the URL box, type the URL that points to your custom error message.
See Also
Error Mapping Properties Dialog Box
• Basic MSI
• InstallScript MSI
For Basic MSI and InstallScript MSI projects, you can configure an IIS setting dynamically at run time through the use of
Windows Installer properties. This enables you to let end users specify the name of the virtual directory, the TCP port, the
site number, or other IIS settings for the Web sites, applications, virtual directories, application pools, and Web service
extensions that they are installing on the target machine.
Windows Installer uses MsiFormatRecord to resolve the property at run time. The installation writes the property and its
value to the following registry key so that the value is available during uninstallation and repair:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield Uninstall
Information\{ProductCode}
Therefore, if your Web site is installed to an end user–specified site number, the Web site, its applications, and its virtual
directories can be successfully uninstalled from that site number.
Tip • If you do not want the IIS data to be stored in the registry, set the IS_IIS_DO_NOT_USE_REG property in your project.
If you use a property for any of the passwords in the Internet Information Services view, the passwords are encrypted when
they are stored in the registry.
Example
The following procedure demonstrates how to let end users specify during installation the user name used for anonymous
access to the Web site. Note that you can substitute a hard-coded value with a property for any of the IIS settings in the
Internet Information Services view that allow you to enter characters. The property that you specify in this view must be
enclosed within square brackets, and the property name must be all uppercase; for example, [MYPROPERTY].
Step 5 of the procedure is slightly different, depending on the project type, since Windows Installer controls the user
interface of Basic MSI installations, and the InstallScript engine controls the user interface of InstallScript MSI installations.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, click the Web site whose user name end users should be able to specify for anonymous
access.
[MYPROPERTY]
5. Use the property in a dialog. This part of the procedure depends on which project type you are using.
b. In the Dialogs explorer, expand the All Dialogs folder, and click the language under the dialog that should
contain the User Name control. As an alternative, you can add a new dialog.
c. Add an Edit Field control to the dialog, and set its Property property to the following:
MYPROPERTY
b. Find the dialog code in the OnFirstUIBefore event for the dialog that should contain the User Name control,
and add a call to the Windows Installer API function MsiSetProperty. For example, if you want the user
name to be the name that the end user specifies on the CustomerInformation dialog, you would add an
MsiSetProperty call as shown in the following lines of code:
Dlg_SdCustomerInformation:
nResult = SdCustomerInformation(szTitle, svName, svCompany, nUser);
MsiSetProperty(ISMSI_HANDLE, "MYPROPERTY", svName);
if (nResult = BACK) goto Dlg_SdWelcome;
See Also
MsiFormatRecord (Windows Installer Help Library)
MsiFormatRecord (Windows Installer Help Library)
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
Working with Dialogs in Basic MSI Projects
Working with Dialogs in InstallScript and InstallScript MSI Projects
Dialog Functions
Dialog Customization Functions
For InstallScript projects, you can configure an IIS setting dynamically at run time through the use of text substitution
string variables. This enables you to let end users specify the name of the virtual directory, the TCP port, the site number, or
other IIS settings for the Web sites, applications, virtual directories, application pools, and Web service extensions that they
are installing on the target machine. The InstallScript run-time code uses the TextSubSubstitute function to replace the
string variable with the appropriate value.
Example
The following procedure demonstrates how to let end users specify during installation the user name used for anonymous
access to the Web site. Note that you can substitute a hard-coded value with a text substitution string variable for any of
the IIS settings in the Internet Information Services view that allow you to enter characters. The string variable that you
specify in this view must be enclosed within angle brackets; for example, <MYPROPERTY>. The string variable that you
specify is case-sensitive.
1. In the View List under Server Configuration, click Internet Information Services.
2. In the Web Sites explorer, click the Web site whose user name end users should be able to specify for anonymous
access.
<MYPROPERTY>
6. Find the dialog code in the OnFirstUIBefore event for the dialog that should contain the User Name control, and add a
call to the InstallScript function TextSubSetValue. For example, if you want the user name to be the name that the
end user specifies on the CustomerInformation dialog, you would add a TextSubSetValue call as shown in the
following lines of code:
Dlg_SdRegisterUser:
szMsg = "";
szTitle = "";
//{{IS_SCRIPT_TAG(Dlg_SdRegisterUser)
nResult = SdRegisterUser( szTitle, szMsg, szName, szCompany );
TextSubSetValue("<MYPROPERTY>", szName, TRUE);
//}}IS_SCRIPT_TAG(Dlg_SdRegisterUser)
if (nResult = BACK) goto Dlg_SdLicense2;
See Also
Text Substitutions
Working with Dialogs in InstallScript and InstallScript MSI Projects
Dialog Functions
Dialog Customization Functions
• Basic MSI
• DIM
• InstallScript
• InstallScript MSI
• Merge Module
Deploying a Web service onto a target system requires copying the Web service–specific files to a particular location and
assigning a virtual directory name for that folder so that the Web service can be accessed via HTTP.
Tip • To learn how to add a virtual directory to your project, see Creating a Web Site and Adding an Application or a Virtual
Directory.
1. In the View List under Application Data, click Files and Folders.
2. Select the folder (target directory) for installing files on the target system. Add your files to this folder.
3. In the View List under Server Configuration, click Internet Information Services.
4. In the Web Sites explorer, select the virtual directory that is associated with the Web service.
5. In the Content Source Path (Local or UNC) setting, click the ellipsis button (...). The Browse for Directory dialog box
opens. Enter the same target directory as the one that contains the new files that you added in the Files and Folders
view.
At installation, files are copied to the target directory folder. In addition, the virtual directory is configured for that folder on
the target system if IIS is present.
See Also
Creating a Web Site and Adding an Application or a Virtual Directory
Internet Information Services View
• Basic MSI
• InstallScript MSI
You can use the Forms Authentication setting, displayed under the Security > Authenticated Access section of the
Internet Information Services view for a website, to set forms authentication on web applications. Set the Forms
Authentication option to Yes to enable forms authentication.
ASP.NET forms-based authentication works well for sites or applications on public Web servers that receive many requests.
This authentication mode lets you manage client registration and authentication at the application level, instead of relying
on the authentication mechanisms provided by the operating system.
Important • Forms authentication sends the user name and password to the Web server as plain text. You should use Secure
Sockets Layer (SSL) encryption for the Log On page and for all other pages in your application except the Home page.
1. In the View List under Server Configuration, click Internet Information Services.
3. Under Security > Authenticated Access, set the Forms Authentication setting to Yes.
IISROOTFOLDER is an InstallShield directory variable that is used to determine the root directory of the Web server on a
target system. If you are using IIS functionality in your installation project and you have added a Web site, then
IISROOTFOLDER is automatically added.
Note • All of the files added to the IISROOTFOLDER directory in the Files and Folders view are installed to the Web server’s root
directory on the target machine. If IIS is not installed, the files are copied to the root folder.
See Also
Internet Information Services View
IIS_WEBSITE_NAME Property
InstallShield 2020
The IIS_WEBSITE_NAME property is obsolete. If this property exists from earlier project versions, the upgrader will handle it
automatically. The upgrader will create a Web site and set the site number field to [IIS_WEBSITE_NAME]. For new Web sites,
you can use any property or hard-coded number.
IIS_PORT_NUMBER Property
InstallShield 2020
The IIS_PORT_NUMBER property is obsolete. If this property exists from earlier project versions, the upgrader will handle it
automatically. The upgrader will create a Web site and set the port number field to [IIS_PORT_NUMBER]. When you create
new Web sites, you can use any property or hard-coded number.
InstallShield lets your users rerun your installation to change program features or reinstall or remove your application.
When users select your application in Add or Remove Programs in the Control Panel, the installation displays dialog boxes
that let users do any of the following:
• Install individual features that were not previously installed, and uninstall individual features.
• Reinstall your application with the settings selected during the first installation.
To modify, repair, or uninstall an application, the operating system must have some indication that the application is
present. To allow this, an installation registers an application with the operating system so that it can be easily maintained
or uninstalled. You enter the necessary information in the General Information view.
In all InstallShield installations, maintenance (that is, modification and repair) is handled automatically by default.
In a Windows Installer–based installation, uninstallation is handled automatically—with the sole exception of custom
actions, which must either undo their own effect during uninstallation or have their effect undone by another custom
action that runs only during uninstallation.
In an InstallScript or InstallScript MSI installation, many script functions’ actions are logged for automatic uninstallation;
your uninstallation script must handle those script function actions that are not logged.
See Also
Preparing an InstallScript Installation for Uninstallation
Setting up uninstallation functionality is simple, considering the complexity of the operations that result.
CreateInstallationInfo (or InstallationInfo) and MaintenanceStart (or DeinstallStart) must be called. In an event-based
script, CreateInstallationInfo and MaintenanceStart are called in the default OnMoveData event handler code.
There are other functions that play important roles in setting up uninstallation functionality. For example, all keys created
using the RegDBCreateKeyEx function are recorded for uninstallation, unless logging is disabled. Also, if you call the
Disable function to disable logging, remember to call Enable to enable the logging again for subsequent actions that must
be recorded for uninstallation.
MaintenanceStart (or DeinstallStart) creates the necessary registry key and its necessary values. To create additional
registry values under this key, call RegDBSetItem, or for custom values use code like the following:
RegDBSetDefaultRoot( HKEY_USER_SELECTABLE );
RegDBSetKeyValueEx( "Software\\Microsoft\\Windows\\Current Version\\Uninstall\\" + INSTANCE_GUID, "My
Custom Value", nType, szValue, nSize);
Note • Uninstallation is available only if the initial installation calls FeatureTransferData or FeatureMoveData. (In an
event-based script, the FeatureTransferData function is called automatically.) If your installation installs files by some other
means (for example, XCopyFile) and you want to make uninstallation available to your end users, deselect all components
and call FeatureTransferData or FeatureMoveData; while this call is executed, you can call SdShowMsg to display a
message.
Note • If you call DeinstallStart to enable uninstallation, the installation script is not executed during uninstallation. To
execute script code during uninstallation, call MaintenanceStart instead. (In an event-based installation, MaintenanceStart
is called in the default OnMoveData event handler code.)
Event-Based Scripts
If your script is event-based, the following event handler functions are called during uninstallation:
• OnBegin
• OnMaintUIBefore
• OnMoving
• OnMoved
• OnMaintUIAfter
• OnEnd
The code in these event handler functions (whose default code you can override) is executed during the uninstallation. For
instructions on executing certain event handler code only during uninstallation, or only during installation, see Executing
Script Code Only During Uninstallation or Only During Installation.
Procedural Scripts
If your script is procedural (that is, uses a program block) and calls MaintenanceStart rather than DeinstallStart to enable
uninstallation, the script is executed during uninstallation. For instructions on executing certain script code only during
uninstallation, or only during installation, see Executing Script Code Only During Uninstallation or Only During Installation.
The installation script is executed during uninstallation and maintenance installations if MaintenanceStart rather than
DeinstallStart is called to enable uninstallation. (In an event-based script, MaintenanceStart is called in the default
OnMoveData event handler code.) To execute code only during uninstallation or maintenance installations, enclose it in
the following if-then statement:
if MAINTENANCE then
/* this code is executed only during
uninstallation or maintenance installations */
endif;
To execute code only during a first installation, enclose it in the following if-then statement:
if !MAINTENANCE then
/* this code is executed only during
a first installation */
endif;
If code is not enclosed in either if-then statement, it is executed during uninstallation, maintenance installations, and first
installations—with the following exceptions in event-based scripts:
• The code in the following event handlers is executed only during uninstallation and maintenance installations:
OnMaintUIBefore
OnMaintUIAfter
• The code in the following event handlers is executed only during the first installation:
OnCCPSearch
OnAppSearch
OnFirstUIBefore
OnFirstUIAfter
• InstallScript
• InstallScript MSI —if the InstallScript user interface (UI) style is the traditional style (which uses the InstallScript engine as
an external UI handler)
This information does not apply to InstallScript MSI projects in which the InstallScript UI style is the new style (which uses the
InstallScript engine as an embedded UI handler). To learn more, see Using the InstallScript Engine as an External vs.
Embedded UI Handler for InstallScript MSI Installations.
In general, if logging is enabled, all of the files, folders, registry entries, .ini file entries, shortcuts, shortcut folders, and
services that are created or replaced while logging is enabled are logged for uninstallation. In addition, all of the
InstallScript functions that make changes to the target system during InstallScript installations and InstallScript MSI
installations are logged for uninstallation. Following are some common examples of functions that an installation logs for
uninstallation by default:
• AddFolderIcon
• AddProfString
• CopyFile
• CreateInstallationInfo
• CreateProgramFolder
• FeatureMoveData
• FeatureTransferData
• RegDBSetAppInfo
• RegDBSetItem
• ReplaceProfString
• ServiceAddService
• ServiceStartService
• VerSearchAndUpdateFile
• VerUpdateFile
• WriteProfString
• XCopyFile
You can disable and re-enable logging by calling Disable (LOGGING); and Enable (LOGGING); in your InstallScript code.
For more information, see Disable and Enable.
See Also
Uninstalling Initialization (.ini) File Entries
Maintenance/Uninstallation Feature
InstallShield 2020
The maintenance/uninstallation feature installs the files needed for maintenance setups and uninstallation, including
engine files; the files’ target location is specified by the value of the system variable DISK1TARGET. This feature is
automatically placed in your .cab files by the release builder and is not displayed in the InstallShield interface.
At run time the maintenance/uninstallation feature is automatically selected for all setup types. Calling FeatureUpdate
deselects this feature. The maintenance/uninstallation feature can also be selected or deselected by calling
FeatureSelectItem and passing the system variable DISK1COMPONENT as the function’s second argument. For example, the
following code deselects the feature:
By default, files created by your product after the installation is complete are assumed to be user data, and are not
removed when the user uninstalls your application.
FileKey remove_file
Component_ ProgramFiles
FileName Product.ini
DirProperty INSTALLDIR
InstallMode 2
By default, your product’s uninstallation removes only data that was created by your installation program.
Note • The RemoveRegistry table—exposed in the Direct Editor—specifies data to be removed only when your product is
installed. For details, see the Windows Installer Help Library.
Project • The following project types support multiple-package installations that use transaction processing:
• Basic MSI
• InstallScript MSI
Windows Installer 4.5 includes support for installing multiple packages using transaction processing. The packages are
chained together and processed as a single transaction. If one or more of the packages in the transaction cannot be
installed successfully or if the end user cancels the installation, the Windows Installer initiates rollback for all of the
packages to restore the system to its earlier state.
This section of the documentation explains how to specify .msi packages that you want InstallShield to include in your
installation as chained packages. This section also explains how to configure settings such as the properties that should be
passed to the chained packages.
Note • Windows Installer 4.5 includes support for installing multiple packages using transaction processing. Earlier versions
do not launch any chained .msi packages.
If you want your installation to install Windows Installer 4.5, see Adding Windows Installer Redistributables to Projects to learn
how.
See Also
Overview of Multiple-Package Installations that Use Transaction Processing
Adding a New Chained .msi Package to Your Project
Project • The following project types support multiple-package installations that use transaction processing:
• Basic MSI
• InstallScript MSI
When you add one or more .msi packages to your installation as chained packages and an end user runs your installation
on a system that has Windows Installer 4.5, the Windows Installer can install all of the packages in a single transaction. If
one or more of the packages in the transaction cannot be installed successfully or if the end user cancels the installation,
the Windows Installer initiates rollback for all packages to restore the system to its earlier state.
When the Windows Installer uses transaction processing, it batches together the various script states from the .msi
packages. For example, Windows Installer executes the InstallInitialize action during the Execute sequence; at this point in
the sequence Windows Installer executes all of the immediate actions for all of the packages and puts all of the deferred
actions in the installation script. Next, Windows Installer executes the deferred actions—but not the commit or rollback
actions—in the installation script for all of the packages. In addition, Windows Installer copies the rollback actions to the
rollback script. If the products for each of the packages are successfully installed up until this point, the Windows Installer
runs all of the commit actions for each of the packages; otherwise, the Windows Installer executes the rollback script to
return the target system to its original state.
For more information about this functionality, see Multiple-Package Installations in the Windows Installer Help Library.
Note • Windows Installer 4.5 includes support for installing multiple packages using transaction processing. Earlier versions
do not launch any chained .msi packages.
If you want your installation to install Windows Installer 4.5, see Adding Windows Installer Redistributables to Projects to learn
how.
See Also
Configuring Multiple Packages for Installation Using Transaction Processing
Adding a New Chained .msi Package to Your Project
Project • The following project types support multiple-package installations that use transaction processing:
• Basic MSI
• InstallScript MSI
InstallShield enables you to add already built Windows Installer packages (.msi files) to your project as chained .msi
packages. Windows Installer 4.5 includes support for installing the multiple packages using transaction processing. The
packages are chained together and processed as a single transaction. If one or more of the packages in the transaction
cannot be installed successfully or if the end user cancels the installation, the Windows Installer initiates rollback for all
packages to restore the system to its earlier state.
The Chained .msi Packages area of the Releases view is where you add to your project one or more .msi packages that you
want to be chained to your main installation.
Note • Windows Installer 4.5 includes support for installing multiple packages using transaction processing. Earlier versions
do not launch any chained .msi packages.
If you want your installation to install Windows Installer 4.5, see Adding Windows Installer Redistributables to Projects to learn
how.
2. Right-click the Chained .msi Packages explorer and then click New Chained Package. InstallShield adds a new item
with a default name.
3. Enter a new name, or right-click it later and click Rename to give it a new name.
The name is not displayed at run time; it is an internal name that is used to differentiate between different chained
.msi packages in the main installation.
4. Select the new chained package item. InstallShield displays its settings in the right pane.
5. For the Installation (run-time path) setting, click the Browse button. The Browse for File dialog box opens.
6. Select the Windows Installer package (.msi file) that you would like to add, and then click Open. The package that you
select must be an .msi package that can be installed through MsiInstallProduct. Note that it cannot be an
InstallScript MSI package.
InstallShield prompts you to specify whether you want to stream the .msi package—and its uncompressed files, if the .msi
package is not compressed—into your product’s main .msi package:
• If you specify that you want InstallShield to stream the files, InstallShield adds the name of the .msi package to the
Installation (run-time path) setting. InstallShield also automatically adds either the file name (if it is a compressed
.msi package) or the entry *.* (if it is an uncompressed .msi package) to the Streamed files box. For the *.* wild-card
entry, InstallShield streams in the .msi package as well as all of the files in the same folder as the .msi package.
• If you specify that you do not want InstallShield to stream the files, InstallShield adds the following path to the
Installation (run-time path) setting:
[SourceDir]FileName.msi
You can change this path if appropriate. For example, you may want to use a path such as the following one, and also
clear the Delete streamed files after installation check box:
[LocalAppDataFolder]{ProductCodeGUID}\FileName.msi
In this example, the .msi package is cached on the local system, and it is available for maintenance.
Tip • You may not want to stream in the .msi package, since Windows Installer has limitations for the file size of .msi
packages.
7. Configure the chained .msi package settings as needed. To learn more, see Chained .msi Package Settings.
If your main installation includes several chained .msi packages, InstallShield uses the Order column in the
ISChainPackage table of the main installation to determine the order in which the chained packages should be launched
at run time. All uninstallations are processed in reverse order, from highest to lowest order number; all installations are
processed in forward order, from lowest to highest order number.
Note • If you have specified .msi packages in the Chained .msi Packages area in the Releases view, InstallShield does not
build the chained packaged when you build releases for your main installation.
See Also
Assigning Release Flags to a Chained .msi Package
Chained .msi Package Settings
Project • The following project types support multiple-package installations that use transaction processing:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
You can assign one or more release flags to a chained .msi package that you want to exclude from certain builds. For
example, if you have a chained .msi package that should be included only in a special edition of your product that contains
a special add-on that requires the chained .msi package, you can flag that chained package and include it only when it is
needed.
Task To add a release flag to a chained .msi package that you have added to your installation project:
2. In the Chained .msi Packages explorer, select the package that should contain the release flag.
3. For the Release flags setting, type a string. The string can be any combination of letters or numbers. To have more
than one flag on a chained package, use a comma to separate the flags.
To learn more about filtering chained .msi packages based on release flags, see Release Flags.
See Also
Chained .msi Package Settings
Project • The following project types support multiple-package installations that use transaction processing:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
2. In the Chained .msi Packages explorer, right-click the chained .msi package that you want to remove from your
project, and then click Remove.
InstallShield removes the chained .msi package from your project. Note that InstallShield does not delete the .msi
package, or any of its files, from your file system.
Once you have configured the features, components, files, shortcuts, registry entries, end-user dialogs, and other elements
of your installation project, you are ready to create and build a release for your installation. InstallShield lets you create
multiple releases for a project and configure each release for a different media type and according to different sets of
requirements. Building releases packages the content of your installation, creating a disk image that you can copy to your
distribution media and distribute or deploy as needed.
Testing is an essential part of creating a reliable installation. InstallShield enables you to selectively test run just the end-
user interface portion of a release. You can also run your installation by simply clicking a button in InstallShield; when you
run an installation by using this method, your installation executes exactly as it would on an end user’s machine. All files
are transferred, shortcuts and registry entries are made, and the user interface is displayed.
Before you release your product, you may want to validate your installation project. Validating a Windows Installer project
involves applying a set of internal consistency evaluator (ICE) rules to your installation project. These ICEs are designed by
Microsoft to help you determine whether your resulting installation package contains a valid database that performs its
actions correctly.
With the debugging tools in InstallShield, you can debug your InstallScript script or Windows Installer release to identify
the sources of problems. When you debug a script, you execute your script, statement by statement, and trace the flow of
control by watching the execution point as it moves through the script. You can also monitor the value of any variable in
your script at any point during script execution. When you debug a Windows Installer release, InstallShield runs through
each action and dialog box until it reaches your breakpoint, when it halts execution. At this point, you can view and set
properties.
See Also
Working with Releases
Validating Projects
Releases View
Once you have designed your project in InstallShield, you are ready to create a release that you can configure and build to
distribute to end users. The release is built according to the options you set for it in the Release Wizard or in settings that
are displayed in the Releases view.
• Basic MSI
• InstallScript MSI
• Merge Module
Every release that you build is a member of a product configuration. A product configuration provides a means for
grouping together releases that share similar properties, such as the product name, product code, and package code.
Product configurations also enable you to keep a history of your builds without having to set up a folder structure outside
InstallShield. For example, when your product is in development, you might have many releases of the same version. You
do not necessarily want to overwrite each release every time that you rebuild the product. With product configurations,
you can maintain your previous build history and incorporate new releases at the same time.
In the past, you may have had to maintain this type of historical record of your builds outside InstallShield. You had to
create a directory structure on a drive, label each folder manually, and then copy the release into its directory. With
product configurations, all of this is done for you in InstallShield.
2. Right-click the Releases explorer and then click New Product Configuration.
InstallShield adds a new product configuration to the Releases explorer. InstallShield lists the product configuration
settings on the General tab.
For descriptions about each of the product configuration settings, see General Tab for a Product Configuration.
Tip • You can also create product configurations through the Release Wizard. You can specify existing product configurations
from the command line (using the -a parameter), but you cannot define the settings of a release through the command line.
See Also
Releases View
• Basic MSI
• Merge Module
As x64 Windows-based systems that do not have 32-bit Windows-on-Windows (WOW64) support become more common,
you may want to perform architecture validation 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 x64 Windows Server Core systems that do not have WOW64 support,
architecture validation can help you identify any x86 product files or x86 custom action files in your installation; x86
binaries cannot be loaded on x64 target systems without WOW64 support.
In addition, if you are mixing x64 and x86 product files (or x64 and x86 custom actions) in a single project and generating
separate x86 and x64 .msi packages, you can use architecture validation to identify any x64 product or custom action files
in your x86 releases, since these files cannot be loaded on x86 target systems.
Architecture validation also enables you to generate pure x86 .msi packages that contain only x86 versions of the built-in
InstallShield custom action DLLs, or pure x64 .msi packages that contain only x64 versions of the built-in InstallShield
custom action DLLs. To enable this functionality, InstallShield uses two predefined path variables:
ISRedistPlatformDependentFolder and ISRedistPlatformDependentExpressFolder. By default, the values of these path
variables are subfolders that contain x86 versions of the InstallShield custom action DLLs; the subfolders are in the
following directory: InstallShield Program Files Folder\Redist. InstallShield modifies the values of these path
variables at build time if necessary to include the x64 versions (instead of the x86 versions) of the InstallShield custom
action DLLs in releases; these files are in different subfolders in InstallShield Program Files Folder\Redist.
• Lenient—This type of validation lets you build x86 and x64 .msi packages (as indicated by the Template Summary
property), and mix x86 and x64 product files and custom action files in both of those types of packages.
Lenient validation does not 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.
Lenient validation does not 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.
• Strict—With this type of validation, InstallShield attempts to build a pure x86 or pure x64 .msi package, depending on
whether the Template Summary property specifies Intel (for x86) or x64.
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. Thus, during
build-time validation of an x86 package, InstallShield generates a build error for each x64 custom action file in the
package. During build-time validation of an x64 package, InstallShield generates a build error for each x86 custom
action file in the package.
Strict validation may 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. Thus, during build-
time validation of an x86 package, InstallShield generates a build warning for each x64 product file in the package.
During build-time validation of an x64 package, InstallShield generates a build warning for each x86 product file in the
package.
Tip • For information on the Template Summary property, see Using the Template Summary Property.
For additional tips on targeting 64-bit operating systems, see Targeting 64-Bit Operating Systems with Basic MSI and
InstallScript MSI Installations.
Task To select the type of architecture validation that you want InstallShield to perform at build time:
2. In the Releases explorer, select the product configuration that you want to configure.
3. On the General tab, in the Architecture Validation setting, select the appropriate option. Available options are:
• None
• Lenient
• Strict
error -7319: 32-bit Standard DLL Custom Action MyCustomAction must not be included in a strict 64-bit
package.
In many cases, an x64 target system can run an x86 file. However, if the x64 system does not have WOW64 support, it may
not be able to run an x86 file.
Depending on your requirements, you may want to replace the x86 file or custom action that is referenced in a build error
or warning with an x64 file or custom action. In other scenarios, you may want to ignore a build error or warning. For
example, if a file’s component has a condition that prevents the component from being installed on x64 systems, you may
want to ignore its corresponding build warning. In some cases, you may decide to reexamine your requirements—that is,
you may want to avoid supporting x64 target systems that do not have WOW64 support.
Similarly, you may encounter build errors and warnings if you are using strict architecture validation to build an x86 .msi
package; for example:
error -7320: 64-bit Standard DLL Custom Action MyCustomAction must not be included in a strict 32-bit
package.
An x86 system cannot run any x64 files or custom actions. Depending on your requirements, you may choose to make
changes to your project or ignore the build errors and warnings. In some cases, you may decide to reexamine your
requirements.
See Also
Targeting 64-Bit Operating Systems
Project • For installation projects: Before building your installation project, ensure that you have completed designing and
configuring the settings for every element in your project, including the features, components, files, shortcuts, registry entries,
and end-user interface.
For merge module projects: Before building your package, ensure that you have completed designing and configuring the
settings for every element in your merge module, including components, files, shortcuts, and registry entries.
Once you have designed your project in InstallShield, you are ready to create a release that you can configure and build to
distribute to end users. You can create multiple releases for a project and configure each release for a different media type
and according to different sets of requirements. InstallShield offers several methods for creating and building a release:
• Use the Release Wizard. (This method is not available in Advanced UI or Suite/Advanced UI projects.)
• Build a release through the automation interface. (This method is not available in Advanced UI or Suite/Advanced UI
projects.)
For information on building an InstallShield release from within Visual Studio, see Building Releases in Microsoft Visual
Studio.
Tip • Make sure that Windows Explorer is not pointing to the Disk1 folder or a subfolder when you build your release. If
Windows Explorer is pointing to the Disk1 folder, the build process fails and generates an error.
See Also
Release Wizard
Build Errors and Warnings
Cloning Releases
Rebuilding Releases
Performing Quick Builds
Build Method
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
The Release Wizard provides an easy way for you to build a product release and specify the settings for that release.
Task To launch the Release Wizard and build your installation package, do one of the following:
Follow the instructions in the panels of the Release Wizard. For a list of errors returned by the wizard, see Build Errors and
Warnings.
See Also
Building Releases in Microsoft Visual Studio
Release Wizard
The Releases view lets you specify the settings for a release and build it. The procedure for creating and building a release
depends on what project type you are using.
Creating and Building a Release in Basic MSI, InstallScript MSI, and Merge Module
Projects
2. In the Releases explorer, right-click the product configuration that should contain the new release, and then click
New Release. For information on how to create a new product configuration, see Working with Product
Configurations. InstallShield adds a new release under the product configuration. Its settings are displayed on the
tabs.
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
2. Right-click the Releases explorer, and then click New Release. InstallShield adds a new release. Its settings are
displayed on the tabs.
2. Right-click the Releases explorer, point to New Release, and click the type of media that you want to create.
InstallShield adds a new release to the explorer. Its settings are displayed on the tabs.
See Also
Building Releases in Microsoft Visual Studio
Configuring Release Settings
The disk image folders for your installation are built in the release location. All additional files and folders that are
necessary for storing uncompressed application files are placed in subfolders of the disk image folders. The release
location is a subfolder of your project’s location.
To see your release after you have built it, click Disk Images under the product name and the release name in the Releases
view. If you have not changed the release location, InstallShield places the built installation package into the following
folder:
You can set the release location either in the Advanced Settings panel of the Release Wizard or in the Release Location
property in the Releases view.
See Also
Changing the Default Project Location
You can build a release from the command line using ISCmdBld.exe for Windows Installer–based projects, for InstallScript
projects, and for Advanced UI or Suite/Advanced UI projects. If your project includes InstallScript, ISCmdBld.exe also
compiles it before building the release.
Using ISCmdBld.exe to build an installation can be useful if you are trying to build from a batch file. Also, building a release
from the command line using ISCmdBld.exe will handle the conversion of .ipr and .ipo files (object project files created
using InstallShield Professional) to an .ism file, in addition to building the release.
Tip • An .ism file in either binary or XML format is accepted by the command-line build. The command-line build also works
with Advanced UI and Suite/Advanced UI project files (.issuite).
You can build a release from the command line using ISCmdBld.exe with the Standalone Build. For more information, see
Standalone Build.
See Also
ISCmdBld.exe
Using ISCmdBld.exe to Build a Release from the Command Line
Building Releases in Microsoft Visual Studio
InstallShield 2020
ISCmdBld.exe is located by default in the InstallShield folder’s System subfolder. Do not move ISCmdBld.exe from its
installed location.
For the syntax and available command-line parameters for ISCmdBld.exe, see ISCmdBld.exe.
See Also
Using Source Code Control at the Command Line
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
If you want to pass numerous parameters during a command-line build, or if you consistently pass the same parameters, it
might be convenient to use an .ini file. The following statement illustrates running ISCmdBld.exe to build a release with
parameters as specified in the MySetup.ini file.
You need to include the same information in the .ini file as you would if you were passing the parameters at the command
line. There are four sections for this file:
• [Project]—In this section, include entries for the path to the project file (.ism), as well as the name of the product
configuration. If you are building a patch, include an entry for the name of the patch configuration that you are
building.
• [Release]—In this section, include entries for release configuration information such as the compression type
(compressed or uncompressed), build flags, Setup.exe settings, and the release name.
• [Mode]—In this section, include any of the available optional entries, such as the Silent=yes entry if you want to build
your release while suppressing any build errors or warning messages. This section also lets you indicate whether a log
file should be created.
• [BuildLocation]—In this section, you can optionally specify the release output location.
Not all sections are required. As with passing parameters directly from the command line, parameters for requirements
such as silent build and build location are optional. In the example .ini file below, these parameters are in the [Mode] and
[BuildLocation] sections. You can omit these entries from your .ini file if you want to accept the defaults. By default, no
log file is created, the installation is not run in silent mode, and your release is created in the project location that is
specified on the File Locations tab of the Options dialog box.
Table 4-1 • Sample Entries in the [Project] Section of the .ini File
Corresponding
ISCmdBld.exe
Command-Line
Entry Parameter Description
Product=Othello Name of your product. This entry lets you override the
value that is specified in the General Information view.
PatchConfigName=“Version 1.2” -patch_config Name of the patch configuration in the Patch Design
view that you want to build.
Table 4-2 • Sample Entries in the [Release] Section of the .ini File
Corresponding
ISCmdBld.exe
Command-Line
Entry Parameter Description
Table 4-3 • Sample Entries in the [Mode] Section of the .ini File
Corresponding
ISCmdBld.exe
Command-Line
Entry Parameter Description
CubFile="C:\Program
Files\InstallShield\2020\Support\Validation\IS
Win8.cub;C:\Program
Files\InstallShield\2020\Support\Validation\da
rice.cub"
BuildTablesRefreshFiles=no -q2 Builds the Windows Installer tables and refreshes files.
Table 4-3 • Sample Entries in the [Mode] Section of the .ini File (cont.)
Corresponding
ISCmdBld.exe
Command-Line
Entry Parameter Description
BuildTablesOnly=yes -q1 Builds only the Windows Installer tables for your
release.
Table 4-3 • Sample Entries in the [Mode] Section of the .ini File (cont.)
Corresponding
ISCmdBld.exe
Command-Line
Entry Parameter Description
LicCheckTimeOut="40" -licCheckTimeOut Sets the time period to check the availability of the
<seconds> license from the license server.
Table 4-4 • Sample Entries in the [BuildLocation] Section of the .ini File
Corresponding
ISCmdBld.exe
Command-Line
Entry Parameter Description
For more information about the .ini file entries, see Building a Release from the Command Line.
See Also
Standalone Command-Line Build
InstallShield 2020
ISBuild.exe, a command-line tool that is available for legacy InstallScript projects, is a shell that calls into ISCmdBld.exe.
ISCmdBld.exe handles the conversion of .ipr and .ipo (object projects created using InstallShield Professional) files to an
.ism file and builds the release.
See Also
ISCmdBld.exe
InstallShield 2020
You can build a self-extracting executable file from the command line using ReleasePackager.exe. This can be useful if you
are building from a batch file.
ReleasePackager.exe is located by default in the InstallShield folder’s System subfolder. Do not move
ReleasePackager.exe from its installed location.
For syntax and available arguments and options for ReleasePackager.exe, see ReleasePackager.exe.
See Also
Using Source Code Control at the Command Line
Rebuilding Releases
InstallShield 2020
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
You can rebuild a release at any time using the default entries that you already provided in the settings in the Releases
view. The release that currently has focus is rebuilt.
• In the Releases view, right-click a release name and then click Build.
You can run the Release Wizard again to rebuild a release. Because the wizard stores the release settings in your
InstallShield project file, the wizard displays all of the options that you set when you last built the release, even if you
deleted the release.
To see your new installation package, click Disk Image(s) for the appropriate release in the Releases view. InstallShield
places the built installation package into the following folder if you have not changed the default release location:
Note • Make sure that Windows Explorer is not pointing to the Disk1 folder or a subfolder when you build your release. If it is
pointing to the Disk1 folder, the build process can continue indefinitely. If Windows Explorer is accessing a subfolder, the build
generates an error.
See Also
Running Installations from the InstallShield Interface
Building Releases in Microsoft Visual Studio
InstallShield 2020
When you are testing your installation, you might not want to continually build all of your installation files if no files have
been changed. InstallShield provides you with two quick build options: Build Tables Only and Build Tables & Refresh Files.
Task To build only your installation’s Windows Installer tables, do one of the following:
• In the Releases view, right-click the release that you would like to build and click Build Tables Only.
Task To build your Windows Installer tables and refresh the installation’s files, do one of the following:
• In the Releases view, right-click the release that you would like to build and click Build Tables & Refresh Files.
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
You might need to build multiple releases with different configurations simultaneously. This functionality is known as a
batch build.
2. In a Basic MSI, InstallScript MSI, or Merge Module project: Right-click a product configuration and click Batch Build.
In an InstallScript or InstallScript Object project: Right-click the Releases explorer and click Batch Build.
The Batch Build dialog box opens to prompt you to select the product configurations and releases that you would like to
build.
• Basic MSI
• InstallScript
• InstallScript MSI
• Merge Module
• Suite/Advanced UI
InstallShield lets you specify commands that you want to be run at various stages of the build process. For example, if you
are developing a Basic MSI project, you may want to modify the .msi package that InstallShield creates at build time before
InstallShield digitally signs it and streams it into the Setup.exe file. You can specify a command that runs a script that
makes the required changes to the .msi package at the appropriate time during the build.
When you are entering a command, you can use any path variables and environment variables that are defined in your
project, instead of using a hard-coded path. You can also use the following variables that are defined specifically for build
event commands.
<ISReleaseName> Basic MSI, This variable indicates the name of the release that
InstallScript, InstallShield is building.
InstallScript MSI,
Merge Module,
Suite/Advanced UI
<ISProductConfigName> Basic MSI, This variable indicates the name of the product
InstallScript, configuration that contains the release that
InstallScript MSI, InstallShield is building. (Note that this is always
Merge Module Media for InstallScript projects.)
<ISReleasePath> Basic MSI, This variable indicates the build location of the
InstallScript, release that InstallShield is building. It is set through
InstallScript MSI, the Release Location setting on the Build tab for a
Merge Module, release in the Releases view.
Suite/Advanced UI
<ISReleaseUsesShallowFolderPaths> Basic MSI, This variable is set to true or false to indicate whether
InstallScript MSI InstallShield uses a shallow folder directory structure
when building your release.
When the build is complete, InstallShield deletes the temporary environment variables that it set.
Task To specify one or more commands that run before, during, or after a build:
2. In the Releases explorer, click the release that you would like to configure.
4. In one or more of the following settings, enter the commands that you want InstallShield to run:
• Prebuild Event
• Postbuild Event
Enter each command as it would be launched from the command prompt. Thus, for example, if you specify a path that
includes spaces, enclose the path within quotation marks.
For details about each setting, see Events Tab for a Release.
To specify more than one command for any of those settings, click the ellipsis button (...) in the setting. A dialog box
opens, enabling you to enter one or more commands. Enter each command on a separate line.
If you enter more than one command for an event settings, InstallShield runs each command at build time in the order that
they are listed for that setting. The build waits until a command finishes before proceeding to the next one.
Tip • A verbose build log shows each of the build events that are run at build time. To troubleshoot build events, generate a
verbose log file and search for strings such as “Launching prebuild events”, “Launching precompression build events”, and
“Launching postbuild events”. These areas of the log list details about the commands that are run at build time.
To generate a verbose build log, pass the -v parameter when launching IsCmdBld.exe from the command line.
See Also
ISCmdBld.exe
When you build a release, the Output window opens across the bottom of the InstallShield user interface. The Tasks tab of
this window lists any build errors and warnings that occur during the build process.
Task To learn how to resolve a build error or warning that you encounter, do one of the following:
• On the Tasks tab of the Output window, click an error code to launch your Internet browser and see Knowledge Base
articles and HelpNet topics for the selected build error or warning.
• See Build Errors and Warnings, which provides tips on how to resolve build errors and warnings.
InstallShield 2020
The InstallShield automation interface enables you to query and modify many project settings from an unattended build
process, using, for example, a VBScript script or Visual Basic application.
The framework of any script that uses the automation interface to access a project appears as follows (you can copy this
script into a text file called Framework.vbs and then double-click the file icon):
See Also
Automation Interface
Automating Installation Development and Build Processes
Canceling Builds
InstallShield 2020
Standalone Build
InstallShield 2020
InstallShield provides a Standalone Build module that enables you to install only the part of InstallShield that compiles the
installations, plus any redistributables that you want to include. For instructions on installing the Standalone Build and any
redistributables on a build machine, see Installing the Standalone Build on a Build Machine.
The InstallShield 2020 Standalone Build can coexist with other major versions of the Standalone Build on the same
machine (in different folders).
Upgrading Projects
The Standalone Build automatically upgrades projects that were created with InstallShield Developer 7.0 or later.
However, it does not upgrade projects that were created with InstallShield for Windows Installer.
See Also
Using the Automation Interface on a 64-Bit System
InstallShield 2020
Edition • Support for multilanguage installations is available with InstallShield Premier Edition only.
• If you have the InstallShield DVD, the file is on the DVD and you can find it using the DVD Browser.
• If you downloaded InstallShield, the Standalone Build installation file is available for download as documented
in the InstallShield download and license instructions (http://www.installshield.com/instructions/sab.asp).
2. Double-click the executable file and run the installation. For detailed information on configuring licensing for the
Standalone Build, see the InstallShield download and license instructions (http://www.installshield.com/
instructions/sab.asp).
During the installation, the Custom Setup dialog shows two Standalone Build features that are disabled by default. Enable
these features if you want to be able to use them.
• Automation Interface—This feature installs and registers the files that you need to use the automation interface with
the Standalone Build.
• InstallScript Objects Support—This feature installs and registers the InstallScript Object support files that enable
you to build InstallScript projects that contain InstallScript Objects.
• MSXML3 (msxml3_wim32.msm)
The Standalone Build installation also installs and registers the Microsoft Scripting Runtime Library (scrrun.dll) if it is not
present. It is installed to the [SystemFolder].
If you copy the Standalone Build files from one machine to another instead of running the installation on that second
machine, you must manually install the technologies that are included in these merge modules and the scrrun.dll file if
they are not already present. You can obtain the installation packages for the merge module technologies from the
Microsoft Web site (http://www.microsoft.com).
Files that Are Registered During the Installation of the Optional Automation Support Feature
The Automation Interface feature in the Standalone Build installation installs and registers the files that you need in order
to use the automation interface with the Standalone Build. Following is the list of files that need to be registered:
If you copy the Standalone Build files from one machine to another instead of running the installation on that second
machine, and if you want to be able to use the automation interface with the Standalone Build, you must manually register
these files.
Files that Are Registered During the Installation of the Optional InstallScript Objects Support Feature
The InstallScript Objects Support feature installs and registers the InstallScript Object support files that enable you to build
InstallScript projects that contain InstallScript Objects. Following is the list of files that need to be registered:
If you copy the Standalone Build files from one machine to another instead of running the installation on that second
machine, and if you want to be able to build InstallScript projects that contain InstallScript Objects, you must manually
register these files.
To manually register one of the .tlb files, use the following file:
See Also
Adding Redistributables to the Build Machine for the Standalone Build
Installing the Standalone Build and InstallShield on the Same Machine
Using the Automation Interface on a 64-Bit System
InstallShield 2020
Most of the redistributables—including merge modules, objects, and InstallShield prerequisites—are not installed
automatically with the Standalone Build because they would require significantly more hard disk space. This allows you to
install on the build machine only the redistributables that are required by your InstallShield projects. The only one that is
included is the .NET Framework 2.0 redistributable.
Tip • The Standalone Build uses the same basic directory structure that InstallShield uses for its program files. Therefore, if
you need to copy a redistributable or some other file from a machine that has InstallShield to a machine that has the
Standalone Build, use the same relative path. For example, if a file is in the InstallShield Program Files
Folder\Modules\i386 directory on the machine that has InstallShield, copy that file to the Standalone Build Program
Files Folder\Modules\i386 directory on the machine that has the Standalone Build.
1. Locate the required redistributables on the machine that has the full version of InstallShield. The file is typically
located in InstallShield Program Files Folder\Redist or a subfolder of the Redist folder. If an InstallShield
redistributable is not available on your machine, you must download it first. For more information, see
Redistributable Downloader Wizard.
2. Copy the redistributable from the machine that has InstallShield to the Standalone Build Program Files Folder on the
build machine.
Task To add a redistributable for Basic MSI or InstallScript MSI projects to your build machine:
1. Locate the required redistributables on the machine that has the full version of InstallShield. If an InstallShield
redistributable is not available on your machine, you must download it first. For more information, see Downloading
Redistributables to Your Computer.
• If you built your own merge modules in InstallShield, you would find them in any of the locations that are listed
on the Merge Modules tab of the Options dialog box.
2. Copy the redistributable from the machine that has InstallShield to appropriate location on the build machine.
Task To add an InstallShield prerequisite for InstallScript projects to your build machine:
1. Locate the required InstallShield prerequisite on the machine that has the full version of InstallShield. If an
InstallShield redistributable is not available on your machine, you must download it first. For more information, see
Downloading Redistributables to Your Computer.
2. Copy the InstallShield prerequisite from the machine that has InstallShield to appropriate location on the build
machine:
Task To add to your build machine one of the other InstallShield redistributables for InstallScript projects:
1. Download the installation for the redistributable. The installations are available through FlexNet Connect. For more
information, see Obtaining Updates for InstallShield.
2. Run the redistributable installation on the build machine. When the InstallShield Wizard displays the Choose
Destination Location dialog, browse to the following location:
If the ObjectsPro folder has not been created yet, you will need to add that folder.
The InstallScript object installations install and register the required object files.
Task To add to your build machine one of your own InstallScript redistributables or a third-party redistributable:
If the ObjectsPro folder has not been created yet, you will need to add that folder.
See Also
Specifying the Directories that Contain InstallShield Prerequisites
Specifying the Directories that Contain Merge Modules
Installing the Standalone Build on a Build Machine
InstallShield 2020
The Standalone Build lets you use ISCmdBld.exe to build releases from the command line. For instructions, see Building a
Release from the Command Line.
See Also
Specifying the Directories that Contain InstallShield Prerequisites
Specifying the Directories that Contain Merge Modules
InstallShield 2020
The Standalone Build includes a standalone version of the automation interface—the InstallShield Standalone Automation
Interface. This interface uses the same ISWiAutomationAutomation Interface Version.dll file that is installed with
InstallShield, but it is installed to a different location.
Note • If you install the Standalone Build on the same machine as InstallShield, the first ISWiAutomationAutomation
Interface Version.dll file that is installed is the one that is registered. To learn more, see Installing the Standalone Build
and InstallShield on the Same Machine.
Future versions of the Standalone Build will have new ProgIDs and new GUIDs. This enables you to install multiple versions
of the Standalone Automation Interface side by side on the same build machine.
See Also
Automation Interface
Automating Installation Development and Build Processes
Using the Automation Interface on a 64-Bit System
InstallShield 2020
In most cases, the Standalone Build is not installed on the same machine where InstallShield is installed. If you do install
both on the same machine, you need to be aware that the Standalone Automation Interface uses the same
ISWiAutomationAutomation Interface Version.dll file that InstallShield uses, but it is installed to a different location.
In addition, both the Standalone Automation Interface and InstallShield use the same ProgID: IswiAutoAutomation
Interface Version.ISWiProject. This enables you to use the same automation script with both the Standalone
Automation Interface and InstallShield, without requiring you to change your code to reflect the appropriate ProgID.
When you first install either InstallShield or the Standalone Build, the installation registers ISWiAutomationAutomation
Interface Version.dll. If you next install the other tool, that second installation detects that
ISWiAutomationAutomation Interface Version.dll is already registered, so it does not re-register it. As long as one
instance of ISWiAutomationAutomation Interface Version.dll is registered, you can use both the Standalone Build and
InstallShield with the automation interface.
If you uninstall the first instance that you originally installed, the installation unregisters ISWiAutomationAutomation
Interface Version.dll. Therefore, you must manually register ISWiAutomationAutomation Interface Version.dll so
that you can use the automation interface with the product that still remains. For example, if you install InstallShield,
install the Standalone Build, and then uninstall InstallShield, you must next manually register the
ISWiAutomationAutomation Interface Version.dll file for the Standalone Build; otherwise, you cannot use the
Standalone Automation Interface.
To manually register ISWiAutomationAutomation Interface Version.dll, use Regsvr32.exe, which is installed in the
System32 folder. The ISWiAutomationAutomation Interface Version.dll file is installed in the System subfolder of the
InstallShield and Standalone Build Program Files folders.
See Also
Installing the Standalone Build on a Build Machine
InstallShield supports the Microsoft Build engine (MSBuild) included with the .NET Framework. MSBuild support enables
you to build Visual Studio solutions with InstallShield projects in build lab environments where Visual Studio is not
installed.
Overview
MSBuild is an extensible build framework designed to remove the build dependence on Visual Studio. The .NET Framework
functions in a role similar to the InstallShield Standalone Build, providing the capability to build projects or solutions from
the command line or any other host of MSBuild. For more information on MSBuild, see the MSDN Library.
MSBuild Tasks
The flexibility and extensibility of MSBuild is controlled through atomic groupings of internal build steps referred to as
tasks. One example of a task that ships with MSBuild is Csc, which can compile code from a Visual C# project. InstallShield
installs an MSBuild task called InstallShield, which builds an InstallShield project, and a targets file that provides default
build steps for the project. This customized task, along with the targets file, enables MSBuild to perform all required
actions to build the InstallShield project as part of a Visual Studio solution.
This table describes the parameters of the InstallShield task. The Project Type column lists the applicable project types
InstallShieldPath String Basic MSI, This parameter specifies the path to folder containing
InstallScript, the InstallShield application.
InstallScript
MSI, Merge
Module
Project String Basic MSI, This parameter specifies the location of the project file
InstallScript, (.ism).
InstallScript
MSI, Merge
Module
ProductConfiguration String Basic MSI, This parameter specifies the product configuration for
InstallScript the release.
MSI, Merge
Module
ReleaseConfiguration String Basic MSI, This parameter specifies the release name.
InstallScript,
InstallScript
MSI, Merge Note • You must specify the ReleaseConfiguration or
Module the PatchConfiguration. If you do not specify one of
these, or if you specify both of these, a build error occurs.
PatchConfiguration String Basic MSI, This parameter specifies the name of the patch
InstallScript configuration in the Patch Design view that is being
MSI built.
OutDir String Basic MSI, This parameter specifies the fully qualified path to the
InstallScript, folder where you want the output folders and files to
InstallScript be placed.
MSI, Merge
Module
MergeModulePath String[ ] Basic MSI, This parameter specifies one or more folders that
InstallScript, contain the merge modules (.msm files) that are
InstallScript referenced by your project.
MSI
InstallShield provides additional ways for specifying
the folders that contain merge modules. For more
information, see Specifying the Directories that
Contain Merge Modules.
PrerequisitePath String[ ] Basic MSI, This parameter specifies one or more semicolon-
InstallScript, delimited folders that contain the InstallShield
InstallScript prerequisite files (.prq files) that are referenced by
MSI your project.
ReleaseFlags String[ ] Basic MSI, This parameter enables you to specify any release flags
InstallScript that you want to include in your release. Separate
MSI multiple flags with commas.
PathVariables ITaskItem[ ] Basic MSI, This parameter enables you to override the path
InstallScript, variables for the project. Using this parameter, you can
InstallScript specify the path to the path variable and also define a
MSI, Merge value for the name of the path variable using the
Module PathVariable subelement.
PreprocessorDefines ITaskItem[ ] Basic MSI, This parameter enables you to add or override the
InstallScript, preprocessor defines for the project. Using this
InstallScript parameter, you can specify the definition of the
MSI preprocessor define and also define a value for the
name of the preprocessor define using the Token
subelement.
OutputGroups ITaskItem[ ] Basic MSI, This parameter specifies the project output groups
InstallScript, from the Visual Studio solution. Using this parameter,
InstallScript you can specify the path to the source location of the
MSI, Merge project output group and also define these additional
Module values using these subelements as listed:
Build String Basic MSI, This parameter specifies what type of build to perform.
InstallScript, You can choose from these types of builds:
InstallScript
• Complete—This option builds the entire release.
MSI, Merge
Module • Compile—This option compiles the Setup.rul
script file. In Basic MSI and Merge Module
projects, this option also streams ISSetup.dll
into the Binary table of the .msi package.
BuildCompressed Boolean Basic MSI, This parameter specifies whether your release is
InstallScript compressed into one file or remains uncompressed in
MSI, Merge multiple files.
Module
BuildSetupExe Boolean Basic MSI, For Basic MSI and InstallScript MSI projects, this
InstallScript parameter specifies whether you want to create a
MSI, Merge Setup.exe file along with your installation.
Module
For merge module projects, this option specifies
whether you want to build the merge module and also
copy it to the merge modules folder, or just build the
.merge module without copying it.
ProductVersion String Basic MSI, This parameter specifies the product version. This is
InstallScript especially helpful if you want to increment the build
MSI, Merge version (the third field) of the product version.
Module
For information on valid product version numbers, see
Specifying the Product Version.
PropertyOverrides ITaskItem[ ] Basic MSI, This parameter enables you to override the value of a
InstallScript Windows Installer property or create the property if it
MSI, Merge does not exist. To use this parameter, include a
Module property list of items whose value is the new property
value, and whose metadata Property is the name of
the property.
RunMsiValidator ITaskItem[ ] Basic MSI, This parameter enables you to specify one or more
InstallScript .cub files to use for validating the installation package
MSI, Merge or merge module after it is built.
Module
To learn more about validation, see Validating
Projects.
RunUpgradeValidation Boolean Basic MSI, This parameter specifies whether or not to run
InstallScript upgrade validation.
MSI
StopOnFirstError Boolean Basic MSI, This parameter specifies whether or not to stop the
InstallScript build after an initial error.
MSI, Merge
Module
MsiVersion String Basic MSI, This parameter specifies the minimum version of
InstallScript Windows Installer that the installation can accept on
MSI, Merge the target machine.
Module
DotNetFrameworkVersion String Basic MSI, This parameter specifies the minimum version of the
InstallScript .NET Framework that the installation can accept on
MSI the target machine.
DotNetUtilPath String Basic MSI, Regasm.exe and InstallUtilLib.dll are utilities that
InstallScript are included with each version of the .NET Framework.
MSI This parameter specifies the path for the directory that
contains the 32-bit version of these files that you want
to use at build time for releases that include .NET
installer classes and COM interop. This is not the path
to .NET Framework redistributable files.
Disk1Folder Output Basic MSI, This parameter specifies the location of the output
String InstallScript, folder.
InstallScript
MSI, Merge
Module
SummaryInfoComments String Basic MSI, Use this parameter to set Summary Information
InstallScript, Stream comments at build time, such as including the
InstallScript build number.
MSI, Merge
The comments that are added using this property can
Module
be viewed on the Properties dialog box of the built
installer.
MSIPackageFileName String Basic MSI, Use this parameter to specify the MSI package file
InstallScript name at build time. Specify the file name—without the
MSI period or the file extension—that InstallShield should
use for the .msi file.
InstallShieldDigitalCertifica String Advanced UI, This parameter specifies the digital certificate
tePassword Basic MSI, password, this is an optional parameter. If it is not
InstallScript, specified, the password configured in the project is
InstallScript used to sign the files.
MSI,
InstallScript
Object, Merge
Module, Suite/
Advanced UI
MSBuild Scripts
MSBuild natively understands one file format: its XML build script, which is used as the project file format for Visual C# and
Visual Basic .NET projects (.csproj and .vbproj). MSBuild also has internal hooks to handle solution files and the Visual C++
project file format (.sln and .vcproj).
The InstallShield integration with Visual Studio uses an MSBuild-compatible XML format project file (.isproj), which enables
MSBuild to seamlessly build Visual Studio solutions that include InstallShield projects. To build solutions in a standalone
environment, install the InstallShield Standalone Build on the build machine.
The following sample code from an .isproj file demonstrates how to do the following:
• Specify the following search paths for InstallShield prerequisites: <ISProductFolder>\SetupPrerequisites and
<ISProjectFolder>\MyCustomPrerequisites.
<PropertyGroup>
<InstallShieldProductVersion>1.2.3</InstallShieldProductVersion>
</PropertyGroup>
<ItemGroup>
<InstallShieldPropertyOverrides Include="My New Product">
<Property>ProductName</Property>
</InstallShieldPropertyOverrides>
<InstallShieldPropertyOverrides Include="My Value">
<Property>MY_PROPERTY</Property>
</InstallShieldPropertyOverrides>
<InstallShieldPathVariableOverrides Include="C:\MyPath">
<PathVariable>MyPathVariableName</PathVariable>
</InstallShieldPathVariableOverrides>
<InstallShieldPrerequisitePath Include="<ISProductFolder>\SetupPrerequisites"/>
<InstallShieldPrerequisitePath Include="<ISProjectFolder>\MyCustomPrerequisites"/>
</ItemGroup>
See Also
Using MSBuild to Build a Release from the Command Line
InstallShield 2020
Note • If you use MSBuild to build Visual Studio solutions with InstallShield projects, MSBuild requires .NET Framework 3.5 or
later.
MSBuild provides an easy way to build a release from the command line on a machine on which Visual Studio is not
installed. The only components you must have installed on the machine are the .NET Framework and the InstallShield
Standalone Build. Place a copy of your Visual Studio solution on the machine, and run MSBuild.
C:\Windows\Microsoft.NET\Framework\Version Folder\
3. Type the command-line statement to build the release build of the Visual Studio integration project. For example:
See Also
Microsoft Build Engine (MSBuild)
When you create a release, it has default settings. You can edit all of the release settings in the Releases view. When you use
the Release Wizard, you can also edit the settings of a release.
2. In the Releases explorer, select the release whose settings you would like to configure. The settings are displayed on
tabs in the right pane.
3. Select a setting on one of the tabs to modify its value. Information about the setting is displayed in the help pane or
when you press F1 from within the Releases view.
See Also
Releases View
To package a build as a single executable file, use the Create a single file executable option in the General Options panel
of the Release Wizard, or the Singe Exe File Name setting in the Releases view, as described in the following procedures.
Note • The single executable file that you create accepts any command-line parameter that Setup.exe accepts.
Task To package a build as a single executable file by using the Release Wizard:
4. By default, the file name <project name>.exe is entered in the File Name box. If you want the self-extracting
executable file to have a different name, type a new file name in the box or select a path variable whose value defines
the file name.
5. In the Icon box, you can specify the fully qualified name of the file that contains the icon that InstallShield should use
when it creates the Setup.exe file at build time.
To specify a file, type an explicit path or path variable, or click the browse button to open the Change Icon dialog box,
in which you can click the Browse button to select a file.
By default, the icon with index 0 is used; to specify a different icon, either select an icon in the Change Icon dialog box
or append the icon’s index or resource ID (preceded by a minus sign) to the file name. For example,
C:\Temp\MyLibrary.dll,2 indicates the icon with an index of 2, and C:\Temp\MyLibrary.dll,-100 indicates the icon
with a resource ID of 100.
6. If you want the executable file to extract the installation files to the target machine and not run the installation, enter
-extract_all:<path> in the Setup Command Line box, where <path> is the desired target folder; for example:
7. Complete the Release Wizard; in the Summary panel, select the Build the Release check box and then click the
Finish button.
Task To package a build as a single executable file by using the settings in the Releases view:
2. In the Releases explorer, select the release that you want to package as a single executable file.
4. For the Single .exe File Name setting, type a file name or a path variable (enclosed in angle brackets—for example,
<MY EXE FILE NAME>) whose value defines the file name.
5. In the Setup.exe Icon File setting, specify the fully qualified name of the file that contains the icon that InstallShield
should use when it creates the Setup.exe file at build time.
To specify a file, type an explicit path or path variable, or click the ellipsis button (...) to open the Change Icon dialog
box, in which you can click the Browse button to select a file.
By default, the icon with index 0 is used; to specify a different icon, either select an icon in the Change Icon dialog box
or append the icon’s index or resource ID (preceded by a minus sign) to the file name. For example,
C:\Temp\MyLibrary.dll,2 indicates the icon with an index of 2, and C:\Temp\MyLibrary.dll,-100 indicates the icon
with a resource ID of 100.
6. If you want the executable file to extract the installation files to the target machine and not run the installation, enter
the following for the Setup Command Line setting:
-extract_all:<path>
To learn how to digitally signing your executable file, see Digital Signing and Security. For information about requiring end
users to enter a password in order to launch the self-extracting executable file, see Password-Protecting Installations.
See Also
Setup.exe and Update.exe Command-Line Parameters
Using Path Variables
Task To place some or all features’ files uncompressed in the disk image, use the Media Layout panel in the Release Wizard:
1. Launch the Release Wizard and navigate to the Media Layout panel.
• To place all features’ files uncompressed in the disk image: Select the CDROM Folder(s) option. All features’ files
are placed in the disk image in the folders specified by the features’ CD-ROM Folder properties. If no folder is
specified for a feature, that feature’s files are placed in the root of the disk image.
a. Select the Custom option, and then click Next. The Custom Media Layout panel opens.
b. In the Features in cabinets box, select or clear the check boxes next to the features. If a feature’s files are
stored in cabinet files, clear the check box. If a feature’s files should be placed in the disk image in the folder
specified by the feature’s CD-ROM Folder property, select the check box. If no folder is specified, that
feature’s files are placed in the root of the disk image.
Tip • If you want most of your features stored in cabinet files, click Clear All and then select the features to be placed
uncompressed in the disk image. Conversely, if you want most of your features placed uncompressed in the disk image,
click Select All and then clear the check boxes for the features to be stored in cabinet files.
Note • Regardless of whether you selected Yes or No for the Compressed setting of a feature’s component, by selecting the
uncompressed (CD-ROM folder) option for the feature, its files will be uncompressed on the distribution media.
Specifying the Required Execution Level for Your Setup Launcher on Windows Vista and Later
Platforms
InstallShield 2020
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• Suite/Advanced UI
InstallShield lets you specify the minimum execution level required by your installation’s Setup.exe file for running the
installation (the setup launcher, any InstallShield prerequisites, the .msi file, and any Advanced UI or Suite/Advanced UI
packages) on Windows Vista and later platforms. You can configure this for each individual release in your project.
2. In the Releases explorer, click the release that you would like to configure.
4. For the Required Execution Level setting, select the appropriate option.
• Administrator—Setup.exe requires administrative privileges to run. Administrators must provide consent, and non-
administrators must provide credentials.
• Highest available—Setup.exe prefers administrative privileges. Administrators must provide consent to run it; non-
administrators run it without administrative privileges. This is the default option for InstallScript and InstallScript MSI
projects.
• Invoker—Setup.exe does not require administrative privileges, and all users can run it without administrative
privileges. Setup.exe does not display any UAC messages prompting for credentials or for consent. This is the default
option for Advanced UI, Basic MSI, and Suite/Advanced UI projects.
For Advanced UI, InstallScript, InstallScript MSI, and Suite/Advanced UI projects, and for Basic MSI projects if the Setup
Launcher setting is set to Yes, InstallShield embeds a Windows application manifest in the Setup.exe launcher as a
resource. This manifest specifies the selected execution level. Operating systems earlier than Windows Vista ignore the
required execution level. The execution level is defined in the manifest as follows:
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
Other valid values for the level attribute are highestAvailable and requireAdministrator.
If the Setup Launcher setting is set to No for a Basic MSI project, InstallShield does not embed the Windows application
manifest in the Setup.exe launcher.
The benefit of elevating the required execution level in Basic MSI projects is that privileges can be elevated only once if
necessary to run Setup.exe, and that these privileges can be carried over to all of the installation’s InstallShield
prerequisites and the Execute sequence of the .msi package without requiring multiple prompts for approval. Thus, if two
of your InstallShield prerequisites require administrative privileges, for example, you can change this setting to
Administrator, and then end users are prompted only once during the installation, before Windows Installer runs the
Setup.exe file.
A similar benefit exists for Advanced UI and Suite/Advanced UI projects, where privileges can be elevated only once if
necessary to run Setup.exe, and that these privileges can be carried over to all of the installation’s Advanced UI or Suite/
Advanced UI packages without requiring multiple prompts for approval.
Note, however, that if you elevate the privileges and also launch the application at the end of the installation, the elevated
privileges are carried over to the application. In most cases, running an application with elevated privileges on Windows
Vista and later platforms is discouraged.
Important • InstallShield runs with elevated privileges. If you launch your installation from within InstallShield, those
elevated privileges are carried over to your installation; thus, your installation automatically has elevated privileges. That
may not reflect the behavior that end users will see if they are using Windows Vista or later. Therefore, if you are using
Windows Vista or later on your development system, consider opening the release folder and launching the installation
directly (instead of from within InstallShield).
To quickly access your release folder so that you can launch your release directly, click the Open Release Folder on the
Standard toolbar, or on the Tools menu, click Open Release Folder.
Note that an end user’s installation experience is more secure when installations are run with only the permissions that
they need. Unless an application is designed to be run only by system administrators, it should be run with the least
privilege.
See Also
Working with InstallShield Prerequisites that Are Included in Installation Projects
Minimizing the Number of User Account Control Prompts During Installation
Specifying Whether a Product Should Be Advertised If Its InstallShield Prerequisites Are Run
with Elevated Privileges
InstallShield 2020
• Basic MSI
• InstallScript MSI
Depending on how it is configured, an installation that includes InstallShield prerequisites may display a User Account
Control (UAC) prompt for elevated privileges on Windows Vista and later systems at several different points during the
installation:
2. When the Setup.exe file launches a setup prerequisite that requires elevated privileges
3. When the Setup.exe file launches a feature prerequisite that requires elevated privileges
4. When the Windows Installer begins the Execute sequence of the .msi package
If you select Administrator for your installation’s Required Execution Level setting in the Releases view, Windows Vista and
later typically display only one UAC prompt; it is displayed when the end user launches the Setup.exe file. However, if you
select Invoker for this setting, Windows Vista and later may display more than one UAC prompt during the installation. For
example, Windows Vista and later may display a UAC prompt for a setup prerequisite that requires elevated privileges and
another UAC prompt for the Execute sequence of the .msi package. If this scenario applies to your installation, you may
want to specify that your installation should advertise and then run your .msi package to help end users avoid the UAC
prompt for the .msi package. If this scenario does not apply to you, it is recommended that you avoid advertising the .msi
package because it would not avoid a UAC prompt.
Tip • The Require Administrative Privileges setting in the General Information view is where you specify whether the .msi
package requires administrative privileges. The Behavior tab in the InstallShield Prerequisite Editor is where you specify
whether a prerequisite requires administrative privileges. For more information about other InstallShield settings that may
affect whether Windows Vista and later displays UAC prompts, see Minimizing the Number of User Account Control Prompts
During Installation.
2. In the Releases explorer, click the release that you would like to configure.
4. For the Advertise If Prerequisites Are Elevated setting, select the appropriate option.
• Advertise: Silent—Indicates that if setup prerequisites in the installation are successfully installed with elevated
privileges, the .msi package should be advertised and run silently (without a user interface). Then the Execute
sequence of the main installation does not require an additional UAC prompt for consent or credentials.
• Advertise: Full UI—Indicates that if setup prerequisites in the installation are successfully installed with elevated
privileges, the .msi package should be advertised and run with a full user interface. Then the Execute sequence of the
main installation does not require an additional UAC prompt.
• No—Indicates that the .msi package should not be advertised. When end users run the installation, one or more UAC
prompts may be displayed to install the setup prerequisites. If the Execute sequence of the .msi package also requires
elevation, an additional UAC prompt may be displayed before the Windows Installer begins the Execute sequence.
Important • The package must support advertisement in order for either of the advertise options to work. Advertisement is
not instantaneous, and it adds extra delays to the installation. In addition, unexpected behavior may occur if the end user
clicks Cancel after advertisement but before the main part of the installation has finished. For example, advertised shortcuts
for your product may appear on the desktop before the main installation begins, and a confused user canceling the main
installation may leave your package advertised but not fully installed. Therefore, in some cases, it may be better to leave this
setting as No to allow the extra UAC prompt and avoid product advertisement.
A common goal is for an installation to display only one UAC prompt. The advertise options for the Advertise If
Prerequisites Are Elevated setting facilitate this but do not guarantee it in all situations. For example, any time that an
installation causes a restart, the installation process returns to limited privileges after the restart. The subsequent privilege
elevation may display an additional UAC prompt, whether the elevation is required for a setup prerequisite, for a feature
prerequisite, or for the .msi package. When the restart comes between the last prerequisite and the .msi package, the .msi
package is not advertised. Following are some examples of different outcomes that may occur when you select one of the
advertise options for this setting:
• The prerequisites require elevation and install successfully on the target machine. The product is advertised and
installed. The product installation does not display a UAC prompt.
• One of the prerequisites in the installation may require a restart. After the restart for the prerequisite occurs, either no
additional prerequisites are installed or none of the other prerequisites that are installed require elevation. Since the
last prerequisite that is installed in this scenario is not a simple success of an elevated prerequisite, advertisement of
the .msi package does not occur.
• None of the prerequisites in the installation need to be installed because they are already present on the target
machine; therefore, advertisement of the .msi package does not occur.
• None of the prerequisites in the installation require elevation; therefore, advertisement of the .msi package does not
occur.
• Elevated prerequisites are successfully installed. However, for this situation, the package is a minor upgrade for a
product that is already installed. That is, the product code in the package matches the product code of the product
that is already present on the target machine. Advertisement of the .msi package does not occur. UAC prompts may or
may not be displayed; it depends on whether a suitable digital certificate is included in the earlier installation and in
the patch.
See Also
Specifying the Behavior for an InstallShield Prerequisite that Requires a Restart
Setup Prerequisites vs. Feature Prerequisites
Password-Protecting Installations
InstallShield 2020
For added security, you can password-protect your installation package. When you password-protect your installation, any
end user who wants to install your package must enter a case-sensitive password to open your installation.
You can activate password protection in the Password & Copyright panel of the Release Wizard.
Specifying the Run-Time Location for InstallShield Prerequisites at the Release Level
InstallShield 2020
• Basic MSI
• InstallScript
• InstallScript MSI
InstallShield lets you specify the run-time location of the InstallShield prerequisites that are included with your
installation.
Task To specify where all of the InstallShield prerequisites should be located for a release, do one of the following:
• In the Releases view, select the release. Then on the Setup.exe tab, for the InstallShield Prerequisites Location
setting, select the appropriate option.
1. In the Redistributables view (in Basic MSI and InstallScript MSI projects) or the Prerequisites view (in InstallScript
projects), specify the appropriate location for each InstallShield prerequisite. For more information, see Specifying a
Run-Time Location for a Specific InstallShield Prerequisite.
5. For the InstallShield Prerequisites Location setting, select Follow Individual Selections.
Tip • As an alternative, you can select the Follow Individual Selections option in the InstallShield Prerequisites panel of the
Release Wizard.
Note that if an InstallShield prerequisite is added to a project as a dependency of another prerequisite, the location for the
prerequisite dependency follows the location setting of the prerequisite that requires it.
If you build a release that includes InstallShield prerequisites and both of the following are true, one or more build errors
may be generated:
• You specify for the InstallShield prerequisites location that the prerequisites should be extracted from Setup.exe or
copied from the source media (instead of being downloaded from the Web to the end user’s computer).
To eliminate the build errors, remove the InstallShield prerequisite from your project, download the InstallShield
prerequisite from the Internet to your computer, or change the InstallShield prerequisites location for the release to the
download option; then rebuild the release.
See Also
Release Wizard
Working with InstallShield Prerequisites that Are Included in Installation Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to Basic MSI and InstallScript MSI Projects
Adding InstallShield Prerequisites, Merge Modules, and Objects to InstallScript Projects
Specifying URLs for Downloading InstallShield Prerequisites
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
InstallShield lets you specify the run-time location of the packages that are included with your Advanced UI or Suite/
Advanced UI installation.
Tip • If you are configuring an Advanced UI or Suite/Advanced UI project for an update setup launcher, the run-time location
of the packages must be either extracted from the setup launcher or downloaded from the Web. The update setup launcher
cannot rely on packages that are stored on the source media.
For more information, see Supporting Downloadable Updates for an Advanced UI or Suite/Advanced UI Installation.
Task To specify where all of the packages should be located for a release:
2. Specify the appropriate location for each InstallShield prerequisite. For more information, see Specifying a Run-Time
Location for a Specific Package in an Advanced UI or Suite/Advanced UI Project.
Note that if a package is added to a project as a dependency of another package, the location for the package dependency
follows the location setting of the package that requires it.
If you build a release that includes package and both of the following are true, one or more build errors may be generated:
• You specify for the package location that the packages should be extracted from Setup.exe or copied from the source
media (instead of being downloaded from the Web to the end user’s computer).
To eliminate the build errors, remove the package from your project, add the package to your computer, or change the
package location for the release to the download option; then rebuild the release.
See Also
Guidelines for Adding Packages to an Advanced UI or Suite/Advanced UI Project
• Advanced UI
• Suite/Advanced UI
Edition • The Advanced UI project type is available in the Professional edition of InstallShield. The Suite/Advanced UI project
type is available in the Premier edition of InstallShield. For information about the differences between these two project types,
see Advanced UI Projects vs. Suite/Advanced UI Projects.
You can specify the uninstallation order of packages in a suite project using the Uninstallation Order property on the
Setup.exe tab of the Releases view.
• Same as Packages Order—Uninstall the packages in the same order that packages were installed (as defined in
the project).
• Reverse of Packages Order—Uninstall the packages in the reverse order that packages were installed (as
defined in the project).
• euoForward(0)—Uninstall the packages in the same order that packages were installed (as defined in the project).
• euoReverse(1)—Uninstall the packages in the reverse order that packages were installed (as defined in the project).
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• InstallScript Object
• Merge Module
• Suite/Advanced UI
You can digitally sign your installation and your application files to assure end users that neither your installation nor the
code within your application has been tampered with or altered since publication.
The Signing tab is where you specify the digital signature information—including the digital certificate files that a
certification authority grated to you—that InstallShield should use to sign your files.
The Signing tab is also where you specify which files in your installation should be digitally signed by InstallShield at build
time. InstallShield enables you to sign any and all of the following files in a release, depending on what type of project you
are using:
• Windows Installer package (.msi file) for Basic MSI and InstallScript MSI projects
• Setup.exe file for Advanced UI, Basic MSI, InstallScript, InstallScript MSI, and Suite/Advanced UI projects
Windows Logo • All executable files (including .exe, .dll, .ocx, .sys, .cpl, .drv, and .scr files) in an installation must be digitally
signed for the Windows logo program.
To learn more about the various settings on the Signing tab, see Signing Tab for a Release.
Certification Authorities
A certification authority is an organization such as VeriSign that issues and manages digital certificates (also known as
digital IDs). The certification authority validates the requester’s identity according to prescribed criteria and issues a digital
certificate. Obtaining a digital certificate requires providing the certificate authority with specific information about your
company and your product.
For a list of certification authorities, see the Windows Root Certificate Program member list on the MSDN Web site.
SHA-256 is favored over SHA-1, which is being deprecated because of the potential for security vulnerabilities. Microsoft
announced that Windows will stop trusting items that were signed and timestamped with SHA-1 certificates after January
1, 2016. In addition, certification authorities—the organizations that issue certificates—are phasing out the creation of
SHA-1 certificates. Thus, it is recommended that you replace any SHA-1 certificates in your InstallShield projects with SHA-
256 certificates. For the latest information and more specific details, check with your certification authority.
If your project is configured to sign with a SHA-256 certificate, InstallShield uses a SHA-256 hash in the signature of the files
that it signs at build time. If your project is configured to sign with a SHA-1 certificate, InstallShield uses a SHA-1 hash. Note
that use of a SHA-1 certificate triggers build warning -7346 to alert you about the SHA-1 usage.
Beginning with InstallShield 2016, support for SHA-256 digital certificates for Windows Installer and InstallScript projects
was enhanced to:
Important • Any new signatures created or timestamped after Jan 1, 2016 must be SHA-256-based signatures. Any files
signed with an SHA-1 certificate need to have a timestamp showing a date and time prior to Jan 1, 2016 in order to continue to
be supported. Those files will still be allowed through the 'Mark-of-the-web" system until Jan 14, 2020, when all SHA-1 support
will stop in all current versions of Windows.
• You can specify the .pfx certificate file on your machine that you want to use.
• You can reference a certificate store that contains the certificate that you want to use.
• PVK2PFX.exe—This is part of the Windows Platform SDK, and it is also included with Microsoft Visual Studio 2005.
• pvkimprt.exe—You can download this PVK Digital Certificate Files Importer tool from the downloads area on the
Microsoft Web site (http://www.microsoft.com/downloads/details.aspx?FamilyID=F9992C94-B129-46BC-B240-
414BDFF679A7&displaylang=EN).
If you configure your project to use a certificate that was imported with password protection into a store, Windows
prompts for the password at build time when InstallShield is attempting to sign your project’s files. The strong key
protection that Windows uses does not permit InstallShield to provide the password to the cryptographic provider.
To learn how to change the default timestamp server that InstallShield uses, or for information on how to disable
timestamping, see Changing the Timestamp Server for Digital Signatures.
See Also
Changing the Timestamp Server for Digital Signatures
InstallShield lets you configure digital signing settings for a release. At build time, InstallShield uses the settings that you
have configured to sign your installation package, your Setup.exe file, and any other files in your release that meet the
criteria that you have defined.
Task To configure digital signing for your release and its files:
2. In the Releases explorer, click the release that you want to sign.
• Certificate URL
• Digital Certificate File—Click the ellipsis button (...) in this setting. The Certificate Selection dialog box opens,
enabling you to specify either the location of the .pfx file or information about the certificate store that contains
the certificate.
• Certificate Password—Note that if you configure your project to use a certificate that was imported with
password protection into a store, Windows prompts for the password at build time when InstallShield is
attempting to sign your project’s files. The strong key protection that Windows uses does not permit InstallShield
to provide the password to the cryptographic provider.
• Signature Description
5. In the Sign Output Files setting, specify which files (Setup.exe, the .msi package, both of those files, or neither of
those files) you want to be signed.
6. In the Sign Files in Package setting, specify whether you want to sign additional files in your installation.
If you select Yes, use the other settings under the Sign Files in Package setting to indicate which files and file patterns
should be signed and which should not be signed.
Note that the files and file patterns that should not be signed override any files and file patterns that should be signed.
For example, if you specify *.exe in an Include setting and in an Exclude setting, InstallShield does not sign any .exe
files.
Tip • For detailed information about any of the settings on the Signing tab, see Signing Tab for a Release.
At build time, InstallShield signs the files as specified on the Signing tab. If the release is for an installation that includes
merge modules, note that the files are signed before the merge module is merged.
See Also
Certificate Selection Dialog Box
Signing a Patch Package
Signing a QuickPatch Package
Working with Releases
Changing the Timestamp Server for Digital Signatures
Digitally Signing a Release After It Has Been Built From the Command Line
InstallShield 2020
• InstallScript
• InstallScript Object
As an alternative to having InstallShield sign your application at build time, you can use the iSign application (iSign.exe)
to digitally sign a release of an InstallScript project from the command line after you have built the release.
For syntax and available command-line parameters for iSign.exe, see iSign.exe.
Release Flags
InstallShield 2020
Project • The following project types include support for release flags:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
When you build your release, you can include and exclude features, InstallShield prerequisites, and chained .msi packages
depending on the type of release. For example, if you are creating a trial version of your product and do not want to include
all the features in the build, you can flag features and then specify those flagged features under the product configuration
or the release.
Task To filter features, InstallShield prerequisites, and chained .msi packages based on release flags:
1. Assign release flags to the features, InstallShield prerequisites, and chained .msi packages.
For detailed information on how, see Assigning Release Flags to Features, Assigning Release Flags to InstallShield
Prerequisites, or Assigning Release Flags to a Chained .msi Package.
The scenario of a trial version versus a full version is a good example of why you might use release flags. The table below
gives an example of four different features that may be available in a product, depending on which version the end user
receives.
In this example, the full version comes with the application’s executable file, help files, a spellchecker, and an add-on pack
that is included as a chained .msi package. The trial version does not include the add-on pack, but it does include an
upgrade pack. Rather than having to create two separate installation projects for what is essentially one product, you can
flag those features that are specific to certain versions. For example, the add-on feature is flagged as Full and the upgrade
feature as Trial.
If you build your release through the Release Wizard, you are given the option of including any flagged features, flagged
InstallShield prerequisites, and flagged chained .msi packages into your release. By default, the release contains all
features, InstallShield prerequisites, and chained .msi packages. If you specify the release flag Full in the Filtering Settings
panel of the Release Wizard, only the Spellchecker feature and the Add_Ons chained .msi package—along with all features
and InstallShield prerequisites without release flags—are built into your release. The upgrade pack is not included in the
installation.
Tip • By default, all features, InstallShield prerequisites, and chained .msi packages are included in a release. When you
specify a release flag in either the Releases view or the Release Wizard, only the unflagged features, the unflagged
InstallShield prerequisites, the unflagged chained .msi packages, the features that contain the specified flag, the InstallShield
prerequisites that contain the specified flag, and the chained .msi packages that contain the specified flag are included in your
installation. InstallShield does not include in the release any features, InstallShield prerequisites, or chained .msi packages
that have a release flag that you did not include in the Releases view or Release Wizard.
See Also
Conditionally Launching Custom Actions Based on Release Flags
Project • The following project types include support for product configuration flags and release flags:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
You can specify which flags to include in your installation both on the release, known as release flags, and on the product
configuration, known as product configuration flags. Although release flags are exposed both as a setting of the release and
in the Release Wizard’s Filtering Settings panel, you can edit the product configuration flags only on the General tab of the
product configuration in the Releases view.
Product configuration flags complement release flags. That is, any feature flags that you specify for the product are
combined with the flags on the individual release that you are building, and all of the features, InstallShield prerequisites,
and chained .msi packages with the specified flags are built into the release. Be careful when specifying flags in the Release
Wizard, because you cannot see which flags are included at the product configuration level.
To demonstrate how product configuration and release flags interact, consider a project with the following features,
InstallShield prerequisites, and chained .msi packages.
Table 4-8 • Sample Features, InstallShield Prerequisites, and Chained .msi Packages
The following table explains which features, InstallShield prerequisites, and chained .msi packages are included in your
installation based on the combination of product configuration flags and release flags:
Table 4-9 • Combining Product Configuration Flags and Release Flags (cont.)
See Also
Conditionally Launching Custom Actions Based on Release Flags
Using Release Flags with Features
Assigning Release Flags to InstallShield Prerequisites
Assigning Release Flags to a Chained .msi Package
Project • The following project types include support for product configuration flags and release flags:
• Basic MSI
• InstallScript MSI
• Suite/Advanced UI
Once you have assigned release flags to your features and InstallShield prerequisites, you can create a release that
includes the ones that are based on those flags. By default, all features, InstallShield prerequisites, and chained .msi
packages are included in a release. Once you specify a flag in either the Releases view or the Release Wizard, only the
unflagged features, the unflagged InstallShield prerequisites, the unflagged chained .msi packages, the features that
contain the specified flag, the InstallShield prerequisites that contain the specified flag, and the chained .msi packages that
contain the specified flag are included in your installation. To include only unflagged features, unflagged InstallShield
prerequisites, and unflagged chained .msi packages, specify a flag that does not exist. For example, you might use
NoFlags. This way, only unflagged features, unflagged InstallShield prerequisites, and unflagged chained .msi packages
are built into a release.
It is possible to include a subfeature but not its parent feature. In such a case, the subfeature is built into the release as a
top-level feature, and its parent is excluded from the release.
You can filter features, InstallShield prerequisites, and chained .msi packages in the Release Wizard or in the Releases view.
Both methods are described below.
2. In the Releases explorer, click the product configuration that you want to modify. Its settings are displayed on the
General tab in the right pane.
3. For the Product Configuration Flags setting, enter the flags that you would like to include. To include more than one
flag, separate each with a comma.
2. In the Releases explorer, click the release that you want to modify. Its settings are displayed on tabs in the right pane.
3. For the Release Flags setting, enter the flags that you would like to include in this release. To include more than one
flag, separate each with a comma.
See Also
Conditionally Launching Custom Actions Based on Release Flags
Using Release Flags with Features
Assigning Release Flags to InstallShield Prerequisites
Assigning Release Flags to a Chained .msi Package
You may want to release your product with more than one configuration—for example, an evaluation release and a full
release. Within a single project, you can build releases containing different subsets of the project’s features; with a single
installation script using preprocessor directives, you can build releases with different run-time behaviors.
3. In the Features explorer, select the check boxes of the features that you want to include in the product configuration,
and clear the check boxes of the features that you do not want to include.
1. In your script, use preprocessor directives to execute different code for different product configurations; for example:
#ifdef EVAL_RELEASE
/* Evaluation-specific code */
#elif FULL_RELEASE
/* Full release-specific code */
#endif
2. In the Compiler Preprocessor Defines box (on the General Options panel of the Release Wizard) or the Compiler
Preprocessor Defines setting (on the Build tab in the Releases view), specify the preprocessor constant that
corresponds to the code that you want the release to execute.
When downloading an application from the Internet, many end users experience a long and confusing series of instructions
explaining how to download and run the application properly. The typical download can take as many as 10 steps. It can be
a frustrating and time-consuming process that is not always successful. End users who fail to download the application
properly must rely on product support to assist them, or they give up completely and never gain access to the application.
This results in time lost for both the consumer and the development team.
With a One-Click Install setup, however, the end user can download an application with minimum effort and can begin
using the application immediately. Compare the installation processes for both typical and One-Click Install setups below.
1. The end user navigates to the Web page and clicks the link to download the application.
2. A dialog opens. The dialog prompts the end user to agree to a software licensing agreement.
3. The end user is given the opportunity to save the installation’s executable file to disk. The end user must remember
this location to access the installation’s executable file later.
5. The end user must search for the installation executable file and then launch it.
7. If any other resources are necessary for the proper execution of the application, the end user must download them at
this time.
8. The installation executes and begins to walk the end user through the installation process.
9. The end user makes several choices, such as the disk location of the application executable file.
11. The end user locates the application executable file on disk and launches the application.
1. The end user navigates to the Web page and clicks the download button.
2. A dialog opens. The dialog shows the progress of the file transfer. Once the installation has been downloaded, the
installation runs.
One-Click Install setups keep the end user on your Web page, instead of searching for an executable file to run. One-
Click Install setups make it possible for the end user to concentrate on using the application, not struggling to download it.
A One-Click Install installation includes a setup player (Setup.ocx) that downloads and then launches the Setup.exe file
with the appropriate command line. This enables end users who are using Windows Vista and later with limited privileges
to run the installation; if elevated privileges are required because of the required execution level specified in the
installation’s manifest, the appropriate User Account Control (UAC) prompt is displayed when the Setup.exe file is
launched. If end users have an earlier version of Windows on their systems, the manifest is ignored, but the other behavior
is the same.
The Setup.exe file for One-Click Install installations does not include any COM information.
Like any other installation, an Internet installation can use features such as updating, maintenance mode, multi-instance
installation, silent installation—in short, any feature that is available for any InstallShield installation.
Function Description
CopyFile Copies a file that is specified by a valid URL, or transmits a CGI or ASP request.
Function Description
SeekBytes Repositions the file pointer within a file that is specified by a valid URL.
The objects within One-Click Install’s setup player are Player and Ether. The Player object is the highest level of the object
model, followed by Ether.
Player Object
InstallShield 2020
Before you can use the setup player, you must create an instance of it. For more information, see Using the Setup Player.
• Open (<URL>)—Specifies the location of the data .cab files and returns a reference to an Ether object. The argument
consists of a URL representing the path to a web server, a UNC path, or the path to the location of the files on your
local drive.
Examples
Player.Open("http://www.mydomain.com/myproduct");
Player.Open("file://\\server\myproduct");
Player.Open("file://c:/my installations/myproduct/media/default");
LastError Method
InstallShield 2020
This is the LastError method of the Player object. This is an integer value containing the error code for an error thrown by a
method of the Player, usually Open().
Syntax
var nError = player.LastError;
Example
var ether = Player.Open("http://www.installshield.com")
Parameters
None.
Return Values
Table 4-11 • Return Values for the LastError Method
-2147186688 No permissions were granted. Clicking Deny on the Java Security dialog throws this error.
-2147186686 Failed to update or install the Setup Player ActiveX control. Verify your ability to download from
the URL specified in the Codebase attribute of the APPLET tag.
-2147166892 Requested URL not found. Verify that your installation files are available at the URL specified
during the player.Open call.
-2147166895 Unable to access protected resource. This error is returned when attempting to access an
installation that requires authentication and the end user does not enter the correct
information.
-2147012889 The server name could not be resolved. Verify that the URL used in your player.Open call.
Misspelling the domain name the URL is a common cause of this error.
Note • For the first six errors listed, the end user can check the Java console for detailed error information.
Open Method
InstallShield 2020
The Open method of the Player object accepts one string argument that specifies the URL of the installation’s cabinet files.
Syntax
var ether = Player.Open("<URL string>")
Example
var ether = Player.Open("http://www.installshield.com")
Parameters
Parameter Description
Return Values
The Open method returns a reference to an Ether object.
Ether Object
InstallShield 2020
Method Description
GetLastError Method
InstallShield 2020
After calling the Ether object’s Play method, call the GetLastError method to find out the result of the installation.
GetLastError tells you if an error occurred, if the installation finished successfully, or if the installation was canceled.
Syntax
ether.GetLastError( );
Example
It is best to poll GetLastError as in the following example:
var intervalID = 0;
function startInstall() {
if (ether)
{
ether.Play();
if (intervalID == 0)
intervalID = window.setInterval("IsSetupFinished()", 3000);
}
}
function IsSetupFinished()
{
var nResult = ether.GetLastError();
if (nResult != 0)
{
if (nResult == SETUP_FINISHED) // setup has completed successfully
/* to do */ ;
if (nResult == SETUP_ERR_CANCELLED) // setup was cancelled
/* to do */ ;
clearInterval(intervalID);
intervalID = 0;
}
}
Parameters
None.
Return Values
A complete list of GetLastError return values is in Disk1\_graphics\Utilities.js under the release’s Disk Images folder,
and is given below.
• SETUP_RUNNING
• SETUP_FINISHED
• SETUP_ERR_GENERAL
• SETUP_ERR_LOADMEDIA
• SETUP_ERR_INSTALLKERNEL
• SETUP_ERR_STARTKERNEL
• SETUP_ERR_OPENCAB
• SETUP_ERR_INSTALLSUPPORT
• SETUP_ERR_SETTEXTSUB
• SETUP_ERR_INITINFO
• SETUP_ERR_GETSETUPDRIVER
• SETUP_ERR_INITPROPERTIES
• SETUP_ERR_RUNINSTALL
• SETUP_ERR_UNINSTALLSUPPORT
• SETUP_ERR_EXTRACTBOOT
• SETUP_ERR_DOWNLOADFILE
• SETUP_ERR_CANCELLED
IsPlaying Method
InstallShield 2020
The IsPlaying method of the Ether object returns a Boolean value indicating whether the installation is running.
Syntax
var <variable> = ether.IsPlaying();
Example
var bPlaying = ether.IsPlaying();
Parameters
None.
Return Values
Play Method
InstallShield 2020
To see an example of the use of this method, build a release using the Create a default Web page option in the Release
Wizard’s Internet Options panel or the Release property grid’s Create Default Web Page property, then examine the code in
the generated Web page (Setup.htm).
Syntax
ether.Play();
Parameters
None.
Return Values
None.
SetProperty Method
InstallShield 2020
The SetProperty method of the Ether object accepts two arguments. The first, a string, represents the name of the property
is::CmdLine. The second is a string specifying Setup.exe command-line parameters.
Syntax
ether.SetProperty("is::CmdLine","Setup.exe command-line options");
Example
ether.SetProperty("is::CmdLine","-l0x0407");
Parameters
The following table contains the parameters for the SetProperty method.
Return Values
None.
When an end user runs a One-Click Install installation, the setup player (Setup.ocx) needs to verify the digital signatures
for following files:
• Setup.ocx
• Setup.exe
• Data1.hdr
• ISSetup.dll
If any of those files are unsigned or the signature is corrupted, the setup player displays a single prompt to inform the end
user that the signature could not be verified. If all files are properly signed and your certificate is not yet always trusted, the
setup player displays a prompt to ask the end user to authorize it (similar to the one that is displayed when you run an
executable file that you downloaded).
InstallShield signs the Setup.ocx file for you. The certificate that is used to sign the Setup.exe, the Data1.hdr, and
ISSetup.dll files must match. This happens automatically if you select the options for signing the Setup.exe file and the
media header.
See Also
Digital Signing and Security
InstallShield’s simplified model for Internet installations eliminates several methods and properties that the Ether object
and its subobjects had in InstallShield Professional 6.x. The following is a list of those methods and properties, and how to
replace them if you are converting an InstallShield Professional 6.x installation Web page to work with an InstallShield
installation.
AskDestPath
To display the equivalent dialog during the installation, call the InstallScript function AskDestPath in your installation
script. To pass a destination path to the installation from the Web page, set a script-defined property.
CommandLine
Replace a line like the following:
To offer the equivalent functionality during the installation, call the InstallScript function SdFeatureTree in your
installation script. To pass a feature selection to the installation from the Web page, set a script-defined property; in
addition, in the installation script, use its value to conditionally call FeatureSelectItem.
Features, GetState
To get a feature’s selection state during the installation, call the InstallScript function FeatureIsItemSelected in your
installation script. A Web page cannot get a feature’s selection state.
FileToOpen
To open a file during the installation, call the InstallScript function LaunchApplication in your installation script. To pass a
file name to the installation from the Web page, set a script-defined property.
GetDownloadSize, FileLevelCosting
To get the required disk space during the installation, call the InstallScript function FeatureGetTotalCost in your
installation script. (Feature dialogs such as SdFeatureTree display the required disk space.) A Web page cannot get the
required disk space.
Language
Replace a line like the following:
ether.SetProperty("is::CmdLine","-l<language code>");LegacyMode
By default, Internet installations run in legacy mode—that is, with the installation’s user-interface events generated as
appropriate. There are two ways to duplicate the effect of setting ether.LegacyMode=false; on your Web page:
ether.SetProperty("is::CmdLine","-s");
• Set a script-defined property or check the return value of Is(WEB_BASED_SETUP), and conditionally call the
installation’s user-interface event handler functions in the OnShowUI handler.
ProductName
A Web page cannot get this information.
GetTargetDir
A Web page cannot get this information.
GetTextSub
A Web page cannot get this information.
IsInstalled
A Web page cannot get this information.
SetSetupType
To specify a setup type during the installation, call the InstallScript function FeatureSetupTypeSet in your installation
script. To display a setup type selection dialog during the installation, call SdSetupType in your installation script. To pass
a setup type to the installation from the Web page, set a script-defined property.
SetTargetDir
To specify a target directory during the installation, assign a value to the system variable TARGETDIR in your installation
script. To pass the target directory to the installation from the Web page, set a script-defined property.
SetTextSub
To specify a text substitution during the installation, assign a value to the TextSub object’s Value property in your
installation script. To pass a text substitution to the installation from the Web page, set a script-defined property.
A default Web page called Setup.htm is created in your disk image folder when you build your One-Click Install installation
using one of the following methods:
• Select the Create a default Web page for the setup check box on the Internet Options panel in the Release Wizard.
• Select Yes for the Create Default Web Page setting on the Internet tab in the Releases view.
You can use this page as it is, customize it however you want, or refer to it as an example of using the Setup Player.
Note that the aforementioned Web page creation settings are disabled if the Generate One-Click Install setting in the
Releases view is set to No.
You must have a Web server that supports HTTP 1.1 on the hosting system. Note that FTP does not support One-Click
Install installations.
It is not necessary to call the Setup Player from a Web page. It is possible to call the Player from other sources such as a
login script or a Visual Basic or Visual C/C++ application. Any programming tool that supports ActiveX controls can call the
Player.
If ether.IsPlaying() Then
MsgBox "Setup is running."
Else
MsgBox "Setup is not running."
End If
Your One-Click Install installation can be run under the secure hypertext transfer protocol (HTTPS)—that is, HTTP using the
Secure Sockets Layer (SLL). The only modification that your installation requires in order to run with HTTPS is to change
http:// to https:// in URLs that are passed to Internet-enabled functions.
You can create a One-Click Install installation using the Release Wizard.
4. Select the Create a default Web page for the setup check box or specify the location of a custom Web page in the
Enter the URL to launch box.
Task To create a One-Click Install installation for a Basic MSI or InstallScript MSI project:
4. Navigate to the One Click Install panel, and select the Generate One-Click Install option.
6. Indicate the browsers that you want your One-Click Install installation to support.
InstallShield 2020
The Setup Player is a Setup.ocx file that downloads and then launches the Setup.exe file with the appropriate command
line. The Setup.ocx file also supports launching a setup executable file with a name other than Setup.exe; for this to work
correctly, the [Startup] section of the Setup.ini file should contain the following key:
LauncherName=SetupLauncher
For an example of using the Setup Player in a Web page, build a release using the Create a default Web page option in the
Release Wizard’s Internet Options panel or the Create Default Web Page setting on the Internet tab in the Releases view.
Then examine the code in the generated Web page (Setup.htm).
Once an instance of the Player has been created, you may use the methods and properties associated with each of the
objects within the Player to customize your installation.
See Also
One-Click Install Installations in InstallScript Projects
InstallShield 2020
To pass data to a launched One-Click Install installation, use the is::CmdLine parameter and the CMDLINE script variable.
See Also
Setup.exe and Update.exe Command-Line Parameters
InstallShield 2020
To run an Internet installation silently, pass it the desired Setup.exe command-line options by calling the Ether object’s
SetProperty method, as in the following examples:
• When running a silent Internet installation, you must specify the -f1 option; there is no valid default location for the
response file in Internet installations.
• When recording or running a silent Internet installation, you must specify a fully qualified absolute path if using the -
f1 or -f2 option; these options do not accept URLs.
• The second argument to SetProperty must use the escape sequences (\\ and \") to specify backslashes and quotation
marks, as in the preceding examples.
See Also
Setup.exe and Update.exe Command-Line Parameters
InstallShield 2020
When you specify a language by using the following method, the One-Click Install installation runs in this language
regardless of the default language specified in InstallShield or the default language of the target system. If you do not use
this method, the One-Click Install installation determines the run-time language in the same way as any other installation.
a. On the Project menu, click Settings. The Project Settings dialog box opens.
c. Select the check box for that language that your installation should target.
3. On your Web page, before you call the Play method, call the SetProperty method to specify the appropriate language
identifier.
For example, the language ID for English is 0009. To set English as the runtime language use the following code:
ether.SetProperty("is::CmdLine","-l0009");
InstallShield 2020
To run your One-Click Install installation in debug mode, enter the following code before invoking ether.Play:
InstallShield 2020
If your One-Click Install installation requires authentication after it is started, you can authenticate the user on the fly using
InstallScript. When authentication is required, the Web server returns HTTP error code 401 to your installation, which
generates an InternetError event. Respond to that event by prompting the user for a user name and password in the
OnInternetError event handler.
The easiest way to do so is to use the InternetErrorDlg API in WinInet.dll and return the value IDRETRY from
OnInternetError. This causes the installation to issue the HTTP request for the file again. If users enter incorrect
information, they will be prompted to enter it again.
Setup.ini
InstallShield 2020
Setup.ini is an initialization file that is created during the build process of InstallScript-based projects to control certain
elements of the installation. The build process fills in only certain key names and values in Setup.ini. After the build
process creates Setup.ini, it is placed in the Disk1 folder in <project folder>\Media\<media name>\Disk Images.
If you want to customize Setup.ini further, modify it with a text editor. You can automate this process by using the
Postbuild Options panel of the Release Wizard or the Execute Batch File property in the Releases view to launch a batch file
or executable file that performs the desired modifications. Do not simply overwrite Setup.ini with a modified copy from a
previous media build; doing so could cause your installation to work improperly.
• [Startup]
• [Mif]
You can add additional sections to Setup.ini to pass information to your setup script. You can then call the GetProfString
and GetProfInt functions to transfer the information from the Setup.ini file to your installation.
[Startup]
EnableLangDlg=Y
Product=My Application
ProductGUID=23EAFFCA-361D-11D3-8B0F-00105A9846E9
Skin=Setup.skin
SmallProgress=N
SplashTime=5
CheckMD5=N
CmdLine=/f1Test1.iss
LauncherName=MyInstall.exe
[Mif]
Type=SMS
Filename=Ishield
SerialNo=IS50-32XYZ-12345
Locale=DEU
Note • If you need to access the file later (after Disk1 has been removed), you should copy Setup.ini to the support folder
(SUPPORTDIR) at the beginning of the installation.
You can use the following keynames in the [Startup] section of Setup.ini:
• EnableLangDlg
• Product
• ProductGUID
• CompanyName
• Skin
• SmallProgress
• SplashTime
• CheckMD5
• CmdLine
• LauncherName
EnableLangDlg
The EnableLangDlg keyname tells the installation whether to display the Language dialog during installation initialization.
The Language dialog lets your end user decide which available language the installation should run in. You can set this
value in the Setup Languages panel of the Release Wizard or through the Languages Dialog property in the Releases
view.
For more information about the Language dialog, see How an Installation Determines Which Language to Use for the User
Interface.
Product
The Product keyname identifies an application or product name to be displayed at the beginning of the text string in the
startup message dialog box.
ProductGUID
The ProductGUID keyname specifies the installation’s GUID so that Setup.exe has access to this data during initialization.
The media builder automatically enters the correct value in Setup.ini; do not change the value.
CompanyName
The CompanyName keyname specifies the name of the company name.
Skin
The Skin keyname specifies the name of the skin file that the installation uses to display end-user dialogs. If this keyname is
not in Setup.ini, no skin is used. You can specify a skin in the User Interface panel of the Release Wizard or through the
Specify Skin property in the Releases view.
SmallProgress
The SmallProgress keyname specifies whether the installation initialization dialog is the small box that was shown by
installations created with InstallShield Professional version 6.31 and earlier, or if it is larger and is consistent with the rest
of the end-user dialogs. Set the value to Y to display the small dialog or N to display the larger dialog. (If the installation
displays a security, Save and/or Run Setup, Choose Setup Language, or Qualifying Product(s) Detected dialog, the
installation initialization dialog is larger and is consistent with the rest of the end-user dialogs, regardless of the value of
this key.) You can set this value in the User Interface panel of the Release Wizard or through the Small initialization dialog
property in the Releases view.
If SmallProgress is set to N, the installation initialization dialog (and the Choose Setup Language dialog, if any) are not
displayed until the startup graphic closes. To specify the length of time for which the startup graphic displays, set the
SplashTime value.
SplashTime
The SplashTime keyname specifies the length of time (in seconds) for which the startup graphic is displayed.
CheckMD5
The CheckMD5 keyname tells the installation whether to compare each file’s MD5 hash value to the value stored in the
installation header file during file extraction. You can set this value with the Verify MD5 signature check box in the General
Options - Advanced dialog box.
Tip • MD5 checking can detect corrupted files, which is useful during Internet installations; not doing MD5 checking can make
file transfer proceed faster.
CmdLine
The CmdLine keyname identifies command-line parameters that are to be passed to Setup.exe if none are passed from the
command line.
Note • If you use the /v parameter at the command prompt when launching Setup.exe, any parameters that are specified
for the CmdLine keyname are ignored.
For more information about available command-line parameters, see Setup.exe and Update.exe Command-Line
Parameters.
LauncherName
If you rename Setup.exe, the LauncherName keyname specifies the file’s new name. This keyname is required if another
installation will launch this installation using the DoInstall function.
If the [Mif] section is present, the installation will automatically create a installation .mif file in the Temp folder. You can
also create an .mif file by using the -m command-line option for Setup.exe and optionally its -m1 and -m2 options.
• Type
• Filename
• SerialNo
• Locale
Type
Set this key to SMS.
Filename
The Filename key is optional. It provides the alternate name for the .mif file to be created. If this key is not included, the
installation tries to use the AppName key under the [Startup] section of Setup.ini as the .mif file name. If the AppName
key is also not present, the installation creates a file with the default name Status.mif.
The file name should not include an extension, since .mif files must have the .mif extension. The file name should not
include a path—it is placed in the Temp folder by default.
SerialNo
The SerialNo key is also optional. If provided, the information from this key is placed in the Serial Number section in the
.mif file. If this key is not present, the installation instead places quotation marks ("").
Locale
The Locale key tells the installation to place the indicated locale in the .mif file. English (ENU) is the default; refer to
Microsoft documentation for a complete listing of locale strings.
The following is an example of a Setup.ini file for an installation that will automatically create an .mif file.
[Startup]
AppName=InstallShield
[Mif]
Type=SMS
Filename=IShield
SerialNo=IS50-32XYZ-12345
Locale=DEU
See Also
Setup.exe and Update.exe Command-Line Parameters
Cloning Releases
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
InstallShield enables you to clone or copy a release in the Releases view. This allows you to create a release with all of its
properties populated as they were in the cloned release. This way, if you want to create more than one release with only a
few differences between them, you can clone a release and change only the settings that you need to change.
2. Right-click the release that you want to copy and click Clone.
A release named Copy of Release x is created. The release copy has all of the same properties as the original release.
Rename the release and modify the release settings that you want to change.
See Also
Working with Releases
Releases View
Important • The Windows 10 Anniversary Update is required for installing and testing a Windows App package (.appx) with
desktop extensions (Desktop Bridge) included. In addition, InstallShield must be installed on a Windows 10 machine or a
machine with the Windows 10 SDK installed in order to: digitally sign the Windows App package, utilize Windows App logo
variants (described in Windows App Logo Considerations, or to build localized Windows App packages.
The Windows App package (.appx/.msix) format is the simple and secure packaging format used to distribute and install
apps on Windows 8.x and 10 and is the only format allowed for Universal Windows Platform apps. Benefits of Windows App
packages include:
• High availability, reliability, and durability, resulting in applications that operate continuously without failure for
extended periods of time
• A smooth installation experience through static builds that require minimal configuration and no customizable UI
• The option to sell or provide the application through the Windows Store
• The ability to leverage UWP functionality such as live tiles as well as the ability to utilize UWP APIs
• The only package format with native support on Windows Nano Server
InstallShield supports creating the Windows App package format and its desktop and server extensions and also provides
testing to help you identify items unsuitable for the Windows App package format. When you select a release in the
Releases view, a per-release tab titled Appx/MSIX includes settings to create a Windows App package. Here, various core
settings can be specified that impact the Windows App package build process.
Windows App packages can be localized using the settings in the Display Properties area on the Appx/MSIX tab. The
supported languages used for the Windows App package build match those in the UI Languages settings on the Build tab
of the release, as long as MakePRI.exe (within the Windows 10 SDK) is found on the build machine. If MakePRI.exe cannot
be found on the build machine, InstallShield will only generate a Windows App package in the default language.
The following instructions provide details on how to create a Windows App package.
Task To convert a Basic MSI project to Windows app package (.appx) format:
1. Open the Basic MSI Project that you want to build a Windows App package for as part of building the .msi release.
2. In the Releases explorer, under the product configuration, click the name of the release for which you want to build a
Windows App package.
3. Click the Appx/MSIX tab and in the Build Windows App Package setting, specify Yes.
5. Do the following:
• Use the General area on the Appx/MSIX tab to specify core settings that impact the build process such as
choosing whether to include desktop extensions or server extensions.
• Use the Package Identity Overrides area on the Appx/MSIX tab to uniquely identify the package to Windows.
• Use the Display Properties area on the Appx/MSIX tab to identify the package to an end user.
For descriptions of these settings, refer to the Appx/MSIX Tab for a Release topic.
6. To configure tiles created in the Windows App package, open the Shortcuts view and configure settings in the
Windows App Package Tile Overrides area. For descriptions of the Windows App Package Tile Overrides settings,
refer to the Shortcut Settings topic.
8. To scan the .msi package for signs of items that are unsuitable for the Windows App package format, run the
InstallShield MSIX/UWP App Suitability Suite. On the Build menu, point to Validation, and then click InstallShield
MSIX/UWP App Suitability Suite. For more information, refer to the InstallShield MSIX/UWP App Suitability Suite
topic.
For information about how to deploy the Windows App package, refer to Deploying Windows App Packages.
See Also
Appx/MSIX Tab for a Release
Shortcut Settings
InstallShield MSIX/UWP App Suitability Suite
Deploying Windows App Packages
Types of Condition Checks in Advanced UI and Suite/Advanced UI Projects
Adding a Sideloading Windows App Package (.appx | .msix) to a Suite/Advanced UI Project
Before distributing your installation, you should test run it to ensure that you discover any issues rather than your
customers. InstallShield enables you to test the end-user dialogs (without copying any files to the target system), run the
entire installation including transferring files.
• Running a Suite Installation with Minimum User Interface from the Command Line
• Basic MSI
• InstallScript MSI
• Merge Module
You can test run an installation to review the end-user dialogs. The test run displays the full user interface, but it does not
copy any files over to the target system or update the registry.
See Also
Specifying Whether Windows Installer Installations Should Be Logged
After you run the Release Wizard and build a release of your installation, you can run it from within InstallShield.
Task To run any of your built installation packages, do one of the following:
• On the Build menu, click Run ReleaseName, where ReleaseName is the name of the release that currently has focus in
the Releases view.
InstallShield runs the release that currently has focus in the Releases view.
If you selected the Uninstall before installing check box in the Options dialog box, the previously run release (if any) is
uninstalled before the current release is run. This option is available on the Preferences tab in the Options dialog box.
You cannot specify any command-line parameters when launching your installation from the InstallShield interface. You
must launch your installation from the command line to pass parameters to the Windows Installer. For more information,
see MsiExec.exe Command-Line Parameters.
Silent installations are installations that run without an end-user interface. If you want your installation to run silently,
InstallShield allows you to create silent installations for Basic MSI, InstallScript MSI, and InstallScript project types.
If your release settings include Setup.exe, you can run the following command:
Setup.exe /s /v"/qn"
Basic MSI installations do not create or read response files. To set installation properties for a Basic MSI project, run a
command line such as:
If you need to install an InstallScript MSI installation without using Setup.exe, you can use the MSI silent mode.
• InstallScript
• InstallScript MSI
InstallShield Silent allows automated electronic software distribution, also known as silent installation. With InstallShield
Silent, there is no need for end users to monitor the installation and provide input through dialogs. An InstallShield Silent
installation runs on its own, without any end-user intervention.
If there are multiple instances of your application on a machine, and if a silent update installation for your application runs
on that machine, it applies the update to the first instance that it finds, and it does not display the Qualifying Product(s)
Detected dialog.
Windows Logo • To comply with Windows logo requirements, a silent installation must create a response file in which the
default installation options are selected.
You can run your installation with the Setup.exe -r parameter to select installation options and automatically record the
InstallShield Silent response file, or you can create your own. To view a real-world example of a response file, refer to the
Setup.iss file located on InstallShield installation’s Disk1. For a description of the response file format, see Creating the
Response File.
If you need to install an InstallScript MSI installation without using Setup.exe, you can use the MSI silent mode.
• InstallScript
• InstallScript MSI
If you want to create an installation that will be run in silent mode, create your installation in a typical manner, and test the
script in the normal (non-silent) manner.
You can easily modify your installation script logic to include flow control based on whether your installation is being run in
silent mode. InstallShield provides a system variable called MODE. The MODE variable contains one of the following constants
to identify the installation’s current mode:
• RECORDMODE—Indicates that the Setup.exe file is automatically generating a silent installation file (.iss file), which
is a record of the installation input, in the Windows folder.
Tip • All InstallShield built-in and Sd dialogs automatically handle the values stored in the InstallShield Silent response file
(.iss file). If you are creating custom dialogs, you will need to call SilentReadData to handle the dialog’s return values in silent
mode.
After you have created or modified the installation, the next step in creating a silent installation is to create the response
file.
• InstallScript
• InstallScript MSI
A normal (non-silent) installation receives the necessary input from end users in the form of responses to dialogs. However,
a silent installation does not prompt the end user for input. A silent installation must get its end-user input from a different
source. That source is the InstallShield Silent response file (.iss file).
A response file contains information similar to that which an end user would enter as responses to dialogs when running a
normal installation. InstallShield Silent reads the necessary input from the response file at run time.
The format of response files resembles that of an .ini file, but response files have .iss extensions. A response file is a plain
text file consisting of sections containing data entries.
There are two ways in which you can create an InstallShield Silent response file: you can run the installation and have
InstallShield record and create the response file for you, or you can write the response file directly.
All InstallShield built-in and Sd dialog functions are designed to write values into the Setup.iss file when InstallShield runs
in record mode (Setup -r). If you are creating custom dialogs, you will need to call SdMakeName and SilentWriteData to
add sections and dialog data to the response file when the installation runs in record mode. Refer to the Sd dialogs’ source
code in the <InstallShield location>\Include folder for examples of using these functions to write to Setup.iss. Read
the following section for more information about what data to add to Setup.iss when calling SdMakeName and
SilentWriteData.
Data entries follow their section names and consist of <name=value> pairs, as in the following example:
Dlg0={23EAFFCA-361D-11D3-8B0F-00105A9846E9}-Welcome-0
A sample response file is included to help familiarize you with the format.
InstallShield 2020
• InstallScript
• InstallScript MSI
All response files begin with a response file silent header. The response file silent header enables InstallShield to identify
the file as a legitimate InstallShield response file. It also helps to verify that the response file corresponds to an installation
created with the proper version of InstallShield.
The format of the silent header is shown below. Enter the following lines at the beginning of your Setup.iss file:
[InstallShield Silent]
Version=v7.00
File=Response File
The Version=v7.00 line indicates the version of the InstallShield Silent response file, not the version of InstallShield. Use
v7.00 in all response files.
When you are creating response files, be sure to use the same version of InstallShield to create the response file that will be
used to run the silent installation.
InstallShield 2020
• InstallScript
• InstallScript MSI
The response file application header is the second block of information in the response file, immediately following the
response file silent header. The response file application header enables you to identify response files visually. It is not
used by the installation script or by Setup.exe. You can use the application header to identify exactly which installation the
response file is for, since it is often difficult to determine this by looking at the dialog data.
The format of the application header is shown below. The values assigned to Name, Version, and Company are derived
from the values written to the registry in the call to the CreateInstallationInfo function in your installation script. (In an
event-based script, CreateInstallationInfo is called in the default OnMoveData event handler code.) Enter the following
lines into your Setup.iss file below the silent header:
[Application]
Name=<ProductKey from CreateInstallationInfo>
Version=<VersionKey from CreateInstallationInfo>
Company=<CompanyKey from CreateInstallationInfo>
InstallShield 2020
• InstallScript
• InstallScript MSI
The third block of information in the response file, after the silent header and the application header, is the response file
dialog sequence. The dialog sequence section lists all dialogs that you would need to use in a normal installation (including
custom dialogs), in the order in which they would appear. The dialogs are listed under the section heading
[<PRODUCT_GUID>-DlgOrder].
The dialog numbering sequence begins at 0. There is no limit to the number of dialogs that you can list.
The order and the number of dialogs is significant. When InstallShield Silent runs, if either the number or the order of the
dialogs does not match the order or the number of the dialogs in the non-silent installation, the silent installation fails and
the log file records the failure. Make one entry for each occurrence of a dialog. A given dialog may be listed more than once
if it appears more than once in the installation.
Dlg<#>=<PRODUCT_GUID>-<DialogIdentifier>
The Dlg<#> part consists of the letters Dlg and a sequence number. The first dialog in the installation is Dlg0. Each dialog
after that increments the value of <#> by one.
<DialogIdentifier> is in the form functionname-<#>, where functionname is the name of the function that created the
dialog, and <#> represents the sequential order of that particular dialog in the installation.
For custom dialogs, you can use any unique alphanumeric name for the functionname portion of <DialogIdentifier>. For
example, you could refer to a custom dialog as MyDialog. If the tenth dialog in the installation were the second occurrence
of the custom dialog MyDialog, there would be an entry in the dialog sequence section such as the following:
Dlg9=<PRODUCT_GUID>-MyDialog-1
The <DialogIdentifier> expression is used to identify the dialog data section for the dialog.
Always end the dialog sequence section with a statement that has the following form:
Count=<number of dialogs>
The statement specifies the exact number of dialogs listed in the dialog sequence section. Count every entry. Since dialog
numbering begins with 0, the value of Count will always be 1 greater than the highest <#> value for a dialog sequence.
The example below lists two dialogs, the Welcome dialog and the AskOptions dialog. Enter your dialog sequence list into
Setup.iss as shown in the example below.
[{23EAFFCA-361D-11D3-8B0F-00105A9846E9}-DlgOrder]
Dlg0={23EAFFCA-361D-11D3-8B0F-00105A9846E9}-Welcome-0
Dlg1={23EAFFCA-361D-11D3-8B0F-00105A9846E9}-AskOptions-0
Count=2
InstallShield 2020
• InstallScript
• InstallScript MSI
The last block of information in a response file is the response file dialog data. The response file dialog data is a collection
of sections containing the values returned by each dialog identified in the dialog sequence section. Each dialog has its own
section. The values listed are the same values that the dialog returns in a normal end-user input-driven installation. You
can also create dialog data sections for custom dialogs.
[<PRODUCT_GUID>-<DialogIdentifier>]
Result=value
Keyname1=value
Keyname2=value
The [<PRODUCT_GUID>-<DialogIdentifier>] section header identifies the specific dialog and is followed by the dialog data
entry list. <DialogIdentifier> is the same expression used to list the dialog in the dialog sequence section.
Data entry items are in the format keyname=value. The keyname is a name for a value returned by a dialog and recorded in
the response file. All dialogs, including custom dialogs, return a value for the keyname Result, reflecting the button that
was clicked to end or exit the dialog. Many dialogs will also set or return a value in a variable.
For example, in a non-silent installation, the AskDestPath dialog returns the destination location in the svDir parameter.
The line in the script might look like the following:
The corresponding dialog data entry in the Setup.iss file for a silent installation might look like the following:
[{23EAFFCA-361D-11D3-8B0F-00105A9846E9}-AskDestPath-0]
Result=1
szPath=C:\Program Files\InstallShield\2020
In the above example, Result=1 is equivalent to clicking the Next button in the dialog, and szPath=C:\Program
Files\InstallShield\2020 is the value returned in the svDir parameter of AskDestPath.
The name of the variable used in the script is meaningless relative to the Setup.iss file. However, in the Setup.iss dialog
data sections, each built-in and Sd dialog has its own set of keynames that map to its parameters. The keynames are
important and must be exactly as defined for each dialog. Refer to Dialog Data Keynames List, below.
When you use custom dialogs, you must create a dialog data entry for the Result keyname for each dialog, plus entries for
any other values set or returned by the custom dialogs. Use the Dialog Data Keynames List, below, as an indicator of how to
create keyname=value expressions for your custom dialogs. Call GetProfString or GetProfInt to read the dialog data
information for the custom dialog. GetProfString and GetProfInt allow you to specify the .iss file, the section, and the
keyname, and they return the value assigned to that keyname.
Every set of component selections and every set of subcomponent selections has one type keyname entry, one count
keyname entry, and as many <#> keyname entries as are required to document each individual component or
subcomponent selection.
When you are creating keynames to record component selections, precede the type, count, and <#> keyname entries with
the word Component, thus:
Component-typeComponent-countComponent-0
When you are creating keynames to record subcomponent selections, precede the type, count, and <#> keyname entries
with the name of the component to which the subcomponents belong, thus:
To create complete value entries, use the equal sign to attach the values to the keynames. (The types of values assigned to
each kind of keyname are described below.) The following example shows complete value entries for two components,
Program Files and Binary Files, and two subcomponents of Program Files, Executables and Support Elements:
Component-type=string
Component-count=2
Component-0=Program Files
Component-1=Binary Files
Program Files-type=string
Program Files-count=2
Program Files-0=Executables
Program Files-1=Support Elements
The type keyname indicates the data type of the components or subcomponents list. Since InstallShield dialogs currently
use only string lists for components and subcomponents lists, type is always equal to string, as in Component-
type=string. Future versions may use number lists, in which case type could equal number.
The value assigned to a <#> keyname entry is the selected component’s or subcomponent’s visible name (the string passed
as the second parameter to ComponentAddItem when the components or subcomponents list was built).
For example, assume the ComponentDialog dialog offers end users a component selection of Program Files, Help Files,
Sample Files, and Utilities. If the end user selects Program Files and Help Files, then the dialog data section for that
instance of the ComponentDialog dialog will have two list item entries and will look something like this:
[{23EAFFCA-361D-11D3-8B0F-00105A9846E9}-ComponentDialog-0]
szDir=C:\MYAPP\FILES
Component-type=string
Component-count=2
Component-0=Program Files
Component-1=Help Files
Result=
The following example shows how subcomponent list selections are recorded. The example is for an instance of the
SdComponentMult dialog. The example shows that two components—Program Files and Help Files—were selected. It
also shows that four subcomponents were chosen: Main Files, Aux. Files, Main Help, and Tutorial Files. Main Files and
Aux. Files are subcomponents of Program Files, and Main Help and Tutorial Files subcomponents of Help Files.
[{23EAFFCA-361D-11D3-8B0F-00105A9846E9}-SdComponentMult-0]
Component-type=string
Component-count=2
Component-0=Program Files
Component-1=Help Files
Program Files-type=string
Program Files-count=2
Program Files-0=Main Files
Program Files-1=Aux. Files
Help Files-type=string
Help Files-count=2
Help Files-0=Main Help
Help Files-1=Tutorial Files
Result=1
AskPath-<#> szPath The path entered in the Destination Directory edit field
ComponentDialog-<#> Component- The selected item’s number in the list (numbering begins with 0)
<#>
RebootDialog-<#> Choice Indicates the final reboot selection made before restarting the
machine. Maps to the radio buttons and has these possible values:
SdAskOptions-<#> Component- The selected item’s number in the list (numbering begins with 0)
<#>
SdAskOptionsList-<#> Component- The selected item’s number in the list (numbering begins with 0)
<#>
SdComponentDialog-<#> Component- The selected item’s number in the list (numbering begins with 0)
<#>
SdComponentDialog2-<#> Component- The selected item’s number in the list (numbering begins with 0)
<#>,
<subcompone
nt>-<#>
SdComponentDialogAdv-<#> Component- The selected item’s number in the list (numbering begins with 0)
<#>
SdComponentMult-<#> Component- The selected item’s number in the list (numbering begins with 0)
number,
<subcompone
nt>-<#>
2 = Restart Windows
SdSelectFolder-<#> szFolder The folder name entered in the Program Folder field
SdSetupType-<#> szDir The path entered in the Destination Directory edit field
SdShowFileMods-<#> nSelection The “Choose what you want Setup to do” radio button selection:
SdWelcomeMaint-<#> Result 301 = Indicates that the Modify button was selected when the Next
button was clicked.
302 = Indicates that the Repair button was selected when the Next
button was clicked.
303 = Indicates that the Remove button was selected when the
Next button was clicked.
See Also
Understanding When an Installation or Uninstallation Restarts the Target System
InstallShield 2020
• InstallScript
• InstallScript MSI
The following response file is the .iss file for a silent InstallShield installation.
[InstallShield Silent]
Version=v7.00
File=Response File
[Application]
Name=InstallShield
Version=10.50.000
Company=My Software Company
[{77AB941D-5876-11D4-A4A2-006067620F66}-DlgOrder]
Dlg0={77AB941D-5876-11D4-A4A2-006067620F66}-SdBitmap-0
Count=8
Dlg1={77AB941D-5876-11D4-A4A2-006067620F66}-Welcome-0
Dlg2={77AB941D-5876-11D4-A4A2-006067620F66}-SdRegisterUser-0
Dlg3={77AB941D-5876-11D4-A4A2-006067620F66}-AskDestPath-0
Dlg4={77AB941D-5876-11D4-A4A2-006067620F66}-SetupType-0
Dlg5={77AB941D-5876-11D4-A4A2-006067620F66}-SelectFolder-0
Dlg6={77AB941D-5876-11D4-A4A2-006067620F66}-SdStartCopy-0
Dlg7={77AB941D-5876-11D4-A4A2-006067620F66}-SdFinish-0
[{77AB941D-5876-11D4-A4A2-006067620F66}-SdBitmap-0]
Result=1
[{77AB941D-5876-11D4-A4A2-006067620F66}-Welcome-0]
Result=1
[{77AB941D-5876-11D4-A4A2-006067620F66}-SdRegisterUser-0]
szName=John Doe
szCompany=My Software Company
Result=1
[{77AB941D-5876-11D4-A4A2-006067620F66}-AskDestPath-0]
szPath=C:\Program Files\Product Name Version
Result=1
[{77AB941D-5876-11D4-A4A2-006067620F66}-SetupType-0]
Result=301
szDir=C:\Program Files\Product Name Version
[{77AB941D-5876-11D4-A4A2-006067620F66}-SelectFolder-0]
szResultFolder=Product Name Version
Result=1
[{77AB941D-5876-11D4-A4A2-006067620F66}-SdStartCopy-0]
Result=1
[{77AB941D-5876-11D4-A4A2-006067620F66}-SdFinish-0]
Result=1
bOpt1=1
bOpt2=0
• InstallScript
• InstallScript MSI
After you have created the installation and the response file, do the following:
1. Add the response file (which is located in your Windows folder by default) to the Disk1 folder under Advanced Files in
the Support Files/Billboards view.
2. Build your release. If you are creating a self-extracting executable file for your installation, enter -s for the Setup
Command Line property in the General Options panel of the Release Wizard or for the Setup Command Line property
in the Releases view.
Now you are ready to run the installation in silent mode using InstallShield Silent. When running an installation in silent
mode, be aware that no messages are displayed. Instead, a log file named Setup.log captures installation information,
including whether the installation was successful. You can review the log file and determine the result of the installation.
(Note that for certain installation initialization errors, the log file may instead be named Setupexe.log and be created in
SUPPORTDIR if the installation is run from the Internet or in SRCDIR otherwise.)
To launch InstallShield Silent, run Setup.exe with the -s option. If you created a self-extracting executable file, simply
launch it; you included the -s option in step 2 above.
InstallShield also provides the -f1 and -f2 switches so that you can specify the name and location of the response file and
the location of the log file. For more information, see Setup.exe and Update.exe Command-Line Parameters.
To verify if a silent installation succeeded, look at the ResultCode value in the [ResponseResult] section of Setup.log.
InstallShield writes an appropriate return value after the ResultCode keyname.
See Also
Adding Files and Folders to the Disk1 Folder
• InstallScript
• InstallScript MSI
Setup.log is the default name for the silent installation log file—generated when the end user runs Setup.exe with the /s
argument—and it is by default created in the directory containing the response file Setup.iss. You can specify a different
name and location for Setup.log using the /f1 and /f2 switches to Setup.exe.
The Setup.log file contains three sections. The first section, [InstallShield Silent], identifies the version of InstallShield
Silent used in the silent installation. It also identifies the file as a log file.
The second section, [Application], identifies the installed application’s name and version, and the company name.
The third section, [ResponseResult], contains the result code indicating whether the silent installation succeeded. An
integer value is assigned to the ResultCode keyname in the [ResponseResult] section. The installation places one of the
following return values in the ResultCode key.
Project • Note that in an InstallScript MSI installation, there is no initialization process for reading or writing response files. As
a result, the only errors that may occur for InstallScript MSI installation are -3 for silent installations and -6 for recording
installations. Thus, the following table shows applicable project types where appropriate.
0 InstallScript, Success.
InstallScript MSI
[Application]
Name=Sample App 3000
Version=1.00.0000
Company=Sample Software Corporation
Lang=0409
[ResponseResult]
ResultCode=0
If you need to silently install an InstallScript MSI project without using Setup.exe, you can use the MSI silent mode.
Unlike the traditional silent mode, the MSI silent mode does not follow the regular logic provided through script. It simply
runs through the InstallExecuteSequence table. (To see this table, navigate to the Direct Editor.) As a result, some events
are not called, including the following:
You need to override the OnMsiSilentInstall event if you want to support the MSI silent installation mode. This allows you to
perform tasks that are normally performed in the OnFirstUIBefore, OnFirstUIAfter, and feature event handlers.
The simplest thing that you can do is to implement an empty body of this event so that the installation will not abort. For
example:
function OnMsiSilentInstall(hInstall)
begin
//Do nothing and allow installation to continue.
end;
Again, OnMsiSilentInstall will be called on MSI silent installation and on activation of an advertised shortcut. It will not be
called on Install-On-Demand, auto-repair, and uninstall mode.
if (MODE = SILENTMODE)
To detect whether an MSI silent mode installation (including /q, advertise, auto-repair, uninstall, or install-on-demand) is
running from InstallShield script, check the Windows Installer property ISSETUP_UISEQUENCE_PROCESSED using the
MsiGetProperty Windows Installer API function. If this property is not set, then it is a silent install. (It indicates that the
InstallUISequence is not executed.)
See Also
Windows Installer API Functions
To initiate a silent uninstallation for a product that was installed through an InstallScript MSI installation, use a response
file.
1. Prepare a response file for the uninstallation (.iss) by running Setup.exe with the /r argument:
Setup.exe /r
2. Type the following at the command line (items in Italics represent data that is specific to your product’s
uninstallation):
Setup.exe /s /f1"FullPath\YourResponseFile.iss"
• Advanced UI
• Suite/Advanced UI
You can use a command line parameter to run a suite installation in minimum UI mode, only displaying a progress panel.
To run a suite installation in minimum UI mode, use the /passive parameter in the command line:
Setup.exe /passive
Validating Projects
InstallShield 2020
Validating a project involves applying a set of internal consistency evaluator (ICE) rules to your installation or merge
module package. The ICEs are designed to help you determine whether the package contains a valid database that
performs its actions correctly. If a package fails one or more ICEs, InstallShield reports the specific ICE rules that were
violated and offers additional information to help you troubleshoot the problem.
Microsoft created many of the ICEs that are available in InstallShield; Revenera created the custom InstallShield ICEs
(ISICEs) that are available for the some of the InstallShield installation and merge module validation suites. The ISICEs help
you validate your package against best practices for Windows-based installations.
Windows Logo • Validating your project may help you identify whether your installation meets installation requirements for
Microsoft’s Windows logo program. Therefore, if you are interested in being able to use the Windows logo, it is recommended
that you use the InstallShield Validation Suite for Windows 8 and the Full MSI Validation Suite to validate your installation
package. If you create a merge module in InstallShield, use the InstallShield Merge Module Validation Suite for Windows 8
and the Merge Module Validation Suite to validate your merge module. For more details, see Requirements for the Windows
Logo Program.
Edition • The Premier Edition of InstallShield includes the following sets of validation suites:
The InstallShield Premier Edition also includes the following sets of validators:
• InstallShield Virtualization Suitability Suite—ISVICEs validators in this suite help you to determine how ready your
products are for virtualization by checking suitability for Microsoft App-V 4.x, Microsoft App-V 5.x, Microsoft Server App-V,
VMware ThinApp, and Citrix XenApp. The validation suites can enable you to make more informed decisions about how
you would build your product if you are considering offering your customers a virtualized version.
• InstallShield Best Practice Suite—ISBP validators in this suite alert you if your installation violates best-practice
guidelines.
• InstallShield MSIX/UWP App Suitability Suite—ISUWP validators in this suite scan an .msi package for signs of items
that are unsuitable for the Windows App package format and provides a report that indicates applicability to the known
Windows App variants (Universal App, Desktop Bridge, Windows Store, WSA, and Nano Server).
InstallShield also provides an engine for upgrade and patching validation. You can access this through the Upgrade
Validation Wizard.
See Also
ICEs
ISICEs
InstallShield Best Practice Suite
InstallShield Virtualization Suitability Suite
InstallShield MSIX/UWP App Suitability Suite
Validating Upgrades, Patches, and QuickPatch Packages
Upgrade Validation Wizard
There are two ways to validate an installation package or a merge module from within InstallShield:
• You can configure InstallShield to validate the installation package or merge module every time that you build a
release. This is disabled by default. For more information, see Specifying Whether Validation Should Be Performed at
Build Time.
If you perform validation at build time, you can specify multiple validation suites.
• You can run validation on demand for a built release. To learn how, see Validating an Installation Package or Merge
Module on Demand.
If you perform validation on demand, you can specify only one validation suite at a time.
Tip • As an alternative, you can validate the installation package or merge module after you build it from the command line
by using ISCmdBld.exe. For more information, see ISCmdBld.exe.
Project • The only way to validate a package for an MSI Database project or an MSM Database project is to perform validation
on demand.
Note • If you want to see validation warnings that apply to your installation or merge module, you must perform validation
on demand; this type of validation message is not available if you perform validation at build time. InstallShield reports the
other types of validation messages—errors and failures—during both validation methods. To learn more about the different
types of validation messages, see Viewing Validation Results.
See Also
Requirements for the Windows Logo Program
InstallShield enables you to specify whether installation packages and merge modules should be validated each time that
a release is successfully built. InstallShield also lets you specify one or more validation suites that should be used for
validation.
1. On the Tools menu, click Options. The Options dialog box opens.
3. Select the check boxes for the types of validation that you would like InstallShield to perform at build time. If you
prefer to validate on demand, and not at build time, clear the check boxes.
4. If you select the Perform validation using check box or the Perform Merge Module validation using check box,
select one or more types of validation that should be performed.
To add a new or custom validator (.cub file), click the Browse button and select it.
Note • If you want to see validation warnings that apply to your installation or merge module, you must perform validation
on demand; this type of validation message is not available if you perform validation at build time. InstallShield reports the
other types of validation messages—errors and failures—during both validation methods.
See Also
Validating an Installation Package or Merge Module on Demand
Requirements for the Windows Logo Program
Specifying Which ICEs, ISICEs, ISVICEs and ISBPs Should Be Run During
Validation
InstallShield 2020
InstallShield lets you customize the list of ICEs, ISICEs, ISVICEs, ISUWPs, and ISBPs that should be used for installation
package validation and merge module validation.
Task To specify which ICEs, ISICEs, ISVICEs, ISUWPs, and ISBPs should be run during validation:
1. On the Tools menu, click Options. The Options dialog box opens.
3. Click the Customize button. The Customize Validation Settings dialog box opens.
4. In the Select CUB file to customize list, click the suite that you want to customize.
5. In the list of ICEs, select the check box for each of the validators that should be used to evaluate the installation
package or merge module. Clear the check box for each of the validators that should not be used for the validation.
To configure multiple consecutive validators, select the first file, press and hold SHIFT, and select the last file. Then
either select or clear the check box of one of the selected validators.
6. Click OK.
If you customize the list of ICEs, ISICEs, ISVICEs, ISUWPs, and ISBPs for a validation suite, anytime that validation is
performed—whether it occurs at build time or on demand—only the selected ICEs, ISICEs, ISVICEs, ISUWPs, and ISBPs are
used.
See Also
Requirements for the Windows Logo Program
InstallShield enables you to validate an installation package or merge module separately from the build process. Doing so
is especially helpful if you configured InstallShield so that validation is not performed as part of every successful build, but
you do need to run it at some point to test your product for Windows logo compliance or for best-practice compliance.
2. On the Build menu, point to Validate, and then click the validation type that you want to run.
See Also
Requirements for the Windows Logo Program
InstallShield displays the results of the validation scan on the Validations tab of the Output window. In addition,
InstallShield saves the results to an XML document in a ValidationFiles folder within the release folder. You can view this
file either by navigating to your build directory, or by navigating to the Releases view and selecting the Validations folder
under your release.
Validation Messages
Validation messages are broken down into three categories:
• Errors—Describe problems with your database, such as having duplicate component GUIDs.
• Failures—Occur when your database has severe enough problems that the validation tool might not be able to run.
If the scan results for your project include validation messages, the messages and associated codes are also listed on the
Tasks tab of the Output window.
Note • If you want to see validation warnings that apply to your installation or merge module, you must perform validation
on demand; this type of validation message is not available if you perform validation at build time. InstallShield reports the
other types of validation messages—errors and failures—during both validation methods. To learn more about these two
validation methods, see Validating an Installation Package or Merge Module.
Tip • You can click a validation code on the Tasks tab of the Output window to see the corresponding Knowledge Base article
or HelpNet topic.
In addition, you can click a validation message on the Tasks tab to jump to the area of the Direct Editor that corresponds to the
validation message. This functionality is available for: ICEs, ISICEs, ISVICEs, ISUWPs, and ISBPs.
ICEs
InstallShield 2020
The validation tool checks your project for compliance with each of the internal consistency evaluators, or ICEs. These ICEs
are those used by Msival2.exe (part of the Microsoft Windows Installer Platform SDK) to validate installation and merge
module packages for Windows logo compliance.
If your installation project or merge module project fails one or more of these ICEs, InstallShield reports the specific ICE
rules that were violated and offers additional information to help you troubleshoot the problem.
To learn about specific ICEs, see ICE Reference in the Windows Installer Help Library.
See Also
Requirements for the Windows Logo Program
ISICEs
InstallShield 2020
The InstallShield validation suites consist of a number of InstallShield ICEs (ISICEs) that help you check your project for
compliance with installation requirements of the Windows logo program.
The following table lists the ISICEs that are available in InstallShield.
ISICE01 Basic MSI, Validates that the application is installed to ProgramFiles or the user’s
InstallScript MSI, AppData folder by default.
MSI Database
ISICE02 Basic MSI, Validates that all executable files included with the installation or merge
InstallScript MSI, module are digitally signed.
Merge Module,
MSI Database
ISICE03 Basic MSI, Validates that there are no nested-installation custom actions (type 7, 23,
InstallScript MSI, and 39).
Merge Module,
MSI Database
ISICE04 Basic MSI, Validates that there are no custom columns added to standard .msi tables.
InstallScript MSI,
Merge Module,
MSI Database
ISICE05 Basic MSI, Validates that there are no properties or custom tables that begin with MSI
InstallScript MSI, (case-insensitive).
Merge Module,
MSI Database
ISICE06 Basic MSI, Validates that the installation does not include any files protected by
InstallScript MSI, Windows Resource Protection.
Merge Module,
MSI Database
ISICE07 Basic MSI, Validates that MSI components are authored for proper installation and
InstallScript MSI, uninstallation.
Merge Module,
MSI Database
ISICE08 Basic MSI, Validates that deferred custom actions do not have the impersonate bit set.
InstallScript MSI,
Merge Module,
MSI Database
ISICE09 Basic MSI, Validates that the installation includes an MsiPatchCertificate table entry.
InstallScript MSI,
MSI Database
ISICE10 Basic MSI, Validates that each custom action has a path specified for the Help File Path
InstallScript MSI, setting in the Custom Actions view.
Merge Module,
MSI Database
ISICE11 Basic MSI, Validates that .exe files have embedded manifests with required information.
InstallScript MSI,
Merge Module,
MSI Database
ISICE12 Basic MSI, Validates that no protected registry keys are modified.
InstallScript MSI,
Merge Module,
MSI Database
ISICE13 Basic MSI, Validates that no .hlp files or WinHelp run-time files are included in the
InstallScript MSI, installation. This ICE is now ISBP17.
Merge Module,
MSI Database
ISICE14 Basic MSI, Validates that no obsolete APIs are imported. This ICE is now ISBP18.
InstallScript MSI,
Merge Module,
MSI Database
ISICE15 Basic MSI, Validates that no deprecated APIs are imported. This ICE is now ISBP19.
InstallScript MSI,
Merge Module,
MSI Database
ISICE16 Basic MSI, Validates that no 16-bit components are distributed in an installation that
InstallScript MSI, targets 64-bit systems.
Merge Module,
MSI Database
ISICE17 Basic MSI, Validates that the installation or merge module does not force a reboot.
InstallScript MSI,
Merge Module,
MSI Database
ISICE19 Basic MSI, Validates properties related to upgrades, that the Upgrade table is present,
InstallScript MSI, and that the installation prevents downgrades.
MSI Database
ISICE20 Basic MSI, Validates that no machine-wide settings are installed by a non-privileged
InstallScript MSI, installation.
MSI Database
ISICE21 Basic MSI, Validates that the app does not depend on the VB6 runtime.
InstallScript MSI,
MSI Database
ISICE22 Basic MSI, Validates that the app does not start automatically on system startup.
InstallScript MSI,
MSI Database
ISICE23 Basic MSI, Validates that the app sets strong and appropriate ACLs.
InstallScript MSI,
MSI Database
ISICE24 Basic MSI, Validates that the installation does not install 16-bit components.
InstallScript MSI,
MSI Database
ISICE25 Basic MSI, Validates that the installation does not install any files to the Windows
InstallScript MSI, directory or its subdirectories.
MSI Database
ISICE26 Basic MSI, Validates that applications support Windows security features by controlling
InstallScript MSI, permissions appropriately.
MSI Database
Tip • In some cases, the following validation error message may be displayed for an ISICE:
File [1] in Component [2] could not be found. All tests against this file's contents may be invalid.
This error occurs if the specified file is missing, and the associated ISICE could not be verified for the file. For example, if an
executable file is missing, ISICE11 cannot verify whether the file has an embedded manifest.
If the aforementioned validation error message is displayed, resolve the missing file issue, and then rerun validation for your
project.
See Also
Viewing Validation Results
ISICE01
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
The application should be installed to either ProgramFiles or AppData folder by default. The current
default location is [1].
Description
Users should be able to install products where they need them, and they should have a consistent experience with where
files are stored by default.
ISICE01 verifies that the default destination location for your product is the Program Files folder or the Application Data
folder. If a different location is used, this error message is displayed during validation.
Corrective Action
Change the default location. For more information, see Setting the Default Product Destination Folder (INSTALLDIR).
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE02
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Message (Error)
File [1] in Component [2] is not digitally signed. All [3] files distributed to Windows Vista and later
are required to be signed.
[1] is the name of an executable file, [2] is the name of the component that contains that file, and [3] is the type of file that
must be signed.
Description
ISICE02 verifies that all executable files in your installation have been digitally signed. This includes files with the following
extensions: exe, dll, ocx, sys, cpl, drv, and scr. If an executable file in your installation has not been digitally signed, this
error message is displayed during validation.
Corrective Action
Ensure that all executable files in your installation have been digitally signed. For more information, see Digital Signing and
Security.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE03
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Message (Error)
Nested custom action [1] of type [2] is not allowed.
[1] is the name of a custom action in your project, and [2] is the Windows Installer type number of custom action.
Description
ISICE03 verifies that your installation does not include any nested-installation custom actions. Nested installations is a
deprecated feature of the Windows Installer. Applications installed with nested installations sometimes fail because they
are difficult for end users to service correctly. Microsoft Corporation recommends that you avoid using nested installations
and nested-installation custom actions to install products that are intended to be released to the public.
To learn more, see Concurrent Installations in the Windows Installer help library.
Corrective Action
To resolve this error, remove the nested-installation custom action from your project. The MSI Type Number value in the
Custom Actions and Sequences view (in Basic MSI, InstallScript MSI, MSI Database, and Transform projects) or the Custom
Actions view (in Merge Module and MSM Database projects) for nested-installation custom actions is 7, 23, or 39.
As an alternative to using a nested installation, you may want to create a create an InstallShield prerequisite, and then add
that InstallShield prerequisite to your installation project. For more information, see Defining InstallShield Prerequisites.
See Also
Working with InstallShield Prerequisites that Are Included in Installation Projects
Summary List of All Custom Action Types (Windows Installer Help Library)
Summary List of All Custom Action Types (Windows Installer Help Library)
Requirements for the Windows Logo Program
ISICEs
ISICE04
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Message (Error)
The standard MSI table [1] does not match the MSI schema defined in schema.msi.
Description
ISICE04 verifies that your installation does not add custom table columns to standard tables. Adding columns to standard
tables is reserved for future versions of Windows Installer.
Corrective Action
To resolve this error, remove any custom table columns that were added to the table that is mentioned in the error
message. You can do this by exporting the table from the Direct Editor, editing the table in a text editor, and importing the
revised table.
See Also
Database Tables (Windows Installer Help Library)
Database Tables (Windows Installer Help Library)
Requirements for the Windows Logo Program
ISICEs
ISICE05
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Messages
Message 1 (Error)
MSI property [1] begins with reserved characters. MSI property names cannot start with "MSI" (case-
insensitive).
Message 2 (Error)
Table [1] begins with reserved characters. Custom table names cannot start with "MSI" (case-
insensitive).
Description
ISICE05 verifies that your installation does not include any custom properties or custom tables whose names begin with
MSI in any combination of uppercase and lowercase letters. The MSI prefix is reserved for future use in new standard
properties and tables.
Corrective Action
To resolve the property-related error, use the Property Manager to rename the custom property that is mentioned in the
error message.
To resolve the table-related error, use the Direct Editor to export the table, use a text editor to edit the table name in the
exported .idt file, and use the Direct Editor to import the newly renamed table into the Direct Editor. Then delete the
original custom table.
See Also
Naming Custom Tables, Properties, and Actions (Windows Installer Help Library)
Naming Custom Tables, Properties, and Actions (Windows Installer Help Library)
Exporting Tables from the Direct Editor
Importing Tables with the Direct Editor
Removing Tables Through the Direct Editor
Requirements for the Windows Logo Program
ISICEs
ISICE06
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Messages
Message 1 (Error)
File [1] in Component [2] is a Windows Protected File. Protected files may not be distributed to Windows
Vista and later.
[1] is the name of a file in your project, and [2] is the name of the component that contains that file.
Message 2 (Warning)
File [1] in Component [2] has the same file name as a Windows Protected File, but appears to be
distributed to a different path.
[1] is the name of a file in your project, and [2] is the name of the component that contains that file.
Description
ISICE06 verifies that your installation does not install files that are protected by Windows Resource Protection (WRP). WRP
is designed to ensure that protected system resources are updated on Windows Vista and later machines only through
Microsoft-approved installation or update mechanisms.
If your installation installs a file that has the same name as a Windows Protected File, but the file is not installed to the
same location as the Windows Protected File, warning message 2 is displayed.
Corrective Action
To resolve the validation error, remove the file that is mentioned in the error message from your project.
If you encounter the validation warning, determine if the file that is mentioned in the message is a protected file:
• If the file is not a protected file but it has the same name as a protected file, you can ignore this warning.
• If the file is a protected file, remove it from your project to resolve this warning.
If your product requires newer versions of system components, the components must be updated on target machines by
using a Microsoft service pack or a Microsoft-approved installation package that contains the system component. System
components should not be repackaged.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE07
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Messages
Message 1 (Error)
Component.ComponentId for Component [1] is null. All components must have a valid ComponentId for proper
installation and uninstallation. If this is left null, justification must be documented.
[1] is the name of a component in your project that does not have a GUID specified in the Component Code setting in the
Components view.
Message 2 (Error)
Component [1] contains COM data, but it has more than 1 file. Each COM component should contain only 1
COM file.
[1] is the name of a component in your project that contains more than one COM server.
Message 3 (Error)
Component [1] has more than one file as the target of a Desktop or Start Menu shortcut.
[1] is the name of a component in your project that has more than one file specified as the target of a shortcut.
Message 4 (Error)
Component [1] is associated with multiple features and is referenced in the following tables: [2]. These
references require the component to be associated with exactly 1 feature.
[1] is the name of a component in your project that is associated with more than one feature and that has references in any
of the following tables: Class, Extension, MsiAssembly, PublishComponent, TypeLib. [2] is a comma-delimited list of
tables that contain references to the component.
Description
ISICE07 verifies that the components in your installation adhere to component rules, which help to ensure that the
installation or uninstallation of one product does not harm any other product on a target system. These rules also help to
ensure that Windows Installer correctly removes all resources that are connected with a product that is being uninstalled.
Corrective Action
To resolve error 1, open the Components view, select the component that is mentioned in the error message, and click the
Component Code setting. In the help pane that is displayed in the lower-right pane, click Generate GUID. If you have a valid
reason for leaving the Component Code setting blank, you can document it in the application that you submit for the
Windows logo program.
To resolve error 2, move any COM servers to separate components so that each COM server is the key path of its
component.
To resolve error 3, use the Shortcuts view to delete all but one of the shortcuts that are associated with the component
mentioned in the error message.
To resolve error 4, use the Setup Design view or the Features view to remove the component from all but one feature.
See Also
Component Settings
Setting Key Paths for Components
Creating Shortcuts and Program Folders
Requirements for the Windows Logo Program
ISICEs
ISICE08
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Message (Error)
Custom Action [1] uses impersonation. Impersonation should not be used when running setups on Windows
Vista or later.
Description
ISICE08 verifies that your installation does not contain any custom actions that use impersonation. If you select one of the
Terminal Server Aware options for the type of in-script execution setting (in the Custom Actions and Sequences view, in the
Custom Actions view, or on the Respond Options panel of the Custom Action Wizard), the custom action impersonates the
end user during per-machine installations on terminal server machines.
Corrective Action
To resolve this validation error, open the Custom Actions and Sequences view (or the Custom Actions view) and click the
custom action that is mentioned in the error message. Change the value of the In-Script Execution setting to one of the
options that does not include Terminal Server Aware.
See Also
In-Script Execution
Requirements for the Windows Logo Program
ISICEs
Custom Actions and Sequences View (or Custom Actions View)
Custom Action Types
ISICE09
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
An MsiPatchCertificate table entry is required for User Account Control (UAC) patching.
Description
ISICE09 verifies that your installation includes an MsiPatchCertificate table entry. In a base installation, this table
provides the signer certificate that will be used to verify the digital signature of subsequent patches when they are applied
by a non-administrator or an administrator who is not using elevated privileges.
Corrective Action
To resolve this validation error, add the MsiPatchCertificate table to your project. To learn how, see Preparing
Installations for Non-Administrator Patches.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE10
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Message (Error)
Custom action [1] of type [2] is not documented in table [3].
[1] is the name of a custom action in your project, and [2] is its Windows Installer type number. [3] is the name of the table
that is missing an entry for the custom action that is listed.
Description
The intended behavior of each custom action must be documented for the Windows logo program. This is especially
helpful if system administrators deploy your product to enterprise environments; they sometimes need to know what the
custom actions do.
ISICE10 verifies that each custom action in your installation is documented by validating that each entry in the
CustomAction table has a corresponding ISCustomActionReference table entry.
Corrective Action
To resolve this validation error, open the Custom Actions and Sequences view (or the Custom Actions view), select the
custom action that is mentioned in the error message, and use the Help File Path setting to specify a path to the document
that describes the behavior of the custom action. When you specify a value in the Help File Path setting, InstallShield adds
a row for that custom action in the ISCustomActionReference table if one has not already been created.
In addition, configure the product configuration for the release so that InstallShield streams the contents of each of the
custom action help files into the .msi file at build time. For more information, see the description of the Include Custom
Action Help setting on the General tab for a product configuration in the Releases view.
Note that if the custom action is a merge module that is consumed in your installation project, specify the path in the
Custom Actions view of the merge module project and then rebuild the merge module.
See Also
ISCustomActionReference Table
Documenting the Behavior of Custom Actions
Guidelines for Creating Custom Actions that Meet Requirements of the Windows Logo Program
Requirements for the Windows Logo Program
ISICEs
ISICE11
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Messages
Message 1 (Error)
Exe [1] in component [2] lacks a manifest.
[1] is the name of an executable file in your project that does not have a manifest, and [2] is the name of the component
that contains the executable file.
Message 2 (Error)
Exe [1] in component [2] lacks a requestedExecutionLevel level setting in its manifest.
[1] is the name of an executable file in your project that has a manifest that was possibly created for Windows XP but that
was not updated for Windows Vista and later. The manifest does not define the execution level for the executable file. [2] is
the name of the component that contains the executable file.
Message 3 (Error)
Exe [1] in component [2] lacks a requestedExecutionLevel uiAccess setting in its manifest.
[1] is the name of an executable file in your project that has a manifest that was possibly created for Windows XP but that
was not updated for Windows Vista and later. The manifest does not define the UI accessibility value for the executable file.
[2] is the name of the component that contains the executable file.
Message 4 (Warning)
Exe [1] in component [2] is marked to require elevated privileges (highestAvailable) which requires a
waiver from Microsoft.
[1] is the name of an executable file in your project that has a manifest that specifies that elevated privileges are required,
and [2] is the name of the component that contains the executable file.
Message 5 (Warning)
Exe [1] in component [2] is marked to require elevated privileges (requireAdministrator) which requires
a waiver from Microsoft.
[1] is the name of an executable file in your project that has a manifest that specifies that elevated privileges are required,
and [2] is the name of the component that contains the executable file.
Message 6 (Warning)
Exe [1] in component [2] is marked to require uiAccess which requires a waiver from Microsoft.
[1] is the name of an executable file in your project that has a manifest that specifies that the executable file is allowed to
bypass UI protection levels in order to use higher privileges to pass information to other windows on the desktop; that is,
the value of uiAccess is set to true. [2] is the name of the component that contains the executable file.
Description
ISICE11 verifies that every .exe file in your installation has an embedded manifest that defines its execution level. The
execution level is defined in the manifest as follows:
<requestedExecutionLevel
level="asInvoker"
uiAccess="false"/>
Other valid values for the level attribute are highestAvailable and requireAdministrator. Note that if you set the level value
to highestAvailable or requireAdministrator, you must apply for a waiver from Microsoft to obtain Windows logo
certification.
The uiAccess attribute indicates whether the executable file is allowed to bypass UI protection levels in order to use higher
privileges for passing information to other windows on the desktop, such as on-screen keyboards. This attribute should be
set to true only for UI accessibility applications. Note that if you set the UI accessibility value to true, you must apply for a
waiver from Microsoft to obtain Windows logo certification.
Corrective Action
To resolve the validation errors (messages 1 through 3), replace the executable file in your installation with one that has an
embedded manifest whose level and uiAccess values are set appropriately.
The validation warnings (messages 4 through 6) are displayed to inform you that if you want to have your product qualify
for the Windows logo program but you keep the requestedExecutionLevel element as it is currently defined in the
executable file’s manifest, you may need to obtain a waiver from Microsoft.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE12
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Message (Error)
Registry key [1] in Component [2] is a protected registry key. Protected registry keys may not be
modified on Windows Vista and later.
[1] is a registry key that only the Trusted Installer group can modify on Windows Vista or later systems, and [2] is the name
of the component that contains that registry key.
Description
ISICE12 verifies that the installation does not attempt to modify registry keys that are protected by Windows Resource
Protection (WRP) on Windows Vista and later systems. Registry keys that can be modified by only the Trusted Installer
group are protected by WRP.
Corrective Action
To resolve this validation error, use the Registry view to remove the protected registry key from your project, or move it to
a part of the registry that is not protected by WRP.
See Also
Using Windows Installer and Windows Resource Protection (Windows Installer Help Library)
Using Windows Installer and Windows Resource Protection (Windows Installer Help Library)
Requirements for the Windows Logo Program
ISICEs
ISICE16
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Message (Error)
File [1] in Component [2] is a 16-bit file. Installations that target 64-bit systems may not include 16-
bit files.
[1] is the name of a 16-bit file in your project, and [2] is the name of the component that contains the file.
Description
If your installation targets 64-bit platforms, ISICE16 verifies that it does not contain any 16-bit files, since 64-bit platforms
do not support 16-bit files.
Corrective Action
To resolve this validation error, replace the 16-bit file with a 64-bit or 32-bit file.
See Also
Windows Installer on 64-bit Operating Systems (Windows Installer Help Library)
Windows Installer on 64-bit Operating Systems (Windows Installer Help Library)
Requirements for the Windows Logo Program
ISICEs
ISICE17
InstallShield 2020
• Basic MSI
• InstallScript MSI
• Merge Module
• MSI Database
Messages
Message 1 (Error)
Sequence [1] includes the [2] action. Use of the [2] action requires a waiver from Microsoft.
[2] is the name of an action in your project, and [1] is the name of the sequence that contains that action.
Message 2 (Error)
Control [1] on Dialog [2] runs the [3] action. Use of the [3] action requires a waiver from Microsoft.
[3] is the name of an action in your project. [2] is the name of the control that includes an event that launches that action.
[2] is the name of the dialog that has the control.
Description
ISICE17 verifies that the installation does not use an action to force a reboot. Currently, the only action that is validated is
ForceReboot.
Corrective Action
The errors are displayed to inform you that if you want to have your product qualify for the Windows logo program but you
keep the specified action in your installation, you may need to obtain a waiver from Microsoft.
To resolve these validation errors, remove the action from sequence or dialog that is mentioned in the message.
Ensure that your project includes the MsiRMFilesInUse dialog to minimize system reboots, and that your application has
been properly instrumented to use the Restart Manager API. For more information, see Minimizing Reboots on Windows
Vista and Later Systems.
See Also
ForceReboot Action (Windows Installer Help Library)
ForceReboot Action (Windows Installer Help Library)
Requirements for the Windows Logo Program
ISICEs
ISICE18
InstallShield 2020
• Basic MSI
• MSI Database
Messages
Message 1 (Error)
Dialog [1] is not present in the Dialog table.
Message 2 (Error)
The Title of Dialog [1] does not include [2] or [ProductName].
[1] is the name of a dialog in your project, and [2] is the value of the [ProductName] variable.
Description
ISICE18 verifies that the installation includes the MsiRMFilesInUse dialog, and that the dialog’s title bar contains the name
of the product.
Corrective Action
To resolve error 1, ensure that the MsiRMFilesInUse dialog is in your project. All Basic MSI projects include this dialog by
default. For more information about this dialog, see Minimizing Reboots on Windows Vista and Later Systems.
To add the dialog back to a Basic MSI project, you can open another Basic MSI project that contains this dialog, or create a
new Basic MSI project. Then export the dialog to the project that needs it. For more information, see Exporting Dialogs to
Other Projects.
To resolve error 2, add the product name or the [ProductName] property to the Caption property for the MsiRMFilesInUse
dialog.
See Also
Using Windows Installer with Restart Manager (Windows Installer Help Library)
Using Windows Installer with Restart Manager (Windows Installer Help Library)
Dialog Control
Requirements for the Windows Logo Program
ISICEs
ISICE19
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Error)
The table [1] is not present in the installation package.
Message 2 (Error)
UpgradeCode [1] does not detect and prevent downgrades with a properly scheduled Type 19 Custom Action;
the package must prevent downgrades.
Message 3 (Error)
The property [1] is not listed in SecureCustomProperties; this can prevent it from being used correctly
for downgrade prevention.
Message 4 (Error)
The property [1] must be a valid GUID; [2] is not a valid GUID.
[1] is the name of a property whose value should be a valid GUID. [2] is the invalid value that is currently used for that
property.
Message 5 (Error)
Column [1] of table Upgrade must hold a valid GUID; [2] is not a valid GUID.
[1] is the name of a column in the Upgrade table, and [2] is the value of an entry in the specified column.
Message 6 (Error)
The property [1] must hold a valid numeric version in the format Major.Minor.Build; [2] is not a version
in this format.
[1] is the name of a property whose value should be a version number in the Major.Minor.Build format. [2] is the invalid
value that is currently used for that property.
Message 7 (Error)
Column [1] of table Upgrade must hold a valid numeric version in the format Major.Minor.Build; [2] is not
a version in this format.
[1] is the name of a column in the Upgrade table, and [2] is the value of an entry in the specified column.
Message 8 (Error)
The property [1] must not be null or empty.
Message 9 (Error)
Column [1] of table Upgrade must not be null or empty.
Message 10 (Error)
The property [1] must be provided; [2] is the default value.
[1] is the name of a property in your project that has not been customized. [2] is the default value that InstallShield uses for
that property.
Message 11 (Error)
The property [1] must hold a valid numeric LANGID; [2] is not a numeric LANGID.
[1] is the name of a property whose value should be a valid language identifier. [2] is the invalid value that is currently used
for that property.
Description
ISICE19 validates properties related to upgrades and that the Upgrade table is present. ISICE19 also helps you determine
whether the installation prevents an earlier package from installing over a new package.
Corrective Action
To resolve errors 1 and 2, ensure that the Upgrades view contains a major upgrade item, that the major upgrade item is
properly configured to prevent the current version of your product from being installed over a future version, and that your
project includes a properly configured and scheduled type 19 custom action. For detailed instructions, see Preventing the
Current Installation from Overwriting a Future Major Version of the Same Product. For more information, see Preventing an
Old Package from Installing Over a Newer Version in the Windows Installer Help Library.
To resolve error 3, add the specified property to the value of the SecureCustomProperties property. You can use the
Property Manager view to set a value for a property. To add multiple values, separate each with a semicolon. For more
information, see SecureCustomProperties Property in the Windows Installer Help Library.
To resolve errors 4 and 5, replace the existing value with a valid GUID. To change the value, open the General Information
view. Then click the setting that is listed in the error message. Enter a valid GUID. Note that if you want to use a new, unique
GUID, you can click the Generate a new GUID button in the setting. For more information, see GUIDs.
To resolve errors 6 and 7, replace the specified value with a valid version number; you can click the error message in the
Output window to move to the location in the Direct Editor that has the invalid value. The version number must contain
only numbers, and it must be in the format aaa.bbb.ccccc, where aaa represents the major version number, bbb represents
the minor version number, and ccccc represents the build number. The maximum value for the aaa and bbb portions is 255.
The maximum value for ccccc is 65,535. For more information, see Specifying the Product Version.
To resolve error 8, enter a value for the specified property. You can use the Property Manager view to set a value for a
property.
To resolve error 9, enter a value for the specified column. You can use the Direct Editor view to set the value; you can click
the error message in the Output window to move to the location in the Direct Editor that needs to be revised. To learn more
about any of the Windows Installer tables, see Database Tables in the Windows Installer Help Library.
To resolve error 10, replace the default value of the specified property with the appropriate value. You can use the Property
Manager view to change the value.
To resolve error 11, replace the existing value of the specified property with a valid language identifier.
See Also
Upgrade Table (Windows Installer Help Library)
Upgrade Table (Windows Installer Help Library)
Property Manager View
Requirements for the Windows Logo Program
ISICEs
ISICE20
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Error)
Row [1] of Table [2]: installing, modifying, or deleting a registry key in root [3] requires elevated
privileges, but this package does not request elevated privileges.
[1] is the name of the row that contains information about a registry change in your project. [2] is the name of the table that
contains that registry-related data. [3] is the predefined root key for the registry data, as listed in the Root column for the
specified row.
Message 2 (Error)
Row [1] of Table [2]: installing, modifying, or deleting a file in directory [3] requires elevated
privileges, but this package does not request elevated privileges.
[1] is the name of a row that contains information about a directory that end users cannot access without elevated
privileges. [2] is the name of the table that contains that directory data. [3] is the name of the directory.
Message 3 (Error)
Environment variable [1] is a system environment variable, but this package does not request elevated
privileges.
[1] is the name of a system environment variable that is included in your project.
Description
If the Require Administrative Privileges setting in the General Information view is set to No for your project, ISICE20 verifies
that your installation does not attempt to perform tasks that require administrative privileges, such as writing to system
registry or folder locations.
Corrective Action
To resolve ISICE20 errors, do one of the following:
• Select Yes for the Require Administrative Privileges setting in the General Information view. For more information, see
Entering Summary Information Stream Data.
• Change your project so that it does not install, modify, or delete data in system locations. For example, if your project
adds a registry key to HKEY_LOCAL_MACHINE, use the Registry view to move that registry key to
HKEY_CURRENT_USER. If your project adds or modifies a system environment variable, use the Environment
Variables view to change the Type setting of that environment variable from System to User.
See Also
Authoring Packages without the UAC Dialog Box (Windows Installer Help Library)
Authoring Packages without the UAC Dialog Box (Windows Installer Help Library)
Installing a Package with Elevated Privileges for a Non-Admin (Windows Installer Help Library)
Installing a Package with Elevated Privileges for a Non-Admin (Windows Installer Help Library)
Guidelines for Packages (Windows Installer Help Library)
Guidelines for Packages (Windows Installer Help Library)
Minimizing the Number of User Account Control Prompts During Installation
Requirements for the Windows Logo Program
ISICEs
ISICE21
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
File [1] in Component [2] depends on the VB6 runtime.
[1] is the name of a file that requires the Visual Basic 6 runtime. [2] is the name of the component that contains that file.
Description
ISICE21 verifies that your product does not depend on the Visual Basic 6 runtime.
Corrective Action
To resolve this validation error, consider the following options:
• If the file is in a component that your product no longer uses, remove the file and its component from your project.
Consider using a newer language such as Visual Basic .NET for the creation of your file.
• Remove the file and its component from your project and replace them with new versions that do not rely on the
Visual Basic 6 runtime.
If neither of those options are feasible for your product, your installation will not qualify for the Windows logo program.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE22
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Error)
Shortcut [1] in Component [2] targets the startup folder.
[1] is the name of a shortcut in your project, and [2] is the name of the component that contains that shortcut.
Message 2 (Error)
Registry key [1] in Component [2] sets a Run key.
[1] is a registry key in your project, and [2] is the name of the component that contains that shortcut.
Description
ISICE22 verifies that your product does not start automatically when the target system starts.
Error message 1 occurs if your installation creates a shortcut in the Startup folder on the Start Menu.
Error message 2 occurs if your installation sets a Run key in locations of the registry such as the following ones:
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion
• HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion
• HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Windows\CurrentVersion
Corrective Action
To resolve this validation error, remove the shortcut or registry key and—if appropriate—the component that contains it
from your project.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE23
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
LockObject [1] in Component [2] sets insecure permissions.
[1] is the name of a file, directory, or registry key for which permissions are configured. [2] is the name of the component
that contains that file, directory, or registry key.
Description
ISICE23 verifies that your installation does not expose a target system to security risks through the configuration of
inappropriate permissions for files, directories, and registry keys.
For example, if your installation assigns write permission to the Everyone user for a particular folder that your installation
installs, ISICE23 triggers an error to alert you to the security vulnerability to which your installation exposes target systems.
Corrective Action
To resolve this validation error, use strong and appropriate permissions for the file, directory, or registry key that is
mentioned in the error. For more information, see:
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE24
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
File [1] in Component [2] is a 16-bit file. Installations that target Windows 8 systems may not include
16-bit files.
[1] is the name of a 16-bit file in the installation. [2] is the name of the component that contains that file.
Description
ISICE24 verifies that the installation does not contain any 16-bit files; 64-bit versions of Windows do not support 16-bit files.
Corrective Action
To resolve this validation error, replace the 16-bit file with a 64-bit or 32-bit file.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE25
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
The destination of Component [1] is the Windows folder or one of its subfolders.
Description
ISICE25 verifies that the installation does not write directly to the Windows folder or any of its subfolders.
Corrective Action
To resolve this validation error, do one of the following:
• If the component is installing a font, ensure that the font file is included in the project according to best practices. To
learn how, see Installing Fonts.
• If the component is installing a device driver, ensure that the driver is included in the project according to best
practices. To learn how, see Configuring Device Driver Settings.
See Also
Requirements for the Windows Logo Program
ISICEs
ISICE26
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
File [1] in Component [2] does not have the Option Header bit [3] set.
[1] is the name of a file, and [2]is the name of the component that contains the file. [3] is the parameter (SafeSEH,
NXCOMPAT, or DYNAMICBASE) that was not used when compiling the file.
Description
ISICE26 verifies that the installation supports Windows security features. It checks the PE header of the executable files
that the installation installs to verify that they were compiled using the following command-line parameters:
A single file can trigger multiple ISICE26 errors, one for each of the aforementioned parameters.
Corrective Action
To resolve this validation error, review build the options for your product’s source code, and edit them as needed. In Visual
Studio, these are configured on the Advanced property page for Linker settings.
See Also
Requirements for the Windows Logo Program
ISICEs
• Basic MSI
• InstallScript MSI
• MSI Database
InstallShield includes a set of validators called the InstallShield Virtualization Suitability Suite. The InstallShield
Virtualization Suitability validators (ISVICEs) in this suite help you check your project’s suitability for various virtualization
technologies.
The following table lists the ISVICEs that are available in InstallShield.
ISVICE01 Basic MSI, App-V 4.x, Checks for the presence of files that may normally be
InstallScript MSI, App-V 5.x, part of the Windows operating system.
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE02 Basic MSI, App-V 4.x, Checks for the presence of device driver files.
InstallScript MSI, App-V 5.x,
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE03 Basic MSI, App-V 4.x, Checks for the presence of ClickOnce deployment
InstallScript MSI, App-V 5.x, files.
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE04 Basic MSI, App-V 4.x, Checks for the presence of files that are part of
InstallScript MSI, App-V 5.x, ASP.NET/IIS applications.
MSI Database ThinApp,
XenApp
ISVICE05 Basic MSI, App-V 4.x, Checks for the presence of files that are part of WMI
InstallScript MSI, App-V 5.x, providers.
MSI Database ThinApp,
XenApp
ISVICE06 Basic MSI, App-V 4.x, Checks for the presence of files that are part of J2EE
InstallScript MSI, App-V 5.x, application servers.
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE07 Basic MSI, App-V 4.x, Checks for the presence of files that are part of
InstallScript MSI, App-V 5.x, applications that may not work when virtualized.
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE08 Basic MSI, App-V 4.x, Checks for the presence of files that are part of
InstallScript MSI, App-V 5.x, applications that are known to fail when virtualized.
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE09 Basic MSI, App-V 4.x, Checks for the presence of InstallShield IIS support
InstallScript MSI, App-V 5.x, indicating that an ASP.NET/IIS application is
MSI Database ThinApp, installed.
XenApp
ISVICE10 Basic MSI, App-V 4.x, Checks for the presence of drivers installed through
InstallScript MSI, App-V 5.x, the MsiDriverPackages table.
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE11 Basic MSI, App-V 4.x, Checks the package to ensure that it contains at least
InstallScript MSI, App-V 5.x, one shortcut.
MSI Database ThinApp,
XenApp
ISVICE12 Basic MSI, App-V 4.x, Checks for the presence of shell extensions.
InstallScript MSI, App-V 5.x,
MSI Database Server App-V,
ThinApp,
XenApp
ISVICE13 Basic MSI, App-V 4.x, Checks for the presence of URL protocol handlers.
InstallScript MSI, Server App-V,
MSI Database ThinApp,
XenApp
ISVICE14 Basic MSI, App-V 4.x, Checks for the presence of support for the Default
InstallScript MSI, Server App-V, Programs list.
MSI Database ThinApp,
XenApp
ISVICE15 Basic MSI, App-V 4.x, Checks for the presence of boot start services.
InstallScript MSI, App-V 5.x,
MSI Database ThinApp,
XenApp
ISVICE16 Basic MSI, App-V 4.x, Checks to ensure that the total installed file size is
InstallScript MSI, Server App-V, less than 4 GB.
MSI Database XenApp
ISVICE17 Basic MSI, App-V 4.x, Checks for the usage of the Windows Installer COM+
InstallScript MSI, App-V 5.x, tables.
MSI Database ThinApp,
XenApp
ISVICE18 Basic MSI, App-V 4.x, Checks for the presence of COM DLL surrogate files.
InstallScript MSI, App-V 5.x,
MSI Database ThinApp,
XenApp
ISVICE19 Basic MSI, ThinApp, Checks to see if this is a 64-bit package. ThinApp and
InstallScript MSI, XenApp XenApp do not support 64-bit applications.
MSI Database
See Also
Viewing Validation Results
ISVICE01
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Error)
The file [1] appears to be a file that is closely integrated with the OS. The files that make up
applications like Internet Explorer or Windows Media Player, or frameworks like the .NET Framework,
do not make good candidates for virtualization. These files should instead be installed locally on
the machine.
Description
ISVICE01 checks for the presence of files that may normally be part of the Windows operating system. If the release
contains one or more of those type of files, this error message is displayed during validation.
Corrective Action
If your end users may be interested in a virtualized version of your product, and if your InstallShield project contains the
.NET Framework or other items that are closely integrated with Windows, you may want to remove those items from your
project. You could document the technologies that are required for your product and instruct your end users to install
them locally on their machines before using a virtualized version of your product.
See Also
InstallShield Virtualization Suitability Suite
ISVICE02
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Error)
The file [1] appears to be a device driver. System-level drivers such as print drivers or USB device
drivers do not work from a virtualized environment. It may be possible to extract this driver such
that it can be installed locally on the machine and allow the rest of the package to be virtualized.
Description
ISVICE02 checks for the presence of device driver files. System-level drives such as print drivers or USB device drivers do
not work from a virtualized environment.
Corrective Action
If your end users may be interested in a virtualized version of your product, and if your InstallShield project contains a
device driver, consider removing the device driver component from your project, and creating a separate installation for
the driver. End users can then install the driver locally to their machines before using a virtualized version of your product.
See Also
InstallShield Virtualization Suitability Suite
ISVICE03
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Error)
The file [1] appears to be a ClickOnce deployment file. ClickOnce is a per-user installation format that
is often incompatible with the per-machine nature of virtual packages. A ClickOnce application also
may try to automatically update itself, which can result in invalid versioning in virtual
application management systems.
Description
ISVICE03 checks for the presence of ClickOnce deployment files. If your project includes ClickOnce deployment files,
ISVICE03 occurs.
Corrective Action
Evaluate how important the ClickOnce deployment files are to the application so that you can determine if it matters
whether the ClickOnce installation behaves as intended. If the ClickOnce deployment files are unimportant, it is probably
safe to deploy a virtualized version of the product with slightly reduced functionality. If the ClickOnce deployment files are
important, a virtualized version of the product may not function well.
See Also
InstallShield Virtualization Suitability Suite
ISVICE04
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• ThinApp
• XenApp
Message (Error)
The file [1] appears to be a part of an ASP.NET/IIS application. This is not supported by desktop
application virtualization.
Description
ISVICE04 checks for the presence of files that are part of ASP.NET or IIS applications.
Corrective Action
If the ASP.NET or IIS application is not an important part of the product, or if it can be separately installed locally on target
systems, you can ignore this validation error.
See Also
InstallShield Virtualization Suitability Suite
ISVICE05
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• ThinApp
• XenApp
Message (Error)
The file [1] appears to be a WMI provider. This is not supported by desktop application virtualization.
If the provider is not a critical piece of the package, it may be possible to use the rest of the
package as a virtual application.
Description
ISVICE05 checks for the presence of files that are part of Windows Management Instrumentation (WMI) providers.
Corrective Action
If the WMI provider is not an important part of the product, or if it can be separately installed locally on target systems, you
can ignore this validation error.
See Also
InstallShield Virtualization Suitability Suite
ISVICE06
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Error)
The file [1] appears to be part of a J2EE application server. This is not supported by desktop
application virtualization.
Description
ISVICE06 checks for the presence of files that are part of J2EE application servers.
Corrective Action
If the J2EE application is not an important part of the product, or if it can be separately installed locally on target systems,
you can ignore this validation error.
See Also
InstallShield Virtualization Suitability Suite
ISVICE07
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Warning)
The file [1] appears to be a part of an application that is known to not be a good candidate for
virtualization; however, it may be possible to virtualize the rest of the package and install the
unsuitable piece physically.
Description
ISVICE07 checks for the presence of files that are part of applications that may not work when virtualized. This includes files
that are from applications such as SQL Server.
Corrective Action
If the unsupported application is not an important part of the product, or if it can be separately installed locally on target
systems, you can ignore this validation error.
See Also
InstallShield Virtualization Suitability Suite
ISVICE08
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Error)
The file [1] appears to be a part of an application that is known to not be a good candidate for
virtualization.
Description
ISVICE08 checks for the presence of files that are part of applications that may not work when virtualized. This includes files
that are from applications such as antivirus software or server software such as Exchange Server.
Corrective Action
If the unsupported application is not an important part of the product, or if it can be separately installed locally on target
systems, you can ignore this validation error.
See Also
InstallShield Virtualization Suitability Suite
ISVICE09
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• ThinApp
• XenApp
Message (Error)
IIS [1] item [2] is included in the package. This is not supported by desktop application virtualization.
[1] is the name of a type of IIS item in the project, and [2] is the name of that item.
Description
ISVICE09 checks for the presence of InstallShield IIS support indicating that an ASP.NET or IIS application is installed.
Corrective Action
If the unsupported ASP.NET or IIS application is not an important part of the product, or if it can be separately installed
locally on target systems, you can ignore this validation error.
See Also
InstallShield Virtualization Suitability Suite
ISVICE10
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Error)
Component [1] contains a device driver installed through the MsiDriverPackages (DIFxApp) table. System-
level drivers such as print drivers or USB device drivers do not work from a virtualized
environment. It may be possible to extract this driver such that it can be installed locally on the
machine and allow the rest of the package to be virtualized.
Description
ISVICE10 checks for the presence of drivers that are configured to be installed through the MsiDriverPackages table.
Corrective Action
If your end users may be interested in a virtualized version of your product, and if your InstallShield project contains a
driver, consider removing the driver from your project, and creating a separate installation for the driver. End users can
then install the driver locally to their machines before using a virtualized version of your product.
See Also
InstallShield Virtualization Suitability Suite
ISVICE11
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• ThinApp
• XenApp
Message (Warning for App-V 4.x and App-V 5.x; Error for ThinApp and XenApp)
This package contains no shortcuts. Shortcuts are usually necessary to define the entry point into the
virtual application.
Description
ISVICE11 checks the package to ensure that it contains at least one shortcut. Shortcuts provide the most visible entry
points for launching applications in a virtual package. Most virtual packages should have at least one shortcut.
Corrective Action
If the package is intended to be used as a dependency by a different virtual package, you can ignore this ISVICE.
If the package is intended to be used as a plug-in, it may be necessary to create a shortcut to the application for which this
is a plug-in.
If end users need to be able to launch the virtual application independently, consider adding a shortcut for the main
executable file.
See Also
InstallShield Virtualization Suitability Suite
ISVICE12
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• Server App-V
• ThinApp
• XenApp
Message (Error for App-V 4.x, App-V 5.x, ThinApp, and XenApp; Warning for Server App-
V)
This package contains a shell extension (key [1]). Shell extensions extend Windows Explorer and cannot
be loaded from a virtual package. This extension may be critical to the use of this application, and
if so this application will not function when virtualized. However, if this extension is non-
critical, the application can still be used.
Description
ISVICE12 checks for the presence of shell extensions.
Corrective Action
Evaluate how important the shell extension is to the product so that you can determine if it matters whether the shell
extension behaves as intended. If the shell extension is unimportant, it is probably safe to deploy a virtualized version of
the product with slightly reduced functionality. If the shell extension is important, a virtualized version of the product may
not function well.
See Also
InstallShield Virtualization Suitability Suite
ISVICE13
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• Server App-V
• ThinApp
• XenApp
Message (Warning)
This package registers a URL protocol (friendly name [1]).
Description
ISVICE13 checks for the presence of URL protocol handlers.
Corrective Action
Evaluate how important the registration of the URL protocol is to the product so that you can determine if it matters
whether the product behaves as intended. If the registration of the URL protocol is unimportant, it is probably safe to
deploy a virtualized version of the product with slightly reduced functionality. If the registration of the URL protocol is
important, a virtualized version of the product may not function well.
Consider performing validation to see if App-V 5.x is a suitable virtualization technology for your product, since it has
support for URL protocol handlers.
See Also
InstallShield Virtualization Suitability Suite
ISVICE14
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• Server App-V
• ThinApp
• XenApp
Message (Warning)
This package registers its capabilities in the Default Programs list (key '%1').
[1] is the name of the key that corresponds with registration information for an item in the Default Programs list.
Description
ISVICE14 checks for the presence of support for the Default Programs list.
Corrective Action
If the Default Programs list registration is not an important part of the product, you can ignore this validation error.
Consider performing validation to see if App-V 5.x is a suitable virtualization technology for your product, since it has
support for registering items in the Default Programs list.
See Also
InstallShield Virtualization Suitability Suite
ISVICE15
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• ThinApp
• XenApp
Message (Error)
This package contains a service (name [1]), which starts at boot time. Virtualized services are limited
to the lifetime of the virtual application so services that must start at boot time do not make good
candidates for virtualization. It may be possible to extract this service such that it can be
installed locally on the machine and allow the rest of the package to be virtualized.
Description
ISVICE15 checks for the presence of boot start services.
Corrective Action
Evaluate how important the service is to the product so that you can determine if it matters whether the product behaves
as intended. If the service is unimportant, it is probably safe to deploy a virtualized version of the product with slightly
reduced functionality.
If the service is important but you can separate it from the rest of the project, remove it from the project, and create a
separate installation for the service. End users can then install the service locally to their machines before using a
virtualized version of your product.
If the service is important but you cannot separate it from the rest of the project, a virtualized version of the product may
not function well.
See Also
InstallShield Virtualization Suitability Suite
ISVICE16
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• Server App-V
• XenApp
Message (Error)
This package contains more than 4 GB of files. Since the target virtualization technology has a 4 GB size
limit, this application cannot be successfully virtualized.
Description
ISVICE16 checks to ensure that the total installed file size is less than 4 GB. App-V 4.x, Server App-V, and XenApp do not
support packages that contain more than 4 GB of files.
Corrective Action
Consider performing validation to see if App-V 5.x or ThinApp are suitable virtualization technologies for your product,
since they support sizes larger than 4 GB.
See Also
InstallShield Virtualization Suitability Suite
ISVICE17
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• ThinApp
• XenApp
Message (Error)
This package contains COM+ data (component [1]), which is not supported, so the application may not work
correctly if virtualized.
[1] is the name of a component in the project; the component contains COM+ data.
Description
ISVICE17 checks for use of the Windows Installer COM+ tables.
Corrective Action
Evaluate how important the COM+ application is to the product so that you can determine if it matters whether the product
behaves as intended. If the COM+ application is unimportant, it is probably safe to deploy a virtualized version of the
product with slightly reduced functionality. If the COM+ application is important, a virtualized version of the product may
not function well.
See Also
InstallShield Virtualization Suitability Suite
ISVICE18
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• App-V 4.x
• App-V 5.x
• ThinApp
• XenApp
Message (Error)
This package contains a COM DLL surrogate (registry key [1]), which is not supported, so the application
may not work correctly if virtualized.
Description
ISVICE18 checks for the presence of COM DLL surrogate files.
Corrective Action
Evaluate how important the COM DLL surrogate is to the product so that you can determine if it matters whether the
product behaves as intended. If the DLL surrogate is unimportant, it is probably safe to deploy a virtualized version of the
product with slightly reduced functionality. If the DLL surrogate is important, a virtualized version of the product may not
function well.
See Also
InstallShield Virtualization Suitability Suite
ISVICE19
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
• ThinApp
• XenApp
Message (Error)
The package is 64-bit. ThinApp and XenApp do not support 64-bit applications.
Description
ISVICE19 checks to see if you are building a 64-bit package. ThinApp and XenApp do not support 64-bit applications.
Corrective Action
Consider performing validation to see if App-V or Server App-V is a suitable virtualization technology for your product, since
it has 64-bit support.
See Also
InstallShield Virtualization Suitability Suite
InstallShield includes a set of validators called the InstallShield MSIX/UWP App Suitability Suite. The InstallShield Windows
App Suitability validators (ISUWPs) in this suite scan an .msi package for signs of items that are unsuitable for the Windows
App package (.appx) format. To access this suite, on the Build menu, point to Validation, and then click InstallShield
MSIX/UWP App Suitability Suite. The suite provides a report in the Releases view that indicates all tests that found issues
and for each issue, an associated column in the report indicates applicability to the known Windows App variants
(Universal App, Desktop Bridge, Windows Store, WSA, and Nano Server). For traditional CUBs, these columns are not
populated. The following ISUWP validations are available in InstallShield:
ISUWP01 Basic MSI Windows App Checks for the presence of Windows services.
ISUWP02 Basic MSI Windows App Checks for the presence of drivers installed with the
MsiDriverPackages table.
ISUWP03 Basic MSI Windows App Checks for the presence of shortcuts. InstallShield
requires shortcuts to identify applications. Without
shortcuts to identify applications, the package is
invalid as there are no ways to start your app.
ISUWP04 Basic MSI Windows App Checks for the presence of multiple shortcuts for
Windows Store applications. InstallShield turns
shortcuts into applications, and the Windows Store
may disallow multiple applications.
ISUWP05 Basic MSI Windows App Checks for the presence of shortcuts for Windows
Nano Server applications. InstallShield will turn any
shortcut into a tile if it points to an .exe installed by
the package; however Windows Nano Server cannot
display application tiles.
ISUWP06 Basic MSI Windows App Checks for the presence of 16-bit files. All server
installations are 64-bit platforms and 64-bit platforms
do not support 16-bit files..
ISUWP07 Basic MSI Windows App Checks for the presence of 32-bit files. All server
installations are 64-bit platforms and 64-bit platforms
do not support 32-bit files.
ISUWP08 Basic MSI Windows App Checks for the presence of applications that require
elevated privileges.
ISUWP09 Basic MSI Windows App Checks for the presence of applications that are
allowed to bypass UI protection levels.
ISUWP10 Basic MSI Windows App Checks for the presence of COM registration.
ISUWP11 Basic MSI Windows App Checks for the presence of executable files that set a
custom Application User Model ID.
ISUWP12 Basic MSI Windows App Checks for the presence of .NET assemblies that are
incompatible with Windows Nano Server.
ISUWP13 Basic MSI Windows App Checks for the presence of .NET assemblies that do
not support the latest version of .NET Framework.
ISUWP14 Basic MSI Windows App Checks for the presence of files that are part of
ASP.NET/IIS applications.
ISUWP15 Basic MSI Windows App Checks for the presence of InstallShield IIS support
indicating that an ASP.NET/IIS application is
installed.
ISUWP16 Basic MSI Windows App Checks for the presence of built-in InstallShield
support that executes SQL scripts.
ISUWP17 Basic MSI Windows App Checks for the presence of built-in InstallShield
support that modifies text files.
ISUWP18 Basic MSI Windows App Checks for the presence of built-in InstallShield
support that modifies XML files.
ISUWP19 Basic MSI Windows App Checks for the presence of built-in InstallShield
support that creates scheduled tasks.
ISUWP20 Basic MSI Windows App Checks for the presence of file type associations that
are reserved or forbidden.
See Also
Viewing Validation Results
ISUWP01
InstallShield 2020
Message (Error)
This package contains one or more Windows services. Windows App packages that target other devices than
Windows Server do not support Windows services.
Description
ISUWP01 checks for the presence of Windows services.
Corrective Action
If one or more Windows services are required by the application, then server extensions and WSA are required. Including
desktop extensions is not supported in this scenario.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP02
InstallShield 2020
Message (Error)
Component [1] contains a device driver installed through the MsiDriverPackages (DIFxApp) table. Windows
App packages do not support device drivers.
Description
ISUWP02 checks for the presence of drivers installed with the MsiDriverPackages table.
Corrective Action
If the driver is required, this application cannot be supported purely by Windows Apps.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP03
InstallShield 2020
Message (Warning)
This package contains no shortcuts. Shortcuts are usually necessary to define the entry point into the
application.
Description
ISUWP03 checks for the presence of shortcuts. InstallShield requires shortcuts to identify applications. Without shortcuts
to identify applications, the package is invalid as there are no ways to start your app.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP04
InstallShield 2020
Message (Warning)
This package contains more than one shortcut. Windows Store may not allow more than one application.
Description
ISUWP04 checks for the presence of multiple shortcuts for Windows Store applications. InstallShield turns shortcuts into
applications, and the Windows Store may disallow multiple applications.
Corrective Action
If you wish to distribute this application on the Windows Store, you may need to split the application into multiple
Windows App packages.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP05
InstallShield 2020
Message (Warning)
This package contains one or more shortcuts. Windows Nano Server cannot show application tiles.
Description
ISUWP05 checks for the presence of shortcuts for Windows Nano Server applications. InstallShield will turn any shortcut
into a tile if it points to an .exe installed by the package; however Windows Nano Server cannot display application tiles.
Corrective Action
This warning alerts you to a known item that may not function as expected.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP06
InstallShield 2020
Message (Warning)
File [1] in Component [2] is a 16-bit file. 64-bit systems do not support 16-bit applications.
Description
ISUWP06 checks for the presence of 16-bit files. All server installations are 64-bit platforms and 64-bit platforms do not
support 16-bit files.
Corrective Action
A corrective action is only necessary if the file is loaded and executed at run-time. Data files that happen to be 16-bit or 32-
bit are not a problem. If the flagged 16-bit file is loaded and executed at run-time, replace it with a 64-bit file.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP07
InstallShield 2020
Message (Warning)
File [1] in Component [2] is a 32-bit file. 64-bit systems may not support 32-bit applications.
Description
ISUWP07 checks for the presence of 32-bit files. All server installations are 64-bit platforms and 64-bit platforms do not
support 32-bit files.
Corrective Action
A corrective action is only necessary if the file is loaded and executed at run-time. Data files that happen to be 16-bit or 32-
bit are not a problem. If the flagged 32-bit file is loaded and executed at run-time, replace it with a 64-bit file.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP08
InstallShield 2020
Message (Error)
File [1] in Component [2] is an application executable file that requires elevated privileges. Windows
Store does not allow applications that require administrative privileges.
Description
ISUWP08 checks for the presence of applications that require elevated privileges.
Corrective Action
Remove the requirement for elevated privileges. An app may be using elevated privileges to subvert best-practices about
handling files or registry keys, and such subversion will not work in a Windows App.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP09
InstallShield 2020
Message (Error)
File [1] in Component [2] is an application executable file that is allowed to bypass UI protection
levels to drive input to higher privilege windows on the desktop. Windows App packages do not
support applications that are allowed to bypass UI protection levels.
Description
ISUWP09 checks for the presence of applications that are allowed to bypass UI protection levels.
Corrective Action
Very few applications require bypassing UI protection levels, but those that do are not currently supported by Windows
Apps. If an application requires bypassing UI protection levels, consider using a different package format than a Windows
App package.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP10
InstallShield 2020
Messages (Warnings)
Message 1 (Warning)
Table [1] contains one or more entries. Applications in Windows App packages cannot expose COM servers
to other applications.
Message 2 (Warning)
Registry key [1] in Component [2] is COM data. Applications in Windows App packages cannot expose COM
servers to other applications.
Description
ISUWP10 checks for the presence of COM registration.
Corrective Action
COM registration may or may not be a problem. Internal use of COM is fully supported by the Desktop Bridge, but no
extension currently supports public registration (for use by other apps). If the latter is required, a Windows App package is
unsuitable.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP11
InstallShield 2020
Message (Error)
File [1] in Component [2] imports API [3]. Applications in Windows App packages are not allowed to set a
custom Application User Model ID.
Description
ISUWP11 checks for the presence of executable files that set a custom Application User Model ID.
Corrective Action
Code-based removal of the offending API call is required. A Windows App will set an Application User Model ID for you.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP12
InstallShield 2020
Messages
Message 1 (Error)
File [1] in Component [2] is a .NET assembly that was compiled against .NET Framework. Windows Nano
Server supports only .NET Core applications
Message 2 (Error)
File [1] in Component [2] is a .NET assembly that was compiled against [3]. Windows Nano Server supports
only .NET Core applications.
Description
ISUWP12 checks for the presence of .NET assemblies that are incompatible with Windows Nano Server.
Corrective Action
Rebuild your app against .NET Core if you want to support Nano Server.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP13
InstallShield 2020
Message (Warning)
File [1] in Component [2] is a .NET assembly that does not support the latest version of .NET Framework.
Windows Store applications always run on the latest version of .NET Framework.
Description
ISUWP13 checks for the presence of .NET assemblies that do not support the latest version of .NET Framework.
Corrective Action
Rebuild or adjust your app.config.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP14
InstallShield 2020
Message (Error)
The file [1] appears to be a part of an ASP.NET/IIS application. This is not supported by applications
in Windows App package.
Description
ISUWP14 checks for the presence of files that are part of ASP.NET/IIS applications.
Corrective Action
Because files that are part of ASP.NET/IIS applications are not supported by Windows Apps, you will need to remove the file
from the package or use an alternative package format.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP15
InstallShield 2020
Message (Error)
IIS [1] item [2] is included in the package. This is not supported by applications in Windows App
packages.
[1] is the name of a type of IIS item in the project, and [2] is the name of that item.
Description
ISUWP15 for the presence of InstallShield IIS support indicating that an ASP.NET/IIS application is installed.
Corrective Action
Because files that are part of ASP.NET/IIS applications are not supported by Windows Apps, you need to remove the file
from the package or use an alternative package format.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP16
InstallShield 2020
Message (Error)
This package contains one or more SQL scripts that run during an installation. Windows App packages do
not support executing SQL scripts.
Description
ISUWP16 checks for the presence of built-in InstallShield support that executes SQL scripts.
Corrective Action
The flagged configuration must be moved from the installation to the application in order to support the use of a Windows
App package.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP17
InstallShield 2020
Message (Error)
This package contains one or more InstallShield Text File Changes items that are performed during an
installation. Windows App packages do not support modifying text files.
Description
ISUWP17 for the presence of built-in InstallShield support that modifies text files.
Corrective Action
The flagged configuration must be moved from the installation to the application in order to support the use of a Windows
App package.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP18
InstallShield 2020
Message (Error)
This package contains one or more InstallShield XML File Changes items that are performed during an
installation. Windows App packages do not support modifying XML files.
Description
ISUWP18 checks for the presence of built-in InstallShield support that modifies XML files.
Corrective Action
The flagged configuration must be moved from the installation to the application in order to support the use of a Windows
App package.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP19
InstallShield 2020
Message (Error)
This package contains one or more InstallShield Scheduled Tasks items that are performed during an
installation. Windows App packages do not support creating scheduled tasks.
Description
ISUWP19 checks for the presence of built-in InstallShield support that creates scheduled tasks.
Corrective Action
The flagged configuration must be moved from the installation to the application in order to support the use of a Windows
App package.
See Also
InstallShield MSIX/UWP App Suitability Suite
ISUWP20
InstallShield 2020
Message (Error)
Extension [1] in Component [2] is a file type that is reserved or forbidden for Windows App packages.
[1] is the name of an extension in the project and [2] is the name of the component it is in.
Description
ISUWP20 checks for the presence of file type associations that are reserved or forbidden.
Corrective Action
Remove the flagged reserved or forbidden file type associations in order to support the use of a Windows App package.
See Also
InstallShield MSIX/UWP App Suitability Suite
Edition • The InstallShield Best Practice Suite is available in the Premier edition of InstallShield.
• Basic MSI
• InstallScript MSI
• MSI Database
Note that some of the ISBPs apply to only Basic MSI and MSI Database projects.
InstallShield includes a set of validators called the InstallShield Best Practice Suite. The InstallShield Best Practice (ISBP)
validators in this suite alert you if your installation violates best-practice guidelines.
The following table lists the ISBPs that are available in InstallShield.
ISBP03 Basic MSI, MSI Verifies that no ComboBox is shorter than 50 units.
Database
ISBP04 Basic MSI, MSI Verifies that properties used on dialogs are secure or restricted public
Database properties.
ISBP06 Basic MSI, Verifies that InstallUISequence custom actions are also sequenced in the
InstallScript MSI, InstallExecuteSequence.
MSI Database
ISBP07 Basic MSI, Verifies that all features have associated components and all components
InstallScript MSI, are associated with features.
MSI Database
ISBP08 Basic MSI, Verifies that ARPINSTALLLOCATION is set after CostFinalize in the
InstallScript MSI, InstallExecuteSequence.
MSI Database
ISBP09 Basic MSI, Verifies that LIMITUI is not set without ARPNOMODIFY.
InstallScript MSI,
MSI Database
ISBP10 Basic MSI, Verifies that AppSearch properties are secure or restricted public properties.
InstallScript MSI,
MSI Database
ISBP11 Basic MSI, Verifies that no precompiled .NET assemblies are being distributed.
InstallScript MSI,
MSI Database
ISBP13 Basic MSI, MSI Verifies that properties set by dialog controls and used in the installation
Database have a default value.
ISBP14 Basic MSI, Verifies that each file has the correct version information or an MsiFileHash
InstallScript MSI, entry.
MSI Database
ISBP15 Basic MSI, MSI Verifies that no RadioButtonGroup has Text defined.
Database
ISBP16 Basic MSI, Verifies that each component with a 64-bit destination is marked as a 64-bit
InstallScript MSI, component.
MSI Database
ISBP17 Basic MSI, Verifies that no .hlp files or WinHelp run-time files are included in the
InstallScript MSI, installation.
MSI Database
ISBP20 Basic MSI, Verifies that no registry entries contained in the Registry table attempt to
InstallScript MSI, remove root-level registry keys (such as HKLM\Software) or other keys that
MSI Database would cause adverse issues on target machines.
See Also
Specifying Whether Validation Should Be Performed at Build Time
Validating an Installation Package or Merge Module
Requirements for the Windows Logo Program
ISBP01
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
Feature ALL conflicts with the installation meta-feature ALL.
Description
ISBP01 verifies that your installation does not have a feature called ALL in uppercase, lowercase, or mixed case letters. In
the context of features, Windows Installer reserves the word ALL for use as a valid value for feature-state properties such as
ADVERTISE, REINSTALL, and ADDLOCAL, which can contain the names of specific features, as well as the word ALL to indicate
all features. Therefore, none of the individual features in a project should be called ALL.
Corrective Action
To resolve this error, change the name of the feature to something other than ALL. For more information, see Creating
Features.
You can also resolve this error by clicking the ISBP01 error message in the Output window. InstallShield displays the
Feature table in Direct Editor view, and highlights the row that contains the feature named ALL. To rename the feature,
select the current name and then type a new one.
See Also
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP02
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
Directory DATABASE conflicts with Windows Installer's undocumented directory DATABASE.
Description
ISBP02 verifies that your installation does not have a directory called DATABASE in uppercase, lowercase, or mixed case
letters. Windows Installer reserves this directory name.
Corrective Action
To resolve this error, click the ISBP02 error message in the Output window. InstallShield displays the Directory table in
Direct Editor view, and highlights the row that contains the directory named DATABASE. To rename the directory, select
the current name and then type a new one.
See Also
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP03
InstallShield 2020
• Basic MSI
• MSI Database
Message (Warning)
ComboBox [1] on Dialog [2] has a height less than 50. This results in a ComboBox too short to view
multiple items at once.
[1] is the name of a combo box control, and [2] is the name of the dialog that has that control.
Description
If a combo box control has a height of less than 50 installer units, end users may be able to see only one item in the box at a
time. To improve the usability, consider changing the height to 50 or higher.
Corrective Action
To resolve this warning, click the ISBP03 warning message in the Output window. InstallShield displays the Control table
in Direct Editor view, and highlights the row that contains the combo box control. Then change the value in the Height
column for that control to 50 or higher.
See Also
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP04
InstallShield 2020
• Basic MSI
• MSI Database
Messages
Message 1 (Warning)
Dialog [1] Control [2] uses private property [3]. Its value will be unavailable to the execute sequence.
[1] is the name of a dialog in your project, [2] is the name of a control on that dialog, and [3] is the name of a private
property that is being set or used by the control.
Message 2 (Warning)
Dialog [1] Control [2] uses insecure custom property [3]. Its value may be unavailable to the execute
sequence.
[1] is the name of a dialog in your project, [2] is the name of a control on that dialog, and [3] is the name of a property that is
used by that control.
Description
You cannot set a private property in the user interface sequence of the installation and then pass the value of that private
property to the execute sequence. Therefore, ISBP04 verifies that your installation does not have any dialog controls that
use private properties. If a dialog control does use a private property, warning 1 occurs to alert you that you may need to
take steps to allow a property’s value to be passed to the execute sequence.
In addition, if you set a public property in the user interface sequence of an installation that requests elevated privileges for
the execute sequence, and you want to pass the property’s value to the execute sequence, the property must be listed as a
value for the SecureCustomProperties property, or it must be a restricted public property. Therefore, ISBP04 also verifies
that if your installation has dialog controls that use custom public properties, the custom public properties are listed as
values for the SecureCustomProperties property. If the custom public properties are not listed in the
SecureCustomProperties property, warning 2 occurs to alert you that you may need to take steps to allow a property’s
value to be passed to the execute sequence.
Corrective Action
If you do not need to use the property in the execute sequence, you can disregard the warning message. However, if you do
need to use the property in this sequence, you need to resolve the warning.
If you need to resolve warning 1, change the private property to a public property. To do so, find the dialog control in the
Dialogs view; for the Property property of that control, use all uppercase letters, since public properties must be in all
uppercase. Also update all other instances of that property name in your project so that it matches.
If you need to resolve warning 2, open the Property Manager view. For the Value column of the SecureCustomProperties
property, add the name of the property that is mentioned in the warning message. If this property contains more than one
property, separate each one with a semicolon (;).
See Also
Private Properties (Windows Installer Help Library)
Private Properties (Windows Installer Help Library)
Public Properties (Windows Installer Help Library)
Public Properties (Windows Installer Help Library)
SecureCustomProperties Property (Windows Installer Help Library)
SecureCustomProperties Property (Windows Installer Help Library)
Specifying that a Public Property Should Be a Restricted Public Property
Property Manager View
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP05
InstallShield 2020
• Basic MSI
• MSI Database
Message (Warning)
Dialog [1] Control [2] has a NULL condition. To ensure the control event always runs, use a condition of
1.
[1] is the name of a dialog in your project, and [2] is the name of a control on that dialog.
Description
ISBP05 verifies that each event’s condition for each dialog control is not null. This helps to ensure that Windows Installer
triggers the control’s events under the proper circumstances.
Corrective Action
If Windows Installer should trigger the event that has a null condition only if no other event for that control is triggered, you
can disregard the warning message.
If you do need to resolve this warning, locate the dialog in the Dialogs view. Click the Behavior item under the dialog. In the
list of controls, click the one that is mentioned in the warning message. Ensure that in the lower-right pane, the Events tab
is displayed. Then, in the grid in the upper-right pane, enter a condition for the event. To ensure that Windows Installer
triggers the event, enter 1 as the condition.
See Also
ControlEvent Table (Windows Installer Help Library)
ControlEvent Table (Windows Installer Help Library)
Conditional Statement Syntax (Windows Installer Help Library)
Conditional Statement Syntax (Windows Installer Help Library)
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP06
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Warning)
Custom Action [1] is scheduled in the InstallUISequence but not the InstallExecuteSequence. It will not
run during a silent or reduced UI installation.
Description
Actions that are scheduled for the Execute sequence during the Installation sequence do not run during silent, basic UI, or
reduced UI installations.
Corrective Action
If Windows Installer should launch the custom action during silent, basic UI, and reduced UI installations, consider
scheduling the custom action for the installation execute sequence—in addition to or instead of the installation UI
sequence.
To reschedule the action, open the Custom Actions and Sequences view, and find the action mentioned in the warning
message. Then drag it from the Installation sequence’s User Interface sequence to the Installation sequence’s Execute
sequence.
To schedule the action in both sequences, copy the action in the Installation sequence’s User Interface sequence to the
Installation sequence’s Execute sequence. You can do this in the Custom Actions and Sequences view by pressing and
holding CTRL while dragging the action from the former sequence to the latter sequence.
If Windows Installer should not launch the custom action during silent, basic UI, and reduced UI installations, you can
ignore this warning.
See Also
Inserting Actions into Sequences
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP07
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Warning)
Feature [1] has no components.
Message 2 (Warning)
Component [1] is not associated with any features.
Description
ISBP07 verifies that every component in your project belongs to at least one feature. If you do not associate a component
with at least one feature, Windows Installer cannot install the component.
ISBP07 also verifies that every feature in your project contains at least one component. Components contain the
installation elements, such as files, shortcuts, and registry entries; if a feature does not contain a component, it does not
contain anything to install.
Corrective Action
To resolve either of these warnings, use the Setup Design view to associate components with features. To learn more, see
Associating Existing Components with Features.
See Also
Installation Fundamentals
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP08
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Warning)
There does not appear to be a Type 51 action setting ARPINSTALLLOCATION after CostFinalize in the
InstallExecuteSequence.
Description
The ARPINSTALLLOCATION property specifies the fully qualified path to the primary destination folder of a product.
Windows Installer writes this value to the Uninstall registry key.
The ARPINSTALLLOCATION property is typically set by a set-a-property type of custom action (type 51).
The SetARPINSTALLLOCATION custom action is a built-in InstallShield custom action that is added automatically to Basic
MSI and InstallScript MSI projects. If you delete this custom action from your project, you may encounter the ISBP08
warning.
Corrective Action
To resolve this warning, add to your project a custom action with the following settings:
Note • As a best practice, any actions after CostFinalize should be sequenced after MigrateFeatureStates when feature
migration is selected on a major upgrade item.
For more information, see Creating Custom Actions in the Custom Actions and Sequences View (or the Custom Actions
View).
See Also
ARPINSTALLLOCATION Property (Windows Installer Help Library)
ARPINSTALLLOCATION Property (Windows Installer Help Library)
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP09
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
The property LIMITUI has been set, but ARPNOMODIFY has not. This can lead to undesirable behavior with
Add or Remove Programs.
Description
If you set the LIMITUI property in an installation, you should also set the ARPNOMODIFY property.
The LIMITUI property sets the user interface level to basic. An installation run with a basic UI typically displays only
progress messages to end users. It does not allow end users to select features or provide other feedback.
The ARPNOMODIFY property prevents end users from modifying the product through Add or Remove Programs.
Corrective Action
To resolve this error, add the ARPNOMODIFY property to your project through the Property Manager view, and set its value
to 1. For more information, see Creating Properties in Windows Installer–Based Projects.
See Also
User Interface Levels (Windows Installer Help Library)
User Interface Levels (Windows Installer Help Library)
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP10
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Warning)
AppSearch [1] uses insecure custom property [2]. Its value may be unavailable to the execute sequence.
[1] is the name of a system search in your project, and [2] is the name of a property that is used by that system search.
Description
If you set a public property in the user interface sequence of an installation that requests elevated privileges for the execute
sequence, and you want to pass the property’s value to the execute sequence, the property must be listed as values for the
SecureCustomProperties property, or it must be a restricted public property. Therefore, ISBP10 verifies that if the
AppSearch table in your project contains custom public properties, the custom public properties are listed as values for the
SecureCustomProperties property. If the custom public properties are not listed in the SecureCustomProperties
property, the warning occurs to alert you that you may need to take steps to allow a property’s value to be passed to the
execute sequence.
Corrective Action
If you do not need to use the property in the execute sequence, you can disregard the warning message. However, if you do
need to use the property in this sequence, you need to resolve the warning.
To resolve this warning, open the Property Manager view. For the Value column of the SecureCustomProperties property,
add the name of the property that is mentioned in the warning message. If this property contains more than one property,
separate each one with a semicolon (;).
See Also
Property Manager View
Adding a System Search
SecureCustomProperties Property (Windows Installer Help Library)
SecureCustomProperties Property (Windows Installer Help Library)
AppSearch Table (Windows Installer Help Library)
AppSearch Table (Windows Installer Help Library)
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP11
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Warning)
File [1] appears to be a precompiled native image of a .NET assembly. This may decrease the efficiency
compared to precompiling on the target machine.
Description
ISBP11 verifies that your project does not include a precompiled native image of a .NET assembly.
Corrective Action
To resolve this warning, replace the native image file mentioned in the message with the appropriate .NET assembly file.
If you want the assembly to be compiled to machine code during the installation, select Yes for the .NET Precompile
Assembly setting of the file’s component.
Precompilation, or just-in-time compilation, takes into account the fact that some code might never be called during
execution. It converts the assembly as it is needed during execution and stores the resulting native code so it is accessible
for subsequent calls. Precompiling on the target machine allows the process to take advantage of the exact architecture of
the machine on which it will be running.
See Also
Component Settings
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP12
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Error)
Custom Action [1] appears to invoke self-registration via RegSvr32. Best practices encourage authoring
COM and Registry table data into the installer package.
[1] is the name of a custom action in your project that may be registering a file through RegSvr32.exe at installation time.
Message 2 (Error)
File [1] is self-registered. Best practices encourage authoring COM and Registry table data into the
installer package.
Description
Although InstallShield lets you designate that a COM server is self-registering, the preferred method of registering a COM
server is to extract the COM information from the file at build time or design time; with this method, InstallShield writes the
COM class information to the Class, ProgID, and Registry tables of the .msi database. Self-registration has several
limitations; for details, see Self-Registering COM Servers.
Corrective Action
To resolve error 1, remove the custom action that is referenced in the error message, and configure COM extraction for the
file as appropriate.
See Also
Traditional COM Registration
Registry-Free COM Registration
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP13
InstallShield 2020
• Basic MSI
• MSI Database
Message (Error)
Property [1] has no default, is set by a dialog control, and is used in table [2]. This may not be
populated in a silent or reduced UI installation.
[1] is the name of a property in your project, and [2] is the name of the table that uses that property.
Description
In most cases, each property in the Property table should have a default value. The default value is used if end users run
the installation in silent, reduced UI, or basic UI mode.
Corrective Action
If you do not need to add a default value for the property, you can disregard the error message.
To resolve this error, open the Property Manager view. Enter a value in the Value column for the property that is specified in
the error message.
See Also
Property Manager View
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP14
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Error)
File [1] has neither a file version nor an MsiFileHash record. This may require the source package when
installing a patch.
Message 2 (Error)
File [1] is recorded as version [2] but is actually version [3]. This may require the source package when
installing a patch.
[1] is the name of file in your project. [2] is the version number that is configured for the file, but [3] is the actual version
number.
Description
ISBP14 verifies that each file in the project has the correct version information or an MsiFileHash entry. Using the correct
version information in versioned files and MsiFileHash entries for unversioned files helps Windows Installer to detect and
eliminate unnecessary file copying. It also helps ensure that the source package is not required to apply a patch to an
earlier version of a product.
Corrective Action
To resolve error 1, consider adding the file version number to the file. If the file is an unversioned file, configure the file so
that a file hash is used.
InstallShield enables you to override a file’s version information. Error 2 may occur if the file’s properties were overridden.
To resolve this error, consider removing the version override.
To configure the settings for a file, open the Files and Folders view. In the Destination computer’s files pane, locate the
file, right-click it, and click Properties. The Properties dialog box opens, enabling you to configure version information and
specifying whether file hashing should be used.
See Also
File Properties Dialog Box
File Table (Windows Installer Help Library)
File Table (Windows Installer Help Library)
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP15
InstallShield 2020
• Basic MSI
• MSI Database
Message (Error)
Control [2] on the Dialog [1] is a borderless RadioButtonGroup with overlapping controls and data in the
Text column. This may cause repaint issues on some systems.
Description
ISBP15 verifies that if you have a borderless radio button group control on a dialog and one or more other controls overlap
the radio button group, the radio button group does not have anything specified for its Text attribute. If it does, it may
cause repaint issues for some versions of Windows Installer.
Corrective Action
To resolve this error, click the ISBP15 error message in the Output window. InstallShield displays the Control table in
Direct Editor view, and highlights the row that contains the radio button control that is mentioned in the error message.
Delete the string in the Text column for that radio button control.
As an alternative, you can change the radio button group control so that it uses a border. To do this, open the Dialogs view
and find the dialog mentioned in the error message. Click the radio button control, and change its Has Border property to
True.
See Also
RadioButtonGroup Control (Windows Installer Help Library)
RadioButtonGroup Control (Windows Installer Help Library)
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP16
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
Component [1] installed to 64-bit location [2] is not marked with the 64-bit component attribute. This
may allow files to be installed to an incorrect location.
[1] is the name of a component, and [2] is the destination folder for the component’s files.
Description
If a component is not configured to be 64 bit, Windows Installer may not install the component’s files to the appropriate 64-
bit location.
Corrective Action
To specify that a component is 64 bit, select Yes for the component’s 64-Bit Component setting.
For more information about the 64-Bit Component setting, as well as additional component settings, see Component
Settings.
See Also
Targeting 64-Bit Operating Systems
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP17
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Error)
File [1] in Component [2] is a WinHelp file and may not be distributed to Windows Vista or later.
[1] is the name of an .hlp file in your project, and [2] is the name of the component that contains the .hlp file.
Message 2 (Error)
File [1] in Component [2] is a WinHelp run-time file and may not be distributed to Windows Vista or
later.
[1] is the name of a Windows Help application file in your project, and [2] is the name of the component that contains that
file.
Description
ISBP17 verifies that .hlp files are not included in your project because Windows Vista and later do not support this type of
file.
In addition, ISBP17 verifies that WinHlp32.exe and WinHelp.exe are not included in the project because these applications
should not be redistributed.
Corrective Action
To resolve this validation error, remove the help file from your project. Consider converting your help system to a different
file format such as .chm, .htm, or .xml. Note that you would need to change your calls from the WinHelp API to the new help
system.
See Also
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP18
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
File [1] in Component [2] imports obsolete API [3].
[1] is the name of a file in your project, and [2] is the name of the component that contains the file. [3] is the name of the
obsolete API that the file uses.
Description
ISBP18 verifies that none of the .dll or .exe files in your project use obsolete kernel APIs.
Corrective Action
To resolve this validation error, replace the file with an updated version that does not use the obsolete API. Note that to
create the updated version, you may need to rewrite and rebuild the .exe or .dll file. If the .exe or .dll file is from a third-
party vendor, contact the vendor to request an updated version.
See Also
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP19
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Message (Error)
File [1] in Component [2] imports deprecated API [3].
[1] is the name of a file in your project, and [2] is the name of the component that contains the file. [3] is the name of the
deprecated API that the file uses.
Description
ISBP19 verifies that none of the .dll or .exe files in your project use deprecated kernel APIs.
Corrective Action
To resolve this validation error, replace the file with an updated version that does not use the deprecated API. Note that to
create the updated version, you may need to rewrite and rebuild the .exe or .dll file. If the .exe or .dll file is from a third-
party vendor, contact the vendor to request an updated version.
See Also
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
ISBP20
InstallShield 2020
• Basic MSI
• InstallScript MSI
• MSI Database
Messages
Message 1 (Error)
Registry entry [1] contains an asterisk in the Name column. This will cause Windows Installer to attempt
to remove a root registry key [2].
[1] is the name in the Registry table’s Registry column for the registry entry row that has the asterisk (*). [2] is the name of
the registry key that would be removed during uninstallation.
Message 2 (Warning)
Registry entry [1] installs to a key that is not recommended for installation with software
applications. Installing this entry could have an adverse effect on target machines ([2]).
[1] is the name in the Registry table’s Registry column for the registry entry row that may cause issues on the target
system. [2] is the name of the registry key.
Description
ISBP20 verifies that your project does not include any registry entries that would remove root-level registry keys such as
HKEY_LOCAL_MACHINE\SOFTWARE if your product is removed from a target machine. The following table shows an
example of some registry data that would cause issues during uninstallation; in this example, the entire
HKEY_LOCAL_MACHINE\SOFTWARE, and all of its subkeys and values, would be removed.
Valu
Registry Root Key Name e Component
ISBP20 also verifies that your project does not include other registry entries that would cause adverse issues on target
machines.
Corrective Action
To resolve the validation error or warning, click the ISBP20 message in the Output window. InstallShield displays the
Registry table in Direct Editor view, and highlights the row that contains the potentially problematic registry entry. To
delete the registry entry, right-click the row and then click Drop Row(s).
See Also
Registry Table (Windows Installer Help Library)
Registry Table (Windows Installer Help Library)
Requirements for the Windows Logo Program
InstallShield Best Practice Suite
• InstallScript
• InstallScript MSI—if the InstallScript user interface (UI) style is the traditional style (which uses the InstallScript engine as
an external UI handler)
This information does not apply to InstallScript MSI projects in which the InstallScript UI style is the new style (which uses the
InstallScript engine as an embedded UI handler). To learn more, see Using the InstallScript Engine as an External vs.
Embedded UI Handler for InstallScript MSI Installations.
The BATCH_INSTALL system variable is set to a non-zero value to indicate that one or more operations need to be
performed after the target system restarts. For example, BATCH_INSTALL can be set to a non-zero value if the installation
determines that a file cannot be installed because the file already exists on the target system and it is locked.
When a file in an installation cannot be installed because it is locked, the installation automatically notifies the operating
system that the file needs to be updated the next time that the system restarts. Because the file may need to be updated
before additional Windows files are loaded, it is updated when Windows is loaded; it is not updated by the InstallScript
installation.
BATCH_INSTALL can be set during an uninstallation in order to remove locked files after the system restarts. However,
after the reboot, the cached installation files are no longer present. Therefore, the only reboot-related operations that can
occur are those that the operating system can perform.
If BATCH_INSTALL is set to a non-zero value when the file transfer finishes, the following occurs:
• The installation does not attempt to self-register any files. This is because it may be necessary for all of the
installation’s files to be completely installed and updated before the files can be self-registered successfully. Note that
this is true regardless of whether the files that could not be installed are self-registering, since the installation assumes
that these files could be dependencies of other self-registering files. In this case, the installation records the files that
need to be self-registered so that after the restart, the installation can self-register those files.
• The framework automatically calls SdFinishReboot (in the OnFirstUIAfter or OnMaintUIAfter events) to give the end
user the option of automatically restarting the system after the installation completes.
• When the installation finishes, it creates an appropriate RunOnce registry value so that the installation runs after the
restart; after the restart, the installation is run with the /reboot parameter.
If the ALLUSERS script variable is set to 1, the RunOnce entry is created under HKEY_LOCAL_MACHINE; otherwise, the
entry is created under HKEY_CURRENT_USER. Windows supports RunOnce entries under both of these locations.
The RunOnce registry value’s name is InstallShield Setup %n, where %n is the lowest integer available to make a
unique key name. The registry value’s data is the complete command line for the installation to run after restart; the
command line includes the path and file name of Setup.exe.
After restart, the installation is run from the installed Disk1 location—DISK1TARGET. Thus, for the installation to run
after restart, the Disk1 files for the installation must be currently installed.
Note that this does not apply to an uninstallation, since after the restart, the cached installation files are no longer
present.
When the installation runs after the restart (that is, when it runs with the /reboot parameter), the following occurs:
• Any self-registering files that were noted by the installation as needing to be registered are registered.
Note that for an uninstallation, the installation does not run after the restart; therefore none of these operations can occur.
See Also
BATCH_INSTALL
You can debug a Windows Installer–based release using the MSI Debugger. The MSI Debugger enables you to view and set
Windows Installer properties as you step through the package’s User Interface and Execute sequences.
The MSI Debugger runs through each action and dialog until it reaches your breakpoint, at which point it halts execution.
Now, you can view and set properties in the Watch window and the Variable window. Finally, you can step through each of
the remaining actions, or you can stop the debugger.
Note • Do not confuse the MSI Debugger with the InstallScript Debugger, since they have completely separate purposes. You
cannot debug an installation package with the InstallScript Debugger, and you cannot debug an InstallScript custom action
with the MSI Debugger.
See Also
MSI Debugger
Working with Windows Installer and Advanced UI or Suite/Advanced UI Properties
User Interface Sequence
Execute Sequence
Before starting the MSI Debugger, you must have built a release and opened the MSI Debugger view in InstallShield. In
addition, you should always set a breakpoint so that you can view the state of the installation at a particular action or
dialog.
When you open the MSI Debugger and begin debugging, it acts on the release that currently has focus in the Releases view.
If you have not yet built the release or if the release is compressed into Setup.exe, the debugger is blank and its toolbar
and menu items are disabled. Switch to a built release or rebuild with the required options to debug the package.
• On the Build menu, point to MSI Debugger and click Start MSI Debugging.
• On the Build menu, point to MSI Debugger and click Step Over.
• Press F5.
• Press F11.
The debugger runs the installation, returns focus to itself, and stops the execution of the installation when it reaches the
breakpoint. Back in the debugger, you can do any of the following:
See Also
MSI Debugger
MSI Debugger Toolbar
2. Open the MSI Debugger view. The debugger displays two lists: first every standard and custom action in the User
Interface sequence, and then every dialog in the installation.
3. Place the cursor on the line that contains the action or dialog on which you want the debugger to break.
• On the Build menu, point to MSI Debugger and click Toggle Breakpoint.
• Press F9.
You can set the breakpoint before you start debugging or while a debugging session is open.
When the debugger reaches the breakpoint, you can view and set properties or continue debugging.
Tip • Notice that the debugger lists the condition, if any, after each action. Set breakpoints carefully on conditional actions,
because if the condition does not evaluate to true, the action is not executed and the debugger will not step in at that point.
Removing Breakpoints
InstallShield 2020
2. Place the cursor in a line with a breakpoint and click the Toggle Breakpoint button or press F9 to remove it.
Task To clear all breakpoints set in the debugger, do one of the following:
• Press SHIFT+F9.
When the debugger stops at a breakpoint or at an action or dialog because you are stepping through the installation, you
can view Windows Installer properties and change their values at run time in the Watch window or the Variable window.
To change a property’s value as the installation is running, edit the Property Value column.
If you do not see the Variable window, click Variable on the View menu.
To change the property’s value as the installation is running, edit the Property Value column.
If you do not see the Watch window, click Watch on the View menu.
See Also
MSI Debugger
You can debug your code when you step into the custom action in the MSI Debugger. You can launch your registered
debugger when you step into one of the following types of custom actions:
Task To step into the current action in the MSI Debugger, do any of the following:
• On the Build menu, point to MSI Debugger and click Step Into.
• Press F11.
A dialog box opens and asks if you want to launch your registered debugger. Select Yes to launch the deubugger. Select No
to step over to the next custom action.
Note • Because InstallShield does not provide the source code for the entry point, you will see some machine code once the
registered debugger is launched. You need to click the Step Into button twice to see your code.
See Also
MSI Debugger
MSI Debugger Toolbar
Task To step over the current action or dialog and continue the execution in the MSI Debugger, do any of the following:
• On the Build menu, point to MSI Debugger and click Step Over.
• Press F10.
Once the debugger reaches a breakpoint on a standard or custom action, it halts the execution of the installation and
receives focus. You can then watch and set installer properties.
To continue stepping through each successive action, keep pressing F10. You may need to click Next on each dialog in the
Setup wizard to progress through the sequence. To view the return value of an action, place the cursor over the action after
it has executed. The return value is displayed as a tooltip. If the action executed successfully, the tool tip reads
ERROR_SUCCESS.
Although setting a breakpoint on an action causes the debugger to break at each subsequent action, setting a breakpoint
on a dialog takes you just to that dialog and then the debugger does not step in again until the next breakpoint.
See Also
MSI Debugger
MSI Debugger Toolbar
• On the Build menu, point to MSI Debugger and click Stop MSI Debugging.
• Press SHIFT+F5.
If the debugger is stopped at a break point on a dialog when you try to end the debugging session, InstallShield displays a
message box with this message: “Please close all the dialogs to stop the debugging session.” To close any open dialogs,
first press F11 to step over the current breakpoint. Then, close any open dialogs.
See Also
MSI Debugger
MSI Debugger Toolbar
As programs become larger, the need for disk spanning increases. Years ago, this meant shipping your product on multiple
floppy disks. The standard is now to use CD-ROMs or DVDs. Although the storage space on a CD or on a DVD is significantly
more than what is available on a floppy disk, many products require even more space. Multimedia tutorials, vast help
libraries, and graphic-rich programs can result in a product that is larger than 650 MB—the size of a standard CD.
If your installation requires more than one CD, DVD, or custom-sized media disk, you need to span it across multiple disks.
The wizard offers you the choice of having InstallShield automatically span your installation across disks, if necessary, or
you can customize how you want your installation files to be split. If you plan on customizing the way your installation
spans across multiple disks, refer to Disk Spanning Rules to reduce problems with your installation.
Limitations
Due to limitations of the Windows Installer service, you cannot run multi-disk installations on a non-removable drive. For
example, if your installation spans two CDs, you need to physically burn the CDs in order to test your installation. If you try
to run it from a fixed drive, the installation will fail.
Because neither Setup.exe nor your .msi file can be spanned across multiple disks, your source files need to be kept
separate from these files. If you create a network installation, which has unlimited size, and specify that all the files should
be compressed, these files are placed inside the .msi file or inside Setup.exe if you elected to create one. All other media
types put Setup.exe, your .msi file, and the .cab files that contain all of your source files separately on the media.
For example, you might have an installation that contains three features—each containing a 1.5 MB file, Setup.exe, and the
installation files for Windows NT—and you want to create a custom media type that is 2 MB in size. The build will span
multiple disks. Disk one will contain Setup.exe, InstMsiW.exe (which contains the logic to install the Windows Installer
service on Windows NT machines), Setup.ini (which is required for installations that include Setup.exe), and your .msi
file. The remaining disks will contain .cab files that store compressed copies of all your source files.
You can elect to have the Release Wizard automatically span your installation across as many disks as required. The wizard
adheres to the following rules, which all multi-disk installations must follow. If you plan to customize how your installation
spans across multiple disks, follow these rules:
• Setup.exe must be on disk one. This rule is applicable if you want to ship your installation on floppy disks and you
need to ship Setup.exe. The size of Setup.exe—depending on whether you choose one for Windows 9x, Windows NT,
or both—can be 1.31 MB to 2.58 MB in size. The installation file for the Windows Installer service is included in the build
as well. This file—called InstMsiW.exe or InstMsiA.exe, depending on the platform you choose—must also reside on
disk one.
• The second file that must be included on disk one is the .msi file that you are building. The total combined size of
the .msi file, Setup.exe, and the Windows Installer installation files exceeds the maximum capacity of a standard 1.4
MB floppy disk. You have two options if you plan to distribute your setup on floppy disks:
• You can distribute your installation without Setup.exe. This option is not available if you are creating an
InstallScript MSI project.
• The second and most feasible option is to use a distribution medium other than floppy disks.
• Any transforms included in your installation must reside on the first disk. For example, if you create an
installation with multiple run-time languages, an .mst file is created for each of those languages. This file is applied to
the installation database, and it provides the language selected in the Language Selection dialog.
• Redistributables (including merge modules) included in your installation must be stored on the first disk.
Redistributables are streamed into the installation database while the script is built. This process cannot be
completed if the redistributables are located on another disk.
In the Release Wizard, you will come across a panel that asks you how you would like to handle disk spanning. You can
choose to let the wizard automatically span your installation across disks if necessary, or you can manually define the disk
spanning. Although you cannot indicate where every file is placed, you can define the disk on which each feature resides.
Components and files are automatically placed on the same disk as their feature. There are other guidelines that
InstallShield automatically follows, whether you choose to define the layout or let the wizard do it for you.
In addition to defining the features that reside on each disk, you can customize the volume label for each disk, create your
own disk prompts, and choose to have the wizard enforce the size of your disks. The step-by-step instructions for
customizing your disk layout are outlined in the Release Wizard documentation.
Disk Prompts
Disk prompts are displayed to end users when they need to place another disk in the drive to continue with the installation.
Although a standard disk prompt is provided, you can provide a prompt that is specific to your product.
The string that is displayed actually comes from a number of sources throughout your project, as described below:
1. The complete prompt originates in the Error table (exposed in the Direct Editor) as error 1302.
2. This value comes from the project’s list of string entries, and the default value for English is “Please insert the disk:
[2].”
3. Windows Installer resolves [2] with the value of the property DiskPrompt, which is set to [1] in the Property Manager.
4. Finally, Windows Installer evaluates [1] to the string you enter into the Disk Prompt field.
In most cases, you will want to enter the same name as the disk volume. For example, assuming the defaults are
unchanged, a Disk Prompt entry of Disk8 would cause the user to be prompted with “Please enter the disk: Disk8.”
You can use a question mark where the disk number will be displayed. This question mark automatically evaluates to the
correct disk number. If you want to prompt your users with, “Please insert the disk: DISK4,” you would enter DISK? for the
fourth disk’s name. You need to specify the disk prompt for each disk in your installation.
Volume Labels
The volume label is the name of the disk on which your installation resides. When the installation calls for a new disk, the
Windows Installer engine verifies that the volume label of the disk matches the volume label that is stored in the
installation database. If the labels do not match, the service assumes that the wrong disk has been inserted in the drive.
You can change the volume label when you customize your disk spanning options. The default volume label is DISK1,
DISK2, DISK3, and so on. When you build your installation, you will see these directories created in your output location.
The disks on which you put your setup need to have the volume labels set to the same names as given by the wizard.
Caution • You cannot change a volume label after the installation has been built. If you do not specify the correct volume
label, the Windows Installer service will not recognize the disk and the installation will fail.
You can use a question mark to define the number of the disk. For example, if you want to set the volume label for your
disks to InstallShield Disk 1, InstallShield Disk 2, and so on, you would rename every disk so that they read
InstallShield Disk ?. At build time, this question mark evaluates to the disk number.
Additional Information
If you add features to your installation after you have defined how you want your installation to span across multiple disks,
those features are automatically added to the last disk of your installation. You can add new disks to your installation at
any time by using the Release Wizard.
• Basic MSI
• InstallScript MSI
Advanced UI and Suite/Advanced UI installations also always creates a setup launcher; they run .msi, .msp, InstallScript, and
.exe packages. To learn more, see Creating Advanced UI and Suite/Advanced UI Installations.
InstallShield lets you specify whether you want your installation to include a Setup.exe setup launcher. A Setup.exe setup
launcher is required in the following cases:
• You want to automatically update or install the Windows Installer engine on a target system, when necessary.
• You are building a multilanguage installation project and you want the language selection dialog to be displayed.
• You are building a release for an InstallScript MSI project and it uses the traditional style for the user interface.
• You are building a release whose product configuration includes support for installing multiple instances of a product
and you want the instance selection dialog to be displayed when appropriate.
• You are building a release for a Basic MSI project that includes billboards.
The Setup.exe setup launcher is a bootstrap application that manages the aforementioned scenarios.
The Setup.exe tab for a release in the Releases view is where you specify information such as whether you want to use a
Setup.exe launcher. To learn more, see Setup.exe Tab for a Release.
Tip • You can also specify setup launcher requirements in the Setup Launcher panel of the Release Wizard.
If you plan to distribute your installation in more than one language, Setup.exe is required whenever you want to provide
end users the option of selecting which language version of the installation they would like to run. To learn more about
multilanguage support, see Creating Multilingual Installations.
To learn more about including the .NET Framework, see Adding .NET Framework Redistributables to Projects.
Note that if you use the new style of UI for an InstallScript MSI installation, InstallShield embeds the InstallScript engine
within the .msi package, and a setup launcher is not required.
For detailed information about these two styles, see Using the InstallScript Engine as an External vs. Embedded UI Handler
for InstallScript MSI Installations.
To learn more about multiple-instance support, see Installing Multiple Instances of Products.
For more information about billboards, see Displaying Billboards in Basic MSI Installations.
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• Suite/Advanced UI
InstallShield lets you use custom information for the version resources of the Setup.exe setup launcher. The information is
displayed on the Properties dialog box for the setup launcher; this Properties dialog box opens when end users right-click
the Setup.exe file and then click Properties.
Note • The Properties dialog box is different on different versions of Windows. For example, on Windows 7 systems, the
version resource information is displayed on the Details tab of the Properties dialog box. However, on Windows XP systems, the
version resource information is displayed on the Version tab of that dialog box.
Also note that some versions of Windows do not show some settings on the Properties dialog box.
Company Name The setting that contains the value for this field varies, depending on the
project type that you are using.
• In Basic MSI and InstallScript MSI projects: Publisher setting in the General
Information view.
If you want InstallShield to use your own custom value for the company field in
an Advanced UI or Suite/Advanced UI project:
1. In the Releases view, select the release that you want to configure.
3. In the Company setting, enter the text that you want to use for the
company field in the properties of your Setup.exe file.
If you select No for the Use Custom Version Properties setting or you leave the
Company setting blank, InstallShield uses the Publisher setting in the General
Information view. If that setting is blank, InstallShield uses the default
InstallShield-specific name.
Product Name The setting that contains the value for this field varies, depending on the
project type that you are using.
• In Basic MSI and InstallScript MSI projects: Product Name setting for the
product configuration in the Releases view. If that setting is blank,
InstallShield uses the Product Name setting in the General Information
view.
Product Version The setting that contains the value for this field varies, depending on the
project type that you are using.
• In Basic MSI and InstallScript MSI projects: Product Version setting for the
product configuration in the Releases view. If that setting is blank,
InstallShield uses the Product Version setting in the General Information
view.
1. In the Releases view, select the release that you want to configure.
3. In the Version setting, enter the value that you want to use for the version
fields in the properties of your Setup.exe file.
If you select No for the Use Custom Version Properties setting or you leave the
Version setting blank, InstallShield uses the Version setting in the General
Information view. If that setting is blank, InstallShield uses the default
InstallShield-specific values.
File Version The setting that contains the value for this field varies, depending on the
project type that you are using.
• In Basic MSI, InstallScript MSI, InstallScript: Use the File Version setting
for Setup.exe under Use Custom Version Properties in Releases view.
If this setting is blank, InstallShield uses the Product Version value by default.
Note • The File Version always contains four fields. If you specify fewer than four
fields for your File Version, the remaining fields are filled with zeros. For example,
if you specify a File Version of 1.1, the File Version that is used in the version
resources of Setup.exe is 1.1.0.0.
If you want to override the File Version, set Use Custom Version Properties to
Yes and enter a version in the File Version field.
1. In the Releases view, select the release that you want to configure.
2. On the Setup.exe tab, set the Use Custom Version Properties setting to
Yes.
3. In the File Version field, enter the value that you want to use for the File
Version field in the Properties of your Setup.exe file.
If you select No for the Use Custom Version Properties setting or you leave
the File Version setting blank, InstallShield uses the File Version setting in the
Product Version from the Product Configuration view for both (Basic MSI and
InstallScript MSI) and in the General Information view for InstallScript. If that
setting is blank, InstallShield uses the default InstallShield-specific values.
Copyright InstallShield uses either a custom value that you provide, or the default
InstallShield copyright notice.
If you want InstallShield to use your own custom value for the copyright field:
1. In the Releases view, select the release that you want to configure.
3. In the Launcher Copyright setting, enter the text that you want to use for
the copyright field in the properties of your Setup.exe file.
If you select No for the Use Custom Version Properties setting or you leave the
Launcher Copyright setting blank, InstallShield uses the default InstallShield
copyright notice.
File Description InstallShield uses either a custom value that you provide, or the default
InstallShield Setup.exe description.
If you want InstallShield to use your own custom value for the description field:
1. In the Releases view, select the release that you want to configure.
3. In the File Description setting, enter the text that you want to use for the
description field in the properties of your Setup.exe file.
In a Basic MSI or InstallScript MSI project—If you select No for the Use Custom
Version Properties setting, InstallShield uses the default InstallShield Setup.exe
description. If you select Yes but leave the File Description setting blank,
InstallShield uses the value for the Comments setting of the product
configuration in the Releases view. If that setting is blank, InstallShield uses the
Summary Information Stream Comments setting in the General Information
view. If that setting is blank, InstallShield uses the default InstallShield
Setup.exe description.
Language For this field, InstallShield uses the language that is specified in the Default
Language setting for the release in the Releases view that you are building.
Original File Name InstallShield uses either a custom value that you provide, or the default
InstallShield file name - Setup.exe.
If you want InstallShield to use your own custom value for the Original File
Name field:
3. On the General tab, in the Setup File Name setting, enter the text that
you want to use for the Original File Name field.
Specify the file name - without the .exe file extension - that InstallShield should
use for the Original File Name that it generates at build time.
See Also
Creating a Setup Launcher
Creating Advanced UI and Suite/Advanced UI Installations
General Information View Settings
Release Settings
Product Configuration Settings
• Advanced UI
• Basic MSI
• InstallScript
• InstallScript MSI
• Suite/Advanced UI
InstallShield lets you specify the icon that should be used for your Setup.exe setup launcher. The icon can be in an .exe,
.dll, or .ico file.
End users can see this icon when they view your Setup.exe file in Windows Explorer. The icon is also displayed on the
Properties dialog box for Setup.exe; this Properties dialog box opens when end users right-click the Setup.exe file and
then click Properties.
If you do not specify an icon, InstallShield uses a default icon for your Setup.exe file.
2. In the Releases explorer, select the release that you want to configure.
4. In the Setup.exe Icon File setting, specify the fully qualified name of the file that contains the icon that InstallShield
should use when it creates the Setup.exe file at build time.
To specify a file, type an explicit path or path variable, or click the ellipsis button (...) to open the Change Icon dialog
box, in which you can click the Browse button to select a file.
By default, the icon with index 0 is used; to specify a different icon, either select an icon in the Change Icon dialog box
or append the icon’s index or resource ID (preceded by a minus sign) to the file name. For example,
C:\Temp\MyLibrary.dll,2 indicates the icon with an index of 2, and C:\Temp\MyLibrary.dll,-100 indicates the icon
with a resource ID of 100.
The next time that you build the release, InstallShield uses the icon that you specified for your Setup.exe file.
See Also
Creating a Setup Launcher
General Information View Settings
Release Settings
Product Configuration Settings
Distributing Installations
InstallShield 2020
Once you have created your installation, you may need to distribute it to a specified location. This location can be a
network drive, a CD, a different location on a local drive, or an FTP site. When you distribute your installation, the disk
image created when you built your installation is copied to the location that you specify.
When your release is built and tested, the only remaining task is to distribute it to the appropriate location. You can
manually copy your release to the appropriate location, or you can use the Events tab in the Releases view to configure the
release so that InstallShield automatically copies the release to the appropriate location—a local or network location, or an
FTP site.
2. In the Releases explorer, select the release that you want to configure.
4. Configure the settings as appropriate. To learn more about the settings on the Events tab, see Events Tab for a
Release.
Note • If your installation consists of only one disk, the contents of the Disk1 folder are copied to the release location, but not
the folder itself. If your installation spans across multiple disks, the folders and their contents are copied to the release
location.
Project • For InstallScript and InstallScript Object projects, InstallShield automatically copies the release to the location that
you specify on the Events tab every time that you build the release.
For any of the following project types, InstallShield copies all of the relevant files for your release to the specified location
whenever you right-click the release in the Releases view and then click Distribute:
• Basic MSI
• InstallScript MSI
• Merge Module
If you specify a folder and an FTP site on the Events tab, InstallShield copies the files to only the FTP location.
If you want the build engine to copy your release to the specified location after every build in a Basic MSI, InstallScript MSI,
or Merge Module project, select Yes for the Distribute After Build setting.
See Also
Releases View
Edition • The ability to distribute releases to virtual machines is available in the Premier edition of InstallShield.
• Basic MSI
• InstallScript
• InstallScript MSI
• Suite/Advanced UI
You can configure releases in your projects so that after each successful build of your installation, InstallShield
automatically reverts a virtual machine (VM) to a designated snapshot (if one is specified), powers on the VM, and copies
your installation to the VM to make it available for testing. You can also alternately perform these testing preparation steps
on demand at any time. The testing preparation capability makes it possible to reduce testing time and eliminate manual
steps.
The VM can be on a Microsoft Hyper-V Server, a VMware ESX or ESXi Server, or a VMware Workstation.
If you are using VMware Workstation, it is recommended that you install VMware Workstation on the same machine as
InstallShield so that InstallShield uses the version of the VIX API that was designed for that specific version of VMware
Workstation. Although it is likely that newer versions of the VIX API will also work, it seems that the best approach is for
InstallShield to use the version of the VIX API that was bundled with your version of VMware Workstation.
Task To configure the VM-related settings for a release to enable distribution to the VM at build time or on demand:
2. In the Releases explorer, select the release that you want to configure.
5. Use the Configuration setting to select the name of the group of VM configuration settings that you want to use when
distributing the selected release to a VM:
• To create a new VM configuration, click the ellipsis button (...) in this setting.
• To edit an existing VM configuration, select it in this setting and then click the ellipsis button (...).
In both cases, the Edit Virtual Machine Configurations dialog box opens, enabling you to configure machine-wide VM
details. For information on using this dialog box, see Edit Virtual Machine Configurations Dialog Box.
Note that when you specify VM configuration settings in the Edit Virtual Machine Configurations dialog box,
InstallShield writes the data that you specify to a file called VMConfigurations.xml. This VMConfigurations.xml file is
a machine-wide file that you can configure once and then use it in other InstallShield projects, as well as share it with
other team members. You can also use this file on your build machine. To learn more, see Sharing Virtual Machine
Settings for Distribution of Releases.
If you configure VM details in these remaining settings, you are overriding some of the machine-wide values that were
entered on the Edit Virtual Machine Configurations dialog box.
For details about all of the settings in the Virtual Machine area, see Events Tab for a Release.
Tip • If you want InstallShield to distribute the release to the specified VM after each successful build, select Yes for the
Distribute After Build setting.
To perform the staging steps for a built release on demand, right-click the release and then click Distribute to VM.
See Also
Sharing Virtual Machine Settings for Distribution of Releases
Releases View
The way in which consumers receive software is rapidly changing. Before the advances in Internet technology and the
introduction of high-speed connections, all software was shipped on some type of removable medium, such as floppy disks
or CD-ROMs. Today, many people download their software directly from the Internet. In order to take advantage of this
time- and money-saving software distribution process, you must package your installation in an easily downloadable and
installable manner.
There are several criteria that your Web-ready installation may need to meet:
Compressed Size
Although many people now connect to the Internet through high-speed cable modems or DSL lines, others still use lower-
speed modems. Package size is very important to people with slower connections due to the increased amount of online
time required to download an application.
Self-Extracting
Many file compression utilities require a special client-side application to decompress the application files. This need for
another utility complicates the download and installation process for end users. To simplify the installation process, the
compression utility that you use should be self-extracting so that no other application is required.
Digitally Signed
To make your customers feel more secure about downloading and installing your software, you can digitally sign your
application package. The digital signature identifies you or your company to end users and assures them that the
application code has not been altered or tampered with since publication. To learn how to digitally sign your application,
see Digital Signing and Security.
Easy to Use
Perhaps the most important aspect of packaging your installation for Internet distribution is making it easy to use. Your
end users may not want to specify a location where the installation files should be saved and then search their computer to
locate those files. Instead, the installation should be seamlessly integrated into the compression package, requiring only
one step to begin the installation.
If your end users access the Internet through a proxy server and your installation is configured to download files, the
installation uses the system proxy settings that are manually configured in Internet Explorer during the download. This
occurs even if another browser on the target system is the default browser.
Note that InstallShield does not include support for the Automatically Detect Settings functionality in Internet Explorer. (If
end users have the Automatically Detect Settings check box selected in Internet Explorer for their LAN connection and the
installation needs to download files, the installation fails because the files cannot be downloaded. If it is possible that your
end users may have the Automatically Detect Settings check box selected in Internet Explorer for their LAN connections,
you may want to embed all of the files in your installation rather than configure them to be downloaded; if the files are
embedded, the failures can be avoided.) However, InstallShield does support the Automatic Configuration Script
functionality that is set up for LAN connections in Internet Explorer.
The following files are automatically created by InstallShield and can be redistributed with your software distribution, as
discussed in your End-User License Agreement.The media build automatically includes them as needed in your disk image
folders.
• data1.cab
• data1.hdr
• ISSetup.dll
• layout.bin
• setup.exe
• setup.ini
• setup.inx
Optional Files
• setup.isn—Skin File
See Also
Overview of ISSetup.dll
InstallShield lets you specify whether you want your installation to include a 64-bit Setup.exe setup launcher. A 64-Bit
Setup.exe setup launcher is required only if the installation is targeting 64-bit system. By default, InstallShield builds the
32-bit setup launcher, which can execute in a 32-bit system as well in WoW64 on 64-bit system. Some 64-bit target systems-
such as Windows Server Core systems may not have 32-bit Windows-on-Windows (WOW64) support. These 64-bit target
systems cannot run 32-bit setup launcher.
The General tab for a product configuration in the Releases view is where you specify information such as whether you
want to build 64-Bit Setup launcher.
Building 64-bit Setup launcher does not build the corresponding 64-bit MSI package by default. In order to build the 64-bit
MSI package, you need to configure the Template Summary with the appropriate 64-bit value (x64 or Intel64). Pure 64-bit
MSI package cannot copy 32-bit product files or execute 32-bit custom action during installation, because 32-bit binaries
cannot be loaded on 64-bit target systems without WOW64 support. The InstallShield Architecture Validation setting for a
product configuration in the Releases view, helps you to build the pure 32-bit or 64-bit MSI package. InstallShield has the
capability to build two installations (one for 32 bit and one for 64 bit) from a single project, based on the release flags
configuration.
For more information on Building 64-bit MSI package, see Targeting 64-Bit Operating Systems with Basic MSI and
InstallScript MSI Installations.
ISDEV: warning -7372: Setup Launcher is configured to build 64-Bit, but Template Summary is not
configured to build 64-Bit MSI package.
This is just to make the attention, because 64-bit setup launcher fails to execute in a pure 32-bit system, and the 32-bit MSI
package fail to install in pure 64-bit system. So, this warning can be fixed by not opting the 64-bit setup launcher if the
installer needs to target pure 32-bit system and WoW64 on 64-bit system. Other way, the MSI template summary can be
changed to generate 64-bit MSI package to target pure 64-bit system.
ISDEV: fatal error -7371: InstallScript custom actions are not supported with 64-Bit Setup Launcher.
If the InstallScript custom actions are required then the Basic MSI project can be configured to build without the 64-bit
setup launcher, because InstallScript runtimes are still in 32-bit which requires 32-bit setup launcher. Other way if the
InstallScript custom actions are not required, it can be deleted from the project and continue building with 64-bit setup
launcher.
If you configure to build the projects that include InstallShield prerequisites with 64-bit setup launcher, ensure the
prerequisite installer is a 64-bit, which can install in pure x64 system and configure the prerequisite conditions to check the
64-bit location either in the registry or folder location.
In some cases, if you want to build the 32-bit prerequisite installer with 64-bit setup launcher, configure the conditions to
check the 32-bit location. Most of the registry conditions in the prerequisites are configured to check the default location,
which is 32-bit location for the 32-bit set up launcher and 64-bit location for the 64-bit setup launcher. But, the 32bit
prerequisite installer creates the registry key under the 32-bit registry hives. To rectify this, you need to modify the registry
location to check the 32-bit location explicitly in the InstallShield prerequisite editor. The prerequisite condition is as
shown below:
Important • The Windows 10 Anniversary Update is required for installing and testing a Windows App package (.appx) with
desktop extensions (Desktop Bridge) included. To digitally sign the Windows App package, InstallShield must be installed on a
Windows 10 machine or a machine with the Windows 10 SDK installed.
Tip • Sideloading must be enabled for a Windows App package to be successfully sideloaded. For more information about
sideloading, refer to the Enable your device for deployment MSDN article.
The following table provides an overview of the ways you can distribute Windows App packages:
Windows Store Upload the Windows App package to the Windows Store This type of app
Windows Store. Refer to the Packaging Windows doesn't need to be
Apps (MSDN article) for more information. signed before it is
uploaded to Microsoft
Any package distributed through the Windows
because Microsoft
Store is subject to additional policies that limit its
signs the package.
contents.
Sideloaded and Add a sideloading Windows App package to a Direct Distribution If a package will be
added to a Suite/ Suite/Advanced UI project as described in Adding (Sideload) sideloaded and added
Advanced UI a Sideloading Windows App Package (.appx | to a Suite, the
Project .msix) to a Suite/Advanced UI Project. Windows App package
must be signed before
A common example of a sideloading app is one
it is built into the
that is distributed to an enterprise environment
Suite/Advanced UI
and is internal to a company only.
project.
You can use condition checks such as the
Windows App Package Eligible eligibility
condition of a Windows App package (.appx) or
the UWP Type Present condition in either an exit
condition or a package's eligibility condition as
well as other condition checks to employ this type
of distribution method. This type of scenario