Altiris

Wise for Windows Installer
Reference
Notice
Wise for Windows Installer, Version 6.2
© 1994-2005 Wise Solutions, Inc. All Rights Reserved.
This documentation and the accompanying software are copyrighted materials. Making unauthorized copies is prohibited by law. No part of
the software or documentation may be reproduced, transmitted, transcribed, stored in a retrieval system or translated into any human or
computer language without prior written permission of Wise Solutions, Inc. Wise Solutions, Inc. asserts its “Moral Right” to be identified as
the author of this work, in all jurisdictions which recognize the “Moral Right.”
Unless otherwise provided by written agreement with Wise Solutions, Inc., this publication, and the software sold with this publication, are
provided “as is” without warranty of any kind either express or implied, including but not limited to the implied warranties of merchantability
and fitness for a particular purpose. The entire risk arising out of the use or performance of this publication and software remains with you.
In no event will Wise Solutions, Inc., or any of its suppliers, be liable for any lost profits, lost savings, direct, incidental or indirect damages or
other economic or consequential damages, even if Wise Solutions, Inc., or its suppliers, have been advised of the possibility of such damages.
Wise Solutions, Inc. reserves the right to modify this document at any time without obligation to notify anyone. In no event shall Wise
Solutions, Inc.’s or its suppliers’ liability under this agreement exceed the sum of any amounts paid hereunder by the customer to Wise or the
supplier.
Wise Solutions, Inc. owns a number of trademarks and service marks (the “Marks”). These Marks are extremely valuable to Wise Solutions,
Inc. and shall not be used by you, or any other person, without Wise Solutions, Inc.’s express written permission. The Marks include, but are
not necessarily limited to the following: Application Isolation Wizard™; ApplicationWatch™; ConflictManager®; ExpressBuild™; Installation
Development Life Cycle™; InstallBuilder®; InstallMaker®; InstallManager®; InstallTailor™; MSI Debugger™; MSI Script™;
PackageManager™; Preflight Deployment™; SetupCapture®; SmartMonitor™; SmartPatch™; Software Distribution Made Easy™; Software
Installations Made Easy®; Unwise™; Virtual Capture™; Visual MSIDiff™; WebDeploy®; Wise Installation System®; Wise MSI Editor™; Wise
Package Studio®; Wise Software Repository™; Wise Solutions®; WiseScript™; WiseScript Express™; WiseUpdate®; WiseUser®; and the
Wise Solutions® logo.
In addition to Wise Solutions, Inc.’s Marks, some Wise Products may include Trademarks or Service Marks owned by other corporations.
These other Marks include, but are not necessarily limited to Microsoft® Windows® and Microsoft® Visual Studio® .NET, which are
registered Trademarks of Microsoft Corporation.
You shall not use any of the Trademarks or Service Marks of Wise Solutions, Inc., Microsoft Corporation, or any other entity, without the
express written permission of such Trademark or Service Mark owner.
Wise Solutions, Inc., a wholly owned subsidiary of Altiris, Inc.
47911 Halyard Drive; Plymouth, Michigan 48170 USA
Phone: +1 734 456 2100 • Fax: +1 734 456 2456 • www.wise.com
Wise for Windows Installer Reference 2

Contents
Chapter 1: Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Documentation Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Getting Help and Product Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Getting Updates Over the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 2: Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Product Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
About Visual Studio .NET Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Using Installation Expert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
About Page Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Customizing Page Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Using the Current Feature Drop-Down List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Using the Current Release Drop-Down List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
About the Product Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Using the Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Filtering the Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Finding Table Errors From the Task List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Adding User-Defined Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Where are Installation Resources Stored? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Using the Enterprise Edition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Sharing Installation Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
About the Share Point Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
How Source Files Are Indexed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Generating Package Contents Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Generating Shared Resource Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Downloading Redistributable Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Downloading Redistributables From the Wise Web Site or Product CD . . . . . . . . . . . . . . . . . . . 35
Downloading Redistributables From Other Vendors’ Web Sites . . . . . . . . . . . . . . . . . . . . . . . . 36
Chapter 3: Setting Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Setting Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Setting General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Setting .NET Assembly Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Setting Advertising Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Setting Digital Signature Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Setting ExpressBuild Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
How ExpressBuild Groups Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Requirements for Using ExpressBuild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Setting Installation Expert Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Setting Merge Module Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Activating Suppressed Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Setting Repository Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Setting Source Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Setting the Default Target Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Setting Visual Studio Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Setting Wildcard Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Creating and Editing Installation Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

About Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Selecting a Component Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Using Component Rules to Align GUIDs in an Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Customizing Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Adding and Editing Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Microsoft Best Practices Component Rule Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
One File Per Component Rule Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Chapter 4: Working With Wise Installation Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Before You Create an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 66
File Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 67
Project Files and Database Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 68
Starting a New Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 69
Creating an Installation Within a Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 70
Creating a Stand-alone Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 72
Creating a Device Driver Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 72
Options for New Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 74
Specifying the Target Platform in an Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 76
What’s Different in a 64-Bit Installation? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 76
Entering Project Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 77
Overview Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 78
Project Type Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 78
Projects Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 79
Main Project Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 80
Pre-build Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 80
Post-build Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 81
Project Outputs Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 81
How the Installation Integrates With the Solution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 81
Scanning the Solution for New Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 82
Opening an Installation Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 83
Comparing Windows Installer Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 85
Saving an Installation as XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 86
Working With Installations in the Software Manager Database . . . . . . . . . . . . . . . . . . . . . . ... .. 87
Compiling, Testing, and Running An Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 88
Compiling An Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 88
Testing An Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 89
Running An Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... .. 90
Chapter 5: Defining an Installation Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Project Summary Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Product Details Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Adding Meta Data to the Software Manager Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Incrementing the Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Setting the Default Installation Directory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
General Information Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Add/Remove Programs Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Features Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Strategies for Organizing Files Into Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Adding a New Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Configuring a Feature Using Its Drop-Down List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Configuring a Feature Using the Feature Details Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Using Conditions With Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Adding and Deleting Feature Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Managing Binary Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Adding Binary Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Refreshing Binary Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Chapter 6: Assembling an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Files or Web Files Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 113
When to Use the File-Related Installation Expert Pages . . . . . . . . . . . . . . . . . . . . . . . . ... . 115
Installation Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 116
Files or Web Files Page Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 116
Adding Files to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 117
Adding Assembly Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 119
Adding Merge Modules Instead of Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 120
Adding Files From the Wise Software Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 121
Adding Contents of Directories to the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 122
Adding Files From Outside the Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 123
Adding .NET Assemblies to the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 124
Editing Settings for Automatic Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 125
Removing a File From the Destination Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 127
Copying and Moving Files on the Destination Computer. . . . . . . . . . . . . . . . . . . . . . . . ... . 128
Editing File Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 129
Editing General File Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 130
Setting Permissions for Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 132
Editing Self-Registration Settings for Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 133
Editing Assembly Settings for Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 133
Creating a Win32 Assembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 135
Viewing Shared File Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 136
Editing XML Files During Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 137
Editing DIFxApp Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 138
How Self-Registration Information is Captured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 139
Using WiseComCapture.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 140
Visual Studio Solution Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 141
Adding Contents of Visual Studio Projects to the Installation . . . . . . . . . . . . . . . . . . . . ... . 142
Registry Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 143
Adding Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 144
Removing Registry Entries From the Destination Computer . . . . . . . . . . . . . . . . . . . . . ... . 145
Importing and Exporting Registry Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 147
Configuring General Registry Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 148
Setting Permissions for Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 149
Viewing Shared Registry Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 150
Special Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 150
INI Files Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 151
Creating and Editing .INI Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 151
Shortcuts Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 152
Adding a Shortcut to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 153
Editing a Shortcut Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 154
Adding an Environment Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 155
Adding File Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 156
Determining Extension Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 157
Adding Command Verbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 158
Selecting MIME Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 158
Services Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 159
Adding a Service to the Destination Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 159
Controlling Services on the Destination Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 161
Adding an ODBC Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 162
Setting ODBC Data Source Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . 162

Setting ODBC Driver Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Setting ODBC Translator Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Adding to the Windows Firewall Exception List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Chapter 7: Your Installation on the Destination Computer . . . . . . . . . . . . . . . . . . . . . 166

About System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Setting a Requirement on the System Requirements Page. . . . . . . . . . . . . . . . . . . . . . . . . . 166
Setting a Requirement by Creating a Launch Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Performing a System Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Searching For Files or Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Searching For Items in .INI Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Searching For a Registry Value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Searching For a Previously-Installed Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Setting Features for Installation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Chapter 8: Organizing Your Installation Into Releases . . . . . . . . . . . . . . . . . . . . . . . . 178

About Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Creating a New Release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Outputting a Multiple-Language Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Customizing a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Customizing Properties for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Customizing Summary Items for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Defining a Feature Set for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Sharing Settings Between Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Example: Creating a Demo Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Setting Build Options for a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Adding Prerequisites to a Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Adding a Prerequisite File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Adding the MSDE Runtime Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Editing the WiseScript That Creates the Installation .EXE . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Creating a Clean Build. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Creating Web-Based Installations With WebDeploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
The WebDeploy Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Tips for Creating an Efficient WebDeploy Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Creating a WebDeploy Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Uploading a WebDeploy Installation to the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Setting Up Media for Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Adding a Media Item. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Adding a Media Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Including Features and Components in Media Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Sharing Media Settings Between Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Example: Spanning an Installation Across Media and Sharing Media Size Information. . . . . . . 206
Chapter 9: Advanced Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

About Command Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Creating a Command Line To Apply to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Applying UI Options to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Applying Logging Options to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Applying an Advertising Option to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Applying a Repair Option to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Changing Public Properties in an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Applying Transforms to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Applying or Removing Patches With a Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Command Line Options For WFWI.EXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

WFWI.EXE Command Line Option Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Automating the Build Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Adding a Digital Signature to Your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Creating an Installation for Microsoft SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Creating a .NET Installation When You Have the .NET Framework . . . . . . . . . . . . . . . . . . . . . . . 220
Creating a .NET Installation Without the .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
About Web Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Features That Support Web Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Creating a Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Creating a Virtual Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Creating a New Web Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Setting Installation Options for a Web Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Setting Installation Options for a Child Virtual Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
About the Web Site Details Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Installing Web Settings From a File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Configuring a Microsoft SQL Server During Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Tips on Using the SQL Server Scripts Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Setting SQL Connection Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Specifying SQL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Specifying Replacements in SQL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Importing .NET Framework Security Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
MTS/COM+ Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Adding an MTS or COM+ Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Chapter 10: Mobile Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Mobile Devices Page Compared to Mobile Device Package Editor . . . . . . . . . . . . . . . . . . . . . . . . 242
About the Mobile Devices Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
About Mobile Device Package Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Pocket PC and Smartphone Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
How a Pocket PC or Smartphone Installation Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Processor and Platform Support for Pocket PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Creating a Pocket PC or Smartphone Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Compiling a Pocket PC or Smartphone Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Setting Application Information for a Mobile Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Setting Platform Support for a Mobile Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Setting Platform Information for a Mobile Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Setting Files for a Mobile Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Editing Details for Mobile Device Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Setting Registry for a Mobile Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Setting Shortcuts for a Mobile Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Setting Desktop Computer Details for a Mobile Device Installation . . . . . . . . . . . . . . . . . . . . . . . 254
Palm OS Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Chapter 11: Translating an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

About the Languages Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Creating a Translated .MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Creating a Language Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Sharing Language Settings Between Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Removing a Language from an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Defining and Translating Into Additional Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
About the New Language Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Defining a New Language and Exporting All Text for Translation . . . . . . . . . . . . . . . . . . . . . 265
Importing All Text Strings After Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Importing All Text Strings With the New Language Wizard . . . . . . . . . . . . . . . . . . . . . . . . . 267

Translating Text Strings You’ve Added or Changed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Translating Text Strings by Exporting to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Exporting Selected Text Strings to a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Importing Selected Text Strings From a File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Translating Text Directly Without Exporting It . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Translating Text on the Language Strings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Changing Text in Installation Expert and Setup Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Resizing Dialog Controls After Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
About the Language Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Changing the Default Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
About the Default Release Language. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
About the Language Strings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Keeping Track of Changed Text Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
What Pre-Translated Languages Are Available?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Language IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Chapter 12: Distributing an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Package Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Copying an Installation to the Share Point Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Copying an Installation to a Network Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Copying an Installation to an FTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Performing an Administrative Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Copying an Installation to Removable Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
WiseUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
The WiseUpdate Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Using WiseUpdate in an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Configuring the WiseUpdate Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
About the WiseUpdate Update File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Uploading WiseUpdate Files With Package Distribution . . . . . . . . . . . . . . . . . . . . . . . . . 292
Uploading WiseUpdate Files With an FTP Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Testing WiseUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Options for Running WiseUpdate Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
WiseUpdate Tips. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Troubleshooting WiseUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Chapter 13: Upgrading Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Preparing for Software Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Archive the Shipping Version of the .MSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Determine the Form of the Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Determine the Product Code and Product Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Check the Installation With UpgradeSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
UpgradeSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Using UpgradeSync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
About Patch Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Creating a Patch File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Specifying Previous Versions for Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Advanced Upgrade Version Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Specifying the Patch Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Specifying Advanced Patch Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Specifying Patch Removal Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Upgrades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Creating an Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Chapter 14: Working With Source Paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Using Source Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Adding an Installation to Source Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Adding Files to an Installation in Source Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Checking Files Into Source Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Checking Files Out from Source Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Getting Latest Version of Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Removing Files from Source Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Undoing the Check Out of Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Showing History of the Installation File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Showing the Differences Between Installation Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Comparing the Current Installation to the Latest in Source Control. . . . . . . . . . . . . . . . . . . . 320
About Path Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Turning Path Variable Substitution On and Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Creating a User-Defined Path Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Creating a Path Variable Based on an Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . 323
Creating a Path Variable Based on a Registry Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Source Paths in an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Changing Source Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Converting to Relative Source File Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Converting to UNC-Based Source File Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Changing the Source Directory Dynamically During Compile . . . . . . . . . . . . . . . . . . . . . . . . 327
Chapter 15: Merge Modules and Transforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

About Merge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Available Tabs and Pages in Merge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Setting Merge Module Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Setting Dependencies for a Merge Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Setting Exclusions for a Merge Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Creating a Merge Module As a New Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Creating a Merge Module Within a Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Creating a Merge Module From Existing Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Creating a Configurable Merge Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Setting Configuration Item Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Specifying Drop-Down List Values for Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Specifying a Bitfield for Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Specifying a Key for Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Example: Configuring an Item for a Merge Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
About the Merge Modules Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Adding a Merge Module to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Editing Merge Module Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
About Transforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Creating a Transform Based on an Existing .MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Setting Transform Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Applying a Transform to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Multiple Instance Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Installing Multiple Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Chapter 16: Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

ApplicationWatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Convert InstallShield Professional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Convert SMS Installer or WiseScript Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Import Visual Studio Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Importing an Installation From a Visual Studio Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

Importing an Installation From a Visual Basic Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
MSI to WSI Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Converting an .MSI to a .WSI File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
Specifying Merge Module Source Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Specifying File Source Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Package Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Validating a Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Customizing Validation Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Adding a Validation Module to Package Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Selecting Validation Rules to Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
About Rules That Call a Custom Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Adding a Rule That Calls a Custom Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
About Validation Rule Sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Adding a Validation Rule Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Predefined Validation Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Wise Task Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Using Wise Task Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Chapter 17: Setup Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

About Setup Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Product Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Specifying Summary Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Features Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Assigning a Component to a Feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Modules Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Advertising Icon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Creating a Folder in Setup Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Creating Duplicate File Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Components Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Component Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Adding and Editing a Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Moving Items Between Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
About the Key Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Isolating a .DLL With an .EXE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Adding Published Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Tables Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Creating a New Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Creating a New Row in a Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Editing Existing Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Searching for Table Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Finding Validation Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Editing Binary Data in the Icon Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
About Wise Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Chapter 18: Using Conditions and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Where Can You Use Conditions? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Condition Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Examples of Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
WiseFixConditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Creating Conditions With Condition Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Checking the Value of a Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Checking the Value of an Environment Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Checking If and How a Feature or Component is Currently Installed . . . . . . . . . . . . . . . . 414

Checking If and How a Feature or Component Will Be Installed by This Installation . . . . . 414
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ........... ............ . . . . . 415
How Do You Use Properties? . . . . . . . . . . . . . . . . . . ........... ............ . . . . . 416
Creating a New Property . . . . . . . . . . . . . . . . . . . . . ........... ............ . . . . . 417
Build Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . ........... ............ . . . . . 418
INI File Properties. . . . . . . . . . . . . . . . . . . . . . . . . . ........... ............ . . . . . 422
Runtime Properties . . . . . . . . . . . . . . . . . . . . . . . . . ........... ............ . . . . . 424
Chapter 19: Working With Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

About Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
About the Wizard Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Using the Dialogs Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Changing the Theme of Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Adding and Editing Dialog Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Importing Text into License and Readme Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Changing the Order of Web Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Using the Dialogs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Adding Controls to Dialogs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Editing Dialog Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Creating a New Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
About Dialog Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Types of Dialog Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Editing Dialog Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Basic Control Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Setting an Event on a Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Assigning Help to a Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Assigning Conditions to a Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Setting the Graphic for a Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Setting the Items in a Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Organizing and Aligning Controls on Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Aligning Dialog Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Centering Dialog Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Making Dialog Controls the Same Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Spacing Dialog Controls Evenly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Setting Dialog Tab Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
About Billboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Adding Billboards to a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Obtaining Logon Information From a Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Adding the Logon Information Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
About the SQL Connection Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Adding the SQL Connection Dialog to an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Editing Additional SQL Connection Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Adding the Custom Property Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Chapter 20: Macro Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

About Macro Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Creating, Editing, and Running a Macro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Events That Can Trigger a Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
About the Macro Editor Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Chapter 21: Debugger for Windows Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

About the Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
The Debugger Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Running the Debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

Setting and Clearing Debugger Breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Evaluating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Working With Temporary Tables and Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Searching For Text in Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Chapter 22: Using MSI Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

The MSI Script Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
About MSI Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
About Installation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Adding a Custom Action Outside a Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Adding a Custom Action to Multiple Sequences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
About Installation Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Finding Text in MSI Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Editing Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Types of Actions in MSI Script Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
About the Standard and Custom Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Adding and Editing Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Commenting Out Script Lines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Calling WiseScripts with Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
WiseScript Editing Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Examples of WiseScripts You Run From an .MSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Using a WiseScript to Parse a Pathname . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Using a WiseScript to Install a License File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Uninstalling Changes Made by a WiseScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Guidelines for Using Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Guidelines for Custom Action Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Guidelines for Custom Action Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Guidelines for Nested Installation Custom Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Guidelines for Calling VBScripts and JScripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Guidelines for Calling .DLLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Launching a Custom Action from a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Custom Actions That Are Added Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Troubleshooting Custom Actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Chapter 23: Custom Action Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Call Custom DLL From Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Call Custom DLL From Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Call Custom DLL From Installed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
Configuring .DLL Parameter Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Call DLL From Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
Call DLL From Installed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Call JScript From Embedded Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
Call JScript From Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Call JScript From Installed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
Call JScript From Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Call VBScript From Embedded Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Call VBScript From Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Call VBScript From Installed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Call VBScript From Property. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Display Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Download File From Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
End Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Execute Program From Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501
Execute Program From Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

Execute Program From Installed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Execute Program From Path. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
If Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Install MSI From Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Install MSI From Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Install MSI From Relative Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Launch Web Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Open Document From Installed Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Pause Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Post Data to HTTP Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Remark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Run WiseScript From Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Run WiseScript From Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Run WiseScript From Installed Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Set Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Set Feature State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Set Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Terminate Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Using the Custom Action Location Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Using the Custom Action Location Tab for Merge Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Using the Custom Action Properties Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Chapter 24: Windows Installer and .NET Technologies . . . . . . . . . . . . . . . . . . . . . . . . 521

About Microsoft Windows Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Frequently Asked Questions About Microsoft Windows Installer . . . . . . . . . . . . . . . . . . . . . . 522
Working With Components and Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
About GUIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
About Microsoft .NET Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Frequently Asked Questions About Microsoft .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Requirements for Creating a .NET Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

Chapter 1
Welcome
Wise for Windows Installer is an installation development system for creating and
editing Windows® Installer (.MSI) installation packages. It is a complete and user-
friendly front end for generating Windows Installer database files, which are executed by
the Windows Installer engine.
With Wise for Windows Installer, you can:
z Create installations that are compliant with Microsoft’s Windows 2000 logo program.
z Edit and refine installations that you’ve converted from other formats.
z Import development projects.
Through its Visual Studio integrated editor, Wise for Windows Installer offers a complete,
seamless integration of the entire installation authoring environment directly into the
Microsoft® Visual Studio® .NET development environment. This tight integration allows
for automatic synchronization of your development project with your installation, saving
you time and significantly improving the quality of your installations.
Microsoft® Windows® Installer is a Microsoft technology that provides a standard

installation engine that can be used for the installation of any 32-bit or 64-bit Windows
software product. It resides on the destination computer and performs the installation of
applications. Windows Installer technology provides features that are not available in
traditional installation-building products (examples: self-healing and install-on-
demand).
Topics include:
z Documentation Roadmap.
z Getting Help and Product Support.
z How to Check Online Help.
z Getting Updates Over the Web.
Documentation Roadmap
The Wise for Windows Installer documentation assumes that you are proficient in the
use of the Windows operating system. If you need help using the operating system,
consult its user documentation.
Use the following sources of information to learn the product.
Online Help
The online help contains detailed technical information and step-by-step instructions for
performing common tasks. For details on using help, see Check Online Help on page 15.

Welcome
Reference Manual
All the material in the online help is also available in .PDF-format reference manuals.
Reference manual .PDFs are provided for Wise for Windows Installer and WiseScript
Express. The Enterprise Edition also includes a Software Manager reference manual. To
access the .PDF reference manuals, select Help menu > Reference Manual from within
each product. (In Visual Studio: Help menu > Wise Help > Reference Manual.)
Getting Started Guide

The printed Getting Started Guide contains system requirements, installation
instructions, and a tutorial. To access a .PDF version of the Getting Started Guide, select
Help menu > Getting Started. (In Visual Studio: Help menu > Wise Help > Getting
Started.)
The installation and repository management sections of the Getting Started Guide are
also available as online help. In the Wise Repository Manager, select Help menu > Help
Topics.
Windows Installer SDK Help

You can get technical details about Windows Installer from its own help system, which is
written by Microsoft for a developer audience. In Wise for Windows Installer, select Help
menu > Windows Installer SDK Help. (In Visual Studio: Help menu > Wise Help >
Windows Installer SDK Help. Windows Installer SDK help topics are also available within
the Visual Studio .NET help collection.)
Release Notes
A release notes document, in .HTM format, covers new features, enhancements, bug
fixes, and known issues for the current version of this product. It also contains links to
release notes for other versions. Access the release notes in the following ways:
z Browse the product CD.
z Select Help menu > Release Notes. (In Visual Studio: Help menu > Wise Help >
Release Notes.)
z If you are a registered customer, visit http://support.wise.com to enter the Support

Center, and then click the Downloads link.
Also see Getting Help and Product Support.
Getting Help and Product Support

Many resources are available to help you use our products. You can search the product
help or reference manual .PDF for answers, or you can use one of the many support
resources available to you as a registered customer.
Also see Documentation Roadmap.
Check Online Help

Access help in the following ways:
z To display context-sensitive help for the active page or dialog, press F1.

Welcome
z To select a help topic from a table of contents, index, or search, select Help menu >
Help Topics. (In Visual Studio: Help menu > Wise Help > Help Topics.)
Select other commands from the Help menu to view the Windows Installer SDK Help, to
view the .PDF-format reference manual or getting started guide, to view Wise resources
on the Web, or to check for upgrades.
If you need help and cannot find the answer in the documentation, explore our technical
support options below.
Use the Technical Support Center

Registered customers can use the Technical Support Center, located at http://
support.wise.com, to submit online support requests, register products, manage
customer information, download updates, or search the Knowledgebase. The
Knowledgebase contains how-to procedures, answers to common support questions,
and workarounds.
Visit Our Newsgroups

Visit www.altiris.com/support/forum/default.asp. Newsgroup postings by your peers
contain answers, tips, analysis, and other comments. Contribute your own expertise to
help others.
Subscribe to TechInfo
TechInfo is a free e-mail newsletter that contains technical tips, product updates, and
other important technical information. To subscribe or to read back issues, visit
www.wise.com/techinfo.asp.
Ask Our Support Team

If you can’t find an answer in our online resources, you can obtain support by phone or
online at http://support.wise.com. Flexible payment options are available to meet your
support needs. For additional details about our support services, visit www.wise.com/
supportoptions.asp or call 1-734-456-2600.
Before you contact technical support, obtain the following:
z Serial number and product version, which you can find by selecting Help menu >
About.
z Operating system version and service pack version if applicable.
z A description of what you do before the problem occurs.
z The text of any error messages that appear.
z Your name, company name, and how to contact you.
z Contract number or payment information, if applicable.
Take Advantage of Our Consulting and Training Services

When you have a challenging repackaging or installation problem, our consultants can
help with script writing, repackaging, installation development, and other solutions that
are fully customizable to fit your project and budget. Visit www.wise.com/consulting.asp
for details.
To upgrade your installation and packaging skills, consider training. Our certified
instructors draw from practical experience to provide relevant course content. Visit
www.wise.com/training.asp for course descriptions and schedules.

Welcome
Contact Our Sales Department
Contact our Sales department to purchase additional products, upgrades, support

services, or consulting and training services.
U.S.: +1 800 554 8565
EMEA: +8000 ALTIRIS (2584747) or +49 211 68 773 222
Other International: +1 734 456 2100
E-mail: wisesales@altiris.com
Web Site: www.wise.com/ordercentermain.asp
Getting Updates Over the Web

You can get the latest version of Wise for Windows Installer using your active Internet
connection. Minor point releases (x.01, x.02, and so on) are generally free, while major
number releases generally incur an upgrade fee. Point releases generally contain
maintenance updates such as bug fixes and minor feature additions.
To check for updates:

1. Connect to the Internet.
2. In Wise for Windows Installer, select Help menu > Check for Updates.
A confirmation prompt appears, and then you are connected to the Technical
Support Center Web site.
If you have not registered this product, follow the screen prompts to create a
user account and register. You will need a valid product serial number. After you
complete the registration, click the link to enter the Technical Support Center.
If you have registered this product, log on and then click the link to enter the
Technical Support Center.
3. Click the Downloads link. Follow the instructions on the Web page to download the
appropriate update.
Note
Wise for Windows Installer can remind you to check for updates. Select an option in the
Check for Updates drop-down list in Wise Options. This sets the frequency at which
you will be reminded to check for updates.

Chapter 2
Basics
Read this overview before creating your first installation. It contains information on
getting started with Wise for Windows Installer.
Topics include:
z Product Editions.
z About Visual Studio .NET Integration.
z Using Installation Expert.
z About the Product Home Page.
z Using the Task List.
z Where are Installation Resources Stored?
z Using the Enterprise Edition.
z Downloading Redistributable Files such as merge modules and Windows Installer

and .NET runtimes.
Product Editions
Wise for Windows Installer is available in 3 editions, each designed to fulfill the needs of
a particular type of user. The edition you purchase determines what features are
available to you.
z Enterprise Edition is a Windows Installer® and .NET installation authoring tool

supporting organizations that develop multiple applications that share common
resources. It helps professional developers create installations that adhere to their
organization’s standards, thereby decreasing the risk of deployment errors.
z Professional Edition is a Windows Installer® and .NET installation authoring tool for
professional software developers who want to create installations for the next
generation of applications, including desktop, server, Web, and mobile devices.
z Standard Edition is a Windows Installer® and .NET installation authoring tool for
professional software developers who want basic but robust support for creating
Windows Installer® and .NET installations.
The following table, which does not include all features, summarizes the differences
between each edition. If a feature is not listed, it is included in all product editions. For a
more comprehensive list of features, visit the Products section of the Wise Web site
(www.wise.com). For new features and enhancements in the current release, see the
Release Notes, available from the Help menu. (In Visual Studio: select Help menu >
Wise Help.)

Basics
Feature Std Pro Ent

General
Specify the target platform for an installation X X
Create configurable merge modules X X
Macro Editor X X
OLE Automation X X
User-defined tasks X
Use merge modules from the Software Manager database X
Add meta data to the Software Manager database X
Enable the Logon Information dialog to configure server software after installation to run X X
under a particular user
Enable the SQL Connection dialog to generate a valid connection string X X
Enable the Custom Property dialog to gather data from the end user during installation X X
ExpressBuild (distributed compiles) X X
Debugger for Windows Installer X X
Package Contents Reports X
WiseScript Express X X X
Wise Options
Repository options X
Sharing Installation Resources
Open an installation package from the Wise Software Repository X
Share installation resources in the share point directory X
Distribute to the share point directory X
View and use resources shared by other applications X
Shared Resource Reports in Wise for Windows Installer X
Installation Expert Pages
.NET Framework Security page X X
Clean Build page X X
Mobile Devices page X X
MTS/COM+ page X X
SQL Server Scripts page X X
Web Files page, ability to edit .XML files X X
WebDeploy page X X
WiseUpdate page X X
Tools
Patch Creation and patch support X X X
Software Manager X

Basics
Feature Std Pro Ent

Upgrade Sync X X X
Package Validation
Turn individual rules on and off X X
Create a new validation module (.CUB file) X
Create new validation rules X
About Visual Studio .NET Integration

You can use Wise for Windows Installer from within Visual Studio .NET. The Visual Studio
integrated editor lets you create all the same installation file types that you create in the
stand-alone Wise editor. The Wise editor and Visual Studio integrated editor are different
interfaces for the same product; they share the same preferences, recently-used file
lists, dialog templates, themes, and installation templates. (The Visual Studio integrated
editor was formerly sold separately as Wise for Visual Studio .NET.)
There are several differences between the Wise editor and the Visual Studio integrated
editor that are inherent in the Visual Studio .NET development environment.
Examples:
z In the Visual Studio integrated editor, you have different choices about how to start
a new project, and you can set source paths to update automatically according to
Visual Studio’s build configuration.
z In the Visual Studio integrated editor, installations synchronize automatically with

the other projects in the solution. Example: adding .EXEs, .DLLs, .OCXs, and
assemblies to the solution adds them to the installation.
z Installation meta data fields (examples: application name, version, manufacturer,

and default directory) are populated using data from the Visual Studio .NET
solution.
When you create an installation project in Visual Studio.NET, a corresponding .WSPROJ

file is created in the same location. The .WSPROJ file points to the .WSI. You can double-
click a .WSPROJ file in Windows Explorer and open it in Visual Studio .NET.
When you double-click an installation file in Windows Explorer, you are prompted to
select which editor to open the file in. You can set an option on this dialog to always
open that file in a specific editor.
If you create an installation project in the Visual Studio integrated editor, and then
uninstall Microsoft Visual Studio .NET, you can continue working on the installation
project in the Wise editor. However, if you right-click a .WSI or .MSI, an option still exists
to edit in the Visual Studio integrated editor, which is no longer possible. Initiate a repair
on Wise for Windows Installer to remove options that have to do with the Visual Studio
integrated editor.
Using Installation Expert

To access Installation Expert, click Installation Expert at the lower left of the Wise for
Windows Installer main window.

Basics
Page Views
Page Groups Page Area
View Navigation Testing and Distribution
Page Views
Use the Page Views drop-down list to select a page view, which is a set of Installation
Expert page groups and pages. See About Page Views on page 22 and Customizing Page
Views on page 23.
Page Groups
When you select a page view, its pages are organized into page groups. Click the group
name to expand or collapse its pages. Click a page name to display that page.
Page Area
When you click a page name in a page group, this area displays the page’s options. Each
page lets you define a specific aspect of the installation. (Examples: On the Files page,
you define what files are included in the installation. On the Registry page, you define
what registry keys and values are created on the destination computer.) Complete just
the pages that are pertinent to your particular installation, in any order. If required
information is missing, Wise for Windows Installer alerts you to the problem during
compile.
To display help for the current page, press F1. To return an Installation Expert page to
its last saved state, select Edit menu > Reset Page.
View Navigation
Click these tabs to change views. (In Visual Studio: these are buttons instead of tabs.)
Testing and Distribution

Compile, Test, Debug, and Run buttons test and compile the installation. The Distribute
button copies the installation package to various locations, such as an FTP site or
network directory. It also performs administrative installations. (In Visual Studio: These
buttons are not available, but the same functionality is available through menu
commands.)

Basics
Also see:
Using the Current Release Drop-Down List on page 25

Using the Current Feature Drop-Down List on page 24
About Page Views

A page view is a set of Installation Expert page groups and pages that you select from
the Page Views drop-down list. Select a page view to display only specific page groups
and pages. There are 3 types of page views:
z Predefined page views that display the groups and pages most frequently used for a
particular type of installation. The All page view displays all page groups and pages.
The Merge Module page view appears for all merge modules. You cannot edit or
delete predefined page views.
z Custom page views that you create to meet your specific needs. See Customizing
Page Views on page 23.
z Page views that are created when you create an installation template. You cannot
delete these page views. See Creating and Editing Installation Templates on
page 55.
The page views are arranged alphabetically in the Page Views drop-down list with the
exception of the All page view, which is always first. The list also includes <New
View...> and <Customize Page Views...>, which are at the end of the list and are
used to create or customize page views.
Predefined Templates and Page Views

Most predefined installation templates have an associated page view. When you create a
new installation by using one of these templates, the page view that is associated with
that template becomes the default page view of the installation. When you open the
installation, this page view appears in the Page Views drop-down list. You can select a
different page view from the list at any time (with the exception of the Merge Module
page view, which can only be used with merge modules). When you select a different
page view, it changes the pages displayed in Installation Expert but does not change the
installation type. If you change the page view and save the installation, this new page
view displays the next time you open the installation, unless you clear the Display the
page view associated with a project when a project is opened checkbox in Wise
Options.
Custom Templates and Page Views

When you create an installation template, a page view is created with the same name
and is listed in the Page Views drop-down list. For details on creating custom
templates, see Creating and Editing Installation Templates on page 55. However, when
you use a template to create an installation, the default page view is the page view that
was displayed when the template was created. If the template’s default page view is a
custom page view, you can customize it. See Customizing Page Views on page 23.
(Enterprise Edition only.) You can share page views that are associated with an
installation template because the page view is stored in the template, which is located in
the share point directory.

Basics
Which Page View Appears?

z The Display the page view associated with a project when a project is
opened checkbox in Wise Options determines what page view appears. If you clear
this checkbox, the page view in Installation Expert does not change when you open
a project regardless of its associated page view. See Setting Installation Expert
Options on page 47.
z The All page view is used when you open an installation file that does not have an
associated page view. An .MSI does not have an associated page view.
Also see Using Installation Expert on page 20.
Customizing Page Views

You can create customized Installation Expert page views that display only the page
groups and pages that you use most often. You can customize the page view of custom
installation templates or create customized page views that are not associated with a
template. You cannot customize the predefined page views, but you can make a copy of
a predefined page view and then customize it.
When you customize a page view, you can specify how many page groups appear, what
the group names are, and what pages appear under each group.
Buttons to edit page groups

and pages are disabled
when a predefined page
view is selected in Page
View Name.
These pages appear under

the group selected in Page
Groups.
The page groups appear on

the left side of Installation
Expert.
To create a page view:

1. From the Page Views drop-down list in Installation Expert, select <New View...>.
The Enter Name dialog appears.
2. Enter a name for the page view.
To create an access key for the name, type & before a letter in the name. The page
view access keys appear only in the page group’s right-click menu accessed by
using the context menu key (the key next to the right Ctrl key).
3. Click OK.
On the Customized Page Views dialog, the new page view is selected in Page View
Name, but it has no page groups or page names.

Basics
4. To copy the page groups and pages of an existing page view:
a. Click Copy View. The Copy View dialog appears.
b. Select the page view to copy and click OK.
You can now customize the page view by changing its page groups and pages.
To customize a page view:

1. From the Page Views drop-down list in Installation Expert, select <Customize
Page Views...>.
The Customize Page Views dialog appears.
2. Select the page view from Page View Name, and do any of the following:
To add a new page group, click the Page Groups Add button and enter a name.
To rename a page group, select the page group and click Rename.
To add a page to a page group, select the page group and click the Add button
to the right of Page Names. In the Select Pages to Add dialog, select one or
more pages and click OK.
To delete a page group or a page name, select it and click its Delete button.
3. Click OK on the Customize Page Views dialog.
To delete a page view, select it from Page View Name and click the top Delete button.
Also see Using Installation Expert on page 20.
Using the Current Feature Drop-Down List

The Current Feature drop-down list appears on pages in the Feature Details page
group. When it appears, you can set options on a per-feature or per-condition basis. You
add features and conditions on the Features page, then select a feature from Current
Feature before setting options on other pages.
Example: Suppose you have 3 features, and each feature requires different registry
entries. On the Registry page, you select the first feature from Current Feature, create
its registry entries, select the second feature in the list, create its registry entries, and
so on. Follow the same steps on the Files, Web Files, or Visual Studio Solution page:
select a feature from Current Feature, then add files for that feature.
During installation, files, registry entries, and other system changes are installed only if
the feature they belong to is installed. The same applies to conditions; add files, registry
entries, and other changes to a condition, and during installation, those files and
registry entries are installed only if the condition is true and the feature is installed.
The All Features (Modify/Delete only) option in Current Feature displays

information for all features at once. (Example: On the Files page this option displays all

Basics
folders and files for all features.) Add and New buttons are disabled while all features
are displayed; you must select a single feature to add items.
On some pages, Current Feature also contains numbers in parentheses, which

represents the number of that page’s items (files or registry keys) that are assigned to
each feature or condition.
Also see:
Using the Current Release Drop-Down List on page 25

Using Installation Expert on page 20
Using the Current Release Drop-Down List

The Current Release drop-down list appears on pages in the Release Definition page
group. When it appears, you can set options on a per-release basis by selecting a
feature from Current Release and then setting options on that page.
A release is a special version of your application. Example: a 30-day evaluation release

for evaluators. Use Current Release to configure separate settings, media, and
language options for each release.
Also see:
Using Installation Expert on page 20

Using the Current Feature Drop-Down List on page 24
About the Product Home Page

The Product Home page provides information about your installation of Wise for
Windows Installer, quick access to areas of the current installation, and access to Wise
resources on the Web.
The Product Home page appears by default when you start Wise for Windows Installer.
To prevent the Home page from appearing by default, clear Display Home page at
startup on Wise Options > General tab. To go to the Product Home page, click Home at
the lower left of the Wise for Windows Installer main window.
Two Product Home pages are available:
z A static page that is installed with Wise for Windows Installer. This appears if you do
not have an Internet connection, or if you disable the dynamic Home page.
z A dynamic page that is downloaded from the Wise Web site if you are connected to
the Internet when you start Wise for Windows Installer. To prevent a dynamic page
from being downloaded from the Internet, mark Don’t get Home page from
Internet on Wise Options > General tab.

Basics
The contents of the page vary depending on the edition of Wise for Windows Installer
that you are using. Typical contents are:
z List of most recently used installation files.
z Shortcut links for creating a new installation project or opening an existing one.
Using the Task List

When Wise for Windows Installer encounters installation issues that could cause
problems, it displays them in the Task List. You can manually display or hide the Task
List from the View menu.
The Task List gathers all installation issues into one place, and makes it easy to analyze
their causes. If the issue is caused by an error in a table, you can quickly jump from the
Task List to the row in the table that caused the error. See Finding Table Errors From the
Task List on page 27.
When you resolve the issue that corresponds to a task, the task is deleted the next time
you run the procedure that generated the task. Example: If a task was added to the
Task List because of a compile error and you resolve that error, the next time you
compile the installation that task is removed from the list.
How Tasks are Added to the Task List

z Save or Compile
If errors occur when you save or compile the installation, the errors are displayed in
the Task List.
z Package Validation
When you run Package Validation, validation issues appear in the View / Correct
dialog. If you mark the Add to Task List checkbox on the View / Correct dialog,
each issue becomes a task in the Task List when you click Finish. If Package
Validation encounters save or compile errors, the package validation process ends
and the errors are added to the Task List. See Package Validation on page 369.
z Check Tables
When you check tables, the installation is searched for component and table errors
and results are placed in the Task List. To check tables, select Setup Editor > Tables
tab, right-click in the left pane and select Check Tables. See Finding Validation
Errors on page 401.
z User-Defined
(Enterprise Edition only.) You can add user-defined tasks to the task list. See Adding
User-Defined Tasks on page 28. (Not available in the Visual Studio integrated
editor.)
z Meta Data
(Enterprise Edition only.) When you create an .MSI or .WSI, a task is added to
remind you to add the package meta data to the Software Manager database by
filling in the Application and Package fields on the Product Details page.
Note
When you close an installation, all tasks, except user-defined tasks, are removed from
the Task List. (In the Visual Studio integrated editor, user-defined tasks are not
available.)

Basics
Task List Icons

The following icons help you quickly identify the types of tasks:
An error that will cause incorrect behavior and must be fixed.
Validation issues found by Package Validation. See Validating a

Package on page 370.
A task you created. In the Enterprise Edition, this icon also appears
with a task that reminds you to add the package meta data to the
Software Manager database.
Operations You Can Perform in the Task List

z Filter tasks by type. See Filtering the Task List.
z Find table errors. See Finding Table Errors From the Task List on page 27.
z Sort a Task List’s column by clicking its header.
z Copy a task’s description by right-clicking its description.
z Delete a task by right-clicking its description.
Filtering the Task List

1. Right-click in the Task List and select Show Tasks.
2. Select a filter. (In Visual Studio: right-click in the Visual Studio .NET Task List and
select Show Tasks.)
Save/Compile
(In Visual Studio: this is called Build Errors.) Tasks that correspond to errors
generated when you save or compile.
Validation
Tasks that correspond to issues generated during Package Validation.
Component
Tasks that correspond to component errors generated when you check tables.
For information on how to check tables, see Using the Task List on page 26.
Table
Tasks that correspond to table validation errors generated when you check
tables. For information on how to check tables, see Using the Task List on
page 26.
User-Defined
Tasks that you have created. (Enterprise Edition only).
When you set a filter, it is in effect until you change it. However, when you encounter
installation issues, the filter is reset to All so installation issues can be displayed.
Finding Table Errors From the Task List

If a task is associated with a table, you can access that table directly from the Task List,
which helps you discover the problem that caused the issue.

Basics
Example: If a source file for the installation was moved or deleted at its source, a
WiseSourcePath table error appears during compile. When you double-click this task,
the WiseSourcePath table appears in Setup Editor, and the row in the table that is the
cause of the problem is highlighted. Use the source path information in the row to
ascertain and resolve the problem.
Caution
Deleting, adding, or editing table data directly is not recommended unless you are an
experienced Windows Installer developer with a clear understanding of Windows
Installer database technology. Editing table data might cause unexpected, undesirable
behavior, including damage to the installation. We cannot provide technical support for
problems arising from table editing.
To find table errors from the Task List:

If the task has a table listed in the Table column, double-click the task. The table is
displayed in Setup Editor > Tables tab, and the row in the table associated with the task
is highlighted. (In Visual Studio: a table is displayed only if a table is associated with the
task.)
If you need more information, check the task’s description or press F1 to display the
help topic for the selected table in the Windows Installer SDK Help.
Also see:
Tables Tab on page 397

Using the Task List on page 26
Adding User-Defined Tasks

¾ Enterprise edition only. Not available in the Visual Studio integrated editor.
You can add tasks to the Task List. Example: Add user-defined tasks to define work that
must be completed on the installation. Tasks you add to the Task List are saved with the
installation. You can only add user-defined tasks to a .WSI; you cannot add them to an
.MSI.
1. On the first line of the Task List, click Click here to add a new item twice and type
the task.
If Click here to add a new item does not appear in the Task List, save the
installation file and it will appear.
2. Click anywhere outside the box that contains the new task.
The task is added to the Task List and appears in the Description column. User-
defined tasks do not use the Tables column.
Also see Using the Task List on page 26.
Where are Installation Resources Stored?

Wise for Windows Installer uses resources such as installation templates, component
rules, language files, and so on, to create installations. In the Standard and Professional

Basics
Editions, these resources are stored in subdirectories of the Wise application directory.
In the Enterprise Edition, they are stored in subdirectories of the share point directory.
(Enterprise Edition only.) You can specify alternate locations for storing resources. See
Setting Repository Options on page 49.
Subdirectories Where Resources Are Stored
Directory Contents
000, 001, and so on (Enterprise Edition only.) Contains source files associated with each package’s
installation. The subdirectories are numbered sequentially, such as 000\001,
000\002, and so on. They are created when someone uses Package Distribution to
distribute to the share point. For details, see How Source Files Are Indexed on
page 32.
Custom Actions (Enterprise Edition only.) Provides a shared location in which you can place files used
in custom actions, such as WiseScripts, VBScripts, .DLLs, and so on, that you use in
Windows Installer installations.
Languages Contains the language resource files used to change the language of installations.
Merge Modules (Enterprise Edition only.) This is the default target location for downloading merge
modules, and the default directory from which you select merge modules to add to an
installation. In the Standard and Professional Editions, the default merge modules
directory is Program Files\Common Files\Merge Modules\Wise Solutions.
Reports (Enterprise Edition only.) Contains the predefined reports (.RPT) that are used in
Software Manager. Also contains the Report.ini file, which stores information about
the predefined reports and about any report customizations.
Projects (Enterprise Edition only.) The default location for new installations you create.
Resources Contains installation resources such as bitmap and icon files.
Scripts (Enterprise Edition only.) Contains temporary files (.QUE) representing packages that
have been distributed to but not yet imported into the Software Manager database.
For details, see About .QUE Files in the Software Manager Help.
The Scripts directory also stores information about package subscriptions.

Templates Contains installation templates, WfWI macros, and additional template files used by
Package Distribution.
Templates\Dialogs Contains the Wise Standard.MSI that provides information used by the New Dialog
Wizard to add a new dialog to an installation.
Templates\File Contains templates used to create a new installation. In the Visual Studio integrated
editor, these templates create installations that are not associated with a Visual
Studio .NET solution.
Templates\Project (Visual Studio integrated editor only.) Contains templates used to create an
installation as a project within a Visual Studio .NET solution.
Templates\Reports (Enterprise Edition only.) Contains the template files that are used to format the
shared resources reports in Wise for Windows Installer.
Themes Contains Themes.ini, which stores information about themes you’ve added or
customized. Also contains subdirectories that store the images for each theme.

Basics
Directory Contents
Validation Contains the predefined validation modules (.CUB files) that are used by Package
Validation.
Virtual OS (Enterprise Edition only.) Provides a shared location in which you can place Virtual OS
files (.WOS) that are used by the Universal Import feature of Software Manager.
Also see About the Share Point Directory on page 32.
Using the Enterprise Edition

¾ Enterprise Edition only.
With the Enterprise Edition of Wise for Windows Installer, you can develop consistent,
accurate, and high quality installations based on corporate standards. The Enterprise
Edition ensures that you use the correct versions of resources, such as files and registry
keys, that are shared across multiple applications. Example: A developer who adds or
updates a .DLL in an installation can instantly view a list of other applications that use
that .DLL and the versions used. The developer can use this information to ensure that
the new application uses the correct version of the .DLL and therefore will not break
existing applications.
The Enterprise Edition lets you share commonly used templates, dialog themes,
translations, and other installation resources within a single development team or
among multiple development teams. This lets developers throughout the organization
create installations with common settings and a consistent look and feel. See Sharing
Installation Resources.
The Enterprise Edition also helps organizations that use Wise Package Studio. It
eliminates the need to repackage internally developed applications, because the
organization’s developers can create installations that adhere to corporate standards. It
also reduces rework of internally developed installations by the development team and
reduces end-user downtime, because the developers who create installations can be
sure to use the correct versions of files and other resources before giving installations to
the IT deployment team. See Sharing the Software Manager Database With Wise
Package Studio in the Software Manager Help.
Also see:
About the Share Point Directory on page 32

Generating Package Contents Reports on page 33
Generating Shared Resource Reports on page 33
Sharing Installation Resources

A key feature of the Enterprise Edition is the ability to develop and enforce standards for
how installations are created. You enforce standards by storing all installation-related
resources in a common location and making sure all developers use those resources in
their installations.

Basics
In Wise Options, you can specify the directories that contain shared resources you will
use in installations. See Setting Repository Options on page 49.
You can share the following resources:
z Component rules ensure that every installation will be organized the same way,
which greatly simplifies the management of multiple product installations.
z Custom actions, such as .DLL files, JScript files, and VBScript files, that can be
added to installations.
z Installation templates, dialogs, dialog themes, languages, and resources,

such as bitmaps and icons, that are used in installations. Create installations with
common settings and a consistent look and feel.
z Merge modules ensure that developers always access approved versions of merge
modules by storing merge modules in a central location, or by using merge modules
that are in the Software Manager database.
z Validation modules (.CUB files) simplify the quality assurance process by ensuring
every installation passes the same validation tests.
z Reports let you share customized report menus and custom reports.
Sharing installation resources is accomplished through the share point directory, the
Software Manager database, and the Software Manager tool.
z The share point directory is typically installed on a shared network drive. Use the
share point directory to store resources, such as templates, dialogs, and themes,
used to create installations as well as the source files used in the application itself.
The share point directory can also contain information about applications that are
waiting to be imported into the Software Manager database and the source files
used by those applications. See About the Share Point Directory on page 32 and
Where are Installation Resources Stored? on page 28.
z The Software Manager database contains information about every resource used by
every application your organization develops. This lets developers see what
resources are used by other applications and select source files from the Wise
Software Repository, to ensure that they use the correct versions of file resources in
applications they develop. Geographically dispersed development teams can
maintain multiple Software Manager databases and use a publish/subscribe model
to pass information between repositories. See About the Wise Software Repository
in the Software Manager Help, and How Source Files Are Indexed on page 32.
z Software Manager lets you manage the information in the Software Manager
database. Use it to import applications into the database, subscribe to applications
in other Software Manager databases, and view information about the resources
used by applications in the database.
In addition to importing Windows Installer installations and merge modules,
Software Manager can import other installation formats such as WiseScripts, SMS
Installer files, InstallShield® Developer executables, and any other installation
format. This lets you import legacy installations without converting them to
Windows Installer format.
See Software Manager Basics in the Software Manager Help.
Also see Sharing the Software Manager Database With Wise Package Studio in the
Software Manager Help.

Basics
About the Share Point Directory

During the Wise for Windows Installer installation, you specify a share point directory.
The default directory name is Wise Share Point, however, you can change the name at
installation time.
For recommendations on where to locate the share point directory, see Choosing the
Location for the Share Point Directory in the Wise for Windows Installer Getting Started
Guide. You can change the share point directory in Wise Options. See Setting Repository
Options on page 49.
The Software Manager database is associated with a specific share point directory. When
you change the default share point directory, you also change the default database.
Share Point Directory Contents

z Resources that are used to create Windows Installer installations. Examples:
installation templates, component rules, language files, and so on.
z Predefined reports.
z Temporary .QUE files representing packages that have been distributed but not
imported into the Software Manager database.
z Source files of installations you import into the Software Manager database.
If your organization uses Wise Package Studio, the share point directory might contain
additional information that is unique to that product.
For a list of the share point subdirectories and their contents, see Where are Installation
Resources Stored? on page 28.
Deleting Files From the Share Point Directory

Caution
Do not edit or delete the contents of the share point directory or its subdirectories
outside of Wise for Windows Installer or other Wise tools. Doing so will cause problems
in Software Manager and can result in loss of data.
A common question is “Can I clean up the share point by deleting unused source files?”
The answer is no. It is too difficult to know which files are safe to delete.
The only recommended way to delete files from the share point directory is to delete the
entire package from the Software Manager database. When you do so, you can delete
the package’s source files from the share point subdirectories (000, 001, and so on), if
those files are not referenced by any other application. See Deleting a Package in the
Also see Sharing Installation Resources on page 30.
How Source Files Are Indexed

A sequentially-numbered directory structure is created under the share point directory
to store occurrences of installation source files when:
z You distribute a package to the share point directory.

Basics
z You import a single package or multiple packages to the Software Manager

database, and you distribute source files.
An index file named wamdb.idx, located in the share point directory, records the location
of the source files. Because files are indexed, distributing source files to the share point
eliminates storage of duplicate files and results in smaller storage requirements than if
you distribute to a network directory.
Example:
Suppose you have 3 packages, each containing a version of report.dll. The first time you
distribute a package containing report.dll, the file is placed in the share point’s 000\001
directory. If you distribute another package containing the same version of report.dll,
the file is not saved a second time, but a counter is set for that file in wamdb.idx. If you
distribute a third package that uses a different version of report.dll, the file is stored in a
second directory, 000\002. The result is a set of all the unique source files used by all
the packages in the Software Manager database.
Also see:
About the Share Point Directory on page 32

Copying an Installation to the Share Point Directory on page 282
Importing From the Share Point Directory in the Software Manager Help
Generating Package Contents Reports

Package contents reports provide an overview of the contents of an installation file and
make it easy to provide this information to end users. Two reports are available:
z Package Contents Summary

Lists detailed information for every resource in an installation, including files,
registry keys, shortcuts, file associations, and merge modules. You can generate
this report for .WSI, .MSI, .WSM, and .MSM files.
z Package Contents By Feature

Contains the same information as the Package Contents Summary report, but
arranges it by feature. You can generate this report for .WSI and .MSI files.
To generate a package contents report:

Select Reports menu > Package Contents and select either Summary or By Feature. (In
Visual Studio: Project menu > Reports > Package Contents and select either Summary
or By Feature.)
The report is generated and opens in a dialog.
Use a report’s table of contents to quickly access information about a specific type of
resource. You can print the report or save it as an HTML or XML file.
Generating Shared Resource Reports


Basics
Shared resource reports provide a quick way to review the resources that are shared by
the current installation and other packages in the Software Manager database. Two
reports are available:
z Shared Files Report

Lists the files that are shared by the current installation and applications in the
Software Manager database. For each file, the report lists each application that uses
the file and shows detailed file information (examples: version, date/time, path, and
so on).
z Shared Registry Report

Lists the registry keys that are shared by the current installation and applications in
the Software Manager database. For each registry key, the report lists each
application that uses the registry key and shows the key value.
In order to generate the shared resources reports, you must be connected to a share
point directory that is associated with a Software Manager database. Typically, this
connection is made during installation. To use a different share point directory and
Software Manager database, see Setting Repository Options on page 49.
The reports are displayed in HTML format. The .XSL templates used to format these
reports are located in the Templates\Reports subdirectory of the share point directory.
You can customize the .XSL templates to supply branding information, to filter data, or
to transform the data to another format.
You also can generate resource reports in Software Manager. The Software Manager
reports contain similar information. See Predefined Software Manager Reports in the
To generate a shared resource report:

1. Select Reports menu and select either Shared Files Report or Shared Registry
Report. (In Visual Studio: Project menu > Reports > Shared Files Report or Project
menu > Reports > Shared Registry Report.)
The Welcome dialog appears.
2. In Data Source, specify the Software Manager database that contains the
resources you want to review. If the Software Manager database you want is not
listed, click Open to select it.
3. From Group, select the group that contains the packages to compare this
installation to.
4. Click Next.
The report is generated and displayed in the Shared Files Report or Shared Registry
Report dialog.
You can save the or print the table report from this dialog. Saving to HTML is
available only on computers that contain MSXML.DLL, which is included in Internet
Explorer 5.x and higher.
5. When you finish reviewing, saving, or printing the report, click Finish.
Also see Sharing Installation Resources on page 30.

Basics
Downloading Redistributable Files

The Download Redistributables wizard, available from the Help menu, lets you obtain
merge modules, Windows Installer runtime installers, and .NET Framework runtime
installers. You need the Windows Installer runtimes if you decide to pre-install Windows
Installer with an installation. You need the .NET Framework if you are creating an
installation that contains .NET elements. Because of size and obsolescence
considerations, these files are distributed via the Internet or product CD.
Note
This wizard appears any time Wise for Windows Installer detects a dependency on other
merge modules or other redistributables. Example: If you run ApplicationWatch and a
file gets added that must be installed with a certain merge module, the Download
Redistributables wizard appears and prompts you to download the necessary merge
module. This wizard might also appear if you install runtimes with the installation, or if
you add files to the installation that are part of a merge module.
Download redistributable files from the following locations:
z Wise Web Site

Select and download one or more redistributables from the Wise Web site. See
Downloading Redistributables From the Wise Web Site or Product CD on page 35.
z Other Vendors’ Web Sites

Select and download a redistributable from a third-party vendor’s Web site.
Available redistributables are authored by the respective vendor, and you need to
contact the vendor for information or help on these redistributables. See
Downloading Redistributables From Other Vendors’ Web Sites on page 36.
Note
If you need to go through a firewall or proxy server to get to the Internet, click the
Advanced button near the bottom of the Source Location dialog to modify your Internet
connection settings; the Source Location dialog is the first dialog that appears when you
use the Download Redistributables wizard. An Advanced Settings dialog appears, where
you can specify information for your proxy server. For help with these options, ask your
network administrator.
z Product CD
Select and download one or more redistributables from the CD that was used to
install the product. See Downloading Redistributables From the Wise Web Site or
Product CD on page 35.
Downloading Redistributables From the Wise Web Site or

Product CD
You must be in an active Wise installation to follow this procedure.
1. Select Help menu > Download Redistributables. (In Visual Studio: Help menu >
Wise Help > Download Redistributables.)
The Source Location dialog appears.
2. Mark Wise Web Site or Product CD and click Next.
3. If you marked Product CD, specify the location of the CD in the Product CD
Location dialog. Then click Next.

Basics
A Download Files dialog appears while all available redistributable files are retrieved.
The Available Redistributable Files dialog then appears.
4. From Redistributable Type, select the type of redistributable to download.
5. In the Modules Available or Versions Available list, mark one or more

checkboxes for the redistributables to download.
6. Click Next.
If you chose to download any merge modules, the Target Location dialog appears,
where you specify merge modules’ download location; otherwise the download
starts and you can skip the next step. Runtimes are downloaded to private
directories where they are accessed as needed by Wise for Windows Installer.
7. From Target Location, select the directory to download the selected merge
modules to, then click Next.
The drop-down list shows all merge module directories specified in Wise Options.
See Setting Merge Module Directories on page 48.
The selected redistributables are downloaded from the Internet or CD.
8. Click Finish on the Download Files dialog to exit the wizard.
The merge modules you selected are now in the directory you specified as the target
location. If any merge modules had dependencies on other merge modules, those merge
modules were also downloaded. Other runtimes are located in their required directories.
Also see Downloading Redistributable Files on page 35.
Downloading Redistributables From Other Vendors’ Web Sites

You must be in an active Wise installation to follow this procedure. We have no control
over other vendor’s redistributable files. Check with the vendor for product support.
2. Mark Other Vendors’ Web Sites and click Next.
When all available redistributables are retrieved, the Available Redistributable Files
dialog appears.
3. In the list box, select the redistributable to download and then click Download to
connect to the vendor’s Web site.
4. Follow the links and prompts on the Web site to download the redistributable. Be
sure to download merge modules to a directory specified in Wise Options. See
Setting Merge Module Directories on page 48.
5. When the download is complete, return to the Available Redistributable Files dialog
and click Finish.
The merge modules and other runtimes you selected are now in the directory you
specified as the target location. If any merge modules had dependencies on other merge
modules, those merge modules were also downloaded.
Also see Downloading Redistributable Files on page 35.

Basics

Chapter 3
Setting Up
Before you create and edit installations, set up Wise for Windows Installer to reflect your
company’s standards:
z Set options that control the installations you create and determine the installation
resources you use.
z Decide whether you need to customize the templates that installations are based
on.
z Decide which rule set to use to help you manage the creation of components in
installations. You can edit the predefined rule sets or create new rule sets. If the
predefined rule sets do not meed your needs, you can duplicate them and modify
the copies as needed, or you can create new rule sets.
Topics include:
z Setting Options.
z Creating and Editing Installation Templates.
z Component Rules.
Setting Options
You can set options that control the installations you create and determine the
installation resources you use. Some of the options are global; they are set for all files
you open with Wise for Windows Installer, including files you created previously. Other
options provide defaults for new files and do not affect existing files.
You set options on the Options dialog, which you access by selecting Tools menu >
Options. In Visual Studio: select Tools menu > Options and click Wise Options in the list
at the left of the dialog.
The Options dialog contains several tabs. (In the Visual Studio integrated editor they are
called pages.) See:
Setting General Options

Setting .NET Assembly Options on page 40
Setting Advertising Options on page 42
Setting Digital Signature Options on page 43
Setting ExpressBuild Options on page 44
Setting Installation Expert Options on page 47
Setting Merge Module Directories on page 48
Activating Suppressed Prompts on page 49
Setting Repository Options on page 49
Setting Source Control Options on page 51
Setting the Default Target Platform on page 52
Setting Visual Studio Options on page 53
Setting Wildcard Groups on page 54

Setting Up
Setting General Options

To set general options, select Tools menu > Options and click the General tab. (In Visual
Studio: Tools menu > Options > Wise Options > General.)
Note
(Visual Studio integrated editor.) To display context-sentitive help, click the Wise Help
link on this dialog.
Automatic Options
z Create backup copy during save
Mark this to create a new backup file every time you save. The backup file name
consists of the current file name plus a number. (Example: if the current file name is
Sample.wsi, the backups are named Sample1.wsi, Sample2.wsi, and so on.) Only
the file you are working on is backed up. (Example: if you open a .WSI and save it,
the corresponding .MSI is not backed up.) Use caution with this option if you are
working with large installation files; if you save often, your disk space will quickly
become depleted.
z Add default remarks to installation sequences

Although most Wise project (.WSI) files have remarks that explain the actions in the
sequences, compiled .MSIs do not. Mark this to add remarks to the current .MSI and
all .MSIs that you open subsequently. Remarks are added to .WSIs only if no
remarks already exist.
z Don’t get Home page from Internet

Mark this to disable the dynamic Product Home page that is downloaded from the
Wise Web site and display the static Product Home page that is installed with Wise
for Windows Installer.
z Create XML copy during save

Mark this to update a copy of the installation in XML format every time you save. If
a copy does not exist, it is created. The copy has the same name as the installation
file with the extension .XML appended, and it is saved in the same directory.
(Example: If the current file name is Application.wsi, the XML copy is named
Application.wsi.xml.) This lets you check the XML version of the installation into a
source code control system and use text-based file comparison tools to find
changes. See Saving an Installation as XML on page 86.
Compiler Options
The following options are default settings for all new compiles. Changing these settings
does not affect installations that have already been compiled.
z Add custom actions for predefined folders in merge modules

This affects the merging of merge modules that place files in predefined directories,
such as \Windows, \System32, and so on. Mark this to have the merge emulate the
behavior of Microsoft’s merge tool, mergemod.dll, which uses custom actions to
handle predefined directories. Clearing this checkbox can fix potential problems with
capitalization inconsistencies in the directory name.

Setting Up
Note
Wise for Windows Installer has its own code for merging a module into an .MSI, but
this checkbox causes your merge to follow the Microsoft conventions for merging.
Microsoft’s merging code adds a custom action to the installation for each
predefined directory referenced in each included merge module. The custom action
uses a Set Property action to set the predefined directory name, whereas the Wise
for Windows Installer code sets the predefined directory name by adding an item to
the Directory table of the Windows Installer database.
z Display error if merge modules conflict with main installation rows

Merge module errors occur if a merge module contains a row that has the same key
as a row in the main installation. Clear this to ignore such errors and let the merge
module row overwrite the row in the main installation.
z Enable Quick Compile

Mark this to speed the compile process by compressing only previously
uncompressed or changed files. Quick Compile writes the .MSI table information. If
a file or media has changed, a full compile will occur instead. Quick Compile is for
project files only. You can also speed compile time by using ExpressBuild, a multi-
processor compile feature in the Professional and Enterprise Editions. See Setting
ExpressBuild Options on page 44.
Startup Options
z Display Home page at startup
Mark this to have the Product Home page appear by default when you start Wise for
Windows Installer.
z Check for Updates

Specify the frequency at which you will be reminded to check for updates to Wise for
Windows Installer. Update reminders occur only when Wise for Windows Installer is
running.
If you don’t want to be reminded to check for updates, select Never. This reduces
the possibility of a user upgrading their version of Wise for Windows Installer to a
version that is not yet supported by your organization.
z Preferred Editor
This option appears only if Microsoft Visual Studio .NET is installed. It determines
which editor is launched when you double-click a Windows Installer file. Always
Prompt always shows a dialog that prompts you to choose the editor. Last Saved
In uses the editor in which the installation file was last saved.
z Reload last project at startup

Mark this to open the last installation you worked on when you launch Wise for
Windows Installer. (Not available in the Visual Studio integrated editor.)
z Refresh Projects Integrated with Visual Studio .NET

When you open a project that has been integrated with Visual Studio .NET, this
option causes the Visual Studio solution to be rebuilt so that this installation has the
most recent files. “Integrated” means the project has been added as part of a Visual
Studio .NET solution. (Not available in the Visual Studio integrated editor.)
Setting .NET Assembly Options

¾ Windows Installer 2.0 or later only.

Setting Up
You can specify whether you create standard Win32 or .NET installations, and customize
how Wise for Windows Installer handles the .NET assemblies. Select Tools menu >
Options and click the .NET Assemblies tab. (In Visual Studio: Tools menu > Options >
Wise Options > Assemblies.)
Note
Note
If the options on the .NET Assemblies tab are disabled, install the .NET Framework and
run a manual repair of the Wise for Windows Installer .MSI from Add/Remove Programs.
(Not applicable in the Visual Studio integrated editor.)
COM Interop Options

z Default Application Type
This determines the default setting for the Application Type field on the Product
Details page for new installations. Changing this field does not affect existing
installations.
Win 32 (non .NET)

Select this if you typically create standard Win32 installations without .NET
assemblies.
.NET Application
Select this if you typically create .NET installations with only .NET elements.
Mixed (.NET and Win32)

Select this if you typically create installations containing both Win32 and .NET
elements. When this option is selected, .NET assemblies you add to an
installation are registered so that they can be called as though they were COM
components. For information on COM interoperability, search for “Interoperating
with Unmanaged Code” in the MSDN Library (msdn.microsoft.com/library/).
z Rescan COM interop registry keys on compile

Mark this to scan and update interop registry keys for .NET assemblies each time
you compile. This checkbox is available only if the .NET Framework is installed on
your computer.
Assembly Scanning Options

The scanning options are available only if the .NET Framework is installed on your
computer.
z Scan Dependencies
Specify how dependency assemblies are added to an installation. You can add them
manually or have Wise for Windows Installer scan the assembly manifest for
dependencies and add them automatically. Changing this option does not affect
assemblies that have already been added to installations.
Never scan dependencies

If you select this, you must add dependency assemblies to installations
manually on the Files, Web Files, or Visual Studio Solution page.

Setting Up
Prompt to scan dependencies

When you add a .NET assembly to an installation, Wise for Windows Installer
scans its manifest for dependencies and prompts you to select which ones to
add to the installation.
Always scan dependencies

When you add a .NET assembly to an installation, Wise for Windows Installer
scans its manifest for dependencies and adds them to the installation.
z Rescan assembly dependencies on compile

Mark this to scan for new assembly dependencies each time you compile.
z Rescan assembly attributes on compile

Mark this to rescan and update assembly attributes each time you compile. This
checkbox is marked by default.
Note
On .NET Framework versions earlier than 1.1, scanning does not occur when you add an
assembly from a UNC or mapped network drive (example: the share point directory). To
enable scanning of such assemblies, either upgrade to .NET Framework version 1.1 or
later, or change your .NET security so that the share point directory is fully trusted.
Setting Advertising Options

You can specify how to gather self-registration and advertising information for files you
add to an installation. Windows Installer considers some kinds of registry entries, such
as file extension definitions, to be advertising information. For details, see Platform
Support of Advertisement in the Windows Installer SDK Help.
To set advertising options, select Tools menu > Options and click the Advertising tab. (In
Visual Studio: Tools menu > Options > Wise Options > Advertising.)
Note
The following options are default settings for all new components. Changing these
settings will not affect existing components.
z Advertising Setting
Select one of the “scan” options to have Wise for Windows Installer inspect your
computer’s registry and the files in the installation and automatically add Windows
Installer advertising information for the files that you add to the installation.
The different scan options let you determine whether the advertising information is
added to the advertising tables (AppId, Class, Extension, Mime, ProgId, TypeLib,
Verb), to the registry, or both. The scan options also cause AppPath registry
information to be added to the installation automatically, although it is not related to
advertising. Only AppPath information at
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths\ is
added.
This system of registration is more robust than letting the file self-register at
installation time because it does not depend on the presence of other files on the
destination computer, nor does it depend on how well the .OCX or .DLL file adheres
to self-registration conventions. However, the .OCX or .DLL files must already be
registered correctly on your computer. If you prefer not to register installation files

Setting Up
on your computer, you can run the scan routine as a stand-alone utility on a
different computer. See Using WiseComCapture.exe on page 140.
Do not scan advertising information

Use self-registration for components that support it. Wise for Windows Installer
will not scan files or the registry.
Scan advertising information into registry keys

Add advertising information to the installation as registry keys only; do not
create entries in advertising tables. This results in an installation that does not
support advertising through COM.
Scan advertising information into advertising tables

Place registry entries that are considered to be advertising information into
advertising tables. Create registry entries for any information that cannot be
placed in the advertising tables. This results in an installation that supports
advertising.
Scan advertising into both advertising tables and registry

Place registry entries that are considered to be advertising information into
advertising tables AND into registry keys. This way, all advertising information is
included in the installation; none is lost.
Caution
When registry entries are created for any information that cannot be placed in the
advertising tables, the installation is more accurate because no information is lost.
However, this might cause an error or warning when you run the Application
Specification Logo test in Package Validation.
z Automatically add self-registration

Mark this to add self-registration information to the installation whenever you add
an .OCX or .DLL file that supports self-registration. Typically, .OCX and .DLL files are
self-registered dynamically on the destination computer by calling self-registration
functions. If you mark this checkbox, Windows Installer registers your .OCX and
.DLL files. The .DLL or .OCX may require certain files to be installed already in order
to self-register properly.
z Default to rescan advertising for new components

If the advertising information contained in your files might change during the
development process, mark this to scan the advertising information and update the
installation every time you compile. The scan options in the Advertising Setting
field above only read the advertising information that’s present in the file when you
first add it to the installation.
This field sets the default for new components; if you change it, existing
components are not affected. The Rescan advertising information during
compile checkbox on the Component Details dialog can override this setting for
individual components.
Setting Digital Signature Options

You can add a digital signature to an installation on the Digital Signature page. If an
installation includes a digital signature, you use the signcode.exe utility to:
z Create a hash of the code, using an algorithm such as MD5 or SHA;
z Encrypt the hash using your private key

Setting Up
z Create a package containing the code, the encrypted hash, and the publisher’s
certificate.
For information on digital signatures, visit www.verisign.com.
To set global options for digital signatures, select Tools menu > Options and click the
Digital Signature tab. (In Visual Studio: Tools menu > Options > Wise Options > Digital
Signature.)
Note
The following options apply to all future installations. They do not affect installations you
created previously.
z Signcode.exe Location
Enter the pathname of the signcode.EXE that performs the signing tasks. For
details, refer to the ActiveX SDK.
z Credentials File
Enter the pathname of the credentials file that contains your Digital ID; the path can
be relative to the .WSI you’re compiling. Your credentials file is provided by Verisign
or another certificate authority. You must use the same computer to apply for and
obtain your Digital ID. You can then use the private key and Digital ID to sign files
on a different computer.
z Private Key File

Enter the pathname of the private key file generated by your browser during the
process of applying for a Software Publisher’s ID; the path can be relative to the
.WSI you’re compiling. A private key file has the extension .PVK. If this key is lost or
stolen, contact Verisign or your certificate authority immediately.
Setting ExpressBuild Options

¾ Professional and Enterprise Editions only.
Note
For multi-processor compile to occur using distributed computers, all source files of the
installation must be on a shared drive and must be specified in the installation with UNC
paths. (Example: \\SERVER\file.exe). In addition, when you open the installation file,
you must open it in such a way that it is referenced by a UNC path. Example: After
selecting File > Open, browse to the installation underneath the My Network Places icon
or type the entire UNC path in the File Name field. These requirements do not apply to
using multiple processors within one computer.
With ExpressBuild™, you can use multiple processors to speed compile time for large
builds. Use multiple processors on the local computer, and use the main processor of
multiple distributed computers (called a build group). The processors on the local
computer can be physical or virtual processors. You can also set up your own computer
to provide processing power for another build computer.
ExpressBuild speeds compile time by distributing the time-consuming task of

compressing .CAB files among multiple processors. Therefore, the greatest time savings
are realized when you have multiple .CAB files. Specify .CAB file creation rules in
Installation Expert > Media page.

Setting Up
If you turn ExpressBuild on, it is turned on globally; that is, it is in effect for all
installation files you open, regardless of when they were created.
To set ExpressBuild™ options:

Select Tools menu > Options and click the ExpressBuild tab. (In Visual Studio: Tools
menu > Options> Wise Options > ExpressBuild.)
Note
You can mark any combination of the 3 checkboxes below. After you mark either of the
first 2 checkboxes, compiles will attempt to use multi-processor compile unless
prevented from doing so. If you mark Allow My Computer to Build for Others, your
computer is immediately available to assist in compiles being performed on other
computers.
See Requirements for Using ExpressBuild on page 46 for requirements for using the
following options, and for reasons why multi-processor compile does not take place.
z Build Using Multiple Local Processors

Mark this to have multiple processors within this computer help process compiles.
The processors on this computer can be physical or virtual processors. You must
also enter the number of local processors in the field below. There are several
requirements for using this option.
Number of Local Processors

Enter the number of physical or virtual processors available on the current
computer.
z Build Using Multiple Distributed Computers

Mark this to have more than one computer help process compiles. You must have
previously set up a build group to use this option. There are several requirements
for using this option.
Build Group Name

Enter the build group name. See How ExpressBuild Groups Work on page 45.
Build Group Domain

Enter the NT domain name of the build group. All members of a single build
group must be in the same NT domain.
z Allow My Computer to Build for Others

Mark this to have this computer be available to help process compiles initiated on
another build computer. Performance degrades while this computer helps to process
compiles. This causes WiseExpressBuild.exe to start immediately.
Build Group Name

Enter the group name of the build group that your computer will be a member
of. If another computer compiles using your build group name, then your
processor will be used to help compile.
How ExpressBuild Groups Work


Setting Up
You can specify a build group of computers within the same NT domain or workgroup to
share processing of compiles. To specify a build group, first you select an arbitrary name
for the build group. Then, on those computers that will be part of a build group, you do
one of 2 things:
z If Wise for Windows Installer is not installed, then run WiseExpressBuild.exe, which
is located in the share point directory. The Wise ExpressBuild dialog opens. Specify
the group name and whether the WiseExpressBuild.exe should open at system
startup. WiseExpressBuild.exe runs in the background and responds to and
manages compile requests from the build computer. You can open it and edit its
properties by double-clicking on its icon in the Windows taskbar.
z If Wise for Windows Installer is installed, open it on that computer. Select Tools
menu > Options, click the ExpressBuild tab, and mark the Allow My Computer to
Build for Others checkbox. (In Visual Studio: Tools menu > Options > Wise
Options > Prompts.) Then enter the group name of the build group your computer
will build for. Do this on each computer that will share processing as part of a single
build group. When you click OK on the Options dialog, the WiseExpressBuild.exe
immediately begins running on your computer, with its icon showing in the system
tray area of your taskbar.
Note
Performance slowdowns will occur on computers in build groups when they are called
upon to help process compiles.
Requirements for Using ExpressBuild

z The computer that initiates the compile of the installation must be running Windows
NT, Windows 2000, or Windows XP or later.
z If you use a computer running Windows 9.x or Me to share compile processing, the
workgroup name of the 9.x/Me computer must match its domain name. Also, the
build group name must be in 8.3 file name format.
z In the following instances, because of .CAB formation issues, multi-processor

compile does not take place and normal compiling occurs:
If you select Uncompressed external files from the Compression Option

field on the Media page.
If you select One Cab in the Cab Options field on the Media page, or if the
.MSI contains only one .CAB for some other reason.
If you select any size other than zero in the Max Media Size field on the Media
page.
If you are in a merge module.
z Because each processor compresses .CAB files, using multiple processors is more
efficient if files are arranged into multiple, moderately-sized .CAB files. To achieve
this, select One Cab per feature or One Cab per component in the Cab Options
field on the Media page.

Setting Up
Additional requirements for using the option to Build Using Multiple

Distributed Computers:
z All the installation source files must be shared so that all members of the build
group have network privileges to access them.
z The paths to all installation source files must be in UNC notation. Change paths to
UNC notation using Tools menu > Convert Source Paths. (In Visual Studio: select
Project menu > Convert Source Paths.) If any source files have paths to the local
drive (Example: C:\MyFiles\file.jpg) then multi-processor compile does not occur.
For information on using this tool, see Source Paths in an Installation on page 324.
z The path to the installation file must be referenced in UNC notation. When you open
the installation file, open it in such a way that it is referenced by a UNC path.
Example: When opening a file, browse to the installation underneath the My
Network Places icon or type the entire UNC path in the File Name field. If you
browse under the My Computer icon, the path will not be referenced in UNC
notation.
Setting Installation Expert Options

To set general options for Wise for Windows Installer and Installation Expert, select Tools
menu > Options and click the Installation Expert tab. (In Visual Studio: Tools menu >
Options > Wise Options > Installation Expert.)
Note
z View directories for all features on Files page

Mark this to display all directories on the Files or Visual Studio Solution page,
regardless of what feature the directory was created for.
Clear this to display only the directories that were created for the current feature
(the feature selected in the Current Feature drop-down list.) Example: If you
create a directory for FeatureA, and then use the Current Feature drop-down list
to go to FeatureB, you no longer see the directory you made for FeatureA. This does
not apply to the Web Files page.
z View registry keys for all features on Registry page

Mark this to display all registry keys on the Registry page, regardless of what
feature the registry key was created for. This displays a composite view of all
registry keys created for all features. If this checkbox is not marked, only keys
created for the currently selected feature (in the Current Feature drop-down list)
are displayed.
z Show merge module components

Mark this to view the files and registry entries from merge modules in Installation
Expert. You can only view merge module components in an .MSI. By default, these
items are hidden.
z Listbox Compatibility Mode

If your computer has certain video drivers, you might have problems selecting items
from list boxes within Wise for Windows Installer. If items that you select from list
boxes are continually misinterpreted by Wise for Windows Installer, mark this
checkbox to eliminate list box problems.

Setting Up
z Expand all features on Features page

Display Feature title instead of name on Features page
Display hidden features on Features page
These checkboxes determine how features are displayed on the Features page. You
can override these settings using the right-click menu on that page.
z Display the page view associated with a project when a project is opened.
Mark this to display an installation project’s default page view when the installation
opens. If you clear this checkbox, the page view in Installation Expert does not
change when you open a project regardless of its associated page view.
z Use advanced drawing routines (restart required)

If a black box appears at the bottom of the Installation Expert page group list,
cutting off the last several pages in the list, mark this checkbox and restart your
computer to eliminate the problem.
z Display Project Summary Page when a project is opened

Mark this to have the Project Summary page appear when an installation is opened.
Setting Merge Module Directories

To set default directories for storing merge modules, select Tools menu > Options and
click the Merge Modules tab. (In Visual Studio: Tools menu > Options> Wise Options >
Merge Modules.) You also can access these options when you add a merge module to an
installation; click the Directories button on the Select Merge Module dialog. See Adding a
Merge Module to an Installation on page 345.
Note
You can store merge modules on a local drive or a shared network drive. When you add
a merge module to an installation, you can select from the merge modules in the
directories you specify here. When you use the Download Redistributables wizard, you
can download merge modules to directories you specify here.
In the Enterprise Edition, you can use merge modules that are in the Software Manager
database, which helps ensure that developers always access approved versions of
merge modules.
z Default Merge Module Directory

Shows the path to the default merge module directory. All merge modules that are
in this directory—along with the merge modules that are in the directories shown in
the Directory list below—are listed on the Select Merge Module dialog that appears
when you click the Add button at the right of the Merge Modules page.
To exclude the merge modules in the default directory from the list, mark Do not
show merge modules from the Default Merge Module Directory.
z Read Merge Modules List From Software Manager Database

(Enterprise Edition only.) Mark this to include merge modules from the Software
Manager database on the Select Merge Module dialog that appears when you click
the Add button on the Merge Modules page.
z Directory
Enter additional directories where merge modules are stored. Merge modules in
these directories are listed on the Select Merge Modules dialog. Example: If you
save your company’s user-created merge modules in the shared network directory

Setting Up
V:\Modules, and you add V:\Modules to the Directory list, the merge modules in
that directory will appear on the Select Merge Module dialog.
To add a directory to the list, click Add, browse for the directory, and click OK. To
include subdirectories in the search, mark the checkbox in the Include Subdirs
column. The next time you click the Add button on the Merge Modules page,
modules in that directory appear on the Select Merge Module dialog.
To delete a directory from the list, click the directory and click Delete. Merge
modules in that directory will no longer appear on the Select Merge Module dialog.
Activating Suppressed Prompts

Some of the prompts that appear in Wise for Windows Installer contain a Don’t show
this message again checkbox that lets you suppress the prompt in the future.
To reactivate prompts that you previously suppressed:

1. Select Tools menu > Options and click the Prompts tab. (In Visual Studio: Tools
menu > Options > Wise Options > Prompts.)
The dialog lists the prompts you have suppressed and shows your last response to
each prompt. If you have not suppressed any Wise for Windows Installer prompts,
nothing is listed.
2. Select the prompt message line and click Activate.
The prompt is removed from the list. The next time you encounter a situation in
which that prompt applies, the prompt will appear.
Note
Setting Repository Options

You can specify the directories that contain shared resources you use in installations.
Select Tools menu > Options and click the Repository tab. (In Visual Studio: Tools menu
> Options > Wise Options > Repository.) You also can change the share point directory
and Software Manager database from this dialog.
Note
For information about sharing resources, see Sharing Installation Resources on page 30.
Note
Changing the share point directory or a specific path does not copy resources to the new
location. The new location you specify must already contain resources. Typically, you will
specify a share point or path that is already in use by another team.

Setting Up
z Share Point
(Read-only.) This displays the share point directory that contains the shared
resources. You cannot edit this field, however, you can click Configure to connect to
a different share point directory. When you click Configure, the Share Point
Directory dialog appears. Browse to an existing share point directory and click Next.
If the share point you selected was created in an older version of Wise software,
then you might also be prompted to enter the Software Manager database name
and the server where it resides. When the share point has been changed, click
Finish to end the wizard.
Note
(Visual Studio integrated editor only.) You must restart Visual Studio .NET for the
share point change to take effect.
z Repository Data Source

(Read-only.) This displays the Software Manager database data source that is
associated with the share point directory above. The database displayed here is
used as the default in Package Distribution when you distribute to the share point
directory.
Default locations are set for specific types of resources based on the share point
directory above. Typically, you will use the default locations. If you want to set individual
share locations for specific resources, click Advanced. The Repository Advanced Settings
dialog appears. To change a default location, double-click one of the following items in
the list box and browse to a new path.
You can use the variable [WiseSharePoint] to represent the share point directory in the
following paths. You also can use the predefined variables that appear on the Path
Variables page. However, you cannot use other user-defined path variables because they
are specific to a single installation and the following paths are global options.
z Component Rules
Specify the location of ComponentRules.ini, which contains the rules that govern
how components are created in installations.
Caution
If you are sharing component rules in the Enterprise Edition, be careful when editing
existing rule sets because your changes will overwrite rule sets used by other
members of the development team.
z Custom Actions
Specify the location in which you will save files used in custom actions (examples:
WiseScripts, .DLL files, JScript files, and VBScript files) that can be added to
installations. This is the default location whenever you browse for a file in a custom
action dialog.
z Default Project Directory

Specify the default directory in which all new installations will be saved. The default
is the Projects subdirectory of the share point directory.
Note
Changes in this field do not take effect until you exit and restart the product.
z Dialogs
Specify the location of the Wise Standard.MSI that contains information used by the
New Dialog Wizard to add a new dialog to an installation.

Setting Up
z Languages
Specify the location of language resource files.
z Resources
Specify the location of the icon and bitmap resources that are used in installations.
z Templates
Specify the location of installation templates and WfWI macros.
z Themes
Specify the location of the themes that are used to customize installation dialogs.
z Validation Modules
Specify the location of the validation modules (.CUB files) and settings used in
Package Validation.
Also see Setting Options on page 38.
Setting Source Control Options

¾ Not available in the Visual Studio integrated editor.
You can set options that enable source control functionality. Select Tools menu > Options
and click the Source Control tab.
The following global options set the levels of interaction Wise for Windows Installer has
with your source code control system (SCCS). For details, see Using Source Control on
page 314.
The following options apply to the current installation and all future installations.
Changing these options does not affect installations you created previously.
Note
If the following options do not appear on the Source Control tab, you probably don’t
have a source code control system on your computer. It could also be that your SCCS is
unrecognized or that there are communications problems between the SCCS server and
your computer.
z Enable source control

Mark this to enable all source control functionality both in the current installation
and all future installations. When you mark this checkbox, the following 3
checkboxes are enabled, as well as the items in the Source Control menu. When
source control is enabled, you can add files to source control, check files in and out,
get the latest version of files, track history, and view differences.
z Check out file when it is opened

If this is marked, then each time you open a file that has been previously checked
in, the file will be automatically checked out for you. If your source code control
system is not available, you can cancel attempts to connect and work on the local
copy of the file.
z Check in file when it is closed

If this is marked, then each time you open a file that has been previously checked
out, the file will be automatically checked in for you.
z Add new files to source control

If this is marked, then each time you create a new installation file and save it, you
will be prompted to add it to your source code control system.

Setting Up
Enabling the source control options above does not implement source control in the
installation. It merely enables you to add and remove files from the source code control
system, and to check them in and out. Use the options on the Source Control menu to
perform these tasks.
Setting the Default Target Platform

You can determine the default platform for new installations and set options for
converting existing 32-bit installations to 64-bit. Select Tools menu > Options and click
the Target Platform tab. (In Visual Studio: Tools menu > Options > Wise Options >
Target Platform.)
Note
Note
64-bit installations are supported only by Windows Installer 2.0 or later.
z Target Platform Selection

The options in this section determine whether new installations you create are
enabled for 64-bit or 32-bit platforms.
Note
(Visual Studio integrated editor only.) The Setup Wizard contains options that let
you change the target platform for a particular project.
Default to 64-bit .MSI/.WSIs

If you mark this, all new .MSI and .WSIs that you create are 64-bit enabled.
Default to 32-bit .MSI/.WSIs

If you mark this, all new .MSI and .WSIs that you create are 32-bit enabled.
Select platform in New Installation File dialog

If you mark this, you can select the platform for each new installation in the
Target Platform section of the New Installation File dialog. (Not available in the
Visual Studio integrated editor.)
z Convert 32-bit .MSI/.WSIs to 64-bit

Mark this to convert 32-bit .MSI and .WSIs to 64-bit when you open them.
Caution
If you mark this checkbox but not the next 2 checkboxes, then every 32-bit
installation file you open is converted to and saved as 64-bit.
When you mark this checkbox, the following checkboxes are available:
Prompt before converting 32-bit files to 64-bit

Mark this to display a warning message each time you are about to convert a
32-bit file to 64-bit.
Preserve original 32-bit .MSI/.WSIs when converting to 64-bit

Mark this to leave the original 32-bit installation file intact and create a 64-bit-
enabled copy. When you save the 64-bit file, its file name defaults to the

Setting Up
original file name with “(64-bit)” appended to the end. Example: If your original
file is named MyApp.wsi, the file name for the new 64-bit installation file will be
MyApp (64-bit).wsi.
Note
You cannot convert 64-bit installations to 32-bit.
Also see:
Specifying the Target Platform in an Installation on page 76

Setting Options on page 38
Setting Visual Studio Options

¾ Visual Studio integrated editor only.
To set global defaults for the way your installations integrate with Visual Studio .NET
solutions, select Tools menu > Options > Wise Options and click Visual Studio. The
Visual Studio options apply only to installations that are integrated with a Visual Studio
.NET solution. The Visual Studio options provide defaults for future installations.
Changing these options does not affect installations you created previously.
Note
Projects Options
To override these defaults for individual installations, or to change them for existing
installations, edit the Projects page of the installation project settings. See Entering
Project Settings on page 77.
z Scan Method
Each time you load, save, or build an installation project or change its settings, Wise
for Windows Installer can scan the other projects in the solution for new files to add
to the installation. See Scanning the Solution for New Files on page 82.
Specify the default level of scanning that will occur for new installations.
Never scan solution

If you select this, you must add new files to installations manually using the
Files page. Also, when files are removed from a solution, you must remove
them from the installations manually.
Prompt only when new files are detected

Select this to be prompted each time there are new files in the solution that
need to be added to the installation. The prompt appears during save, build, or
compile.
Prompt when any files are detected

This is the highest level of prompting. Like the previous option, the prompt
appears during save, build, or compile when there are new files. Also, if you
previously excluded files by clearing their checkboxes, you’ll be prompted to
confirm that those files should be excluded.

Setting Up
Always scan solution

Each time Wise for Windows Installer scans a solution, it adds new files to the
installation and deletes files that have been removed from the solution.
z Bind installed files to the solution build configuration

Mark this to set the default for new projects you create. This option causes the
installation source paths to change automatically when you change a project’s build
configuration. To change this option for an existing project, right-click a project
name in Solution Explorer, and select Properties.
Main Project Options

To override these defaults for individual installations, or to change them for existing
installations, edit the Main Project page of the installation project settings. See Main
Project Page on page 80.
z Automatically Update Product Information

Mark this to update the installation’s product name, version, and manufacturer
whenever you rebuild the solution or whenever the version number of the main
target file changes.
z Create Shortcut
Mark this to add a shortcut for the main target file to each installation.
Also see Setting Options on page 38.
Setting Wildcard Groups

On the Wildcard Groups tab, you can create groups of wildcards so you don’t have to
type multiple wildcards repeatedly. Select Tools menu > Options and click the Wildcard
Groups tab. (In Visual Studio: Tools menu > Options> Wise Options > Wildcard Groups.)
On the Files and Web Files pages in Installation Expert, you use the wildcard groups
when you add directory contents. Wildcard groups on the Wildcard Groups tab appear in
the Include Wildcards list on the Add Contents and Wildcard Details dialogs. Select a
wildcard group to add just a subset of the files in the directory whose contents you are
adding.
Several wildcard groups are predefined, which you can edit. If you delete them, they are
recreated on application launch. Also, wildcards that you enter in any Include
Wildcards field are added to the list of wildcard groups.
Note
To add a wildcard group so it appears in Include Wildcards:

1. On the Wildcard Groups tab, click Add.
The Wildcard Group Details dialog appears.
2. Complete the dialog and click OK:
Group Name
Enter a name to precede the wildcards in the Include Wildcards list. This is a
visual identifier to help you quickly find the wildcards in the list.

Setting Up
Wildcards
Enter semi-colon delimited wildcards. (Example: Enter *.EXE;*.DLL for all .EXE
and .DLL files. A ? represents any one character.)
Later, when you add contents or set automatic updating on the Files or Web Files page,
this wildcard group is available from the Include Wildcards list.
Creating and Editing Installation Templates

Templates are stored in the Templates directory.
z In the Standard and Professional Editions, the Templates directory is under the Wise
for Windows Installer application directory.
z In the Enterprise Edition, the Templates directory is under the share point directory.
This lets all developers in your organization access the same templates.
For details, see Sharing Installation Resources on page 30 and Where are Installation
Resources Stored? on page 28.
Caution
Editing predefined templates is not recommended, because they might be overwritten
during upgrades. Instead, save customized templates with different names, or make
copies of the predefined templates and edit the copies.
About Installation and Merge Module Templates:

When you create a new installation or merge module, it gets its configuration from a
template file. Templates contain logical defaults and commonly used settings. Some
template files are predefined and appear when you create a new installation. You also
can create your own templates.
Example: Suppose that all the installations you create have the same system
configuration requirements and the same dialogs. You can create a custom template
that has those changes preconfigured. To do this, you would create a new installation,
make the necessary changes to the System Requirements and Dialogs pages, and then
save the installation in a specific location. Thereafter, every time you create a new
installation, the template you saved is available to base new installations on.
To create a custom template in the Wise editor:

1. Select File menu > New.
The New Installation File dialog appears.
2. Select a template file on which to base the new template and click OK. Only icons
that have a corresponding file in the Templates directory are templates; other icons
cannot be used to create or edit templates.
A new installation or merge module opens.
3. Make all the changes that should appear in installations created with this template.
4. To include a description that will appear in the New Installation File dialog when you
click this template:
a. Select Setup Editor > Product tab.
b. Click the Summary icon.

Setting Up
c. In the upper right pane, double-click Comments.
d. On the Summary Details dialog that appears, enter a description of this

template in Value and click OK.
5. When you finish editing the installation, select File menu > Save As. In the Save As
dialog, name the file and save it in the Templates directory as a .WSI, .MSI, WSM,
or .MSM.
When you save the installation template, a page view is created with the same
name and is listed in the Page Views drop-down list. However, when you use the
template to create an installation, the default page view is the page view that was
displayed when the template was created. If the template’s default page view is a
6. To test the new template, select File menu > New.
The New Installation File dialog appears and the file you just created appears in the
Custom Templates category. If the New Installation File dialog does not contain
the new template, verify that you saved it as a .WSI, or .WSM in the Templates
directory.
7. Select the template you just created and click OK.
8. Verify that the changes you made in the template are present in this new installation
file.
To create a custom template in the Visual Studio integrated editor:

1. If a solution is open in Visual Studio .NET, close it.
2. Select File menu > New > File.
The New File dialog appears.
3. From the Categories list, select Wise Files.
4. In the Templates list, select an icon on which to base the new template. Some
icons are not templates, but instead invoke an import process or prompt to create a
new transform.
To create a template in .WSI or .WSM format, select a project icon (name ends
with “Project”).
To create a template in .MSI or .MSM format, select a file icon (name ends with
“File”).
5. Click Open.
A new installation or merge module opens.
6. Make all the changes that should appear in installations created with this template.
7. When you finish editing the installation, select File menu > Save As. Name the file,
and save it in either:
Templates\Project directory (.WSI or .WSM). These templates appear when you

select File menu > New > Project.
Templates\File directory (.MSI, .MSM, or .WSI). These templates appear when

you select File menu > New > File.
When you save the installation template, a page view is created with the same
name and is listed in the Page Views drop-down list. However, when you use the
template to create an installation, the default page view is the page view that was

Setting Up
displayed when the template was created. If the template’s default page view is a
8. To test the new template, do the following:
If you saved the template in the Templates\Project directory, select File menu >
New > Project. On the New Project dialog, click Wise Setup and Deployment
Projects in the Project Types list. Your new template should appear in the
Templates list.
If you saved the template in the Templates\File directory, select File menu >
New > File. On the New File dialog, click Wise Files in the Categories list. Your
new template should appear in the Templates list.
10. To test the template, verify that the changes you made in the installation template
are present in this new installation file.
Component Rules
You can select or create rules that help you manage the creation of components in an
installation. Using component rules eliminates the need to specify component
information for every individual resource you add to an installation and ensures that
components are created consistently across all installations. Component rules can also
help you align component GUIDs in an upgrade with component GUIDs in previous
versions of the installation.
When you first create an installation, you select a component rule set to manage
components you add to that installation. Then, whenever you add a resource, such as a
file, registry key, shortcut, or anything else that can be installed, components are
created for those resources in accordance with the rule set you selected. Example: You
can always create a new component for each new file added to the installation, or you
can group related resources, such as help files, into one component.
Two predefined rule sets are provided. You might find that they manage your
components satisfactorily and no customization is necessary. If the predefined rule sets
do not meed your needs, you can duplicate them and modify the copies as needed, or
you can create new rule sets to reflect your company’s standards. For descriptions of the
predefined rule sets, see Microsoft Best Practices Component Rule Set on page 63 and
One File Per Component Rule Set on page 64. For instructions on creating new rule sets,
see Customizing Component Rules on page 60.
(Enterprise Edition only.) You can share component rules with others in your
organization via a share point directory. Sharing component rules ensures that you
always use the most current set of rules and that your installations always adhere to
company standards for creating components. To share component rules, select Tools
menu > Options, click the Repository tab, and click the Advanced button. (In Visual
Studio: Tools menu > Options > Wise Options > Repository.) Make sure a shared
directory is specified for the Component Rules path. See Setting Repository Options on
page 49.
About Component Rules

A component rule set manages components that are added to installations.
z A rule set is a collection of rules.

Setting Up
z A rule consists of one or more conditions and one or more actions.
z A condition determines the criteria that a resource must meet in order for an action
to be performed. Example: If you select the condition Added resource is a Shortcut,
the action is only performed for shortcut resources.
z An action determines how a resource will be assigned to a component.
In the Standard and Professional Editions, rule sets are stored in the registry. In the
Enterprise Edition, rule sets are stored in an .INI file located in the share point directory.
You can change the location; see Setting Repository Options on page 49. Do not attempt
to edit the .INI file outside of the Component Rules dialogs.
Caution
If you are sharing component rules, when you edit existing rule sets your changes will
overwrite rule sets used by other members of your team.
How Component Rules Are Applied

Component rules are applied in the order they appear from top to bottom in the list of
rules on the Customize Component Rules dialog. When a rule has multiple conditions,
only resources that meet all the conditions have the rule applied to them. Once an
added resource matches the conditions in a rule, the action is applied and no
subsequent rules are evaluated for that resource. If you add a resource that does not
meet any of the conditions in the rule set, then the Microsoft Best Practices rule set is
used for that resource.
Selecting a Component Rule Set

Use the Component Rule Selection dialog to select a rule set and component naming
conventions for the current installation or to set the default rule options for all future
installations.
The component key values you enter on the Component Rule Selection dialog can be
overridden by specific rules. Example: If you use a rule set that contains rules for
naming certain types of components, then only the components that do not meet the
conditions in the rule set will be named using the component key value options you
specify here.
To select a component rule set:

1. Select Component Rules menu > Select Rule Set. (In Visual Studio: Project menu >
Component Rules > Select Rule Set.)
The Component Rule Selection dialog appears.
2. From Rule Set Name, select the rule set to use for this installation.
3. To make the specified rule set the default for all future installations, mark Make
this the default rule set for all Windows Installer files.
4. In the Component Key Values section, select an option from the Default list to
determine the naming convention for new components. If the rule set you use
specifies the component naming under certain conditions, the naming convention
you specify here will be overridden when those conditions are met.
Set component key to a named Base

Select this to name new components with specified text plus an incremental
number. Selecting this option enables the Base field. Enter text to serve as a

Setting Up
base for the component name (example: Component). Component names will
be incremented from this base (example: Component1, Component2, and so
on).
Set component key to key of keypath or first resource

Select this to name components as follows:
If the resource is a file, registry key, or ODBC data source, give the
component the same name as the key of the keypath.
For any other type of resource, give the component the same name as the
key of the first resource in the component.
Set component key to table name of keypath or first resource

Select this to give new components the name of the table in which the keypath
or first resource resides. If multiple components are named for the same table,
an incremental number is added to the component name (example: File1, File2,
and so on).
5. From Files, you can select a different naming convention for components that are
based on file resources. You can use the long file name of the keypath file, the short
file name of the keypath file, or the naming convention specified in the Default field
above.
6. To make the options in the Component Key Values section the defaults for all
future installations, mark Make this the default key naming convention for all
installations.
7. Click OK on the Component Rule Selection dialog.
All resources that you add to this installation from this time forward will be organized
into components according to the rule set and other conventions you specified.
Using Component Rules to Align GUIDs in an Upgrade

Component rules can help you align component GUIDs in an upgrade with component
GUIDs in previous versions of the installation. If GUIDS or key paths for the same
component don’t match between the new and old .MSI, the component could
inadvertently get deleted because Windows Installer does not recognize the components
as being the same. Aligning component GUIDs for matching components prevents
upgrades from deleting necessary files in the newer version.
If you are working on an upgrade installation, you specify the previous versions of the
installation on the Previous Installation Versions dialog. Then, make sure you use a
component rule set that contains a rule for aligning component GUIDs with previous
versions. Example: The 2 predefined rule sets contain a rule in which, if the keypath
resource matches a resource in the previous .MSI list, the component layout of the
previous .MSI is matched and the component key is set to match the previous version.
All new resources you add to the upgrade installation will be checked against the
previous installations.
To ensure that all resources you add to an upgrade installation are aligned with previous
versions, specify the previous installation versions before adding any resources to the
installation. If you have already added resources to the installation, as is the case when
you use a copy of a previous .WSI as a starting point for creating an upgrade
installation, you must run UpgradeSync to align GUIDs for existing components.

Setting Up
To use component rules to align GUIDs in an upgrade:

1. Create or open the upgrade installation.
2. If you have already added resources to the upgrade installation, run UpgradeSync to
align GUIDs for existing components. See UpgradeSync on page 300.
3. Select a rule set to use for this upgrade. See Selecting a Component Rule Set on
page 58. Make sure the rule set you select contains a rule for aligning component
GUIDs with previous versions; this should be the first rule in the rule set.
For best results, use the same rule set, if any, that was used in the previous
versions. That way, component creation in the upgrade will be consistent with the
previous versions.
4. Select Component Rules menu > Previous Versions. (In Visual Studio: Project menu
> Component Rules > Previous Versions.)
The Previous Installation Versions dialog appears.
5. On the Previous Installation Versions dialog, specify the previous versions of this
installation.
To add a previous version .MSI to the list, click Add, click to browse to the
.MSI, and click Open. The .MSI is added to the list.
The previous versions will be checked in the order they appear in this list.
6. Click OK on the Previous Installation Versions dialog.
All new resources you add to the upgrade installation will be checked against and
aligned with the previous installations you specified.
Customizing Component Rules

If the predefined component rule sets do not reflect your company’s standards, you can
create a new rule set. The predefined rule sets, Microsoft Best Practices and One file per
component, are read-only and cannot be modified. However, you can copy a predefined
rule set and modify the copy.
When creating new rules, refer to Microsoft’s rules for creating components; see
Organizing Applications into Components and Changing the Component Code in the
Windows Installer SDK Help.
Caution
To add a new component rule set:

1. Select Component Rules menu > Customize. (In Visual Studio: Project menu >
Component Rules > Customize.)
The Component Rules Manager dialog appears, listing the predefined rule sets and
custom rule sets you have created.
2. Click New.
The Enter Rule Set Name dialog appears.
3. Enter a unique Rule Set Name to identify this rule set and click OK.

Setting Up
The new rule set name appears and is selected in the Component Rules Manager
dialog.
4. Click Modify.
The Customize Component Rules dialog appears.
5. In the Customize Component Rules dialog, click Add to add the first rule for this rule
set.
This starts the Component Rule Wizard, which you step through to add the
conditions and actions that comprise the rule. For details on using the Component
Rule Wizard, see Adding and Editing Component Rules on page 61.
6. When you have finished adding rules to the rule set, click OK in the Customize
Component Rules dialog and then click OK in the Component Rules Manager dialog.
The new rule set is added to the list of available rule sets. To use the new rule set for the
current installation or to make it the default for all future installations, you must select it
as described in Selecting a Component Rule Set on page 58.
To customize an existing component rule set:

any custom rule sets you have created.
2. Click a rule set.
To copy the rule set, click Copy, type the new name on the Enter Rule Set Name
dialog, and click OK.
To modify the rule set, click Modify. The Customize Component Rules dialog
appears, where you can add, edit, and delete rules. For details, see Adding and
Editing Component Rules on page 61.
Note
If you selected a predefined rule set, all the buttons on the Customize
Components Rules dialog are disabled because the predefined rule sets are
read-only. However, you can use this dialog to view the rules in a predefined
rule set.
To rename the rule set, click Rename, type the new name on the Enter Rule Set
Name dialog, and click OK.
To delete the rule set, click the Delete button to the right of the rule set name.
3. Click OK in the Customize Component Rules dialog.
Adding and Editing Component Rules

You can add component rules to a rule set, edit existing component rules, and delete
component rules.
The predefined rule sets, Microsoft Best Practices and One file per component, are read-
only and cannot be modified.

Setting Up
Caution
To edit a component rule:

any custom rule sets you have created.
2. Click a rule set and click Modify.
The Customize Component Rules dialog appears.
To add a rule, click Add. This starts the Component Rule Wizard, which lets you
define component rules. For details, see the procedure below.
To edit a rule, click the rule in the rules list and click Details. This starts the
Component Rule Wizard, which you can step through to change the rule name
or change any of the conditions or actions. For details, see the procedure below.
3. When you finish, click OK on the Customize Component Rules dialog.
The Component Rules Manager dialog reappears.
4. Click OK.
To add or edit a component rule:

1. On the Name dialog of the Component Rule Wizard, enter a name for the new rule
and click Next. If this is an existing rule, the name is already entered and you can
accept or change it.
The Conditions dialog appears.
2. In the Which condition(s) do you want to check? list, mark the checkbox next
to each condition to check.
When there are no conditions for performing the action(s) in this rule, select the
condition Always perform associated action.
As you mark checkboxes, the conditions appear in the Rule description list. If you
select a condition that is incompatible with a condition you’ve already selected, the
first condition you selected is removed from the list.
3. If a condition contains underlined text, click the underlined text to open a Rule
Details dialog. There you can select a value for the underlined text.
Example: If you selected the condition Added resource is a file with name any,
you would click the word any and enter a specific file name. Wildcards are allowed.
4. When you’ve added all conditions that comprise the rule, click Next on the
Conditions dialog.
The Actions dialog appears.
5. In the Which action(s) do you want to perform? list, mark the checkbox next to
the action or actions to perform.

Setting Up
The actions you mark appear in the Rule description list. If you select an action
that is incompatible with an action you’ve already selected, the first action you
selected is removed from the list.
6. If an action contains underlined text, click the underlined text to open a Rule Details
dialog. There you can specify a value for the underlined text.
Example: If you selected the action Set component key to Component, you
would click the word Component and enter specific text.
7. When you’ve added all actions to the rule, click Finish on the Actions dialog.
The Customize Component Rules dialog reappears. The rule is displayed in the
upper list box and its details are displayed in the Rule description list.
8. You can continue to add and edit rules. When you finish, click OK on the Customize
Component Rules dialog.
The new rules are added to the rule set and the Component Rules Manager dialog
reappears.
9. Click OK.
Microsoft Best Practices Component Rule Set

When you use this predefined rule set, components are created using Microsoft’s
component creation guidelines; see Organizing Applications into Components and
Changing the Component Code in the Windows Installer SDK Help.
If an added resource does not meet the conditions in a rule, the next rule is evaluated
for that resource. If the resource does not meet the conditions in any of the rules, the
component is created according to the final rule.
z Match components in previous versions of the .MSI

If the keypath resource matches a resource in the previous .MSI list, match the
component layout of the previous .MSI and set the component key to match the
previous version.
z Add all executable files to their own components

If the added resource is a 32-bit executable file (.DLL, .OCX, or .EXE), create a new
component.
z Add all .TLB files to their own components

If the added resource is a .TLB file, create a new component.
z Group Matching .HLP and .CNT files together

If resource file names are the same and their file extensions are .HLP or .CNT, add
them to the same component. The .HLP will be the keypath file.
z Group matching .CHM and .CHI files together

If resource file names are the same and their extensions are .CHM or .CHI, add
them to the same component. The .CHM will be the keypath file.
z Put registry keys associated with files or components in matching

components
If the added resource is a registry key, and the registry value name or value refers
to a file or component, add the resource to an existing component that contains the
same type of resource.

Setting Up
z Put Current User registry keys in their own component

If the added resource is a registry key under HKEY_CURRENT_USER, add the
resource to the component matching the conditions and set the component key
base to CurrentUser. The component key base will be incremented for each new
component matching this condition. Example: CurrentUser1, CurrentUser2, and so
on.
z Put non-Current User registry keys in their own component

If the added resource is a registry key NOT under HKEY_CURRENT_USER, add the
resource to an existing component that contains the same type of resource.
z Group all non-executable files to their own component

If the added resource is not a 32-bit executable file (.DLL, .OCX, or .EXE), add the
z Name new non-advertised shortcuts by destination directory

If the added resource is a shortcut, add it to an existing component containing non-
advertised shortcuts in the same destination directory.
z Group non-keypath resources by resource type

If the added resource cannot be set to the keypath, that is, if it is not a file, registry
key, or ODBC data source, add the resource to an existing component that contains
the same type of resource.
z Create new components for resources not matching other criteria

For all other resources that do not match the criteria above, create a new
component for the resource and set the component key to the table name of the
keypath or the first resource. If multiple components are named for the same table,
an incremental number is added to the component name. Example, File1, File2, and
so on.
One File Per Component Rule Set

When you use this predefined rule set, each file you add to the installation becomes its
own component.
If an added resource does not meet the conditions in a rule, the next rule is evaluated
for that resource. If the resource does not meet the conditions in any of the rules, the
component is created according to the final rule.
z Match components in previous versions of the .MSI

If the keypath resource matches a resource in the previous .MSI list, match the
component layout of the previous .MSI and set the component key to match the
previous version.
z Add all files to their own components

If the added resource is a file, create a new component.
z Put registry keys associated with files or components in matching

components
If the added resource is a registry key, and the registry value name or value refers
to a file or component, add the resource to an existing component that contains the
same type of resource.
z Put Current User registry keys in their own component

If the added resource is a registry key under HKEY_CURRENT_USER, add the
resource to the component matching the conditions and set the component key
base to CurrentUser. The component key base will be incremented for each new

Setting Up
component matching this condition. Example: CurrentUser1, CurrentUser2, and so

on.
z Put non-Current user registry keys in their own component

If the added resource is a registry key NOT under HKEY_CURRENT_USER, add the
z Name new non-advertised shortcuts by destination directory

If the added resource is a shortcut, add it to an existing component containing non-
advertised shortcuts in the same destination directory.
z Group non-keypath resources by resource type

If the added resource cannot be set to the keypath, that is, if it is not a file, registry
key, or ODBC data source, add the resource to an existing component that contains
the same type of resource.
z Create new components for resources not matching other criteria

For all other resources that do not match the criteria above, create a new
component for the resource and set the component key to the table name of the
keypath or the first resource. If multiple components are named for the same table,
an incremental number is added to the component name. Example: File1, File2, and
so on.

Chapter 4
Working With Wise Installation Files
This section describes the basic procedures for working with installation files.
Topics include:
z Before You Create an Installation.
z File Types.
z Project Files and Database Files.
z Options for New Installations.
z Starting a New Installation.
z Specifying the Target Platform in an Installation.
z Entering Project Settings.
z How the Installation Integrates With the Solution.
z Scanning the Solution for New Files.
z Opening an Installation Package.
z Comparing Windows Installer Files.
z Saving an Installation as XML.
z Working With Installations in the Software Manager Database.
z Compiling, Testing, and Running An Installation.
Before You Create an Installation

To avoid interruptions during installation development, gather the following information
before you begin creating an installation in Wise for Windows Installer.
z All the files to install on the destination computer. This includes program files, files
necessary for optional features, related .DLLs, drivers, and other support files.
(Visual Studio integrated editor only.) Some of these files (examples: .DLLs, .OCXs,
and .EXEs) might be added automatically when you create the installation project.
z Any third-party installations that the installation will provide. Example: Adobe
Acrobat Reader.
z Which files and other system changes comprise which features. (In Windows
Installer, a feature is a distinct part of your application’s functionality. Examples: a
spell-checker, a thesaurus, or a collection of clip art.) If the installation will let end
users select optional components, you must organize files into features when you
create the installation.
z A list of the changes that must be made to system information files (examples: .INI
files, the registry, and so on) for your application to run properly.

z The application’s system requirements in as much detail as possible. Consider not

only memory and disk requirements, but also the minimum screen depth and
resolution, and the minimum required version of the operating system.
z Any custom graphics, referred to as billboards, that should be displayed during

installation.
z Any changes that should be made to the dialogs that will be displayed during
installation. See Using the Dialogs Page on page 430 for a list of dialogs.
z If applicable, a Readme file and a license agreement file.
File Types
In Wise for Windows Installer, you can create and edit different types of Windows
Installer database files. You can work in the Windows Installer database file or in a
project file that contains instructions for compiling the Windows Installer database file.
See Project Files and Database Files on page 68. Each extension is described below.
Extension Description
.MSI Windows Installer database, which is a distributable installation. The .MSI extension is
associated with the Windows Installer executable, MSIExec.EXE. When an .MSI is
opened, Windows Installer executes it, thereby installing the application.You can open
and edit an .MSI in Wise for Windows Installer; however, options that have to do with
creating an .MSI, such as those on the Releases, Release Settings, and Media page,
are disabled. To convert an .MSI to a project file (.WSI), see MSI to WSI Conversion on
page 364.
.WSI Windows Installer project file, which describes an .MSI but does not store contents. It
is in the same format as an .MSI. You edit a .WSI in Wise for Windows Installer and
compile it to the corresponding .MSI. The .WSI is smaller in size and you can set
multiple options for the output of the .MSI.
.WSPROJ (Visual Studio integrated editor only.) Visual Studio project file for a Windows Installer
installation. When you create an installation project in Visual Studio .NET, a
corresponding .WSPROJ file is created in the same location. The .WSPROJ file points to
the .WSI.
.MSM Windows Installer merge module, which is a pre-compiled library of components (files,
registry changes, and other system changes) that installs a discrete part of your
application. It cannot be run alone, but must be merged with an .MSI during the .MSI
compile. Merge modules provide flexibility in developing installations because you can
break the installation into logical parts and share merge modules between
installations. See About Merge Modules on page 329.
.WSM Windows Installer merge module project, which describes an .MSM, but does not store
merge module contents. You edit a .WSM in Wise for Windows Installer and compile it
to the corresponding .MSM. See About Merge Modules on page 329.
.MST Windows Installer transform, which changes a Windows Installer package at runtime
and must be applied from the command line. See About Transforms on page 348.
.MSP Windows Installer patch, which updates an existing installed application. Patches
contain only the differences between the old and new versions of an application.
Create a patch with the Patch Creation tool, which creates an .MSP file to distribute to
end users. See Patches on page 302.

Extension Description
.PCP Windows Installer patch project, which describes and compiles to a Windows Installer
patch. A .PCP file is created from the Patch Creation tool. See Patches on page 302.
.EXE You can compile an .EXE that encapsulates the .MSI or that calls an external .MSI.
Doing so gives you the option of pre-installing Windows Installer software before
performing your own installation, which ensures the installation will run. For details,
see Setting Build Options for a Release on page 185 and Adding Prerequisites to a
Release on page 186.
Project Files and Database Files

Typically, the installation you distribute is an .MSI. Windows Installer operates on .MSIs,
which are a type of relational database that stores installation information and files in
tables. See About Microsoft Windows Installer on page 521.
On the Build Options page (see Setting Build Options for a Release on page 185) or on
the Media page (see Setting Up Media for Distribution on page 201), you can specify to
output an installation in different ways:
z As a single-file .MSI, which contains compressed installation files.
z As an .MSI that has external compressed .CAB files.
z As an .MSI that has external uncompressed files.
z As an .EXE that contains the .MSI and installation files.
z As an .EXE that launches an external .MSI.
If you to output an .EXE, you can then pre-install Windows Installer or other runtimes.
When you create an installation, you can work either in a .WSI (project) file or an .MSI.
The same applies to merge modules; work in an .MSM file or a .WSM (project) file.
Note
Do not confuse the Wise installation project file (.WSI) with the Visual Studio project file
(.WSPROJ).
If you work in .WSI or .WSM (Wise If you work in .MSI or .MSM

project) (Windows Installer database)
How are installation Externally. The project contains paths to Inside the database file. Files are
files and paths stored? the installation files. During compile, refreshed from disk unless Don’t update
they are compiled into the resulting .MSI or recompress files when saving is
or .EXE. marked on the Product Details page.
Can you create Yes. Use the Releases page and other No. Because you are already working in
releases? Release Definition pages. the final output file, options for multiple
output files are disabled, which includes all
Release Definition pages.

If you work in .WSI or .WSM (Wise If you work in .MSI or .MSM

project) (Windows Installer database)
Compiling does what? Reads the project information and Refreshes files from disk unless Don’t
compiles a database file (.MSI or .MSM), update or recompress files when
which contains installation files. saving is marked on the Product Details
page.
Can you switch from You can switch from a project file to a Use MSI to WSI Conversion (see MSI to
working on one file database file by compiling the project, WSI Conversion on page 364) to convert
type to the other? opening the resulting database file, and an .MSI to a .WSI. It extracts installation
continuing development in the database files from an .MSI, saves them to disk at
file. However, an .MSI created by locations you specify, and creates a .WSI
compiling a .WSI does not contain file that points to those files.
paths; it contains only the files
themselves. Therefore, any files added
prior to the switch will not be refreshed
from disk because they have no file path.
Only those files you add after the switch
contain file paths and are refreshed from
disk.
Starting a New Installation

Follow the steps below to create a new standard Windows Installer installation. To create
a new transform, see Creating a Transform Based on an Existing .MSI on page 349. To
create a new merge module, see Creating a Merge Module As a New Installation on
page 334.
To start a new installation in the Wise editor:

1. Select Start menu > Programs > Wise > Wise for Windows Installer.
The New Installation File dialog appears. If it doesn’t appear, select File menu >
New. For details on options in the New Installation File dialog, see:
Options for New Installations on page 74.
File Types on page 67.
Project Files and Database Files on page 68.
2. In the Categories list, click Predefined Templates.
3. In the Templates/Tools list, click the Windows Application icon.
A Windows Application installation is a standard installation intended for a Windows

computer or server.
For information on other icons in the list, see:
Device Driver icon: Creating a Device Driver Installation on page 72.
Web Application icon: About Web Installations on page 222.
Server Application icon: Obtaining Logon Information From a Dialog on

page 450.
Pocket PC Application and Smartphone Application icons: Creating a Pocket PC

or Smartphone Installation on page 246.

Palm Application icon: Palm OS Installations on page 255.
4. In the File type section, specify the type of file to create:
Create an .MSI (Windows Installer database), which is a distributable

installation. Because an .MSI typically encapsulates all the files in the
installation, it is larger and takes longer to save. Also, some options that
determine the output of an .MSI are not available when you work with the .MSI
itself.
Create a .WSI (Windows Installer project), which contains instructions for

compiling an .MSI. When you work in a .WSI instead of an .MSI, the .WSI file is
smaller and you can set multiple options for the output of the .MSI.
For information on .MSI and .WSI files, see File Types on page 67 and Project Files
and Database Files on page 68.
5. Select a target platform if necessary: 32-bit or 64-bit. For details, see Specifying the
Target Platform in an Installation on page 76.
The Target Platform section appears only if Select platform in New Installation
File dialog is marked in Wise Options.
6. Click OK. The new installation opens.
To start a new installation in the Visual Studio integrated editor:

When you start a new installation, you have several options for how to proceed. Not only
do you choose whether to create a project associated with a solution, but you also
choose what kind of file to create. Typically, you will create an installation in one of these
ways:
z As a project integrated with a Visual Studio .NET solution. Do this to create an

installation for an application you’ve developed in Visual Studio .NET. See Creating
an Installation Within a Solution on page 70.
z As a stand-alone installation that is not integrated with a solution. Do this to

package application files that are not already in a Visual Studio .NET solution into an
installation. See Creating a Stand-alone Installation on page 72.
Creating an Installation Within a Solution

When you work in the Visual Studio integrated editor, you typically create an installation
as a project within a Visual Studio .NET solution. Because the installation is
synchronized with the other projects in the solution, additions or changes you make in
the other projects can be added to the installation automatically. For information on
what gets updated, see How the Installation Integrates With the Solution on page 81.
Each Visual Studio installation project contains settings that control how it interacts with
other projects in the solution. You can enter project settings when you create a new
installation, or you can create an installation with default settings. You can edit project
settings at any time. See Entering Project Settings on page 77.
To create a stand-alone installation that is not integrated with a Visual Studio .NET
solution, see Creating a Stand-alone Installation on page 72.

Note
For best results, build the solution before creating the installation. This ensures that the
target files are available for integration into the installation. If the main project’s target
file does not exist when you create the installation, project information might not appear
on the Product Details page as expected. The data will be included in the compiled .MSI,
and will appear on the Projects page the next time you compile the installation project.
To create an installation within a solution:

1. Start Visual Studio .NET and open a solution.
2. Select File menu > New > Project.
The New Project dialog appears.
3. In the Project Types list, select Wise Setup and Deployment Projects.
4. In the Templates list, do one of the following:
(Professional and Enterprise Editions.) Select the Setup Wizard icon to create a
new Windows Application installation and enter its project settings.
(Standard Edition.) Select the Windows Application icon, which creates a new
installation with default settings, which you can change later.
A Windows Application installation is a standard installation intended for a Windows
computer or server.
For information on the other icons in the list, see:
Web Application icon: About Web Installations on page 222.
Server Application icon: Obtaining Logon Information From a Dialog on

page 450.
Merge Module icon: Available Tabs and Pages in Merge Modules on page 330.
5. In Name, enter a name for the installation file. In Location, specify the directory in
which to save the project.
6. Mark Add to Solution.
7. Click OK.
If you selected the Windows Application icon, an installation project is created in the
location you specified and is listed in Solution Explorer. Skip to the last step.
If you selected the Setup Wizard icon, the Wise Setup Wizard appears.
8. Step through the Wise Setup Wizard:
a. On the wizard’s Overview page, review the project settings.
b. On the wizard’s Project Type page, select the Windows Application option.
c. For information on other settings in this wizard, see Entering Project Settings on
page 77.
d. Click Finish.
An installation project is created in the location you specified and is listed in Solution
Explorer. A corresponding .WSPROJ file (Visual Studio project) is created in the
same location.
9. Double-click the .WSI file in Solution Explorer.

The installation opens.
Also see:
Starting a New Installation on page 69

Options for New Installations on page 74
Creating a Stand-alone Installation

You can create an installation that is not associated with a Visual Studio .NET solution.
Example: You might do this when you are not creating the .EXE and .DLL files that make
up the installation. In such cases, there is no need to synchronize the installation with
other Visual Studio projects.
To create an installation that is part of a Visual Studio .NET solution, see Creating an
Installation Within a Solution on page 70.
To create a stand-alone installation:

1. Start Visual Studio .NET. If a solution is open, close it.
3. In the Categories list, select Wise Files.
4. In the Templates list, click one of the following icons:
Windows Application File

Create an .MSI (Windows Installer database), which is a distributable
installation. Because an .MSI typically encapsulates all the files in the
installation, it is larger and takes longer to save. Also, some options that
determine the output of an .MSI are not available when you work with the .MSI
itself.
Windows Application Project

Create a .WSI (Windows Installer project), which contains instructions for
compiling an .MSI. When you work in a .WSI instead of an .MSI, the .WSI file is
smaller and you can set multiple options for the output of the .MSI.
For information on .MSI and .WSI files, see File Types on page 67 and Project Files
and Database Files on page 68.
5. Click Open.
The installation opens.
Also see:
Starting a New Installation on page 69

Options for New Installations on page 74
Creating a Device Driver Installation

¾ Supported by Windows 2000, Windows XP, Windows Server 2003, or later.

You can create an installation that supports Microsoft’s Driver Install Frameworks
(DIFx). Microsoft created the Driver Install Frameworks to significantly improve the
quality of device driver installations. For information on DIFx, search for “DIFx” in the
MSDN Library (msdn.microsoft.com/library/).
The Microsoft DIFxApp merge module simplifies the process of creating installations that
install device drivers. This merge module adds custom actions to the installation that are
needed to install and uninstall the driver package using Driver Install Frameworks for
Applications (DIFxApp). After you add the merge module, you add the files that make up
the driver package and specify the DIFxApp options for installing the driver.
1. Make sure the device driver you are installing meets Microsoft’s DIFx driver
requirements.
2. Do one of the following to add the Microsoft DIFxApp merge module to the
installation.
Start a new installation and select the Device Driver icon on the New
Installation File dialog. See Starting a New Installation on page 69. (In Visual
Studio: start a new stand-alone installation and select the Device Driver icon on
the New File dialog. See Creating a Stand-alone Installation on page 72.)
For an existing installation, add the merge module on the Merge Modules page.
See Adding a Merge Module to an Installation on page 345.
Note
Early versions of this merge module might be named “Binaries.”
3. On the Features page, do the following.
a. Add a feature for the installation’s driver package. See a Adding a New Feature
on page 103.
b. Add the condition “VersionNT>=500” to the feature. This condition ensures that
the driver package is installed only on systems running Windows 2000 or later.
See Using Conditions With Features on page 108.
4. On the Files page, do the following. For details, see Adding Files to an Installation on
page 117.
a. Select the driver package feature.
b. Create a unique directory for the driver package.
c. Add the driver package’s .INF file to the directory you created.
d. The driver package’s .INF file must be the first file added to this directory so
that it becomes the key path of the component.
e. Add the other files that make up the driver package to the same directory that
contains the .INF file.
f. In the lower right list box, double-click the .INF file.
g. The File Details dialog appears.
h. Click the Driver tab and edit the DIFxAPP options. See Editing DIFxApp Options
on page 138.
5. To add additional driver packages repeat the preceding steps, except for adding the
DIFxApp merge module.
6. Continue developing the installation.

Options for New Installations

There are several ways to create new installations. To display options, select File menu
> New. (In Visual Studio: select File menu > New Project or File menu > New File, and
select the Wise project type or category.)
You can create new files either in Windows Installer database format (.MSI, .MSM) or in
Wise’s project format (.WSI, .WSM). See Project Files and Database Files on page 68.
Some options let you start a new installation by using a tool (example: Palm Application)
and some let you create different kinds of Windows Installer installations from
templates. You can create custom templates, which appear as additional options for new
installations. See Creating and Editing Installation Templates on page 55.
Tips
z In the Wise editor, templates are organized in category subfolders. Examples:
Predefined Templates, Custom Templates, and so on.
z In the Visual Studio integrated editor, templates are organized by integrated project
and stand-alone files:
Select File menu > New > Project > Wise Setup and Deployment Projects for
new projects that are integrated with a solution.
Select File menu > New > File > Wise Files for stand-alone files.
New Installation Options

Note
In the Visual Studio integrated editor, to determine the file type of a given option, select
the option and then view the help text that appears at the bottom of the dialog. In the
Wise editor, the file type is determined by the file type options.
z Setup Wizard
(Visual Studio integrated editor only. Not available in Standard edition.) Runs a
wizard that creates a Windows Application, Web Application, Server Application, or
Merge Module installation. With this wizard, you can customize the settings rather
than accepting the defaults of the standard templates. See Creating an Installation
Within a Solution on page 70.
z Windows Application
Creates a standard installation with default settings. See Starting a New Installation
on page 69. (In the Visual Studio integrated editor, see Creating an Installation
Within a Solution on page 70. If this name ends with “File”, it creates a stand-alone
file that’s not part of a solution; see Creating a Stand-alone Installation on
page 72.)
z Web Application
(Professional and Enterprise editions only.) Creates an installation intended to be
run on Microsoft Internet Information Server (IIS). See About Web Installations on
page 222.
z Server Application
(Professional and Enterprise editions only.) Creates an installation intended to be
run on Microsoft IIS, with an additional dialog for recording logon information. See
Obtaining Logon Information From a Dialog on page 450. Installations created from
this template work only on Windows NT, 2000, XP, or Server 2003.

z Device Driver
Creates an installation that installs a device driver. This template supports
Microsoft’s Driver Install Frameworks (DIFx). It includes the DIFxApp merge module
that adds custom actions to the installation that are needed to install and uninstall
the device driver package using Driver Install Frameworks for Applications
(DIFxApp). See Creating a Device Driver Installation on page 72.
z Merge Module
See Creating a Merge Module As a New Installation on page 334. (In Visual Studio:
see Creating a Merge Module Within a Solution on page 336. If this name ends with
“File”, it creates a stand-alone file that’s not part of a solution; see Creating a Merge
Module As a New Installation on page 334.)
z Transform
See Creating a Transform Based on an Existing .MSI on page 349.
z Mobile Device Tools

(Professional and Enterprise editions only.) The following tools create an installation
for a mobile device.
Pocket PC Application
See Creating a Pocket PC or Smartphone Installation on page 246.
Palm Application
See Palm OS Installations on page 255.
Smartphone Application
z Conversion Tools
The following tools convert an existing installation from another format to Windows
Installer format.
SMS Installer or WiseScript Installation

See Convert SMS Installer or WiseScript Installation on page 358.
InstallShield Professional
See Convert InstallShield Professional on page 357.
z Import Tools
The following tools open an import wizard, where you select a development project
file to import. Target file information is extracted from the project file and added to
the installation. See Import Visual Studio Projects on page 360.
Visual Basic
(In Visual Studio: this is named Import Visual Basic.)
Visual C#
(Not available in the Visual Studio integrated editor.)
Visual J#
z File type options

(Wise editor only.) Select the format of the file:
Create standard .MSI or .MSM file that contains all binary and cabinet
files
Mark this to create a new Windows Installer database file. Because the
installation file generally encapsulates all the files of the installation, an .MSI is
usually larger in size and takes longer to save. Also, some options that

determine the output of an .MSI are not available if you work with the .MSI
itself.
Create .WSI or .WSM project file that can be compiled into an .MSI or
.MSM
Mark this to create a project file instead of a installation file. Unlike .MSIs,
project files are not distributable installation files; they describe and compile a
distributable file. They do not contain installation files. This option lets you edit
and save the .WSI quickly and has more options for outputting the .MSI. A .WSI
compiles to an .MSI, and a .WSM compiles to an .MSM (merge module).
z Target Platform options

(Professional and Enterprise editions only.) This section appears if the Select
platform in New Installation File dialog option is marked in Wise Options. For
information about 64-bit installations, see What’s Different in a 64-Bit Installation?
on page 76.
Create installation for 32-bit platform

Enables the installation for 32-bit platforms.
Create installation for 64-bit platform

Enables the installation for 64-bit platforms.
Specifying the Target Platform in an Installation

You can specify whether installations are enabled for 32-bit or 64-bit platforms. The
target platform is set when the installation is first created; you cannot change the target
platform after the file is created. The target platform default for new installations is
controlled by the Target Platform Selection setting in Wise Options. See Setting the
Default Target Platform on page 52.
(Visual Studio only.) When you create a project with the Setup Wizard, you can override
the default target platform for that particular project. You do this on the Main Project
page of the Setup Wizard. See Entering Project Settings on page 77.
(Wise editor only.) If you specify Select platform in New Installation File dialog in
Wise Options, a Target Platform section appears on the New Installation File dialog when
you select File menu > New. In this section, you can change the default platform when
you create a new installation.
Note
64-bit installations are supported only by Windows Installer 2.0 or later.
Also see What’s Different in a 64-Bit Installation? on page 76.
What’s Different in a 64-Bit Installation?

A 64-bit installation file differs from a 32-bit installation in the following ways:
z The minimum version of Windows Installer is set to 2.00 in the Installer Version
field on the General Information page. Do not override this setting in a 64-bit

installation, because 64-bit installations are not supported by Windows Installer

versions earlier than 2.0.
Note
Installations with an Installer Version of 2.0 or later cannot run on Windows NT
4.0, Service Pack 5 or earlier. This is a Microsoft restriction.
z The value Intel64 is added to the Template Summary summary item, which
indicates the platform and language versions supported by the installation. To
display this value, select Setup Editor > Product tab > Summary icon. Do not
change this value in a 64-bit installation, however, you can change the language ID.
z Condition Builder contains 2 additional property values: VersionNT64 and Intel64.
z The Directory table contains additional folders with “64” appended to their names.
z The Files and Visual Studio Solution pages contain an additional predefined
directory, Program Files (x86).
z You can designate a component as a 64-bit component by marking the 64-bit

component checkbox on the Component Details dialog. See Adding and Editing a
Component on page 392.
z The Read Registry Value dialog contains a checkbox that lets you include 64-bit
components in a registry value search. See Searching For a Registry Value on
page 173.
z When you create a custom action that calls a JScript or VBScript file, a checkbox lets
you call a 64-bit script.
z The Target Platform field on the Product Details page provides a quick way to
determine for which platform an installation is enabled. See Product Details Page on
page 92.
Also see Specifying the Target Platform in an Installation on page 76.
Entering Project Settings

Each Visual Studio installation project has settings that control how it interacts with
other projects in the solution.
Stand-alone installations that are not integrated with a Visual Studio .NET solution do
not have project settings.
To access project settings:

Do one of the following:
z While creating a new installation project, select Setup Wizard on the New Project
dialog. (Professional and Enterprise Editions only.) See Creating an Installation
The Wise Setup Wizard dialog appears. Available pages are: Overview, Project Type,
Projects, and Main Project.
z Right-click an existing installation project in Solution Explorer and select Properties.

The Property Pages dialog appears. Available pages are: Projects, Project Outputs,
Main Project, Pre-build Event, and Post-build Event.
Note
The Property Pages dialog contains a link to the Configuration Properties page,
however, configuration properties do not apply to Wise editor installation projects.
Also see:
Overview Page on page 78

Project Type Page on page 78
Projects Page on page 79
Main Project Page on page 80
Pre-build Event on page 80
Post-build Event on page 81
Project Outputs Page on page 81
Overview Page
The Overview page summarizes the project settings for the project you are creating.
Review the settings to make sure they are correct. To change these settings, click the
links at the left to access the Project Type, Projects, or Main Project pages.
Also see:
Creating an Installation Within a Solution on page 70

Entering Project Settings on page 77
Project Type Page

The Project Type page lets you specify what kind of installation project you are creating.
This page is accessible only from the Wise Setup Wizard when you create a new
installation (Professional and Enterprise Editions only).
z Windows Application
Create a standard Windows Installer installation (.WSI). This is intended for
installation to Windows computers or servers. See Creating an Installation Within a
Solution.
z Web Application or Web Service

Create a standard Windows Installer installation (.WSI). This has options
preconfigured to enable it to be installed to a Microsoft Internet Information Server.
See About Web Installations on page 222.
z Server Application
Create a standard Windows Installer installation (.WSI). This is the same as the Web
Application above except that it also prompts the end user to enter valid NT logon
information. See Obtaining Logon Information From a Dialog on page 450.

z Merge Module
Create a standard merge module project (.WSM). See Creating a Merge Module
Also see:

Projects Page
On the Projects page, you select projects to add to the installation you are creating.
Access this page either from the Wise Setup Wizard when you create a new installation,
or by right-clicking a project in a solution and selecting Properties.
z Select the projects to include in this package

From this list of all projects in the current solution, select the ones to add to this
installation. (All projects are selected by default.) Output files of the selected
projects are added to this installation.
If you add a project to this solution later, it will be added to the project list and
selected for inclusion.
To exclude a project from the installation, deselect it.
z Scan Method
Each time you load, save, or build an installation project or change its settings, Wise
for Windows Installer can scan projects in the solution for new files to add to the
installation. See Scanning the Solution for New Files on page 82.
Specify the level of scanning that will occur for this installation. The default is
determined by the Scan Method option in Wise Options.
Never scan solution

If you select this, you must add new files to installations manually using the
Files page. Also, when files are removed from a solution, you must remove
them from the installations manually.
Prompt only when new files are detected

Select this to be prompted each time there are new files in the solution that
need to be added to the installation. The prompt appears during save, build, or
compile.
Prompt when any files are detected

This is the highest level of prompting. Like the previous option, the prompt
appears during save, build, or compile when there are new files. Also, if you
previously excluded files by clearing their checkboxes, you’ll be prompted to
confirm that those files should be excluded.
Always scan solution

Each time Wise for Windows Installer scans a solution, it adds new files to the
installation and deletes files that have been removed from the solution.
z Bind installed files to the solution build configuration

Mark this to have the installation source paths change automatically when you
change this project’s build configuration. The default is determined by a checkbox in
Wise Options.

Also see:

Main Project Page

On the Main Project page, you specify the main project and set options that affect the
main project. Access this page either from the Wise Setup Wizard when you create a
new installation, or by right-clicking a project in a solution and selecting Properties.
z Main Project
Select the project that generates the main target, or executable file, for your
application. (Example: If the main executable for the project is Sample.exe, you
would select the project that generates Sample.exe.) When you select a project, a
shortcut is generated for the main target and the version number in the Wise
project is updated from the main target.
If you select <None>, or if you are in a merge module, shortcut generation and
version updating does not occur.
z Automatically Update Product Information

Mark this to update the installation’s product name, version, and manufacturer
whenever you rebuild the solution or whenever the version number of the main
target file changes. (In a merge module, only the version is updated .) The default
is determined by a checkbox in Wise Options. This is disabled if you select <None>
in Main Project.
z Create Shortcut
Mark this to add a shortcut for the main target file to the installation. The default is
determined by a checkbox in Wise Options. This is disabled if you select <None> in
Main Project.
z Target Platform
(Wise Setup Wizard only.) This defaults to the Target Platform Selection in Wise
Options. You can change the target platform for this particular installation project.
Because you cannot change the target platform after the project is created, this
option does not appear on the Property Pages dialog.
Also see:

Pre-build Event
The Pre-build Event page lets you add to a project anything that is needed before the
build occurs. Example: You can copy something to a source where you need it.
Access this page by right-clicking a project in Solution Explorer and selecting Properties.
You can use any DOS command to create command lines for this build event. You can
add as many command lines as needed.

Post-build Event
The Post-build Event page lets you add to a project anything that is needed after the
build occurs. Example: You can copy an .MSI to the network.
Access this page by right-clicking a project in Solution Explorer and selecting Properties.
You can use any DOS command to create command lines for this build event. You can
add as many command lines as needed.
Project Outputs Page

By default, the installation includes only the main output file (.EXE or .DLL) from each
project in the solution, and the content files from each project. On the Project Outputs
page, you select which projects to include in the installation and specify additional
project output files to include in the installation.
This page is accessible only on the Project Properties dialog. Right-click a project in a
solution and select Properties.
z Project
Select the project to specify additional outputs for.
z Output Groups
Select one or more types of output files to include in the installation:
Debug Symbols
Include the project’s debugging (.PDB) files.
Localized Resources
Include files marked as resources for the project. Example: additional files for a
specific language.
Source Files
Include all source code files in the project.
Content Files
Include all files marked as content within the project, that is, files that are not
compiled but are meant to be distributed with the application. Examples: HTML,
ASP, and ASPX files.
Primary Output
Include the .DLL or .EXE built by the project.
Also see:

How the Installation Integrates With the Solution


When you add an installation to a Visual Studio .NET solution, as described in Creating
an Installation Within a Solution on page 70, the following items are added to the
installation project:
z All primary outputs (.EXEs and .DLLs) of the projects in the solution, and all content
files in the solution. (Content files are not compiled but are meant to be distributed
with the application. Examples: HTML, ASP, and ASPX files.) When a project consists
only of a .DLL or .OCX, has no additional content, and is a dependent of another
project, it is not added to the installation by default.
To add other outputs to the installation, select them on the Project Outputs page in
the project settings.
Wise for Windows Installer can scan for files you add or delete after you’ve created
the installation project, and can add them to or delete them from the project. See
Scanning the Solution for New Files on page 82.
z Assembly dependencies, if you have selected one of the rescan assembly options in
Wise Options.
View these in Installation Expert > Files page or Visual Studio Solution page.
z The application name, version, and manufacturer from the main project in the
solution.
View these in Installation Expert > Product Details page. The default directory is
filled in with the same name as the main project. You can change the main project
on the Main Project page in the project settings.
Note
Except for the product version, once the information on the Product Details page is
set, it does not change if you change the information in the main project.
z An advertised shortcut for the application.

On the Project Outputs page in the project settings, you can choose not to create a
shortcut.
When you add a new project to the solution, its outputs are added to the installation.
To exclude a project from the installation, or to change how the installation project
integrates with the solution, edit the installation’s project settings. See Entering Project
Settings on page 77.
Note
Only files that reside in the directory where the solution (.sln) file resides and its
subdirectories can be managed with source control. Files that reside in system
directories or other locations outside the solution directory are not managed by source
control, and therefore do not appear in the Other Files or Source Files folders under the
installation project in Solution Explorer.
Scanning the Solution for New Files

Wise for Windows Installer can scan projects in a solution for new output files that need
to be added to the installation, and add those files to the installation.
Scanning occurs when you:

z Load, save, or build an installation project within a solution.
z Change the installation’s project settings. Examples: output types, projects to

include.
How and when the solution is scanned is determined by the Scan Method option. The
default is set in Wise Options and can be changed for specific installations on the
Projects page in the project settings. See Setting Visual Studio Options on page 53 and
Projects Page on page 79.
z If you add an existing .WSI to a solution, the .WSI project’s original scan method
setting is preserved.
z If you add an existing .WSI project to a solution and no scan method setting is
found, the default scan method is used.
You can specify the level of scanning that should occur for each installation. See Projects
Page on page 79.
Add Project Outputs to Installation Dialog

This dialog appears during save, build, or compile when the scan method is set to
prompt. On this dialog, you can:
z Mark checkboxes for files to add them to the installation project.
z Edit the destination feature and target directory by clicking a file and editing the
appropriate cell.
z Add and edit multiple files at once by selecting them and clicking the Properties
button. On the Project Output Properties dialog that appears, you can add a new
feature and add a new directory for all of the selected files.
Note
In a Web installation, you can only change the destination feature.
Why Would You Change the Scan Method?

You can change the scan method for specific installations on the Projects page in the
project settings.
You might want to change an installation’s scan method at various stages of the
development cycle. Example:
z At the beginning of a development project when you are continually creating new
projects and files, you would want to add all new files automatically.
z As development continues and you become more discriminating about the files you
add to the installation, you might want to be prompted to add files.
z At the end of the development cycle, you can turn the scanning off altogether so
you don’t introduce any new files into the installation.
Also see How the Installation Integrates With the Solution on page 81.
Opening an Installation Package

¾ Enterprise Edition only. Not available in the Visual Studio integrated editor.

Open dialogs show different tabs according to which edition you have and what tool you
are using. The Open dialog might contain two or more tabs that let you open different
items:
z File System tab: Opens a package from a directory on your computer.
z Repository tab: Opens a package from the Wise Software Repository.

The Repository tab on the Open dialog provides a centralized list of installation
packages and eliminates the need to navigate your file system to find an installation
file. When you select a package from the repository:
The package opens from its location in the repository. Typically, this is the
Scripts directory or your default project directory.
If the package status is Available, you are prompted to change the status to
Under Development.
Caution
Use caution when changing available packages, because they might have been
deployed to end users.
If you try to save the package, a prompt asks if you want to overwrite the file
that is in the repository.
z Groups tab: Opens a group from the Wise Software Repository. This is only available
for some tools.
To open a package from a directory:

Click the File System tab on the Open dialog and navigate to a package. This is the same
as the standard Windows Open dialog.
To open a package from the Wise Software Repository:

1. Click the Repository tab on the Open dialog.
Packages are displayed in the list box if they have a valid path to an installation file
(.MSI, .WSI, and so on). If a package’s path to its installation file is missing or
broken, or is not accessible by the current computer, that package is not listed. Also,
subscription packages are not listed.
2. Database displays the current Software Manager database. To select a package

from a different database, click .
The Select Data Source dialog appears. This is a standard Windows ODBC
connection wizard, which lets you connect to a database via an ODBC data source.
3. Specify criteria for filtering the packages that are displayed above:
Groups
This lists the groups defined in Software Manager.
Status
This lists the possible package statuses.
Package Type
This lists the available package types.
4. Select a package in the list and click Open.
If you change an installation that you opened from the repository, re-import it into the
Software Manager database. Otherwise, changes will not be reflected in the repository.

To open a group from the Wise Software Repository:

1. Click the Groups tab on the Open dialog.
Groups in the current Software Manager database are displayed.
2. Database displays the current Software Manager database. To select a group from
a different database, click .
The Select Data Source dialog appears. This is a standard Windows ODBC
connection wizard, which lets you connect to a database via an ODBC data source.
3. In the Open dialog, do the following and click Open:
In Deployment Groups, choose a group.
In Application/Package, mark the packages to open in the tool.
Comparing Windows Installer Files

Visual MSIDiff™ lets you compare the following types of files and see the differences in
Setup Editor > Tables tab: .MSI, .WSI, .MSP, .MSM, .WSM, or .MST files. You can
compare an .MSP file only with its base .MSI.
Options for Comparing Files

z Compare the current file to another file.
z Compare any 2 files. (Not available in the Visual Studio integrated editor.)
z Compare a transform to its base .MSI, to see the items that the transform changes
in the .MSI.
To view differences between two Windows Installer files:

1. Open a file.
2. Select Tools menu > Visual MSIDiff and then select an option. (In Visual Studio:
Project menu > Visual MSIDiff.)
Compare Current File to Another File

The Compare Windows Installer Files dialog appears. Specify the file to compare
to the current file. To have the file you specify in Compare To treated as the
newer file in the comparison, mark the dialog’s checkbox. To compare an .MSP
to an .MSI, the current file must be the .MSI. An .MSP is always treated as the
newer file. Click OK.
Compare Any Two Files

The Compare Windows Installer Files dialog appears. Specify the files to
compare. The file you specify in the Base File field becomes the current file. To
compare an .MSP to an .MSI, the Base File must be the .MSI. To have the file
you specify in Compare To treated as the newer file in the comparison, mark
the dialog’s checkbox. An .MSP is always treated as the newer file. Click OK.
Compare Transform to Base .MSI

(Transform files only.) Automatically compares the .MST to its base .MSI.
You are taken to Setup Editor > Tables tab and the Visual MSIDiff Key dialog
appears, which describes icons that indicate changes. Changes are shown in the
tables and rows where they occur.

3. On the Visual MSIDiff Key dialog, take note of the symbols and colors that indicate
changes and click OK.
If the Visual MSIDiff Key dialog does not appear, you might have marked its Do not
show this dialog again checkbox. You can reactivate this prompt in Wise Options.
4. Scroll through tables on the Tables tab, looking for the symbols for changed tables.
Click on changed tables to view differences in rows, which are indicated by symbols
and colors.
As you work in the installation file, the symbols indicating changed items are
updated dynamically. The compare stays on until you end it.
5. To end the compare, select Tools menu > Visual MSIDiff > End Current Compare.
(In Visual Studio: Project menu > Visual MSIDiff > End Current Compare.) This
turns off compare symbols and closes the comparison file.
You can also launch Wise for Windows Installer in the Visual MSIDiff mode from a
command line. See Command Line Options For WFWI.EXE on page 217.
Also see Tables Tab on page 397.
Saving an Installation as XML

You can save a copy of an installation (.WSI, .MSI, WSM, or .MSM) in XML format. This
lets you check the XML version of the installation into a text-based source code control
system (SCCS), use text-based file comparison tools to find changes, or perform
analyses with XML reporting tools.
You can set a global option in Wise Options to create an XML copy every time you save
an installation file, or you can export to an XML file on an as-needed basis. Depending
on the size of the installation file, creating an XML copy can take several minutes.
You cannot open an XML-format file in Wise for Windows Installer.
To create an XML file during saves:

Use this method when you plan to check the XML file into an SCCS from Wise for
Windows Installer. This ensures that the XML copy is always synchronized with the
original installation file.
1. Select Tools menu > Options and click the General tab. (In Visual Studio: Tools >
Options > Wise Options > General.)
2. Mark the Create XML copy during save checkbox.
This global option causes an XML copy to be created every time you save an installation
file. The copy has the same name as the installation file with the extension .XML
appended, and it is saved in the same directory. (Example: If the current file name is
Application.wsi, the XML copy is named Application.wsi.xml.)
To export an XML file as needed:

Use this method when you do not have an integrated SCCS, or to compare the version of
the installation you’re working in to the version that you checked out of your SCCS.
1. Select File menu > Export to XML. (In Visual Studio: Project > Export to XML.)
2. In the Save As dialog that appears, specify a file name with the extension .XML and
click Save.

If you have not named the installation file yet, name and save the installation file on
the Save As dialog. When the Save As dialog reappears, specify the .XML file.
The current installation is saved and exported to XML format.
Working With Installations in the Software Manager

Database
There are restrictions on editing and saving an installation that has been added to the
Software Manager database (either by adding its meta data or importing it).
When the Package Path Matches a Package in the Database

If you open an installation file and the Software Manager database contains a package
with the same package path, the application and package names on the Product Details
page are disabled. This is because the installation is connected to the package in the
database. You can only edit these names on the Package Attributes dialog in Software
Manager.
If you edit the installation’s meta data, the meta data in the database is updated when
you save the installation. If you change the installation, re-import it to the Software
Manager database to update its resources.
Opening a Copy of a Package in the Database

If you open an installation file that is a copy of a package in the Software Manager
database, the application and package names are populated and enabled. Change one
or both of these names before saving the installation to avoid overwriting the package in
the database. Then, when you then save the installation, a new package and its meta
data are added to the Software Manager database.
Example: You want to create a patch for an installation that is in the Software Manager
database. You open a copy of the installation file to change it. Before you save the
installation, you change its package name on the Product Details page. When you save
the installation, a new package with the same application name, and its meta data, are
added to the database.
Duplicate Package in Software Manager Database Dialog

If you open an installation file that is a copy of a package in the Software Manager
database, and you don’t change the application and package name on the Product
Details page, the Duplicate Package in Software Manager Database dialog appears when
you try to save the installation. Select an option and click OK:
z Create a New Package (recommended)

Mark this to create a new package in the Software Manager database. The Product
Details page opens so that you can change the application or package name before
saving the installation file.
z Overwrite Existing Package

Mark this to overwrite the package in the Software Manager database. The meta
data of the package in the database is overwritten, and its resources are removed
from the database.

z Work Disconnected
Mark this to keep the installation file disconnected from the Software Manager
database. When you save the installation, its meta data is not added to the
database.
To connect the installation file to the Software Manager database, change the
application or package name on the Product Details page and save the installation.
A new package and its meta data are added to the database.
Compiling, Testing, and Running An Installation

To test an installation, you can:
z Compile the installation to an executable .MSI or .EXE. See Compiling An

Installation.
z Test the installation, which appears to run but does not make any modifications on
your system. See Testing An Installation on page 89.
z Debug the installation in an .MSI debugger, which lets you step through the
installation while viewing the property values and other table data. This actually
runs the installation, and lets you see exactly what it is doing at any time. See
Running the Debugger on page 463. The Debugger for Windows Installer is available
in the Professional and Enterprise Editions only.
z Run the compiled installation, which is either an .MSI or an .EXE. See Running An
Installation on page 90.
Note
When working in a .WSI, you can set the installation to generate more than one
installation program by adding releases to the Releases page. If you test, debug, or run
an installation that contains multiple releases, you are prompted to select a release.
Compiling An Installation
Compiling an installation compresses its files, builds .CABs if necessary, and creates the
installation .MSI. Depending on the .EXE option you select on the Build Options page,
compiling can also create an installation .EXE. (In Visual Studio: compiling and building
do the same thing.)
The number and type of files generated depend on the settings you select on the Build
Options and Media pages. If the installation contains multiple releases, all releases in
the installation are compiled. To compile a specific release, go to the Releases page,
select one or more releases, and click the Compile button at the right of the Releases
page.
If you are working in a .WSI or .WSM file, you can speed the compile process by
marking the Enable Quick Compile checkbox in Wise Options. Quick Compile
compresses only previously uncompressed or changed files. If a file or media entry has
changed, a full compile occurs instead. You can also speed compile time by using
ExpressBuild, a multi-processor compile feature in the Professional and Enterprise
Editions. See the description of Quick Compile in Setting General Options on page 39
and see Setting ExpressBuild Options on page 44.
To compile an installation in the Wise editor:

Click Compile at the lower right of the main window.

To compile an installation in the Visual Studio integrated editor:

Select one of the following commands from the Build menu:
z Build Solution
Compiles all projects in the current solution. If quick compile is enabled and you
have already built this solution, this command compiles only what has changed
since the last build.
z Build <project name>

Compiles only the project you have selected in Solution Explorer. If quick compile is
enabled and you have already built this project, this command compiles only what
has changed since the last build.
z Rebuild Solution
Compiles all files in all projects in the solution.
z Rebuild <project name>

Compiles all files in the project you have selected in Solution Explorer.
z Compile
Compiles the current project or installation file. This is the only command available
for installations that are not part of a Visual Studio .NET installation.
Compile Results
If you are working in an .MSI or .MSM, compiling saves the file. If file paths are stored in
the .MSI, compiling first refreshes the files with the latest version. If files cannot be
read, or other errors occur, errors are listed in the Task List. (In Visual Studio: errors
appear in the Visual Studio .NET Output window as they are encountered and then, at
the end of the compile, they are listed in the Task List.) Use the Task List to determine
the source of the errors; see Using the Task List on page 26.
If you see messages that files are missing, you can suppress the file refresh by marking
the Don’t update or recompress files when saving checkbox on the Product Details
page. If merge modules are missing, you can download them using Help menu >
Download Redistributables. (In Visual Studio: Help menu > Wise Help > Download
Redistributables.)
Also see:
Testing An Installation on page 89

Running An Installation on page 90
Running the Debugger on page 463
Testing An Installation
You can compile and test an installation in test mode, which does not install or modify
files or change the system. This lets you run through the UI and logic of an installation
without making changes. Click Test at the lower right of the main window. (In Visual
Studio: select Project menu > Start in Test Mode.)
If you have added command lines to the Command Line page, when you click Test, a
menu appears with further options. The menu contains the names of all command lines
you’ve created. You can test with a command line by selecting its name. To avoid having
to select from the button menu, press Ctrl+T to test with no command line.
If this installation contains multiple releases, you are prompted to select one.

You cannot test a transform or a merge module by itself. It can only be run in
conjunction with an .MSI. To run a transform or merge module, run the base .MSI from
the command line with the appropriate command line options, which are documented in
the Windows Installer SDK Help.
Note
If you change the installation and then test it, but the change is not apparent, exit the
installation and compile it. Then test it again.
Also see:
Compiling An Installation on page 88

Running An Installation on page 90
Running An Installation
To install an installation on your computer, click Run at the lower right of the main
window. (In Visual Studio: in Solution Explorer, right-click the installation project icon
and select Set as StartUp Project. Then, select Debug menu > Start Without Debugging.
The additional options below are not available.) Then choose the type of installation
from the button menu:
z Force Reinstall
Normally, if an application is installed and you attempt to install it again, Windows
Installer prompts you to remove it. This option uses command lines to bypass the
uninstall. Existing resources are replaced, and new resources are laid down. (The
command line msiexec.exe /FAMSUV [MSIFILENAME] is used. See Command Line
Options in the Windows Installer SDK Help.)
z Uninstall --> Install

If the application is already installed, this option first uninstalls it, then installs.
z Run
Runs the installation normally. If the application is already installed, you are
prompted to uninstall it.
z Other command lines

If you added command lines to the Command Line page, they also appear. To avoid
having to select from the button menu, press Ctrl+R to run with no command line.
If this installation contains multiple releases, you are prompted to select one.
The installation is compiled and then runs as it would on the destination computer,
actually installing files and modifying the system.
You cannot run a transform or a merge module by itself. It can only be run in
conjunction with an .MSI. To run a transform or merge module, run the base .MSI from
the command line with the appropriate command line options, which are documented in
Note
If you change the installation and then run it, but the change is not apparent, exit the
installation and compile it. Then run it again.
Also see:

Compiling An Installation on page 88

Testing An Installation on page 89

Chapter 5
Defining an Installation Project
When you start a new installation, you enter information about the installation and the
application, and define the structure of the installation.
Topics include:
z Project Summary Page.
z Product Details Page.
z General Information Page.
z Add/Remove Programs Page.
z Features Page.
z Managing Binary Resources.
Project Summary Page

The Installation Expert > Project Summary page provides the following information
about the current installation project and quick access to areas of the installation:
z Links to Installation Expert pages that have content in the current installation and,
where appropriate, the number of items defined on each page. Examples: how
many features are defined on the Features page, how many files have been added
to the Files page, and so on.
z (Enterprise Edition only.) Links to the Package Contents reports.
z Installation package meta data (read-only). To edit the meta data, see Product
Details Page on page 92.
A checkbox in Wise Options determines whether the Project Summary page appears
when an installation is opened.
Product Details Page

Use Installation Expert > Product Details page to enter, edit, or view an installation’s
meta data. Meta data is displayed for .MSI, .WSI, and .MST files. In the Value column of
the Package Meta Data table, you can enter or edit meta data that is not read-only.
Note
The meta data that appears when you create a transform comes from the base .MSI. If
you change a transform’s meta data, it is set when the transform is applied.
(Enterprise Edition only.) If you define meta data fields in Software Manager, they
appear on the Product Details page unless the Software Manager database cannot be
found. You can edit these meta data fields on the Product Details page or in Software
Manager. In Software Manager, you can also change the order in which the meta data

fields appear on the Product Details page. See Defining Custom Meta Data Fields in the
(Enterprise Edition only.) For an .MSI or .WSI, you can add the meta data that appears
on the Product Details page to the Software Manager database. This lets you add
package information to the Software Manager database early in the development
process. It also eliminates the need to enter the meta data manually in Software
Manager and ensures that every package in the database has meta data that meets
your corporate standards. See Adding Meta Data to the Software Manager Database on
page 95. Also see How to Get Packages Into the Software Manager Database in the
Note
(Visual Studio integrated editor only.) Except for the product version, once the
information on the Product Details page is set, it does not change if you change the
information in the main project.
z Application
(Enterprise Edition only.) Enter the name to use for this application in the Software
Manager database. This can be the same as the Product Name meta data field.
This field appears in an .MSI or .WSI only.
z Package
(Enterprise Edition only.) Enter a unique name to identify this package in the
Software Manager database. Typically, you use the Application name plus specific
version information. (Example: If the Application name is Product, the Package
name might be Product 5.05.) This field appears in an .MSI or .WSI only.
z Product Type
(Read-only.) This displays Windows Installer for installations and Transform for
transforms.
z Product Name
Enter the name of the application, which by default is the name of the first directory
you create on the Files or Web Files page. The end user sees this name during
installation and in the Add/Remove Programs dialog.
(Visual Studio integrated editor only.) If this installation is part of a Visual Studio
.NET solution, this is pre-filled.
z Manufacturer
Enter the manufacturer or publisher of the application.
z Version
Enter the version number of the application. Windows Installer uses this to identify
this application when subsequent patches or upgrades are applied. The version
should be in the format AA.BB.CCCC.DDDD, where AA is the major version, BB is
the minor version, CCCC is the build version, and DDDD is optional and ignored. It is
stored as a string data type. See Incrementing the Version on page 96.
.NET solution, this is pre-filled. You can have the version number updated
automatically.

Caution
If you are releasing a newer version of your application but are not using an
upgrade or patch, it is very important to enter a new version on the Product Details
page. Not doing so can cause the installation to open in maintenance mode instead
of in normal installation mode. This can result in an invalid installation that is a
mixture of old and new files, which can cause errors in your application. The only
exception is if the installation contains no new files, no deletion of files, and no other
system changes, which means that only the contents of files are changed.
z Default Directory
During installation, this directory is displayed to the end user on the Destination
Folder dialog, and the end user can change the default location for the application.
(The Destination Folder dialog is called the Single Feature Destination dialog in Wise
for Windows Installer.) This defaults to the first directory you create on the Files or
Web Files page. To change the default directory, select its value, click the Change
button, and select a new directory. See Setting the Default Installation Directory on
page 97.
z Package Path
(Read-only.) This displays the installation file’s location.
z Repository ID
(Enterprise Edition only) (Read-only.) This displays the package’s unique identifier in
the Wise Software Repository, which Wise for Windows Installer generates in the
form of a GUID. This ID is generated when you save or compile an installation after
entering the application and package names. It is also generated when you import a
package in Software Manager, if it does not already exist.
z Product Code
Every Windows Installer installation must have a unique product code, which is used
as the principal identification for the application. Wise for Windows Installer
generates a product code in the form of a GUID, which ensures that no 2
applications ever have the same product code. To change the product code:
Select its value and click the Change button.
On the dialog that appears, click Yes to change the product code and the
upgrade code, or click No to change just the product code. If the installation is
an upgrade of an existing installation, then change the product code only. For
information on the upgrade code, see Upgrades on page 311.
Changing the product code also changes the package code. For information on
the product and package codes, see ProductCode Property, Package Codes, and
Product Codes in the Windows Installer SDK Help. Also see About GUIDs on
page 524.
z Target Platform
(Professional and Enterprise Editions only.) This read-only field displays the platform
for which this installation is enabled, 64-bit or 32-bit.The platform is set when you
create the installation. To change the target platform for future installations, see
Setting the Default Target Platform on page 52.
z Application Type
(Professional and Enterprise Editions only.) Specify whether this is a standard Win32
or a .NET installation. This also determines how Wise for Windows Installer handles

COM interoperability registry entries. This defaults to the Default Application

Type that is specified in Wise Options. See Setting .NET Assembly Options on
page 40.
The ability to create .NET installations is supported only by Windows Installer 2.0 or
later.
Win 32 (non .NET)

Select this if this is a standard Win32 installation without .NET assemblies.
.NET Application
Select this if this is a .NET installation with only .NET elements.

Select this if this installation contains both Win32 and .NET elements. When this
option is selected, the Generate COM interop registry keys for .NET
Assembly checkbox on the File Details dialog > Self-registration tab is marked
by default for all .NET assemblies you add to this installation. The assemblies
will be registered so that they can be called as though they were COM elements.
When the .NET Application or Mixed option is selected, entries are created in the
MsiAssembly and MsiAssemblyName tables for each assembly you add to the
installation. The Global Assembly Cache directory also appears on the Files page.
z Installation Target
(Professional and Enterprise Editions only.) This value is for meta data purposes
only. It does not change the installation.
Windows-based desktop/server PC
Mark this if the installation does not install a Web service to an IIS server. This
is the default except for Web and server applications.
Windows-based IIS Web server

Mark this if the installation installs a Web application to an IIS server. This is the
default for Web and server applications.
z Description
Describe the package. In the Enterprise edition, this becomes part of the package
meta data when the package is imported into the Software Manager database.
z Don’t update or recompress files when saving

(.MSI files only.) Files are stored in .MSI files either with a hard-coded pathname to
the original, or without a pathname. For files with pathnames, Wise for Windows
Installer gets the latest copy of the file from the specified path when you save or
compile the .MSI. Mark this to prevent Wise for Windows Installer getting the latest
copy of files that have pathnames.
If you clear this checkbox, files that are set to be compressed are not re-
compressed when you save or compile. (Compression options are on the Media
page.)
Adding Meta Data to the Software Manager Database

1. Select Installation Expert > Product Details page.
2. Enter the Application and Package names. These fields appear in an .MSI or .WSI
only. See Product Details Page on page 92.

3. Select File menu > Save to save the installation.
If this is the first time you’ve saved the installation, the Save As dialog appears. (In
Visual Studio: the Save File As dialog appears.) Enter a name for the file and click
Save.
4. If a package with the same application and package name is already in the Software
Manager database, a warning message appears. Click OK and change either the
application or package name to create a new package in Software Manager.
When you save the installation, its meta data is added to the Software Manager
database and the Repository ID field is populated.
What happens when you add meta data to the Software Manager
database?
z The meta data appears in Software Manager on the Package pane and the Package
Attributes dialog. See About the Software Manager Window and Viewing and Editing
Package Attributes in the Software Manager Help.
This only adds the package’s meta data to the Software Manager database. It does
not import the package’s resources. To import the package’s resources, see Package
Import in the Software Manager Help.
z The package is assigned a status of New in Software Manager. You cannot change to
or from this status manually. A New package is changed to Under Development only
when you use the Import Wizard to import its resource information.
z The package is assigned a repository ID in the form of a GUID. If you make a copy
of the installation and change the copies application or package name, it is assigned
a new repository ID.
z The Application and Package fields on the Product Details page are disabled. You
can edit them on the Package Attributes dialog in Software Manager. See Viewing
and Editing Package Attributes in the Software Manager Help.
If you open an installation file that is a copy of the package in the Software Manager
database, the Application and Package fields are populated and enabled. Change
one or both of these fields before saving the installation to avoid overwriting the
package in the database. See Working With Installations in the Software Manager
Database on page 87.
z If you edit meta data on the Product Details page, the meta data in the Software
Manager database is updated when you save the installation. If you edit meta data
in Software Manager, your edits appear on the Product Details page the next time
you open the installation.
Also see How to Get Packages Into the Software Manager Database in the Software
Manager Help.
Incrementing the Version

Windows Installer uses the version number of the application to identify the product
when subsequent patches or upgrades are applied. You set the version number on the
Product Details page. See Product Details Page on page 92.
(Visual Studio integrated editor only.) If an installation is part of a Visual Studio .NET
solution, you can have the version number updated whenever the version number of the
main target file changes. To enable version updating, mark the Automatically Update

The Version Number checkbox on the Main Project page of the Property Pages dialog.
See Main Project Page on page 80.
When should you increment the version field?

z When you add or delete files from the installation.
z When you create, remove, or edit any other items besides files. Examples: services,
ODBC, runtimes, registry, and so on.
z If you plan to create a patch that updates earlier versions to this version.
z When you include upgrade entries on the Upgrades page of versions that this
installation will upgrade.
When can you leave the version field the same?

z When you create an update that has all the same files as the original version, and
only the contents of files have changed.
Setting the Default Installation Directory

During installation, this directory is displayed to the end user on the Destination Folder
dialog, and the end user can change the default location for the application. (The
Destination Folder dialog is called the Single Feature Destination dialog in Wise for
Windows Installer.)
On the Product Details page, you can change the default installation directory and reset
the default directories for features that use this directory. You can also create a new
directory as a child, or subdirectory, of an existing directory.
Note
When end users install your application, sometimes the installation directory defaults to
the C:\ drive, and other times it defaults to another drive. This happens because
Windows Installer automatically determines which drive has the most free space.
1. In Installation Expert > Product Details page, select the Default Directory value and
click the Change button.
The Set Default Install Directory dialog appears. The Default Directory drop-down
list contains all the directories accessed by this installation, including Windows
predefined directories.
2. From Default Directory, select a new default installation directory.
If the directory you want is not listed, add it in Installation Expert > Files page.
To create a new directory as a child of an existing directory, select a directory, click

the New Folder button and, in the Create New Folder dialog, enter a name for the
new subdirectory.
3. Mark Change Feature configurable directories to have any features that

explicitly reference the default directory change when you select a new default
directory.
To see if a feature explicitly references a directory, double-click the feature name on

the Features page. If the Directory field does not contain <none>, then the
feature explicitly references a directory.
4. Click OK.

General Information Page

Use Installation Expert > General Information page to set the summary information and
the required Windows Installer version for the installation file. End users can see the
summary information by right-clicking the compiled .MSI or .EXE in Windows Explorer
and selecting Properties.
For information on summary items, see Summary Property Descriptions in the Windows
Installer SDK Help.
z Title
Enter the name of the application. This field often includes a version number.
z Subject
Enter a brief description of the application.
z Author
Enter the author or publisher of the application. This field often includes a copyright
notice.
z Keywords
Enter a list of keywords that the end user can use to search for this installation in
Windows Explorer.
z Installer Version
(Read-only.) This displays the minimum Windows Installer version required on the
destination computer to run this installation. This is not the version of the
application. If the destination computer has an earlier version of Windows Installer,
the installation fails.
To change this version, select Setup Editor > Product tab, click the Summary icon in
the left pane, and double-click Minimum Installer Version in the upper right pane.
If this is a 64-bit installation, the minimum version of Windows Installer is set to

2.00 or later. Do not change this value in a 64-bit installation.
Microsoft Restrictions:
Installations with a Windows Installer version of 2.0 or later cannot run on

Windows NT 4.0 Service Pack 5 or earlier.
Installations with a Windows Installer version of 3.0 cannot run on Windows 95,
98, Me, or NT 4.0.
Windows Installer version 3.0 requires Windows 2000 Service Pack 3 or later,
Windows XP, or Windows Server 2003.
z Comments
Enter comments about the application that this installation installs.
Add/Remove Programs Page

Windows 2000, XP, and Server 2003 have an Add/Remove Programs applet that
supports a rich display of applications. Use Installation Expert > Add/Remove Programs
page to enter the information necessary to support these capabilities.
z Do not display in Add/Remove Programs list

Mark this to exclude your application from Add/Remove Programs.

z Display in Add/Remove Programs list

Mark this to include your application in Add/Remove Programs and to set the
following:
Display Icon
Specify an icon to appear next to the application name in Add/Remove
Programs. If you leave this blank, a generic icon is used. Click Browse to select
a file from the installation. If the file exists on disk, you also see an icon
selection dialog where you select the icon.
Icon Number
Enter the icon resource ID (preceded by -) or the icon number for the specified
icon. Because a file can contain multiple icons, icons in a file are numbered,
starting from zero. This is pre-filled if you selected an icon from the icon
selection dialog.
Hide modify button

Mark this to disable the Change button for your application in Add/Remove
Programs. This prevents end users from changing the installation.
Hide remove button

Mark this to disable the Remove button for your application in Add/Remove
Programs. End users will not be able to uninstall the application using Add/
Remove Programs.
z Support Information Page

The following information appears under the Support Information link in Add/
Remove Programs.
Online Info URL

Enter a URL where end users can get online support for the application.
Contact Person
Enter the name of a person or department that end users can contact if they
have questions. Examples: a support technician or the support department.
Phone Number
Enter the phone number for the contact person specified above.
Help URL
Enter the path to a help file that will be installed on the destination computer.
Comments
Enter any additional comments for the end user.
Hide repair button

Mark this to disable the installation repair option under the Support Information
link in Add/Remove Programs.
Features Page
Use Installation Expert > Features page to create the structure of an installation by
defining:
z What features make up the application.
z How those features are presented to the end user during installation.
z What conditions must be true for portions of features to be installed.

Determine your application’s features and conditions before configuring other aspects of
the installation, because many of the pages in Installation Expert have a Current
Feature drop-down list that lets you set options on a per-feature and per-condition
basis.
For information on what features are and how they are used, see Working With
Components and Features on page 523.
Note
The Wise Installation System and WiseScript Editor refer to features as “components.”
To see a tree structure that lists all components, merge modules, files, registry entries,
and other installation items associated with each feature, use Setup Editor > Features
tab.
To specify which features are installed by default if the end user selects a Complete,
Typical, or Custom installation type on the Installation Type Dialog, use the Installation
Types page. See Setting Features for Installation Types on page 175.
In an installation with multiple releases, you can deselect certain features for certain
releases on the Release Settings page. See Defining a Feature Set for a Release on
page 183.
About the Complete Feature

In a new installation, the Features page already contains a feature named Complete,
because every installation must contain at least one feature. You can rename the
Complete feature. You can delete it, but only after you create a second feature. See
Strategies for Organizing Files Into Features on page 101.
Working With the Features Page

The tree structure on the Features page displays features and conditions, and their
hierarchical relationships.
z To add a new feature, click its parent feature and click the Add button at the right of
the page. See Adding a New Feature on page 103.
z To configure installation options for a feature, click its icon ( ) and select an
option from its drop-down list. See Configuring a Feature Using Its Drop-Down List.
z To configure all items for a feature, click its name and click Details at the right of the
Features page. See Configuring a Feature Using the Feature Details Dialog on
page 105.
z To delete a feature or condition, click its name and click Delete at the right of the
page. When you delete a feature, all its child features and conditions are deleted
also.
z To rearrange features, click Move Up and Move Down at the right of the page. You
can move features within their current level only, in their current sibling group. You
cannot move features to their parent or child levels.
z To add a condition to a feature, click its name and click Add Condition at the right of
the page. See Using Conditions With Features on page 108 and Adding and Deleting
Feature Conditions on page 109.
Use the right-click menu to:
z Expand or collapse a selected feature’s children.

z Display hidden features.
z Display the features’ titles as they appear on the Select Feature dialog during
installation rather than the features’ names, which are used by Windows Installer.
Any display option you select from the right-click menu overrides the corresponding
setting in Wise Options.
To See How Features Appear During Installation

1. In a sample installation file, add a second feature on the Features page.
2. On the Files page, add a file to each feature. Select the feature from the Current
Feature drop-down list before adding the file.
3. On the Dialogs page, clear the checkbox for Installation Type Dialog, and mark
the checkbox for Select Feature Dialog.
4. Click Test in the lower right corner of the main window. (In Visual Studio: select
Project menu > Start in Test mode.)
The Select Feature dialog in the installation program reflects the options that you set on
the Features page.
Strategies for Organizing Files Into Features

It is important to create and organize features and define conditions in a logical way; not
doing so can result in non-functional versions of your application being installed.
Features in an installation appear in a tree structure, which lets you place features in
hierarchical relationships. You can add a feature at the same level as another feature
(sibling level) or as a child of another feature. Sibling features can be installed
independently of each other, while child features can be installed only if their parent
feature is installed.
The core resources for an application should always be in a top-level feature. The core
feature should install a functioning version of your application; it should have no
dependencies on resources that are in optional features.
When Windows Installer repairs an installation due to corruption or deletion of a

resource, it repairs the entire feature. Example: If an advertised shortcut is part of the
top level feature, and that advertised shortcut gets deleted, the entire application is
reinstalled during the repair. Therefore, isolate advertised shortcuts and their .EXEs into
their own sub-features to avoid complete reinstallation and result in more efficient
repairs.
Place dependent features below required core files:

In the illustration below, the features Internal_Text_Editor and Internal_Graphics_Editor,
which are built into the application, are dependent on the presence of the core
application files, which are assigned to the Core feature. By making them children of the
Core feature, you ensure that they are never installed without the Core feature.

Dependent on Core feature.
Place dependent features as siblings to core files, but require core

files:
In the illustration below, the features Internal_Text_Editor and Internal_Graphics_Editor,
which are built into the application, are dependent on the presence of the core
application files, which are assigned to the Core feature. Because they are siblings of the
Core feature, an end user might install the text editor feature or the graphics editor
feature without installing the core feature, which would break the installation. To avoid
this problem, make the Core feature required; double-click it and mark the Required
Feature checkbox on the Feature Details dialog. Required features cannot be turned off
during installation. The advantage to this strategy is that during installation, the end
user sees the optional features at the top level instead of buried in the tree structure.
Place stand-alone features as siblings:

In the illustration below, the features External_Text_Editor and
External_Graphics_Editor are stand-alone applications, which can run independently of
the core application. Therefore, you can make them siblings of the Core feature. An end
user can install the text editor or the graphics editor without the core application.
Independent of Core feature.

Use conditions with features:

In the illustration below, the Core feature has 2 conditions. VersionNT specifies that the
operating system must be Windows NT, 2000, or XP, and Version9X specifies that the
operating system must be Windows 95, 98, or Me. Because conditions appear in the
Current Feature drop-down list, which appears on most Installation Expert pages, you
can associate the same kinds of items with a condition that you can with a feature,
including files, registry entries, shortcuts, services, and so on. Any items that you
associate with either condition are installed only if the feature is installed and the
condition is true.
Conditions.
Also see Features Page.
Adding a New Feature

1. Do one of the following:
In Installation Expert > Features page, click the feature name under which the
new feature should appear. Then click Add at the right of the Features page.
To add the new feature at the top level, click Installation Features; to add the
new feature under a feature, click the feature’s name.
In Setup Editor > Features tab, right-click the feature under which the new
feature should appear, and select New > Feature.
To add the new feature at the top level, right-click the Features icon; to add the
new feature under a feature, right-click the feature’s name.
The Feature Details dialog appears.
2. Complete the dialog. See Configuring a Feature Using the Feature Details Dialog on
page 105.
3. Click OK on the Feature Details dialog.
The new feature appears in the tree.
4. The order in which features appear on the Features page determines the order of
the features on the Select Features dialog that appears during installation. To
rearrange the order, select a feature name and click Move Up or Move Down at the
right of the Features page.
To edit a feature’s settings, double-click its name. To rename a feature, right-click its
name, select Rename, and enter a new name. To delete a feature and its child features,
right-click its name and select Delete.
Also see:
Features Page on page 99

Strategies for Organizing Files Into Features on page 101

Configuring a Feature Using Its Drop-Down List

In Installation Expert > Features page, when you click the icon next to a feature name,
a drop-down list that contains options for installing the feature appears. The option you
set in this drop-down list determines the default state of the feature during installation.
The drop-down list provides a way to set common options quickly. The icon itself
provides a visual cue that indicating which options have been set.
The drop-down list options are a subset of the options available in the Feature Details
dialog, which you access by clicking the Details button at the right of the Features page.
Note
The first 4 options in the feature’s drop-down list set the default only; the end user can
change the default during installation. To prevent the end user from being able to
change the defaults you set here, you can turn off the Select Feature dialog on the
Dialogs page, use the Feature Details dialog to set features to be required, or set
features to be hidden from the end user.
To set options for a feature:

Click the feature’s icon and select an option. You can select only one of the first 4
options, but you can set the fifth option, Hidden from user, in combination with any of
the first 4 options.
z Will be installed on local hard drive

Make the feature default to being installed on the local hard drive. (This option
corresponds to setting Favor Local in the Attributes drop-down list on the Feature
Details dialog.)
z Will be installed to run from source

Make the feature default to being run from source. (This option corresponds to
setting Favor Source in the Attributes drop-down list on the Feature Details
dialog.)
If a feature is installed to run from source, it is available to the application and

visible to the end user, but is not actually installed on the local hard drive. When the
feature is invoked, your application must call Windows Installer functions, such as
MsiGetComponentPath, to locate and read the necessary files from the installation
source, which might be a CD-ROM or shared network directory. Example: Use this
option to specify a clip art library to run from the source. Then you must code your
application to attempt to read from the installation source when the end user tries
to use the clip art library.
z Feature will be installed when required

Make the feature default to being advertised. (This option corresponds to setting
Favor Advertising in the Advertising drop-down list on the Feature Details
dialog.)
If a feature is advertised, it is available to the application and visible to the end user,
but is not actually installed on the hard drive. If the installation source, such as a
CD-ROM or shared network directory, is available to the destination computer, the
feature is installed when the end user invokes the feature. If the installation source
is not available, the end user is prompted for the installation source.

z Entire feature will be unavailable

Prevent the feature from appearing during installation and from being installed.
(This option corresponds to setting Never Install This Feature on the Level drop-
down list on the Feature Details dialog.)
z Hidden from user

Prevent the feature from appearing to the end user in the installation’s Select
Features dialog. You can set this option in combination with any one of the other
options above. (This option corresponds to setting Hidden in the Display drop-
down list on the Feature Details dialog.)
Also see:

Configuring a Feature Using the Feature Details Dialog on page 105
Configuring a Feature Using the Feature Details Dialog

When you create a new feature or edit an existing feature, you can configure the feature
using the Feature Details dialog. Access this dialog from Installation Expert or Setup
Editor. See Adding a New Feature on page 103.
(Visual Studio integrated editor only.) The Feature Details dialog also appears when you
click the Add New Feature button on the Add Project Outputs to Installation dialog. This
dialog appears during save, build, or compile when the scan method is set to prompt.
See Scanning the Solution for New Files on page 82.
For technical information on the fields in this dialog, see Feature Table in the Windows
Installer SDK Help.
Note
Some options in this dialog set the default only; the end user can change the default
during installation. To prevent the end user from being able to change the defaults you
set, you can turn off the Select Feature dialog on the Dialogs page, set features to be
required, or set features to be hidden.
z Name
Enter the name of the feature, which is used internally by Windows Installer.
z Title
Enter text to identify the feature. This text appears on the Select Features dialog
during installation.
z Parent
This list contains all features in the installation. To change the feature’s parent, and
therefore the feature tree, select from this list. This lets you change the feature tree
in Installation Expert or Setup Editor instead of editing tables.
z Description
Enter a multi-line description of the feature. This appears if the end user selects a
feature on the Select Features dialog during installation. This text must fit in the
Feature Description area of the Select Features dialog.
z Level
If you are using the Installation Types page to determine which features to install for
a Typical or Complete installation, you can skip this field. If not, specify whether this
feature is installed for a Typical or Complete installation. The end user chooses

Typical, Complete, or Custom in the Installation Type dialog (also called Select
Installation Type). During a Custom installation, the end user can turn features on
or off individually.
Each installation has an installation level, stored in the property INSTALLLEVEL.

Each feature has its own installation level value, which is set by this field. If a
feature’s level is less than or equal to the installation’s INSTALLLEVEL property, then
the feature is installed. By default, INSTALLLEVEL is set to 3 for a Typical
installation, and to 1000 for a Complete installation.
Normal
Set the feature’s level value to 3, which means that it gets installed by default
for either Typical or Complete.
Never install this feature

Set the feature’s level value to 0, which means that it won’t appear during
installation, and won’t be installed.
Always install this feature

Set the feature’s level value to 1, which means that it gets installed by default
for either Typical or Complete.
Custom
Set the feature’s installation level value yourself. Example: if you want a feature
to be installed for a Complete installation, but not for a Typical installation, set a
custom level value that’s greater than 3 and less than or equal to 1000. The
Custom Value field becomes available.
z Custom Value
If Custom is selected in Level above, enter the level value for the feature in this
field. For details, read the description of Level, above.
Note
The end user’s action in the Installation Type dialog determines the INSTALLLEVEL
property. To see how this works, go to Setup Editor > Dialogs tab and click the
Installation Type Dialog in the list. Double-click the Typical/Complete/Custom radio
button, and you see that the end user’s choice in this radio group sets the property
InstallMode. If you then double-click Next on the Installation Type dialog and view
the Events tab, you see that, based on the InstallMode value, the installation
property INSTALLLEVEL is set to either 3 or 1000.
z Display
Specify if and how the feature is displayed to the end user in the Select Feature
dialog during installation.
Invisible
Do not display the feature.
Visible and Expanded

Display the feature and its children.
Visible and Collapsed

Display the feature but not its children.
To expand or collapse a selected feature’s children, display hidden features, or

display the features’ titles rather than the features’ names, use the right-click menu
on the Features page. See Features Page on page 99.

z Attributes
Specify the default for the feature in the installation. The end user can change the
default.
Favor Local
The feature should be installed on the destination computer.
Favor Source
The feature should be run from the source CD or network directory. This means
the feature is available to the application, but is not installed on the local hard
drive. When the feature is invoked, your application must call Windows Installer
functions (example: MsiGetComponentPath) to locate and read the necessary
files from the installation source, which might be a CD or shared network
directory. A typical use of this option would be to specify a clip art library to run
from the source. Then you must code your application to attempt to read from
the installation source when the end user tries to use the clip art library.
Favor Parent
The feature should use the same attribute setting as its parent feature. If you
select this option, you must also set the installation to generate uncompressed
external files that can run from the source. See the description of Media Type
in Adding a Media Item on page 202.
z Advertising
Specify the default setting for how this feature supports advertising. If a feature is
advertised, it is not installed, but it appears to be installed to the end user. Example:
The end user might see shortcuts or menu options for an advertised feature, or the
system might have certain entry points to the feature, such as a registered file
extension, that can initiate installation-on-demand of an advertised feature.
None
By default, the feature is set to be installed, not advertised.
Favor Advertising
By default, the feature is set to be advertised.
Disallow Advertising
The feature is set to be installed, not advertised, and the end user cannot
change the default.
Note
Advertising is only supported on certain platforms. To suppress advertising on
unsupported platforms, mark Disable advertising if not supported by OS below.
See Platform Support of Advertisement in the Windows Installer SDK Help.
z Directory
To let end users select the directory for this feature, select a directory from this list.
When the end user selects this feature in the Select Feature dialog during
installation, the Browse button becomes enabled so that they can select a new
directory. Child features of this feature inherit the new directory selected by the end
user. If you leave the directory set to <none>, then the files for this feature are
installed in the directory structure specified on the Files page.
To ensure that two features always get installed to the same directory, select the
same option in Directory for both features.
If you let end users select directories for individual features, you must code your
application in such a way that it can locate the features wherever they might be

placed by the end user. To do this, you can call Windows Installer functions, such as
MsiGetComponentPath.
Note
Only the files that are in the directory you select or in its child directories will be
installed in the new directory that the end user selects. Example: Suppose FeatureA
installs File1 in the Sample\FeatureA\ directory and File2 in the Windows directory.
During installation, the end user specifies Sample\A\ for the new directory. Only
File1, which was originally in the FeatureA\ directory, is actually installed in the A\
directory. File2 is still installed in the Windows directory.
z Required Feature
Mark this if the feature is required for installation. During installation, end users
cannot deactivate installation of a required feature. If you select Never install this
feature in Level (above), it overrides this option.
z Disable advertising if not supported by OS

Mark this to ignore any choices you’ve made in the Advertising drop-down list if
the operating system on the destination computer does not support advertising. See
Platform Support of Advertisement in the Windows Installer SDK Help.
Also see Configuring a Feature Using Its Drop-Down List on page 104.
Using Conditions With Features

You can add conditions to features to specify different actions based on installation
properties, system configuration, end user choices, and so on. Both conditions and
features are listed in the Current Feature drop-down list, which appears on all
Installation Expert pages in the Feature Details page group. Just as you can specify
options on a per-feature basis, you can also specify options on a per-condition basis.
Options on these pages that you associate with a condition are installed only if the
condition is true and the feature is installed.
Example:
Suppose your core application files are stored in a feature named Application. If your
application is installed on Windows 95, 98, or Me, you want to also install
Application9x.dll, but if your application is installed on Windows NT, 2000, XP, or Server
2003, you want to install ApplicationNT.dll. You do not want to install both .DLLs, but
instead want to install one or the other based on the version of the operating system. To
do this, you:
z Add 2 conditions under the Web_Creator feature, Version9X (which specifies an OS

of Windows 95, 98, or Me) and VersionNT (which specifies an OS of Windows NT,
2000, XP, or Server 2003).
z On the Files page, select the VersionNT condition from the Current Feature drop-
down list, then add the ApplicationNT.dll file.
z On the Files page, select the Version9X condition from the Current Feature drop-
down list, then add the Application9x.dll file.
During installation, the files contained within the conditions are installed only if the
condition is true.
Version9X and VersionNT are properties that are set by Windows Installer. See
VersionNT Property and Version9X Property in the Windows Installer SDK Help.

Also see:
WiseFixConditions on page 411

Adding and Deleting Feature Conditions on page 109
Adding and Deleting Feature Conditions

To add a new condition to a feature:
1. Select Installation Expert > Features page.
2. Click a feature name.
3. Click Add Condition at the right of the Features page.
The Feature Condition dialog appears.
4. Click Build, and create your condition in the Condition Builder dialog.
The Condition Builder dialog lets you construct a conditional expression and check
its syntax. For details, see Creating Conditions With Condition Builder on page 411.
Note
If you add a component condition that checks the installed state of a component or
feature, add the merge module CondFix.msm to the installation. This merge module
fixes a Windows Installer limitation. For details, see WiseFixConditions on page 411.
5. Click OK in the Feature Condition dialog.
The condition appears in the Current Feature drop-down list. If you want to make file
changes or other system changes on the destination computer only if this condition is
true, you first select this condition from the Current Feature drop-down list.
To delete a condition:
1. Select Installation Expert > Features page
2. Select a condition.
3. Click Delete at the right of the Features page.
You are prompted to choose what to do with the components that are associated
with the condition. Conditions can contain files, registry entries, and so on, all of
which make up components. When you delete a condition, one of 2 things can
happen:
You can delete all the components that have been added to the condition.
You can move all the components associated with the condition to the
condition’s parent feature. If you choose to move the components, they are
placed under the parent feature, and are installed unconditionally.
Also see Features Page on page 99.
Managing Binary Resources

Use Installation Expert > Resources page to add and update binary resources, and to
change the names or source files for existing binary entries. It provides an easy way to

edit and update peripheral files. (Examples: graphics you might have added for an
installation dialog or .DLLs you might call with a custom action.) Any changes you make
here are reflected in the Binary table that you can access in Setup Editor > Tables tab.
The Resources page also lets you link binary data to its source files, by marking binary
resources to be refreshed. As a result, the binary data is updated during compile with
any modification that might have been made to the source file.
Note
The Resources page might contain entries you did not add, such as images, icons, and
Wise .DLL files. The images and icons appear on wizard dialogs during installation. If you
are using the default installation wizard, do not delete these resource entries; otherwise
you might encounter errors during compile. The Wise .DLL files support advanced
functionality that you add to an installation (example: custom actions). Removing or
refreshing these files can result in advanced functionality ceasing to work correctly.
Columns on the Resources Page

z Name
Name of the row in the Binary table.
z File Name
Path to the source file that contains the binary data. <Unspecified> in this column
indicates that the source file is not known. (Example: This is the case when an
installation includes a third-party .MSI.) Unspecified entries are stored in the .MSI
and cannot be updated during compile.
z Last Modified, Size

Creation or modification date of the file that contains the binary data and its size.
z Refresh
Mark this to update the binary data during compile, to reflect any changes made in
the source file. See Refreshing Binary Resources on page 111.
Working With the Resources Page

z To change binary resource properties for a selected resource, click Details at the
right of the page. See Adding Binary Resources on page 111 for details on the dialog
that appears.
z To add binary resources to an installation, click Add at the right of the page. See
Adding Binary Resources on page 111.
z To delete a selected binary resource from the installation, click Delete at the right of
the page.
z To edit a selected source file, click Edit at the right of the page. The file opens in an
appropriate application or you are prompted to select an application. Make the
changes and save the file.
z To copy binary data into a new source file, click Save As at the right of the page. You
might do this to extract a file stored in an .MSI (with an <Unspecified> file name) to
your disk.

Note
If you’ve saved a resource with an unspecified source file to a new file, don’t save
the installation until you verify that you selected the appropriate file extension. To
do this, select the resource on the Resources page and click the Edit button at the
right of the page. The file should open in an appropriate application. If it doesn’t,
select Edit menu > Reset Page and save the resource again, using a different
extension.
Adding Binary Resources

When you use the Resources page to add binary resources to an installation, Wise for
Windows Installer adds the appropriate rows to the Binary table.
1. In Installation Expert > Resources page, click Add at the right.
The Resource Details dialog appears.
2. Complete the dialog:
Name
Enter a descriptive name for the data you’re adding. This name appears on the
Resources page and in the Binary table. If you leave this blank, the name of the
source file is used instead.
File Name
Specify the file that contains the binary data.
Create/update link to refresh data when file changes

Mark this to update the data during compile with any modification you might
have made to the source file. This also marks the checkbox in the Refresh
column on the Resources page. For details, see Refreshing Binary Resources on
page 111.
If this checkbox is unavailable, you’ve selected a resource with an unspecified

file name.
Note
You can create or remove this link later, by marking or clearing the checkbox in
the Refresh column on the Resources page.
3. Click OK.
Also see Managing Binary Resources on page 109.
Refreshing Binary Resources

When you mark a binary resource to be refreshed, you create a link between the binary
data in the installation and its source file. As a result, each time you compile, the binary
data is updated with any changes you might have made to the source file. In a project
file (.WSI), the source file for a binary resource marked to be refreshed stays outside
the project file, and therefore does not increase the size of the .WSI.
To have a binary resource refreshed:

z Mark the corresponding checkbox in the Refresh column on the Resources page.

z Mark the Create/update link to refresh data when file changes checkbox on
the Resource Details dialog.
See Adding Binary Resources on page 111.
You can only refresh binary resources with known source files. If you try to mark the
Refresh checkbox for a resource whose source file is shown as unspecified, you are
prompted to export the data to a new source file.
To resolve compile errors for binary resources that appear in red:

If a binary resource marked to be refreshed appears in red, with question marks in the
Last Modified and Size columns, the name or the location of its source file has changed.
To compile without binary file errors, do one of the following:
z Use the Resource Details dialog to update the pathname for the source file.
z Clear the Refresh checkbox and use the existing entry for the resource in the Binary
table.
If an error message appears when you try to clear the Refresh checkbox, it means
that the Binary table does not have an entry for this resource. Example: This can
happen if you’re working with a .WSI and the source file was changed while the
project file was closed. In this case, you must use the Resource Details dialog and
set a source file for the binary resource, if you don’t want to delete it.
See Adding Binary Resources on page 111.
Also see Managing Binary Resources on page 109.

Chapter 6
Assembling an Installation
The Feature Details page group of Installation Expert lets you add files and other system
changes to an installation. For information on Installation Expert, see Using Installation
Expert on page 20.
Topics include:
z Files or Web Files Page.
z Visual Studio Solution Page.
z Registry Page.
z INI Files Page.
z Shortcuts Page.
z Adding an Environment Variable.
z Adding File Associations.
z Services Page.
z Adding an ODBC Item.
z Adding to the Windows Firewall Exception List.
Also see About the Merge Modules Page on page 345.
Files or Web Files Page

On the Files or Web Files page, you specify the directories and files to be installed on the
destination computer. You also can specify operations to remove, copy, or move files on
the destination computer during the installation.
On the Web Files page, you also can add Web sites, virtual directories, and Web folders,
and set their options. The Web Files page displays items to be installed to a Microsoft
Internet Information Services Web server, while the Files page displays all items to be
installed. For a summary of differences between the two pages, as well as links to Web-
related functionality, see About Web Installations on page 222.
(Visual Studio integrated editor only.) If an installation is part of a Visual Studio .NET
solution, all primary outputs (.EXEs and .DLLs) of the projects in the solution are added
to the Files page when you create the installation. To add other outputs to the
installation, select them on the Project Outputs page in the project settings. Files you
add to the solution later can also be added automatically. (See Scanning the Solution for
New Files on page 82.) Use the Files page to organize files into features and to add any
files that are not added automatically. For an alternate view of the files in the solution,
use the Visual Studio Solution Page (page 141).
Also see When to Use the File-Related Installation Expert Pages on page 115.

Current Feature
drop-down list.
Directories
available to Files in the
your computer. directory selected
on the left.
Directories to
be installed on
the destination Files or
computer. operations to be
installed on the
destination
computer.
The Windows directory represents the system

directory of the destination computer. Structure
you add to the Web Files page is installed under
the Web server root.
Working With the Files or Web Files Page

z If the installation has multiple features, specify the feature you are configuring by
selecting it from the Current Feature drop-down list.
z Use the right-click menu to expand or collapse folders, to hide or show empty
folders, and to rename folders.
z Drag and drop folders and files to the page and from Windows Explorer, or use the
following buttons:
Add Contents
Add an entire directory to the installation, filter the directory using wildcards,
and link the directory so that the installation’s contents change dynamically as
the directory’s contents change. See Adding Contents of Directories to the
Add File
Add files to the installation. See Adding Files to an Installation on page 117.
New
Create directories to be installed on the destination computer. You also can
create directories in Setup Editor; see Creating a Folder in Setup Editor on
page 389.
Delete (lower left)

Remove a directory from the installation.

Details (lower left)

On the Files page, use this to set NTSF permissions. On the Web Files page, use
this to set all IIS-related details about the item, as well as Web-based security.
Wildcards
Update settings of a directory in the installation; see Editing Settings for
Automatic Updating on page 125.
Operation
Add operations to the installation. See:
Removing a File From the Destination Computer on page 127.

Copying and Moving Files on the Destination Computer on page 128.
Delete (lower right)

Remove a file or operation from the installation.
Details (lower right)

View details on the installation’s files or operations, including attributes, name
and source, permissions, self-registration, and assembly options. See:
Editing File Details on page 129.

Removing a File From the Destination Computer on page 127.
Copying and Moving Files on the Destination Computer on page 128
To learn about Web-specific functionality of the Web Files page, see About Web
Installations on page 222.
Also see:
Installation Directories on page 116

Files or Web Files Page Icons on page 116
Adding Merge Modules Instead of Files on page 120
Adding Files From the Wise Software Repository on page 121
Adding .NET Assemblies to the Installation on page 124
How Self-Registration Information is Captured on page 139
When to Use the File-Related Installation Expert Pages

You can add files to an installation on the Files page, the Web Files page, and the Visual
Studio Solution page (Visual Studio integrated editor only). The following table describes
when should you use each of these pages.
Page When to use it

Files z To add files to any installation.
z In a installation that is part of a Visual Studio

solution, to add files that are not included in the
solution.

Page When to use it

Web Files z To create Web folders, virtual directories, and Web
sites, and add files to them.
z To add files to a Web installation.

Visual Studio Solution z To display the installation’s files in a solution-
(Visual Studio integrated oriented view.
editor only)
z To reorganize files in the installation that were
added from the solution.
Installation Directories
A new installation contains several predefined directories. They appear in the lower left
list box of the Files page, and in the left pane of the Components and Features tabs in
Setup Editor.
z Program Files. Represents the Program Files directory on the destination computer.
z Windows. Represents the system directory (regardless of its actual name) on the
destination computer. Some standard directories are already created under
Windows, such as System32 and Fonts. To create a subdirectory of the system
directory, create it under the Windows directory.
z Program Files (x86). (64-bit installations only.) A 64-bit system has 2 directories for
program files: Program Files, in which 64-bit applications and components are
installed; and Program Files (x86), in which 32-bit applications and components are
installed. See Setting the Default Target Platform on page 52.
z Global Assembly Cache. (.NET installation only.) This is used for assemblies that will
be shared by many applications on the destination computer. It appears only if you
select either .NET Application or Mixed (.NET and Win32) as the application
type on the Product Details page.
z wwwroot. Represents the root of the Web server on the destination computer, which
is typically C:\InetPub\wwwroot\. See About Web Installations on page 222.
You can add new directories on the Files page, the Web Files page, the Components tab,
and the Features tab.
If the directory structure on your computer changes while you are assembling an
installation, change the source directories in the installation, or convert them to relative
or UNC-based source paths. See Source Paths in an Installation on page 324.
Also see:
Files or Web Files Page on page 113

Visual Studio Solution Page on page 141
Files or Web Files Page Icons

The following icons appear in the lower right list box on the Files or Web Files page to
help you quickly identify different types of files on the destination computer.

Icon Represents
Installation file
Duplicate installation file
Installation file with permissions set
File to be removed from the destination computer
File to be moved on the destination computer
New location of file to be moved on the destination computer
File to be copied on the destination computer
New location of file to be copied on the destination computer
Web site. These cannot be deleted or renamed from the Files page.
Use the Web Files page instead.
Virtual directory. These cannot be deleted or renamed from the Files
page. Use the Web Files page instead.
Also see:

Adding Files to an Installation

If you add the same file to multiple locations, it is considered a duplicate file entry. See
Creating Duplicate File Entries on page 389.
(Enterprise Edition only.) When you add files to a package that has already been
distributed to the share point directory and imported, you are prompted to add the new
files to the share point directory. If you do so, the .QUE file for that package is reset and
you must re-import the package in Software Manager.
From Installation Expert:

1. Select the Files or Web Files page. In the Visual Studio integrated editor, you also
can select the Visual Studio Solution page.
2. From Current Feature, select a feature or condition. (Because any item you add
must be assigned to a specific feature, you cannot add an item when All Features
is selected.)
Items that you add to a feature are installed on the destination computer only if the
feature is installed. Items that you add to a condition are installed only if the feature
is installed and the condition is true.

3. If the directory where the file is to be added is not listed in the lower left list box:
a. Select the directory under which the new directory should be created.
b. Click New, enter a directory name, and click OK.
The directory you specify will be created on the destination computer if it does not
exist.
Note
When you add a directory, you might not see it when you select another feature
from Current Feature. To display directories for all features, mark the View
directories for all features on Files page checkbox in Wise Options.
4. In the lower left list box, select the directory to which the file will be added.
5. In the upper list boxes, navigate to a file and double-click it or drag it to the lower
right list box. You can select multiple files.
If you attempt to add files to the Destination Computer icon or the Program Files
directory, you are prompted to first create a folder to hold the files.
The file is added to the selected folder and appears in the lower right list box. If other
dialogs appear, see Additional Dialogs below.
From the Features tab in Setup Editor:

1. On the Features tab, expand a feature and then expand its Combined folder.
2. Expand the Files icon.
If the Files icon does not appear, right-click and select Hide Empty Folders/Items.
3. To add a new directory, right-click a directory and select New > folder.
4. To add a file, right-click a directory and select New > File.
The Add Files to Installation dialog appears.
5. Specify one or more files and click Open.
The file is added to the selected folder and appears in the upper right pane. If other
dialogs appear, see Additional Dialogs below.
From the Components tab in Setup Editor:

1. On the Components tab, expand a component.
2. Right-click the Files icon and select New > File.
If the Files icon does not appear, right-click and select Hide Empty Folders/Items.
The Add Files to Installation dialog appears.
3. Specify one or more files and click Open.
The file is added to the component’s installation directory and appears in the upper right
pane. If other dialogs appear, see Additional Dialogs below.
Additional Dialogs
z If you add a .NET assembly, and if Scan Dependencies in Wise Options is set to
Prompt to scan dependencies, then Wise for Windows Installer:
Scans the assembly manifest for dependencies.

Displays the Assembly Dependencies dialog, which prompts you to select the
dependencies to add to the installation.
See Adding Assembly Dependencies on page 119.
z If a file that is part of a merge module is added, the Files in Merge Modules dialog
appears. It prompts you to add the merge module and, if necessary, download it.
See Adding Merge Modules Instead of Files on page 120.
z If a file that is used by a package in the Wise Software Repository is added, the Files
in Repository dialog appears and prompts you to add a version of the file that is in
the repository. See Adding Files From the Wise Software Repository on page 121.
(Enterprise Edition only.)
z A File Details dialog appears if you double-click a file. It also appears if you select
multiple files and click Details (Files or Web Files page) or right-click and select
Details (Components and Features tabs). See Editing File Details on page 129.
Also see:

Adding Contents of Directories to the Installation on page 122
Adding Files From Outside the Solution on page 123
Editing Settings for Automatic Updating on page 125
Removing a File From the Destination Computer on page 127
Copying and Moving Files on the Destination Computer on page 128
Adding Assembly Dependencies

Each time you add a .NET assembly to an installation, Wise for Windows Installer can
scan its manifest for dependencies and prompt you to select the ones to add to the
installation. (Scanning is available only if the .NET Framework is installed on your
computer.)
This happens when:
z Scan Dependencies in Wise Options is set to Prompt to scan dependencies,

and you add a .NET assembly to the installation.
z You use the Import Visual Basic, C#, or J# tool, and you clear the Automatically
add Assembly Dependencies without prompting checkbox on the Select
Configuration dialog. (Not available in the Visual Studio integrated editor.)
If a file that is part of a merge module is added, the Files in Merge Modules dialog
appears. It prompts you to add the merge module and, if necessary, download it. See
Adding Merge Modules Instead of Files.
If a file that is used by a package in the Wise Software Repository is added, the Files in
Repository dialog appears and prompts you to add a version of the file that is in the
repository. See Adding Files From the Wise Software Repository on page 121.

Note
On .NET Framework versions earlier than 1.1, scanning does not occur when you add an
assembly from a UNC or mapped network drive (example: the share point directory). To
enable scanning of such assemblies, either upgrade to .NET Framework version 1.1 or
later, or change your .NET security so that the share point directory is fully trusted.
If dependencies are found, the Assembly Dependencies dialog appears and lists
dependencies for all added files. To add dependencies to the installation, mark their
checkboxes and click OK.
Adding Merge Modules Instead of Files

The Files in Merge Modules dialog appears when a file that is part of a merge module is
added to an installation. Typically, it appears when you add a file to the Files or Web Files
page. It might also appear after you add files on the Visual Studio Solution page, or run
tools that add files to an installation (example: ApplicationWatch.) The Files in Merge
Modules dialog lets you add the merge module that contains the file instead of adding
the file.
Example:
The file olepro32.dll is part of a merge module named oleaut32.msm (Microsoft OLE
2.40). Because the file olepro32.dll is meant to function as part of a more
comprehensive merge module, it is better to add the merge module instead of the
individual file.
The merge module might contain other files, registry keys, and dependencies on other
merge modules. If it contains dependencies, the dependent merge modules are added
also. Other files and registry keys that are in the merge module are removed from the
installation to avoid duplication.
To add the merge module that contains the file:

Mark the checkboxes of merge modules to add. To see what dependent merge modules
will be added, expand the folders. Then click OK.
If the merge modules or their dependencies are not found, the Download
Redistributables Wizard opens with the appropriate merge modules selected. When you
finish the download, the merge modules are added to the installation.
To add the file instead of the merge module:

Clear the checkboxes of all merge modules and click OK. Dependency merge modules
are not added if you clear the parent merge module’s checkbox.
To hide this dialog in the future:

From Show this Dialog, select one of the following:
z Hide; Replace files with merge modules matching version

Avoid seeing this dialog in the future and always replace files with the corresponding
merge modules. This turns the dialog off for all instances in which it would normally
appear.
z Hide; Don’t automatically add merge modules

Avoid seeing this dialog in the future and never replace files with the corresponding
merge modules. This turns the dialog off for all instances in which it would normally
appear.

To make the dialog appear again, click the Prompts tab in Wise Options and activate the
dialog.
Also see:
Downloading Redistributable Files on page 35

Adding Files to an Installation on page 117
Adding Files From the Wise Software Repository

The Files in Repository dialog appears when a file that is used by a package in the Wise
Software Repository is added to an installation. Typically, it appears when you add a file
to the Files or Web Files page. It might also appear after you add files on the Visual
Studio Solution page, or run tools that add files to an installation (example:
ApplicationWatch). The Files in Repository dialog lets you add the version of the file that
is in the repository, which ensures that you use the correct versions of file resources in
applications you develop.
Example: An approved version of the file Sample.dll is stored in the Wise Software
Repository and is used by several packages in the Software Manager database. When
you add Sample.dll to an installation, you can select the version in the repository as the
source for the file.
To add a file from the Wise Software Repository:

On the Files in Repository dialog, mark the checkboxes of files to add and click OK.
The file’s source path is set to the same location as the version in the Wise Software
Repository. You can see the source path on the File Details dialog > General tab.
Caution
If you are working in a Visual Studio solution, selecting a file outside the solution breaks
the integration of the installation with the solution. When you build the solution, the
outside file will not be built. Also, a source file outside the solution cannot be added to
source control.
To hide this dialog in the future:

From Show this Dialog, select Hide. This turns the dialog off for all instances in which
it would normally appear.
To make the dialog appear again, click the Prompts tab in Wise Options and activate the
dialog.
Also see:
Viewing Shared File Resources on page 136


Adding Contents of Directories to the Installation

You can add the entire contents of a directory to an installation or use wildcard filters to
add only specified files in the directory. You also can link a directory that you add to the
installation so that it is dynamically updated when the source directory changes.
1. Select Installation Expert > Files or Web Files page.
is selected.)
3. In the upper left list box, select a directory whose contents you want to add.
4. In the lower left list box, select a directory where you want to add the contents.
5. Click Add Contents.
The Add Contents dialog appears.
Dest. Directory
Enter the name of the installation directory that will hold the contents of the
directory you’re adding. If you don’t enter a directory name, the contents are
added to the directory that’s selected in the lower list box.
Include Wildcards, Exclude Wildcards

To add or exclude files based on specific criteria, enter a semicolon-delimited
list of wildcards. Wildcards apply only at the moment you click OK in this dialog
unless you also mark the Update installation checkbox below. (Example:
Enter *.EXE for all EXE files. A ? represents any one character.) If you leave the
wildcard fields blank, all files in the directory are added. Groups of wildcards
appear in Include Wildcards, which you can edit; see Setting Wildcard Groups
on page 54.
Include Subdirectories
Mark this to add all the subdirectories within the directory you’re adding. The
wildcard settings and update installation settings apply to the subdirectories
also.
Update installation as files are added or removed from source directory

Mark this to dynamically update the installation when the contents of the
directory you’re adding change on your computer. Otherwise, the wildcards
apply only at the moment you add the directory.
Note
If you link a directory using this checkbox and if files originally added by the
wildcard are now missing, a Wildcard Deleted Files dialog appears when you
save the installation. Click No to leave temporarily missing files in the
installation.
If you mark this checkbox, each time you save the installation, it is
synchronized with the current contents of the directory. If you specified
wildcards, the installation is synchronized based on the wildcard criteria. If you
included subdirectories, those directories are updated also. If you don’t mark

this checkbox, you can turn automatic updating on later by using the Wildcard
Details dialog; see Editing Settings for Automatic Updating on page 125.
7. Click OK.
The contents of the directory in the upper left list box are added to the directory you
selected in the lower left list box or to the directory you specified in the Dest.
Directory field. If you marked the Update installation as selected files are
added or removed from source directory checkbox, the linked folder displays
with a small magnifying glass ( ).
Note
When you add a directory, you might not see it when you select another feature
from Current Feature. To display directories for all features, mark the View
Also see:

Adding Files From Outside the Solution

When you add files from outside a solution to an installation that is part of a solution,
those files do not appear in the Source Files tree under the installation project in
Solution Explorer. In addition, you cannot add those files to source control, because
Visual Studio .NET does not allow files outside a solution to be managed with source
control.
The Copy Source Files dialog, which appears the first time you save or build a solution
after adding files from outside the solution, lets you copy the source files to the solution
directory. If you click Cancel on the Copy Source Files dialog, that file is not copied and
the dialog will not appear again for that file. If you do not copy source files with the Copy
Source Files dialog, you can use Convert Source Paths instead. See Source Paths in an
Note
Files that you add to the installation from the Wise Software Repository do not appear
on the Copy Source Files dialog, even though they are outside the solution, because you
cannot copy those files to a different directory.
To copy files to the default solution directory:

This is the recommended way to copy source files.
z When the Copy Source Files dialog appears, click OK.
All files that are listed in the dialog are copied to the default solution directory, which is
listed in the Copy To column, and their source paths are changed in the installation.
When the files are successfully copied, they appear in the Source Files tree in Solution
Explorer.

To copy files to a specified directory:

This lets you copy the source files to a directory other than the default solution path.
1. On the Copy Source Files dialog, select the file to copy.
2. Click Change Selected Path.
The Change Selected path dialog appears. Current Directory displays the current
location of the file.
Change to
Specify the directory.
Change Sub-Directories
Mark this to copy files in all subdirectories of the current directory.
4. Click OK.
On the Copy Source Files dialog, the new directory path is listed in the Copy To
column.
5. Repeat these steps to copy additional files.
6. Click OK on the Copy Source Files dialog.
The files are copied to the locations you specified, and their source paths are
changed in the installation.
Also see:

Adding .NET Assemblies to the Installation

Note
later.
When you create a .NET installation, you can use the Files or Web Files page to add .NET
assemblies. In the Visual Studio integrated editor, you also can use the Visual Studio
Solution page. When you add a file that is a .NET assembly to an installation, the
MsiAssembly and MsiAssemblyName tables are updated.
If the .NET Framework is installed on your computer, the following tasks are performed
automatically when you add a .NET assembly. If the .NET Framework is not installed,
you must perform these tasks manually; see Creating a .NET Installation Without the
.NET Framework on page 221.
z Files contained in a multifile assembly are added when the main assembly file
(containing the manifest) is added.
z Depending on the Scan Dependencies option in Wise Options, you either enter
assembly dependencies manually, or they are scanned and added automatically, or
they are scanned and you are prompted to add them.
z Assembly attributes are added to the Assembly tab of the File Details dialog.

z In a mixed installation (.NET and Win32), registry keys are added to register .NET
assemblies so that they can be called as though they were COM components.
You can install assemblies into the Global Assembly Cache, the WinSxS directory, or a
private directory. Each of these directories is used in a different way:
Global Assembly Cache

Assemblies that will be shared by many applications on the destination computer should
be installed into the Global Assembly Cache directory. Assemblies installed into the
Global Assembly Cache must be strongly named. A strong name consists of an
assembly’s identity—its simple text name, version number, and culture information (if
provided)—strengthened by a public key and a digital signature generated over the
assembly. The Global Assembly Cache directory appears only if .NET Application or
Mixed (.NET and Win32) is selected as the application type on the Product Details
page. See Installation of Assemblies to the Global Assembly Cache in the Windows
Installer SDK Help.
WinSxS
To enable side-by-side sharing of a Win32 assembly, install it into the WinSxS directory,
which is under the Windows directory on Windows XP or later. Assemblies installed into
WinSxS must be strongly named. On Windows XP or later, shared assemblies are
installed as side-by-side assemblies. See Side-by-Side Assemblies in the Windows
Installer SDK Help.
Private directory
If an assembly is private, used by only one application, install it into any installation
directory, provided its path contains a maximum of 256 characters. See Private
Assemblies in the Windows Installer SDK Help.
Also see:

Editing Settings for Automatic Updating

On the Files or Web Files page, if you link a source directory to a directory in the
installation, the files in the installation are updated when the contents of the source
directory change. You can add and edit the settings for automatic updating of a
directory:
1. Select Installation Expert > Files or Web Files page.
is selected.)
3. Click the directory name in the lower left list box and click Wildcards at the lower left
of the Files or Web Files page.
The Wildcard Details dialog appears. If the directory is currently linked to directories
on your computer, those directories appear in the Source Directory list.

4. To link the contents of a source directory to this installation directory, click Add,
select a directory from your computer, and click OK.
Whenever the contents of directories in the Source Directory list change, the
installation directory is updated, based on the wildcard settings. Example: Suppose
you link the directory C:\Directory and enter *.exe in Include Wildcards. Later
you add Editor.exe to C:\Directory and remove Paint.exe from C:\Directory. This
installation is updated so that it contains Editor.exe and does not contain Paint.exe.
If you also added Paint.dll to the source directory, it is not added to the installation
directory because it does not match the wildcard criteria.
5. To turn off automatic updating for this installation directory, select each directory in
the Source Directory list and click Delete.
6. To configure a particular source directory, select it in the Source Directory list and
complete the Wildcard Details dialog:
Include Wildcards, Exclude Wildcards

To include or exclude files based on specific criteria, enter a semicolon-
delimited list of wildcards. (Example: Enter *.EXE for all EXE files or *.DLL for
.DLL files.) If you leave the wildcard fields blank, all files in the directory are
added. Groups of wildcards appear in Include Wildcards. To edit groups, use
the Wildcards tab in Options; see Setting Wildcard Groups on page 54.
Include Subdirectories
Mark this to add all the subdirectories within the directory you’re adding. The
wildcard settings and update installation settings apply to the subdirectories
also.
Change existing components’ attributes

When files are added because of changes in the source directory, new
components are created to hold them. Mark this to reset the attributes of any
pre-existing components to the settings specified on this dialog. If you do not
mark this checkbox, the files currently in the source directory do not have the
component attributes you set below.
Run location
Specify whether new components are installed on the local hard drive (Run
Locally), not installed on the local hard drive (Run From Source), or either.
Change this option only if you plan to integrate Windows Installer function calls
into your application to determine the installed location.
Always increment shared DLL count

Mark this to always increment the count of applications using .DLLs in this
component when it is installed, even if the file is not already installed. Normally,
Windows Installer only increments the shared DLL count on a file if the file is
installed and has an existing shared DLL count. If a component is installed to
the Global Assembly Cache, you cannot increment the shared DLL count.
Leave installed on uninstall

Mark this to leave the component installed when its parent feature is
uninstalled.
Check condition during reinstall

Mark this to check conditions attached to the component when the application is
reinstalled. If this is not marked, the conditions are checked only during the
original installation.

Never overwrite if key path exists

Mark this to prevent the installation of this component if the file, registry entry,
or ODBC data source specified as the key path is already present.
7. Click OK.
8. If a change in the wildcards causes files to be deleted, the Wildcard Deleted Files
dialog appears. Click Yes to remove the listed files from the installation.
The files in the installation directory are updated immediately according to the changes
you made on the Wildcard Details dialog.
Also see:

Removing a File From the Destination Computer

You can add an operation to remove one or more files from the destination computer
during installation. This operation affects files that are already on the destination
computer, not files that are part of the installation.
You can use this operation to remove unneeded files on the destination computer to
keep it in a cleaner state. You also can use it to work around Windows Installer version
rules. Example: If the latest release of an installation uses an older version of a .DLL
than was used in the previous release, the version rules will not allow you to install the
older .DLL. If the installation first removes the newer .DLL from the destination
computer, then the version rules will not prevent the installation of the older .DLL.
Caution
Be very careful when removing files from the destination computer. Do not remove files
unless you are sure that they are not used by another application.
Select Installation Expert > Files or Web Files page.

From Current Feature, select a feature or condition. (Because any item you
add must be assigned to a specific feature, you cannot add an item when All
Features is selected.)
Items that you add to a feature are installed on the destination computer only if
the feature is installed. Items that you add to a condition are installed only if
the feature is installed and the condition is true.
Click Operation below the lower right list box and select Remove File.
In Setup Editor, on the Components or Features tab, right-click a component or

feature and select New > Remove File.
The Remove File Details dialog appears.

Directory
Specify the directory on the destination computer where the file is located or
create a new subdirectory. To create a new subdirectory, select a directory and
click New Folder.
File Name
Specify the name of the file to be removed. You can use wildcards to select
multiple files or you can mark All Files to select all files in the selected
directory.
Remove During
Specify when the file should be removed: during install, uninstall, or both install
and uninstall.
3. Click OK.
The operation to remove a file from the destination computer appears, preceded by .
On the Files or Web Files page, the entry’s Type column contains “Remove.”
To edit it, double-click its name. To delete it, use the right-click menu.
Also see:

Copying and Moving Files on the Destination Computer

You can add an operation to copy or move a file on the destination computer during
installation. This operation affects files that are already on the destination computer, not
files that are part of the installation.
You might copy or move files on the destination computer to reorganize the location of
the installation files in a new release. Example: Your application installed graphic files to
C:\Program Files\Application\Graphics, but your latest release installs them to C:\My
Documents\Application. You can add an operation to copy or move the existing graphic
files from the old directory to the new directory.
Caution
Be very careful when moving files on the destination computer. Do not move files unless
you are sure that they are not used by another application.
Select Installation Expert > Files or Web Files page.

Click Operation below the lower right list box and select Copy File or Move File.


feature, select New, and select Copy File or Move File.
The Copy File Details or Move File Details dialog appears.
Source Directory
Specify the directory on the destination computer where the file is located or
click New Folder.
Source File Name

Specify the name of the file to be copied or moved. You can use wildcards to
select multiple files or you can mark All Files to select all files in the selected
directory.
Dest. Directory
Specify the directory on the destination computer to copy or move the file to or
click New Folder.
To rename files on the destination computer, make the source and destination
directory the same.
Dest. File Name

To change the name of a file when it is copied or moved, specify the new name.
To leave the file name unchanged when it is copied or moved, leave this field
blank. This also works when you use wildcards in the Source File Name field to
select multiple files.
3. Click OK.
The operation to copy or move a file on the destination computer appears, preceded by
the copy icon ( ) or move icon ( ). On the Files or Web Files page, the entry’s Type
column contains “Copy to” or “Move to” followed by the directory to which the file will be
copied or moved.
To edit it, double-click its name. To delete it, use the right-click menu.
Also see:

Editing File Details

When you add a file to an installation, it inherits the attributes of the original file. If you
edit the attributes of a file in an installation, the file reflects your edits when installed on
the destination computer.

Note
When you add an operation to remove, move, or copy a file on the destination computer,
an entry for that operation appears on the Files or Web Files page in the lower right list
box. Because the entry is an operation to be performed on a file on the destination
computer, you cannot edit its attributes. However, you can edit the details of the
operation.
To edit attributes for a single file:

On the Files or Web Files page, double-click a file in the lower right list box.
(Visual Studio integrated editor only.) On the Visual Studio Solution page, double-click a
file in the lower right list box.
The File Details dialog appears. It contains several tabs. See:
Editing General File Details on page 130

Setting Permissions for Files and Directories on page 132
Editing Self-Registration Settings for Files on page 133
Editing Assembly Settings for Files on page 133
Viewing Shared File Resources on page 136
Editing XML Files During Installation on page 137
To edit attributes for multiple files:

1. On the Files or Web Files page, or the Visual Studio Solution page (Visual Studio
integrated editor only), select multiple files in the lower right list box.
2. Click Details at the lower right of the page.
The File Details dialog for multiple files appears. Only a subset of the editing options are
available. You cannot edit permissions, self-registration settings, assembly settings, or
view shared resources. For details, see Editing General File Details on page 130.
Note
If you add a file to an installation, then add it again to a different directory, the second
instance is added as a duplicate file. If you double-click the second file, the Duplicate
File Details dialog appears instead of the File Details dialog. (Also see Creating Duplicate
File Entries on page 389.) With .NET assemblies, if you add the same file to the
application directory and the Global Assembly Cache, a duplicate file is not created
because they are treated as separate components.
Also see:

Editing General File Details

In Installation Expert: On the Files or Web Files page, double-click a file. In the
Visual Studio integrated editor, you also can use the Visual Studio Solution
page.
In Setup Editor: On the Components or Features tab, double-click a file.

The File Details dialog appears.
2. Click the General tab.
Long Filename
The name of the file as displayed on computers running Windows 95 and later.
Short Filename
The 8.3 file name as displayed in DOS or under older versions of Windows.
Specify the short name your application will look for if it is installed on a shared
network directory that doesn’t support long file names.
Source Pathname
The full pathname of the file on your computer. If this is blank, or if it is just a
file name with no path, you might be working in an .MSI, which encapsulates
the file itself.
Font Name
The name of the font contained in the file, if it is a font file.
Read Only
Make the file read-only on the destination computer.
Hidden
Make the file hidden on the destination computer.
System
Designate this file as a system file on the destination computer.
Vital
Mark this if this file must be installed correctly for the installation to succeed. If
the file cannot be installed for any reason, the installation fails.
Add to Hash Table

If this is an unversioned file, mark this to create an entry for this file in the
MsiFileHash table. Windows Installer version 2.0 or later uses file hashing to
detect and eliminate unnecessary file copying during reinstalls and repairs. It
does this by comparing a file hash stored in the MsiFileHash table to a hash of
an existing file on the destination computer. See MsiFileHash Table in the
Windows Installer SDK Help. (Not available for multiple files.)
Self-Register OCX/DLL
(Multiple Files dialog only.) Many files support self-registration (examples:
many .OCXs and some .DLLs). Mark this to self-register these files during the
installation with an unordered registration method.
File has Valid Checksum

Many executable files (examples: .EXE, .OCX, .DLL, etc.) store a checksum that
can be checked against actual file contents to ensure the file is not corrupted.
Mark this to have file contents verified during reinstall or repair. If the
verification fails, the file is assumed to be corrupted and is replaced. For files
that contain checksum information, this checkbox is marked automatically when
you add the file to the installation.
Duplicate Files
This appears only if this file was added to the installation more than once. The
duplicates are listed here for informational purposes only. You can view and edit
duplicate file entries on the Components and Features tabs in Setup Editor. See
Creating Duplicate File Entries on page 389.

4. Click OK.
Note
With .NET assemblies, if you add the same file to the application directory and the
Global Assembly Cache, a duplicate file is not created because they are treated as
separate components.
Setting Permissions for Files and Directories

You can set NTFS (NT file system) permissions for files and folders. You set permissions
for a file or folder for a specific user; thus for one file or folder, you can create sets of
permissions for multiple users. Set permissions only if you know the user names and
domains of users who install this installation.
Note
Permissions require an NTFS partition and therefore work only under Windows NT, 2000,
XP, and Server 2003. The Permissions tab does not set Web-based security. To set Web-
based security, go to Installation Expert > Web Files, select the directory or virtual
directory, and click the Details button. The Directory Security tab lets you set options for
Microsoft Internet Information Server. See IIS documentation for details on options.
To set NTFS file or directory security:

1. Specify a file or folder:
In Installation Expert: On the Files page, select a file or folder and click the
corresponding Details button. In the Visual Studio integrated editor, you also
can use the Visual Studio Solution page. (On the Web Files page, you can set
Web server security, not NTFS security.)
In Setup Editor: On the Components or Features tab, right-click a file, or a

folder underneath a Create Folder icon, and select Details.
The details dialog appears.
2. On the Permissions tab, click Add, which lets you add a user and specify permissions
for that user.
The Lock Permissions Details dialog appears.
3. Enter the Domain and User name and click OK.
4. The domain and user names appear in the upper list box, and the list of permissions
is enabled.
5. To set permissions, mark the checkboxes.
You can add multiple users.
Caution
If you set permissions for a folder that is written to by this installation, be sure that the
user installing this application has privileges to write to the folder. Example: Suppose
you give write privileges to ASPNET_USER for Program Files\SampleFolder, which later
in this installation has files written to it. The current user profile running this installation
is ADMINISTRATOR. Therefore installation will fail to write to SampleFolder, because
only ASPNET_USER has write permissions to SampleFolder. ASPNET_USER is
automatically set; see Runtime Properties on page 424.

When you set permissions for a file, the file appears preceded by .
Editing Self-Registration Settings for Files

Many files support self-registration (examples: many .OCXs and some .DLLs). You can
edit these files so that they self-register during installation.
page.

2. Click the Self-registration tab.
Registration Method
Do not register
Unordered (normal Windows Installer behavior)

Select this if the file does not require that other files in the installation be
registered first for it to self-register properly.
Use order specified below

(Not available in a merge module.) Select this if this file requires that other
files in the installation be registered first for it to self-register properly. This
enables the Registration Order field.
Registration Order
This section lists files you’ve selected for self-registration with the Use order
specified below method. Arrange files in the order in which they need to self-
register. You can only move the file for which you are viewing details.
Generate COM interop registry keys for .NET Assembly

If this installation contains both .NET and COM elements, mark this to register
.NET assemblies so that they can be called as though they were COM elements.
This checkbox is enabled only if you have the .NET Framework installed on your
computer, and if the file you are viewing is an assembly that was written to
allow COM interop. When the Application Type on the Product Details page is
Mixed (.NET and Win32), this checkbox is marked by default.
4. Click OK.
Editing Assembly Settings for Files

Use the Assembly tab on the File Details dialog to enter and edit information about .NET
and Win32 assemblies. Wise for Windows Installer uses this information to register the
assembly files.
z For a .NET assembly, use the Assembly tab to enter the assembly attributes. If the
.NET Framework is installed on your computer, this information is filled in from the
assembly manifest and you should not have to change it. Also use the Assembly tab
to specify whether to display the .NET assembly as a reference in Visual Studio .NET
on the destination computer.

z For a Win32 assembly, use the Assembly tab to create and edit a manifest. See
Creating a Win32 Assembly on page 135.
To edit assembly settings for files:

In Installation Expert: On the Files, double-click a file. In the Visual Studio

integrated editor, you also can use the Visual Studio Solution page.

2. Click the Assembly tab.
The Assembly tab only appears for files that are keypaths to their components.
3. Complete the dialog. If you have .NET installed on this computer, some of these
options may be preconfigured. If you don’t have .NET, enable options below by
selecting .NET in Assembly Type.
Assembly Type
Specify whether this file is a .NET assembly, a Win32 assembly, or neither.
Manifest
.NET and Win32 assemblies require a manifest. Select the file that contains the
manifest for this assembly. For .NET assemblies, this often is the same as the
file you are editing, because most manifests are embedded in the assembly file
or in one of the files in a multifile assembly. For Win32 files, the manifest is
often an external file with the same name plus “.manifest”. (Example: The
manifest for My.exe would be named My.exe.manifest.) For information on
creating a Win32 assembly and manifest, see Creating a Win32 Assembly on
page 135.
Assembly Attributes
This displays the assembly’s name, publicKeyToken, and version attributes.
If this information has not been pre-filled, click Add to enter it. Enter the Name
and Value for each of the assembly’s attributes. For information on obtaining
assembly attributes, see Creating a .NET Installation Without the .NET
Framework on page 221.
Show reference in Visual Studio .NET

Mark this to add a registry key that displays this assembly as a reference in
Visual Studio on the destination computer. (Visual Studio .NET 2002 or later
only.) This lets you pull the assembly into a Visual Studio project without having
to browse for it.
Execute Install method on this assembly

A .NET assembly can contain an install object that performs additional
installation functions unique to the assembly. Mark this to execute this
assembly’s install object after the file is installed.
Generate native-code version during installation

Mark this to run the Native Image Generator (ngen.exe) on the assembly after
it is installed. The Native Image Generator precompiles portions of the assembly
and caches it on the target computer so assemblies load and execute faster. For
details, search for “Native Image Generator” in the MSDN Library
(msdn.microsoft.com/library/).
4. Click OK.

Also see Editing File Details on page 129.
Creating a Win32 Assembly

Your can use Win32 assemblies to isolate applications on destination computers running
under Windows XP or later. Isolating an application .EXE means its dependent, shared
.DLL and .OCX files are placed inside the application directory or in the WinSxS directory
rather than in a non-side-by-side location. This ensures that your application always
uses the version of .DLL or .OCX with which it was installed. It prevents overwriting of
previous versions of the .DLL or .OCX and ensures that other applications do not
overwrite your version of shared files.
You isolate a Win32 assembly by means of a manifest file, which describes the assembly
and any resources it depends on. Options for adding a Win32 assembly and its manifest
to an installation are:
z Create a manifest for a Win32 assembly outside of Wise for Windows Installer, then
add the assembly and its manifest to the installation as you would any other files.
On the Assembly tab of the File Details dialog, mark it as a Win32 assembly and
specify the manifest file.
z Use the procedure below to create a Win32 assembly and manifest on the Manifest
File Details dialog. This populates the MsiAssembly and MsiAssemblyName tables.
Caution
Isolation does not work on all applications. Applications must be written according to
Microsoft programming guidelines to work with operating system isolation methods.
(Example: If an application hard-codes paths to support files, isolation might not work.)
For details, see the following topics in the Windows Installer SDK Help: Isolated
Components, Installation of Win32 Assemblies, Side-by-Side Assemblies. Also, search
for “assembly manifest” and “isolated applications” in the MSDN Library
(msdn.microsoft.com).
To create a Win32 assembly and manifest:

1. Add the application file and its dependent files to the installation.
2. In Installation Expert > Files or Web Files page, double-click the application file in
the lower-right list box. In the Visual Studio integrated editor, you also can use the
Visual Studio Solution page.
3. Click the Assembly tab.
4. From Assembly Type, select Win32.
Attributes are read from the file and displayed in the Assembly Attributes list, and
a manifest file name is entered in Manifest.
5. To add dependencies to the manifest file, click Edit.
The Manifest File Details dialog appears.
6. Click Add, then select an option:
Installed File
Adds a dependency to a file that is in the installation. On the Select File dialog
that appears, select the dependency file and click OK. The dependency file is

added to the installation as a side-by-side assembly. It is marked as a Win32

assembly and a manifest is created for it.
External Manifest
Adds the attributes of an external manifest file as a dependency. Specify a
manifest file and click OK. The manifest you specify and the file it points to must
be present on the destination computer or in the installation. They must also be
located in the application’s directory structure or the WinSxS directory. See
Private Assemblies in the Windows Installer SDK Help.
7. To add more dependencies, repeat the preceding step.
8. Mark Use XP Common Controls to add a dependency on the Common Controls

Version 6.0, which gives the Win32 assembly .EXE the look and feel of Windows XP.
For details, search for “Windows XP visual style” in the MSDN Library
(msdn.microsoft.com).
9. Click OK, then click OK on the File Details dialog.
The manifest file is created in XML format and added to the installation with the same
name as the dependent file plus “.manifest”. (Example: The manifest for My.exe would
be named My.exe.manifest.) The manifest is also added to your computer with the
extension .XML. (Example: If you add C:\Program Files\My.exe and make it a Win32
assembly, the file C:\Program Files\My.exe.xml is created.)
Also see:
Editing File Details on page 129

Editing Assembly Settings for Files on page 133
Viewing Shared File Resources

The Shared Resources tab on the File Details dialog displays all packages in the Software
Manager database that use a specific file, even if they install the file to a different
location. This lets you:
z Determine the correct version of the file to use in your application. If you are
connected to the Software Manager database used with your organization’s
installation of Wise Package Studio, you can see if the file is used by packages that
have already been deployed.
z Resolve potential file conflicts during the development cycle. When the file in the
current installation conflicts with a file in the Wise Software Repository, you can
replace the current file with the correct version from the repository.
You also can view shared file resources in a report format. See Generating Shared
Resource Reports on page 33.
To view shared resources, you must be connected to a Software Manager database data
source. For information on the Software Manager database, see About the Software
Manager Database in the Software Manager Help.
To view shared file resources:


page.

2. Click the Shared Resources tab.
In the Visual Studio integrated editor, “Output from current solution” in the
Application column indicates a file that is in the current Visual Studio solution.
A white exclamation point to the left of the package indicates that the current file is
already in the Wise Software Repository and it does not conflict with the file used by
that package.
A red exclamation point to the left of the package indicates that the current file
conflicts with the file used by that package. Examples: The files have a different
version, date/time, or size; the files are installed to the same directory, but
component GUIDs do not match.
To select a different file:

Caution
If you are working in a Visual Studio solution, selecting a file outside the solution breaks
the integration of the installation with the solution. When you build the solution, the
outside file will not be built. Also, a source file outside the solution cannot be added to
source control.
1. On the Shared Resources tab of the File Details dialog, select the application that
contains the version of the file you want to use.
(Visual Studio integrated editor only.) If you previously sourced the file from outside
the solution, you can rebind the file to the solution by selecting the version labeled
“Output from current solution.”
2. Click Use Instead.
This button is disabled when: the application you selected above is the one that is
currently open; there is no conflict; or the source file listed in the Wise Software
Repository cannot be found (example: the file has been deleted).
3. Click OK.
The current file is replaced with the version of the file in the Wise Software
Repository. If a conflict existed, the exclamation point to the left of the package
changes from red to white.
Editing XML Files During Installation

When you add an XML file, such as Web.config, to the Files or Web Files page, and then
get details for the XML file, the Dynamic Content tab appears, which shows the file’s
contents.

The purpose of the Dynamic Content tab is to let you modify the XML file by inserting
system-specific information such as local directory paths and user names. Because this
information is different for each server, you use Windows Installer properties to specify
dynamic items.
Note
If you add an XML file, but the Dynamic Content tab does not appear in the file’s details
dialog, the file was not recognized as a well-formed XML file. Check the file for
irregularities and verify it adheres to XML and Microsoft authoring standards.
To set values to be replaced in an XML file at runtime:

1. On the Files or Web Files page in Installation Expert, add a valid XML file. In the
Visual Studio integrated editor, you also can use the Visual Studio Solution page.
2. Double-click the XML file and select the Dynamic Content tab.
The contents of the XML file appear in the list box.
3. Mark Enable Dynamic Content.
The Edit button becomes enabled for editable lines only after you mark Enable
Dynamic Content.
4. Select a line and click the Edit button.
Not all lines are editable, only lines that have name-value attributes. (Example:
<compilation defaultLanguage=”c#” />.) The Attribute Editor dialog appears.
5. To edit an XML attribute:
a. Select the attribute in the top list box.
b. In Dynamic Value, type a new value to replace the current value at runtime.
You can enter bracketed Windows Installer property names. You must have
added a mechanism elsewhere in the installation to populate the property.
(Example: Use the Custom Property Dialog; see Adding the Custom Property
Dialog on page 455. Or use properties defined in Runtime Properties on
page 424.)
c. Alternatively, you can select a property name from Property and click the
Insert into Dynamic Value button.
6. Click OK in the Attribute Editor dialog when finished.
During runtime, the attribute is replaced with the dynamic value you specified. Windows
Installer properties are resolved to their value.
Editing DIFxApp Options

When an installation contains a device driver that meets Microsoft’s Driver Install
Frameworks (DIFx) driver requirements, you can use Microsoft’s Driver Install
Frameworks for Applications (DIFxApp) to install the driver. See Creating a Device Driver
You edit the DIFxApp options on the Driver tab of the File Details dialog. This tab
appears only if all of the following are true:
z The DIFxApp merge module has been added to the installation.

Note
Early versions of this merge module might be named “Binaries.”
z You selected an .INF file on the Files page.
z The .INF file is the key path of the component.
To edit DIFxApp options:

1. Double-click the device driver’s .INF file on the Files page or on the Components or
Features tab in Setup Editor. In the Visual Studio integrated editor, you also can use
the Visual Studio Solution page.
2. Click the Driver tab.
Use DIFxApp to install this driver file

When you mark this checkbox, the other options become enabled. They are all
marked by default.
Retain better-matching PnP function drivers

Mark this to retain the device’s Plug and Play function driver if it is a better
match for the device than the driver in the installation. If you clear this
checkbox, the installation’s plug and play function driver is always installed.
Prompt for missing device

Mark this to prompt the end user to connect a device to the computer if the
device matches this driver and is disconnected.
Create entry under Add/Remove Programs

Mark this to make this driver package removable through Add/Remove
Programs.
Driver Installation Order

This list box displays the .INF file you selected on the Files page and every other
.INF file in the installation that uses DIFxApp for its installation. Use the Move
Up and Move Down buttons to move the .INF file you selected on the Files page.
4. Click OK.
How Self-Registration Information is Captured

When you add a .DLL or .OCX file containing COM self-registration information to an
installation, its registration information is scanned and the appropriate registry keys are
added to the installation. This system of registration is more robust than letting the file
self-register at installation time because it does not depend on the presence of other
files on the destination computer or on how well the .OCX or .DLL file adheres to self-
registration conventions.
How Self-registration Information is Scanned

z When a file is added to an installation, its type libraries are scanned for registration
information and the appropriate registry keys are added to the installation. You can
set options in Wise Options to rescan and update the installation each time you
compile. Additional options determine whether the advertising information is added

to the advertising tables (AppId, Class, Extension, Mime, ProgId, TypeLib, Verb), to
the registry, or both. See Setting General Options on page 39.
z A more powerful scanning method captures information not available in the type
library, such as extensions, keys in hives other than HKEY_CLASSES_ROOT, and
keys in sections other than CLSID, Interface, Mime, Typelib, or ProgIds. To use this
method, do one of the following:
On the Component Details dialog, mark Self-register the key path file
before compile. Each time you compile, files in the component are re-
registered, the registration information is rescanned, and any new information
is added to the installation. See Adding and Editing a Component on page 392.
Use the WiseComCapture.exe utility to extract a file’s registration information to

a .REG file, from which you can import registry keys into the installation. Use
this method to avoid registering the files on your computer. See Using
WiseComCapture.exe.
Using WiseComCapture.exe
To scan a file’s self-registration information and add it to an installation, the file must be
registered on your computer. If you prefer not to register files on your computer, you
can run the scan routine as a stand-alone utility on a different computer. This utility,
WiseComCapture.exe, is in the Wise for Windows Installer application directory. It
extracts the registration information to a .REG file, from which you can import registry
keys into the installation.
1. Copy or install the files to self-register onto a computer other than your build
computer.
2. Copy WiseComCapture.exe to a location you can access from the other computer.
3. Run WiseComCapture.exe from the command line, using the following syntax:
WiseComCapture.exe /r /u Input_COM_Full_pathname Output_REG_pathname
where:
/r self-registers the files before extracting the registry information.
/u self-unregisters the files after the extraction is finished.
Input_COM_Full_pathname is the path to the file or files that should be self-

registered.
Output_REG_pathname is the path and file name of the .REG file to which the
registry information will be extracted. This file must be accessible to anyone
who will be working on the installation.
The files are registered and the registry information is extracted to the .REG file you
specified.
4. On the build computer, do one of the following to import the .REG file:
On the Registry page, import the .REG file you created. This method imports
the information once but does not update it if the file’s registration information
changes. See Importing and Exporting Registry Entries on page 147.
In Setup Editor > Components tab, display the Component Details dialog for the
component containing the file. In Import .REG File, specify the .REG file you
created. Mark Extract advertising information from registry file. See
Adding and Editing a Component on page 392. If you rerun

WiseComCapture.exe whenever the file’s registration information changes, its

registry information will be imported from the .REG file.
Also see How Self-Registration Information is Captured on page 139.
Visual Studio Solution Page

This page is available only if the installation is part of a Visual Studio .NET solution.
The Visual Studio Solution page is similar to the Files page, except that it provides an
alternate view of the files in the Visual Studio solution. The upper-left list box displays a
solution node, similar to the view in Solution Explorer, that represents the projects in
the solution and lists the files that they contain. This is useful when you are working with
a solution that has an extensive folder structure (example: a Web project).
All primary outputs (.EXEs and .DLLs) of the projects in the solution are added to the
Visual Studio Solution page when you create the installation. To add other outputs to the
installation, select them on the Project Outputs page in the project settings. Files you
add to the solution later can also be added automatically. (See Scanning the Solution for
New Files on page 82.) Use the Visual Studio Solution page to organize files into
features, to move a file to a different installation directory, or to change file details.
If an External Files folder appears in the upper-left list box, it contains files that are in
the project but are in a directory that’s outside of the project directory.
If Wise for Windows Installer cannot locate the solution file, the upper-left list box of the
Visual Studio Solution page will be empty.
Working With the Visual Studio Solution Page

z Use the right-click menu to expand or collapse folders, to hide or show empty
folders, and to rename folders.
z Drag and drop folders and files to the page and from Windows Explorer, or use the
following buttons:
Add Contents
Add the contents of a Visual Studio .NET project to the installation. See Adding
Contents of Visual Studio Projects to the Installation on page 142.
Add File
Add files to the installation. See Adding Files to an Installation on page 117.
New
Create directories to be installed on the destination computer. You also can
create directories in Setup Editor; see Creating a Folder in Setup Editor on
page 389.
Delete (lower left)

Remove a directory from the installation.

Details (lower left)

Set NTSF permissions.
Delete (lower right)

Remove a file or operation from the installation.
Details (lower right)

View details on the installation’s files or operations, including attributes, name
and source, permissions, self-registration, and assembly options. See Editing
File Details on page 129.
Also see:

Adding Merge Modules Instead of Files on page 120
Adding Files From the Wise Software Repository on page 121
Adding Files From Outside the Solution on page 123
Editing File Details on page 129
How Self-Registration Information is Captured on page 139
Adding Contents of Visual Studio Projects to the Installation

1. Select Installation Expert > Visual Studio Solution page.
is selected.)
3. In the upper left list box, select a Visual Studio project whose contents you want to
add.
If Wise for Windows Installer cannot locate the solution file, the upper-left list box
will be empty.
4. In the lower left list box, select a directory where you want to add the contents.
The Add Contents dialog appears, listing the files in the selected project.
6. Select one or more files to add and click OK.
The selected files are added to the directory you selected in the lower left list box.
Also see:


Registry Page
Use the Registry page to specify the registry entries to be installed, removed, or edited
on the destination computer. You can either add registry entries manually or import a
registry file (.REG). If you import a Visual Basic .VBR file, it will import the registry
settings, but will not automatically set up for the installation of either a remote
automation or DCOM™ server. You also can export to a registry file.
When you import a registry entry that points to a standard directory, such as Win32 or
Program Files, Wise for Windows Installer replaces the path to the directory with
formatted text in brackets. As a result, the registry entry automatically points to the
correct directory, no matter where it is located. Example: References to c:\Program
Files\ are replaced with [ProgramFilesFolder].
In addition, if the registry key points to a file in the installation, it will be replaced by
[#filekey]. Example: If you have c:\program files\myapp\myapp.exe in your install, and
you add a registry key that refers to that file, its value becomes [#myapp.exe],
assuming myapp.exe is the key to the file in the File table. See Formatted in the
Registry keys
on your Registry values
computer. in the key
selected on the
left.
Registry keys Registry values

to be created to be installed
on the on the
destination destination
computer. computer.
Working With the Registry Page

z Use the right-click menu to expand or collapse directories and to hide or show
empty directories.
z Drag and drop keys and values on the Registry page, or use the following buttons:
Add Keys
Copy a registry key, including all its subkeys and values, from your computer to
the installation.

Add Values
Copy values from your computer to the installation.
Add
Create a new key or import a registry file into the installation.
Delete Key, Delete Value

Remove a registry key or value from the installation.
Details
Edit registry key settings.
Also see:
Adding Registry Keys on page 144

Removing Registry Entries From the Destination Computer on page 145
Importing and Exporting Registry Entries on page 147
Configuring General Registry Settings on page 148
Setting Permissions for Registry Keys on page 149
Viewing Shared Registry Resources on page 150
Special Registry Keys on page 150
Adding Registry Keys

You can use Installation Expert or Setup Editor to add registry keys and values to any
registry folder or subfolder. You also can change settings for selected registry keys and
rename or delete files and folders. However, you cannot rename or delete a root folder.
In Installation Expert, the Registry page displays only the registry keys for the feature in
the Current Feature drop-down list. To display registry keys for all features, mark
View registry keys for all features on Registry page in Wise Options.
In Setup Editor, the Registry icon displays the registry keys and values that are included
in the selected feature or component.
To add an empty registry key:

1. Select Installation Expert > Registry page.
is selected.)
3. In the lower left list box, select the location for the key.
4. Click Add and select Key.
The Registry Details dialog appears.
5. From Operation, select Create empty key.
6. In Key, click at the end of the existing text, and add a backslash and the name of
the new key.
Example: Append \Preferences to the end of the existing key name.
7. Click OK.

To add a registry value in Installation Expert:

is selected.)
3. In the lower left list box, select the key to contain the value you’re adding.
4. Click Add and select Key.
5. Complete the dialog and click OK. For details, see Configuring General Registry
To add a registry value in Setup Editor:

1. Do one of the following in Setup Editor:
On the Features tab, expand a feature and then expand its Combined folder.
On the Components tab, expand a component.
2. Expand the Registry icon.
If the Registry icon does not appear, right-click and select Hide Empty Folders/
Items.
3. To add a new folder, right-click a folder and select New > Folder. Rename the new
folder.
4. Right-click a folder and select New > Registry Key.
5. Complete the dialog and click OK. For details, see Configuring General Registry
The registry value is added to the selected feature or component and appears in the
upper right pane. To edit it, double-click its name. To delete it, use the right-click menu.
Removing Registry Entries From the Destination Computer

You can specify registry keys and values to be removed from the destination computer
during installation. This operation affects registry entries that are already on the
destination computer, not registry entries that are part of the installation.
In Installation Expert, the Registry page displays only the registry keys for the feature in
the Current Feature drop-down list. To display registry keys for all features, mark
View registry keys for all features on Registry page in Wise Options.
Caution
Be very careful when removing registry entries from the destination computer. Do not
remove registry entries unless you are sure that they are not used by another
application.

To add a remove registry operation in Installation Expert:

is selected.)
3. Add the registry key and value to the installation. See Adding Registry Keys on
page 144.
4. In the lower left list box, select the key that contains the value to remove.
5. In the lower right list box, double-click the value to remove.
7. From Operation, select Remove value during install.
8. Click OK.
A red exclamation point appears over the icon of the registry value you selected to
indicate that this value will be removed during installation.
To add a remove registry operation in Setup Editor:

1. Do one of the following in Setup Editor:
On the Features tab, expand a feature and then expand its Combined folder.
On the Components tab, expand a component.
2. Expand the Remove Registry icon.
If the Remove Registry icon does not appear, right-click and select Hide Empty
Folders/Items.
3. Right-click a folder and select New > Remove Registry.
The Remove Registry Details dialog appears.
Root
The top-level key from which the key will be removed. Example:
HKEY_CURRENT_USER.
Key
The name of the key to remove. To create an entire key path, separate key
names with backslashes (\). Example: NewDocument\Protocol\StdFileEditing.
Value Name
The value to remove. You can enter a formatted text string. For information
about formatted text strings, see Formatted and Registry Table in the Windows
Installer SDK Help.
5. Click OK.
The remove registry operation appears in the upper right pane. To edit it, double-click
its name. To delete it, use the right-click menu.
To remove multiple registry keys from the destination computer:


is selected.)
3. Add the registry keys and values to the installation. See Adding Registry Keys on
page 144.
4. In the lower left list box, right-click the key that contains the subkeys and values to
remove, and select Remove all subkeys and values on install.
A red exclamation point appears over the folder icon of the registry key you selected to
indicate that all the subkeys and values of this registry key will be removed during
installation.
Importing and Exporting Registry Entries

You can import registry files (.REG) into an installation. You also can export registry key
settings from an installation to a .REG file. RegEdit 4.0 and 5.0 formats are supported
for importing; RegEdit 4.0 formats are supported for exporting.
To import a registry file:

Select Installation Expert > Registry page.

Click Add at the lower left of the Registry page and select Import.
In Setup Editor, on the Components or Features tab, right-click the Registry

icon or a registry folder and select Import from .REG File.
2. In the dialog that appears, specify a .REG file and click Open.
The contents of the selected registry file, along with all corresponding folders, are placed
in the appropriate root folder.
To export to a registry file:

Select Installation Expert > Registry page.

In the lower left list box, right-click the key to export, and select Export to .REG
File. To export all keys that you’ve designated for the destination computer,
right-click the Destination Computer icon.
In Setup Editor, on the Components or Features tab, right-click the Registry

icon or a registry folder and select Export to .REG File.
The Export to .REG File dialog appears.
2. In File Name, specify the pathname of the registry file you are creating.
3. In Export As, select the version of RegEdit that the registry file should be
compatible with.

Registration File (*.REG)

Export to a Unicode file format.
Win9x/NT 4 Registration File (*.REG)

Export to a flat text file format.
4. Click OK.
The .REG file is saved in the location you specified. If the registry key you exported had
a property name surrounded by brackets, and that property is defined in the Property
table in the Windows Installer database, then the bracketed property name is replaced
with the local computer value of the property in the exported .REG file.
Configuring General Registry Settings

Use the General tab on the Registry Details dialog to set or edit the general registry key
settings.
In Installation Expert > Registry page, click Add > Key.
Double-click a registry value on the Registry page in Installation Expert or on

the Components or Features tab in SetUp Editor.
Operation
Specify what operation will be applied to the key and its associated value.
Create/update key and value

If the value exists, it is updated. If the key or value does not exist, it is
created.
Create empty key

An empty key is created. It is populated with a +.
Remove subkeys for uninstall

During uninstall, all subkeys of this key are removed.
Create empty key and remove subkeys for uninstall

During uninstall, all subkeys of this key and all named values of the key
itself are removed.
Remove value during install

This value is removed from the registry key. On the Registry page, a red
exclamation point appears over the icon of the registry value you selected.
This option appears only when you access the Registry Details dialog from
the Registry page.
Root
The top-level key in which the new key will be added. (Example:
HKEY_CURRENT_USER.) This is enabled only when you access the Registry
Details dialog from the Add button on the Registry page.
Key
The name of the new key. Create an entire key path by separating key names
with backslashes (\). (Example: Entering NewDocument\Protocol\StdFileEditing
creates the StdFileEditing key inside the Protocol key, which is created inside

the NewDocument key.) Any keys in the path that do not already exist on the
destination computer are created. This is enabled only when you access the
Registry Details dialog from the Add button on the Registry page.
Value Name
The name of a new named value. You can enter a formatted text string. For
information about formatted text strings, see Formatted and Registry Table in
Data Value
The data for the value. You can enter a formatted text string. (Example: To
return the directory that contains MyApp.exe, enter a value of [$component],
where component is MyApp.exe; to return the directory and the file name, enter
a value of [#MyApp.exe].) For information about formatted text strings, see
Formatted and Registry Table in the Windows Installer SDK Help.
Data Type
Select the type of data contained in the named value. The associated Windows
API data types are in parentheses below.
String
A piece of alphanumeric text. You can enter properties by enclosing the
property name in square brackets. (REG_SZ)
Unexpanded string
Variable names, such as %WIN%, are not expanded, allowing Windows NT
system variables to be embedded. (REG_EXPAND_SZ)
Double word
A 32-bit value in decimal notation. (REG_DWORD)
Binary / Hex
A series of bytes in hexadecimal notation. The bytes should be entered
without separating spaces or commas. (REG_BINARY) Example:
AD30C0A94020A8FC4C0008.
4. Click OK.
Setting Permissions for Registry Keys

Use the Permissions tab on the Registry Details dialog to set permissions to protect your
application’s registries against accidental deletion or changes. Also see Configuring
General Registry Settings on page 148.
Note
These permissions require an NTFS partition and therefore work only under Windows
NT, 2000, XP, and Server 2003.
The permissions you set are applied to the domain and user you specify, so you can set
different permissions for the same registry key for different users. Set permissions only
if you know your users and their domains. Example: If you are a system administrator
and want to set permissions for registry keys in an .MSI as appropriate for your
network.
To add permissions for a domain and user:

In Installation Expert > Registry page, click Add > Key.

Double-click a registry value on the Registry page in Installation Expert or on

the Components or Features tab in SetUp Editor.
2. Click the Permissions tab and click Add.
3. Enter the Domain and User name and click OK.
4. The domain and user names appear in the upper list box, and the list of permissions
is enabled.
5. To set permissions, mark the checkboxes.
You can add multiple users.
Viewing Shared Registry Resources

The Shared Resources tab on the Registry Details dialog displays all packages in the
Software Manager database that use a specific registry key and value. This lets you
ensure that the registry keys that are set by your current application will not conflict
with keys set by other packages. If you are connected to the Software Manager
database used with your organization’s installation of Wise Package Studio, you can see
registry keys that are set by packages that have already been deployed.
You also can view shared registry resources in a report format. See Generating Shared
Resource Reports on page 33.
In order to view shared resources, you must be connected to a Software Manager

database data source. For information on the Software Manager database, see About the
Software Manager Database in the Software Manager Help.
To view shared registry resources:

1. Double-click a registry value on the Registry page in Installation Expert or on the
Components or Features tab in Setup Editor.
2. Click the Shared Resources tab.
Also see Registry Page on page 143.
Special Registry Keys

In addition to the standard top-level registry keys, a special registry key named
HKEY_USER_SELECTABLE is provided. Depending on the operating system, during
installation an end user can install an application for the current user only or for all the
users of the computer. Registry changes under this key are made to either
HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE, based on the end user’s choice
Windows Installer itself also provides registry keys with special functionality. (Example:
You can install a key named AlwaysInstallElevated to force Windows Installer
installations to always install with elevated privileges.) For a list of these special keys,
see User Policies and Machine Policies in the Windows Installer SDK Help.

INI Files Page

Use the INI Files page to:
z Update the contents of an existing .INI file, such as System.ini.
z Create an .INI file and write installation properties to it.
You cannot use this page to delete part or all of an .INI file.
The left list box on this page represents the directory tree of the destination computer,
and the right list box contains .INI entries you add to the installation. Use the right-click
menu to expand or collapse folders and to hide or show empty folders.
Note
To see the same directory structure that exists on the Files page, mark the View
Tips for Creating and Editing .INI Files

z After you create an .INI file, you cannot edit its name. You must delete the .INI
entry and create a new one.
z When you edit an existing .INI file, new .INI file settings are merged into the
existing settings. If you enter a section name that already exists, its new parameter
assignment lines are added to the existing section. If a section and its variable
already exist, the variable’s value is overwritten.
z You can use formatted text strings to resolve special substrings in the Section,
Key, or Value fields in the INI File table, entering the formatted text directly on the
INI File Details dialog. You also can edit the IniFile table in Setup Editor. For
information on formatted text strings, see Formatted in the Windows Installer SDK
Help. For information on editing tables, see Editing Existing Tables on page 400.
Creating and Editing .INI Files

Note
When you change an .INI file and then view its contents, the lines within the changed
section might not be in the same order as before the change. This is not a problem
because the entries in an .INI file are not order dependent.
From Installation Expert:

1. Select INI Files page.
is selected.)
3. To create a new folder for the INI file, click New Folder, enter a folder name, and
click OK.
4. In the left pane, select a folder and click New File.
The INI File Details dialog appears.

5. Complete the dialog; see below.
6. Click OK.
The INI File entry appears in the right list box. To edit it, double-click its name. To
delete it, use the right-click menu.
From Setup Editor:
7. On the Components or Features tab, expand a component or feature.
8. To create a new folder for the INI file, right-click the INI Files icon or one of its
subfolders and select New > Folder. Rename the folder.
9. Right-click a folder and select New > INI File.
Note
Add the .INI file immediately after creating the folder, because if you create the
folder, but fail to put an .INI file entry inside it, the folder is deleted from the
installation the next time you save it.
The INI File Details dialog appears.
10. Complete the dialog; see below.
11. Click OK.
The INI File entry is added to the selected feature or component and appears in the
upper right pane. To edit it, double-click its name. To delete it, use the right-click menu.
Completing the INI File Details dialog:

z INI Filename
Enter a name for the new .INI file, or click Import to import an existing .INI file. This
file will be created on the destination computer, if it does not already exist. If it
exists, the .INI contents you enter will be used to edit the existing .INI file.
Note
Because Windows Installer does not support writing comments to .INI files,
comments are removed from .INI files you import.
z INI Settings
Enter the information to add or change in the .INI file. The text must be in the
correct syntax. Section names must be in brackets and contents must be in the
form variable=value. Example:
[SECTIONNAME]
Color=Red
You can enter Windows Installer property names (surrounded by brackets) for both
the variable and value. Example: To set a variable named MyAppLocation to the
installation directory and add it to the APPLICATIONPATH section, enter:
[APPLICATIONPATH]
MyAppLocation=[PRIMARYFOLDER]
Shortcuts Page
The Shortcuts page lets you add, edit, and delete shortcuts for files in the installation,
and add icons for shortcuts you will install. You also can create a shortcut for a file on

the destination computer that’s not in the installation. Shortcuts for files that have
associated shortcuts are created automatically if you select one of the scan advertising
options from the Advertising Setting drop-down list in Wise Options.
(Visual Studio integrated editor only.) If the installation is part of a Visual Studio .NET
solution, an advertised shortcut for the application is created by default. The Project
Outputs page in the project settings contains an option that lets you specify not to
create a shortcut automatically. See Entering Project Settings on page 77.
Adding a Shortcut to an Installation

Select Installation Expert > Shortcuts page.

Click Add at the right of the Shortcuts page.

feature and select New > Shortcut.
The Shortcut Type dialog appears.
File in the installation

Mark this to have the shortcut open a file in the installation.
Advertised
This is marked by default, which means this shortcut appears on the destination
computer regardless of whether its target is installed or advertised. When the
end user opens an advertised shortcut, installation of the target .EXE file is
initiated. If you clear this checkbox, the shortcut appears only if its target is
installed, but not if its target is advertised.
Note
If you designate a shortcut as advertised, and the shortcut’s target gets
deleted, selecting that shortcut initiates self-repair. Self-repair is not initiated
for non-advertised shortcuts.
Command Line
Mark this to have the shortcut execute a command line statement. Use this
option to open a file that’s not part of the installation, but only if you’re sure the
file exists on the destination computer.
Command Line
Enter the entire command line statement, including arguments and other
command line options; see Arguments in Editing a Shortcut Configuration
on page 154. Enclose the statement in quotation marks if it contains spaces.
Shortcut Name
Enter a name for the shortcut.
3. Click Next.

If you created a shortcut for a file in the installation, the Shortcut File Selection
dialog appears.
4. Select the installation file to create a shortcut for and click Next.
Note
Files added under the Duplicate Files icon in the Features or Components tabs of
Setup Editor do not appear because you cannot add shortcuts for duplicate files.
The Shortcut Destination Directory dialog appears.
5. Specify a directory to contain the shortcut.
The predefined directories on this dialog represent standard system directories on

the destination computer, regardless of their actual names. The most common
location for application shortcuts is the Start menu’s Programs directory, which is
selected by default. To put the shortcut in a new directory, click New Folder to
create it.
6. Click Finish.
The Shortcut Details dialog appears, where you can specify further details for the
shortcut. See Editing a Shortcut Configuration on page 154. When the end user
installs your application, this shortcut will appear in the location you specified.
The shortcut appears. To edit it, double-click its name. To delete it, use the right-click
menu.
Editing a Shortcut Configuration

Select Installation Expert > Shortcuts page.

Double-click the shortcut.
In Setup Editor, on the Components or Features tab, expand the component or

feature that contains the shortcut. Click the Shortcuts icon and double-click the
shortcut in the upper right pane.
If the Shortcuts icon does not appear, right-click and select Hide Empty Folders/
Items.
The Shortcut Details dialog appears.
Name
The name of the shortcut. If the name is longer than 8.3 characters, the short
(8.3) file name appears first, followed by a pipe character (|) and the long
(Windows 95) file name.
Target File
(Read-only.) This contains the file name of the target of this file. You specified
this file when you created this shortcut. To create a shortcut to a different file,
delete this shortcut entry and create a new one. If you created a command line
shortcut, this field is replaced by the Command Line field.

Command Line
This appears only if you created a command line shortcut. It contains the
command line statement.
Dest. Directory
This lists all pre-defined directories and directories you’ve created. Select the
location for the shortcut on the destination computer, or click New Folder to
create a new directory.
Arguments
Enter command line arguments to append to the command line statement that
is executed to launch the target of this shortcut. You can enter property names
surrounded by brackets to specify standard directories. (Example: To specify a
file named Notes.txt in the Windows directory, enter
[WindowsFolder]Notes.txt.) For a list of predefined directories, see System
Folder Properties in the Windows Installer SDK Help.
Description
Enter a one-line description of the shortcut, which appears when an end user
right-clicks on a shortcut file in Windows Explorer and selects Properties.
Working Directory
Select the directory that should be current when the target of this shortcut is
launched.
Show Window
Select whether the target file opens in a normal, minimized, or maximized
window.
Advertised
Mark this to have the shortcut appear on the destination computer regardless of
whether its target is installed or advertised. When the end user opens an
advertised shortcut, installation of the target .EXE file is initiated. If you clear
this checkbox, the shortcut appears only if its target is installed, but not if its
target is advertised. You can select a new feature or icon only if this checkbox is
marked.
Feature
To associate this feature with a different shortcut, select the feature. Because
non-advertised shortcuts cannot be associated with a feature, this field is
enabled for advertised shortcuts only.
3. To select a new icon, click New Icon and specify the icon.
4. Click OK.
Adding an Environment Variable

You can add, edit, and delete environment variables and values to be set by the
operating system on the destination computer. You can add environment variables from
Installation Expert or Setup Editor.
Select Installation Expert > Environment Variables page.


Click Add at the right of the page.

feature and select New > Environment Variable.
The Environment Variable Details dialog appears.
Name
Enter a name for the environment variable.
Value
Enter a value for the environment variable.
Note
To read the value of an existing environment variable into a property, use the
Set Property type of custom action to read it into a property. Enter
[%ENVIRONMENT_VARIABLE_NAME] in the Property Value field on the
Details tab of the Set Property dialog while making the action (brackets
required).
Operation
Specify how to handle the variable during installation and uninstallation.
Replacement
Specify how to handle an existing value for the variable.
Windows NT based system environment variable

Mark this if this is a Windows NT, 2000, XP, or Server 2003 system environment
variable.
3. Click OK.
The environment variable is added. To edit it, double-click its name. To delete it, use the
right-click menu.
Adding File Associations

You can associate file extensions with executables to determine which application to
launch when the end user double-clicks a file with a certain extension. You can associate
file extensions with any executable file in an installation. File associations are a type of
advertising and are stored in the registry.
To add a file association:

Select Installation Expert > File Associations page.

Click Add at the right of the page and select New.


feature and select New > File Association.
The File Association Details dialog appears.
2. On the Extension Details tab, select the executable to use for the extension, type an
extension, and enter the program ID for the executable. For details, see
Determining Extension Settings on page 157.
3. (Optional.) On the Command Verbs tab, click Add, and on the Verb Details dialog
that appears, set the actions that will be available when the end user right-clicks an
executable with this extension in Windows Explorer. For details, see Adding
Command Verbs on page 158.
4. (Optional.) On the MIME Types tab, mark Show All and mark checkboxes to select
the MIME types to associate with this extension. For details, see Selecting MIME
Types on page 158.
5. Click OK.
The file association appears. To edit it, double-click its name. To delete it, use the right-
click menu.
In Setup Editor, a new branch of folders is created under the Advertising icon to show
the application folder, the Extensions folder, and the ProgId folder.
To import a file association:

1. Select Installation Expert > File Associations page.
is selected.)
3. Click Add at the right of the File Associations page and select Import.
The Import File Association dialog appears.
4. Click Browse to select the executable to use for the extension. You can only select
executables that you’ve already added to the installation.
5. From Extension, select the extension to use. This list shows all available extensions
on your computer.
6. Click OK.
All relevant information for the extension you select is imported into the Extension
Details, Command Verbs, and MIME Types tabs. To edit those tabs, double-click the file
association name.
Also see Advertising Icon on page 388.
Determining Extension Settings

Use the Extension Details tab to determine file association settings.
1. Click the Extension Details tab on the File Associations Details dialog. See Adding
File Associations on page 156.

Executable File
Specify the executable to use for the extension. You can only select an
executable that is in the installation.
Extension
Enter an extension. Do not include the period.
ProgID
Enter or select the program ID for the executable. This list contains the ProgIDs
defined in this installation and the ProgIDs detected for the executable you
specified above.
Description
Enter the type of file. The end user sees this description on the Properties dialog
for files of this type.
Icon
Click Change Icon and specify an icon. This icon will be displayed on files of this
type on the destination computer.
Note
The Description and Icon fields are associated with the ProgID, not the extension.
If no ProgID is specified, those fields are disabled.
3. Click OK.
Adding Command Verbs

Use the Command Verbs tab to determine which actions are available when the end user
right-clicks a file with your file association in Windows Explorer. The actions appear in
the end user’s right-click menu in the same order that you set here.
1. Click the Command Verbs tab on the File Associations Details dialog. See Adding File
Associations on page 156.
2. Click Add to add a new action or double-click an action.
The Verb Details dialog appears.
Verb
Enter or select the action to be performed when the end user selects the
corresponding command from the right-click menu.
Command
Enter the command as it should appear on the right-click menu. This entry is
added to the text strings on the Languages page and can be localized. See
Translating an Installation on page 258.
Argument
Enter command line options that will be passed to the executable file when the
action is performed. The default (%1) is a Windows variable that holds the
pathname of the file that was opened.
4. Click OK.
Selecting MIME Types

Use the MIME Types tab to select the MIME types to associate with your extension.

1. Click the MIME Types tab on the File Associations Details dialog. See Adding File
Associations on page 156.
Show All
Mark this to display all available MIME types on your computer. To associate a
MIME type with an extension, click its checkbox. If you are an experienced
Windows Installer developer, you can add MIME types using the MIME table in
Setup Editor.
Show Associated
Mark this to display the MIME types currently associated with the selected file
extension. To disassociate a MIME type, clear its checkbox.
3. Click OK.
Services Page
Use the Services page to define applications to be installed as a service under Windows
NT, 2000, XP, or Server 2003. You also can start, stop, and delete services that are
installed on the destination computer. For information on coding an application to run as
a service, consult Microsoft developer documentation.
Application files that can be installed as a service are: .EXE, .VXD, .SYS, or .386.
Adding a Service to the Destination Computer

You can add a service to an installation from Installation Expert or Setup Editor.
1. Select Installation Expert > Files page.
is selected.)
3. Add the file that runs the service. Application files that can be installed as a service
are: .EXE, .VXD, .SYS, or .386.
Select Installation Expert > Services page.

From Current Feature, select a feature or condition.
Click Add at the right of the page and select Create Service.
On the Features or Components tab in Setup Editor, right-click a feature or

component and select New > Service.
The Select File dialog appears, which displays only the files that are associated with
the currently-selected feature. The left list box displays the directory structure of
the installation, and the right list box displays files in the selected directory.
5. Select a file in the right list box and click OK.
The Create Service Details dialog appears.

The options you set on the Create Service Details dialog are dependent on how you
coded your service. Some of the options correspond to options in the Services
control panel (Windows NT 4.0) or the Services application (Windows 2000, XP, and
Server 2003). For details, see ServiceInstall Table in the Windows Installer SDK
Help.
Service Name
Enter the name of the service. This name is used internally by the service to
register itself properly in the registry, so this value must match the internal
name of the service that’s stored within the application file. You can see the
internal name in Windows Task Manager or the SCList Windows utility.
Display Name
The name that appears in the Services control panel on Windows NT 4.0 or the
Services application on Windows 2000, XP, and Server 2003.
Description
Enter a description for the service. This appears only in the Windows 2000
Services application.
Executable
Displays the file you selected on the Select File dialog, which runs the service.
Arguments
Enter any arguments to be passed to the service on the command line at
startup.
Login Username, Password

Enter the Windows NT or Windows 2000/XP/Server 2003 account information
for the account the service is to run under. Example: .\Username or
Domain\Username.
Load Order Group

Enter the group that this service will be a part of. Groups are loaded
alphabetically at startup.
Dependencies
Enter the names of any other services that must be running before this service
can start.
Error Control
Specify what happens if an error is reported while starting the service.
Ignore Error
Logs the error in an error log and continues.
Normal Error
Displays a message to the end user and logs the error in an error log.
Critical Error
Reboots the system and sets it to the last known good menu.
Service that runs in its own process

Mark this if the service runs as its own process.
Service that shares a process with others

Mark this if the service runs as a shared process, such as a kernel driver or file
system driver.
Automatic
Mark this to have the service always start when the destination computer is
started.

Manual
Mark this to have the service enabled but not automatically started. If this
option is marked, the end user can start the process manually using the
Services control panel or Services application.
Service interacts with desktop

Mark this to have the service display UI (examples: an application window, an
item on the taskbar, and so on) to the end user while it is running.
7. Click OK.
The service appears. To edit it, double-click its name. To delete it, use the right-click
menu.
To start, stop, and delete services on the destination computer, see Controlling Services
on the Destination Computer.
Controlling Services on the Destination Computer

You can start, stop, and delete services that are in the installation or services that are
already installed on the destination computer.
To add a service to the installation, see Adding a Service to the Destination Computer on
page 159.
Select Installation Expert > Services page.

If the service is not in this installation, select a feature with which to associate
the control service action.
Click Add at the right of the page and select Service Control.
On the Features or Components tab in Setup Editor, right-click a feature or

component and select New > Service Control.
The Service Control Details dialog appears.
Service Name
Select a service contained in the currently-selected feature, or enter the name
of a service you expect to be installed on the destination computer. This name is
used internally by the service to register itself properly in the registry, so this
value must match the internal name of the service that’s stored within the
application file.
Arguments
Enter any arguments to be passed to the service on the command line at
startup.
Install Action
Mark the actions to perform on the service when your application is installed.

Uninstall Action
Mark the actions to perform on the service when your application is uninstalled.
Wait for service action to complete before continuing

Mark this if the installation should wait until the actions specified above finish
before continuing with installation.
3. Click OK.
The service control item appears. To edit it, double-click its name. To delete it, use the
right-click menu.
Note
To both stop and delete a service, do not mark both the Stop Service and Delete
Service checkboxes in the same control service action; instead, create two control
service actions. On the first control service action, mark Stop Service and Wait for
service action to complete before continuing. On the second control service action,
mark Delete Service. This ensures that the service is completely stopped before the
installation attempts to remove it.
Adding an ODBC Item

You can use Installation Expert or Setup Editor to define the ODBC (Open Data Base
Connectivity) data sources, drivers, and translators to include in an installation. For
information about ODBC, consult technical documentation provided by Microsoft.
Select Installation Expert > ODBC page.
Items that you add to a feature are installed on the destination computer
only if the feature is installed. Items that you add to a condition are installed
only if the feature is installed and the condition is true.
Click Add at the right of the ODBC page and select Driver, Data Source, or
Translator.
On the Features or Components tab, right-click a feature or component, select

New, and select ODBC Source, ODBC Driver, or ODBC Translator.
The corresponding dialog appears.
2. Complete the dialog and click OK. For details, see:
Setting ODBC Data Source Details on page 162
Setting ODBC Driver Details on page 163
Setting ODBC Translator Details on page 163.
The ODBC entry appears. To edit it, double-click its name. To delete it, use the right-
click menu.
Setting ODBC Data Source Details

1. Access the ODBC Data Source Details dialog. See Adding an ODBC Item on
page 162.

Data Source Name

Enter a name for the data source, or click Import to import data source
information from a saved data source file. If you click Import, the Select Data
Source dialog appears, which displays a list of ODBC data sources that are
currently registered on your computer.
Driver
Enter the driver name that will be used to access this data source. If you don’t
know the exact spelling of the driver name, click Import to import the data
source.
Register Per Machine, Register Per User

Mark Register Per Machine to give all users on the destination computer
access to the data source, or mark Register Per User to give only the user
who installs the application access to the data source.
Source Attributes
Enter attributes for the data source, one per line, in keyword=value format.
Press Ctrl+Enter to move to the next line.
3. Click OK.
Setting ODBC Driver Details

1. Access the ODBC Driver Details dialog. See Adding an ODBC Item on page 162.
Driver Name
Enter a name for the driver, or click Import to import driver information from a
saved driver file. If you click Import, the Select ODBC Driver dialog appears,
which displays a list of ODBC drivers that are currently installed on your
computer.
Driver .DLL
Specify the path to the .DLL used for this driver.
Setup .DLL
Specify the path to the .DLL used to configure this driver.
Driver Attributes
Enter attributes for the driver, one per line, in keyword=value format. Press
Ctrl+Enter to move to the next line.
3. Click OK.
Setting ODBC Translator Details

1. Access the ODBC Translator Details dialog. See Adding an ODBC Item on page 162.
Description
Enter a description of the translator, or click Import to import an existing
translator. If you click Import, the Select ODBC Driver dialog appears, which
displays a list of ODBC translators that are currently installed on your computer.
Translator File
Specify the file that contains the translator.

Setup File
Specify the file that contains configuration data for the selected translator.
3. Click OK.
Adding to the Windows Firewall Exception List

The Windows Firewall that is included with Windows XP SP2, Windows Server 2003 SP1,
and later, controls which applications and ports on the destination computer can accept
incoming traffic from the Internet or a network. When Windows Firewall detects
incoming traffic, it blocks the connection and prompts the end user to block or allow the
connection. If the end user allows the connection, the application or port is added to the
Windows Firewall exception list, so that future connections to that application or port are
not blocked.
On the Firewall Exceptions page, you can specify application files and ports to be added
to the Windows Firewall exception list during installation. This adds custom actions to
the installation, which add the exceptions to the Windows Firewall exception list. When
your application is installed, it can accept incoming traffic and open required ports on
the destination computer without end user intervention. This is useful for games and
other similar applications.
If your installation contains an exception that is already in the Windows Firewall

exception list on the destination computer, it will not overwrite that existing exception.
Also, only exceptions that are installed with your application are removed when your
application is uninstalled.
Example: Your installation installs a multi-player network game, which requires multiple
users to communicate with each other over the Internet. On computers that use
Windows Firewall, end users are prompted the first time another player tries to
communicate with them. If you add the port that the game uses to the Windows Firewall
exception list, then the game communication can occur without prompting the end
users.
Operating System Notes

The ability to add Windows Firewall exceptions to an installation is not restricted by the
operating system that is running on your build computer. The operating system on the
destination computer determines whether the exceptions are implemented.
z When the destination computer is running Windows XP SP2, Windows Server 2003
SP1, or later, the exceptions are added to the Windows Firewall exceptions list.
z When the destination computer is running an operating system that does not have
Windows Firewall, the installation runs normally and the Windows Firewall
exceptions are ignored.
To add to the Windows Firewall exception list:

1. Select Installation Expert > Firewall Exceptions page.
is selected.)
feature is installed.
3. Click Add at the right of the Firewall Exceptions page.

The Exception Type dialog appears.
4. Specify the type of exception to add:
Application file. Do this to allow traffic to this specific file through any port. Go
to step 5.
Port. Do this to allow traffic from any application through this specific port. Go
to step 6.
5. To add an application file:
a. On the Exception Type dialog, mark Application and click Next.
The Application Selection dialog appears and displays files in the installation
with the following extensions: .EXE, .COM, or .ICD.
b. Select a file. A file can appear in the exception list only once.
The Friendly Name defaults to the file name. You can edit this information.
c. Click Finish.
6. To add a port:
a. On the Exception Type dialog, mark Port.
b. In Friendly Name, enter a descriptive name for the port.
c. In Port Number, enter the number of the port to open.
d. Mark TCP or UDP to specify the communications protocol.
A combination of port number and protocol type can appear in the exception list
only once.
e. Click Finish.
The exception appears. To edit it, double-click its name. To delete it, use the right-click
menu.
When you edit an application exception, you can only change the Friendly Name. When
you edit a port exception, you can change the Friendly Name, the Port Number, and
the protocol type.
When a file that is specified in an exception is deleted from the installation, the
exception entry and the associated custom actions are removed also.

Chapter 7
Your Installation on the Destination Computer
The Target System and User Interface page groups in Installation Expert, along with the
Launch Conditions icon in Setup Editor > Product tab, let you determine how the
installation behaves on the destination computer.
Topics include:
z About System Requirements (setting minimum system requirements).
z Performing a System Search (searching the destination computer for specific

items).
z Setting Features for Installation Types (determining which features are installed
when the end user selects a specific installation type).
For information on selecting and editing the dialogs that appear during installation, see
Working With Dialogs on page 427.
About System Requirements

You can define system requirements for an installation in 2 different areas of Wise for
Windows Installer:
z System Requirements page

You can use a point-and-click interface to set requirements for the operating
system, the Internet Explorer version, and screen attributes. You can specify
minimum hardware and software requirements for the installation and set warning
messages that display to the end user if the destination computer does not meet
specified requirements. See Setting a Requirement on the System Requirements
Page.
z Launch Conditions icon

This is in Setup Editor > Product tab. It lets you build complex conditions using
Windows Installer runtime properties that test aspects of the destination computer.
See Setting a Requirement by Creating a Launch Condition on page 168
Setting a Requirement on the System Requirements Page

This procedure applies to any system requirement that you set on the System
Requirements page. Notes on specific system requirements follow the procedure.
1. Select Installation Expert > System Requirements page.
2. Double-click a requirement.
The Minimum System Requirements dialog appears.
3. From the drop-down list at the top of the dialog, select a requirement.
Requirements that begin with “All” or “Do not check” indicate that this requirement
is not checked. Any requirement you select includes not only the requirement but
also any greater value. Example: Selecting a Windows version of Windows 98 lets

an installation run on any computer with Windows 98 or any later versions of the
same operating system.
4. In Message Text, enter the error message that appears if the destination computer
doesn’t meet the system requirement. It should communicate to the user why the
installation cannot run.
5. Click OK.
Windows Version
The requirements you set for the Windows version apply only if the destination
computer is running one of the following operating systems:
Windows 95
Window 98
Windows Me
If the destination computer is running a version of Windows NT, the minimum system
requirements specified under the Windows NT Version item are checked instead.
Windows NT Version
The requirements you set for the Windows NT version apply only if the destination
computer is running one of the following operating systems:
Windows NT 4.0
Window 2000
Windows XP
Windows Server 2003
If the destination computer is running Windows 95, Windows 98, or Windows Me, the
minimum system requirements specified under the Windows Version item are checked
instead.
Screen Resolution
The minimum required screen resolution.
Screen Colors
The minimum required screen depth. 24 Million Colors corresponds to True Color in
the Display Control Panel.
Internet Explorer Version

The minimum required version of Microsoft Internet Explorer.
Windows Installer Runtime Version

Rather than have the installation fail if the destination computer lacks the required
version of Windows Installer, you can set the installation to pre-install a later version of
Windows Installer. Use the Prerequisites page to pre-install Windows Installer; see
Adding Prerequisites to a Release on page 186.
SQL Server Version

This option is useful if you have set up this installation to configure a Microsoft SQL
Server on the SQL Server Scripts page. By default, this value is not checked. See
Configuring a Microsoft SQL Server During Installation on page 234.

.NET Framework Version

This verifies the version of the Microsoft .NET Framework.
IIS Version
This option is useful if you have set up this installation to configure a Microsoft Internet
Information Services (IIS) server. By default, this value is not checked. Also see About
Web Installations on page 222.
If you set an IIS Version, then an additional list of requirements appears, which are
settings available in IIS 4.0 and later. These requirements match those that are in
Internet Services Manager under the Web Service Extensions folder icon. You can
double-click any of these requirements to check its state as set on the destination IIS
Web server.
Also see:
Importing .NET Framework Security Settings on page 238

About Microsoft .NET Technology on page 524
Requirements for Creating a .NET Installation on page 527
Setting a Requirement by Creating a Launch Condition

You can use launch conditions to check system requirements on the destination
computer. (Example: The value of properties or environment variables.) Windows
Installer defines several properties at runtime that are useful for defining conditions.
See Hardware Properties and Operating System Properties in the Windows Installer SDK
Help.
To set basic requirements, use the System Requirements page; see Setting a
Requirement on the System Requirements Page on page 166. To create new launch
conditions and edit existing ones, use the Launch Conditions icon in Setup Editor >
Product tab.
To create a new launch condition:

1. In Setup Editor > Product tab, right-click the Launch Condition icon and select New
> Launch Condition.
The Launch Condition Details dialog appears.
Condition
Enter the new condition or click Build to create a condition in Condition Builder.
See Creating Conditions With Condition Builder on page 411.
Message Text
Enter the error message that appears if the destination computer doesn’t meet
the condition. It should communicate to the end user why the installation
cannot run.
3. Click OK.
The new condition appears in the list in the upper right pane.

Note
If the launch condition depends on a system search, move the AppSearch action so that
it precedes the LaunchCondtions action in the User Interface sequence. For silent
installations, also move the AppSearch action in the Execute Immediate sequence. See
About Installation Sequences on page 470.
To edit or delete an existing launch condition:

In Setup Editor > Product tab, select the Launch Condition icon to display current launch
conditions in the upper right pane.
z To edit a launch condition, double-click it.
z To delete a launch condition, select it and press Delete.
Performing a System Search

Use the System Search page to search the destination computer:
z To find a previous version of your application that wasn’t installed using Windows
Installer technology.
z To find any files, directories, .INI files, registry entries, or components of a previous
version of your application. You can specify the items to search for and then code
the installation so the new version is placed in the same location as the previous
one, rather than in a default location.
z To look for a specific third-party application. Example: You might want to include a
feature in your application that is only installed if a certain application is already
installed on the destination computer.
At runtime, the installation searches for the items indicated on the System Search page
and places the results in properties you specify. There is no order to the search,
therefore you can’t make one entry depend on another.
See:
Searching For Files or Directories on page 169

Searching For Items in .INI Files on page 171
Searching For a Registry Value on page 173
Searching For a Previously-Installed Component on page 174
For information on searching for previous versions, see Searching for Existing
Applications, Files, Registry Entries, or .ini File Entries in the Windows Installer SDK
Help. You can get the product code GUID of the previous installation by filling in the
Action Property field on the Upgrade dialog. See Creating an Upgrade on page 311.
Searching For Files or Directories

On the System Search page, you can set up a search for a file or directory on the
destination computer. To find a directory, you must search for a specific file contained
inside the directory. When you search for a file, Windows Installer stops searching as
soon as it finds the first file or directory that matches your specification. Therefore, it’s
important that you specify unique file or directory attributes for your search. You can
specify to return either the full file path or just the directory that contains the file.
1. Select Installation Expert > System Search page.

2. Click Add at the right of the page and select File or Directory.
The Search for File dialog appears.
Property
Specify a property name. It will hold the result of the search, which is a file
name or directory path. If you’ve already defined a new public property (all
uppercase) in the Properties icon on the Product tab, then you can select it from
the list; otherwise enter a new property name (all uppercase). If you enter a
new property name, and the search fails to find a match, the property value will
be null and will be false if used in a condition.
Operation
Select the type of entry for the property:
Search all fixed drives for a file

Searches all permanent attached drives for the file. You determine how
many levels down the search is performed by entering a search depth. This
operation returns the entire pathname to the file. Example: C:\Program
Files\Application\Application.exe.
Search for file: return full file name

Searches a specific directory for a file, and returns a full pathname.
(Example: C:\Program Files\Application\Application.exe.) If you select this
option, Search Directory becomes enabled.
Search for file: return containing directory only

Searches a specific folder for a file, and returns the path to the file without
the file name. (Example: C:\Program Files\Application\.) If you select this
option, Search Directory becomes enabled.
Search Directory
This is not available when you search all fixed drives for a file. Although you can
enter a specific path here, it is best to enter one of the predefined folder
properties that are listed in the Directory table of the Tables tab in Setup Editor.
Example: Entering [Windows] searches the default Windows directory,
regardless of its name or location.
Search Depth
Enter how many directories below the search directory to search. The default, 0,
searches only the top level of the directory specified in Search Directory. If
you are searching all fixed drives for a file, then 0 searches the root directories
only. Enter 1 to search both the top level and the top level’s child directories, 2
to search two levels of child directories, and so on.
File Name
Enter the name of the file.
Details
Click to specify more details about the file.
The Search File Details dialog appears.
4. If you clicked Details, complete the dialog:
Because the file search stops with the first match, enter as much detail as possible
to ensure that the installation finds the correct file.
File Name
Enter the name of the installed file. This is the only required search criteria.

Min. Version
(Optional.) The file’s binary version resource must be equal to or greater than
this number. Leave both version fields blank to ignore the file version.
Max. Version
(Optional.) The file’s binary version resource must be equal to or less than this
number. Leave both version fields blank to ignore the file version.
Note
When using the version fields, make sure you consider the binary version
resource and not the string version resource. The Windows Properties dialog for
files displays only the string version, which can be different from the binary
version. Only the first 3 segments of a 4 segment version string are considered.
Example: For 1.0.2.3, only 1.0.2 is considered.
Min. Size
The file’s size must be equal or greater than this number. Leave the default
value of 0 to ignore the file size.
Max. Size
The file’s size must be equal or less than this number. Leave the default value of
0 to ignore the file size.
Languages
(Optional.) To search for a file with a particular language ID, enter the language
ID. To enter multiple languages, separate the language IDs with commas.
5. Click OK in the Search File Details dialog.
6. Click OK in the Search for File dialog.
To test the search, add a text box on one of the dialogs in the installation. In the text
box’s Control Text field, enter the property name (surrounded by brackets) that you
assigned to this search. (Example: [MY_PROPERTY].) This causes the value of the
property to be displayed on the dialog. When you run the installation, the property you
specified will hold the results of the search. If it is empty, the search failed.
Searching For Items in .INI Files

On the System Search page, you can set up a search for an item in an .INI file on the
destination computer. You can either search for a generic value, or do a special search
that’s tailored specifically for a file path or directory path.
Note
When you use the System Search page to search for an .INI file, you can only search for
.INI files that are inside the Windows or the Winnt directory. Windows Installer does not
find .INI files that are located in other directories, even subdirectories within the
Windows directory.
.INI File Terminology

z An .INI file consists of sections with the following syntax:
[DirectoriesAndFiles]
SrcDir=E:\Application\
SrcFiles=E:\Application\Application.exe, E:\WiseUser\wiseuser.dll

z In the section above, DirectoriesAndFiles is an INI Section Name and SrcDir is an

INI Item Name.
z Item Field refers to the number of the item in a comma-delimited list. Example:
The Item Field for E:\WiseUser\wiseuser.dll in the section above is 2 because it is
the second item in the list.
To add an .INI file to the search list:

2. Click Add at the right of the page and select INI File.
The Read INI File dialog appears.
Property
name, directory path, or other value, depending on the operation performed by
the search. If you’ve already defined a new public property (all uppercase) in
the Properties icon on the Product tab, then you can select it from the list;
otherwise enter a new property name (all uppercase). If you enter a new
property name, and the search fails to find a match, the property value will be
null and will be false if used in a condition.
Operation
Read directory name from INI file

Use this only if the .INI information you are searching for is a directory path.
A search of this type returns the entire directory path. Example:
E:\Application\.
If you use this operation on .INI information that’s in the form of a file path,
or any other form, then this type of search fails. The search also fails if there
is more than one value listed for the item, separated by commas.
Read file pathname from INI file

Use this only if the .INI information you are searching for is a file path.
Example: E:\Application\Application.exe. However, the file name itself is
dropped from the search result. A search of this type returns the directory
path only, minus the file name. Example: E:\Application\.
If you use this operation on .INI information that’s in the form of a directory
path, or any other form, then this type of search fails. The search also fails if
there is more than one value listed for the item, separated by commas.
Read raw value from INI file

Use this to find any type of .INI information. This type of search has the
added benefit of letting you specify the Item Field, which determines which
value in a comma-delimited list of values to retrieve. Example: If you set the
Item Field to 2 and search this item:
Colors=red,blue,green
“blue” is returned because it is the second field in the item.
INI File Name

Enter the name of the .INI file. (Not case-sensitive.)

INI Section Name

Enter the section name that contains the item you’re searching for. Although
section names are enclosed in brackets, don’t include the brackets. (Not case-
sensitive.)
INI Item Name

Enter the name of the item that contains the value you’re searching for. (Not
case-sensitive.)
Item Field
This is enabled if you select Read raw value from INI file in the Operation
field. If the item you’re searching for contains several values, separated by
commas, enter the number of the value’s position in the list of values or enter 0
to get all values.
4. Click OK.
Searching For a Registry Value

On the System Search page, you can set up a search for a registry value on the
destination computer. You can either search for a generic value, or do a special search
that’s tailored specifically for a file path or directory path.
2. Click Add at the right of the page and select Registry.
The Read Registry Value dialog appears.
Property
name, directory path, or other value, depending on the operation performed by
the search. If you’ve already defined a new public property (all uppercase) in
the Properties icon on the Product tab, then you can select it from the list;
Operation
Read directory name from registry

Use this only if the registry information you are searching for is a directory
path. A search of this type returns the entire directory path. Example:
E:\Application\.
If you use this operation on registry information that’s not in the form of a
file path, the search fails.
Read file pathname from registry

Use this only if the registry information you are searching for is a file path,
such as E:\Application\Application.exe. However, the file name itself is

dropped from the search result. A search of this type returns the directory
path only, minus the file name. Example: E:\Application\.
If you use this operation on registry information that’s not in the form of a
directory path, the search fails.
Read raw value from registry

Use this to find any type of registry information.
Root
Select the root folder that contains the registry value to search for.
Key
Enter an entire key path, separating key names with backslashes. Example:
Software\Application\Common.
Value Name
Enter the name of the registry value. To find the default registry value, leave
this blank.
Search 64-bit portion of the registry

(64-bit installations only.) Mark this to find registry keys that are designated as
64-bit components.
4. Click OK.
Searching For a Previously-Installed Component

On the System Search page, you can set up a search for a component that was
previously installed on the destination computer. The search looks for the component’s
GUID in the registry to determine whether the component is installed.
You might use this search to find the installation directory of a component installed by a
different Windows Installer installation.
Example: Suppose you want to find the installation directory of version 1.0 of your
Sample1 application. You could use a file search to find the file, Sample1.exe, but it
might take a long time to search all drives. Instead, you could search for the component
ID of the component that contained Sample1.exe in the original installation. This type of
search is much faster.
In order to perform a component search, you must know the component’s ID. To obtain
this ID, you must have access to the .WSI file of the previous installation. You can find
the component’s GUID on the Component Details dialog; see Adding and Editing a
To add a component to your search list:

2. Click Add at the right of the page and select Component.
The Read Component Settings dialog appears.

Property
Specify a property. It will hold the result of the search, which is a file name,
directory path, or other value, depending on the operation performed by the
search. If you’ve already defined a new public property (all uppercase) in the
Properties icon on the Product tab, then you can select it from the list;
Operation
Read directory name from component keypath

Select this operation if the component you are searching for contains only an
empty directory (a Create Directory item) and has an empty key path. This
operation returns a directory path. (Example: C:\Program
Files\Application\.) If the keypath for this component is a file, ODBC item, or
registry item, this operation fails.
Read file pathname from component keypath

Select this operation only if the component you are searching for has a file
for a key path. In this case, it returns the directory path. Example:
C:\Program Files\Application\.
Component ID
Enter the GUID for the component. See Adding and Editing a Component on
page 392 and About GUIDs on page 524.
4. Click OK.
Setting Features for Installation Types

Use the Installation Types page to determine which features are installed when the end
user selects Complete, Typical, or Custom on the Installation Type dialog. To display the
Installation Type dialog to the end user during installation, you must mark its checkbox
on the Dialogs page.
Example: Suppose your application contains 3 features. You could set the following
defaults for the Installation Type dialog:
Installation Type Features Installed by Default

Typical Core
Complete Core
Tutorial
Samples

Because the Installation Types page simply sets the defaults, the end user can still
override these choices during installation by clicking Custom in the Installation Type
dialog, and then turning features on or off on the Select Feature dialog. To display the
Select Feature dialog to the end user during installation, mark its checkbox on the
Dialogs page.
On the Installation Types page, the upper left list box shows 3 installation types by
default, Typical, Complete, and Custom, which correspond to the 3 radio buttons
presented to the end user on the Installation Type dialog during installation. The right
list box shows the features in the installation. You can collapse or expand the features
and their child features using the right-click menu.
For each installation type, you can set the following:
z Quick access key

To change the underlined letter for the access key, double-click an installation type
name to make it editable, then change the position of the &. The letter that follows
the & becomes underlined on the Select Installation Type dialog.
z Whether it is selected by default

To set an installation type radio button to be selected by default, select the
installation type name in the upper left list and click Default Installation Type.
z Description text
This text appears next to the radio button on the Installation Type dialog. To change
the text for a specific installation type, select the installation type name in the upper
left list and change the text in the Description text box.
z Default features
To set which features are turned on by default during installation, select an
installation type name in the upper left list and mark the checkboxes of the features
in the list on the right.
Caution
If you are using the Installation Types page to manage the Installation Type dialog, do
not edit the Installation Type dialog. Doing so causes the Installation Types page not to
work properly.
The Select Installation Type and Select Features dialogs below illustrate how the
selections you make on the Installation Types page appear to the end user.
Selected by
default
Description
text
Access key

Default
features

Chapter 8
Organizing Your Installation Into Releases
You can create an installation that generates different installations for different releases
of your application. You do this by creating and customizing releases within the
installation. You can create releases that install different features, have different
properties, have different output formats, and generate a Web-based installation.
Note
You can only create releases in a project file (.WSI). In any other file, the pages in the
Release Definition page group are fully or partially disabled. An exception is the
Languages page. See Translating an Installation on page 258.
Topics include:
z About Releases.
z Customizing a Release (setting per-release overrides for properties, summary

items, and features).
z Setting Build Options for a Release (determining format of output files and language
options).
z Adding Prerequisites to a Release (determining files to pre-install).
z Creating a Clean Build (creating a compilable copy that has minimal impact on a
build computer).
z Creating Web-Based Installations With WebDeploy (creating an installation end

users can run from the Web).
z Setting Up Media for Distribution.
About Releases
Note
This page is fully enabled in a .WSI only. In an .MSI or .MST, you cannot add or delete.
The Releases page lets you define multiple releases for an installation, edit releases, and
delete releases you’ve created. If you haven’t created additional releases for the
installation, the Releases page lists only one release: Default.
Example:
You might want to have a standard and a demo edition for your application, and you
might want to release both editions on CD and as Internet downloads. In this case, you
would create 4 releases:
z Standard edition on CD-ROM
z Standard edition for the Internet
z Demo edition on CD-ROM

z Demo edition for the Internet
The Releases page contains the following buttons:
z Details
Edit a release.
z Add
Add a new release. See Creating a New Release.
z Delete
Delete a release. At least one release is required; if the installation only has one
release, you cannot delete it.
z Compile
Compile a specific release without compiling the entire installation. Select one or
more releases and click the Compile button at the right of the Releases page.
The Compile button at the bottom of the main window compiles the entire
installation. (In Visual Studio: use commands on the Build menu.) See Compiling An
You can edit various aspects of each release on the other pages in the Release Definition
page group.
Creating a New Release

Note
1. Select Installation Expert > Releases page.
2. Click Add.
The Release Details dialog appears.
3. Enter the following:
Release Name
Enter a unique name that describes the release. Example: Standard_CD-ROM or
Standard_Internet. This name appears on the Releases page.
.MSI File Name

Name the installation file for this release. Do not include the directory name.
Each release is saved in a separate .MSI. If you leave this blank, the release
name defaults to the name of the .WSI with the extension .MSI. When there are
multiple releases, this can cause a compile error, because no 2 releases can
have the same name.
Description
Enter information to distinguish this release from others. Examples: Demo,
Optimized for Internet Distribution. This description appears on the Releases
page.
Installation Theme
Select the theme for the installation dialogs for this release. The theme controls
the overall look of the dialogs by setting the dialogs’ top or side image and the
fonts of the dialog text. You can use different themes for different releases.
Example: Use a different theme for a demo release to clearly distinguish it from

your standard release. For details, see Changing the Theme of Dialogs on
page 431.
The theme of the Default release on the Releases page corresponds to the
Default Theme on the Dialogs page. Changing the theme on one page changes
it on the other. Renaming or deleting the Default release breaks this
relationship.
Compression Type
Select the amount of compression. This depends on the media you use to
distribute the release. Examples: For an Internet release, use maximum
compression for a faster download, but for a release on a CD, use no
compression. Higher compression slows the compile.
Release Type
Select Terminal Server Enabled if this release is intended to be installed in a
Microsoft Terminal Services or Citrix environment. This sets the installation to
be installed per-machine and prevents keypaths for components from being
assigned to per-user resources. This option might cause keypaths to be empty,
and might cause a one-time repair. Environment variables are duplicated,
creating a per-user set and a per-machine set, one of which is installed
depending on the value of ALLUSERS. Also see ALLUSERS Property in the
Windows Installer SDK Help. (Enterprise Edition only.)
Build this release during compile

Mark this to have this release compiled when you click Compile at the bottom of
the main window. (In Visual Studio: use commands on the Build menu.) This
corresponds to the checkbox in the Build column on the Releases page. Marking
or clearing one checkbox affects the other checkbox.
4. To add or edit media settings, click Edit Media. The Media Details dialog appears.
See Setting Up Media for Distribution on page 201. The Edit Media button and the
Media section appear only when you first add a new release.
5. Click OK.
The release is added to the list on the Releases page. To edit a release, double-click its
name. The other pages in the Release Definition page group let you further customize
each release.
Outputting a Multiple-Language Release

Note
Normally, when you compile an installation containing multiple languages, a separate

.MSI or .MST is created for each language. However, you can create a single installation
that contains multiple languages, and either automatically installs in the destination
computer’s language or prompts the end user to select a language. To create a multiple
language installation, you must create a release that compiles to an .EXE file.
1. On the Releases page, create a release to contain the multiple languages. See
Creating a New Release on page 179.
2. On the Build Options page:
Current Release
Select the release that you just created

.EXE Options
Select one of the following:
Single-file .EXE
When you select this, you must create a language transform for each
additional language. See Creating a Language Transform on page 260.
During compile, the transforms are packaged inside the .EXE along with the
.MSI.
.EXE that launches external .MSI

When you select this, you can use language transforms or you can create a
separate .MSI for each language. During compile, settings for the .EXE are
stored in a separate .INI file. See INI File Properties on page 422.
Include all languages in installation .EXE

Mark this to embed all the languages that are marked on the Languages page in
the output .EXE.
Always prompt for installation language

Mark this to prompt the end user to select a language.
Clear this to have the resulting installation verify if one of the languages in the
installation is on the destination computer. If so, the installation proceeds in the
destination computer’s language. If not, the end user is prompted to select a
language.
3. On the Languages page, select the languages you want to include in this release.
See Creating a Translated .MSI on page 259.
4. Save and compile the installation.
When the end user launches the installation .EXE, the installation either proceeds in the
destination computer’s language or prompts the end user to select a language. If you
created a single-file .EXE, the .MSI runs with the appropriate transform. If you created
an .EXE that launches an external .MSI, the appropriate language .MSI runs.
Customizing a Release
When you create a new release, it has the same properties, summary items, and
features list as the Default release. The Release Settings page lets you customize a
particular release by:
z Overriding the properties and summary items. These are set for the entire
installation in Setup Editor > Product tab.
z Selecting the features to include in the release. Features are set for the entire
installation in Installation Expert > Features page.
The tree structure on the Release Settings page displays features and their
hierarchical relationships. Use the right-click menu to collapse or expand all features
or child features of selected parents only.
You can share settings between releases, so you can efficiently create releases that
share all or most settings.
Example:
Customize a release as a demo in which:
z The application doesn’t allow the end user to save files.
z The product’s name indicates it is a demo.

z The product’s summary informs the end user that this demo release doesn’t allow
saving files.
Note
This page is enabled in a .WSI only.
Customizing Properties for a Release

Note
You can use the Release Settings page to override the value of an existing property or
add a new property for a specific release. Example: Change the ProductName property
to reflect that a particular release is a demo version rather than a full version.
Each release contains the properties listed under the Properties icon in Setup Editor >
Product tab. Only those properties you change or add for a specific release appear under
the Properties icon on the Release Settings page. Properties you add for a specific
release do not appear in Setup Editor. Deleting a property from the Release Settings
page removes the override for the specific release.
1. Select Installation Expert > Release Settings page.
2. From Current Release, select a release.
3. In the list box, click the Properties icon.
4. Click Add at the right of the Release Settings page. The Property Settings Override
dialog appears.
5. From Name, select an existing property or enter a name to create a new property.
6. In Value, enter an initial value for the property. During execution, the installation
might change this value.
7. Click OK.
The property appears in the list box. To edit it, double-click its name.
Customizing Summary Items for a Release

Note
You can use the Release Settings page to override the value of an existing summary
item or edit customized summary items. Example: Change the Comment Summary item
to reflect that a particular release is a demo version rather than a full version.
End users can see the summary information by right-clicking the compiled .MSI or .EXE
in Windows Explorer and selecting Properties.
Installer SDK Help.
Each release contains the summary items listed under the Summary icon in Setup Editor
> Product tab. Only those summary items you change for a specific release appear
under the Summary icon on the Release Settings page. You cannot create new summary

items. Deleting a summary item from the Release Settings page removes the override
for the specific release.
To customize summary items:

3. In the list box, click the Summary icon.
4. Click Add at the right of the Release Settings page. The Summary Settings Override
dialog appears.
5. From Name, select a summary item.
6. In Value, enter a new value or text for the summary item.
7. Click OK.
The summary item appears in the list box. To edit it, double-click its name.
Also see:
Specifying Summary Information on page 384
Defining a Feature Set for a Release

Note
The Release Settings page lists all features in an installation. You can select the features
to include in a particular release. Example: Turn off a SpellCheck or a SaveAs feature for
a demo release.
3. If necessary, expand the Features icon in the list box.
4. To include a feature in this release, mark its checkbox. To exclude a feature, clear its
checkbox.
Sharing Settings Between Releases

Note
You can share settings from a release with other releases in the installation. After you
initially share settings, the settings for the releases are linked. This means that any
change you make to the release settings for any of the linked releases is applied to all
other linked releases. At any time, you can break the link.
To share settings between releases:

2. From Current Release, select a release to copy settings to.

3. Click Share at the right of the Release Settings page. The Share Release dialog
appears.
4. From Copy/Share Settings From, select the release that contains the settings to
copy.
5. Click OK.
The settings of the release in Copy/Share Settings From immediately replace the
settings of the release in Current Release. Any change you make to the release
settings of either of the linked releases is applied to the other release, until you break
the link.
To break a link between releases:

3. Click Share at the right of the Release Settings page. The Share Release dialog
appears.
4. From Copy/Share Settings From, select <None>.
5. Click OK.
The link between the selected release and other releases is broken. The current settings
of the releases are not changed, but changing settings for one release no longer affects
the settings of the other release.
Example: Creating a Demo Release

This example describes how you could define a demo release for an application. In this
example:
z The release is named Sample Demo.
z The application’s summary dialog indicates that this is a demo release.
z Potential customers can use the demo version indefinitely, but they can’t save any
files.
Assumptions
z On the Features page, you have added a SaveAs feature with the appropriate
resources for the default release.
z The SaveAs feature includes resources that let end users save files.
z On the Releases page, you have created a release named Demo.
To create a sample demo release:

2. From Current Release, select Demo.
3. Click the Properties icon.
4. Click Add at the right of the Release Settings page. The Property Settings Override
dialog appears.
5. From Name, select ProductName.

6. In Value, enter Sample Demo.
7. Click OK.
8. Click the Summary icon.
9. Click Add at the right of the Release Settings page. The Summary Settings Override
dialog appears.
10. From Name, select Comments.
11. In Value, enter:
This is a demo version; it does not allow you to save files.
12. Click OK.
13. If necessary, expand the Features icon in the list box.
14. Clear the SaveAs feature’s checkbox.
Setting Build Options for a Release

Note
On the Build Options page, you can customize a release by selecting the format of
output files and language options.
1. Select Installation Expert > Build Options page.
3. Complete the build options listed below.
Build Options
z Use short file names for files uncompressed outside of the install
Mark this to abbreviate file names to 8.3 format names. This is useful if you will
distribute your installation on CDs with the 8.3 format.
z .EXE Options
This determines what kind of files are output when you compile this release. If you
create an .EXE, you can install Windows Installer and .NET Framework runtimes and
run prerequisite files on the destination computer before the main installation. See
Adding Prerequisites to a Release on page 186. For WebDeploy to be enabled, you
must select one of the WebDeploy options. For details, see Creating a WebDeploy
Do not create an .EXE file

Create only the .MSI file. The installation will work only on computers that have
Windows Installer installed. Selecting this disables the remaining options on the
Build Options page.
Single-file .EXE (only valid for files inside .MSI)

Place the .MSI file inside an .EXE file. This is the preferred option if you plan to
send an installation via e-mail or place it on a Web page.
.EXE that launches external .MSI

Create an .EXE with the same name as the .MSI file. Settings for the .EXE are
stored in a separate .INI file. See INI File Properties on page 422. The .EXE
itself is small, because it doesn’t contain any runtimes or the .MSI file. This is

the preferred option if you place the installation on a CD, because the .MSI does
not need to be extracted to the hard drive.
WebDeploy .EXE
Create an .EXE that is optimized for direct downloading from the Internet. The
installation will compile to an .EXE that contains the download information, and
an .MSI file that might or might not be embedded in the .EXE. This sets the
Create a downloadable .EXE option on the WebDeploy page, and vice versa.
WebDeploy .EXE and .INI

Change the download information dynamically, perhaps as a result of end user
input. The installation will compile to an .EXE, an external .MSI, and an external
.INI file that contains the download information. This sets the Create an .EXE
and .INI option on the WebDeploy page, and vice versa.
Caution
If you change the .EXE options after you edit the WiseScript on the Prerequisite
Pages, you will lose all the changes you made to the script.
z Password
Enter a password. The user installing the application is prompted to enter the
password to initiate the installation. This password is the same for all users. You can
protect only .EXEs with a password.
z Prompt to remove previous version before installing

Mark this to have the installation check for previous versions of the same application
and prompt the end user to uninstall the previous version before proceeding with
the new installation.
For this to work, the previous version must have been installed using Windows
Installer technology. If not, then use the System Search page to search for a
previous version.
Note
For best results, use the Upgrades page rather than this option to deal with previous
versions of your software.
Do not mark this checkbox if you are using the Upgrades page or patches to update
an application.
z Include all languages in installation .EXE

Mark this to embed all the languages that are marked on the Languages page in the
output .EXE. For details, see Outputting a Multiple-Language Release on page 180.
z Always prompt for installation language

Mark this to cause a multi-language installation to prompt the end user for the
language at runtime.
Clear this to have the resulting installation verify if one of the languages in the
installation is on the destination computer. If so, the installation proceeds in the
destination computer’s language. If not, the end user is prompted to select a
language.
Adding Prerequisites to a Release

On the Prerequisites page, you can:
z Select the Windows Installer and .NET Framework runtimes to pre-install.

z Add prerequisite files to run before the main installation. Prerequisite files are
usually .EXE or .MSI files, but there is no restriction on their type.
z Add the MSDE runtime to run before the main installation. This is a special file that
installs MSDE using specific command line options and settings. It is added as an
include script to the WiseScript that creates the installation .EXE.
If you specify a runtime that is not on your computer, the Download Redistributables
wizard appears during compile. Use the Wise Web Site option to download that runtime,
which should be pre-selected. See Downloading Redistributable Files on page 35.
Note
The options on the Prerequisites page are disabled if Do not create an .EXE file is
selected from .EXE Options on the Build Options page. See Setting Build Options for a
To add prerequisites to a release:

1. Select Installation Expert > Prerequisites page.
3. Select the runtimes to pre-install.
Windows Installer Runtime Version

Select the Windows Installer runtime version to pre-install for each set of
operating systems: Windows 9x, NT, and 2000/XP/2003. This adds a file to the
installation that pre-installs Windows Installer if it is not on the destination
computer.
If you know that a particular operating system is not used on any destination
computers, select None for that operating system.
Select Latest to add the latest runtime that you have downloaded and that
works with that operating system.
Example: If the latest runtime that you have downloaded is 2.0 and you
select Latest (NT) and Latest (2000/XP/2003), then 2.0 is added to the
installation. If later you download 3.0, both 2.0 and 3.0 are added. Version
2.0 would be the latest runtime for NT and 3.0 would be the latest for 2000/
XP/2003.
If you select a runtime for Windows: The installation includes:

9X InstMsi.exe
NT InstMsiW.exe
2000/XP/2003 (runtime earlier than 3.0) InstMsiW.exe
2000/XP/2003 (runtime 3.0 or later) InstMsi3.exe
.NET Framework Runtime Version

Select the .NET Framework runtime version to pre-install. This adds the file
dotnetfx.exe to the installation, which pre-installs the .NET Framework
regardless of the destination computer’s operating system.

Note
Prior to the release of Windows Installer 3.0, the .NET Framework included the
version of the Windows Installer runtime that it required. However, Microsoft
does not distribute Windows Installer 3.0 with the .NET Framework. If your
application requires Windows Installer 3.0, configure the installation to pre-
install it.
If the .NET Framework includes a Windows Installer version that is later than
the Windows Installer version you selected above, the later version is pre-
installed.
4. To delay the reboot to the end of the installation and minimize reboots for the end
user, mark Delay Windows Installer runtime reboot until after product
installation.
This is enabled only if one of the Windows Installer Runtime Version fields is set
to 2.0 or later, or if a .NET Framework that includes Windows Installer 2.0 or later is
selected. Normally, installing the Windows Installer runtime requires a reboot at
that point in the installation.
5. To run the prerequisite files before checking the launch conditions of the .MSI
installation, mark Don’t check the launch conditions of the .MSI installation
until after running the prerequisites.
By default, the .MSI launch conditions are checked after the installation of any
runtimes that you select on the Prerequisites page and before any prerequisite files
run. With this option you can delay checking the .MSI launch conditions until after
the prerequisite files run. Use this option when the .MSI launch conditions will fail if
the prerequisite files have not been run.
6. To add a prerequisite file, click Add at the right of the page and select Prerequisite.
The Prerequisite Details dialog appears.
7. Complete the Prerequisites Details dialog and click OK. See Adding a Prerequisite
File on page 189.
The prerequisite file is added to the Prerequisites page. To edit or delete it, use the
right-click menu.
8. To add the MSDE runtime prerequisite, click Add at the right of the page and select
Runtime.
The Runtime Details dialog appears.
9. Complete the Runtime Details dialog and click OK. See Adding the MSDE Runtime
Prerequisite on page 190.
The runtime is added to the Prerequisites page. To edit or delete it, use the right-
click menu.
10. If a prerequisite file or runtime requires a reboot, you might need to edit the
WiseScript to make the reboot run smoothly. We recommend adding 2 Pause actions
for 1000 milliseconds after a prerequisite or runtime that requires a reboot. This
works better than 1 Pause action for 2000 milliseconds. Adding the Pause actions
prevents the WiseScript from trying to launch the next prerequisite or runtime while
the computer is shutting down. See Editing the WiseScript That Creates the
Installation .EXE on page 191.
11. During installation, any runtimes you selected at the top of the Prerequisites page
run first, and then the prerequisite files and runtimes run in the order that they are

listed. To rearrange the order, select an item in the lower pane and click Move Up or
Move Down at the right of the page.
For each prerequisite file and runtime that you add, script is added to the WiseScript
that creates the installation’s .EXE. You can edit this script to enhance the functionality
of the prerequisites. See Editing the WiseScript That Creates the Installation .EXE on
page 191.
Adding a Prerequisite File

On the Prerequisites page, you can add prerequisite files to run before the main
installation. Prerequisite files are usually .EXE or .MSI files, but there is no restriction on
their type.
Note
3. To add a prerequisite file, click Add at the right of the page and select Prerequisite.
The Prerequisite Details dialog appears.
Note
If you compile an installation into an .EXE that launches an external .MSI, 3 files are
generated: an .EXE, an .MSI, and an .INI. If you add prerequisite files to the
installation, a subdirectory that is named after your installation file is also created.
When you distribute the installation, you must include this subdirectory along with
the 3 files that are generated or the installation will not run.
File Path
Specify the prerequisite file to be run before the main installation.
Command Line
Specify the command line options to apply to the prerequisite file at run time.
If the prerequisite’s launch conditions fail, stop the .MSI installation

Mark this to stop the main installation if the prerequisite file fails to run because
of its launch conditions.
Add Launch Conditions

Click this to add launch conditions to the prerequisite file.
The Prerequisite Launch Conditions dialog appears. You can add launch
conditions for the destination computer’s operating system, display settings,
and NT administrator rights. The prerequisite file runs only if all conditions are
true. Conditions you add appear in the Condition section. If your prerequisite
file is an .MSI, you cannot add launch conditions, but you can view its launch
conditions on the Prerequisite Launch Conditions dialog.
To add a launch condition, select an option from both drop-down lists and
click Add. Repeat to add additional launch conditions.

To delete a launch condition, select it in the Condition section and click

Delete.
Click OK to save the launch conditions.
5. Click OK on the Prerequisite Details dialog.
The prerequisite file is added to the Prerequisites page. To edit or delete it, use the
right-click menu.
6. To add additional prerequisites, repeat the steps above.
Also see:
Adding Prerequisites to a Release on page 186
Adding the MSDE Runtime Prerequisite

If you need to distribute MSDE with an application, you can use the Prerequisites page
to add the MSDE runtime to run before the main installation. This is a special file that
installs MSDE using specific command line options and settings. It is added as an include
script to the WiseScript that creates the installation .EXE. Unlike prerequisite files, you
do not set command line options or launch conditions for this runtime because any
options are built into the runtime.
The runtime is always included in the installation .EXE, even if .EXE that launches
external .MSI is selected on the Build Options page.
Before you can add the MSDE runtime to an installation, you must add the MSDE
installation files to your computer.
Note
To add the MSDE runtime to your computer:

2. Mark Other Vendors’ Web Sites and click Next. When all available redistributables
are retrieved, the Available Redistributable Files dialog appears.
3. In the list box, select the MSDE 2000 runtime (Microsoft SQL Server 2000 Desktop
Engine). Then click Download to launch your Internet browser, if necessary, and
connect to Microsoft’s Web site.
4. Follow the links and prompts on the Web site to download the MSDE .EXE file.
5. When the download is complete, return to the Available Redistributable Files dialog
and click Finish.
6. Find the .EXE file that you downloaded and double-click it to extract the MSDE
installation files to your computer.

To add the MSDE runtime to an installation:

3. Click Add at the right of the page and select Runtime.
The Runtime Details dialog appears.
4. To add the MSDE runtime, mark its checkbox and click OK.
The Details dialog appears.
MSDE Directory
Specify the directory to which you extracted the MSDE installation files.
Strong SA Password
Enter a strong password for the system administrator of this instance of MSDE.
A strong password is one that meets these requirements:
It may not contain your user name or any part of your full name.
It must be at least 6 characters long.
It must contain elements from 3 of the following types of characters:

uppercase letters, lowercase letters, numerals, and special characters.
MSDE Instance
Enter a name for this instance of MSDE, if required.
6. Click OK on the Details dialog.
The runtime is added to the Prerequisites page. To edit or delete it, use the right-
click menu.
Also see:
Adding Prerequisites to a Release on page 186

Adding a Prerequisite File on page 189
Editing the WiseScript That Creates the Installation .EXE

If you select an option to create an .EXE on the Build Options page, a WiseScript project
file (.WSE) is generated, which is used to compile the .EXE. After you add prerequisite
files or runtimes to an installation on the Prerequisites page, you can edit this WiseScript
to enhance the functionality of the prerequisites.
If your default WiseScript editor is WiseScript Express, you cannot use this interface to
open WiseScripts that were created in another Wise product, because they might
contain actions that WiseScript Express does not support.
Caution
Make sure the .EXE options on the Build Options page are set correctly before you edit
the WiseScript. If you change the .EXE options after you edit the WiseScript, you will
lose all the changes you made to the script.
To edit the WiseScript:


2. Add prerequisites as needed. See Adding Prerequisites to a Release on page 186.
Note
After you edit the WiseScript, the ability to add or edit prerequisite files and
runtimes on the Prerequisites page is disabled. To enable them, click Reset Script at
the right of the page.
3. Click Edit Script at the right of the page.
The Edit Script button is disabled if Do not create an .EXE file is selected from
.EXE Options on the Build Options page. See Setting Build Options for a Release on
page 185. It is also disabled until you add prerequisite files or runtimes.
If you have not previously edited the script, a warning message appears. Click Yes.
The installation is saved and compiled and the WiseScript that creates the
installation’s .EXE opens in your default WiseScript editor. See WiseScript Editing
Tools on page 473.
The name of the WiseScript file for the default release is the installation name with
the extension .WSE. The WiseScript files for additional releases are named for the
release.
Caution
Don’t change the name of the WiseScript file. It must have this name to create an
.EXE that includes your edits.
4. Edit the WiseScript as needed and save it.
The next time you compile the installation, an .EXE is generated using the
WiseScript file that you edited.
5. Thoroughly test the WiseScript to make sure it executes as expected.
To reset the WiseScript:

1. Click Reset Script at the right of the page.
This button is enabled only if you have used the Edit Script button.
A warning message appears.
2. Click Yes.
The changes you made to the WiseScript are deleted, and the ability to add and edit
prerequisite files on the Prerequisites page is enabled.
Also see:
WiseScript Editing Tools on page 473
Creating a Clean Build

Note

Use the Clean Build page if you need to do the final build on a clean build computer. A
clean build environment helps avoid virus contamination. Also, moving a build to a clean
build computer will reveal whether some necessary files exist only on the developer’s
computer.
The clean build itself is a collection of files that are necessary to compile an installation
project. This includes a minimal copy of Wise for Windows Installer, an .INI file that
stores information normally stored in the registry, and all installation files. No changes
are made to the registry or system of the build computer during the build creation
process.
Options for Saving the Clean Build

You set clean build options per release, which means you can have a different clean build
location for each release.
z Check the clean build into a source code control system (SCCS). Every time you
generate a clean build, any files in the installation that changed are checked into the
SCCS. This provides a history of versions of the installation and lets you recreate a
build at any stage in its development process.
z Save the clean build to any network directory. Every time you generate a clean
build, the necessary files are recopied to the directory, overwriting previous
versions. Do this if you do not need to recreate older builds.
Requirements
z The build computer must have Windows Installer installed in order to compile the
final build. Version 2.0 or later is preferred because some advanced features are not
supported in earlier versions.
z To use the source control option, you must have an SCCS installed on your local
computer. You cannot be running an SCCS from a network.
To create a clean build in source control:

1. (Wise editor only.) Select Tools menu > Options. On the Source Control tab, mark
Enable source control and click OK.
This checkbox appears only if a locally-installed SCCS is detected on your computer.
2. Select Installation Expert > Clean Build page.
4. Mark Store clean build in source control. This is disabled if source control is not
enabled in options. (In Visual Studio: this is disabled if an SCCS is not installed
locally.
5. Click Browse under the Store clean build in source control option and specify
where in the SCCS to store the project. Dialogs from your SCCS lead you through
this process.
In the Wise editor: If you are using the Source Control menu for version control
on the entire installation, select a different folder in source control to store the
clean build.
In Visual Studio: If you are already storing the installation project in source
control, select a different folder in source control to store the clean build.
This completes the setup portion of the clean build process. Complete the following
steps when you are ready to copy the clean build to the clean build environment.

6. To make the final build, select File menu > Update Clean Build. (In Visual Studio:
Project menu > Update Clean Build.) This is disabled if no clean build options are set
for any release.
The new or updated files are checked into your SCCS.
7. From your SCCS, copy or get the clean build folder to your clean build computer.
8. From the clean build folder on the clean build computer, double-click the file
Wisebuild.exe, which silently compiles the build.
The compiled files appear for each release whose Build checkbox is marked on the
Releases page. Two log files are created; one shows compile actions and the other
shows compile errors.
To create a clean build in a directory:

1. Select Installation Expert > Clean Build page.
3. Mark Store clean build in directory. This lets you copy the clean build anywhere
on the network, to a disk or zip drive, or to any other directory accessible to your
computer. You can then copy it to a clean build computer.
4. Click Browse under the Store clean build in directory option and specify the
directory in which to store the clean build.
This completes the setup portion of the clean build process. Complete the following
steps when you are ready to copy the clean build to the clean build environment.
5. To make the final build, select File menu > Update Clean Build. (In Visual Studio:
Project menu > Update Clean Build.) This is disabled if no clean build options are set
for any release.
The new or updated files are copied to the directory you selected.
6. From the directory, copy the clean build folder to your clean build computer.
7. From the clean build folder on the clean build computer, double-click the file
Wisebuild.exe, which silently compiles the build.
The compiled files appear for each release whose Build checkbox is marked on the
Releases page. Two log files are created; one shows compile actions and the other
shows compile errors.
Creating Web-Based Installations With WebDeploy

¾ Editions and Windows Installer version.
Available in Professional and Enterprise Editions only. For best results with WebDeploy,
the destination computer should have Windows Installer 2.0 or later.
Note
WebDeploy™ lets you create Web-based installations that minimize bandwidth

requirements by downloading only the files needed for the installation.
Examples:

z If you set the installation to pre-install the Windows Installer runtime, and the
destination computer already has that runtime installed, then the runtime file is not
downloaded.
z If the installation contains multiple features, only the features that the end user
selects during installation are downloaded and installed.
Without WebDeploy, you could create a single-file .EXE, upload it to an FTP server, and
let your end users download it by clicking on its link. The disadvantage of this is that a
single-file .EXE can be very large. The entire installation, including Windows Installer
runtimes, is downloaded whether or not it is needed on the destination computer. The
resulting download can take a long time and tie up bandwidth.
Note
You cannot use WebDeploy to run patches (.MSP) or transforms (.MST). To distribute
updates with WebDeploy, format the installation as an upgrade using the Upgrades
page.
For information on using WebDeploy with WiseUpdate, see WiseUpdate Tips on

page 296.
You can use WebDeploy in several ways, depending on how you set the WebDeploy
options:
Create an .EXE that contains the .MSI

Windows Installer and .NET runtimes, and prerequisite files, if any, are external to the
.EXE. When an end user launches the .EXE from the Web, it runs the .MSI from the Web.
The runtime and prerequisite files are downloaded only if they are needed on the
destination computer. See The WebDeploy Process on page 197.
WiseScript runtimes that you add on the Prerequisites page are always included in the
.EXE.
This is the best method to use when distributing installations over the Internet because,
if a self-repair is needed, the .MSI is cached locally and no further downloads are ever
required.
Create an .EXE that runs an external .MSI

Windows Installer and .NET runtimes, and prerequisite files, if any, are external to the
.EXE. The resulting .EXE is very small. When an end user launches the .EXE, it connects
to the Web location of the .MSI and runs the .MSI. The runtime and prerequisite files are
downloaded only if they are needed on the destination computer.
WiseScript runtimes that you add on the Prerequisites page are always included in the
.EXE.
This method is best used over a corporate intranet. Because the .MSI is run directly from
the Web, if a self-repair or install-on-demand is needed, the end user must have
immediate access to the original Web location of the .MSI.
Create an .EXE that runs an external .MSI, and an external .INI that
contains download and installation information
Use this method to change the download information dynamically, perhaps as a result of
end user input. You compile to an .EXE and .INI and then distribute the .EXE on a CD or
other media along with an Autoplay program.
Example:

Suppose you want to let the end user select from multiple download sites. You write an
Autoplay program that presents download site options to the end user. When the end
user selects a site, the Autoplay program copies the .EXE and .INI to a temporary
directory, then edits the .INI file, adding the URL of the selected download site. The
Autoplay program then launches the .EXE, which connects to the appropriate Web site
based on the updated information in the .INI file, and runs the .MSI file it finds there.
Also see:
Tips for Creating an Efficient WebDeploy Installation on page 197

Creating a WebDeploy Installation on page 198
Uploading a WebDeploy Installation to the Web on page 199

The WebDeploy Process

The following diagram shows how the WebDeploy™ process works when you distribute
an .EXE with an embedded .MSI over the Internet.
Phase 1: Your Computer Your Web Server
Package Distribution or FTP client
When you develop the installation, you:

z Compile the installation to an .EXE that contains the .MSI
z Configure WebDeploy by specifying the location of installation files on the Web server
z Upload the installation files to the Web server
z Notify end users of the Web link to the .EXE
Phase 2: Destination Computer Your Web Server:

z Contains the .EXE and
other pieces of the
installation ready for
download
(HTTP Protocol)
The end user:

z Launches the installation .EXE from your Web server
Phase 3: Destination Computer Your Web Server:

z Contains the .EXE and
other pieces of the
installation ready for
download
(HTTP Protocol)
When the end user runs the .EXE, it:

z Runs the .MSI
z Runs an installation wizard
z Determines which pieces of the application are needed
z Installs the appropriate pieces of the application
Tips for Creating an Efficient WebDeploy Installation


z For more efficient downloading, organize the installation into components. Only the
components that are needed for the installation are downloaded. See Working With
z Make the installation download more efficiently. On the Installation Expert > Media
page, display the Media Details dialog and select One Cab per component in the
Cab Options field. See Adding a Media Item on page 202.
z It is a good idea to digitally sign installations that you plan to deploy over the Web.
To add an authenticode digital signature to your installation files, use the Digital
Signature page. This requires Windows Installer 2.0 or later. See Adding a Digital
Signature to Your Installation on page 219.
Creating a WebDeploy Installation

Note
The WebDeploy™ page lets you enable an installation for distribution via the Web. You
do this by setting options for compiling the installation and for connecting to the Web
server that will contain the installation files. For suggestions on how to set WebDeploy
options to meet your requirements, see Creating Web-Based Installations With
WebDeploy on page 194. Also see Tips for Creating an Efficient WebDeploy Installation
on page 197.
1. Select Installation Expert > WebDeploy page.
3. Mark Create a Web-based installation. This enables the remaining options on the
page.
4. From .EXE Options, specify how the installation is created. This is linked to the
.EXE Options field on the Build Options page.
Create a downloadable .EXE

Create an .EXE that is optimized for direct downloading from the Internet. The
installation will compile to an .EXE that contains the download information, and
an .MSI file that might or might not be embedded in the .EXE. This sets the
WebDeploy .EXE option on the Build Options page, and vice versa.
Create an .EXE and .INI

Change the download information dynamically, perhaps as a result of end user
input. The installation will compile to an .EXE, an external .MSI, and an external
.INI file that contains the download information. (See INI File Properties on
page 422.) This sets the WebDeploy .EXE and .INI option on the Build
Options page, and vice versa.)
5. In the following fields, specify the URL to which you will upload various installation
files. This information is included in the installation and determines where the
installation looks for files to download. You must specify the full URL address,

pathname, and file name. Include a username and password if your Web server
requires them. Use the format:
http://username:password@www.address.com/file_name.msi
Click the Edit button next to each field to display a URL Settings dialog, which lets
you enter the elements of the file location separately and then builds the full path
from your entries.
Note
If you select the Create .EXE and .INI option, the password is stored in the .INI
file. If you are concerned about the password being visible, select the Create a
downloadable .EXE option instead, which stores the password in the .EXE.
.MSI Download URL

Enter the Web server address that points to the .MSI. This must match the
name of the .MSI you upload later. To embed the .MSI in the .EXE, leave this
field blank.
9x Download URL / NT Download URL

To make the Windows Installer runtime installations for Windows 9x and
Windows NT available for pre-installation, enter the addresses of the runtime
installation files. The runtime installation files are typically named:
Windows 9x: InstMsi.exe

Windows NT: InstMsiW.exe
Leave these fields blank to embed the .MSI in the .EXE if the Prerequisites page
is set to pre-install the Windows Installer runtime.
.NET Runtime URL / .NET Update URL

Getting the latest version of the .NET Framework runtime requires installing two
files, the original installation and a patch installation. In .NET Runtime URL,
enter the address that points to the .NET Framework runtime file
(dotnetfx.exe). In .NET Update URL, enter the address that points to the .NET
Framework upgrade file.
Leave these fields blank to embed the .MSI in the .EXE if the Prerequisites page
is set to pre-install the .NET Framework runtime.
Uploading a WebDeploy Installation to the Web

Note
To upload the files in a WebDeploy™ installation, you can use:
z Package Distribution. Because Package Distribution cannot upload to multiple

directories, use it only if all the installation files will be stored in the same directory
on the server.
z Any FTP client. Do this when the Windows Installer and .NET runtime installation
files will be stored in a different location than the application installation files.

To upload a WebDeploy installation with Package Distribution:

1. To have the installation pre-install the Windows Installer runtime, set the following
fields to determine which versions of the Windows Installer runtime file are
uploaded by Package Distribution.
Note
On each of the following pages, select a release.
Build Options page: In the .EXE Options field, select one of the WebDeploy
options.
Prerequisites page: In the Windows Installer Runtime Version fields, select

the versions of Windows Installer to install.
WebDeploy page: Specify the same path in all the Download URL fields.
Package Distribution cannot upload to multiple locations.
2. Make sure that a directory exists on the Web server at the URL address you
specified on the WebDeploy page.
3. Run Package Distribution and mark the FTP Server option. In the FTP Upload
Directory field on the FTP Server dialog, make sure you enter the same directory
path specified in the Download URL fields on the WebDeploy page. For details, see
Copying an Installation to an FTP Server on page 285.
Package Distribution uploads all the files needed by the WebDeploy installation to a
single directory on your Web server.
Now you can distribute the installation .EXE. If you will distribute the .EXE from the Web
rather than on CD or other media, create a Web page with a link to the .EXE.
To upload a WebDeploy installation with an FTP client:

1. Make sure that directories exist on the Web server at the URL addresses you
specified in the Download URL fields on the WebDeploy page.
2. Using an FTP client, upload the installation files:
If you are distributing a single-feature .MSI over the Internet, the installation
should be compiled to an .EXE that contains the .MSI. Create a Web page
containing a link to the .EXE file, then upload the .EXE to the location of that
Web page.
Example:
Upload Sample1.exe to http://www.Sample1.com/installs
If you are distributing a multi-feature, install-on-demand application over a

corporate intranet, the installation should be compiled to an .EXE that runs an
external .MSI. Create a Web page containing a link to the .EXE file, then upload
the .EXE to the location of that Web page. Then upload the .MSI and any
external .CAB files to the URL address you specified in the .MSI Download
URL field on the WebDeploy page.
Example:
UploadSample2.exe to http://www.Sample2.com/installations
UploadSample2.msi to http://www.Sample2.com/downloads
If you are distributing the installation via an Autoplay program, the installation
should be compiled to an .EXE that runs an external .INI and .MSI. Save the
Autoplay program and the .EXE and .INI files to a CD or other distribution

media. Then upload the .MSI and any external .CAB files to the URL address you
specified in the .MSI Download URL field on the WebDeploy page.
Example:
Upload Sample3.msi to http://www.Sample3.com/downloads
3. If the installation will pre-install any Windows Installer or .NET runtimes, use an FTP
client to upload the following files:
If you specified a 9x Download URL on the WebDeploy page, upload the file
InstMsi.exe to that Web address.
If you specified a NT Download URL on the WebDeploy page, upload the file
InstMsiW.exe to that Web address.
If you specified a .NET Runtime URL on the WebDeploy page, upload the .NET
Framework file dotnetfx.exe to that Web address. Likewise, if you specified a
.NET Update URL, upload the .NET Framework update file to that Web
address.
If you do not have a copy of the appropriate runtime file, use the Download
Redistributables wizard. See Downloading Redistributable Files on page 35.
4. Distribute the installation media or notify your end users of the Web link to the .EXE.
Setting Up Media for Distribution

Note
The Media page lets you prepare an installation for distribution. Here, you specify
compression, the media’s size, holding directories, and how features and components
are organized on the media. You set media options per release.
If the installation spans more than one media, you can determine which files are placed
on which disk, or you can have it done for you.
To prepare an installation for distribution, perform these tasks:
z Add media items to apply different compression options to different files in

components or features. See Adding a Media Item on page 202.
During compile, the media items are placed in the destination directories in the
order in which they’re listed on the Media page. To rearrange the order, select a
media item and click Move Up or Move Down at the right of the Media page, or drag
the media item to a new position. The .MSI file is an exception. It is always placed in
the first destination directory, no matter where it appears in the list.
z Add destination directories. Destination directories are holding places for the
installation. They represent the disks, CDs, or server you use for distributing your
application. See Adding a Media Destination on page 204.
z Compile the installation.
z Copy the contents from the destination directories onto the media you will use for
distribution.
Note
At least one media item is required. If the Media page contains only one item, you
cannot delete it.

Adding a Media Item

Note
You can add media items to apply different compression options to different files in
components or features.
Example:
Leave a Readme file and a tutorial uncompressed, compress application files inside the
.MSI file, and compress graphic files into external .CAB files. In this case, you would add
these media items:
z Uncompressed Readme
z Uncompressed Tutorial
z Compressed application files
z Compressed graphic files
To add a media item:

1. Select Installation Expert > Media page.
3. Click Add at the right of the Media page. The Media Details dialog appears.
4. In Media Name, describe the media item you’re setting up. Examples: Compressed
Application Files or Uncompressed Tutorial. This name appears on the Media page.
The media name must be unique within a release.
5. In Compression Option, specify how to compress the installation files. This is

disabled if Single-file .EXE is selected on the Build Options page.
Compress files inside .MSI

Wrap all files inside the .MSI, including .CAB files if you select a .CAB option
below.
Compress files into external Cab files

Compress all files into one or more .CAB files outside the .MSI file. CAB files are
like .ZIP files; they contain one or more compressed files.
When you select one of the above compression options, you must select one of the
Cab Options below.
Uncompressed external files

Leave all files uncompressed and outside the .MSI file. If you configured part of
the application to run from the source media, you must use this option. See the
description of the Will be installed to run from source icon in Configuring a
Feature Using Its Drop-Down List on page 104.
If you select this option, you also might want to use short file names for
uncompressed files outside the installation. See the description of Use short
file names for files uncompressed outside of the install in Creating a New
6. In Cab Options, determine the makeup of your .CAB files. To minimize file size, use
fewer .CAB files; to minimize installation time, use more .CAB files. This is disabled
if you select Uncompressed external files from Compression Option above, or
if you are working in an .MSI.

Quickest (new files and modules get cab file)

Any new files that you add to the installation, including merge modules, get
their own .CAB files. This is selected by default in an .MSI.
One Cab (including modules)

Create one large .CAB file for all files and merge modules in the installation.
This option saves some file space by eliminating overlap in .CAB files, but
installation is slower than installing from multiple .CAB files.
One Cab per feature

Every feature in the installation gets its own .CAB file. This option is most
efficient on a CD or similar media, where file size is not an issue.
One Cab per component

Every component in the installation gets its own .CAB file. This option is best for
WebDeploy installations, where only required components are downloaded.
The remaining options on the Media page are enabled in a .WSI only.
7. In the Custom Media Settings area, specify settings that are related to the size of
your media.
Share media destination/size info with previous media entry

Gives a media item the same size and destination settings as its predecessor’s,
therefore, mark this for the second and subsequent media items only. Example:
This makes it easier to create a CD where some files are compressed and others
are not. You can create one or more media items with different compression
options but have them all placed on the same CD.
You can also use this option to have one distribution medium (example: a CD)
filled up before starting to place media items on a second or third distribution
medium. See Example: Spanning an Installation Across Media and Sharing
Media Size Information on page 206.
Max Media Size

Enter the size of the distribution media as a whole number and select the
appropriate unit (KB or MB) from the drop-down list. To indicate unlimited size,
enter 0.
Cluster Size
Select the bytes per sector of the distribution media.
Recommendations for common distribution media:
Media Max Media Size Cluster Size

CD-ROM 550 MB 2048 Bytes
ZIP disk 100 MB or 250 MB 2048 Bytes
Floppy disk 1440 KB 512 Bytes
8. In the Media Destinations section, enter the directory where the installation is
stored before you copy it to the distribution media. Enter one destination for each
distribution medium. For details, see Adding a Media Destination on page 204.
9. In the Include Features/Components section, select the features and

components to include in this media item. For details, see Including Features and
Components in Media Items on page 205.

10. Click OK.
The media item appears on the Media page, in the Media Name column. To edit it,
double-click its name.
Adding a Media Destination

Note
These settings are enabled in a .WSI only.
A media destination is a holding directory for the installation. It has the same capacity
as indicated in the Max Media Size field in the Media Details dialog. During compile, all
files for your installation are placed in one or more destination directories, and you copy
them from there to your distribution media. Enter one destination for each distribution
media. If you don’t create media destinations, that is, destination directories, the files
are copied to the directory where the .WSI file is located.
Example: If your installation is so large that it needs 2 CDs, enter 2 destination

directories. Files are copied to the first destination directory in the list, until the directory
is filled to the maximum media size. Then, the application starts copying files to the
second destination directory.
Note
The .MSI file is always placed in the first directory in the list.
To specify a destination directory:

3. Double-click a media item. The Media Details dialog appears.
4. In the Media Destinations section, click Add. The Media Destination Details dialog
appears.
Destination Directory
Specify the holding directory in which the installation files are stored before
they’re placed on the selected media.
If you specify a maximum media size on the Media Details dialog and do not
specify destination directories, installation files are placed in folders with
generic names (Disk1, Disk2, and so on) in the directory that contains the
project file.
Volume Label
This entry appears in the Label field when you right-click the icon for a volume
in Windows Explorer and select Properties.
It is very important to change volume labels for your disks or CDs to match this
value. Failing to do so will prevent the installation from working properly.
Disk Name
Enter the disk name that should appear when the installation prompts the end
user to insert another disk or CD. Example: Disk2. This only pertains to
installations that require multiple distribution media.
6. Click OK.

During compile, the installation is broken up into the directories you specify. Then, you
must copy the contents of each directory to a disk or CD that has the same name that’s
in the Volume Label field.
Including Features and Components in Media Items

Note
These settings are enabled in a .WSI only.
You can specify the features and components to include in each media item.
By default, All Features/Components are selected to be included. Use this setting in

any of the following instances:
z The installation has only one media item.
z You want to include every remaining feature and component that is not included in a
previous media item.
z It doesn’t matter which files are on which medium.
In any other case, use the Include Items for Media dialog to select the features and
components to include in the current media item. During compile, an error message
notifies you if you have failed to include a feature that has files added to it.
Examples:
z Suppose you want to have an uncompressed Readme file on your distribution

media. In this case, you could create a media item called Uncompressed Readme.
Then, from the list of components to include, you would select the Readme file’s
component for inclusion in this media item.
z Suppose the installation includes a graphic feature with sample images, and you
want to compress these images into an external .CAB file. In this case, you could
create a media item called Compressed graphic files. Then, from the list of features,
you would select the graphic feature for inclusion in this media item.
To include features and components in a media item:

3. Double-click a media item. The Media Details dialog appears.
4. In the Include Features/Components section, click Add. The Include Items for
Media dialog appears.
5. From the drop-down list, specify whether to include components or features.
6. In the list box, select one or more features or components and click OK.
The features or components you selected appear in the Include Features/

Components section on the Media Details dialog. To exclude a feature or component,
select it and click Delete. If you delete all selected features and components, the default
setting of All Features/Components returns.

Sharing Media Settings Between Releases

Note
You can share media settings from a release with other releases in the installation. After
you initially share settings, the settings for the releases are linked. This means that any
change you make to the media settings for any of the linked releases is applied to all
other linked releases. At any time, you can break the link.

2. From Current Release, select a release to copy settings to.
3. Click Share at the right of the Media page. The Share Release dialog appears.
4. From Copy/Share Media Settings From, select the release that contains the
settings to copy.
5. Click OK.
The settings of the release in Copy/Share Media Settings From immediately replace
the settings of the release in Current Release. Any change you make to the media of
either of the linked releases is applied to the other release, until you break the link.

3. Click Share at the right of the Media page. The Share Release dialog appears.
4. From Copy/Share Media Settings From, select <None>.
5. Click OK.
the settings of other release.
Example: Spanning an Installation Across Media and Sharing

Media Size Information
You can span an installation across CDs and use the Share media destinations/size
info with previous media entry option. Suppose the following:
z The files for your application use 1.5 GB of uncompressed disk space.
z You want to distribute the application on 2 CDs.
z For each of the 2 CDs, you can safely assume a maximum size of 550 MB, which
means that you need to compress some, but not all of your files.
z Your application includes some features that are always installed on the destination
computer. These are the files you compress.
z The application also includes some features that the end user can either install or
run from the CD-ROM. These are the files you don’t compress.

This scenario means that you need to create 2 media items:
z One media item for those features and components that are always installed,
compressed into one big .CAB file.
z A second media item for those files that can be run from the CD and that you
therefore don’t compress.
To create media items with shared size information:

The following steps are for the first media item.
2. Click Add at the right of the Media page. The Media Details dialog appears.
3. Complete the dialog.
Media Name
Enter a name for the first media item. Example: Compressed Files.
Compression Option
Select Compress files into external Cab files.
Cab Options
Select One Cab (including modules).
Max Media Size

Enter 550 MB.
Cluster Size
Select 2048 Bytes.
4. In the Media Destinations section, click Add. The Media Destination Details dialog
appears.
5. Make the following entries for the first CD:
C:\My Installation\CD 1
This assumes that you have a directory named My Installation on your C drive.
Volume Label
CD One
It is very important to change volume labels for your disks or CDs to match this
value. Failing to do so will prevent the installation from working properly.
Disk Name
CD 1
6. Click OK.
7. In the Media Destinations section, click Add again. The Media Destination Details
dialog appears.
8. Make the following entries for the second CD:
C:\My Installation\CD 2
Volume Label
CD Two

Disk Name
CD 2
9. Click OK.
10. In the Include Features/Components list, click Add and select the features and
components to compress.
11. Click OK.
The next steps are for the second media item.
12. On the Media page, click Add. The Media Details dialog appears.
13. Complete the dialog.
Media Name
Enter a name for the second media item. Example: Uncompressed Files.
Compression Option
Select Uncompressed external files.
Share media destination/size info with previous media entry.

Mark this checkbox.
Include Features/Components section

Click Add and select the features and components to leave uncompressed.
14. Click OK.
After compile, the destination directory CD 1 contains the .CAB file and as many
uncompressed files as can fit on the CD. All remaining uncompressed files are in the
directory CD 2.

Chapter 9
Advanced Installations
Wise for Windows Installer lets you set advanced installation options and create special
purpose installations such as installations for Web applications.
Topics include:
z About Command Lines.
z Adding a Digital Signature to Your Installation.
z Creating an Installation for Microsoft SMS.
z Creating a .NET Installation When You Have the .NET Framework.
z Creating a .NET Installation Without the .NET Framework.
z About Web Installations.
z Configuring a Microsoft SQL Server During Installation.
z Importing .NET Framework Security Settings.
z MTS/COM+ Page.
About Command Lines

Command lines change the behavior of an .EXE for different work environments and
user requirements. You can work with 2 sets of command lines for installations:
Command Lines You Can Apply to Command Lines You Can Apply to
Installations at Runtime Wise for Windows Installer for
Compiling
Call MSIExec.EXE. Call WFWI.EXE.
Are applied to Windows Installer Are applied to Wise for Windows Installer
installations or patches at runtime. at runtime to compile an installation.
They let you specify UI, logging, Options let you control logging and UI, and
advertising, and repair options. They set default values for properties in the
also let you edit public properties, compiled installation.
apply transforms, and apply or remove
patches.

Command Lines You Can Apply to Command Lines You Can Apply to
Installations at Runtime Wise for Windows Installer for
Compiling
Are documented fully in Command Line Are documented in Wise product
Options and Standard Installer documentation. See Command Line
Command Line Options in the Windows Options For WFWI.EXE on page 217.
Installer SDK Help.
Can be built automatically with the Must be built manually.
Command Line page. See Creating a
Command Line To Apply to an
Installation on page 210. Also build
them manually; see Command-Line
Options in the Windows Installer SDK
Help.
Also see:
WFWI.EXE Command Line Option Example on page 218

Automating the Build Process on page 218
Creating a Command Line To Apply to an Installation

Use the Command Line page in Installation Expert to create syntactically correct
command lines to apply to an installation at runtime. These are applied to MSIExec.EXE
on the destination computer. Command lines you create appear in a popup menu for the
Test and Run buttons so you can test them.
1. Select Installation Expert > Command Line page.
2. Click Add.
The Command Line Details dialog appears.
Note
Although you can enter a command line in the Command Line field, we
recommend that you use the options provided in this utility for an optimal, error-
free installation.
3. Click the General tab and complete the dialog:
Name
Enter the name of the command line.
Shortcut File
Specify the full pathname of the shortcut file (.LNK) you are creating to execute
the command line. The default location is the Temp directory.
You also can create a batch file by changing the file extension to .BAT.
Install Mode
Select an install mode:

Install
Installs or configures the installation package. Select this option to remove
patches.
Advertised
Advertises the installation on the destination computer.
Repair
Repairs an application that is installed on the destination computer.
Network Install
Extracts the files in the installation package to a network location.
Uninstall
Uninstalls the installation package.
Update
Updates the installation package by applying patches.
4. Depending on the install mode you select, additional tabs appear on the Command
Line Details dialog. Following are the tabs that appear and how you can use them to
modify the command line:
UI Options
Make the installation run in silent mode and set the user interface level. See
Applying UI Options to an Installation on page 211.
Logging
Generate a log when the installation is run and select logging options. See
Applying Logging Options to an Installation on page 213.
Advertising
Advertise applications and apply a transform to the advertised package. See
Applying an Advertising Option to an Installation on page 214.
Repair
Repair installed files. See Applying a Repair Option to an Installation on
page 215.
Properties
Change the value of public properties. See Changing Public Properties in an
Transforms
Apply transforms to the installation package using the TRANSFORMS property.
See Applying Transforms to an Installation on page 216.
Patches
Add or remove patches using the PATCH and MSIPATCHREMOVE properties. See
Applying or Removing Patches With a Command Line on page 216.
5. After you modify the command line, click OK.
The command line is added to the Command Line page. To edit it, double-click its name.
To delete it, select it and click Delete.
Also see About Command Lines on page 209.
Applying UI Options to an Installation


You can set the UI options, which determine how much the end user interacts with the
installation. See User Interface Levels in the Windows Installer SDK Help. You can set UI
options for all versions of Windows Installer or for Windows Installer 3.0 only.
1. On the Command Line Details dialog, click the UI Options tab. See Creating a
Command Line To Apply to an Installation on page 210.
2. To enable the UI Options checkboxes, mark Set User Interface level.
3. By default, qn - No UI is marked in the All Windows Installer versions section.

To set options for all versions of Windows Installer, mark the appropriate options in
this section.
qn - No UI
Displays no user interface during the installation.
qb - Basic UI
Displays built-in modeless dialogs that show progress messages during the
installation.
Note
Modal dialogs require user input whereas modeless dialogs don’t.
qr - Reduced UI
Displays authored modeless dialog and built-in modal error-message boxes
during the installation.
qf - Full UI
Displays both modal and modeless dialogs that have been authored into the
internal user interface, and built-in modal error-message boxes during the
installation.
qn+ - No UI
Displays no user interface, except for a modal dialog at the end of the
installation.
qb+ - Basic UI
Displays built-in modeless dialogs that show progress messages during the
installation and a modal dialog at the end of the installation.
qb- - Basic UI
Displays built-in modeless dialogs that show progress messages and no modal
dialogs during the installation.
4. If you mark either the qb+ or qb- option, then the Hide the Cancel Button button
is enabled. Mark this to add the ! switch to the command line, which removes the
Cancel button from the installation dialogs.
5. To set options for Windows Installer 3.0 only, mark one of the following options in
the Windows Installer 3.0 only section. This overrides any options you mark in
the All Windows Installer versions section. (These options are enabled only if
Windows Installer 3.0 or later is installed on your computer.)
Quiet - No UI
Displays no user interface during the installation.
Passive - display a progress bar but no other prompts or messages
6. If you mark Quiet or Passive in the Windows Installer 3.0 only section, you can
also control how Windows Installer handles reboots.

Default (Restart if required)

Restarts the computer when necessary with no prompts or warnings to the user.
No restart
Never restarts the computer after the installation.
Force restart
Always restarts the computer after the installation.
Prompt restart
(Passive only.) Displays a message that a restart is required to complete the
installation and asks the user if they want to restart the computer now.
7. Click OK.
Also see Creating a Command Line To Apply to an Installation on page 210.
Applying Logging Options to an Installation

You can set logging options that determine what activities are logged during the
installation. For information on logging options, see Logging in the Windows Installer
SDK Help. You can set logging options for all versions of Windows Installer or for
Windows Installer 3.0 and later.
1. Click the Logging tab on the Command Line Details dialog. See Creating a Command
Line To Apply to an Installation on page 210.
2. To enable the Logging Options checkboxes, mark Create Log File.
This enables the field to its right, which displays the default location for a log file
created during installation. The default location is the Temp directory.
3. To change the location of the log file, specify a new pathname.
4. To set logging options for all versions of Windows Installer, mark the appropriate
checkboxes in the All Windows Installer versions section:
* - Wildcard, log all information

Logs all information, but does not use verbose output. This is marked by
default. When this checkbox is marked, the first 4 options in this section are
enabled. Clear this checkbox to enable all the other options in this section.
v - Verbose output
Logs more detailed information about each event or error.
+ - Append to existing file

Appends the log to an existing log file.
! - Flush each line to the log
i - Status messages
w - Non-fatal warnings
a - Start up of actions
Logs actions as they are started.

r - Action-specific records
u - User requests
c - Initial UI parameters
Logs the initial user interface parameters.
m - Out-of-memory or fatal exit information
o - Out-of-disk-space messages
p - Terminal properties
e - All error messages
5. To set logging options for Windows Installer 3.0 or later, mark log - log all
information in the Windows Installer 3.0 or later section. This overrides any
options you mark in the All Windows Installer versions section.
Note
This option is enabled only if Windows Installer 3.0 or later is installed on your
computer. It will work on the destination computer only if it has Windows Installer
3.0 or later installed.
6. Click OK.
Applying an Advertising Option to an Installation

Windows Installer can advertise the availability of an application to end users and to
other applications without actually installing the application. If an application is
advertised, only the interfaces required for installing the application are presented to the
end user or other applications, saving time and disk space. End users install the
application by activating the advertised interface.
You can set advertising options that determine who sees the advertised application and
whether a transform is applied to it. For information on advertising options, see
Advertisement in the Windows Installer SDK Help.
1. Click the Advertising tab on the Command Line Details dialog. See Creating a
Note
The Advertising tab appears only when Install Mode on the General tab of the
Command Line Details dialog is set to Advertised.
m - Advertise to all users of machine
u - Advertise to the current user
t - Applies transform to advertised package

Add a transform to the advertised installation.
In the field below the checkbox, specify the transform file to include in the
installation.

3. Click OK.
Applying a Repair Option to an Installation

You can set a repair option for an installation that determines the files that are
reinstalled during a repair. You also can specify whether files are rewritten, overwritten,
or run from the source. For information on repair options, see REINSTALLMODE Property
in the Windows Installer SDK Help.
1. Click the Repair tab on the Command Line Details dialog. See Creating a Command
Line To Apply to an Installation on page 210.
Note
The Repair tab appears only when Install Mode on the General tab of the
Command Line Details dialog is set to Repair.
p - Reinstall only if file is missing
o - Reinstall if file is missing or if an older version is installed
e - Reinstall if file is missing or an equal or older version is installed
d - Reinstall if file is missing or a different version is installed.
c - Reinstall if file is missing or the stored checksum doesn’t match the

calculated value
a - Force all files to be reinstalled
u - Rewrite all required user specific registry entries
m - Rewrite all required machine specific registry entries
s - Overwrite all existing shortcuts
v- Run from source and re-cache the local package
3. Click OK.
Changing Public Properties in an Installation

For information on public properties, see Public Properties in the Windows Installer SDK
Help.
1. Click the Properties tab on the Command Line Details dialog. See Creating a

Note
The Properties tab appears only when Install Mode on the General tab of the
Command Line Details dialog is set to Install or Network Install.
2. Select a property in the left pane and click Add to copy it to the right pane.
3. In the right pane, enter the value for the property.
4. Click OK.
Applying Transforms to an Installation

For information on transforms, see TRANSFORMS Property in the Windows Installer SDK
Help.
1. Click the Transform tab on the Command Line Details dialog. See Creating a
Note
The Transforms tab appears only when Install Mode on the General tab of the
Command Line Details dialog is set to Install.
2. Click Add and specify the transform file (.MST).
The full pathname appears in Transform List.
3. Repeat the preceding step to specify additional transforms.
4. Because Windows Installer applies transforms in the order specified, adjust the
order of the transforms as needed.
5. Click OK.
Applying or Removing Patches With a Command

Line
You can update an installation by applying or removing patches. For information on
patches, see PATCH Property and MSIPATCHREMOVE Property in the Windows Installer
SDK Help.
Prior to Windows Installer 3.0, you could only remove a patch by uninstalling the entire
application. Beginning with Windows Installer 3.0, you can remove a single patch or a
set of patches in any order without uninstalling the application. See Removing Patches
and Uninstallable Patches in the Windows Installer SDK Help.
1. On the General tab, select one of the following from Install Mode. See Creating a

Install
Use this option to remove or apply patches. You can apply patches to an
installed package or to the package being installed by the command line
Update
Use this option to update installed applications.
2. Click the Patches tab on the Command Line Details dialog.
3. Mark whether to add or remove patches. The option to remove patches is enabled
only if Windows Installer 3.0 or later is installed on your computer.
4. Click Add and specify a patch file (.MSP).
The full pathname appears in the Patch List.
5. Repeat the preceding step to specify additional patches. (Windows Installer 3.0 or
later only.)
6. Windows Installer applies patches in the order listed. To rearrange the order, click
Move Up or Move Down. If you used patch sequencing with Windows Installer 3.0
when you created the patches, that sequencing would override the order you specify
here.
7. Click OK.
Command Line Options For WFWI.EXE

You can invoke Wise for Windows Installer (WfWI.exe) with command line options and
pass it the name of your project file (.WSI) as a parameter. WFWI.exe command lines let
you compile an installation, while setting options that have to do with the compile. You
can also set the default value of Windows Installer properties within the installation.
You can also launch Wise for Windows Installer (WfWI.exe) in the Visual MSIDiff mode
using the following command line: WFWI.EXE <base file> <compare file>. For
information on Visual MSIDiff, see Comparing Windows Installer Files on page 85.
Do not confuse this list of command line options with the command line options that you
can apply at runtime to an .MSI via the executable msiexec.exe. For a list of those
command line options, see Command Line Options in the Windows Installer SDK Help.
You can use the Command Line page to build command lines to apply to your .MSI. See
Creating a Command Line To Apply to an Installation on page 210.
Command line options Description

/c Compile only and exit. This must be the
first option in the command line statement.
/releases=<release name 1>, (Visual Studio only.) Compile only the
<release name 2> specified releases from an installation
containing multiple releases.
/c=“release name” Compile only the specified release from an
installation containing multiple releases.
(Not available in the Visual Studio
integrated editor.)

Command line options Description

/p name=value Set property values. The property name
and value must immediately follow the /p.
You can use as many property name and
value switches as you like in a command
line. Do not enter any spaces in the
name=value construction, unless they are
enclosed in double quotes.
/o path Specifies the compiled output file. You
cannot specify a relative path; specify an
absolute path. The path must immediately
follow the /o.
/F Has the same effect as clearing the Don’t
update or recompress files when
saving checkbox on the Product Details
Page on page 92.
/s Causes the compile to be silent. If you
don’t include this, error or informational
dialogs might appear that require user
intervention. (Not available in the Visual
Studio integrated editor.)
/l log file name The /l followed by a log file name makes an
additional compile log file, in addition to
compile.log, which is created automatically.
WFWI.EXE Command Line Option Example

The following example shows how to compile an installation from the command line.
“C:\Program Files\Wise for Windows Installer\WFWI.EXE” C:\Installers\MyApp.wsi /c /s /p

CURRENT_FILES="E:\Test Development" /o C:\MyAppInstaller.msi
The preceding command line does this:
z Invokes the executable.
z Specifies the .WSI to compile (C:\Installers\MyApp.wsi).
z Sets it to compile (/c).
z Sets all error messages to be suppressed (/s).
z Sets the property CURRENT_FILES (/p CURRENT_FILES="E:\Test Development").
z Sets the output location (/o C:\MyAppInstaller.msi).
If you set multiple properties, separate property value pairs with spaces. Enclose values
with double quotes.
Automating the Build Process

You can use WFWI.exe command line options in conjunction with other processes to
create an automated build process.

Enter the following command line statement into a batch file or any other program that
has the ability to run command line statements, such as Scheduled Tasks in the Control
Panel:
WFWI.EXE "C:\Development\Sample.wsi" /c /o "C:\Sample.msi" /s
where:
z WfWI.exe is the path to the Wise executable
z "C:\Development\Sample.wsi" is the path to the project file you want to compile
z "C:\Sample.msi" is the pathname where the output file will be compiled
Adding a Digital Signature to Your Installation

Use the Digital Signature page to add an Authenticode digital signature to an installation
file so its integrity and authenticity can be verified. You must have a valid VeriSign
commercial certificate to use this feature. For information about digital signatures, visit
the VeriSign Web site at www.verisign.com and search for “authenticode.”
To define a digital signature, mark the Add a digital signature option on the Digital
Signature page and complete the page:
z Web URL
Enter your company’s Web site address.
z Descriptive Name
Enter the name of your application. This name is embedded in your Authenticode
certificate to let end users verify the name of the application they are installing.
z TimeStamp URL
Specify the URL you use for your timestamping service. Timestamping lets end
users distinguish between a certificate that’s expired but was valid when it was used
to sign the installation, and a certificate that was used to sign an installation while it
was expired. The timestamping service must be available to build the installation
but does not need to be available to the end user running the installation.
z Credentials File, Private Key File

Specify your VeriSign credentials file and private key file.
z Digital Signature for

Specify which output files should be digitally signed. If you select a type of output
file that is not selected on the Build Options page, this drop-down list is ignored.
Example: If you specify Do not create an .EXE file in .EXE Options on the Build
Options page, and in this drop-down list you select Installation .EXE only, no
digitally signed installation is created, because the installation doesn’t create an
.EXE file.
Note
The ability to add a digital signature to .MSI and external .CAB files is supported
only by Windows Installer 2.0 or later.
Creating an Installation for Microsoft SMS

If an installation will be run in a Microsoft Systems Management Server (SMS)
environment, you can have the installation create a status .MIF file in the Windows
directory to describe the application. In order to use an installation in an SMS

environment, you must also create a package definition file (.PDF or .SMS), which
contains information about the installation. You can create the package definition
file manually, or configure the installation to create it when compiled. For information
about SMS, visit the Microsoft Developer Network (msdn.microsoft.com).
The Microsoft SMS page specifies the information for the .MIF file and package definition
file. Alternatively, you can apply the /m command line option to msiexec.exe to create a
status.mif file. See Command Line Options in the Windows Installer SDK Help.
To have the installation create a status .MIF file and a package definition file, mark
Create Status MIF and complete the page.
z Install MIF Filename

Enter the name of the application being installed. Example: sample.mif.
z Uninstall MIF Filename

Enter the name of the application being uninstalled. Example: uninstall_sample.mif.
z Serial Number
Enter the serial number of the application being installed.
z Package Definition File

To create a package definition file when the installation is compiled, mark one of the
following checkboxes. Verify that the installation’s name, version, and manufacturer
are entered on the Product Details page, because that information is included in the
package definition file.
Create .PDF File (SMS 1.2 or earlier)

Mark this to create a package definition file of file type .PDF. In Version, enter
the SMS version.
Create .SMS File (SMS 2.0 or later)

Mark this to create a package definition file of file type .SMS. In Version, enter
the SMS version.
You can also import an existing Microsoft SMS installation. See Convert SMS Installer or
WiseScript Installation on page 358.
Creating a .NET Installation When You Have the

.NET Framework
The .NET Framework helps automate the process of building a .NET installation by
extracting most of the assembly details from the assembly manifests and adding them
to the installation.
2. In the Application Type field, select either .NET Application or Mixed (.NET and
Win32).
This designates the installation as .NET and determines how Wise for Windows
Installer handles COM interop registry entries. See Product Details Page on page 92.
3. Add assemblies and their dependency files to the installation, using the Files page.
For details, see Adding .NET Assemblies to the Installation on page 124.

Wise for Windows Installer finds all multifile assemblies and adds them
automatically. Depending on the Scan Dependencies option in Wise Options,
dependency assemblies might be added automatically, or you might be prompted to
add them. If the option to Never scan dependencies is selected, you must add
the dependencies.
4. If the destination computer’s operating system is not Windows XP or Windows

Server 2003, add support for the .NET Framework to the installation. On the
Prerequisites page, select the desired release and then select the runtime from
.NET Framework Runtime Version.
For details, see Adding Prerequisites to a Release on page 186.
5. Finish building the installation as usual, then compile and distribute it.
Also see:

Frequently Asked Questions About Microsoft Windows Installer on page 522
Creating a .NET Installation Without the .NET Framework on page 221
Setting a Requirement on the System Requirements Page on page 166 (for information
on setting the required .NET Framework version)
Creating a .NET Installation Without the .NET

Framework
You can build an installation for a .NET application even if you do not have the .NET
Framework installed on your computer. Perhaps your company’s development computers
have the .NET Framework, but the computer you use to build installations does not. If
you do not have the .NET Framework, you must do manually what the .NET Framework
normally does automatically.
2. In Application Type, select either .NET Application or Mixed (.NET and

Win32).
This designates the installation as .NET and determines how Wise for Windows
Installer handles COM interop registry entries. See Product Details Page on page 92.
3. Add assemblies to the installation, using the Files or Web Files page.
For details, see Adding .NET Assemblies to the Installation on page 124. Be sure to
add all files in multifile assemblies.
4. Add attributes and dependencies for each assembly.
a. Use a computer that has the .NET Framework installed and has the assemblies.
This typically is a development computer.
b. For each assembly, run the ildasm tool from the Visual Studio .NET command
prompt. When you run ildasm, you select an assembly and the program displays
the assembly’s attributes. Write down the assembly’s name, publicKeyToken,
and version, as well as any dependencies.

c. On the Files or Web Files page, add the dependency assemblies to the same
directory as the assembly that has the dependencies. Repeat for each assembly.
d. In the lower right pane of the Files or Web Files page, double-click an assembly
to display the File Details dialog. Click the Assembly tab. Click Add to add the
Name and Value of the assembly’s name, publicKeyToken, and version. Repeat
for each assembly. For details, see Editing Assembly Settings for Files on
page 133.
5. If the installation contains both .NET and Win32 components, register the .NET
components for COM interop.
a. Use a computer that has the .NET Framework installed and has the assemblies.
This typically is a development computer.
b. For each .NET assembly, run the Assembly Registration tool (regasm) from the
Visual Studio .NET command prompt. Run regasm with the argument /regfile
and specify a file name.
Example: regasm AssemblyFileName /regfile:RegFileName.reg.
This command generates a .REG file containing the registry entries you need to
allow the .NET assembly to be called as a COM component. Search for
“Assembly Registration Tool (Regasm.exe)” in the MSDN Library
c. On the Registry page, import the .REG file you created for each assembly. See
Adding Registry Keys on page 144.
6. If the destination computer’s operating system is not Windows XP or Windows

Server 2003, add support for the .NET Framework to the installation. On the
Prerequisites page, select the desired release and then select the runtime from
.NET Framework Runtime Version.
For details, see Adding Prerequisites to a Release on page 186.
7. Finish building the installation as usual, then compile and distribute it.
Also see:

Frequently Asked Questions About Microsoft Windows Installer on page 522
Creating a .NET Installation When You Have the .NET Framework on page 220
About Web Installations

You can create an installation that installs Web resources to a Microsoft Internet
Information Server (IIS) by using the Web Files page in Installation Expert.
To learn about file-related functionality on the Web Files page, see Files or Web Files
Page on page 113 and its subtopics.
To learn about Web-related functionality, see:
Features That Support Web Installations on page 223

Creating a Web Site on page 224
Creating a Virtual Directory on page 226

Creating a New Web Folder on page 228

Setting Installation Options for a Web Installation on page 229
Setting Installation Options for a Child Virtual Directory on page 230
About the Web Site Details Dialog on page 232
Installing Web Settings From a File on page 233
Note
If you cannot see the Web Files page in the list of pages in Installation Expert, select
Web Application or All from the Page Views drop-down list in the upper left corner.
Differences Between the Files Page and Web Files Page
Files page Web Files page

Can create directories and add files to Can create Web folders, virtual
them. directories, and Web sites, and add files
to them.
Can set NTFS-based (NT file system) Can set Web-based security on
permissions on directories. directories.
Shows all directories and files to be Shows only directories and files to be
installed, including Web items. accessible via an IIS Web server.
Shows Web sites under the physical Shows Web sites in the hierarchy as they
directory where they will be installed. will appear in IIS Internet Services
Manager.
Contains the wwwroot directory, which Does not contain wwwroot, but you can
represents the physical InetPub\wwwroot map a virtual directory to a physical
directory on the destination computer. directory you created under wwwroot on
the Files page.
Cannot delete a physical directory that is Can delete a virtual directory or Web
mapped to a virtual directory or Web site, and a message asks if you want to
site. delete the corresponding mapped
physical directory and files.
Features That Support Web Installations

In addition to the Web Files page, several features throughout the product specifically
support Web application installations:
Dynamic Editing of XML files

The Dynamic Content tab appears for valid XML files, such as Web.config, that you add
to the installation. Use it to edit the attributes in an XML file by substituting the value of
Windows Installer properties at runtime. Gather the values of properties using the
Custom Property Dialog below. See Editing XML Files During Installation on page 137.

Custom Property Dialog

The Custom Property Dialog provides an easy way to let the end user specify values for
Windows Installer properties. You can use these properties to populate an XML file, as
described above. See Adding the Custom Property Dialog on page 455.
SQL Connection Dialog

Let the end user select a SQL Server name and security credentials to generate a valid
SQL Server connection string; see About the SQL Connection Dialog on page 452. The
connection string can then be used elsewhere, such as in a Web.config file or on the SQL
Server Scripts page.
ASPNET Properties
The default ASP .NET users that are set by .NET installations are put into Windows
Installer properties: ASPNET_USER, ASPNET1.0_USER, and ASPNET1.1_USER. You can
use these for setting directory security. See Runtime Properties on page 424.
Directory Security
You can set NTFS directory security, which enhances Web site security. See Setting
Permissions for Files and Directories on page 132.
Wildcard Groupings
To make it easier to quickly add all files of specific types, such as all Web file types, you
can set up Wildcard groups in Options. Then, when you add the contents of a directory
on the Files or Web Files page, you can choose a wildcard group to filter on. See Setting
Wildcard Groups on page 54.
Check for IIS Version

On the System Requirements page, you can require a specific version of Microsoft
Internet Information Server (IIS). Once you set an IIS version, a list of Web extensions
appears, and you can check whether they are enabled. However, the Web extensions are
only valid on destination computers with IIS 6.0 later.
Enhanced Scanning of Solutions in Visual Studio

If your Visual Studio .NET solution contains a Web application project, and you create a
Wise Web Application installation project, the scanning process intelligently adds Web
content files in addition to traditional output files.
Instance Transforms
You can install more than one instance of a Web application to multiple virtual directories
using instance transforms; see Multiple Instance Installations on page 352.
Also see About Web Installations on page 222.
Creating a Web Site

New Web sites that you add to an installation appear under the Program Files directory
by default. Microsoft Internet Information Server (IIS) supports the creation of new Web

sites only on server operating systems, which excludes Windows 2000 Professional and
Windows XP. To let end users install to workstation operating systems, you can allow a
Web site to be created as a virtual directory; see Install as Virtual Directory on
Workstation in Setting Installation Options for a Web Installation on page 229.
To create a Web site:

1. Select Installation Expert > Web Files page.
If you don’t see the Web Files page, select All from the Page Views drop-down list.
is selected.)
3. If the Web installation requires a Web server restart, mark Restart IIS service
during installation. This checkbox does not appear when All Features is selected
above.
4. In the lower left list box, select a parent node.
5. Click New and select New Web Site.
The New Web Site dialog appears.
Description
Enter a description for the directory, which serves as an identifying name in
Internet Information Services.
Local Path
Specify the physical directory to which the Web site is mapped. You can browse
to any directory that has already been added to the installation. Example:
Change this to a directory under wwwroot to have this item reside under
wwwroot.
7. Click OK.
The site appears in the lower left list box.
8. Select the new site and click Details.
The details dialog appears with several tabs.
9. Click the Installation Settings tab and complete the tab:
Override Existing Settings

If an installation with the same name as this one is already on the destination
computer, specify whether to retain existing settings (None) or override
existing settings (All).
10. Click the Web Site UI tab. Use this tab to specify the installation options that will be
available to the end user at run time. For details, see Setting Installation Options for
a Web Installation on page 229.
11. Complete the remaining tabs on the details dialog. These tabs correspond to options
on the properties dialog in IIS, version 5.0. Use them to specify which options are
user-configurable at run time. For information on these tabs, see the IIS help. Also
see About the Web Site Details Dialog on page 232.
12. Click OK on the details dialog.

Note
Clicking OK on the details dialog regenerates the Web dialogs in the installation.
To delete a Web site:

z On the Web Files page, in the lower left list box, select a Web site and click Delete.
At the prompt that appears:
Click Yes to delete the corresponding physical directory and files.
Click No to clear the Web Folder settings but leave the folders and files in the
installation and the lower-left pane.
If the Delete button is disabled, it means you have selected a normal folder instead
of a Web site. To delete a normal folder from the installation, use the Files page.
On the Files page or Visual Studio Solution page, you cannot delete a physical directory
that is linked to a Web site.
To change a Web site to a virtual directory:

z On the Web Files page, in the lower left list box, right-click a Web site and select
Change to Virtual Directory.
Any Web dialogs in this installation are regenerated.
Settings on the details dialog that do not apply to virtual directories are disabled.
However, if you change this back to a Web site, those settings are retained. For
information on Web site settings, see Setting Installation Options for a Web Installation
on page 229 and About the Web Site Details Dialog on page 232.
Creating a Virtual Directory

This section covers creating a virtual directory, converting an existing installation
directory to a virtual directory, adding a directory from your computer as a virtual
directory, and deleting a virtual directory.
A virtual directory is considered top-level if it is directly under Destination Computer,

and is considered a child if it is under a Web site.
To create a virtual directory:

is selected.)
3. If the Web installation requires a Web server restart, mark Restart IIS service
during installation. This checkbox does not appear when All Features is selected
above.
4. In the lower left list box, select a parent node.

5. Click New and select New Virtual Directory.
The New Virtual Directory dialog appears.
Alias
Enter an alias for the directory. This typically appears in the URL to this Web
resource.
Local Path
Specify the physical directory to which the alias is mapped. You can browse to
any directory that has already been added to the installation and create an
additional directory (optional) by typing its name in this field.
7. Click OK.
The virtual directory appears in the lower left list box.
8. Select the new virtual directory and click Details.
The details dialog appears with several tabs. For a top-level virtual directory, the
Web Site, Web Site UI, and Home Directory tabs appear. For a child virtual directory,
the Virtual Directory and Virtual Directory UI tabs appear. The remaining tabs are
the same for both types of virtual directory.
9. Click the Installation Settings tab and complete the tab:
Override Existing Settings

If an installation with the same name as this one is already on the destination
computer, specify whether to retain existing settings (None) or override
existing settings (All).
Remove on Uninstall
(Top-level virtual directories only.) Mark this to have this virtual directory
removed (unregistered) from IIS during uninstall. This does not uninstall the
physical directory and files—the normal uninstall mechanism handles that.
10. To specify the installation options that will be available to the end user at run time,
do one of the following:
If this is a top-level virtual directory, click the Web Site UI tab. For details, see
Setting Installation Options for a Web Installation on page 229.
If this is a child virtual directory, click the Virtual Directory UI tab. For details,
see Setting Installation Options for a Child Virtual Directory on page 230.
11. Complete the remaining tabs on the details dialog. These tabs correspond to options
on the properties dialog in IIS, version 5.0. Use them to specify which options are
user-configurable at run time. For information on these tabs, see the IIS help. Also
see About the Web Site Details Dialog on page 232.
12. Click OK on the details dialog.
Note
To add a directory from your computer as a virtual directory:

1. On the Web Files page, manually create a virtual directory with the name of the
directory on your computer.
2. In the upper left list box, navigate to and select the directory on your computer.

The Add Contents dialog appears.
4. In Dest. Directory, clear the name and then click OK.
The contents are added into the virtual directory. If you don’t first clear the Dest.
Directory field, then the directory is added as a Web folder.
To map an existing physical directory to a virtual directory:

Use this procedure if you have already created a directory on the Files page or a Web
folder on the Web Files page, and you now want to map that directory to a virtual
directory.
1. On the Web Files page, in the lower left list box, select a parent node.
2. Click New and select New Virtual Directory.
The New Virtual Directory dialog appears.
Alias
Enter an alias for the directory. This appears in the URL to this Web resource.
Local Path
Browse to the existing directory to be mapped to a virtual directory.
4. Click OK.
To delete a virtual directory:

z On the Web Files page, in the lower left list box, select a virtual directory and click
Delete.
A message asks if you want to delete the corresponding physical directory and files.
On the Files page or Visual Studio Solution page, you cannot delete a physical directory
that is linked to a virtual directory.
To change a virtual directory to a Web site:

z On the Web Files page, in the lower left list box, right-click a top-level virtual
directory and select Change to Web Site. (You cannot change a child virtual
directory.)
Any Web dialogs in this installation are regenerated.
Settings on the details dialog that do not apply to Web sites are disabled. However, if
you change this back to a virtual directory, those settings are retained. For information
on virtual directory settings, see Setting Installation Options for a Web Installation on
page 229 and About the Web Site Details Dialog on page 232.
Creating a New Web Folder


is selected.)
3. In the lower left list box, select a Web site or virtual directory.
4. Click New and select New Web Folder.
5. Enter a name for the directory and click OK.
6. Select the new directory and click Details.
The details dialog appears with several tabs.
7. Complete the tabs on the details dialog. These tabs correspond to options on the
properties dialog in IIS, version 5.0. For information on these tabs, see the IIS help.
Also see About the Web Site Details Dialog on page 232.
Setting Installation Options for a Web Installation

An important part of setting up a Web installation is specifying the installation options
that will be available to the end user at run time. To do so, use the Web Site UI tab,
which appears on the details dialog for Web sites and top-level virtual directories. If the
virtual directory is under a Web site, then see Setting Installation Options for a Child
Virtual Directory on page 230.
You set options for each Web site or virtual directory you have added on the Web Files
page. Setting installation options adds Web (IIS) dialogs to the installation. If you omit
the procedure below, no Web dialogs appear to the end user, and the installation
attempts to apply the defaults for all items.
Caution
Do not edit the Web (IIS) dialogs, except to change their order (as a group) in the
installation sequence. Editing the Web dialogs might cause unexpected, undesirable
behavior, including damage to the installation. Also, any operation within this product
that affects the installation’s user interface will regenerate the Web dialogs, therefore,
any changes you make to them will be lost.
To set installation options:

2. In the lower left list box, select a Web site or a top-level virtual directory and click
Details. If you don’t see the item you want, make sure you have the correct feature
selected in Current Feature.
3. Click the Web Site UI tab.
4. To display installation dialogs to the end user at run time, mark Display Run-Time
UI. This adds Web dialogs to the installation.

If this is a top-level virtual directory, no other options are available. Skip the
remaining steps and click OK.
If this is a Web site, the remaining options on the tab are enabled when you mark
this checkbox.
Note
If the current installation was built in an older version of Wise for Windows Installer,
you are prompted to first convert the dialogs on the Dialogs page. Converting resets
navigation and conditions, so if you have customized the dialogs, back up this
installation before converting.
5. Complete the User Installation Options section:
New Web Site

Mark this to let end users install Web resources to a new Web site. However,
even if you mark this, this will not be an available option if the operating system
of the destination computer does not support the creation of new Web sites.
Existing Web Site

Mark this to let end users install Web resources to an existing Web site. They
will see a list of existing Web sites to choose from.
Virtual Directory
Mark this to let end users install Web resources to a virtual directory. If you
select only this option, then this Web site will be installed as a virtual directory.
Install as Virtual Directory on Workstation

This applies only if the New Web Site option above is marked, and the
installation is installed to an operating system whose IIS version does not
support creation of a new Web site. This option ensures that end users can
install to a virtual directory even if you did not mark it above. Otherwise, the
installation will fail because it is trying to force a Web site to be created when
the IIS version disallows it.
6. Complete the New Web Site Prompts section.
These options are enabled if you mark New Web Site above. Mark the items that
the end user should be able to configure during installation. These items correspond
to options on the properties dialog in IIS. See About the Web Site Details Dialog on
page 232.
7. Click OK.
Note
Setting Installation Options for a Child Virtual Directory

An important part of setting up a Web installation is specifying the installation options
that will be available to the end user at run time. To do so, use the Virtual Directory UI
tab, which appears on the details dialog for child virtual directories. If the virtual

directory is directly under Destination Computer, then see Setting Installation Options
for a Web Installation on page 229.
You set options for each Web site or virtual directory you have added on the Web Files
page. Setting installation options adds Web (IIS) dialogs to the installation. If you omit
the procedure below, no Web dialogs appear to the end user, and the installation
attempts to apply the defaults for all items.
Caution
To set installation options:

2. In the lower left list box, select a child virtual directory and click Details. If you don’t
see the item you want, make sure you have the correct feature selected in Current
Feature.
3. Click the Virtual Directory UI tab.
4. To display installation dialogs to the end user at run time, mark Display Run-Time
UI. This adds Web dialogs to the installation. When you mark this checkbox, the
remaining options on the tab are enabled.
Note
If the UI is disabled for the parent Web site, then Web dialogs are not generated for
this child virtual directory.
Note
If the current installation was built in an older version of Wise for Windows Installer,
you are prompted to first convert the dialogs on the Dialogs page. Converting resets
navigation and conditions, so if you have customized the dialogs, back up this
installation before converting.
5. Complete the tab:
Web Resources Location:
New Virtual Directory

Mark this to let end users install Web resources in the named virtual
directory to a new virtual directory.
Existing Virtual Directory

Mark this to let end users choose to install Web resources to an existing
virtual directory. They will see a list of existing virtual directories to choose
from.
Let End Users Rename Virtual Directory at Run Time

Mark this to let end users enter a new name and parent directory for the virtual
directory, other than the name you set by default on the Web Files page.
6. Click OK.

Note
About the Web Site Details Dialog

If you select a directory, virtual directory, or Web site on the Web Dialogs page and click
Details, a multi-tabbed details dialog appears. Most tabs on this dialog correspond to
those in Microsoft Internet Information Server’s (IIS) Internet Services Manager, version
5.0. For information on these tabs, see the IIS help.
Tabs that do not appear in IIS:

z Installation Settings
Lets you override existing settings when installing over an existing Web site or
virtual directory. See Creating a Web Site on page 224 or Creating a Virtual
Directory on page 226.
z Web Site UI
(Web sites and top-level virtual directories.) Lets you specify the installation options
that will be available to the end user at run time. See Setting Installation Options for
a Web Installation on page 229.
z Virtual Directory UI
(Child virtual directories only.) Lets you specify the installation options that will be
available to the end user at run time. See Setting Installation Options for a Child
Virtual Directory on page 230.
Options in Wise for Windows Installer That are Different From IIS:
z On the Web Site tab, you can only specify one identity for a Web site (consisting of
an IP address, port, and host header), whereas in IIS you can specify multiple
identities.
z The Web Site tab lacks the Connections and Logging sections.
z The Home Directory and Virtual Directory tabs lack the options to specify where the
content should come from.
z The Directory Security tab lacks the IIS options for IP address and domain name
restrictions and Secure communications. The navigation of this tab is also different
from IIS.
z The HTTP Headers tab lacks the ability to edit content ratings.
How Options Are Set on the Web Server

When you install a Web site or virtual directory that already exists, you can control
whether settings are changed on the Web server. Use the Override Existing Settings
drop-down list on the Web site details dialog > Installation Settings tab.

Installing Web Settings From a File

You can let the end user run your Web installation on multiple computers and set the
same settings on each one without having to step through the Web dialogs. Example: An
end user, who operates a Web farm, wants to run your installation with the same Web
site settings on 12 computers.
This is accomplished by a Web settings XML file that is generated by the end user from a
special command line. The end user can edit this XML file to set the Web installation
options they want. When the end user runs the installation with another special
command line, the Web installation settings are obtained from the XML file.
The XML file can be created and used during the initial installation only. Using the
command lines during a reinstall or uninstall does not work. Instead, the .MSI runs as it
normally would for the reinstall or uninstall.
About the Web Settings XML File:

z The XML file is generated for a specific operating system type. If the end user
creates the XML file on a server-class computer, those settings cannot be installed
on a workstation, and vice versa.
z The XML file is generated for a specific .MSI and should only be used with that .MSI.
z The XML file is generated for a specific version of Wise for Windows Installer and can
only be used with that version.
z The XML file contains the default Web site settings that you have set in the
installation.
z If the installation contains a Web site, the XML file cannot be generated on a
workstation.
z End users should limit their editing to the sections in the XML file that are
commented. These generally are settings that appear in the Web dialogs, that is,
settings that appear on the Installation Settings, Web Site UI, and Virtual Directory
tabs on the Web site details dialog. Editing non-commented settings can cause the
installation to fail or cause IIS to be configured improperly. We cannot provide
technical support for such problems.
To install Web settings from a file:

This procedure is performed by end users. If you will let your end users use this feature,
you must provide them with this information.
1. Run the installation with the following command line:
msiexec.exe /i "PathToMsi.msi" WISE_CONFIG_OUTPUT_PATH="PathToWebSettingsFile.xml"
where PathToMsi.msi is the full path to the installation and

PathToWebSettingsFile.xml is the full path to where the XML should be created.
The default Web site settings are written to the XML file specified in the command
line. The installation itself is not performed and a Setup Canceled dialog appears.
2. Edit the XML file to set the desired options and then save the changes.
Follow the guidelines at the beginning of the XML file. Only edit settings that are
commented.

3. On the destination computer, run the installation with the following command line:
msiexec.exe /i "PathToMsi.msi" WISE_CONFIG_INPUT_PATH="PathToWebSettingsFile.xml"
where PathToMsi.msi is the full path to the installation and

PathToWebSettingsFile.xml is the full path to the edited XML file.
The installation uses information in the XML file to configure the Web settings. Web
dialogs do not appear during installation.
Configuring a Microsoft SQL Server During

Installation
Use the SQL Server Scripts page to create or configure Microsoft SQL Server databases.
You might use this page if the application you are installing is a database application and
depends on certain database content and configuration. This page eliminates the need
to require end users to configure databases manually.
On this page, you specify a connection string and SQL statements, which are executed
during installation. Thus you have the ability to do any configuration that is possible with
SQL statements. You can generate SQL statements in 3 ways:
z Type or paste SQL statements.
z Import SQL statements from a file.
z Specify a database to recreate, and the necessary SQL statements are generated
automatically.
To configure an installation to run a SQL script:

1. Select Installation Expert > SQL Server Scripts page.
See Tips on Using the SQL Server Scripts Page on page 235.
is selected.)
3. Click Add at the right side of the page.
The SQL Script Details dialog appears.
4. Click the Connection tab and specify a name for the SQL script and a connection
string that connects to the database the installation modifies.
For details, see Setting SQL Connection Strings on page 235.
5. Click the Statements tab and specify SQL statements to be executed on the
destination computer.
For details, see Specifying SQL Statements on page 236.
6. Click the Replacement tab and specify text strings to be found and replaced within
the SQL statements at install time.

For details, see Specifying Replacements in SQL Statements on page 237.
7. Click OK on the SQL Script Details dialog.
The script is added to the list on the SQL Server Scripts page.
8. The SQL scripts are executed in the order they appear on the SQL Server Scripts
page. To rearrange the order, select a statement name and click Move Up or Move
Down.
For information on setting the required SQL Server version, see Setting a Requirement
on the System Requirements Page on page 166.
Tips on Using the SQL Server Scripts Page

z Add the SQL Connection dialog to an installation to create a valid connection string
for a SQL Server located anywhere on the network of the destination computer. See
About the SQL Connection Dialog on page 452.
z Uninstall won’t roll back the changes performed by the SQL statements.
z Databases are connected to and configured through the ODBC driver on the
z The SQL scripts you specify are saved to a file with the same name as the script
name you specify, with the extension .SQL The file is added to the installation. This
file appears on the Files page under a Temp directory. During installation, this file is
installed, its statements are executed, and then it is deleted. Do not remove this file
from the installation.
z The SQL Server Scripts page does not provide error checking for valid SQL syntax or
debugging for failed statements. Make sure the SQL code you enter is well-tested
before deployment. If errors occur during installation, the end user will see SQL
error dialogs.
Note
These tips assume familiarity with SQL Server statement syntax and debugging.
Technical Support does not provide assistance with debugging SQL statements.
Also see Configuring a Microsoft SQL Server During Installation on page 234.
Setting SQL Connection Strings

1. Click the Connection tab on the SQL Script Details dialog. See Configuring a
Microsoft SQL Server During Installation on page 234.
Name
A name for the SQL script is generated and displayed here. You can accept the
default or enter a more descriptive name. If you later change this field, the
script file is not renamed.
A file with this name and the extension .SQL is added to the installation.

Connection String
Enter a connection string that connects to a specific Microsoft SQL Server and
database. The default connection string works for most locally installed SQL
Server databases.
If you use the SQL Connection dialog in this installation, enter the Windows
Installer property WISE_SQL_CONN_STR enclosed in brackets. This property is
populated with a valid connection string when the end user completes the SQL
Connection dialog and clicks Next. See About the SQL Connection Dialog on
page 452.
If your application connects to more than one SQL Server during installation,
add a SQL Connection dialog for each additional server, edit the additional
dialogs, and use a different property for each connection string. See Editing
Additional SQL Connection Dialogs on page 454.
The database you specify here must be accessible through ODBC on the
destination computer. If you have a database registered in ODBC on your own
computer, you can click Browse to select it, and the connection string is
generated. For this to work, the destination computer must have access to the
same database.
3. Click OK.
Also see Tips on Using the SQL Server Scripts Page on page 235.
Specifying SQL Statements

1. Click the Statements tab on the SQL Script Details dialog. See Configuring a
2. To import a file containing SQL statements, click Import SQL File and specify a .SQL
or .TXT file that contains SQL statements.
The statements appear on the Statements tab, where you can edit them. If you
later change the file on disk, you must re-import the file to include the changes in
the installation.
3. To generate statements that recreate a database, click Recreate Database.
The Recreate Database dialog appears.
Connection String
Specify a connection string to the Microsoft SQL Server and database. It must
be accessible to your computer. If it is registered as an ODBC data source on
your computer, click Browse to select it, and the connection string is generated.
Database Name
Enter a name for the database to be created on the destination computer.
Import Data Rows

Mark this to populate the database’s tables with all its current data. This is
unavailable until you mark the Import Tables checkbox below.
Import Views
Mark this to import the defined views of the database.

Import Procedures
Mark this to import the defined procedures of the database.
Import Tables
Mark this to import blank tables from the database. This does not import the
data (mark Import Data Rows to import data). You can import all tables, only
certain tables, or all tables except certain tables. For the last 2 options, enter a
list of table names delimited by commas.
Refresh when installation is compiled

Mark this to have the SQL statements regenerated from the actual database
when you compile this installation. This causes the compile to take longer. Do
not edit the SQL statements on the Statements tab, because they will be
overwritten during compile.
Remove this database first

Mark this to delete this database, if it already exists on the SQL Server, before
execution of the SQL statements. If this checkbox is cleared, and the database
already exists, then any overlapping tables are overwritten on the destination
computer, new tables are added, and non-overlapping tables are left as-is. This
results in a composite database that is mixture of new and old.
5. Click OK.
Note
Error checking or debugging is not available for statements that you type or import.
Make sure the SQL code you enter is well-tested before deployment. If errors occur
during installation, the end user will see SQL error dialogs.
Specifying Replacements in SQL Statements

You can specify text strings to be found and replaced within the SQL statements during
installation.
1. Click the Replacement tab on the SQL Script Details dialog. See Configuring a
2. Click Add.
The Add Replacement dialog appears.
Text to Find
Enter regular text or formatted text, such as a bracketed property name. If you
enter formatted text, it is resolved before the find and replace takes place.
Example: If you enter [INSTALLDIR], the find and replace searches for the
value of INSTALLDIR.
Replace With
Enter regular text or formatted text, or select a current Windows Installer
property from the drop-down list. If you enter formatted text, items are
replaced with the value of the formatted text. This is useful for creating dynamic
installations. Example: Suppose you are creating a new database on the server.

Place an edit field on a dialog asking for the new database name. The answer is
stored in a property, which you could then use in this field, replacing the current
database name.
4. Click OK.
Note
Keep in mind that any matching string is replaced, so only replace strings you know to
be unique. Example: If you replace “Red” with “Blue,” a “PreparedStatement” object in a
SQL statement becomes “PrepaBlueStatement” and breaks the code.
Importing .NET Framework Security Settings

Use the .NET Framework Security page to import .NET Framework security settings from
your computer into an installation for a .NET application that you are deploying using
no-touch deployment. No-touch deployment lets system administrators deploy .NET
desktop applications via a remote Web server without altering the end user’s registry or
shared system components. Search for “No-Touch Deployment in the .NET Framework”
in the MSDN Library (msdn.microsoft.com/library/).
When an end user downloads your .NET application using no-touch deployment, they
need specific security settings to be able to run the application. You import these
security settings from your computer into the installation. When the application is
downloaded, the settings you imported into the installation change the client’s security
settings and enable the application to run.
To be able to import security settings using the .NET Framework Security page, you
must have the .NET Framework installed on your computer. You create and configure
.NET Framework security settings using the Microsoft .NET Framework Configuration
tool, which is in Administrative Tools in your computer’s Control Panel. The .NET
Framework security settings consist of a hierarchy of code groups. When you import
.NET Framework Security settings, you import one or more of these code groups.

Properties and
Code groups on values of the
your computer. code group last
selected in the
upper-left pane.
Properties and
Code groups you values of the
have imported code group last
from your selected in the
computer into lower-left pane.
the installation.
To import .NET Framework security settings:

1. Select Installation Expert > .NET Framework Security page.
is selected.)
3. In the upper-left list box, navigate to and select the code group that contains the
security settings.
4. Click Add Code Group to add the code group to the installation.
The code group appears in bold type in the lower-left pane. If you import a child
code group, any parent code groups also appear but are not in bold type. These
parent code groups contain no security settings, but maintain the correct
hierarchical structure for the code groups.
To delete a .NET Framework security code group from the installation, select it in the
lower-left list box and click Delete. If the code group has parent code groups that are
not in bold type, they do not need to be deleted. They are removed when you exit the
.NET Framework Security page.
Also see About Microsoft .NET Technology on page 524.
MTS/COM+ Page

Use the MTS/COM+ page to add MTS or COM+ application packages to an installation.
The MTS/COM+ page is intended for software developers who know the computer
names of the servers that contain MTS or COM+ server applications.
Both MTS (Microsoft Transaction Server) and COM+ are steps in the evolution of the
Component Object Model (COM) technology. MTS, which was developed first, is a
transaction processing system for developing, deploying, and managing server
applications. MTS Server is an add-on that runs on Windows NT 4.0.
COM+, the next generation of COM technology, is part of the operating system on
Windows 2000, XP, and Server 2003. It provides a standard that lets any two
components communicate with each other regardless of what computer each is running
on, the operating systems that are running, and the language in which the components
are written. COM+ ships with and requires Microsoft Windows 2000, XP, or Server 2003.
All computers can communicate via COM if they have support for DCOM (Distributed
Component Object Model) installed.
MTS or COM+ packages generally consist of server software and client software. When
you add an MTS or COM+ package to an installation, you must designate it as either a
server installation or a client installation. You cannot add both the server and client
installation for a given MTS or COM+ application to the same feature. If you need to
install both the server and client of the same application, either create two .MSI files, or
put the server installation in one feature, and the client installation in another feature. If
the MTS or COM+ application contains roles, those roles are not installed on destination
computers.
Also see Adding an MTS or COM+ Application on page 240.
Adding an MTS or COM+ Application

1. Make sure that you have either MTS or COM+ on your computer, and that the MTS
or COM+ server application is installed and configured on your computer exactly as
it should be configured on the destination computer.
Note
(Optional) You can add the files that make up the MTS/COM+ application on the
Files page. This lets you place the files in any directory structure. Otherwise, the
files are placed in the Program Files\{GUID}\ directory. If you add the files yourself,
you must mark the Use Existing Source Paths checkbox later in this procedure.
2. Select Installation Expert > MTS/COM+ page.
is selected.)
Click Add at the right of the MTS/COM+ page.
The MTS/COM+ Application Details dialog appears.

Application Name
Specify the MTS/COM+ application. You can only select from currently installed
applications.
GUID
(Read-only.) This contains the GUID of the MTS/COM+ application that you
select.
Installation Type
Select the installation type:
Client
Installs the client portion of the MTS/COM+ application. This installation type
requires a remote server name. In Remote Server Name, enter the name
of the computer on the network that will contain the MTS/COM+ server
application the client will connect to. If you design the installation so that the
server name is placed into a property dynamically during the installation
wizard dialogs, you can enter that property name here, surrounded by
brackets.
Server
Installs the server portion of the MTS/COM+ application.
Refresh/Update Application on Compile

Mark this to refresh the MTS/COM+ application from your computer's
Component Services control panel each time you compile the installation. If you
clear this checkbox, the MTS/COM+ application information is copied
immediately to this installation and is not refreshed during compile. Example:
You might use this option if you need to transfer the installation to a computer
that does not have the same MTS/COM+ application installed. If it is set to
refresh and the MTS/COM+ application is not found, an error occurs during
compile.
Use Existing Source Paths

Use this option to prevent the MTS/COM+ files from being added to the default
location on the Files page. This lets you place the files on the Files page in the
directory you choose. You must add the files that make up the MTS/COM+
application to the Files page before marking this checkbox. Otherwise, you will
get an error during compile.
5. Click OK.
The information you entered above is stored in the WiseComPlusApp and

WiseComPlusComponent tables in the Windows Installer database.
Also see MTS/COM+ Page on page 239.

Chapter 10
Mobile Devices

The Mobile Devices page lets you create and configure installations that support
installation to mobile devices: Pocket PC, Smartphone, and Palm. The Mobile Device
Package Editor tool lets you edit existing .CABs or quickly create a simple new .CAB.
Topics include:
z Mobile Devices Page Compared to Mobile Device Package Editor.
z About the Mobile Devices Page.
z About Mobile Device Package Editor.
z Pocket PC and Smartphone Installations.
z How a Pocket PC or Smartphone Installation Works.
z Processor and Platform Support for Pocket PC.
z Compiling a Pocket PC or Smartphone Installation.
z Creating a Pocket PC or Smartphone Installation.
z Palm OS Installations.
Mobile Devices Page Compared to Mobile Device

Package Editor
Wise for Windows Installer has the following 2 features for installing your application to
mobile devices:
Mobile Devices Page

Use this page in Installation Expert to add mobile device support to an .MSI-based
installation. Using the Mobile Devices page, you can:
z Add support for multiple mobile device platforms and processors. Each time you
compile the .MSI, the necessary .CABs are recompiled and wrapped inside the .MSI.
When the .MSI runs on a desktop computer that has an attached mobile device, the
appropriate .CAB is extracted from the .MSI and installed onto the mobile device.
z Create a single .MSI installation that installs to the desktop computer and the
mobile device.
z Close the installation, re-open the installation, and continue editing mobile device
support from where you left off.
See About the Mobile Devices Page on page 243.

Mobile Devices
Mobile Device Package Editor Tool

Use this tool, available from the Tools menu, to quickly create a simple .CAB file or to
edit the resources of an existing .CAB file. (In Visual Studio: available from the Projects
menu.) This tool has the following limitations:
z You cannot close the .CAB, re-open the .CAB and continue editing where you left off.
When you create a new .CAB, you can compile the .CAB, but you cannot save the
settings that were used to create the .CAB.
z Once you exit the tool, you can re-open the .CAB, but you cannot edit the platform
or processor information for the .CAB or for any individual resource within the .CAB.
See About Mobile Device Package Editor on page 244.
About the Mobile Devices Page

Note
To see the Mobile Devices page, select one of these views from the Page Views drop-
down list in Installation Expert: All, Palm Application, Pocket PC Application, Smartphone
Application.
When you add support on the Mobile Devices page, the installation that you create is an
.MSI-based installation, which can only be installed on a desktop computer. However,
the .MSI-based installation installs files that support the mobile device software. Thus
any mobile device installation is a two-part process: the .MSI-based installation is
installed onto the desktop computer, and then the appropriate device installation is
installed.
The advantage of using an .MSI-based installation that also installs to mobile devices is
that the mobile device installation can be part of a larger installation that installs
software to the desktop computer. This lets you install your main application to a
desktop computer and simultaneously install support for any mobile device—Pocket PC,
Smartphone, Palm—that the user has. The ability to install to all platforms at once,
including Windows, simplifies the installation process for you and the end user.
In addition, if the installation supports the Pocket PC 2002 platform, you can
automatically install the .NET Compact Framework, a version of .NET designed for
mobile devices. If you don’t have the .NET Compact Framework runtime, and you
include it, the Download Redistributables wizard appears and prompts you to download
it.
Also see:
Mobile Devices Page Compared to Mobile Device Package Editor on page 242
Pocket PC and Smartphone Installations on page 244
How a Pocket PC or Smartphone Installation Works on page 245
Processor and Platform Support for Pocket PC on page 245
Creating a Pocket PC or Smartphone Installation on page 246
Compiling a Pocket PC or Smartphone Installation on page 246
Palm OS Installations on page 255

Mobile Devices
About Mobile Device Package Editor

The Mobile Device Package Editor tool is primarily intended for opening and editing an
existing .CAB file. Use it to make minor changes to an existing .CAB, including changes
to files, registry entries, and shortcuts. If you open an existing .CAB, you cannot change
the supported platforms or processors for the .CAB or any individual resource within the
.CAB.
You can also use Mobile Device Package Editor to create new .CAB files, but we
recommend that you use the Mobile Devices page in Wise for Windows Installer instead.
The Mobile Device Package Editor provides limited functionality for creating new .CABs
with no ability to save. You can only define a .CAB or .CABs and immediately compile—
once you quit, the .CAB definition is lost and cannot be recompiled. To make changes at
that point, you must open each .CAB and edit it individually.
To launch Mobile Device Package Editor:

1. Select Tools menu > Mobile Device Package Editor. (In Visual Studio: Project menu
> Mobile Device Package Editor.)
2. Use File > Open or File > New to open a .CAB and edit as described in:
Setting Application Information for a Mobile Device on page 247

Setting Platform Support for a Mobile Device on page 247
Setting Platform Information for a Mobile Device on page 249
Setting Files for a Mobile Device on page 249
Setting Registry for a Mobile Device on page 252
Setting Shortcuts for a Mobile Device on page 253
Pocket PC and Smartphone Installations

On the Mobile Devices page, you can add a separate installation whose target is a Pocket
PC or Smartphone mobile device. The instructions for creating a Pocket PC and
Smartphone installation are combined, because the process for each is nearly the same.
Palm installations are discussed in Palm OS Installations on page 255.
Both Microsoft Pocket PC and Microsoft Smartphone 2002 are Windows CE-based
operating systems for mobile devices. Because these operating systems share some
underlying code, the process for creating a Pocket PC or Smartphone installation is very
similar with the exception of platform and processor support. The Pocket PC operating
system is compatible with many different platforms and processors, while Smartphone
only supports Smartphone devices. Therefore, the Pocket PC wizard contains options
and dialogs for specifying platform and processor support, while the Smartphone wizard
does not.
Pocket PC installations created with Wise for Windows Installer can be executed on
Windows CE 2.0 or later, and must be installed by the end user from Windows 95 or
later, or Windows NT 4.0 or later. All versions of Smartphone are supported. Installation
to Pocket PC removable storage cards is also supported.

Mobile Devices
How a Pocket PC or Smartphone Installation Works

Below is a general description of the process for installing onto a Pocket PC or
Smartphone device.
1. Before setting up a mobile device installation, determine which platforms and

processors this installation should target. Some processors do not work with some
platforms. For processor and platform information, see SDK documentation for
Pocket PC and Smartphone.
2. Create the installation by using a wizard on the Mobile Devices page, during which
you add files, registry entries, shortcuts, and specify platform and application
information. All resources that are to be installed on the mobile device are
encapsulated on the Mobile Devices page. Items you enter on the Files, Registry,
and Shortcuts pages are installed on the desktop computer, not the mobile device.
3. Compile the installation. During compile, you might notice that a subdirectory is
created with the .MSI. The .CAB and .INI files are created in this directory, then
compiled into the .MSI.
4. Deploy the .MSI-based installation to the end user’s desktop computer.
5. The end user runs the .MSI-based installation, which installs to the desktop
computer. The .CAB and .INI files, which are necessary to install onto the mobile
device, are installed onto the desktop computer, along with any installation
resources that were specified on other pages in Installation Expert.
6. The mobile device installation is invoked and run by CEAppMgr.EXE (the Add/
Remove Programs dialog of ActiveSync). You can set this to happen immediately
after desktop computer installation, or create a shortcut on the desktop computer
that the end user can open to start installation. Otherwise, the end user is prompted
to install the next time the mobile device is connected to the desktop computer.
Uninstall of the mobile device application is controlled by the mobile device and
ActiveSync. Uninstalling the application from the desktop computer has no affect on the
application that is installed on the Pocket PC or Smartphone device.
Processor and Platform Support for Pocket PC

When you create a Pocket PC mobile device installation, you can specify which platforms
and processors you plan to support. Keep in mind that marking the checkboxes for
platforms and processors does not provide support, it enables you to provide support by
assigning resources to those platforms or processors. You can also specify platform and
processor support for resources that include specific files, registry items, shortcuts, and
the Setup.dll. When you specify platform and processor support for specific files or other
resources, the file or resource is isolated into a .CAB file for each platform and
processor.
Example: Suppose you support the Pocket PC 2000 and Handheld PC Pro platforms.
Then you add the file Application-P.EXE and specify that it is compatible only with Pocket
PC 2000. Then you add the file Application-H.EXE and specify that it is compatible only
with Handheld PC Pro. When you compile, Application-P.EXE is put in
Application.POCKETPC.CAB and Application-H.EXE is put in Application.HPC.CAB.

Mobile Devices
During installation onto the mobile device, the .CAB files can copy files, apply registry
settings, and run custom code located in the Setup.dll.
Note
Smartphone does not contain processor and platform support options because
Smartphone installations can be installed only to Smartphone platforms.
Creating a Pocket PC or Smartphone Installation

On the Mobile Devices page, click Add at the right of the page and select Pocket
PC or Smartphone. Use this method to add the mobile device installation to an
existing installation. (If the Mobile Devices page is not visible, select All from
the Page Views drop-down list in Installation Expert.)
On the New Installation File dialog, select the Pocket PC Application or

Smartphone Application template from the Predefined Templates category. Use
this method to add the mobile device installation to a new installation.
2. Step through the wizard and complete the following dialogs:
Application Information. See Setting Application Information for a Mobile Device

on page 247.
Platform Support. (Pocket PC only) See Setting Platform Support for a Mobile
Device on page 247.
Platform Information. (Pocket PC only) See Setting Platform Information for a

Mobile Device on page 249.
Files. See Setting Files for a Mobile Device on page 249.
Registry. See Setting Registry for a Mobile Device on page 252.
Shortcuts. See Setting Shortcuts for a Mobile Device on page 253.
Desktop. See Setting Desktop Computer Details for a Mobile Device Installation
on page 254.
To edit the mobile device entry, select it and click Details.
After you create a mobile device entry, you might notice changes throughout Installation
Expert, such as files added on the Files page, a shortcut on the Shortcuts page, and new
custom actions added to MSI Script. Do not make changes to these items because doing
so will cause the mobile device installation to fail.
Compiling a Pocket PC or Smartphone Installation

The information you specify on the Mobile Devices page is stored in an .INF file. The .INF
file is used by Microsoft Cab Wizard (cabwiz.EXE or cabwizsp.EXE) to make the .CABs
necessary for the mobile device installation. These .CABs are then compiled into the
.MSI (unless you specified otherwise on the Media page).

Mobile Devices
During the creation of .CABs, one or more DOS windows appear briefly. These DOS
windows are for the Microsoft Cab Wizard. Separate .CABs are created for each platform
that has a specifically assigned resource.
If you specify platforms, but you do not assign any resources to the platform, a .CAB is
not created for the platform during compile. Resources must be specifically assigned to
the platform for a .CAB file to be created. Trying to compile an empty .CAB results in a
compile error.
Setting Application Information for a Mobile Device

1. Do one of the following to access the Application Information dialog:
Step through the Pocket PC or Smartphone wizard.

Double-click a Mobile Device entry on the Mobile Device page and click the
Application Information tab.
Select this page in the Mobile Device Package Editor tool.

Application Name
Enter the name of the application you are installing. This name appears in the
desktop computer’s mobile device software (the Add/Remove Programs dialog,
accessible from the Microsoft ActiveSync window).
Description
The end user sees this description in the Add/Remove Programs dialog before
installation.
Company Name
Enter the name of the company that developed the application. This further
describes the application to the end user during installation.
Name of Setup Files

During compile, several files are created, including an .INI, .INF, and one or
more .CABs. The .INF file is used to create the .CAB files. The .INI file is used to
install to the mobile device. The name you enter here determines the naming
convention of all the .CAB files and other related files. All .CAB files are named
according to the following structure: [Name of Setup Files.Processor
Name.CAB].
Device Installation Directory

Select or create a directory in which to store files on the mobile device. To
create a directory, select a directory and add the name of your directory at the
end. (Example: select \Program Files and then type \MyFolder at the end.) The
directory you create appears on the Files dialog in this wizard.
Setting Platform Support for a Mobile Device


Mobile Devices
1. Do one of the following to access the Platform Support dialog:
Step through the Pocket PC wizard.

Platform Support tab.

Note
If you are using the Mobile Device Package Editor and you used File menu > Open to
open a .CAB, then platform and processor support options are disabled. You cannot
change platform and processor for an existing .CAB.
Platforms or Processes Supported

Specify the platforms and processors you plan to support. Keep in mind that
marking the checkboxes for platforms and processors does not provide support,
it enables you to provide support by assigning resources to those platforms or
processors. Separate .CAB files are compiled for each platform and processor
that you assign resources to. Resources include files, registry items, shortcuts,
and the Setup.dll.
Example: Suppose you support the Pocket PC 2000 and Handheld PC Pro
platforms. Then you add the file Application-P.EXE and specify that it is
compatible only with Pocket PC 2000. Then you add the file Application-H.EXE
and specify that it is compatible only with Handheld PC Pro. When you compile,
Application-P.EXE is put in Application.POCKETPC.CAB and Application-H.EXE is
put in Application.HPC.CAB.
You can assign the platforms and processors you mark on this page to resources
such as shortcuts, registry entries, and shortcuts. After setting support, add
resources to each supported platform and processor.
Note
If you add platforms and processors but do not assign any resources to them, a
compile error occurs.
Include the .NET Compact Framework

(Mobile Devices page only.) The .NET Compact Framework is only applicable to
the Pocket PC 2002 platform. Mark this to include the .NET Compact Framework
for every processor type you specified. You must have the .NET Compact
Framework directory located in the Stub directory in the Wise for Windows
Installer application directory. You can use the Download Redistributables
wizard, available from the Help menu, to obtain this directory. (In Visual Studio:
available from Help menu > Wise Help.) When you mark this checkbox, the
.NET Compact Framework is installed from application manager (CEAppMgr.exe)
before your application is installed.
.NET Compact Framework Runtime Version

Select a version of the .NET Compact Framework.
3. Click OK.

Mobile Devices
Note
When the installation .MSI is run on a desktop computer, the installation queries the
connected mobile device for its platform and processor. It runs the .CAB file that has
specific support for that system.
Setting Platform Information for a Mobile Device

1. Do one of the following to access the Platform Information dialog:
Step through the Pocket PC wizard.

Platform Information tab.

Note
If you are using the Mobile Device Package Editor and you used File menu > Open to
open a .CAB, then platform and processor support options are disabled. You cannot
change platform and processor for an existing .CAB.
2. Complete the dialog for each platform you plan to support:
Minimum and Maximum Version

Minimum and maximum version that your application runs on. When the
application is installed on a mobile device, it queries the mobile device’s system
and makes sure it is supported according to the versions you enter on this page.
If you specify a minimum version, you must also specify a maximum version. To
indicate that it runs on any version higher than the minimum, enter 100 as the
maximum.
Minimum and Maximum Build

(Optional.) If you specify a minimum build, you must also specify a maximum
build, but you can specify a maximum build by itself. Builds are intermediate
releases between major releases. Example: the full platform version might
read: 2.1.03. In this case, 2.1 is the version number and the build is .03.
Setup.dll Path
(Optional.) You can include a separate Setup.dll for each platform that you
support. The Setup.dll is executed during installation. It lets you perform
custom operations during installation and removal of your application. For
information on how to create this file, refer to Microsoft’s Pocket PC or
Smartphone SDK documentation, or search for “Setup.dll” + “Windows CE” in
the MSDN Library (msdn.microsoft.com/library).
Setting Files for a Mobile Device

1. Do one of the following to access the Files dialog:

Mobile Devices

Double-click a Mobile Device entry on the Mobile Device page and click the Files
tab.

The upper 2 list boxes show the directories and files available on your computer. The
lower 2 list boxes represent the directory structure and files that will be installed
onto the mobile device. In the lower list boxes, add the directories and files to
create on the mobile device.
The My Documents, Program Files, and Windows directories represent the

corresponding directories on the mobile device. The Device Installation Directory
that you specified on the Application Information page also appears here.
Note
This mobile device installation must contain files. Trying to compile an empty .CAB
results in a compile error.
2. Use the following buttons to set the files to be installed onto the mobile device
during installation and specify processor and platform support for each file.
Add Contents
Add the contents of the selected directory to the installation. This does not add
the directory itself, it only adds the contents. To add the directory, first create a
directory of the same name in the lower left list box, then add the contents to
that directory.
Add File
Add files to the directory selected in the lower left list box.
New Folder
Create directories that will be installed on the destination computer.
Delete Folder
Remove a directory from the installation. This doesn’t delete the folder from the
mobile device, it only removes it from this installation.
Delete File
Remove a file or operation from the installation. This doesn’t delete the file from
the mobile device, it only removes it from this installation.
Details
Select a file and click Details to set details about the file, including how to
handles errors, replacement options, shared .DLL count, self-registration, and
platform and processor support.
See Editing Details for Mobile Device Files.
Editing Details for Mobile Device Files

1. Do one of the following to access the Files dialog:

Mobile Devices
Double-click a Mobile Device entry on the Mobile Device page and click the Files
tab.

2. Double-click a file you added to the installation.
Source Pathname
This is the current path to the file on your hard drive. To replace this file, specify
a new file.
Destination File Name

Enter the name for the file when it is installed onto the mobile device.
File Copy Errors

Specify how the installation should respond if a file error occurs during the
installation of this file.
Skip silently if error occurs

Do not install this file and do not notify the end user if an error occurs.
Warn if attempting to skip

Warn the end user if an attempt is made to skip a file after an error occurs.
Do not allow file to be skipped

Do not allow the end user to skip copying a file.
Increment Shared .DLL Count

Mark this to increment the counter for this file (if it is a .DLL, .OCX, or .VBX) in
the registry of the mobile device. The shared .DLL counter prevents the file
from being uninstalled if any programs are still using it.
Self-Register File
Some files (examples: .OCXs and some .DLLs) support self-registration. Mark
this to have the file register itself in the registry of the mobile device.
Replace Existing File

Specify how the installation should respond if the file being installed is already
on the mobile device.
Install Only if File Already Exists

Mark this to install this file only if a file of the same name already exists in the
installation directory of the mobile device.
Note
The options below are disabled if you opened an existing .CAB in Mobile Device
Package Editor. You can only specify processor and platform support when you
select File menu > New to start an installation.
Note
The options below are available for Pocket PC installations only.

Mobile Devices
Platform Supported
Select the platform with which this file is compatible. If you select a specific
platform, then this file is isolated into a .CAB file for that particular platform. If
you select All, the file is installed to all of the platforms you selected for
Platform Support.
Processor Supported
Select the processor with which this file is compatible. If you select a specific
processor, then this file is isolated into a .CAB file for that particular processor. If
you select All, the file is installed to all of the processors you selected for
Platform Support.
4. Click OK.
Setting Registry for a Mobile Device

1. Do one of the following to access the Registry dialog:

Registry tab.

The left list box shows keys and the right list box shows values.
2. To add a new key or value, click New Key.
The Registry Details dialog appears:
Root
Select the parent key under which the new key will reside.
Key
Enter the name of the key to create or update. You can create multiple
hierarchical keys at once by separating them with backslashes, as in directory
path names. (Example: Protocol\StdFileEditing creates the StdFileEditing key
inside the Protocol key.) Any keys you specify that do not exist are created.
Value Name
Enter the name of a new named value.
Data Value
The data you enter should be valid data for the Data Type you select below.
Press Ctrl+Enter to insert a carriage return.
Data Type
Select the type of data contained in the named value. Available types are:
String
(REG_SZ prefix.) Identifies a value entry as an expandable string.

Mobile Devices
Multiple Strings
(REG_MULTI_SZ prefix.) Identifies a value entry as a multiple string. These
are multiple pieces of text, separated by carriage returns.
Binary/Hex
(REG_BINARY prefix.) List of numeric values separated by commas. Two
bytes per field. Do not use the “0x” hexadecimal prefix.
Double Word
(REG_DWORD prefix.) Identifies a value entry as a 4 byte (DWORD) entry.
This must be a valid DWORD value.
Don’t Overwrite if Key Already Exists

Clear this to have this registry value overwrite the existing key value on the
mobile device if it already exists. Mark this to prevent this registry setting from
overwriting the existing key value.
Note
The options below are disabled if you opened an existing .CAB in Mobile Device
Package Editor. You can only specify processor and platform support when you
select File menu > New to start an installation.
Note
Platform Supported
Select the platform on which this registry entry should be installed. If you select
a specific platform, then this registry entry will be isolated into a .CAB file that is
meant only for that particular platform. If you select All, the registry entry will
be installed to all of the platforms you selected for Platform Support.
Processor Supported
Select the processor on which this registry entry should be installed. If you
select a specific processor, then this registry entry will be isolated into a .CAB
file that is meant only for that particular processor. If you select All, the registry
entry will be installed to all of the processors you selected for Platform Support.
4. Click OK.
After you add a new registry entry, you can edit it by selecting the key name from the
left list box and double-clicking the value in the right list box.
Setting Shortcuts for a Mobile Device

1. Do one of the following to access the Shortcuts dialog:

Shortcuts tab.


Mobile Devices
2. Click Add.
The Shortcut Details dialog appears.
Source Pathname
Click Browse and specify the file from the mobile device installation for which
you want to create a shortcut. Only those files that you added to the mobile
device’s files are displayed.
Shortcut Name
Enter the name for the shortcut on the mobile device.
Shortcut Location
Select the directory for the shortcut on the mobile device. The drop-down list
contains the most common locations for shortcuts on mobile devices.
Note
Platform Supported
This field is disabled and matches the target file’s platform.
Processor Supported
This field is disabled and matches the target file’s processor.
4. Click OK.
After you add a new shortcut, you can edit it by selecting the shortcut name and clicking
Details.
Setting Desktop Computer Details for a Mobile

Device Installation
Use the Desktop Computer dialog to set options that determine how the mobile device
installation is stored and run on the desktop computer.
It is important to understand that with a mobile device installation, there are 2 separate
installations that take place; see How a Pocket PC or Smartphone Installation Works on
page 245.
1. Do one of the following to access the Desktop Computer dialog:

Desktop Computer tab.
Directory on Desktop Computer

Specify the directory on the desktop computer in which to store the .CAB and
.INI files that are necessary for installation to the mobile device. Typically, this
would be in the Program Files directory. These files are run from the Add/
Remove Programs option in ActiveSync.

Mobile Devices
Prompt end user to install on mobile device during .MSI execution (runs
Application Manager)
If you mark this and the mobile device is connected during the .MSI installation,
then the end user is prompted to perform the mobile device installation
immediately following the .MSI installation.
If installation onto the mobile device will not take place immediately following the
.MSI installation, then use the fields below to create a shortcut on the desktop
computer. This shortcut initiates installation onto the mobile device by calling CE
Application Manager.
Shortcut Name
Enter a name for the shortcut, such as Install PocketWriter.
Shortcut Directory
Select a directory on the desktop computer in which to place the shortcut.
Typically, you would place it in the Windows Start menu. Select
Windows\Profiles\Start Menu\Programs\ to place the shortcut in the
common shortcut location.
Icon File
To use a custom icon, enter the path to the .ICO, .EXE, or .DLL file that contains
the icon.
Icon Index
Enter the resource number of the icon (in the .ICO, .EXE, or .DLL file specified
above) to use from the icon file above. This icon displays in the Shortcut
Directory you selected above.
Palm OS Installations
Use the Mobile Devices page to create an installation for devices running Palm OS.
If you add a Palm OS application to an installation and there are multiple Palm users on
the target computer, then an additional dialog appears during installation if the user
selects Custom on the Installation Type Dialog. This dialog, named Palm User
Information, lists the Palm users who regularly use this computer to perform a HotSync.
During installation, mark the checkboxes of those users who should have this software
installed into their Palm User directories. Software is only installed to the Palm User
directory if you mark the Install File to Palm User Folder During Installation
checkbox on the Palm File Details dialog, as outlined in the procedure below.
If this installation was created in an earlier version of Wise for Windows Installer, it
might not contain the Palm User Information dialog. To add this dialog, see Creating a
New Dialog on page 437. Without this dialog, the application is installed by default to all
Palm users if the Install File to Palm User Folder During Installation checkbox is
marked.
Uninstall of this application is controlled by the Palm device. Uninstalling the application
from the desktop computer has no affect on the application that is installed on the Palm
device.
To create a Palm OS installation:

1. Start the Palm wizard by doing one of the following:

Mobile Devices
On the Mobile Devices page, click Add at the right of the page and select Palm
OS. Use this method to add the mobile device installation to an existing
installation. (If the Mobile Devices page is not visible, select All from the Page
Views drop-down list in Installation Expert.)
From the New Installation File dialog, select the Palm Application template from
the Predefined Templates category. Use this method to add the mobile device
installation to a new installation.
The Application Information dialog appears.
2. Complete the dialog and click Next:
Application Name
Enter the name of the application you are installing. This is used to display the
name of the mobile device entry on the Mobile Devices page.
Desktop Directory
Specify a directory on the desktop computer in which to store the files that you
plan to add to the Palm device. This is simply a holding area for the files to
enable their being copied to Palm-specific directories. The files in this directory
are uninstalled when the .MSI is uninstalled from the desktop computer.
Typically, this would be a directory under the Program Files directory.
The Palm OS Files dialog appears.
3. Click Add, specify a file, and complete the Palm File Details dialog:
File Name
Specify the name for the file when it is installed onto the Palm device.
Source Pathname
This specifies the source path for the file you added.
Install File to Palm “Add-on” Folder During Installation

The Add-on directory is a temporary holding area for Palm applications. When
an end user opens the Palm Desktop software and uses the Install Tool to add a
new application to the Palm device, the contents of this directory are displayed
first. This lets end users manually install software to the Palm device and gives
all Palm users of the desktop computer access to the application.
Install File to Palm User Folder During Installation

The application is copied to the Palm User Folder for the users who are specified
on the Palm User Information dialog, which appears during installation of the
.MSI. Palm applications located in the Palm User Folder are installed to the
device whenever a HotSync is performed on the Palm device. Use this option to
install the application when the end user performs a HotSync and to let only
specific Palm users have access to the application.
Note
Files you install to the Add-on folder or Palm User folder are not uninstalled
when the .MSI is uninstalled. Only those files in the Desktop Directory are
uninstalled. End users can use the Palm software to perform uninstalls from
their device.
4. Click OK, and add more files if desired.
5. Click Finish on the Palm OS Files dialog.
To edit the mobile device entry, select it and click Details.

Mobile Devices

Chapter 11
Translating an Installation
You can translate the default dialogs in an installation into any language. Wise for
Windows Installer contains 5 pre-translated languages in addition to English; the
optional Language Pack contains translations for 20 additional languages. You can add
any language that is not already pre-translated.
About the Languages Page

The Languages page displays pre-translated languages. Pre-translated languages
contain translations for all default text in the installation’s user interface elements.
Examples: error messages; disk prompts; text and controls on dialogs; descriptions or
names for launch conditions, features, or shortcuts; property values, file names, and
directory names.
Use the Languages page to:
z Translate an installation into one or more languages. This translates the default text
in the installation’s user interface elements. It does not translate your application or
any user interface elements you customize in the installation.
z Define a new language, if the language you need is not one of the pre-translated
languages. See Defining and Translating Into Additional Languages on page 263.
z Export text strings to a file that you can send to a translator. Do this when you
define a new language, or when you add or change any user interface elements in
an installation.
z Import translated text strings from a file to the installation. See Importing All Text
Strings After Translation on page 266 and Importing All Text Strings With the New
Language Wizard on page 267.
z Translate customized user interface elements. See Translating Text Strings You’ve
Added or Changed on page 268.
z Keep track of changed, exported, and imported strings. See Keeping Track of
Changed Text Strings on page 278.
Columns on the Languages Page

The Languages page has two columns:
z The Language Name column lists all available languages. To translate an

installation, you mark the checkbox for one or more languages. This adds translated
strings for that language to the installation. Translated installations are generated
during compile.
z When you mark the checkbox for a language, the Text Translated column displays
Yes to indicate that the installation contains a translation for that language. All
languages that show Yes in this column are listed on the Language menu.

Options for Compiling a Translated Installation

z Compile to a separate .MSI file for the default language plus each language that is
marked on the Languages page. See Creating a Translated .MSI on page 259.
z Compile to a language transform (.MST). The compile creates an .MSI for the
default language and a separate .MST for each language that is marked on the
Languages page. At installation, the appropriate .MST must be applied to the .MSI
to change the installation language. See Creating a Language Transform on
page 260.
When Translations Are Not Compiled

When you mark a language checkbox, then clear it, the translation remains in the
installation but no .MSI or .MST is created in that language during compile. This lets you
omit a language from the compile without losing any translated text strings. This is
especially important when you have added custom translated text.
Additional Translation Options

You can create a multiple-language installation that installs in the destination computer’s
language or prompts the end user to select a language. For details, see Outputting a
Multiple-Language Release on page 180.
A Share option makes it easy to translate several releases into the same language or set
of languages, with the same language settings. See Sharing Language Settings Between
Releases on page 261.
Note
The Languages page is disabled for transforms. Edit languages in the base .MSI.
Creating a Translated .MSI

You can translate an installation to another language and have it compile to one or more
.MSI files. A separate .MSI is created for the default language plus each language that is
marked on the Languages page. To compile all languages into one installation file, see
Outputting a Multiple-Language Release on page 180.
If you have customized any of the user interface elements of this installation, you must
translate the changed text before translating the installation. See Translating Text
Strings You’ve Added or Changed on page 268.
If the language you need is not listed on the Languages page, you must define a new
language and translate its text strings. See Defining and Translating Into Additional
Languages on page 263.
Note
If the installation contains Web resources, adding or changing a language regenerates
the Web dialogs in the installation.
To create a translated .MSI:

1. Select Installation Expert > Languages page.
3. Mark the checkbox next to each language to translate this installation to.

Some .MSI files might not have languages listed on the Languages page. In that
case, you must use the .WSI that compiled the .MSI.
Note
If this installation was created in a previous version of Wise for Windows Installer,
but you did not update the path variables when you first opened the installation in
the newer version, you will receive an error when you mark a language checkbox. To
fix this, close the installation, reopen it, and click Yes in the prompt that asks you to
update variables.
The remaining steps are optional.
4. Double-click the marked language.
The Language Details dialog appears.
Destination File
Specify the full pathname for the translated .MSI; be sure to include the .MSI
file extension.
If you leave this field blank, this language is always compiled to an .MSI whose
name is created by adding an underscore and the language name to the
installation file name. Example: If you mark the checkbox for German and the
installation file is named Sample, a file named Sample_German.msi is created
during compile.
If you specify an .MST file instead of an .MSI, this language is compiled to a

language transform. See Creating a Language Transform on page 260.
Codepage, Language ID
Leave the defaults in these fields. You typically only change these fields when
you define a new language.
Default release language

(.WSI files only.) Mark this to use this language as the default language for this
release. During compile, the default release language overrides the Default
language on the Language menu.
Note
Only one language per release can be the default release language. An error
message lets you know if you mark this checkbox for a second language.
See About the Default Release Language on page 277.
6. Click OK.
7. If needed, complete the Language Details dialog for any other languages that are
marked.
Default text strings for the selected release are translated into the selected languages.
You can share these language settings with other releases in this installation. See
Sharing Language Settings Between Releases on page 261.
Creating a Language Transform

You can create one or more language transforms that change the language in the
dialogs that appear during installation. The compile creates an .MSI for the default

language and a separate .MST for each language that is marked on the Languages page.
During installation, the appropriate .MST must be applied to the .MSI to change the
installation language. See Applying a Transform to an Installation on page 351.
If you have customized any of the user interface elements of this installation, you must
translate the changed text before translating the installation. See Translating Text
Strings You’ve Added or Changed on page 268.
If the language you need is not listed on the Languages page, you must define a new
language and translate its text strings. See Defining and Translating Into Additional
Languages on page 263.
Note
To create a language transform:

3. Mark the checkbox next to each language to create a language transform for.
Some .MSI files might not have languages listed on the Languages page. In that
case, you must use the .WSI that compiled the .MSI.
4. Double-click the marked language.
The Language Details dialog appears.
5. In Destination File, specify the full pathname for the translated .MST; be sure to
include the .MST file extension.
If you specify an .MSI file instead of an .MST, this language is compiled to an

installation database. See Creating a Translated .MSI on page 259.
6. Leave the defaults in Codepage and Language ID. You typically change these
fields only when you define a new language. The Default release language
checkbox is disabled when you specify an .MST as the destination file.
7. Click OK.
8. If needed, complete the Language Details dialog for any other languages you
marked.
Default text strings for the selected release are translated into the selected languages.
You can share these language settings with other releases in this installation. See
Sharing Language Settings Between Releases on page 261.
Sharing Language Settings Between Releases

You can translate several releases into the same language or languages, with the same
settings you define in the Language Details dialog. To do this, you share language
settings between releases.
After you initially share language settings, the settings for the releases are linked. This
means that any change you make to the language settings for any of the linked releases
is applied to all other linked releases. At any time, you can break the link. Breaking the
link does not change the current settings for the releases.


1. Translate the installation to another language as described in Creating a Translated
.MSI on page 259.
3. From Current Release, select the release to copy settings to.
4. Click Share at the right of the page. The Share Release dialog appears.
5. From Copy/Share Languages From, select the release that contains the settings
to copy.
6. Click OK.
The settings of the release in Copy/Share Languages From immediately replace the
settings of the release in Current Release. Any change you make to the language
settings of either of the linked releases is also applied to the other release, until you
break the link.

3. Click Share at the right of the page. The Share Release dialog appears.
4. From Copy/Share Languages From, select <None>.
5. Click OK.
the settings of the other release.
Removing a Language from an Installation

You can disable a language in an installation. This means the installation still contains
the translated strings for the disabled language but the installation is not compiled to
that language.
You also can delete a language entirely from an installation. This means the language is
removed from the Languages page and its translated strings are deleted from the
installation. This is not recommended if you have added or changed text strings in a
language, because the customized strings are lost.
Note
To disable a language in an installation:

z In Installation Expert > Languages page, clear the checkbox next to the language to
disable.
The translated text strings for that language remain in the installation, but the
installation is not translated to that language during compile. To compile the installation
to that language again, simply mark its checkbox. In this way you can easily turn a
language off and on.

To delete a language entirely from an installation:

z In Installation Expert > Languages page, click a language and click Delete at the
right of the page.
The language is removed from the Languages page in the installation. Text strings for
the deleted language are deleted from the installation, unless that language is selected
in another release. The language will still be available in other installations if it is one of
the pre-translated languages or if you added it to the installation template.
Caution
When you delete a language this way, all custom translated text strings in that language
are lost.
To restore a language that was deleted:

If you use the Delete button on the Languages page to delete a language and its text
strings from an installation, you can later restore that language to the installation if you
have a file containing translated text strings for that language.
Add the language to the Languages page and import translated text strings. See
Importing All Text Strings With the New Language Wizard on page 267.
z To restore one of the pre-translated languages, select the appropriate resource file
from the Languages subdirectory of the Wise for Windows Installer application
directory. (In the Enterprise Edition, the Languages subdirectory is under the share
point directory.) To restore a language that you added and had translated, specify
the resource or text file containing the translated text strings.
The language is restored to the Languages page.
Note
This process does not restore any custom translated text.
Defining and Translating Into Additional Languages

If the language you need is not one of the 25 pre-translated languages, you can add it to
the Languages page and add translated text for that language. Then you can translate
installations into the new language.
Example:
Suppose you want to translate an installation into Swiss French. However, that language
is not included in the standard product or the optional Language Pack. You can add
Swiss French to the Languages page and add Swiss French text strings to the
installation. Then, you can compile an installation that displays Swiss French on all
dialogs and error messages.
The new language and its translated strings are added to the current installation only. To
make the new language available for future installations, add it to an installation
template instead of to a specific installation. See Creating and Editing Installation
Templates on page 55.

Process for Defining and Translate Into a New Language

1. If you plan to customize or add new elements to the user interface of the
installation, do so first. That way, the customized strings will be included when you
export text strings for translation.
2. Add the new language to the list on the Languages page by defining language
settings, then export the text strings in the installation to a resource or text file. See
Defining a New Language and Exporting All Text for Translation on page 265.
3. Have the text strings translated to the new language. The translator should
translate the strings in place in the same file, to ensure the returned file is
formatted identically.
Caution
If you export the strings to a text file, make sure that the first two fields in the text
file are not translated. These are the table and key names for the text strings and
must remain intact.
4. Import the translated resource or text file. See Importing All Text Strings After
Translation on page 266.
Now you can compile the installation to the new language. See Creating a Translated
.MSI on page 259 and Creating a Language Transform on page 260.
After the initial translation, whenever you add or change text strings, you must have
them translated if you want them in the new language. See Translating Text Strings
You’ve Added or Changed on page 268.
About the New Language Wizard

Use the New Language wizard to:
z Define a new language on the Languages page.
z Export text strings to a file that you can send to a translator.
z Import translated text strings from a file to the installation.
To use the New Language wizard:

1. In Installation Expert > Languages page, click Add at the right of the page.
The Specify Language Details dialog appears.
2. Complete the dialog. The information you need to enter depends on what you plan
to do; for details, see the topics listed in the next step. Then click Next.
The Export/Import Text Strings for Language dialog appears.
3. Mark one of the following options:
Export
Export all text strings to a file for translation into this new language. This is the
option most typically used. For details, see Defining a New Language and
Exporting All Text for Translation on page 265.
Import
Import a file containing translated text strings for this language. Do this if you
already have translated text strings for this language. For details, see Importing
All Text Strings With the New Language Wizard on page 267.

None
Add a new language with text strings in the default language. Do this when you
want to add a new language to the Languages page now and translate the
strings later.
4. If you select None, click Finish to add the language to the Languages page and exit
the wizard. If you select Export or Import, click Next. Additional dialogs appear;
for details, see the topics listed in the preceding step.
Defining a New Language and Exporting All Text for

Translation
If the language you need is not one of the 25 pre-translated languages, you can define
the new language on the Languages page, then export strings from the installation.
Later, you have the strings translated and import the translated strings.
3. Click Add at the right of the page.
The New Language wizard appears with the Specify Language Details dialog.
Language Name
Enter a name for the new language.
Destination File
(Optional.) Specify the full pathname for the translated installation file. You can
create an .MSI or a transform (.MST).
installation file name. Example: If the new language is named NewLanguage,
and the installation file is named Sample, the translated installation is compiled
to Sample_NewLanguage.msi.
Codepage
A code page ensures that the correct character set is used for the language you
are adding. In most cases, it is best to specify 0, which is a language-neutral
code page. If the language you are adding uses a multi-byte character set, then
select the appropriate code page from the drop-down list. See Setting the Code
Page of a Database in the Windows Installer SDK Help.
Language ID
Specify only one language ID for the language you are adding. Windows
Installer supports only one language in this field.
See Language IDs on page 279 or visit msdn.microsoft.com for a complete list
of language IDs.


Note
5. Click Next.
The Export/Import Text Strings for Language dialog appears.
6. If you have not had the strings translated, mark Export and click Next.
The Export Default Strings dialog appears.
Export As
Select a file type for the text strings:
Resource File
Exports the strings to a Visual C++ style resource file; this includes an .H
(header) file. With a resource editor, you or the translator can resize dialogs
appropriately for each language.
Text File
Exports the strings to a standard text file, in which they are separated by
tabs.
File Name
Specify the full pathname for the file to export text strings to.
Export File and Directory Names

Mark this to include the installation’s file and directory names in the export file.
8. Click Finish.
The text strings are exported to the file you specified, which you can send to a
translator. When you receive the translated file from the translator, you import the text
strings into the installation. See Importing All Text Strings After Translation.
Importing All Text Strings After Translation

Typically, while adding a new language to the Languages page, you export the text
strings from the installation to a file and send them to a translator. After the text strings
for the new language are translated, you must import them into the installation. In this
procedure, you use the Language Strings dialog to import translated text strings.
This procedure assumes that you have already added the new language to the
Languages page, defined its settings, and exported text strings as described in Defining
a New Language and Exporting All Text for Translation on page 265. If you have not
defined language settings for the new language, you can use the New Language Wizard
to define the language settings and import the text strings at the same time. See
Importing All Text Strings With the New Language Wizard on page 267.
Note
In .TXT files, if tab characters for one or more text strings are added or deleted during
translation, the text strings cannot be imported. To determine whether there are any
text strings that are not imported and therefore not translated, go to the Language
Strings dialog and compare the entries in the Changed and Exported columns. They
should match. See Keeping Track of Changed Text Strings on page 278.

To import all text strings using the Language Strings dialog:

3. Click Strings at the right of the page.
The Language Strings dialog appears.
4. From Language, select the language for which you will replace all text strings.
5. At the bottom left of the Language Strings dialog, click Import.
The Import Language Strings dialog appears.
6. In Translated Strings File, specify the name of the file that contains the
translated text strings for the new language.
7. Make sure the Do not compare with current strings option is marked. You only
need to compare strings when you import strings you add or change after you’ve
imported all strings.
8. Click OK.
The translated text strings are imported into the installation and you can translate the
installation to the new language. See Creating a Translated .MSI on page 259 and
Creating a Language Transform on page 260.
Importing All Text Strings With the New Language Wizard

You can use the New Language wizard to import text strings at the same time you define
a new language on the Languages page. Do this only when you already have a file
containing translated text strings for the language you are adding. Example: If you
added the language Swiss French to a previous installation, and now you want to use it
in a new installation, you can use the New Language wizard to import Swiss French
translations to the new installation.
Note
A better way to make a new language available for multiple installations is to add it to an
installation template instead of to a specific installation. See Creating and Editing
Installation Templates on page 55.
You might also use this process to restore a language that you deleted from the
Languages page. You must have access to the original file that contains the translated
text strings. This process does not restore any custom translated text.
Typically, you do not have a translated text file at the time you define a new language.
Instead, you use the New Language wizard to define a new language and export text
strings to a file, you have the file translated, and you import the translated strings at a
later time. See Defining and Translating Into Additional Languages on page 263.
To import all text strings with the New Language wizard:

The New Language wizard appears with the Specify Language Details dialog.

Language Name
Enter a name for the new language.
Destination File
(Optional.) Specify the full pathname for the translated installation file. You can
create an .MSI or a transform (.MST).
installation file name. Example: If the new language is named NewLanguage,
and the installation file is named Sample, the translated installation is compiled
to Sample_NewLanguage.msi.
Codepage
A code page ensures that the correct character set is used for the language you
are adding. In most cases, it is best to specify 0, which is a language-neutral
code page. If the language you are adding uses a multi-byte character set, then
select the appropriate code page from the drop-down list. See Setting the Code
Page of a Database in the Windows Installer SDK Help.
Language ID
Specify only one language ID for the language you are adding. Windows
Installer supports only one language in this field.
See Language IDs on page 279 or visit msdn.microsoft.com for a complete list
of language IDs.

Note
5. Click Next.
The Export/Import Text Strings dialog appears.
6. Mark Import and click Next.
The Import Translated Text Strings dialog appears.
7. In Translated Strings File, specify the file containing the translated strings.
8. Click Finish.
The translated text strings are imported into the installation and you can translate the
installation to the new language. See Creating a Translated .MSI on page 259 and
Creating a Language Transform on page 260.
Translating Text Strings You’ve Added or Changed

When you add or change any user interface elements in an installation, you must
translate those changes if you want them to appear in another language. Examples:

error messages; disk prompts; text and controls on dialogs; descriptions or names for
launch conditions, features, or shortcuts; property values, file names, and directory
names.
You have several options for finding out which strings need to be translated and getting
the translated text into the installation:
z If you change multiple strings and need to send them to a translator, export only the
changed strings to a file. Send the file to a translator, then import the translated
strings back into the installation. See Translating Text Strings by Exporting to a File
on page 269.
z If you make just a few small changes and you know the translations, you can edit
the text directly. See Translating Text Directly Without Exporting It on page 272.
z If you are adding an entire new language, you can export all text strings in the
installation, have them translated, and then import the translated strings to the
installation. See Defining and Translating Into Additional Languages on page 263.
The translated text might require more space than the default language. (Example:
Most languages require more space than English.) Therefore, you might need to resize
dialog controls to accommodate text expansion. See Resizing Dialog Controls After
Translation on page 274.
Note
Dialog controls are shared across all languages, which means that a control you add to
one language is added to all other languages as well. Similarly, a control you delete in
one language is deleted in all other languages. However, you can add conditions to show
or hide certain controls in certain languages. For details, see Conditions for Controls on
Dialogs on page 408. Also see UserLanguageID Property in the Windows Installer SDK
Help.
Translating Text Strings by Exporting to a File

When you add or change any user interface elements in an installation, you must
translate those changes if you want them to appear in another language. To do so, you
export the new or changed text strings to a file, have them translated, then import the
translated strings back into the installation. See Exporting Selected Text Strings to a File
on page 270 and Importing Selected Text Strings From a File on page 271.
Example:
Suppose an installation is in English and Spanish. You decide to add a new dialog to the
installation wizard. You add the dialog in the default language (in this case, English).
That way, the dialog is added to all languages in the installation (English and Spanish).
However, because the Spanish text for the new dialog does not exist, the new dialog
displays in English, even in the Spanish version of the installation. You must export all
the text on the new dialog to a file, have it translated to Spanish, and then import the
Spanish version of the text back into the installation.
If you are translating the entire installation to a new language, you can export,
translate, and import all text strings in the installation. See Defining and Translating
Into Additional Languages on page 263. If you make just a few small changes and you
know the translations, you can edit the text directly. See Changing Text in Installation
Expert and Setup Editor on page 273.

You can use the Language Strings dialog on the Languages page to keep track of
changed and exported text strings. See Keeping Track of Changed Text Strings on
page 278.
Exporting Selected Text Strings to a File

Export selected text strings when you add or change text strings in an installation that is
translated to another language. Example: When you add a custom dialog, you must
translate the text in that dialog to all other languages used in the installation.
To export selected text strings:

4. From Language, select the language to export text strings for. The drop-down list
shows those languages that have translated text strings in this installation; they are
indicated by a Yes in the Text Translated column on the Languages page.
5. On the Language Strings dialog, click Export.
The Export Language Strings dialog appears.
6. From Export As, select a file type for the text strings:
Resource File
Exports the dialogs and strings to a Visual C++ style resource file; this includes
an .H (header) file. With a resource editor, you or the translator can resize
dialogs appropriately for each language.
Text File
Exports the strings to a standard text file, in which fields are separated by tabs.
Caution
Make sure that the first two fields in the text file are not translated. These are the
table and key names for the text strings and must remain intact.
7. In File Name, specify the full pathname for the file to export text strings to.
8. From Export Options, select which strings to export:
New or changed strings since last export

Export strings that were added or changed since you last exported text strings
for translation.
New or changed strings in installation

Export all strings that were added or changed in this installation.
All strings in current language

Export all the text strings in the language you selected from the Language
drop-down list.
All strings in default language

Export the text strings in the default language for the .WSI. This is either the
Default language on the Language menu or the default release language
defined on the Language Details dialog.

9. To include the installation’s file and directory names in the export file, mark Export
File and Directory Names.
10. Click OK.
The text strings are exported to the file you specified, which you can send to a
translator. When you receive the translated file from the translator, you import the text
strings into the installation. See Importing Selected Text Strings From a File.
Importing Selected Text Strings From a File

When you add or change text strings in an installation that is translated to another
language, you must export the changed text strings and have them translated, as
described in Exporting Selected Text Strings to a File on page 270. When you receive
translated text strings from the translator, you import them into the installation so that
those text strings appear in the correct language in the compiled installation.
4. From Language, select the language to import text strings for.
5. In the Language Strings dialog, click Import.
The Import Language Strings dialog appears.
6. In Translated Strings File, specify the name of the file that contains the
translated text strings.
7. If additional text changes might have been made since the text strings were
exported, you can compare the strings in the installation to the strings in the
original export file. If the strings don’t match, the corresponding translated strings
are not imported. To enable the compare:
a. Mark Compare current strings with original strings.
b. In Original Strings File, specify the name of the file you exported for
translation.
8. Click OK.
The translated text strings are inserted into the installation.
If you chose to compare the text strings during the import, an error message informs
you when one or more text strings in the installation have been changed since the
export. In that case, the translated strings that correspond to the changed strings are
not imported. You should re-export the changed text strings for additional translation.
Note
In .TXT files, if tab characters for one or more text strings are added or deleted during
translation, the text strings cannot be imported. To find out if there are any text strings
that are not imported and therefore not translated, go to the Language Strings dialog
and compare the entries in the Changed and Exported columns. They should match. See
Keeping Track of Changed Text Strings on page 278.

Translating Text Directly Without Exporting It

Typically, you export all text strings, file names, and directory names to a file to have
them translated. Then you import the translations back into the installation. However, in
some instances you might need to translate a small amount of text, such as a single
dialog control or a single file name. Rather than going through the process of exporting
and importing changed text strings, you can make these changes yourself for each
language.
Example:
Suppose you have translated an installation to German. Then you add a Cancel button to
an existing dialog. You already know the German translation for “Cancel” because other
dialogs contain a Cancel button. In this case, you don’t need to export, translate, and
import the changed string; you can change the text for the new Cancel button.
You have 2 options for translating changed text:
z Translate specific text in the Language Strings dialog. This lets you see at a glance
the translation status of text strings in the installation. See Translating Text on the
Language Strings Dialog.
z Change specific text in Installation Expert and Setup Editor. See Changing Text in
Installation Expert and Setup Editor on page 273.
Both of these procedures assume you already have the translation for the changed text.
If you are adding an entire new language, you can export, translate, and import all text
strings in the installation. See Defining and Translating Into Additional Languages on
page 263. If you change several strings and need to put them in a file for the translator,
you can export, translate, and import only the strings you changed. See Translating Text
Strings by Exporting to a File on page 269.
Translating Text on the Language Strings Dialog

In the Language Strings dialog, you can change translated text for any of the selected
languages. Do this when you have only a small amount of text to be changed and you
know the translation for that text. To translate larger amounts of text, see Translating
Text Strings by Exporting to a File on page 269.
4. From Language, select a language. The Language Strings dialog shows the text
strings for that language.
5. In the Translated Text column, click the text to change and press Enter.
6. Enter new text or change the existing text.
7. Press Enter.
You can observe the change in the corresponding table in the Tables tab in Setup Editor.
Similarly, you can change text in the Tables tab or the Dialogs tab, then observe the
change here in the Language Strings dialog. See Changing Text in Installation Expert
and Setup Editor.

Changing Text in Installation Expert and Setup

Editor
You can change translated text for any of the selected languages in certain areas of
Installation Expert and Setup Editor. Do this when you have only a small amount of text
to be changed and you know the translation for that text. To translate larger amounts of
text, see Translating Text Strings by Exporting to a File on page 269.
1. From the Language menu, select a language.
2. Go to the table, dialog, or Installation Expert page that contains the text string, file
name, or directory name to edit.
3. Change the text. Note that the text is changed only for the language you’ve selected
from the Language menu.
You can observe the change in the Language Strings dialog. Similarly, you can change
translated text in the Language Strings dialog, then observe the change in Installation
Expert or Setup Editor. See Translating Text on the Language Strings Dialog on
page 272.
Tables and Columns That Contain Text Strings You Can Translate
You can edit the strings in Setup Editor > Tables tab, in other Setup Editor tabs, or in
Installation Expert.
Table Columns you can translate and edit

ActionText Description, Template
BBControl Text
ComboBox Text
Control Text, Help
Dialog Title
Directory DefaultDir
DuplicateFile DestName
Error Message
Feature Title, Description
File FileName
LaunchCondition Description
ListBox Text
ListView Text
Media DiskPrompt
Property Value
RadioButton Text, Help
Shortcut Name, Description
UIText Text
WiseReleaseMediaDest DiskPrompt

Resizing Dialog Controls After Translation

Because some languages require more space than others, you might need to resize
dialog controls (examples: buttons and text boxes) to accommodate text expansion.
1. From the Language menu, select a language.
To resize dialog controls across all languages, select the Default language.
2. Select Setup Editor > Dialogs tab.
3. Click the dialog to change.
4. Select a dialog control and resize it.
For information on dialog controls, see Types of Dialog Controls on page 438.
Note
Dialog controls are shared across all languages, which means that a control you add to
one language is added to all other languages as well. Similarly, a control you delete in
one language is deleted in all other languages. However, you can add conditions to show
or hide certain controls in certain languages. For details, see Conditions for Controls on
Dialogs on page 408. Also see UserLanguageID Property in the Windows Installer SDK
Help.
About the Language Menu

The Language menu lists all languages that have text translated in the installation. Use
the Language menu to display translatable items in another language. Examples: error
messages; disk prompts; text and controls on dialogs; descriptions or names for launch
conditions, features, or shortcuts; property values, file names, and directory names.
Example:
Suppose you have translated an installation to German, and you want to resize buttons
and text boxes on a dialog to accommodate the longer German text. In Setup Editor,
click the Dialogs tab and display a dialog. Its text is in the default language. Now select
Language menu > German. The dialog is displayed in German, and you can resize dialog
controls as needed.
When you add or change text in the installation’s user interface elements, make sure
Language menu > Default is selected. That way, the items are added or changed for all
languages. If you change the user interface while a different language is selected, the
change is made for that language only.
The Language menu does not affect the basic information in the installation, such as
files added or dialogs selected. This means you cannot add files or select dialogs for a
certain language in this manner. Any file you add in Installation Expert or any dialog you
select in the Dialogs tab in one language is added and selected for all languages in the
overall installation. To add files or select dialogs for a certain language only, use features
and the Release Settings page. For details, see Customizing a Release on page 181.
The default language is initially English, however, you can change it. See Changing the
Default Language. You also can override the default language for a specific release by
designating a default release language. See About the Default Release Language on
page 277.

Changing the Default Language

The Default language that appears on the Language menu is initially English and is the
same for all new installations. During compile, an .MSI is always created for the default
language regardless of how many other languages are marked on the Languages page.
When you translate an installation into one or more language transforms, the base .MSI
is always compiled in the default language. The exception is when you define a default
release language. See About the Default Release Language on page 277.
You can change the default language for new installations by creating a new installation
template. Although templates must be in .MSI format, you must start with a .WSI
because you cannot specify the default language in an .MSI.
To create a template with a different default language in the Wise

editor:
The New Installation File dialog appears.
2. In the Categories list, click Predefined Templates.
3. In the Templates/Tools list, click the Windows Application icon.
4. Mark Create .WSI or .WSM project file that can be compiled into an .MSI or
.MSM and click OK.
5. In Installation Expert > Languages page, mark the checkbox next to the language
that should be the default.
6. Double-click the language name to display the Language Details dialog.
7. Mark Default release language and click OK.
8. Click Compile.
9. In the Save As dialog that appears,
a. Navigate to the Templates subdirectory and enter a file name. The location of
the Templates subdirectory varies. See Where are Installation Resources
Stored? on page 28.
b. From Save as Type, select Installer Projects (*.wsi).
c. Click Save.
The .WSI is saved and then is compiled to an .MSI. Only .MSIs appear in the New
Installation File dialog as templates.
To test the new template:

The New Installation File dialog appears and the file you just created appears in the
Custom Templates category. If the New Installation File dialog does not contain
the new template, check to make sure you saved the installation as an .MSI in the
Templates directory.
3. Check that the default language has been changed:
The Default language should be the only one listed on the Language menu.

In Installation Expert > Dialogs page, display any dialog. The dialog should
appear in the new default language rather than in English.
You can use this template to create installations in which the default language is the one
you selected.
To create a template with a different default language in the Visual

Studio integrated editor:
Note
This procedure describes how to create a template for an installation within a solution.
You also can change the default language in templates that create a merge module
within a solution, or a stand-alone installation or merge module. However, you must
start with an installation project file (.WSI or .MSI) because you cannot specify the
default language in an .MSI. For information about the types of templates you can
create, see Creating and Editing Installation Templates on page 55.
1. If a solution is open in Visual Studio .NET, close it.
3. From the Categories list, select Wise Files.
4. In the Templates list, click the Windows Application Project icon and click Open.
A new installation opens.
5. In Installation Expert > Languages page, mark the checkbox next to the language
that should be the default.
6. Double-click the language name to display the Language Details dialog.
7. Mark Default release language and click OK.
8. Select File menu > Save As, name the file, and save it.
9. Select Build menu > Compile to create an .MSI.
10. Copy the .MSI file to the Templates\File directory. The location of the Templates
directory varies. See Where are Installation Resources Stored? on page 28.
11. If you prefer to create a .WSI template, rename the file’s extension. If you have
added files to the template, use MSI to WSI Conversion to create the .WSI template.
To test the new template:

2. Click Wise Setup and Deployment Projects in the Project Types list.
The file you just created appears in the Templates list. If the New Project dialog
does not contain the new template, check to make sure you saved it as a .WSI in
the Templates\Project directory.
4. In Solution Explorer, click the new project .WSI to open the installation in the Visual
Studio integrated editor.
5. Check that the default language has been changed.

The Default language should be the only one listed on the Language menu.
In Installation Expert > Dialogs page, display any dialog. The dialog should
appear in the new default language rather than in English.
You can use this template to create installations in which the default language is the one
you selected.
About the Default Release Language

The default release language is defined for a specific installation. It overrides the Default
language on the Language menu during compile.
Example: Suppose you’re creating an installation named Sample and you only want to
create one .MSI, in German. Mark the Default release language checkbox on the
Language Details dialog for German. When you compile, Sample.msi will be in German.
If you don’t mark the checkbox, the compile will create two files: Sample.msi, which is
in the default language, and Sample_German.msi.
You can also use the default release language to change the language of a base .MSI,
against which you will apply other language transforms. Example: Suppose you create
an installation named Sample2. On the Languages page, you mark the checkbox for
German and, on the Language Details dialog for German, you mark the Default
release language checkbox. Then, back on the Languages page, you mark the
checkbox for Spanish. On the Language Details dialog for Spanish, you enter
Sample2_Spanish.mst as the Destination File. When you compile, the following files
result: Sample2.msi, which is in German, and Sample2_Spanish.mst, which is a Spanish
language transform.
The Default release language checkbox is on the Language Details dialog and the
Specify Language Details dialog of the New Language wizard. It appears in .WSI files
only.
Note
Only one language per release can be the default release language.
About the Language Strings Dialog

The Language Strings dialog, which appears when you click the Strings button at the
right of the Installation Expert > Languages page, displays all translated and default
text strings side by side. Use the Language Strings dialog to translate strings and keep
track of changed text strings.
Columns on the Language Strings Dialog

z Translated Text
Lists all text strings in the selected language.
z Default Text
Lists all text strings in the default language.
z Table
Indicates the table in the database that contains the string.
z Key
Shows the key to the table.

z Column
Indicates which column of the table is translated.
z Changed
Yes indicates that a text string has been added or changed. See Keeping Track of
Changed Text Strings.
z Exported
Yes indicates that a text string has been exported. See Keeping Track of Changed
Text Strings.
Also see:
Exporting Selected Text Strings to a File on page 270

Importing All Text Strings After Translation on page 266
Importing Selected Text Strings From a File on page 271
Translating Text on the Language Strings Dialog on page 272
Keeping Track of Changed Text Strings

Two columns in the Language Strings dialog help you keep track of changed, exported,
and imported strings: the Changed column and the Exported column. Both columns
should contain No when you are ready to compile a translated installation.
When you do this the Changed and the Exported

column contains column contains
Add or change a text string Yes No
Export strings Yes Yes
Import strings No No
The same stages apply when you add or change files or directories, if you export file and
directory names for translation. If you do not export file and directory names, then the
entry in the Changed column remains Yes.
If the Changed column still reads Yes after you’ve imported text strings, one of 2 things
happened:
z Formatting for the corresponding text string in the resource or text file was
changed. (Example: This can happen if a tab in a text file was deleted or moved.)
Try to reformat the resource or text file and then import it again.
z When you imported, you chose to compare current strings with original strings, and
you’ve made changes to the strings in the interim. In this case, export changed text
strings again. Translate the strings that have changed, then import them.
What Pre-Translated Languages Are Available?

Pre-translated text strings let you instantly translate an installation into the following
languages:
French
German
Italian

Portuguese
Spanish
The optional Language Pack lets you select from these additional pre-translated
languages.
Chinese (PRC)
Chinese (Taiwan)
Czech
Danish
Dutch (Netherlands)
Finnish
French (Canadian)
Greek
Hungarian
Indonesian
Japanese
Korean
Norwegian
Polish
Portuguese (Brazil)
Russian
Spanish (Basque)
Spanish (Catalan)
Swedish
Turkish
If the language you need is not listed here, you can send the installation text strings to
a translator and then add the new language and the translated strings to the Languages
page. See Defining and Translating Into Additional Languages on page 263.
The default language for all installations is English, unless you change it. For details, see
Changing the Default Language on page 275.
Language IDs
Windows Installer uses language IDs to determine whether the destination computer
supports the language that is used for the installation dialogs. Example: If you create an
installation with the language ID for Greek, that installation only runs on a computer
with Greek fonts.
Language IDs and Locale Codes for Common Languages

For additional language codes, search for “Table of Language Identifiers” and “Language
Code and Scripts” in the MSDN Library (msdn.microsoft.com/library).
Language Sublanguage ID Script Locale

(decimal Language
notation) Code
Language- 0
neutral
Process or 1024
User Default
Language


(decimal Language
notation) Code
Czech 1029 Latin 2 CSY
Danish Danish 1030 Latin 1 DAN
Dutch Belgian (Flemish) 2067 Latin 1 NLB
Dutch Dutch (Standard) 1043 Latin 1 NLD
English American 1033 Latin 1 ENU
English Australian 3081 Latin 1 ENA
English British 2057 Latin 1 ENG
English Canadian 4105 Latin 1 ENC
English Ireland 6153 Latin 1 ENI
English New Zealand 5129 Latin 1 ENZ
Finnish Finnish 1035 Latin 1 FIN
French Belgian 2060 Latin 1 FRB
French Canadian 3084 Latin 1 FRC
French French (Standard) 1036 Latin 1 FRA
French Swiss 4108 Latin 1 FRS
German Austrian 3079 Latin 1 DEA
German German 1031 Latin 1 DEU
(Standard)
German Swiss 2055 Latin 1 DES
Greek 1032 Greek ELL
Hungarian 1038 Latin 2 HUN
Icelandic Icelandic 1039 Latin 1 ISL
Italian Italian (Standard) 1040 Latin 1 ITA
Italian Swiss 2064 Latin 1 ITS
Norwegian Norwegian 1044 Latin 1 NOR
(Bokmal)
Norwegian Norwegian 2068 Latin 1 NON
(Nynorsk)
Polish 1045 Latin 2 PLK
Portuguese Portuguese 1046 Latin 1 PTB
(Brazilian)
Portuguese Portuguese 2070 Latin 1 PTG
(Standard)
Russian 1049 Cyrillic RUS
Slovak 1051 Latin 2 SKY
Spanish Mexican 2058 Latin 1 ESM


(decimal Language
notation) Code
Spanish Spain (Modern 3082 Latin 1 ESN
Sort)
Spanish Spain (Standard/ 1034 Latin 1 ESP
Traditional Sort)
Swedish Swedish 1053 Latin 1 SVE
Turkish 1055 Ext. Latin TRK
(code page
1254)

Chapter 12
Distributing an Installation
When you complete and compile an installation and are ready to deploy it, you can:
z Use Package Distribution to distribute an installation to disk, to the network, or to

an FTP server for deployment to end users.
z Use Package Distribution to perform an administrative installation, which lets end

users install from a network.
z Use WiseUpdate to configure your application for automatic updating.
In the Enterprise Edition, you also can use Package Distribution to distribute to the share
point directory, so that the installation can be imported into the Software Manager
database.
Package Distribution
Use Package Distribution to deploy or share a package by:
z Copying an Installation to the Share Point Directory. (Enterprise Edition only.)
z Copying an Installation to a Network Directory on page 284.
z Copying an Installation to an FTP Server on page 285.
z Performing an Administrative Installation on page 286.
z Copying an Installation to Removable Media on page 286.
You can run Package Distribution from Wise for Windows Installer or from Software
Manager. What’s the difference? Typically, when you run Package Distribution from Wise
for Windows Installer, you distribute a project file or the compiled installable file from its
source directory. When you distribute from Software Manager, you distribute installable
files only (examples: .MSI or .EXE files) from the Software Manager database.
Therefore, when you run Package Distribution from Software Manager, the option to
distribute to the share point directory is not available.
Copying an Installation to the Share Point Directory

You can use Package Distribution to copy an installation or merge module to the share
point directory, for later importing into the Software Manager database. This lets you
store all installation information in a centralized location and use Software Manager to
manage installation resources. See Sharing Installation Resources on page 30.
Distributing to the share point directory does not actually import the package into the
Software Manager database, but copies it to a directory in a format that can be imported
into the Software Manager database. You use Software Manager to import it from the
share point.
When you distribute to the share point directory:

z All the installation’s source files are copied to the share point directory and the
source paths for those files are updated. See Where are Installation Resources
Stored? on page 28.
z If the Application Name and Package Name fields are not blank, the package’s
meta data is added to the Software Manager database, if it is not already there.
z You might want to copy the installation file to the Scripts subdirectory of the share
point directory, if the installation is not already located in the share point directory.
When is This Option Available?

z This option is available only if you are connected to a share point directory that is
associated with a Software Manager database. Typically, this connection is made
during installation. To use a different share point directory and Software Manager
database, see Setting Repository Options on page 49.
z This option is not available when you use Package Distribution from Software
Manager, because packages listed in Software Manager are already in the Software
Manager database.
To copy an installation to the share point directory:

1. Click Distribute in the lower right of the window. (In Visual Studio: select Project
menu > Package Distribution.)
2. If you are in a .WSI that contains multiple releases, a drop-down list appears. Select
a release.
3. Mark Distribute to share point directory.
4. Click Next. If necessary, the installation file is saved and compiled.
The Distribute to share point directory dialog appears.
5. Share Point (read-only) displays the share point directory to which the installation
will be copied. It defaults to the share point directory that is specified in Wise
Options.
6. The Copy Installation File To checkbox enables Pathname. During distribution, a

copy of the installation file is placed in the directory you specify here, and its source
paths are updated to reflect the location of the source files in the share point
directory.
Caution
(Wise Editor only.) If an installation file is located in the share point directory, Copy
Installation File To is cleared by default. If you mark it, then 2 copies of the
installation file will be in the share point directory, which can lead to confusion about
which file to edit.
Caution
(Visual Studio integrated editor only.) If you clear this checkbox, the source paths in
the project will be overwritten with the paths in the share point directory. If the
project is bound to other projects in the solution, these bindings will be broken.
In most cases, if the installation file is not already in the share point directory, it
is best to specify the Scripts\<application name>\<package name>
subdirectory of the share point directory, which is the default.

If you are distributing an .MSI or .WSI that is set to compile with external files,
specify either a subdirectory of Scripts or some other directory. This prevents
overwriting of any external files that might also be used by another installation.
To verify how the installation is set to compile, go to the Media page and look at
the Compression Option on the Media Details dialog.
Clear this if you don’t want to copy the installation file (recommended in the
Wise editor only).
7. Application Name and Package Name are pre-filled with data from the Product
Details page; the application and package names are used if defined; otherwise, the
product name and version are used. These names will be assigned to the installation
when it is imported into the Software Manager database.
If the package’s meta data is in the Software Manager database, don’t change these
names. If you change the names, you will have 2 packages in the database for the
same installation: a package with just meta data and the package you import. See
Adding Meta Data to the Software Manager Database on page 95.
8. Click Finish.
If a package with resources and the same package path is already in the Software
Manager database a warning message appears asking if you want to overwrite it.
Click Yes to re-import the package.
The installation or merge module is copied to the share point directory. From there, it
can be imported into the Software Manager database through Software Manager. See
Importing From the Share Point Directory in the Software Manager Help.
Copying an Installation to a Network Directory

When you are ready to deploy an installation to end users, share it with a coworker, or
copy it to another computer, you can use Package Distribution to copy a compiled
installation to a network directory.
Note
To copy an installation and its .PDF or .SMS file, distribute the .WSI file unless one never
existed.
a release.
3. Mark Network.
The Network Directory dialog appears.
Network Directory
Specify the directory to copy the package to. This can be a relative path or a
path variable.

Destination File Name

(Optional.) Enter an alternate name for the file that is saved to the network
directory. Do not include a file extension.
6. Click Finish.
Copying an Installation to an FTP Server

When you are ready to deploy an installation to end users, you can use Package
Distribution to copy the compiled installation to an FTP server.
Package Distribution uses the FTP protocol to transfer the files to the server location you
specify. End users can download the files from the FTP server using an FTP client. If the
server is also configured to run a Web server, end users can download the files through
their Web browser (HTTP protocol) as well. Package Distribution does not support
passive FTP, which is required by some firewall and gateway configurations, and it
cannot FTP through a proxy server.
a release.
3. Mark FTP Server.
The FTP Server dialog appears.
FTP Server Address

The address of the FTP server to transfer the package files to. Example:
ftp.server.com.
FTP Logon Name

A valid logon name for this FTP server. The logon name must have write access
to the directory to transfer files to.
FTP Logon Password

A valid password.
FTP Upload Directory

The directory on the FTP server to copy the package to. The first character must
be a forward slash (/). Example: /published/installations.
6. Click Next.
The package is uploaded to the FTP server. A dialog shows the status of the upload.
7. Click Finish.
Note
If this option does not work as you expect, open an FTP client, configure it with the
same information you entered in Package Distribution, and make sure it works.
(Windows contains a default FTP client.)

Performing an Administrative Installation

When a Windows Installer installation is ready to deploy to end users, you can use
Package Distribution to perform an administrative installation. An administrative
installation copies a source image of the application to a network; the source image
resembles the directory structure of the installed application. End users who have access
to the administrative installation can then install the application from the network
location.
See Administrative Installation in the Windows Installer SDK Help.
a release.
3. Mark Administrative Installation.
The Administrative Installation dialog appears.
Network Directory
Specify the directory in which to place the administrative installation.
Use Short File Names

Mark this if you are copying the administrative installation to a location that
does not support long file names. This sets the SHORTFILENAMES property,
causing all file names and directories in the administrative installation to be
shortened to their 8.3 equivalent names. See SHORTFILENAMES Property in the
Windows Installer SDK help.
6. Click Finish.
An executable version of the package is copied to the directory you specified.
Copying an Installation to Removable Media

When an installation is ready to deploy to end users, you can use Package Distribution to
copy the compiled installation to floppy disks or other removable media, such as zip
disks. You cannot copy an installation to a rewritable CD; instead, use a CD creation
program.
a release.
3. Mark Removable Media.

If the installation contains 2 or more media destinations (defined on the Media

page), the Distribution Media Directories dialog appears. This dialog displays the
media destination settings you entered when you configured the media items.
Although you specify these media directories as destinations for compiling, they
actually serve as sources when you distribute.
5. If the Distribution Media Directories dialog appears, check the following lists to
verify that the installation files are in the proper directories before you distribute
them.
Volume Label
Displays the value you entered when you created this destination on the Media
Details dialog.
Directory
Displays the media destination you entered on the Media Details dialog. If you
moved the compiled files since compiling, edit this value to point to the new
location. Either click and type directly in the column, or select the row to edit
and browse to the new location of the files.
6. Click Next on the Distribution Media dialog.
The Removable Media dialog appears.
Destination Disk
Select the letter of the drive to which files will be copied. Only removable-media
drives connected to the computer are displayed.
Disk Label
Enter a name for the finished disk that will contain the installation.
Setup Filename
Enter the name for the final installation file. You do not need to enter an
extension. If you leave this blank, the final installation file is named the same as
the currently-open installation file.
Erase Disk Before File Copy

Mark this to erase the target disk before copying the installation onto it.
8. Click Finish.
The installation is copied to the media. You are prompted to insert new media as
necessary.
If you are distributing a single file that is too large for the media specified, you are
prompted to insert a higher capacity media. If that is not possible, use the Media page
to span the installation across multiple media. See Setting Up Media for Distribution on
page 201.
WiseUpdate
WiseUpdate® offers an easy method for updating your application on your end users’
computers, ensuring that end users are always working with the most current version of
your application. Based on settings you specify on the WiseUpdate page, WiseUpdate
installs a small client application along with your application. You can place a shortcut to
this application in the end user’s Startup group so that it checks for updates when the

destination computer is booted or an end user logs on to Windows. WiseUpdate Client

checks for newer versions of your application at the Web location you specified. If it
finds a new installation, it downloads and runs it.
WiseUpdate, by itself, does not deploy the current version of your application; it simply
adds a Web-based update mechanism to your end users’ computers. The first time you
configure WiseUpdate, you enable that version to check for later versions over the
Internet. Once WiseUpdate is integrated into your application, it simplifies the upgrade
process for you and your end users for future updates to your application. For details,
see Configuring the WiseUpdate Page on page 290.
When WiseUpdate runs on the destination computer, the end user can change proxy
server information or the check interval by clicking the Advanced button on the first
dialog of the wizard.
Also see:
The WiseUpdate Process on page 289

Using WiseUpdate in an Installation on page 289
Options for Running WiseUpdate Client on page 295
WiseUpdate Tips on page 296
Troubleshooting WiseUpdate on page 297

The WiseUpdate Process

Phase 1: Your Computer Your Web Server (FTP/HTTP):
z Contains the WiseUpdate
When you first use WiseUpdate, you:
1. Develop the installation update file that stores:
The current version number
2. Configure WiseUpdate and
(FTP) URLs to the installation files
specify:
z Contains the installation files
Location of updates on the Web
server 3. Upload to the Web server: and Readme
Current version of the WiseUpdate update file
application Installation files and Readme
Phase 2: Destination Computer

The end user:
1. Obtains your application through normal distribution channels
2. Installs your application:
WiseUpdate Client is copied to the application directory
A shortcut to WiseUpdate client is placed on the destination computer
Phase 3: Your Computer Your Web Server (FTP/HTTP):

z Contains the WiseUpdate
When you update your application to
a new version, you: update file that stores:
The new version number
1. Develop an upgrade or patch
(FTP) URLs to the new installation
2. Configure WiseUpdate and
specify: files
z Contains the new installation
Same Web location as the 3. Upload to the Web server:
original WiseUpdate update file
files and Readme
New version of the application Installation files and Readme
Phase 4: Destination Computer Your Web Server (FTP/HTTP)
(HTTP)
When WiseUpdate Client is run on the destination computer, it:

z Runs an upgrade wizard
z Reads the WiseUpdate update file on the Web server
z Determines that a new version exists
z Displays the Readme
z Downloads and runs new installation files
z Updates the local version
Using WiseUpdate in an Installation


To use WiseUpdate® effectively, you must use it in 2 or more successive versions of

your application. Using it in one version of your application only enables that version to
check for later versions over the Internet.
Process for Using WiseUpdate Effectively

1. Select Installation Expert > WiseUpdate page.
2. Mark Include WiseUpdate Client.
This causes WiseUpdate Client, a small executable file (WiseUpdt.exe), to be

included in the installation and installed on the destination computer in the main
application directory along with your application.
3. Configure the WiseUpdate page. For details, see Configuring the WiseUpdate Page
on page 290.
4. When the installation is tested and ready for distribution, upload the installation
files, the Readme file, and the update file to a Web server in one of the following
ways:
Run Package Distribution using the FTP Server option. (See Uploading
WiseUpdate Files With Package Distribution on page 292.) Do not use Package
Distribution if your network setup requires that you use a proxy server to FTP
files or if you want to place files in different directories.
Use any FTP client. (See Uploading WiseUpdate Files With an FTP Client on
page 294.)
Caution
If you do not upload the files before deploying your application to end users, they
see an error when they attempt to check for upgrades.
5. Test the WiseUpdate process. For details, see Testing WiseUpdate on page 294.
6. Distribute your application using your usual method. Examples: CD or WebDeploy.
7. The next time you update your application, do the following:
a. Format it as an upgrade or a patch.
b. Update the Version field on the Product Details page, otherwise the
maintenance mode will be entered.
c. Upload the updated installation files to the Web server.
After you upload the updated application, end users who have WiseUpdate will be
prompted to update their application over the Internet.
Configuring the WiseUpdate Page

Completing the WiseUpdate page causes the WiseUpdate Client to be installed in the
application directory on the destination computer along with your application. Most of
the fields on this page specify information to be embedded inside WiseUpdate Client.
This information tells the client when, how, and where to check the Web location for new
versions.

The first time you configure WiseUpdate, you enable that version to check for later
versions over the Internet. To enable the Internet updating capability, you must use
WiseUpdate for each successive version of your application.
1. Select Installation Expert > WiseUpdate page.
2. Mark Include WiseUpdate Client.
3. Complete the page:
Host Address
Enter the Web server address where you plan to store updated installation files.
(Example: www.company.com.) You can also enter the server’s IP address.
Note
The Web location you select should be accessible through both the FTP and the
HTTP protocols—Package Distribution uses FTP to transfer files to it, and end
users use HTTP (WiseUpdate Client) to read and download files from it. See
WiseUpdate Tips on page 296.
Host Username
If necessary, enter the username that’s required to connect to the host address.
Typically, Web servers don’t require user names and passwords. This is used for
basic HTTP authentication.
Host Password
If necessary, enter the password that’s required to connect to the host address.
Enter this only if the Host Username is entered above.
Host Directory
Enter the directory on the Web server where you plan to store updated
installation files, including the WiseUpdate update file. To put the files in the
root directory of the host, leave this blank.
If you are working in an update, the directory must be the same as in the
original version of the installation.
Update Filename
Enter a name for the WiseUpdate update file and use the extension .INI.
(Example: WiseUpdate.ini.) This file is created during compile. In subsequent
versions of this installation, the file name must be the same as in the original
version of the installation. See About the WiseUpdate Update File on page 292.
Product Version
Enter the current version of the installation. This version is stored with your
application on the destination computer and is compared to the version stored
in the update file on the Web server.
Check Interval (days)

Enter the frequency at which to remind the end user to check for updates. This
works in conjunction with the Add client to StartUp group checkbox below.
If you place the WiseUpdate shortcut in the StartUp group on the destination
computer, WiseUpdate Client runs when the destination computer is booted or
the end user logs on to Windows. If the check interval has been reached,
WiseUpdate Client runs normally, prompting the end user to check for updates.
If the check interval has not been reached, WiseUpdate Client runs silently and
quits.

Alternate Web Page

Enter a URL to direct the end user to if WiseUpdate Client cannot check for
updates or download the installation files. You might direct the end user to a
Web page that contains technical support information, upgrade information, or
a discussion of possible problems.
Start Menu Icon

This is enabled when you mark the Add client to StartUp group checkbox
below. Enter a name for a shortcut to be created in the Startup group of the
destination computer’s Windows Start menu. This name cannot contain special
characters such as /, :, *, or ?.
Add client to StartUp group

Mark this to have the installation add a shortcut for WiseUpdate Client to the
Startup group of the Windows Start menu on the destination computer. Then,
when the destination computer is booted or the end user logs on to Windows,
the shortcut runs WiseUpdate Client according to the Check Interval (days)
setting described above.
If you do not mark this checkbox, then WiseUpdate Client will never be run on
the end user’s computer unless you code your application to run it. For details,
see Options for Running WiseUpdate Client on page 295.
About the WiseUpdate Update File

On the WiseUpdate page, you enter a name for the WiseUpdate update file, which is
created during compile. Later, the update file is uploaded to a Web server. When
WiseUpdate Client runs on the destination computer, it reads the update file to
determine if a new version exists, and if so, where to find the new version and its
Readme.
The update file is in .INI format and contains information you enter on the WiseUpdate
page. It is formatted as follows:
[WiseUpdate]
Version=2.0
Size=1095391
Install=http://www.company.com/updates/Application.exe
ReadMe=http://www.company.com/updates/Readme.rtf
where:
z Version is the version of installation that is available on the server.
z Size is the size of the installation in bytes.
z Install is the URL to the installation.
z ReadMe is the URL to the installation’s Readme file. If there is no Readme file, the
Readme line is omitted.
Uploading WiseUpdate Files With Package

Distribution

After you complete the WiseUpdate page and are ready to distribute an installation, you
can use Package Distribution’s FTP Server option to upload installation files to a Web
server. The files you upload are:
z The compiled installation file or files.
z An optional Readme file.
z The WiseUpdate update file, which specifies the current version of the application,
the URL to the installation files, and the URL to the Readme. See About the
WiseUpdate Update File on page 292.
Because FTP and HTTP are different protocols controlled by different servers, the
connection information you entered on the WiseUpdate page might differ from the
information you enter in Package Distribution.
Package Distribution cannot FTP through a proxy server and it does not support placing
different files in different directories. If you need that capability, see Uploading
WiseUpdate Files With an FTP Client on page 294.
To use Package Distribution with WiseUpdate:

1. Click Compile to make sure the installation is compiled. (In Visual Studio: select a
Build command from the Build menu.)
2. Click Distribute. (In Visual Studio: select Project menu > Package Distribution.)
3. In the Welcome dialog, mark FTP Server and click Next.
The Upload WiseUpdate Information dialog appears.
4. Mark Upload WiseUpdate client information. The following options become

enabled:
ReadMe File
If you’re using WiseUpdate for the first time, you can leave this blank. However,
if you’ve used WiseUpdate before and are now uploading an update, specify a
Readme file in text or rich text format (.RTF), which will be displayed to the end
user before the upgrade. RTF files cannot contain embedded graphics.
Product Version
Enter the version to be stored in the update file. WiseUpdate Client compares
this version to the version on the destination computer to determine if an
update is needed. Usually, this should be the same as the Product Version
field on the WiseUpdate page and the Version field on the Product Details
page. You can force updates by entering a later version in this field.
Example: If the version deployed on the destination computer is 1.0.0, and you
enter 1.0.2 in this field, it will trigger the destination computer to be updated.
5. Click Next.
The Upload Installation dialog appears.
6. On the Upload Installation dialog, enter FTP information that points to the same
Web location you specified on the WiseUpdate page and click Next.
The installation files, the Readme you selected, and a WiseUpdate update file are
uploaded to the Web server you specified. If this is the first time you’ve used
WiseUpdate for this application, test the WiseUpdate process thoroughly to make sure
that no network-specific problems occur. See Testing WiseUpdate on page 294.

Uploading WiseUpdate Files With an FTP Client

Package Distribution cannot FTP through a proxy server and it does not support placing
different files in different directories. If your network setup requires that you upload files
through a proxy server, or if your HTTP server does not support FTP uploads, you cannot
use Package Distribution to upload the files to the Web server. You can still use
WiseUpdate, but you must do manually what Package Distribution does automatically.
Use an FTP client to upload the following items to the Host Address and Host
Directory you specified on the WiseUpdate page:
z The compiled installation file or files.
z An optional Readme file.
z The WiseUpdate update file, which specifies the current version of the application,
the URL to the installation files, and the URL to the Readme. See About the
WiseUpdate Update File on page 292.
You can place the installation files and Readme at any Web location, provided their URLs
are recorded correctly in the WiseUpdate update file.
When you enter the URLs in the FTP client, make sure they match the case of the actual
path on the Web server. Some HTTP servers are case-sensitive and display errors if the
case does not match exactly.
Testing WiseUpdate
After you configure the WiseUpdate page and upload files to the FTP server, you should
test the WiseUpdate process.
To test how WiseUpdate works when an update is not needed:

In this test, the end user’s version of your application matches the version on the Web
server.
1. Install the first version of your application on a testing computer (not your
development computer).
2. On the testing computer, open your application’s installation directory and double-
click the file WiseUpdt.exe. Normally, this file is run automatically at prescribed
intervals at startup, but for testing purposes, you run the .EXE directly.
WiseUpdate Client opens, customized with your application’s name.
3. Click Next.
WiseUpdate Client uses the HTTP connection information that you specified on the
WiseUpdate page to read the WiseUpdate update file on the Web server. If you are
running the same version of your application as that on the server, a message
notifies you that you are running the latest version.
4. Close the WiseUpdate Client window.
If this test is not successful, see WiseUpdate Tips on page 296 and Troubleshooting
WiseUpdate on page 297.

If this test is successful, follow the next procedure to test what happens when the
version of your application on the Web server is later than the end user’s version.
To test how WiseUpdate works when an update is needed:

1. To make the application on the server appear to be a later version, do one of the
following:
On your development computer, in the Upload WiseUpdate Information dialog,

enter a later product version. (Example: If the original version was 1.0.0, enter
1.0.2.) Then compile the installation and run Package Distribution again. This
updates the update file on the Web server to indicate a new product version.
If you are not using Package Distribution, manually edit the update file on the
Web server so that the version is later.
2. On the testing computer, open your application’s installation directory and double-
click the file WiseUpdt.exe. Then click Next.
Because the version on the Web server is now later than the version on the testing
computer, WiseUpdate Client displays the Readme file and then displays an option to
download and run the installation.
3. You can download and run the installation, but installation will fail unless the version
on the server is an upgrade or patch that updates the currently installed version. In
a real-life scenario, when you put updates on the server, they must be configured as
upgrades or patches.
4. Restore the correct version information to the server by doing one of the following:
On your development computer, compile and run Package Distribution again,

and enter the original version in the Upload WiseUpdate Information dialog.
Edit the WiseUpdate update file on the Web server.
If this test is not successful, see WiseUpdate Tips on page 296 and Troubleshooting
WiseUpdate on page 297.
If you see the Web page you entered in the Alternate Web Page field on the
WiseUpdate page, then there was a problem connecting to the host via HTTP, or the
necessary files were not found on the host.
Options for Running WiseUpdate Client

Options on the WiseUpdate page determine how WiseUpdate Client (WiseUpdt.exe) is
run on the destination computer.
Run Silently From a Shortcut on the Destination Computer

z On the WiseUpdate page, mark the Add client to Startup group checkbox and
enter a value in the Check Interval (days) field.
z The installation adds a shortcut for WiseUpdate Client to the Startup group of the
Windows Start menu on the destination computer.
z When the destination computer is booted or the end user logs on to Windows,
WiseUpdate Client silently checks the time elapsed since it last ran. If the number of
days elapsed is greater than the check interval value, WiseUpdate Client prompts
the end user to check for updates.

Run From Your Application

z On the WiseUpdate page, clear the Add client to Startup group checkbox.
Entering a value in the Check Interval (days) field is optional.
z Code your application to open the file WiseUpdt.exe from the application directory,
in either of the following ways:
Run WiseUpdate Client when the application is run.

To use the check interval value from the WiseUpdate page, run WiseUpdate
Client with the /c command line option. Then WiseUpdate Client silently checks
the time elapsed since it last ran. If the number of days elapsed is greater than
the check interval value, WiseUpdate Client prompts the end user to check for
updates.
Add a menu command in your application to run WiseUpdate Client.
WiseUpdate Tips
Can WiseUpdate be used with WebDeploy?
Yes. Make sure that update installations you release are formatted as upgrades (use the
Upgrades page). You cannot use WebDeploy to run patch files (.MSP).
WebDeploy embeds connection information into the .EXE of the .MSI/.EXE pair, so that
the .EXE can launch the .MSI from a location on the Web. WiseUpdate provides for
regular checking for updates initiated by the application on the destination computer. If
you plan to put all compiled files in the same location on the Web, then specify the same
directory on both the WebDeploy and WiseUpdate pages.
Because the .EXE of an .MSI/.EXE pair might contain optional runtimes (examples:
Windows Installer or .NET runtimes), WiseUpdate always attempts to open the .EXE, not
the .MSI. Follow these guidelines:
z The .EXE of the .MSI/.EXE pair must be located somewhere on the Web and must be
accessible to WiseUpdate users. It cannot be distributed through e-mail or other
mechanisms.
z On the WiseUpdate page, the connection information you enter must point to the
location of the WiseUpdate update file on the Web server.
What does the FTP Server option in Package Distribution do?

Package Distribution provides an FTP client that can upload files to an FTP server.
However, Package Distribution cannot FTP through a proxy server and it does not
support placing different files in different directories. Most commercial and shareware
FTP clients work through a proxy server and let you copy files individually, create
folders, and so on. If you plan to place different compiled files in different locations on
the Web, use your own FTP client instead of Package Distribution. Example: You might
upload the .MSI but not its corresponding .EXE, because you plan to e-mail the .EXE to
end users.
Does WiseUpdate work if the Web location of the WiseUpdate update

file changes?
No. Once you start using WiseUpdate, all subsequent versions of the WiseUpdate update
file must be located in the same directory as the original. This is because the

WiseUpdate Client that’s already on end user’s computers only knows to look at the Web
location you set when you originally configured it. Therefore, when you configure the
WiseUpdate page for subsequent versions of the same application, make sure that the
Host fields and the Update Filename field are the same as in the original version of
the installation.
Why are there 3 different fields that accept the product version?
During the WiseUpdate process, you encounter 3 different fields that require a product
version. How are these fields related?
z The Version field on the Product Details page sets the version for the application,
and is used by Windows Installer to determine whether updates and patches are
valid upgrades for the installed version.
z The Product Version field on the WiseUpdate page sets the version in the registry
of the destination computer, which WiseUpdate Client checks against the update file
on the FTP server.
z The Product Version field on the Upload WiseUpdate Information dialog of Package
Distribution sets the version stored in the update file on the FTP server.
Typically, all 3 of these fields should have the same version number, but you can change
the versions to force upgrades.
Troubleshooting WiseUpdate
If you encounter problems with WiseUpdate during testing or after deploying your
application, check the following suggestions.
z Use an FTP client to observe what files are the on the Web server and where they
are located. Open the WiseUpdate update file that is located on the Web server and
see if the referenced paths are valid.
z WiseUpdate Client uses HTTP to connect to the Web server specified on the
WiseUpdate page. Package Distribution’s FTP Server option uses the FTP protocol
to upload the installation .EXE, an optional Readme file, and a WiseUpdate update
file. Both operations access the same location on the same server. Therefore, both
protocols must have access to the directory, and the host must be able to process
both HTTP and FTP requests. Also, the Host Directory, the Host Username, and
the Host Password might be different for using the FTP protocol than for using the
HTTP protocol. This is because the Web server and the FTP server might have
different alias and user information, but point to the same directory.
z Updates for Windows Installer installations must be in the form of an upgrade or

patch. If the end user has version 1.0.0 of your application installed, and you make
some changes to it and upload it with a new version number, the WiseUpdate
upgrade will fail unless you configured the updated package as an upgrade (using
the Upgrades page) or a patch (using Patch Creation).
z If end users cannot view the Readme file in WiseUpdate Client, make sure the
Readme file does not have embedded graphics, which are not supported.

Chapter 13
Upgrading Applications
Windows Installer provides 2 main methods for upgrading installations: patching and
upgrading. You can also have the end user upgrade by uninstalling and then reinstalling,
although this method is not recommended. You can create upgrades and patches for
installations using the UpgradeSync tool, Patch Creation tool, and the Upgrades page.
Topics include:
z Preparing for Software Updates.
z UpgradeSync (a tool that improves the quality of patches).
z Patches.
z Upgrades.
For information on upgrading, see the following topics in the Windows Installer SDK
Help.
Patching and Upgrades

Preparing an Application for Future Major Upgrades
Small Updates
Minor Upgrades
Major Upgrades
UpgradeCode Property
Patching
Changing the Product Code
Preparing for Software Updates

Preparing for updates starts when you ship the first version of your application. Use the
following steps to prepare for a software update:
1. Archive the Shipping Version of the .MSI on page 298.
2. Determine the Form of the Update on page 299.
3. Determine the Product Code and Product Version on page 300.
4. Check the Installation With UpgradeSync on page 300.
Archive the Shipping Version of the .MSI

This is the first step in preparing for an update.
Planning for the next software update should start when you ship the first version of
your application. To create an update, you must have access to previous versions of the
installation. Always archive the shipping installation in a place that is accessible. Even if
you compile and ship the installation as an .EXE, archive the .MSI, which is created
alongside the .EXE. If the installation included .CABs or other files, archive those also.

Determine the Form of the Update

This is the second step in preparing for an update.
An update can be a patch, an upgrade, or a reinstall. You can create both a patch and an
upgrade of the same installation. If you do not create a patch or an upgrade, your
update is a reinstall by default. You can also use command line options to cause an
upgrade to completely or partially reinstall.
About Patches
z Can only update an existing application.
z Can update multiple previous versions to the current version.
z Can only update an application originally installed with Windows Installer

technology.
z Are small, containing only the changes between the original and updated
applications.
z Are created with the Patch Creation tool; see Creating a Patch File on page 304.
z Allow little flexibility in customizing an update. Example: You cannot change feature
states, leave certain features installed, or perform custom actions based on the
version of the installed application.
About Upgrades
z Used when you make major changes to an installation.
z Update an existing application or install the entire application.
z Are at least as large as a stand-alone installation.
z Can update multiple versions of an installed application.
z After installing the new version, check for components of the previous version that
are no longer needed and remove them.
z Allow flexibility in customizing an update. Example: You can run custom actions and
specify features to leave on the destination computer based on what version is
already installed.
z Are created on the Upgrades page; see Upgrades on page 311.
About Reinstalls
z Are required by default if you don’t provide for another method of updating, such as
a patch or upgrade. Reinstalls are forced by the operating system if the version and
the product code are the same.
z If the product code is changed, then the updated application can be installed
alongside the original application, or can inadvertently be installed over the original
application.
z Are not recommended for updating an application.
z Should only be used to update if one of the following is true:
The update is so small that only the contents of a few files changed. No new
files or registry keys were added, and none were removed.

The update is so large that you want the old and new versions to be able to
coexist on the same computer.
If you make changes to the installation (Example: adding or removing files), you must
change the product version. If you do not change the product version and the end user
tries to reinstall, it can result in an invalid mix of old and new files. If the product version
is incremented, the installation displays a message stating that the application is already
installed and installation cannot continue. The end user must uninstall the application
and run the installation to install the new version. To avoid this, use patches or
upgrades.
Determine the Product Code and Product Version

This is the third step in preparing for an update.
Before deploying an updated installation, you must determine whether you need to
change the product code and the product version. Windows Installer uses the product
code and product version to determine how to handle an upgrade. Also, your company’s
support department might need to differentiate updates based on product version.
You change the product code and product version on the Product Details page. For
information on when to change them, see Patching and Upgrades in the Windows
Installer SDK Help. Also see Changing the Product Code in the Windows Installer SDK
Help.
Caution
If you are releasing a newer version of your application but are not using an upgrade or
patch, it is very important to enter a new version on the Product Details page. Not doing
so can cause the installation to open in maintenance mode instead of in normal
installation mode. This can result in an invalid installation that is a mixture of old and
new files, which can cause errors in your application. The only exception is if the
installation contains no new files, no deletion of files, and no other system changes,
which means that only the contents of files are changed.
Check the Installation With UpgradeSync

This is the fourth step in preparing for an update.
UpgradeSync changes the current installation in preparation for creating either a patch
or upgrade. UpgradeSync compares the current installation to the previous version of
the installation and prepares the current installation for a patch or upgrade.
See UpgradeSync on page 300.
UpgradeSync
Using UpgradeSync is one of the steps in preparing software for updates; see Preparing
for Software Updates on page 298.
UpgradeSync compares the current package with the previous version of the package,
and does the following to prepare the current package for a patch or upgrade:
z Changes the PackageCode, ProductCode, and ProductVersion properties if

necessary.

z Aligns component GUIDs. If GUIDs or key paths for the same component don’t
match between the new and old .MSI, the component could inadvertently get
deleted because Windows Installer does not recognize the components as being the
same. Aligning component GUIDs for matching components prevents upgrades from
deleting necessary files in the newer version.
z Detects errors that could cause problems with a patch or upgrade and, if possible,
fixes them.
Note
UpgradeSync does not create an upgrade or patch; it eliminates the most commonly
encountered problems that cause patches and upgrades to work incorrectly. Use
UpgradeSync before you create a patch or an upgrade. Use Patch Creation to create a
patch and the Upgrades page to create an upgrade.
For information on the different types of updates and when to change the ProductCode
and ProductVersion, see Patching and Upgrades in the Windows Installer SDK Help.
UpgradeSync changes your current installation according to Microsoft’s
recommendations, based on the type of upgrade you plan to make.
When you add new resources to an upgrade installation, you can use component rules to
ensure that the component GUIDs are aligned with those in previous installations. See
Using Component Rules to Align GUIDs in an Upgrade on page 59.
Also see:
About GUIDs on page 524

Using UpgradeSync
Using UpgradeSync
1. Open the current version of the installation file (.WSI or .MSI).
2. Select Tools menu > UpgradeSync. (In Visual Studio: Project menu >
UpgradeSync.)
3. In Previous MSI path, specify the pathname of the previous .MSI.
You must specify an .MSI here, even if you deployed the installation as a single-file
.EXE. The .MSI is created in the same directory as the .EXE during compile.
4. Click Next.
The Upgrade Type dialog appears.
Small Update
Select this to ship this installation as a patch or reinstall. Small updates
generally contain minimal changes to the contents of files. This option changes
the package code.
Minor Upgrade
Select this to ship this installation as a patch or reinstall. Minor upgrades
generally contain changes such as new or removed features, files, or other
items. This option changes the package code and forces you to increment the
product version of the current installation if it is the same as the previous .MSI’s
product version.

Major Upgrade
Select this to ship the current installation as an upgrade. You usually ship an
installation as an upgrade when it contains comprehensive changes, but you
can create an upgrade for minimal changes. This option changes the package
code and product code, and forces you to increment the product version of the
current installation if it is the same as the previous .MSI’s product version.
Current Version
If you selected either the Minor or Major Upgrade options, and this is the same
as Previous Version, then you must increment it. If you do not increment it,
an error occurs when you click Next.
6. Click Next.
The Upgrading/Patching Issues dialog appears.
This dialog lists issues in the installation that might cause problems when creating
an upgrade or a patch. These errors are the most common causes of patch and
upgrade failures reported by Windows Installer users. Errors that can be fixed
automatically have a checkbox. The following types of error cannot be fixed
automatically and therefore have no checkboxes:
File ‘filename.txt’ is a new resource that needs to be added to a new

component and assigned to a new subfeature.
This means that a new resource has been added to an existing component. This
violates Microsoft Windows Installer guidelines, and can cause problems. Put
the resource in its own component in Setup Editor > Component tab.
Component ‘componentname.exe’ exists in the previous version and

the keypath does not exist in the current install. The component’s
contents will be deleted during an upgrade.
This means that the component is in the old version, but not in the new version.
This might be intentional, so it is not fixed automatically. If it is not intentional,
add the component to the new version to prevent it from being deleted during
upgrading or patching. Add the component in Setup Editor > Component tab.
7. Mark the checkboxes of the errors to fix.
8. Click Save to File to save the errors to a text file.
9. Click Finish.
The necessary changes are made to the installation. If you plan to create a patch or
upgrade, use Patch Creation or the Upgrades page. See Creating a Patch File on
page 304 or Creating an Upgrade on page 311.
Also see Preparing for Software Updates on page 298.
Patches
Use Patch Creation to create a Windows Installer patch file (.MSP) that updates installed
versions of a Windows Installer-based application. A patch file can update one or several
previous versions. Unlike full installations, a patch installation contains only the
information necessary to update an installed version of the application.
Patch Creation uses 3 files from the Microsoft Windows Installer SDK: PATCHWIZ.DLL,
MSPATCHC.DLL, and MAKECAB.EXE. They are installed in the Wise for Windows Installer
application directory. You specify settings in Patch Creation, and it saves those settings

in a patch settings file (.PCP). Patch Creation then sends the patch settings file to
PATCHWIZ.DLL, which creates the patch file (.MSP).
Patch Creation Guidelines

z Before you use Patch Creation, use UpgradeSync. See UpgradeSync on page 300.
z The package code must be different between the old installations and the new
installation. To see the package code, click the Summary icon in Setup Editor >
Product tab. Changing the Version field on the Product Details page causes the
package code to be updated, as does running UpgradeSync.
z The previous version or versions must have been installed using Windows Installer.
z To edit an existing patch, you need access to its patch settings file (.PCP).
z If you created any previous patches for an installation, you need access to the most
recent patch file (.MSP) to read its file sequence number and disk ID.
z You need access to the complete installation in .MSI format for every installation
that this patch will upgrade and for the latest version of your application. If the
installation includes external compressed or uncompressed files, you need them
also.
Note
If you compiled the installation as an .EXE, you need the .MSI for the installation
because Patch Creation does not operate on .EXE files. The .MSI is created in the
same directory as the .EXE during compile.
Patching Assemblies in the Global Assembly Cache
¾ Windows Installer 3.0 or later.

Prior to Windows Installer 3.0, it was difficult to patch assemblies that were installed in
the Global Assembly Cache (GAC), because the files could not be found.
When you patch an assembly that is installed in the GAC, Windows Installer 3.0
identifies and finds the original file and applies a binary patch. This eliminates the need
for Windows Installer to access the original installation source in order to patch an
assembly installed in the GAC. See MsiPatchOldAssemblyName Table and
MsiPatchOldAssemblyFile Table in the Windows Installer SDK Help.
Also see:
About Patch Sequencing on page 303

Creating a Patch File on page 304
For additional topics, see Upgrading Applications on page 298.
About Patch Sequencing

¾ Windows Installer 3.0 or later.
Patch sequencing ensures that patches are applied in the correct order, regardless of the
order in which they are actually provided to the destination computer.
Sequencing is supported for small update patches only. Sequenced patches can be
installed by Windows Installer 2.0, but the sequencing is ignored.

You add sequencing information to a patch during Patch Creation. You can add
sequencing to a patch you created previously. Step through Patch Creation, open an
existing patch file, enter sequencing information, and complete the wizard to recompile
the patch.
Order in Which Patches Are Applied

1. Patches without sequence information are applied in the order they are provided to
the destination computer. Example: If Patch2 is provided before Patch1, they will be
applied in that order.
2. Sequenced patches are applied in sequence order.
Patch Families
A patch family is a group of patches that update the same, similar, or related
functionality of the application and should be applied in a specific order relative to other
patches in the same family. Most patches belong to a single family, and most
applications are updated by a single family. However, a patch can belong to multiple
families if it applies to more than one application or includes multiple fixes.
Example: Suppose you have 2 applications that are sold separately, but are also sold
together as a suite. Patches A and C update only Application1 and belong to family 100.
Patch B updates only Application2 and belongs to family 200. Patch D updates both
applications and belongs to family 100 and family 200.
You might sequence these patches as follows:
Patch Updates Family Sequence

A Application1 100 10
B Application2 200 10
C Application1 100 20
D Application1 100 30
Application2 200 20
The patches would be applied to the applications in this order:
z Family 100: A, C, D
z Family 200: B, D
Also see:
Specifying the Patch Sequence on page 309

Patches on page 302
Sequencing Patches and MsiPatchSequence Table in the Windows Installer SDK Help
Creating a Patch File

Before you create a patch file, see the guidelines in Patches on page 302.
1. Select Tools menu > Patch Creation. (In Visual Studio: Project menu > Patch
Creation.)

The Welcome dialog appears, listing the basic steps for creating a patch file. The
wizard guides you through each step.
2. Click Next.
The Specify Patch Settings File dialog appears.
3. Choose one of these options:
Create a new patch file

Creates a new patch settings file (.PCP file).
Open an existing patch settings file

If you mark this, also specify the .PCP file.
4. Click Next.
The Specify Previous Versions dialog appears, where you select .MSI files of
previous versions that this patch updates, referred to as targets. When this patch is
run on a destination computer, it verifies that a valid target exists before
installation. You must add at least one previous version to this list.
5. To add a previous version, click Add.
The Previous Version Details dialog appears.
6. Complete the dialog and click OK. See Specifying Previous Versions for Patches on
page 307.
7. If you are prompted to run an administrative installation because the installation

database is compressed, click Yes.
The patch creation process, which is executed by the Microsoft-provided file

PATCHWIZ.DLL, operates on uncompressed files only. Typically, the files in an .MSI
are compressed. The administrative installation places all the files of the installation
in a temporary directory. After the administrative installation finishes, the Specify
Previous Versions dialog appears again.
Note
Microsoft’s Windows Installer engine is called to perform the administrative
installation. If the operation fails for any reason, the error message generated by
Windows Installer displays. To work around the error open the .MSI, set it to
generate uncompressed files, and recompile. Then specify the uncompressed
version on the Specify Previous Version dialog. To set an .MSI to generate
uncompressed files, go to the Media page, click Details at the right of the page, and
in Compression Option select Uncompressed external files.
8. Repeat the steps above to add additional previous versions.
9. When you finish, click Next on the Specify Previous Versions dialog.
The Specify Upgrade Version dialog appears.
Upgrade MSI path

The earlier versions of your application will be upgraded to the version you
specify here. By default, the path to the current installation’s .MSI appears.
Advanced
Click this to enter advanced settings. The Advanced Upgrade Version Details
dialog appears. Complete the dialog and click OK; see Advanced Upgrade
Version Details on page 308.

11. Click Next on the Specify Upgrade Version dialog.
12. If you are prompted to run an administrative installation again, click Yes. If you are
prompted to update the package code, click Yes.
If Windows Installer 3.0 or later is installed on your computer, the Patch Sequencing
dialog appears. Complete the dialog and click OK; see Specifying the Patch
Sequence on page 309. Otherwise, the Compile Patch dialog appears.
13. Complete the Compile Patch dialog:
Output .MSP file

Specify a full pathname for the patch file that you distribute to end users.
Advanced Settings
Click Advanced to display the Advanced Patch Settings dialog. Complete the
dialog and click OK. See Specifying Advanced Patch Settings on page 309.
Patch Removal
(Windows Installer 3.0 or later only.) To make this patch removable through
Add/Remove Programs, click Allow Removal and complete the Patch Removal
Settings dialog. See Specifying Patch Removal Settings on page 310.
Note
Multi-patch Media Settings: During patch creation, entries are made in the Media
table of the patch installation. The following options populate the Media table. For
each subsequent patch, the file sequence start number and the disk ID start number
must be higher than the one in the previous .MSI or patch file. To enter these
numbers accurately, you must have access to the most recent patch file distributed
to end users.
File Sequence Start, Disk ID Start

The file sequence number indicates which files in the File table are located on a
particular source disk. The disk ID number indicates how many media entries
are in the Media table. For patches, these numbers must be at least 1 greater
than the corresponding numbers in the most recent patch or .MSI for this
application installation. To specify these numbers, browse to the most recent
patch file created for this installation.
Volume Label
Enter the name of the CD or other media on which this patch will ship. If the
application needs repair in the future, Windows Installer uses this label to tell
the end user what media to insert to perform the repair. If the patch is not
shipped on any media but is distributed over the Internet, this field is ignored.
Disk Prompt
Enter the prompt that the end user should see if this application needs to be
repaired. Example: Insert the disk labeled Application 2.0.
14. Click Next to begin the patch creation process.
During patch creation, you might see a message stating that the versions between
the target image (previous version) and upgrade image (new version) do not match.
This is normal; click Yes if this message appears.
Note
If the date and time of a file in the upgrade is earlier than the date and time of the
matching file in the original installation, Patch Creation changes the date of the file
in the upgrade file to be later than that of the original installation.

The Compile Patch dialog notifies you when the patch creation is completed.
15. Click View Log to view a log file of all actions performed by Patchwiz.dll to create the
patch.
If the patch file could not be created, use the log file to determine the source of the
error.
Also see:
Patches on page 302

Removing Patches in the Windows Installer SDK Help
For additional topics, see Upgrading Applications on page 298.
Specifying Previous Versions for Patches

1. Access the Previous Version Details dialog. See Creating a Patch File on page 304.
This dialog is not related to the System Search page in Installation Expert, which
lets you search for files, registry entries, and components, or search .INI files.
Previous MSI path

Specify the path to an .MSI that can be upgraded by this patch. You must
specify an .MSI, even if you deployed the installation as a single-file .EXE.
Ignore missing files while making patch

Mark this if you have files that you do not want to put in the patch, such as a
ReadMe file. This lets you delete files from the .MSI without receiving an error
during patch file creation.
Match Product Code

Mark this if this patch should be installed only if the product code of the
installed application on the destination computer matches the product code of
the current installation. The product code is located on the Product Details
page.
Match Upgrade Code

Leave this marked to make sure that the upgrade code is the same for the
previous application and upgrade application. The upgrade code should always
be the same for different versions of the same application.
Match Language
Mark this to confirm that the language codes match between the target and
upgrade images.
Version To Check
Select what parts of the product version—the major, minor, or update version—
should be used in the version relationship comparison. Example: Suppose the
product version is 2.4.6801. The first segment is the major version; the second
segment is the minor version; and the third segment is the update version (also
called build version).
The version for each installation is in the Version field on the Product Details
page.

Version Relationship
Select a comparison that must be true in order for the patch to be installed.
Base Version is the version of the package you use to create the patch; this is
the version you specify in Previous MSI path. Installed Version is the version
of the package being upgraded. In most cases, you should select the
relationship Base Version must be = Installed Version. This means that the
previous version you used to create this patch must match the version installed
on the destination computer.
C++ Symbol File Directories (Optional)

If your application is written in C++, you can make your patch files smaller by
specifying the directories where your Symbol and Object files are stored for the
previous version of your application.
Advanced Upgrade Version Details

1. Access the Advanced Upgrade Version Details dialog. See Creating a Patch File on
page 304.
Patch GUID
Each patch file is assigned a GUID, independent of product codes and upgrade
codes. The installation uses this to track which patches have been applied to an
application. To change this value, click Generate or paste another valid GUID
into this field. See About GUIDs on page 524.
Previous Patch GUIDs to replace

This lists the GUIDs of previous patches that might have been applied to the
original installation. You can browse for additional patches and add their GUIDs
to this list. This list of GUIDs should not be delimited; do not enter spaces or
other characters between the GUIDs.
If any of these patches are found on the destination computer and are
registered with Windows Installer, they are unregistered and their patch
transforms are removed from the list of transforms associated with the
application. This lets you apply a patch to an original installation without having
applied any intermediate patches. Example: If this patch represents Service
Pack 2, setting this field lets end users upgrade to Service Pack 2 even if they
did not install Service Pack 1.
Read Product Codes to Upgrade from Target .MSI Files

By default, the product codes are read from the .MSI files of the previous
versions that you specified. If you do not want the product codes to be read
from the previous version .MSI files, clear this checkbox.
Additional Product Codes

If you cleared the previous checkbox, specify a product code or codes;
otherwise no valid targets exist for this patch file. If the previous checkbox is
marked, product codes you enter are added to the product codes that are read
from previous version .MSI files. The product codes must be in GUID format,
separated by semicolons.
C++ Symbol File Directories (Optional)

If your application is written in C++, you can make your patch files smaller by
specifying the directories where your Symbol and Object files are stored for the
upgrade version of your application.

Specifying the Patch Sequence

1. Access the Patch Sequencing dialog. See Creating a Patch File on page 304.
2. On the Patch Sequencing dialog, click Add to specify sequencing information.
The Patch Sequence Details dialog appears.
Patch Family
Specify the patch family that this patch belongs to.
To sequence this patch after a specific patch, click Browse and select a patch file
(.MSP). This populates the Patch Family and the Sequence Within Family
fields. Example: If you browse to a patch that is in Family01 and has a sequence
of 10, the current patch will be added to Family01 with a sequence of 20
(sequences are generated in increments of 10). If the selected patch belongs to
multiple families, the first family found is used.
Sequence Within Family

Enter a number to specify the order in which this patch should be applied,
relative to other patches in this patch family. The default sequence number is
the previous sequence plus 10.
Product Code
Typically, you should leave this field blank, which causes the patch to be applied
to all targets in the family. If you enter a product code GUID, then sequencing is
used only when the patch is applied to the installation defined by that GUID,
relative to other patches in the family.
Replace previous sequenced patches with this patch

Mark this to have this patch supersede the updates provided by earlier patches
in this patch family. A patch supersedes earlier patches in a patch family when it
includes all functionality contained in earlier patches in the family. A small
update patch cannot supersede a minor upgrade or major upgrade patch.
4. On the Patch Sequencing dialog, add more sequencing information if needed. When
you finish, click Next to continue the Patch Creation wizard.
Also see:

Sequencing Patches and MsiPatchSequence Table in the Windows Installer SDK Help
Specifying Advanced Patch Settings

1. On the Compile Patch dialog of Patch Creation, click Advanced to display the
Advanced Patch Settings dialog. See Creating a Patch File on page 304.
Do not create file patches, use entire files in patch package

Mark this to have the patch file contain entire files instead of only the changed
bits of files. Example: Suppose that only 5 files have changed between version
1.0 and version 1.0.1 of your application. If this checkbox is cleared, the
resulting patch file contains only the changed bits between the 5 files; if this
checkbox is marked, the patch file contains the 5 files in their entirety.

Allow Product Codes to differ between the upgrade and prior versions
Mark this to upgrade a previous version even if it has a different product code.
This global setting overrides the validation settings you specified on the
Previous Version Details dialog.
Allow Version Number to differ between the upgrade and prior versions
Mark this to have the patch be able to upgrade a previous version if its version
number is different. This global setting overrides the validation settings you
specified on the Previous Version Details dialog. You should always leave this
checkbox marked.
Create a log file

Mark this to create a log file containing details of the patch creation. If an error
occurs in the process, refer to this file for information about what caused the
error. The log file has the same name you gave to the output .MSP file with the
extension .LOG, and is in the same directory.
Specifying Patch Removal Settings

You can make a patch removable through Add/Remove Programs. This lets end users
uninstall a patch without having to uninstall the entire application. For information on
which patches can be removed, see Uninstallable Patches in the Windows Installer SDK
Help.
1. On the Compile Patch dialog of Patch Creation, click Allow Removal to display the
Patch Removal Settings dialog. See Creating a Patch File on page 304.
Make This Patch Removable

Mark this to make this patch removable through Add/Remove Programs.
When you make a patch removable, enter values for the following meta data,
which is used by Add/Remove programs. Only the Classification is required.
Description
Enter a brief description of the patch that will appear in Add/Remove programs.
DisplayName
Enter a name for the patch that will appear in Add/Remove Programs.
Classification
(Required.) Enter text to describe the category of updates that this patch
belongs to. The category descriptions are arbitrary. Examples: hot fix, security
rollup, update, critical update, service pack, update rollup, and so on.
ManufacturerName
Enter the manufacturer or publisher of the application.
TargetProductName
Enter the name of the application that this patch updates.
MoreInfoURL
Enter a URL where end users can get online support for the application.

Upgrades
Use the Upgrades page to create an installation that upgrades previous versions of an
application. During an upgrade, the installation searches the destination computer for
applications that can be upgraded, and upon detection, retrieves its version information
from the registry. The installation uses this information along with the criteria on the
Upgrades page to determine whether the installed application should be upgraded. Then
the installation silently uninstalls the previous version and installs the new version.
Note
Upgrading is only supported in Windows Installer runtime v1.1 or later.
What You Need to Create an Upgrade

z The previous version or versions, which you are upgrading, must have been
installed using Windows Installer.
z You need access to the .MSI of each version you are upgrading.
z If you do not have access to the .MSI files, you must have the upgrade code and
version information from the .MSI files. The upgrade code is stored in the
UpgradeCode property, which is in the Properties icon in Setup Editor > Product tab.
The version is located on the Product Details page.
z The product code of this installation should be different from the product codes of
the installations you will upgrade.
What is the Upgrade Code?

The upgrade code is a property that is set when you create a new installation. It should
be the same for a related set of applications. When the end user launches an installation
on the destination computer, Windows Installer searches for applications with the same
upgrade code.
The upgrade code is the only information required for creating an upgrade. If no other
upgrade specifications are entered, it is used as the sole factor for determining whether
the upgrade takes place. You can see the upgrade code under the Properties icon in
Setup Editor > Product tab. It is in GUID format.
Creating an Upgrade
1. Select Installation Expert > Upgrades page.
2. Click Add at the right of the page and specify the .MSI or .WSI for the previous
version of the application.
If you see a warning to update the current installation’s product code, click Yes.
The Upgrade Details dialog appears.
Upgrade Code
If you specified an .MSI or .WSI to upgrade, this is filled in with that .MSI’s
upgrade code. If you did not specify an .MSI, you must enter the upgrade code
of the installation you want to upgrade. See What is the Upgrade Code? on
page 311.

Minimum Version
Enter the minimum version that should be upgraded by this installation. The
version you enter here is not upgraded unless you mark the Include minimum
version in range checkbox.
Include minimum version in range

Mark this to include the minimum version as a valid upgrade. If you clear this,
only versions greater than the minimum version are upgraded.
Maximum Version
Enter the maximum version that should be upgraded by this installation. The
version you enter here is not upgraded unless you mark the Include
maximum version in range checkbox.
Include maximum version in range

Mark this to include the maximum version as a valid upgrade. If you clear this,
only versions below the maximum version are upgraded.
Languages
This determines if an application should be upgraded based on its language.
Enter a semicolon-delimited list of languages that should be upgraded by this
installation. If this is left blank, all languages are included. Example: To upgrade
only the American English version, enter 1033. See Language IDs on page 279.
Exclude languages in list

Mark this to reverse the function of the Languages field, causing this
installation to upgrade only the versions not listed in the Languages field.
Example: To upgrade every version except the American English version, enter
1033 in the Languages field and mark this checkbox.
Features to remove
If this is left blank, the upgrade removes all existing features from the installed
application, and then installs the features specified in the new installation. To
prevent the removal of a feature or features, you must specify the features you
want removed. Then the upgrade removes only the features you specify and
leaves any other features. The list of features should be comma-delimited. The
feature names must exactly match those in the previous version.
Example: Suppose Application 1.0 contains the features Feature1, Feature2,

and Feature3. Application 2.0 contains the features Feature1, Feature2, and
Feature4; Feature3 has been dropped. When you upgrade 1.0 users, you enter
Feature1, Feature2 in Features to remove. When the upgrade takes place,
Windows Installer first removes the features Feature1 and Feature2 from the
existing installation, then installs the features Feature1, Feature2, and
Feature4. Therefore, users of 1.0 still have the feature Feature3 on their
computer.
Action Property
Specify a property to run a particular custom action based on which product
version is already installed. During installation, if an application with the same
upgrade code is found on the destination computer, its product code is placed
into this property. You can set conditions on custom actions so that they
execute based on the contents of this property. If you choose to create a new
property, enter its name in all uppercase letters, and add it to the list of
restricted public properties, which is stored in the SecureCustomProperties
property. Only restricted public properties appear in this list.

Continue installation after a remove failure

Mark this to continue the installation, even if it is unable to remove one or more
features of the installed application.
Migrate feature states

Mark this to retain the feature states of the installed application during the
upgrade. Example: If the end user chose not to install a feature, such as a spell
checker, in the initial installation, the upgrade will not install it either.
Do not uninstall previous version

Mark this to keep the previous version of the application on the destination
computer when the upgrade is installed. This lets the end user have 2 versions
of the application installed.
4. Click OK.

Chapter 14
Working With Source Paths
You might find that you need to work with source paths during installation development.
Project files (.WSI) reference files you add to the installation by their source path. Each
time you compile, the files are copied from the source path to the .MSI.
Topics include:
z Using Source Control. (Not available in the Visual Studio integrated editor.)
z About Path Variables.
z Source Paths in an Installation.
In the Enterprise Edition, you can distribute an installation to the share point directory
so that it can be imported into the Software Manager database. When you distribute to
the share point, all the installation’s source files are copied to the share point and the
source paths for those files are updated in the installation. See Copying an Installation
to the Share Point Directory on page 282.
Using Source Control

Visual Studio .NET contains built-in source control functionality.
Source code control is the control, tracking, and recording of all changes made to a set
of source code files. Various commercial and open-source software applications, such as
Microsoft Visual SourceSafe, act as source code control systems (SCCS). All SCCS
applications have similar functionality: tracking who is working on what file; allowing for
retrieval of previous versions, backing out of changes, adding and removing files from
the SCCS; and recording the history of files. They might also provide functionality for
viewing the differences between versions of files.
Wise for Windows Installer integrates with leading SCCS applications to let you perform
source control tasks on an installation. Wise for Windows Installer determines the SCCS
that you are using and calls APIs that interact with it. The API functions display dialogs
and functionality directly from your SCCS. On the Source Control tab in Wise Options,
you enable source code control and set the global level of interaction between your
SCCS and Wise for Windows Installer. See Setting Source Control Options on page 51.
To use source control, you must:
z Have an SCCS installed on your computer, have a valid account, and you might need
permissions to create new directories and add files. Because Wise for Windows
Installer works though your existing user account, the permissions you experience
in Wise for Windows Installer are the same as those you already have set in your
SCCS.
z Enable the Source Control menu by marking the Enable source control checkbox
in Wise Options. If you do not have an SCCS installed on your system, the Source

Control menu is hidden and the Source Control tab in Wise Options displays an
informational message.
Note
If your installation is already located in your source control system, you can connect to
the existing installation. Do a Get of all the installation files to your hard drive, then
follow the procedure in Adding an Installation to Source Control on page 315.
How XML Files Integrate With Source Code Control

To ensure that the XML copy is always synchronized with the original installation file, be
sure to mark the Create XML copy during save checkbox in Wise Options.
If an XML copy of an installation is in the same directory as the installation file:
z Source control tasks that you perform on the current installation file are also
performed on its XML copy. This ensures that both versions remain synchronized.
(The XML copy does not appear on the SCCS dialogs.)
z When you show history, the XML file is used instead of the installation file.
z When you compare differences, the XML file is used instead of the installation file. In
Visual Studio integrated editor, you cannot perform comparisons with the XML file.
This is a Visual Studio limitation.
z If you are using the Visual Studio source code control, do not check out files outside
of the Visual Studio interface. If you do, the installation file and its XML copy will get
out of sync.
See Saving an Installation as XML on page 86.
Also see:
Adding Files to an Installation in Source Control on page 316

Checking Files Into Source Control on page 317
Checking Files Out from Source Control on page 318
Getting Latest Version of Files on page 318
Removing Files from Source Control on page 319
Undoing the Check Out of Files on page 319
Showing History of the Installation File on page 319
Showing the Differences Between Installation Files on page 320
Comparing the Current Installation to the Latest in Source Control on page 320
Adding an Installation to Source Control

Visual Studio .NET contains built-in source control functionality.
To use source control, you must have a source code control system (SCCS) installed on
your computer. For information about source control, see Using Source Control on
page 314.
1. If the commands in the Source Control menu are disabled, do the following:
a. Select Tools menu > Options > Source Control tab.
b. Mark Enable source control. This enables the Source Control menu.

c. Click OK to exit Wise Options.
2. Select Source Control menu > Add.
Dialogs from your SCCS appear, in which you connect to your SCCS and select the
location where this installation should be stored. To get further help on any of these
options, see the help system for your SCCS. If this installation is already located in
your SCCS, you can connect to it by selecting its current location when prompted.
After the SCCS-related dialogs appear, the Add to Source Control dialog appears.
This dialog contains the files that you add on the Files, Web Files, or Visual Studio
Solution page and resource files from the Wise for Windows Installer directory that
are part of every new installation.
Note
If you are working in a .WSI, only the .WSI can be added to source control; there is
no way to add the corresponding compiled .MSI. The .WSI or .MSI you are working
in does not appear on the Add to Source Control dialog because it is added
automatically. Only files that are currently part of the installation appear. If you later
add more files, repeat this process to add those files to the SCCS.
3. On the Add to Source Control dialog, mark the checkboxes of the files to add to
source control and click OK. Comments, which are stored as an attribute of the file
in the SCCS, are optional. If necessary, scroll to the right to view the Type and File
Path columns.
The Copy Files to New Location dialog appears if any files are not in the directory
tree of the installation file. Because all files that you add to source control must be
in the same directory tree as the installation file, this dialog prompts you to move
the files to a new directory under the installation file directory.
4. Mark the checkboxes of the files to copy to the same directory tree as the
installation file. To change the new location, click Change Dir and select another
directory within the same directory tree.
The New Location column indicates the directory to which files will be copied. (Scroll
right to see the New Location column.) If you later edit a file, you must edit the file
that is copied to the new location, because that is the file that is compiled into the
installation.
Note
To avoid moving files, cancel this operation, remove this project from source control,
and move the installation file into the same directory tree as its source files.
5. Click OK.
After the installation is added to your SCCS, use the options in the Source Control menu
to coordinate file transactions between your computer and the SCCS. Whenever you add
files to the installation, repeat the process above to add them to your SCCS.
Also see Adding Files to an Installation in Source Control on page 316.
Adding Files to an Installation in Source Control


When you add files to an installation, you must also add them to your source code
control system (SCCS), even if you’ve previously added the installation to source
control. Example: Suppose you add an installation to source control, along with source
files A.dll, B.txt, and C.jpg. Later, you add the file D.gif to the installation. To get D.gif
into source control follow the procedure below.
1. Select Source Control menu > Add.
The Add to Source Control dialog appears. This dialog shows files in the installation
that have not yet been added to source control.
2. Mark the checkboxes of the files in the installation to add to source control and click
OK. Comments, which are stored as an attribute of the file in the SCCS, are
optional.
The Copy Files to New Location dialog appears if any files are not in the directory
tree of the installation file. Because all files that you add to source control must be
in the same directory tree as the installation file, this dialog prompts you to move
the files to a new directory under the installation file directory.
3. Mark the checkboxes of the files to copy to the same directory tree as the
installation file. To change the new location, click Change Dir and select another
directory within the same directory tree.
The New Location column indicates the directory to which files will be copied. (Scroll
right to see the New Location column.) If you later edit a file, you must edit the file
that is copied to the new location, because that is the file that is compiled into the
installation.
Note
To avoid moving files, cancel this operation, remove this project from source control,
and move the installation file into the same directory tree as its source files.
4. Click OK.
After the installation is added to your SCCS, use the options in the Source Control menu
to coordinate file transactions between your computer and the SCCS. Whenever you add
files to the installation, repeat the process above to add them to your SCCS.
Also see:
Using Source Control on page 314

Adding an Installation to Source Control on page 315
Checking Files Into Source Control

You can use this feature only if you’ve added the current installation to your source code
control system (SCCS).
If you check a file in, then attempt to work on it, you are prompted to save it with a new
name because the file is locked for changes unless it is checked out first.
1. Select Source Control menu > Check In.
The Check In dialog appears, listing all files that have previously been checked out.

Note
When you add an installation to source control, the installation file (.WSI or .MSI) is
added and is also checked out, so it might appear in this dialog even if you
previously did not check it out.
2. Mark the checkboxes of the files to check into source control and click OK.
Comments, which are stored as an attribute of the file in the SCCS, are optional.
Also see:

Checking Files Out from Source Control

If you check a file in, then attempt to work on it, you are prompted to save it with a new
name because the file is locked for changes unless it is checked out first.
1. Select Source Control menu > Check Out.
The Check Out dialog appears, listing all files that have previously been checked in.
Note
When you add an installation to source control, all files except the installation file
(.WSI or .MSI) are checked in, so they might appear in this dialog even if you
previously did not check them in.
2. Mark the checkboxes of the files to check out from source control and click OK.
Also see:

Getting Latest Version of Files

1. Select Source Control menu > Get Latest Version.
The Get Latest Version dialog appears, listing all files in the installation.
2. Mark the checkboxes of the files to get from source control and click OK. You cannot
select a new location to copy files you get; they replace the existing files at the
check in/check out location.

Also see:

Removing Files from Source Control

1. Select Source Control menu > Remove.
The Remove dialog appears, listing all files in the installation.
2. Mark the checkboxes of the files to remove from source control and click OK.
Also see:

Undoing the Check Out of Files

1. Select Source Control menu > Undo Check Out.
The Undo Check Out dialog appears, listing all files that have been checked out.
Note
When you add a installation to source control, the installation file (.WSI or .MSI) is
added and is also checked out, so it might appear in this dialog even if you
previously did not check it out.
2. Mark the checkboxes of the files for which to undo check out. This backs out your
changes to the file, and checks the file back into source control.
Also see:

Showing History of the Installation File


You can view the history of an installation in terms of its check in/check out activity in
the SCCS. You can only view the history of the installation file (.WSI or .MSI), not the
other source files associated with the installation. If an XML copy of the installation
exists, the Show History command displays the history of the XML file instead of the
installation file. To view the history of files other than the installation file, use your SCCS
directly.
To view the history of the installation file, select Source Control menu > Show History.
Dialogs from your SCCS appear. For information on these dialogs, consult the
documentation for your SCCS. In Microsoft Visual SourceSafe, the History Options dialog
appears, followed by the History of ProjectFileName.wsi dialog.
Also see:

Showing the Differences Between Installation Files

SCCS applications commonly have functionality to let you see the differences between
the installation located on your local computer and the installation in the SCCS.
To access this feature from Wise for Windows Installer, select Source Control menu >
Show Differences. Dialogs that are unique to your SCCS appear. For help using these
dialogs to show differences, consult the documentation for your SCCS.
Note
If you are using Microsoft Visual SourceSafe, the Difference Options dialog appears. You
might need to select the SourceSafe folder and the Windows folder to compare in the
Compare and To fields. Then click the Project button for differences.
To perform a compare using Visual MSIDiff instead, use the Compare to Latest menu
command. It performs a table-by-table, row-by-row comparison of the current
installation file to the installation file in your SCCS. See Comparing the Current
Installation to the Latest in Source Control.
Also see:

Comparing the Current Installation to the Latest in Source

Control

You can perform a table-by-table, row-by-row comparison of the database tables that
make up an installation file (.MSI or .WSI). The current installation file is compared to
the latest installation file that is checked into your SCCS.
1. Select Source Control menu > Compare to Latest.
You are taken to Setup Editor > Tables tab and the Visual MSIDiff Key dialog
appears, which describes icons that indicate changes. Changes are shown in the
tables and rows where they occur.
2. On the Visual MSIDiff Key dialog, take note of the symbols and colors that indicate
changes and click OK.
If the Visual MSIDiff Key dialog does not appear, you might have clicked its Do not
show this dialog again checkbox. You can reactivate this dialog on the Prompts
tab in Wise Options.
3. On the Tables tab, scroll through tables, looking for the symbols for changed tables.
Click changed tables to view differences in rows, which are indicated by symbols and
colors.
As you work in the installation file, the symbols indicating changed items are
updated dynamically.
4. To turn the compare off, which closes the comparison file and returns to the current
file, select Tools menu > Visual MSIDiff > End Current Compare. Closing the file also
ends the compare.
Another command in the Source Control menu, Show Differences, lets you use the
compare technology offered by your SCCS. See Showing the Differences Between
Installation Files on page 320.
Also see:

About Path Variables

Note
(Visual Studio integrated editor only.) This feature is independent of Visual Studio .NET’s
Configuration Manager feature, which lets you store source files in Release and Debug
directories.
When you add a file to an installation, its source path is stored. During compile, the
source path information is used to find the file and compile it into the .MSI or .EXE. The
Path Variables page lets you define variables to replace commonly-used source paths.
However, it has no effect on files that are already part of the installation. For these files,
see Source Paths in an Installation on page 324. If you add a file, and its source path
matches one of the paths defined on the Path Variables page, the variable that
represents the path is stored instead of the hard-coded path.
Example: Suppose the source files for your test build are in C:\Application\Test, and the
source files for your production build are in C:\Application\Production. You could create
a user-defined path variable named Application_Files and set it to C:\Application\Test. If
you then add the test build source files, their source path would contain the variable
name. You could then change this path variable to C:\Application\Production for your
production build.

Note
Do not create more than one variable that refers to the same path, because only one of
them is used when you add files.
Predefined Path Variables

Commonly used paths, particularly system-related paths, are predefined on the Path
Variables page. By default, they are enabled, which means all files you add from
common folders contain path variables as part of the source pathname. You cannot
modify predefined path variables, but you can turn substitution off; see Turning Path
Variable Substitution On and Off on page 322.
Use to Replace Substrings

You can also use path variables to replace any matching substring in a path. Example: If
files are in C:\Development\Application\Version1.0, you could create a path variable
named Version and set it to Version 1.0. Each time an instance of “Version 1.0” was
found in a path, it would be replaced with [Version].
Options for Creating a Path Variable

z Creating a User-Defined Path Variable on page 322.
z Creating a Path Variable Based on an Environment Variable on page 323.
z Creating a Path Variable Based on a Registry Value on page 323.
Turning Path Variable Substitution On and Off

The Path Variables page lets you define variables to replace commonly-used source
paths. Once these variables are defined, you can turn them on and off.
1. Select Installation Expert > Path Variables page.
2. Mark or clear the checkbox in the Replace column.
Turning substitution off does not remove the path variable from paths for files added
previously; it only affects paths for files added subsequently.
Also see About Path Variables on page 321.
Creating a User-Defined Path Variable

You can create a user-defined path variable that is set to a directory on your system. For
information on using variables for source paths, see About Path Variables on page 321.
2. Click Add at the right of the page and select User-Defined Path Variable.
The User-Defined Path Variable Details dialog appears.
Variable Name
Enter any name, but do not use special characters or spaces. Because this is not
a Windows Installer property, you do not need to follow Windows Installer
property naming conventions. This variable is inserted into the pathnames of
files that are pulled from the directory that appears in Current Value.

Current Value
(Read-only) This displays what you enter in Defined Value.
Defined Value
Specify the directory to replace with a variable. When you add a file from this
directory, the variable name replaces the pathname.
Replace When Matched

Mark this to activate this path variable. If this is cleared, this path variable has
no effect on files you add to the installation.
4. Click OK.
Creating a Path Variable Based on an Environment Variable

You can create a path variable that is set to the value of an environment variable. For
information on using variables for source paths, see About Path Variables on page 321.
2. Click Add at the right of the page and select Environment Path Variable.
The Environment Variable Path Variable Details dialog appears.
Variable Name
Current Value
(Read-only) This displays the current value of the environment variable you
select below.
Env. Variable
This list contains the environment variables that are currently defined on your
computer. Select an environment variable that contains a directory path.

4. Click OK.
Creating a Path Variable Based on a Registry Value

You can create a path variable that is set to a registry value. For information on using
variables for source paths, see About Path Variables on page 321.
When a registry path value is displayed on the Path Variables page, a double slash
precedes the value name. This is normal. (You might have to scroll to the right to see
this value in the Defined Value column.)
2. Click Add at the right of the page and select Registry Path Variable.
The Registry Path Variable Details dialog appears.

Variable Name
Current Value
(Read-only.) This shows the current data of the registry value specified below.
Reg. Key
Specify the complete key name of the registry value that contains a directory
path. The registry browser that appears shows only key names (folder icons).
You specify the value in Reg. Value below.
Reg. Value
Select the value to pull a directory name from. This list shows the values
contained in the key you selected above.

4. Click OK.
Source Paths in an Installation

Note
(Visual Studio integrated editor only.) This feature is independent of Visual Studio .NET’s
Configuration Manager feature, which lets you store source files in Release and Debug
directories.
As you work on an installation, paths to files listed on the Files, Web Files, or Visual
Studio Solution page can become invalid if you:
z Move files that are part of the installation to a new directory on your computer or
network.
z Move the installation file itself from your computer to another computer.
z Use relative pathnames and then move the installation file.
z Rename a directory.
If paths are invalid, then during compile error messages appear in the Task List
concerning the files that could not be opened. Rather than adding the files again, you
can specify the new source directories for these files.
The Convert Source Paths dialog lets you change the directories that contain an
installation’s files. You can also change all the directories to either relative or UNC
(Uniform Naming Convention) paths. If you change directories to relative paths, then
the installation can be opened on any computer that has the same relative directory
structure. If you change the directories to UNC paths, you can leave the source files on a
server but open the installation from any computer on the local network.
Whether the path to a file is stored depends on what kind of file you’re working in. When
you add a file to an .WSI or .MSI, the path to the file is stored, and each time you
compile, the file is recompressed into the resulting .MSI. However, if you open an .MSI
that was compiled from a .WSI, it does not store paths to the files because the files are

encapsulated inside the .MSI. You cannot change the source paths of files encapsulated
inside an .MSI.
To see a file’s path, go to the Files, Web Files, or Visual Studio Solution page and double-
click a file in the lower right list box. The File Details dialog appears, which displays the
pathname for the file in the Source Pathname field. If this field only displays a file
name or is blank, then you are working in an .MSI that was compiled from a .WSI. If
files do not have paths, you can either double-click on each file and define a path, or
convert the .MSI to a .WSI by using MSI to WSI Conversion.
Also see:
Changing Source Directories on page 325

Converting to Relative Source File Paths on page 326
Converting to UNC-Based Source File Paths on page 326
Changing the Source Directory Dynamically During Compile on page 327
Changing Source Directories

When you change source directories, you can specify a new path for a selected directory
or for multiple directories.
1. Select Tools menu > Convert Source Paths. (In Visual Studio: Project menu >
Convert Source Paths.)
The Convert Source Paths dialog appears with a list of all the directories that are
referenced in the installation.
2. Select a directory from the list.
To change multiple directories, select a high-level directory so that you can change
all of its subdirectories.
The Change Selected Path dialog appears.
Change to
Specify the new pathname.
Mark this to change the subdirectories of the current directory.
5. Click OK.
The Change Source Directories to column displays the new pathname. If you
marked Change Sub-Directories, all directories that start with the same name as
the one you changed are renamed.
Example: If you change C:\Program Files\Application\Manual to C:\Program

Files\Application\Online Manuals, all the directories that begin with C:\Program
Files\Application\Manuals are changed.
6. To make additional changes, repeat the preceding steps.
7. To set the path type for files that you add to the installation later, make a selection
from Path Type on the Convert Source Paths dialog.
You can set paths to absolute, relative, or UNC-based.

8. Click OK.
All parts of the installation that reference these directories are updated.
Also see Source Paths in an Installation on page 324.
Converting to Relative Source File Paths

You can convert the paths of source files to relative paths. You might do this to keep all
your source files in a central version and source control system. (Example: Microsoft
Visual SourceSafe. In Microsoft Visual SourceSafe, if you copy the installation files to a
different directory each time you do a Get, you can use this feature to ensure that the
paths are always valid, even though the directory structure changes.)
A relative pathname uses .\ in the path to indicate the current directory, and it uses ..\
to indicate one directory up. All paths are relative to where the .WSI or .MSI file is
located.
Example: If the path to the .WSI is C:\Development\Application.wsi, and you add the
file C:\Program Files\Application.ini, the relative pathname of Application.ini is
..\Program Files\Application.ini.
The Convert Source Paths dialog appears.
2. Click Change All Paths to Relative.
The Change Source Directories to column displays the new pathnames.
A one-time conversion of the paths in the installation is performed. To change the

directories back to absolute paths, select high-level directories and change the
paths; see Changing Source Directories on page 325.
Paths to files that are not on the same drive as the installation file are not
converted, because they cannot be written as relative paths. Predefined paths, such
as [ProgramFiles], cannot be changed to relative paths.
3. To convert all directories you add to the installation later to relative paths, select
Relative Paths from Path Type.
4. Click OK.
Converting to UNC-Based Source File Paths

You can convert the mapped drive paths of source files to UNC-based (Uniform Naming
Convention) paths. This helps prevent compile errors when installation source files are
on a central file server.
Example: If you add files to an installation from your Y:\ drive, which is mapped to a file
server, paths of files you add to the installation start with Y:\. If a co-worker opens and
compiles the installation on another computer that doesn’t have its Y:\ drive mapped to
the same file server, the compile fails because the installation cannot find the source
files on the Y:\ drive. However, if you first convert all network paths to UNC paths, co-
workers on the same network can open and compile the installation without
encountering errors. Instead of a path such as Y:\Application.ini, a file has a fully
qualified path such as \\Server\Development\Application\Application.ini.

2. Click Change All Paths to UNC.
This button is only available if at least one of the paths in the installation is from a
mapped network drive.
The Change Source Directories to column displays the new pathnames. Only the
source paths that are from mapped drives are changed to UNC.
3. To convert all directories you add subsequently to UNC paths, select UNC Paths
from Path Type.
4. Click OK.
A one-time conversion of all the network paths in the installation is performed. Paths to
files that are on local drives are not converted. However, if the local drive is shared, it is
converted to the shared drive name.
Also see Source Paths in an Installation on page 324.
Changing the Source Directory Dynamically During Compile

You can define a source directory as a property, so you can easily reassign the location
of source files when you compile a .WSI or .MSI. Use this feature if you:
z Frequently change the location of source files.
z Frequently move the installation to other computers.
z Need to point to a different source directory each time you compile.
Use the procedures below to change the source directory dynamically during compile.
To create a property to hold the source directory value:

1. Select Setup Editor > Product tab and click the Properties icon in the left pane.
2. In the right pane, select New > Property from the right-click menu.
The Property Details dialog appears.
Name
Enter a new property name.
Value
Enter the directory path that currently contains the source files.
Example: Enter SourceFiles in the Name field and enter C:\Development in the
Value field. The directory path you enter here can be changed by command line
options during compile.
To point source directories to the value of the property:

1. Select Tools menu > Convert Source Paths.

2. Select the source directory to change dynamically.
The Change Selected Path dialog appears.
Change to
Enter the name of the property, surrounded by square brackets. The property
name is case-sensitive. Example: [SourceFiles].
You can add other directories to the end of the property name to create other
locations. Example:
[SourceFiles]Libraries\Visual Basic
[SourceFiles]Libraries\C++
Mark this to change the subdirectories of the current directory.
5. Click OK.
The Change Source Directories to column displays the property name in brackets.
6. Click OK.
To change the source directory by compiling from the command line:

1. Select Windows Start menu > Run.
The Run window appears.
The path of the WfWI.exe program.
The path to the .WSI or .MSI to be compiled.
The command line options to compile and set the property value.
Example: "C:\Program Files\Wise for Windows Installer\WfWI.exe"
C:\Installers\Application.wsi /c /p SourceFiles="E:\Development\"
See About Command Lines on page 209 and Source Paths in an Installation on
page 324.

Chapter 15
Merge Modules and Transforms
You can apply merge modules and transforms to installations you create in Wise for
Windows Installer. Both change the installation in some way. Merge modules are
databases that contain separate, self-contained software installations. You use them to
insert shared Windows Installer components and setup logic into an installation during
compile. Transforms are applied at runtime only, to customize the installation for a
particular group of end users.
Topics include:
z About Merge Modules.
z Available Tabs and Pages in Merge Modules.
z Creating a Merge Module As a New Installation.
z Creating a Merge Module Within a Solution.
z Creating a Merge Module From Existing Components.
z Creating a Configurable Merge Module.
z About the Merge Modules Page.
z Adding a Merge Module to an Installation.
z About Transforms.
z Creating a Transform Based on an Existing .MSI.
z Applying a Transform to an Installation.
z Multiple Instance Installations.
About Merge Modules

A merge module is a special kind of Windows Installer database that contains the
components needed to install a discrete software bundle. A merge module cannot be
installed alone, but must be merged into a standard Windows Installer installation
during compile of the installation. Typically, a merge module or a collection of merge
modules related by dependencies installs a software product or portion of a product at
runtime. The purpose of merge modules is to let you add self-contained software
modules to multiple installations. See Merge Modules in the Windows Installer SDK Help.
Example: Suppose you have 5 applications that require a specifically configured version
of the Visual Basic runtime. You could create a merge module that installs and
configures the Visual Basic runtime. Then you add the merge module to each installation
that requires that particular Visual Basic runtime. This saves you from having to add the
necessary files, registry entries, and other components to every installation individually.
It also saves time if you update the merge module; instead of updating the 5
installations for all applications, you update only the merge module, then recompile the
5 installations.

When deploying software via a merge module, keep update considerations in mind.
Example: If you deploy MSDE via a merge module, end users cannot use Microsoft’s
MSDE security patches to update that installation of MSDE. Microsoft patches only
operate on software packages installed by .MSI. You would have to incorporate the
MSDE patch changes in an update to your own application and distribute it to your end
users. This could cause security and timing issues for your end users.
You can create merge modules and add them to installations. See Adding a Merge
Module to an Installation on page 345. You can also add predefined merge modules to
an installation, which install commonly-used software packages. For information on
obtaining predefined merge modules, see Downloading Redistributable Files on page 35.
Note
When you view MSI Script in a merge module, you’ll notice that you cannot select an
installation mode, that there are no actions in the right pane, and that there are no
sequence tabs at the bottom. This is because any custom action you add to a merge
module does not contain its own sequence tables and must be merged into the
CustomAction table and the sequence tables of the main installation. See All Custom
Actions on page 469 and Using the Custom Action Location Tab for Merge Modules on
page 516.
Configurable Merge Modules

Configurable merge modules contain certain values that the installation author can
configure to specify how the module behaves in an installation. Example: A configurable
merge module might let you set attributes on components, enable or disable isolated
components, specify a bitmap for a dialog, or specify how a custom action is run.
When you add a configurable merge module to an installation, an additional dialog

appears, on which you specify values for the configurable items. You also can create
configurable merge modules.
Configurable merge modules are supported only by Windows Installer 2.0 or later. See
Configurable Merge Modules in the Windows Installer SDK Help.
Also see:
Available Tabs and Pages in Merge Modules on page 330

Creating a Merge Module As a New Installation on page 334
Creating a Merge Module Within a Solution on page 336
Creating a Merge Module From Existing Components on page 337
Creating a Configurable Merge Module on page 338
About the Merge Modules Page on page 345
Editing Merge Module Details on page 347
Available Tabs and Pages in Merge Modules

When you work in a merge module, you have access to a limited set of pages in
Installation Expert. Some of these pages are unique to merge modules.
You cannot add features to a merge module, therefore, the Features tab does not appear
in Setup Editor when you are in a merge module. Instead, the Module tab appears,
which contains information similar to that found on the Features tab. It lets you
manipulate the components, files, registry entries, and other items in the merge
module. Items you add to the merge module are listed under this tab. For information
about each icon, see Items You Can Add on the Features Tab on page 386.

The panes on the Module tab show only the items you’ve added, unless you select to
show empty folders and items from the right-click menu. The upper right pane shows
the contents of the item selected in the left pane. For an expanded view of a selected
item, double-click the item in the right pane.
Also see:
Setting Merge Module Details on page 331

Setting Dependencies for a Merge Module on page 332
Setting Exclusions for a Merge Module on page 333
Creating a Merge Module As a New Installation on page 334
Creating a Merge Module Within a Solution on page 336
Creating a Configurable Merge Module on page 338
Setting Merge Module Details

¾ Available in merge module files (.WSM, .MSM) only.
Use the Module Details page to specify the name, version, language, and type of a
merge module. Windows Installer uses this information to identify the merge module.
1. Select Installation Expert > Module Details page.
If there is no Module Details page, you are not in a merge module file.
2. Complete the page:
Module Name
Enter a name that Windows Installer and Wise for Windows Installer can use
internally to identify the merge module.
Version
Enter the version of the module. Windows Installer and Wise for Windows
Installer use this number to check versions of dependency and exclusion merge
modules. You can use the format xxxxx.xxxxx.xxxxx.xxxxx, where x is a digit.
See Version in the Windows Installer SDK Help.
Language
Enter the language code for the merge module. English is 1033. Language
neutral (meaning the merge module works with all languages) is 0. See
Language IDs on page 279.
Module Type
Select the module type. This defaults to the Default Application Type that is
specified in Wise Options. See Setting .NET Assembly Options on page 40.
Note
The ability to create .NET installations is supported only by Windows Installer
2.0 or later.
Win 32 (non .NET)

A standard Win32 merge module without .NET assemblies.
.NET Application
A .NET merge module with only .NET elements.


A merge module that contains both Win32 and .NET elements. When this
option is selected, the Generate COM interop registry keys for .NET
Assembly checkbox on the Self-registration tab of the File Details dialog is
marked by default for all .NET assemblies you add to this merge module.
The assemblies will be registered so that they can be called as though they
were COM elements.
When the .NET Application or Mixed option is selected, entries are created in
the MsiAssembly and MsiAssemblyName tables for each assembly you add to
the merge module. Also, the Global Assembly Cache appears on the Files page.
Also see Available Tabs and Pages in Merge Modules on page 330.
Setting Dependencies for a Merge Module

The Dependencies page lets you add, edit, and remove the dependencies for a merge
module.
A dependency is a merge module that is required for the current merge module to work.
Dependencies can have their own dependencies, which means that the module you
designate as a dependency could itself have a dependency on another module, and so
on. Use dependencies to compartmentalize different components of software. When you
compile an installation that contains a merge module that has a dependency, both the
original merge module and all its dependencies are merged into the installation.
Example:
Suppose you have a merge module that consists of a library of database drivers, but for
those drivers to work, MDAC must also be installed. You designate the MDAC merge
module as a dependency to the database driver module. Then, whenever you add the
database driver module to an installation, Wise for Windows Installer attempts to add
the dependency merge module, MDAC.
Wise for Windows Installer looks for dependency merge modules in the default merge
module directory specified in Wise Options, and also looks at the list of previously added
merge modules. If Wise for Windows Installer does not find the dependent module in
either of these places, it prompts you to add the dependency merge module yourself.
To add a dependency to a merge module:

1. Select Installation Expert > Dependencies page.
If there is no Dependencies page, you are not in a merge module file.
2. Click Add at the right of the Dependencies page and specify one or more merge
modules.
If you select one merge module, the Dependency Module Details dialog appears.
If you select multiple merge modules, they’re listed on the Dependencies page.
Double-click a module name to open the Dependency Module Details dialog for a
specific merge module.
Fields are populated with information extracted from the merge module.

Module ID
To specify a different merge module, click Browse.
Language ID
To specify a different language for the dependent merge module, change
Language ID. (Example: Do this if the merge module you’ve selected includes
a complete language group but you want your merge module to be dependent
on only one language in this group.) To ignore any language considerations,
enter 0.
Version
To ignore any version considerations for the merge module upon which the new
merge module will be dependent, leave Version blank.
4. Click OK.
The merge module is added to the Dependencies page.
Note
The information on the Dependency Module Details dialog fills the
ModuleDependency table, which you can see in Setup Editor > Tables tab. See
ModuleDependency Table in the Windows Installer SDK Help.
Setting Exclusions for a Merge Module

The Exclusions page lets you add, edit, and remove the exclusions for a merge module.
Exclusions are a way of preventing 2 incompatible merge modules from being merged
into the same installation. You can set merge modules to be exclusions of each other.
Example: Suppose you have 2 versions of the same merge module: version 1.0 and
version 1.1. These 2 merge modules should never be installed together, so you make
each an exclusion of the other.
Completing the Exclusions page enters the exclusion information in the ModuleExclusion
table in the Windows Installer database and triggers compile and verification error
messages if both merge modules are included in the same installation.
To add an exclusion to a merge module:

1. Select Installation Expert > Exclusions page.
If there is no Exclusions page, you are not in a merge module file.
2. Click Add at the right of the Exclusions page and specify one or more merge
modules to exclude from the current merge module.
If you select one merge module, the Exclusion Module Details dialog appears.
If you select multiple merge modules, they’re listed on the Exclusions page. Double-
click a module name to open the Exclusion Module Details dialog for a specific
merge module.
Fields are filled in with information extracted from the merge module.

Module ID
To specify a different merge module, click Browse.
Language ID
To specify a different language for the merge module to be excluded, change
the number in Language ID. (Example: Do this if the merge module you’ve
selected includes a complete language group but you want to exclude one
language in this group only.) To ignore any language considerations, enter 0.
Min Version and Max Version

To exclude multiple versions of the same merge module, edit the Min Version
and Max Version fields to reflect the versions to exclude. If you leave these
fields blank, all versions of the merge module are excluded.
4. Click OK.
The merge module is added to the Exclusions page.
Note
The information on the Exclusion Module Details dialog fills the ModuleExclusion
table, which you can see in Setup Editor > Tables tab. See ModuleExclusion Table in
Creating a Merge Module As a New Installation

You can create a merge module in much the same way that you create a new
installation.
(Visual Studio integrated editor.) Follow this procedure to create a merge module that is
not associated with a Visual Studio .NET solution. Do this if you plan to create the merge
module and have it remain static. If it is part of a solution, it is continually rebuilt, so
creating it stand-alone makes it more stable.
To create a merge module that is part of a Visual Studio .NET solution, see Creating a
Merge Module Within a Solution on page 336.
Starting a new merge module in the Wise editor:

The New Installation File dialog opens.
2. From the Categories list, select Other Templates.
3. From the Template/Tools list, select the Merge Module icon.
4. Select a file type and a target platform, and click OK.
For information on file types, see File Types on page 67.
The Target Platform section on the New Installation File dialog is available in the
Professional and Enterprise Editions only, and appears only if Select platform in
New Installation File dialog is selected in Wise Options. For information on target
platforms, see Specifying the Target Platform in an Installation on page 76.
A new merge module opens. In Installation Expert, 4 page groups appear, showing
the pages that apply to merge modules. Go to Assembling the merge module below.

Starting a new merge module in the Visual Studio integrated editor:

1. Start Visual Studio .NET. If a solution is open, close it.
4. In the Templates list, click one of the following icons:
Merge Module File

Create an .MSM (Windows Installer merge module). Because the .MSM typically
encapsulates all the files of the merge module, it is larger and takes longer to
save. Also, some options that determine the output of an .MSM file are not
available when you work with the .MSM itself.
Merge Module Project

Create a .WSM (Windows Installer merge module project file). When you work
in an .WSM instead of an .MSM, the .WSM is smaller and you can set multiple
options for the output of the .MSM.
For information on .MSM and .WSM files, see File Types on page 67.
5. Click Open.
The new merge module opens. In Installation Expert, 4 page groups appear,
showing the pages that apply to merge modules. Go to Assembling the merge
module below.
Assembling the merge module

1. Assemble the merge module by adding files, registry entries and so on using the
pages under the Details page group. Because merge modules cannot have multiple
features, you don’t select a feature on these pages.
Note
The Files page includes an extra folder named Application. By default, files that you
add to this folder are copied to the default installation directory of the installation
into which the merge module is merged. Example: If you merge the merge module
into an installation that installs files to C:\Program Files\Product, all files you add to
the Application folder will also be installed to C:\Program Files\Product.
2. If you’re creating a configurable merge module, specify which items can be modified
when the module is merged into an installation. See Creating a Configurable Merge
Module on page 338.
3. Select the dependencies and exclusions for this merge module.
Dependencies are other merge modules that must be included with this merge
module, and exclusions are other merge modules that cannot be included with this
merge module. See Setting Dependencies for a Merge Module on page 332 and
Setting Exclusions for a Merge Module on page 333.
4. Configure the summary information for the merge module, which is described in
General Information Page on page 98.
5. Configure the Module Details page, which contains the merge module name,
language, and version, and is described in Setting Merge Module Details on
page 331.

After you create the merge module, you can add it to a standard installation. See Adding
a Merge Module to an Installation on page 345.
Also see:
About Merge Modules on page 329

Creating a Merge Module Within a Solution

When you work in the Visual Studio integrated editor, you typically create a merge
module as a project within a Visual Studio .NET solution. Because the merge module is
synchronized with the other projects in the solution, it is rebuilt every time the solution
is rebuilt. Use this method if the content of the merge module is frequently changing.
To create a merge module that is not integrated with a Visual Studio .NET solution, see
Creating a Merge Module As a New Installation on page 334.
1. Start Visual Studio .NET and open a solution.
2. Select File menu > New > Project.
3. In the Project Types list, select Wise Setup and Deployment Projects.
4. In the Templates list, do one of the following:
(Professional and Enterprise Editions.) Select the Setup Wizard icon to create a
new merge module and enter its project settings.
(Standard Edition.) Select the Merge Module icon to create a new merge module
with default settings, which you can change later.
5. In Name, enter a name for the merge module file. In Location, specify the
directory in which to save the merge module project.
6. Mark Add to Solution.
7. Click OK.
If you selected the Windows Application icon, a merge module project is created in
the location you specified and is listed in Solution Explorer. Skip the next step.
If you selected the Setup Wizard icon, the Wise Setup Wizard appears.
8. Step through the Wise Setup Wizard:
a. On the wizard’s Overview page, review the project settings.
b. On the wizards’ Project Type page, select the Merge Module option.
c. For information on other settings in this wizard, see Entering Project Settings on
page 77.
d. Click Finish.
A merge module project is created in the location you specified and is listed in
Solution Explorer.
9. Double-click the .WSM file in Solution Explorer.

The new merge module opens. In Installation Expert, 4 page groups appear,
showing the pages that apply to merge modules.
10. Assemble the merge module by adding files, registry entries and so on using the
pages under the Details page group. Because merge modules cannot have multiple
features, you don’t select a feature on these pages.
Note
The Files page includes an extra folder named Application. By default, files that you
add to this folder are copied to the default installation directory of the installation
into which the merge module is merged. Example: If you merge the merge module
into an installation that installs files to C:\Program Files\Product, all files you add to
the Application folder will also be installed to C:\Program Files\Product.
11. If you’re creating a configurable merge module, specify which items can be modified
when the module is merged into an installation. See Creating a Configurable Merge
Module on page 338.
12. Select the dependencies and exclusions for this merge module.
Dependencies are other merge modules that must be included with this merge
module, and exclusions are other merge modules that cannot be included with this
merge module. See Setting Dependencies for a Merge Module on page 332 and
Setting Exclusions for a Merge Module on page 333.
13. Configure the summary information for the merge module, which is described in
General Information Page on page 98.
14. Configure the Module Details page, which contains the merge module name,
language, and version, and is described in Setting Merge Module Details on
page 331.
After you create the merge module, you can add it to a standard installation. See Adding
a Merge Module to an Installation on page 345.
Creating a Merge Module From Existing Components

You can create a merge module by moving components from a feature in an existing
installation file or merge module into a new merge module.
Note
All the components you plan to move to the new merge module must be in the same
feature. If they are not, create a feature temporarily and add the components to it in
Setup Editor > Features tab.
1. Open the installation file or merge module to move components from.
2. Select Tools menu > Move Components to Merge Module. (In Visual Studio: Project
menu > Move Components to Merge Module.)
You can also select Setup Editor > Features tab (in an installation) or Setup Editor >
Modules tab (in a merge module), right-click the feature containing the components
to move, and select Move Components to Merge Module.
The Merge Module Information dialog appears.

Merge Module Path

Specify a full pathname for the new merge module.
Module Name
Enter a name that Windows Installer and Wise for Windows Installer can use
internally to identify the merge module.
Version
Enter the version of the module. Windows Installer and Wise for Windows
Installer use this number to check versions of dependency and exclusion merge
modules. You can use the format xxxxx.xxxxx.xxxxx.xxxxx, where x is a digit.
See Version in the Windows Installer SDK Help.
Language
Enter the language code for the merge module. English is 1033. Language
neutral (meaning the merge module works with all languages) is 0. See
Language IDs on page 279.
4. Click Next.
The Merge Module Components dialog appears.
5. From Export from Feature, select the feature that contains the components to
move.
If you are moving components from a merge module, there are no features.
6. Mark the checkboxes of the components to move into the new merge module.
7. Click Finish.
The components you select are removed from this installation, compiled into the new
merge module, and re-inserted in the form of a merge module. The new merge module
is also available to other installations.
Also see:
Setting Merge Module Details on page 331

Setting Dependencies for a Merge Module on page 332
Setting Exclusions for a Merge Module on page 333
Creating a Configurable Merge Module

To create a configurable merge module, you add configuration items to a standard
merge module. On the Substitutions page, you specify the:
z Substitution item, which is the field that can be configured.
z Configuration item, which determines how a field can be configured.
This creates a substitution value, which consists of one or more values specified by
configuration items. When a configurable merge module is added to an installation, the

installation author can specify values for the substitution item based on the
configuration item settings. See Adding a Merge Module to an Installation on page 345.
Configurable merge modules are supported only by Windows Installer 2.0 or later.
For information on creating a standard merge module, see Creating a Merge Module As a
New Installation on page 334. (In Visual Studio: also see Creating a Merge Module
Within a Solution on page 336.)
To add a configuration item to a merge module:

1. Select Installation Expert > Substitutions page.
If there is no Substitutions page, you are not in a merge module file.
The Module Substitution dialog appears.
3. From Table, select the table that contains the item to be configured when the
merge module is added to an installation.
4. In the table, click a table cell to select the substitution item.
5. Click Add and select from the button menu:
Configurable Item
Select to add a configuration item to the selected substitution item. See Setting
Configuration Item Details on page 339.
Constant
Select to add a constant value in combination with configurable items. Example:
After adding a configuration item, select this option to add a pipe character (|)
before adding another configuration item.
6. Click OK.
The value you defined for the configurable item appears in the Value field, and the
item appears in the Configuration Items list box.
7. To add more values for the item, repeat the preceding 2 steps.
If you add multiple values, multiple rows appear in the list box and the values are
concatenated to create the entire substitution value. See Example: Configuring an
Item for a Merge Module on page 343.
8. Click OK.
The new configuration item is listed on the Substitutions page.
Also see:
Specifying Drop-Down List Values for Substitution on page 341

Specifying a Bitfield for Substitution on page 342
Specifying a Key for Substitution on page 343
Setting Configuration Item Details

1. Access the Configuration Item Details dialog from the Module Substitution dialog.
See Creating a Configurable Merge Module on page 338.

Name
Enter a name to represent the item in the Configuration Items list box on the
Module Substitution dialog.
Display Name
Enter the name that should appear on the Merge Module Configuration dialog
when the merge module is added to an installation.
Description
Describe what can be modified.
Type
Select the type of configurable data that is appropriate for the item you allow to
be substituted.
Arbitrary Text
The installation author can enter any text to replace the default value.
Example: Use this when you allow a file name to be modified. See Example:
Configuring an Item for a Merge Module on page 343.
Formatted Text
The installation author can enter any text in Windows Installer formatted
text format to replace the default value. Example: Use this when you allow a
registry value to be modified.
RTF Text
The installation author can enter any text in rich text format to replace the
default value. Example: Use this when you allow a different license
agreement to be selected.
Text Drop-down List

The installation author can select from a drop-down list to replace the
default value. This list displays only the name you gave the value, not the
actual value. This is useful when the values are not self-explanatory.
(Example: Use this option to make a property configurable. Possible choices
for the installation author could be to let all end users or only selected end
users install this particular file.) For information on completing the additional
fields that display when this option is selected, see Specifying Drop-Down
List Values for Substitution on page 341.
Windows Installer Identifier

The installation author can enter text in the format of a Windows Installer
identifier to replace the default value. This text can contain ASCII
characters, digits, underscores, or periods, and must begin with either a
letter or an underscore. Example: Use this to allow a key to be changed or
entered into any table.
For information on the format types like the ones listed above, see Text Format
Types in the Windows Installer SDK Help.
Bitfield (Drop-down List)

The installation author can select from a drop-down list to replace the
default value. This list displays only the name you gave the value, not the
actual value. This is useful when you provide values that are not self-
explanatory. Use the bitfield type only on columns that are bit flags.
(Example: In the Files table, the Attribute column contains bit flags
representing the file attributes. Therefore, you can use the bitfield type to
make a file’s attributes configurable. Possible choices for the installation

author could be for the file to be read-only; read-only and hidden; or read-
only, hidden, and vital.) For information on completing the additional fields
that display when this option is selected, see Specifying a Bitfield for
Substitution on page 342 and Bitfield Format Types in the Windows Installer
SDK Help.
Integer
The installation author can enter any integer to replace the default value.
Example: Use this to make the size of a control or a dialog configurable. See
Integer Format Types in the Windows Installer SDK Help.
Key Into a Table

The installation author can select a key into a table from a drop-down list to
replace the default value. (Example: Use this to let the installation author
change the directory for a component when adding a merge module to an
installation.) For information on completing the additional fields that display
when this option is selected, see Specifying a Key for Substitution on
page 343 and Key Format Types in the Windows Installer SDK Help.
Non-nullable
Mark this if a value is required for this configuration item.
Default Value
Enter the value that should appear on the Merge Module dialog when the
configurable merge module is added to an installation. This is the value that can
be changed.
3. Click OK.
Specifying Drop-Down List Values for Substitution

When you add a configuration item to a configurable merge module as a text drop-down
list, you must specify values and the text that describes them. When adding the merge
module to an installation, the installation author selects from a list that displays the
descriptive text. See Text Format Types in the Windows Installer SDK Help.
2. Complete the Configuration Item Details dialog. See Setting Configuration Item
Details on page 339.
3. From Type, select Text Drop-down List.
4. Click Add.
The Drop-down List Value dialog appears.
Name
Enter text to describe the substitution value. The installation author sees this
value in the Value drop-down list on the Merge Module Configuration dialog.
Value
Enter the value to be substituted for the current value of the configuration item.
6. Click OK.

The Configuration Item Details dialog lists the text and value you defined.
7. Repeat the preceding 3 steps to add additional values.
8. Click OK.
The values you defined for the configurable item appear in the Value field, and the
items appear in the Configuration Items list box.
9. Click OK.
Specifying a Bitfield for Substitution

When you add a configuration item to a configurable merge module as a bitfield drop-
down list, you must specify values and the text that describes them. When adding the
merge module to an installation, the installation author selects from a list that shows the
descriptive text. See Bitfield Format Types in the Windows Installer SDK Help.
3. From Type, select Bitfield (Drop-down List).
4. In Bitmask, enter the decimal value of the bit flag to set. To set multiple bit flags,
enter the sum of their decimal values.
Example: Suppose you want to let the installation author set the attributes of a file
to system and vital. The decimal value of the system attribute is 4. The decimal
value of the vital attribute is 512. You would add these values and enter a bitmask
of 516.
5. Click Add.
The Drop-down List Value dialog appears.
Name
Enter text to describe the substitution value. The installation author sees this
value in the Value drop-down list on the Merge Module Configuration dialog.
Value
Enter the value to be substituted for the current value of the configuration item.
7. Click OK.
The Configuration Item Details dialog lists the text and value you defined.
8. Repeat the preceding 3 steps to add additional values.
9. Click OK.
items appear in the Configuration Items list box.
10. Click OK.

Specifying a Key for Substitution

When you add a configuration item to a configurable merge module as a key into a
table, you must specify a table for the key to make configurable. When adding the
merge module to an installation, the installation author selects from a list that appears.
For information on this format type, see Key Format Types in the Windows Installer SDK
Help.
3. From Type, select Key Into a Table.
4. Mark Delete Unreferenced Rows to have the row that is referenced by the default
value merged if the installation author selects the default value when adding the
merge module to an installation.
Example: Suppose the merge module includes a dialog with a graphic. You select
Binary (Bitmap) from Key Table and set the Default Value to the bitmap in the
merge module. If the installation author selects a different bitmap when adding the
merge module to an installation, then the default bitmap is no longer referenced. If
Delete Unreferenced Rows is marked, the default bitmap is not merged into the
installation.
5. From Key Table, select the type of table to make available for selection for this key.
6. Click OK.
items appear in the Configuration Item list box.
7. Click OK.
Example: Configuring an Item for a Merge Module

Suppose your merge module includes a file named ReleaseNotes. Here is how you can
let installation authors select a long or a short file name when they merge the module
into an installation.
1. Select Installation Expert > Substitutions page.
3. From Table, select File.
4. In the FileName column, click the cell that contains the ReleaseNotes file name. It
should look something like this:
RELEAS~1.TXT|ReleaseNotes.txt
5. Click Add and select Configurable Item.

The Configuration Item Details dialog appears.
Name
Enter “short name.”
Display Name
Enter “Short file name.”
Description
Enter “Choose whether to use a short or a long file name for this file.”
Type
Select Arbitrary Text.
Default Value
Enter “RELEAS~1.TXT.”
7. Click OK.
On the Module Substitution dialog, your configuration item appears as short_name

in the Configuration Items list box.
8. Click Add and select Constant.
The Substitution Constant dialog appears.
9. In Constant Substitution Value, enter the pipe character (|) and click OK.
On the Module Substitution dialog, the pipe character (|) appears in the
Configuration Items list box, below short_name.
10. Click Add and select Configurable Item.
The Configuration Item Details dialog appears.
Name
Enter “long name.”
Display Name
Enter “Long file name.”
Description
Enter “Choose whether to use a short or a long file name for this file.”
Type
Select Arbitrary Text.
Default Value
Enter “ReleaseNotes.txt.”
12. Click OK.
On the Module Substitution dialog, long_name appears in the Configuration Items

list box, below the pipe character. Value shows the substitution options for the file
name: [=short_name]|[=long_name].
13. When you add this merge module to an installation, the configuration items will
appear in the order they are listed here. To rearrange the items click move up and
move down.
When you add this configurable merge module to an installation, the Merge Module
Configuration dialog displays the following:

z In the list box at the top: Short file name and Long file name.
z Description: Choose whether to use a short or a long file name for this file.
z Text Value: either RELEAS~1.TXT or ReleaseNotes.txt, depending on the selection in

the list box. This value can be modified.
Also see Creating a Configurable Merge Module on page 338.
About the Merge Modules Page

The Merge Modules page lets you add merge modules to an installation, edit settings for
merge modules that you’ve already added, and remove merge modules from an
installation.
See:
Adding a Merge Module to an Installation.

Editing Merge Module Details on page 347.
About Merge Modules on page 329.
Adding a Merge Module to an Installation

Use the Merge Modules page to add merge modules to an installation. By default, merge
modules are not installed with Wise for Windows Installer. However, you can create
merge modules or use the Download Redistributables wizard to obtain third-party merge
modules. See Downloading Redistributable Files on page 35.
When deploying software via a merge module, keep update considerations in mind.
Example: If you deploy MSDE via a merge module, end users cannot use Microsoft’s
MSDE security patches to update that installation of MSDE. Microsoft patches only
operate on software packages installed by Microsoft .MSIs. You would have to
incorporate the MSDE patch changes in an update to your own application and distribute
it to your end users. This could cause security and timing issues for your end users.
To add a merge module:

1. Select Installation Expert > Merge Modules page.
is selected.)
3. Click Add at the right of the Merge Modules page.
The Select Merge Module dialog appears and lists available merge modules in the
directories specified in Wise Options. See Setting Merge Module Directories on
page 48.
In the Enterprise Edition, the Select Merge Module dialog can also include merge
modules that are in the Software Manager database. You must have access to the
Software Manager database and the Read Merge Modules List From Software
Manager Database checkbox must be marked in Wise Options.

4. If the merge module you want is not in the list, do one of the following:
To add directories to search for merge modules, click Directories and the Merge
Modules tab from Wise Options appears. Click Add to add the directory that
contains the merge module. See Setting Merge Module Directories on page 48.
The merge modules in this directory are added to the list of available merge
modules.
Click Download to add merge modules from the Wise Web site, other vendors’
Web sites, or from the product CD. See Downloading Redistributable Files on
page 35. If you download the merge modules to a directory that is specified in
Wise Options, they are added to the list of available merge modules.
5. Select one or more merge modules from the list by marking the corresponding
checkboxes.
6. Click Next.
The Merge Module File Directory dialog appears.
7. To change the destination for a merge module, select one or more merge modules
and click Change.
The Select Merge Module Destination Directory dialog appears.
8. Select a directory and click OK.
Select the destination directory for files in the merge module that are not installed
to a predefined directory. If there are no files in the merge module’s Application
directory and you want to leave this blank, select <none>.
9. If the installation contains only one feature and the merge module is not
configurable, the Merge Module File Directory dialog contains a Finish button. Click
Finish to complete this process.
10. If the installation contains multiple features, the Merge Module File Directory dialog
contains a Next button. Click Next to continue.
The Merge Module Features dialog appears.
11. To add this merge module to other features besides the one you selected in the
Current Feature drop-down list, select them in the list box. You can select multiple
features.
If multiple features in the installation depend on this merge module, you should add
it to all of them. Only one copy of the merge module is installed on the destination
computer regardless of how many features include it.
12. If none of the merge modules you’re adding is configurable, the Merge Module
Features dialog contains a Finish button. Click Finish to complete the process.
13. If any of the merge modules you’re adding is configurable, the Merge Module
Features dialog contains a Next button. Click Next to continue. The Merge Module
Configuration dialog appears.
14. In the list box, select the name of the item to configure. If the Value drop-down list
appears, select a value. If a text field appears, its label indicates the type of data
you can enter. For a description of possible values, see Editing Merge Module Details
on page 347.
15. If you’re adding more than one configurable merge module, a Next button appears
at the bottom of the dialog. Click Next and repeat the preceding step.

The Next button changes to a Finish button when the Merge Module Configuration
dialog shows the last configurable merge module to be added.
16. Click Finish.
The merge modules are added to this installation. If any of the merge modules contain
dependencies, Wise for Windows Installer attempts to add them by looking in the default
merge module directory. See Setting Dependencies for a Merge Module on page 332. If
a dependency merge module cannot be found, you are prompted to download it. During
compile, the merge modules are merged into the installation, so that the resulting .MSI
contains both the changes defined in the standard installation as well as the changes
defined in the merge modules. If your compile fails because of merge module errors, the
errors appear in the Task List.
To remove a merge module from an installation, select the merge module on the Merge
Modules page and click Delete. If the module is included with more than one feature, it
is only removed from the installation when you remove it from all features.
Also see About the Merge Modules Page on page 345.
Editing Merge Module Details

1. Select Installation Expert > Merge Modules page.
2. From Current Feature, select the feature or condition that contains the merge
module to edit.
3. Double-click a merge module.
The Merge Module Details dialog appears. It has 1 tab if you’ve double-clicked a
standard merge module and 2 tabs for a configurable merge module.
4. Click the Settings tab and change the dialog’s settings as needed:
Module Source Path

To get the same merge module (with the same GUID) from a different location,
enter a full pathname to the merge module.
Select the destination directory for files in the merge module that are not
installed to a predefined directory. If there are no files in the merge module’s
Application directory and you want to leave this blank, select <none>.
Feature
If the installation contains multiple features, a list of features appears. To add
this merge module to other features, mark their checkboxes.
If multiple features in the installation depend on this merge module, you should
add it to all of them. Only one copy of the merge module is installed on the
destination computer regardless of how many features include it.
5. If the merge module is configurable, the Merge Module Details dialog has a
Configuration tab. To change configuration values:
Click the configuration tab.
In the list box, select the name of the item to configure.
If the Value drop-down list appears, select a value. It will be either a bitfield
value, a table, or text. If a text field appears its label indicates the type of data
you can enter:

Text Value
Enter any text.
Formatted Text Value

Enter any text in Windows Installer formatted text format.
RTF Value
Enter any text in rich text format.
Windows Installer Identifier Value

Enter text in the format of a Windows Installer identifier, which may contain
ASCII characters, digits, underscores, or periods, and must begin with either
a letter or an underscore.
For information on the format types listed above, see Text Format Types in the
Integer Value
Enter any integer. See Integer Format Types in the Windows Installer SDK
Help.
For general information on configurable item types, see Semantic Types in the Windows
Installer SDK Help or see Creating a Configurable Merge Module on page 338.
Note
During compile, if the installation contains a merge module that cannot be located on
your system, you are prompted to download the merge module. This can happen if the
installation was created on a different computer or if you have moved your merge
modules directory.
Also see Adding a Merge Module to an Installation on page 345.
About Transforms
A transform is a special kind of Windows Installer file (.MST) that customizes a Windows
Installer installation. You use it to change the installation in some way for a specific
group of end users. When you create a new transform, you must specify a standard
installation database (.MSI) on which to base the transform. Unlike merge modules,
which you can add to multiple installations, you create a transform to work only with a
specific installation.
Because it would be unwieldy to install all options for all groups of end users, you can
create one base .MSI, along with several transforms, each of which modifies the .MSI
database at installation to customize it for different groups.
Example: Suppose you are a system administrator who’s deploying a new version of
workgroup software. You can use transforms to customize the installation for the needs
of different departments. In each transform, you make changes to customize an
installation for a particular department. Then during installation, you make sure that the
appropriate transform is applied for each department.
To create a transform, see:
z Creating a Transform Based on an Existing .MSI. This lets you change any aspect of
the installation.
z Creating a Language Transform on page 260. This lets you change the language on
the dialogs that appear during installation.

Transforms must be run from the command line. See Applying a Transform to an
Note
The Languages pages is disabled for transforms. Edit languages in the base .MSI.
Also see:
Transforms in the Windows Installer SDK Help

Setting Transform Details on page 350
Creating a Transform Based on an Existing .MSI

You can select a standard installation file, and a temporary copy of that installation file
opens in Wise for Windows Installer, where you define changes for the transform. This is
the most flexible way of creating a transform, because you can change any aspect of the
installation.
Example: Suppose you want a transform that changes the application name, changes
what registry entries are installed, and changes what system requirements are
necessary to run the installation. Because these changes affect multiple areas of the
product, you use this method to create the transform.
1. (Visual Studio only.) If a solution is open in Visual Studio .NET, close it.
2. Select File menu > New. The New Installation File dialog appears. (In Visual Studio:
select File menu > New > File. The New File dialog appears.)
From the Categories list, select Other Templates. (In Visual Studio: select
Wise Files.)
In the Templates/Tools list, select the Transform icon, then click OK. (In
Visual Studio: in the Templates list, select Transform File, then click Open.)
The Open File dialog appears.
3. Specify the .MSI on which this transform should be based.
The transform opens with the exact settings of the installation on which it is based.
4. Make changes to the installation, such as adding files, or changing any other
settings.
Note
If you add files when editing a transform, a .CAB file is created along with the
transform. When you apply the transform, make sure the .CAB file, the original
.MSI, and the .MST are all in the same directory.
5. When you finish making changes, select File menu > Save.
The Save As dialog appears. (In Visual Studio: the Save File As dialog appears.)
6. Type a name for the transform and click Save.
The Transform Details dialog appears.
7. Complete the Transform Details dialog as described in Setting Transform Details on

page 350, and click OK.

The transform appears in the location you specified, with an .MST extension. For
information on applying a transform, see Applying a Transform to an Installation on
page 351.
Setting Transform Details

The Transform Details dialog, which you see when saving a transform file, contains
options that flag error conditions of a transform. You set the error conditions to ignore.
It also contains validation options. Normally, if the error conditions exist, errors are
generated when the transform is applied to the standard installation.
In most cases, if you create the transform using Wise for Windows Installer, you can
leave the defaults on the Transform Details dialog. See
MsiCreateTransformSummaryInfo in the Windows Installer SDK Help.
z Base database
This is the .MSI on which this transform is based. Do not change this. If this
transform is applied to a database other than the one specified here, an error is
generated during installation.
z Suppress Transform Application Errors

The following checkboxes let you suppress certain errors if the transform attempts
to perform certain operations on the base database. In most cases, you can leave
the default settings in this section.
Add existing row

Suppress errors from occurring if the transform attempts to add a row that
already exists in the base .MSI.
Delete missing row

Suppress errors from occurring if the transform attempts to remove a row that
doesn’t exist in the base .MSI.
Add existing table

Suppress errors from occurring if the transform attempts to add a table that
already exists in the base .MSI. This is marked by default when you create a
transform.
Delete missing table

Suppress errors from occurring if the transform attempts to delete a table that
doesn’t exist in the base .MSI. This is marked by default when you create a
transform.
Update missing row

Suppress errors from occurring if the transform attempts to update a row that
doesn’t exist in the base .MSI.
Code page mismatch

Suppress errors from occurring if the code page (language) setting of the
transform does not match that of the base .MSI.
z Validation
The following checkboxes and fields let you require certain conditions to be true for
the transform to be applied to the base .MSI.
Match Language
Mark this if the language of the transform must match the language of the base
.MSI.

Match Product
Mark this if the product code of the transform must match the product code of
the base .MSI.
Match Upgrade Code

Mark this if the upgrade code of the transform must match the upgrade code of
the base .MSI.
Version Matching
The version of the installation (set on the Product Details page) is in the form
AA.BB.CCCC.DDDD, where AA represents the major version, BB represents the
minor version, CCCC represents the update version, and DDDD represents the
build version. Select an item in the list to have the version of the transform
checked against the version of the base .MSI. If the versions do not match, an
error is generated during installation.
Version Relationship
If you chose to check versions, specify what version relationship must be true in
order not to generate an error.
Applying a Transform to an Installation

A transform must be applied to a base .MSI during installation using a command line
option; it cannot be applied beforehand.
On the command line, type the following:
msiexec /i Application.msi TRANSFORMS=TransformName.mst
where Application.msi is the name of the .MSI, and TransformName.mst is the name of
the transform.
Because it is not practical to have end users type a line on the command line to run a
transform, we suggest you use one the following methods to run the transform:
z Write a batch file that runs the .MSI along with the appropriate transform.
z Output the installation as an .EXE that launches an .MSI, which lets you send
command line options to the .MSI. Do this on the Build Options page. See the
example below.
Example: Applying a Transform with an .EXE

In this example, you output the installation as an .EXE that launches an .MSI and applies
the transform.
1. Select Installation Expert > Releases page.
2. Create a new release. See Creating a New Release on page 179.
3. Select the Build Options page, select the new release from the Current Release
drop-down list, and select .EXE that launches external .MSI from the .EXE
Options drop-down list.
4. Compile the installation, which creates an .EXE, an .MSI, and an .INI file.
5. Open the .INI file, and add the following line:
CmdLine=TRANSFORMS="TransformName.mst" /i
where TransformName.mst is the name of the transform.

When you double-click the .EXE file, it reads the .INI file of the same name. (Example:
Application.EXE reads Application.INI.) When it runs the installation, it applies the
command line option specified in the CmdLine property and the transform is applied.
These command line options are passed to msiexec.exe, the Windows Installer
executable.
If you have multiple transforms, you can make multiple releases, and manually edit the
.INI file for each release.
Multiple Instance Installations

Note
Multiple instance installations are supported only by the versions of Windows Installer
released with Windows XP SP1 (2.0.2600.1106), Windows Server 2003 (2.0.3790.0), or
later.
Windows Installer permits one instance of a product code to be installed per machine
and one instance to be installed per user. To install multiple instances of a product
without creating a separate installation for each instance, you can create instance
transforms to change the product code for each instance. An instance transform changes
the product code of an installation or patch and can isolate its data so that multiple
instances of the application can be installed.
Example: A Web server administrator can install multiple instances of a web site
template on the same server to different virtual directories.
Guidelines
z Code the application so that it can locate resources based on the instance identifier.
To create the instance identifier, you define an instance property in the base
installation and have the instance transform set the property value.
z Create a base installation. For each instance to be installed, create an instance

transform. The base installation may install its own instance.
z Each instance must have a unique product code and an instance identifier.
z To isolate resources for each instance, install them into a location that depends on
the instance identifier.
For additional guidelines, see Authoring Multiple Instances with Instance Transforms in
Creating an instance transform:

1. Open the base installation or patch for which you are creating an instance
transform.
2. Select Installation Expert > Instance Transforms page.
3. In Instance Property, enter a property that will be replaced by a unique value in

this instance of the installation.
4. Product Name is pre-filled with the product name from the Product Details page. If
you change it here, it is changed on the Product Details page.

The Instance Transform Details dialog appears.
Instance Property Value

The base product name is incremented by 1 for each new instance transform.
You can change this but the value must be unique. This value will replace the
instance property and serve as the instance identifier.
Product Code
Wise for Windows Installer generates a product code in the form of a GUID,
which ensures that no 2 applications ever have the same product code. To
change the product code, click Generate; typing or editing a GUID does not
generate a valid GUID.
Product Name
You can change this but the name must be unique. The end user sees this name
during installation and in the Add/Remove Programs dialog.
File Name
You can change this but the name must be unique. This becomes the name of
the transforms that is created. The transform is saved in the same directory as
the base installation file.
Change install directory to Instance Property Value?

Mark this to change the value of the directory property INSTALLDIR to the value
in the Instance Property Value field above. INSTALLDIR is the main
installation directory for the application (example: Program Files\Application).
This helps you isolate files for each instance.
Example: Suppose you want to install test, beta, evaluation, and production
versions of your application on the same destination computer. To do this, code
your application to look for these instances. Add files to the installation. On the
Instance Transforms page, add instances for each version of your application
and define an instance property value for each (examples: 1, 2, 3, 4). Mark the
Change install directory to Instance Property Value checkbox for each
instance. When each instance transform is applied to the installation, files are
installed into INSTALLDIR, but the value of INSTALLDIR changes based on the
instance property value. (Examples: Program Files\Application1, Program
Files\Application2, and so on.) If you did not mark the Change install
directory to Instance Property Value checkbox, then files for each instance
would be installed on top of each other in the same directory as for the base
installation.
7. Click OK.
The instance transform is added to the list on the Instance Transforms page. To edit an
instance transform, double-click its name. The actual transform files (.MST) are created
during compile.
Also see Installing Multiple Instances on page 353.
Installing Multiple Instances


Note
Multiple instance installations are supported only by the versions of Windows Installer
released with Windows XP SP1 (2.0.2600.1106), Windows Server 2003 (2.0.3790.0), or
later.
Like other types of transforms, an instance transform must be applied to a base .MSI or
patch during installation using a command line option; it cannot be applied beforehand.
On the command line, type the following:
msiexec /i Application.msi TRANSFORMS=Instance.mst MSINEWINSTANCE=1 /qb
where Application.msi is the name of the .MSI, and Instance.mst is the name of the
transform.
For additional examples, see Installing Multiple Instances with Instance Transforms in
Also see Multiple Instance Installations on page 352.

Chapter 16
Tools
Wise for Windows Installer contains powerful tools that perform specialized functions.
You can start a tool, except for Setup Capture, by selecting its name from the Tools
menu. (In Visual Studio: Project menu.) Some tools are also available on the Tools
toolbar. To display the Tools toolbar, select View menu > Tools. (In Visual Studio: View
menu > Toolbars > Wise Wizards.)
You also can start some tools from the New Installation File dialog, which puts the
results from the tool into a new installation file. (In Visual Studio: New Project or New
File dialog.)
Wise for Windows Installer Tools

z ApplicationWatch on page 356.
z Convert InstallShield Professional on page 357.
z Convert SMS Installer or WiseScript Installation on page 358.
z Convert Source Paths. See Source Paths in an Installation on page 324.
z Import Visual Studio Projects on page 360.
z Move Components to Merge Module. See Creating a Merge Module From Existing
Components on page 337.
z MSI to WSI Conversion on page 364.
z Package Distribution. Copy a compiled installation to an FTP server, to a local area

network, or to removable media. You can also perform an administrative installation
to a shared network directory. In the Enterprise Edition, you also can distribute an
installation to the share point directory. See Package Distribution on page 282.
z Package Validation. See Package Validation on page 369.
z Patch Creation. See Creating a Patch File on page 304.
z Software Manager, which provides the interface for working with packages in the
Software Manager database. See Software Manager Basics in the Software Manager
Help. (Enterprise Edition only.)
z UpgradeSync on page 300.
z Visual MSIDiff™. See Comparing Windows Installer Files on page 85.
z WiseScript Express™, which lets you lets you write scripts that solve complex
problems outside the Windows Installer environment. Save the scripts as separate
.EXEs to be called from Call WiseScript custom actions in a Windows Installer
installation. See WiseScript Editing Tools on page 473.
z Wise Task Manager on page 379.

Tools
Note
SetupCapture has been replaced by the expanded tools for converting and importing
non-Windows Installer projects that are listed above. These tools provide more accurate
installations than could be obtained by capturing the installations.
ApplicationWatch
ApplicationWatch monitors your system as you execute an application or run an
installation and helps you determine which .DLL, .OCX, and .EXE files were accessed. It
adds these files to the current Windows Installer installation. You can use this tool for
informational purposes or to facilitate the creation of a new installation.
Note
Application Watch cannot monitor 16-bit applications.
1. Exit all other applications so the files they access are not added to the installation.
2. Select Tools menu > ApplicationWatch. (In Visual Studio: Project menu >
Application Watch.)
The Run Application dialog appears.
Application Path
Specify the full pathname of the application executable to run.
Command Options
Enter any command line options that should be applied to the executable. Refer
to the source application’s documentation for applicable command line options.
4. Click Execute, which launches the source application.
5. In the source application, use all possible features except printing. If you are
watching an installation, run the installation through to completion.
As you use various features of the application, ApplicationWatch monitors your

system to see which .DLL, .OCX, and .EXE files are accessed. Use as many of the
application’s features as possible to ensure that files used by rarely-used features
are recorded. Do not use the application to print, because printing accesses
Windows operating system and printer-specific files.
6. Exit the application, return to the Run Application dialog, and click Finish.
Adding Merge Modules Instead of Files on page 120.
The files that were accessed by the source application are added to the Files page. If you
use this information as a starting point for developing a complete installation, you
should compile and test the installation thoroughly to make sure it operates correctly.

Tools
Caution
Some of the files that are listed on the Files page might be platform-specific or non-
distributable Windows system files. If you are not sure whether it is safe to deploy a file,
check with Microsoft developer documentation before deploying these files to end users.
Convert InstallShield Professional

You can use the Convert InstallShield® Professional tool to convert an installation script
project (.IPR) that was created in version 5.5 or later of InstallShield Professional to a
Windows Installer package.
Guidelines
z Because InstallShield Professional installations are based on a different technology
than Windows Installer, not all elements of the source installation are converted to
Windows Installer format:
The installation is built from the configuration files defined by the .IPR. Files,
registry keys, and shortcuts are converted. The Product Name, Product Version,
and Company Name properties are also converted. File source paths are
retained.
The .RUL file, which controls how the resources are installed, cannot be
converted. Add custom actions to the new package to replace any custom logic
that was previously stored in the .RUL file.
Only InstallShield projects that use English in their dialogs can be converted.
z All the files available to the original InstallShield installation must be available to the
converted Windows Installer package at the same locations.
z Resources are organized into features based on groups in the resource lists. To
retain the organization in the InstallShield project, components are organized into
separate features, with FileGroups as child features.
To convert an InstallShield Professional installation:

Select File menu > New. On the New Installation File dialog, select Conversion
Tools from the Categories list and double-click InstallShield Professional in the
Templates/Tools list. (In Visual Studio: Select File menu > New > File. On the
New File dialog, select Wise Files from the Categories list and double-click
Convert InstallShield Professional in the Templates list.) Use this method to
create an installation that contains only the information from the converted
installation.
Select Tools menu > Convert InstallShield® Professional. (In Visual Studio:
Project menu > Convert InstallShield® Professional.) Use this method to add
the converted installation’s information to the current installation file.
2. On the Welcome dialog, specify the full pathname of the project file (.IPR) to
convert.
3. Click Next to start the conversion.

Tools
The Conversion Progress dialog appears. The .IPR file is converted to Windows
Installer format.
When the conversion is finished, the Conversion Complete dialog appears. It

displays the results of the conversion and lists any errors or problems that might
have occurred. (Example: If files referenced by the source installation could not be
found, an error is displayed.) You can fix these problems in Installation Expert and
Setup Editor.
4. To obtain a record of the conversion errors, click Save Errors or Print Errors.
5. Click Finish.
More errors might appear at this point, which have to do with saving in Windows
Installer format.
The installation that was created from the .IPR file opens. Pages in Installation
Expert (example: Files page) are populated based on the contents of the source
installation.
Convert SMS Installer or WiseScript Installation

With this tool, you can convert the following types of installation scripts:
z An .IPF file created in Microsoft’s System Management Server (SMS).
z A .WSE file created in version 5.0 and later of Wise Installation System.
z A .WSE file created in WiseScript Editor.
z An .EXE file created by one of the applications above. Do this when you do not have
the original installation file. The compiled .EXE file contains an embedded copy of
the installation script.
Use the following guidelines to identify and fix conversion problems:
z Because WiseScripts and SMS Installer scripts are based on a non-Windows Installer
technology, not all elements of the script are converted to Windows Installer format:
Only the installation of files, registry changes, and other system changes are
converted.
Custom dialogs, custom logic, and other settings are not converted.
z All the files available to the original SMS installation must be available to the
converted Windows Installer package at the same locations.
z Components are converted to features, and Execute Program script actions are
converted to Execute Program custom actions.
z Some script actions can cause problems with the conversion process.

Tools
To convert an SMS Installer script or WiseScript:

1. Before converting a script, open it and delete all Display Billboard, Display Graphic,
and Add Icon script actions from the script.
Select File menu > New. On the New Installation File dialog, select Conversion
Tools from the Categories list and double-click the SMS Installer or WiseScript
Installation icon in the Templates/Tools list. (In Visual Studio: Select File
menu > New > File. On the New Files dialog, select Wise Files from the
Categories list and double-click Convert SMS Installer or WiseScript
Installation in the Templates list.) Use this method to create an installation
that contains only the information from the converted installation.
Select Tools menu > Convert SMS Installer or WiseScript Installation. (In Visual
Studio: Project menu > Convert SMS Installer or WiseScript Installation.) Use
this method to add the converted installation’s information to the current
installation file.
Installation Script
Specify a .WSE, .EXE, or .IPF file to convert.
You cannot convert .EXE files that were not generated by the Wise Installation
System or SMS.
Extract Directory
If you are converting an .EXE file, specify a temporary directory to hold the files
extracted from the installation.
4. Click Next to start the conversion.
The script is converted to Windows Installer format.
When the conversion is finished, the Conversion Complete dialog appears. It shows
the results of the conversion and lists any errors or problems that might have
occurred. (Example: If files referenced by the original script could not be found, an
error is displayed.) You can fix these problems in Wise for Windows Installer.
5. To obtain a record of the conversion errors, click Save Errors or Print Errors.
6. Click Finish.
More errors might appear at this point, which have to do with saving in Windows
Installer format.
appears. It prompts you to add the merge module and, if necessary, download it.
See Adding Merge Modules Instead of Files on page 120.
If a file that is used by a package in the Wise Software Repository is added, the Files
in Repository dialog appears and prompts you to add a version of the file that is in
the repository. See Adding Files From the Wise Software Repository on page 121.
The original script is now integrated into a new or current installation.
7. View results from the conversion on pages in Installation Expert.

Tools
Pages in Installation Expert (example: Files page) are populated based on the
contents of the source installation. If you converted an .IPF or .WSE, files are
referenced from their original locations. If you converted an .EXE, files are stored in
and referenced from the directory you specified in Extract Directory above.
Import Visual Studio Projects

Visual Studio Projects in the Wise Editor
The Import Visual Basic, Visual C#, or Visual J# tools let you import a Visual Basic, C#,
or J# project file into an installation file. You specify information about the project, and
the tool extracts information, such as source file paths, and integrates it into a new or
existing installation. For instructions on running these tools, see Importing an
Installation From a Visual Studio Project on page 361.
z These tools only support projects of these types:

Microsoft Visual Basic 5
Microsoft Visual Basic 6
Microsoft Visual Basic .NET
Microsoft C#
Microsoft J#.
z These types of files are supported: .VBP, .VBPROJ, .CSPROJ, .VJSPROJ, or .SLN.
z When you import a solution, any project types other than those listed above are
skipped. If your VB, C#, or J# projects depend on files that are in projects that are
skipped, the installation might not work.
z For Visual Basic projects, the Visual Basic Import tool only supports file types of the
Standard EXE project type.
z For Visual Basic .NET, C#, or J# projects, if a project file has dependencies on other
projects, you cannot import just the project file. You must import the entire solution
that contains the project and its dependencies.
z There is no link between a project or solution and the installation you create for the
project or solution. If your solution or project is updated with new files, you must
make those changes in the installation manually. Use the Visual Studio integrated
editor to link a development project directly to an installation project.
z These tools are not designed to set up a remote automation or a DCOM™ server
automatically.
Visual Basic Projects in the Visual Studio integrated editor

The Import Visual Basic tool lets you import a Visual Basic 5 or 6 project file into an
installation file. You specify information about the project, and the tool extracts
information, such as source file paths, and integrates it into a new or existing
installation. For instructions on running this tool, see Importing an Installation From a
Visual Basic Project on page 363.
z This tool only supports projects of file type .VBP. Only the Standard EXE project type
is supported.
z There is no link between a VB 5 or 6 project or solution and the installation you

create for the project or solution. If your solution or project is updated with new
files, you must make those changes in the installation manually.

Tools
z This tool is not designed to set up a remote automation or a DCOM™ server

automatically.
z You can only use the Import Visual Basic 5/6 Project tool on a stand-alone
installation project. See Creating a Stand-alone Installation on page 72 for details.
You cannot use it in a multi-project solution.
Importing an Installation From a Visual Studio Project

Use the following procedure to create a Windows Installer package from a Visual Basic,
Visual C#, or Visual J# project. For general information on these tools, see Import Visual
Studio Projects on page 360.
Select File menu > New. On the New Installation File dialog, select Import Tools
from the Categories list, and in the Templates/Tools list, double-click the
type of project to import. Use this method to create an installation that contains
only the information from the imported installation.
Select Tools menu > Import Tools and select the type of project to import. Use
this method to add the imported installation’s information to the current
installation file.
The Project or Solution File dialog appears.
2. In the Project or Solution File field, specify the path to the project or solution file,
and click Next.
The dialog that appears depends on what kind of file you import.
If you import a Visual Basic .NET, C#, or J# file, the Select Configuration dialog
appears, which shows the configurations stored in the solution or project. These
correspond to build configurations in your Microsoft development environment.
If you import a Visual Basic 5 or 6 file, the Select Visual Basic Directory dialog
appears.
3. If the Select Configuration dialog appears, select the configuration to import. To be

prompted at the end of this wizard to select which assembly dependencies get
added to which feature, clear Automatically add Assembly Dependencies
without prompting. Otherwise dependencies will be added silently.
4. If the Select Visual Basic Directory dialog appears, specify the directory on your
computer where Visual Basic is installed. The Visual Basic installation directory
contains the support files that must be included as part of the installation because
they are needed by the Visual Basic program.
5. Click Next.
The Scanning Project Files dialog appears.
During the scan, you might see an error about the project being out of date or
missing. You can attempt a rebuild of the project from this tool, or open the
development environment yourself and rebuild the project. Another error, Project
<Project Name> contains a reference to the project with GUID..., means that you
selected a project that has a reference to another project. In this case, the import
ends. You must select the solution (.SLN) file that contains both projects.

Tools
Next, the Dependency Files Not Found dialog appears if necessary, which lists
missing dependency (.DEP) files for Win32 target files. Dependency files list
referenced files. This dialog usually does not apply to .NET projects, which use
assembly manifests instead of dependency files, unless the .NET project depends on
a COM .DLL that has a dependency. If the dependency files cannot be read, then the
files they refer to cannot be added to the installation you are creating.
6. If any files in the Dependency Files Not Found dialog are crucial to this installation,
cancel the import process, locate the files, move them to the System or System32
directory, and then restart the import process.
7. Click Next.
The Files Not Found dialog appears if necessary, which lists the target files that were
not found during the scan.
8. If necessary, select a file and click Browse to locate missing files. Files might be
missing if the configuration of the solution that you selected has not been built.
Missing files will cause compile errors in the installation that results from this import
process.
9. Click Next.
The Installation Files dialog appears, which lists the files that were detected. These
are the files that will be added to the installation.
10. To make changes to the files that will be added to the installation, add or remove
files by clicking Add or Delete, and then click Next.
The Application Installation Information dialog appears. The items on this dialog set
fields in the installation.
Name
Enter a name for the installation. This overwrites the Name field on the Product
Details page. If you don’t want to overwrite the current installation name, leave
this blank.
Installation Directory
Enter the default installation directory where files from this import should be
placed. This determines the folder on the Files page of Installation Expert in
which all added files are placed.
12. Click Finish to complete the import.
If you imported a Visual Basic .NET, C#, or J# project and you cleared the
Automatically add Assembly Dependencies without prompting checkbox, the
Assembly Dependencies dialog appears. It prompts you to select which
dependencies to add to the installation. See Adding Assembly Dependencies on
page 119.

Tools
The project is integrated into a Windows Installer installation file, which contains all the
information it needs to install the project. Options are pre-filled on the Files and Product
Details pages. As with any installation, you should compile and test the installation
thoroughly to ensure it operates correctly.
Importing an Installation From a Visual Basic Project

Use the following procedure to convert a Visual Basic project to a Windows Installer
package. For general information on these tools, see Import Visual Studio Projects on
page 360.
Select File menu > New > File and double-click Import Visual Basic. Use this
method to create an installation that contains only the information from the
converted installation.
Select Project menu > Import Visual Basic. This is available only if you have
opened a file and not a project. Use this method to add the imported
installation’s information to the current installation file.
The Project File dialog appears.
2. In VB Project File, specify the path to the project file and click Next.
The Select Visual Basic Directory dialog appears.
3. Specify the directory on your computer where Visual Basic is installed. The Visual
Basic installation directory contains the support files that must be included as part
of the installation because they are needed by the Visual Basic program.
4. Click Next.
The Scanning Project Files dialog appears.
During the scan, you might see an error about the project being out of date or
missing. You can attempt a rebuild of the project from this tool, or open the
development environment yourself and rebuild the project. Another error, Project
<Project Name> contains a reference to the project with GUID..., means that you
selected a project that has a reference to another project. In this case, the import
ends. You must select the solution (.SLN) file that contains both projects.
Next, the Dependency Files Not Found dialog appears if necessary, which lists
missing dependency (.DEP) files for Win32 target files. Dependency files list
referenced files. This dialog usually does not apply to .NET projects, which use
assembly manifests instead of dependency files, unless the .NET project depends on
a COM .DLL that has a dependency. If the dependency files cannot be read, then the
files they refer to cannot be added to the installation you are creating.
5. If any files in the Dependency Files Not Found dialog are crucial to this installation,
cancel the import process, locate the files, move them to the System or System32
directory, and then restart the import process.
6. Click Next.
The Files Not Found dialog appears if necessary, which lists the target files that were
not found during the scan.

Tools
7. If necessary, select a file and click Browse to locate missing files. Files might be
missing if the configuration of the solution that you selected has not been built.
Missing files will cause compile errors in the installation that results from this import
process.
8. Click Next.
The Installation Files dialog appears, which lists the files that were detected. These
are the files that will be added to the installation.
9. To make changes to the files that will be added to the installation, add or remove
files by clicking Add or Delete, and then click Next.
The Application Installation Information dialog appears. The items on this dialog set
fields in the installation.
Name
Enter a name for the installation. This overwrites the Name field on the Product
Details page. If you don’t want to overwrite the current installation name, leave
this blank.
Installation Directory
Enter the default installation directory where files from this import should be
placed. This determines the folder on the Files page of Installation Expert in
which all added files are placed.
11. Click Finish to complete the import.
The project is integrated into a Windows Installer installation file, which contains all the
information it needs to install the project. Options are pre-filled on the Files and Product
Details pages. As with any installation, you should compile and test the installation
thoroughly to ensure it operates correctly.
MSI to WSI Conversion

Use MSI to WSI Conversion to convert existing .MSI files to Windows Installer project
files (.WSI). An .MSI is a distributable installation. Because an .MSI typically
encapsulates all the files in the installation, it is larger and takes longer to save. A
project file (.WSI) compiles to an .MSI. Instead of compressed files, a .WSI contains
paths to source files. A .WSI file is smaller and you can set multiple options for the
output of the .MSI. For information on the differences between project files and
installation database files, see Project Files and Database Files on page 68.

Tools
If you have an installation .MSI, you can open and edit it in Wise for Windows Installer.
However, to take advantage of some Wise for Windows Installer features, you can
convert the .MSI to a project file.
See:
Converting an .MSI to a .WSI File on page 365

Specifying Merge Module Source Directories on page 366
Specifying File Source Directories on page 367
Converting an .MSI to a .WSI File

By default, MSI to WSI Conversion extracts files and merge modules from an .MSI to a
directory you select. It then creates a project file (.WSI) that references those files and
merge modules. The project file, in turn, can be edited in Wise for Windows Installer,
and then compiled to a new .MSI file. Alternately, instead of extracting files from the
.MSI and creating the new .WSI to point to them, you can redefine source paths so they
point to source files already on your computer. In this case, the files from the .MSI are
not extracted, but are substituted by files on your computer.
A .WSI file records the files and merge modules that should be compiled into the .MSI by
storing source paths. (You can see a source path in Wise for Windows Installer by
double-clicking a file on the Files or Web Files page.) When you open a .WSI and
compile, Wise for Windows Installer reads the source paths, and then compiles them
into the .MSI.
Running MSI to WSI Conversion involves redefining source paths, either by extracting
files and merge modules from the .MSI itself, or by redefining the source paths to point
to files and merge modules that already exist on your computer.
To convert an .MSI to a .WSI:

1. (Visual Studio integrated editor only.) To add the installation project to a specific
solution, first open the solution in Visual Studio .NET.
2. Open an .MSI.
If a message appears asking you to convert this Windows Installer database to a

Wise project file, click Yes. Otherwise, select Tools menu > MSI to WSI Conversion.
(In Visual Studio: Project menu > MSI to WSI Conversion.)
3. In New Source Directory, specify the directory to which all files and merge
modules in the .MSI will be extracted. In the converted .WSI file, all source paths
will point to the files and merge modules located in this directory. You can override
this directory for individual files and merge modules later in this wizard.
If the .MSI contains any merge modules, the Merge Module Sources dialog appears;
otherwise, the File Sources dialog appears.
4. On the Merge Module Sources dialog, you can change the default for extracting
merge modules, which is to extract them from the .MSI into the default source
directory you specified on the Welcome dialog. To accept the default, click Next. To
change the default, see Specifying Merge Module Source Directories on page 366.
5. On the File Sources dialog, you can change the default for extracting files, which is
to extract them from the .MSI into the default source directory you specified on the

Tools
Welcome dialog. To accept the default, click Next. To change the default, see
Specifying File Source Directories on page 367.
The Create WSI File dialog appears.
6. In New .WSI File, specify the path of the new .WSI to create. Do not select a
directory that already contains an .MSI of the same name, because when you
compile this .WSI file, it overwrites any .MSI of the same name that resides in the
same directory.
7. Click Finish.
If any source files or associated .CAB files are not in the location specified in the
.MSI, they are listed on the Files Not Found dialog and source paths are not created
for those files. You must find them and add them to the new .WSI.
The new .WSI is created at the location you specified, the current .MSI is closed,
and the new .WSI is opened. (In Visual Studio: the new .WSI is added to the current
solution as a new project.) Compile and test this installation thoroughly before
deploying.
Specifying Merge Module Source Directories

During MSI to WSI Conversion, merge modules are extracted from the .MSI to the
default source directory specified on the Welcome dialog. The source files are pulled
from the source directory when the .WSI is compiled. On the Merge Module Source
dialog, you can override the default source directory for specific merge modules. For
information on converting an .MSI, see MSI to WSI Conversion on page 364.
You can override the default source directory in the following ways:
z Change Source Directory

Extract merge modules to a directory other than the default directory.
z Replace With Local File

Select merge modules on your computer to replace the merge modules in the .MSI.
The merge modules you select on your computer must have identical GUIDs as
those you are replacing.
z Search Module Directories

Search for merge modules by GUID in all the merge module directories defined in
Wise Options.
z Reset to Default
After changing the source path through any of the above methods, you can reset a
merge module to its default, which is to extract to the default source directory.
To change the directory to which merge modules will be extracted:

1. On the Merge Module Sources dialog, select one or more merge modules.
2. Click Change Path and select Change Source Directory.
The Select Directory dialog appears.
3. Select a directory and click OK. The merge modules you selected will be extracted to
this directory instead of the default source directory.
4. Complete the .MSI to .WSI conversion wizard.

Tools
To replace merge modules with merge modules on your computer by

specifying the merge module location:
1. On the Merge Module Sources dialog, select one or more merge modules to replace.
2. Click Change Path and select Replace With Local File.
If multiple merge modules are selected, the Select Directory dialog appears. If one
merge module is selected, the Choose Replacement Merge Module dialog appears.
3. Select either a directory or a specific merge module:
On the Select Directory dialog, select the directory that contains replacement
merge modules for all the merge modules you have selected and click OK.
Merge modules are matched by GUID, a unique identifier attached to Windows
Installer files, rather than by name. If the search is unsuccessful, a dialog lists
the merge modules that were not found.
On the Choose Replacement Merge Module dialog, specify the merge module to
replace the selected merge module. You must specify a merge module whose
GUID matches the GUID of the original merge module; otherwise an error
occurs.
The Source column on the Merge Module Sources dialog changes to Local to indicate
that a local merge module will be used instead of the merge module in the .MSI.
4. Complete the MSI to WSI conversion wizard.
To replace merge modules with merge modules on your computer by

searching:
1. On the Merge Module Sources dialog, select one or more merge modules to replace.
2. Click Change Path and select Search Module Directories.
A search of module directories is performed. Merge Module directories are defined in

Wise Options.
Merge Modules are matched by GUID, a unique identifier attached to Windows

Installer files, rather than by name. The first found instance is used. The Source
column changes to Local to indicate that local merge modules will be used instead of
merge modules from the .MSI. If the search is unsuccessful, a dialog lists the merge
modules that were not found.
Specifying File Source Directories

During MSI to WSI Conversion, files are extracted from the .MSI to the default source
directory specified on the Welcome dialog. The source files are pulled from the source
directory when the .WSI is compiled. On the File Sources dialog, you can override the
default source directory for specific files. For information on converting an .MSI, see MSI
to WSI Conversion on page 364.
You can override the default source directory in the following ways:
z Change Source Directory

Extract files to a directory other than the default directory.
z Replace With Local File

Select files on your computer to replace the files in the .MSI. This option lets you
search your computer for matching files.

Tools
z Reset to Default
After changing the source path through any of the above methods, you can reset a
file to its default, which is to extract to the default source directory.
To change the directory to which files will be extracted:

1. On the File Sources dialog, select one or more files.
2. Click Change Path and select Change Source Directory.
The Select Directory dialog appears.
3. Select a directory and click OK. The selected files will be extracted to this directory
instead of the default source directory.
To replace one file with a file on your computer:

1. On the File Sources dialog, select a file to replace.
The Choose Replacement File dialog appears.
3. Specify a file to replace the selected file. The Source column on the File Sources
dialog changes to Local to indicate that a local file will be used instead of the file in
the .MSI.
To replace multiple files with local files by searching:

1. On the File Sources dialog, select multiple files to replace.
The Replace With Local Files dialog appears.
3. Select an option from Search Options and click OK.
Selected Directory Only

Search only the current directory for the selected files.
Selected Directory and Sub-Directories

Search the current directory and all its subdirectories for the selected files.
Note
For the following 2 options, the Destination Path column is appended to whatever
directory you select. Example: Suppose you are repackaging Application.msi, and
you have it installed in C:\Program Files\Application, you would select the C:\ drive,
then select Selected Directory Contains Destination Directory Structure and
click OK. If you selected the Application directory itself, it would result in searching
C:\Program Files\Application\Program Files\Application because the Destination
Path column on the File Sources dialog is appended to the end of the directory you
select.
Selected Directory Contains Destination Directory Structure

Select this if a directory on your computer or network contains the application’s
files in a directory structure that mimics the directory structure in which they
will be installed. You might have this directory if you have the application

Tools
installed, or you might just have a directory that contains the same directory
structure as that of the installed application.
Using this option, the Duplicate Files Details dialog might appear if the
installation you are converting contains instances of duplicate files. An
installation can contain multiple copies of a file and the copies can be set to
install to the same directory. Example: Suppose the installation Application.msi
contains both a Windows NT version and a Windows 98 version of the file
pshop.dll. Only one file gets installed, depending on the operating system the
installation runs on. In an installation with duplicate files, MSI to WSI
Conversion cannot change the paths to point to your local computer, because
your local computer only contains one copy of the file. For these files, either
leave them set to the default, which will extract all copies of the file from the
.MSI, or individually replace them with the appropriate files from your
computer.
Selected Directory Contains Administrative Install

Select this if a directory on your computer or network contains an
administrative installation. Select the same directory you selected as the root
directory for the administrative installation. An administrative installation
mimics the directory structure of the installed application and allows for
network installations. Unlike a normal installation, an administrative installation
has a copy of every file that the installation contains. This option pulls files from
the directory structure created by an administrative installation.
Files are matched by name. The first found instance is used. The Source column on
the File Sources dialog changes to Local to indicate that local files will be used
instead of files from the .MSI. If the search is unsuccessful, a dialog lists the files.
Package Validation
Package Validation checks a Windows Installer package for errors based on rules in one
or more validation modules. It validates package files (.MSI and .WSI), merge modules
(.MSM and .WSM), and transforms (.MST). For details, see Validating a Package.
z If you correct validation errors in a .WSI or .WSM, it is recompiled to an .MSI or

.MSM at the end of validation.
z If you correct validation errors in an .MSI or .MSM, errors are not corrected in any
corresponding .WSI or .WSM.
z When you specify a transform, Package Validation checks both the transform and
the original .MSI.
Package Validation contains predefined validation modules. See Predefined Validation

Modules on page 378. In the Professional and Enterprise Editions, the validation
modules are fully customizable to accommodate corporate standards:
z You can select which validation rules to use during the validation test.
z You can create new validation modules and new validation rules. (Enterprise Edition
only.)
See Customizing Validation Modules on page 371.
Portions of Package Validation were developed based on public Microsoft documents. It

has not been reviewed or certified by Microsoft. This tool helps you prepare a package
for certification, but cannot guarantee that the application will meet all Windows

Tools
Application Specification requirements. For information on Windows requirements, see

Windows Installer and Logo Requirements in the Windows Installer SDK Help.
Note
Package Validation ignores issues pertaining to the group box “enabled” attribute, which
Microsoft’s validation module falsely reports as an error.
Validating a Package
Use Package Validation to verify an installation package using predefined or customized
validation modules.
1. Open the installation file (.MSI or .WSI), merge module (.MSM or .WSM), or
transform (.MST) to test.
2. Select Tools menu > Package Validation. (In Visual Studio: Project menu > Package
Validation.)
3. To view the description of a validation module, select the module in the list.
4. Mark the validation modules to use to validate the package.
By default, the list contains predefined validation modules. See Predefined

Validation Modules on page 378.
Note
The tests in Application Specification Logo are a subset of the tests in Internal
Consistency, therefore, running both tests at the same time might result in duplicate
errors.
5. If this installation contains multiple releases, the Release drop-down list appears
below the list of validation modules. Select the release to test.
6. (Professional and Enterprise Editions only.) To customize or create validation

modules, click Customize and see Customizing Validation Modules on page 371.
7. Click Next to start testing.
The Performing Validation dialog appears.
When the validation is complete, the View / Correct dialog appears. It lists validation
issues that represent areas where the package might not comply with the
specifications in the validation modules you selected. The icon to the left of each
issue indicates the issue type.
{{{import icons at 78 dpi for better legibility}}}
Icon Issue Type Indicates

Error A problem that causes incorrect behavior and must
be fixed.
Warning A problem that might cause incorrect behavior.
When a validation rule set displays issues, it uses
this icon. See Adding a Validation Rule Set on
page 376.

Tools
Icon Issue Type Indicates

Logo Issue A possible problem based on Microsoft’s logo
specifications.
Wise-specific A possible problem based on checks that are built in
Issue to Wise for Windows Installer.
8. Select an issue to view its description in Details.
If the issue was found by a Microsoft validation module, see ICE Reference in the
Windows Installer SDK Help for details.
9. If the Correct button is enabled when you select an issue, click it to correct the
issue.
Caution
If you correct a .WSI or .WSM, it is recompiled to an .MSI or .MSM at the end of
validation. If you correct an .MSI or .MSM, errors are not corrected in any
corresponding .WSI or .WSM.
10. If the Correct button is not enabled when you select an issue, the issue cannot be
corrected within Package Validation. Make any necessary changes to the installation
package in Wise for Windows Installer.
Note
The Correct button is not enabled when an issue is found by a custom action rule.
Depending on how the custom action is written, the problem might be fixed
automatically when it’s found, or you might need to fix the problem manually.
11. To add issues to the Task List and fix them manually, mark Add to Task List.
When you click Finish, the issues appear in the Task List. See Using the Task List on
page 26.
12. To obtain a record of the issues, click Save to File or Print All.
13. Click Finish.
Also see Package Validation on page 369
Customizing Validation Modules

A validation module is a .CUB file that contains one or more validation rules. A validation
rule can be a custom action that calls a .DLL, .EXE. or VBScript (.VBS), or a rule set that
consists of a series of conditions and actions.
In the Professional and Enterprise Editions, you can customize validation modules by
selecting which validation rules to use during the validation test. See Selecting
Validation Rules to Use on page 373.
In the Enterprise Edition, you also can create new validation modules and new validation
rules. Do this if you prefer not to modify a predefined validation module, or to define a
validation module that contains only your custom rules.

Tools
See:
Adding a Validation Module to Package Validation on page 372

About Rules That Call a Custom Action on page 374
Adding a Rule That Calls a Custom Action on page 374
About Validation Rule Sets on page 375
Adding a Validation Rule Set on page 376
Adding a Validation Module to Package Validation

Package Validation contains predefined validation modules. If the predefined validation
modules do not meet your needs, you can add new ones. These can be validation
modules you create in the Customized Validation Rules dialog or in another program
such as the Orca database editor.
1. Start Package Validation as described in Validating a Package on page 370 and click
Customize on the Welcome dialog.
The Customized Validation Rules dialog appears. Validation Files lists the
predefined validation modules and any validation modules you’ve added. When you
select a validation module, its rules appear in Validation Rules.
2. Click Add to the right of the Validation Files list.
The Validation File Details dialog appears.
3. Enter a unique name and description to identify the validation module in the
Welcome dialog of Package Validation.
4. In File, specify a new or existing .CUB file name.
If this is a new file and you do not specify its location, it is created in the Validation
subdirectory of your share point directory.
5. If the .CUB file you specify is intended to validate merge modules only, mark Only
display this file for Merge Modules.
6. Click OK.
On the Customized Validation Rules dialog, the validation module you specified
appears in Validation Files.
7. To add a rule to the validation module, click Add to the right of the Validation
Rules list. To add a rule that:
Calls a custom action, see Adding a Rule That Calls a Custom Action on
page 374.
Consists of a series of conditions and actions, see Adding a Validation Rule Set
on page 376.
8. To enable or disable the rules to use during validation, see Selecting Validation Rules
to Use on page 373.
9. To delete a validation module or rule, select it and click the Delete button to its
right.
Deleting a validation module from Package Validation does not delete the .CUB file
from the computer.
10. When you finish, click OK.

Tools
The customizations remain in effect until you change them.
Also see:
Customizing Validation Modules on page 371

Predefined Validation Modules on page 378
Selecting Validation Rules to Use

A validation module typically contains multiple rules that verify a package. You can
customize validation modules by selecting which validation rules to use during the
validation test.
Example:
Darice.cub, authored by Microsoft, contains more than 90 ICE (Internal Consistency

Evaluator) custom actions, or rules, that check a package’s internal database
consistency. You can disable any of these rules. For a description of Microsoft’s ICE
custom actions, see ICE Reference in the Windows Installer SDK Help.
Note
When customizing a predefined validation module, customize a copy of the .CUB file to
retain the original file.
2. In Validation Files, select a validation module.
If the validation module is not listed, see Adding a Validation Module to Package
Validation on page 372.
3. In Validation Rules, mark the checkboxes for rules to include.
4. (Enterprise Edition only.) To add a rule to the validation module, click Add to the
right of the Validation Rules list. To add a rule that:
Calls a custom action, see Adding a Rule That Calls a Custom Action on
page 374.
Consists of a series of conditions and actions, see Adding a Validation Rule Set
on page 376.
5. When you finish, click OK.
Also see:

Predefined Validation Modules on page 378

Tools
About Rules That Call a Custom Action

You can add rules that call a custom action to a new or existing validation module
(.CUB). The custom action, which must be in the form of a .DLL, .EXE, or VBScript
(.VBS), performs specific checks on a package. For details, see Adding a Rule That Calls
a Custom Action on page 374.
Note
You cannot add rules to predefined validation modules.
Example: Suppose you want to check packages for hard-coded references to C:\ or D:\
and replace those references with the directory property INSTALLDIR. To do this, write a
VBScript to find and replace the references and then display a message. In Package
Validation, you specify a new or existing .CUB file and add a rule that calls the VBScript.
When you run Package Validation with the new rule enabled, the VBScript performs the
find and replace operations.
When a validation test finds an error based on a custom action rule, the Correct button
on the View / Correct dialog is not enabled; the error is fixed based on functions in the
custom action. Errors found by a custom action rule are displayed on the View / Correct
dialog only if the custom action contains a message string. For information on
formatting message strings, see ICE Message Guidelines in the Windows Installer SDK
Help.
For information on creating a custom action to perform validation checks, see Internal
Consistency Evaluators - ICEs and Building An ICE in the Windows Installer SDK Help.
Also see:

Adding a Validation Rule Set on page 376
Adding a Rule That Calls a Custom Action

Note
When customizing a predefined validation module, customize a copy of the module to
1. Write a custom action (.DLL, .EXE, or VBScript) to perform validation checks.
3. In Validation Files, select a validation module to customize.

Tools
Note
4. Click Add to the right of the Validation Rules list and select DLL Rule, EXE Rule, or
VBScript Rule.
A details dialog appears.
5. Enter a unique name and description to identify this rule when it appears in the
Validation Rules list.
6. If the custom action file is in the File drop-down list, select it.
The files listed are those contained in the validation module you are editing.
7. If the custom action file is not in the File drop-down list, do one of the following:
For .DLL and .EXE files, click New and specify the .DLL or .EXE file.
For a VBScript file, click Options, select New, and specify the VBScript file. To
edit the VBScript, click Options, select Edit, and modify the VBScript in the
Macro Editor.
8. (.DLL and VBScript only.) If the Function field appears, enter the name of the
function in the .DLL or VBScript that performs the validation.
9. (.EXE only.) If the Parameters field appears, enter any command line options that
are needed to run the .EXE.
10. Click OK
The OK button is disabled if required fields are missing.
The Customized Validation Rules dialog reappears, and the new rule is displayed at
the end of the Validation Rules list with its checkbox marked.
11. To add more rules to this validation module, either repeat this procedure or see
Adding a Validation Rule Set on page 376.
Also see:

About Validation Rule Sets

You can add a rule set to a new or existing validation module. A rule set consists of a
series of conditions to check in a package and actions to take if the conditions are met.
You create rules sets with the Validation Rules wizard.
Note
Example:

Tools
Suppose you want to determine if your packages contain any version of report.dll earlier
than 2.0.0 and if so, replace it with version 2.0.0 of report.dll. The rule set you create
for this check would contain the following conditions and actions:
Select file with name report.dll

and where version is less than 2.0.0
Display text report.dll version less than 2.0.0 in View/Correct dialog
Replace file with C:\Development\DLLs\report.dll
The underlined values in the conditions and actions might be truncated on the screen.
When you include the action to display text, errors found by a custom rule set are
displayed on the View / Correct dialog. The error text is displayed with the question
mark icon ( ) and the Correct button is enabled. Click Correct to perform the actions in
the rule set.
Also see:

Adding a Rule That Calls a Custom Action on page 374
Adding a Validation Rule Set

Note
When customizing a predefined validation module, customize a copy of the .CUB file to
2. In Validation Files, select a validation module to customize.
Note
3. Click Add to the right of the Validation Rules list and select Rule Set.
The Validation Rules dialog appears.
4. Enter a unique rule set name and description to identify this rule set in the
Validation Rules list.
5. Click Add.
The Validation Rules wizard starts and the Name dialog appears.
6. Complete the dialog and click Next:
Rule name
Enter a unique name for this rule.

Tools
Type
Select whether an issue that breaks this rule will be displayed as an error or
warning on the View / Correct dialog.
The Conditions dialog appears.
7. In Which condition(s) do you want to check, mark conditions in the order they
should be checked.
The conditions you mark appear in the Rule description list.
8. If a condition contains underlined text, click the underlined text to open the Rule
Details dialog and specify its value.
Example: If you selected the condition:
Select file with name any
you would click the word any and enter a specific file name.
9. When you finish adding conditions, click Next.
The Actions dialog appears.
10. In Which action(s) do you want to perform, mark the action or actions to
perform if the conditions for this rule are met. Mark them in the order they should
be performed. Actions that are incompatible with the conditions you selected are
disabled.
The actions you mark appear in the Rule description list.
Note
To display a message in Package Validation’s View / Correct dialog, include the
action Display text [text] in View/Correct dialog. Replace [text] with your message.
11. If an action contains underlined text, click the underlined text to open the Rule
Details dialog and specify its value.
Example: If you selected the action:
Display text none in View/Correct dialog
you would click the word none and enter specific text.
12. When you finish adding actions, click Finish.
The Validation Rules dialog reappears. The rule list displays the rule, and the Rule
description list displays its conditions and actions.
13. To add additional rules, click Add to restart the Validation Rules wizard.
14. Modify rules on the Validation Rules dialog as follows:
To edit a rule, select it in the rules list and click Details. This restarts the
Validation Rules wizard, in which you can change the rule name or any
conditions or actions.
To delete a rule, select it in the rules list and click Delete.
To rearrange the order of the rules, select a rule in the rules list and click Move
Up or Move Down.
To change the value in a condition or action, click its underlined text in the Rule
description list and enter new text on the Rule Details dialog.
15. When you finish adding and editing rules, click OK on the Validation Rules dialog.

Tools
The OK button is disabled if required fields are missing.
The Customized Validation Rules dialog reappears, and the new rule set is displayed
at the end of the Validation Rules list with its checkbox marked.
16. To add more rules to this validation module, either repeat this procedure or see
Adding a Rule That Calls a Custom Action on page 374.
Also see:

Predefined Validation Modules

Package Validation contains predefined validation modules that perform the tests
described below.
z Application Specification Logo

Runs logo.cub, which is provided by Microsoft as part of its logo verification
program. The tests in logo.cub are a subset of the tests in darice.cub, therefore,
running both tests at the same time might result in duplicate errors.
z Windows Installer SDK Internal Consistency

Runs darice.cub, which is provided by Microsoft. It performs more than 50 checks to
ensure that the installation databases are internally consistent.
z Merge Module Consistency Checks

Runs mergemod.cub, which is provided by Microsoft to test the internal consistency
of merge modules. This is the only predefined validation module that appears on the
Welcome dialog when you validate a merge module.
Wise for Windows Installer Checks

The following checks are built in to Package Validation; they do not run .CUB files.
z Component design
Checks that the proper files have been placed into each component and that the
same file has not been placed into multiple components.
z Uninstall support
Checks that the package does not reference non-Windows Installer uninstall
utilities.
z Files in shared folders

Checks that no executable files have been placed in shared folders.
z Hidden and protected application files

Checks that application files have been protected from accidental deletion by the
end user.
z Transitive flag set on OS based components

Checks that the Transitive bit is set on operating system-dependent components.
Transitive components are components that must be swapped out if the end user
upgrades the destination computer to a new operating system.
z Icon placement in Start Menu

Checks that shortcut icons are installed correctly in the Start Menu.

Tools
z All application/library files are 32-bit

Ensures that no 16-bit components are included in the package.
z Changes to Win.ini or System.ini

Checks to see if changes are being made to these files.
z Components shared with non-Windows installer applications

Checks that no components of the package are shared with other applications that
do not use Windows Installer.
z Files installed to Program Files by default

Checks that all application files are installed to a subdirectory of Program Files.
z Terminal Server Compatibility

(Enterprise edition only.) Checks for errors that might cause problems when the
package is installed in a Microsoft Terminal Services or Citrix environment. With
terminal service applications, installation resources must reside in per-machine
locations rather than per-user locations. Errors result from this test if the installation
is set to install per-user, if any keypaths reside in user-specific locations, or if
environment variables are present in the installation. If environment variables are
present, using the Correct button duplicates the variables, creating a per-user set
and a per-machine set, one of which is installed depending on the value of
ALLUSERS. Correcting some errors might cause keypaths to be empty, and might
cause a one-time repair. You can set a release to be compatible with Terminal
Services. See the description of the Release Type field in Creating a New Release
on page 179. Also see ALLUSERS Property in the Windows Installer SDK Help.
Also see:
Validating a Package on page 370

Wise Task Manager

¾ Enterprise Edition of Wise Editor only.
Wise Task Manager manages the following operations:
z Importing packages into the Software Manager database.
z Adding, removing, or replacing merge modules that are part of .MSI or .WSI
packages in the Software Manager database.
z Compiling .MSI or .WSI packages in Software Manager.
Each of these managed operations consists of one or more tasks.
Because Wise Task Manager manages these operations, the user who runs them can
proceed with other tasks in Wise Package Studio while these operations are processed.
When a user runs one of the managed operations listed above, Wise Task Manager
queues them and executes them in the order in which they are received. An operation is
performed after any other operations that are in the queue for that computer.
Use Wise Task Manager to:
z Cancel the tasks of managed operations. You can cancel only the tasks of operations
that you run.
z View a task’s log file to resolve problems if the task fails.

Tools
z View information about a task, including:
Its status.
What computer ran the task.
How many tasks, if any, are ahead of it and waiting to be executed.
Other task details.
Also see Using Wise Task Manager on page 380.
Using Wise Task Manager

¾ Enterprise Edition of Wise Editor only.
Keys to using Wise Task Manager:
z The tasks for each operation form a group, and every other group of tasks is shaded
to distinguish the groups.
z A task can have 1 of 6 statuses: Canceled, Completed, Executing, Failed, Waiting, or

Warning.
z A Warning status means the task completed, but an error message was written to
the task’s log file.
z If a task fails, Wise Task Manager moves to the next task.
z When a task is executing:
An icon appears in the status column.
Details on the progress of the task appear at the bottom of the Wise Task
Manager dialog unless you select another task.
To use Wise Task Manager:

Select Tools menu > Wise Task Manager.
In Software Manager or Wise for Windows Installer, run a managed operation.

For information on managed operations, see Wise Task Manager on page 379.
The Wise Task Manager dialog appears. If Wise Task Manager opened during a
managed operation, the dialog remains open only until the operation is completed.
2. To view a task’s details, select the task and click Details.
3. To change the tasks that appear, click Options on the Wise Task Manager dialog. By
default, Wise Task Manager displays only the tasks belonging to operations you run
that do not have a status of Completed.
The Wise Task Manager Options dialog appears.
a. Complete the dialog:
Show tasks for all users

Mark this to display the tasks for all managed operations run by all users
who are using the same share point directory.
Show tasks from the last

Select the time period of the tasks to display.

Tools
Show only the tasks with the following statuses

Mark the statuses of the tasks to display.
b. Click OK.
4. To cancel a task, select the task and click Cancel Tasks.
You can cancel only tasks belonging to operations you ran that have a status of
Waiting or Executing. If you cancel one task in an operation, then all the tasks of the
operation are canceled.

Chapter 17
Setup Editor
Setup Editor is a powerful view of the installation, and using its advanced features
requires proficiency in the Windows Installer development environment or in software
development in general. While Installation Expert lets you create basic Windows
Installer installations and provides an easy-to-use, task-oriented user interface to set
the most common installation tasks, Setup Editor lets you create fully customized,
interactive installations.
Topics include:
z About Setup Editor.
z Product Tab.
z Features Tab.
z Components Tab.
z Isolating a .DLL With an .EXE.
z Tables Tab.
Setup Editor also contains the Dialogs Tab, which is discussed in Using the Dialogs Tab
on page 433, and the Module Tab, which is discussed in Available Tabs and Pages in
Merge Modules on page 330.
About Setup Editor

Setup Editor provides an in-depth view of all changes you make to an installation. You
can make those changes in Setup Editor or Installation Expert. However, there are
certain advanced tasks you can perform in Setup Editor only:
z Edit the text on installation dialogs.
z Create components and assign them to features.
z Build complex conditions that must be met for installation to occur.
z Select dialogs to appear during maintenance installations (uninstalls).
z Edit the raw table data of the Windows Installer database.
Note
This documentation does not discuss Windows Installer tables, functions, or properties.
Before you edit raw table data, read the Windows Installer SDK help for that table. On
the Tables tab, click a table and press F1.

Setup Editor
The upper right

pane displays
contents of the
item selected in
The left pane lists the left pane.
items for the selected Double-click
tab. Expand folders items to edit
to see their contents them.
in the upper right
pane. To show or
hide empty items,
right-click and select
Hide Empty Folders/
Items.
The lower right pane contains context-sensitive help. To hide the help, select
View menu and clear Help Pane. (Not available in the Visual Studio integrated
editor.)
Note
Check the right-click menu frequently when you are working in Setup Editor. It provides
access to most of the tasks that you can accomplish in Setup Editor.
Setup Editor Tabs

z Product
Set and edit the summary information to be stored with the installation file,
properties that are used during compile, and launch conditions that determine
whether the installation can run on the destination computer. See Product Tab on
page 384.
z Features
Add, edit, and delete features. Assign components to features; add and remove
components to and from features; and arrange the features of the installation. See
Features Tab on page 385.
z Dialogs
Select and customize dialogs the installation uses. See Using the Dialogs Tab on
page 433.
z Tables
Edit tables in the .MSI database. You can access most of the data in these tables
through Installation Expert pages or other tabs of Setup Editor. Deleting, adding, or
editing table data directly is not recommended unless you are an experienced
Windows Installer developer with a clear understanding of Windows Installer
database technology. See Tables Tab on page 397.
z Components
Add, edit, and delete individual components of the installation. Each component is
one action the installation performs. Example: installing a file, changing the registry,
and so on. See Components Tab on page 390.

Setup Editor
z Module
This tab appears only when you are in a merge module file. Add, edit, and delete the
components, files, registry entries, and other installation modifications contained in
the merge module. See Available Tabs and Pages in Merge Modules on page 330.
Product Tab
On the Product tab in Setup Editor, you set and edit the following information for an
installation:
Summary
Use the Summary icon to set the value of a summary item. End users can see the
See Specifying Summary Information on page 384.
Properties
Use the Properties icon to add, edit, and delete properties in an installation. Properties
are variables that are initialized by the installation and are used by Windows Installer.
The property values can change during runtime. Some of the properties that appear are
required Windows Installer properties, so use caution in editing or deleting them.
See:
Properties on page 415

Creating a New Property on page 417
Properties in the Windows Installer SDK Help
Launch Conditions
Use the Launch Conditions icon to create new launch conditions and edit existing launch
conditions. Launch conditions are system requirements that must be met on the
destination computer for the installation to proceed. See Setting a Requirement by
Creating a Launch Condition on page 168.
Specifying Summary Information

Use the Summary icon to set the value of a summary item. End users can see the
Installer SDK Help.
You can use the Release Settings page to override the value of an existing summary
item or edit customized summary items. See Customizing Summary Items for a Release
on page 182.
To view all available summary items, click the Summary icon in the left pane on the
Product tab. A list of summary items appears in the upper right pane, and you can edit
an item by changing its value. You cannot create or delete summary items, because they
are defined by Windows Installer.
The following summary items are named differently in the Windows Installer SDK Help:

Setup Editor
Name in Setup Editor Name in Windows Installer SDK

Source Type Word Count
Minimum Installer Version Page Count
Package Code Revision Number
Template Summary Template
To set the value of a summary item:

1. In Setup Editor > Product tab, click the Summary icon.
2. In the upper right pane, double-click a summary item. The Summary Details dialog
appears.
In a transform, some summary items are not editable because they keep the value
of the base .MSI.
3. In Value, enter a new value.
4. Click OK.
You also can edit several of the summary items in Installation Expert > General
Information page. See General Information Page on page 98.
Features Tab
The Features tab lets you manipulate an installation’s features and all corresponding
items. It displays a tree structure that lists all components, merge modules, files,
registry entries, and other installation items associated with each feature.
For information on what features are and how they are used, see Working With
Features you add in Installation Expert are displayed on this tab. However, the features’
conditions are not displayed in Setup Editor.
By default, the Features tab displays only items that are in the installation. Example: If
the installation contains a file, a Files icon appears. If you have not added any items to
the installation, only the Features and Complete icons appear. (Complete is the default
feature that is included in new installations.)
Working With the Features Tree

z To display all empty items, right-click in the left pane and select Hide Empty Folders/
Items.
z To display a feature’s contents, click the feature in the left pane. The contents
appear in the upper right pane.
z To display all items in a feature, click the feature’s Combined icon. All items appear
in the upper right pane.
z To display all items in a feature grouped by type, expand the feature’s Combined
icon and click the type icon.
z To expand or collapse a selected feature’s children, use the right-click menu.

Setup Editor
z To customize how items appear in the features tree, right-click in the left pane and
select Customize View. In the Customize View dialog that appears, mark the
checkboxes of the items to display, and rearrange items by clicking Move Up or
Move Down.
z To quickly organize the items on the Features tab:
Drag a feature to a new parent feature.
Drag components from one feature to another.
Adding an Item to a Feature

Do either of the following in Setup Editor > Features tab:
z Right-click the feature name. Select New and the item to add.
z Expand the feature and expand the Combined folder. If necessary, show empty
folders. Right-click the icon for a particular item and select New.
If an icon does not appear, right-click and use the Customize View dialog to show
the icon.
Items You Can Add on the Features Tab

Most of these items can also be added in Installation Expert.
z Feature. See Adding a New Feature on page 103.
z Component assignment. See Assigning a Component to a Feature on page 387.
z Folder. See Creating a Folder in Setup Editor on page 389
z Duplicate file entry. See Creating Duplicate File Entries on page 389
z Environment variable. See Adding an Environment Variable on page 155.
z File association. See Advertising Icon on page 388 and Adding File Associations on
page 156.
z File. See Adding Files to an Installation on page 117.
z INI file. See Creating and Editing .INI Files on page 151.
z ODBC source, driver, or translator. See Adding an ODBC Item on page 162.
z Registry key. See Adding Registry Keys on page 144.
z Service control. See Controlling Services on the Destination Computer on page 161.
z Service. See Adding a Service to the Destination Computer on page 159.
z Shortcut. See Adding a Shortcut to an Installation on page 153.
z Remove Registry operation. See Removing Registry Entries From the Destination
Computer on page 145.
z Remove Files operation. See Removing a File From the Destination Computer on
page 127.
z Move Files operation. See Copying and Moving Files on the Destination Computer on
page 128.
z Copy Files operation. See Copying and Moving Files on the Destination Computer on
page 128.

Setup Editor
You also can view merge modules included in specific features. See Modules Icon on
page 388.
Assigning a Component to a Feature

The Components icon lets you:
z Assign components to features.
z Remove (unassign) components from features.
z Move components between features.
z Add new components and edit the details of existing ones. See Adding and Editing a
When a component is assigned to a feature, the component is installed on the

destination computer only if the feature is installed.
The Components icon on the Features tab shows items in each component. To access
installation items organized by component, use the Components tab. See Components
Tab on page 390.
To assign a component to a feature:

1. In Setup Editor > Features tab, right-click a feature and select New > Component
Assignment.
The Assign Components to Feature dialog appears. The dialog lists all components in
the installation, except those already assigned to the currently selected feature.
2. Select one or more components to add to the feature.
3. Click OK.
You can add the same component to more than one feature; the component is in the
installation only once. Example: If your application includes a grammar check feature
and a spell check feature that both depend on the same file, you might want to assign
that file’s component to both features. That way the file is available even if only one of
the features is installed on the destination computer.
To unassign a component:
1. In Setup Editor > Features tab, expand the folder for the feature that contains the
component to unassign.
2. Click the Components icon. All components for the feature appear in the upper right
pane.
3. In the upper right pane, right-click a component and select Unassign.
Components that are not assigned to any feature are not installed on the destination
computer.
To move a component to a different feature:

1. In Setup Editor > Features tab, expand the folder for the feature that contains the
component to move.
2. Click the Components icon. All components for the feature appear in the upper right
pane.

Setup Editor
3. In the upper right pane, click a component and drag it to a different feature in the
left pane.
The component is moved to the new feature.
Also see Features Tab on page 385.
Modules Icon
The Modules icon displays merge modules included in specific features. However, you
cannot add merge modules here. To add or edit merge modules in an installation, use
Installation Expert > Merge Modules page. See Adding a Merge Module to an Installation
on page 345 and Editing Merge Module Details on page 347.
To view merge modules in a feature:

1. In Setup Editor > Features tab, expand a feature.
2. Click the Modules icon.
The merge modules in the selected feature appear in the upper right pane.
If the Advertising icon does not appear, right-click and select Hide Empty Folders/
Items.
Also see:

Features Tab on page 385
Advertising Icon
The Advertising icon contains information that Windows Installer uses when publishing
and assigning applications to the destination computer. The Advertising icon:
z Shows the entry points that are installed if you are using advertising to make
applications available to end users.
z Lets you edit and create new file associations. See Adding File Associations on
page 156.
Note
The Advertising icon might contain other advertising items besides file extensions
but you can add extensions only.
z Lets you view and edit AppID and ProgID information.
Advertisement, which is a way to deploy applications in large organizations, is available

with Windows Installer, but only for supported platforms. See Advertisement and
Platform Support of Advertising in the Windows Installer SDK Help.
To view or edit AppID or ProgID information:

1. In Setup Editor, on the Components or Features tab, expand the Advertising icon
under a feature or component and select the AppID or ProgID folder.
If the Advertising icon does not appear, right-click and select Hide Empty Folders/
Items.

Setup Editor
2. In the upper right pane, double-click an AppID or ProgID.
The AppID or ProgID dialog appears, which displays information from the AppID or
ProgID table.
3. You can edit the entries in the Value column. See AppID Table or ProgID Table in the
Caution
Editing table data directly is not recommended unless you are an experienced Windows
Installer developer with a clear understanding of Windows Installer database technology.
Creating a Folder in Setup Editor

The Create Folder icon lets you add a new empty directory under an existing directory.
You can also create directories on the Files, Web Files, or Visual Studio Solution pages in
Installation Expert, where you can also use wildcards to add files to directories
automatically. See Editing Settings for Automatic Updating on page 125.
To add permissions to the directory you create, see Setting Permissions for Files and
Directories on page 132.
To create a new folder:

1. In Setup Editor, on the Components or Features tab, right-click a component or
feature and select New > Create Folder.
The Create Folder Details dialog appears.
2. From Directory, select a parent directory.
3. At the end of the existing path, type \ followed by the name of the new directory.
Example: To create a folder named Sample in the Program Files directory, the
Directory field should contain Program Files\Sample.
4. Click OK.
The Create Folder entry appears in the upper right pane.
Also see:

Features Tab on page 385
Creating Duplicate File Entries

Duplicate files are files that must be copied to more than one location during installation.
According to Windows Installer rules, you cannot install the same file multiple times. The
Duplicate File icon lets you:
z Place the same file in different directories.
z Place a file in the same directory with a different name.
See DuplicateFile Table in the Windows Installer SDK Help.
You can create a duplicate file entry only for files that are already in the installation.

Setup Editor
Note
Duplicate files are not created for .NET assemblies added to both the application
directory and the Global Assembly Cache. Instead, they are treated as separate
components.
To add a duplicate file entry:

1. In Setup Editor, on the Components or Features tab, right-click a component or
feature and select New > Duplicate File.
2. The Duplicate File Details dialog appears.
3. Specify the following:
Existing File
Specify the pathname for the file to be duplicated.
Dest. Directory
Specify the directory on the destination computer in which the duplicate file
should be installed. To add a subdirectory to the directory you selected, click
New Folder and enter a folder name.
Long File Name

Enter a name for the duplicate file.
Short File Name

(Optional.) Enter a short file name in 8.3 format to accommodate systems that
don’t support long file names.
4. Click OK.
The duplicate file entry appears in the upper right pane.
If you added the duplicate file to a different feature and a different directory than the
original file, then a new component is created for the duplicate file.
You cannot have 2 components install the same file to the same destination directory. If
the file is already set to be installed to the same directory by a component assigned to
another feature, you are prompted to create a component assignment to the current
feature. If you do this, then any future changes to the component will affect all features
to which it is assigned.
To edit a duplicate file entry, double-click its name. To delete it, right-click its name and
select Delete.
Components Tab
The Components tab lets you manipulate an installation’s components. It displays a tree
structure that lists all files, registry entries, and other installation items contained in
each component. It also indicates any component errors.
Installation Expert automatically creates the appropriate components for each item you
add and organizes them according to a component rule set you select. Example: You can
always create a new component for each new file added to the installation, or you can
group related resources, such as help files, into one component. See Component Rules
on page 57.

Setup Editor
By default, the Components tab displays only items that are in the installation. Example:
If the installation contains a file, a Files icon appears. If you have not added any items to
the installation, only the Components icon appears.
Working With the Components Tree

z To display all empty items, right-click in the left pane and select Hide Empty Folders/
Items.
z To display a component’s contents, click the component in the left pane. The
contents appear in the upper right pane. You also can expand the component so
that its contents appear in the components tree.
z To expand or collapse a selected component’s children, use the right-click menu.
z To customize the icons that appear in the components tree, right-click in the left
pane and select Customize View. In the Customize View dialog that appears, mark
the checkboxes of the items to display, and rearrange items by clicking Move Up or
Move Down.
z To quickly organize the items on the Components tab:
Drag an item from the upper right pane to a different component on the left
pane.
In the left pane, drag an entire component item group from one component to
another.
Adding an Item to a Component

Do either of the following in Setup Editor > Components tab:
z Right-click the component name. Select New and the item to add.
z Expand the component. If necessary, show empty folders. Right-click the icon for a
particular item and select New.
If an icon does not appear, right-click and use the Customize View dialog to show
the icon.
Items You Can Add on the Components Tab

Most of these items can also be added in Installation Expert.
z Component. See Adding and Editing a Component on page 392.
z Folder. See Creating a Folder in Setup Editor on page 389
z Duplicate file entry. See Creating Duplicate File Entries on page 389
z Environment variable. See Adding an Environment Variable on page 155.
z File association. See Advertising Icon on page 388 and Adding File Associations on
page 156.
z File. See Adding Files to an Installation on page 117.
z INI file. See Creating and Editing .INI Files on page 151.
z Isolated component. See Isolating a .DLL With an .EXE on page 396.
z ODBC source, driver, or translator. See Adding an ODBC Item on page 162.
z Published component. See Adding Published Components on page 397.
z Registry key. See Adding Registry Keys on page 144.

Setup Editor
z Service control. See Controlling Services on the Destination Computer on page 161.
z Service. See Adding a Service to the Destination Computer on page 159.
z Shortcut. See Adding a Shortcut to an Installation on page 153.
z Remove Registry operation. See Removing Registry Entries From the Destination
Computer on page 145.
z Remove Files operation. See Removing a File From the Destination Computer on
page 127.
z Move Files operation. See Copying and Moving Files on the Destination Computer on
page 128.
z Copy Files operation. See Copying and Moving Files on the Destination Computer on
page 128.
Also see:
Component Errors on page 392

Moving Items Between Components on page 395
About the Key Path on page 396
Component Errors
As you work on the Components tab, Setup Editor continually monitors components for
common errors. When it detects an error, it changes the color of the component’s icon to
red.
To view a component error message:

In Setup Editor > Components tab, right-click the red component icon and select Show
Errors.
Typical Causes of Component Errors

z The component has an empty key path but contains files, registry entries, or ODBC
data sources.
z The component has more than one executable (.EXE, .DLL, .OCX).
z The same file is assigned to multiple components.
z A shortcut is assigned to the component, but the key path for the shortcut is not a
file.
z Registry keys are created in HKEY_CURRENT_USER, but the key path is not for a
registry key in HKEY_CURRENT_USER.
Also see Components Tab on page 390.
Adding and Editing a Component

Caution
To work with items on the Components tab, you should be proficient in the Windows
Installer development environment. See Windows Installer Components in the Windows
Installer SDK Help.

Setup Editor
Installation Expert automatically creates the appropriate components for each item you
add to an installation. However, you can add and edit components yourself in Setup
Editor > Components tab.
z To edit a component, double-click its name.
z To edit multiple components, first select the Components icon in the upper left pane.
In the upper-right pane, select components, right-click, and select Details. On the
Multi-Component Details dialog, you can edit a subset of the fields found in the
Component Details dialog.
z To delete or rename a component, use the right-click menu.
To add a new component:

1. In Setup Editor > Components tab, right-click and select New > Component.
The Component Details dialog appears.
Component
Enter a name for the new component. Components generated by Installation
Expert have automatically generated names that usually reflect the first file
added to a particular directory.
Directory
Enter the directory on the destination computer where the files in this
component will be installed. To create a new folder, click New.
GUID
(Optional.) To replace the automatically-generated GUID (globally unique
identifier) for this component with a new one, click Generate.
Condition
Enter the condition required to install this component. To always have the
component installed, leave this blank. To enter a condition that must evaluate to
true before the component can be installed, click Build. The Condition Builder
appears. See Creating Conditions With Condition Builder on page 411.
For some conditions, you might need to add a special merge module that
addresses a limitation of Windows Installer. See Using Conditions With Features
on page 108.
Run Location
Select the location from which the component should run:
Run Locally
The component is installed and runs from the destination computer’s hard
drive. This setting overrides the corresponding feature’s attribute.
Run from Source

The component runs from the media or the server that contains the
installation. This setting overrides the corresponding feature’s attribute.
Run from Source or Locally

The component takes on the feature’s attribute.
Key Path Type

Select the type of item Windows Installer should use as a key path:
File Key Path

Use a file as the component’s key path.

Setup Editor
Registry Key Path

Use a registry entry as the component’s key path.
ODBC Data Source Key Path

Use an ODBC data source as the component’s key path.
Key Path
Select the item Windows Installer should use as a key path. The drop-down list
shows files, registry entries, or ODBC data sources that are included in the
component, depending on your selection in the Key Path Type field. See About
the Key Path on page 396.
Always increment shared .DLL count

Mark this to increment the count of applications using .DLLs in this component
when installing it, even if the component is already installed. If a component is
installed to the Global Assembly Cache, you cannot increment the reference
count.
Leave installed on uninstall

Mark this to leave the component installed when its feature is uninstalled.
Check condition during reinstall (Transitive)

Mark this to check the condition not only on the original installation but also
when the component is re-installed.
Never overwrite if key path exists

Mark this to prevent the component from being installed if the item specified as
the key path already exists.
64-bit component
(64-bit installations only.) Mark this to designate the component as a 64-bit
component. The target directory and the component must both be either 32-bit
or 64-bit. If one is 32-bit and the other is 64-bit, a warning message appears,
giving you the option to change the target directory to match the component.
Example: If this checkbox is marked and the Directory is Program Files (x86),
you are prompted to change this target directory to its 64-bit counterpart,
Program Files.
Self-register key path file before compile

Mark this so that, each time you compile, the file referenced in the Key Path
field is re-registered, the registration information is rescanned, and any new
information is added to the installation.
If you clear this checkbox, then the file is not self-registered; instead,
registration information is scanned from its type library and added to the
installation. Registering the file enables its advertising information to be drawn
into the installation—if the file is not registered, then this advertising
information might not be present on the current computer, which means it
cannot be automatically added. See How Self-Registration Information is
Captured on page 139.
Rescan advertising information during compile

Mark this to gather advertising information from the registry for the file
referenced in the Key Path field each time you compile the installation. This
overrides the Default to rescan advertising for new components checkbox
in Wise Options for this component.
Import REG File

Specify a .REG file that contains registry information about the key path file.
This information is read into the component each time you compile.

Setup Editor
Example: If the programmer who creates the key file for this component is not
the author of the installation, the programmer can place all required information
into a .REG file and give this file to the installation author for inclusion into the
component. You can use WiseComCapture.exe to create this .REG file. See
Using WiseComCapture.exe on page 140.
Extract advertising information from registry file

Mark this to take information from the .REG file and places it into the
advertising tables instead of the registry tables if possible.
3. Click OK on the Component Details dialog.
If the installation has only one feature, the component is added to that feature. If
the installation has more than one feature, the Select Feature(s) to Assign
Component to dialog appears.
4. Mark one or more checkboxes for the features to assign the new component to and
click OK.
The component appears in the upper right pane.
Also see: Components Tab on page 390.
Moving Items Between Components

Caution
To work with items on the Components tab, you should be proficient in the Windows
Installer development environment. See Windows Installer Components in the Windows
Installer SDK Help.
On the Components tab, you can move items from one component to another. The
procedure below works for all types of items, and also warns you when a key path must
be changed. For files and registry entries, you can drag between components, but you
are not warned if a key path is changed.
1. In Setup Editor > Components tab, navigate to an item so that it appears in the
upper right pane.
2. In the upper right pane, select one or more items, right-click, and select Move.
Note
If an item you select is the component’s key path, a message informs you that the
item will become the destination component’s key path, even if that component
already has a key path. To reset the destination component’s key path, click Yes. To
cancel the move, click No. You can reset key paths manually by right-clicking an
item and selecting Set as Key.
The Move to a Different Component dialog appears.
3. Click the component to move the selected item to.
4. Click OK.
If the component icon is colored red after you move an item to it, the change you made
causes an error. Right-click the component and select Show Errors to see a description
of the problem.

Setup Editor
About the Key Path

To determine whether a specific component is installed, Windows Installer looks for the
component’s key path rather than looking for every item in the component. If it finds the
item that is specified as the key path, it assumes that all other items that make up the
corresponding component, and therefore, the component, are installed. Some items
require a key path (example: advertised shortcut).
Setup Editor indicates key paths by placing a yellow key icon over the item’s icon.
To set an item as key path:

z In Setup Editor > Components tab, right-click the item and select Set as Key.
OR
z Select the item as key path on the Component Details dialog. See Adding and
Editing a Component on page 392.
Isolating a .DLL With an .EXE

To prevent .DLL conflicts, you can associate a .DLL file in the installation with a specific
.EXE file in the installation. Then Windows Installer automatically associates the .DLL
with the .EXE, even if the destination computer already has a .DLL with the same name
installed. See Isolated Components in the Windows Installer SDK Help.
Only Windows 98 Second Edition (SE), Me, 2000, XP, and Server 2003 support isolated
components. Therefore, you should add the .DLL to the System32 directory, as you
normally would. Then, create an isolated component that moves the .DLL to your
application’s directory if the destination computer runs one of the above operating
systems.
Note
Before you isolate a .DLL with an executable, make sure that you’ve added all files to
the installation, especially .EXE and .DLL files.
To isolate a .DLL with an .EXE:

1. In Setup Editor > Components tab, right-click a .DLL and select New > Isolated
Component.
The Isolated Component Details dialog appears, where you select a file for isolation
from the feature that contains the component.
If the key path for the current component is not an .EXE, the drop-down list
shows all .EXEs in the containing feature that are key paths of .DLL files.
If the key path for the current component is an .EXE, the drop-down list shows
all files from the containing feature that are key paths other than the current
component.
2. From Associated File, select the .EXE to assign to this .DLL.
3. Click OK.
The isolated component entry appears in the upper right pane. To edit it, double-click its
name. To delete it, right-click its name and select Delete.

Setup Editor
Adding Published Components

Published components let applications written specifically for Windows Installer refer to
one or more components by a single identifier. Example: Do this to add the same
published component to each component in a feature. At runtime, the installation only
needs to check for one published component to determine if the feature is installed. See
PublishComponent Table and Qualified Components in the Windows Installer SDK Help.
1. In Setup Editor > Components tab, right-click a component and select New >
Published Component.
2. The Publish Component Details dialog appears.
Publish GUID
(Optional.) To replace the automatically-generated GUID (globally unique
identifier) for this component with a new one, click Generate.
Feature
Select the feature to have published.
Component
Select the component to have published.
Qualifier
Enter a text string to distinguish multiple forms of the same component.
Application Data
Enter a text string that describes the qualified component, that is, the
combination of component and qualifier. This string can be displayed to the end
user.
4. Click OK.
The published component entry appears in the upper right pane. To edit it, double-click
its name. To delete it, right-click its name and select Delete.
Tables Tab
The Tables tab lists every table in the Windows Installer database. Most of this data is
accessible in Installation Expert or in the other tabs of Setup Editor. The Tables tab lets
you edit existing table data, add new data, add new tables, and delete tables.
In addition to standard Windows Installer tables, the Tables tab also lists Wise tables,
which are described in About Wise Tables on page 403.
Reasons to Edit Tables Directly

z To use the few features, such as ReserveCost, that are not available anywhere but
on the Tables tab.
z To add a table to store data that is non-Windows Installer standard. Example: If you
create a custom action that stores data, you must create a new table in which to

Setup Editor
store it. Or you might write a .DLL that reads the new table and performs certain
actions.
z To edit the data created in Installation Expert or on the other tabs of Setup Editor.
Caution
Working With Tables

Key field. Table headings.
Column
information
List of tables in
the Windows
Installer
database. Table contents.
(Lower right pane

not available in the
Visual Studio
integrated editor.)
By default, the left pane of the Tables tab lists all the tables in the Windows Installer
database, even those that don’t contain data.
z To hide empty tables, right-click in the left pane and select Show Empty Tables. To
redisplay the empty tables, right-click and select Show Empty Tables again.
z To display a table’s contents, click its name in the left pane. The table’s contents
appear in the upper right pane, arranged in columns by field. The column width and
sort order are retained when you leave the Tables tab.
The top heading row of the table displays field names. Key fields are indicated by a
key symbol. By convention, database columns that are external keys take the name
of the primary key column with an added underscore character. Example: An
external key to the File column of the File table is always named File_.
z An optional, second heading row shows the field’s data type, string length if
applicable, and whether the field can be null. To display or hide the second heading
row, right-click the table and select Column Info.
z Initially, tables are not sorted. To sort a table, click the heading for the column to
sort.

Setup Editor
z You can select rows in tables, then copy and paste them into any program that
supports SYLK format, such as Excel. You also can paste the rows into a text editor,
where they appear as comma-delimited text.
See:
Creating a New Table on page 399

Creating a New Row in a Table on page 400
Editing Existing Tables on page 400
Searching for Table Data on page 401
Finding Validation Errors on page 401
Editing Binary Data in the Icon Table on page 402
About Wise Tables on page 403
Creating a New Table

Caution
1. In Setup Editor > Tables tab, right-click and select Create Table.
The Create Table dialog appears.
2. In Table Name, enter the name of the new table.
3. Click Add to add a field.
The Field Definition dialog appears.
Field Name
Enter the name of the field.
Data Type
Specify whether this field is a long integer, short integer, or string.
String Length
If this field is a string, enter the length of the string in this field. The default is
255 characters; a length of 0 indicates no length limit.
Nullable
Mark this to indicate that this field can be null.
Primary Key
Mark this to indicate that this field is a primary key in this table. A table can
have more than one primary field.
Localizable
Mark this to indicate that this field should be translatable. If you distribute this
installation in another language, the data in this field will be translated.
Value Range Min/Value Range Max

Enter minimum and maximum allowed values for an integer field. These fields
are available only when the data type is a long or short integer.

Setup Editor
Value Set
Enter a list of acceptable values for this field, separated by semicolons.
Key Table
Select the table to which this column is linked. Example: The SelfReg table has
a column File_ that is linked to the File table.
Key Column
Select the column in the linked table. Example: The SelfReg table File_ column
is linked to the File column in the File table.
Category
Select the type of information stored in this column.
Description
Enter a short text description of the information stored in this column.
5. Click OK on the Field Definition dialog.
6. Continue to add fields as needed.
7. On the Create Table dialog, click OK to add the table.
Also see:

Creating a New Row in a Table on page 400
Creating a New Row in a Table

Caution
When you add a row to a table this way, additional rows are not added to related tables.
Be sure you understand relational databases and Windows Installer database technology
before adding rows.
1. In Setup Editor > Tables, in the left pane, select a table.
2. In the upper right pane, right-click the row above which the new row should appear
and select New Row.
A message dialog appears.
3. Click OK. A new row is added to the table.
4. Click in each field to select it for entry. (If you click away from the row, you might
have to triple-click to access a field.)
Editing Existing Tables

On the Tables tab, you can directly edit any data in the Windows Installer database. You
also can delete rows from tables and delete tables.
Caution

Setup Editor
To edit table data:

1. In Setup Editor > Tables tab, in the left pane, select a table.
2. In the upper right pane, do one of the following:
Click the field to change and press Enter or F2.
If a field is already active, press Tab to move from left to right or Shift+Tab to
move from right to left within the table.
3. Type new data or change the existing data.
Some table columns have drop-down lists that you can use for editing. Example: The
drop-down list for the Feature_Parent column in the Feature table lets you select a new
parent for the current feature. Drop-down lists for columns that contain formatted data
type show the properties from the Property table. You can either select from the list or
enter a new property.
To delete a row from a table:

In Setup Editor > Tables tab, in the upper right pane, right-click a row and select Delete.
To delete a table:
1. In Setup Editor > Tables tab, in the left pane, right-click a table and select Delete
Table.
2. Click Yes on the warning dialog that appears.
If you later add an item that requires the deleted table, Wise for Windows Installer
automatically recreates the table.
Searching for Table Data

On the Tables tab, you can search for and replace strings. Search the entire database, a
single table, or a single column. (In the Visual Studio integrated editor, you cannot
choose where to search, because the standard Visual Studio Find dialog is used.)
Example: The product name changes and you need to find and replace it everywhere it
occurs.
Find and Replace commands are in the Edit menu.
Also see:
Finding Validation Errors on page 401

Finding Text in MSI Script on page 471
Assigning a Component to a Feature on page 387
Finding Validation Errors

On the Tables tab, you can search for tables that contain errors and you can search for
individual validation errors. These are quick ways to search for validation errors while
you are working on a package.
A validation error occurs when the data in a field does not comply with the requirements
assigned to the field. Examples: null fields in columns that are not nullable, foreign key
mismatches, and strings that are too long for the field.

Setup Editor
Alternatively, when a project is complete and all changes are saved, you can run the
Package Validation tool to check the entire package against a set of rules, such as the
Windows Installer SDK Internal Consistency rules.
To find tables that contain errors:

In Setup Editor > Tables tab, right-click the left pane and select Check Tables.
The installation is searched for tables that contain errors. Any table that contains an
error is shown in red in the left pane and the error becomes a task in the Task List.
You can use the Task List to review the errors (see Using the Task List on page 26) or
you can click a red table name and use the Find Error menu item to find the row that
contains the error. See the following procedure.
To find individual validation errors in a database:

1. In Setup Editor > Tables tab, right-click and select Find Error.
The Find dialog appears.
2. In the Direction section, mark either Up or Down to specify the search direction.
3. Click Find Next.
If the database contains one or more validation errors, the first one is highlighted in
red in the upper right pane.
4. To find the next error, click Find Next again.
To find validation errors in a package:

z Select Tools menu > Package Validation.
Package Validation appears. See Validating a Package on page 370.
When validation is complete, the View / Correct dialog appears. It lists validation
issues that represent areas where the package might not comply with the
specifications in the validation modules you selected. The icon to the left of each
issue indicates the issue type. When you close Package Validation, validation errors
that were not corrected are added to the Task List.
Also see:

Searching for Table Data on page 401
Editing Binary Data in the Icon Table

On the Tables tab, you can edit binary data in the Icon table. Most items in this table are
graphics (example: shortcut icons). You can export binary files for editing and then
import them back into the installation. Exported binary files are formatted as Windows
bitmaps.
The Binary table also contains binary data. To edit binary data in the Binary table, use
the Resources page. See Managing Binary Resources on page 109.

Setup Editor
Caution
To edit binary data:

1. In Setup Editor > Tables tab, click the Icon table.
The table’s data appears in the upper right pane. You can change the data in the
Name fields as you would in any other table.
2. In the Data column, click a binary field (displayed as {binary data}) and press F2 or
Enter.
The Edit Binary Data dialog appears.
3. In the Action section, mark an option:
Read binary data from file

Import binary data from an external file.
Write binary data to file

Export binary data to an external file so it can be edited.
4. In File Name, do one of the following:
If you are reading from an external file, specify the full pathname of a file to
read.
If you are writing to a file, enter the full pathname of the file. By default, this
file is exported to the directory where the Windows Installer database file is
stored. To export to a different directory, specify a full path, such as
C:\TEMP\FILENAME.
5. Click OK.
About Wise Tables

Wise tables contain information related to items you’ve added in Wise for Windows
Installer. These tables are included in a .WSI file only, unless you use an .MSI file as the
project file. When you compile, these tables are not included in the resulting .MSI.
Caution
z WiseAdvertising. Contains the advertising information you select in the Compiler

Options section of the Component Details dialog.
z WiseCommandLine. Contains the information that is used on the Command Line

page.

Setup Editor
z WiseComPlusApp. Contains a list of MTS/COM+ applications that are in the

installation.
z WiseComPlusComponent. Contains information relating to MTS/COM+

applications that are in the installation.
z WiseDlgSequence. Contains information about the sequence and display

conditions of wizard dialogs.
z WiseFeatureCondition. Contains a list of the conditions you have added to

features on the Installation Expert’s Features page.
z WiseFileAttributes. Contains bit fields associated with a file that is a part of an

installation.
z WiseInstanceTransforms. Contains information about instance transforms that

are defined in Installation Expert > Instance Transforms page.
z WiseLangString. Contains all strings for all languages currently defined in the
installation.
z WiseLanguage. Contains a list of all languages defined for the installation, along
with the corresponding releases.
z WiseMediaOptions. Contains a list of values for development environment display

purposes.
z WiseMetaDataCache. Contains user-defined meta data after values for the meta
data are entered on the Product Details page.
z WiseMobileDevice. Contains a list of all mobile device applications, a description

of each, and appropriate attributes.
z WiseMobileDeviceDesktopFiles. This is added only when you add a Palm

application to the Mobile Devices page. It describes the files in the file table that are
mobile device files.
z WiseModuleConfiguration. Contains the information that configurable merge

modules use during the merge process.
z WiseModuleSignature. Contains a list of merge modules that are in the

installation project file.
z WisePageLists. Contains information on the page groups of the page view

associated with the installation.
z WisePathReplacement. This table, in combination with Wise custom actions,

enables conversion of registry path values that contain long file names or trailing
backslashes.
z WisePathVariable. Contains paths defined on the Path Variables page.
z WisePocketPCFile. Contains information about each file for a Pocket PC

application.
z WisePocketPCPlatform. Contains information about each platform that the user

selects on the Support Platform dialog for a Pocket PC application.
z WisePocketPCRegistry. Contains information about each Pocket PC registry key

and all of its attributes.
z WisePocketPCShortcut. Contains information about each Pocket PC shortcut and

all of its attributes.

Setup Editor
z WisePrerequisites. Contains information on prerequisites that are added to the

installation on the Prerequisites page.
z WiseRelease. Contains a list of all releases in the installation.
z WiseReleaseExclude. Contains a list of features and components you’ve

deselected for a particular release.
z WiseReleaseMedia. Contains a list of all media for each release.
z WiseReleaseMediaDest. Contains a list of all destination directories for each

media within each release.
z WiseReleaseMediaInclude. Contains a list of all features and components

included in a particular media.
z WiseReleaseOverride. Contains a list of properties and summary items you’ve

overridden for a specific release on the Release Settings page.
z WiseSequence. Contains the remarks used in MSI Script as well as any empty If/
End If blocks.
z WiseSourcePath. Contains a list of all source paths for all files that are in the
installation.
z WiseStreamFiles. Contains a list of all source path names for custom actions and
graphics that are in the installation.
z WiseTaskList. (Wise editor, Enterprise edition only.) Contains a list of user-defined

tasks that are in the installation.
z WiseVDAttributes. Stores the Web Dialogs settings for the virtual directories on
the Web Files page.
z WiseVersionInfo. (Enterprise edition only.) This table is populated when a

Windows Installer installation is imported in Software Manager. It contains version
information that speeds future subscriptions and imports of the installation.
z WiseVirtualDirectory. Stores the settings you chose for virtual directories and
Web folders you created on the Web Files page.
z WiseVSOutput. (Visual Studio integrated editor only.) Contains a list of project

outputs and their settings.
z WiseVSOutputGroup. (Visual Studio integrated editor only.) Contains a list of

output groups for each solution.
z WiseVSProject. (Visual Studio integrated editor only.) Contains a list of projects in

the solution and their settings.
z WiseWebSiteAttributes. Stores the Web Dialogs settings for Web sites you
created on the Web Files page.
z WiseWebSites. Stores the settings you chose for Web sites you created on the
Web Files page.
z WiseWildcard. Contains an entry for each time you add a wildcard in Installation
Expert > Files page and mark the Update installation as files are added or
removed from source directory checkbox.
z WiseWildcardFile. Contains a list of files that were originally added via a wildcard,
and were later deleted because they no longer exist. File information is stored so
that if and when a file is re-added, crucial information about the file is retained.

Setup Editor

Chapter 18
Using Conditions and Properties
Conditions and properties are integral parts of any complex installation. To do advanced
customization of an installation, you’ll probably need to use conditions and properties.
Topics include:
z Conditions.
z Where Can You Use Conditions?
z Condition Guidelines and Examples of Conditions.
z Creating Conditions With Condition Builder.
z Properties.
z How Do You Use Properties?
z Creating a New Property.
z About Build Properties, INI File Properties, and Runtime Properties.
Conditions
Conditions are like expressions: they evaluate to a true or false value. You associate
conditions with different elements of an installation such as features, components,
actions, dialogs, and dialog controls to determine whether something happens or not.
Based on whether the condition is true or not, you can determine whether to:
z Allow the installation to continue.
z Install certain features and components.
z Display certain dialogs or dialog controls.
z Execute custom actions you add in MSI Script.
When you create a new installation, conditions are already created throughout the
installation where appropriate.
You often use properties inside conditions. Properties are named values that are any of
the following:
z Predefined in Wise for Windows Installer.
z Defined by Windows Installer, by you in the installation file, or by the end user
z Based on the system configuration of the destination computer.
See Properties on page 415.
Also see:
Where Can You Use Conditions? on page 408

Condition Guidelines on page 409

Examples of Conditions on page 410

WiseFixConditions on page 411
Creating Conditions With Condition Builder on page 411
Where Can You Use Conditions?

Conditions on the Features Page
You can add conditions on the Features page. These conditions appear in the Current
Feature drop-down list that appears at the top of pages in the Feature Details page
group. Using the Current Feature drop-down list, you can add system changes to a
condition or feature. These changes can include adding files, registry entries, services,
and ODBC. Items that you add to a feature are installed on the destination computer
only if the feature is installed. Items that you add to a condition are installed only if the
feature is installed and the condition is true.
See Using Conditions With Features on page 108.
Conditions for Actions

You can set conditions on the actions in MSI Script by using If Statements. MSI Script
contains standard Windows Installer actions, dialogs, and custom actions. In general,
you should not set or change conditions for standard actions, but you’ll probably set
conditions for any custom actions or dialogs you create. See Using MSI Script on
page 466 and Guidelines for Custom Action Conditions on page 480.
Launch Conditions
Launch conditions are system requirements that must be met for the installation to
proceed. You set launch conditions in the Launch Conditions icon in Setup Editor >
Product tab. When you set system requirements on the System Requirements page,
they are added to the Launch Conditions icon.
Example of a a possible launch condition:
ScreenX >= 800 AND ScreenY >= 600
This condition specifies that the screen resolution must be 800 x 600 in order for the
installation to proceed.
ScreenX and ScreenY are Windows Installer properties that are set according to the
screen resolution on the destination computer. See ScreenX Property and ScreenY
Property in the Windows Installer SDK Help.
Conditions for Controls on Dialogs

In Setup Editor > Dialogs tab, you can use conditions with dialog controls. Controls are
the items that appear on dialogs, such as text boxes, radio buttons and checkboxes.
Because many conditions are already set on the default installation dialogs, you can use
those for examples of how you might use conditions in dialogs. View them in Setup
Editor > Dialogs tab.
z Conditions that set the state of controls

You can create a condition that sets a control to be enabled, disabled, shown,
hidden, or set as the default control.
Example: If you double-click the Next button on the License Dialog in Setup Editor >
Dialogs tab, then on the Conditions tab on the Properties dialog you see 3 conditions
attached to the Next button. These conditions determine the state of the Next

button. They are all based on the value of a property named Accept. The Accept
property is set to “Yes” when the end user clicks the I accept the license
agreement radio button. As soon as Accept equals “Yes”, the Next button becomes
enabled and set to the default control. (To see how the Accept property is set,
double-click the radio buttons on the License Dialog, then look at the Items tab on
the Properties dialog.)
z Conditions attached to control events

You can attach an event to a control. The event can have an associated condition.
You might attach events to Next buttons that specify what event happens if the Next
button is clicked.
Example: Click the Installation Type Dialog in Setup Editor > Dialogs tab. Double-
click the Next button and click the Events tab on the Properties dialog. Depending
on what the property InstallMode is set to, different dialogs appear, as specified in
the NewDialog events. If the end user selects the Custom radio button, InstallMode
is set to Custom, and the Select Feature Dialog appears. If the end user does not
select the Custom radio button, the Start Installation Dialog appears. The value of
the InstallMode property is determined by the end user’s radio button choice.
Conditions Attached to Components

You can attach conditions to components in Setup Editor > Components tab. (You can
also add them to components on the Features tab.) If you attach a condition to a
component, the component is installed only if the condition is true. To add or change a
condition attached to a component, right-click a component icon and select Details. Use
the Condition field on the Component Details dialog that appears to add or change a
condition.
If you add conditions to the Features page, and add items to the conditions using the
Current Feature drop-down list at the top of Installation Expert pages, then some of
the components on the Components tab will have conditions set.
Note
If you add a component condition that checks the installed state of a component or
feature, add the merge module CondFix.msm to the installation. This merge module
fixes a Windows Installer limitation; see WiseFixConditions on page 411.
Condition Guidelines
Before creating conditions, become familiar with the following Windows Installer
guidelines for creating conditions.
z You can use the following types of values inside a condition:
The name of the property. This is case-sensitive. You do not need to enclose the
property name in square brackets. See Using Properties in Conditional
Statements in the Windows Installer SDK Help.
Any integer between -32,767 and 32,767. You cannot use floating point values.
String literal. Enclose text in quotation marks. Example: “Windows NT 4.0”.

Properties that have not been set evaluate to an empty string “” (null).
Environment variable. Precede the variable name with a percent symbol (%).
z If a property is set, it evaluates to true in a Boolean expression.

Example: If the installation runs on a destination computer whose operating system

is Windows NT, 2000, XP, or Server 2003, the property VersionNT is set to the
version number of the operating system. However, if you want to set a condition to
check for these operating systems, you can enter the condition as VersionNT. If
VersionNT is set to anything at all, even 0, the condition evaluates to true.
z When adding conditions to the Launch Conditions icon, you can add conditions that
check properties or environment variables, but you cannot add conditions that check
the installed state of a component or feature.
z You might need to include the merge module CondFix.msm, that fixes certain
Windows Installer limitations related to component conditions. See
WiseFixConditions on page 411.
z Property names and values, by default, are case-sensitive. To make them case-
insensitive, precede the operator with ~= instead of =.
Example: If you enter the condition REMOVE=ALL but the value of the REMOVE
property is currently “All” (with upper- and lowercase), the condition is false. To
write the condition so that it is case-insensitive, type the condition as follows:
REMOVE~=”All”
z Environment variable names are not case-sensitive.
z Non-existent property values are treated as empty strings and evaluate to false.
z Operators and precedence are the same as in the BASIC and SQL languages, but
you can override precedence with parentheses.
z Arithmetic operators and floating point numeric values are not supported.
For details, see Conditional Statement Syntax in the Windows Installer SDK Help.
Examples of Conditions
You can build conditions using property names, environment variables, and feature and
component states. Conditions can contain both Windows Installer properties and
properties that you create. A complete list of Windows Installer properties is available in
Property Reference in the Windows Installer SDK Help.
Condition The Condition Is True If

SystemLanguageID=1033 The installation is running on a computer whose
language is set to English.
REMOVE~=”ALL” The product is being uninstalled. The ~ makes the
condition case-insensitive.
NOT Installed The product is being installed for the first time.
CHECKBOX_IS_MARKED You make a checkbox and associate the property
CHECKBOX_IS_MARKED with it, and during
installation, the end user marks the checkbox.
VersionNT The installation is running on Windows NT 4, 2000,
XP, or Server 2003.
Version9X AND NOT Installed The installation is running on Windows 95, 98, or
Me, and the application is not yet installed.

WiseFixConditions
Wise for Windows Installer contains a special merge module, WiseFixConditions
(CondFix.msm), that fixes certain Windows Installer limitations:
Add CondFix.msm to an installation if:
z You add a component condition that checks the installed state of a component or
feature.
z (Windows 9x installations only.) You create a component condition based on a

property that is set during the UI Sequence. Example: The end user can set a
property by marking a checkbox or entering text in an installation dialog.
The Wise for Windows Installer installation places CondFix.msm in the default merge
modules directory, or you can download it with the Download Redistributables wizard.
See Downloading Redistributable Files on page 35. This merge module appears on the
Select Merge Module dialog when you add a merge module on the Merge Modules page.
If you don’t see it, you’ve marked the Do not show merge modules from the
Default Merge Module Directory checkbox in Wise Options. See Setting Merge
Module Directories on page 48.
Also see: Using Conditions With Features on page 108
Creating Conditions With Condition Builder

Use the Condition Builder dialog to build conditions that test the installed state of
components and features and the value of properties and environment variables. You
can access the Condition Builder dialog from different areas of Wise for Windows
Installer. See Where Can You Use Conditions? on page 408.
Scrolling text
box. Enter or
build conditions
here.
Click to check the

syntax of
conditional
statements.
Operator
buttons
Mark Ignore Case
to make conditions
case-insensitive.
This inserts a ~
when you click a
comparative
operator button.
Lists

Operator Buttons
Most of the operator buttons in the middle of the dialog, starting with the = button, are
described in Conditional Statement Syntax in the Windows Installer SDK Help. They
include logical, comparative, string, and bitwise operators.
z Use the ~ button before an operator to make the condition case-insensitive.
z Use the () buttons to enclose parts of the condition, which changes the order of
precedence.
z Use the " button to enclose literal text.
Lists
z Fields
Select the kind of item the condition checks. You can check the installed state for
features and components, and you can check the value of properties and
environment variables.
z Values
If you selected Environment Variable or Property in the Fields list, double-click the
name of an environment variable or a property to insert it into a condition. See
Checking the Value of a Property on page 412 or Checking the Value of an
Environment Variable on page 413.
Note
The following 2 lists let you check the current or future installed state of a feature or
component. The procedures for using these are described in Checking If and How a
Feature or Component is Currently Installed on page 414 and Checking If and How a
Feature or Component Will Be Installed by This Installation on page 414.
z State
Use this list only to check the installed state of a component or feature. Action
refers to what occurs during installation, and Installed refers to the current state of
the destination computer.
z Install/Action state
Use this list only to check the installed state of a component or feature. Absent
means the feature or component is not installed, Advertised means it is
advertised, Local means it is installed on the local hard drive, and Source means it
is installed to run from the installation source.
Also see:
Condition Guidelines on page 409

Examples of Conditions on page 410
Checking the Value of a Property

To check whether a property evaluates to true:
You do not need to use the Condition Builder dialog. Enter the name of the property in
the Condition field. Example: To create a condition that checks whether Windows NT,
2000, XP, or Server 2003 is running, you enter the condition, VersionNT, which evaluates
to true when VersionNT is set.

To check whether the property equals a certain value:

1. Access the Condition Builder dialog. See Creating Conditions With Condition Builder
on page 411.
2. In the Fields list, click the Property folder.
The Values list displays a list of properties and directories that are initialized by this
installation. More properties appear than in other lists of properties, such as the
Properties icon in Setup Editor > Product tab. It includes Windows Installer
properties that are set at runtime based on system configuration, such as ScreenX
and ScreenY. For information on Windows Installer properties, see Property
Reference in the Windows Installer SDK Help.
3. In the Values list, double-click the name of the property.
If the property you want does not appear in this list, enter the property name in the
condition list box at the top of the Condition Builder dialog.
4. Click the = button.
An equals sign is inserted in the condition list box.
5. Click in the condition list box after the equals sign and enter a value.
6. Click OK.
Checking the Value of an Environment Variable

Environment variables are system or end user variables that are set by the operating
system running on the destination computer. They contain values specific to that
computer.
Note
This procedure lets you check the value of an environment variable. To read the value of
an environment variable into a property, use the Set Property type of custom action.
Enter [%ENVIRONMENT_VARIABLE_NAME] in the Property Value field on the Custom
Action Target dialog while making the action (brackets required).
on page 411.
2. In the Fields list, click the Environment Variable folder.
The Values list displays the environment variables that currently exist on your
computer. If the environment variable you want is not in the list, enter its name in
the condition list box at the top of the Condition Builder dialog. For information on
available environment variables, consult Microsoft Windows developer
documentation.
3. In the Values list, double-click the name of the environment variable.
5. Click in the condition list box after the equals sign and enter a value.
6. Click OK.

Checking If and How a Feature or Component is

Currently Installed
A feature or component might be installed to run locally, from the source, or advertised,
which are all options you can set when installing a component or feature.
Note
You cannot add this type of condition to the Launch Conditions icon in Setup Editor >
Product tab. Also, when you add this type of condition, add the merge module
CondFix.msm to the installation. This merge module fixes a Windows Installer limitation.
For details, see WiseFixConditions on page 411.
on page 411.
2. In the Fields list, click the Feature or Component folder.
3. In the Values list, click the name of the feature or component.
4. In the State list, double-click Installed.
6. In the Install/Action state list, double-click one of the following to check the
current installation state of the feature or condition:
Absent
Not installed.
Advertised
Installed in an advertised state.
Local
Installed locally.
Source
Installed to run from installation source.
When you finish, a condition appears in the condition list box. Based on the choices
you make, the appropriate Windows Installer codes are inserted. Example:
!Complete = 3
7. Click OK.
Checking If and How a Feature or Component Will

Be Installed by This Installation
A feature or component might be installed to run locally, from the source, or advertised,
which are all options you can set when installing a component or feature.
Note
You cannot add this type of condition to the Launch Conditions icon in Setup Editor >
Product tab. Also, when you add this type of condition, add the merge module
CondFix.msm to the installation. This merge module fixes a Windows Installer limitation.
For details, see WiseFixConditions on page 411.
on page 411.

2. In the Fields list, click the Feature or Component folder.
3. In the Values list, click the name of the feature or component.
4. In the State list, double-click Action.
6. In the Install/Action state list, double-click one of the following to check the
action state of the feature or condition:
Absent
Will not be installed by this installation.
Advertised
Will be installed in an advertised state.
Local
Will be installed locally by this installation.
Source
Will be installed to run from installation source by this installation.
When you finish, a condition appears in the condition list box. Based on the choices
you make, the appropriate Windows Installer codes are inserted. Example:
&Complete = 3
7. Click OK.
Properties
Properties are variables used by Windows Installer during installation. You often use
properties inside conditions. You can hard-code the value of a property, but you can also
make properties more flexible by manipulating them during runtime based on user
input, system configuration, or other situations.
Properties are set by the following methods and in the following order:
z Included in the installation database

Some properties are included in all installations you create in Wise for Windows
Installer. These include required Windows Installer properties, properties that are
used on the installation dialogs, predefined Wise properties, and the directories
listed in the Directory table on the Tables tab in Setup Editor. You can see these
properties by clicking the Properties icon in Setup Editor > Product tab. See Build
Properties on page 418 for descriptions of each.
z Created by you in the installation database

You can create properties in the Properties icon in Setup Editor > Product tab. Also,
some dialogs that contain a property drop-down list also contain a New button with
which you can create a new property. See Creating a New Property on page 417.
z On the command line

Properties can be set on the command line. See Command Line Options For
WFWI.EXE on page 217.
z Set by Windows Installer at runtime

Some properties are set by Windows Installer according to the configuration of the
destination computer. See Property Reference in the Windows Installer SDK Help for
a complete list.

z By end user input

You can author the user interface so that end user input sets property values.
Example: You can associate a property name with a dialog control. The results of
the end user’s action on the dialog control are put into the property.
Because each method of setting properties can be overridden by the methods that come
after it, property values might change during installation. In the Professional and
Enterprise Editions, you can see the value of properties during installation in the
Properties pane of Debugger for Windows Installer, which appears when you click the
Debug button. (In Visual Studio: select Debug menu > Start.)
Properties that are authored into the installation database’s Property table, which
appear in the Properties icon in Setup Editor > Product tab, represent initial values of
properties. Changing the Properties table after installation begins has no effect on the
values of properties that are stored in memory. During installation, properties can be
changed only by actions that are running in immediate execution mode. User interface
actions are in immediate execution mode, and you can set your custom actions to run in
immediate execution mode.
Also see:
How Do You Use Properties? on page 416

Creating a New Property on page 417
INI File Properties on page 422
Runtime Properties on page 424
How Do You Use Properties?

You can use properties in the following ways:
To interact with the user

You can attach properties to controls on dialogs, which puts the results of the control
into the property. Then, use the property in a condition.
Example: In Setup Editor > Dialogs tab, the Installation Type Dialog has a set of radio
buttons. The radio buttons are associated with a property named InstallMode, and based
on the value of InstallMode, the Next button displays a different dialog. Double-click the
radio buttons and the Next button, to view their Properties dialogs. See About Dialog
Controls on page 438.
In conditions
You can use properties inside conditions. You do not need to enclose the property name
in brackets. Conditions determine whether something happens or not.
As formatted text on dialogs

To display the value of a property or write the value of a property to a file, you must
enclose the property name in square brackets. Example: [Property].
Example: In Setup Editor > Dialogs tab, right-click a dialog name, and select Details.
The Dialog Details dialog appears with [ProductName] [_WiseDialogSuffix] in the Dialog
Title.
To display a bracket, you must enclose it in square brackets. Example: [[].

To change the way the installation is run

You can set properties that change the way Windows Installer runs. Example: To force or
suppress a reboot at the end of installation, you could create a Set Property custom
action that sets the Windows Installer property named REBOOT.
Creating a New Property

Note
Before you create a new property, search the Windows Installer SDK Help to make sure
the property name is not already used by Windows Installer. See Property Reference in
1. In Setup Editor > Product tab, right-click the Properties icon and select New >
Property.
The Property Details dialog appears.
Name
Enter a name for the property. Properties can contain only letters, numbers,
underscores, and periods and must begin with a letter or underscore.
A public property name consists of all uppercase letters. The value of public
properties can be passed from the UI Sequence to the Execute Sequence. In
most cases, barring security issues, you should designate properties as public
properties. See Public Properties in the Windows Installer SDK Help. A private
property name includes lowercase letters. See Private Properties in the
Value
Enter an initial value for the property.
According to Windows Installer guidelines, you should always enter an initial

value. However, in some cases you might not want to. Example: If the property
is associated with a checkbox, and you want the checkbox to appear unchecked
initially.
Note
You cannot enter other properties to set the value of a new property because
text you enter is interpreted literally. This is not true for some specific Windows
Installer properties, such as DiskPrompt and PrimaryFolder. To set a property to
the value or values of other properties, use the Set Property custom action. See
Set Property on page 514.
Hidden property
Mark this to designate this property as hidden. This Windows Installer 2.0
feature prevents the property’s value from being written to the installation log
file. Use this for properties that contain information, such as serial numbers or
passwords, that you don’t want end users to see.
Add to the list of restricted public properties

Mark this to designate this property as a restricted public property. Do this if the
installation is to be performed on locked-down Windows NT, 2000, XP, or Server
2003 computers and you want the ability to change and pass its value from the
UI Sequence to the Execute Sequence. See Restricted Public Properties in the

Windows Installer SDK Help. This is disabled if you entered any lowercase
letters in the name.
3. Click OK.
The property is added to the list of properties initialized by this installation.
You can also create a new property from any dialog in the product that has a Property
drop-down list with a New button next to it.
To edit a property, double-click its name under the Properties icon in Setup Editor >
Product tab.
Caution
You can edit and delete properties, but many of the properties you see in the Properties
icon are Windows Installer properties. You should be proficient in the Windows Installer
development environment before you edit or delete Windows Installer properties. If you
change the name of a property, make sure you update any dialog controls or conditions
that reference the property name.
Build Properties
Properties defined by settings in an installation at build time are listed below. Some of
them, such as INSTALLLEVEL, can be changed at runtime from the command line or
during the Action Sequence. You can also create new properties for your own use. See
Creating a New Property on page 417.
On the Build Options page, you can configure an installation to create an .EXE that
launches an .MSI. Then the installation includes an .INI file that contains settings
necessary for the installation to run. Some of the build properties below determine the
default value of some of the properties in the .INI file. In that case, the property
description includes the name of the corresponding property in the .INI file.
Property Name Description

_WiseDebugMode By default, debug mode is off. Set this property to 1 to debug .DLLs that you
added to an installation using a custom action. For this feature to work, the
Custom Action Type for the action must be Call DLL with Variable
Parameter List and you must have the Microsoft Visual C++ development
environment installed. The debugger opens at a breakpoint just before your
.DLL code begins, so at first you might see assembly code. If so, single-step
ahead to see your .DLL code.
_WiseDialogFontDefault Contains the text style used for body text on wizard dialogs. When you add a
control, set its font to this font, otherwise the font specified in DefaultUIFont
is used. The font choices for this property are listed in the TextStyle table
located on the Tables tab.
_WiseDialogSuffix Contains the text that’s appended to the name of the application
(ProductName) in the wizard dialog title bar.
_WiseDialogTitleFontDefault Contains the text style used for the titles on wizard dialogs. This is not for the
text in the title bar itself, but for the text inside the wizard that introduces the
dialog content. The font choices for this property are listed in the TextStyle
table located on the Tables tab.


Accept Sets the initial value of the radio button on the License Dialog. The default
value, “No”, causes the I do not accept the license agreement radio
button to be marked by default. The Next button on the License Dialog has an
event attached to it, which causes the Next button to be disabled until the
end user marks I accept the license agreement radio button.
ApplicationUsers Sets the initial value of the radio button on the User Information dialog. The
default value, “AllUsers”, causes the Anyone who uses this computer radio
button to be marked by default. The Next button on the User Information
dialog has an event attached to it, which causes the Windows Installer
property ALLUSERS to be set to true if the end user leaves the Anyone who
uses this computer radio button marked.
APPS_TEST Provides backwards compatibility for the System Search page for installations
created in Wise for Windows Installer 2.0.
DefaultUIFont Contains the text style used for the installation user interface if no other
value is set. To match the default dialog text that already exists, set any new
controls you add to _WiseDialogFontDefault. The font choices for this
property are listed in the TextStyle table located on the Tables tab.
DiskPrompt Contains the default text that prompts the end user to insert the next
installation disk.
ErrorDialog Contains the name of the dialog that should be displayed if there are
installation errors.
IISVERSION If you add Web resources to an installation, this property is set during
runtime to the version of Microsoft Internet Information Server that is
running on the destination computer. If IIS is not installed, this property
remains empty during installation.
INSTALLDIR This is the main installation directory for the application. By default,
INSTALLDIR is set to the first directory you create under the Program Files
folder on the Files or Web Files page. On the Destination Folder dialog during
installation, the end user can change this directory. The Windows Installer
property PRIMARYFOLDER is set to the value of INSTALLDIR before
installation of files begins.
INSTALLLEVEL All features that have install levels less than or equal to this number are
installed. See the description of the Level field in Configuring a Feature Using
the Feature Details Dialog on page 105. This value is set by events attached
to the Next button on the Installation Type Dialog.
InstallMode Sets the initial value of the radio button on the Installation Type Dialog. The
default value, “Typical”, causes the Typical radio button to be marked by
default. The Next button on the License Dialog has an event attached to it,
which sets the value of the Windows Installer property INSTALLLEVEL.
INSTALLLEVEL determines which features are installed.
MaintenanceMode Sets the initial value of the radio button on the Maintenance Welcome Dialog.
The default value, “Modify”, causes the Modify radio button to be marked by
default. The Next button on the Maintenance Welcome Dialog has events
attached to it, which cause different dialogs to appear based on the radio
button that is marked.
Manufacturer Set this property to your company name.


PIDTemplate Determines what characters are valid for the Product ID field on the User
Information Dialog. For information on the types of text available, see
MaskedEdit Control in the Windows Installer SDK Help.
PRIMARYFOLDER Contains the installation directory. Always leave this property set to
INSTALLDIR.
ProductCode ProductCode is a GUID (global unique identifier) generated by Windows
Installer, that uniquely identifies this product. No product codes are alike. You
can generate a new product code on the Product Details page. Do not enter
new product codes, because they must be created according to a specific
algorithm.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the ProductCode property in the .INI file that’s generated.
See INI File Properties on page 422.
ProductID Contains the full product ID after the end user’s entry has been validated.
ProductLanguage Indicates the language for this product. See Language IDs on page 279.
ProductName Contains the name of the product, which is set on the Product Details page.
ProductVersion Contains the product version number, which is set on the Product Details
page.
default value for the ProductVersion property in the INI file that’s generated.
ReinstallFileOlderVersion Indicates the action to take when an older version of a file being installed
already exists. The default value of “o” means overwrite. This sets an option
in the ReinstallMode dialog.
ReinstallFileVersion Indicates the action to take when the same version of a file being installed
already exists. The default value of “o” means overwrite. This sets an option
on the ReinstallMode dialog.
ReinstallRepair Indicates the action to take when reinstalling or repairing a file. The default
value of “r” means repair. This sets an option on the ReinstallMode dialog.
SecureCustomProperties Contains a semicolon-delimited list of properties that are restricted public
properties.
UpgradeCode Contains the product code for a related group of products, one of which might
be an upgrade for another.
WiseCRLF Contains a carriage return/line feed. Use in editable text boxes to insert lines,
or in property definitions.
WiseInitAdminError Contains the text of the error message that appears if the Windows Installer
runtime needs to be installed but the current user does not have
administrator privileges, which are necessary to install it.
default value for the AdminError property in the .INI file that’s generated.


WiseInitCmdLine Contains the default command line that is passed to MSIEXEC, which is the
Windows Installer executable that runs the .MSI. The command line
statement should end with the /I command line switch. This property is
absent unless you create it.
default value for the CmdLine property in the .INI file that’s generated. See
INI File Properties on page 422.
WiseInitExistError Contains the error that is displayed if a previous version of the installation is
already installed on the destination computer.
default value for the ExistError property in the .INI file that’s generated. See
WiseInitLangDefault Contains the default language for the installation, which initially is English. It
can also contain the language ID, separated from the language name by a
comma. (Example: English, 1033). If the language of the destination
computer matches this ID, the installation runs without applying any
language transforms.
default value for the WiseInitLangDefault property in the .INI file that’s
generated. See INI File Properties on page 422.
WiseInitPrefix Contains the text that’s displayed before the “Wise Installation” text in the
installation’s initialization window. The initialization window is the small
window that appears before the installation wizard dialogs appear.
default value for the WiseInitPrefix property in the .INI file that’s generated.
WiseInitProductName Contains the text displayed in the title bar of the installation’s initialization
window. The initialization window is the small window that appears before the
installation wizard dialogs appear. This value overrides the value stored in the
ProductName property for the initialization window, to provide a shorter
name that fits in the window. This property is absent unless you create it.
default value for the ProductName property in the .INI file that’s generated.
WiseInitProgressText Enter the text that should display while the hourglass is being displayed
WiseInitSpaceError Contains the error text that is displayed if the destination computer does not
have enough free disk space to copy the .MSI database to its local disk drive.
default value for the SpaceError property in the .INI file that’s generated. See


WiseInitSuffix Contains the text that’s displayed after the “Wise Installation” text in the
installation’s initialization window. The initialization window is the small
window that appears before the installation wizard dialogs appear.
default value for the WiseInitSuffix property in the .INI file that’s generated.
WiseMaskedProperties Contains Windows Installer properties that can be set by the end user during
installation, and whose value will be masked.
WISEWEBSITES properties Caution
Do not edit any properties whose name begins with WISEWEBSITES. They
are set when you add Web resources to an installation and generate Web
dialogs. Changing these properties can result in unexpected behavior. Also,
when the Web dialogs are regenerated, any changes you make to these
properties will be lost.
Also see:
Runtime Properties on page 424

Properties on page 415
INI File Properties

On the Build Options page, you can configure each release in the Current Release
drop-down list to compile into an .EXE, an .MSI, or an .EXE that launches an .MSI. If you
compile an installation into an .EXE that launches an .MSI, then 3 files are generated
during compile: an .EXE, an .MSI, and an .INI. The values of certain build settings are
stored in the .INI file, which must be distributed along with the .EXE that launches the
.MSI. You can change these settings, thereby determining how the .MSI database is run.
The list below shows the properties that are stored in the [WiseInstaller] section of the
.INI file.
Some of the properties in the .INI file get their default values from the build properties
listed in Build Properties on page 418. See individual descriptions below to determine
which build property the .INI property takes its default from, if any.

AdminError Contains the text of the error message that appears if the Windows Installer
runtime needs to be installed but the current user does not have administrator
privileges, which are necessary to install it. Defaults to the value of the build
property named WiseInitAdminError. See Build Properties on page 418.
CharFont Contains the font that is used in the installation’s initialization window. The
initialization window is the small window that appears before the installation
wizard dialogs appear. This also affects any other initial dialogs that appear,
such as the language selection and password dialogs.


CharSet Contains the character set that is used in the installation’s initialization
window. Different languages have different character sets. The initialization
window is the small window that appears before the installation wizard dialogs
appear. This also affects any other initial dialogs that appear, such as the
language selection and password dialogs.
CharSize Contains the font size that is used in the installation’s initialization window.
The initialization window is the small window that appears before the
installation wizard dialogs appear. This also affects any other initial dialogs
that appear, such as the language selection and password dialogs.
CmdLine Contains the default command line that will be passed to MSIEXEC, which is
the Windows Installer executable that runs the .MSI. The command line
statement should end with the /I command line switch. This defaults to the
value of the build property named WiseInitCmdLine. See Build Properties on
page 418.
DelayReboot If this is set to 1, a reboot caused by pre-installation of the Windows Installer
runtime is delayed to the end of the installation. It is set to 1 if you mark the
Delay Windows Installer runtime reboot until after product
installation checkbox on the Prerequisites page.
ExistError Contains the error that is displayed if a previous version of the installation is
already installed on the destination computer. This defaults to the value of the
build property WiseInitExistError. See Build Properties on page 418.
InstMSI CmdLine Contains the default command line that is passed to InstMsi.exe, which is the
executable that installs Windows Installer. The default command line switches
are /q /r:i.
Languagex Contains the language name and ID from the Language Details dialog. The
.INI file contains one Language line for each language in the release, where x
is incremented for each language: Language1, Language2, and so on.
LanguageFilex Contains the name of the installation .MSI. The .INI file contains one
LanguageFile line for each language in the release, where x is incremented for
each language: LanguageFile1, LanguageFile2, and so on. This property
supports full URL addresses, so if you distribute this installation via the Web,
you can specify the address where the file resides.
ProductCode ProductCode is a GUID (global unique identifier) generated by Windows
Installer, that uniquely identifies this product. No product codes are alike. You
can generate a new product code on the Product Details page. Do not enter
new product codes, because they must be created according to a specific
algorithm. This is the same as the build property ProductCode.
ProductFile Contains the relative pathname to the .MSI that is being installed. You do not
need to change this unless you move the .MSI from its default location.
ProductName Text that displays in the title bar of the installation’s initialization window. The
initialization window is the small window that appears before the installation
wizard dialogs appear. This defaults to the value in the build property
WiseInitProductName. See Build Properties on page 418.
ProductVersion Contains the product version number, which you set on the Product Details
page. This defaults to the value of the build property named ProductVersion.
See Build Properties on page 418.


Remove Previous If this is set to 1, the end user is prompted to remove any previously installed
versions of the same application. It is set to 1 if you mark the Prompt to
remove previous version before installing checkbox on the Build Options
page. The message stored in the WiseInitExistError property displays.
Runtime9x Contains the relative pathname of the file that installs Windows Installer for
Windows 95/98. Do not change this property unless you change the location
of this file.
RuntimeNT Contains the relative pathname of the file that installs Windows Installer for
Windows NT, 2000, XP, or Server 2003. Do not change this property unless
you change the location of this file.
RuntimeVersion If an installation includes the Windows Installer runtime, this is the version of
the included Windows Installer. You set an installation to include the Windows
Installer runtime on the Prerequisites page.
SpaceError Contains the error text that is displayed if the destination computer does not
have enough free disk space to copy the .MSI database to its local disk drive.
This defaults to the value of the build property named WiseInitSpaceError. See
Build Properties on page 418.
TransformMSI The TransformMSI .INI value is used if the file referenced in the ProductFile
property is an .MST. In that case, the TransformMSI property contains the
relative pathname of the base .MSI for the .MST.
WiseInitLangDefault Contains the default installation language. This defaults to the value of the
build property named WiseInitLangDefault. See Build Properties on page 418.
WiseInitLangPrompt Text that displays on the dialog that prompts the end user for a language
during installation, which happens when you create a multiple-language
release. Defaults to the value of the WiseInitLangPrompt property in the
Property table.
WiseInitPrefix Text that displays before the “Wise Installation” text in the installation’s
initialization window. The initialization window is the small window that
appears before the installation wizard dialogs appear. This defaults to the
value in the build property WiseInitPrefix. See Build Properties on page 418.
WiseInitProgressText Enter the text that displays with the hourglass during installation.
WiseInitSuffix Text that displays after the “Wise Installation” text in the installations’s
initialization window. The initialization window is the small window that
appears before the installation wizard dialogs appear. This defaults to the
value in the build property WiseInitSuffix. See Build Properties on page 418.
Also see Properties on page 415.
Runtime Properties
The properties listed in Build Properties on page 418 represent properties that are
initialized by the installation. All build properties are also runtime properties. Windows
Installer sets additional properties at runtime that contain useful information you can
use in an installation. For definitions of all the properties Windows Installer sets at
runtime, see Property Reference in the Windows Installer SDK Help.

In Web Installations
(Professional and Enterprise Editions only.) When you add Web resources in Installation
Expert > Web Files page, certain properties are set by a custom action.
The following properties are provided so that you can grant the ASPNet account
permission to directories; see Setting Permissions for Files and Directories on page 132.

ASPNET_USER When the .NET Framework is installed, it creates a user account with limited
privileges to run ASP .NET applications. This property is populated with the
ASP account of either the latest version of .NET, or the version of .NET
checked for on the System Requirements page.
ASPNET1.0_USER This property is populated with the ASP account that was created by the 1.0
version of .NET.
ASPNET1.1_USER This property is populated with the ASP account that was created by the 1.1
version of .NET.
The following properties are provided so that you can perform operations based on how
and where the Web site or virtual directory is installed. (Example: Use these properties
to create shortcuts to a Web site or virtual directory.) In the following property names,
<VIRTDIR> and <WEBSITE> are populated from the PropertyRoot column of the
WiseVirtualDirectory table for the given Web site or virtual directory.

<VIRTDIR >_HOMEDIR Contains the physical home directory of the virtual directory.
<VIRTDIR>_BEGINURL Contains the beginning portion of the URL of the virtual directory.
<VIRTDIR>_URL Contains the URL of the virtual directory.
<WEBSITE>_BEGINURL Contains the beginning portion of the URL of the web site. Example: To create
a shortcut to a specific page in the Web site, use:
[<WEBSITE>_BEGINURL]file_name.html
<WEBSITE>_HOMEDIR Contains the physical home directory of the web site or virtual directory.
<WEBSITE>_INSTTYPE Contains the installation type of the web site or virtual directory (NEW, EXIST,
or VIRDIR).
<WEBSITE>_URL Contains the URL of the web site or virtual directory.
From the SQL Connection Dialog

When you add the SQL Connection dialog to an installation, the following property is set
by a custom action. This property is provided so that you can use it for the connection
string in Installation Expert > SQL Server Scripts page. See Setting SQL Connection
Strings on page 235 and Adding the SQL Connection Dialog to an Installation on
page 453.


WISE_SQL_CONN_STR This property is populated with the connection string that is created when the
end user completes the SQL Connection dialog.
Also see Properties on page 415.

Chapter 19
Working With Dialogs
You can select, edit, and rearrange dialogs that appear to the end user during
installation. This lets you determine the level of control the end user has over the
installation. You also can select the theme that controls the overall look of the
installation dialogs.
For most installations, the Dialogs page provides all the options that are needed for
selecting and editing dialogs. The Dialogs tab in Setup Editor contains advanced tools for
editing the appearance as well as the behavior and logic of installation dialogs.
Topics include:
z About Dialogs.
z Using the Dialogs Page.
z Changing the Theme of Dialogs.
z Using the Dialogs Tab.
z Editing Dialog Details.
z Creating a New Dialog.
z About Dialog Controls.
z About Billboards.
z Obtaining Logon Information From a Dialog.
z About the SQL Connection Dialog.
z Adding the Custom Property Dialog.
About Dialogs
You can access dialogs from:
z Dialogs page (in Installation Expert)

The dialogs on the Dialogs page are those in the Welcome Dialog Wizard, which
appear to the end user during a normal installation. Turn the dialogs on or off,
rearrange them, view conditions, and select the dialog theme. Click the Dialog
Editor button to display a dialog on the Dialogs tab.
z Dialogs tab (in Setup Editor)

Edit any dialogs in the installation and create new dialogs.
z Display Dialog actions (in MSI Script)

View dialog sequences as they are ordered in the installation sequences, as well as
the conditions under which the dialogs display. The conditions are within If
statements surrounding the Display Dialog actions. One Display Dialog action
represents an entire dialog sequence. Example: Welcome_Dialog in MSI Script
represents the entire Welcome Dialog Wizard, as shown on the Dialogs tab. In MSI

Script, if you double-click the script line for Welcome_Dialog, the first dialog of the
Welcome Dialog Wizard displays on the Dialogs tab.
The Dialogs tab shows all dialogs that are part of an .MSI. Any of these dialogs can
appear in different situations:
Install Dialogs
The Install Dialogs appear during a normal installation, if no command line options are
used to run an advertisement, administrative, or silent installation.
Maintenance Dialogs
The Maintenance Dialogs appear when the installation is run in maintenance mode, that
is, when it is run after the application is installed. Maintenance mode lets the end user
change, repair, or uninstall the application.
Admin Dialogs
The Admin Dialogs appear during an administration installation. An administrative
installation copies a source image of the application to a network, for later installation by
end users.
To run an administrative installation, use the command line option /a. See About
Installation Modes on page 468.
Also see:
About Installation Sequences on page 470

Types of Actions in MSI Script Sequences on page 471
About the Wizard Dialogs on page 428
Using the Dialogs Page on page 430
Using the Dialogs Tab on page 433
About the Wizard Dialogs

Some dialogs in the Welcome Dialog Wizard are probably familiar to you, because they
appear in almost all installations. Others only appear in certain situations:
z If you add them with the New Dialog Wizard (Creating a New Dialog on page 437).
z If you add certain features to your installation, corresponding dialogs are added.
Example: IIS dialogs are added if you add Web resources to the Web Files page.
z If you create an installation based on a certain template in the New Installation File
dialog. Example: The Server Application template contains the SQL Connection
Dialog.
Dialogs That Can Appear in Installations

z Welcome Dialog
z License Dialog
See Importing Text into License and Readme Dialogs on page 433.
z Readme Dialog
See Importing Text into License and Readme Dialogs on page 433.

z User Information Dialog

Lets end users enter their name, company, and product ID, and indicate whether
the software should be installed for all users or only for the current user. The latter
applies only to destination computers that run Windows NT, 2000, XP, or Server
2003. The Product ID field does not appear to the end user if the ProductID
property (select Product tab > Properties icon) is set to none. See ProductID
Property and PIDTemplate Property in the Windows Installer SDK Help.
z Single Feature Destination Dialog

Sets the installation directory.
z Installation Type Dialog

Lets the end user select a typical, complete, or custom installation, which you define
on Installation Expert > Installation Types page.
z Select Feature Dialog

Lets the end user select which features to install and how to install them.
z Palm User Installation Dialog

If you add a Palm installation via the Mobile Devices page, and if the destination
computer has more than one Palm user, this dialog appears to let the end user
select the Palm users for which the Palm application will be installed.
z SQL Connection Dialog

Appears in installations started from the Server Application template in the New
Installation File dialog. It lets end users select a SQL Server name and security
credentials, and puts the resulting connection string into a property. You can use
this connection string on Installation Expert > SQL Server Scripts page. See Adding
the SQL Connection Dialog to an Installation on page 453.
z IIS Dialogs
Several dialogs that begin with “IIS” are added if you install Web files. See About
Web Installations on page 222.
Caution
behavior, including damage to the installation. Also, any operation within this
product that affects the installation’s user interface will regenerate the Web dialogs,
therefore, any changes you make to them will be lost.
z Logon Information Dialog

Appears in installations started from the Server Application template in the New
Installation File dialog. You can add it to any installation by using the New Dialog
Wizard. See Adding the Logon Information Dialog on page 451.
z Custom Property Dialog

Lets end users set the values of Windows Installer Properties. You can only add this
dialog via the New Dialog Wizard, where you set the properties that appear during
installation. See Adding the Custom Property Dialog on page 455.
Also see:
Using the Dialogs Page on page 430

Using the Dialogs Tab on page 433
About Dialogs on page 427

Using the Dialogs Page

Use Installation Expert > Dialogs page to view, activate, and rearrange installation
dialogs that are part of the Welcome Dialog Wizard. The dialogs you activate determine
the level of control the end user has over the installation.
Caution
Using the Convert button:

The Dialogs page looks different based on the version of Wise for Windows Installer that
the current installation was created in. If the current installation was created in 6.0 or
later, it has more options, which are documented below. When the installation was
created in earlier versions, it has fewer options and contains a Convert button.
The Convert button converts the button navigation to a more flexible and robust system,
which facilitates changing the order of dialogs. However, converting may cause problems
with legacy installations if you have extensively customized the dialogs and their
settings. Make a backup of the installation before converting if such customization
exists. Click Convert and the dialogs are instantly converted to the new system with no
undo. At that point, new options appear on the Dialogs page.
To activate dialogs for an installation:

Mark the checkbox next to the dialog’s name.
Caution
If this installation contains Web resources, then the list of dialogs might include Web
(IIS) dialogs. Only enable or disable the Web dialogs as a group. Enabling individual Web
dialogs can prevent the installation from working properly.
To view a dialog:
Click the dialog name in the Dialogs list.
To edit dialog details and attributes:

Select the dialog, click Details, and see Editing Dialog Details on page 435.
To change the order of dialogs during installation:

Use the Move Up and Move Down buttons.
Caution
If this installation contains Web resources, then the list of dialogs might include Web
(IIS) dialogs. The Web dialogs must always remain in their original order, so they should
only be moved as a group. See Changing the Order of Web Dialogs on page 433.

To add a dialog to the installation:

Click the Add button and complete the wizard as described in Creating a New Dialog on
page 437.
To turn off all installation dialogs:

z Use a silent installation. See User Interface Levels in the Windows Installer SDK
Help.
z In Setup Editor > Dialogs tab, clear the checkbox next to Welcome Dialog
Wizard.
About changing conditions

On the Dialogs page, you see the conditions attached to each dialog. You can change
these conditions by double-clicking the dialog name and editing the Conditions field,
but this is not recommended. Most of the Windows Installer properties referenced in
conditions are documented in the Windows Installer SDK Help.
Changing the Theme of Dialogs

The theme controls the overall look of installation dialogs by setting the dialogs’ top or
side image and the fonts of the dialog text. You can choose from predefined themes or
themes that you have created.
Caution
Changing themes might delete dialog customizations in installations created in previous
versions of this Wise product. To preserve dialog customizations, leave None selected in
Default Theme.
To change the dialog theme:

1. Select Installation Expert > Dialogs page.
2. From Default Theme, select a new theme.
The None option appears in Default Theme for installations created in

previous versions of this Wise product. If the installation you previously created
has dialog customizations that you do not want to lose, leave the Default
Theme set to None.
Select No Graphics to omit top or side images from dialogs. Use this option to
minimize the size of an installation that is always run silently.
The dialog in the Preview pane displays the new theme.
Applying Themes to Releases

You can apply different themes to different releases. The theme of the Default release
on the Releases page corresponds to the Default Theme on the Dialogs page. Changing
the theme on one page changes it on the other. Renaming or deleting the Default
release breaks this relationship. See Creating a New Release on page 179.

Adding and Editing Dialog Themes

The theme controls the overall look of installation dialogs by setting the dialogs’ top or
side image and the fonts of the dialog text. You can edit themes and create customized
dialog themes.
If an installation was imported or converted from a non-Wise product, the ability to edit
the themes is limited and varies depending on the product.
2. Click Edit Themes.
The Edit Themes dialog appears.
3. Specify a theme:
To edit an existing theme, click the theme name in the list on the left.
To create a new theme, click New and enter the theme’s name in Name.
To create a new theme based on an existing theme, click a theme in the list,
click Copy, and enter the new theme’s name in Name.
4. To add images to a new theme or to change an existing theme’s images, click

Browse to the right of Top Image Preview or Side Image Preview and select a
new image file.
The image you select appears in the preview pane.
When you create a new theme, the images you specify are copied to a new
subdirectory in the Themes directory. The location of the Themes directory varies.
See Where are Installation Resources Stored? on page 28.
Theme images you create must be in .BMP format. To quickly create theme images,
copy and edit a set of predefined images. These images are in the subdirectories of
the Themes directory.
5. To remove an image from a theme, click the Remove button to the right of the
image.
6. To edit a theme’s fonts, click the Set Font button to the right of the font to change
and select a new font from the Font dialog. Select a font that will be on the
destination computer. If the font you select is not on the destination computer, the
font is set to a recognized system font.
The selected font appears on the Edit Themes dialog next to the Set Font button.
The Title Font settings control the font for the title of all dialogs that have a top
image. (Example: the title “License Agreement” on the License Dialog.) The
Title Font settings do not control the font for the title of the Welcome Dialog or
any other dialogs that have a side image.
The Main Font settings control the font for the rest of the text on the dialogs.
You cannot edit the font of individual sections of a dialog from the Edit Themes
dialog.
If you create a new theme and do not set the fonts for that theme, it uses the
default font settings in the Properties table.
To edit the font of the Welcome dialog title or of any individual sections of dialog
text, use Setup Editor > Dialogs tab. See Basic Control Settings on page 440.

If you change one or more themes on the Edit Themes dialog, and then click OK, all the
changes are saved, but if you click Cancel, all the changes are canceled.
Importing Text into License and Readme Dialogs

You can import an .RTF or .TXT file to appear on the License and Readme dialogs. After
you import the text, you can edit it in its dialog.
2. Select the dialog in the Dialogs list.
3. Click Import Text and select an .RTF or .TXT file. (This button is available only when
you select the License or Readme dialogs.)
The text is imported into the dialog but any embedded graphics are removed.
Note
If you encounter error messages or formatting problems when you import the file, open
it in Wordpad, save it as .RTF, and re-import it. Some computers cannot import files with
formats other than .RTF. Also, only the standard .RTF settings are supported for the
License and Readme dialogs.
Changing the Order of Web Dialogs

If this installation contains Web resources, then it might contain Web (IIS) dialogs.
These dialogs must always remain in their original order, so they should only be moved
as a group.
2. Click Web Dialogs.
The Web Dialog Sequence dialog appears.
If the Web Dialogs button does not appear, either this installation does not contain
Web resources, or the user interface has been disabled for those Web resources.
3. In the list of dialogs, WEB DIALOGS represents the entire group of Web-related
dialogs, which must be moved as a group. Use the Move Up and Move Down buttons
to move the group of Web dialogs.
Caution
Using the Dialogs Tab

Use Setup Editor > Dialogs tab to select, edit, rearrange, and create the dialogs that will
appear in an installation. It shows the complete list of dialogs and provides more options
for working with dialogs than are available in Installation Expert > Dialogs page.

The Dialogs tab contains a Layout menu, a right-click menu, and a toolbar that let you
add new controls to dialogs, edit existing controls, and organize dialog content.
z To expand or collapse a selected dialog set’s children, use the right-click menu.
z If the toolbar is not visible, select View menu > Controls. (In Visual Studio: View
menu > Toolbox.)
Caution
To activate dialogs for an installation:

Mark the checkbox next to the dialog’s name. This works consistently for wizard dialogs
that appear under a wizard set, such as the Welcome Dialog Wizard. It does not work for
some required dialogs, such as the User Exit and Fatal Error dialogs, which can appear
whether you mark their checkbox or not. If you turn off the Cancel dialogs that appear
as children of wizard dialogs, the Cancel button that calls the Cancel dialog becomes
disabled in the wizard dialog.
Caution
If this installation contains Web resources, then it might contain Web (IIS) dialogs. Only
enable or disable the Web dialogs as a group. Enabling individual Web dialogs can
prevent the installation from working properly.
To edit dialog details and attributes:

Right-click the dialog name in the left pane and select Details. See Editing Dialog Details
on page 435.
Caution
If you are using the Installation Types page to manage the Installation Types dialog, you
cannot change any details on the Installation Types dialog. Doing so causes the
Installation Types page not to work properly.
To change the order of dialogs during installation:

Right-click the dialog name in the left pane and select. Move Up or Move Down
Caution
If this installation contains Web resources, then it might contain Web (IIS) dialogs. The
Web dialogs must always remain in their original order, so they should only be moved as
a group. See Changing the Order of Web Dialogs on page 433.
To add a dialog to the installation:

In the left pane, right-click where the new dialog should appear, and select New >
Dialog. Complete the wizard as described in Creating a New Dialog on page 437.
To turn off all installation dialogs:


z Use a silent installation. See User Interface Levels in the Windows Installer SDK
Help.
z In Setup Editor > Dialogs tab, clear the checkbox next to Welcome Dialog
Wizard.
Adding Controls to Dialogs

Add controls to dialogs on the Dialogs tab in Setup Editor.
Because of limitations with Windows Installer, do not place dialog controls on top of
graphics. Although you can place objects on top of one another, controls that are placed
on top of graphics often do not appear at runtime.
Caution
1. In Setup Editor > Dialogs tab, select a dialog in the left pane.
The dialog appears in the right pane.
2. Select Layout menu > Add, and then select the type of control to insert. If the
controls in the Add menu are disabled, click the dialog to make it active, and try
adding the control again.
(In Visual Studio: select View menu > Toolbox, and on the toolbox, double-click the
type of control to insert.)
Depending on the type of control you select, a Properties dialog appears so you can
configure the control’s properties, position, and attributes. For information on each
tab of the Properties dialog, see:
Basic Control Settings on page 440

Setting an Event on a Control on page 443
Assigning Help to a Control on page 444
Assigning Conditions to a Control on page 444
Setting the Graphic for a Control on page 444
Setting the Items in a Control on page 445
3. Click OK to add the control to the dialog.
When you finish adding and configuring controls, use other commands on the Layout
menu to help organize and arrange them. (In Visual Studio: use commands on the
Format menu.)
When you perform an operation on multiple controls at once (example: aligning

controls), the last control you select is the master control, which the other selected
controls will conform to. The master control is surrounded with solid handles instead of
hollow handles.
Editing Dialog Details

You can edit the general details of any installation dialog from:

z Setup Editor > Dialogs tab: Right-click the name of a dialog in the left pane, and
select Details.
z Installation Expert > Dialogs page: Select the dialog and click the Details button.
The Dialog Details dialog appears.
Caution
If you are using the Installation Types page to manage the Installation Types dialog, do
not change any details on the Installation Type dialog. Doing so causes the Installation
Types page not to work properly.
Caution
z Dialog Title
Enter the title of the dialog. You can include an installation property in the title by
enclosing it in square brackets. Example: [ProductName] inserts the name of the
product at runtime.
z X and Y Centering
Enter X and Y values from 1 to 100 to indicate where on the screen the dialog
should be centered. Values of 50 in both fields mean that the dialog should be
exactly centered on the screen. If the Y Centering value is set to 33, the center of
the dialog will be 1/3 of the way from the top of the screen.
z Visible
Mark this to make the dialog visible.
z Minimize Button
Mark this to add a minimize button.
z Track Disk Space

Mark this to have the dialog periodically call Windows Installer to update any disk
space fields on the dialog.
z Error Dialog
Mark this if the dialog is an error dialog. The property named ErrorDialog
determines which specific dialog is called if errors occur during installation. The
dialog must contain a text control named ErrorText to receive the contents of the
error message. An installation can contain only one error dialog.
z Modal
Mark this if the dialog should be modal, which means the dialog is the front window
of the installation until the end user clicks OK or Cancel. The end user cannot access
other windows or dialogs of the installation until the modal dialog is dismissed.
z Keep Modeless
Mark this if non-modal dialogs that are displayed when this dialog appears should
remain on the screen.
z Use Custom Palette

Mark this to use a custom color palette on displays with 256 colors or less. This
usually makes the dialog look better, provided only one dialog is on the screen at a
time.

Note
If you get details for the Custom Property Dialog, an Edit button appears on the Dialog
Details dialog. This lets you change the Windows Installer properties for the Custom
Property Dialog.
Creating a New Dialog

The New Dialog Wizard guides you through the process of adding a new dialog to an
installation.
1. Start the New Dialog Wizard:
Select Setup Editor > Dialogs tab. In the left pane, right-click where the new
dialog should appear, and select New > Dialog.
OR
Select Installation Expert > Dialogs page > Add button.

The Select Dialog Type dialog appears.
Note
The dialog templates that appear are in Wise Standard.msi, which is stored in
\Templates\Dialogs. The location of the Templates directory varies. See Where are
Installation Resources Stored? on page 28. To make additional dialogs available in
each new installation, open Wise Standard.msi and add the dialogs to the All Dialogs
branch on the Dialogs tab.
2. Select the type of dialog and click Next.
The Dialog Properties dialog appears.
3. Edit any values by clicking the item in the Type column and then clicking Edit.
This dialog lets you change any properties the new dialog inherits from the
template. Example: Each dialog must have a unique name. The wizard assigns a
unique name to the new dialog by appending a number to the template’s name, but
you might want a more descriptive name.
4. When you finish editing values, click Next.
If you added the Custom Property dialog, the Select Custom Properties dialog
appears, where you can select properties that can be set by the end user during
installation. See Adding the Custom Property Dialog on page 455.
The Select Installation Placement dialog appears, which differs slightly based on
what version of Wise for Windows Installer the current installation was created in.
Read about the Convert button in Using the Dialogs Page on page 430.
5. Specify where in the sequence the new dialog should appear.
If Move Up and Move Down buttons appear, use them to move the new dialog
within the list.
If they do not appear, then you must select a dialog in both the After and
Before columns. The new dialog will appear after the dialog you select in After,
and before the dialog you select in Before.
6. Click Finish to add the new dialog to the dialog list.
Now you can add and edit controls on the dialog.

See:
Adding Controls to Dialogs on page 435

Editing Dialog Details on page 435
Organizing and Aligning Controls on Dialogs on page 446
About Dialog Controls

Installation dialogs contain standard controls, which you can add and edit. Most controls
are configured by completing their Properties dialog. See Editing Dialog Controls on
page 439.
Dialog controls often have an associated property. The result from the dialog control is
put into the property. To have a dialog control be deselected by default, associate the
control with a property whose value is not defined (null).
Example:
Suppose you create a checkbox, and you want the checkbox to be initially cleared. In
the Properties dialog for the checkbox, click the New button next to the Property field,
create a new property named CHECKBOX1, and leave its value blank. Although this
results in error messages during compile (which you can safely ignore), it ensures that
the checkbox is initially cleared when initially cleared when it appears to the end user.
(Delete the property from the Properties icon on the Product tab to eliminate error
messages.) To test whether the end user marked the checkbox, you use a condition that
consists of the property’s name, that is, CHECKBOX1. If the checkbox was not marked,
the value of the property remains null, and therefore CHECKBOX1 is false. If the
checkbox was marked, its value is now non-null, and therefore CHECKBOX1 is true.
Types of Dialog Controls

z Billboard. A static field that defines the area of the dialog where a sequence of text
and images is displayed during installation. Billboards require special setup. See
About Billboards on page 448.
z Bitmap. A static image field for displaying graphics.
z Button. A clickable button.
z Checkbox. A single checkbox for on/off, true/false settings.
z Combobox. A combination edit field and drop-down list control that lets the end
user select a predefined value or enter a value.
z Directory Combobox. Displays a combination directory list and path edit field to
let the end user specify a directory.
z Directory Listbox. Displays the folders below the main part of the current path.
This is intended to be used with the path edit control.
z Edit Field. A single line input field.
z Group Box. A boundary box drawn around related controls.
z Icon. A static image control for displaying icons.
z Line. A separator line drawn between groups of controls.
z Listbox. Displays a single column of values without icons. The end user can select
one value from the list.

z Listview. Displays a single column of values with an icon next to each. The end
user can select one value from the list.
z Masked Edit Field. A text edit field with a mask that creates a template for end
user data entry, specifying default values for some positions and specifying the
proper type of character (numeric or alpha) for others. You can enter certain
characters in the Control Text field of the Masked Edit control to constrain which
characters can be used at each character position of the control. See MaskedEdit
Control in the Windows Installer SDK Help.
z Path Edit. A single line input field that accepts only a valid pathname. This is
intended to be used in conjunction with the directory list box or directory combobox
controls.
z Progress Bar. A control that displays the progress of an installation or other

operation.
z Radio Button. A group of mutually exclusive options with a separate radio button
for each option.
z Scrollable Text. A multi-line text entry field.
z Selection Tree. Displays the feature selection tree.
z Text. Static text field for displaying messages. The end user cannot change text in
this type of field. You can enter a property name surrounded by brackets in this type
of control to display a property’s current value.
z Volume Cost Listbox. A static text control that shows information about the disk
space requirements of different volumes (referred to as “cost” in Windows Installer
terminology) for the currently selected features.
z Volume Combobox. Lets the end user select a volume for installation.
Editing Dialog Controls

Caution
The dialog appears in the right pane.
2. Double-click a control.
A multi-tabbed Properties dialog appears. The tabs that appear vary depending on
the type of control. See:
Basic Control Settings on page 440

Setting an Event on a Control on page 443
Assigning Help to a Control on page 444
Assigning Conditions to a Control on page 444
Setting the Graphic for a Control on page 444
Setting the Items in a Control on page 445
To see the results of these settings, compile and run the installation.

Basic Control Settings

The Control tab, which appears on the Properties dialog for dialog controls, determines
the appearance and basic behavior of controls. See Editing Dialog Controls.
The settings available on this tab vary depending on the type of control.
z Property
The name of the property associated with this control. The property determines the
initial state of the control, and holds the result from the control after end user input.
This property can determine the initial state of the control. Example: If a checkbox
is associated with a property whose value is not defined (null), the checkbox is
initially cleared when it appears to the end user. After the end user has interacted
with a control by marking it, entering text into it, or selecting an option, the result of
the user input is stored in this property.
You can create a new property. For details, see Creating a New Property on
page 417.
Note
(Windows 9x installations only.) If you create a component condition based on a
property that is set during the UI Sequence, add the merge module CondFix.msm to
the installation. This merge module fixes a Windows Installer limitation. For details,
see WiseFixConditions on page 411.
z Control Text
The text in the control. For bitmap and icon controls, this stores the key in the
binary table in which the bitmap or icon is stored. Click Import to import text from
an existing text file (.TXT or .RTF).
Note
If you encounter error messages or formatting problems when you import the file,
open it in Wordpad, save it as .RTF, and re-import it. Some computers cannot import
files with formats other than .RTF.
z Max Characters
(This replaces the Control Text field for an edit field control.) Enter the maximum
number of characters the end user can enter.
z Default
Mark this to activate this control when the user presses Enter while on this dialog.
Example: If you mark this checkbox for an OK button on a dialog, then when the
user presses Enter, the event associated with the OK button is activated.
z Cancel
Mark this to activate this control when the user presses Esc while on this dialog.
Example: If you mark this checkbox for a Cancel button on a dialog, then when the
user presses Esc, the event associated with the Cancel button is activated.
z Font Property
(Not available for a scrollable text control.) Select the property that defines a font.
In most cases, select _WiseDialogFontDefault to match the default text of other
text on dialogs. To define a new font style, add a new row to the TextStyle table in
Setup Editor > Tables tab. Then create a new property, and enter the new text
style’s name, surrounded by curly brackets, as the property value.

z Control Font
You can click Set Font and select a font for the control. The Font Property field, if
set, overrides this field.
X Position, Y Position
The location of the control within the dialog. The upper left corner is represented by
X,Y values of 0,0. You also can drag the control to position it on the dialog.
z Width, Height
The size of the control in installation units, which are equal to 1/12 the height of the
system font on the destination computer.
General Attributes
z Visible
Makes the control visible.
z Sunken
Makes the control beveled to appear pushed into the dialog.
z Right Aligned Text

Right-aligns text in the control.
z Enabled
Enables the control, that is, display it in a state the end user recognizes as clickable.
z Indirect
If you mark this, the information for the control is not stored directly in the property
for the control. Instead, the value of the control’s property is used as the real
property name to store the information in.
Example: Suppose a dialog has 3 radio buttons and a checkbox. The radio buttons
set the property RADIO to FIRST, SECOND, or THIRD. The checkbox also uses the
property RADIO but has the Indirect checkbox marked. The property FIRST,
SECOND, or THIRD is set to the checkbox state based on the setting of the radio
button.
z Scrollbar on left side

On a scrolling field control, places the scrollbar on the left instead of the right.
(Usually used with the Right-To-Left Reading checkbox below.)
z Integer
Restricts end users to entering only integers in this control.
z Right-To-Left Reading
Indicates that the text in this control is in a language that is read right to left.
z Has Border
Displays a group box frame around the radio buttons in a radio button control.
z Check Value
If the end user marks the control, the value of the property in the Property field is
set to this value.
Control Attributes
z Transparent
Makes the background of the control transparent.

z Format Size
Attempts to format displayed text as a number representing a count of bytes. The
control’s text must be set to a number in units of 512 bytes. KB, MB, or GB is added
to the end of the text depending on how large the number is.
z No Prefix
Displays any & characters in the control’s text. Otherwise, & characters do not
appear and cause the next character to be underscored.
z Users Language
Makes the text control use fonts created in the end user's default UI codepage. If
this is cleared, the fonts are created in the database’s codepage.
z No Word Wrap
Text is not wrapped to fit the control area. Instead, it is clipped at the right edge of
the control.
z Multiline
Lets an edit field control accept multiple lines of text. If this is cleared, it accepts
only a single line.
z Image Handle
Obtains the image from a handle rather than from the Binary table.
z Icon Control
Replaces the control’s text with an icon. The control’s text is used as a key to the
Binary table to point to the icon data.
z Pushbutton
(Checkboxes and radio button groups only.) Draws the control as if it were a
pushbutton, although its behavior is not changed.
z Fixed Size
Prevents the image associated with the control from being scaled to fit the control
size. Instead, the image is cropped or centered in the control.
z Password
Makes an edit control display asterisks instead of the characters that the end user
types. This is typical of controls that require entry of a password.
z Bitmap
Replaces the control’s text with a bitmap. The control’s text is used as a key to the
Binary table to point to the bitmap data.
z Icon Size
Determines how icons are displayed in the control. Select a size, or select First
Icon to set scaling according to the first icon.
z Sorted
By default, the items in the control are sorted alphabetically before they are
displayed. Mark this to sort the items in the order they appear on the Items tab of
the Properties dialog.
z Droplist
Makes the control display a drop-down list rather than a multi-line selection list.
z Removable Volumes, CD-ROM Volumes, Fixed Volume, RAM Disk Volumes,

Remote Volumes, Floppy Volume
Mark the checkboxes to determine which types of volumes are listed in the control.
z Windows 95 Style
Displays the control using a Windows 95 appearance.

Setting an Event on a Control

The Events tab, which appears on the Properties dialog for dialog controls, determines
the events that the control can send and receive. See Editing Dialog Controls on
page 439.
Use events to control the display of other dialogs, and to control the way Windows
Installer displays dialogs. When an event is generated (either by a dialog control or by
Windows Installer) it is published. The published event is sent to Windows Installer and
to all dialogs controls that have subscribed to it.
Publish Events
The top section of the Events tab lists the events published by the control.
z To add a new published event, click Add.
z To edit a selected event, click Details.
z To remove a selected event from this control, click Delete.
z To rearrange the order in which the events are sent, click Move Up or Move Down.
When you click Add or Details, the Publish Event Details dialog appears, where you set
the following options:
z Event
Select the event to be published. See the following in the Windows Installer SDK
Help:
ControlEvent Overview for general information on control events.

Control Events for details on each control event.
z Argument
Enter the argument for the event. If no value is passed for that argument, the event
is ignored. See Control Events in the Windows Installer SDK Help; click an event
name to see valid arguments.
z Condition
If you enter a condition for the event, the event occurs only if the condition is true.
If there is no condition, the event always occurs. For details, see Conditions on
page 407.
Subscribe to Events
The bottom section of the Events tab lists the events accepted by the control.
z To add a new subscribed event, click Add.
z To edit a selected event, click Details.
z To remove a selected event from this control, click Delete.
When you click Add or Details, the Subscribe Event Details dialog appears, where you
set the following options:
z Event
Select the event to be subscribed to. See the following in the Windows Installer SDK
Help:
ControlEvent Overview for general information on control events.

Control Events for details on each control event.

z Attributes
Select an attribute that should be set for the control when the subscribing control
receives the ControlEvent. For information on valid attributes, see Control Attributes
in the Windows Installer SDK Help.
Assigning Help to a Control

The Help tab, which appears on the Properties dialog for dialog controls, lets you set
tooltip help for the control. See Editing Dialog Controls on page 439.
z Tooltip
A 1 or 2 word phrase that appears when the end user points to the control and
pauses. This is used only by screen reading programs.
Assigning Conditions to a Control

The Conditions tab, which appears on the Properties dialog for dialog controls, lets you
set conditions for a control. The conditions let you assign specific attributes to a control.
Conditions determine whether the control is the default control, and whether it is
disabled, enabled, hidden, or visible. You can add multiple conditions to a control.
z To add a new condition, click Add.
z To edit a selected condition, click Details.
z To remove a selected condition from this control, click Delete.
When you click Add or Details, the Control Condition Details dialog appears, where you
set the following options:
z Action
The action to take when the condition is true.
z Condition
If you enter a condition for the event, the event occurs only if the condition is true.
If there is no condition, the event always occurs. For details, see Conditions on
page 407.
Setting the Graphic for a Control

The Graphic tab, which appears on the Properties dialog for graphical dialog controls,
lets you specify a graphic file for the control. It determines the image displayed in the
control. Not all controls can display graphics. See Editing Dialog Controls on page 439.
z Graphic Name
The drop-down list displays graphics stored in the Binary table. Select a graphic or
click Set to import a new graphic. Graphics must be in .BMP format.
z Information
Displays information about the graphic, including the number of colors in its palette,
its width and height, and its size.
z Preview
Displays the image. If necessary, the image is scaled down to fit in the preview
area.

Setting the Items in a Control

The Items tab, which appears on the Properties dialog for list box controls, comboboxes,
listview controls, and radio button controls, determines the items that are listed in the
control. It also lets you determine the tab order of the items, and set the vertical
position (which determines the order of the items on the dialog). See Editing Dialog
Controls on page 439.
All controls that share the same property name also share the same list of items.
Example: Suppose you make a radio button control, associate the property ITEM_LIST
with it, and add 3 items to it. Then on another dialog, you make a listview control and
associate ITEM_LIST with it. If you look at the Items tab for the listview control, it
contains the same items as for the radio button.
z To add a new item, click Add.
z To edit a selected item, click Details.
z To remove a selected item from this control, click Delete.
z To rearrange the order in which the items are displayed, click Move Up or Move
Down. To change the order in which the items appear on the dialog, double-click
each item and set its Y coordinate.
When you click Add or Details, a details dialog appears, where you can specify the text
that appears in the control.
The settings available on this tab vary depending on the type of control.
z Text
The text of the button or list item.
z Value
The value returned to the control’s property when the item is selected.
z Icon Name
Select an icon from the list or click Set and select an icon file on your hard drive.
The icon you set appears next to this item in the list control. This option does not
appear for all types of controls.
z Font Property
Select the property that defines a font. In most cases, select
_WiseDialogFontDefault to match the default text of other text on dialogs. To
define a new font style, add a new row to the TextStyle table in Setup Editor >
Tables tab. Then create a new property, and enter the new text style’s name,
surrounded by curly brackets, as the property value.
z Control Font
You can click Set Font and select a font for the control. The Font Property field, if
set, overrides this field.
z X Position, Y Position
The location of the item within the control. The upper left corner is represented by
X,Y values of 0,0. To rearrange items within the control (example: to reorder the
items for radio buttons), change the Y position.
z Width, Height
The size of the control in installation units, which are equal to 1/12 the height of the
system font on the destination computer.

Organizing and Aligning Controls on Dialogs

You can align, center, and evenly space controls on installation dialogs. You can also
constrain controls so they are the same size and set the tab order. You perform these
functions using commands on the Layout or right-click menu. (In Visual Studio: use the
Format or right-click menu.)
When you perform an operation on multiple controls at once (example: aligning

controls), the last control you select is the master control, which the other selected
controls will conform to. The master control is surrounded with solid handles instead of
hollow handles.
Because of limitations with Windows Installer, do not place dialog controls on top of
graphics. Although you can place objects on top of one another, controls that are placed
on top of graphics often do not appear at runtime.
Caution
Aligning Dialog Controls

You can align controls on a dialog in relation to each other.
2. In the right pane, select 2 or more controls.
The last control you select is the master control that the other controls will be
aligned with.
3. Select Layout menu > Align > Lefts/Rights/Tops/Bottoms, depending on which edge
of the controls should align. (In Visual Studio: Format menu > Align > Lefts/Rights/
Tops/Bottoms)
All selected controls are aligned with the master control.
Centering Dialog Controls

You can center controls on a dialog in relation to the dialog boundaries.
3. Select Layout menu > Center in Form > and then select one of the following. (In
Visual Studio: Format menu > Center in Form.)
Vertically. Center within the top and bottom edges of the dialog.
Horizontally. Center within the left and right edges of the dialog.
All selected controls are centered in the dialog.
Making Dialog Controls the Same Size

You can make multiple controls on a dialog the same size.

The last control you select is the master control that the other controls will be sized
to.
3. Select Layout menu > Make Same Size and then select one of the following. (In
Visual Studio: Format menu > Make Same Size.)
Width.
Height.
Both.
All selected controls are sized to the master control.
Spacing Dialog Controls Evenly

You can space controls on dialogs evenly between the leftmost and rightmost controls
(for horizontal spacing) or the topmost and bottommost controls (for vertical spacing.)
3. Select Layout menu and then select one of the following. (In Visual Studio: Format
menu.)
Horizontal Spacing > Make Equal. Space items left to right.
Vertical Spacing > Make Equal. Space items up and down.
All selected controls are spaced evenly on the dialog.
Setting Dialog Tab Order

You can determine the tab order of controls on dialogs.
2. Click anywhere on the dialog to set focus.
3. Select Layout menu > Set Tab Order. (In Visual Studio: View menu > Tab Order.)
This is disabled unless you set the focus on the dialog first.
A black box appears for each control. The numbers on the boxes indicate the tab
order.
4. To set the new tab order for the dialog, click the controls in order. Each control turns
blue as its new tab order is assigned.
If the first several items have the correct tab order, and you want to begin
renumbering the tab order at a later number, hold down the Ctrl key and click the
control after which you want to renumber. Example: If controls 1 through 7 have the
correct tab order, and you want to start renumbering from 8, press Ctrl and click
control 7. Then continue setting tab order starting from control 8.
5. (Visual Studio integrated editor only.) Before working in another project in the
solution, save the installation to set the tab order.

About Billboards
Billboards consist of a series of text and images that are dynamically displayed on a
dialog during installation. Typically, billboards highlight features of the program being
installed, promote related products, or encourage product registration.
A billboard is associated with an action, and is displayed while that action is performed
during installation. A billboard consists of:
z The billboard. The billboard defines the area of the dialog where a sequence of text
and images is displayed. The billboard is like a screen on which bitmaps, icons, or
text controls are projected.
z The billboard control. The billboard control is associated with a feature and an
installation action. It also defines how many bitmaps, icons or text controls are
displayed, and in what order. You create one billboard control for each bitmap, icon,
or text control.
z Bitmap/Icon/Text control. Bitmap, icon, or text controls are associated with a

billboard control, and you place them inside the billboard area.
Where to Use Billboards

Billboards typically are used on the Progress Dialog under the Install Dialogs, and are
associated with the InstallFiles action. You can add billboards to other dialogs, if:
z The dialog is displayed to the end user while the installation is performing an action.
z You associate the billboard with an action that takes some time to perform. If the
action is completed in a fraction of a second, the end user will not see the billboard.
A billboard typically consists of several bitmaps, icons or text controls. If you want to
display only one control, add it to the dialog directly instead of within a billboard.
Windows Installer does not support the display of billboards outside of installation
dialogs.
Adding Billboards to a Dialog

In the following steps, bitmaps, icons, and text controls are referred to as content items.
1. Select Setup Editor > Dialogs tab.
2. In the left pane, select the Progress Dialog under Install Dialogs.
By default, the Progress Dialog contains a billboard, which is represented by a small

outline in the lower left corner of the dialog. Content items you add will be bounded
by this outline.

3. Click the small outline and resize and move it to accommodate the content items
you plan to add. You can adjust it later.
Note
Although a default billboard area is already created, you also can create your own.
Right-click the dialog and select Add > Billboard. On the Properties dialog that
appears, click the Events tab. Make sure the Subscribe to Event list contains an
entry where Event is set to SetProgress and Attribute is set to Progress.
4. Create one or more billboard controls:
a. Right-click the dialog and select Billboards > New.
The Billboard Details dialog appears.
b. Complete the dialog:
Name
Enter a descriptive name for this control.
Feature
Select a feature from the list. This control’s content item only appears during
installation if this feature is installed.
Action
Select an action from the list. We strongly recommended that you leave the
default, InstallFiles, because usually only this action takes time to complete.
The control’s content items are displayed while this action is performed
Display After
If this is the first control, select <display first>. Otherwise, select the
control that this one should appear after.
c. Click OK.

d. Repeat this step to add as many controls as you have content items.
The controls you create do not appear on the dialog. You can only see their content
items, which you add in the next step.
5. Add content items to each billboard control:
Right-click the dialog and select Billboards > BillboardControlName, where

BillboardControlName is the name of the control. This makes the control active.
Right-click the dialog, select Billboards > Add Control, and select Bitmap, Icon,
or Text.
A properties dialog appears. The tabs that appear vary depending on the type of
control.
For bitmaps or icons, click the Graphic tab and select a graphic or click Set to
import a new graphic. Graphics must be in .BMP format. See Setting the
Graphic for a Control on page 444.
For text controls, enter text in the Control Text field. See Basic Control
You can add multiple content items to each control.
Make sure each content item is within the outline that represents the billboard
area.
If you add large content items, you can resize the Progress Dialog itself to
accommodate them. Also, you might need to resize bitmap items for them to
display correctly.
6. To preview the billboard, select each billboard in order from the Billboard submenu
of the right-click menu.
7. To see the billboard work, compile and run the installation.
Note
Billboards do not appear when you test the installation. This is because files are not
installed during a test, so the InstallFiles event is never triggered. To view the billboards,
you must run the installation. See Running An Installation on page 90.
To edit an existing billboard:

Always select the billboard control name first by right-clicking and selecting Billboards >
BillboardControlName, where BillboardControlName is the name of the billboard control.
This makes the control active, which means that any editing you do is applied to that
billboard.
Obtaining Logon Information From a Dialog

¾ Professional and Enterprise Editions only
¾ Operating system requirement.

Installations that contain the Logon Information dialog can be run on Windows NT 4,
2000, XP, and Server 2003 only.
Often, server software must be configured after installation to run under a particular
user with certain permissions. To help with this process, you can add the Logon

Information dialog to an installation. The Logon Information dialog is fully customizable,

which lets you communicate its purpose to the user.
Use the Logon Information dialog to:
z Let the end user create a new NT user account during installation, if the end user
has the privileges to do so.
z Let the end user specify an existing NT user account during installation.
z Populate the properties MYUSERNAME and MYPASSWORD with the logon

information specified by the user.
Although this dialog captures the logon information, it does not use it in any way or
apply it to your executables or services. You must do that yourself by using the
properties elsewhere in the installation.
Example: To have a service run under the specified user account, you can enter the
property names MYUSERNAME and MYPASSWORD, enclosed in brackets, in the Service
Details dialog (Installation Expert > Services page). You also can use these properties as
the account to run a Web application (Web Files page).
Also see Adding the Logon Information Dialog on page 451.
Adding the Logon Information Dialog

¾ Operating system requirement.

Installations that contain the Logon Information dialog can be run on Windows NT 4,
2000, XP, and Server 2003 only.
The Server Application template (Server Application.msi) contains the Logon

Information dialog by default. For all other installations, you can add the Logon
Information dialog by using the New Dialog Wizard in Setup Editor > Dialogs tab.
(In the Wise editor) To create a new installation that contains the
Logon Information dialog:
2. In the Categories list, select Predefined Templates.
3. In the Templates/Tools list, select Server Application and click OK.
4. In Setup Editor > Dialogs tab, select the Logon Information Dialog and edit the
dialog text as needed to communicate its purpose to the end user installing your
application.
(In the Visual Studio integrated editor) To create a new installation

that contains the Logon Information dialog:
3. In the Templates list, select Server Application Project and click Open.

4. In Setup Editor > Dialogs tab, select the Logon Information Dialog and edit the
dialog text as needed to communicate its purpose to the end user installing your
application.
To add the Logon Information dialog to any installation:

1. In Setup Editor > Dialogs tab, expand the Install Dialogs tree, then expand the
Welcome Dialog Wizard tree.
2. Right-click on a dialog under the Welcome Dialog Wizard and select New > Dialog.
3. On the Select Dialog Type dialog, select Logon Information and click Next.
4. Step through the wizard to create a new dialog; see Creating a New Dialog on
page 437.
5. Edit the dialog text as needed to communicate the purpose of the user account to
the end user installing your application.
Guidelines for Using the Logon Information Dialog

z Make sure you customize the text on the Logon Information dialog to communicate
the logon information’s purpose to the end user.
z If the end user chooses to create a new user, the end user must have user creation
privileges on the server or domain.
z If the end user creates a user with this dialog, then cancels the installation, the
created user still exists and is not deleted.
z During installation, the end user cannot progress through the installation until a
valid NT account is entered on this dialog. There is no mechanism for the end user
to skip this part of the installation.
z Do not use this dialog to capture logon information to be used in a SQL Server
connection string on the SQL Server Scripts page; Microsoft’s SQL Server logon
mechanism prevents this from working.
Also see:
Adding a Service to the Destination Computer on page 159

About Web Installations on page 222
Obtaining Logon Information From a Dialog on page 450
About the SQL Connection Dialog

Add the SQL Connection dialog to an installation to:
z Let the end user select a SQL Server name and security credentials to generate a
valid SQL Server connection string.
z Populate the WISE_SQL_CONN_STR property with the valid connection string.
When the end user completes the SQL Connection dialog and clicks Next, the installation
creates and tests the connection string. If the connection string is not valid, an error
message appears.

Note
The SQL Connection dialog only validates the connection string; it cannot verify that the
user has permission to execute all SQL statements in a SQL script.
SQL Connection Dialog Requirements

z Use the WISE_SQL_CONN_STR property for the connection string in Installation
Expert > SQL Server Scripts page. See Configuring a Microsoft SQL Server During
z The ODBC SQL Server driver must be on the destination computer for this dialog to
work. Use the Prerequisites page to pre-install MDAC, which includes the ODBC SQL
Server driver. See Adding Prerequisites to a Release on page 186.
z The Browse button appears on the SQL Connection dialog only if SQL Client Tools
(osql.exe) is installed on the destination computer. When the end user clicks the
Browse button, a drop-down list appears with the SQL Servers on their network. If
the Browse button does not appear, the end user must enter the SQL Server name.
z This dialog requires no modification to output a valid connection string to the

property WISE_SQL_CONN_STR. However, if your application connects to more than
one SQL Server during installation, add a SQL Connection dialog for each additional
server, edit the additional dialogs, and use a different property for each connection
string. See Editing Additional SQL Connection Dialogs on page 454.
Also see Adding the SQL Connection Dialog to an Installation on page 453.
Adding the SQL Connection Dialog to an Installation

The Web Application and Server Application templates contain the SQL Connection
dialog. For all other installations, you can add the SQL Connection dialog.
(In the Wise editor) To create a new installation that contains the SQL
Connection dialog:
2. In the Categories list, select Predefined Templates.
3. In the Templates/Tools list, select Server Application or Web Application and

click OK.
4. In Setup Editor > Dialogs tab, select SQL Connection Dialog and edit the dialog text
as needed to communicate its purpose to the end user who installs your application.
(In the Visual Studio integrated editor) To create a new installation

that contains the SQL Connection dialog:
3. In the Templates list, select Server Application Project or Web Application

Project and click Open.

4. In Setup Editor > Dialogs tab, select SQL Connection Dialog and edit the dialog text
as needed to communicate its purpose to the end user who installs your application.
To add the SQL Connection dialog to any installation:

1. In Installation Expert > Dialogs page, click Add.
The Select Dialog Type dialog appears.
2. Select SQL Connection Dialog and click Next.
3. Step through the wizard to create a new dialog; see Creating a New Dialog on
page 437.
4. Edit the dialog text as needed to communicate its purpose to the end user who
installs your application.
Also see About the SQL Connection Dialog on page 452.
Editing Additional SQL Connection Dialogs

In most cases, an application connects to only one SQL Server during installation.
However, if your application connects to more than one SQL Server during installation,
add a SQL Connection dialog for each additional server and edit the additional dialogs as
follows:
1. Start the New Dialog Wizard to add an additional SQL Connection dialog. See Adding
the SQL Connection Dialog to an Installation on page 453.
2. On the Dialog Properties dialog of the New Dialog Wizard, edit the dialog’s default
control properties.
Example: Edit the dialog’s control properties as follows:
From: To:
WiseSqlServerName WiseSqlServerName1
WiseSqlAuth WiseSqlAuth1
WiseSqlUser WiseSqlUser1
WiseSqlPass WiseSqlPass1
3. Finish the New Dialog Wizard.
4. In Setup Editor > Dialogs tab, select SQL Connection Dialog1 in the left pane.
5. In the right pane, edit the Argument of the [WiseSqlParam] event for the Browse
and Next buttons using the new control properties and a new property for the
connection string. See Setting an Event on a Control on page 443.
Example: Edit the Argument of the [WiseSqlParam] event for the Browse and Next
buttons as follows:

From: To:
WiseSqlServerName|WiseSqlAuth|WiseSqlUser|WiseSq WiseSqlServerName1|WiseSqlAuth1|WiseSqlUser1|Wis
lPass|WISE_SQL_CONN_STR eSqlPass1|WISE_SQL_CONN_STR1
6. Use the new property for the connection string in the SQL script that executes the
connection with the additional SQL Server. See Setting SQL Connection Strings on
page 235.
Example: Use the WISE_SQL_CONN_STR1 property for the connection string.
Also see About the SQL Connection Dialog on page 452.
Adding the Custom Property Dialog

The Custom Property Dialog lets you specify Windows Installer properties that can be
set by the end user during installation. You might use this if there are environment-
dependent values that you cannot predict, which must be provided by the end user, such
as user names and passwords. You can use this dialog to gather property values to
replace in an XML file; see Editing XML Files During Installation on page 137.
This dialog does not appear in any installation by default, and must be added via the
New Dialog Wizard.
Caution
Do not add more than one Custom Property dialog to a single installation; only one per
installation is supported. If an installation contains multiple Custom Property dialogs,
then multiple, identical dialogs appear to the end user at run time.
To add the Custom Property Dialog:

2. Click Add.
The New Dialog Wizard appears, which is fully documented in Creating a New Dialog
on page 437.
3. In the list of dialogs, select Custom Property Dialog and click Next.
4. Leave the defaults on the Dialog Properties dialog and click Next.
The Select Custom Properties dialog appears, where you can either choose existing
Windows Installer properties or create new properties.
Existing Properties
To add an existing property, select it from this list and click Add. To create a new
property, select <New Property> from this list, and define the new property as
described in Creating a New Property on page 417.

End User-Configurable Properties

This list, which you build via the Add button, contains the properties that will be
editable by the end user in the Custom Property Dialog during installation.
Property Description
For each property you added in End User-Configurable Properties, select the
property name and add a description here to help the end user understand how
to set the property. This is limited to about 275 characters, because of the size
of the field that appears on the Custom Property Dialog.
Display property value as asterisks during installation

To mask the property value during installation, select the property name in End
User-Configurable Properties and mark this checkbox. If the end user sets
this value during installation, their entry is masked, and they must enter the
property value a second time to verify the entry. This also omits the property
value from the installation log. Use this feature when the property value
includes sensitive information (example: a password).
6. Finish the New Dialog Wizard.
The Custom Property Dialog now appears in the list of dialogs on the Dialogs page.
When you run this installation, the Custom Property Dialog appears.
To edit the properties on the Custom Property Dialog:

2. In the list of dialogs, select Custom Property Dialog.
3. Click Details.
4. On the Dialog Details dialog, click the Edit button.
The Edit Custom Properties dialog appears, where you can change the properties.

Chapter 20
Macro Editor

The Macro Editor provides access to Wise Automation, which programmatically controls
Wise for Windows Installer. Use Wise Automation to perform tasks that occur regularly
and require multiple steps in the user interface. Example: You can write Wise
Automation in the Macro Editor to automate daily builds. To view the Wise Automation
Reference, open WiseAutomation.chm, which is in the Help subdirectory of the Wise
product application directory.
Caution
You should be familiar with macros and comfortable with Visual Basic to use this feature.
For information on Visual Basic, visit msdn.microsoft.com/vbasic/.
Note
You can use Wise Automation with Visual Studio or other scripting environments.
Topics include:
z About Macro Files.
z Creating, Editing, and Running a Macro.
z About the Macro Editor Window.
About Macro Files

Use the Macro Editor to create and edit macro files. The default macro file in the
Templates folder (Macros.wbs) contains sample macros. These samples are commented
out, which means that you can view the script in the Macro Editor but you can’t run the
macros unless you uncomment the script. You can add macros to Macros.wbs, and edit
and delete its macros.
Each new file you start in Wise for Windows Installer has Macros.wbs attached. When
you open the Macro dialog, you can attach a different macro file.
You can create two types of macros:
z Event macros that run when you fire the corresponding event.
z Macros that you run manually.
If your .WBS files include event macros, you might encounter a situation in which you
want to create a new project that doesn’t run these macros. Example: You might have a
macro that runs on the New event and adds a specific set of files to a specific set of
directories every time you start a new project. To start a new project that does not

Macro Editor
include these files and directories, you can create a new .WBS file that doesn’t contain
any macros. Then, attach this macro file to your project.
The Macro Editor doesn’t let you save a .WBS file under a different name. To rename a
macro file, change the file name in Windows Explorer.
Also see:
Creating, Editing, and Running a Macro

About the Macro Editor Window on page 460
Creating, Editing, and Running a Macro

The Macro Editor is similar to Microsoft’s Visual Basic Editor. For information on Visual
Basic, visit msdn.microsoft.com/vbasic/.
To create a macro:
(Visual Studio integrated editor only.) In MSI Script, right-click in the

Installation Sequence pane and select Macros.
(Wise editor only.) Select Edit menu > Macros.

The Macro dialog appears.
Macro Is Run
Select:
Manually to create a manually-run macro.
On WFWI Event to create a macro that runs on an event.
Event Name
For a manually-run macro, enter a name for the new macro. Do not include
spaces in the name. For an event macro, select an event.
Pathname
When you create a new macro, it is added to the macro file displayed. To add
the new macro to a different .WBS file, browse to the file’s location. To create a
new .WBS file, click New and specify the file.
3. Click Create.
The Macro Editor window appears. See About the Macro Editor Window on
page 460.
4. In the script box, write the macro.
5. In the Macro Editor, select File menu > Save.
6. To create another macro, select Script menu > Add New Macro, enter a name for the
macro on the dialog that appears, write the macro, and save it.
7. When finished, exit the Macro Editor.

Macro Editor
To edit a macro:


2. From Macro Is Run, select:
Manually to edit a manually-run macro.
On WFWI Event to edit a macro that runs on an event.
3. In the list box, select the macro to edit.
If the macro is in a file other than the one shown in Pathname, browse to the file’s
location.
4. Click Edit.
The Macro Editor window appears. See About the Macro Editor Window on
page 460.
5. Edit the macro.
6. In the Macro Editor, select File menu > Save.
7. Exit the Macro Editor.
To run a macro manually:



2. From Macro Is Run, select Manually.
3. In the list box, select the macro to run.
If the macro is in a file other than the one shown in Pathname, browse to the file’s
location.
4. Click Run.
Also see:
About Macro Files on page 457

Events That Can Trigger a Macro
Events That Can Trigger a Macro

Using the Macro Editor, you can write macros for OLE Automation events. Example: If
you write a macro for the AddFile event, the macro runs every time you add a file to an
installation. See Creating, Editing, and Running a Macro on page 458.

Macro Editor
Event What you could do with a macro

AddFile Have each .DLL or .EXE file you add marked Read-only
or have all .DLL files placed into the System directory.
New Have a specific set of files added each time you start a
new installation. You could also add a message box so
you can choose not to have the files added.
Open Have all files you’ve added previously replaced with
any updated files in a certain folder each time you
open an installation.
QueryDisplayValidation Have Package Validation not display certain ICE error
messages. To do this, set the variable bDisplay to
FALSE for that error.
QueryFixValidation Have Package Validation determine if an ICE error is
fixable and supply code to fix it. It is first called when
bCheckOnly = TRUE. If bFix is set to TRUE, it
determines that the error is fixable and the Correct
button on the Package Validation View / Correct dialog
is enabled. When the user clicks the Correct button,
the macro is called again with bCheckOnly = FALSE.
The macro should then execute the changes needed to
fix the ICE error.
Run If an installation requires files that are accessed by a
custom action, the macro can ensure that these files
are copied to the proper location before you run the
installation.
Save Run several checks to ensure an installation adheres
to your corporate standards.
Test Same as Run.
VBImport Have all relevant entries in the database tables
changed to comply with your corporate standards.
About the Macro Editor Window

Caution
You should be familiar with macros and comfortable with Visual Basic to use this feature.
For information on Visual Basic, visit msdn.microsoft.com/vbasic/
The Macro Editor window with all its functions is very similar to the Microsoft Visual Basic
window.
Buttons
These are unique to the Macro Editor or are in some way different from those in Visual
Basic:

Macro Editor
Options Opens the Script Editor Options dialog, where you set
and change the appearance of a script.
Members Is context-sensitive and gives you properties and

methods in the context of a clicked object. If your
pointer is not on an object when you select this item
from the right-click menu, then it lists all available
properties and methods. Properties and methods for
an object are all predefined in Wise for Windows
Installer. The global list also contains Visual Basic
functions.
Repeat Finds text again.
Exit Closes the Macro Editor window; if you’ve made

changes to the current macro, a dialog prompts you to
save or discard your changes.
Event View Shows only one macro at a time.
Object View Shows all macros you’ve written for a particular object.
Full Module View Shows all macros you’ve defined for both WfWI events
and general functions.
Additional Right-Click Menu Options

z List Objects
Displays a global list of objects. Objects are predefined in Wise for Windows
Installer. For help on Wise functions, see the Wise Automation Reference, which is
in the Help directory under the Wise product application directory.
z List Functions
Displays a global list of Wise and Visual Basic functions. For help on Visual Basic
functions, visit msdn.microsoft.com/vbasic/. For help on Wise functions, see the
Wise Automation Reference, which is in the Help directory under the Wise product
application directory.
z Check Syntax
Checks the macro for the correct syntax.
z Revert to Saved
Reverts the current macro to the last saved version, to undo any changes you’ve
made since you last saved.
There are 2 drop-down lists along the top of the script box. The drop-down list on the
left lets you select the type of macro: (General) for manually run macros, and
WFWIEvents for event macros. The drop-down list on the right lets you select
corresponding macros.

Chapter 21
Debugger for Windows Installer

The Debugger for Windows Installer is an easy-to-use tool that lets you step through an
installation to isolate and resolve problems. You can view the installation’s actions and
their properties, the installation database tables, and the Windows Installer log file, and
you can evaluate conditions. Use the debugger when an installation doesn’t perform as
you anticipated and you can’t readily determine why.
Topics include:
z About the Debugger for Windows Installer.
z Running the Debugger.
z Evaluating Conditions.
z Working With Temporary Tables and Columns.
z Searching For Text in Tables.
About the Debugger

The Debugger for Windows Installer runs an installation, which can be an .MSI, a .WSI,
or a transform (.MST), and lets you see exactly what it is doing at any time. As the
installation runs, the debugger displays temporary Windows Installer properties that you
can change to see how they affect the installation. Example: You can test a radio
button’s conditions by changing its current values, or change the current value of an
installation directory.
The debugger does not fix problems in the installation. Once you’ve used the debugger
to test the installation, use Wise for Windows Installer to make the appropriate changes
in the .MSI, .WSI, or .MST file. You cannot edit the installation within the debugger; you
can only change temporary values to see how they affect the installation. See Working
With Temporary Tables and Columns on page 465.
Also see:
The Debugger Window

To open the Debugger for Windows Installer, see Running the Debugger on page 463. To
show or hide any pane, use the View menu.

Parts of the Debugger Window

The debugger window consists of the following panes:
z Actions
Lists the actions in the installation. These correspond to the actions in the Normal
Installation mode of MSI Script. Dialog actions can change depending on whether
you are installing or uninstalling your application.
z Table List
Lists all the tables in the installation in a window named _Tables. To open a table,
double-click its row in the Table List. Move from one open table to another by
clicking the corresponding tab at the bottom of this window. You can edit temporary
table fields only. See Working With Temporary Tables and Columns on page 465.
z Log
Displays a record of the actions that are processed during the installation. This
installation log is generated by Windows Installer and is displayed for informational
purposes only.
z Properties
Displays the properties of the action selected in the Actions pane. It shows current
values of the action’s condition, condition state, sequence, and type. You cannot
change any of the properties in this pane.
z Condition Evaluator
Lets you test conditions without adding them to the installation. When you enter
conditions and run the installation, the Condition Evaluator displays the conditions’
values. See Evaluating Conditions on page 465.
You can customize the debugger window by rearranging the panes. Any changes you
make to the panes are retained the next time you launch the debugger program. Use
the right-click menu in the Actions, Properties, Condition Evaluator, and Log panes for
these additional options:
z Float as MDI Window

Change the pane to a window with a tab in the Table List pane. To dock it again,
right-click in the window and clear this option.
z Allow Docking
Dock a pane when you drag it near an edge of the screen. When this option is not
marked, the pane does not dock regardless of where you drag it. You can also
prevent docking by pressing Ctrl while dragging.
z Hide
Remove the selected pane from the screen. To restore the pane, select it in the View
menu.
Running the Debugger

The debugger runs through the actions in the Normal Installation mode only. It cannot
debug the Administrative or Advertisement installations.
1. In Wise for Windows Installer, open the .WSI, .MSI, or .MST to debug.

2. Click the Debug button. (In Visual Studio: In Solution Explorer, right-click the
installation project icon and select Set as Startup Project. Then select Debug menu
> Start.)
The installation is saved and compiled if you have made changes since the last
compile. You are prompted to select an .MSI if you defined more than one release.
The debugger window opens.
3. Set breakpoints if desired. See Setting and Clearing Debugger Breakpoints.
4. To run the installation, do one of the following:
Run through the actions

Select Debug menu > Go. This executes all actions up to the first breakpoint, if
any. As each action is processed, a white arrow appears to its left. When the
installation pauses at a dialog for end user input, the white arrow stops at the
next action to be processed.
Run one action at a time

Select Debug menu > Step Over or Step Into to execute only the action with the
arrow to its left. After the action is processed, the arrow moves to the next line
and the debugger waits for another command.
Use Step Into if the installation contains one or more custom actions that call
VBScript, and you have the VBScript Debugger or Visual Studio with InterDev
installed. This opens the VBScript Debugger or Visual Studio and lets you debug
the VBScript. When you are finished, you can return to the installation in the
Debugger for Windows Installer.
Step Over runs VBScript actions but does not open the VBScript Debugger.
Run to a selected action

Select the action, then select Debug menu > Run to Selection. This executes all
the actions up to the selected action. After the actions are processed, the arrow
moves to the selected action and the debugger waits for another command.
5. To stop the installation, select Debug menu > Stop Debugging or click Cancel in the
installation’s user interface.
Setting and Clearing Debugger Breakpoints

A breakpoint is a place in the installation where you temporarily halt the execution. You
set breakpoints in the Actions pane of the debugger. When you set a breakpoint and
then run the installation, it pauses at the breakpoint and waits for another command.
You can set multiple breakpoints.
To set a breakpoint:
Click the action at which you want to set a breakpoint, then press F9.
You can set breakpoints on sequences and control events only.
To clear a breakpoint:
Click an action with a breakpoint and press F9.
To clear all breakpoints at once, press Ctrl + Shift + F9.

Evaluating Conditions
To display the Condition Evaluator pane, select View menu > Condition Evaluator.
This pane lets you test conditions without having to add them to the installation. You
enter the condition or conditions in the Condition Evaluator, and then run the installation
in the debugger. The Condition Evaluator returns the values, either TRUE or FALSE, for
the conditions you entered.
To enter a condition, click in the Condition column of the Condition Evaluator pane, then
enter the condition. Conditions you enter are saved from session to session. To delete a
condition, click its Condition column and press Delete.
Working With Temporary Tables and Columns

As you run the installation in the Debugger for Windows Installer, the Windows Installer
runtime creates a temporary table named _Property and adds temporary columns to the
Component, Feature, and File tables. The fields in these temporary columns represent
the current values of directories, user-defined properties, and Windows Installer
properties. This is where you do most of your debugging. Stop the installation to look at
a particular value and make sure it’s set correctly, or to change a temporary value to see
how that affects the installation.
To change a temporary field’s value, triple-click in its column and type the new value.
Changing temporary values does not affect the installation file; it just provides a way to
try different values. When you decide what changes need to be made, update the
installation in Wise for Windows Installer.
When you change a setting in an installation dialog, the corresponding property value in
the _Property table changes. As you step through the installation, you’ll notice that
certain tables and fields display in red. This means they have changed since the last step
or, if you are not stepping over, since the beginning of the installation or the last
breakpoint.
Searching For Text in Tables

Within the Debugger for Windows Installer, you can search for text in the entire
database, the current table only, or the current column only. To do so, select Edit menu
> Find.

Chapter 22
Using MSI Script
MSI Script™ provides a powerful yet easy-to-use environment for editing Windows
Installer installation sequences, even if you are not familiar with the underlying Windows
Installer technology. A sequence is a set of actions that are performed during a
particular type of installation.
Topics include:
z The MSI Script Window.
z About MSI Script.
z About Installation Modes.
z About Installation Sequences.
z Editing Sequences.
z Calling WiseScripts with Custom Actions.
z Guidelines for Using Custom Actions.
z Launching a Custom Action from a Dialog.
z Custom Actions That Are Added Automatically.
z Troubleshooting Custom Actions.
The MSI Script Window

To access MSI Script™, click the MSI Script tab at the bottom of the main application
window.

Using MSI Script
Installation
Mode
Restricted Areas
Actions
Sequences
z Installation Mode
Installation modes represent the different ways an installation can be run. Choose
whether to work on a normal installation, an advertisement installation, or an
administrative installation. See About Installation Modes on page 468.
z Actions
You can select from standard actions, which are built-in Windows Installer functions,
or custom actions, which you configure yourself. To learn about an action, double-
click it and press F1.
z Restricted Areas
If you select an action that has restrictions on its placement, the restricted area is
shaded.
z Sequences
Below the sequence area are tabs that let you switch between sequences. Each
installation mode is comprised of sequences, which, in the Windows Installer
database, correspond to sequence tables.
About MSI Script

MSI Script™ contains the sequences of actions that make up an installation. The action
sequences are pre-defined following the Windows Installer guidelines for creating
sequences. The actions are in the recommended order, and, where appropriate,
conditions are set. We recommend that you do not delete or move any standard actions.
See Standard Actions Reference in the Windows Installer SDK Help.
The existing action sequences are sufficient for most installations. If you need
specialized functionality not offered by Windows Installer, you can add custom actions to
an installation. With custom actions, you can call .EXEs, .DLLs, WiseScripts, JScripts,
and VBScripts. You can set installation properties and directories and call nested .MSI
files. You can also perform many other functions such as launching a Web page or
downloading a file from a Web site. See Custom Action Reference on page 489.

Using MSI Script
Also see:
About Installation Modes

Finding Text in MSI Script on page 471
About Installation Modes

MSI Script contains 3 installation modes: Normal Installation, Administrative
Installation, and Advertisement Installation. Access these modes from the Installation
Mode drop-down list in MSI Script. They represent the actions that are performed
during each type of installation. They contain standard Windows Installer actions, dialog
actions, and custom actions. All installation modes are included in every Windows
Installer installation you create, but each mode is run only under certain circumstances.
Installation modes are not used with merge modules.
Normal Installation
Select this installation mode to edit the sequences that are run during a normal
installation. This is the most common type of installation.
If the application is not already installed when an end user double-clicks the installation
.MSI, the standard installation wizard appears (Install Dialogs), which installs the
product. If the application is already installed when an end user double-clicks the
installation .MSI or if the end user selects it from the Add/Remove control panel, the
installation runs in maintenance mode (Maintenance Dialogs), which provides options to
modify, repair, or uninstall an application. For information on dialog groupings, see
About Dialogs on page 427.
Administrative Installation
Select this installation mode to edit the sequences that are run during an administrative
installation.
An administrative installation copies a source image of the application to a network; the

source image resembles the directory structure of the installed application. End users
who have access to the administrative installation can then install the application from
the network location.
To run an administrative installation, use the command line option /a. (Example:
msiexec /a “C:\Pathname\Sample.msi”.) An administrative installation uses the Admin
Dialogs. For information on dialog groupings, see About Dialogs on page 427.
Also see:
Performing an Administrative Installation on page 286

Command Line Options in the Windows Installer SDK Help
Advertisement Installation
Select this installation mode to edit the sequences that are run during an advertisement
installation.
An advertisement installation places entry points, such as shortcuts, on the destination

computer without actually installing the application. When an installation is opened in
advertising mode, only the Execute sequences are run because it does not have a User
Interface sequence, and therefore no dialogs appear. See Advertisement in the Windows
Installer SDK Help.

Using MSI Script
To run an advertisement installation, use the command line option /j. Example: msiexec
/j “C:\Pathname\Sample.msi”.
All Custom Actions

Select All Custom Actions from the Installation Mode drop-down list to view the All
Custom Actions list. The All Custom Actions list does not represent an installation mode,
but instead is a repository of all custom actions stored in the CustomAction table of this
installation.
Use All Custom Actions to do the following:
z Add a custom action outside a sequence

See Adding a Custom Action Outside a Sequence.
z Add a custom action to multiple sequences

See Adding a Custom Action to Multiple Sequences on page 469.
z Quickly review and edit custom actions

If your custom actions are scattered, you can quickly review and edit them without
scanning through each sequence to find them.
Adding a Custom Action Outside a Sequence

You can add a custom action that is not invoked unless you provide a mechanism to call
it during installation, such as creating an event that triggers the custom action.
Example: You might want a custom action to run if an end user clicks a button on a
dialog during installation. See Launching a Custom Action from a Dialog on page 483.
1. Select MSI Script.
2. From Installation Modes, select All Custom Actions.
This displays a list of all custom actions in this installation.
3. In the Actions list, double-click the action.
4. Complete the Details and Properties tabs as you would normally.
If the action does not have these tabs, then you cannot add it outside a sequence.
5. On the Location tab, mark No Sequence.
This tab is only available in the All Custom Actions mode.
6. Click OK.
Adding a Custom Action to Multiple Sequences

When you copy and paste an action between sequences, an entirely new copy of that
custom action is stored in the installation database. To avoid this duplication and
possible use of extra disk space, you can assign an action to multiple sequences.
2. From Installation Modes, select All Custom Actions.
This displays a list of all custom actions in this installation.
3. In the Actions list, double-click the action.
4. Complete the Details and Properties tabs as you would normally.

Using MSI Script
If the action does not have these tabs, then you cannot add it to multiple
sequences.
5. On the Location tab, clear No Sequence.
This tab provides another way to perform tasks that you normally perform in the
User Interface, Execute Immediate, or Execute Deferred sequences. See Using the
Custom Action Location Tab on page 515.
6. From Sequence, select a sequence.
7. In the list box of actions, select an action and click Add.
The action is added to the sequence, below the action you selected.
If you are in a merge module, the layout of the Location tab is different. See Using
the Custom Action Location Tab for Merge Modules on page 516.
8. Select other sequences and add the action to them.
9. Click OK.
About Installation Sequences

Installation sequences are represented by tabs below the Installation Sequence
section in MSI Script. Windows Installer has 2 main types of sequences: User Interface
and Execute. The User Interface sequence, which is executed at the beginning of
installation, gathers system information, displays dialogs to the end user, and records
end user choices. It is suppressed during silent installations.
The Execute sequence installs the application and makes changes to the system. During
installation, Windows Installer first goes through each action in the Execute sequence
and builds an internal installation script to follow. You cannot see or access this internal
script. This first pass is referred to as immediate mode and is represented by the
Execute Immediate tab. After it creates the internal installation script, it runs the script
it created, performing the actions that change the system. The second pass is referred
to as deferred mode, and encompasses all the actions between InstallInitialize and
InstallFinalize. It is represented by the Execute Deferred tab. This makes it easier to
specify in which mode to run an action. For information on where to place a custom
action, see Guidelines for Custom Action Location on page 478.
When Windows Installer generates the installation script, it generates a rollback script
that will undo the actions of the installation script. The rollback script is executed if the
installation is canceled or is unsuccessful, and is also run in deferred mode. Although
you cannot view or edit the rollback script, you can specify that custom actions you add
be added to it; use the In-Script Options field on the Properties tab of the custom
action details dialog.
On Windows NT, 2000, XP, and Server 2003, Windows Installer runs as a service, which
is registered in the Services control panel. When an .MSI is launched, it is run by the
service. The Windows Installer service can run with elevated privileges based on
policies, and the Windows Installer database runs with the current user’s privileges.
When you add custom actions, you can specify whether they should be run with elevated
privileges (system context) or with user privileges (user context). Set privileges to user
context or system context in the In-Script Options field on the Properties tab of the
custom action details dialog. On Windows 95 and Windows 98, Windows Installer runs
as an executable. Because there are no levels of privileges on Windows 95 and Windows
98 (everyone has full privileges), setting privileges has no effect.

Using MSI Script
For information on Windows Installer sequence tables, see Using a Sequence Table in
Finding Text in MSI Script

Press Ctrl + F and enter a text string to find lines that contain that string. All installation
sequences are searched, and you can select which installation modes to search. (In the
Visual Studio integrated editor, you cannot select installation modes, because the
standard Visual Studio Find dialog is used.)
Note
You cannot replace text using this feature, but you can replace text in Setup Editor >
Tables tab. See Searching for Table Data on page 401.
Also see:
About Installation Modes on page 468

About MSI Script on page 467
Editing Sequences
Use the commands on the Edit menu, the right-click menu, or the tools on the toolbar to
edit an MSI Script™ sequence. You can edit only one action at a time, but you can cut,
copy, or paste several actions at a time. To edit an action, select its installation mode,
click its sequence tab, and select the action from the Installation Sequence pane.
See:
Types of Actions in MSI Script Sequences

About the Standard and Custom Tabs on page 472
Adding and Editing Actions on page 472
Commenting Out Script Lines on page 473
About MSI Script on page 467
Types of Actions in MSI Script Sequences

z Windows Installer standard actions (gray)
These built-in actions are defined by the Windows Installer SDK. Double-click a
standard action in the Installation Sequence list and press F1 to access the
Windows Installer SDK help for the action. These actions perform basic installation
tasks, such as creating shortcuts and writing files. You cannot edit standard actions,
and you should not move or delete them. See Standard Actions in the Windows
Installer SDK Help.
z Dialog actions (violet)

Dialog actions display dialogs or groups of dialogs. Often, one Display Dialog action
includes several dialogs. To edit or view all the dialogs associated with a Display
Dialog action, double-click the Display Dialog line, and the dialog opens in Setup
Editor > Dialogs tab. See Using the Dialogs Tab on page 433.
z Custom actions (black)

You can add custom actions to an installation to perform actions that are not
available using Windows Installer’s standard actions. Custom actions are sometimes

Using MSI Script
added automatically to enhance some capabilities of Windows Installer. See Custom

Actions That Are Added Automatically on page 483.
z If Statements - Conditions (blue)

Use If Statements to indicate that a condition is attached to the actions between the
If Statement and its corresponding End statement.
z Remarks (green)
Remark statements document the script. Remarks that explain how the script works
are already added to new scripts you create. Removing these remarks has no
adverse affect.
About the Standard and Custom Tabs

You can add both custom actions and standard actions to an MSI Script sequence. At the
lower left of the Actions list, the Custom tab displays custom actions, and the Standard
tab displays Windows Installer built-in actions. The Standard tab displays only those
Windows Installer actions that are not already in the selected sequence.
Display Dialog actions are not displayed on either the Standard or Custom tab. To add a
dialog, use Setup Editor > Dialogs tab. After you add a dialog, it appears in MSI Script
as an action.
Adding and Editing Actions

To add an action to an MSI Script sequence, do one of the following:
z Drag and drop the action

Drag the action from the Actions list onto a line in the Installation Sequence list.
The new action appears before the line that is highlighted when you drop the action.
z Double-click the action

In the Installation Sequence list, select the line above which the new action
should appear and double-click the action in the Actions list.
z Type and select the action

In the Installation Sequence list, select the line above which the new action
should appear. Type the first few letters of the action name. As you type, the current
line becomes a drop-down list containing all the action names. Select an action and
press Enter.
About Restricted Areas

If an action has restrictions on its placement in the sequence, the restricted areas are
shaded in the Installation Sequence list when you select that action in the Actions
list. Place the action in a non-restricted area.
Editing Custom Action Settings

When you add a custom action, a dialog appears that lets you enter settings for the
custom action. To access this dialog for an existing custom action, double-click it. For
information on these dialogs, see Custom Action Reference on page 489. If you double-
click Display Dialog actions, the dialog opens in Setup Editor > Dialogs tab. To move an
action, select Move Up or Move Down from the Edit menu.

Using MSI Script
Note
You cannot edit Windows Installer standard actions, which are displayed in gray, and you
should not move or delete them.
You can also copy and paste actions to other locations in the installation sequence.
However, each time you copy and paste an action, an entirely new copy of the action is
stored in the installation. To avoid this duplication, see Adding a Custom Action to
Multiple Sequences on page 469.
Also see:
Guidelines for Using Custom Actions on page 478

Types of Actions in MSI Script Sequences on page 471
Commenting Out Script Lines

While you are working in MSI Script, you can temporarily disable certain actions to help
you with your debug process. You do this by commenting out actions. Commented
actions remain in the sequence, but are skipped when the sequence is executed.
z To comment out an action, select the line or lines in the sequence that you want to
disable and select Edit menu > Comment. (In Visual Studio: Edit menu > Advanced
> Comment Selection.)
The commented lines appear in green.
z To reactivate commented lines, select them again and select Comment a second
time. (In Visual Studio: Edit menu > Advanced > Uncomment Selection.)
Calling WiseScripts with Custom Actions

The Run WiseScript custom actions provide the ability to call WiseScripts. WiseScript™
technology provides many specialized functions that are not available in or are difficult
to do with Windows Installer technology. In a WiseScript, you can use special actions
that let you pass information between the main Windows Installer installation and the
WiseScript .EXE that is being called. For information on which WiseScript editing tool
comes with your software, see WiseScript Editing Tools.
Note
If the main Windows Installer installation is run silently, a called WiseScript is called
silently.
WiseScript Editing Tools

The following WiseScript editing tools are available:
z WiseScript Express
Included in Wise for Windows Installer and Wise Package Studio - Standard Edition.
z WiseScript Editor
Included in Wise Package Studio - Professional Edition.
z Wise Installation System

A fully-featured stand-alone product for creating WiseScripts. You must use version
8 or later to create WiseScripts that can be run by Windows Installer.

Using MSI Script
Determining Your Default WiseScript Editing Tool

Use the following to determine the WiseScript Editing tool that opens by default when
you open a WiseScript from a Call WiseScript custom action or from a menu:
z If you have Wise for Windows Installer, it launches Wise Installation System, if
available. If it is not available, it launches WiseScript Express.
z If you have Wise Package Studio - Standard Edition, it launches Wise Installation
System, if available. If Wise Installation System is not available, it launches
WiseScript Express.
z If you have Wise Package Studio - Professional Edition, it always launches

WiseScript Editor.
Adding script actions to Wise Installation System

If you have Wise Installation System, but it doesn’t contain the script actions that
communicate with Windows Installer (Get Windows Installer Property, Set Windows
Installer Property, and Evaluate Windows Installer Condition), you can copy them into
the Wise Installation System. From the Wise for Windows Installer/WiseScript Express/
Actions folder, copy the 3 .WSE files named for these 3 script actions and paste them in
your Wise Installation System/Actions folder. After you reopen the Wise Installation
System, these actions are available.
Calling a WiseScript .EXE versus calling a regular .EXE

Creating a custom action that calls a WiseScript .EXE is similar to calling a regular .EXE,
except that communication can take place between Windows Installer and WiseScript.
This is possible through the use of the Get Windows Installer Property, Set Windows
Installer Property, and Evaluate Windows Installer Condition actions in the WiseScript.
For information on these actions, see the documentation for the WiseScript editing tool.
Examples of WiseScripts You Run From an .MSI

This section provides illustrations of how to use WiseScripts called by a Windows
Installer installation. For information on which WiseScript editing tool comes with your
software, see WiseScript Editing Tools.
For script examples, see:
z Using a WiseScript to Parse a Pathname on page 474
z Using a WiseScript to Install a License File on page 475
z Uninstalling Changes Made by a WiseScript on page 476
Using a WiseScript to Parse a Pathname

Because Microsoft’s Windows Installer technology does not allow for parsing, you cannot
use it to create an installation that extracts a pathname from the registry and then
parses the pathname to isolate the file name into a property. However, you can send the
pathname to a WiseScript executable, do the parsing, then send the file name back in a
Windows Installer property.
Example: You extract the pathname C:\Program Files\Application\Application.exe, use

WiseScript to parse the file name, Application.exe, and send the file name back in a
Windows Installer property.
Do the following:

Using MSI Script
1. Write a WiseScript that uses:
Get Windows Installer Property script action to get the property named
APPLICATION_PATH into a temporary variable.
Parse String script action on the temporary variable to put the file name into
another temporary variable.
Set Windows Installer Property script action to put the file name back into the
Windows Installer property APPLICATION_PATH.
2. In Installation Expert, use the System Search page to get a registry entry that
consists of a full pathname. Put the pathname into a property named
APPLICATION_PATH.
3. In MSI Script, add a custom action to Run a WiseScript from Installation and specify
the WiseScript you wrote.
4. When an end user runs the Windows Installer installation, it calls the WiseScript,
which parses the pathname. When the Windows Installer installation continues
running, APPLICATION_PATH contains Application.exe.
The sample WiseScript looks like this (the script lines are numbered for clarity):
1. Get Windows Installer Property APPLICATION_PATH into TEMP

2. Parse String "%TEMP%" into PATH and FILE
3. Set Windows Installer Property APPLICATION_PATH to %PATH%
Using a WiseScript to Install a License File

Virtually anyone can open an installation .MSI and see the files and other information it
contains. Usually, this is an advantage, but it can be a disadvantage when you need to
include sensitive information such as passwords or a license file. To hide sensitive files,
install them with a WiseScript and save them within the WiseScript .EXE.
Example: Your application comes in 2 editions: Regular and Super. Serial numbers for
the Regular edition begin with the letter R, and serial numbers for the Super edition
begin with S. The serial number the end user enters during installation determines the
license file that gets installed, which determines which features are turned on. You set
up the installation to have the license files installed by the WiseScript instead of the .MSI
so that the license files are embedded in the WiseScript .EXE and cannot be opened.
Do the following:
1. Write a WiseScript that uses:
Get Windows Installer Property script action to get the property named
SERIALNUM into a temporary variable named SERIALNUMBER.
Set Variable script action, with the Evaluate Expression operation, to place the
first character of the serial number in a variable named EDITION.
If Statements and Install File(s) script actions to install the appropriate license
file based on the value of the EDITION variable.
2. In MSI Script, add a custom action to Run a WiseScript from Installation and specify
the WiseScript you wrote.
3. During the Windows Installer installation, the WiseScript runs, gets the first
character of the serial number, and installs the appropriate license file.

Using MSI Script
1. Get Windows Installer Property SERIALNUM into SERIALNUMBER

2. Get Windows Installer Property INSTALLDIR into MAINDIR
3. Set Variable EDITION to LEFT$(SERIALNUMBER,1)
4. Check free disk space
5. If EDITION Equals "R" then
6. Install File c:\Development\Source\RLicense.exe to
%MAINDIR%\RLicense.exe
7. Else
8. If EDITION Equals "S" then
9. Install File c:\Development\Source\SLicense.exe to
%MAINDIR%\SLicense.exe
10. Else
11. If EDITION Equals "" then
12. Display Message "Invalid serial number"
13. End
14. End
15. End
To ensure the license file is uninstalled when the application is uninstalled, see
Uninstalling Changes Made by a WiseScript.
Uninstalling Changes Made by a WiseScript

You can use the Run WiseScript custom actions to make changes to the destination
computer when the script is run from your .MSI. (Example: You can use the Install
File(s) script action to add files or you can use the Edit Registry script action to add, edit,
or delete keys or values in the registry.) However, the Windows Installer installation
does not recognize any changes the WiseScript makes to the system and therefore will
not uninstall any of these changes during uninstall of the main Windows Installer
installation.
To solve this problem, do the following:
z In the WiseScript, include steps to install an installation log and Unwise32.exe.
z In the .MSI, during an uninstall, use a custom action to call the Unwise32.exe that is
in the WiseScript.
Example: You have an .MSI named Core and a WiseScript named CorePlus. CorePlus
includes an Install File(s) script action that installs a file named A.dll. You want to make
sure that A.dll gets uninstalled when Core is uninstalled.
In the Core .MSI, do the following:

1. Select MSI Script and click the Execute Immediate tab.
2. Scroll down and click directly below the RemoveExistingProducts action.
3. Add an If Statement with a value of NOT Installed.
This condition causes it to run only during initial installation of Core.
4. Add a Run WiseScript From Installation custom action and set:
Custom Action Name to ActionInstallCorePlus
WiseScript .EXE File to C:\Plus\CorePlus.EXE

Using MSI Script
Leave Command Line blank. On the Properties tab, leave the defaults.
5. Add an End Statement.
The above script lines install CorePlus, which in this example is A.dll. In the
following script lines, you make provisions for the uninstall.
6. Add an If Statement with a value of REMOVE~=“ALL”.
This condition causes it to only run during uninstall of Core.
7. Add an Execute Program From Destination custom action and set:
Custom Action Name to RemoveCorePlus
Working Directory to INSTALLDIR
EXE and Command Line to [INSTALLDIR]Unwise32.exe /S install.log

On the Properties tab, leave the defaults.
8. Add an End Statement.
The MSI script looks like this (the script lines are numbered for clarity):
1. If NOT Installed then

2. Run WiseScript From Installation C:\Plus\CorePlus.EXE
3. End
4. If REMOVE~=”ALL” then
5. Execute Program From Destination [INSTALLDIR]unwise32.exe /S
install.log Default Directory Program Files\Core
6. End
In the CorePlus WiseScript, do the following:

1. Add a Get Windows Installer Property script action and set:
Dest. Variable to MAINDIR
Property Name to INSTALLDIR

INSTALLDIR is the installation directory of Core, the main Windows Installer
installation. This sets the WiseScript installation directory to the same value as the
main installation’s installation directory.
2. Add a Set Variable script action and set:
Variable to MAINDIR
New Value to %MAINDIR%
Operation to Remove trailing backslashes.

INSTALLDIR has a trailing backslash, but to be compatible with WiseScript,
MAINDIR cannot have a trailing backslash.
3. Add an Open/Close INSTALL.LOG script action with Open new installation log
marked and the log file path specified as %MAINDIR%\install.log.
This causes the WiseScript to create a log in the installation directory.
4. Add an Install File(s) script action and set:
Source Pathname for Unwise32.exe
Destination Pathname to %MAINDIR%\Unwise32.exe.

Using MSI Script
Unwise32.exe is located within the WiseScript Express directory under the Wise for
Windows Installer directory.
5. Add an Install File(s) script action and set:
Source Pathname for A.dll
Destination Pathname to %MAINDIR%\A.dll.
Add any other necessary script actions. (Example: You could edit registry entries, check
if a certain file or directory exists, or rename a file or directory.) For this example, the
CorePlus script installs only A.dll. For troubleshooting purposes, you might also want to
add a Display Message script action that shows the value of %MAINDIR%. This lets you
know when the WiseScript runs, and also gives you debugging abilities.
1. Get Windows Installer Property INSTALLDIR into MAINDIR

2. Set Variable MAINDIR to %MAINDIR%
3. Open new installation log file %MAINDIR%\install.log
4. Install File C:\Program Files\Unwise32.exe to
%MAINDIR%\Unwise32.exe
5. Install File C:\Plus\A.dll to %MAINDIR%\A.dll
Guidelines for Using Custom Actions

When you use Windows Installer to install a file, it takes care of the repair and
management of the file. When you use a custom action to change an installation, you
take Windows Installer out of the loop. (Example: If you use a custom action to install a
file, you must also include custom actions to repair or uninstall the file because Windows
Installer is unaware of the file.) Therefore, use custom actions conservatively when
making permanent changes on the destination computer, and use them only for actions
that cannot be accomplished through Windows Installer. See Uninstalling Changes Made
by a WiseScript on page 476.
Caution
Although you can change the order and conditions for standard actions and dialogs, we
recommend that you do not change these settings unless you are proficient in the
Windows Installer development environment. Many actions have restrictions that
determine where they must appear in the sequence. See Actions with Sequencing
Restrictions in the Windows Installer SDK Help for more details.
The following topics provide guidelines for using custom actions:
Guidelines for Custom Action Location

Guidelines for Custom Action Conditions on page 480
Guidelines for Nested Installation Custom Actions on page 480
Guidelines for Calling VBScripts and JScripts on page 481
Guidelines for Calling .DLLs on page 481
Guidelines for Custom Action Location

General
z Place the custom action as high in the sequence as possible where it executes
properly. If it doesn’t execute properly when you test it, keep moving it lower in the
sequence until it works.

Using MSI Script
z If the custom action uses information that’s gathered during the User Interface
sequence, place it after the actions that gather the information you need.
z If the installation is run silently, items in the User Interface sequence do not
execute.
Correct Sequence
If the action does this: Place it in this sequence:

Gathers input from an end user User Interface
Needs to change properties User Interface or Execute Immediate
Is an Install MSI custom action Execute Immediate
Is to be executed sometime during the Execute Immediate or Execute Deferred
installation of files
Place it between the InstallInitialize and
InstallFinalize actions, near the InstallFiles
action. The InstallFiles action installs files
during deferred mode.
Makes a change to the system Execute Deferred
Depends on a previous action in order Execute Deferred
to run
Windows Installer does not perform the
action when it runs in Immediate mode. If
a custom action depends on a change to
the system, and the change has not yet
been made, the custom action fails.
Requires elevated privileges to run Execute Deferred
Actions run in Deferred mode can be run

under the system context. See the
description of the In-Script Options field
in Using the Custom Action Properties Tab
on page 517.
Restricted Areas
z If an action has restrictions on its placement in the sequence, the restricted areas
are shaded in the Installation Sequence list when you select the action in the
Actions list. Place the action in a non-restricted area. Restrictions are defined by
Windows Installer functionality. Example: You can’t run an action that depends on
an installed file if the file is not yet installed.
z If you use the Move Up and Move Down commands on a custom action that has
restricted placement, keep in mind that the restricted areas will not be shaded.
Before moving an action, select the action in the Actions list to view its restricted
areas.
Formatted Text
z If you use formatted text in a custom action, such as a bracketed property name,
the custom action must be placed after the CostFinalize action in the User Interface
sequence. This is a Windows Installer requirement.

Using MSI Script
z If you use formatted text in a custom action, do not put the custom action in the
Execute Deferred sequence. Formatted text strings do not convert in the Execute
Deferred sequence. The exceptions to this rule are the CustomActionData and
ProductCode properties. See Formatted and Obtaining Context Information for
Deferred Execution Custom Actions in the Windows Installer SDK Help.
Guidelines for Custom Action Conditions

Place a custom action between conditional If Statements to run it only if a certain
condition is true. A condition can check whether the product is installed, the value of a
property is true, if specific system requirements are met, and more. See Conditions on
page 407 and Conditional Statement Syntax in the Windows Installer SDK Help.
To Run Only During Initial Installation

The Execute sequences under the Normal Installation mode run during initial installation
and later during maintenance and uninstall installations. To run a custom action during
the initial installation only, set its condition to NOT Installed. Installed is a Windows
Installer property that is true if the product is installed.
Example: If you add a custom action that opens a Readme file and set the action’s
condition to NOT Installed, then the Readme opens during initial installation, but does
not open during maintenance installations (reinstall, modify, and repair operations).
To Run Only During Uninstall

If the product is being uninstalled, the REMOVE property is set to All or ALL. To run a
custom action during uninstall only, set its condition to REMOVE~=”ALL”. (The ~ causes
the comparison to be case-insensitive.)
Guidelines for Nested Installation Custom Actions

You can call another installation from within the running installation with an Install MSI
custom action. Use this type of custom action to deploy or uninstall one product from
within the installation of another product. See Nested Installation Actions in the
Limitations
Nested installations are supported according to the Windows Installer specification.
While nested installations may sometimes be necessary, we do not recommend using
them because of the restrictions on their use. See a list of restrictions at the end of
Nested Installation Actions in the Windows Installer SDK help.
Usage
According to the Windows Installer SDK, Install MSI custom actions should be placed
between InstallInitialize and InstallFinalize of the main installation’s action sequence.
Install MSI custom actions must be set to run synchronously.
Example: Suppose your main installation, Main.MSI, has a button on a dialog that, if
clicked, installs Second.MSI. You can use an Install MSI custom action to run the second
.MSI. Then you can use another Install MSI custom action to provide for uninstallation if
the main installation is uninstalled.

Using MSI Script
To specify the circumstances in which a nested .MSI is called, set conditional If

Statements around the Install MSI custom action in the sequence. See Guidelines for
Custom Action Conditions on page 480.
Note
Getting a nested installation to install is straightforward, but getting it to uninstall
properly when the calling application is uninstalled requires that you add 2 custom
actions. Set the first custom action to call the nested installation, and set its condition to
NOT Installed (Custom Action Location dialog). Set the second custom action to call the
nested installation also, set its Property Settings field to REMOVE=ALL (Custom Action
Target dialog), and set its condition to REMOVE~=”All”.
With this type of custom action, you can call only Windows Installer installations. To call
an installation that was created with the Wise Installation System or WiseScript Editor,
use a Run WiseScript custom action. See WiseScript Editing Tools on page 473. To call
an installation that was created with any other installation technology, use an Execute
Program custom action type.
A nested installation file can be accessed from 3 different locations:
z It can be stored within the main installation file. See Install MSI From Installation on
page 505.
z It can be distributed along with the main installation file. See Install MSI From
Relative Path on page 506.
z It can be an installed or advertised application that already exists on the destination

computer. See Install MSI From Destination on page 504.
The return values for nested installation actions are the same as for other custom
actions. See Custom Action Return Values in the Windows Installer SDK Help.
Guidelines for Calling VBScripts and JScripts

You can create a custom action that calls a JScript or VBScript file that you’ve authored.
You cannot pass parameters to JScript or VBScript. You must use your script to read and
write properties to the installation—your script can access the current installation
session. The exceptions are the Call JScript From Embedded Code and Call VBScript
From Embedded Code. They let you store the script inside the custom action and resolve
formatted property names and other references. Make sure the destination computer
contains the runtime for JScript or VBScript.
You can call scripts using custom actions, but you must author the JScript or VBScript.
The built-in Macro Editor is not meant to author JScripts and VBScripts that you call from
custom actions. For help authoring the script, see the following topics in the Windows
Installer SDK Help:
Scripts
Obtaining Context Information for Deferred Execution Custom Actions
Downloading an Installation From the Internet
Return Values of JScript and VBScript Custom Actions
How do I access the current installer session from inside a custom action?
Guidelines for Calling .DLLs

There are 2 types of custom actions that call .DLLs from an installation: Call DLL Custom
Actions and Call Custom DLL Custom Actions.

Using MSI Script
Call DLL Custom Actions

Two custom actions—Call DLL From Installed Files, Call DLL From Installation—use the
Windows Installer method for calling .DLLs, which does not allow you to send any
specific parameters to the .DLL. The only parameter you can send is the handle (of type
MSIHANDLE) for the current installation session. From within your .DLL, you must use
Windows Installer function calls to access the current installer session and database
properties. Also, the return value for the .DLL is limited to a constant specifying whether
the .DLL call was successful. See Custom Action Return Values in the Windows Installer
SDK Help. Your function declaration statement should look something like this:
UINT__stdcall CustomActionName(MSIHANDLE hInstall)
To write your .DLL function according to Windows Installer guidelines, see the following
topics in the Windows Installer SDK Help:
Dynamic-Link Libraries
How do I access the current installer session from inside a custom action?
Custom Action Type 1
Custom Action Type 17
Call Custom DLL Custom Actions

Three custom actions—Call Custom DLL From Installation, Call Custom DLL from
Installed Files, Call Custom DLL From Destination Computer—allow variable parameter
lists to be sent to the .DLL. These actions are passed through a Wise .DLL. This method
for calling .DLLs is an alternative to the Windows Installer method. This method works
with the way you typically code .DLL functions, and does not require you to code your
functions according to Windows Installer guidelines. However, if you use this method,
you should be aware that your .DLL call gets passed through a Wise-created .DLL that
handles the passing of parameters. A Wise-created custom action is added to the
installation to enable this passing of parameters. See Custom Actions That Are Added
Automatically on page 483.
In the User Interface or Execute Immediate sequences, you can send Windows Installer
properties to the .DLL function as parameters. The property’s current value is passed to
the function, and, if the function changes that value, the new value is put into the
corresponding property.
In the Execute Deferred sequence, the number of properties you can access is limited.
You can only access UserSID, CustomActionData, and ProductCode. CustomActionData
is filled with the property value of any Windows Installer property that has the same
name as the Custom Action. See Obtaining Context Information for Deferred Execution
Custom Actions in the Windows Installer SDK Help.
Debugging a Call Custom DLL Custom Action

You can debug .DLL functions while you are running an installation. Debugging a .DLL is
different from using the Debugger for Windows Installer, which shows the runtime
environment of the .MSI. Debugging a .DLL shows your .DLL code in Microsoft Visual
Studio. The following are requirements for using .DLL debugging:
z You authored the .DLL and have its source code on your computer.
z You have Microsoft Visual Studio installed.
z You are using one of the Call Custom DLL custom action types.
z MSDEV.EXE is in your path for debugging.

Using MSI Script
To enable debugging, use Setup Editor > Product tab to set the property named
_WiseDebugMode to 1. Then test or run the installation. Microsoft Visual Studio opens
and attaches to the installation process, and a breakpoint is invoked near the start of
your .DLL. You need to step a few times to get out of Windows Installer compiled code
and into your .DLL code.
Note
The debugging method described above only works with the Call Custom DLL custom
action types. It does not work with the Call DLL custom action types.
Launching a Custom Action from a Dialog

You can use a control on a dialog to launch a custom action. Example: You can set a
button so that if the end user clicks it, the custom action runs.
2. From Installation Mode, select All Custom Actions.
3. Create a new custom action and configure it normally, but mark No Sequence on
the Location tab.
The action is not added to any sequence.
4. In Setup Editor > Dialogs tab, right-click a dialog and select Add > Button.
Make sure the button is not on top of a graphic. You can add other controls besides
buttons.
5. On the Control tab of the button’s Properties dialog, enter the label for the button in
the Control Text list box.
6. On the Events tab, in the Publish Events group box, click Add and complete the
dialog:
Event
Select DoAction.
Argument
Enter the name of the custom action. The name is case-sensitive.
When the installation is run, the button you added appears on a dialog. When the end
user clicks the button, the custom action you specified is run.
Custom Actions That Are Added Automatically

Wise for Windows Installer provides several custom actions to add functionality that is
not available with Windows Installer’s standard actions. When you use certain features,
such as custom actions that call a .DLL, Wise custom actions are added to the
installation. Removing the Wise custom actions might cause problems with the
installation.

Using MSI Script
Custom Action Purpose

ConfigureWebUI z Inspects the destination computer to see if the Web installation can be
installed.
z Loads all the information out of the tables and configures the properties
needed to properly display the Web dialogs based on the destination
computer.
z Populates the list of existing Web sites that appears in the Web dialogs
when installing to an existing site.
z Checks for WISE_CONFIG_INPUT_PATH and

WISE_CONFIG_OUTPUT_PATH to determine if Wise for Windows
Installer should generate or read in settings to or from a configuration
file.
DiagnosticAppSearch Enumerates the entries in the AppSearch table and evaluates the
expressions using the MSIEvaluate Property function. It then retrieves the
value of the property and reports the results.
DiagnosticCheckDiskSpace Evaluates the disk costing and identifies computers that don’t meet the
requirements. The MsiVerifyDiskSpace function calculates the costing and
validates the amount of disk space. The following properties are used to
display the amount of disk space required and available on the destination
computer:
z PrimaryVolumePath
z PrimaryVolumeSpaceAvailable
z PrimaryVolumeSpaceRequired
z PrimaryVolumeSpaceRemaining
DiagnosticCheckDotNet Determines if .NET is required by this installation.
The Preflight Instrumentation determines if this check is required by

checking the MsiAssembly table for entries with 0 in the Attributes column. If
the check is not required, the Preflight Instrumentation does not insert this
check.
The test first ensures that there is a .NET assembly in the package. It then
retrieves from the registry the versions of .NET that are installed. If a
version of .NET is installed, it returns success and lists the versions installed.
If no version is installed the test fails. This check is inserted after the launch
condition check.
DiagnosticCheckExecuteLocally Evaluates type 34 or type 50 custom actions, which launch a file that is
expected to exist on the destination computer. Once the test obtains the
application path and ensures that it is valid, it calls the load library to ensure
the application can be loaded and returns success if the application
succeeded, failure if not.
DiagnosticCheckInUseFiles Tells the user how many files in the preflight installation are in use. The
message it returns is: Checked x files (OCX, EXE, and DLL files only), y are
in use.

Using MSI Script

DiagnosticCheckLaunchCondition Determines which launch conditions succeed and which fail. It enumerates
the LaunchCondition table and evaluates the condition using the
MsiEvaluateCondition API function.
During preflight instrumentation, Wise for Windows Installer determines if

any actions were removed in the InstallExecuteSequence before the
LaunchCondition action. If actions were removed, Wise for Windows Installer
cannot determine if the launch condition failed because of the removed
action or because of the condition. Preflight instrumentation sets the
property WISEDIAGLAUNCHWARN to 1 to indicate that Wise for Windows
Installer cannot determine the reason the launch condition failed.
DiagnosticCheckPatchExistence Based on the patch GUID, checks if the patch is already installed. If it is, it
returns a failure; otherwise, the test passes.
DiagnosticFileAssociationConflict Processes the Extension table and checks the registry for support for each
extension. This test opens the registry key for the extension. If the key
exists, then the extension is already registered. The existing value of the key
is compared with the ProgId to be registered; if they match, the same
application re-registers the same extension. If they do not match, the
application being installed overwrites the existing extension. If the key is
empty, the extension is registered but no application is associated with it.
DiagnosticLaunchWeb During Preflight Instrumentation, extracts URLs from the DisplayURL,
DownloadFile, and PostToHttp custom actions. It puts them in a table,
WiseUrlDiag, which is processed on the destination computer.
First, the test ensures that the connection can be opened to the specified
URL; then, the content is downloaded. The test then translates the result
into text.
DiagnosticManagedFileCheck Ensures that files that have been distributed throughout the environment are
known and tested. This test ensures that a given computer is in a well
known, managed state and that testing and conflict management operations
are not invalid in the production environment.
DiagnosticMarkBeginRun Indicates the beginning of the preflight test. Also determines if the
application that the preflight package is testing is already installed.
DiagnosticMarkEndRun Indicates the end of the preflight test and that the .MSI was fully processed.
Preflight Analysis uses the DiagnosticMarkEndRun test to determine if a run
is incomplete.
DiagnosticOpenDocExtCheck During Preflight Instrumentation, builds a list of document extensions from
the OpenDocument custom action and saves the list in the WiseExtDiag
table. On the destination computer, checks the registry for support for each
extension.
This test tries to open the registry key associated with the extension. If it
successfully opens the key, then an association exists. Otherwise, no
association exists.
DiagnosticPayloadInstalled Determines which files can be installed based on Windows installer file
versioning rules. The message it returns is: There are x files in this
installation, y files will be installed.

Using MSI Script

DiagnosticSecurityCheckFileRead Iterate through the files or registry keys and values that can be installed by
the installation and query the system for permissions to create, access, and
DiagnosticSecurityCheckFileWrite
update files or values.
DiagnosticSecurityCheckRegistry
Build a list of all securable objects from the File and Registry tables. For
Read
objects that exist, the test reads the security descriptor. For each profile on
DiagnosticSecurityCheckRegistry the system (read tests) or the installer’s account (write tests), the test reads
Write each security descriptor’s access control list and determines the user’s level
of access to the object. For objects that do not exist (Example: objects that
will be installed), the parent object’s access control list is used to determine
the access level. The test also reads and applies information from the
LockPermissions table to gather additional security information (read test
only).
ModifyXMLFiles Performs variable replacement within an .XML file.
PopulateVirDirs Populates the list of existing virtual directories for a given site when
installing to an existing virtual directory.
SetPatchMode Sets the REINSTALL property to the list of features in the previous version of
the user’s application and sets the ADDLOCAL property to the list of features,
if any, that were added to the installation in the new version of the
application. This action is added to all installations but affects only
installations that use patching.
SetPatchReinstallMode Sets the REINSTALLMODE property to “omus” (the Windows Installer
default) for patches. See REINSTALLMODE Property in the Windows Installer
SDK Help. This action is added to all installations but affects only
installations that use patching.
SetWizardProperty Determines what user interface wizard to display in the maintenance mode.
SetWizardProperty1 Determines what user interface wizard to display in the regular installation
mode.
WiseAltStartup When you add a custom action that calls a .DLL with parameters, this action
is added to save the current state of properties for use by the custom actions
running in deferred mode.
WiseCleanup When you add a custom action that calls a .DLL with parameters, this action
is added to clean up any temporary files left over from the custom action.
WiseFindSqlClientTools Sets the property WiseOsqlCmd to the command line to launch the Osql tool.
WiseGetASPNETUser Sets Windows Installer properties (ASPNET1.0_USER, ASPNET1.1_USER,
and ASPNET_USER) containing the names of the ASP.Net users. These can
be used to grant access to a user during installation.
WiseGetDotNetVersion Sets the property DOTNETFX to 1 if at least one version of .NET framework is
installed. Also sets various properties to 1 to indicate which versions of .NET
framework are installed (Example: DOTNETV1.0.3705).
WiseGetIEVersion Sets Windows Installer properties containing the version of Internet Explorer
installed on the destination computer. These can be used for launch
conditions to ensure that the computer has a required version of Internet
Explorer installed. IEVERSION contains the version in simplified form, and
IEVERSIONEX contains the complete version.

Using MSI Script

WiseGetIISFeaturesEnabled Sets properties (CGIENABLED, ISPAIENABLED, ASPENABLED,
ASPDOTNETENABLED, SSIENABLED, IDCENABLED, FPEXTENABLED, and
WebDAVENABLED) to show which features are enabled in IIS. This is useful
for setting launch conditions to ensure that the destination computer has the
required environment for the installation.
WiseGetIISVersion Set a property with the major IIS version (IISVERSION).
WiseGetSQLServers Uses the WiseOsqlCmd property to call osql to get the list of available SQL
servers. Then it reads the property WiseSqlParam to get the name of a
property that is used by a combo box in the ComboBox table. It then fills
that combo box with the list of SQL servers.
WiseGetSQLServerVersion Sets the property SQLSERVERVERSION to the version of SQL Server (or
MSDE) installed on the destination computer.
WiseIISValidateInput Validates input for the Web dialogs. (Example: It verifies that port numbers
are within range and IP addresses are formatted correctly.)
WiseNextDlg Determines the dialog to display when the end user selects the Next button.
WisePrevDlg Determines the dialog to display when the end user selects the Back button.
WiseRegComPlus Registers (on installation) or unregisters (on uninstall) MTS/COM+
components that are specified on MTS/COM+ page.
WiseSingleFileCheck Adds functionality for creating single-file .EXE installations. It removes
cached copies of the .MSI that are extracted during uninstalls.
WiseSQLCallDLL Reads a file of SQL commands and executes them. This is how Wise for
Windows Installer executes SQL scripts on the SQL Scripts page.
WiseStartup When you add a custom action that calls a .DLL with parameters, this action
enables parameter passing for actions that call a .DLL file and extracts the
necessary Wisescript .EXE and .DLL files.
WiseTestSqlConn Reads the property WiseSqlParam to get the names of properties to use for
the SQL connection test. It then reads those properties to get the user
name, password, and so on, and tries to connect to the SQL server. If it is
successful, it sets the value of the last property in WiseSqlParam to the full
connection string. If it fails, it sets the property WiseSqlError to an error
message.
WiseUpgradeCheck When you add upgrade information to the Upgrades page, this action is
added to work around issues where the Windows Installer runtime does not
detect previous versions of the application.
WiseUpgradeCheckEx When you add upgrade information to the Upgrades page, this action is
added to work around issues where the Windows Installer runtime does not
detect previous versions of the application.
WiseVirtDirCallDll Creates, modifies, or removes the appropriate Web sites and virtual
directories based on the XML generated by WiseWriteWebXmlDll.
WiseWriteWebXMLDll Generates XML for operations that must take place during the installation,
based on table information and properties set on the Web dialogs. The
generated XML is stored in the registry under a Wise subkey of the
installation’s uninstall key in HKEY_LOCAL_MACHINE.

Using MSI Script
Troubleshooting Custom Actions

If a custom action doesn’t work:
z Try moving it to a different sequence, or to a lower position in the current sequence.
z Does the custom action require elevated privileges? If so, try running it in the
Execute Deferred sequence. On the custom action’s Properties tab, set the In-
Script Options drop-down to Deferred Execution - System Context.
z Make sure the custom action name is unique. To quickly survey your custom
actions, select All Custom Actions from Installation Mode.
z Does the custom action reference a Windows Installer property, such as REMOVE?
Windows Installer standard actions set Windows Installer properties. It could be that
the property your custom action is referring to is not set yet. Use the debugger to
discover whether the property is set at the point where you expect it to be set. Keep
moving the custom action down in the sequence until it works.
z Is the installation attempting to change restricted public properties? The ability to

do this depends on several factors. See Restricted Public Properties in the Windows
Installer SDK Help.

Chapter 23
Custom Action Reference
While Windows Installer provides standard actions that perform most functionality you
need in an installation, occasionally you might need additional functionality not available
in standard actions. In that case, Windows Installer supports a variety of custom
actions, which let you call code from other development environments, display a
message, download a file from a Web site, launch a Web page, post information over the
Internet to your organization’s server, run another installation, set directories, set a
feature state, set properties, and more. These custom actions let you add extensive
functionality to an installation without having to write the code yourself.
This section outlines each custom action and gives hints on using it effectively. For
technical details on custom actions, see Custom Actions in the Windows Installer SDK
Help. For help using the interface, see Using MSI Script on page 466.
Call Custom DLL From Destination

This custom action calls a .DLL file that already resides on the destination computer.
Tips
z You can send a variable parameter list to the .DLL.
z The .DLL should be common to all Windows computers, such as user32.dll.
A tutorial demonstrates this custom action in the Wise for Windows Installer Getting
Started Guide.
Note
Before being passed to Windows Installer, calls you make with Call Custom DLL actions
are passed through a .DLL that facilitates the passing of parameters.
Usage
Double-click the custom action and complete the Details tab:
z Custom Action Name

Enter a unique name that begins with a letter or underscore. It can contain numbers
and periods. It must not match the name of any Windows Installer standard action.
z DLL File
Specify a .DLL file that exists on the destination computer to call during installation.
Type the path to the .DLL as it will be on the destination computer, but use a
Windows Installer directory property (enclosed in brackets) to specify the beginning
of the path. You can use a predefined directory property, or a property representing
a directory you created in this installation. To see directories defined in this
installation, go to Setup Editor > Tables tab and click the Directories table.
Example: this specifies a .DLL in the System32 directory:
[SystemFolder]user32.dll

z Function Name
Type the name of the function within the .DLL file to call.
z Parameter List
In the parameter list, specify the parameters to send to the .DLL.
z Return Value Type

Select the data type of the return value that is returned from the .DLL.
z Returned Property
Type or select a property name. The return value of the function call will be put into
this property.
Also see:

Configuring .DLL Parameter Settings on page 492
Guidelines for Custom Action Location on page 478
Using the Custom Action Properties Tab on page 517
Using the Custom Action Location Tab on page 515
Call Custom DLL From Installation

This custom action stores a .DLL file in the Binary table of this installation file and calls it
during installation. Use this to call a .DLL that does not reside on the destination
computer. During installation, the .DLL is extracted to a temporary directory, is called,
and is deleted. It is not registered.
Tips
z Manage the .DLL on the Resources page, which reflects the Binary table.
Note
Usage

z DLL File
Specify a .DLL from your hard drive or local network to call during installation.
z Function Name
z Parameter List
z Return Value Type


z Returned Property
this property.
Also see:

Call Custom DLL From Installed Files

This custom action calls a .DLL file that is installed by this installation. Use this custom
action to call the .DLL during installation, while leaving the .DLL on the destination
computer as part of the installation.
Tips
z Before you add this custom action, add the file to be called to the Files page in
z Shaded areas of MSI Script indicate restricted placement for this custom action;
because this custom action calls an installed file, it must run after files are installed.
Note
Usage

z DLL File
Specify a .DLL file to call during installation. It must have already been added to this
installation.
z Function Name
z Parameter List
z Return Value Type

z Returned Property
this property.

Also see:

Configuring .DLL Parameter Settings

When you add a Call Custom .DLL custom action, use the DLL Parameter Details dialog
to add parameters. To access this dialog, double-click one of the Call Custom .DLL
actions in MSI Script, and click the Add button.
In the Execute Immediate or User Interface sequences only, you can send Windows
Installer properties to the .DLL function as parameters. The property’s current value is
passed to the function and, if the function changes that value, the property is updated
back in the installation. To send a property, set Value Source to Property and type or
select the property name in Property Name.
To create a parameter, complete the DLL Parameter Details dialog:
z Parameter Type
This lists standard data types and two Windows Installer-specific items. Check the
.DLL function for its required parameter data types. The option MsiHandle to
Install gives you the handle hInstall, which is a handle to the running installation;
the option MsiHandle to Database gives you the handle hDatabase, which is a
handle to the running database. Some Windows Installer function calls and
database calls require these handles as parameters.
z Value Source
A parameter’s value can be set from a Windows Installer property, a constant, or a
constant with a NULL value. When you select a value source, the appropriate field
below becomes enabled.
z Property Name
If you selected Property in Value Source, enter or select a Windows Installer
property here to send as a parameter. This only works in the Execute Immediate or
User Interface sequences.
z Constant Value
If you selected Constant in Value Source, enter a constant value.
If you selected Constant with NULL value, the value of NULL is passed
regardless of the parameter type, so Not applicable is displayed for the
parameter type.
If you selected Formatted Constant in Value Source, enter a formatted text

string. This lets you pass the path of a file, feature, or directory to the custom
action. Example: To pass a file path, enter [#filekey] as the constant value. See
Formatted in the Windows Installer SDK Help.
Call DLL From Installation

This custom action stores a .DLL file in the Binary table of this installation file and calls it
during installation. During installation, the .DLL is extracted to a temporary directory, is
called, and is deleted. It is not registered.

Tips
z Manage the .DLL on the Resources page, which reflects the Binary table.
z You cannot send a variable parameter list to the .DLL. You can send only the handle
to the installation, which means the .DLL must be written specifically for Windows
Installer. To avoid these restrictions, use a “Call Custom DLL...” action instead.
Usage

z DLL File
Specify a .DLL from your hard drive or local network to call during installation.
z Function Name
Also see:

Custom Action Type 1 in the Windows Installer SDK Help
Call DLL From Installed Files

This custom action calls a .DLL file that is installed by this installation. Use this if the
.DLL should remain on the destination computer after installation.
Tips
z You cannot send a variable parameter list to the .DLL. You can send only the handle
to the installation, which means the .DLL must be written specifically for Windows
Installer. To avoid these restrictions, use a “Call Custom DLL...” action instead.
Usage


z DLL File
Specify a .DLL file to call during installation. It must have already been added to this
installation.
z Function Name
Also see:

Call JScript From Embedded Code

This custom action runs JScript code that is embedded inside this custom action.
Tips
z The script is limited to 255 characters; use other JScript custom actions for longer
scripts.
z The destination computer must contain the script’s runtime.
Usage

z Run Script in Win64 Process

Mark this if the script file is 64-bit. If the script file is 32-bit, leave this cleared.
(Available only in 64-bit installations.)
z Enter the JScript to execute
z Type or paste the script text. Code elements, such as function names, declarations,
and values, are color-coded. You can use bracketed property names, table keys,
environment variable references, and other special substrings. See Formatted in the
Also see:


Call JScript From Installation

This custom action stores a JScript file in the Binary table of this installation file and runs
it during installation. During installation, the JScript file is extracted to a temporary
directory, is run, and is deleted.
Tips
z Manage the file on the Resources page, which reflects the Binary table.
z Use the script to read and write properties to the installation.
Usage

z Script File
Specify a script file from your hard drive or local network to call during installation.
z Script Function Call

(Optional.) Type the name of the function within the script to call.

Also see:

Call JScript From Installed Files

This custom action runs code from a JScript file that is installed by this installation. Use
this to call the script file during installation, while leaving the file on the destination
Tips

Usage

z Script File
Specify a script file to call during installation. It must have already been added to
this installation via the Files page.


Also see:

Call JScript From Property

This custom action runs JScript code that is stored inside a Windows Installer property.
You might store the script in a property if part or all of the script needs to be generated
dynamically based on end user input or system configuration.
Tips
z The script is limited to 32 Kb, which is the size limit for Windows Installer properties.
Usage

z Property
Specify a property that stores the script, either by selecting a property or typing a
new property name. Elsewhere in the installation, you must provide a mechanism
for populating this property with the script text.



Also see:

Call VBScript From Embedded Code

This custom action runs VBScript code that is embedded inside this custom action.
Tips
z The script is limited to 255 characters; use other VBScript custom actions for longer
scripts.
z The destination computer must contain the VBScript runtime.
Usage


z Enter the VBScript to execute
z Type or paste the script text. Code elements, such as function names, declarations,
and values, are color-coded. You can use bracketed property names, table keys,
environment variable references, and other special substrings. See Formatted in the
Also see:

Call VBScript From Installation

This custom action stores a VBScript file in the Binary table of this installation file and
runs it during installation. During installation, the VBScript file is extracted to a
temporary directory, is run, and is deleted.

Tips
z Manage the file on the Resources page, which reflects the Binary table.
Usage

z Script File
Specify a script file from your hard drive or local network to call during installation.


Also see:

Call VBScript From Installed Files

This custom action runs code from a VBScript file that is installed by this installation.
Use this to call the script file during installation, while leaving the file on the destination
Tips
Usage


z Script File
Specify a script file to call during installation. It must have already been added to
this installation via the Files page.


Also see:

Call VBScript From Property

This custom action runs VBScript code that is stored inside a Windows Installer property.
You might store the script in a property if part or all of the VBScript needs to be
generated dynamically based on end user input or system configuration.
Tips
z The script is limited to 32 Kb, which is the size limit for Windows Installer properties.
z To use this option, you must also provide some mechanism for populating the
property with the script text.
Usage

z Property
Specify a property that stores the script, either by selecting a property or typing a
new property name. Elsewhere in the installation, populate this property with the
script text.



Also see:

Display Message
This custom action displays a message to the end user. You can also use it for debugging
by displaying the value of properties while the installation runs.
Tips
z If this custom action is within a condition, the message is displayed only when the
specified condition is met.
Example: You could display a message if end users marked a checkbox on a dialog.
You would associate the checkbox with a property and then set up a condition to
check if the property was true. For information on conditional blocks, see If
Statement on page 504.
z You can use formatted text strings, such as bracketed property names, in Message
Title or Message Text. However, formatted text strings only work in the Execute
Immediate or User Interface sequences. See Guidelines for Custom Action Location
on page 478 and Formatted in the Windows Installer SDK Help.
Usage
Double-click the custom action and complete the dialog:
z Message Title
Enter text to be displayed in the title bar of the message dialog.
z Message Text
Enter the text to be displayed in the message dialog. Press Ctrl+Enter to add line
breaks in the displayed text.
z Message Icon
Select an appropriate icon for your message dialog.
Also see:
Remark on page 509

Download File From Internet

This custom action downloads a file from the Internet.
Tips
z If you place this action in the User Interface or Execute Immediate sequences, you
can use formatted text strings, such as [INSTALLDIR], in the Source URL and
Destination Directory fields. See Formatted in the Windows Installer SDK Help.
cannot display progress bar text.

z If you place this action in the Execute Deferred sequence, you must hard-code the
destination and source paths.
z Downloaded files are not uninstalled when the product is uninstalled because
Windows Installer only uninstalls files installed with standard actions, not custom
actions.
Usage
z Source URL
Enter the URL of the file to download, including the name of the file.
Example: http://www.site.com/readme.pdf.
z Destination Directory
Specify the file path, including file name, on the destination computer where the file
should be downloaded. Example: [INSTALLDIR]readme.pdf.
z Error Handling
Determine how errors in the download operation are handled.
Ignore Errors
The installation continues regardless of errors.
Abort Installation
The installation stops if the download operation cannot be completed.
z Progress Bar Text

Enter the text to display in the progress bar during the download. Progress bar text
appears only if this custom action is in the Execute Deferred sequence. You cannot
enter properties or formatted text. The field length is limited to 64 characters and 2
lines.
Also see:
Launch Web Page on page 507

Post Data to HTTP Server on page 508
End Statement
The End Statement action marks the end of an If action, which specifies conditions to
attach to an action or a set of actions. The End Statement action takes no parameters,
and double-clicking it in the Actions list immediately inserts it into the script above the
selected script line.
Also see If Statement on page 504.
Execute Program From Destination

This custom action calls an .EXE file that already resides on the destination computer.
Use it to call .EXE files that are common to all Windows computers, such as
notepad.exe. A tutorial demonstrates this custom action in the Wise for Windows
Installer Getting Started Guide.

Usage

z Working Directory
Using a non-bracketed Windows Installer directory property (Example:
INSTALLDIR), specify the working directory of the .EXE file to call. When the .EXE
file is run on the destination computer, its current working directory is set to the
directory you specify here. This must be set to a directory that can be specified with
a Windows Installer directory property, which are listed when you click Browse.
z EXE and Command Line

Using a bracketed Windows Installer directory property to specify location, enter the
full path to the .EXE file that exists on the destination computer. Example:
[INSTALLDIR]TextEditor\MyEditor.EXE. If the .EXE file is registered or is in the PATH
environment variable, you might not need to type the entire path. Example: To
specify Notepad, just type NOTEPAD.EXE, because it is in the PATH variable.
(Optional) To pass command line options to the .EXE file, enter them after the name
of the .EXE file. The command line options are executed in relation to the working
directory. Example: If you type INSTALLDIR in Working Directory, and type
NOTEPAD.EXE README.TXT in this field, the README.TXT file that is in INSTALLDIR
is opened.
Also see:

Execute Program From Installation

This custom action stores an .EXE file in the Binary table of this installation file and calls
it during installation. During installation, the .EXE is extracted to a temporary directory,
is run, and is deleted. You can manage the file you specify from the Resources page,
which reflects the Binary table.
Usage

z Executable File
Specify an .EXE file from your computer or local network. The .EXE file will be stored
in the Binary table of the installation.

z Command Line
(Optional) Enter any command line options to pass to the .EXE file.
Also see:

Execute Program From Installed Files

This custom action calls an .EXE file that is installed by this installation.
Tips
Usage

z Executable File
Specify the .EXE file to run. It must have already been added to this installation.
z Command Line
(Optional) Enter command line options to pass to the .EXE file.
On the Properties tab, In-Script Options is disabled for this custom action.
Also see:

Execute Program From Path

This custom action calls an .EXE file whose path is specified by the value of a property. It
is useful if the path to the .EXE file is dependent on end user input or system
configuration.
To use this option, you must provide a mechanism for setting a property with the value
of the .EXE path. Example: You could use the Set Property custom action and set a path
based on the operating system. Or you could use the System Search page to set a
property to the path of a found file.

Usage

z Property
Specify a property that will store the path and name of the .EXE. Select a property
or type a new property name.
z Command Line
(Optional) Enter command line options to pass to the .EXE file.
Also see:

If Statement
Use If Statements to set conditions on actions. An If Statement marks the beginning of
a If block, which is a conditional block of actions. The If block must be concluded by an
End Statement. If the condition specified in the If Statement is true, the actions inside
the If block are executed; if false, the actions are not executed. You can nest If
Statements to create complex conditions.
The condition you enter in the Condition field is subject to Windows Installer guidelines
for creating conditions. See Conditional Statement Syntax in the Windows Installer SDK
Help. To use the Condition Builder to create a syntactically correct Windows Installer
condition, click Build. See Creating Conditions With Condition Builder on page 411.
Also see:
Conditions on page 407

Using Conditions With Features on page 108
Install MSI From Destination

This custom action runs a Windows Installer installation that is already advertised or
installed on the destination computer (referred to as a nested installation). This is useful
for reinstalling or uninstalling an application that was originally installed with an Install
MSI custom action.
Tips
z The installation being called must already be advertised or installed on the
z You must know the product code of the installation to call.
z This custom action is not available in an Administrative Installation.
z The installation being called must be a Windows Installer installation.

z On the Properties tab, In-Script Options is disabled for this custom action and
Processing only allows synchronous execution.
z For best results, place this custom action in the Execute Immediate sequence after
the InstallFinalize action.
Usage

z Product Code
Either enter or copy and paste the product code of the nested installation. The
product code is stored in a property named ProductCode. To find the product code of
the nested .MSI, view its Product Code field on the Product Details page.
z Property Settings
Enter properties to set for the nested installation. You can set Windows Installer
properties or private properties. Example: To set the main installation directory for
the nested installation to be the same as for the current installation:
INSTALLDIR="[INSTALLDIR]"
If the directory represented by the property might contain spaces, as is typical with
the installation directory, enclose the property in quotes as shown above.
To set the nested installation to be advertised, enter:
ADVERTISE=ALL
To uninstall the nested installation, enter:
REMOVE=ALL
For a list of properties, see Property Reference in the Windows Installer SDK Help.
Also see:

Nested Installation Actions in the Windows Installer SDK Help
Install MSI From Installation

This custom action stores an .MSI in the Binary table of this installation and runs it
during installation (referred to as a nested installation). This is useful for deploying a
second application from within the main installation.
Tips
z Manage the .MSI on the Resources page, which reflects the Binary table.

Usage

z Installation to Run
Specify the .MSI to run from your computer or local network. The installation must
be in .MSI format, and must not include external compressed or uncompressed files.
z Property Settings
ADVERTISE=ALL
REMOVE=ALL
Also see:

Install MSI From Relative Path

This custom action runs an .MSI from the main installation (referred to as a nested
installation). This is useful to deploy or uninstall a second application from within this
installation.
This custom action assumes that both the main installation file and the nested
installation file are stored on the same installation media. Example: You could place the
main and nested installations on a CD. The path to the nested installation must be
specified using a relative path from the main installation.

Tips
Usage

z Installation to Run
Enter the relative pathname of the .MSI to run. Example: If this installation is
located at the top level of a CD (F:\), and the nested installation is at
F:\SubInstall\second.msi, enter the following:
SubInstall\second.msi
z Property Settings
ADVERTISE=ALL
REMOVE=ALL
Also see:

Launch Web Page

This custom action displays a Web page during installation using the end user’s default
browser.

In Web Page URL on the Launch Web Page dialog, designate the URL to launch during
installation. The URL must be complete. Example: http://www.wise.com.
Also see:
Download File From Internet on page 500

Post Data to HTTP Server on page 508
Open Document From Installed Files

This custom action opens a document installed by the installation. On the Open
Document From Installed Files dialog, specify the name of the file to open from this
installation.
Tips
Also see Guidelines for Custom Action Location on page 478.
Pause Installation
This custom action temporarily stops a sequence from executing. After the specified
number of seconds, the sequence continues running.
This action must be placed in the Execute Deferred sequence.
Usage
z Seconds to Pause
Number of seconds for the sequence to pause.
z Progress Bar Text

Text to display in the progress bar during the pause. You cannot enter properties or
other formatted text. The field length is limited to 64 characters and 2 lines.
Also see Guidelines for Custom Action Location on page 478.
Post Data to HTTP Server

This custom action posts information over the Internet to a Web server. Example: Use it
to record user registration information or other data.
Tips
z You must have an ASP or CGI program set up to accept data from HTTP POST
operations.

z The computer running the installation must have a valid Internet connection (such
as dial-up networking).
can use formatted text strings, such as [PROPERTY], in the Destination URL and
Text to Post fields. However, because of Windows Installer limitations, if you place
it in the Execute Deferred sequence, you must hard-code the destination and source
paths. See Guidelines for Custom Action Location on page 478 and Formatted in the
z Because of Windows Installer limitations, to display progress bar text to the user,
you must place the action in the Execute Deferred sequence.
z To give end users control over whether to post data to your HTTP server, put this
custom action in a conditional block. Set the conditional block so that it only posts
data if the end user has agreed to this posting. Example: Add a checkbox the user
marks to accept posting of data. Associate the checkbox with a property and set up
the conditional block to run if the property is true. For information on conditional
blocks, see If Statement on page 504.
Usage
z Destination URL
The URL of the CGI program or ASP page that will accept the posted data.
z Text to Post
The text to post should be one or more lines in the format field=data, where field is
the name of the field expected by the Web application, and data is the data to
populate the field. If a line does not appear to contain a field name followed by =, it
is assumed to be a continuation of the previous line, and the data on the 2 lines is
concatenated and sent with a single field identifier. For information on using
formatted text, see the tips above .
z Error Handling
Determines how errors in the posting operation are handled.
Ignore Errors
The script continues regardless of any errors.
Abort Installation
The installation stops if the posting operation cannot be completed.
z Progress Bar Text

Enter text to display in the progress bar while data is posted to the server. This
action must be placed in the Execute Deferred sequence for progress bar text to
work.
Also see:
Download File From Internet on page 500

Launch Web Page on page 507
Remark
The Remark action lets you put comments in sequences to document what is happening
in the script.

In Remark, type the comment. To place a blank line in the sequence, add a Remark
action, but leave Remark blank.
Run WiseScript From Destination

This custom action runs a WiseScript .EXE that already resides on the destination
computer. WiseScript editing tools are discussed in WiseScript Editing Tools on
page 473. Also see Examples of WiseScripts You Run From an .MSI on page 474.
If you use both WiseScript and Windows Installer technology, you can integrate them
with this custom action. Use this to leverage past WiseScripts or to gain access to
unique WiseScript technology.
Tips
z In the WiseScript, use special script actions—Get Windows Installer Property, Set
Windows Installer Property, and Evaluate Windows Installer Condition—to
communicate between the Windows Installer installation and the WiseScript. For
details, see documentation for your WiseScript editing tool.
z Access your WiseScript editing tool by selecting Tools menu > WiseScript. (In Visual
Studio: Project menu > WiseScript.)
z If the WiseScript being called uses a Set Windows Installer Property action, place
this custom action in the User Interface or Execute Immediate sequence.
Usage

z WiseScript .EXE File

Specify an executable file on the destination computer that was compiled in a
WiseScript editing tool. You must type a path to the file using a predefined directory
name, such as [CommonFilesFolder], to specify the location on the destination
computer. A trailing slash after a predefined directory name is not necessary.
Example: [INSTALLDIR]Directory\Setup.exe.
z Options button
This is disabled for this custom action.
z Command Line
(Optional) Enter the command line options to send to the .EXE. Example: Enter /s to
make the WiseScript run silently. The documentation for your WiseScript editing tool
lists valid command line options.
Also see:
Calling WiseScripts with Custom Actions on page 473


Run WiseScript From Installation

This custom action stores a WiseScript .EXE in the Binary table of this installation file
and runs it during installation. WiseScript editing tools are discussed in WiseScript
Editing Tools on page 473. Also see Examples of WiseScripts You Run From an .MSI on
page 474.
Tips
z Manage the file you specify on the Resources page, which reflects the Binary table.
Usage


Specify an executable file on your computer or network that was compiled in a
WiseScript editing tool. The file you select will be copied into the Binary table of this
installation. Optionally, you can use the Options button below.
z Options button
Browse for WiseScript

Select a WiseScript .EXE file on your hard drive or network and places its path
in the WiseScript .EXE File field.
Create New WiseScript

Open a new WiseScript in a WiseScript editing tool.
Edit Existing WiseScript

If you’ve specified a WiseScript .EXE in WiseScript .EXE File, and that .EXE
has a corresponding .WSE file with the same name in the same folder as the
.EXE, this option opens that .WSE file in a WiseScript editing tool. This option is
disabled if WiseScript .EXE File is empty or if a corresponding .WSE file does
not exist.
z Command Line

Also see:

Run WiseScript From Installed Files

This custom action runs a WiseScript .EXE that is installed by this installation. WiseScript
editing tools are discussed in WiseScript Editing Tools on page 473. Also see Examples
of WiseScripts You Run From an .MSI on page 474.
Tips
Usage


Specify an executable file contained in this installation that was compiled in a
WiseScript Editing tool. Optionally, you can use the Options button below.
z Options button
Browse for WiseScript

Select a WiseScript .EXE file on your hard drive or network and places its path
in the WiseScript .EXE File field.
Create New WiseScript

Open a new WiseScript in a WiseScript editing tool.

Edit Existing WiseScript

If you’ve specified a WiseScript .EXE in the WiseScript .EXE File field, and that
.EXE has a corresponding .WSE file with the same name in the same folder as
the .EXE, this option opens that .WSE file in a WiseScript editing tool. This
option is disabled if the WiseScript .EXE File field is empty or if a
corresponding .WSE file does not exist for the specified .EXE file.
z Command Line
Also see:

Set Directory
This custom action sets a new value for a directory property. Example: Set a new value
for a directory based on end user input during installation. A tutorial demonstrates this
custom action in the Wise for Windows Installer Getting Started Guide.
Tips
z For best results, place this action in the User Interface or Execute Immediate
sequence.
z On the Properties tab, the In-Script Options and Processing drop-down lists are
disabled for this custom action.
Usage

z Directory
Specify the directory to change the value of. It must be a directory you’ve added to
this installation or a predefined Windows system directory, which appears when you
browse. Do not enclose the directory property with brackets.
z Directory Value
Enter the new path of the directory. You can use property and directory names by
enclosing them in brackets. Example: To indicate a directory named Data in the
installation directory, enter:
[INSTALLDIR]Data
Also see:


Custom Action Type 35 in the Windows Installer SDK Help.
Set Feature State

This custom action sets the installation state of a feature at runtime. The installation
state determines how or whether a feature is installed. Example: Use this custom action
to omit features during upgrade of limited versions of the product.
On the Set Feature State dialog, select the feature from Feature, then mark an
installation state option for that feature.
Tips
z This custom action has restrictions on its placement, indicated by shaded areas in
the Installation Sequence.
z If you set a feature to run from source and the files are compressed, Windows
Installer sets the feature to run from the local drive.
z For information on how Windows Installer sets feature states when features share
components, see MsiSetFeatureState in the Windows Installer SDK Help.
Also see:
Configuring a Feature Using Its Drop-Down List on page 104

Configuring a Feature Using the Feature Details Dialog on page 105
Guidelines for Custom Action Location on page 478.
Set Property
This custom action sets a Windows Installer property. This custom action is useful for
setting a property based on end user input or on system configuration.
Tips
z For best results, place this action in the User Interface or Execute Immediate
sequence.
z On the Properties tab, the In-Script Options and Processing drop-down lists are
disabled for this custom action.
Usage

z Property
Select a property from the list, or enter a new property name. Do not enclose this
property name with brackets.

z Property Value
Enter the value to set the property to. Because this value is of the data type
Formatted, you can use property and directory names by enclosing them in
brackets. For information on formatted text strings, see Formatted in the Windows
Installer SDK Help.
Also see:

Terminate Installation
This custom action terminates the installation and displays a message explaining the
termination. Typically, you would place this custom action within a conditional block; see
If Statement on page 504.
Tips
z This custom action has restrictions on its placement, indicated by shaded areas in
the Installation Sequence.
z The Properties tab is disabled for this custom action.
Usage

z Termination Message
Enter a message to explain to the end user why the installation terminated. Use
plain text, formatted text strings, or enter an integer that is indexed to an entry in
the error table.
Also see:
Formatted in the Windows Installer SDK Help

Using the Custom Action Location Tab

The Location tab appears for custom actions only if you are working in the All Custom
Actions installation mode. The All Custom Actions installation mode lists all the
custom actions that are part of this installation, which are stored in the CustomAction
table. Also see All Custom Actions on page 469.

Note
The Location tab is an alternate way to perform tasks that you normally perform in the
User Interface, Execute Immediate, or Execute Deferred sequences. You can move and
copy custom actions by using editing functions in these sequences. The main use for this
tab is to click the No Sequence option, which causes this action to not run unless an
event invokes it.
z No Sequence
Omits the custom action from all sequences, and stores it in the CustomAction
table. If you mark this, the custom action is only invoked if you set an event to run
the custom action. See Launching a Custom Action from a Dialog on page 483.
If you clear No Sequence, enter the following information:
z Sequence
Select a sequence to which to add this custom action. The options here correspond
to the sequences available with each of the 3 installation modes.
z Location list box

This displays all the custom actions that are part of this installation. Click on an
action in the list box and click one of the following buttons:
Click Add to add the custom action to the sequence below the action you
selected.
Click Remove to remove it from the sequence.
Click Move Up and Move Down to specify where in the sequence the custom
action is stored.
z Condition
For this action to run only if a certain condition is true, enter a condition. In the User
Interface, Execute Immediate, and Execute Deferred sequences, the condition you
enter is displayed as an If Statement preceding the custom action. To use the
Condition Builder to create a syntactically correct Windows Installer condition, click
Build. See Creating Conditions With Condition Builder on page 411.
Using the Custom Action Location Tab for Merge

Modules
The merge module version of the Location tab only appears for custom actions if you are
working in a merge module (.WSM or .MSM file). It is a different version of the Location
tab than the one that displays in a standard installation (.WSI or .MSI file). Use this tab
to set the location for a custom action in a merge module. Also see All Custom Actions
on page 469.
Note
When you add a custom action to a merge module, you’ll notice that the Custom
Action Name field automatically contains the GUID of the merge module. You should
leave the GUID as part of the custom action name to ensure adherence to Windows
Installer guidelines for naming custom actions in merge modules.
Because a merge module is merged into a standard installation, you must specify where
the custom action should be merged into the action sequence of the standard
installation. To specify where this custom action is merged into the main action
sequence, set the following options:

z No Sequence
Clear this to add this action to an action sequence. If the action is not in an action
sequence, it is never executed.
If you clear the No Sequence, enter the following information:
z Sequence
Select a sequence to which to add this custom action. The options here correspond
to the sequences available with each of the three installation modes of a standard
installation (.WSI or .MSI file).
z Reference Action
This drop-down list contains all the standard Windows Installer actions from the
sequence that you selected in the Sequence drop-down list. This custom action,
when merged into a standard installation, will be placed relative to the action you
select in this list.
z Sequence Number
If the reference action you select above is not found, this custom action will be
placed using this sequence number. In most cases, you can ignore this field. You can
view sequence numbers for a particular sequence by viewing the sequence in the
Tables tab in Setup Editor.
In the Placement section, mark an option to specify where to place this action:
Before Action
Click this option to place this action before the Reference Action you selected
above.
After Action
Click this option to place this action after the Reference Action you selected
above.
z Condition
If you want this action to run only if a certain condition is true, enter a condition. In
the User Interface, Execute Immediate, and Execute Deferred sequences, the
condition you enter is displayed as an If Statement preceding the custom action. To
use the Condition Builder to create a syntactically correct Windows Installer
condition, click Build. See Creating Conditions With Condition Builder on page 411.
Using the Custom Action Properties Tab

The Properties tab appears on the details dialog for most custom actions. However,
sometimes options are disabled or display different choices based on what kind of
custom action you added and where you added it. In this dialog, you set options that
determine when and how the custom action is run.
In-Script Options
This determines when the custom action is executed. When Windows Installer runs the
installation, it first reads the action sequences and creates its own internal installation
script to follow, then later it executes that script. You can have the custom action
executed immediately when Windows Installer first encounters it, or later during
execution of the internal script. See Custom Action In-Script Execution Options in the

Note
The In-Script Options drop-down list is disabled if this custom action is located in the
User Interface or Execute Immediate sequences because both these sequences already
run in immediate execution mode, making this drop-down list redundant. It is disabled
for Set Property and Set Directory because they must be run in immediate execution
mode in order to work.
z Immediate Execution
If you place an action in the User Interface or Execute Immediate sequence, this is
set to Immediate Execution and is disabled, because those two sequences always
run in immediate execution. This action will be executed during Windows Installer’s
first pass through the installation database, before the internal script is generated
and executed. Actions in immediate execution mode can change properties; actions
in any type of deferred mode cannot. Actions in immediate execution mode always
run under User Context, which means that they run with the same privilege level as
the currently logged-in user. If the custom action needs to be run under a higher
privilege level, place it in the Execute Deferred sequence and set this field to
Deferred Execution - System Context.
Note
The following four options all apply to deferred custom actions, and are available
only if the custom action is placed in the Execute Deferred sequence. Otherwise the
drop-down list is disabled.
z Deferred Execution - User Context

Select this if the action should be executed later during installation, during the time
when all other system changes are performed by Windows Installer. This runs under
user context, so if the current user doesn't have elevated privileges, and the action
needs elevated privileges to succeed, it might fail. Use this option if the custom
action depends on a file that is installed with the installation. Custom actions that
change the system directly should be run in Deferred Execution. Deferred custom
actions cannot change properties in the Property table. See Deferred Execution
Custom Actions in the Windows Installer SDK Help.
z Rollback only
Select this if the action should be executed later, during installation of the rollback
script, which is invoked if the end user cancels the installation or if the installation is
unsuccessful. Use rollback actions to undo previous custom actions that made
changes to the system. Rollback actions run in deferred execution mode and cannot
run asynchronously. See Rollback Custom Actions in the Windows Installer SDK
Help.
z Commit only
Select this if the action should be executed later, during installation of the commit
script, which is invoked upon successful completion of the installation script.
Commit actions run in deferred execution mode. See Commit Custom Actions in the
z Deferred Execution - System Context

If execution of the custom action requires elevated privileges, set this option. You
must also set AlwaysInstallElevated keys in the registry. See AlwaysInstallElevated
in the Windows Installer SDK Help. This makes the custom action run as though it
were logged in as a system account, similar to the way services can log in as a
system account.

Note
User context and system context are relevant only on locked-down Windows NT,
2000, XP, and Server 2003 computers. Actions run in system context are run with
elevated privileges by the Windows Installer service. Actions run in user context are
run with the current user’s privileges.
Processing
The main installation thread can control the custom action thread in different ways.
Options in this drop-down list determine how the custom action thread is controlled. See
Custom Action Return Processing Options and Synchronous and Asynchronous Custom
Actions in the Windows Installer SDK Help.
The Processing options are not available if the custom action type is Set Property or Set
Directory and are limited to synchronous for Install MSI custom actions.
z Synchronous
Run the custom action synchronously to the main installation thread. Windows
Installer waits for the custom action to complete before continuing the main
installation. The exit code of the custom action must be 0 to indicate success. Use
this method for Windows Installer to wait for the success of the action before
continuing.
z Synchronous, Ignore exit code

Run the custom action synchronously to the main installation thread. Windows
Installer waits for the custom action to complete before continuing the main
installation. Use this option if success of the action is unnecessary to continue with
the installation. The exit code of the custom action is ignored.
z Asynch, Wait at end of sequence

Run the custom action asynchronously to the main installation thread. Windows
Installer runs the custom action simultaneously with the main installation. At the
end of the script, Windows Installer waits for the exit code from the custom action
before continuing. Use this if the installation is not dependent on completion of this
action, but you want to check the exit code. This option is not available for Install
MSI custom actions or if you selected Rollback Only in the In-Script Options list
above.
z Asynch, No wait
Run the custom action asynchronously to the main installation thread. This means
that Windows Installer runs the custom action simultaneously with the main
installation. Windows Installer does not wait for completion of the custom action and
does not check the exit code. This option is not supported for Install MSI custom
actions. This option is not supported for Install MSI custom actions or if you selected
Rollback Only in the In-Script Options list above.
Scheduling Options
If you add the custom action to both the UI Sequence and the Execute Sequence, but
you want to limit the number of times it actually runs, select an option here. See Custom
Action Execution Scheduling Options in the Windows Installer SDK Help.
z Always Execute
Select this to have the action execute in all sequences that you added it to.
z Run first time

Select this to have the custom action execute only the first time Windows Installer
encounters it.

z Run once per process

Select this option to prevent the custom action from running twice if the custom
action modifies property or database data. Use for custom actions in either Execute
sequence that should not run if the installation is running in silent mode.
z Run only if UI sequence was run

Select this option if the custom action should run only if either Execute sequence is
run following User Interface sequence.
Progress Bar Text

Enter the text to display with the progress bar while the action runs. The action must be
placed in the Execute Deferred sequence for the text to be displayed. You cannot enter
properties or other formatted text; see Formatted in the Windows Installer SDK Help.
The field length is limited to 64-characters and two lines.

Chapter 24
Windows Installer and .NET Technologies
Wise products integrate closely with Microsoft Windows technologies. The installations
you create are in Microsoft Windows Installer format and are run on the destination
computer by the Windows Installer engine.
Wise for Windows Installer is an authoring environment for Microsoft’s Windows Installer
service. It also supports Microsoft’s .NET Framework. Although a comprehensive
discussion of Windows Installer and .NET is not possible here, it is important that you
understand some basic concepts about Windows Installer and .NET, and how Wise for
Windows Installer supports them.
Topics include:
z About Microsoft Windows Installer.
z About Microsoft .NET Technology.
About Microsoft Windows Installer

To create a streamlined process for installing and managing applications, Microsoft
developed the Windows Installer service. It consists of a set of guidelines, an Application
Programming Interface, and a runtime service to help make application installation and
ongoing management part of the basic Windows system services. The Windows Installer
service is not an installation-authoring tool, but rather an installation engine and rule set
for installation packages. The Windows Installer engine resides on the destination
computer, reads the installation database (.MSI), and performs the installation and any
subsequent management, such as self-repair.
Instead of an installation executable (such as setup.exe), your installation is in the form

of a database file (.MSI), which contains instructions and can also enclose installation
files. Because this database uses highly structured, uniform data tables, there is 100%
accountability of where each file is installed and a thorough log of which files belong to
which applications. As a result, individual files can readily be restored to repair damaged
applications.
Each table is dedicated to a particular type of installation information such as Class,

Components, Features, Files, Execution Sequence, and Registry. Certain logic is built in
to the Windows Installer engine, such as when to prompt for a reboot, disk space
checking, and file version replacement rules. When an .MSI is opened, msiexec.exe
reads the data stored in the database and builds an internal script to follow. It then
performs the actions in the script to complete the installation.
Microsoft Windows Installer has its own help system, which contains detailed
information on every aspect of Windows Installer. Access the Windows Installer SDK
Help by selecting Help menu > Windows Installer SDK Help. (In Visual Studio: Help
menu > Wise Help > Windows Installer Help.)

Frequently Asked Questions About Microsoft Windows Installer

How is Windows Installer different from Wise for Windows Installer?
Microsoft Windows Installer is a Microsoft technology for writing, managing, and
installing applications. The Microsoft Windows Installer service, which resides
permanently on the destination computer as part of the operating system, includes a
Windows Installer executable named msiexec.exe. The executable runs installation files,
called Windows Installer database files (.MSI files), that are written especially for
Windows Installer.
Wise for Windows Installer is an installation authoring application for creating Windows
Installer database files. When you build an installation in Wise for Windows Installer,
you populate tables within a Windows Installer database file. The Wise for Windows
Installer user interface exposes the functionality offered by Windows Installer.
How are files stored on the destination computer?

When an application is installed on the destination computer, Windows Installer stores
copies of .MSI files in a hidden directory named Installer, which is in the Windows or
Winnt directory. These copies are used if the end user attempts to remove, repair, or
reinstall the application from the Add/Remove Programs dialog. However, these .MSI
files do not necessarily store application files, so if the end user attempts a repair or
reinstall, Windows Installer might prompt the end user for the original installation source
(shared network directory or CD).
If you output an.MSI file compressed in an .EXE file, Windows Installer uncompresses a
copy of the .MSI into \Program Files\Common Files\Wise Installation Wizard\ on the
destination computer. These .MSI files do not have to be left on the destination
computer, but if they are, the end user does not need the source media to repair or
reinstall an installation.
What if your end users don’t have Windows Installer?

The Windows Installer runtime is built into the Windows Server 2003, Windows 2000,
Windows XP, and Windows Me operating systems. Because the Windows Installer
runtime is not available on some target systems, Wise for Windows Installer lets you
create an .EXE file that installs the Windows Installer runtime before beginning the
application installation. Use this option if your target computers have older operating
systems. See Setting Build Options for a Release on page 185 and Adding Prerequisites
to a Release on page 186.
What is advertisement?
Advertisement is a way to deploy applications in large organizations. It is available with
Windows Installer, but only for supported platforms. (See Platform Support of
Advertisement in the Windows Installer SDK Help.) During installation development, you
can set features or entire applications to be advertised. End users invoke advertised
items by launching a shortcut, opening a file with an advertised file extension, or by
accessing any other entry point.
If a feature or application is advertised, only the entry points to the feature or

application are installed. Example: If the application Microsoft Word is advertised to
destination computers, the end users still see the Microsoft Word icons in their Start
menu and Desktop, and the file extension .doc is registered, but none of the files that
make up Microsoft Word are actually installed.

How does Wise for Windows Installer support advertisement?

In Wise for Windows Installer, you can set default advertisement on a per-feature basis
on the Feature Details dialog. If you advertise features, however, you must include
Windows Installer function calls within the application to initiate a feature-level
installation of the necessary files when an advertised entry point is invoked.
For information on coding an application for advertisement, see Advertisement in the

Windows Installer SDK Help. Microsoft Windows Installer provides command lines for
advertising an entire application. See Command Line Options in the Windows Installer
SDK Help.
How do I use advanced features?

Most advanced Windows Installer features require you to use Windows Installer function
calls in an application. Other features require specific operating systems, such as
Windows 2000 or Windows 2000 Server.
Example: You could add a menu option for a spell checker, but design the installation so
that the files necessary for the spell checker are not installed by default. When the end
user selects the spell checker menu option, your code can use Windows Installer
functions to install the necessary files on demand.
While Wise for Windows Installer can help you bundle an application into an installation
package, it cannot help you design, develop, and code an application to use Microsoft
Windows Installer APIs. Use the Windows Installer Software Development Kit (SDK)
online help, which is installed with Wise for Windows Installer, as a reference for coding
Windows Installer functionality into an application.
Also see About Microsoft Windows Installer on page 521.
Working With Components and Features

In Microsoft Windows Installer terminology, a feature is a distinct part of an application’s
functionality, which end users can usually choose to install. (Example: A feature could be
a spell-checker, a thesaurus, or a collection of clip art.) You create and organize features
yourself. See Strategies for Organizing Files Into Features on page 101.
A component is a basic installation unit that is always installed or uninstalled as a

coherent piece. Windows Installer tracks each component by the component ID, a GUID.
(See About GUIDs.) Only one instance of a component is installed on a destination
computer, allowing several features or applications to share the same component
without installing multiple instances of it. Components include single files, a group of
related files, COM objects, registry keys, shortcuts, resources, libraries grouped in a
directory, or shared pieces of code such as DAO. When you add files to an installation,
components are created based on a component rule set you select. (Example: You can
create a new component for each new file added to the installation, or you can group
related resources, such as help files, into one component.) For details, see Component
Rules on page 57. You can reorganize components or create them manually by using
Setup Editor > Components tab.
For information on how Windows Installer handles components and features, see the
following topics in the Windows Installer SDK Help:
Windows Installer Components

Component Management

Components and Features

Organizing Applications into Components
About GUIDs
GUID stands for globally unique identifier. It is a data type comprised of a text string
that represents a Class identifier (ID).
The purpose of a GUID is to provide a unique identifying string that differentiates

products, packages, components, features, upgrades, patches, and so on. By reading
GUIDs, Windows Installer can determine what is installed on a destination computer and
take appropriate action.
Examples:
z When you create an upgrade, you enter the upgrade codes, which are GUIDS, for
the versions of the application that can be upgraded. Then during installation,
Windows Installer searches the destination computer for these upgrade codes to
determine whether an upgrade should occur.
z Each component of an application has an assigned GUID. You can use the System
Search page to quickly search for components on the destination computer to
determine if a previous version exists.
A GUID must be in the format: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} where

X is a hex digit (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). Wise for Windows Installer generates
GUIDs whenever necessary, using an algorithm that reduces the chances of generating a
duplicate GUID to almost zero. If you need to change a GUID, Wise for Windows
Installer provides a Generate button that generates a new, valid GUID.
Caution
Do not attempt to create a GUID by typing random hex characters.
About Microsoft .NET Technology

Microsoft’s .NET platform is a family of products that provide tools for developing, server
infrastructure for managing, and building block services and client software for using
XML services. The .NET Framework, which is a .NET development tool, is an
environment for building, deploying, and running XML Web services. It consists of
several parts, including the common language runtime, which is the engine at the core
of managed code execution. Microsoft Visual Studio .NET is a development tool that
exploits the capabilities of the .NET Framework to build powerful Windows applications.
Wise for Windows Installer simplifies the process of creating installations for .NET
applications, automating the process by extracting most of the installation details from
your assemblies.
Windows Installer 2.0 or later only

later.

Also see:
Frequently Asked Questions About Microsoft .NET on page 525

Importing .NET Framework Security Settings on page 238
For information on setting the required .NET Framework version, see Setting a
Requirement on the System Requirements Page on page 166.
Frequently Asked Questions About Microsoft .NET

This section covers important concepts you should understand before you use Wise for
Windows Installer to build .NET installations.
What does the common language runtime do?

The common language runtime manages the execution of code and provides services
such as cross-language integration, code access security, object lifetime management,
and debugging and profiling support. Search for “Common Language Runtime” in the
MSDN Library (msdn.microsoft.com/library/).
What’s the difference between managed and unmanaged code?

Code developed with a language compiler that targets the common language runtime is
called managed code. All code based on Microsoft intermediate language (MSIL)
executes as managed code. Managed code is self-describing; it contains metadata that
describes every element managed by the common language runtime. The runtime uses
the metadata to provide services.
Code that runs outside the runtime and does not contain metadata is called unmanaged
code. Examples of unmanaged code are COM components, ActiveX interfaces, and
Win32 API functions. Unmanaged code executes in the common language runtime
environment with minimal services.
Can I add managed code to an existing application?

Few developers are able to rewrite existing applications completely as managed (.NET)
code. Instead, you can combine managed and unmanaged components in one
installation. Code that contains a mix of managed and unmanaged elements is called
interoperable code.
The common language runtime supports COM interoperability (interop). For backward
compatibility, COM interop provides access to existing COM components without
requiring you to modify the original components. COM interop also enables your COM
clients to access managed code as easily as they access other COM objects. This is
accomplished by adding information to the system registry so .NET components are
called as though they were COM components. At runtime, the common language
runtime marshals data between COM objects and managed objects as needed.
Search for “Interoperating with Unmanaged Code” in the MSDN Library

What is an assembly?
An assembly is the primary building block of a .NET application. An assembly contains its
own naming, binding, versioning, deployment, and configuration information. It consists
of 2 elements: a manifest, which is the meta data that describes information about the

assembly and any resources it depends on; and a set of instructions in the form of
Microsoft Intermediate Language (MSIL) code that is executed when the assembly is
referenced.
You can group assembly elements into a single file assembly, which incorporates the
manifest into a portable executable (PE) file, which can be an .EXE or .DLL, with the
source code. You also can create a multifile assembly consisting of modules of compiled
code, resources, or other files required by the application. In a multifile assembly, the
manifest can be a standalone file or it can be incorporated into one of the PE files in the
assembly.
When you add a .NET assembly to an installation, Wise for Windows Installer creates
entries in the MsiAssembly and MsiAssemblyName tables.
See Assemblies in the Windows Installer SDK Help.
How does .NET reduce file sharing conflicts?

An important benefit of .NET installations is the reduction of file sharing conflicts. With
the common language runtime, the assembly is described by a manifest; the registry is
no longer relied upon for storing and accessing the COM activation data. This allows
components to be fully isolated from each other.
Assembly sharing is accomplished in several ways:
z Global Assembly Cache

To install .NET assemblies that are intended to be shared by many applications on
the computer, make sure they are strongly named and install them into the Global
Assembly Cache, which is a machine-wide code cache. Do not install assemblies into
the Global Assembly Cache unless they specifically need to be shared. The Global
Assembly Cache is available only if the .NET Framework is installed on the
z Side-by-side
To safely share COM or Win32 assemblies among multiple applications and to
minimize .DLL conflicts, use side-by-side assembly sharing. Instead of having a
single version of an assembly that assumes backward compatibility with all
applications, side-by-side assembly sharing enables multiple versions of a COM or
Win32 assembly to run simultaneously on the destination computer. Side-by-side
assembly sharing is available only on Windows XP or later. See Side-by-Side
Assemblies in the Windows Installer SDK Help.
z Private assembly
To reserve a Win32 assembly for the exclusive use of one application, install it in a
directory that is private to the application, typically the application directory. This is
called a private assembly. The dependency of the application on the private
assembly is specified in an application manifest file. On operating systems earlier
than Windows XP, a copy of the private assembly and a .local file is installed into a
private directory for the exclusive use of the application. A version of the assembly
is also globally registered on the system and made available for any application that
binds to it. The global version of the assembly can be the version installed with the
application or an earlier version.
I thought .NET meant I could use XCOPY to install applications without

registration. Why do I need to build a Windows Installer installation?
For a .NET application that uses only managed code and private assemblies, the
installation process can be as simple as copying files to the destination computer. Most

developers, however, still need to create a compressed, single-file installation that is

easy to deploy and that provides a friendly interface to the end user.
.NET applications that use shared assemblies, or that have a mix of managed and
unmanaged code, cannot be installed via XCOPY. You should use the Windows Installer
service for installations that do any of the following:
z Install COM files
z Install assemblies to the Global Assembly Cache
z Require user information during the installation
z Require security
z Create a shortcut
z Require elevated privileges to install on a locked-down computer
By creating a Windows Installer installation for your .NET applications, you can take
advantage of the services Windows Installer provides: installation, repair, and removal
of assemblies; roll back; install-on-demand; patching; and advertisement.
How does Wise for Windows Installer support .NET installations?

Wise for Windows Installer lets you install .NET assemblies into the Global Assembly
Cache, or as side-by-side or private assemblies. It also lets you create mixed
installations by registering .NET assemblies with COM.
If the .NET Framework is installed on your computer, Wise for Windows Installer can
automate the process as follows:
z Find all files in multifile assemblies and add them to the installation.
z Scan for assembly dependencies and add them to the installation.
z Determine attributes for registering the assembly files and add them to the
MsiAssemblyName table.
z Add registry keys for COM interop.
Also see:

Requirements for Creating a .NET Installation

later. When you create a .NET installation, you should have the .NET Framework
installed on your computer. If the .NET Framework is installed on your company’s
development computers, but not on the computer used to build installations, it is
possible to create a .NET installation. However, you must enter certain information
manually. See Creating a .NET Installation Without the .NET Framework on page 221.
You can build .NET installations without having Windows XP or later on your computer.
However, in order to take advantage of side-by-side assembly sharing, the destination

computer must have Windows XP or later installed. To use the Global Assembly Cache,
the destination computer must have the .NET Framework installed.
Before you begin to create an installation for your .NET application, do the following:
1. Gather all your assemblies, both Win32 and .NET, and their manifests into a
common location.
2. Determine the directories in which the assemblies are to be installed.
You can install assemblies into the Global Assembly Cache, the WinSxS directory, or
a private directory. For information on how each of these directories is used, see
Adding .NET Assemblies to the Installation on page 124.
3. For assemblies that are to be installed into the Global Assembly Cache or WinSxS,
generate publicKeyTokens and sign the assemblies.
Also see:

Frequently Asked Questions About Microsoft .NET on page 525

Index
Symbols Windows Installer 471 attributes 134, 221

Actions list 466 defined 525
.NET
activate prompts 49 patching 303
about 525
private 125, 526
ASP user properties 425 Add button, disabled 25
scanning 119
assembly options 41 add project outputs to installation 83 scanning options 41
Compact Framework 248
Add/Remove Programs page 98 scanning problems 42, 120
creating installation 220, 221
AddFile sharing 125, 526
file attributes 133
event macro 460 side-by-side sharing 125, 526
installation, requirements 527
Admin Dialogs 428 assembly dependencies
.NET Framework
adding 362
about 524 admin install, error in Patch
obtaining 221
creating installations with 220 Creation 305
downloading from Web or CD 35 asynchronous, defined 519
AdminError 422
importing security settings 238 attributes (assembly)
administrative installation
pre-installing 187, 199, 221, 222 about 468 adding to installation 134, 221
setting required version 168 obtaining 221
dialogs 468
.NET Framework Security page 238 during patching 305 Authenticode 219
.NET Runtime URL 199 performing 286 automatic updating 54
.NET Update URL 199 advertisement automation 457
_Property table 465 about 522 of build process 218
auto-adding information 42 of compile 218
_WiseDebugMode 418
configuring shortcut for 155
_WiseDialogFontDefault 418 extension, adding 388 B
_WiseDialogSuffix 418 features 523 background build 218
_WiseDialogTitleFontDefault 418 how it works 522
backward compatibility
options 42
dialogs 430
Numerics rescanning advertising info 43
themes 431
000 directory 29, 33 advertisement installation
billboard
32-bit installation about 468
about 448
converting to 64-bit 52 dialogs 468
adding 448
386 file 159 All Custom Actions, about 469 control 448
64-bit component 394 Altiris creating 448
consulting 16 where to use 448
64-bit installation
getting updates 17 binary resource
about 76
training 16 adding 111
9x Download URL 199
application error 112
monitoring 356 exporting 110
A name 93 linking to file 111
Accept property 408, 419 watching 356 properties, changing 110
action 471 Application Specification for Windows refreshing 111, 111
adding to sequence 472 2000 378 saving 110
Also see custom action source file, editing 110
application type
built-in 471 updating 111
options 41
condition 480 specifying 94 Binary table
copy and paste 473 auto-updating 402
ApplicationUsers 419
dialog 471 editing 402
in component rule 58, 62 ApplicationWatch 356
missing file 112
in debugger 463 and 16-bit applications 356
storing .DLL 490, 493
in installation sequence 470 APPS_TEST 419 storing .EXE 502
in validation rule 377 ARM 242 storing .MSI 505
standard 471 storing scripts 495, 498
ASPNET_USER 425
stored in Binary table 402 storing WiseScript 511
assembly
types 471
adding to installation 124 bitfield, for substitution 342
using conditions 408

bitmap CEAppMgr.EXE 245 Command Line page 210
adding to dialog 444 CharFont 422 command verb 158
dialog control 438
CharSet 423 comment out line 473
setting on dialog 442
CharSize 423 commit only 518
blank line
inserting into sequence 509 Check Tables 26 Common Executable Format 242
breakpoint check tables for errors 402 Common Files folder 522
clearing 464 checkbox common language runtime 525
setting in debugger 464 dialog control 438 Also see .NET Framework
setting items 445 comparison
build
Also see compile checking for updates 17 of Windows Installer files 85
automating 218 checking in files 317 to source control 320
clean 193 checking out files 318 compatibility with Windows Installer
sharing settings 183 version 98
checksum, validating 131
Build column 180 compile
Citrix
build error automating 218
compatibility 180
See compile validation 379 change source directory 327
changes not saved 90
Build Options page 185 clean build
error 26
button in directory 194
errors after import 362, 364
dialog control 438 in source control 193 file path errors 89, 324
resizing for language 274 Clean Build page 193 how to 88
cluster size 203 log file 218
C mobile device 246
CmdLine 423
C# quick 40, 88
code group, importing for .NET 238
importing 361 release 179, 180
project types 360 code page 265, 268
silent 218
tips for import 360 code signing with multiple processors 44
C++ symbol file directory 308, 308 See digital signature Complete feature 100
CAB colors in sequence 471 Complete installation type 175
adding files 250 column information 398 component error
creating CAB files 202 COM interoperability (interop) adding to Task List 26
file details 251 about 525
Component Object Model 240
names for mobile device 247 registering .NET assembly 95,
platform version 249 component rules
222, 332
register DLL 251 about 57
COM+ 240 action 58, 62
registry 252
combobox dialog control 438 adding 61
shortcut 254
command line aligning GUIDs 59
Call Custom DLL
creating 210 Also see rule set or component
from destination 489
command line options, installation condition 58, 62
from installation 490
about 209 deleting 61
from installed file 491
advertising 214 editing 61
tips 481
creating 210 how applied 58
Call DLL in upgrade 59
general options 210
from installation 492 Microsoft Best Practices 63
installation log 213
from installed file 493 modifying 61
logging 213
tips 481 One File Per Component 64
patch, applying 216
Call JScript patch, removing 216 predefined 63, 64
from embedded code 494 public property, changing 215 selecting 58
from installation 495 repair 215 sharing 50, 57
from installed file 495 running 90, 210 ComponentRules.ini 50
from property 496 testing 89 components
tips 481 transform, applying 216 64-bit 394
Call VBScript UI options 212 adding 393
from embedded code 497 command line options, WfWI.exe assigning to feature 387, 395
from installation 497 about 209 checking if installed 414, 414
from installed file 498 compiling with 328 condition not working 411
from property 499 create log file 218 conditions, adding 409, 409
tips 481 example 218, 328 creating 57, 523
Cancel button, hiding in install 212 list of 217 defined 523

editing 393 configuration item 338 troubleshooting 488
including in media 205 adding 338 using formatted text strings 480
isolating 396 bitfield 342 Wise 483
key path 396 configurable 339 Custom Actions directory 29, 50
moving 387 constant 339
custom installation 106, 175
moving items to 395 data types 340
Custom Property Dialog 455
moving to merge module 337 defining 339
naming 58 key into a table 343 custom tab, in MSI Script 472
publishing 397 text drop-down 341 CustomActionData 482
removing from feature 387 ConfigureWebUI 484
renaming 393
connection string 235, 452
D
searching for 174 darice.cub 378
consulting 16
Components tab data source, ODBC
controls
about 390 adding 162
adding file 118 See dialog control
details 162
errors, showing 392 convert .MSI to .WSI 365
Wise Software Repository 50
showing/hiding items 391 Convert button, Dialogs page 430
database
tree structure 390 Convert InstallShield Project 357 configuring during
compression Convert SMS Installer or installation 234
compiled installation 180 WiseScript 358 connecting to 235
installation files 202 convert source paths 324 creating during installation 236
CondFix.msm copy file on destination computer 128 running SQL statements 236
about 411 database file, Windows Installer 68
copy source files 123
when to add 411
credentials file 44, 219 database index
condition file location 32
about 407 CUB file
about 371 Debugger for Windows Installer
adding to dialog 408
Also see validation module about 462
attached to event 409
customizing 371 evaluating conditions 463, 465
building 411
log file 463
checking environment Current Feature list
running 463
variable 413 about 24
searching tables 465
checking for component 414, 414 Features page 100
setting breakpoints 464
checking for feature 414, 414 number in parentheses 25
starting 462
checking on reinstall 126, 394 Current Release list 25 viewing properties 463
checking property value 412
custom action viewing table 463
deleting from Features page 109 accessing properties 482 viewing temporary table 465
evaluating at runtime 463, 465
added by Wise 483 window, rearranging 463
example 410
adding outside a sequence 469 debugging
for component 409, 409 adding to multiple sequences 469
for dialog item 444 DLL 482
adding to sequence 472 VBScript 464
guidelines 409
calling another installation 480
in component rule 58, 62 default directory
calling with validation rule 374
in validation rule 377 application installation 97
choosing location 479, 515
not working 411 changing 94
compile error 112
on Features page 408 projects 50
condition 480
organizing 101 default language 275
configuring parameters 492
setting for action 408, 504 default release language
copy and paste 473
setting for component 393 guidelines 478 about 277
system requirements 408 setting 260, 265, 268
in deferred mode 482
tips 480
in merge modules 516 DefaultUIFont 419
using environment variable 409 launching from dialog 483
using numbers 409 deferred execution 518
methods for calling .DLL 481
using properties 407, 409 deferred mode
moving 479
using string 409 about 470
name for merge module 516
where to use 408 accessing properties 482
properties 517
Condition Builder 411 restrictions on placement 472 DelayReboot 423
configurable data 340 run on uninstall 480 Delete button, disabled 25
configurable merge module run once 480 Delete Unreferenced Rows 343
Also see merge module setting condition 504 deleting 471
configuration item 338 stored in Binary table 402
Dependencies page 332
creating 338 tips 478

dependency editing 433 Digital Signature page 219
adding 119 fonts 441, 445 directory
adding to merge module 332 graphic, adding 444 adding contents 122, 142
adding without .NET help, adding 444 changing 325
Framework 221 Install Dialogs 428 changing to virtual directory 228
defined 332 launching action from 483 creating 389
files 362, 363 Maintenance Dialogs 428 creating empty 389
scanning for 221 making modal 436 default for installation 97
scanning options 41 name 435 default for projects 50
scanning problems 42, 120 position 435 filtering contents 54
desktop computer previewing 430 merge module 48
for mobile device 254 properties 416 name, translating 266, 271
Desktop, adding shortcut 153 properties, editing 435 predefined 116
selecting 430 renaming 114, 141
destination computer
translating 258 searching for 169
copying file 128
turning off all 431, 434 setting permissions 132
how files are stored 522 turning on/off 434
moving file 128 setting with custom action 513
Welcome Dialog Wizard 428 using wildcard to filter 122, 142
removing file 127
dialog control viewing for all features 47, 118,
removing registry entry 145
about 438 123
device driver adding 435
adding to Add/Remove directory combobox control 438
aligning 446
Programs 139 directory listbox control 438
Also see dialog
options 138 attributes 441 DiskPrompt 419
device driver, installing 73 basic settings 440 disks, copying installation 286
DiagnosticAppSearch 484 centering 446 Display Message 500
DiagnosticCheckDiskSpace 484 condition on event 409 distribution
condition, adding 408 preparing for 201
DiagnosticCheckDotNet 484
condition, setting 444 See Package Distribution
DiagnosticCheckExecuteLocally 484
disabling 408, 444 DLL file
DiagnosticCheckInUseFiles 484 editing 439
accessed by application 356
DiagnosticCheckLaunchCondition 485 enabling 408, 444
calling from destination 489
DiagnosticCheckPatchExistence 485 event, setting 443 calling from installation 490, 492
graphic, setting 444
DiagnosticFileAssociationConflict 485 calling from installed file 491, 493
help, adding 444
DiagnosticLaunchWeb 485 calling with validation rule 374
indirect 441 debugging 482
DiagnosticManagedFileCheck 485 location on dialog 441, 445
preventing conflicts 396
DiagnosticMarkBeginRun 485 organizing 446
sending parameters to 481, 492,
DiagnosticMarkEndRun 485 populating 445 493, 493
properties 440
DiagnosticOpenDocExtCheck 485 shared DLL count 126, 394
property, assigning 440
DiagnosticPayloadInstalled 485 Windows Installer method 481,
setting as default 444 492, 493
DiagnosticSecurityCheckFileRead 486 sizing 446
document, open from installed file 508
DiagnosticSecurityCheckFileWrite 486 spacing 447
state, setting 408 documentation 14
DiagnosticSecurityCheckRegistryRead
486 tab order, setting 447 dotNET
text 440 See .NET
DiagnosticSecurityCheckRegistryWrite
486 tooltip, adding 444 dotnetfx.exe 187
types 438
dialog Download File From Internet 500
dialog theme
about 427 Download Redistributables 35
See theme, dialog
accessing 427 driver
action 471 Dialogs directory 29, 50
adding to Add/Remove
adding 437 Dialogs page 430 Programs 139
Admin Dialogs 428 Dialogs tab 433 Driver Install Frameworks 73
Also see dialog control
DIFx 73 driver package
Also see theme, dialog
DIFxAPP adding to Add/Remove
bitmap, adding 442
changing for language 274 merge module 73 Programs 139
options 138 installing 73
condition, adding 408, 444
digital signature options 138
controlling display of 443
creating 437 adding 219 driver, installing 73
displaying image 448 options 43 driver, ODBC

adding 162 execute program checking out 318
details 163 from destination 501 comparing 85
duplicate files 130, 131, 389 from installation 502 conditions, adding 408
dyamic content 137 from installed file 503 copying on destination
from path 503 computer 128
E ExistError 423 duplicate 131, 389
export to XML 86 extension, adding 156, 388
edit field control 438 extracting from .MSI 365, 367
edit script 473 ExpressBuild 44
general details 130
Edit Script button extension hidden 131
enabling 192 adding 388 inside .MSI 202
Also see first letter of the installation location, setting 126
editions 18
extension latest version, getting 318
elevated privileges 150 details 157 location, changing 325, 326, 326
End Statement 501 External Files folder 141 moving on destination
Enterprise edition 30 extract directory 359 computer 128
environment variable multiple files, adding 122, 142
adding 155 F name, changing 129
checking the value 413 name, translating 266, 271
family, patch 304
path variable 323 outside .MSI 202
reading 413 features path error 324
about 523 path, changing during
using in condition 409
adding 103 compile 327
error
advertisement options 107 preventing overwriting 127
compile 26 assigning component 387
component 26 read-only 131
attributes 107 recompressing 95
found by UpgradeSync 302
checking if installed 414, 414 removing from destination
in Components tab 392
Complete feature 100 computer 127
in Patch Creation 305 conditions, about 108
save 26 removing from source control 319
conditions, adding 408 searching for 169
table 26
configuring 104, 105 self-registration 131, 133
validation 26, 370 defaults, setting 175 setting permissions 132
ErrorDialog 419 deleting 100 short file name 185
Evaluate Windows Installer display to end user 106 shortcut, adding 153
Condition 474 editing 24 shortcut, editing 154
event features tree 100 source directories 367
dialog control 443 including in media 205 system file, designating 131
macro 458 installation location 107 type, setting 157
installation options 104 undoing check out 319
event macro
about 459 installation state 514 updating from hard drive 95, 125
moving 100 using wildcard to add 122, 142
adding 458
number in parentheses 25 validating checksum 131
editing 459
organizing files 101 Win32 settings 133
exclusion, merge module 333 registry value, adding 143
Exclusions page 333 file association
requiring 108
actions 158
EXE file turning off 183
adding 156
accessed by application 356 Features page command verb 158
calling from destination 501 about 99 extension settings 157
calling from installation 502 features tree 100 importing 157
calling from installed file 503
Features tab MIME type 159
calling from path 503
about 385 File Associations page 156
calling with validation rule 374 adding feature 103
editing the WiseScript 191 file location
adding file 118
importing 358 indexing 32
showing/hiding items 385
isolating with .DLL 396 tree structure 385 file name
outputting installation as 185 long 131
file
that launches .MSI 422 short 131
.NET settings 133
with .MSI 68 File page
adding to installation 117
Execute Deferred 466, 470 adding to source control 317 when to use 115
Execute Immediate 466, 470 assembly settings 133 file resources, shared 136
execute installation attributes, changing 129 Files page
for testing 90 checking in 317 about 113

adding directory 122 HKEY_USER_SELECTABLE 150 install MSI
adding file 117 Home page 25 from destination 504
automatic updating 125 from installation 505
HTTP protocol 285
icons 116 from relative path 506
viewing directories 47 HTTP Server, posting data 508
install/action state 412
filter I installation
added files 54 adding SQL to 236
ICE
filter directories with wildcards 122, adding to source control 51, 315,
defined 373
142 317
errors 371
find error in installation database 402 before you start 66
icon building 88
Find table data 401 folder with magnifying glass 123 calling multiple 480, 504, 505,
find text 471 on Features page 104 506
folder on Files page 116 compiling 88
See directory setting on dialog 442 compression 180
setting permissions 132 Task List 27 copying to disks 286
font, in dialog theme 432 icon control 438 copying to FTP server 285
FTP server, copying installation to 285 If Statement 504 copying to network 284, 286
IIS creating 69
FTP, passive 285
creating virtual directory 226 creating as project 70
function, macro
creating Web folder 228 creating as stand-alone 72
showing 461 creating from installed
creating Web site 224
application 356
G details 232
creation options 74
installing to 222
GAC restarting 225, 226 custom 106, 175
See Global Assembly Cache disconnected 88
setting required version 168
General Information page 98 user for ASP 425 displaying images during 448
Get Windows Installer Property 474 version 419 execution of actions 463
integration with solution 70, 82
Getting Started Guide 15 IIS dialogs
language, setting 384
Global Assembly Cache adding 229, 231
localizing 258
defined 526 changing order 433
media 201
directory 116, 125 do not edit 229, 231, 433
mobile device 246
patching 303 regenerating 229, 231, 433
multiple instances 352
graphic IISVERSION property 419 multiple releases 178
adding to dialog 444 image opening a copy 87, 96
referencing 109 adding to dialog 444 opening from repository 84
stored in Binary table 402 displaying on dialog 448 password, setting 186
updating 109 immediate execution 518 pausing 508
group immediate mode 470 previous directory, finding 174
opening from repository 84 running 90
import
group box control 438 server application 451
C# project 361
silent custom actions 473
GUID compile errors 362, 364
source control compare 320, 320
about 524 J# project 361
starting in test mode 89
for components 59, 393 Visual Basic Project 363
starting without debugging 90
patch 308 Visual Basic project 361
template, creating 55
In 365 terminating 515
H index testing 89
H file 270 file location 32 transform, applying 351
handheld 242 INI file translating 258, 260
hash table 131 creating 151, 151 turning off dialogs 431, 434
help editing 151 uninstall, avoiding 300
about 14 editing tips 151 uninstalling nested 481
adding to dialog 444 in installation 422 validating 370
using 15 in WebDeploy 195, 198 watching 356
Windows Installer SDK 15 searching 171 Installation Expert
updating 151 about 20
hidden file 131
INI Files page 151 getting help 21
Hide Empty Folders/Items 385, 391
In-Script Options 470, 517 page groups, about 21
history, showing for project 319 page navigation 21
Install Dialogs 428
Hitachi 242 page views, customizing 23

pages, resetting 21 K See language or translation
undo changes 21 location
key fields 398
installation log for custom action 479, 515
key path
creating 213 for merge module actions 516
about 396
omitting property values 456 Location tab 469, 470
for components 394
installation mode 468 setting 396 lock
installation sequence Key Table 343 directory 132
about 467 file 132
defined 470 L registry 149
types of actions 471 log file, command line 218
language
Installation Target 95 adding 263 log, installation
Installation Type dialog 175, 429 Also see translation See installation log
Installation Types page 175 choosing a release 25 logging option, in command line 213
INSTALLDIR 419 default for release 277 logo certification, Windows 2000 378
default, changing 275
Installed property 410, 480 logo.cub 378
defining 265
INSTALLLEVEL 106, 419 disabling in installation 262 Logon Information dialog 429
InstallMode 419 exporting selected strings 270 adding 451
multiple-language release 180 guidelines 452
InstallShield Project, converting 357
instance identifier 352 pre-translated 278
removing from installation 263 M
instance transform
restoring to installation 263 macro
about 352
selecting at runtime 180 adding for event 458
creating 352
selecting for display 274 creating 458
installing 354
setting for installation 384 editing 459
product code 353
sharing between releases 261 event 459
InstMSI CmdLine 423 strings, See text strings running 459
InstMsi.exe 187, 199 transform, creating 260 Macro Editor
InstMsi3.exe 187 language ID checking syntax 461
InstMsiW.exe 187, 199 list 279 functions, viewing 461
integer in condition 409 setting 265, 268 members 461
Language menu, using 274 objects, viewing 461
Internet Explorer version 167
showing all macros 461
Internet Information Server Language Pack 279
using 460
See IIS Language property 423
macro file
Internet, downloading file 500 LanguageFile 423 renaming 458
interoperable code 525 Languages directory 29, 51 samples 457
Also see COM interoperability Languages page 258 Macros.wbs 457
IPF file, importing 358 latest file version, getting 318 Main Project page 80
IPR file, converting to Windows launch condition main project/target 80
Installer 357 about 384 Maintenance Dialogs 428
isolation creating 168
MaintenanceMode 419
using component 396 editing 169
with Win32 assembly 135 Major upgrade 302
launch Visual Studio integrated
Item Field, in .INI 172 editor 71, 72 MAKECAB.EXE 302
Launch Web Page 507 managed code 525
J launch Wise for Windows Installer 69 managed operations 379
J# Layout menu 434 manifest
importing 361 creating for Win32 135
License dialog
project types 360 defined 525
importing text 433
tips for import 360 file 134
line control 438
JScript manual
calling from embedded code 494 line, inserting blank 509 accessing online 15
calling from installation 495 listbox manufacturer
calling from installed file 495 populating 445 property 419
calling from property 496 Listbox Compatibility Mode 47 setting name 93
guidelines for calling 481 listbox control 438 masked edit control 439
listview control 439 MDAC merge module 453
localization media

creating 202 Microsoft Cab Wizard 246 launched by .EXE 422
deleting 201 Microsoft Internet Information Server ways of creating 69
destination 204 See IIS MSI Script
example 206 Microsoft SMS 358 about 467
sharing settings 206 custom tab 472
Microsoft SMS page 219
size 203 finding text 471
Microsoft SQL Server
Media page 201 shaded areas 472
See SQL Server
merge module standard tab 472
Microsoft Transaction Server 240 window 466
about 329
action location, choosing 516 Microsoft Visual SourceSafe 316 MSI to WSI Conversion
add to feature 346 MIF file 219, 219 about 364
adding 345 MIME type, associating with running 365
adding features 330 extension 159 msiexec.exe 522
CondFix.msm 411
minimum installer version 385 MsiFileHash table 131
configurable 330
configuring 346 minimum system requirements MSM file
See system requirements Also see merge module
creating as new installation 334
Minor upgrade 301 defined 67
creating from components 337
creating stand-alone 334 MIPS 242 MSP file
creating within a solution 336 mixed installation 41, 95 Also see patch
custom action 39 defined 67
mobile device
dependency, adding 332 how created 303
about 242
directory for downloads 346 MSPATCHC.DLL 302
compile errors 247
directory, default 29, 48 compiling 246 MST file
downloading from Web or CD 35 desktop computer 254 Also see transform
exclusion, adding 333 defined 67
file information 251
exporting components 338 for languages 260
files 250
extracting from .MSI 365, 366 information 247 MTS/COM+ page 240
from Software Manager
installation, creating 246 multifile assembly 124, 526
database 48
overview 245 multi-patch 306
language, setting 331 Palm 255
naming 331 multiple-language release 180
platform version 249
naming custom action 516 MYPASSWORD 450
platforms 245, 248
options 48 registry information 252 MYUSERNAME 450
predefined 35
self-registration 251
removing 347 N
shortcut 254
running 90
settings 347 Mobile Device Package Editor 244 name of product 93
showing files and registry Mobile Devices page 244 nested installation
entries 47 ModifyXMLFiles 486 on destination computer 504
source directory 366 Module Details page 331 relative to base 506
substitution 338 substorage 505
Module tab
suppressing errors 40 tips for running 480
about 330
testing 90 uninstalling 481
ModuleDependency table 333
version, setting 331 NET
ModuleExclusion table 334 See .NET
Merge Modules page 345
Modules icon 388 network directory
mergemod.cub 378
Motorola 242 copying installation to 284
message, displaying to end user 500
Move Components to Merge New
meta data
Module 337 event macro 460
adding to Software Manager
database 95 move file on destination computer 128 New button, disabled 25
defining fields 92 MSDE runtime 190 new features
editing 92, 96 MSI Download URL 199 Refer to Release Notes
entering 92 New File 74
MSI file
issue in Task List 26
about 68 New Installation File 69
rearranging 92 adding to source control 315 New Language wizard 264
metadata compression 180
See meta data New Project 74
contains files 202
Microsoft .NET converting to .WSI 365 newsgroups 16
See .NET creating 70, 72 normal installation mode 468
Microsoft Application Specification 378 defined 67 no-touch deployment 238

NT download URL 199 about 369 patch sequence
Also see validation about 303
O correcting problems 371 specifying 309
object list 461 running 370 Patch Wizard
OCX file, accessed by application 356 page See Patch Creation
See Installation Expert PATCHWIZ.DLL 302
ODBC page 162
page count 385 path edit control 439
ODBC SQL Server driver 453
page groups path variable
ODBC, adding 162
about 21 environment 323
ODBC.INI, updating 151
page views registry 323
Open about 22 turning off 322
event macro 460 associated with template 22 user defined 322
Open Document From Installed creating 23 Path Variables page 321
File 508 customizing 24 pathnames
operation displaying 23
changing directories 325
copy file 128 predefined 22
relative paths 326
move file 128 selecting 21 UNC paths 326
remove file 127 sharing 22
Pause Installation 508
options Palm
PCP file
.NET assemblies 41 Add-on folder 256
Also see patch
about 38 User Folder 256
defined 68
advertising 42 Palm installation how created 302
digital signature 43 creating 255
general 39 PDF (Package Definition File) 219
Palm User Installation dialog 429
Installation Expert 47 permissions
parameters for directories 132
merge modules 48
sending to .DLL 481, 493, 493
prompts 49 for files 132
repository 49 parent feature 105 for registry 149
resource sharing 49 parsing 474 PIDTemplate 420
source control 51 passive FTP 285 platform
target platform 52 password See target platform
Visual Studio .NET 53 for installing 186 platform version 249
osql.exe 453 obtaining 450 Pocket PC 242, 244
Overview page 78 patch compiling 246
overwriting, preventing 127 about 302 desktop computer 254
advanced settings 309 file information 251
P Also see Patch Creation files 250
package applying to installation 216 information 247
opening from repository 84 assembly in GAC 303 installation, creating 246
overwriting 87, 96 compile settings 306 overview 245
creating 87, 304 platform version 249
package code 385
defining upgrade versions 308 platforms 245, 248
changing 94
description 299 registry information 252
in patch 303
family 304 shortcut 254
Package Contents by Feature file 67
report 33 PopulateVirDirs 486
GUID 308
Package Contents Summary report 33 guidelines 303 Post Data to HTTP Server 508
Package Definition File (PDF) 219 preparing for 300 Post-build event 81
Package Distribution project file 68 Pre-build event 80
about 282 removing 310 preferences
administrative install 286 removing from installation 216 See options
copying .EXE to disks 286 specifying sequence 309 prerequisites
copying .EXE to network 284 specifying version to patch 307
adding 187
copying .MSI to network 284 supercedence 309
command line 189
copying to FTP server 285 uninstalling 310 launch conditions 189
distributing to share point 282 when to use 299
MSDE runtime 190
running in Software Manager 282 Patch Creation prerequisite file 189
package name 93 about 302 requiring a reboot 188
error on admin install 305 WiseScript runtime 190
package path 94
previous version, specifying 307
Package Validation Prerequisites page
running 304

enabling 187 masking user entry 456 key, editing 148
previous version overriding value 182 locking 149
specifying for patch 307 precedence 416 per machine 150
PRIMARYFOLDER 420 prompting user for value 455 per user 150
restricted public 417 permission, adding 149
private assembly 125, 526
runtime 415, 424 removing entry from destination
private key 44, 219 set by user 416, 416 computer 145
privileges set by Windows Installer 415 removing multiple keys 146
elevated 150 set with custom action 514 searching 173
setting for custom actions 470 using in condition 407, 409 value, adding 145
product code value, checking 412 viewing all keys 47
in instance transform 353 viewing in debugger 463 viewing for all features 144, 145
setting 94 properties for dialog Registry page 143
upgrading 300 event 443 registry path variable 323
Product Details page 92 help 444
registry resources, shared 150
Product Home page 25 Properties icon 384
reinstall
product name 93 Property table 465 rechecking conditions 126
Product tab 384 public property, changing 215 when to use 299
product type 93 published component, adding 397 ReinstallFileOlderVersion 420
product version published event 443 ReinstallFileVersion 420
See version ReinstallRepair 420
ProductCode 420, 423
Q relative paths, converting to 326
ProductFile 423 QUE file 29 release
ProductID 420 QueryDisplayValidation .WSI file only 178
event macro 460 about 178
ProductLanguage 420
QueryFixValidation compiling 179, 180
ProductName 420, 423 creating 179
event macro 460
ProductVersion 420, 423 customizing 181
quick compile 40, 88
Program Files (x86) 116 example 184
progress bar control 439 R multiple languages 180
sharing language settings 261
progress text radio button
translation 421, 424 sharing settings 183
control 439
turning features off 183
project file populating 445
release notes 15
connecting to existing 315 readme
creating 70, 72 See release notes Release Settings page
working with 68 choosing release 25
Readme dialog
Project Outputs page 81 customizing release 182
importing text 433
customizing summary 182
Project Summary page 92 read-only files 131 defining features 183
Project Type page 78 REBOOT property 417 sharing settings 183
project, in Visual Studio .NET red component icon 392 working with 181
entering settings 77 redistributables, downloading 35 Releases page 178
Projects page 79 reference action 517 remark action 509
prompt options 49 reference manual remarks, adding to .MSI 39
properties accessing online 15 removable media, copying
about 415 referencing graphics 109 installation 286
accessing from custom action 482
Refresh column 111 remove from destination computer
adding new 182
REG file file 127
as Boolean value 410 registry entry 145
as formatted text 416 exporting 147
importing 147 Remove Previous 424
common uses 416
creating 418 registry REMOVE property 410, 410
custom action 517 data type 149 repair option, in command line 215
defined 415 empty key, adding 144 Replace table data 401
definitions 418 exporting 147
reports
for dialog control 440 for elevated privileges 150
package contents 33
how they are set 415 for mobile device 252
resource sharing 34
initializing 415 for multiple users 150
installation project 77 importing 147 Reports directory 29
list 418 key, creating 144 repository

Also see Wise Software RuntimeVersion 424 adding 159
Repository configuring 160
options 49 S deleting from destination
repository ID 94, 96 sales contact 17 computer 161
starting 161
rescan advertising info 43 Save
stopping 161
reset page 21 event macro 460
Services page 159, 159
resolution (screen) requirement 167 save error 26
Set Directory 513
resource scanning
for dependencies 221 Set Feature State 514
exporting 110
problems 42, 120 Set Property 514
resource sharing
about 30 solution for new files 82 Set Windows Installer Property 474
locations 50 SCCS SetPatchMode 486
options 49 See source control SetPatchReinstallMode 486
reports 34 scheduling options 519 settings, installation project 77
Resources directory 29, 51 screen Setup Editor
Resources page 109 colors requirement 167 about 382
restricted public properties 417 resolution requirement 167 tabs 383
revision number 385 ScreenX property 408 Setup Wizard 71, 74
rollback ScreenY property 408 SetupCapture 356
script 470 Scripts directory 29 SetWizardProperty 486
rollback only 518 scrollable text control 439 SetWizardProperty1 486
RUL file, InstallShield 357 search depth 170 share point directory
rule search for text 471 about 32
See component rules searching table data 401 changing 50
See validation rule SecureCustomProperties 420 editing contents 32
rule set, component subdirectories 29
security
copying 61 temporary file 29, 32
achieving with WiseScript 475
creating 60 where to locate 32
for file or folder 132
deleting 61 importing .NET Framework shared assembly 125
modifying 61 settings 238 Shared Files report 34
renaming 61
Select Feature dialog 429 Shared Registry report 34
selecting 58
where stored 58 select package from repository 84 shared resources
selection tree control 439 file 136
rule set, validation
registry 150
about 375 self-registration 131
adding automatically 43 short file name 286
creating 376
how captured 139 shortcut
run application, from
ApplicationWatch 356 on mobile device 251 adding to installation 153
setting for files 133 advertised 153
Run button
sequence, installation editing 154
avoiding popup 90
about 467 for mobile device 254
Run event macro 460
adding action 472 Shortcuts page 152
run installation choosing for action 515 Shx 242
changes not saved 90 colors of actions 471
how to 90 side-by-side sharing 125, 526
commenting out line 473
Run WiseScript signcode.exe 43
how they are run 470
example 474, 475, 476 inserting blank line 509 silent compile 218
from destination 510 restricted areas 472 silent installation
from installation 511 searching 471 calling WiseScript 473
from installed file 512 types of actions 471 SLN file 360
runtime sequence, patch Small update 301
downloading from Web or CD 35 about 303 Smartphone 244
evaluating conditions 463 specifying 309 compiling 246
properties 415, 424 server desktop computer 254
runtime prerequisite logon information 450 file information 251
adding 190 SQL, configuring 234 files 250
Runtime9x 424 server application 451 information 247
RuntimeNT 424 service installation, creating 246
overview 245

platform version 249 modifying 454 .INI file 171
platforms 248 using 452 about 169
registry information 252 SQL connection string file or directory 169
shortcut 254 populating 452 installed component 174
SMS registry 173
SQL Server
converting to Windows configuring 234 System.ini, updating 151
Installer 358 connecting to 235 Systems Management Server
installation 219 setting required version 167 See SMS
SMS file SQL Server Scripts page 234
copying 284
SQL statements
T
Software Manager 31 adding to installation 236 tab order
Software Manager database replacing text in 237 for controls 445
importing packages from share standard action on dialogs 447
point directory 282 Also see custom action table
solution color 471 added by Wise 403
integrated with installation 82 deleting 471 adding row 400
scanning for new files 82 restrictions on placement 472 creating 399
source control standard tab, in MSI Script 472 deleting 401
about 314 deleting row 400
start installation in test mode 89
adding clean build 193 editing binary data 402
Start menu, adding shortcut 153 editing table data 400
adding project 315, 317
start Visual Studio integrated field definition 399
checking files in 317
checking files out 318 editor 71, 72 finding errors 401
comparing to latest 320 start Wise for Windows Installer 69 searching 401
connect to existing 315 status MIF file 219 searching during runtime 465
disabling 51 showing/hiding 398
status, package 96
enabling 51 temporary 465
string viewing in debugger 463
getting latest version 318
Also see text strings
of XML files 315 table error
using in condition 409
removing files 319 adding to Task List 26
strong name 125 finding from Task List 27
showing differences 320
showing history 319 StrongARM 242 Tables tab
undoing check out 319 subscribed event 443 about 397
source directory substitution value 338 column information 398
about 324 Substitutions page 338 comparing installations 321
changing 325 viewing 398
summary items
changing during compile 327 target platform 94
about 384
file 367 about 76
overriding 182
invalid 324 setting value 384 mobile device 245, 248
relative 326 options 52
support 16
UNC-based 326 specifying 76
newsgroups 16
source file task
online support 16
in share point 29 adding 26
indexing location 32 Support Information Page 99
component 26
location, changing 325 suppressed prompts, activating 49 save/compile 26
relative paths 326 synchronous, defined 519 table 26
UNC paths 326 syntax, checking macro for 461 user-defined 28
source path SYS file 159 validation 26
Also see source directory Wise Task Manager 379
system context 470, 518
converting 324 Task List
merge module 366 system file, designating file as 131
about 26
source tree relative to base 506 system requirements adding tasks 26
about 166 component error 26
source type 385
adding conditions for 408 filtering 27
SpaceError 424 setting in Installation Expert 166 finding table errors 27
SQL Client Tools 453 setting with launch condition 168 icons 27
SQL Connection dialog System Requirements page 166 meta data issue 26
about 429 system requirements, Wise product resolving issues 26
adding 453 Refer to Getting Started Guide save/compile error 26
adding more than one 454 table error 26
System Search page
guidelines 453

user-defined task 28 changing per release 179 unmanaged code 525
validation issue 26 editing 432 update
technical support 16 fonts 432 based on wildcards 54
newsgroups 16 images 432 Update Clean Build 194, 194
online support 16 no graphics 431
update, checking for 17
none 431
template upgrade
associated page view 22 predefined 431
about 311
convert InstallShield Themes directory 29, 51, 432
adding to installation 311
Professional 357 toolbar for dialogs 434 aligning component GUIDs 59
convert SMS Installer or tools archiving previous 298
WiseScript 359 overview 355 avoiding uninstall 300
creating 55 starting 355 configuring 311
import Visual Basic 361
tooltip for dialog 444 description 299
import Visual C# 361
training 16 errors, avoiding 300
import Visual J# 361 further reading 298
language 275 transform
general steps 298
location 29 about 348
applying to installation 216, 351 guidelines 311
page view, associating 22, 56 patch or upgrade 299
page view, customizing 22, 56 applying, example 351
patch, creating 304
server application 451 based on existing .MSI 349
creating for language 260 preparing for 300
Templates directory 29, 51 product code, changing 300
example 348
temporary package file 29, 32 product version, changing 300
excluding files 349
temporary table 465 file 67 specifying for patch 308
specifying version for 307
Terminal Server including files 349
when to patch 299
validation 379 meta data, changing 92
when to reinstall 299
Terminal Services multiple instances 352
options for creating 348 UpgradeCode 311, 420
compatibility 180
options, setting 350 Upgrades page 311
Terminate Installation 515
running 90 UpgradeSync 300
test suppressing errors 350
installation 89 user context 470
testing 90
merge module 90 user defined path variable 322
TransformMSI 424
transform 90 User Information dialog 429
translation
Test button User Interface 466, 470
about 89 Also see language
compiling to .MSI 259 user name, obtaining 450
avoiding popup 89
compiling to language user-defined task 28
Test, event macro 460
transform 260 UserSID 482
text box of progress text 421, 424
dialog control 439 of user interface 258 V
resizing for language 274 strings, See text strings
validation
text strings translator, ODBC Also see Package Validation
Also see language adding 162 error 370
exporting all 265 details 163 errors in tables 401
exporting selected strings 270
tutorial issue in Task List 26
importing all 266, 267
Refer to Getting Started Guide of installation 370
importing selected 271
typical installation 175 terminal server compatibility 379
pre-translated 278
test descriptions 378
tracking changes 278
translating changed 268
U Validation directory 30, 51
translating in Installation UNC paths 326 validation module
Expert 273 undo about 371
translating in Language Strings check out 319 adding 372
dialog 272 Installation Expert page 21 customizing 371
translating in SetupEditor 273 predefined 378
uninstall
translating without exporting 272 avoiding 300 selecting 370
Text Translated 258 selecting rules 373
leaving components installed 126
theme, dialog patch 310 validation rule
adding 432 running action during 480 about 375
backward compatibility 431 setting options 98 action 377
changing 431 WiseScript 476 calling .DLL 374
calling .EXE 374

calling custom action 374 Visual Studio integrated editor using with Autoplay 195
calling VBScript 374 about 20 versus non-WebDeploy
condition 377 Visual Studio project, importing 361 installation 195
creating 374, 376 Visual Studio Solution page WebDeploy page 198
selecting 373
wildcard
value source, for parameter 492 adding files with 122, 142
External Files folder 141
variable parameters 493, 493 changing 125
about 141
VBImport event macro 460 filtering directories 122, 142
adding directory 142
VBP file 360, 360 Also see Files page groups 54
VBPROJ file 360 when to use 115 WIN.INI, updating 151
VBR file 143 VJSPROJ file 360 Win32 assembly

creating 135
VBScript volume combobox control 439
isolating 135
calling from embedded code 497 volume cost listbox control 439
Windows
calling from installation 497 VXD file 159
calling from installed file 498 setting required version 167
calling from property 499 W Windows 2000
calling with validation rule 374 locked-down machines 417
wamdb.idx service, adding 159
debugging 464
about 32 service, controlling 161
guidelines for calling 481
WBS file 457 support information 99
vendor redistributables,
Web dialogs validation checks 378
downloading 36
adding 229, 231 Windows application, creating
VeriSign
changing order 433 installation 69, 70, 72
commercial certificate 219
do not edit 229, 231, 433 Windows CE 244
Web site 44, 219
regenerating 229, 231, 433
version Windows directory
Web Files page 222 adding file 116
changing 300
about 113
incrementing 97 Windows Installer
when to use 115
of product 93 about 521
upgrading 300 Web folder actions 471
when to update 300 creating 228 administrative installation 286
details 232 comparing files 85
Version9X property 108
Web installation compatibility with 98
VersionNT property 108, 410
choosing dialogs 229, 230 database files 68
Virtual Directories page creating virtual directory 226 delaying reboot 188
See Web Files page features that support 223 developer documentation 15
virtual directory install from Web 194 difference from Wise for Windows
changing to Web site 228 installing settings from file 233 Installer 522
child 226 Web settings XML file 233 help 15
choosing dialogs 229, 230 Web page how it works 521
creating 226 launch from installation 507 Installer directory 522
details 232 logo requirements 378
Web server
editing web.config 137 package, defined 67
version 419
how options are set 227 pre-installing 187, 199, 522
installation options 229, 230 Web settings XML file 233
pre-installing 3.0 188
removing on uninstall 227 Web site repairing feature 101
top-level 226 changing to virtual directory 226 required version 98
Virtual OS directory 30 choosing dialogs 229 setting required version 167
creating 224
Visual Basic Windows Installer SDK Help 15, 521
details 232
editor 460 Windows Installer service 470
how options are set 225
importing 361, 363
installation options 229 Windows NT
project types 360, 360
installing on workstation 230 locked-down machines 417
tips for import 360 service, adding 159
installing settings from file 233
using in macro 458
web.config 137 service, controlling 161
Visual MSIDiff setting required version 167
key to icons 85, 321 WebDeploy
about 194 Windows XP
using 85 service, adding 159
with source control 320, 320 process overview 197
setting options 198 service, controlling 161
Visual SourceSafe 316
tips 198 Winnt directory
Visual Studio .NET, integrating with 20 uploading installation 199 adding item 116

WinSxS 116, 125 WiseLangString table 404 WiseTestSqlConn 487
Wise Automation 457 WiseLanguage table 404 WiseUpdate
Wise custom actions 483 WiseMaskedProperties 422 about 287
configuring 291
Wise editor 20 WiseMediaOptions table 404
process overview 289
Wise Installation System WiseMetaDataCache table 404 running from application 296
converting from 358 WiseMobileDevice table 404 troubleshooting 297
editing script 473
WiseMobileDeviceDesktopFiles updating file 291
Wise options table 404 uploading 293
See options WiseModuleConfiguration table 404 WiseUpdate page 287
Wise Package Studio 30 WiseModuleSignature table 404 WiseUpgradeCheck 487
Wise PocketPCShortcut table 404 WiseNextDlg 487 WiseUpgradeCheckEx 487
Wise Software Repository WisePageLists table 404 WiseVersionInfo table 405
about 31
WisePathReplacement table 404 WiseVirtDirCallDll 487
Wise Standard.msi 437
WisePathVariable table 404 WiseVSOutput table 405
Wise Task Manager
WisePocketPCFile table 404 WiseVSOutputGroup table 405
about 379
using 380 WisePocketPCPlatform table 404 WiseVSProject table 405
Wise Task Manager task 379 WisePocketPCRegistry table 404 WiseWildcard table 405
WISE_SQL_CONN_STR 426, 452 WisePrerequisites table 405 WiseWildcardFile table 405
WiseAdvertising table 403 WisePrevDlg 487 WiseWriteWebXMLDll 487
WiseAltStartup 486 WiseRegComPlus 487 wizard
WiseRelease table 404, 405 See tools
WiseCleanup 486
WiseReleaseExclude table 405 wizard dialogs 428
WiseComCapture.exe 140
WiseReleaseMedia table 405 word count 385
WiseCommandLine table 403
WiseReleaseMediaDest table 405 WSE file, converting 358
WiseComPlusApp table 404
WiseReleaseMediaInclude table 405 WSI file
WiseComPlusComponent table 404
creating 70, 72
WiseCRLF 420 WiseReleaseOverride table 405
defined 67
WiseDebugMode 418 WiseScript working with 68
calling 473
WiseDialogFontDefault 418 WSM file
calling from destination 510
WiseDialogSuffix 418 Also see merge module
calling from installation 511
WiseDialogTitleFontDefault 418 calling from installed file 512 defined 67
WiseFeatureCondition table 404 converting to Windows WSPROJ file 67
WiseFindSqlClientTools 486 Installer 358 wwwroot 223
editing from Prerequisites
WiseFixConditions merge module
See CondFix.msm
page 191 X
editing tools 473 XML
WiseGetASPNETUser 486 example 474 editing attributes 137
WiseGetDotNetVersion 486 parsing pathname 474
XML format installation
WiseGetIEVersion 486 resetting from Prerequisites
about 86
WiseGetIISFeaturesEnabled 487 page 192
create during save 39, 86
security 475
WiseGetIISVersion 487 exporting to 86
silent installation 473
WiseGetSQLServers 487 integrating with source
uninstalling 476
WiseGetSQLServerVersion 487 control 315
WiseScript Editor 473
WiseIISValidateInput 487 WiseScript Express 473
WiseInitAdminError 420 WiseScript runtime
WiseInitCmdLine 421 adding 190
WiseInitExistError 421 WiseSequence table 405
WiseInitLangDefault 421, 424 WiseSingleFileCheck 487
WiseInitLangPrompt 424 WiseSourcePath table 405
WiseInitPrefix 421, 424 WiseSql1.sql 235
WiseInitProductName 421 WiseSQLCallDLL 487
WiseInitProgressText 421, 424 WiseStartup 487
WiseInitSpaceError 421 WiseStreamFiles table 405
WiseInitSuffix 422, 424 WiseTaskList table 405

Altiris

Uploaded by

Copyright:

Available Formats

You might also like

Altiris

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Altiris

Uploaded by

Copyright:

Available Formats

Wise for Windows Installer

Wise for Windows Installer Reference 2

Wise for Windows Installer Reference 3

Chapter 4: Working With Wise Installation Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Chapter 5: Defining an Installation Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Wise for Windows Installer Reference 4

Chapter 6: Assembling an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Wise for Windows Installer Reference 5

Chapter 7: Your Installation on the Destination Computer . . . . . . . . . . . . . . . . . . . . . 166

Chapter 8: Organizing Your Installation Into Releases . . . . . . . . . . . . . . . . . . . . . . . . 178

Chapter 9: Advanced Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Wise for Windows Installer Reference 6

Chapter 10: Mobile Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

Chapter 11: Translating an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Wise for Windows Installer Reference 7

Chapter 12: Distributing an Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Chapter 13: Upgrading Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Wise for Windows Installer Reference 8

Chapter 15: Merge Modules and Transforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Chapter 16: Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Wise for Windows Installer Reference 9

Chapter 17: Setup Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

Chapter 18: Using Conditions and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Wise for Windows Installer Reference 10

Chapter 19: Working With Dialogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427

Chapter 20: Macro Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

Chapter 21: Debugger for Windows Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

Wise for Windows Installer Reference 11

Chapter 22: Using MSI Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

Chapter 23: Custom Action Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Wise for Windows Installer Reference 12

Chapter 24: Windows Installer and .NET Technologies . . . . . . . . . . . . . . . . . . . . . . . . 521

Wise for Windows Installer Reference 13

With Wise for Windows Installer, you can:

z Import development projects.

Microsoft® Windows® Installer is a Microsoft technology that provides a standard

z Getting Help and Product Support.

z How to Check Online Help.

z Getting Updates Over the Web.

Use the following sources of information to learn the product.

Wise for Windows Installer Reference 14

Getting Started Guide

Windows Installer SDK Help

z Browse the product CD.

z If you are a registered customer, visit http://support.wise.com to enter the Support

Also see Getting Help and Product Support.

Getting Help and Product Support

Also see Documentation Roadmap.

Check Online Help

Wise for Windows Installer Reference 15

Use the Technical Support Center

Visit Our Newsgroups

Ask Our Support Team

Before you contact technical support, obtain the following:

z Operating system version and service pack version if applicable.

z A description of what you do before the problem occurs.

z The text of any error messages that appear.

z Your name, company name, and how to contact you.

z Contract number or payment information, if applicable.