Beruflich Dokumente
Kultur Dokumente
Legal Notice
Copyright © 2010 Symantec Corporation. All rights reserved.
Symantec, the Symantec Logo, and Altiris are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and
other countries. Other names may be trademarks of their respective owners.
The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse
engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec
Corporation and its licensors, if any.
THE DOCUMENTATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES,
INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE
DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT
BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS
DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE.
The Licensed Software and Documentation are deemed to be commercial computer software as defined in FAR 12.212 and subject to
restricted rights as defined in FAR Section 52.227-19 “Commercial Computer Software - Restricted Rights” and DFARS 227.7202, “Rights in
Commercial Computer Software or Commercial Computer Software Documentation”, as applicable, and any successor regulations. Any use,
modification, reproduction release, performance, display or disclosure of the Licensed Software and Documentation by the U.S. Government
shall be solely in accordance with the terms of this Agreement.
Symantec Corporation
350 Ellis Street
Mountain View, CA 94043
http://www.symantec.com
z A range of support options that give you the flexibility to select the right amount of
service for any size organization
z Telephone and/or web-based support that provides rapid response and up-to-the-
minute information
For information about Symantec’s support offerings, you can visit our web site at the
following URL:
www.symantec.com/business/support/
All support services will be delivered in accordance with your support agreement and the
then-current enterprise technical support policy.
www.symantec.com/business/support/
Before contacting Technical Support, make sure you have satisfied the system
requirements that are listed in your product documentation. Also, you should be at the
computer on which the problem occurred, in case it is necessary to replicate the
problem.
When you contact Technical Support, please have the following information available:
z Hardware information
z Operating system
z Network topology
z Problem description:
www.symantec.com/business/support/
Customer service
Customer service information is available at the following URL:
www.symantec.com/business/support/
To access more information about Enterprise services, please visit our Web site at the
following URL:
www.symantec.com/business/services/
Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 1: Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
About Windows Installer Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Starting the Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
The Product Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
About Visual Studio Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
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
Using the Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Filtering the Task List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Finding Table Errors From the Task List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Adding User-Defined Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Installation Resources and Their Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Generating Package Contents Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Downloading Redistributable Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Downloading Redistributables From the Wise Web Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Downloading Redistributables From Other Vendors’ Web Sites . . . . . . . . . . . . . . . . . . . . . . . . 31
Product Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Chapter 2: Setting Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
How you can set up Windows Installer Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Setting Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Setting General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Setting .NET Assembly Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Setting Advertising Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Setting Digital Signature Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
About ExpressBuild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Setting ExpressBuild Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
How ExpressBuild Groups Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Requirements for Using ExpressBuild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Setting Installation Expert Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Setting Merge Module Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Activating Suppressed Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Setting Source Control Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Setting Visual Studio Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Setting Wildcard Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Creating and Editing Installation Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
About Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Selecting a Component Rule Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Using Component Rules to Align GUIDs in an Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Customizing Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Adding and Editing Component Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Microsoft Best Practices Component Rule Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
z Create installations that are compliant with the Microsoft Windows 2000, XP, and
Vista logo program.
z Edit and refine installations that you have converted from other formats.
Through its Visual Studio integrated editor, Windows Installer Editor offers a complete,
seamless integration of the entire installation authoring environment directly into the
Microsoft® Visual Studio® 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.
The Windows Application icon lets you create a standard installation. You can
create other types of installations.
See Starting a New Installation on page 71 and Options for New Installations on
page 77.
d. In Target Platform, specify whether this installation is enabled for 32-bit, 64-
bit (x64), or 64-bit (Itanium) platforms. This sets the initial target platform for
the Default release.
e. If the application has been written to be installed and run by standard users
without elevation, mark Create a Vista Standard User Installation. This
clears the Enable User Account Control (UAC) check box in Installation
Expert > Windows Installer Options page.
f. Click OK.
See also:
Installation Expert Installation Expert lets you create basic Windows Installer
installations and provides an easy-to-use, task-oriented user
interface to perform the most common installation tasks.
Each page of Installation Expert lets you configure a specific
aspect of your installation.
MSI Script is easy to work with even if you are not familiar
with the underlying Windows Installer technology. Just
double-click the custom action to add to your sequence or
start typing the action name, then fill out options for the
action. A new line based on the action and the options you
entered appears in the sequence at the location of the last
selected action. The resulting sequence is displayed in clear,
readable statements.
To navigate between views, click the navigation tabs at the lower left of the main
window.
Additional Interfaces
z The Tools menu contains powerful tools that perform specialized functions.
See About Windows Installer Editor tools on page 336.
z The Compile, Test, Debug, and Run buttons let you test and compile the installation.
See Compiling An Installation on page 87, Testing and Running An Installation on
page 88, and About the Debugger on page 427.
z You can use Windows Installer Editor from within Visual Studio.
See About Visual Studio Integration on page 19.
There are several differences between the Wise editor and the Visual Studio integrated
editor that are inherent in the Visual Studio 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
the Visual Studio build configuration.
When you create an installation project in Visual Studio, 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.
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 box 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, 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. Perform a repair on
Windows Installer Editor to remove options that have to do with the Visual Studio
integrated editor
Note
The Visual Studio AutoRecover is disabled for Wise projects.
See also
Page Views
Page Area
Page Groups
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 only
the pages that are pertinent to your particular installation, in any order. If required
information is missing, an error message appears during compile.
z Use on the toolbar to navigate from page to page, or click the page name in
the list of pages.
z To return a 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.)
In Visual Studio: These buttons are not available, but the same functionality is available
through menu commands.)
See also:
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 49.
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.
You can select a different page view from the list at any time, except when you are
working in a merge module. Merge module projects cannot use other page views, and
their page views cannot be used with other types of projects.
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 check box in Wise Options.
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.
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.
See also:
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.
To create an access key for the name, type & (ampersand) before a letter in the
name. The page view access keys appear only in the page group’s right-click menu,
which you access from the context menu key (the key next to the right Ctrl key).
3. Click OK.
On the Customized Page Views dialog box, the new page view is selected in Page
View Name, but it has no page groups or page names.
The Merge Module page view does not appear on the list because it cannot be
copied.
You can now customize the page view by changing its page groups and pages.
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. On the Select Pages to Add dialog box, select one
or more pages and click OK.
To delete a page group or a page name, select it and click its Delete button.
To delete a page view, select it from Page View Name and click the top Delete button.
See also:
Example: Suppose you have three 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.
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.
See also:
See also:
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 28.
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 deleted.
z Package Validation
When you run Package Validation, validation issues appear on the View / Correct
dialog box. If you mark the Add to Task List check box on the View / Correct
dialog box, 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.
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.
z User-Defined
You can add user-defined tasks to the task list.
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.)
2. Select a filter. (In Visual Studio: right-click in the Visual Studio Task List and select
Show Tasks.)
Save/Compile
(In Visual Studio: this is called Build Errors.) Tasks that correspond to errors
that are generated when you save or compile.
Validation
Tasks that correspond to issues that are generated during Package Validation.
Component
Tasks that correspond to component errors that are generated when you check
tables.
Table
Tasks that correspond to table validation errors that are generated when you
check tables.
User-Defined
Tasks that you have created.
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.
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.
Warning
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.
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.
See also:
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.
See also:
Directory Contents
Custom Actions Files that you create to use in custom actions, such as WiseScripts, VBScripts, .DLLs,
and so on, that you use in Windows Installer installations.
Languages Language resource files that are used to change the language of installations.
Resources Installation resources such as bitmap and icon files.
Templates Macros and additional template files that are used by Package Distribution.
Templates\Dialogs The Wise Standard.MSI that provides information that is used by the New Dialog
Wizard to add a new dialog box to an installation.
Templates\File Templates that are used to create a new installation.
In the Visual Studio integrated editor, these templates create installations that are
not associated with a Visual Studio solution.
Templates\Project (Visual Studio integrated editor only.) Templates that are used to create an
installation as a project within a Visual Studio solution.
Templates\Reports Templates that are used to format the shared resources reports in Windows Installer
Editor. These reports are available only when you have a repository connection in
Wise Installation Studio.
Themes Themes.ini, which stores information about themes you have added or customized.
Also contains subdirectories that store the images for each theme.
Validation Predefined validation modules (.CUB files) that are used by Package Validation.
In Visual Studio: Project menu > Reports > Package Contents and select either
Summary or By Feature.
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.
This wizard appears any time Windows Installer Editor detects a dependency on other
merge modules or other redistributables. Example: If you run ApplicationWatch and it
adds a file 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.
Wise Web Site Select and download one or more redistributables from the
Wise Web site.
If you need to go through a firewall or proxy server to get to the Internet, the Download
Redistributables wizard uses your browser’s proxy settings. To change your Internet
connection settings, refer to your browser’s documentation.
In Visual Studio: Help menu > Wise Help > Download Redistributables.
A Download Files dialog box appears while all available redistributable files are
retrieved. The Available Redistributable Files dialog box then appears.
4. In the Modules Available or Versions Available list, mark one or more check
boxes for the redistributables to download.
5. Click Next.
If you chose to download any merge modules, the Target Location dialog box
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 Windows Installer Editor.
6. 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.
7. Click Finish on the Download Files dialog box to finish 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.
See also:
In Visual Studio: Help menu > Wise Help > Download Redistributables.
When all available redistributables are retrieved, the Available Redistributable Files
dialog box 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.
5. When the download is complete, return to the Available Redistributable Files dialog
box 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.
See also:
Product Documentation
This 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.
Online Help
The online help contains detailed technical information and step-by-step instructions for
performing common tasks.
z To display context-sensitive help for the active window or dialog box, press F1.
z To select a help topic from a table of contents, index, or search, select Help menu >
Help Topics.
z In Visual Studio, select Help menu > Wise Help > Help Topics.)
Reference Manual
All the material in the online help is also available in a .PDF-format reference manual,
which you can access by selecting Help menu > Reference Manual.
Version 4.5 of the Windows Installer SDK Help is provided. If you have obtained a later
version, links from the Wise product documentation to the Windows Installer SDK Help
might not work.
To access the Windows Installer SDK Help in Visual Studio, select Help menu > Wise
Help > Windows Installer SDK Help. Windows Installer SDK help topics are also available
within the Visual Studio help collection.
Release Notes
The product release notes cover new features, enhancements, bug fixes, and known
issues for the current version of this product. To access the release notes, select Release
Notes from the Symantec program group on the Windows Start menu.
z Set options that control the installations you create and determine the installation
resources you use.
See Setting Options on page 34.
z Decide whether you need to customize the templates that installations are based
on.
See Creating and Editing Installation Templates on page 49.
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.
See Component Rules on page 51.
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 Windows Installer Editor, 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 box, 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 box.)
The Options dialog box contains the following tabs. (In the Visual Studio integrated
editor they are called pages.) See:
In Visual Studio: Tools menu > Options > Wise Options > General.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
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.
Compiler Options
The following options are default settings for all new compiles. Changing these settings
does not affect installations that have already been compiled.
Note
Windows Installer Editor has its own code for merging a module into an .MSI, but
this check box 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
Windows Installer Editor code sets the predefined directory name by adding an item
to the Directory table of the Windows Installer database.
Startup Options
z Reload last project at startup
Mark this to open the last installation you worked on when you start Windows
Installer Editor.
z Preferred Editor
This option appears only if Microsoft Visual Studio is installed. It determines which
editor is opened when you double-click a Windows Installer file. Always Prompt
always displays a dialog box that prompts you to choose the editor. Last Saved In
uses the editor in which the installation file was last saved.
See also:
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
To set options:
Select Tools menu > Options and click the .NET Assemblies tab. (In Visual Studio: Tools
menu > Options > Wise Options > Assemblies.) Complete the tab.
If the options on the .NET Assemblies tab are unavailable, install the .NET Framework
and run a manual repair of the Windows Installer Editor .MSI from Add/Remove
Programs. (Not applicable in the Visual Studio integrated editor.)
.NET Application
Select this if you typically create .NET installations with only .NET elements.
z Scan Dependencies
Specify how dependency assemblies are added to an installation. You can add them
manually or have Windows Installer Editor scan the assembly manifest for
dependencies and add them automatically. Changing this option does not affect
assemblies that have already been added to installations.
Note
On .NET Framework versions earlier than 1.1, the scan 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.
See also:
The Advertising options are default settings for all new components. Changing these
settings will not affect existing components.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
To set options:
Select Tools menu > Options and click the Advertising tab. (In Visual Studio: Tools menu
> Options > Wise Options > Advertising.) Complete the tab.
z Advertising Setting
Select one of the “scan” options to have Windows Installer Editor 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.
However, the .OCX or .DLL files must already be registered correctly on your
computer. If you prefer not to register installation files on your computer, you can
run the scan routine as a stand-alone utility on a different computer.
Warning
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.
This field sets the default for new components; if you change it, existing
components are not affected. The Rescan advertising information during
compile check box on the Component Details dialog box can override this setting
for individual components.
See also:
The Digital Signature options provide default settings for the Digital Signature page and
Patch Creation. These options apply to all future installation and patch files. They do not
affect existing files.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
To set options:
Select Tools menu > Options and click the Digital Signature tab. (In Visual Studio: Tools
menu > Options > Wise Options > Digital Signature.) Complete the tab.
Signcode.exe Location
Enter the path of the signcode.exe that performs the signing tasks.
Credentials File
Enter the path of the credentials file that contains your Digital ID.
Signtool.exe Location
Enter the path of the signtool.exe that performs the signing tasks.
See also:
About ExpressBuild
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 you
select 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.
See:
Before you use ExpressBuild, verify that you meet the requirements for using
ExpressBuild options and review the reasons why multi-processor compile might not
work.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
To set options:
Select Tools menu > Options and click the ExpressBuild tab. (In Visual Studio: Tools
menu > Options> Wise Options > ExpressBuild.) Complete the tab.
You can mark any combination of the three check boxes below. After you mark either of
the first two check boxes, compiles will try 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 also:
z If Windows Installer Editor 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 check box. (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 box, 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.
See also:
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.
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.
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.
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.
See also:
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
To set options:
To set options for Installation Expert, select Tools menu > Options and click the
Installation Expert tab.
In Visual Studio: Tools menu > Options > Wise Options > Installation Expert.
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.
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 check box, the page view in Installation Expert does not
change when you open a project regardless of its associated page view.
See also:
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.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
To set options:
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 box.
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 Directory
Enter additional directories where merge modules are stored. Merge modules in
these directories are listed on the Select Merge Modules dialog box. Example: If you
save your organization’s user-created merge modules in the shared network
directory 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 box.
To add a directory to the list, click Add, browse for the directory, and click OK. To
include subdirectories in the search, mark the check box 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 box.
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
box.
See also:
In Visual Studio: Tools menu > Options > Wise Options > Prompts.
The dialog box lists the prompts you have suppressed and shows your last response
to each prompt. If you have not suppressed any Windows Installer Editor prompts,
nothing is listed.
The prompt is removed from the list. The next time you encounter a situation in
which that prompt applies, the prompt will appear.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
See also:
The Source Control options apply to the current installation and all future installations.
Changing these options does not affect existing installations.
To set options:
Select Tools menu > Options and click the Source Control tab. Complete the tab.
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.
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.
See also:
The Visual Studio options provide defaults for future installations. Changing these
options does not affect existing installations.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
To set options:
Select Tools menu > Options > Wise Options and click Visual Studio. Complete the tab.
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.
z Scan Method
Each time you load, save, or build an installation project or change its settings,
Windows Installer Editor can scan the other projects in the solution for new files to
add to the installation.
Specify the default level of scanning that will occur for new installations.
z Create Shortcut
Mark this to add a shortcut for the main target file to each installation.
See also:
On the Files page 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 dialog boxes. 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 when the application starts. Also, wildcards that you enter in any Include
Wildcards field are added to the list of wildcard groups.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
In Visual Studio: Tools menu > Options> Wise Options > Wildcard Groups.
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.
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 page, this wildcard
group is available from the Include Wildcards list.
See also:
Example: If all your installations have the same system configuration requirements and
document file extensions, you can create a template with these changes preconfigured.
Warning
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.
z Templates\Project contains templates for new projects that are integrated with a
solution.
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.
3. Make all the changes that should appear in installations that will be created with this
template.
4. To include a description that will appear on the New Installation File dialog box when
you click this template:
d. On the Summary Details dialog box that appears, enter a description of this
template in Value and click OK.
b. Name the file and save it in the Templates directory as a .WSI, .MSI, .WSM, or
.MSM.
When you save the 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 custom
page view, you can customize it.
The New Installation File dialog box appears and the file that you just created
appears in the Custom Templates category. If the New Installation File dialog box
does not contain the new template, verify that you saved it in the correct format
and location.
8. Verify that the changes you made in the template are present in this new
installation.
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.
6. Make all the changes that should appear in installations created with this template.
If you saved the template in the Templates\Project directory, select File menu >
New > Project. On the New Project dialog box, 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 box, click Wise Files in the Categories list.
Your new template should appear in the Templates list.
10. Verify that the changes you made in the template are present in this new
installation.
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 organization’s standards. For descriptions of
the predefined rule sets, see Microsoft Best Practices Component Rule Set on page 57
and One File Per Component Rule Set on page 59. For instructions on creating new rule
sets, see Customizing Component Rules on page 55.
See also:
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.
See also:
The component key values you enter on the Component Rule Selection dialog box 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.
In Visual Studio: Project menu > Component Rules > Select Rule Set.
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.
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.
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.
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.
See also:
If you are working on an upgrade installation, you specify the previous versions of the
installation on the Previous Installation Versions dialog box. Then, make sure you use a
component rule set that contains a rule for aligning component GUIDs with previous
versions. Example: The two 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.
2. If you have already added resources to the upgrade installation, run UpgradeSync
to align GUIDs for existing components.
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.
In Visual Studio: Project menu > Component Rules > Previous Versions.
5. On the Previous Installation Versions dialog box, 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.
All new resources you add to the upgrade installation will be checked against and
aligned with the previous installations you specified.
See also:
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.
The Component Rules Manager dialog box appears, listing the predefined rule sets
and custom rule sets you have created.
2. Click New.
3. Enter a unique Rule Set Name to identify this rule set and click OK.
The new rule set name appears and is selected in the Component Rules Manager
dialog box.
4. Click Modify.
5. On the Customize Component Rules dialog box, 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.
6. When you finish adding rules to the rule set, click OK on the Customize Component
Rules dialog box and then click OK on the Component Rules Manager dialog box.
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.
The Component Rules Manager dialog box appears, listing the predefined rule sets
and any custom rule sets you have created.
To copy the rule set, click Copy, type the new name on the Enter Rule Set Name
dialog box, and click OK.
To modify the rule set, click Modify. The Customize Component Rules dialog box
appears, where you can add, edit, and delete rules.
See Adding and Editing Component Rules on page 56.
Note
If you selected a predefined rule set, all the buttons on the Customize
Components Rules dialog box are unavailable because the predefined rule sets
are read-only. However, you can use this dialog box 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 box, and click OK.
To delete the rule set, click the Delete button to the right of the rule set name.
See also:
The predefined rule sets, Microsoft Best Practices and One file per component, are read-
only and cannot be modified.
The Component Rules Manager dialog box appears, listing the predefined rule sets
and any custom rule sets you have created.
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 box.
4. Click OK.
2. In the Which condition(s) do you want to check? list, mark the check box 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 check boxes, the conditions appear in the Rule description list. If you
select a condition that is incompatible with a condition you have 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 box. 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 have added all conditions that comprise the rule, click Next on the
Conditions page.
5. In the Which action(s) do you want to perform? list, mark the check box next
to the action or actions to perform.
The actions you mark appear in the Rule description list. If you select an action
that is incompatible with an action you have 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 box. 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 have added all actions to the rule, click Finish on the Actions page.
The Customize Component Rules dialog box 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 box.
The new rules are added to the rule set and the Component Rules Manager dialog
box reappears.
9. Click OK.
See also:
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.
an incremental number is added to the component name. Example, File1, File2, and
so on.
See also:
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 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 Any changes that should be made to the dialog boxes that will be displayed during
installation.
See Using the Dialogs Page on page 395.
File Types
In Windows Installer Editor, 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.
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 Windows Installer Editor. However, options that have to do with
creating an .MSI, such as those on the Releases, Release Settings, and Media pages,
are unavailable.
Extension Description
.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 that you
distribute to end users.
.PCP Windows Installer patch project, which describes and compiles to a Windows Installer
patch. A .PCP file is created from the Patch Creation tool.
.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 the Windows Installer runtime before
performing your own installation, which ensures that the installation will run.
See Setting Build Options for a Release on page 199 and Adding Prerequisites to a
Release on page 200.
On the Build Options page (see Setting Build Options for a Release on page 199) or on
the Media page (see Setting Up Media for Distribution on page 208), you can specify to
output an installation in different ways:
If you to output an .EXE, you can then pre-install Windows Installer or other runtimes.
When you create an installation, you can work in a .WSI (project) file or an .MSI file.
The same applies to merge modules; you can work in a .WSM (project) file or an .MSM
file.
Note
Do not confuse the Wise installation project file (.WSI) with the Visual Studio project file
(.WSPROJ).
Windows Installer Editor supports both x64 (for AMD64 and Intel EM64T processors) and
64-bit Itanium platforms.
z An Itanium installation will not run on an x64 platform, and vice versa.
z On the Registry page, you cannot browse the 64-bit registry in the upper list boxes.
However, you can add 64-bit registry keys in the lower list boxes, and you can
import .REG files that contain 64-bit keys.
See:
The Template Summary property of the .MSI is set during compile based on the
release’s Target Platform setting. The initial target platform for the Default release is
set by the Target Platform option on the New Installation File dialog box.
When an installation project (.WSI) contains multiple releases that compile to 32-bit and
64-bit .MSIs, the Template Summary property reflects one platform or the other. The
correct Template Summary property is set in each .MSI during compile.
See Configuring a Feature Using the Feature Details Dialog on page 103.
Condition Builder
Condition Builder contains additional property values:
Registry page
z The upper list boxes can display the 32-bit or 64-bit registry. The 64-bit registry is
visible only if your computer is running a 64-bit operating system.
z The lower list boxes can display the 32-bit or 64-bit registry on any computer.
z You can add registry keys and values to the 32-bit or 64-bit registry on any
computer.
Prerequisites page
In a 64-bit installation, you can specify a prerequisite for the x64 or IA64 (Itanium)
edition of the .NET Framework. To download these runtimes, use the Wise Web Site
option of the Download Redistributables wizard.
Custom actions
Windows Installer Editor does not contain 64-bit versions of custom actions, however:
z When you create a custom action that calls a JScript or VBScript file, a check box
lets you indicate that the script needs to access 64-bit functionality and run in a 64-
bit process.
z The following Call Custom DLL actions can call 64-bit .DLLs:
Call Custom DLL From Destination
Call Custom DLL From Installation
Call Custom DLL From Installed Files
Because .DLLs are processor-specific, the .DLL that you call must target the same
platform (32-bit, x64, or 64-bit Itanium) as the installation. In a mixed-target
project file (.WSI), condition each Call Custom .DLL custom action for the
appropriate platform.
z Providing separate logical views of key portions of the registry, intercepting 32-bit
registry calls to each logical registry view, and mapping them to the corresponding
physical registry location. The reflection process is transparent to the application.
Therefore, a 32-bit application can access registry data as if it were running on 32-
bit Windows even if the data is stored in a different location on 64-bit Windows.
When an installation contains both 32-bit and 64-bit components, place files and
registry keys in the appropriate location for the platform they target.
z Place the keys in the 32- z Place the keys in the 62-bit registry view.
bit registry view. They will
z Mark the component as 64-bit on the
be installed in the
Component Details dialog box.
WOW6432Node (for hives
that have a WOW6432
node).
Search for “Running 32-bit Applications” and “WOW64 Implementation Details” in the
MSDN Library (msdn.microsoft.com/library/).
z Set the target platform for all features to 32-bit. A 64-bit feature in a 32-bit
installation will never be installed.
z Add resources to the installation as usual. Do not add 64-bit components to a 32-bit
installation.
z Set the target platform for all releases to 32-bit (this is the default).
z Add resources to the installation as usual. When you add 64-bit .EXE and .DLL files
or 64-bit registry keys, they are designated as 64-bit components. (The 64-bit
component check box is marked on the Component Details dialog box.)
z AMD 64-bit computers require Windows Installer version 3.0 or later. If your
installation targets AMD 64-bit computers, include a system requirement to check
the destination computer’s Windows Installer version.
z AMD 64-bit computers require Windows Installer version 3.0 or later. If your
installation targets AMD 64-bit computers, include a system requirement to check
the destination computer’s Windows Installer version.
You can create a single installation project (.WSI) that can produce 32-bit and 64-bit
installation files.
See Creating Multiple, Platform-Specific Installations from One Project File on page 68.
z A 64-bit merge module can be merged into a 64-bit installation. The processor type
(x64 or Intel64) of the merge module must match that of the installation.
See also:
Example:
You develop a graphics suite that consists of features for drawing, graphing, and page
layout. The application was originally developed as a 32-bit application, and you will
continue to support a 32-bit version, but you also will release a version that contains
some 64-bit components. To save development time, you want to maintain a single
installation project (.WSI) that can produce installation files for both platforms.
z Organize the project by feature. Do this to let the end user choose from different
platform-specific features during installation. In a large installation, this method will
work better than organizing the project by component.
Note
If you add a 64-bit component to a 32-bit feature, it will never be installed. A 64-bit
component will be ignored during installation on a 32-bit computer, and a 32-bit
feature will not be installed on a 64-bit computer.
z Organize the project by component. This method results in fewer features and
possibly less duplication. However, in a large installation, it might be less efficient to
have to assign a target platform to each component.
2. On the Features page, create separate features for the different target platforms.
Example:
3. When you add files, registry keys, and other resources to the installation, be sure to
select the appropriate feature. Example: Add Chart32.exe to the Charting32
feature, and add Chart64.exe to the Charting64 feature.
4. In MSI Script, add a custom action to set the value of the INSTALLDIR property.
5. On the Releases page, create a release for each target platform. Example:
Graphic32, Graphic64.
6. On the Release Settings page, select the features to include in each release.
Example:
Graphic32.msi, which runs installs only 32-bit components and runs on any
platform. Its Template Summary property is set to Intel, which represents a 32-
bit installation.
Graphic64.msi, which installs both 32-bit and 64-components and runs on x64
platforms only. Its Template Summary property is set to x64.
2. When you add files, registry keys, and other resources to the installation, put both
32-bit and 64-bit items in a single feature. Example: Add both Chart32.exe and
Chart64.exe to the Charting feature.
3. In MSI Script, add a custom action to set the value of the INSTALLDIR property.
4. On the Releases page, create a release for each target platform. Example:
Graphic32, Graphic64.
5. On the Release Settings page, select the components to include in each release.
Example:
Graphic32.msi, which installs only 32-bit components and runs on any platform.
Its Template Summary property is set to Intel, which represents a 32-bit
installation.
Graphic64.msi, which installs both 32-bit and 64-components and runs on 64-
bit platforms only. Its Template Summary property is set to x64.
See also:
To define the second installation directory, add a custom action to set the default value
of INSTALLDIR based on the destination computer’s platform. Place the custom action at
the beginning of the installation initialization. You only need a custom action for the
undefined installation directory.
If VersionNT64 then
Set Property INSTALLDIR to [ProgramFiles64Folder]\QuickFacts
End
If the destination computer’s target platform is 64-bit, then the default installation
directory is Program Files\QuickFacts. If it is 32-bit, then the original installation
directory is used.
See also:
The New Installation File dialog box appears. If it does not appear, select File menu
> New.
6. If the application has been written to be installed and run by standard users without
elevation, mark Create a Vista Standard User Installation. This clears the
Enable User Account Control (UAC) check box in Installation Expert > Windows
Installer Options page.
z Windows Installer Editor warns you when you make a change in the installation that
is incompatible with a standard user installation:
On the Files page, the default installation folder in the lower-left list box is
Windows\Profiles\Local Settings\Application Data instead of Program Files.
On the Files page, a warning message appears when you try to add a file to a
protected area.
On the Registry page, a warning message appears when you try to add a
registry key to a protected area.
z The DisableUAP property is set, which hides the option to install for all users or the
current user on the installation’s User Information dialog box.
z The Destination Folder dialog box does not appear because letting the end user
change to a directory that is not per-user would cause the installation to fail.
z The User Account Control dialog box that prompts end users for administrator
credentials does not appear.
Installations that were created in a Wise product earlier than Wise Package Studio 7.0
SP1 or Wise Installation Studio 7.0 run as if User Account Control is enabled.
See also About UAC Elevation of Windows Installer Installations on page 183.
In Installation Expert > Windows Installer Options page, clear the Enable User
Account Control (UAC) check box.
See Setting Version-Specific Windows Installer Options on page 181.
On the New Installation File dialog box, mark Create a Vista Standard User
Installation. This clears the Enable User Account Control (UAC) check box
in Installation Expert > Windows Installer Options page.
This option is not available in the Visual Studio integrated editor.
2. As you develop the installation, do not access or install to protected areas. Example:
the Program Files or Windows System directories, or the HKLM or HKCR sections of
the registry.
the other projects in the solution, additions or changes you make in the other projects
can be added to the installation automatically. See How the Installation Integrates With
the Solution on page 83.
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 78.
You can create a stand-alone installation that is not integrated with a Visual Studio
solution. See Creating a Stand-alone Installation on page 75.
You also can create other types of installations. See Options for New Installations on
page 77.
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.
3. In the Project Types list, select Wise Setup and Deployment Projects.
Select the Setup Wizard icon to create a new Windows Application installation
and enter its project settings.
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.
5. In Name, enter a name for the installation file. In Location, specify the directory in
which to save the project.
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.
b. On the wizard’s Project Type page, select the Windows Application option.
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.
See also:
You can create an installation that is part of a Visual Studio solution. See Creating an
Installation Within a Solution on page 73.
You also can create other types of installations. See Options for New Installations on
page 77.
See File Types on page 61 and Project Files and Database Files on page 62.
5. Click Open.
See also:
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.
Note
Early versions of this merge module might be named “Binaries.”
2. Make sure the device driver you are installing meets the Microsoft DIFx driver
requirements.
Start a new installation and select the Device Driver icon on the New
Installation File dialog box.
See Starting a New Installation on page 71.
(In Visual Studio: Start a new stand-alone installation and select the Device
Driver icon on the New File dialog box.
Start a new installation and select the Device Driver icon on the New
Installation File dialog box.
See Starting a New Installation on page 71.
4. On the Merge modules page, add the Microsoft DIFxApp merge module to the
installation.
5. On the Features page, add a feature for the installation’s 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.
7. To add additional driver packages repeat the preceding steps, except for adding the
DIFxApp merge module.
Setup Wizard
(Visual Studio integrated editor only.) Runs a wizard that creates a Windows Application,
Server Application, or Merge Module installation. With this wizard, you can customize
the settings rather than accepting the defaults of the standard templates.
Windows Application
Creates a standard installation with default settings.
In the Visual Studio integrated editor, see Creating an Installation Within a Solution on
page 73 or Creating a Stand-alone Installation on page 75.
Device Driver
Creates an installation that installs a device driver. This template supports Microsoft
Driver Install Frameworks (DIFx). Use it with 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).
Windows Mobile
Opens the Windows Mobile wizard, which lets you add Windows Mobile .CAB files to a
desktop installation. The wizard is also accessible from the Mobile Devices page.
Palm Application
Opens the Palm OS wizard, which lets you add Palm OS files to a desktop installation.
The wizard is also accessible from the Mobile Devices page.
Transform
Lets you change any aspect of an installation by creating a transform based on changes
that you make to the installation.
Merge Module
See Creating a Merge Module As a New Installation on page 316.
In Visual Studio: see Creating a Merge Module Within a Solution on page 318 or
Creating a Merge Module As a New Installation on page 316.
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.
z Visual Basic
(In Visual Studio: this is named Import Visual Basic.)
z Visual C#
(Not available in the Visual Studio integrated editor.)
z Visual J#
(Not available in the Visual Studio integrated editor.)
Stand-alone installations that are not integrated with a Visual Studio solution do not
have project settings.
z While creating a new installation project, select Setup Wizard on the New Project
dialog box.
See Creating an Installation Within a Solution on page 73.
The Wise Setup Wizard dialog box appears. Available pages are: Overview, Project
Type, Projects, and Main Project.
The Property Pages dialog box appears. Available pages are: Projects, Project
Outputs, Main Project, Pre-build Event, and Post-build Event.
Note
The Property Pages dialog box contains a link to the Configuration Properties page,
however, configuration properties do not apply to Wise editor installation projects.
See also:
Overview Page
¾ Visual Studio integrated editor only.
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.
See also:
z Windows Application
Create a standard Windows Installer installation (.WSI). This is intended for
installation to Windows computers or servers.
z Merge Module
Create a standard merge module project (.WSM).
See also:
Projects Page
¾ Visual Studio integrated editor only.
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.
If you add a project to this solution later, it will be added to the project list and
selected for inclusion.
z Scan Method
Each time you load, save, or build an installation project or change its settings,
Windows Installer Editor can scan projects in the solution for new files to add to the
installation.
Specify the level of scanning that will occur for this installation. The default is
determined by the Scan Method option in Wise Options.
See also:
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 Create Shortcut
Mark this to add a shortcut for the main target file to the installation. The default is
determined by a check box in Wise Options. This is unavailable if you select
<None> in Main Project.
See also:
Pre-build Event
¾ Visual Studio integrated editor only.
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
¾ Visual Studio integrated editor only.
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.
You also can add and delete output groups in a specific installation in Installation Expert
> Visual Studio Solution page. Any changes you make on the Visual Studio Solution
page override the settings on the Project Outputs page.
This page is accessible only on the Project Properties dialog box. 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.
See also:
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 the appropriate output group on the
Project Outputs page in the project settings, or add them on the Visual Studio
Solution page.
Windows Installer Editor can scan for files you add or delete after you create the
installation project, and can add them to or delete them from the project.
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.
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.
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.
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 47 and Projects Page on page 80.
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.
If the solution contains a mixed-platform (32-bit and 64-bit) project, define the
INSTALLDIR property to ensure that the outputs are placed in the appropriate directory
for each platform.
z Mark check boxes 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 box that appears, you can add a
new feature and add a new directory for all of the selected files.
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.
See also:
z Compare a transform to its base .MSI, to see the items that the transform changes
in the .MSI.
2. Select Tools menu > Visual MSIDiff and then select an option.
You are taken to Setup Editor > Tables tab and the Visual MSIDiff Key dialog box
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 box, take note of the symbols and colors that
indicate changes and click OK.
If the Visual MSIDiff Key dialog box does not appear, you might have marked its Do
not show this dialog again check box. 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 start Windows Installer Editor in the Visual MSIDiff mode from a command
line.
See also:
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.
1. Select Tools menu > Options and click the General tab.
In Visual Studio: Tools > Options > Wise Options > General.
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.)
2. In the Save As dialog box 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 box. When the Save As dialog box reappears, specify the .XML
file.
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.
Multiple Releases
The number and type of files that are 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.
When the installation is part of a Visual Studio solution, settings on the Visual Studio
Releases dialog box determine which releases are compiled for a given solution
configuration. You access this dialog box from the Release Details dialog box.
See Associating a Release With Visual Studio Build Configurations on page 192.
z Mark the Enable Quick Compile check box 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.
See Setting General Options on page 35.
If the installation contains files that have missing or invalid source paths, the
Welcome dialog box of the Remove Missing Files tool appears. This lets you remove
those files if they should not be in the installation.
See Removing Files With Missing or Invalid Source Paths on page 354.
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 Rebuild Solution
Compiles all files in all projects in the solution.
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 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 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.
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 check box 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.)
See also:
z Test the installation, which appears to run but does not install files or change the
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 428.
z Run the installation on your computer, which installs files and changes the system.
See Running An Installation on page 89.
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.
Testing An Installation
You run an installation in test mode, which does not install files or change the system.
This lets you run through the user interface and logic of an installation without making
changes.
To test an installation
1. Click Test at the lower right of the main window.
2. If you have added command lines to the Command Line page, a menu appears with
further options. The menu contains the names of all command lines you 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.
3. If you are working in a .WSI that contains multiple releases, you are prompted to
select one.
Note
If you change the installation and then test it, but the change is not apparent, close the
installation. Reopen it and compile it, and then run it again.
See also:
Running An Installation
When you run an installation on your computer, it runs as it would on the destination
computer, actually installing files and changing the system.
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.)
Force Reinstall
Normally, if an application is installed and you try 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.
Run
Runs the installation normally. If the application is already installed, you are
prompted to uninstall it.
3. If you are working in a .WSI that contains multiple releases, you are prompted to
select one.
Note
If you change the installation and then run it, but the change is not apparent, close the
installation. Reopen it and compile it, and then run it again.
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.
See also:
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 Installation package meta data (read-only). You can edit the meta data.
See Product Details Page on page 91.
A check box in Wise Options determines whether the Project Summary page appears
when an installation is opened.
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.
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 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 page.
The end user sees this name during installation and in the Add/Remove Programs
dialog box.
(Visual Studio integrated editor only.) If this installation is part of a Visual Studio
solution, this is pre-filled.
z Manufacturer
Enter the manufacturer or publisher of the application.
(Visual Studio integrated editor only.) If this installation is part of a Visual Studio
solution, this is pre-filled.
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.
(Visual Studio integrated editor only.) If this installation is part of a Visual Studio
solution, this is pre-filled.
Warning
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 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 box, and the end user can change the default location for the
application. (The Destination Folder dialog box is called the Single Feature
Destination dialog box in Windows Installer Editor.) This defaults to the first
directory you create on the Files page. To change the default directory, select its
value, click the Change button, and select a new directory.
(Visual Studio integrated editor only.) If this installation is part of a Visual Studio
solution, this is pre-filled.
z Package Path
(Read-only.) This displays the installation file’s location.
z Product Code
Every Windows Installer installation must have a unique product code, which is used
as the principal identification for the application. Windows Installer Editor generates
a product code in the form of a GUID, which ensures that no two applications ever
have the same product code. To change the product code:
On the dialog box 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.
See Upgrades on page 292.
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.
z Application Type
Specify whether this is a standard Win32 or a .NET installation. This also determines
how Windows Installer Editor handles COM interoperability registry entries. This
defaults to the Default Application Type that is specified in Wise Options.
The ability to create .NET installations is supported only by Windows Installer 2.0 or
later.
.NET Application
Select this if this is a .NET installation with only .NET 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
This value is for meta data purposes only. It does not change the installation.
z Description
Describe the package.
If you clear this check box, files that are set to be compressed are not re-
compressed when you save or compile.
You can increment the version number automatically during compile by marking the
Increment version number on compile check box on the Product Details page.
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.
z Reset the default directory for features that use this 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 determines which drive has the most free space.
2. Select the Default Directory value and click the Change button.
The Set Default Install Directory dialog box appears. The Default Directory drop-
down list contains all the directories accessed by this installation, including
predefined Windows directories.
If the directory you want is not listed, add it in Installation Expert > Files page.
5. Click OK.
Note
In Windows Vista and later, the file Properties dialog box does not contain summary
information.
For information on summary items, see Summary Property Descriptions in the Windows
Installer SDK Help.
Select Installation Expert > General Information and complete the page:
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.
Microsoft Restrictions:
Windows Installer version 3.0 requires Windows 2000 SP 3 or later, Windows XP,
or Windows 2003.
z Comments
Enter comments about the application that this installation installs.
Select Installation Expert > Add/Remove Programs and complete the page:
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 box 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 box.
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.
Features Page
Use Installation Expert > Features page to create the structure of an installation by
defining:
z How those features are presented to the end user during installation.
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.
Note
WiseScript Package Editor 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.
In an installation with multiple releases, you can deselect certain features for certain
releases on the Release Settings page.
See Defining a Feature and Component Set for a Release on page 196.
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 101.
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 103.
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 106 and Adding and Deleting Feature
Conditions on page 107.
z Display the features’ titles as they appear on the Select Feature dialog box 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.
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 check box for Installation Type Dialog, and mark
the check box for Select Feature Dialog.
The Select Feature dialog box in the installation reflects the options that you set on the
Features page.
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.
The following examples illustrate several strategies for organizing files into features.
Place dependent features as siblings to core files, but require core files
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 check box on the
Feature Details dialog box. 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.
Conditions
See also:
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.
See Configuring a Feature Using the Feature Details Dialog on page 103.
4. The order in which features appear on the Features page determines the order of
the features on the Select Features dialog box 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.
See also:
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 that are available in the Feature
Details dialog box, which you access by clicking the Details button at the right of the
Features page.
Note
The first four 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 box on the
Dialogs page, use the Feature Details dialog box to set features to be required, or set
features to be hidden from the end user.
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.
See also:
(Visual Studio integrated editor only.) The Feature Details dialog box also appears when
you click the Add New Feature button on the Add Project Outputs to Installation dialog
box. This dialog box appears during save, build, or compile when the scan method is set
to prompt.
For technical information on the fields on this dialog box, see Feature Table in the
Windows Installer SDK Help.
Note
Some options on this dialog box 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 box on the Dialogs page, set
features to be required, or set features to be hidden.
z Title
Enter text to identify the feature. This text appears on the Select Features dialog
box 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 Target Platform
Specify the platform on which this feature should be installed.
Note
If you add a 64-bit component to a 32-bit feature, it will never be installed. A 64-bit
component will be ignored when installing on a 32-bit computer, and a 32-bit
feature will not be installed on a 64-bit computer.
All Processors
The feature appears for installation on any computer, regardless of the
platform.
32 Bit Processors
The feature appears for installation on 32-bit computers only.
64 Bit Processors
The feature appears for installation on 64-bit computers only.
x64 Only
The feature appears for installation on computers that support the x86
architecture (including AMD64 or EM64T).
Itanium Only
The feature appears for installation on computers that support the Itanium 64-
bit processor.
z Description
Enter a multi-line description of the feature. This appears if the end user selects a
feature on the Select Features dialog box during installation. This text must fit in the
Feature Description area of the Select Features dialog box.
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 on the Installation Type dialog box (also called Select
Installation Type). During a Custom installation, the end user can turn features on
or off individually.
Normal
Set the feature’s level value to 3, 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 on the Installation Type dialog box 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 box 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 on the Select Feature
dialog box during installation.
Invisible
Do not display the feature.
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 try 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.
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 perform 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 on the Select Feature dialog box 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.
See also:
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/Me, you want to also install Application9x.dll,
but if your application is installed on operating system later than Windows Me, 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 two conditions under the Web_Creator feature, Version9X (which specifies an
OS of Windows 95/98/Me) and VersionNT (which specifies an OS later than Windows
Me).
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.
See also:
4. Click Build, and create your condition on the Condition Builder dialog box.
The Condition Builder dialog box lets you construct a conditional expression and
check its syntax.
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 383.
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.
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 two 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.
See also:
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 dialog boxes 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.
File Name Path to the source file that contains the binary data
z To add binary resources to an installation, click Add at the right of the page.
See Adding Binary Resources on page 109.
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 have 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.
Select Installation Expert > Resources page, click Add at the right of the page, and
complete the Resource Details dialog box:
z 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.
z File Name
Specify the file that contains the binary data.
This check box is unavailable if you have selected a resource with an unspecified file
name.
Note
You can create or remove this link later, by marking or clearing the check box in the
Refresh column on the Resources page.
See also:
z Mark the corresponding check box in the Refresh column on the Resources page.
z Mark the Create/update link to refresh data when file changes check box on
the Resource Details dialog box.
You can only refresh binary resources with known source files. If you try to mark the
Refresh check box for a resource whose source file is shown as unspecified, you are
prompted to export the data to a new source file.
z Use the Resource Details dialog box to update the path for the source file.
z Clear the Refresh check box and use the existing entry for the resource in the Binary
table.
If an error message appears when you try to clear the Refresh check box, 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 box
and set a source file for the binary resource, if you don’t want to delete it.
See:
Files Page
On the 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.
(Visual Studio integrated editor only.) When you create an installation that is part of a
Visual Studio solution, all primary outputs (.EXEs and .DLLs) of the projects in the
solution are added to the installation. Other, non-primary outputs are added if they
belong to an output group that is included in the scan for new files. Use the Files page to
organize files into features and to add any files that are not added automatically. The
Visual Studio Solution page provides a project- and output group-oriented view of the
files in the solution.
Current Feature
drop-down list
Directories
available to your Files in the
computer directory selected
on the left
Directories to
be installed on
the destination Files or
computer operations to be
installed on the
destination
computer
z In the lower-left list box, use the right-click menu to expand or collapse folders, to
hide or show empty folders, and to rename folders.
z Drag directories or files from the upper list boxes to the lower list boxes.
Add Contents
Add an entire directory and its contents 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.
Add File
Add files to the directory that is selected in the lower-left list box.
New
Create directories to be installed on the destination computer.
Wildcards
Update settings of a directory in the installation.
Operation
Add operations to the installation. See:
See also:
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.
Program Files (x86) (64-bit installations only.) A 64-bit system has two
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.
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 also:
Installation file
See also:
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.
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 check box 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 try 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 directory and appears in the lower-right list box.
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.
The file is added to the selected folder and appears in the upper-right pane.
If the Files icon does not appear, right-click and select Hide Empty Folders/Items.
The file is added to the component’s installation directory and appears in the upper-right
pane.
Displays the Assembly Dependencies dialog box, which prompts you to select
the dependencies to add to the installation.
See Assembly Dependencies on page 123.
z If a file that is part of a merge module is added, the Files in Merge Modules dialog
box appears. It prompts you to add the merge module and, if necessary, download
it.
See Adding Merge Modules Instead of Files on page 118.
Double-click a file.
See also:
The Files in Merge Modules dialog box 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.
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 make the dialog box appear again, click the Prompts tab in Wise Options and activate
the dialog box.
See also:
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. 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.
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 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.
Note
If you link a directory using this check box and if files originally added by the
wildcard are now missing, a Wildcard Deleted Files dialog box appears when you
save the installation. Click No to leave temporarily missing files in the
installation.
If you mark this check box, 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 check box, you can turn automatic updating on later by using the Wildcard
Details dialog box.
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 check box, 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
directories for all features on Files page check box in Wise Options.
See also:
The Copy Source Files dialog box, 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 box, that file is not
copied and the dialog box will not appear again for that file. If you do not copy source
files with the Copy Source Files dialog box, you can use Convert Source Paths instead.
Note
Files that you add to the installation from the Wise Software Repository do not appear
on the Copy Source Files dialog box, even though they are outside the solution, because
you cannot copy those files to a different directory.
z When the Copy Source Files dialog box appears, click OK.
All files that are listed in the dialog box 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.
1. On the Copy Source Files dialog box, select the file to copy.
The Change Selected path dialog box 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 box, the new directory path is listed in the Copy To
column.
The files are copied to the locations you specified, and their source paths are
changed in the installation.
See also:
When you create a .NET installation, you can use the 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 237.
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.
See Assembly Dependencies on page 123.
z Assembly attributes are added to the Assembly tab of the File Details dialog box.
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:
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.
See also:
z Windows Installer Editor can scan the assembly’s manifest and add the dependency
files.
z Windows Installer Editor can scan the assembly’s manifest and prompt you to add
the dependency files.
z In Wise Options > .NET Assemblies tab, use the Scan Dependencies drop-down
list.
z In the Import Visual Basic, C#, or J# tool, on the Select Configuration dialog box,
use the Automatically add Assembly Dependencies without prompting check
box. (Not available in the Visual Studio integrated editor.)
You can exclude dependencies from the assembly scan for a specific installation or for all
installations.
Note
On .NET Framework versions earlier than 1.1, the scan 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 directory is fully trusted.
Assembly Dependencies
When you add a .NET assembly to an installation, Windows Installer Editor can scan the
assembly’s manifest for dependencies and prompt you to add the dependency files to
the installation.
If the scan finds dependencies, the Assembly Dependencies dialog box lists
dependencies for all the assemblies you added. In the Assembly Dependencies dialog
box, you can check the checkbox next to a dependency name to add the dependency to
the installation. If you uncheck the check box, the dependency is added to the project
dependency exclusion list and is skipped by future scans of the current installation.
You can remove dependencies from the project dependency exclusion list.
See Removing Dependencies from the Project Dependency Exclusion List on page 343.
See also:
You can use the following exclusion lists to exclude dependencies from assembly scans:
Assembly dependencies that are in an exclusion list are never added to an installation,
even if the .NET assembly is rescanned, or if you add a new assembly that has the same
dependency.
You can create an XML file that overrides the hard-coded dependency exclusions with
exclusions that you define. Name the file dotnetexclude.xml and place it in the Windows
Installer Editor subdirectory of this product’s installation directory.
The dotnetexclude.xml file overrides all the hard-coded exclusions. To retain the hard-
coded exclusions, add them to the XML file. The following list of default exclusions is
provided in the proper XML syntax. You can add your own exclusions to this list.
See also:
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.)
3. Click the directory name in the lower-left list box and click Wildcards at the lower
left of the Files page.
The Wildcard Details dialog box 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 box:
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.
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.
7. Click OK.
8. If a change in the wildcards causes files to be deleted, the Wildcard Deleted Files
dialog box 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 box.
See also:
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.
Warning
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.
a. 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.
b. Click Operation below the lower-right list box and select Remove File.
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 page, the entry’s Type column contains “Remove.”
To edit it, double-click its name. To delete it, use the right-click menu.
See also:
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.
Warning
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.
a. 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.
b. Click Operation below the lower-right list box and select Copy File or Move
File.
Source 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.
Dest. Directory
Specify the directory on the destination computer to copy or move the file to or
create a new subdirectory. To create a new subdirectory, select a directory and
click New Folder.
To rename files on the destination computer, make the source and destination
directory the same.
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 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.
See also:
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 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.
(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 box appears. It contains several tabs. See:
In the Visual Studio integrated editor, you also can use the Visual Studio Solution
page.
The Multiple Files dialog box appears. Only a subset of the editing options are
available.See Editing General File Details on page 130 and Setting Permissions for Files
and Directories.
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 box appears instead of the File Details dialog box. (See also Creating
Duplicate File Entries on page 364.) 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.
See also:
In Installation Expert: On the Files page, select one or more files and click
Details.
In the Visual Studio integrated editor, you also can use the Visual Studio
Solution page.
In Setup Editor: On the Components or Features tab, select one or more files
and select Details from the right-click menu.
The File Details or Multiple Files dialog box appears.
Long Filename
(File Details dialog box only.) The name of the file as displayed on computers
running Windows 95 and later.
Short Filename
(File Details dialog box only.) 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 path 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
(File Details dialog box only.) 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.
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.
Self-Register OCX/DLL
(Multiple Files dialog box 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.
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.
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.
When you set permissions for a file, the file appears preceded by .
In Installation Expert: On the Files page, select a folder, file, or set of files and
click the corresponding Details button. (On the Web Files page, you can set
permissions for files but not for folders.)
In the Visual Studio integrated editor, you also can use the Visual Studio
Solution page.
c. Click OK.
The domain and user names appear in the upper list box, and the list of permissions
is enabled.
Warning
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. If the current
user profile running this installation is ADMINISTRATOR, then the installation will fail to
write to SampleFolder, because only ASPNET_USER has write permissions to
SampleFolder. ASPNET_USER is automatically set.
See Run Time Properties on page 510.
Registration Method
Do not register
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 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.
This check box 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 check box is marked by default.
4. Click OK.
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 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.
The Assembly tab only appears for files that are keypaths to their components.
3. Complete the dialog box. If .NET is 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.)
Assembly Attributes
This displays the assembly’s culture, 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.
4. Click OK.
See also:
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 Windows Installer Editor, 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 box, 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 box. This populates the MsiAssembly and MsiAssemblyName
tables.
Warning
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).
2. In Installation Expert > 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.
Attributes are read from the file and displayed in the Assembly Attributes list, and
a manifest file name is entered in Manifest.
Installed File
Adds a dependency to a file that is in the installation. On the Select File dialog
box 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.
For details, search for “Windows XP visual style” in the MSDN Library
(msdn.microsoft.com).
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.)
See also:
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 box, 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.
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 Edit button becomes enabled for editable lines only after you mark Enable
Dynamic Content.
Not all lines are editable, only lines that have name-value attributes. (Example:
<compilation defaultLanguage=”c#” />.) The Attribute Editor dialog box appears.
b. In Dynamic Value, type a new value to replace the current value at run time.
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 420. Or use properties defined in Run Time Properties on
page 510.)
c. Alternatively, you can select a property name from Property and click the
Insert into Dynamic Value button.
At run time, the attribute is replaced with the dynamic value you specified. Windows
Installer properties are resolved to their value.
See also:
You edit the DIFxApp options on the Driver tab of the File Details dialog box. This tab
appears only if all of the following are true:
Note
Early versions of this merge module might be named “Binaries.”
In the Visual Studio integrated editor, you also can use the Visual Studio Solution
page.
4. Click OK.
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 box, 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 368.
Using WiseComCapture.exe
before you can 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 Windows Installer Editor installation
directory. It extracts the registration information to a .REG file, from which you can
import registry keys into the installation.
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:
where:
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 150.
In Setup Editor > Components tab, display the Component Details dialog box
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 368.
See also:
The Visual Studio Solution page is similar to the Files page, except:
z The upper-left list box displays the projects in the solution and organizes each
project’s output by output groups.
z The lower-right list box organizes the files in the installation by output group.
Therefore, where the Files page is folder-oriented, the Visual Studio Solution page is
project- and output group-oriented. This organization of the page simplifies the addition
of output files to the installation. It is especially useful when you are working with a
solution that has an extensive folder structure (example: a Web project).
z Override the file installation directories that result from scanning the solution.
z Add output files that were not included in the solution scan.
z Define which output groups are included in the solution scan. Changes that you
make on the Visual Studio Solution page affect the output group settings on the
Project Outputs page in the project settings.
See Project Outputs Page on page 82.
If the solution contains a mixed-platform (32-bit and 64-bit) project, define the
INSTALLDIR property to ensure that the outputs are placed in the appropriate directory
for each platform.
z When new output files are added to the solution, they are added to the installation
in the same directory as their output group, even if the output group was moved
from its original directory. If you select the option to maintain an output group’s
directory structure, when you add new files to the solution, they are added to the
corresponding directory in the installation.
z When new output files are added to the solution, and they belong to a project that is
not included in the scan for new files, the files are not added to the installation.
z If you move an output group or its files to a different installation directory, future
file scans update the existing files as follows:
If you leave the existing output group in its original folder, and place new copies
of the files elsewhere, then both copies of each file are updated.
If you move the output group but leave the existing files in their original folder,
the files in their original folder are updated.
If you move the output group and its files from their original directory, the files
in the new directory are updated.
z In the lower-left list box, use the right-click menu to expand or collapse folders, to
hide or show empty folders, and to rename folders.
z Drag an output group or file from the upper list boxes to the lower list boxes.
z Drag an output group or file from the lower-right list box to the lower-left list box.
When you drag an output group, the Add Contents dialog box appears.
See Adding Contents of Visual Studio Projects to the Installation on page 143.
Add Contents
Add the contents of an output group to the installation.
See Adding Contents of Visual Studio Projects to the Installation on page 143.
Add File
Add files to the directory that is selected in the lower-left list box.
New
Create directories to be installed on the destination computer. You also can
create directories in Setup Editor.
Warning
When you remove an output group from the lower-right list box, all other
outputs of that group are removed from the installation. Also, the check box for
that output group is cleared on the Project Output page in the project settings,
which excludes that group from future scans for output files.
If you select an output group in the lower-right list box that is enabled, the
Details button displays the Output Group Details dialog box. This dialog box lets
you change the Maintain directory structure and Exclude dependencies
options for the output group. An output group is enabled when you select its
parent folder in the lower-left list box.
Note
If the dependencies of an output group are excluded and you clear the Exclude
dependencies option on the Output Group Details dialog box, the
dependencies will not appear in the lower-right list box until you save the
installation.
See also:
z Override the file installation directories that result from scanning the solution.
z Add output files that were not included in the solution scan.
The dialog box that appears in this procedure also appears when you drag an output
group from the right-lower list box to the left-lower list box.
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.
2. In the upper-left list box, expand a project and select the output group to add.
If Windows Installer Editor cannot locate the solution file, the upper-left list box is
empty.
3. In the lower-left list box, select a directory to add the output group to.
5. Specify how to update output groups and files that are already in the installation.
Your selection here affects how the existing output groups and files are affected by
future file scans. By default, different options are selected on the Add Contents
dialog box depending on the output group.
Exclude dependencies
This excludes dependency files from the output group that are referenced by
the project. Select this option when you want to exclude dependencies from the
installation. If you clear this option, the dependencies appear in the parent
folder of the output group.
Note
You can change the Maintain directory structure and Exclude
dependencies options that you select for an output group on the Output Group
Details dialog box.
See Working with the Visual Studio Solution page on page 141.
When new output files are added to the solution, they are added to the installation
in the same directory as their output group, even if the output was moved from its
original directory. If you select the option to maintain an output group’s directory
structure, when you add new files to the solution, they are added to the
corresponding directory in the installation.
6. Click OK.
See also:
Installation file
Dependencies file
Output group
See also:
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, Windows Installer Editor 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].
Registry keys
on your Registry values
computer. in the key
selected on the
left.
On a 64-bit
computer, the
64-bit registry
is visible here.
z Use the right-click menu to expand or collapse directories, to hide or show empty
directories, and to view the 32-bit or 64-bit registry. The upper panes can display
the 32-bit or 64-bit registry, but the 64-bit registry is visible only when your
computer is running a 64-bit operating system. The lower panes can display the 64-
bit view on any computer, but only in projects with 64-bit features or releases.
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.
In a 64-bit installation, this button contains a menu that lets you specify
whether to add the key to the 32-bit or 64-bit registry.
Add Values
Copy values from your computer to the installation.
In a 64-bit installation, this button contains a menu that lets you specify
whether to add the value to the 32-bit or 64-bit registry.
Add
Create a new key or import a registry file into the installation.
Details
Edit registry key settings.
See also:
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.
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. In a 64-bit installation, right-click in the lower-left list box and select 32-bit View or
64-bit View.
4. In the lower-left list box, select the location for the key.
7. In Key, click at the end of the existing text, and add a backslash and the name of
the new key.
8. Click OK.
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. In a 64-bit installation, right-click in the lower-left list box and select 32-bit View or
64-bit View.
4. In the lower-left list box, select the key to contain the value you’re adding.
On the Features tab, expand a feature and then expand its Combined folder.
If the Combined folder 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.
The registry value is added to the selected feature or component and appears in the
lower-right list box. To edit it, double-click its name. To delete it, use the right-click
menu.
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.
Warning
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.
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.)
4. In a 64-bit installation, right-click in the lower-left list box and select 32-bit View or
64-bit View.
5. In the lower-left list box, select the key that contains the value to remove.
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.
On the Features tab, expand a feature and then expand its Combined folder.
If the Combined folder does not appear, right-click and select Hide Empty
Folders/Items.
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.
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.)
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.
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.
b. In a 64-bit installation, right-click in the lower-left list box and select 32-bit
View or 64-bit View.
c. Click Add at the lower left of the Registry page and select Import.
2. On the dialog box 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.
In the lower-left list box, right-click the key to export, and select Export to .REG
File. To export all keys that you have designated for the destination computer,
right-click the Destination Computer icon.
2. In File Name, specify the path of the registry file you are creating.
3. In Export As, select the version of RegEdit that the registry file should be
compatible with.
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.
In Installation Expert > Registry page, click Add > Key at the lower left of the
page.
Operation
Specify what operation will be applied to the key and its associated value.
Root
This is enabled only when you access the Registry Details dialog box from the
Add button on the Registry page.
The top-level key in which the new key will be added. (Example:
HKEY_CURRENT_USER.)
Key
This is enabled only when you access the Registry Details dialog box from the
Add button on the Registry page.
Enter 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 exist are created.
Value Name
Enter 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 the Windows Installer SDK Help.
Data Value
Enter 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.
String
(REG_SZ) Identifies the value as an expandable string. To include a
property, enclose the property name in square brackets.
Unexpanded string
(REG_EXPAND_SZ) Identifies the value as a string that contains
unexpanded references to environment variables that are expanded when
the value is retrieved. Enclose the environment variables in single percent
signs. For example, %PATH%.
Double word
(REG_DWORD) Identifies the value as a 32-bit number in decimal notation.
Binary / Hex
(REG_BINARY) Identifies the value as a binary in hexadecimal notation. Do
not use spaces, commas, or other characters to separate the bytes.
Example: AD30C0A94020A8FC4C0008.
3. Click OK.
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.
In Installation Expert: On the Registry page, right-click a registry key and select
Permissions.
2. Click Add.
c. Click OK.
The domain and user names appear in the upper list box, and the list of permissions
is enabled.
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.
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
directories for all features on Files page check box in Wise Options.
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 box. You also can edit the IniFile table in Setup Editor. For
information on formatted text strings, see Formatted in the Windows Installer SDK
Help.
See Editing Existing Tables on page 377.
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. To create a new folder for the INI file, click New Folder, enter a folder name, and
click OK.
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.
2. 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.
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.
5. 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.
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
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.
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.
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
started. If you clear this check box, 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 is deleted,
selecting that shortcut performs self-repair. Self-repair is not performed 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. 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 box 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 predefined directories on this dialog box 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 box appears, where you can specify further details for
the shortcut. 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.
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 predefined directories and directories that you have 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 start 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
started.
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 started. If you clear
this check box, 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 check box
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.
a. 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.)
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 box 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.
3. Click OK.
The environment variable is added. To edit it, double-click its name. To delete it, use the
right-click menu.
a. 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.
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.
3. (Optional.) On the Command Verbs tab, click Add, and on the Verb Details dialog
box that appears, set the actions that will be available when the end user right-
clicks an executable with this extension in Windows Explorer.
4. (Optional.) On the MIME Types tab, mark Show All and mark check boxes to select
the MIME types to associate with this extension.
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.
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.)
3. Click Add at the right of the File Associations page and select Import.
4. Click Browse to select the executable to use for the extension. You can only select
executables that you have 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.
See also:
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
box 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 unavailable.
3. Click OK.
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.
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 path
of the file that was opened.
4. Click OK.
Show All
Mark this to display all available MIME types on your computer. To associate a
MIME type with an extension, click its check box. 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 check box.
3. Click OK.
Services Page
Use the Services page to define applications to be installed as a service. 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.
After you add a service, you can set options to start, stop, and delete services on the
destination computer.
To add a service
1. Select Installation Expert > Files 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. Add the file that runs the service. Application files that can be installed as a service
are: .EXE, .VXD, .SYS, or .386.
Click Add at the right of the page and select Create Service.
The options you set on the Create Service Details dialog box are dependent on how
you coded your service. Some of the options correspond to options in the Services
application. 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 application.
Description
Enter a description for the service. This appears only in the Windows Services
application.
Executable
Displays the file you selected on the Select File dialog box, which runs the
service.
Arguments
Enter any arguments to be passed to the service on the command line 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
Restarts the system and sets it to the last known good menu.
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.
7. Click OK.
The service appears. To edit it, double-click its name. To delete it, use the right-click
menu.
To control a service
1. Do one of the following:
a. 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.
b. Click Add at the right of the page and select Service Control.
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.
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 check boxes 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 tries to remove it.
a. 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.
b. Click Add at the right of the ODBC page and select Driver, Data Source, or
Translator.
2. Complete the dialog box and click OK. For details, see:
The ODBC entry appears. To edit it, double-click its name. To delete it, use the right-
click menu.
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.
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.
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 box
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.
Description
Enter a description of the translator, or click Import to import an existing
translator. If you click Import, the Select ODBC Driver dialog box 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.
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.
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.
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.
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.
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.
a. On the Exception Type dialog box, mark Application and click Next.
The Application Selection dialog box 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 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.
See Setting a System Requirement for Server Roles and Services on page 172.
See Setting a System Requirement for Server Roles and Services on page 172.
2. Double-click a requirement.
3. From the drop-down list at the top of the dialog box, 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 XP lets
an installation run on any computer with Windows XP 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 2000
Windows XP
Windows Server 2003
Windows Vista
Windows Server 2008
Windows 7
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.
To prevent this, you can use the Prerequisites page to set the installation to pre-install a
later version of Windows Installer.
This option is useful if you have set up this installation to configure a Microsoft SQL
Server on the SQL Server Scripts page.
IIS Version
Use this option to check for the presence of a Microsoft Internet Information Services
(IIS) server. By default, this value is not checked.
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. You can specify the order in which these launch conditions are evaluated in
the WiseLaunchCondition table.
See also:
By default, when you set requirements for server roles and services, you can only select
from a subset of the server roles and services. If you want to check for additional server
roles and services, you must first add them.
See Adding Roles and Services to the Server Roles and Services Dialog Box on
page 173.
3. In the list of roles and services, check the server roles and services that must be
installed to install the application.
4. Type the error message that appears if the destination computer does not meet this
system requirement.
This message should communicate to the user why the installation cannot run.
5. Click OK.
See also:
Adding Roles and Services to the Server Roles and Services Dialog
Box
The Server Roles and Services dialog box appears when you double-click Server Roles
and Services (Server 2008) on the System Requirements page. This dialog box lists only
a subset of the server roles and services that an installation can check for on a Windows
Server 2008 computer.
To check for additional server roles or services, you must first add them to the roles.txt
file. After you add them to the roles.txt file, they appear on the Server Roles and
Services dialog box.
When you add a role or service to the roles.txt file, you must enter the value of the ID
property for the server role or service. These values are listed in the ID properties table
in the Win32_ServerFeature Class article in Microsoft’s MSDN Library. This table has a
column for the value and another column for the description of the value.
To add server roles and services to the Server Roles and Services
dialog box
1. Access the roles.txt file and remove its Read-only attribute.
3. Below the last entry, type SVFT_ followed by the value for the server role or service.
You get the value from the Win32_ServerFeature Class article in Microsoft’s MSDN
Library.
4. After the value for the server role or service, press the Tab key and type the value’s
description.
You can enter any description, but we recommend using Microsoft’s description.
This description appears on the Server Roles and Services dialog box in alphabetical
order.
5. Repeat the preceding two steps to add additional server roles or services.
The next time you open the Server Roles and Services dialog box, the options you
added to the roles.txt file appear in the list of server roles and services.
To create new launch conditions and edit existing ones, use the Launch Conditions icon
in Setup Editor > Product tab.
Condition
Enter the new condition or click Build to create a condition in Condition Builder.
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.
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 435.
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 run time, the installation searches for the items that are specified 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:
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 box.
2. Click Add at the right of the page and select File or Directory.
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 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.
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
box for files displays only the string version, which can be different from the
binary version. Only the first three segments of a four-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.
To test the search, add a text box on one of the dialog boxes 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 box. When you run the installation, the property
you specified will hold the results of the search. If it is empty, the search failed.
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.
SrcDir=E:\Application\
SrcFiles=E:\Application\Application.exe, E:\Sample\Sample.dll
z Item Field refers to the number of the item in a comma-delimited list. Example:
The Item Field for E:\Sample\Sample.dll in the section above is 2 because it is the
second item in the list.
2. Click Add at the right of the page and select INI File.
Property
Specify a property name. 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;
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:
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.
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.
Colors=red,blue,green
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.
To test the search, add a text box on one of the dialog boxes 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 box. When you run the installation, the property
you specified will hold the results of the search. If it is empty, the search failed.
Property
Specify a property name. 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;
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:
If you use this operation on registry information that’s not in the form of a
file path, the search fails.
If you use this operation on registry information that’s not in the form of a
directory path, the search fails.
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.
4. Click OK.
To test the search, add a text box on one of the dialog boxes 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 box. When you run the installation, the property
you specified will hold the results of the search. If it is empty, the search failed.
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.
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 box.
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;
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:
Component ID
Enter the GUID for the component.
See Adding and Editing a Component on page 368 and About GUIDs on
page 488.
4. Click OK.
To test the search, add a text box on one of the dialog boxes 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 box. When you run the installation, the property
you specified will hold the results of the search. If it is empty, the search failed.
z No elevation required
This option disables UAC. Check this check box only if the installation does not
access a protected area on the destination computer.
The DisableUAP property is set, which hides the option to install for all users or
the current user on the installation’s User Information dialog box.
At run time, when the installation reaches the Deferred Execution sequence, the
user is prompted for administrator credentials.
Restart Manager
Installations and updates often require computer restarts when files that are being
updated are in use by a running application or service. In Windows Vista or later, Restart
Manager can detect processes that have files in use and stop and restart them without
requiring a restart of the computer. Applications that are written to take advantage of
Restart Manager can be restarted and restored to the same state and with the same
data as before the restart.
To enable Restart Manager for this installation, mark the following options:
The use of Restart Manager determines which dialog box appears if the installation
tries to update files that are being used:
If Restart Manager is enabled, the Windows Vista Files in Use dialog box
(MsiRMFilesInUse) appears.
If Restart Manager is disabled, the Files in Use dialog box (used in earlier
versions of Windows) appears.
Shut down only if all affected applications are registered for a restart
If at least one affected application is unregistered, then the attempt to shut
down all applications, registered or not, fails and a restart is required at the end
of the installation.
To set logging options for installations that will run under Windows Installer 4.0 or later,
mark the appropriate check boxes:
z a - Start up of actions
Logs actions as they are started.
z c - Initial UI parameters
Logs the initial user interface parameters.
z i - Status messages
z o - Out-of-disk-space messages
z p - Terminal properties
z r - Action-specific records
z u - User requests
z v - Verbose output
Logs more detailed information about each event or error.
z w - Non-fatal warnings
Installation actions that write to a protected area on the destination computer require
elevation. When UAC is enabled and the installation tries to access a protected area, the
user is prompted as follows:
Installations that were created in a Wise product earlier than Wise Package Studio 7.0
SP1 or Wise Installation Studio 7.0 run as if UAC is enabled.
Option Description
Elevate the Deferred In a typical MSI, only the Deferred Execution sequence should contain actions
Execution sequence that write to a protected area on the destination computer. The installation runs
in standard user mode until it enters the Execute Deferred sequence. Then a UAC
prompt appears and the Execute Deferred sequence runs in administrator mode.
The prompt appears even if the installation runs silently. This option is the
default for most installations.
Set this option on the Windows Installer Options page, under the UAC
Compatibility Settings section.
If custom actions do not run or if the installation fails for other elevation-related
reasons, consider another elevation method.
Elevate the entire MSI You can elevate an entire Windows Installer installation. At run time, a UAC
prompt appears only when the installation begins. The remainder of the
installation runs in an elevated mode.
Set this option on the Windows Installer Options page, under the UAC
Compatibility Settings section.
z When the installation contains custom actions that access protected areas
and are located outside of the Execute Deferred sequence. Typically, such
custom actions check launch conditions or obtain data to populate
installation dialog boxes.
You can wrap the MSI in an EXE in Installation Expert on the Build Options page.
Select one of the options that create an EXE.
z When you need to add runtime or prerequisite files to the installation for pre-
installation on the destination computer.
z When the installation contains custom actions that access protected areas
and are located outside of the Execute Deferred sequence. Typically, such
custom actions check launch conditions or obtain data to populate
installation dialog boxes.
When the installation runs in maintenance mode, the MSI runs outside the EXE
wrapper. Therefore, a UAC prompt appears when the MSI runs.
Option Description
Create a standard user If an application is written to be installed and run by standard users without
installation with no elevation elevation, you can bypass UAC elevation issues. The installation cannot contain
actions that access a protected area on the destination computer. If the
installation tries to access a protected area, it fails.
See also:
Use this method of elevation when an installation’s User Interface sequence contains the
following types of custom actions:
z Actions that access a restricted area to check launch conditions or obtain data to
populate installation dialog boxes.
z Actions that perform an IIS check. These actions usually appear in a Web or server
installation.
z Actions that access user information or other restricted information. These actions
usually appear in a server installation.
The option to elevate the entire MSI is on the Windows Installer Options page, under the
UAC Compatibility Settings section.
When you elevate an entire MSI, the custom action WiseElevateCheck is added to the
User Interface sequence. Do not remove this custom action from the installation.
Note
When you create a Web installation or a server installation, Wise IIS-related custom
actions are added to the Execute Immediate sequence. These actions are coded to run
in an elevated mode. Any other custom actions in the Execute Immediate sequence that
access restricted areas are not elevated. Move them to the Execute Deferred sequence.
z A single UAC prompt appears when the MSI begins. No other prompts appear.
z If the installation is set to create an installation log, two logs might be created. One
log contains little information. The other log appears to contain entries for two
installations. If you specified a name for the log file, only one log is created but it
might appear to contain entries for two installations. This is normal.
When the installation runs in maintenance mode, the installation is not elevated and a
UAC prompt appears before the Execute Deferred sequence begins. If the installation
contains the Wise IIS-related custom actions in the Execute Immediate sequence, a
prompt appears before that sequence as well.
You also can elevate an MSI by wrapping it in a WiseScript EXE that sets the run level
with a manifest file.
Example: Suppose your application contains three features. You could set the following
defaults for the Installation Type dialog box:
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 box, and then turning features on or off on the Select Feature dialog box. To
display the Select Feature dialog box to the end user during installation, mark its check
box on the Dialogs page.
On the Installation Types page, the upper-left list box shows the default installation
types: Typical, Complete, and Custom, which correspond to the radio buttons that are
presented to the end user on the Installation Type dialog box 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.
z Description text
This text appears next to the radio button on the Installation Type dialog box. 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 check boxes of the
features in the list on the right.
Warning
If you are using the Installation Types page to manage the Installation Type dialog box,
do not edit the Installation Type dialog box. Doing so causes the Installation Types page
not to work properly.
The following examples 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
About Releases
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 unavailable. An exception is the
Languages page.
See About the Languages Page on page 247.
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 support different platforms.
The Releases page lets you define multiple releases for an installation, edit releases, and
delete releases you have created. If you haven’t created additional releases for the
installation, the Releases page lists only one release: Default.
Example 1:
You want to have a standard and an evaluation edition for your application, and you
want to release both editions on CD and as Internet downloads. To accomplish this,
create four releases:
Example 2:
You want to create a single installation project (.WSI) that can produce installation files
for 32-bit, x64, and 64-bit Itanium platforms. To accomplish this, create three releases
and set the appropriate target platform for each one:
z 32-bit edition
z x64 edition
z Itanium edition
See Creating Multiple, Platform-Specific Installations from One Project File on page 68.
z Details
Edit a release.
z Add
Add 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.)
You can edit various aspects of each release on the other pages in the Release Definition
page group.
2. Click Add.
Release Name
Enter a unique name that describes the release. Example: Standard_CD-ROM or
Standard_Internet. This name appears on the Releases page.
To populate the file name or subdirectory with the value of one or more
properties, enter one or more property names surrounded by brackets.
Example: [ProductName].msi
You can use one or more specific parts of a property’s value if its segments
are period delimited. This is most useful for adding all or part of the product
version number to the file name. The syntax is:
[property_name.%segment_number%segment_number]
You can add characters between the segments, except for periods,
numerals, or the % symbol.
Description
Enter information to distinguish this release from others. Examples: Evaluation,
Optimized for Internet Distribution. This description appears on the Releases
page.
Installation Theme
Select the theme for the installation dialog boxes for this release. The theme
controls the overall look of the dialog boxes by setting their top or side images
and the fonts of the dialog box text. You can use different themes for different
releases. Example: Use a different theme for an evaluation release to clearly
distinguish it from your standard release.
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.
Target Platform
Select the target platform for this release. This determines the Template
Summary property of the compiled .MSI. The initial default is set by the Target
Platform option on the New Installation File dialog box.
This corresponds to the check box in the Build column on the Releases page.
Marking or clearing one check box affects the other check box.
4. To add or edit media settings, click Edit Media. The Media Details dialog box
appears. The Edit Media button and the Media section appear only when you first
add a new release.
5. (Visual Studio integrated editor only.) To specify which build configurations in Visual
Studio will cause this release to be compiled, click Visual Studio. (The Visual Studio
button does not appear in a stand-alone installation.)
See Associating a Release With Visual Studio Build Configurations on page 192.
6. 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.
See also:
Example: Your solution contains both 32-bit and 64-bit projects. In Visual Studio, you
use the Configuration Manager to create a configuration for each platform. In the
installation project, you create a 32-bit and a 64-bit release. When you build the 64-bit
configuration, only the 64-bit project is built, but both releases are compiled. As a
result, the 32-bit release contains files from the 64-bit project. To prevent this, use the
Visual Studio Release dialog box to associate the 32-bit release with the 32-bit
configuration, and the 64-bit release with the 64-bit configuration. Then, when you build
the 64-bit configuration, only the 64-bit release is compiled.
Platform configurations are not supported in Visual Studio 2003 or earlier. In those
versions, you specify the build configuration only.
You define configurations and platforms in Configuration Manager within Visual Studio.
For details, refer to the Visual Studio documentation.
2. If Platform appears, select a platform. This drop-down list does not appear if the
version of Visual Studio does not support platform configurations, or if only one
platform is available.
3. In the Configurations list, mark the configurations that, when built for the above
platform, should cause this release to be compiled.
4. If Platform appears, repeat step 2 and step 3 for each platform that is listed.
See also:
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.
During compile, the transforms are packaged inside the .EXE along with the
.MSI.
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.
When the end user runs 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:
z The product’s summary informs the end user that this evaluation release doesn’t
allow saving files.
Note
This page is enabled in a .WSI only.
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 an evaluation version rather than a full version.
The property override does not affect property values in other languages in the
installation. Example: If a property has a value of 0 in the Default language and a value
of 5 in German, and you change the value to 12 on the Release Settings page, the value
of the property in the German .MSI will be 5.
Each release contains the properties listed under the Properties icon in Setup Editor >
Product tab. Only those properties that you change or add for a specific release appear
under the Properties icon on the Release Settings page. Properties that 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.
4. Click Add at the right of the Release Settings page. The Property Settings Override
dialog box 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.
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 an evaluation 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.
Note
In Windows Vista and later, the file Properties dialog box does not contain summary
information.
For information on summary items, see Summary Property Descriptions in the Windows
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.
4. Click Add at the right of the Release Settings page. The Summary Settings Override
dialog box appears.
7. Click OK.
The summary item appears in the list box. To edit it, double-click its name.
See also:
The Release Settings page lists all features in an installation. You can:
z Select the features to include in a particular release. Example: Turn off a SpellCheck
or a SaveAs feature for a evaluation release.
4. To include a feature in this release, mark its check box. To exclude a feature, clear
its check box.
a. Click the feature name to display the feature’s components in the lower pane.
b. Mark the check boxes of components to include. All check boxes are marked by
default.
See also:
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.
3. Click Share at the right of the Release Settings page. The Share Release dialog box
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.
3. Click Share at the right of the Release Settings page. The Share Release dialog box
appears.
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.
z The application’s summary dialog box indicates that this is an evaluation release.
z Potential customers can use the evaluation 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.
4. Click Add at the right of the Release Settings page. The Property Settings Override
dialog box appears.
7. Click OK.
9. Click Add at the right of the Release Settings page. The Summary Settings Override
dialog box appears.
On the Build Options page, you can customize a release by selecting the format of
output files and language options.
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. In a
64-bit installation, the .EXE will always be 32-bit.
Warning
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 who installs the application is prompted to enter the
password to start the installation. This password is the same for all users. You can
protect only single-file .EXEs with a password.
the new installation. This option is disabled when the Install the .MSI into an SVS
layer option is selected.
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 application.
Do not mark this check box if you are using the Upgrades page or patches to update
an application.
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.
See also:
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 runtimes to run before the main installation. They are added as an include
script to the WiseScript that creates the installation .EXE.
Note
The options on the Prerequisites page are unavailable 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 199.
3. Select the Windows Installer and .NET Framework runtime versions to pre-install.
For each prerequisite file and runtime file that you add in the lower pane, 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 205.
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.
Note
The options on the Prerequisites page are unavailable 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 199.
You can select a Windows Installer runtime for Windows 2000/XP/2003 and
Windows Vista/2008. This adds a file to the installation that pre-installs the
selected version of Windows Installer if it is not on the destination computer.
Because Windows Installer 4.0 is unique to Vista and is installed with Vista, it is
not included in the lists. A Windows Installer runtime version 4.5 does not work
with Windows 2000.
If you know that the operating system is not used on any destination
computers, select None.
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 3.0 and you select
Latest (2000/XP/2003), then 3.0 is added to the installation. If later you
download the Windows Installer 4.5 for XP/Server 2003 (32 bit) runtime, then
this 4.5 runtime would be added to the installation.
4. (Optional) Mark the Delay Windows Installer runtime reboot until after
product installation option.
This option delays the restart to the end of the installation and minimizes restarts
for the end user.
This is enabled only if one of the Windows Installer Runtime Version fields is set
to 2.0 or later. Normally, installing the Windows Installer runtime requires a restart
at that point in the installation.
6. (Optional) Mark the Show Microsoft .NET End-User License Agreement option.
This is enabled if you selected an option to install the .NET Framework runtime.
Mark this to display the end-user license agreement (EULA) to the end user during
installation, or clear it to suppress the EULA.
Note
The options on the Prerequisites page are unavailable 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 199.
3. 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.
4. To add a prerequisite file, click Add at the right of the page and select Prerequisite.
Note
If you compile an installation into an .EXE that launches an external .MSI, three 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 three 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.
The Prerequisite Launch Conditions dialog box 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 box.
To add a launch condition, select an option from both drop-down lists and
click Add. Repeat to add additional launch conditions.
The prerequisite file is added to the Prerequisites page. To edit or delete it, use the
right-click menu.
8. If a prerequisite file or runtime requires a restart, you might need to edit the
WiseScript to make the restart run smoothly. We recommend adding two Pause
actions for 1000 milliseconds after a prerequisite or runtime that requires a restart.
This works better than one Pause action for 2000 milliseconds. Adding the Pause
actions prevents the WiseScript from trying to start the next prerequisite or runtime
while the computer is shutting down.
9. 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 in the lower pane, 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 205.
If the build options for this installation are set to create an .EXE that launches an
external .MSI, then when this installation is compiled, the prerequisite .EXE is copied to
a subdirectory of the installation’s project directory, named Msi_Name\FILEPATH1.
A 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 a runtime to an installation, you must add the runtime files to your
computer. To download many of the runtimes, select Help menu > Download
Redistributables (In Visual Studio: Help menu > Wise Help > Download
Redistributables.) and mark Other Vendors’ Web Sites. If a runtime is not available
from Download Redistributables, you must download it directly from the vendor’s Web
site.
Note
The options on the Prerequisites page are unavailable 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 199.
For many runtimes, an additional dialog box appears where you specify settings for
the runtime.
The runtime is added to the Prerequisites page. To edit or delete it, use the right-
click menu.
8. If a prerequisite file or runtime requires a restart, you might need to edit the
WiseScript to make the restart run smoothly. We recommend adding two Pause
actions for 1000 milliseconds after a prerequisite or runtime that requires a restart.
This works better than one Pause action for 2000 milliseconds. Adding the Pause
actions prevents the WiseScript from trying to start the next prerequisite or runtime
while the computer is shutting down.
9. 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 in the lower pane, 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 205.
Warning
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.
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 WiseScript Editor.
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.
Warning
Don’t change the name of the WiseScript file. It must have this name to create an
.EXE that includes your edits.
The next time you compile the installation, an .EXE is generated using the
WiseScript file that you edited.
This button is enabled only if you have used the Edit Script button.
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.
See also:
Use the Clean Build page if you need to perform 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 Windows Installer Editor, 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.
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.
This check box appears only if a locally-installed SCCS is detected on your computer.
4. Mark Store clean build in source control. This is unavailable if source control is
not enabled in options. (In Visual Studio: this is unavailable 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. Dialog boxes 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 unavailable if no clean build options are
set for any release.
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 check box is marked on the
Releases page. Two log files are created; one shows compile actions and the other
shows compile errors.
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 unavailable 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 check box is marked on the
Releases page. Two log files are created; one shows compile actions and the other
shows compile errors.
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.
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 210.
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.
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
3. Click Add at the right of the Media page. The Media Details dialog box 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.
When you select one of the above compression options, you must select one of the
Cab Options below.
See the description of the Will be installed to run from source icon in
Configuring a Feature Using Its Drop-Down List on page 101.
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 Release on page 190.
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
unavailable if you select Uncompressed external files from Compression
Option above, or if you are working in an .MSI.
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.
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 213.
Cluster Size
Select the bytes per sector of the distribution media.
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.
The media item appears on the Media page, in the Media Name column. To edit it,
double-click its name.
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 box. 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 two CDs, enter two 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.
4. In the Media Destinations section, click Add. The Media Destination Details dialog
box 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 box 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.
You can specify the features and components to include in each media item.
z You want to include every remaining feature and component that is not included in a
previous media item.
In any other case, use the Include Items for Media dialog box 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 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.
4. In the Include Features/Components section, click Add. The Include Items for
Media dialog box appears.
6. In the list box, select one or more features or components and click OK.
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.
3. Click Share at the right of the Media page. The Share Release dialog box 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 box appears.
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 other release.
z The files for your application use 1.5 GB of uncompressed disk space.
z For each of the two 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 two 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.
2. Click Add at the right of the Media page. The Media Details dialog box appears.
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).
Cluster Size
Select 2048 Bytes.
4. In the Media Destinations section, click Add. The Media Destination Details dialog
box appears.
Destination Directory
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 box appears.
Destination Directory
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.
12. On the Media page, click Add. The Media Details dialog box appears.
Media Name
Enter a name for the second media item. Example: Uncompressed Files.
Compression Option
Select Uncompressed external files.
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.
z Creating a .NET Installation When You Have the .NET Framework on page 236
Use the Mobile Devices page to configure a Windows Installer installation to install files
that support a mobile device application.
This lets you install the main application to a desktop computer and simultaneously
install support for any mobile device that the user has. The ability to install to multiple
platforms at once, including Windows, simplifies the installation process for you and the
end user.
z Palm OS
If the installation supports the Pocket PC 2002 platform, you also can 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 in the installation, the
Download Redistributables wizard appears during compile and prompts you to download
it.
See also:
For Windows Mobile applications, the installation consists of one or more .CAB
files. Obtain the .CAB files from a vendor or other source.
For Palm OS applications, the installation consists of one or more files in any of
these formats: .PDB, .PRC, or .PQA.
2. In Windows Installer Editor, go to Installation Expert > Mobile Devices page and add
the mobile device installation files.
3. Finish assembling the Windows Installer installation. Any resources that you add to
the installation, other than those on the Mobile Devices page, are installed on the
desktop computer, not the mobile device.
4. If you added one or more Palm OS files, and you selected the option to install to the
Palm user folder, then verify that the installation contains the Installation Type and
Palm User Information dialog boxes.
5. Compile the installation. The mobile device installation files are included in the
compiled .MSI or .EXE. If you added Windows Mobile .CAB files, an .INI file that
describes the .CABs is created and included in the compiled .MSI or .EXE.
See also:
Mobile device .CAB files are generated by the CabWiz program from an information file
(.INF). The .INF is a text file that specifies directories, files, settings, and configurations
that are used to install a mobile device application.
(Pocket PC applications only.) A single .INF file can contain information to produce
multiple .CAB files. Example: An application supports the Windows Mobile and Pocket PC
2002 platforms, but several of the application files are platform-dependent. When you
create the installation, you assign the files to the device that supports that platform.
When you compile, the Windows Mobile-specific files are placed in the Windows Mobile
.CAB file, and the Pocket PC 2002-specific files are placed in the Pocket PC 2002 .CAB
file.
z The .CAB file and an .INI file that describes the .CAB are included in an installation
that runs on the desktop computer. The desktop computer contains Application
Manager (CeAppMgr.exe), which is installed with ActiveSync. Application Manager
installs the mobile device application on the device.
z The end user copies the .CAB file to the mobile device and opens it. The .CAB file
extracts its contents to the directories that were specified in the .INF file.
Uninstall of the mobile device application is controlled by the mobile device and
ActiveSync. Uninstalling the mobile device installation from the desktop computer does
not affect the application that is installed on the mobile device.
To add Windows Mobile .CAB files to a desktop installation, use Installation Expert >
Mobile Devices page.
See also:
z Select Installation Expert > Mobile Devices. Do this to add the mobile device
installation to an existing installation.
a. 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.
b. Click Add at the right of the page and select Windows Mobile.
If the Mobile Devices page is not visible, select All or Windows Mobile
Application from the Page Views drop-down list in Installation Expert.
z On the New Installation File dialog box, select the Windows Mobile template from
the Predefined Templates category. Do this to add the mobile device installation to a
new installation.
(In Visual Studio: On the New File dialog box, select the Windows Mobile template
from the Wise Files category.)
Application Name
Enter the name of the application you are installing. This appears in the list of
applications on the Mobile Devices page. It also appears in the desktop
computer’s mobile device software (the Add/Remove Programs dialog box,
which is accessible from the Microsoft ActiveSync window).
Description
This appears in the desktop computer’s mobile device software.
c. Click Next.
Desktop Directory
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.
If installation onto the mobile device will not take place immediately following the
desktop installation, then use the following fields to create a shortcut on the desktop
computer. This shortcut starts installation onto the mobile device by calling the
Application Manager.
Shortcut Name
Enter a name for the shortcut on the mobile device.
Shortcut Directory
Select a directory on the desktop computer in which to place the shortcut.
Typically, this is the Windows Start menu.
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 appears in the Shortcut
Directory you selected above.
4. Click Finish.
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 change or delete these items because doing
so will cause the mobile device installation to fail.
See also:
z .PQA (Palm query application), which is a .PDB that contains world-wide web
content.
To install a Palm OS application, the end user installs or downloads its file to the desktop
computer, runs the Palm Desktop software to specify the new application, and performs
a HotSync operation to install the application on the mobile device.
To add Palm OS files to a desktop installation, use Installation Expert > Mobile Devices
page. You can specify where the Palm OS files are installed.
When multiple Palm users use the desktop computer, the end user who runs the
Windows Installer installation can specify which Palm users should be able to access the
new Palm application.
a. Mark the Install File to Palm User Folder During Installation check box on
the Palm File Details dialog box.
b. Add the Installation Type and Palm User Information dialog boxes to the
installation.
a. Selects Custom on the Install Type dialog box. This causes the Palm User
Information dialog box to appear.
b. Selects users on the Palm User Information dialog box, which lists all Palm users
on the desktop computer.
The Palm files are installed in the directories for the specified users. If the steps above
are not followed, the files are installed for all Palm users.
Installations that were created in a product earlier than Wise for Windows Installer 5.0
or Windows Installer Editor 4.5 might not contain the Palm User Information dialog box.
You can add this dialog box.
Uninstalling
Uninstall of the mobile device application is controlled by the Palm device. Uninstalling
the application from the desktop computer does not affect the application that is
installed on the mobile device.
See also:
z Select Installation Expert > Mobile Devices. Do this to add the mobile device
installation to an existing installation.
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.
Click Add at the right of the page and select Palm OS.
If the Mobile Devices page is not visible, select All or Palm Application from the
Page Views drop-down list in Installation Expert.
z On the New Installation File dialog box, select the Palm Application template from
the Predefined Templates category. Do this to add the mobile device installation to a
new installation.
(In Visual Studio: On the New File dialog box, select the Palm Application template
from the Wise Files category.)
Application Name
Enter the name of the application you are installing. This appears in the list of
applications on the Mobile Devices page.
Desktop Directory
Specify a directory on the desktop computer in which to store the files that will
be added to the Palm device. Typically, this is a subdirectory of the Program
Files directory. If you select one of the folder options on the Palm File Details
dialog box, the files are copied to the Palm-specific directories. The files in this
directory are uninstalled when the .MSI is uninstalled from the desktop
computer.
2. Click Add, specify a file, and complete the Palm File Details dialog box:
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.
Note
Files that are installed in the Add-on folder or Palm user folders are not uninstalled
when the desktop application is uninstalled.
See also:
Command lines that you can apply Command lines that you can apply to
to installations at run time Windows Installer Editor for
compiling
Call MSIExec.EXE. Call WFWI.EXE.
Are applied to Windows Installer Are applied to Windows Installer Editor at
installations or patches at run time. run time to compile an installation.
Options 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.
Are documented fully in Command Line Are documented in Wise product
Options and Standard Installer documentation.
Command Line Options in the Windows
See Command Line Options For WFWI.EXE
Installer SDK Help.
on page 231.
z 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 223.
See also:
Use the Command Line page in Installation Expert to create syntactically correct
command lines to apply to an installation at run time. These are applied to MSIExec.EXE
on the destination computer. Command lines that you create appear in a popup menu
for the Test and Run buttons so you can test them.
2. Click Add.
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.
Name
Enter the name of the command line.
Shortcut File
Specify the full path 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 box. 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.
Logging
Generate a log when the installation is run and select logging options.
Advertising
Advertise applications and apply a transform to the advertised package.
Repair
Repair installed files.
Properties
Change the value of public properties.
Transforms
Apply transforms to the installation package using the TRANSFORMS property.
Patches
Add or remove patches using the PATCH and MSIPATCHREMOVE properties.
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.
See also:
You can use a command line to 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.
2. To enable the UI Options check boxes, mark Set User Interface level.
qn - No UI
Displays no user interface during the installation.
qb - Basic UI
Displays built-in modeless dialog boxes that show progress messages during
the installation.
Note
Modal dialog boxes require user input whereas modeless dialog boxes 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 dialog boxes 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 box at the end of the
installation.
qb+ - Basic UI
Displays built-in modeless dialog boxes that show progress messages during
the installation and a modal dialog box at the end of the installation.
qb- - Basic UI
Displays built-in modeless dialog boxes that show progress messages and no
modal dialog boxes during the installation.
4. If you mark the qb, qb+, or qb- option, then the Hide the Cancel Button check
box is enabled. Check this to add the ! switch to the command line, which removes
the Cancel button from the installation dialog boxes.
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.
6. If you mark Quiet or Passive in the Windows Installer 3.0 only section, you can
also control how Windows Installer handles restarts.
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.
See also:
You can use a command line to 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.
In Windows Installer 4.0 and later, you can set logging options in the installation instead
of with a command line.
2. To enable the Logging Options check boxes, 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.
4. To set logging options for all versions of Windows Installer, mark the appropriate
check boxes in the All Windows Installer versions section:
v - Verbose output
Logs more detailed information about each event or error.
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.
o - Out-of-disk-space messages
p - Terminal properties
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.
See also:
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 use a command line to 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.
Note
The Advertising tab appears only when Install Mode on the General tab of the
Command Line Details dialog box is set to Advertised.
In the field below the check box, specify the transform file to include in the
installation.
3. Click OK.
See also:
You can use a command line to 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.
Note
The Repair tab appears only when Install Mode on the General tab of the
Command Line Details dialog box is set to Repair.
3. Click OK.
See also:
For information on public properties, see Public Properties in the Windows Installer SDK
Help.
Note
The Properties tab appears only when Install Mode on the General tab of the
Command Line Details dialog box 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.
4. Click OK.
See also:
For information on transforms, see TRANSFORMS Property in the Windows Installer SDK
Help.
Note
The Transforms tab appears only when Install Mode on the General tab of the
Command Line Details dialog box is set to Install.
4. Because Windows Installer applies transforms in the order specified, adjust the
order of the transforms as needed.
5. Click OK.
See also:
You can use a command line to 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.
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 box.
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.
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.
See also:
You can also start Windows Installer Editor (WfWI.exe) in the Visual MSIDiff mode using
the following command line:
Do not confuse this list of command-line options with the command-line options that you
can apply at run time to an .MSI through the executable msiexec.exe. For a list of those
command-line options, see Command Line Options in the Windows Installer SDK Help.
If you set multiple properties, separate the property value pairs with spaces. Enclose the
values with double quotes.
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 Control
Panel:
where:
z “path\project file” is the path to the installation (.WSI) or merge module (.WSM)
project file to compile
z “path\output file” is the location of the compiled installation (.MSI) or merge module
(.MSM)
Requirements
z You must have a valid code signing certificate, which you can obtain from a
commercial certificate authority such as Verisign. For a list of certificate authorities,
search for “Microsoft Root Certificate Program Members” in the MSDN Library
(msdn.microsoft.com/library/).
z Web URL
Enter your organization’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 has 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 on your computer
to build the installation but does not need to be available to the end user running
the installation.
z Certificate options
Note
The ability to add a digital signature to .MSI and external .CAB files is supported by
Windows Installer 2.0 or later only.
See also:
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 Serial Number
Enter the serial number of the application being installed.
2. In the Application Type field, select either .NET Application or Mixed (.NET and
Win32).
This designates the installation as .NET and determines how Windows Installer
Editor handles COM interop registry entries.
3. Add assemblies and their dependency files to the installation, using the Files page.
Windows Installer Editor 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 does not contain the .NET Framework, 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.
The Windows Vista and later operating systems already include the .NET
Framework.
5. Finish building the installation as usual, then compile and distribute it.
See also:
This designates the installation as .NET and determines how Windows Installer
Editor handles COM interop registry entries.
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 command
prompt. When you run ildasm, you select an assembly and the program displays
the assembly’s attributes. Write down the assembly’s culture, name,
publicKeyToken, and version, as well as any dependencies.
c. On the 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 page, double-click an assembly to display
the File Details dialog box. Click the Assembly tab. Click Add to add the Name
and Value of the assembly’s culture, name, publicKeyToken, and version.
Repeat for each assembly.
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 command prompt. Run regasm with the argument /regfile and
specify a file name.
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
(msdn.microsoft.com/library/).
c. On the Registry page, import the .REG file you created for each assembly.
6. If the destination computer does not contain the .NET Framework, 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.
The Windows Vista and later operating systems already include the .NET
Framework.
7. Finish building the installation as usual, then compile and distribute it.
See also:
On this page, you specify a connection string and SQL statements, which are executed
during installation. Therefore, you have the ability to do any configuration that is
possible with SQL statements.
z Specify a database to recreate, and the necessary SQL statements are generated
automatically.
See Tips for Using the SQL Server Scripts Page on page 239.
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.
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.
5. Click the Statements tab and specify SQL statements to be executed on the
destination computer.
6. Click the Replacement tab and specify text strings to be found and replaced within
the SQL statements at install time.
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 170.
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
destination computer.
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 messages.
Note
These tips assume familiarity with SQL Server statement syntax and debugging.
Technical Support does not provide assistance with debugging SQL statements.
See also:
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 box 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 box and clicks Next.
If your application connects to more than one SQL Server during installation,
add a SQL Connection dialog box for each additional server, edit the additional
dialog boxes, and use a different property for each connection string.
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.
See also:
Tips for Using the SQL Server Scripts Page on page 239
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.
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 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 two options, enter
a list of table names delimited by commas.
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 messages.
See also:
Tips for Using the SQL Server Scripts Page on page 239
2. Click Add.
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 box 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.
See also:
Tips for Using the SQL Server Scripts Page on page 239
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.
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. 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.
See also:
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 runs on Windows NT Server 4.0 or later.
COM+, the next generation of COM technology, is shipped with and requires the
Microsoft Windows operating system. 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. All computers can communicate through 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.
See also:
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 check box later in this procedure.
3. 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.
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 dialog boxes, you can enter that property name here, surrounded by
brackets.
Server
Installs the server portion of the MTS/COM+ application.
6. Click OK.
See also:
Translate an installation into one or This translates the default text in the
more languages installation’s user interface elements. It does
not translate your application or any user
interface elements that you customize in the
installation.
Export text strings to a file that Do this when you define a new language, or
you can send to a translator when you add or change any user interface
elements in an installation.
z When you mark the check box 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.
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 250.
A Share option makes it easy to translate several releases into the same language or set
of languages, with the same language settings.
Note
The Languages page is unavailable for transforms. Edit languages in the base .MSI.
z 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 Have Added or Changed on page 258.
z 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 253.
3. Mark the check box 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 Windows Installer Editor, 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 check box. To fix
this, close the installation, reopen it, and click Yes in the prompt that asks you to
update variables.
Destination File
Specify the full path 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 check box for German and the
installation file is named Sample, a file named Sample_German.msi is created
during compile.
Codepage, Language ID
Leave the defaults in these fields. You typically only change these fields when
you define a new language.
Note
Only one language per release can be the default release language. An error
message lets you know if you mark this check box for a second language.
6. Click OK.
7. If needed, complete the Language Details dialog box 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.
z 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 Have Added or Changed on page 258.
z 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 253.
3. Mark the check box 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.
5. In Destination File, specify the full path for the translated .MST; be sure to include
the .MST file extension.
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 check
box is unavailable when you specify an .MST as the destination file.
7. Click OK.
8. If needed, complete the Language Details dialog box 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.
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.
4. Click Share at the right of the page. The Share Release dialog box 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 box appears.
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.
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.
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 check box. In this way you can easily turn a
language off and on.
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.
Warning
When you delete a language this way, all custom translated text strings in that language
are lost.
Add the language to the Languages page and import translated text strings.
See Importing All Text Strings With the New Language Wizard on page 257.
z To restore one of the pre-translated languages, select the appropriate resource file
from the Languages subdirectory. To restore a language that you added and had
translated, specify the resource or text file containing the translated text strings.
The location of the Languages subdirectory varies.
Note
This process does not restore any custom translated text.
Example:
Suppose you want to translate an installation into Swiss French. However, that language
is not one of the pre-translated languages. 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 dialog boxes 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.
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 254.
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.
Warning
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.
See Creating a Translated .MSI on page 249 and Creating a Language Transform on
page 250.
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 Have Added or Changed on page 258.
3. Complete the page. 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.
Export
Export all text strings to a file for translation into this new language. This is the
option most typically used.
See Defining a New Language and Exporting All Text for Translation on
page 254.
Import
Import a file containing translated text strings for this language. Do this if you
already have translated text strings for this language.
See Importing All Text Strings With the New Language Wizard on page 257.
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.
5. 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 pages appear; for
details, see the topics listed in the preceding step.
The New Language wizard appears with the Specify Language Details page.
Language Name
Enter a name for the new language.
Destination File
(Optional.) Specify the full path for the translated installation file. You can
create an .MSI or a transform (.MST).
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 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.
Note
Only one language per release can be the default release language. An error
message lets you know if you mark this check box for a second language.
5. Click Next.
6. If you have not had the strings translated, mark Export and click Next.
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 dialog
boxes 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 path for the file to export text strings to.
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.
This procedure assumes that you have added the new language to the Languages page,
defined its settings, and exported text strings.
See Defining a New Language and Exporting All Text for Translation on page 254.
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 257.
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 box and compare the entries in the Changed and Exported columns. They
should match.
See Keeping Track of Changed Text Strings on page 268.
To import all text strings using the Language Strings dialog box
1. Select Installation Expert > Languages page.
4. From Language, select the language for which you will replace all text strings.
5. At the bottom left of the Language Strings dialog box, click Import.
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 have
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 249 and Creating a Language Transform on
page 250.
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 49.
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.
The New Language wizard appears with the Specify Language Details page.
Language Name
Enter a name for the new language.
Destination File
(Optional.) Specify the full path for the translated installation file. You can
create an .MSI or a transform (.MST).
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 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.
Note
Only one language per release can be the default release language. An error
message lets you know if you mark this check box for a second language.
5. Click Next.
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 249 and Creating a Language Transform on
page 250.
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 259.
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 261.
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 253.
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 box controls to accommodate text expansion.
Note
dialog box 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.
See Conditions for controls on dialog boxes on page 381. Also see UserLanguageID
Property in the Windows Installer SDK Help.
See Exporting Selected Text Strings to a File on page 259 and Importing Selected Text
Strings From a File on page 261.
Example:
Suppose an installation is in English and Spanish. You decide to add a new dialog box to
the installation wizard. You add the dialog box in the default language (in this case,
English). That way, the dialog box is added to all languages in the installation (English
and Spanish). However, because the Spanish text for the new dialog box does not exist,
the new dialog box displays in English, even in the Spanish version of the installation.
You must export all the text on the new dialog box to a file, have it translated to
Spanish, and then import the Spanish version of the text back into the installation.
z 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 253.
z 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 263.
z You can use the Language Strings dialog box on the Languages page to keep track
of changed and exported text strings.
See Keeping Track of Changed Text Strings on page 268.
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.
6. From Export As, select a file type for the text strings:
Resource File
Exports the dialog boxes 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 dialog boxes appropriately for each language.
Text File
Exports the strings to a standard text file, in which fields are separated by tabs.
Warning
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 path for the file to export text strings to.
9. To include the installation’s file and directory names in the export file, mark Export
File and Directory Names.
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.
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.
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:
b. In Original Strings File, specify the name of the file you exported for
translation.
8. Click OK.
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
box and compare the entries in the Changed and Exported columns. They should match.
See Keeping Track of Changed Text Strings on page 268.
dialog box 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 box. You already know the German translation for “Cancel” because
other dialog boxes 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.
z Translate specific text in the Language Strings dialog box. This lets you see at a
glance the translation status of text strings in the installation.
See Translating Text on the Language Strings Dialog.
Both of the above procedures assume that you already have the translation for the
changed text.
z 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 253.
z 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 259.
If you need to translate larger amounts of text, export the text strings to a file.
4. From Language, select a language. The Language Strings dialog box shows the
text strings for that language.
5. In the Translated Text column, click the text to change and press Enter.
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 box.
If you need to translate larger amounts of text, export the text strings to a file.
2. Go to the table, dialog box, 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 selected
from the Language menu.
You can observe the change in the Language Strings dialog box. Similarly, you can
change translated text in the Language Strings dialog box, then observe the change in
Installation Expert or Setup Editor.
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.
To resize dialog box controls across all languages, select the Default language.
Note
dialog box 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.
See Conditions for controls on dialog boxes on page 381. Also see UserLanguageID
Property in the Windows Installer SDK Help.
Example:
Suppose you have translated an installation to German, and you want to resize buttons
and text boxes on a dialog box to accommodate the longer German text. In Setup Editor,
click the Dialogs tab and display a dialog box. Its text is in the default language. Now
select Language menu > German. The dialog box is displayed in German, and you can
resize dialog box 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 dialog boxes selected. This means you cannot add files or select dialog
boxes for a certain language in this manner. Any file you add in Installation Expert or
any dialog box 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 dialog boxes for a certain
language only, use features and the Release Settings page.
The default language is initially English, however, you can change it. You also can
override the default language for a specific release by designating a default release
language.
See Changing the Default Language on page 265 and About the Default Release
Language on page 267.
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.
4. Mark Create .WSI or .WSM project file that can be compiled into an .MSI or
.MSM and click OK.
5. Select Installation Expert > Languages page and mark the check box next to the
language that should be the default.
6. Double-click the language name to display the Language Details dialog box.
8. Click Compile.
a. Navigate to the Templates subdirectory and enter a file name. The location of
the Templates subdirectory varies.
c. Click Save.
The .WSI is saved and then is compiled to an .MSI. Only .MSIs appear in the New
Installation File dialog box as templates.
The New Installation File dialog box appears and the file you just created appears in
the Custom Templates category. If the New Installation File dialog box does not
contain the new template, check to make sure you saved the installation as an .MSI
in the Templates directory.
The Default language should be the only one listed on the Language menu.
In Installation Expert > Dialogs page, display any dialog box. The dialog box
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.
4. In the Templates list, click the Windows Application Project icon and click Open.
5. Select Installation Expert > Languages page and mark the check box next to the
language that should be the default.
6. Double-click the language name to display the Language Details dialog box.
8. Select File menu > Save As, name the file, and save it.
10. Copy the .MSI file to the Templates\File directory. The location of the Templates
directory varies.
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.
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
box 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.
The Default language should be the only one listed on the Language menu.
In Installation Expert > Dialogs page, display any dialog box. The dialog box
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.
Example: Suppose you’re creating an installation named Sample and you only want to
create one .MSI, in German. Mark the Default release language check box on the
Language Details dialog box for German. When you compile, Sample.msi will be in
German. If you don’t mark the check box, 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 check box for
German and, on the Language Details dialog box for German, you mark the Default
release language check box. Then, back on the Languages page, you mark the check
box for Spanish. On the Language Details dialog box 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 check box is on the Language Details dialog box and
the Specify Language Details page of the New Language wizard. It appears in .WSI files
only.
Note
Only one language per release can be the default release language.
See also:
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 have imported text strings, one of two
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 have 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.
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
Hindi
Hungarian
Indonesian
Japanese
Korean
Norwegian
Polish
Portuguese (Brazil)
Russian
Romanian
Spanish (Basque)
Spanish (Catalan)
Swedish
Thai
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.
The default language for all installations is English, unless you change it.
Language IDs
Windows Installer uses language IDs to determine whether the destination computer
supports the language that is used for the installation dialog boxes. Example: If you
create an installation with the language ID for Greek, that installation only runs on a
computer with Greek fonts.
Package Distribution
When you complete and compile an installation, you can use Package Distribution to
share or deploy it by:
Copying a project and its source files to a network directory lets you share the project
with coworkers without breaking the paths to source files. The source file paths are
changed to the new paths during this process. These paths are not relative; however,
you can use relative paths in a project file.
When you run package Distribution from a .WSI, it is compiled and the compiled
installation is distributed. If an .EXE is associated with the installation, the .EXE is
distributed.
To copy a .WSI with its .PDF or .SMS file, select the Installation option on the
Distribution Method page. If a .WSI never existed, use the .MSI.
2. If you specified a .WSI that contains multiple releases, a drop-down list appears.
Select a release.
3. Mark Network.
Network Directory
Specify the directory to copy the package to.
6. Click Finish.
See also:
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.
When you run package Distribution from a .WSI, it is compiled and the compiled
installation is distributed. If an .EXE is associated with the installation, the .EXE is
distributed.
2. If you specified a .WSI that contains multiple releases, a drop-down list appears.
Select a release.
6. Click Next.
The package is uploaded to the FTP server. A dialog box 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.)
See also:
2. If you specified a .WSI that contains multiple releases, a drop-down list appears.
Select a release.
Network Directory
Specify the directory in which to place the administrative installation.
5. Click Finish.
See also:
2. If you are in a .WSI that contains multiple releases, a drop-down list appears. Select
a release.
If the installation contains two or more media destinations (defined on the Media
page), the Distribution Media Directories page appears. This page 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 page 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 box.
Directory
Displays the media destination you entered on the Media Details dialog box. 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.
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.
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.
You can create upgrades and patches for installations using the UpgradeSync tool, Patch
Creation tool, and the Upgrades page.
For information on upgrading, see the following topics in the Windows Installer SDK
Help.
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.
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 Are small, containing only the changes between the original and updated
applications.
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 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.
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.
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 a 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.
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
organization’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:
Warning
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 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.
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.
UpgradeSync
Using UpgradeSync is one of the steps in preparing software for updates.
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 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 also:
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.)
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.
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.
This page 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 check box. The following types of error cannot be fixed
automatically and therefore have no check boxes:
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 284 or Creating an Upgrade on page 293.
See also:
Patch Creation
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 these files from the Microsoft Windows Installer SDK:
PATCHWIZ.DLL, MSPATCHC.DLL, and MAKECAB.EXE. They are installed in the Windows
Installer Editor installation 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).
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.
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.
See also:
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.
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 two 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.
z Family 100: A, C, D
z Family 200: B, D
See also:
The Welcome page appears, listing the basic steps for creating a patch file. The
wizard guides you through each step.
2. Click Next.
4. Click Next.
The Specify Previous Versions page 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, complete the Previous Version Details dialog
box, and click OK.
Note
The Microsoft 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 page. 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. When you finish, click Next on the Specify Previous Versions page.
Advanced
Click this to enter advanced settings. The Advanced Upgrade Version Details
dialog box appears. Complete the dialog box and click OK.
11. If you are prompted to run an administrative installation again, click Yes. If you are
prompted to update the package code, click Yes.
If you marked the option to add a digital signature, the Specify Digital Signature
Settings page appears. A warning message appears if the original installation was
not signed.
12. To add a digital signature to the patch, complete the Specify Digital Signature
Settings page.
If Windows Installer 3.0 or later is installed on your computer, the Patch Sequencing
page appears. Complete the page and click OK.
Advanced Settings
Click Advanced to display the Advanced Patch Settings dialog box. Complete the
dialog box and click OK.
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 page.
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.
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.
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 page 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.
See also:
This page 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.
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.
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.
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.
You can avoid this problem by signing patches that will be run under Windows Vista or
later operating system. To do so:
z Add a digital signature to the patch, using the same certificate that was used to sign
the original installation.
When the patch is applied, the Windows Vista or later operating system performs the
elevation for the application. This means that a standard user can run the update, and
does not have to provide administrator authorization to run the application.
Requirements
z You must have a valid code signing certificate, which you can obtain from a
commercial certificate authority such as Verisign. For a list of certificate authorities,
search for “Microsoft Root Certificate Program Members” in the MSDN Library
(msdn.microsoft.com/library/).
Also search for “User Account Control (UAC) Patching” in the MSDN Library
(msdn.microsoft.com/library).
z Web URL
Enter your organization’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 has 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 on your computer
to build the installation but does not need to be available to the end user running
the installation.
z Certificate options
z Certificate options
See also:
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.
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.
4. On the Patch Sequencing dialog box, add more sequencing information if needed.
When you finish, click Next to continue the Patch Creation wizard.
See also:
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 box.
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 box. You should always leave
this check box marked.
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.
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.
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
To create 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.
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.
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 check box.
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 check box.
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.
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 specify the features to
remove. 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.
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.
4. Click OK.
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.
Windows Installer Editor integrates with leading SCCS applications to let you perform
source control tasks on an installation. Windows Installer Editor determines the SCCS
that you are using and calls APIs that interact with it. The API functions display dialog
boxes 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 Windows Installer Editor.
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 Windows Installer
Editor works though your existing user account, the permissions you experience in
Windows Installer Editor are the same as those you already have set in your SCCS.
z Enable the Source Control menu by marking the Enable source control check box
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 296.
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 dialog boxes.)
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
the Visual Studio interface. If you do, the installation file and its XML copy will get
out of sync.
See also:
To use source control, you must have a source code control system (SCCS) installed on
your computer.
b. Mark Enable source control. This enables the Source Control menu.
Dialog boxes 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 dialog boxes appear, the Add to Source Control dialog box
appears. This dialog box contains the files that you add to the installation and
resource files from the Windows Installer Editor 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 box 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 box, mark the check boxes 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 box 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 box prompts
you to move the files to a new directory under the installation file directory.
4. Mark the check boxes 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.
See also:
The Add to Source Control dialog box appears. This dialog box shows files in the
installation that have not yet been added to source control.
2. On the Add to Source Control dialog box, mark the check boxes 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 box 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 box prompts
you to move the files to a new directory under the installation file directory.
3. Mark the check boxes 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.
See also:
If you check a file in, then try 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.
The Check In dialog box 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 box even if you
previously did not check it out.
2. Mark the check boxes 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.
See also:
If you check a file in, then try 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.
The Check Out dialog box 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 box even if you
previously did not check them in.
2. Mark the check boxes of the files to check out from source control and click OK.
Comments, which are stored as an attribute of the file in the SCCS, are optional.
See also:
The Get Latest Version dialog box appears, listing all files in the installation.
2. Mark the check boxes 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.
See also:
The Remove dialog box appears, listing all files in the installation.
2. Mark the check boxes of the files to remove from source control and click OK.
Comments, which are stored as an attribute of the file in the SCCS, are optional.
See also:
The Undo Check Out dialog box 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 box even if you
previously did not check it out.
2. Mark the check boxes 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.
See also:
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.
Dialog boxes from your SCCS appear. For information on these dialog boxes, consult the
documentation for your SCCS. In Microsoft Visual SourceSafe, the History Options dialog
box appears, followed by the History of ProjectFileName.wsi dialog box.
See also:
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 Windows Installer Editor, select Source Control menu >
Show Differences. Dialog boxes from your SCCS appear. For help using these dialog
boxes to show differences, consult the documentation for your SCCS.
Note
If you are using Microsoft Visual SourceSafe, the Difference Options dialog box 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 also:
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.
You are taken to Setup Editor > Tables tab and the Visual MSIDiff Key dialog box
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 box, take note of the symbols and colors that
indicate changes and click OK.
If the Visual MSIDiff Key dialog box does not appear, you might have clicked its Do
not show this dialog again check box. You can reactivate this dialog box 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 also:
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 306. 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.
Turning substitution off does not remove the path variable from paths for files added
previously; it only affects paths for files added subsequently.
See also:
2. Click Add at the right of the page and select User-Defined Path Variable.
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 paths 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 path.
4. Click OK.
See also:
2. Click Add at the right of the page and select Environment Path Variable.
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 paths of files
that are pulled from the directory that appears in Current Value.
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.
See also:
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.
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 paths of files
that are pulled from the directory that appears in Current Value.
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.
See also:
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 Rename a directory.
If paths are broken, 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 new source directories for these files. If files with broken paths should not be
in the installation, you can use the Remove Missing Files tool to remove them.
See Removing Files With Missing or Invalid Source Paths on page 354.
The Convert Source Paths dialog box 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 or Visual Studio Solution page and double-click a file
in the lower-right list box. The File Details dialog box appears, which displays the path
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.
See also:
The Convert Source Paths dialog box appears with a list of all the directories that are
referenced in the installation.
To change multiple directories, select a high-level directory so that you can change
all of its subdirectories.
Change to
Specify the new path.
Change Sub-Directories
Mark this to change the subdirectories of the current directory.
5. Click OK.
The Change Source Directories to column displays the new path. If you marked
Change Sub-Directories, all directories that start with the same name as the one
you changed are renamed.
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 box.
8. Click OK.
All parts of the installation that reference these directories are updated.
See also:
A relative path 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 path of Application.ini is ..\Program
Files\Application.ini.
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.
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.
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 paths. 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.
See also:
Use the procedures below to change the source directory dynamically during compile.
2. In the right pane, select New > Property from the right-click menu.
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.
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++
Change Sub-Directories
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.
See About Command Lines on page 223 and Source Paths in an Installation on
page 306.
Example: Suppose you have five 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 five
installations for all applications, you update only the merge module, then recompile the
five installations.
When deploying software through a merge module, keep update considerations in mind.
Example: If you deploy MSDE through 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.
z Predefined merge modules that install commonly-used software packages. You can
download these from the Wise Web site or from other vendors’ Web sites.
See Downloading Redistributable Files on page 30.
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 433 and Using the Custom Action Location Tab for
Merge Modules on page 480.
When you add a configurable merge module to an installation, an additional dialog box
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 also:
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.
See Items you can add on the Features tab on page 360.
The panes on the Module tab show only the items you have 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.
See also:
If there is no Module Details page, you are not in a merge module file.
Module Name
Enter a name that Windows Installer and Windows Installer Editor can use
internally to identify the merge module.
Version
Enter the version of the module. Windows Installer and Windows Installer Editor
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 ID for the merge module. English is 1033. Language neutral
(meaning the merge module works with all languages) is 0.
Module Type
Select the module type. This defaults to the Default Application Type that is
specified in Wise Options.
Note
The ability to create .NET installations is supported only by Windows Installer
2.0 or later.
.NET Application
A .NET merge module with only .NET 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.
See also:
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, Windows Installer Editor tries to add the
dependency merge module, MDAC.
Windows Installer Editor 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 Windows Installer Editor does not find the dependent module in
either of these places, it prompts you to add the dependency merge module yourself.
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 box
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 box 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 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.
Note
The information on the Dependency Module Details dialog box fills the
ModuleDependency table, which you can see in Setup Editor > Tables tab. See
ModuleDependency Table in the Windows Installer SDK Help.
See also:
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.
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 box 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 box 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
selected includes a complete language group but you want to exclude one
language in this group only.) To ignore any language considerations, enter 0.
4. Click OK.
Note
The information on the Exclusion Module Details dialog box fills the ModuleExclusion
table, which you can see in Setup Editor > Tables tab. See ModuleExclusion Table in
the Windows Installer SDK Help.
See also:
(Visual Studio integrated editor.) Follow this procedure to create a merge module that is
not associated with a Visual Studio 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.
You also can create a merge module that is part of a Visual Studio solution.
The Target Platform section on the New Installation File dialog box appears only if
Select platform in New Installation File dialog is selected in Wise Options.
A new merge module opens. In Installation Expert, four page groups appear,
showing the pages that apply to merge modules.
5. Click Open.
The new merge module opens. In Installation Expert, four page groups appear,
showing the pages that apply to merge modules.
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.
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 314 and Setting Exclusions
for a Merge Module on page 315.
5. Configure the Module Details page, which contains the merge module name,
language, and version.
After you create the merge module, you can add it to a standard installation.
See also:
You can also create a merge module that is not integrated with a Visual Studio solution.
3. In the Project Types list, select Wise Setup and Deployment Projects.
Select the Setup Wizard icon to create a new merge module and enter its
project settings.
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.
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.
b. On the wizards’ Project Type page, select the Merge Module option.
d. Click Finish.
A merge module project is created in the location you specified and is listed in
Solution Explorer.
The new merge module opens. In Installation Expert, four 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.
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 314 and Setting Exclusions
for a Merge Module on page 315.
13. Configure the summary information for the merge module, which is described in
General Information Page on page 95.
14. Configure the Module Details page, which contains the merge module name,
language, and version.
After you create the merge module, you can add it to a standard installation.
See also:
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.
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.
Module Name
Enter a name that Windows Installer and Windows Installer Editor can use
internally to identify the merge module.
Version
Enter the version of the module. Windows Installer and Windows Installer Editor
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 ID for the merge module. English is 1033. Language neutral
(meaning the merge module works with all languages) is 0.
4. Click Next.
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 check boxes 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.
See also:
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.
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 316. (In Visual Studio: also see Creating a Merge Module
Within a Solution on page 318.)
3. From Table, select the table that contains the item to be configured when the
merge module is added to an installation.
Configurable Item
Select to add a configuration item to the selected substitution item.
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 two steps.
If you add multiple values, multiple rows appear in the list box and the values are
concatenated to create the entire substitution value.
8. Click OK.
See also:
Name
Enter a name to represent the item in the Configuration Items list box on the
Module Substitution dialog box.
Display Name
Enter the name that should appear on the Merge Module Configuration dialog
box 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.
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.
For information on the format types like the ones listed above, see Text Format
Types in the Windows Installer SDK Help.
See Specifying a Bitfield for Substitution on page 324 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 box configurable.
See Specifying a Key for Substitution on page 325 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 box when the
configurable merge module is added to an installation. This is the value that can
be changed.
3. Click OK.
4. Click Add.
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
box.
Value
Enter the value to be substituted for the current value of the configuration item.
6. Click OK.
The Configuration Item Details dialog box lists the text and value you defined.
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.
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.
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.
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
box.
Value
Enter the value to be substituted for the current value of the configuration item.
7. Click OK.
The Configuration Item Details dialog box lists the text and value you defined.
9. 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.
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 box 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.
The values you defined for the configurable item appear in the Value field, and the
items appear in the Configuration Item list box.
7. Click OK.
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
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.
9. In Constant Substitution Value, enter the pipe character (|) and click OK.
On the Module Substitution dialog box, the pipe character (|) appears in the
Configuration Items list box, below short_name.
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.”
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 box 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.
See also:
See:
When deploying software through a merge module, keep update considerations in mind.
Example: If you deploy MSDE through 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.
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.
The Select Merge Module dialog box appears and lists available merge modules in
the directories specified 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. The merge modules in this directory are added to
the list of available merge modules.
See Setting Merge Module Directories on page 45.
Click Download to add merge modules from the Wise Web site, other vendors’
Web sites. 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.
See Downloading Redistributable Files on page 30.
5. Select one or more merge modules from the list by marking the corresponding
check boxes.
6. Click Next.
7. To change the destination for a merge module, select one or more merge modules
and click Change.
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 box contains a Finish button.
Click Finish to complete this process.
10. If the installation contains multiple features, the Merge Module File Directory dialog
box contains a Next button. Click Next to continue.
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 box 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 box contains a Next button. Click Next to continue. The Merge
Module Configuration dialog box 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.
15. If you’re adding more than one configurable merge module, a Next button appears
at the bottom of the dialog box. Click Next and repeat the preceding step.
The Next button changes to a Finish button when the Merge Module Configuration
dialog box shows the last configurable merge module to be added.
The merge modules are added to this installation. If any of the merge modules contain
dependencies, Windows Installer Editor tries to add them by looking in the default
merge module directory.
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.
See also:
2. From Current Feature, select the feature or condition that contains the merge
module to edit.
The Merge Module Details dialog box appears. It has one tab if you double-clicked a
standard merge module and two tabs for a configurable merge module.
4. Click the Settings tab and change the dialog box’s settings as needed:
Destination Directory
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 check boxes.
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 box has a
Configuration tab. To change configuration values:
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.
RTF Value
Enter any text in rich text format.
For information on the format types listed above, see Text Format Types in the
Windows Installer SDK Help.
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 321.
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.
See also:
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. Typically, a transform works
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.
z A transform based on changes that you make to an existing installation. This lets
you change any aspect of an installation.
See Creating a Transform Based on an Existing .MSI.
z A language transform that lets you change the language on the dialog boxes that
appear during installation.
See Creating a Language Transform on page 250.
Note
The Languages pages is unavailable for transforms. Edit languages in the base .MSI.
See also:
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.
2. Select File menu > New. The New Installation File dialog box appears.
(In Visual Studio: select File menu > New > File. The New File dialog box appears.)
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 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.
See also:
In most cases, if you create the transform using Windows Installer Editor, you can leave
the defaults on the Transform Details dialog box. See MsiCreateTransformSummaryInfo
in the Windows Installer SDK Help.
z Base database
(Read-only) This is the .MSI on which this transform is based. If this transform is
applied to a database other than the one specified here, an error is generated
during installation.
z Validation
The following check boxes 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.
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.
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.
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.
CmdLine=TRANSFORMS="TransformName.mst" /i
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.
z Removing Dependencies from the Project Dependency Exclusion List on page 343
You can start a tool in several ways (some options are available for specific tools only).
z By clicking its icon on the Tools toolbar. To display the Tools toolbar, select View
menu > Tools.
In Visual Studio: View menu > Toolbars > Wise Wizards.
z By clicking its icon on the New Installation File dialog box, which puts the results
from the tool into a new installation file.
In Visual Studio: New Project or New File dialog box.
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.
z Package Validation
z Patch Creation.
z UpgradeSync
z Visual MSIDiff™
See Comparing Windows Installer Files on page 85.
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 computer as you execute an application or run an
installation and determines which .DLL, .OCX, and .EXE files were accessed. It then adds
these files to a new 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.
To watch an application
1. Close all other applications so that the files they access are not added to the
installation.
2. Select Tools menu > ApplicationWatch. (In Visual Studio: Project menu >
ApplicationWatch.)
Application Path
Specify the full path of the application executable to run.
Command Options
Enter any command-line options to apply to the executable. Refer to the source
application’s documentation for applicable command-line options.
5. In the source application, use all possible features except printing. If you are
watching an installation, run the installation through to completion.
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. Close the application, return to the Run Application dialog box, and click Finish.
If a file that is part of a merge module is added, the Files in Merge Modules dialog box
appears. It prompts you to add the merge module and, if necessary, download it.
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, compile
and test the installation thoroughly to verify that it operates correctly.
Warning
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.
Conversion Guidelines
Following are guidelines for using Convert SMS Installer or WiseScript Installation:
z You cannot convert all .EXEs—only those that were created with Microsoft SMS or a
WiseScript-based product.
z If you do not have the original installation project file, you can convert the compiled
.EXE instead, because it contains an embedded copy of the script.
Only the installation of files, registry changes, and other system changes are
converted.
Custom dialog boxes, custom logic, and other settings are not converted.
z All the files that are available to the original 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.
3. Select Tools menu > Convert WiseScript Installation or SMS Installer. (In Visual
Studio: Project menu > Convert WiseScript Installation or SMS Installer.)
Installation Script
Specify the full path of the .IPF or .EXE to convert.
Extract Directory
If you specified an .EXE file above, specify a directory in which to hold the
extracted files and click Next.
Files must be extracted from the .EXE before the conversion can begin. This
becomes the source directory for the new package.
When the conversion is finished, the Conversion Complete page appears. It shows
the results of the conversion and lists any errors or problems that might have
occurred. (Example: An error occurs when files that were referenced by the source
installation cannot be found.)
6. To obtain a record of any conversion errors, click Save Errors or Print Errors.
7. Click Finish.
More errors might appear at this point, which have to do with saving in Windows
Installer format.
If a file that is part of a merge module is added, the Files in Merge Modules dialog
box appears. It prompts you to add the merge module and, if necessary, download
it.
8. Open the resulting package in Windows Installer Editor to view the converted file
and to resolve reported problems.
Pages in Installation Expert, such as the Files page, are populated based on the
contents of the source installation. If you converted an .IPF, files are referenced
from their original locations. If you converted an .EXE, files from the converted
installation are stored in and referenced from the extract directory that you
specified above.
See also:
To work with projects that were created with Visual Studio or Visual Basic 2005 or
later, open the project in Visual Studio and create the installation in the Visual
Studio integrated editor.
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.
To link a development project directly to an installation project, use the Visual
Studio integrated editor.
z These tools are not designed to set up a remote automation or a DCOM™ server
automatically.
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 Visual Basic 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.
z You can only use the Import Visual Basic 5/6 Project tool in a stand-alone
installation project. You cannot use it in a multi-project solution.
See Creating a Stand-alone Installation on page 75.
Select File menu > New. On the New Installation File dialog box, select Import
Tools from the Categories list, and in the Templates/Tools list, double-click
the type of project to import. This creates an installation that contains only the
information from the imported installation.
Select Tools menu > Import Tools and select the type of project to import. This
adds the imported installation’s information to the current installation file.
The Project or Solution File dialog box appears.
2. In Project or Solution File, specify the path to the project or solution file and click
Next.
(Visual Basic .NET, C#, or J# projects.) The Select Configuration dialog box
appears. This displays the configurations that are in the solution or project,
which correspond to build configurations in your Microsoft development
environment.
(Visual Basic 5 or 6 project.) The Select Visual Basic Directory dialog box
appears.
Specify the directory on your computer where Visual Basic 5 or 6 is installed.
This directory contains the support files that must be included in the installation
because they are needed by the Visual Basic program.
2. In VB Project File, specify the path to the project file and click Next.
3. Specify the directory on your computer where Visual Basic 5 or 6 is installed. This
directory contains the support files that must be included in the installation because
they are needed by the Visual Basic program.
The Scanning Project Files page appears. During or after the scan, additional
prompts and pages might appear:
If the project is out of date or missing, a prompt appears. You can try to rebuild
the project from this tool, or open the development environment and rebuild
the project from there.
If the project has a reference to another project, an error message appears and
the import ends. Restart the import and select the solution file (.SLN) that
contains both projects.
If dependency files (.DEP) for Win32 target files are missing, the Dependency
Files Not Found page appears. Dependency files list referenced files. This page
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.
If any files on the Dependency Files Not Found page are crucial to this
installation:
b. Locate the files and move them to the System or System32 directory.
2. Click Next.
If target files were not found during the scan, the Files Not Found page appears.
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.
b. Click Next.
4. The Installation Files page lists the files that were detected during the scan and will
be added to the installation.
5. To add or remove files in the installation, click Add or Delete and then click Next.
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. All added files are placed in this directory in Installation Expert > Files
page.
7. Click Finish.
(Visual Basic .NET, C#, or J# projects.) If you cleared the Automatically add
Assembly Dependencies without prompting check box, the Assembly
Dependencies dialog box appears. It prompts you to select which dependencies
to add to the installation.
See Assembly Dependencies on page 123.
If a file that is part of a merge module is added, the Files in Merge Modules
dialog box appears. It prompts you to add the merge module and, if necessary,
download it.
See Adding Merge Modules Instead of Files on page 118.
The project is integrated into an 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.
When you choose not to add a dependency, it is added to the project dependency
exclusion list for that installation. The exclusion list is stored in the WiseMediaOptions
table.
Assembly dependencies that are in the exclusion list are never added to the installation,
even if the .NET assembly is rescanned, or if you add a new assembly that has the same
dependency. Use the Manage Assembly Exclusions tool to remove dependencies from
the exclusion list so that they can appear in future assembly scans.
2. On the Tools menu, click Manage Assembly Exclusions. (In Visual Studio: Project
menu > Manage Assembly Exclusions.)
3. In the Manage Assembly Exclusions dialog box, uncheck the check box for each
dependency to remove from the exclusion list.
4. Click OK.
See also:
When you run the Manage Assembly Exclusions tool, the Manage Assembly Exclusions
dialog box lists all the dependencies that are in the exclusion list for the current
installation. You can uncheck the check box next to a dependency to remove it from the
exclusion list so that it can appear in future assembly scans.
See Removing Dependencies from the Project Dependency Exclusion List on page 343.
If you have an installation .MSI, you can open and edit it in Windows Installer Editor.
However, to take advantage of some Windows Installer Editor features, you can convert
the .MSI to a project file.
See:
A .WSI file records the files and merge modules that should be compiled into the .MSI by
storing source paths. (To see the source path for a file in the installation, display its File
Details dialog box.) When you open a .WSI and compile, Windows Installer Editor 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.
2. Open an .MSI.
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 page appears;
otherwise, the File Sources page appears.
4. On the Merge Module Sources page, 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 page. To accept the default, click Next.
5. On the File Sources page, 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
Welcome page. To accept the default, click Next.
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 page 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.
You can override the default source directory in the following ways:
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.
3. Select a directory and click OK. The merge modules you selected will be extracted to
this directory instead of the default source directory.
If multiple merge modules are selected, the Select Directory dialog box appears. If
one merge module is selected, the Choose Replacement Merge Module dialog box
appears.
On the Select Directory dialog box, 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 box lists the merge modules that were not found.
On the Choose Replacement Merge Module dialog box, 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 page changes to Local to indicate
that a local merge module will be used instead of the merge module in the .MSI.
You can override the default source directory in the following ways:
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.
3. Select a directory and click OK. The selected files will be extracted to this directory
instead of the default source directory.
3. Specify a file to replace the selected file. The Source column on the File Sources
page changes to Local to indicate that a local file will be used instead of the file in
the .MSI.
Note
For the following two 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 page is appended to the end of the directory you
select.
Using this option, the Duplicate Files Details dialog box 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.
Files are matched by name. The first found instance is used. The Source column on
the File Sources page changes to Local to indicate that local files will be used instead
of files from the .MSI. If the search is unsuccessful, a dialog box 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 installation files (.MSI and .WSI), merge
modules (.MSM and .WSM), and transforms (.MST). When you select a transform,
Package Validation checks both the transform and the original .MSI.
If you correct validation errors in a .WSI or .WSM, the file is recompiled to an .MSI or
.MSM at the end of validation. If you correct validation errors in an .MSI or .MSM, errors
are not corrected in any corresponding .WSI or .WSM.
Note
Package Validation ignores issues pertaining to the group box “enabled” attribute, which
the Microsoft validation module falsely reports as an error.
See also:
Validating a Package
Predefined Validation Modules on page 352
Customizing Validation Modules on page 351
Windows Vista/Windows 7 Validation on page 353
Validating a Package
Use Package Validation to verify an installation package using predefined or customized
validation modules.
To validate a package
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.
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.
Note
The Windows Vista Compatibility Checks validation module takes longer to run than
others due to the nature of its validation checks.
When the validation is complete, the View / Correct page 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.
If the issue was found by a Microsoft validation module, see ICE Reference or Merge
Module 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.
Warning
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 Windows Installer Editor.
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.
12. To obtain a record of the issues, click Save to File or Print All.
See also:
You can customize validation modules by selecting which validation rules to use during
the validation test.
Example:
Note
When customizing a predefined validation module, customize a copy of the .CUB file to
retain the original file.
The Customized Validation Rules dialog box appears. Validation Files lists the
predefined validation modules and any validation modules you added. When you
select a validation module, its rules appear in Validation Rules.
See also:
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.
See also:
the description of the Release Type field in Creating a New Release on page 190
See also:
The contents of these tables are current as of this product’s release. You can update
these tables as follows:
z Rebuild the tables by running the GetWRPItems.exe utility, which is installed in the
bin subdirectory of this product's installation directory. Run it from the command
prompt on a computer that is running the Windows Vista or later operating system
and specify the full path to WiseVistaIce.cub. Example:
The GetWRPItems.exe utility deletes the contents of both tables and rebuilds them
based on the WRP information on your computer. Because the edition of the
Windows Vista or later operating system that is installed might affect the contents of
the rebuilt files, run the utility on the edition of the operating system that your
installations target.
See also:
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 Rename a directory.
2. Click Next.
3. Select the files to remove from the installation and click Next.
4. If you ran this tool from the Tools menu, the Compile This Installation check box
appears when the removal process finishes. Clear the check box to continue without
compiling.
5. Click Finish.
If you marked the Compile This Installation check box, or if you ran this tool from
within the compile process, the installation is compiled.
6. If you compiled the installation but you did not remove all the files with missing or
broken source paths, the Welcome page reappears. Do one of the following:
Click Cancel on the Welcome page, fix the source paths, and recompile.
a. In the lower-left list box, navigate to the directory that contains the file.
b. In the lower-right list box, double-click the file to display the File Details dialog
box.
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.
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.
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.
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 summary information by right-clicking the
compiled .MSI or .EXE in Windows Explorer and selecting
Properties.
See:
Note
In Windows Vista and later, the file Properties dialog box does not contain summary
information.
For information on summary items, see Summary Property Descriptions in the Windows
Installer SDK Help.
You can use the Release Settings page to override the value of an existing summary
item or edit customized summary items.
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:
The Template Summary determines the target platform of the compiled .MSI.
2. In the upper-right pane, double-click a summary item. The Summary Details dialog
box appears.
In a transform, some summary items are not editable because they keep the value
of the base .MSI.
4. Click OK.
You also can edit several of the summary items in Installation Expert > General
Information page.
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.
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.)
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 customize how items appear in the features tree, right-click in the left pane and
select Customize View. In the Customize View dialog box that appears, mark the
check boxes of the items to display, and rearrange items by clicking Move Up or
Move Down.
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 box to
show the icon.
You also can view merge modules that are included in specific features.
The Components icon on the Features tab shows items in each component. To access
installation items organized by component, use the Components tab.
The Assign Components to Feature dialog box appears. The dialog box lists all
components in the installation, except those already assigned to the currently
selected 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.
Components that are not assigned to any feature are not installed on the destination
computer.
2. Click the Components icon. All components for the feature appear in the upper-right
pane.
3. In the upper-right pane, click a component and drag it to a different feature in the
left pane.
See also:
Modules Icon
The Modules icon in Setup Editor 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 328 and Editing Merge Module
Details on page 330.
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.
See also:
Advertising Icon
The Advertising icon in Setup Editor 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.
Note
The Advertising icon might contain other advertising items besides file extensions
but you can add extensions only.
See Advertisement and Platform Support of Advertising in the Windows Installer SDK
Help.
If the Advertising icon does not appear, right-click and select Hide Empty Folders/
Items.
The AppID or ProgID dialog box 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
Windows Installer SDK Help.
Warning
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 also:
You also can create directories on the Files or Visual Studio Solution pages in Installation
Expert, where you can also use wildcards to add files to directories automatically.
3. At the end of the existing path, type \ (backslash) 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.
See also:
You can create a duplicate file entry only for files that are already in the installation.
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.
Existing File
Specify the path 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.
4. Click OK.
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 two 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.
See also:
To ensure that a file is installed when it is included in multiple features, do one of the
following:
z Put the file in the Complete feature or in a Hidden feature that is always installed.
z Add the file to the different components from the Components tab in Setup Editor.
The file in each component must be installed to a different directory. When you add
the same file to multiple components on the Components tab, an entry is not
created in the DuplicateFile table for the duplicates files.
See Adding Files to an Installation on page 116.
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.
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.
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 customize the icons that appear in the components tree, right-click in the left
pane and select Customize View. In the Customize View dialog box that appears,
mark the check boxes of the items to display, and rearrange items by clicking Move
Up or Move Down.
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.
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 box to
show the icon.
See also:
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.
z The component has more than one executable (.EXE, .DLL, .OCX).
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.
See also:
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 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 box, you can edit a subset of the fields found in
the Component Details dialog box.
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.
For some conditions, you might need to add a special merge module that
addresses a limitation of Windows Installer.
When you add a 64-bit component to the installation, the 64-bit component
check box below is marked automatically and the condition (VersionNT64) is
added to this field. This must be the first condition in the condition string. If you
add conditions, add them after the (VersionNT64) and enclose them in
parentheses. Example:
As long as the 64-bit check box is marked, you cannot delete the
(VersionNT64) condition. This ensures that the component is installed only on a
64-bit platform.
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.
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.
64-bit component
When this is marked, it designates the component as 64-bit. 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 check
box is marked and the Directory is Program Files (x86), you are prompted to
change this target directory to its 64-bit counterpart, Program Files.
This is marked automatically for 64-bit .EXE or .DLL files and 64-bit registry
keys that you add to the installation.
Uninstall on supercedence
Mark this to prevent leaving an orphan component of a patch package on a
computer when the patch package is superceded by another. If you mark this
option, Windows Installer 4.5 or later unregisters and uninstalls this component
when a superceding patch package is installed. If you don’t mark this option
and the component is not used, it might be left behind.
Shared
Mark this to share this component with any other installed package that has the
same component. If the package
If you clear this check box, 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.
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.
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 box appears.
4. Mark one or more check boxes for the features to assign the new component to and
click OK.
See also:
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.
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.
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.
See also:
Setup Editor indicates key paths by placing a yellow key icon over the item’s icon.
OR
z Select the item as key path on the Component Details dialog box.
See Adding and Editing a Component on page 368.
See also:
Add the .DLL to the System32 directory, as you normally would, and then create an
isolated component that moves the .DLL to your application’s directory.
Note
Before you isolate a .DLL with an executable, make sure that you have added all files to
the installation, especially .EXE and .DLL files.
The Isolated Component Details dialog box 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.
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.
See also:
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.
See also:
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.
z To edit the data created in Installation Expert or on the other tabs of Setup Editor.
Warning
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.
Column
information
List of tables in
the Windows
Installer
database. Table contents.
(The lower-right
pane is not in the
Visual Studio
integrated editor.)
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
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.
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:
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 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.
See also:
2. In the upper-right pane, right-click the row above which the new row should appear
and select New Row.
A message appears.
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.)
Warning
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.
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.
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 table:
1. In Setup Editor > Tables tab, in the left pane, right-click a table and select Delete
Table.
If you later add an item that requires the deleted table, Windows Installer Editor
automatically recreates the table.
Example: The product name changes and you need to find and replace it everywhere it
occurs.
See also:
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.
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.
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.
2. In the Direction section, mark either Up or Down to specify the search direction.
If the database contains one or more validation errors, the first one is highlighted in
red in the upper-right pane.
When validation is complete, the View / Correct dialog box 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.
See also:
The Binary table also contains binary data. To edit binary data in the Binary table, use
the Resources page.
Warning
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.
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.
If you are reading from an external file, specify the full path of a file to read.
If you are writing to a file, enter the full path 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.
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, dialog boxes, and dialog box controls to determine whether something happens
or not. Based on whether the condition is true or not, you can determine whether to:
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 Defined by Windows Installer, by you in the installation file, or by the end user
during installation.
See also:
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 About MSI Script on page 431 and Guidelines for Custom Action Conditions on
page 446.
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.
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.
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 box you see three
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 view the Items tab on the
Properties dialog box.)
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 box.
Depending on what the property InstallMode is set to, different dialog boxes 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.
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 383.
Condition Guidelines
Before creating conditions, become familiar with the following Windows Installer
guidelines for creating conditions.
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. Properties that have not been set
evaluate to an empty string “” (null).
Environment variable. Precede the variable name with a percent symbol (%).
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 383.
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 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.
WiseFixConditions
Windows Installer Editor contains a special merge module, WiseFixConditions
(CondFix.msm), that fixes certain Windows Installer limitations:
Add CondFix.msm to an installation if you add a component condition that checks the
installed state of a component or feature.
The Windows Installer Editor installation places CondFix.msm in the default merge
modules directory, or you can download it with the Download Redistributables wizard.
This merge module appears on the Select Merge Module dialog box when you add a
merge module on the Merge Modules page. If you don’t see it, you have marked the Do
not show merge modules from the Default Merge Module Directory check box in
Wise Options.
See also:
Scrolling text
box. Enter or
build conditions
here.
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 box, 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 () buttons to enclose parts of the condition, which changes the order of
precedence.
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 385 or Checking the Value of an
Environment Variable on page 386.
Note
The following two lists let you check the current or future installed state of a feature
or component.
See Checking If and How a Feature or Component is Currently Installed on page 387
and Checking If and How a Feature or Component Will Be Installed by This
Installation on page 387.
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.
See also:
For examples of where the Conditions field appears, see Where Can You Use
Conditions? on page 380.
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 run time based on system configuration, such as ScreenX
and ScreenY. For information on Windows Installer properties, see Property
Reference in the Windows Installer SDK Help.
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 box.
5. Click in the condition list box after the equals sign and enter a value.
6. Click OK.
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 box while creating the action (brackets required).
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 box. For information
on available environment variables, consult Microsoft Windows developer
documentation.
5. Click in the condition list box after the equals sign and enter a value.
6. Click OK.
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.
See WiseFixConditions on page 383.
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.
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.
See WiseFixConditions on page 383.
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 that are 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 at run time based on user
input, system configuration, or other situations.
Properties are set by the following methods and in the following order:
Included in the Some properties are included in all installations you create
installation database in Windows Installer Editor. These include required Windows
Installer properties, properties that are used on the
installation dialog boxes, 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.
Created by you in the You can create properties in the Properties icon in Setup
installation database Editor > Product tab. Also, some dialog boxes that contain a
property drop-down list also contain a New button with
which you can create a new property.
Because each method of setting properties can be overridden by the methods that come
after it, property values might change during installation. 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.
See also:
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 box. Double-click
the radio buttons and the Next button, to view their Properties dialog boxes.
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.
Example: In Setup Editor > Dialogs tab, right-click a dialog box name, and select
Details. The Dialog Details dialog box appears with [ProductName] [_WiseDialogSuffix]
in the Dialog Title.
Example: To force or suppress a restart at the end of installation, you could create a Set
Property custom action that sets the Windows Installer property named REBOOT.
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
Windows Installer SDK Help.)
Value
Enter an initial value for the property.
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 478.
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.
3. Click OK.
You can also create a new property from any dialog box 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.
Warning
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 box controls or
conditions that reference the property name.
About Dialogs
You can select, edit, and rearrange dialog boxes 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 dialog boxes.
For most installations, the Dialogs page provides all the options that are needed for
selecting and editing dialog boxes. The Dialogs tab in Setup Editor contains advanced
tools for editing the appearance as well as the behavior and logic of installation dialog
boxes.
z Dialogs page
(Installation Expert) The dialog boxes on the Dialogs page are those in the Welcome
Dialog Wizard, which appear to the end user during a normal installation. Turn the
dialog box boxes on or off, rearrange them, view conditions, and select the dialog
box theme. Click the Dialog Editor button to display a dialog box on the Dialogs tab.
z Dialogs tab
(Setup Editor) Edit any dialog boxes in the installation and create new dialog boxes.
The Dialogs tab shows all dialog boxes that are part of an .MSI. Any of these dialog
boxes 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.
See also:
z If you add certain features to your installation, corresponding dialog boxes are
added.
z If you create an installation based on a certain template that has special dialog
boxes. (Example: The Server Application template contains the SQL Connection
dialog.) You select the installation template in the New Installation File dialog box.
Welcome dialog
License dialog See Importing Text into License and Readme Dialogs on
page 397.
Readme dialog See Importing Text into License and Readme Dialogs on
page 397.
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
Product ID field does not appear to the end user if the
ProductID property (select Product tab > Properties
icon) is set to none.
See also:
The Dialogs page looks different based on the version of the Wise product that the
current installation was created in. If the installation was created in Wise for Windows
Installer 6.0 or later, or Windows Installer Editor 5.5 or later, or any version of Wise MSI
Editor, it has more options, which are documented below. If the installation was created
in earlier versions, it has fewer options and contains a Convert button.
z In Setup Editor > Dialogs tab, clear the check box next to Welcome Dialog
Wizard.
Conditions field, but this is not recommended. Most of the Windows Installer properties
referenced in conditions are documented in the Windows Installer SDK Help.
Warning
Changing themes might delete dialog box customizations in installations that were
created in previous versions of this Wise product. To preserve dialog box customizations,
leave None selected in Default Theme.
Select No Graphics to omit top or side images from dialog boxes. Use this
option to minimize the size of an installation that is always run silently.
The dialog box in the Preview pane displays the new theme.
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.
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.
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 subdirectory
varies.
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 box. 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 box next to the Set Font
button.
The Title Font settings control the font for the title of all dialog boxes 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 dialog boxes that have a side image.
The Main Font settings control the font for the rest of the text on the dialog
boxes. You cannot edit the font of individual sections of a dialog box from the
Edit Themes dialog box.
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 box title or of any individual sections of
dialog box text, use Setup Editor > Dialogs tab.
See Basic Control Settings on page 404.
If you change one or more themes on the Edit Themes dialog box, and then click OK, all
the changes are saved, but if you click Cancel, all the changes are canceled.
This button is available only when you select the License or Readme dialog boxes.
The text is imported into the dialog box 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 dialog boxes.
The Dialogs tab contains a Layout menu, a right-click menu, and a toolbar that let you
add new controls to dialog boxes, edit existing controls, and organize dialog box
content.
z To expand or collapse a selected dialog set’s children, use the right-click menu.
Warning
If you are using the Installation Types page to manage the Installation Types dialog box,
you cannot change any details on the Installation Types dialog box. Doing so causes the
Installation Types page not to work properly.
z In Setup Editor > Dialogs tab, clear the check box next to Welcome Dialog
Wizard.
Because of limitations with Windows Installer, do not place dialog box 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 run time.
2. Select Layout menu > Add, and then select the type of control to insert. If the
controls in the Add menu are unavailable, click the dialog box 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 box appears so you
can configure the control’s properties, position, and attributes. For information on
each tab of the Properties dialog box, see:
4. Use other commands on the Layout menu to help organize and arrange the new
controls.
z Setup Editor > Dialogs tab: Right-click the name of a dialog box in the left pane,
and select Details.
z Installation Expert > Dialogs page: Select the dialog box and click the Details
button.
Warning
If you are using the Installation Types page to manage the Installation Types dialog box,
do not change any details on the Installation Type dialog box. Doing so causes the
Installation Types page not to work properly.
z Dialog Title
Enter the title of the dialog box. You can include an installation property in the title
by enclosing it in square brackets. Example: [ProductName] inserts the name of the
product at run time.
z X and Y Centering
Enter X and Y values from 1 to 100 to indicate where on the screen the dialog box
should be centered. Values of 50 in both fields mean that the dialog box should be
exactly centered on the screen. If the Y Centering value is set to 33, the center of
the dialog box will be 1/3 of the way from the top of the screen.
z Visible
Mark this to make the dialog box visible.
z Minimize Button
Mark this to add a minimize button.
z Error Dialog
Mark this if the dialog box is an error dialog box. The property named ErrorDialog
determines which specific dialog box is called if errors occur during installation. The
dialog box must contain a text control named ErrorText to receive the contents of
the error message. An installation can contain only one error dialog box.
z Modal
Mark this if the dialog box should be modal, which means the dialog box is the front
window of the installation until the end user clicks OK or Cancel. The end user
cannot access other windows or dialog boxes of the installation until the modal
dialog box is dismissed.
z Keep Modeless
Mark this if non-modal dialog boxes that are displayed when this dialog box appears
should remain on the screen.
Note
If you get details for the Custom Property dialog box, an Edit button appears on the
Dialog Details dialog box. This lets you change the Windows Installer properties for the
Custom Property dialog box.
Select Setup Editor > Dialogs tab. In the left pane, right-click where the new
dialog box should appear, and select New > Dialog.
OR
Note
The dialog box templates that appear are in Wise Standard.msi, which is stored in
\Templates\Dialogs. To make additional dialog boxes available in each new
installation, open Wise Standard.msi and add the dialog boxes to the All Dialogs
branch on the Dialogs tab.
The location of the Templates subdirectory varies.
See Installation Resources and Their Locations on page 29.
3. Edit any values by clicking the item in the Type column and then clicking Edit.
This page lets you change any properties the new dialog box inherits from the
template. Example: Each dialog box must have a unique name. The wizard assigns
a unique name to the new dialog box by appending a number to the template’s
name, but you might want a more descriptive name.
If you added the Custom Property dialog box, the Select Custom Properties page
appears, where you can select properties that can be set by the end user during
installation.
The Select Installation Placement page appears, which differs slightly based on what
version of Windows Installer Editor the current installation was created in.
Read about the Convert button in Using the Dialogs Page on page 395.
5. Specify where in the sequence the new dialog box should appear.
If Move Up and Move Down buttons appear, use them to move the new dialog
box within the list.
If they do not appear, then you must select a dialog box in both the After and
Before columns. The new dialog box will appear after the dialog box you select
in After, and before the dialog box you select in Before.
6. Click Finish to add the new dialog box to the dialog box list.
Now you can add and edit controls on the dialog box.
See:
dialog box controls often have an associated property. The result from the dialog box
control is put into the property. To have a dialog box control be deselected by default,
associate the control with a property whose value is not defined (null).
Example:
Suppose you create a check box, and you want the check box to be initially cleared. In
the Properties dialog box for the check box, 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 check box 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 check box, you use a condition
that consists of the property’s name, that is, CHECKBOX1. If the check box was not
marked, the value of the property remains null, and therefore CHECKBOX1 is false. If
the check box was marked, its value is now non-null, and therefore CHECKBOX1 is true.
Billboard A static field that defines the area of the dialog box where a
sequence of text and images is displayed during installation
The end user can select one value from the list.
Listview Displays a single column of values with an icon next to each
The end user can select one value from the list.
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
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.
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
Volume Combobox Lets the end user select a volume for installation
2. Double-click a control.
A multi-tabbed Properties dialog box appears. The tabs that appear vary depending
on the type of control. See:
To see the results of these settings, compile and run the installation.
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 check box
is associated with a property whose value is not defined (null), the check box 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.
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
box. Example: If you mark this check box for an OK button on a dialog box, 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 box.
Example: If you mark this check box for a Cancel button on a dialog box, 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 dialog boxes. 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 control within the dialog box. 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 box.
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 box.
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 box has three radio buttons and a check box. The radio
buttons set the property RADIO to FIRST, SECOND, or THIRD. The check box also
uses the property RADIO but has the Indirect check box marked. The property
FIRST, SECOND, or THIRD is set to the check box state based on the setting of the
radio button.
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
Tries 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 & (ampersand) 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
(Check Boxes 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 box.
z Droplist
Makes the control display a drop-down list rather than a multi-line selection list.
z Windows 95 Style
Displays the control using a Windows 95 appearance.
z Elevation Shield
Adds the Windows Vista shield icon (User Account Control elevation icon) to a
pushbutton control.
Use events to control the display of other dialog boxes, and to control the way Windows
Installer displays dialog boxes. When an event is generated (either by a dialog box
control or by Windows Installer) it is published. The published event is sent to Windows
Installer and to all dialog box controls that have subscribed to it.
Publish events
The top section of the Events tab lists the events published by the control.
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 box appears, where you
set the following options:
z Event
Select the event to be published. See the following in the Windows Installer SDK
Help:
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.
Subscribe to events
The bottom section of the Events tab lists the events accepted by the control.
When you click Add or Details, the Subscribe Event Details dialog box 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:
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.
Note
The Help tab is not available for radio button controls. Instead, enter tooltip help for
radio button controls in the Help Text field on the Radio Button Details dialog box,
which you access from the Items tab.
z Tooltip
A short phrase that appears when the end user points to the control and pauses.
This is also used by screen reading programs.
When you click Add or Details, the Control Condition Details dialog box 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.
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.
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 three items to it. Then on another dialog box, you make a listview
control and associate ITEM_LIST with it. If you view the Items tab for the listview
control, it contains the same items as for the radio button.
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 box, double-click
each item and set its Y coordinate.
When you click Add or Details, a details dialog box 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 Help Text
A short phrase that appears when the end user points to the control and pauses.
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 dialog boxes.
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.
To prevent unexpected control layering, set the dialog box’s tab order to include any
graphic or control that is overlapped by another control. The higher the item is in the tab
order, the closer to the top layer it will be.
Example: On the sample dialog box shown below, the image covers most of the dialog
box, and is overlapped by text and check box controls. Because the graphic and static
text controls are not included in the tab order, they might be layered over the check box
control at run time.
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.
3. Select Layout menu > Center in Form > and then select one of the following.
Vertically. Center within the top and bottom edges of the dialog box.
Horizontally. Center within the left and right edges of the dialog box.
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.
Width.
Height.
Both.
To prevent unexpected control layering, set the dialog box’s tab order to include any
graphic or control that is overlapped by another control. The higher the item is in the tab
order, the closer to the top layer it will be.
This is unavailable unless you set the focus on the dialog box 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 box, 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 box 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:
The billboard The billboard defines the area of the dialog box where a
sequence of text and images is displayed. The billboard
is like a screen on which bitmaps, icons, or text controls
are projected.
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.
Bitmap/Icon/Text control Bitmap, icon, or text controls are associated with a
billboard control, and you place them inside the
billboard area.
z The dialog box 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 box directly instead of within a billboard.
Windows Installer does not support the display of billboards outside installation dialog
boxes.
2. In the left pane, select the Progress dialog under Install Dialogs.
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 box and select Add > Billboard. On the Properties dialog box
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.
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
during installation.
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 box. You can only see their
content items, which you add in the next step.
Right-click the dialog box and select Billboards > BillboardControlName, where
BillboardControlName is the name of the control. This makes the control active.
Right-click the dialog box, select Billboards > Add Control, and select Bitmap,
Icon, or Text.
A properties dialog box 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 408.
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 box 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.
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 89.
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.
Although this dialog box 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 box (Installation Expert > Services page).
See also:
(In the Wise editor) To create a new installation that contains the
Logon Information dialog box
1. Select File menu > New.
4. In Setup Editor > Dialogs tab, select the Logon Information dialog and edit the
dialog box text as needed to communicate its purpose to the end user who installs
your application.
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 box text as needed to communicate its purpose to the end user who installs
your application.
2. Right-click on a dialog box under the Welcome Dialog Wizard and select New >
Dialog.
3. On the Select Dialog Type dialog box, select Logon Information and click Next.
5. Edit the dialog box text as needed to communicate the purpose of the user account
to the end user who installs your application.
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 box, 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 box. There is no mechanism for the end
user to skip this part of the installation.
z Do not use this dialog box to capture logon information to be used in a SQL Server
connection string on the SQL Server Scripts page; the Microsoft SQL Server logon
mechanism prevents this from working.
See also:
z Let the end user select a SQL Server name and security credentials to generate a
valid SQL Server connection string.
When the end user completes the SQL Connection dialog box 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 box only validates the connection string; it cannot verify that
the user has permission to execute all SQL statements in a SQL script.
z The ODBC SQL Server driver must be on the destination computer for this dialog
box 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 200.
z The Browse button appears on the SQL Connection dialog box 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 box 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 box for each
additional server, edit the additional dialog boxes, and use a different property for
each connection string.
See Editing Additional SQL Connection Dialogs on page 419.
See also:
(In the Wise editor) To create a new installation that contains the SQL
Connection dialog box
1. Select File menu > New.
4. In Setup Editor > Dialogs tab, select SQL Connection Dialog and edit the dialog box
text as needed to communicate its purpose to the end user who installs your
application.
3. In the Templates list, select Server Application Project and click Open.
4. In Setup Editor > Dialogs tab, select SQL Connection Dialog Box and edit the dialog
box text as needed to communicate its purpose to the end user who installs your
application.
2. Click Add.
5. Edit the dialog box text as needed to communicate its purpose to the end user who
installs your application.
See also:
2. On the Dialog Properties dialog box of the New Dialog Wizard, edit the dialog box’s
default control properties.
From: To:
WiseSqlServerName WiseSqlServerName1
WiseSqlAuth WiseSqlAuth1
WiseSqlUser WiseSqlUser1
WiseSqlPass WiseSqlPass1
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.
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 also:
This dialog box does not appear in any installation by default, and must be added
through the New Dialog Wizard.
Warning
Do not add more than one Custom Property dialog box to a single installation; only one
per installation is supported. If an installation contains multiple Custom Property dialog
boxes, then multiple, identical dialog boxes appear to the end user at run time.
2. Click Add.
3. On the Select Dialog Type page, select Custom Property Dialog and click Next.
4. Leave the defaults on the Dialog Properties page and click Next.
The Select Custom Properties page 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.
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 box.
The Custom Property dialog box now appears in the list of dialog boxes on the Dialogs
page. When you run this installation, the Custom Property dialog box appears.
3. Click Details.
The Edit Custom Properties dialog box appears, where you can change the properties.
Warning
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.
Each new file you start in Windows Installer Editor has Macros.wbs attached. When you
open the Macro dialog box, you can attach a different macro file.
z Event macros that run when you fire the corresponding event.
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
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.
See also:
To create a macro
1. Do one of the following:
Macro Is Run
Select:
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.
6. To create another macro, select Script menu > Add New Macro, enter a name for the
macro on the dialog box that appears, write the macro, and save it.
To edit a macro
1. Do one of the following:
If the macro is in a file other than the one shown in Pathname, browse to the file’s
location.
4. Click Edit.
If the macro is in a file other than the one shown in Pathname, browse to the file’s
location.
4. Click Run.
See also:
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:
Options Opens the Script Editor Options dialog box, where you
set and change the appearance of a script
Object View Shows all macros you have written for a particular
object
Full Module View Shows all macros you have defined for both Windows
Installer Editor events and general functions
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
installation 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 made
since you last saved.
There are two 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.
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 have used the
debugger to test the installation, use Windows Installer Editor 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 also:
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.
You can customize the debugger window by rearranging the panes. Any changes you
make to the panes are retained the next time you run the debugger program. Use the
right-click menu in the Actions, Properties, Condition Evaluator, and Log panes for these
additional options:
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 the pane.
z Hide
Remove the selected pane from the screen. To restore the pane, select it in the View
menu.
2. Click the Debug button 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.)
The installation is saved and compiled if you made changes since the last compile.
You are prompted to select an .MSI if you defined more than one release. The
debugger window opens.
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.
5. To stop the installation, select Debug menu > Stop Debugging or click Cancel in the
installation’s user interface.
Examples:
For more information on using Windows Installer command-line options, search for
“Command-Line Options for the Microsoft Windows Installer Tool Msiexec.exe” in the
MSDN Library (msdn.microsoft.com/library).
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.
To clear a breakpoint
Click an action with a breakpoint and press 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.
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 Windows Installer Editor.
When you change a setting in an installation dialog box, 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.
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 opening a Web page or
downloading a file from a Web site.
Windows Installer Editor uses custom actions to add functionality that is not available
with the Windows Installer standard actions. When you use certain features, such as
custom actions that call a .DLL, Wise custom actions are added to the installation.
Warning
Removing Wise custom actions might cause problems with the installation.
See also:
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.
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.
Installer installation you create, but each mode is run only under certain circumstances.
Installation modes are not used with merge modules.
For information on dialog box groupings, see About Dialogs on page 392.
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 page, the
installation runs in maintenance mode (Maintenance Dialogs), which provides options to
modify, repair, or uninstall an application.
Administrative Installation
Select this installation mode to edit the sequences that are run during an administrative
installation.
See also:
Advertisement Installation
Select this installation mode to edit the sequences that are run during an advertisement
installation.
To run an advertisement installation, use the command-line option /j. Example: msiexec
/j “C:\path\Sample.msi”.
If the action does not have these tabs, then you cannot add it outside a sequence.
6. Click OK.
If the action does not have these tabs, then you cannot add it to multiple
sequences.
This tab provides another way to perform tasks that you normally perform in the
User Interface, Execute Immediate, or Execute Deferred sequences.
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 480.
9. Click OK.
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 445.
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 box.
For information on Windows Installer sequence tables, see Using a Sequence Table in
the Windows Installer SDK Help.
In the Visual Studio integrated editor, you cannot select an installation mode, because
the standard Visual Studio Find dialog box 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 377.
See also:
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:
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.
Display Dialog actions are not displayed on either the Standard or Custom tab. To add a
dialog box, use Setup Editor > Dialogs tab. After you add a dialog box, it appears in MSI
Script as an action.
For information on these dialog boxes, see Custom Action Reference on page 451.
If you double-click Display Dialog actions, the dialog box opens in Setup Editor > Dialogs
tab. To move an action, select Move Up or Move Down from the Edit menu.
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 434.
See also:
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.
z To reactivate commented lines, select them again and select Comment a second
time.
In Visual Studio: Edit menu > Advanced > Uncomment Selection.
Note
If the main Windows Installer installation is run silently, a called WiseScript is called
silently.
WiseScript Editor is embedded within Windows Installer Editor and appears when you
create a custom action that calls a WiseScript.
For information on these actions, see About WiseScript Actions in the WiseScript Editor
Help.
See also:
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 path. Put the path 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 path. 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):
Example: Your application comes in two 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.
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.
The sample WiseScript looks like this (the script lines are numbered for clarity):
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.
4. Add a Run WiseScript From Installation custom action and set the following:
Command Line: Leave this blank. On the Properties tab, leave the defaults.
The above script lines install CorePlus, which in this example is A.dll. In the
following script lines, you make provisions for the uninstall.
7. Add an Execute Program From Destination custom action and set the following:
The MSI script looks like this (the script lines are numbered for clarity):
Variable: MAINDIR
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.
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.
The sample WiseScript looks like this (the script lines are numbered for clarity):
Even if you have coded an installation to bypass the UAC prompting, the installation
might fail if it contains WiseScript custom actions. When the Windows Vista or later
operating system encounters a WiseScript .EXE, it interprets that .EXE as an installation
and triggers User Account Control.
To prevent UAC prompting on the WiseScript custom action, add a manifest to the
WiseScript to indicate its run level. In Wise Installation Express 7.0 SP1 or later, the
manifest is added automatically and the run level is set to asInvoker, which runs the
WiseScript as the user who runs the .MSI.
z If you create the WiseScript in WiseScript Package Editor, go to Installation Expert >
Build Settings page and set the manifest file option to asInvoker or specify a custom
manifest file.
a. Windows Installer Editor checks for custom actions that run a WiseScript.
d. If the WiseScript .EXE had an associated row on the Windows Installer Editor
Resources page, the Refresh check box for that resource is cleared so that the
.EXE on disk is not used during the next compile.
2. In WiseScript Editor, open each WiseScript .WSE from its original location and
recompile.
3. In Windows Installer Editor, go to Installation Expert > Resources page and re-select
the Refresh check box for each WiseScript .EXE.
See also:
Warning
Although you can change the order and conditions for standard actions and dialog
boxes, 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.
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.
Note
The User Account Control (UAC) that was introduced with Windows Vista affects the
execution of custom actions that access protected areas on the destination computer.
You might need to elevate part or all of the installation to prevent the failure of such
custom actions.
See About UAC Elevation of Windows Installer Installations on page 183.
Correct Sequence
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.
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.
See Conditions on page 380 and Conditional Statement Syntax in the Windows Installer
SDK Help.
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).
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 box 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.
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 two custom
actions. Set the first custom action to call the nested installation, and set its condition to
NOT Installed (Custom Action Location dialog box). Set the second custom action to call
the nested installation also, set its Property Settings field to REMOVE=ALL (Custom
Action Target dialog box), 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 a WiseScript product, use a Run WiseScript custom
action. To call an installation that was created with any other installation technology, use
an Execute Program custom action type.
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.
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
To write your .DLL function according to Windows Installer guidelines, see the following
topics in the Windows Installer SDK Help:
Dynamic-Link Libraries
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.
z You authored the .DLL and have its source code on your computer.
z You are using one of the Call Custom DLL custom action types.
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.
3. Create a new custom action and configure it normally, but mark No Sequence on
the Location tab.
4. In Setup Editor > Dialogs tab, right-click a dialog box 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 box, 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 box:
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 box. When the
end user clicks the button, the custom action you specified is run.
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 trying to change restricted public properties? The ability to do this
depends on several factors.
See Restricted Public Properties in the Windows Installer SDK Help.
z Using the Custom Action Location Tab for Merge Modules on page 480
For technical details on custom actions, see Custom Actions in the Windows Installer
SDK Help.
For help using the MSI Script interface, see The MSI Script Window on page 432.
Tips
z You can send a variable parameter list to the .DLL.
z Because .DLLs are processor-specific, the .DLL that you call must target the same
platform (32-bit, x64, or 64-bit Itanium) as the installation. In a mixed-target
project file (.WSI), condition each Call Custom .DLL custom action for the
appropriate platform. Example: Your .WSI contains a 32-bit release, an x64 release,
and an Itanium release. You add three Call Custom .DLL actions to the project: one
to call ABC32.dll, one to call ABCx64.dll, and one to call ABCItanium.dll. Place each
custom action inside a condition block that checks for the appropriate platform.
For a tutorial that demonstrates this custom action, refer to the 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 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.
[SystemFolder]user32.dll
z 64-bit
Mark this if you are calling a 64-bit .DLL from a 64-bit installation.
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 Returned Property
Type or select a property name. The return value of the function call will be put into
this property.
In the Execute Immediate or User Interface sequences only, you can send Windows
Installer properties to the .DLL function as parameters.
See also:
Tips
z You can send a variable parameter list to the .DLL.
z Because .DLLs are processor-specific, the .DLL that you call must target the same
platform (32-bit, x64, or 64-bit Itanium) as the installation. In a mixed-target
project file (.WSI), condition each Call Custom .DLL custom action for the
appropriate platform. Example: Your .WSI contains a 32-bit release, an x64 release,
and an Itanium release. You add three Call Custom .DLL actions to the project: one
to call ABC32.dll, one to call ABCx64.dll, and one to call ABCItanium.dll. Place each
custom action inside a condition block that checks for the appropriate platform.
z Manage the .DLL on the Resources page, which reflects the Binary table.
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 DLL File
Specify a .DLL from your hard drive or local network to call during installation.
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 Returned Property
Type or select a property name. The return value of the function call will be put into
this property.
In the Execute Immediate or User Interface sequences only, you can send Windows
Installer properties to the .DLL function as parameters.
See also:
Tips
z You can send a variable parameter list to the .DLL.
z Because .DLLs are processor-specific, the .DLL that you call must target the same
platform (32-bit, x64, or 64-bit Itanium) as the installation. In a mixed-target
project file (.WSI), condition each Call Custom .DLL custom action for the
appropriate platform. Example: Your .WSI contains a 32-bit release, an x64 release,
and an Itanium release. You add three Call Custom .DLL actions to the project: one
to call ABC32.dll, one to call ABCx64.dll, and one to call ABCItanium.dll. Place each
custom action inside a condition block that checks for the appropriate platform.
z Before you add this custom action, add the file to be called to the Files page in
Installation Expert.
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
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 DLL File
Specify a .DLL file to call during installation. It must have already been added to this
installation.
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 Returned Property
Type or select a property name. The return value of the function call will be put into
this property.
In the Execute Immediate or User Interface sequences only, you can send Windows
Installer properties to the .DLL function as parameters.
See also:
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:
Double-click one of the Call Custom .DLL actions in MSI Script and click the Add button.
Then complete the DLL Parameter Details dialog box:
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 with NULL value, the value of NULL is passed
regardless of the parameter type, so Not applicable is displayed for the
parameter type.
See also:
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
Double-click the custom action and complete the Details tab:
z DLL File
Specify a .DLL from your hard drive or local network to call during installation.
z Function Name
Type the name of the function within the .DLL file to call.
See also:
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.
z Before you add this custom action, add the file to be called to the Files page in
Installation Expert.
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.
Usage
Double-click the custom action and complete the Details tab:
z DLL File
Specify a .DLL file to call during installation. It must have already been added to this
installation.
z Function Name
Type the name of the function within the .DLL file to call.
See also:
Tips
z The script is limited to 255 characters; use other JScript custom actions for longer
scripts.
Usage
Double-click the custom action and complete the Details tab:
See also:
Tips
z Manage the file on the Resources page, which reflects the Binary table.
Usage
Double-click the custom action and complete the Details tab:
z Script File
Specify a script file from your hard drive or local network to call during installation.
See also:
Tips
z Before you add this custom action, add the file to be called to the Files page in
Installation Expert.
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.
Usage
Double-click the custom action and complete the Details tab:
z Script File
Specify a script file to call during installation. It must have already been added to
this installation on the Files page.
See also:
Tips
z The script is limited to 32 Kb, which is the size limit for Windows Installer properties.
Usage
Double-click the custom action and complete the Details tab:
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.
See also:
Tips
z The script is limited to 255 characters; use other VBScript custom actions for longer
scripts.
Usage
Double-click the custom action and complete the Details tab:
See also:
Tips
z Manage the file on the Resources page, which reflects the Binary table.
Usage
Double-click the custom action and complete the Details tab:
z Script File
Specify a script file from your hard drive or local network to call during installation.
See also:
Tips
z Before you add this custom action, add the file to be called to the Files page in
Installation Expert.
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.
Usage
Double-click the custom action and complete the Details tab:
z Script File
Specify a script file to call during installation. It must have already been added to
this installation on the Files page.
See also:
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
Double-click the custom action and complete the Details tab:
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.
See also:
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 check box on a dialog
box. You would associate the check box with a property and then set up a condition
to check if the property was true.
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 445 and Formatted in the
Windows Installer SDK Help.
Usage
Double-click the custom action and complete the dialog box:
z Message Title
Enter text to be displayed in the title bar of the message.
z Message Text
Enter the text to be displayed in the message dialog box. Press Ctrl+Enter to add
line breaks in the displayed text.
z Message Icon
Select an appropriate icon for your message dialog box.
See also:
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.
z If you place this action in the User Interface or Execute Immediate sequences, you
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
Double-click the custom action and complete the dialog box:
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.
See also:
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.
See also:
For a tutorial that demonstrates this custom action, refer to the Getting Started Guide.
Usage
Double-click the custom action and complete the Details tab:
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.
(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.
See also:
Usage
Double-click the custom action and complete the Details tab:
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.
See also:
Tips
z Before you add this custom action, add the file to be called to the Files page in
Installation Expert.
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.
Usage
Double-click the custom action and complete the Details tab:
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 unavailable for this custom action.
See also:
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
Double-click the custom action and complete the Details tab:
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.
See also:
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 also:
Tips
z The installation being called must already be advertised or installed on the
destination computer.
z On the Properties tab, In-Script Options is unavailable 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
Double-click the custom action and complete the Details tab:
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.
ADVERTISE=ALL
REMOVE=ALL
For a list of properties, see Property Reference in the Windows Installer SDK Help.
See also:
Tips
z Manage the .MSI on the Resources page, which reflects the Binary table.
z On the Properties tab, In-Script Options is unavailable 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
Double-click the custom action and complete the Details tab:
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
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.
ADVERTISE=ALL
REMOVE=ALL
For a list of properties, see Property Reference in the Windows Installer SDK Help.
See also:
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
z This custom action is not available in an Administrative Installation.
z On the Properties tab, In-Script Options is unavailable 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
Double-click the custom action and complete the Details tab:
z Installation to Run
Enter the relative path 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
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.
ADVERTISE=ALL
REMOVE=ALL
For a list of properties, see Property Reference in the Windows Installer SDK Help.
See also:
In Web Page URL on the Launch Web Page dialog box, designate the URL to open
during installation. The URL must be complete. Example: http://www.symantec.com.
See also:
Tips
z Before you add this custom action, add the file to be called to the Files page in
Installation Expert.
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.
See also:
Pause Installation
This custom action temporarily stops a sequence from executing. After the specified
number of seconds, the sequence continues running.
Usage
Double-click the custom action and complete the dialog box:
z Seconds to Pause
Number of seconds for the sequence to pause.
See also:
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).
z If you place this action in the User Interface or Execute Immediate sequences, you
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 445 and Formatted in the
Windows Installer SDK Help.
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 check box the user
marks to accept posting of data. Associate the check box with a property and set up
the conditional block to run if the property is true.
To create a condition, use an If Statement.
Usage
Double-click the custom action and complete the dialog box:
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 two 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.
See also:
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.
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 the WiseScript documentation.
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
Double-click the custom action and complete the Details tab:
z Options button
This is unavailable 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. For a list of valid command-line options, see the
WiseScript documentation.
See also:
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 the WiseScript documentation.
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.
z Manage the file you specify on the Resources page, which reflects the Binary table.
Usage
Double-click the custom action and complete the Details tab:
z Options button
z Command Line
(Optional) Enter the command-line options to send to the .EXE. Example: Enter /s
to make the WiseScript run silently. For a list of valid command-line options, see the
WiseScript documentation.
See also:
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 the WiseScript documentation.
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.
z Before you add this custom action, add the file to be called to the Files page in
Installation Expert.
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.
Usage
Double-click the custom action and complete the Details tab:
z Options button
z Command Line
(Optional) Enter the command-line options to send to the .EXE. Example: Enter /s
to make the WiseScript run silently. For a list of valid command-line options, see the
WiseScript documentation.
See also:
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.
For a tutorial that demonstrates this custom action, refer to the 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
unavailable for this custom action.
Usage
Double-click the custom action and complete the Details tab:
z Directory
Specify the directory to change the value of. It must be a directory you 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
See also:
On the Set Feature State dialog box, 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.
See also:
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
unavailable for this custom action.
Usage
Double-click the custom action and complete the Details tab:
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.
See also:
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,
which begins with an If Statement.
Tips
z This custom action has restrictions on its placement, indicated by shaded areas in
the Installation Sequence.
Usage
Double-click the custom action and complete the Details tab:
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.
See also:
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.
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.
Click Add to add the custom action to the sequence below the action you
selected.
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 also:
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.
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 also:
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 Windows Installer SDK Help.
Note
The In-Script Options drop-down list is unavailable 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
unavailable 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 unavailable, because those two sequences always
run in immediate execution. This action will be executed during the first pass that
Windows Installer makes 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 unavailable.
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
Windows Installer SDK Help.
Note
User context and system context are relevant only on locked-down 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 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.
The Windows Vista Logo Program requires you to document every custom action in an
installation. The Windows Vista Compatibility Checks validation module in Package
Validation includes a check for custom action descriptions. If you plan to certify an
installation for Windows Vista or later operating system, use the Description tab to
document custom actions.
This requirement applies to the Wise custom actions as well as the ones you add. For
information you can use to document Wise custom actions, see Wise Custom Actions on
page 493.
To obtain a report of each custom action and its description, select Reports menu >
Custom Actions.
Windows Installer Editor is an authoring environment for the Microsoft Windows Installer
service. Although a comprehensive discussion of Windows Installer is not possible here,
it is important that you understand some basic concepts about Windows Installer and
how Windows Installer Editor supports it.
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.)
Windows Installer Editor is an installation authoring application for creating and editing
Windows Installer database files. When you build an installation in Windows Installer
Editor, you populate tables within a Windows Installer database file. The Windows
Installer Editor user interface exposes the functionality offered by Windows Installer.
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.
See Setting Build Options for a Release on page 199 and Adding Prerequisites to a
Release on page 200.
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 running a shortcut, opening a file with an advertised file extension, or by
accessing any other entry point.
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 Windows Installer Editor 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 Windows Installer Editor, as a reference for coding
Windows Installer functionality into an application.
See also:
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:
See also:
About GUIDs
GUID stands for globally unique identifier. It is a data type comprised of a text string
that represents a Class identifier (ID).
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.
Warning
Do not try to create a GUID by typing random hex characters.
See also:
Windows Installer Editor simplifies the process of creating installations for .NET
applications, automating the process by extracting most of the installation details from
your assemblies.
See also:
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.
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 run time, the common language
runtime marshals data between COM objects and managed objects as needed.
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 two 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 stand-alone file or it can be incorporated into one of the PE files in the
assembly.
When you add a .NET assembly to an installation, Windows Installer Editor creates
entries in the MsiAssembly and MsiAssemblyName tables.
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.
.NET applications that use shared assemblies, or that have a mix of managed and
unmanaged code, cannot be installed with XCOPY. You should use the Windows Installer
service for installations that do any of the following:
z Require security
z Create a shortcut
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.
If the .NET Framework is installed on your computer, Windows Installer Editor can
automate the process as follows:
z Find all files in multifile assemblies and add them to the installation.
z Determine attributes for registering the assembly files and add them to the
MsiAssemblyName table.
See also:
See Creating a .NET Installation Without the .NET Framework on page 237.
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:
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 122.
3. For assemblies that are to be installed into the Global Assembly Cache or WinSxS,
generate publicKeyTokens and sign the assemblies.
See also:
Windows Installer Editor uses custom actions to add functionality that is not available
with the Windows Installer standard actions. When you use certain features, such as
custom actions that call a .DLL, Wise custom actions are added to the installation.
Warning
Removing Wise custom actions might cause problems with the installation.
The Windows Vista Logo Program requires you to document every custom action in an
installation. This applies to the Wise custom actions as well as the ones you add. If you
plan to certify an installation for the Windows Vista or later operating system, use the
information in the following table to document the Wise custom actions.
You document the custom actions on the Description tab that appears on the details
dialog box for all custom actions.
See also:
When User Account Control is disabled, the option to install for all users or
for the current user on the installation’s User Information dialog box is
hidden. If the installation has User Account Control disabled, but is run on a
version of Windows Installer earlier than 4.0, then that option on the User
Information dialog box is shown. This is the default behavior for earlier
versions of Windows Installer.
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 dialog boxes based on the
destination computer.
z Populates the list of existing Web sites that appears on the Web dialog
boxes when installing to an existing site.
z PrimaryVolumePath
z PrimaryVolumeSpaceAvailable
z PrimaryVolumeSpaceRequired
z PrimaryVolumeSpaceRemaining
DiagnosticCheckDotNet Determines if .NET is required by this installation.
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 run 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.
DiagnosticCheckLaunchCondition Determines which launch conditions succeed and which fail. It enumerates
the LaunchCondition table and evaluates the condition using the
MsiEvaluateCondition API function.
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 valid 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.
DiagnosticOpenDocExtChec 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.
Diagnostic Payload Installed 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.
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).
PopulateVirDirs Populates the list of existing virtual directories for a given site when
installing to an existing virtual directory.
SetARPINSTALLLOCATION Sets the ARPINSTALLLOCATION property to the value of INSTALLDIR.
Caution
If this custom action appears in an installation, do not remove or move it.
WiseFindSqlClientTools Sets the property WiseOsqlCmd to the command line to run the Osql tool.
WiseFirewallInfo Gathers information about the Windows Firewall during installation on
Windows XP SP2, Windows Server 2003 SP1, and later.
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.
Wise tables contain information that is related to items you added in Windows Installer
Editor. Most of these tables do not appear in the compiled .MSI, unless noted otherwise
or unless you use an .MSI file as the project file.
Some of the tables listed below are available in certain Wise products only.
Warning
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.
See also:
It describes the files in the file table that are mobile device
files.
WiseModuleConfiguration Contains the information that configurable merge modules
use during the merge process
WiseModuleSignature Contains a list of merge modules that are in the installation
project file
WisePageLists Contains information on the page groups of the page view
associated with the installation
WisePathReplacement Yes In combination with Wise custom actions, enables conversion
of registry path values that contain long file names or trailing
backslashes
WisePathVariable Contains paths that are defined on the Path Variables page.
WisePocketPCFile Contains information about each file for a Pocket PC
application
WisePocketPCPlatform Contains information about each platform that the user
selects on the Support Platform dialog box for a Pocket PC
application
Properties are variables that are used by Windows Installer during installation. This
section lists Windows Installer properties.
See also:
Build Properties
Properties that are defined by settings in an installation at build time are listed below.
Some of them, such as INSTALLLEVEL, can be changed at run time from the command
line or during the Action Sequence. You also can create new properties for your own use.
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.
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.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the ProductVersion property in the INI file that’s generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the AdminError property in the .INI file that’s generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the CmdLine property in the .INI file that’s generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the ExistError property in the .INI file that’s generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the WiseInitLangDefault property in the .INI file that’s
generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the WiseInitPrefix property in the .INI file that’s generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the ProductName property in the .INI file that’s generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the SpaceError property in the .INI file that’s generated.
If an installation creates an .EXE that launches an .MSI, this property sets the
default value for the WiseInitSuffix property in the .INI file that’s generated.
See also:
Some of the properties in the .INI file get their default values from the build properties.
See individual descriptions below to determine which build property the .INI property
takes its default from, if any.
See also:
See Setting SQL Connection Strings on page 240 and Adding the SQL Connection Dialog
to an Installation on page 418.
See also: