other countries. Other names may be trademarks of t heir 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 E XTENT THAT SUCH DISCLAIMERS ARE HELD T O BE LEGALLY INV ALID . SYMANTE C 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
Windows Installer Editor Reference2
Technical Support
Symantec Technical Support maintains support centers globally. Technical Support’s
primary role is to respond to specific queries about product features and functionality.
The Technical Support group also creates content for our online Knowledge Base. The
Technical Support group works collaboratively with the other functional areas within
Symantec to answer your questions in a timely fashion. For example, the Technical
Support group works with Product Engineering and Symantec Security Response to
provide alerting services and virus definition updates.
Symantec’s maintenance offerings include the following:
zA range of support options that give you the flexibility to select the right amount of
service for any size organization
zTelephone and/or web-based support that provides rapid response and up-to-the-
minute information
zUpgrade assurance that delivers software upgrades
zGlobal support purchased on a regional business hours or 24 hours a day, 7 days a
week basis
zPremium service offerings that include Account Management Services
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.
Contacting Technical Support
Customers with a current maintenance agreement may access Technical Support
information at the following URL:
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:
zProduct release level
zHardware information
zAvailable memory, disk space, and NIC information
zOperating system
zVersion and patch level
zNetwork topology
zRouter, gateway, and IP address information
zProblem description:
Error messages and log files
Windows Installer Editor Reference3
Troubleshooting that was performed before contacting Symantec
Recent software configuration changes and network changes
Licensing and registration
If your Symantec product requires registration or a license key, access our technical
support Web page at the following URL:
www.symantec.com/business/support/
Customer service
Customer service information is available at the following URL:
www.symantec.com/business/support/
Customer Service is available to assist with non-technical questions, such as the
following types of issues:
zQuestions regarding product licensing or serialization
zProduct registration updates, such as address or name changes
zGeneral product information (features, language availability, local dealers)
zLatest information about product updates and upgrades
zInformation about upgrade assurance and maintenance contracts
zInformation about the Symantec Buying Programs
zAdvice about Symantec’s technical support options
zNontechnical presales questions
zIssues that are related to CD-ROMs or manuals
Support agreement resources
If you want to contact Symantec regarding an existing support agreement, please
contact the support agreement administration team for your region as follows:
Asia-Pacific and Japancustomercare_apac@symantec.com
Europe, Middle-East, and Africasemea@symantec.com
North America and Latin Americasupportsolutions@symantec.com
Additional enterprise services
Symantec offers a comprehensive set of services that allow you to maximize your
investment in Symantec products and to develop your knowledge, expertise, and global
insight, which enable you to manage your business risks proactively.
Enterprise services that are available include the following:
Windows Installer Editor Reference4
Managed ServicesManaged services remove the burden of managing and
monitoring security devices and events, ensuring rapid response
to real threats.
Consulting
Services
Educational
Services
To access more information about Enterprise services, please visit our Web site at the
following URL:
www.symantec.com/business/services/
Select your country or language from the site index.
Symantec Consulting Services provide on-site technical
expertise from Symantec and its trusted partners. Symantec
Consulting Services offer a variety of prepackaged and
customizable options that include assessment, design,
implementation, monitoring, and management capabilities. Each
is focused on establishing and maintaining the integrity and
availability of your IT resources.
Educational Services provide a full array of technical training,
security education, security certification, and awareness
communication programs.
zAbout Windows Installer Editor on page 17
zStarting the Software on page 18
zThe Product Interface on page 18
zAbout Visual Studio Integration on page 19
zUsing Installation Expert on page 20
zUsing the Task List on page 26
zUsing a Wise Package Studio Repository on page 29
zInstallation Resources and Their Locations on page 32
zGenerating Package Contents Reports on page 33
zDownloading Redistributable Files on page 34
zDownloading Redistributable Files on page 34
zProduct Documentation on page 36
About Windows Installer Editor
Windows Installer Editor is an installation development tool for creating and editing
Windows® Installer (.MSI) installation packages. It is a complete and user-friendly front
end for generating Windows Installer database files, which are executed by the Windows
Installer engine.
With Windows Installer Editor, you can:
zCreate installations that are compliant with the Microsoft Windows 2000, XP, and
Vista logo program.
zEdit and refine installations that you have converted from other formats.
zImport development projects.
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.
Microsoft® Windows® Installer is a Microsoft technology that provides a standard
installation engine that can be used for the installation of any 32-bit or 64-bit Windows
application. It resides on the destination computer and performs the installation of
applications. Windows Installer technology provides features that are not available in
traditional installation-building products (examples: self-healing and install-ondemand).
Windows Installer Editor is included with Wise Installation Studio.
Windows Installer Editor Reference17
Starting the Software
To start the software
1. Select Start menu > Programs > Symantec > Wise Installation Studio > Windows
Installer Editor.
2. Select File menu > New.
The New Installation File dialog box appears.
3. Complete the dialog box:
a. In the Categories list, click Predefined Templates.
b. In the Templates/Tools list, click the Windows Application icon.
The Windows Application icon lets you create a standard installation. You can
create other types of installations.
See Starting a New Installation on page 78 and Options for New Installations on
page 84.
c.In the File type section, specify the type of file to create.
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.
Introduction
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.
See Creating an Installation for Standard Users on page 80.
f.Click OK.
The new installation opens.
See also:
Creating an Installation Within a Solution on page 80
The Product Interface
Windows Installer Editor has the following views, each of which provides you with a
different development environment.
Installation ExpertInstallation 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.
Windows Installer Editor Reference18
See Using Installation Expert on page 20.
Introduction
MSI ScriptMSI Script provides a powerful yet easy-to-use environment
for editing Windows Installer installation sequences. A
sequence is a set of actions that are performed during a
particular type of 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.
See About MSI Script on page 491
Setup EditorSetup Editor is a powerful view of the installation, and using
its advanced features requires proficiency in the Windows
Installer development environment or in software
development. Set up Editor lets you create fully customized
interactive installations. Certain advanced tasks can be
performed only in Setup Editor.
See About Setup Editor on page 413.
To navigate between views, click the navigation tabs at the lower left of the main
window.
Additional Interfaces
zThe Tools menu contains powerful tools that perform specialized functions.
See About Windows Installer Editor tools on page 391.
zThe Compile, Test, Debug, and Run buttons let you test and compile the installation.
See Compiling An Installation on page 97, Testing and Running An Installation on
page 98, and About the Debugger on page 487.
zYou can use Windows Installer Editor from within Visual Studio.
See About Visual Studio Integration on page 19.
About Visual Studio Integration
You can use Windows Installer Editor from within Visual Studio. The Visual Studio
integrated editor lets you create all the same installation file types that y ou create in the
stand-alone Wise editor. The Wise editor and Visual Studio integrated editor are different
interfaces for the same product; they share the same preferences, recently-used file
lists, dialog box templates, themes, and installation templates. (The Visual Studio
integrated editor was formerly sold separately as Wise for Visual Studio .NET.)
There are several differences between the Wise editor and the Visual Studio integrated
editor that are inherent in the Visual Studio development environment.
Examples:
zIn the Visual Studio integrated editor, you have different choi ces about how to start
a new project, and you can set source paths to update automatically according to
the Visual Studio build configuration.
Windows Installer Editor Reference19
Introduction
zIn the Visual Studio integrated editor, installations synchronize automatically with
the other projects in the solution. Example: adding .EXEs, .DLLs, .OCXs, and
assemblies to the solution adds them to the installation.
zInstallation meta data fields (examples: application name, version, manufacturer,
and default directory) are populated using data from the Visual Studio solution.
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. Y ou can set an option on this dialog box to alw ays
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
How the Installation Integrates With the Solution on page 90
Using Installation Expert
To access Installation Expert, click Installation Expert at the lower left of the Windows
Installer Editor main window.
Windows Installer Editor Reference20
Page Views
Introduction
Installation Expert window in Windows Installer Editor
Page Groups
Page Area
View Navigation
Compile and Test
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.
zUse on the toolbar to navigate from page to page, or click the page name in
the list of pages.
zTo display help for the current page, press F1.
zTo 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.)
Windows Installer Editor Reference21
Compiling and Testing
Compile, Test, Debug, and Run buttons test and compile the installation.
In Visual Studio: These buttons are not available, but the same functionalit y is a v ailable
through menu commands.)
See also:
Using the Current Release Drop-Down List on page 25
Using the Current Feature Drop-Down List on page 24
About Page Views
A page view is a set of Installation Expert page groups and pages that you select from
the Page Views drop-down list. Select a page view to display only specific page groups
and pages.
Types of Page Views
zPredefined page views that display the groups and pages most frequently used for a
Introduction
particular type of installation. The All page view displays all page groups and pages.
The Merge Module page view appears for all merge modules. You cannot edit or
delete predefined page views.
zCustom page views that you create to meet your specific needs.
See Customizing Page Views on page 23.
zPage views that are created when you create an installation template. You cannot
delete these page views.
See Creating and Editing Installation Templates on page 54.
The page views are arranged alphabetically in the Page Views drop-down list with the
exception of the All page view, which is always first. The list also includes <New View...> and <Customize Page Views...>, which are at the end of the list and are
used to create or customize page views.
Predefined Templates and Page Views
Most predefined installation templates have an associated page view. When you create a
new installation by using one of these templates, the page view that is associated with
that template becomes the default page view of the installation. When you open the
installation, this page view appears in the Page Views drop-down list.
You can select a different page view from the list at any time, 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.
Custom Templates and Page Views
When you create a custom installation template, a page view is created with the same
name and is listed in the Page Views drop-down list.
Windows Installer Editor Reference22
Introduction
See Creating and Editing Installation Templates on page 54.
When you use a template to create an installation, the default page view is the page
view that was displayed when the template was created. If the template’s default page
view is a custom page view, you can customize it.
See Customizing Page Views on page 23.
(Requires a repository connection.) You can share page views that are associated with
an installation template because the page view is stored in the template, which is
located in the share point directory.
Which Page View Appears?
zThe Display the page view associated with a project when a project is
opened check box in Wise Options determines what page view appears. 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 Setting Installation Expert Options on page 47.
zThe 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:
Using Installation Expert on page 20
Customizing Page Views
You can create customized Installation Expert page views that display only the page
groups and pages that you use most often. You can customize the page view of custom
installation templates or create customized page views that are not associated with a
template. Y ou cannot customiz e the p redefined page views, but y ou can mak e a copy of
a predefined page view and then customize it.
When you customize a page view, you can specify how many page groups appear, what
the group names are, and what pages appear under each group.
Customized Page Views dialog box
Buttons to edit page groups
and pages are unavailable
when a predefined page
view is selected in Page View Name.
These pages appear under
the group selected in Page Groups.
Windows Installer Editor Reference23
The page groups appear on
the left side of Installation
Expert.
Introduction
To create a page view
1. From the Page Views drop-down list in Installation Expert, select <New View...>.
The Enter Name dialog box appears.
2. Enter a name for the page view.
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.
4. To copy the page groups and pages of an existing page view:
a. Click Copy View. The Copy View dialog box appears.
b. Select the page view to copy and click OK.
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.
To customize a page view
1. From the Page Views drop-down list in Installation Expert, select <Customize
Page Views...>.
The Customize Page Views dialog box appears.
2. Select the page view from Page View Name, and do any of the following:
To add a new page group, click the Page Groups Add button and enter a name.
To rename a page group, select the page group and click Rename.
To add a page to a page group, select the page group and click the Add button
to the right of Page Names. 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.
3. Click OK on the Customize Page Views dialog box.
To delete a page view, select it from Page View Name and click the top Delete button.
See also:
Using Installation Expert on page 20
Using the Current Feature Drop-Down List
The Current Feature drop-down list appears on pages in the Feature Details page
group. When it appears, you can set options on a per-feature or per-condition basis. You
add features and conditions on the Features page, then select a feature from Current Feature before setting options on other pages.
Windows Installer Editor Reference24
Introduction
Current Feature drop-down list
Example: Suppose you have three features, an d 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.
The All Features (Modify/Delete only) option in Current Feature displays
information for all features at once. (Example: On the Files page this option displays all
folders and files for all features.) Add and New buttons are unavailable while all features
are displayed; you must select a single feature to add items.
On some pages, Current Feature also contains numbers in parentheses, which
represents the number of that page’s items (files or registry keys) that are assigned to
each feature or condition.
See also:
Using the Current Release Drop-Down List on page 25
Using Installation Expert on page 20
Using the Current Release Drop-Down List
The Current Release drop-down list appears on pages in the Release Definition page
group. When it appears, you can set options on a per-release basis by selecting a
feature from Current Release and then setting options on that page.
Current Release drop-down list
A release is a special version of your application. Example: a 30-day evaluation release
for evaluators. Use Current Release to configure separate settings, media, and
language options for each release.
See also:
Windows Installer Editor Reference25
Using Installation Expert on page 20
Using the Current Feature Drop-Down List on page 24
Using the Task List
When Windows Installer Editor encounters installation issues that could cause problems,
it displays them in the Task List. You can manually display or hide the Task List from the
View menu.
The Task List gathers all installation issues into one place, and makes it easy to analyze
their causes. If the issue is caused by an error in a table, you can quickly jump from the
Task List to the row in the table that caused the error.
See Finding Table Errors From the Task List on page 28.
When you resolve the issue that corresponds to a task, the task is del eted 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.
How Tasks are Added to the Task List
zSave or Compile
If errors occur when you save or compile an installation, the errors are displayed in
the Task List.
Introduction
zPackage 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.
See Package Validation on page 404.
zCheck Tables
When you check tables, the installation is sea rch ed for com ponent and table errors
and results are placed in the Task List. To check tables, sel ect Setup Editor > Tables
tab, right-click in the left pane and select Check Tables.
See Finding Validation Errors on page 435.
zUser-Defined
You can add user-defined tasks to the task list.
See Adding User-Defined Tasks on page 28.
(Not available in the Visual Studio integrated editor.)
zMeta Data
(Requires a repository connection.) When you create an .MSI or .WSI, a task is
added to remind you to add the package meta data to the Software Manager
database by filling in the Application and Package fields on the Product Details
page.
Note
When you close an installation, all tasks, except user-defined tasks, are removed from
the Task List. (In the Visual Studio integrated editor, user-defined tasks are not
available.)
Windows Installer Editor Reference26
Introduction
Task List Icons
The following icons help you quickly identify the types of tasks in the Task List:
An error that will cause incorrect behavior and must be fixed
Validation issues found by Package Validation
See Validating a Package on page 404.
A task you created
If you have a repository connection, this icon also appears with a
task that reminds you to add the package meta data to the
Software Manager database.
Operations you can perform in the Task List
zFilter tasks by type.
See Filtering the Task List.
zFind table errors.
See Finding Table Errors From the Task List on page 28.
zSort a Task List column by clicking its header.
zCopy a task’s description by right-clicking its description.
zDelete a task by right-clicking its description.
Filtering the Task List
To filter the task list
1. Right-click in the Task List and select Show Tasks.
2. Select a filter. (In Visual Studio: right-click in the Visual Studio Task List and select
Show Tasks.)
Save/Compile
Validation
Component
Table
(In Visual Studio: this is called Build Errors.) Tasks that correspond to errors
that are generated when you save or compile.
Tasks that correspond to issues that are generated during Package Validation.
Tasks that correspond to component errors that are generated when you check
tables.
See Using the Task List on page 26.
Tasks that correspond to table validation errors that are generated when you
check tables.
Windows Installer Editor Reference27
See Using the Task List on page 26.
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.
Finding Table Errors From the Task List
If a task is associated with a table, you can access that table directly from the Task List,
which helps you discover the problem that caused the issue.
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 u nexpected, undesirable
behavior, including damage to the installation. We cannot provide technical support for
problems arising from table editing.
Introduction
To find table errors from the Task List:
If the task has a table listed in the Table column, double-click the task. The table is
displayed in Setup Editor > Tables tab, and the row in the table associated with the task
is highlighted.
In Visual Studio: a table is displayed only if a table is associated with the task.
If you need more information, check the task’s description or press F1 to display the
help topic for the selected table in the Windows Installer SDK Help.
See also:
Tables Tab on page 430
Using the Task List on page 26
Adding User-Defined Tasks
¾ Not available in the Visual Studio integrated editor.
You can add tasks to the Task List. Example: Add user-defined tasks to define work that
must be completed on the installation. Tasks you add to the Task List are saved with the
installation. You can only add user-defined tasks to a .WSI; you cannot add them to an
.MSI.
To add a user-defined task
1. On the first line of the T ask Li st, click Click here to add a new item twice and type
the task.
If Click here to add a new item does not appear in the Task List, save the
installation file and it will appear.
Windows Installer Editor Reference28
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:
Using the Task List on page 26
Using a Wise Package Studio Repository
¾ Requires a repository connection.
You can connect to a Wise Software Repository that has been configured for an
installation of Wise Package Studio 8.0 or later. To do so, use the Repository Client
Manager.
See Connecting to a Wise Software Repository on page 65.
Use information in the Wise Software Repository to develop consistent, accurate, and
high quality applications and installations:
Introduction
Improve Applications During Development and Testing
zUse the Wise Software Repository to mirror y our producti on e nvi ronm ent. The Wise
Software Repository™ is a collection of resources, and information about those
resources, for internally developed and third-party applications.
To import and manage information in the Wise Software Repository, use Software
Manager.
See About Importing Packages in the Software Manager Help.
zUnderstand how the application will behave in the production environment so you
can identify and resolve potential conflicts during the application’s development.
Check each file and registry key you add to an installation for possible conflicts
with those in other applications. Example: A developer who adds or updates a
.DLL to an installation can instantly view a list of other applications that use that
.DLL and the versions used. The developer can use this inform ation to ensure
that the new application uses the correct version of the .DLL and therefore will
not break existing applications.
See Viewing Shared File Resources on page 152 and Viewing Shar ed R egistry
Resources on page 170.
View the file and registry resources that are shared among applications in the
target environment so you can identify potential problems.
See Generating Shared Resource Reports on page 31.
Collaborate on and Standardize Installation Development
zShare installation resources to enforce organizational standards and maintain a
consistent look and feel across your installations. Example: Develop a set of
common component rules to ensure that every installation will be organized the
same way.
You can share the following resources:
Windows Installer Editor Reference29
Component rules
Introduction
Custom actions
Dialog boxes and dialog box themes
Languages
Merge modules
Installation templates
Validation modules
Other resources (bitmaps and icons that are used in installations)
See Setting Repository Options on page 50.
zAdd a file to an installation from the Wise Software Repository, to ensure that you
use the correct versions of file resources in applications you develop.
See Adding Files From the Wise Software Repository on page 133.
zUse merge modules that are in the Wise Software Repository, to help ensure that
developers always access approved versions of merge modules.
See Setting Merge Module Directories on page 48 and Adding a Merge Module to an
Installation on page 381.
Reduce Repackaging Efforts
If your organization also uses Wise Package Studio, connecting Wise Installation Studio
to a repository eliminates the need to repackage internally developed applications,
because the organization’s developers can create installations that adhere to corporate
standards. It also reduces rework of internally developed installations by the
development team and reduces end-user downtime, because the developers who create
installations can be sure to use the correct versions of files and other resources before
giving installations to the IT deployment team.
See also:
About the Share Point Directory on page 30
About the Wise Software Repository in the Software Manager Help
About the Share Point Directory
¾ Requires a repository connection.
When you connect to a Wise Software Repository that has been configured for an
installation of Wise Package Studio, you can use and share installation resources that
are in the share point directory.
Share Point Directory Contents
zResources that are used to create Windows Installer installations. Examples:
installation templates, component rules, language files, and so on.
zTemporary .QUE files representing packages that have been distributed but not
imported into the Software Manager database.
zSource files of installations you import into the Software Manager database.
zInformation that is unique to Wise Package Studio.
Windows Installer Editor Reference30
Deleting Files From the Share Point Directory
Warning
Do not edit or delete the contents of the share point directory or its subdirectories
outside Windows Installer Editor or other Wise tools. Doing so will cause problems in
Wise Package Studio and can result in loss of data.
A common question is “Can I clean up the share point by deleting unused source files?”
The answer is no. It is too difficult to know which files are safe to delete.
The only recommended way to delete files from the share point directory is to delete the
entire package from the Software Manager database. When you do so, you can delete
the package’s source files from the share point subdirectories (000, 001, and so on), if
those files are not referenced by any other application. Do this from Software Manager
in Wise Package Studio.
See also:
Installation Resources and Their Locations on page 32
Using a Wise Package Studio Repository on page 29.
Generating Shared Resource Reports
Introduction
¾ Requires a repository connection.
The following shared resource reports provide a quick way to review the resources that
are shared by the current installation and other packages in the Software Manager
database.
zShared Files Report
Lists the files that are shared by the current installation and packages in the
Software Manager database. For each file, the report lists each application that uses
the file and shows detailed file information (examples: version, date/time, path, and
so on).
zShared Registry Report
Lists the registry keys that are shared by the current installation and packages in
the Software Manager database. For each registry key, the report lists each
application that uses the registry key and shows t he key valu e.
The reports are displayed in HTML format. The .XSL templates used to format these
reports are in the Templates\Reports subdirectory of this product’s installation directory.
You can customize the .XSL templates to supply branding information, to filter data, or
to transform the data to another format.
To generate a shared resource report
1. Select Reports menu and select either Shared Files or Shared Registry.
(In Visual Studio: Project menu > Reports > Shared Files R eport or Shared R egistry
Report.)
The Welcome dialog box appears.
2. In Data Source, specify the Software Manager database that contains the
resources you want to review. If the Software Manager database you want is not
listed, click Open to select it.
Windows Installer Editor Reference31
3. From Group, select the group that contains the packages to compare this
installation to.
4. Click Next.
The report is generated and displayed in the Shared Files Report or Shared Registry
Report dialog box.
You can save the or print the report from this dialog box. Saving to HTML is
available only on computers that contain MSXML.DLL, which is included in Internet
Explorer 5.x and higher.
5. When you finish reviewing, saving, or printing the report, click Finish.
See also:
Connecting to a Wise Software Repository on page 65
Installation Resources and Their Locations
Windows Installer Editor uses various resources to create installations. (Example:
installation templates, component rules, language files, and so on.) Most of these
resources are installed with this product. Others must be created and placed in the
appropriate directory before they can be used.
Introduction
These resources are in subdirectories of the Windows Installer Editor installation
directory.
If you have a repository connection, these directories are still present under the
installation directory; however, the resources are used from subdirectories of the share
point directory instead. Several of these directories are available only on the share
point, and only if you have a repository connection.
The share point directory also contains subdirectories that are specific to the Wise
Package Studio Workbench.
You can specify alternate locations for storing resources.
See Setting Repository Options on page 50.
DirectoryContents
Custom ActionsFiles that you create to use in custom actions, such as WiseScripts, VBScripts, .DLLs,
and so on, that you use in Windows Installer installations.
LanguagesLanguage resource files that are used to change the language of installations.
Merge ModulesThe default merge modules directory is Program Files\Common Files\Merge
Modules\Wise Solutions. This is the default target location for downloading merge
modules, and the default directory from which you select merge modules to add to an
installation. If you have a repository connection, you can change the default merge
modules directory to the Merge Modules subdirectory of the share point directory.
Reports(Requires a repository connection.) Predefined reports (.RPT) that are used in
Software Manager. Also contains the Report.ini file, which stores information about
the predefined reports and about any report customizations.
ProjectsThe default location for new installations that you create.
ResourcesInstallation resources such as bitmap and icon files.
Windows Installer Editor Reference32
Introduction
DirectoryContents
TemplatesMacros and additional template files that are used by Package Distribution.
Templates\DialogsThe Wise Standard.MSI that provides information that is used by the New Dialog
Wizard to add a new dialog box to an installation.
Templates\FileTemplates that are used to create a new installation. If you have a repository
connection, you must create this subdirectory under the share point directory. It is
not created when the share point is created.
See Creating and Editing Installation Templates on page 54
In the Visual Studio integrated editor, these templates create installations that are
not associated with a Visual Studio solution. The Visual Studio integrated editor
cannot use templates from the share point directory. It must use templates on the
local computer.
Templates\Project(Visual Studio integrated editor only.) Templates that are used to create an
installation as a project within a Visual Studio solution. These templates are not
available from the share point directory.
Templates\ReportsTemplates 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.
ThemesThemes.ini, which stores information about themes you have added or customized.
Also contains subdirectories that store the images for each theme.
ValidationPredefined validation modules (.CUB files) that are used by Package Validation.
See also:
Using a Wise Package Studio Repository on page 29
Connecting to a Wise Software Repository on page 65
About the Share Point Directory on page 30
Generating Package Contents Reports
Package contents reports provide an overview of the contents of an installation file and
make it easy to provide this information to end users. The following reports are
available:
zPackage Contents Summary
Lists detailed information for every resource in an installation, including files,
registry keys, shortcuts, file associations, and merge modules. You can generate
this report for .WSI, .MSI, .WSM, and .MSM files.
zPackage Contents By Feature
Contains the same information as the Package Contents Summary report, but
arranges it by feature. You can generate this report for .WSI and .MSI files.
To generate a package contents report
1. Select Reports menu > Package Contents and select either Summary or By F eature.
In Visual Studio: Project menu > Reports > Package Contents and select either
Summary or By Feature.
2. The report is generated and opens in a dialog box.
Windows Installer Editor Reference33
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.
Downloading Redistributable Files
The Download Redistributables wizard, available from the Help menu, lets you obtain
merge modules, Windows Installer runtime installers, and .NET Framework runtime
installers. You need the Windows Installer runtimes if y ou decide to pre-install Windows
Installer with an installation. You need the .NET Framework if you are creating an
installation that contains .NET elements. Because of size and obsolescence
considerations, these files are distributed through the Internet.
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.
Download redistributable files from the following locations:
Introduction
Wise Web SiteSelect and download one or more redistributables from the
Wise Web site.
See Downloading Redistributables From the Wise Web Site
on page 34.
Other Vendors’ Web
Sites
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.
Select and download a redistributable from a third-party
vendor’s Web site. Available redistributables are authored
by the respective vendor, and you need to contact the
vendor for information or help on these redistributables.
See Downl oading Redistributables From Other Vendors’ Web
Sites on page 35.
Downloading Redistributables From the Wise Web Site
You must be in an active Wise installation to follow this procedure.
To download redistributables from the Wise Web Site
1. Select Help menu > Download Redistributables.
In Visual Studio: Help menu > Wise Help > Download Redistributables.
The Source Location dialog box appears.
2. Mark Wise Web Site and click Next.
A Download Files dialog box appears while all available redistributable files are
retrieved. The Available Redistributable Files dialog box then appears.
3. From Redistributable Type, select the type of redistributable to download.
Windows Installer Editor Reference34
Introduction
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.
See Setting Merge Module Directories on page 48.
The selected redistributables are downloaded from the Internet.
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:
Downloading Redistributable Files on page 34
Downloading Redistributables From Other Vendors’ Web Sites
You must be in an active Wise installation to follow this procedure. We have no control
over other vendor’s redistributable files. Check with the ve nd or for product support.
To download redistributables from other vendors’ Web sites
1. Select Help menu > Download Redistributables.
In Visual Studio: Help menu > Wise Help > Download Redistributables.
The Source Location dialog box appears.
2. Mark Other Vendors’ Web Sites and click Next.
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.
See Setting Merge Module Directories on page 48.
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:
Windows Installer Editor Reference35
Downloading Redistributable Files on page 34
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.
Use the following sources of information to learn about this product.
Online Help
The online help contains detailed technical information and step-by-step instructions for
performing common tasks.
Access help in the following ways:
zTo display context-sensitive help for the active window or dialog box, press F1.
zTo select a help topic from a table of contents, index, or search, select Help menu >
Help Topics.
zIn Visual Studio, select Help menu > Wise Help > Help Topics.)
Reference Manual
Introduction
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.
Getting Started Guide
The Getting Started Guide contains system requirements, installation in structions, and a
tutorial. You can access a .PDF version of the Getting Started Guide from the Windows
Start menu.
Windows Installer SDK Help
You can get technical details about Windows Installer from its own help system, which is
written by Microsoft for a developer audience. In Wise for Windows Installer, select Help
menu > Windows Installer SDK Help.
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. T o access the release not es, select Release
Notes from the Symantec program group on the Windows Start menu.
Windows Installer Editor Reference36
Chapter 2
Setting Up
This chapter includes the following topics:
zHow you can set up Windows Installer Editor on page 37
zSetting Options on page 37
zCreating and Editing Installation Templates on page 54
zComponent Rules on page 57
zConnecting to a Wise Software Repository on page 65
How you can set up Windows Installer Editor
Before you create and edit installations, set up Windows Installer Editor to reflect your
organization’s standards:
zSet options that control the installations you create and determine the installation
resources you use.
See Setting Options on page 37.
zDecide whether you need to customize the templates that installations are based
on.
See Creating and Editing Installation Templates on page 54.
zDecide 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 57.
zYou can connect to a Wise Software Repository that has been configured for an
installation of Wise Package Studio.
See Connecting to a Wise Software Repository on page 65.
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:
Setting General Options
Windows Installer Editor Reference37
Setting .NET Assembly Options on page 40
Setting Advertising Options on page 41
Setting Digital Signature Options on page 43
Setting ExpressBuild Options on page 44
Setting Installation Expert Options on page 47
Setting Merge Module Directories on page 48
Activating Suppressed Prompts on page 49
Setting Repository Options on page 50
Setting Source Control Options on page 51
Setting Visual Studio Options on page 52
Setting Wildcard Groups on page 54
Setting General Options
To set general options, select Tools menu > Options and click the General tab.
In Visual Studio: Tools menu > Options > Wise Options > General.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
Setting Up
Automatic Options
zCreate 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.
zAdd default remarks to installation sequences
Although most Wise project (.WSI) files have remarks that explain the actions in the
sequences, compiled .MSIs do not. Mark this to add remarks to the current .MSI and
all .MSIs that you open subsequently. Remarks are added to .WSIs only if no
remarks already exist.
zCreate XML copy during save
Mark this to update a copy of the installation in XML format every time you save. If
a copy does not exist, it is created. The copy has the same name as the installation
file with the extension .XML appended, and it is saved in the same directory.
(Example: If the current file name is Application.wsi, the XML copy is named
Application.wsi.xml.) This lets you check the XML version of the installation into a
source code control system and use text-based file comparison tools to find
changes.
See Saving an Installation as XML on page 95.
Compiler Options
The following options are default settings for all new compiles. Changing these settings
does not affect installations that have already been compiled.
Windows Installer Editor Reference38
Setting Up
zAdd custom actions for predefined folders in merge modules
This affects the merging of merge modules that place files in predefined directories,
such as \Windows, \System32, and so on. Mark this to have the merge emulate the
behavior of the Microsoft merge tool, mergemod.dll, which uses custom actions to
handle predefined directories. Clearing this check box can fix potential problems
with capitalization inconsistencies in the directory name.
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.
zDisplay error if merge modules conflict with main installation rows
Merge module errors occur if a merge module contains a row that has the same key
as a row in the main installation. Clear this to ignore such errors and let the merge
module row overwrite the row in the main installation.
zEnable Quick Compile
Mark this to speed the compile process by compressing only previously
uncompressed or changed files. Quick Compile writes the .MSI table information. If
a file or media has changed, a full compile will occur instead. Quick Compile is for
project files only. You can also speed compile time by using ExpressBuild, a multiprocessor compile feature.
See About ExpressBuild on page 44.
Software Virtualization Options
¾ (Not available in the Visual Studio integrated editor.)
zInstall into virtual layer from Run button
Mark this to install an installation into a virtual layer when you click the Run button.
This creates a new layer, installs the .MSI into the layer, and activates the layer.
After you test the installation, you can delete the layer to restore your computer to
its original state.
See Running An Installation on page 99.
Startup Options
zReload last project at startup
Mark this to open the last installation you worked on when you start Windows
Installer Editor.
Not available in the Visual Studio integrated editor.
zPreferred 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.
Windows Installer Editor Reference39
zRefresh Projects Integrated with Visual Studio .NET
This option appears only if Microsoft Visual Studio is installed. When you open a
project that has been integrated with Visual Studio, this option causes the Visual
Studio solution to be rebuilt so that this installation has the most recent files.
“Integrated” means the project has been added as part of a Visual Studio solution.
(Not available in the Visual Studio integrated editor.)
See also:
Setting Options on page 37
Setting .NET Assembly Options
¾ Windows Installer 2.0 or later only.
You can specif y whether you cre ate standard Wi n32 or .NET installations, and customize
how Windows Installer Editor handles the .NET assemblies.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
Setting Up
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.)
COM Interop Options
zDefault Application Type
This determines the default setting for the Application Type field on the Product
Details page for new installations. Changing this field does not affect existing
installations.
Win 32 (non .NET)
Select this if you typically create standard Win32 installations without .NET
assemblies.
.NET Application
Select this if you typically create .NET installations with only .NET elements.
Mixed (.NET and Win32)
Select this if you typically create installations containing both Win32 and .NET
elements. When this option is selected, .NET assemblies you add to an
installation are registered so that they can be called as though they were COM
components. For information on COM interoperability, search for “Interoperating
with Unmanaged Code” in the MSDN Library (msdn.microsoft.com/library/).
zRescan COM interop registry keys on compile
Mark this to scan and update interop registry keys for .NET assemblies each time
you compile. This check box is available only if the .NET Framework is installed on
your computer.
Windows Installer Editor Reference40
Setting Up
Assembly Scanning Options
The scanning options are available only if the .NET Framework is installed on your
computer.
zScan Dependencies
Specify how dependency assemblies are added to an installation. Y ou 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.
Never scan dependencies
If you select this, you must add dependency assemblies to installations
manually on the Files, Web Files, or Visual Studio Solution page.
Prompt to scan dependencies
When you add a .NET assembly to an installation, Windows Installer Editor
scans its manifest for dependencies and prompts you to select which ones to
add to the installation.
Always scan dependencies
When you add a .NET assembly to an installation, Windows Installer Editor
scans its manifest for dependencies and adds them to the installation.
zRescan assembly dependencies on compile
Mark this to scan for new assembly dependencies each time you compile.
zRescan assembly attributes on compile
Mark this to res can and update assembly attributes each time you compile. This
check box is marked by default.
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). T o
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:
Setting Options on page 37
Setting Advertising Options
You can specify how to gather self-registration and advertising information for files you
add to an installation. Windows Installer considers some kinds of registry entries, such
as file extension definitions, to be advertising information.
See Platform Support of Advertisement in the Windows Installer SDK Help.
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.
Windows Installer Editor Reference41
Setting Up
To set options:
Select T ools menu > Options and click the Adv ertising tab. (In Visual Studio: Tools menu
> Options > Wise Options > Advertising.) Complete the tab.
zAdvertising 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.
This registration method is preferred over self-registration because it does not
depend on the presence of other files on the destination computer, nor does it
depend on how well the .OCX or .DLL file adheres to self-registration conventions.
However, the .OCX or .DLL files must already be registered correctly on your
computer. If you prefer not to register installation files on your computer, you can
run the scan routine as a stand-alone utility on a different computer.
See Using WiseComCapture.exe on page 156.
Do not scan advertising information
Use self-registration for components that support it. Windows Installer Editor
will not scan files or the registry.
Scan advertising information into registry keys
Add advertising information to the installation as registry keys only; do not
create entries in advertising tables. This results in an installation that does not
support advertising through COM.
Scan advertising information into advertising tables
Place registry entries that are considered to be advertising information into
advertising tables. Create registry entries for any information that cannot be
placed in the advertising tables. This results in an installation that supports
advertising.
Scan advertising into both advertising tables and registry
Place registry entries that are considered to be advertising information into
advertising tables and into registry keys. As a result, all advertising information
is included in the installation; none is lost.
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.
zAutomatically add self-registration
Mark this to add self-registration information to the installation whenever you add
an .OCX or .DLL file that supports self-registration. Typically , .OCX and .DLL files are
self-registered dynamically on the destination computer by calling self-registration
functions. If you mark this check box, Windows Installer registers your .OCX and
Windows Installer Editor Reference42
.DLL files. The .DLL or .OCX may require certain files to be installed already i n order
to self-register properly.
Scanning the advertising information into the advertising tables is recommended
over self-registration.
zDefault to rescan advertising for new components
If the advertising information contained in your files might change during the
development process, mark this to scan the advertising information and update the
installation every time you compile. The scan options in the Advertising Setting
field above only read the advertising information that’s present in the file when you
first add it to the installation.
This field sets the default for new components; if you change it, existing
components are not affected. The Rescan advertising information during compile check box on the Component Details dialog box can override this setting
for individual components.
See also:
Setting Options on page 37
Setting Digital Signature Options
Setting Up
You can a dd a digi t al s ign at ure t o an i nst al la tion on the Digital Signature page. You also
can add a digital signature to a patch in Patch Creation.
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.
zSigning with Public/Private Key Pair Files
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.
Private Key File
Enter the path of the private key file (.PVK). If this key is lost or stolen, contact
your certificate authority immediately.
zSigning with Personal Information Exchange Files
Signtool.exe Location
Personal Information Exchange (.pfx) File
Windows Installer Editor Reference43
Enter the path of the signtool.exe that performs the signing tasks.
Enter the path of your Personal Information Exchange file (.PFX).
See also:
Adding a Digital Signature to a Patch on page 341
Adding a Digital Signature to an Installation on page 262
Setting Options on page 37
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.
Setting Up
ExpressBuild speeds compile time by distributing the time-consuming task of
compressing .CAB files among multiple processors. Therefore, the greatest time savings
are realized when you have multiple .CAB files. Specify .CAB file creation rules in
Installation Expert > Media page.
See:
Setting ExpressBuild Options
How ExpressBuild Groups Work on page 45
Requirements for Using ExpressBuild on page 46
Setting ExpressBuild Options
If you turn ExpressBuild on, it is turned on globally; that is, it is in effect for all
installation files you open, regardless of when they were created.
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.
See Requirements for Using ExpressBuild on page 46.
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 m ark any combination of the three check boxes below. After y ou m ark either of
the first two check boxes, compiles will try to use multi-processor compile unless
Windows Installer Editor Reference44
Setting Up
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.
zBuild Using Multiple Local Processors
Mark this to have multiple processors within this computer help process compiles.
The processors on this computer can be physical or virtual processors. You must
also enter the number of local processors in the field below. There are several
requirements for using this option.
Number of Local Processors
Enter the number of physical or virtual processors available on the current
computer.
zBuild Using Multiple Distributed Computers
Mark this to have more than one computer help process compiles. You must have
previously set up a build group to use this option. There are several requirements
for using this option.
Build Group Name
Enter the build group name.
See How ExpressBuild Groups Work on page 45.
Build Group Domain
Enter the NT domain name of the build group. All members of a single build
group must be in the same NT domain.
zAllow My Computer to Build for Others
Mark this to have this computer be available to help proce ss compiles that are
started on another build computer. Performance degrades while this computer helps
to process compiles. This causes WiseExpressBuild.exe to start immediately.
Build Group Name
Enter the group name of the build group that your computer will be a member
of. If another computer compiles using your build group name, then your
processor will be used to help compile.
See also:
About ExpressBuild on page 44
Setting Options on page 37
How ExpressBuild Groups Work
You can specify a build group of computers within the same NT domain or workgroup to
share processing of compiles. T o specify a buil d group, first you select an arbitrary name
for the build group. Then, on those computers that will be part of a build group, you do
one of two things:
zIf Windows Installer Editor is not installed, then run WiseExpressBuild.exe, which is
located in the share point directory. The Wise ExpressBuild dialog box opens.
Specify the group name and whether the WiseExpressBuild.exe should open at
system startup. WiseExpressBuild.exe runs in the background and responds to and
manages compile requests from the build computer. You can open it and edit its
properties by double-clicking on its icon in the Windows taskbar.
zIf 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
Windows Installer Editor Reference45
Setting Up
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:
About ExpressBuild on page 44
Setting ExpressBuild Options on page 44
Requirements for Using ExpressBuild
Requirements for Using ExpressBuild
zIn the following instances, because of .CAB formation issues, multi-processor
compile does not take place and normal compiling occurs:
If you select Uncompressed external files from the Compression Option
field on the Media page.
If you select One Cab in the Cab Options field on the Media page, or if the
.MSI contains only one .CAB for some other reason.
If you select any size other than zero in the Max Media Size field on the Media
page.
If you are in a merge module.
zBecause each processor compresses .CAB files, using multiple p r ocessors 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.
Additional requirements for using the option to Build Using Multiple
Distributed Computers:
zAll the installation source files must be shared so that all members of the build
group have network privileges to access them.
zThe 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.
See Source Paths in an Installation on page 359.
zThe 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
Windows Installer Editor Reference46
browse under the My Computer icon, the path will not be referenced in UNC
notation.
See also:
About ExpressBuild on page 44
Setting ExpressBuild Options on page 44
How ExpressBuild Groups Work on page 45
Setting Installation Expert Options
You can set options that control the behavior of Installation Expert.
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.
Setting Up
In Visual Studio: Tools menu > Options > Wise Options > Installation Expert.
Complete the tab.
zView directories for all features on Files page
Mark this to display all directories on the Files or Visual Studio Solution page,
regardless of what feature the directory was created for.
Clear this to display only the directories that were created for the current feature
(the feature selected in the Current Feature drop-down list.) Example: If you
create a directory for FeatureA, and then use the Current Feature drop-down list
to go to FeatureB, you no longer see the directory you made for FeatureA.
This does not apply to the Web Files page.
zView registry keys for all features on Registry page
Mark this to display all registry keys on the Registry page, regardless of what
feature the registry key was created for. This displays a composite view of all
registry keys created for all features. If this check box is not marked, only keys
created for the currently selected feature (in the Current Feature drop-down list)
are displayed.
zShow merge module components
Mark this to view the files and registry entries from merge modules in Installation
Expert. You can only view merge module components in an .MSI. By default, these
items are hidden.
zListbox Compatibility Mode
If your computer has certain video driv ers, y ou might have problems selecting items
from list boxes within Windows Installer Editor. If items that you select from list
boxes are continually misinterpreted by Windows Installer Editor, mark this check
box to eliminate list box problems.
Windows Installer Editor Reference47
Setting Up
zExpand all features on Features page
Display Feature title instead of name on Features page
Display hidden features on Features page
These check boxes determine how features are displayed on the Features page. You
can override these settings using the right-click menu on that page.
zDisplay 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.
zUse advanced drawing routines (restart required)
If a black box appears at the bottom of the Installation Expert page group list,
cutting off the last several pages in the list, mark this check box and restart your
computer to eliminate the problem.
zDisplay Project Summary Page when a project is opened
Mark this to have the Project Summary page appear when an installation is opened.
See also:
Setting Options on page 37
Setting Merge Module Directories
You can set default directories for storing merge modules.
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.
(Requires a repository connection.) Y ou can use merge modules that are in the Software
Manager database, which helps ensure that developers always access approved v ersions
of merge modules.
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.
See Adding a Merge Module to an Installation on page 381.
Complete the tab.
zDefault Merge Module Directory
Shows the path to the default merge module directory. All merge modules that are
in this directory—along with the merge modules that are in the directories shown in
the Directory list below—are listed on the Select Merge Module dialog box that
appears when you click the Add button at the right of the Merge Modules page.
Windows Installer Editor Reference48
Setting Up
If you have a repository connection, you can change this to the Merge Modules
subdirectory of the share point directory.
To exclude the merge modules in the default directory from the list, mark Do not show merge modules from the Default Merge Module Directory.
zRead Merge Modules List From Software Manager Database
(Requires a repository connection.) Mark this to include merge modules from the
Software Manager database on the Select Merge Module dialog box that appears
when you click the Add button on the Merge Modules page.
zDirectory
Enter additional directories where merge modules are stored. Me rge 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 M erg e Module dialog
box.
See also:
Setting Options on page 37
Activating Suppressed Prompts
Some of the prompts that appear in Windows Installer Editor contain a Don’t show this
message again check box that lets you suppress the prompt in the future.
To reactivate prompts that you previously suppressed
1. Select Tools menu > Options and click the Prompts tab.
In Visual Studio: Tools menu > Options > Wise Options > Prompts.
The dialog box lists the prompts you have suppressed and shows your last respon se
to each prompt. If you have not suppressed any Windows Installer Editor prompts,
nothing is listed.
2. Select the prompt message line and click Activate.
The prompt is removed from the list. The next time you encounter a situation in
which that prompt applies, the prompt will appear.
Note
(Visual Studio integrated editor.) To display context-sensitive help, click the Wise Help
link on this dialog box.
See also:
Setting Options on page 37
Windows Installer Editor Reference49
Setting Repository Options
¾ Requires a repository connection.
Use the Repository tab on the Wise Options dialog box to specify the directories that
contain the resources that are used to create and edit Windows Installer installations.
Typically, you will use the default locations, but you can set alternate locations for
specific resources.
See Installation Resources and Their Locations on page 32.
The Repository tab displays the share point directory that is associated with the
repository, if any, with which you are connected. To connect to a Wise Software
Repository, use the Repository Client Manager.
See Connecting to a Wise Software Repository on page 65.
To change a default resource location
The resource locations are used for Windows Installer installations only.
1. Select Tools menu > Options.
In Visual Studio: Tools menu > Options > Wise Options.
Setting Up
2. On the Wise Options dialog box, click the Repository tab.
3. Click Advanced.
4. On the Repository Advanced Settings dialog box that appears, double-click one of
the following items and browse to a new path.
You can use the variable [WiseSharePoint] to represent the share point directory in
the following paths. You also can use the predefined variables that appear on the
Path Variables page. However, you cannot use other user-defined path variables
because they are specific to a single installation and the following paths are global
options.
Component Rules
Specify the location of ComponentRules.ini, which contains the rules that
govern how components are created in installations.
Warning
If you are sharing component rules, be careful when editing existing rule sets
because your changes will overwrite rule sets used by team members.
Custom Actions
Specify the location in which you will save files used in custom actions
(examples: WiseScripts, .DLL files, JScript files, and VBScript files) that can be
added to installations. This is the default location whenever you browse for a file
on a custom action dialog box.
Default Project Directory
Specify the default directory in which all new installations will be saved. The
default is the Projects subdirectory of the share point directory.
Windows Installer Editor Reference50
Note
Changes in this field do not take effect until you exit and restart the product.
Setting Up
Dialogs
Specify the location of the Wise Standard.MSI that contains information that the
New Dialog Wizard uses to add a new dialog box to an installation.
Languages
Specify the location of language resource files.
Resources
Specify the location of the bitmaps and icons that are used in installations.
Templates
Specify the location of installation templates and WfWI macros.
Note
If you have a repository connection, shared templates must be in the
Templates\File subdirectory of the share point directory. Howeve r, you only
need to specify the top-level Te mplates directory here. Example:
[WiseSharePoint]\Templates.
See Creating and Editing Installation Templates on page 54.
The Visual Studio integrated editor cannot use templates from the share point
directory. It must use templates on the local computer.
Themes
Specify the location of the themes that are used to customize installation dialog
boxes.
Validation Modules
Specify the location of the validation modules (.CUB files) and settings that are
used in Package Validation.
See also:
Connecting to a Wise Software Repository on page 65
Setting Merge Module Directories on page 48
Setting Options on page 37
Setting Source Control Options
¾ Not available in the Visual Studio integrated editor.
You can set options that enable source control functionality and set the levels of
interaction Windows Installer Editor has with your source code control system (SCCS).
See Using Source Control on page 348.
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.
Windows Installer Editor Reference51
Setting Up
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 p roblems betwee n the SCCS serv er and
your computer.
zEnable source control
Mark this to enable all source control functionality both in the current installation
and all future installations. When you mark this check box, the following three check
boxes are enabled, as well as the items in the Source Control menu. When source
control is enabled, you can add files to source control, c heck files in and out, get the
latest version of files, track history, and view differences.
zCheck out file when it is opened
If this is marked, then each time you open a file that has been previously checked
in, the file will be automatically checked out for you. If your source code control
system is not available, you can cancel attempts to connect and work on the local
copy of the file.
zCheck in file when it is closed
If this is marked, then each time you open a file that has been previously checked
out, the file will be automatically checked in for you.
zAdd new files to source control
If this is marked, then each time you create a new installation file and save it, you
will be prompted to add it to your source code control system.
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:
Setting Options on page 37
Setting Visual Studio Options
¾ Visual Studio integrated editor only.
you can set global defaults for the way your installations integrate with Visual Studio
solutions. The Visual Studio options apply only to installations that are integrated with a
Visual Studio solution.
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.
Windows Installer Editor Reference52
Setting Up
Projects Options
To override these defaults for individual installations, or to change them for existing
installations, edit the Projects page of the installation project settings.
See Entering Project Settings on page 85.
zScan 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.
See Scanning the Solution for New Files on page 91.
Specify the default level of scanning that will occur for new installations.
Never scan solution
If you select this, you must add new files to in stallations manually using the
Files page. Also, when files are removed from a solution, you must remove
them from the installations manually.
Prompt only when new files are detected
Select this to be prompted each time there are new files in the solution that
need to be added to the installation. The prompt appears during save, build, or
compile.
Prompt when any files are detected
This is the highest level of prompting. Like the previous option, the prompt
appears during save, build, or compile when there are new files. Also, if you
previously excluded files by clearing their check boxes, you’ll be prompted to
confirm that those files should be excluded.
Always scan solution
Each time Windows Installer Editor scans a solution, it adds new files to the
installation and deletes files that have been removed from the solution.
zBind installed files to the solution build configuration
Mark this to set the default for new projects you create. This option causes the
installation source paths to change automatically when you change a project’s build
configuration. To change this option for an existing project, right-click a project
name in Solution Explorer, and select Properties.
Main Project Options
To override these defaults for individual installations, or to change them for existing
installations, edit the Main Project page of the installation project settings.
See Main Project Page on page 88.
zAutomatically Update Product Information
Mark this to upd ate the instal lation’s product name, version, and manufacturer
whenever you rebuild the solution or whenever the version number of the main
target file changes.
zCreate Shortcut
Mark this to add a shortcut for the main target file to each installation.
See also:
Setting Options on page 37
Windows Installer Editor Reference53
Setting Wildcard Groups
On the Wildcard Groups tab, you can create groups of wildcards so you don’t have to
type multiple wildcards repeatedly.
On the Files and Web Files pages in Installation Expert, you use the wildcard groups
when you add directory contents. Wildcard groups on the Wildcard Groups tab appear in
the Include Wildcards list on the Add Contents and Wildcard Details 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.
To add a wildcard group so it appears in Include Wildcards
1. Select Tools menu > Options and click the Wildcard Groups tab.
In Visual Studio: Tools menu > Options> Wise Options > Wildcard Groups.
Setting Up
2. On the Wildcard Groups tab, click Add.
The Wildcard Group Details dialog box appears.
3. Complete the dialog box and click OK:
Group Name
Enter a name to precede the wildcards in the Include Wildcards list. This is a
visual identifier to help you quickly find the wildcards in the list.
Wildcards
Enter semi-colon delimited wildcards. (Example: Enter *.EXE;*.DLL for all .EXE
and .DLL files. A ? represents any one character.)
Later, when you add contents or set automatic updating on the Files or Web Files page,
this wildcard group is available from the Include Wildcards list.
See also:
Setting Options on page 37
Creating and Editing Installation Templates
When you create a new installation or merge module, it gets its configuration from a
template file. Templates contain logical defaults and commonly used settings. Some
template files are predefined and appear when you create a new installation. You also
can create your own templates.
Example: If all your installations have the same system configuration requ irements and
document file extensions, you can create a template with these changes preconfigured.
Windows Installer Editor Reference54
Setting Up
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.
Template Location in the Wise Editor
Templates are in the Templates\File subdirectory of the Windows Installer Editor
installation directory.
See Installation Resources and Their Locations on page 32.
If you have a repository connection, you can share templates by placing them in the
Templates\File subdirectory of the share point directory. If a template is not in that
location, the template on the local computer is used. Typically, you should only place
customized templates in the share point and leave the predefined templates on the local
computer.
The File subdirectory is not created by default when the share point is created. A user
with permission to create directories on the share point must create it.
Template Location in the Visual Studio Integrated Editor
Templates are organized by integrated project and stand-alone files:
zTemplates\Project contains templates for new projects that are integrated with a
solution.
zTemplates\File contains templates for stand-alone files.
The Visual Studio integrated editor cannot use templates from the share point directory
even if you have a repository connection. It must use templates on the local computer.
To create a custom template in the Wise editor
1. Select File menu > New.
The New Installation File dialog box appears.
2. Select a template file on which to base the new template and click OK. Only icons
that have a correspo nding file i n the Templates directory are templates; other icons
cannot be used to create or edit templates.
A new installation or merge module opens.
3. Make all the changes that should appear in installations that will be created with this
template.
4. T o include a description that will appear on the New Installation File dialog box when
you click this template:
a. Select Setup Editor > Product tab.
b. Click the Summary icon.
c.In the upper-right pane, double-click Comments.
d. On the Summary Details dialog box that appears, enter a description of this
5. Save the file:
a. Select File menu > Save As.
Windows Installer Editor Reference55
template in Value and click OK.
Setting Up
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.
See Customizing Page Views on page 23.
6. To test the new template, select File menu > New.
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.
7. Select the template you just created and click OK.
8. Verify that the changes you made in the template are present in this new
installation.
To create a custom template in the Visual Studio integrated editor
1. If a solution is open in Visual Studio, close it.
2. Select File menu > New > File.
The New File dialog box appears.
3. From the Categories list, select Wise Files.
4. In the Templates list, select an icon on which to base the new template. Some
icons are not templates, but instead invoke an import process or prompt to create a
new transform.
To create a template in .WSI or .WSM format, select a project icon (name ends
with “Project”).
To create a template in .MSI or .MSM format, select a file icon (name ends with
“File”).
5. Click Open.
A new installation or merge module opens.
6. Make all the changes that should appear in installations created with this template.
7. Save the file:
a. Select File menu > Save As.
b. Name the file, and save it in either:
Templates\Project directory (.WSI or .WSM). These templates appear when
you select File menu > New > Project.
Templates\File directory (.MSI, .MSM, or .WSI). These templates appear
when you select File menu > New > File.
When you save the 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
Windows Installer Editor Reference56
Setting Up
when the template was created. If the template’s default page view is a custom
page view, you can customize it.
See Customizing Page Views on page 23.
8. To test the new template, do the following:
If you saved the template in the T emplates\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.
9. Select the template you just created and click OK.
10. Verify that the changes you made in the template are present in this new
installation.
See also:
Connecting to a Wise Software Repository on page 65
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 organiza tion’s standards. For descriptions of
the predefined rule sets, see Microsoft Best Practices Component Rule Set on page 63
and One File Per Component Rule Set on page 65. For instructions on creating new rule
sets, see Customizing Component Rules on page 60.
(Requires a repository connection.) You can share component rules with others in your
organization through a share point directory. Sharing component rules ensures that you
always use the most current set of rules and that your installations always adhere to
company standards for creating components. To share component rules, select Tools
menu > Options, click the Repository tab, and click the Advanced button. (In Visual
Studio: Tools menu > Options > Wise Options > Repository.) Make sure a shared
directory is specified for the Component Rules pat h.
See Setting Repository Options on page 50.
Windows Installer Editor Reference57
See also:
About Component Rules on page 58
Selecting a Component Rule Set on page 58
Using Component Rules to Align GUIDs in an Upgrade on page 59
About Component Rules
A component rule set manages components that are added to installations.
zA rule set is a collection of rules.
zA rule consists of one or more conditions and one or more actions.
zA 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.
zAn action determines how a resource will be assigned to a component.
Rule sets are stored in the registry.
How Component Rules Are Applied
Component rules are applied in the order they appear from top to bottom in the list of
rules on the Customize Component Rules dialog box. When a rule has multiple
conditions, only resources that meet all the conditions have the rule applied to them.
Once an added resource matches the conditions in a rule, the action is applied and no
subsequent rules are evaluated for that resource. If you add a resource that does not
meet any of the conditions in the rule set, then the Microsoft Best Practices rule set is
used for that resource.
Setting Up
See also:
Component Rules on page 57
Microsoft Best Practices Component Rule Set on page 63
Selecting a Component Rule Set
Use the Component Rule Selection dialog box to select a rule set and component nami ng
conventions for the current installation or to set the default rule options for all future
installations.
The component key values you enter on the Component Rule Selection dialog 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.
To select a component rule set
1. Select Component Rules menu > Select Rule Set.
In Visual Studio: Project menu > Component Rules > Select Rule Set.
The Component Rule Selection dialog box appears.
2. From Rule Set Name, select the rule set to use for this installation.
3. To make the specified rule set the default for all future installations, mark Make this the default rule set for all Windows Installer files.
Windows Installer Editor Reference58
Setting Up
4. In the Component Key Values section, select an option from the Default list to
determine the naming convention for new components. If the rule set you use
specifies the component naming under certain conditions, the naming convention
you specify here will be overridden when those conditions are met.
Set component key to a named Base
Select this to name new components with specified text plus an incremental
number. Selecting this option enables the Base field. Enter text to serve as a
base for the component name (example: Component). Component names will
be incremented from this base (example: Component1, Component2, and so
on).
Set component key to key of keypath or first resource
Select this to name components as follows:
If the resource is a file, registry key, or ODBC data source, give the
component the same name as the key of the keypath.
For any other type of resource, give the component the same name as the
key of the first resource in the component.
Set component key to table name of keypath or first resource
Select this to give new components the name of the table in which the keypath
or first resource resides. If multiple components are named for the same table,
an incremental number is added to the component name (example: File1, File2,
and so on).
5. From Files, you can select a different naming convention for components that are
based on file resources. You can use the long file name of the keypath file, the short
file name of the keypath file, or the naming convention specified i n the Default field
above.
6. To make the options in the Component Key Values section the defaults for all
future installations, mark Make this the default key naming convention for all installations.
7. Click OK on the Component Rule Selection dialog box.
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:
Component Rules on page 57
Using Component Rules to Align GUIDs in an Upgrade
Component rules can help you align component GUIDs in an upgrade with component
GUIDs in previous versions of the installation. If GUIDS or key paths for the same
component don’t match between the new and old .MSI, the component could
inadvertently get deleted because Windows Installer does not recognize the components
as being the same. Aligning component GUIDs for matching components prevents
upgrades from deleting necessary files in the newer version.
If you are working on an upgrade installation, you specify the previous versions of the
installation on the Previous Installation Versions dialog 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
Windows Installer Editor Reference59
Setting Up
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.
T o en sure that all resources you add to an upgrade instal lation 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 w hen
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.
To use component rules to align GUIDs in an upgrade
1. Create or open the upgrade installation.
2. If you have already added resources to the upgrade installation, run UpgradeSync
to align GUIDs for existing components.
See UpgradeSync on page 333.
3. Select a rule set to use for this upgrade.
See Selecting a Component Rule Set on page 58.
Make sure the rule set you select contains a rule for aligning component GUIDs with
previous versions; this should be the first rule in the rule set.
For best results, use the same rule set, if any, that was used in the previous
versions. That way, component creation in the upgrade will be consistent with the
previous versions.
4. Select Component Rules menu > Previous Versions.
In Visual Studio: Project menu > Component Rules > Previous Versions.
The Previous Installation Versions dialog box appears.
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 t he list.
The previous versions will be checked in the order they appear in this list.
6. Click OK on the Previous Installation Versions dialog box.
All new resources you add to the upgrade installation will be checked against and
aligned with the previous installations you specified.
See also:
Component Rules on page 57
Customizing Component Rules
If the predefined component rule sets do not reflect your organization’s standards, you
can create a new rule set. The predefined rule sets, Microsoft Best Practices and One file
per component, are read-only and cannot be modified. However, you can copy a
predefined rule set and modify the copy.
When creating new rules, refer to Microsoft’s rules for creating components.
Windows Installer Editor Reference60
Setting Up
See Organizing Applications into Components and Changing the Component Code in the
Windows Installer SDK Help.
To add a new component rule set
1. Select Component Rules menu > Customize.
In Visual Studio: Project menu > Component Rules > Customize.
The Component Rules Manager dialog box appears, listing the predefined rule sets
and custom rule sets you have created.
2. Click New.
The Enter Rule Set Name dialog box appears.
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.
The Customize Component Rules dialog box appears.
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.
See Adding and Editing Component Rules on page 62.
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.
See Selecting a Component Rule Set on page 58.
To customize an existing component rule set
1. Select Component Rules menu > Customize.
In Visual Studio: Project menu > Component Rules > Customize.
The Component Rules Manager dialog box appears, listing the predefined rule sets
and any custom rule sets you have created.
2. Click a rule set.
T o 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 R ules dialog box
appears, where you can add, edit, and delete rules.
See Adding and Editing Component Rules on page 62.
Windows Installer Editor Reference61
Setting Up
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.
3. Click OK on the Customize Component Rules dialog box.
See also:
Component Rules on page 57
Adding and Editing Component Rules
You can add component rules to a rule set, edit existing component rules, and delete
component rules.
The predefined rule sets, Microsoft Best Practices and One file per component, are readonly and cannot be modified.
To edit a component rule
1. Select Component Rules menu > Customize.
In Visual Studio: Project menu > Component Rules > Customize.
The Component Rules Manager dialog box appears, listing the predefined rule sets
and any custom rule sets you have created.
2. Click a rule set and click Modify.
The Customize Component Rules dialog box appears.
To add a rule, click Add. This starts the Component Rule Wizard, which lets you
define component rules. For details, see the procedure below.
To edit a rule, click the rule in the rules list and click Details. This starts the
Component Rule Wizard, which you can step through to change the rule name
or change any of the conditions or actions. For details, see the procedure below .
3. When you finish, click OK on the Customize Component Rules dialog box.
The Component Rules Manager dialog box reappears.
4. Click OK.
To add or edit a component rule
1. On the Name page of the Component Rule Wizard, enter a name for the new rule
and click Next. If this is an existing rule, the name is already entered and you can
accept or change it.
The Conditions page appears.
2. In the Which condition(s) do you want to check? list, mark the check box next
to each condition to check.
Windows Installer Editor Reference62
Setting Up
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 Ru le 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.
The Actions page appears.
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:
Component Rules on page 57
Microsoft Best Practices Component Rule Set
When you use this predefined rule set, components are created using the Microsoft
component creation guidelines.
See Organizing Applications into Components and Changing the Component Code in the
Windows Installer SDK Help.
If an added resource does not meet the conditions in a rule, the next rule is evaluated
for that resource. If the resource does not meet the conditions in any of the rules, the
component is created according to the final rule.
Windows Installer Editor Reference63
Setting Up
zMatch components in previous versions of the .MSI
If the keypath resource matches a resource in the previous .MSI list, match the
component layout of the previous .MSI and set the component key to match the
previous version.
zAdd all executable files to their own components
If the added resource is a 32-bit executable file (.DLL, .OCX, or .EXE), create a new
component.
zAdd all .TLB files to their own components
If the added resource is a .TLB file, create a new component.
zGroup Matching .HLP and .CNT files together
If resource file names are the same and their file extensions are .HLP or .CNT, add
them to the same component. The .HLP will be the keypath file.
zGroup matching .CHM and .CHI files together
If resource file names are the same and their extensions are .CHM or .CHI, add
them to the same component. The .CHM will be the keypath file.
zPut registry keys associated with files or components in matching
components
If the added resource is a registry key, and the registry value name or value refers
to a file or component, add the resource to an existing component that contains the
same type of resource.
zPut Current User registry keys in their own component
If the added resource is a registry key under HKEY_CURRENT_USER, add the
resource to the component matching the conditions and set the component key
base to CurrentUser. The component key base will be incremented for each new
component matching this condition. Example: CurrentUser1, CurrentUser2, and so
on.
zPut non-Current User registry keys in their own component
If the added resource is a registry key NOT under HKEY_CURRENT_USER, add the
resource to an existing component that contains the same type of resource.
zGroup all non-executable files to their own component
If the added resource is not a 32-bit executable file (.DLL, .OCX, or .EXE), add the
resource to an existing component that contains the same type of resource.
zName new non-advertised shortcuts by destination directory
If the added resource is a shortcut, add it to an existing component containing nonadvertised shortcuts in the same destination directory.
zGroup non-keypath resources by resource type
If the added resource cannot be set to the keypath, that is, if it is not a file, registry
key, or ODBC data source, add the resource to an existing component that contains
the same type of resource.
zCreate new components for resources not matching other criteria
For all other resources that do not match the criteria above, create a new
component for the resource and set the component key to the table name of the
keypath or the first resource. If multiple components are named for the same table,
an incremental number is added to the component name. Example, File1, File2, and
so on.
See also:
Component Rules on page 57
Windows Installer Editor Reference64
One File Per Component Rule Set
When you use this predefined rule set, each file you add to the installation becomes its
own component.
If an added resource does not meet the conditions in a rule, the next rule is evaluated
for that resource. If the resource does not meet the conditions in any of the rules, the
component is created according to the final rule.
zMatch components in previous versions of the .MSI
If the keypath resource matches a resource in the previous .MSI list, match the
component layout of the previous .MSI and set the component key to match the
previous version.
zAdd all files to their own components
If the added resource is a file, create a new component.
zPut registry keys associated with files or components in matching
components
If the added resource is a registry key, and the registry value name or value refers
to a file or component, add the resource to an existing component that contains the
same type of resource.
zPut Current User registry keys in their own component
If the added resource is a registry key under HKEY_CURRENT_USER, add the
resource to the component matching the conditions and set the component key
base to CurrentUser. The component key base will be incremented for each new
component matching this condition. Example: CurrentUser1, CurrentUser2, and so
on.
zPut non-Current user registry keys in their own co mponent
If the added resource is a registry key NOT under HKEY_CURRENT_USER, add the
resource to an existing component that contains the same type of resource.
Setting Up
zName new non-advertised shortcuts by destination directory
If the added resource is a shortcut, add it to an existing component containing nonadvertised shortcuts in the same destination directory.
zGroup non-keypath resources by resource type
If the added resource cannot be set to the keypath, that is, if it is not a file, registry
key, or ODBC data source, add the resource to an existing component that contains
the same type of resource.
zCreate new components for resources not matching other criteria
For all other resources that do not match the criteria above, create a new
component for the resource and set the component key to the table name of the
keypath or the first resource. If multiple components are named for the same table,
an incremental number is added to the component name. Example: File1, File2, and
so on.
Connecting to a Wise Software Repository
You can connect to a Wise Software Repository that has been configured for an
installation of Wise Package Studio.
When you connect to a Wise Software Repository:
zThe default locations for installation resources are set to subdirectories of the share
point directory that is associated with the repository.
Windows Installer Editor Reference65
Setting Up
See Installation Resources and Their Locations on page 32.
zRepository-related features in Windows Installer Editor are enabled.
Requirements
zA Wise Software Repository must be set up and configured on a shared server, and
you must be able to access that server from your computer.
zWise Package Studio 8.0 or later.
zFuture releases of Wise Installation Studio might require an upgrade of Wise
Package Studio and the repository.
To connect Windows Installer Editor to a Wise Software Repository
2. In Share Point, specify the share point directory that is associated with the Wise
Package Studio repository.
3. Click Finish.
See also:
Using a Wise Package Studio Repository on page 29
Windows Installer Editor Reference66
Chapter 3
Working With Wise Installation Files
This chapter includes the following topics:
zBefore You Create an Installation on page 67
zFile Types on page 68
zProject Files and Database Files on page 69
zTarget Platforms: 32-bit and 64-bit on page 70
zStarting a New Installation (page 78)
zOptions for New Ins tallations on page 84
zEntering Project Settings on page 85
zHow the Installation Integrates With the Solution on page 90
zScanning the Solution for New Files on page 91
zOpening an Installation Package on page 92
zComparing Windows Installer Files on page 93
zSaving an Installation as XML on page 95
zWorking With Installations in the Software Manager Database on page 95
zCompiling An Installation on page 97
zTesting and Running An Installation on page 98
Before You Create an Installation
To avoid interruptions during installation development, gather the following information
before you begin creating an installation in Windows Installer Editor.
zAll 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.
zAny third-party installations that the installation will provide. Example: Adobe
Acrobat Reader.
zWhich 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.
zA 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.
Windows Installer Editor Reference67
File Types
Working With Wise Installation Files
zThe application’s system requirements in as much detail as possible. Consider not
only memory and disk requirements, but also the minimum screen depth and
resolution, and the minimum required version of the operating system.
zAny custom graphics, referred to as billboards, that should be displayed during
installation.
zAny changes that should be made to the dialog boxes that will be displayed during
installation.
See Using the Dialogs Page on page 452.
zIf applicable, a Readme file and a license agreement file.
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.
See Project Files and Database Files on page 69.
Following are the types of Windows installer files.
ExtensionDescription
.MSIWindows 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, th ereby installing the app lication. Y ou 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.
You can convert an .MSI to a project file (.WSI).
See MSI to WSI Conversion on page 399.
.WSIWindows Installer project file, which describes an .MSI but does not store contents. It
is in the same format as an .MSI. You edit a .WSI in Windows Installer Editor and
compile it to the corresponding .MSI. The .WSI file is smaller than an .MSI and you can
set multiple options for the output of the .MSI.
.WSPROJ(Visual Studio integrated editor only) Visual Studio project file for a Windows Installer
installation. When you create an installation project in Visual Studio, a corresponding
.WSPROJ file is created in the same location. The .WSPROJ file points to the .WSI.
.MSMWindows Installer merge module, which is a pre-compiled library of components (files,
registry changes, and other system changes) that installs a discrete part of your
application. It cannot be run alone, but must be merged with an .MSI during the .MSI
compile.
See About Merge Modules on page 364.
.WSMWindows Installer merge module project, which describes an .MSM, but does not store
merge module contents. You edit a .WSM in Windows Installer Editor and compile it to
the corresponding .MSM.
See About Merge Modules on page 364.
.MSTWindows Installer transform, which changes a Windows Installer package at run time
and must be applied from the command line. See About Transforms on page 384.
Windows Installer Editor Reference68
Working With Wise Installation Files
ExtensionDescription
.MSPWindows 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.
See Patch Creation on page 335.
.PCPWindows Installer patch project, which describes and compiles to a Windows Installer
patch. A .PCP file is created from the Patch Creation tool.
See Patch Creation on page 335.
.EXEYou 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 216 and Adding Prerequisites to a
Release on page 221.
Project Files and Database Files
T ypically, the installation you distribute is an .MSI. Windows Installer operates on .MSIs,
which are a type of relational database that stores installation information and files in
tables.
See About Microsoft Windows Installer on page 545.
On the Build Options page (see Setting Build Options for a Release on page 216) or on
the Media page (see Setting Up Media for Distribution on page 236), you can specify to
output an installation in different ways:
zAs a single-file .MSI, which contains compressed installation files.
zAs an .MSI that has external compressed .CAB files.
zAs an .MSI that has external uncompressed files.
zAs an .EXE that contains the .MSI and installation files.
zAs an .EXE that runs an external .MSI.
If you to output an .EXE, you can then pre-install Windows Installer or other runtimes.
When you create an installation, you can work 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 Reference69
Working With Wise Installation Files
If you work in a .WSI or .WSM
(Wise project)
How are installation
files and paths stored?
Can you create
releases?
Compiling does what?Reads the project information and
Can you switch from
working on one file
type to the other?
Externally. The project contains paths to
the installation files. During compile,
they are compiled into the resulting .MSI
or .EXE.
Yes. Use the Re leases page and other
Release Definition pages.
compiles a database file (.MSI or .MSM),
which contains installation files.
You can switch from a project file to a
database file by compiling the project,
opening the resulting database file, and
continuing development in the database
file. However, an .MSI created by
compiling a .WSI does not contain file
paths; it contains only the files
themselves. Therefore, any files added
prior to the switch will not be refreshed
from disk because they have no file path.
Only those files you add after the switch
contain file paths and are refreshed from
disk.
If you work in an .MSI or .MSM
(Windows Installer database)
Inside the database file. Files are
refreshed from disk unless Don’t update or recompress files when saving is
marked on the Product Details page.
No. Because you are already working in
the final output file, options for multiple
output files are unavailable, which includes
all Release Definition pages.
Refreshes files from disk unless Don’t
update or recompress files when
saving is marked on the Product Details
page.
Use MSI to WSI Conversion to convert an
.MSI to a .WSI. It extracts installation files
from an .MSI, saves them to disk at
locations you specify, and creates a .WSI
that points to those files.
See MSI to WSI Conversion on page 399.
Target Platforms: 32-bit and 64-bit
Windows Installer Editor supports the following types of installation packages:
z32-bit installations that contain only 32-bit components
z64-bit installations that contain only 64-bit components
z64-bit installations that contain some 32-bit components
Windows Installer Editor supports both x64 (for AMD64 and Intel EM64T processors) and
64-bit Itanium platforms.
zAn Itanium installation will not run on an x64 platform, and vice versa.
zA 64-bit installation will not run on a 32-bit platform.
zA 32-bit installation will run on any 32-bit or 64-bit platform.
Developing 64-bit Installations on a 32-bit Computer
You can develop a 64-bit installation on a 32-bit computer, with these limitations:
zOn the Registry page, you cannot browse the 64-bit registry in the upper list box es.
However, you can add 64-bit registry keys in the lower list boxes, and you can
import .REG files that contain 64-bit keys.
Windows Installer Editor Reference70
zYou cannot test, run, or debug a 64-bit installation on a 32-bit computer.
See:
How to Specify the Target Platform on page 71
What’s Different in a 64-bit Installation? on page 72
32-bit Applications on 64-bit Computers on page 73
Guidelines for Creating Platform-Specific Installations on page 74
Creating Multiple, Platform-Specific Installations from One Project File on page 75
Using 64-Bit Windows Installer Packages in the Windows Installer SDK Help
How to Specify the Target Platform
The target platform is stored in the Templa te Summary property of the .MSI or .MSM
(merge module). For an installation to run, the platform in the Template Summary
property must match the platform of the destination computer.
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.
This setting is visible under Setup Editor > Product tab > Summary. Do not change the
target platform setting there.
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 Template Summary Property in the Windows Installer SDK Help.
Additional Target Platform Settings
zFeature Details dialog box
To display this dialog box, double-click a feature in Installation Expert > Features
page.
At run time, the destination computer’s platform determines whether a feature is
available for installation. (Example: On a 64-bit destination computer, a feature that
is designated as 32-bit does not appear to the end user and is never installed.)
This setting is used primarily to organize components by feature in a 64-bit
installation that contains 32-bit components.
See Configuring a Feature Using the Feature Details Dialog on page 116.
Windows Installer Editor Reference71
zComponent Details dialog box
To display this dialog box, select Setup Editor > Components tab, right-click a
component, and select Details.
The 64-bit component check box designates a component as 64-bit. This is
marked when you add 64-bit .EXE and .DLL files or 64-bit registry keys. If this is not
marked, the component is registered as a 32-bit component.
What’s Different in a 64-bit Installation?
A 64-bit installation differs from a 32-bit installation in the following ways:
General Information page
The minimum version of Windows Installer is set to 2.00 in the Installer Version field.
Do not override this setting in a 64-bit installation, because 64-bit installations are not
supported by Windows Installer versions earlier than 2.0.
Setup Editor > Product Tab > Summary icon
The Template Summary property is set to x64 or Intel64, which indicates the platform
that is supported by the installation.
zVersionNT64, which is set when the installation runs on a 64-bit platform.
zIntel64, which is set when the installation runs on an Itanium platform.
zMsix64, which is set when the installation runs on an x64 platform.
Files Page, Visual Studio Solutions Page
Additional predefined directories appear in the lower-left list box: Program Files (x86)
and Windows\SysWOW64. These are for 32-bit components in a 64-bit installation.
See Installation Directories on page 128.
Setup Editor > Tables tab
The Directory table contains additional, 64-bit specific folders.
Registry page
zThe 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.
zThe lower list boxes can display the 32-bit or 64-bit registry on any computer.
zYou can add registry keys and values to the 32-bit or 64-bit registry on any
computer.
See Registry Page on page 161.
Component Details dialog box
For a 64-bit component, the 64-bit component check box is marked and the
Condition field contains (VersionNT64).
See Adding and Editing a Component on page 425.
Windows Installer Editor Reference72
Working With Wise Installation Files
System Search page
The Read Registry Value dialog box, which you access from the System Search page,
contains a check box that lets you include 64-bit components in a registry value search.
See Searching For a Registry Value on page 196.
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, us e th e Wise Web Site
option of the Download Redistributables wizard.
Custom actions
Windows Installer Editor does not contain 64-bit versions of custom actions, however:
zWhen 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 64bit process.
zThe 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.
32-bit Applications on 64-bit Computers
WOW64 (Windows On Windows 64) is an emulator that lets 32-bit applications run on
64-bit versions of Windows. To prevent file and registry collisions, it isolates 32-bit
applications from 64-bit applications by:
zRedirecting 32-bit applications to the Program Files (x86) directory.
zRedirecting system calls from 32-bit applications to the SysWOW64 directory.
zProviding 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 32bit 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.
ResourcePlace 32-bit versions inPlace 64-bit versions in
Program files (default
directory)
Program Files (x86) directoryProgram Files directory
Windows Installer Editor Reference73
Working With Wise Installation Files
ResourcePlace 32-bit versions inPlace 64-bit versions in
bit registry view. They will
be installed in the
WOW6432Node (for hives
that have a WOW6432
node).
zDo not mark the
component as 6 4-bit.
Search for “Running 32-bit Applications” and “WOW64 Implementation Details” in the
MSDN Library (msdn.microsoft.com/library/).
zPlace the keys in the 62-bit registry view.
zMark the component as 64-bit on the
Component Details dialog box.
Guidelines for Creating Platform-Specific Installations
The following guidelines refer to creating installations in Windows Installer Editor. For
more general guidelines, see Using 64-Bit Windows Installer Packages in the Windows
Installer SDK Help.
32-bit Installations That Contain Only 32-bit Components
zOn the New Installation File dialog box, select 32-bit as the target platform. This
sets the initial target platform for the Default release.
zSet the target platform for all features to 32-bit. A 64-bit feature in a 32-bit
installation will never be installed.
zAdd resources to the installation as usual. Do not add 64-bit components to a 32-bit
installation.
zSet the target platform for all re leases to 32-bit (this is the default).
64-bit Installations That Contain Only 64-bit Components
zOn the New Installation File dialog box, select one of the 64-bit options as the target
platform. This sets the initial target platform for the Default release.
zSelect the appropriate 64-bit target platform for all features.
zAdd 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.)
zSelect the appropriate 64-bit target platform for all releases.
zAMD 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.
Windows Installer Editor Reference74
Working With Wise Installation Files
64-bit Installations That Contain Some 32-bit Components
zSelect the appropriate target platform for each feature, and add the correct type of
component to each one. Do not add a 64-bit component to a 32-bit feature, and
vice versa, because it will never be installed.
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.) When you add 32-bit files or registry keys, the 64-bit component check box is not marked.
zSelect the appropriate target platform for each release.
zAMD 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 75.
Platform-Specific Merge Modules
zA 32-bit merge module can be merged into a 32-bit or 64-bit installation.
zA 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:
How to Specify the Target Platform on page 71
Using 64-bit Merge Modules in the Windows Installer SDK Help
Creating Multiple, Platform-Specific Installations from One Project
File
You can create a single installation project (.WSI) that can produce 32-bit and 64-bit
installation files, or x64 and Itanium installation files.
Example:
You develop a gra phics 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.
Your options are:
zOrganize 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.
Windows Installer Editor Reference75
Working With Wise Installation Files
zOrganize 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.
To organize a mixed-platform project by feature
1. On the New Installation File dialog box, select x64 as the target platform.
2. On the Features page, create separate features for the different target platforms.
Example:
This feature is used by both
versions.
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.
See Defining the INSTALLDIR Property in a Mixed-Platform Installation on page 78.
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:
Select the 64-bit release
Select the features to be
installed on 64-bit platforms
7. Compiling the project creates the following .MSIs:
Graphic32.msi, which runs installs only 32-bit components and runs on any
Windows Installer Editor Reference76
platform. Its Template Summary property is set to Intel, which represents a 32bit installation.
Working With Wise Installation Files
Graphic64.msi, which installs both 32-bit and 64-components and runs on x64
platforms only. Its Template Summary property is set to x64.
To organize a mixed-platform project by component
1. On the Features page, create a single set of features and set their target platform to
All Processors. Example:
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.
See Defining the INSTALLDIR Property in a Mixed-Platform Installation on page 78.
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:
Select the 64-bit release.
Select the features to be
installed on 64-bit platforms.
Within each feature, select the
components to be installed on
64-bit platforms.
6. Compiling the project creates the following .MSIs:
Graphic32.msi, which installs only 32-bit components and runs on any platform.
Windows Installer Editor Reference77
Its Template Summary property is set to Intel, which rep resents a 32-bit
installation.
Working With Wise Installation Files
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:
Configuring a Feature Using the Feature Details Dialog on page 116
Customizing a Release on page 211
Defining a Feature and Component Set for a Release on page 213
Defining the INSTALLDIR Property in a MixedPlatform Installation
The INSTALLDIR build property represents the main installation directory for the
application. By default, it is set to the first directory you create under the Program Files
folder on the Files page. A mixed platform project has two installation directories: one
under Program Files and another under Program Files (x86). However, the INSTALLDIR
property can have only one value. To see this, go to the Files page and view the
subdirectories of Program Files and Program Files (x86); only one will be designated as
the INSTALLDIR.
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.
Example: The installation directory is Program Files (x86)\QuickFacts. In MSI Script,
enter the following custom action:
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:
Creating Multiple, Platform-Specific Installations from One Project File on page 75
About MSI Script on page 491
Custom Action Reference on page 511
Starting a New Installation
Follow the steps below to create a new standard Windows Installer installation.
You can create other types of installations.
See Options for New Installations on page 84.
To start a new installation in the Wise editor
1. Select Start menu > Programs > Symantec > Wise Installation Studio > Windows
Installer Editor.
The New Installation File dialog box appears. If it does not appear, select File menu
> New.
Windows Installer Editor Reference78
Working With Wise Installation Files
2. In the Categories list, click Predefined Templates.
3. In the Templates/Tools list, click the Windows Application icon.
A Windows Application installation is a standard installation intended for a Windows
computer or server.
4. In the File type section, specify the type of file to create:
Create an .MSI (Windows Installer database), which is a distributable
installation.
Create a .WSI (Windows Installer project), which contains instructions for
compiling an .MSI.
See Project Files and Database Files on page 69.
5. Select a target platform: 32-bit, 64-bit (x64), or 64-bit (Itanium).
See How to Specify the Target Platform on page 71.
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.
See Creating an Installation for Standard Users on page 80.
7. Click OK. The new installation opens.
To start a new installation in the Visual Studio integrated editor
When you start a new installation, you have sever al options for how to proceed. Not only
do you choose whether to create a project associated with a solution, but you also
choose what kind of file to create. T ypically, you will create an installation in one of these
ways:
zAs a project integrated with a Visual Studio solution. Do this to create an installation
for an application you have developed in Visual Studio.
See Creating an Installation Within a Solution on page 80.
zAs a stand-alone installation that is not integrated with a solution. Do this to
package application files that are not already in a Visual Studio solution into an
installation.
See Creating a Stand-alone Installation on page 82.
About Standard User Installations
¾ Windows Installer 4.0 or later only.
The User Account Control (UAC) that was introduced with Windows Vista provides a
temporary privilege-elevation model. A standard user installation is one in which the
UAC is disabled so that standard users can install it without elevation. The installation
cannot contain actions that access a protected area on the destination computer.
During development, a standard user installation behaves as follows:
zWindows 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 Installer Editor Reference79
Windows\Profiles\Local Settings\Application Data instead of Program Files.
Working With Wise Installation 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.
zThe 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.
See Creating an Installation for Standard Users on page 80.
At run time, a standard user installation behaves as follows:
zThe 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.
zThe User Account Control dialog box that prompts end users for administrator
credentials does not appear.
zIf the installation tries to access a protected area, it fails.
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 200.
Creating an Installation for Standard Users
¾ Windows Installer 4.0 or later only.
A standard user installation is one in which the UAC is disabled so that standard users
can install it without elevation. The installation cannot contain actions that access a
protected area on the destination computer.
See About Standard User Installations on page 79.
To create a standard user installation
1. Do one of the following:
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 198.
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.
Creating an Installation Within a Solution
¾ Visual Studio integrated editor only.
When you work in the Visual Studio integrated editor, you typically create an installation
as a project within a Visual Studio solution. Because the installation is synchronized with
Windows Installer Editor Reference80
Working With Wise Installation Files
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 90.
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 85.
You can create a stand-alone installation that is not integrated with a Visual Studio
solution. See Creating a Stand-alone Installation on page 82.
You also can create other types of installations. See Options for New Installations on
page 84.
Note
For best results, build the solution before creating the installation. This ensures that the
target files are available for integration into the installation. If the main project’s target
file does not exist when you create the installation, project information might not appear
on the Product Details page as expected. The data will be included in the compiled .MSI,
and will appear on the Projects page the next time you compile the installation project.
To create an installation within a solution
1. Start Visual Studio and open a solution.
2. Select File menu > New > Project.
The New Project dialog box appears.
3. In the Project Types list, select Wise Setup and Deployment Projects.
4. In the Templates list, do one of the following:
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 th e installation file. In Location, specify the directory in
which to save the project.
6. Mark Add to Solution.
7. Click OK.
If you selected the Windows Application icon, an installation project is created in the
location you specified and is listed in Solution Explorer. Skip to the last step.
If you selected the Setup Wizard icon, the Wise Setup Wizard appears.
8. Step through the Wise Setup Wizard:
a. On the wizard’s Overview page, review the project settings.
b. On the wizard’s Project Type page, select the Windows Application option.
c.Set additional options if necessary.
Windows Installer Editor Reference81
See Entering Project Settings on page 85.
d. Click Finish.
An installation project is created in the location you specified and is listed in Solution
Explorer. A corresponding .WSPROJ file (Visual Studio project) is created in the
same location.
9. Double-click the .WSI file in Solution Explorer.
The installation opens.
See also:
Starting a New Installation on page 78
Creating a Stand-alone Installation
¾ Visual Studio integrated editor only.
You can create an installation that is not associated with a Visual Studio solution.
Example: You might do this when you are not creating the .EXE and .DLL files that make
up the installation. In such cases, there is no need to synchronize the installation with
other Visual Studio projects.
You can create an installation that is part of a Visual Studio solution. See Creating an
Installation Within a Solution on page 80.
Working With Wise Installation Files
You also can create other types of installations. See Options for New Installations on
page 84.
To create a stand-alone installation
1. Start Visual Studio. If a solution is open, close it.
2. Select File menu > New > File.
The New File dialog box appears.
3. In the Categories list, select Wise Files.
4. In the Templates list, click one of the following icons:
Windows Application File
Create an .MSI (Windows Installer database), which is a distributable
installation. Because an .MSI typically encapsulates all the files in the
installation, it is larger and takes longer to save. Also, some options that
determine the output of an .MSI are not available when you work with the .MSI
itself.
Windows Application Project
Create a .WSI (Windows Installer project), which contains instructions for
compiling an .MSI. When you work in a .WSI instead of an .MSI, the .WSI file is
smaller and you can set multiple options for the output of the .MSI.
See File Types on page 68 and Project Files and Database Files on page 69.
5. Click Open.
The installation opens.
See also:
Windows Installer Editor Reference82
Starting a New Installation on page 78
Creating a Device Driver Installation
You can create an installation that supports Microsoft Driver Install Frameworks (DIFx).
Microsoft created the Driver Install Frameworks to significantly improve the quality of
device driver installations. For information on DIFx, search for “DIFx” in the MSDN
Library (msdn.microsoft.com/library/).
The Microsoft DIFxApp merge module simplifies the process of creating installations that
install device drivers. This merge module adds custom actions to the installation that are
needed to install and uninstall the driver package using Driver Install Frameworks for
Applications (DIFxApp). After you add the merge module, you add the files that make up
the driver package and specify the DIFxApp options for installing the driver.
To create a device driver installation
1. Use the Download Redistributables wizard to download the latest version of the
DIFxApp merge module from the Wise Web site, if you have not already done so.
See Downloading Redistributable Files on page 34.
Note
Early versions of this merge module might be named “Binaries.”
Working With Wise Installation Files
2. Make sure the device driver you are installing meets the Microsoft DIFx driver
requirements.
3. Do one of the following:
Start a new installation and select the Device Driver icon on the New
Installation File dialog box.
See Starting a New Installation on page 78.
(In Visual Studio: Start a new stand-alone installation and select the Device
Driver icon on the New File dialog box.
See Creating a Stand-alone Installation on page 82.)
Start a new installation and select the Device Driver icon on the New
Installation File dialog box.
See Starting a New Installation on page 78.
Open an existing in stallation.
4. On the Merge modules page, add the Microsoft DIFxApp merge module to the
installation.
See Adding a Merge Module to an Installation on page 381.
5. On the Features page, add a feature for the installation’s driver package.
See a Adding a New Feature on page 114.
6. On the Files page, do the following.
See Adding Files to an Installation on page 130.
a. Select the driver package feature.
b. Create a unique directory for the driver package.
c.Add the driver package’s .INF file to the directory you created.
Windows Installer Editor Reference83
d. The driver package’s .INF file must be the first file added to this directory so
that it becomes the key path of the component.
e. Add the other files that make up the driver package to the same directory that
contains the .INF file.
f.In the lower-right list box, double-click the .INF file.
g. The File Details dialog box appears.
h. Click the Driver tab and edit the DIFxAPP options.
See Editing DIFxApp Options on page 154.
7. To add additional driver packages repeat the preceding steps, except for adding the
DIFxApp merge module.
8. Continue developing the installation.
Options for New Installations
When you create a new installation, the New Installation File dialog box appears and
provides options for starting an installation. Most of the options use a template to start a
specific kind of installation. If you have created custom templates, they appear as
additional options for new installations.
Working With Wise Installation Files
See Creating and Editing Installation Templates on page 54.
This section describes the options that are available.
Setup Wizard
(Visual Studio integrated editor only .) Runs a wizard that creates a Windows Application,
Web Application, Server Application, or Merge Module installation. With this wizard, you
can customize the settings rather than accepting the defaults of the standard templates.
See Creating an Installation Within a Solution on page 80.
Windows Application
Creates a standard installation with default settings.
See Starting a New Installation on page 78.
In the Visual Studio integrated editor, see Creating an Installation Within a Solution on
page 80 or Creating a Stand-alone Installation on page 82.
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).
See Creating a Device Driver Installation on page 83.
Web Application
Creates an installation intended to be run on Microsoft Internet Information Server
(IIS).
See About Web Installations on page 266.
Windows Installer Editor Reference84
Working With Wise Installation Files
Server Application
Creates an installation intended to be run on Microsoft IIS, with an additional dialog box
for recording logon information.
See Obtaining Logon Information From a Dialog on page 475.
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.
See Adding Windows Mobile Files on page 246.
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.
See Adding Palm OS Files on page 249.
Transform
Lets you change any aspect of an installation by creating a transform based on changes
that you make to the installation.
See Creating a Transform Based on an Existing .MSI on page 385.
Merge Module
See Creating a Merge Module As a New Installation on page 369.
In Visual Studio: see Creating a Merge Module Within a Solution on page 371 or
Creating a Merge Module As a New Installation on page 369.
Import Tools
The following tools open an import wizard, where you select a development project file
to import. Target file information is extracted from the project file and added to the
installation.
See Import Visual Studio Projects on page 395.
zVisual Basic
(In Visual Studio: this is named Import Visual Basic.)
zVisual C#
(Not available in the Visual Studio integrated editor.)
zVisual J#
(Not available in the Visual Studio integrated editor.)
Entering Project Settings
¾ Visual Studio integrated editor only.
Each Visual Studio installation project has settings that control how it interacts with
other projects in the solution.
Stand-alone installations that are not integrated with a Visual Studio solution do not
have project settings.
Windows Installer Editor Reference85
Working With Wise Installation Files
To access project settings:
Do one of the following:
zWhile creating a new installation project, select Setup Wizard on the New Project
dialog box.
See Creating an Installation Within a Solution on page 80.
The Wise Setup Wizard dialog box appears. Available pages are: Overview, Project
Type, Projects, and Main Project.
zRight-click an existing installation project in Solution Explorer and select Properties.
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 on page 86
Project Type Page on page 86
Projects Page on page 87
Main Project Page on page 88
Pre-build Event on page 89
Post-build Event on page 89
Project Outputs Page on page 89
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:
Creating an Installation Within a Solution on page 80
Entering Project Settings on page 85
Project Type Page
¾ Visual Studio integrated editor only.
The Project T ype page lets you specify what kind of installation project you are creating.
This page is accessible only from the Wise Setup Wizard when you create a new
installation.
zWindows Application
Create a standard Windows Installer installation (.WSI). This is intended for
installation to Windows computers or servers.
See Creating an Installation Within a Solution.
Windows Installer Editor Reference86
Projects Page
Working With Wise Installation Files
zWeb Application or Web Service
Create a standard Windows Installer installation (.WSI). This has options
preconfigured to enable it to be installed to a Microsoft Internet Information Server.
See About Web Installations on page 266.
zServer Application
Create a standard Windows Installer installation (.WSI). This is the same as the Web
Application above except that it also prompts the end user to enter valid NT logon
information.
See Obtaining Logon Information From a Dialog on page 475.
zMerge Module
Create a standard merge module project (.WSM).
See Creating a Merge Module Within a Solution on page 371.
See also:
Creating an Installation Within a Solution on page 80
Entering Project Settings on page 85
¾ 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.
zSelect the projects to include in this package
From this list of all projects in the current solution, select the ones to add to this
installation. (All projects are selected by default.) Output files of the selected
projects are added to this installation.
If you add a project to this solution later, it will be added to the project list and
selected for inclusion.
To exclude a project from the installation, deselect it.
zScan 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.
See Scanning the Solution for New Files on page 91.
Specify the level of scanning that will occur for this installation. The default is
determined by the Scan Method option in Wise Options.
Never scan solution
If you select this, you must add new files to in stallations manually using the
Files page. Also, when files are removed from a solution, you must remove
them from the installations manually.
Prompt only when new files are detected
Windows Installer Editor Reference87
Select this to be prompted each time there are new files in the solution that
need to be added to the installation. The prompt appears during save, build, or
compile.
Working With Wise Installation Files
Prompt when any files are detected
This is the highest level of prompting. Like the previous option, the prompt
appears during save, build, or compile when there are new files. Also, if you
previously excluded files by clearing their check boxes, you’ll be prompted to
confirm that those files should be excluded.
Always scan solution
Each time Windows Installer Editor scans a solution, it adds new files to the
installation and deletes files that have been removed from the solution.
zBind installed files to the solution build configuration
Mark this to have the installation source paths change automatically when you
change this project’s build configuration. The default is determined by a check box
in Wise Options.
zAutomatically generate web sites and virtual directories
Mark this to include Web application projects in the project scannin g and create web
sites and virtual directories based on the scan. If you do not want the web sites or
virtual directories to be created, clear this check box.
See also:
Creating an Installation Within a Solution on page 80
Entering Project Settings on page 85
Main Project Page
¾ Visual Studio integrated editor only.
On the Main Project page, you specify the main project and set options that affect the
main project. Access this page either from the Wise Setup Wizard when you create a
new installation, or by right-clicking a project in a solution and selecting Properties.
zMain Project
zAutomatically Update Product Information
zCreate Shortcut
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.
Mark this to upd ate the instal lation’s product name, version, and manufacturer
whenever you rebuild the solution or whenever the version number of the main
target file changes. (In a merge module, only the version is updated.) The default is
determined by a check box in Wise Options. This is unavailable if you select
<None> in Main Project.
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:
Windows Installer Editor Reference88
Pre-build Event
Post-build Event
Working With Wise Installation Files
Creating an Installation Within a Solution on page 80
Entering Project Settings on page 85
¾ 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.
¾ 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.
Project Outputs Page
¾ Visual Studio integrated editor only.
By default, the installation includes only the main output file (.EXE or .DLL) from each
project in the solution, and the content files from each project. On the Project Outputs
page, you select which projects to include in the installation and specify additional
project output files to include in the installation.
You also can add and delete output groups in a specific i nstallation 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.
See Visual Studio Solution Page on page 157.
This page is accessible only on the Project Properties dialog box. Right-click a project in
a solution and select Properties.
zProject
Select the project to specify additional outputs for.
zOutput Groups
Select one or more types of output files to include in the installatio n:
Debug Symbols
Include the project’s debugging (.PDB) files.
Localized Resources
Windows Installer Editor Reference89
Include files marked as resources for the project. Example: additional files for a
specific language.
Working With Wise Installation Files
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:
Creating an Installation Within a Solution on page 80
Entering Project Settings on page 85
How the Installation Integrates With the Solution
¾ Visual Studio integrated editor only.
When you add an installation to a Visual Studio solution, as described in Creating an
Installation Within a Solution on page 80, the following items are added to the
installation project:
zAll 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.
See Scanning the Solution for New Files on page 91.
zAssembly 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.
zThe 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.
zAn advertised shortcut for the application.
On the Project Outputs page in the project settings, you can choose not to create a
shortcut.
Windows Installer Editor Reference90
When you add a new project to the solution, its outputs are added to the installation.
To exclude a project from the installation, or to change how the installation project
integrates with the solution, edit the installation’s project settings.
See Entering Project Settings on page 85.
Note
Only files that reside in the directory where the solution (.sln) file resides and its
subdirectories can be managed with source control. Files that reside in system
directories or other locations outside the solution directory are not managed by source
control, and therefore do not appear in the Other Files or Source Files folders under the
installation project in Solution Explorer.
Scanning the Solution for New Files
¾ Visual Studio integrated editor only.
Windows Installer Editor can scan projects in a solution for new output files that need to
be added to the installation, and add those files to the installation.
Scanning occurs when you:
Working With Wise Installation Files
zLoad, save, or build an installation project within a solution.
zChange the installation’s project settings. Examples: output types, projects to
include.
How and when the solution is scanned is determined by the Scan Method option. The
default is set in Wise Options and can be changed for specific installations on the
Projects page in the project settings.
See Setting Visual Studio Options on page 52 and Projects Page on page 87.
zIf you add an existing .WSI to a solution, the .WSI project’s original scan method
setting is preserved.
zIf you add an existing .WSI project to a solution and no scan method setting is
found, the default scan method is used.
You can specify the level of scanning that should occur for each installation.
See Projects Page on page 87.
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.
See Defining the INSTALLDIR Property in a Mixed-Platform Installation on page 78.
Add Project Outputs to Installation dialog box
This dialog box appears during save, build, or compile when the scan method is set to
prompt. On this dialog box, you can:
zMark check boxes for files to add them to the installation project.
zEdit the destination feature and target directory by clicking a file and editing the
appropriate cell.
Windows Installer Editor Reference91
Working With Wise Installation Files
zAdd 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.
Note
In a Web installation, you can only change the destination feature.
Why would you change the scan method?
You can change the scan method for specific installations on the Projects page in the
project settings.
You might want to change an installation’s scan method at various stages of the
development cycle. Example:
zAt the beginning of a development project when you are continually creating new
projects and files, you would want to add all new files automatically.
zAs development continues and you become more disc riminating about the files you
add to the installation, you might want to be prompted to add files.
zAt 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:
How the Installation Integrates With the Solution on page 90
Opening an Installation Package
¾ Requires a repository connection. Not available in the Visual Studio
integrated editor.
The Open dialog box might contain the following tabs that let you open different items:
zFile System tab: Opens a package from a directory on your computer.
zRepository tab: Opens a package from the Wise Software Repository.
The Repository tab on the Open dialog box provides a centralized list of installation
packages and eliminates the need to navigate your file system to find an installation
file. When you select a package from the repository:
The package opens from its location in the repository.
Typically, this is the Scripts directory or your default project directory.
If the package status is Available, you are prompted to change the status to
Under Development.
Warning
Use caution when changing available packages, because they might have been
deployed to end users.
If you try to save the package, a prompt asks if you want to overwrite the file
If the package is checked into the Software Manager Revision Control, you
Windows Installer Editor Reference92
that is in the repository.
might see additional prompts when you try to edit or save it.
Working With Wise Installation Files
(Revision Control is available only in the Wise Package Studio version of
Software Manager but it can affect packages that you open in Wise Installation
Studio.)
To open a package from a directory:
Click the File System tab on the Open dialog box and navigate to a package. This is the
same as the standard Windows Open dialog box.
To open a package from the Wise Software Repository
1. Click the Repository tab on the Open dialog box.
Packages are displayed in the list box if they have a valid path to an installation file
(.MSI, .WSI, and so on). If a package’s path to its installation file is missing or
broken, or is not accessible by the current computer, that package is not listed. Also,
subscription packages are not listed.
2. Database displays the current Software Manager database. To select a package
from a different database, click .
The Select Data Source dialog box appears. This is a standard Windows ODBC
connection wizard, which lets you connect to a database through an ODBC data
source.
3. Specify criteria for filtering the packages that are displayed above:
Groups
This lists the groups defined in Software Manager.
Status
This lists the possible package statuses.
Package Type
This lists the available package types.
4. Select a package in the list and click Open.
If you change an installation that you opened from the repository, re-import it into the
Software Manager database. Otherwise, changes will not be reflected in the repository.
See also:
Using a Wise Package Studio Repository on page 29
Comparing Windows Installer Files
Visual MSIDiff™ lets you compare the following types of files and see the differences in
Setup Editor > Tables tab: .MSI, .WSI, .MSP, .MSM, .WSM, or .MST files. You can
compare an .MSP file only with its base .MSI.
Options for Comparing Files
zCompare the current file to another file.
zCompare any two files.
(Not available in the Visual Studio integrated editor.)
zCompare a transform to its base .MSI, to see the items that the transform changes
in the .MSI.
Windows Installer Editor Reference93
Working With Wise Installation Files
To view differences between two Windows Installer files
1. Open a file.
2. Select Tools menu > Visual MSIDiff and then select an option.
In Visual Studio: Project menu > Visual MSIDiff.
Compare Current File to Another File
The Compare Windows Installer Files dialog box appears. Specify the file to
compare to the current file. To have the file you specify in Compare To treated
as the newer file in the comparison, mark the dialog box’s check box. To
compare an .MSP to an .MSI, the current file must be the .MSI. An .MSP is
always treated as the newer file. Click OK.
Compare Any Two Files
The Compare Windows Installer Files dialog box appears. Specify the files to
compare. The file you specify in the Base File field becomes the current file. To
compare an .MSP to an .MSI, the Base File must be the .MSI. To have the file
you specify in Compare To treated as the newer file in the comparison, mark
the dialog box’s check box. An .MSP is always treated as the newer file. Click
OK. (Not available in the Visual Studio integrated editor.)
Compare Transform to Base .MSI
(Transform files only.) Automatically compares the .MST to its base .MSI.
You are taken to Setup Editor > Tables tab and the Visual MSIDiff Key dialog 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 mark ed 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 Command Line Options For WFWI.EXE on page 259.
See also:
Tables Tab on page 430
Windows Installer Editor Reference94
Saving an Installation as XML
You can save a copy of an installation (.WSI, .MSI, WSM, or .MSM) in XML format. This
lets you check the XML version of the installation into a text-based source code control
system (SCCS), use text-based file comparison tools to find changes, or perform
analyses with XML reporting tools.
You can set a global option in Wise Options to create an XML copy every time you save
an installation file, or you can export to an XML file on an as-needed basis. Depending
on the size of the installation file, creating an XML copy can take several minutes.
You cannot open an XML-format file in Windows Installer Editor.
To create an XML file during saves
Use this method when you plan to check the XML file into an SCCS from Windows
Installer Editor. This ensures that the XML copy is always synchronized with the original
installation file.
1. Select Tools menu > Options and click the General tab.
In Visual Studio: Tools > Options > Wise Options > General.
2. Mark the Create XML copy during save check box.
Working With Wise Installation Files
This global option causes an XML copy to be created every time you save an installation
file. The copy has the same name as the installation file with the extension .XML
appended, and it is saved in the same directory. (Example: If the current file name is
Application.wsi, the XML copy is named Application.wsi.xml.)
To export an XML file as needed
Use this method when you do not have an integrated SCCS, or to compare the version
of the installation you’re working in to the version that you checked out of your SCCS.
1. Select File menu > Export to XML.
In Visual Studio: Project > Export to XML.
2. In the Save As dialog 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.
The current installation is saved and exported to XML format.
Working With Installations in the Software Manager
Database
¾ Requires a repository connection.
There are restrictions on editing and saving an installation that has been added to the
Software Manager database (either by adding its meta data or importing it).
Windows Installer Editor Reference95
Working With Wise Installation Files
When the package path matches a package in the database
If you open an installation file and the Software Manager database contains a package
with the same package path, the application and package names on the Product Details
page are unavailable. This is because the installation is connected to the package in the
database. You can only edit these names on the Package Attributes dialog box in
Software Manager.
If you edit the installation’s meta data, the meta data in the database is updated when
you save the installation. If you change the installation, re-import it to the Software
Manager database to update its resources.
Opening a copy of a package in the database
If you open an installation file that is a copy of a package in the Software Manager
database, the application and package names are populated and enabled. Change one
or both of these names before saving the installation to avoid overwriting the package in
the database. Then, when you then save the installation, a new package and its meta
data are added to the Software Manager database.
Example: You want to create a patch for an installation that is in the Software Manager
database. You open a copy of the installation file to change it. Before you save the
installation, you change its package name on the Product Details page. When you save
the installation, a new package with the same application name, and its meta data, are
added to the database.
Duplicate package in Software Manager Database dialog box
If you open an installation file that is a copy of a package in the Software Manager
database, and you don’t change the application and package name on the Product
Details page, the Duplicate Package in Software Manager Database dialog box appears
when you try to save the installation. Select an option and click OK:
zCreate a New Package (recommended)
Mark this to create a new package in the Software Manager database. The Product
Details page opens so that you can change the application or package name before
saving the installation file.
zOverwrite Existing Package
Mark this to overwrite the package in the Software Manager database. The meta
data of the package in the database is overwritten, and its resources are removed
from the database.
zWork Disconnected
Mark this to keep the installation file disconnected from the Software Manager
database. When you save the installation, its meta data is not added to the
database.
To connect the installation file to the Software Manager database, change the
application or package name on the Product Details page and save the installation.
A new package and its meta data are added to the database.
See also:
Using a Wise Package Studio Repository on page 29
Windows Installer Editor Reference96
Compiling An Installation
Compiling an installation compresses its files, builds .CABs if necessary, and creates the
installation .MSI. Depending on the .EXE option you select on the Build Options page,
compiling can also create an installation .EXE.
(In Visual Studio: compiling and building do the same thing.)
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 but ton 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 209.
Speeding the Compile
If you are working in a .WSI or .WSM file, you can use either of the following methods to
speed the compile process:
Working With Wise Installation Files
zMark 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 38.
zUse ExpressBuild, a multi-processor compile feature.
See About ExpressBuild on page 44.
To compile an installation in the Wise editor
1. Click Compile at the lower right of the main window.
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 409.
To compile an installation in the Visual Studio integrated editor:
Select one of the following commands from the Build menu:
zBuild 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.
zBuild project name
Compiles only the project you selected in Solution Explorer. If quick compile is
enabled and you have already built this project, this command compiles only what
has changed since the last build.
zRebuild Solution
Compiles all files in all projects in the solution.
Windows Installer Editor Reference97
Working With Wise Installation Files
zRebuild project name
Compiles all files in the project you selected in Solution Explorer.
zCompile
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.
See Using the Task List on page 26.
If you see messages that files are missing, you can suppress the file refresh by marking
the Don’t update or recompress files when saving 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:
Testing An Installation on page 99
Running An Installation on page 99
Running the Debugger on page 488
Testing and Running An Installation
To test an installation, you can:
zTest the installation, which appears to run but does not install files or change the
system.
See Testing An Installation on page 99.
zDebug 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 488.
zRun the installation on your computer, which installs files and changes the system.
See Running An Installation on page 99.
zRun the installation and install it into a virtual layer. After you test the installation,
you can then delete the layer to restore your computer to its original state.
See Running An Installation on page 99.
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.
Windows Installer Editor Reference98
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.
In Visual Studio: select Project menu > Start in Test Mode.
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.
The installation is compiled and run in test mode.
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.
Working With Wise Installation Files
Testing a transform or merge module
You cannot test a transform or a merge module by itself. It can only be run in
conjunction with an .MSI. To run a transform or merge module, run the base .MSI from
the command line with the appropriate command-line options, which are documented in
the Windows Installer SDK Help.
See also:
Compiling An Installation on page 97
Running An Installation on page 99
Running the Debugger on page 488
Running An Installation
When you run an installation, you can either:
zInstall it on your computer.
This runs the installation as it would run on the destination computer and makes
changes to your computer.
zInstall it into a virtual layer.
This creates a new virtual layer, installs the .MSI into the layer, and activates the
layer. After you test the installation, you can delete the virtual layer to restore your
computer to its original state. (Not available in the Visual Studio integrated editor.)
To perform side-by-side testing of two versions of an application without them
interfering with each other, install one version into a virtual layer and the other version
on your computer.
Windows Installer Editor Reference99
Working With Wise Installation Files
To run an installation and install it on your computer
1. Click Run at the lower right of the main window.
In Visual Studio: in Solution Explorer, right-click the installation project icon and
select Set as StartUp Project. Then, select Debug menu > Start Without Debugging.
The additional options below are not available.)
2. Select the type of installation from the button menu:
Force Reinstall
Normally, if an ap plication 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.
See Command Line Options in the Windows Installer SDK Help.)
Uninstall --> Install
If the application is already installed, this option first uninstalls it, then installs.
Run
Runs the installation normally. If the application is already installed, you are
prompted to uninstall it.
Other command lines
If you added command lines to the Command Line page, they also appear. To
avoid having to select from the button menu, press Ctrl+R to run with no
command line.
3. If you are working in a .WSI that contains multiple releases, you are prompted to
select one.
The installation is compiled and run.
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 an installation and install it into a virtual layer
¾ Not available in the Visual Studio integrated editor.
1. On the Wise Options dialog box, mark the Install into virtual layer from Run
button option.
See Setting General Options on page 38.
2. Click Run at the lower right of the main window.
3. If you are working in a .WSI that contains multiple releases, you are prompted to
select one.
The application is installed into a new virtual layer and activated. You can test the
installation by viewing its installed files and running the application. If needed, you
can edit the contents of the layer in the Virtual Package Editor. You might add or
delete a file or registry key for testing purposes. You can then delete the layer to
restore your computer to its original state.
See About Installation Expert in the Virtual Package Editor Help.
Windows Installer Editor Reference100
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.