Docstoc

Windows_Installer_Training_Material

Document Sample
Windows_Installer_Training_Material Powered By Docstoc
					                                                                                Windows Installer Technology

                TABLE OF CONTENTS of window installer Technology.


Overview of Windows Installer Technology ---------------------------------------------------------------------- 5
  Windows Installer Technology ----------------------------------------------------------------------------------- 7
  Windows Installer Client ------------------------------------------------------------------------------------------- 7
  Windows Installer Service ----------------------------------------------------------------------------------------- 8
  You can find this Service by going to --------------------------------------------------------------------------- 8
  Windows Installer Packages-------------------------------------------------------------------------------------- 9
         Windows Installer Components ------------------------------------------------------------------------ 10
         Windows Installer Features ----------------------------------------------------------------------------- 11
  Feature of Windows Installer Service ------------------------------------------------------------------------ 12
Components ----------------------------------------------------------------------------------------------------------- 16
  Some Rules of Organizing Applications into Components ---------------------------------------------- 17
  Common Component Errors ------------------------------------------------------------------------------------ 18
  What are Isolated Components -------------------------------------------------------------------------------- 18
  How do you use Isolated Components ---------------------------------------------------------------------- 18
  Isolate Components Action ------------------------------------------------------------------------------------- 19
      How it works ----------------------------------------------------------------------------------------------------- 19
      Why do this?----------------------------------------------------------------------------------------------------- 19
      How does the action operate? ------------------------------------------------------------------------------ 19
  Component sharing ----------------------------------------------------------------------------------------------- 20
Properties -------------------------------------------------------------------------------------------------------------- 21
  Five Ways to Set a Property ------------------------------------------------------------------------------------ 21
  Categories of Properties ----------------------------------------------------------------------------------------- 22
  Most Important WFWI Properties ----------------------------------------------------------------------------- 23
  Creating Properties ----------------------------------------------------------------------------------------------- 24
  Editing Properties ------------------------------------------------------------------------------------------------- 25
  Deleting Properties ----------------------------------------------------------------------------------------------- 25
      LAB - Reading a Registry Value to a Property ---------------------------------------------------------- 25
      LAB - Using a Property to Remove a File at Install Time --------------------------------------------- 26
Environment Variables ---------------------------------------------------------------------------------------------- 28
      LAB – Add a New Environment Variable ----------------------------------------------------------------- 28
  Manually Adding Entries into the Environment Table ---------------------------------------------------- 30
The Installation Databases ---------------------------------------------------------------------------------------- 31
  What is the Installation Database? ---------------------------------------------------------------------------- 31
      Core Tables Group -------------------------------------------------------------------------------------------- 33
      File Tables Group ---------------------------------------------------------------------------------------------- 34
                                                                                 Windows Installer Technology

     Locator Tables Group ----------------------------------------------------------------------------------------- 34
     Registry Tables Group ---------------------------------------------------------------------------------------- 35
     Registry Tables Group ---------------------------------------------------------------------------------------- 38
     The Systems Tables Group ---------------------------------------------------------------------------------- 38
What good is a GUID (Globally Unique Identifier) ------------------------------------------------------------ 38
  Component ID ------------------------------------------------------------------------------------------------------ 39
  Package Code ----------------------------------------------------------------------------------------------------- 39
  Product Code------------------------------------------------------------------------------------------------------- 40
  Upgrade Code ----------------------------------------------------------------------------------------------------- 41
  Upgrades ------------------------------------------------------------------------------------------------------------ 41
  Patches -------------------------------------------------------------------------------------------------------------- 43
Patch Dos and Don'ts ----------------------------------------------------------------------------------------------- 44
  Do: -------------------------------------------------------------------------------------------------------------------- 44
  Don’t: ----------------------------------------------------------------------------------------------------------------- 44
  Permissions--------------------------------------------------------------------------------------------------------- 53
  Setting Permissions ---------------------------------------------------------------------------------------------- 54
     Setting permissions on Registry Keys -------------------------------------------------------------------- 54
     Setting permissions on Directories ------------------------------------------------------------------------- 54
     Setting permissions on a File -------------------------------------------------------------------------------- 55
The Registry – Intermediate Level ------------------------------------------------------------------------------- 55
  Introducing the Registry ----------------------------------------------------------------------------------------- 55
     Class IDs --------------------------------------------------------------------------------------------------------- 57
     ProgID------------------------------------------------------------------------------------------------------------- 57
     The AppID Subkey (HKCR\AppID) ------------------------------------------------------------------------ 58
     Interface Subkey (HKCR\Interface) ------------------------------------------------------------------------ 58
     Type Library definitions (HKCR\TypeLib) ---------------------------------------------------------------- 58
     HKEY_LOCAL_MACHINE (HKLM) ------------------------------------------------------------------------ 59
     HKEY_LOCAL_MACHINE \ HARDWARE --------------------------------------------------------------- 59
     HKEY_LOCAL_MACHINE \ SYSTEM -------------------------------------------------------------------- 59
     HKEY_LOCAL_MACHINE \ SECURITY ----------------------------------------------------------------- 60
     HKEY_LOCAL_MACHINE \ SOFTWARE---------------------------------------------------------------- 60
     HKEY_CURRENT_CONFIG (HKCC) --------------------------------------------------------------------- 60
     HKEY_USERS (HKU) ----------------------------------------------------------------------------------------- 61
  Registry Data Types ---------------------------------------------------------------------------------------------- 61
  Learn how the Registry is organized and managed ------------------------------------------------------ 63
     Hives -------------------------------------------------------------------------------------------------------------- 64
  USING COM REGISTRATION TABLES IN WISE -------------------------------------------------------- 65
                                                                                Windows Installer Technology

     What is COM? -------------------------------------------------------------------------------------------------- 65
     Self-Registration ------------------------------------------------------------------------------------------------ 65
     Why we use COM registration tables instead of self-registration ----------------------------------- 65
     COM Registration Tables Group --------------------------------------------------------------------------- 66
  IMPORTANT - Helpful Tips ------------------------------------------------------------------------------------- 76
What is an .INI File? ------------------------------------------------------------------------------------------------- 77
  Format of .INI Files ----------------------------------------------------------------------------------------------- 77
  INI Files Page ------------------------------------------------------------------------------------------------------ 78
  Adding / Editing (INI) files --------------------------------------------------------------------------------------- 78
     LAB – Create a New INI File -------------------------------------------------------------------------------- 79
     LAB - Make Changes to an Existing INI File------------------------------------------------------------- 80
     LAB - Delete an Existing INI File --------------------------------------------------------------------------- 80
Services ---------------------------------------------------------------------------------------------------------------- 80
  Controlling Services on the Destination Computer -------------------------------------------------------- 81
     LAB – Create a Service --------------------------------------------------------------------------------------- 82
     Checking Service Name -------------------------------------------------------------------------------------- 84
     To Check a Service is running correctly ------------------------------------------------------------------ 85
Open Database Connectivity (ODBC) -------------------------------------------------------------------------- 86
  What is ODBC? ---------------------------------------------------------------------------------------------------- 86
  Purpose of ODBC ------------------------------------------------------------------------------------------------- 86
  ODBC Driver ------------------------------------------------------------------------------------------------------- 86
     Adding an ODBC Driver -------------------------------------------------------------------------------------- 88
     LAB - How to add an ODBC Driver to your installation? ---------------------------------------------- 89
  ODBC Data Source ----------------------------------------------------------------------------------------------- 90
     Adding an ODBC Data Source------------------------------------------------------------------------------ 90
     LAB - How to add an ODBC Data Source to your installation? ------------------------------------- 92
  ODBC Translator -------------------------------------------------------------------------------------------------- 94
     Adding an ODBC Translator --------------------------------------------------------------------------------- 94
     LAB - How to add an ODBC Translator to your installation? ---------------------------------------- 94
Merge Modules ------------------------------------------------------------------------------------------------------- 96
  When to make merge modules -------------------------------------------------------------------------------- 97
  Encapsulate files as much as possible ---------------------------------------------------------------------- 98
  Versions of Files --------------------------------------------------------------------------------------------------- 98
  Where are they used and what are the Advantages ------------------------------------------------------ 99
  When not to make Merge Module ----------------------------------------------------------------------------- 99
  Merge Modules - Their Relationship to MSI Files --------------------------------------------------------- 99
  Steps in Building a Merge Module --------------------------------------------------------------------------- 100
                                                                                 Windows Installer Technology

The AppSearch ------------------------------------------------------------------------------------------------------ 107
  Uses of AppSearch ---------------------------------------------------------------------------------------------- 109
     LAB – Performing an AppSearch using DrLocator ---------------------------------------------------- 109
     LAB – How to Remove a File using Appsearch -------------------------------------------------------- 117
     LAB – Performing an AppSearch using RegLocator ------------------------------------------------- 122
Transforms ------------------------------------------------------------------------------------------------------------ 123
  What is a Transform --------------------------------------------------------------------------------------------- 123
  What do Transforms do? --------------------------------------------------------------------------------------- 123
  Why use a Transform? ------------------------------------------------------------------------------------------ 123
  How do I apply a transform to an installation? ------------------------------------------------------------ 125
  Applying Multiple Transforms to an msi--------------------------------------------------------------------- 125
  Transforms – Types of Methods ------------------------------------------------------------------------------ 125
  Types of Windows Installer Transforms -------------------------------------------------------------------- 126
Conditional Logic ---------------------------------------------------------------------------------------------------- 127
  Conditions ---------------------------------------------------------------------------------------------------------- 127
     Conditional Statement Syntax------------------------------------------------------------------------------ 128
     Access Prefixes ------------------------------------------------------------------------------------------------ 129
     Logical Operators --------------------------------------------------------------------------------------------- 129
     Comparative Operators -------------------------------------------------------------------------------------- 129
     Substring Operators ------------------------------------------------------------------------------------------ 130
     Bitwise Numeric Operators --------------------------------------------------------------------------------- 130
  Where can you create conditions? --------------------------------------------------------------------------- 130
     1. Feature page ------------------------------------------------------------------------------------------------ 131
     LAB – Adding a Condition to a Feature ------------------------------------------------------------------ 131
     2. Launch Conditions ----------------------------------------------------------------------------------------- 132
     3. Conditions for Controls on Dialogs -------------------------------------------------------------------- 135
     4. Conditions attached to Components ------------------------------------------------------------------ 137
     5. Conditions for Actions------------------------------------------------------------------------------------- 138
  The Condition Builder ------------------------------------------------------------------------------------------- 139
     Values Types inside a Condition -------------------------------------------------------------------------- 140
  Condition - Checks if a Feature/Component is currently installed ------------------------------------ 142
     LAB – Building Condition that checks installed state of Feature/Component ------------------ 142
     LAB – Building Condition that checks if a Feature/Component will be installed --------------- 143
Dialogs ----------------------------------------------------------------------------------------------------------------- 144
  Introduction -------------------------------------------------------------------------------------------------------- 144
  Working with Dialogs -------------------------------------------------------------------------------------------- 145
  Types of Dialogs -------------------------------------------------------------------------------------------------- 146
                                                                            Windows Installer Technology

  Using the Dialogs Page ----------------------------------------------------------------------------------------- 147
  Creating New Dialogs ------------------------------------------------------------------------------------------- 149
  Setting an Event on a Control --------------------------------------------------------------------------------- 150




Overview of Windows Installer Technology

Windows Installer is a built-in Operating System service that manages the installed state
of an application. Prior to Windows Installer, software applications used various setup
technologies, each of which contained unique installation rules for each application. At
times, the applications did the wrong things at setup time. For instance, an earlier
version of a particular file might be installed over a newer version of that same file. Some
setup technologies made it difficult to maintain accurate reference counts on shared
components for the many applications installed on a computer. As a result, installing or
removing certain applications might break other applications.


Using Windows Installer, the operating system implements all of the proper installation
rules. To adhere to those rules and to avoid the problems described in the preceding
paragraph, an application needs only to describe itself in a Windows Installer package.
Windows Installer then performs the installation tasks for each application, which can
help you, prevent or minimize common installation problems.


Adding, Upgrading, or Deleting an Application Can Damage Other Installed
Applications


Prior to Windows Installer, adding, upgrading, or deleting an application can break other
existing applications on a computer — or worse, it can break the operating system.
There are many causes of this type of problem, and Windows Installer takes steps to
                                                               Windows Installer Technology

minimize them. A few of the ways Windows Installer solves such problems are detailed
in the following subsections.




Providing consistent and reliable version rules


Traditionally, software manufacturers delivered a unique setup program for each
application. When an application was added, modified, upgraded, or removed from a
system, the setup program enforced its own rules, such as providing version-control
directives. Because each setup program provided its own rules, interactions among two
or more applications sometimes caused conflicting results. For example, newer versions
of shared files might be replaced with older ones. As a result, applications that required
the newer version of the file were not successfully and completely installed. A failed
installation could cause other applications not to function.
You can avoid this problem by taking advantage of Windows Installer. Windows Installer
provides consistent and reliable installation for all applications, which prevents newer
files from being overwritten by older files.




Providing system-wide management of shared resources


Inter-application conflicts can occur when uninstalling one application removes files
shared by other applications on the computer.
Windows Installer addresses this problem by keeping track of the resources that
Windows Installer-based applications use. For example, several products include the
Grid Control for Microsoft Visual Basic®, which uses Windows Installer. After this control
is installed, Windows Installer detects its presence. When you install other products that
use the Grid Control, each product is added to the client list for the Grid Control.
Windows Installer references these client lists when installing, upgrading, or removing
components.
                                                             Windows Installer Technology

Windows Installer maintains and manages all setup and installation information about
each product it installs. When you uninstall a product, Windows Installer does not
remove any component that has other applications in its client list.

Windows Installer Technology


Windows Installer is an engine you can use to manage the state of an application. The
state of an application includes installation, modification, upgrade, or removal.
Windows Installer is not a software distribution technology. Software-distribution
technologies use Windows Installer to install and manage software applications.
Currently, most software distribution technologies rely on Windows Installer's command-
line capabilities to install and manage Windows Installer–based applications. The Group
Policy-based software deployment component of Windows .NET Server provides
enhanced benefits to administrators by using the advanced functionality in Windows
Installer.


The Windows Installer technology is made up of three elements that work together:
                Windows Installer client
                Windows Installer service
                Windows Installer package (an .msi file.)

Windows Installer Client
The Windows Installer client is any application that calls Windows Installer to perform a
task. Some common clients include the following:
       The Windows-based shell.

       Add or Remove Programs in Control Panel of Windows XP Professional and
Windows 2000 Professional.

   Windows Installer-enabled applications, such as Office 2000.

   Software distribution technologies, such as Systems Management Server (SMS) and
the software installation component of Group Policy included Windows .NET Server and
Windows 2000 Server.
                                                           Windows Installer Technology

The Windows Installer client is responsible for user interactions such as displaying the
Setup user interface during an installation. For example, the Windows Installer client
uses the Windows Installer service to change the computer state by copying files and
writing registry changes. Earlier approaches required each application vendor to deliver
a unique program for each installation state change for every application.

Windows Installer Service

The Windows Installer service uses information in a Windows Installer package file to
manage all phases of installing a program-- add, change, upgrade, and remove. The
Windows Installer service performs all installation-related tasks as needed by copying
files onto the hard disk, making registry modifications, creating shortcuts on the desktop,
and displaying dialog boxes to capture user installation preferences.


Note: The Windows Installer service is part of the Windows XP Professional, Windows 2000
Professional, and Windows Me operating systems and is available for the Windows 95,
Windows 98, and Windows NT 4.0 operating systems.


You can find this Service by going to

Start  Settings  Control Panel  Administrative Tools  Services  Windows
Installer
Below Fig shows the location of this service.
                                                           Windows Installer Technology




Windows Installer Packages

Each Windows Installer package (.msi) file contains a database that stores all the
instructions for the Windows Installer service and data required to manage the state of a
program, such as adding, changing, or removing it from a computer. For example, an
.msi file of an application can contain instructions for installing the application when a
prior version of the application is already installed. The .msi file could also contain
instructions for installing the software on a computer where that application has never
been present. To simplify creating and customizing .msi files, setup program authoring
tool vendors have developed various authoring tools for Windows Installer.
. Figure 1 illustrates an example of the contents of a typical Windows Installer package.
                                                               Windows Installer Technology




Figure 1 Contents of a Windows Installer package


Whereas existing installers use procedural scripts to deliver a disjointed collection of
files, registry keys, and other resources, the Windows Installer service views all
applications as three logical building blocks: components, features, and products.



Let us understand these three concepts in detail.

First, a note on terminology : an installable resource (resource hereafter) is defined as a
file, registry key, shortcut, or any other piece that an installer typically delivers to a
computer.

     Windows Installer Components

A Windows Installer component is the smallest and most fundamental of the three logical
containers. A component is a collection of files, registry keys, and other resources that
are all installed or uninstalled together. When a given component is selected for
installation or removal, all of the resources in that component are either installed or
removed. Components are the building blocks that are not exposed to the user; only the
setup developer needs any knowledge of which components make up a given
application.

A given resource can be part of only one component. For example, no two components
                                                            Windows Installer Technology

will share the same file, whether they are part of the same product or parts of different
products. Because of this restriction, components are usually small, consisting of a file
and other resources that are very tightly coupled to it such as registration information. A
component can be said to own its resources.




     Windows Installer Features

The Windows Installer features are the granular pieces of an application that a user can
choose to install, and typically they represent the functional features of the application
itself. When a user chooses Custom in a setup program today, the pieces of the
application they are able to select for installation correspond roughly to features.

Essentially, features are groupings of components. It is instructive to view a feature as
merely a convenient way to select a group of components for installation. In addition,
features can also contain other features—this allows applications to be hierarchically
organized. For example, the Microsoft Word feature within Microsoft Office might contain
a sub-feature such as Proofing Tools. When a given feature is selected for installation,
all of its components are selected for installation.

The Windows Installer service performs all of its management at the component level,
thus eliminating the need for a feature to have exclusive ownership of its components.
Two features , whether from within the same application or from different applications,
can share a given component without affecting the Windows Installer management
scheme. Similarly, it is not necessary for a feature to be globally unique; therefore, they
do not have globally unique identifiers.

Whereas existing installers typically give the user a binary choice between “installed”
and “not installed” for a given feature, the Windows Installer features can be set to one of
four states:

   Installed on Local Hard Disk—files are copied to the local computer’s hard drive.
   Installed to Run from Source—files are left on the source (typically a CD or a network
    share). The application accesses the files from the source.
   Advertised—files are left on the source, but they can be automatically copied down
    the first time they are used. Advertising is explained in the “On Demand Install”
    section of this document.
                                                                                           Windows Installer Technology

      Not Installed—no files are copied.



         Windows Installer Products

A Windows Installer product represents a single product such as Microsoft Office.
Products consist of one or more Windows Installer features. Each product is described to
the Windows Installer service in the form of a single package file (*.msi file). Products do
not directly own any resources, but they do have globally unique identifiers known as
Product Codes. These Product Codes enable the Windows Installer service to uniquely
identify applications that are clients of a given component (the Windows Installer service
maintains a list of client products for each component) and to quickly determine if a given
product is already installed on a particular computer.

Using a simplified version of Microsoft Office as an example, the following diagram
illustrates the relationships between Windows Installer components, features, products,
and resources.

                                                              Product
                                                          Microsoft Office



                  Feature 1                                                   Feature 2                        Feature 3
                    Word                                                        Excel                         Powerpoint



      Feature 4                  Component 1                             Component 2                         Component 3
       Speller                    Word core                               Excel core                        Powerpoint core



    Component 4
                         Winword.exe           Shortcut          Excell.exe               Reg Key   Powerpnt.exe       Powerpnt.dll
    Speller engine




       Mssp.dll




Feature of Windows Installer Service
                                                             Windows Installer Technology

Advertising

The installer registers the application, creates shortcuts and menu entries, associates
file types etc. without actually copying the application files to the user's hard drive. If the
user or another application tries to access the advertised program, it is installed on
demand. In this case the invoking of the installer is handled by the operating system.

Installation on demand

This is quite similar to Advertising. However it doesn't refer to a whole application, but to
a feature or function that is called from inside the application (e.g. an import filter). When
the application tries to access the feature and finds that it isn't present, it calls the
installer service to install it just in time. These way users don’t have to anticipate the
functionality they need before they ever used the product. Requirement: The application
must be modified to call the Windows Installer API.

Repair

When launching an application, all the key paths are checked, they can be either files,
registry entries etc. If any of them is missing or damaged, the complete feature (all files
and registry entries are part of a component which in turn is a part of a feature) installed
again.

Elevated privileges

Setup runs with Administrator privileges even if it is launched from a normal user
account.

Rollback

The installer records all changes it makes to the system, and creates temporary backup
copies of overwritten and removed files. If setup is aborted, the system is reverted to its
previous state. After the setup is finished successfully, the rollback information and
backup files are deleted to save disk space. (Do not confuse this with un-installation).



Merge Modules
                                                            Windows Installer Technology

You can deliver run-time components (e.g. VB Runtime) or operating system updates by
importing a merge module (.msm file) into your installer package. This avoids the
problems with having to launch external third party setups or mimic their behavior.


Merge Modules are mostly created for the COM Servers and other files which are getting
installed in the shared locations like WINDOWS, System32, and COMMON FILES
folders.


When a merge module is merged into the .msi file of an application, all the information
and resources required to install the components delivered by the merge module are
incorporated into the application's .msi file. The merge module is then no longer required
to install these components and the merge module does not need to be accessible to a
user. Because all the information needed to install the components is delivered as a
single file, the use of merge modules can eliminate many instances of version conflicts,
missing registry entries, and improperly installed files.


       Side-by-Side Sharing of Components

Windows 2000 and Windows 98 Second Edition introduce another measure to avoid
version conflicts with shared DLLs (also called as "DLL Hell"). It is now possible to load
several versions of the same file into memory. By this method, files like COM servers are
no longer copied to a common location but to the application directory. This requires
modification of the application to enable it to load components from the application
directory, and modifications to the component to avoid conflicts with other instances of
the same file. And of course such a component must be registered in a special way,
which can be done with the Windows Installer. This also avoids the need for a reboot,
because a component located in the application directory will not be in use (locked) by a
different application.

Side-by-Side Sharing of Components

Windows 2000 and Windows 98 Second Edition introduce another measure to avoid
version conflicts with shared DLLs (also called as "DLL Hell"). It is now possible to load
several versions of the same file into memory. Microsoft recommends that files like COM
servers are no longer copied to a common location but to the application directory. This
requires modification of the application to enable it to load components from the
                                                             Windows Installer Technology

application directory, and modifications to the component to avoid conflicts with other
instances of the same file. And of course such a component must be registered in a
special way, which can be done with the Windows Installer. This also avoids the need for
a reboot, because a component located in the application directory will not be in use
(locked) by a different application.

Transforms

Transforms can be used to customize installation, e.g. to deploy different configurations
of an application to different departments in a company, to localize a product, or to apply
upgrades. The Transform does not change the actual installer package. Instead the
installer database is loaded into memory, then the transform is applied to this database
and finally the installation takes place.

Advantages:


      Only one installer package that can be reused; Transform only includes unique
       modifications
      When installer package is updated (new version of application) Transform can be
       re-used without changes (at least in theory)

Patching and Upgrades



An application that has been installed using the Microsoft® Windows® Installer can be
upgraded by reinstalling an updated installation package (.msi file), or by applying a
Windows Installer patch (an .msp file) to the application.


Servicing applications by delivering a Windows Installer patch, rather than a complete
installation package for the updated product can have the following advantages:


      A patch can contain an entire file or only the file bits necessary to update part of
       the file. This can enable the user to download an upgrade patch that is much
       smaller than the installation package for the entire product.
      An update using a patch can preserve a user customization of the application
       through the upgrade.
                                                             Windows Installer Technology

A Windows Installer patch (.msp file) is a self-contained package that contains the actual
updates to the application and describes which versions of the application can receive
the patch.

Small Update

       Only few files have to be changed.
       Version number and product GUID stay unchanged.
       Typically shipped as binary patch.
       Example: Bug fix, service pack

Minor Upgrade

       Version number is incremented, but product GUID stay unchanged.
       Typically new features are added.
       Example: New version of application.

Major Upgrades

       Product GUID is changed.
       Applying the upgrade results in a new product
       Example: Upgrading MS Works to MS Office.


Components

A component is the smallest installation unit for the Windows Installer Service. It is a
collection of installable resources or just resources. A resource is a file, registry entry,
shortcut, type library or the like.


Components are commonly hidden from the user. Whenever a user selects a feature for
installation the Windows Installer Service determines which components are required


When a component is installed everything that comprises the component is installed and
like-wise when a component is uninstalled so too is everything that comprised it
                                                           Windows Installer Technology

The Windows Installer Service identifies a component by its unique GUID. The Windows
Installer looks for a component’s keypath in order to check whether the component is
installed correctly


       A keypath is normally one of the files that comprises the component but can also
be one of the registry entries associated with the component


       The keypath defines the location of the component on the system. If the keypath
for a component is missing, the Windows Installer treats it as broken and tries to take the
necessary steps to repair it


Because components are commonly shared by more than one application or product
they must be correctly organized in your application. There are a number of strict rules
that must be followed when creating the components:



Some Rules of Organizing Applications into Components


Proper ‘componentization’ guarantees that all resources that define a component are
removed with no orphaned resources left behind. These rules are listed below:-


 All files in a component must be installed into the same directory


 No one file can be included in more than one component (NOTE: this can happen
only if file is going to different locations).




 Every component must have only one KeyPath – either a file or registry key or the
folder in which the component resides. All versioned files .exe, .DLL, .OCX, files and
those that are the targets of advertised shortcuts, must be the KeyPath of a component


 Every .EXE, .DLL, .OCX, .HLP and .CHM file should be in its own component and
these files should be the keypath for the component
                                                               Windows Installer Technology



 There can be only one file that is a target for a Start Menu or desktop shortcut in
each component. This means that every file that serves as the target of a shortcut has
to be in it’s own component



Common Component Errors


 Component has an empty key path but contains files, registry entries, or ODBC data
sources. (component highlighted in red)
 Component has more than one executable. (.EXE,.DLL,.OCX)
 A shortcut is assigned to the component, but the key path for the shortcut is not a file
 Registry keys are created in HKEY_CURRENT_USER, but the key path is not for a
registry key in HKEY_CURRENT_USER



What are Isolated Components


The new functionality of Windows 2000 and Windows 98, which permits an application to
have a private copy of a COM component, has been implemented in the system loader.
The system loader looks for a file with the extension local in the application folder and if
it finds this file it alters its search logic to prefer DLL’s that are located in the same folder
as the application.



How do you use Isolated Components


Sharing components among various applications has been one of the major benefits of
Microsoft Windows. However, the ever-increasing number of applications requiring
special versions of these shared components has created a condition known as “DLL
Hell”.


In this situation (DLL Hell), different applications need different versions of the same
component. The original concept of sharing components was that each component
                                                            Windows Installer Technology

would be completely compatible with previous versions and thus a newer version of a
component would never cause an application dependent on an earlier version to fail.


In reality, sadly this is not often the case as there are many instances of a newer
component version breaking an application that was previously successful using the
earlier version
Windows XP/ 2000 and Windows 98 second edition have a new functionality that allows
different versions of the same component to reside in memory at the same time.


This enables what is called “side-by-side sharing” and is a huge step towards eliminating
DLL Hell. The concept of side-by-side DLL components occurs when one version of the
component runs in one process while the other component version runs in another
process. This new approach to component sharing applies to both COM DLL’s and
WIN32DLL’s.



Isolate Components Action

How it works


The Isolate Components action installs a copy of a component (commonly a shared
DLL) into a private location for use by a specific application (typically an EXE)



Why do this?


This isolates the application from other copies of the component that may be installed to
a shared location on the computer (like the systems folder).



How does the action operate?


The action refers to each record of the Isolated Component Table (located in the Setup
Editor - Tables tab) and associates the files of the components listed in the Component-
Shared column with the components listed in the Component-Application column. The
                                                           Windows Installer Technology

Installer installs the Component-Shared files into the same directory as Component-
Application. The installer generates a file in this directory, zero bytes in length, having
the short filename of the key file for component-application (usually this is the same
name as the EXE) appended with '.local'.



Component sharing


Shared Components are components which will be used by other applications and
contain files with .DLL, .OCX, .TLB, .OLB, .EXE extensions and any relevant support
files (.HLP) or registry information. They are generally files which have been developed
by Microsoft or other third parties to provide functionality which is used by several
applications.


For example:
Microsoft’s MSJET35.dll is a file that is used by several applications to connect up to an
Access Database. Existing installers manage shared files by maintaining a shared
reference count (refcount) for each shared file in the system registry and by not
removing a file until that refcount reaches zero. Since Windows Installer maintains a
refcount at the component level these resources are more efficiently managed.


Since the Windows Installer service maintains a shared count at the component level
rather than at the file level, and because components are atomic units, a proper refcount
is maintained for all resources. The Windows Installer service does not remove a
component unless there are no remaining applications that are depending on that
component.

The Windows Installer maintains component refcounts in the form of a client list of
product codes (rather than integers). This means that the Windows Installer can identify
clients of the resource and keep counts synchronized.

The Windows Installer service model for installation and removal is much simpler than
the procedural method used by traditional installers. Existing installation technologies
lack the notion of components, they use different procedures for installation and removal,
and they cannot perform a refcount of non-file resources. As a result, they typically leave
many resources behind on the computer after an application is uninstalled or removed.
                                                          Windows Installer Technology

The Windows Installer service, by contrast, has a much cleaner model. Because
Windows Installer service can accurately track what a given component has installed
and when that component can be removed, applications installed using the Windows
Installer service can be uninstalled much more cleanly.


Note:
Disadvantages of Component Sharing may be minimized by Isolated Components
operating Side-by-side sharing.



Properties


Properties are variables used by Windows Installer during installation. The list of
Properties is found under the Product tab in the Setup Editor of Wise for Windows
Installer.



Five Ways to Set a Property


1. The author of the MSI can add his or her own properties in Properties, found under
the Product tab in the Setup Editor of Wise e.g. INSTALLDIR


2. Properties can be set at the command line. To set a property at the command line
uses the shown command line. This is only possible for public properties, these are
always in capital letters:
Msiexec /I <your.msi> <PROP> =”Your Value”                 e.g. ALLUSERS =1


3. Wise automatically sets certain properties. An example of an automatically installed
property would be installation dialog boxes; Wise defaults to a certain series of dialog
boxes for the installation of every MSI


4. Some properties are set by Windows Installer according to the configuration of the
Destination computer.
                                                          Windows Installer Technology



5. Properties can be set up so that the values are derived from the input of users. A
dialog box is offered to the user and the results become the value of the property



Categories of Properties


There are three categories of properties as defined by Windows Installer documentation:
   Private properties
   Public properties
   Restricted public properties.


Restricted public properties are only relevant on locked-down Windows NT, Windows
2000, or Windows XP computers


Private properties cannot be changed from the command line, neither can they be
passed from the UI Sequence (the period of the install when dialog boxes are displayed,
user choices are made, system information gathered) to the Execute Sequence (the
period when the program is actually installed). This means that private properties are
more secure. Properties are made private by using some lowercase letters in the name
of the property.


Public Properties can be changed from the command line and passed from the UI
Sequence to the Execute Sequence. For a property to be public, it must contain no
lowercase letters.


Restricted Properties. The author of the MSI may want to limit the ability to change
some public properties i.e. not want the user to change them. When the ‘Add to the list
of restricted public properties’, box is checked within a Property it can only be changed
by the System Administrator (Note that this is only relevant on Windows NT/2000
systems).
                                                              Windows Installer Technology

Most Important WFWI Properties


The following list is a collection of common Wise for Windows Installer Properties. The
properties are listed below with a brief description of what each property does:


1. INSTALLDIR – This is the property/directory that holds the location where the main
application will be installed. Generally, this is the location of the first directory created in
your install when using the Installation Expert


2. TARGETDIR         –   This property specifies the root destination directory for the
installation.


3. ALLUSERS – This property is set to a value of 0, 1, or 2. The property determines if
shortcuts are installed to the current user's profile or to the All User's Profile on Windows
NT and Windows 2000 platforms


4. REBOOT – This property is set to a value of Force, Suppress, or ReallySuppress.
This property allows the user to force a reboot at the end of the install or suppress a
required reboot to varying extents


5. APPS_TEST – This property, when set to 1, allows the user to make use of the
DRLocator table and RegLocator table with the AppSearch table to search for and
retrieve files paths or registry key values


6. SystemLanguageID – This property holds the value of the current language code
the operating system is running


7. VersionNT –        This property contains the current version number of an NT based
operating system
                                                            Windows Installer Technology

8. Intel/Alpha – These properties identify the type of processor used in the current
machine. A numeric value is used to represent each different processor type (such as 4
for 486, 5 for Pentium, 6 for Pentium Pro/II/III)


9. Time – This property holds the current local system time


10. Date – This property holds the current local system date


11. AdminUser – This property is set if the current user has administrator privileges on
the local machine


12. INSTALLLEVEL - This property contains the current installation level (stored as a
numeric value). The Windows Installer will install all features whose level attribute is less
than or equal to the value in INSTALLLEVEL


13. ProductCode - This Property is a unique identifier for the particular product release,
   represented as a string GUID.


14. ProductLanguage – This Property specifies the language the installer should use
   for any strings in the user interface.


15. Manufacturer -- is the name of the manufacturer of the product.


16. ProductVersion – is the version of the product in a specified string format.


17. ProductName – contains the name of the application being installed, for example,
   Microsoft® Office 97. This is only used for display purposes.



Creating Properties


Properties are found under the Product tab in the Setup Editor.
                                                             Windows Installer Technology

1. To create a new property, right click on Properties and select New > Property from
the menu


2. In the dialog box that opens, enter the Name of the property (Properties can contain
only letters, numbers, underscores (_) or periods and must begin with a letter or number)
and assign the property a value (you must enter an initial value for the property as the
table cannot hold an empty/blank value)
If you wish the property to be a restricted public property, check the relevant box – note
that the box will not be available should there be any lowercase text in the Name box.



Editing Properties

To edit a property, right click on that property and select Details.

Deleting Properties
Delete a property by right clicking on that property and selecting delete from the menu.


LAB - Reading a Registry Value to a Property



In this exercise we will create a registry entry containing your name. Once completed,
we will check the result by running regedit to check this entry has been created
correctly.

    1. Select Installation Expert ► Target System - System Search page, click on the
        Add button and select Registry.

    2. In the Read Registry Value dialog box, enter the name of the Property you wish
                                                             Windows Installer Technology

        to set (select from the drop down list or create a new property name).




     3. Select the Operation type using the drop down list. In this case we are looking
        for the registry value so choose “Read raw value from registry”.

     4. Select appropriate Root using the drop down list.

     5. Fill in Key field using the name of the key. This is the key path minus the Root.
        Do not use a leading or trailing '\' symbol in this field; the Windows Installer will
        make the necessary substitution at runtime.

     6. Fill in the Value Name. This is the text that is in the Name column of the right
        hand section of the Regedit tool.

     7. To check process worked – display result in dialog box by using property name.
        It should display the registry value.



LAB - Using a Property to Remove a File at Install Time


During an installation, you might want to remove existing files from the destination
machine. One reason to do this is to save disk space. Another reason is to avoid
possible file conflicts between a previous installation and a new installation. This clean
up helps prevent errors during installation.


To set up your installation to remove an existing file (such as c:\Program Files\myfile.txt)
from         he        destination          machine,        follow       these        steps:


Create or open an installation in Wise for Windows Installer (e.g. WinZip.wsi)


1.     Go to the Components tab in Setup Editor.

2.     Add an empty component by right-clicking the Components icon and selecting New
       > Component.
                                                            Windows Installer Technology

3.    In the Component Details dialog box, enter a name, such as ABC, in the
      Component field.

4.    Leave the remaining fields set to their default values, or set them specific to your
      installation. Click OK.

5.    Go to the Feature tab in Setup Editor. Choose a feature to associate with this
      component. To ensure that this component is installed, choose a feature that is
      always installed.

6.    In the left pane, right-click the feature you chose and select
      New > Component Assignment.

7.    In the Assign Components to Feature dialog box, click the name of the empty
      component you added in the first step. For example, click ABC. Click OK.

8.    Go to the Product tab in Setup Editor.

9.    Right click the Properties icon and select New > Property.

10.   In the Property Settings dialog box, enter a property name, such as XYZ, in the
      Name field.

11.   In the Value field, enter the directory path on the destination machine that contains
      the file you want to delete. For example c:\Program Files.

12.   Click OK.

13.   Go to the Tables tab in Setup Editor. In the left pane, right-click RemoveFile and
      select New > Row to create a new row.

14.   In the new row that appears in the right pane, enter the following fields:

           FileKey: Enter any value, for example, TEST.

           Component: From the drop-down list, select the name of the empty
           component that you created, such as ABC.

           FileName: Enter the name of file you want to delete, for example, myfile.txt.
                                                          Windows Installer Technology



           DirProperty: Enter the name of the property that contains the file pathname
           as a value, for example XYZ.



           InstallMode: Enter one of the following (we recommend entering 3):
           1=Remove only when the associated component is being installed.
           2=Remove only when the associated component is being removed.
           3=Remove in either of the above cases

15. Compile and run your installation.

       When the user runs this installation, the file c:\Program Files\myfile.txt will be
removed.



Environment Variables


Environment variables are system or user variables that are set by the operating system
running on the destination computer. They contain values specific to that computer.


The Environment Variable icon, located on the Features and Components tabs in Setup
Editor, lets you add environment variables and values to be set by the operating system
on the destination computer. You can also change properties for selected environment
variables and delete them.


LAB – Add a New Environment Variable


1.     On the Features tab in Setup Editor, right-click the feature to which you want to
       add the environment variable.
2.     From the right-click menu, select New > Environment Variable. The
       Environment Variable Details dialog appears.
3.     In the Name field, enter a name for the environment variable.
4.     In the Value field, enter a value for the new environment variable.
5.     In the Operation field, set how to handle the variable on installation and un-
                                                              Windows Installer Technology

        installation.
6.      In the Replacement field, set how an existing value for the variable is handled.
7.      Mark the Windows NT/2000/XP system environment variable checkbox if this
        is a Windows NT/2000/XP system environment variable. Click OK.




The environment variable is listed in the upper right pane. To edit an environment
variable you are creating, double-click its name.


IMPORTANT: Operation should state ‘Set value on install and delete on uninstall’
NOTE:
This procedure above lets you create a new environment variable. If you want to read
the value of an existing environment variable into a property, use the Set Property type
of custom action to read it into a property. Enter [%ENVIRONMENT_VARIABLE_NAME]
in the Property Value field on the Details tab of the Set Property dialog while making the
action (brackets required).


Check paths on Install and Uninstall to ensure it does not break the System path.
Two ways of checking:
     1. Right click on MyComputer – Properties – Advanced – Environment Variable
     2. Go to MSDOS Command prompt – Type Run CMD Set or Run CMD SetPath
        (CMD set will give a list of all Environment variables)
        NOTE: On NT4, especially, when checking paths in command prompt it appears
        to be still missing after install – you may need to reboot for it to appear.
                                                           Windows Installer Technology

Manually Adding Entries into the Environment Table


Below is a description of what should be input into each table:




Environment          Name             Value                              Component


Newpath              *=-Path          [~];[INSTALLDIR]program.exe Program.exe
Newpath1             =-Path           [~];[INSTALLDIR]program.exe Program.exe


Environment Column


This is used to set the name for the table’s primary key, you can call it anything it must
be unique


Name Column


This is used for us to define the name of the variable we would like to set, in this case,
we are setting Path, and this is a commonly found Environment Variable and is found on
every windows system.
*=-Path        – this means System Environment Variable
=-Path         – this means we are setting a User Environment Variable


The “–“this means to remove the variable on uninstall, so if I had “=Path” this would me
to leave the variable behind.


Value Column


This allows us to set the Value we would like to add in the Environment Variable.
[~]; if this is at the beginning of the value this symbol means append to path.
         i.e. [~];[INSTALLDIR]program.exe
If the symbol is at the end, it means to Prefix.
i.e. [INSTALLDIR]program.exe; [~]
                                                            Windows Installer Technology

And finally if the symbol is not there at all it will Replace the environment Variable with
the value you inserted
i.e. [INSTALLDIR] program.exe


Component Column


In this column you set the variable to a component in your application. It is always better
to select the component that the Variable is associated to.
For Example -
In the example above we were setting “program.exe” in the Path Variable and we set the
component to “Program.exe”



The Installation Databases

The Tables Tab in Setup Editor lists every table in the MSI database. We can edit
existing table data, add new data and add new tables.


There are 79 native tables defined in an MSI database. The tables can be grouped into
10 related groups. Some tables will fall into more than one group so as to provide a link
between groups.


To create an installation database we need to populate the tables with relevant
information pertaining to the application and the installation process.



What is the Installation Database?


The Installation Database is a set of relational tables that are linked together through the
data in various primary and foreign keys.


The database tables reflect the general layout of the application including the features
that will be available on it, the components contained in its make-up, the relationship
                                                             Windows Installer Technology

between these features and components, the necessary files and registry settings and
the sequence table where these actions/events are ordered.
The tables in the MSI database can be considered to fall into 10 related groups. The
following table illustrates these groups and gives a brief description of what each group
does:-


Group Name                                                                         No. of
                            Description
                                                                                   Tables
Core Tables                 The Core Tables are concerned with the basic           7
                            features and Components that make up the
                            application for which the Installation Package is
                            being created
File Tables                 These Tables basically define all the files that       16
                            make up the application. It also contains the
                            actions to be taken in relation to these files as
                            well as Tables that are concerned with items like
                            icon files and INI files that need special attention
Installation Procedure      As the group names suggests. These Tables              13
Tables                      contain information that will be used to control
                            the tasks performed during the installation
Locator Tables              Again, as the group name implies, these tables         6
                            hold the information needed to locate files and
                            applications on the client machine when the
                            installation is executed.
NT Service Tables           Set the Parameters required for both installing        2
                            and controlling NT services.
ODBC Tables                 Tables in this group contain all the necessary         5
                            information required to install ODBC drivers or
                            data source/translators on a system.
Program Information         The 5 tables related to this group, all contain the    5
Tables                      information that will be needed during the
                            installation of an application
Registry Tables             This group contains all information pertaining to      16
                                                             Windows Installer Technology

                              the registry. The information for making the
                              various types of registry entries by COM
                              Components, MIME Types, Prog ID’s etc are all
                              contained in these tables.
System Tables                 This group of tables track the tables, columns      6
                              and information in the other tables of the
                              Installation Database
User Interface Tables         As the name suggests this group of tables           14
                              contains the data that is used to create the User
                              Interface (Displays, Dialog Boxes) displayed
                              during an Installation, repair or Uninstallation.



Core Tables Group


Core Tables Group consists of tables describing the fundamental features and
components of the application and installer package.


        The Feature Table lists all features belonging to the application
        The Condition Table contains the conditional expressions that determine
whether or not a particular feature will be installed.
        Feature Components Table describes which components belong to which
feature.
        The Component Table lists all the components belonging to the Installation.
        The Directory Table lists the directories that are needed during the installation.
Because each component can have one and only one directory associated with it, the
components table is closely related to this table and has an external key to the directory
table.
        The Publish Components table lists the features and components that are
published for use by other applications
                                                           Windows Installer Technology

File Tables Group




Locator Tables Group


Locator Tables Group is used to locate files in applications. In order to search for a file
we must determine the file signature and then locate the file. The Locator Tables search
                                                               Windows Installer Technology

the registry, directory tree, Installer configuration data or INI files for the unique signature
of a file. In order for the locator to know that we are seeking the right file and not another
with the same name the File Signature is checked in the Signature table.


       RegLocator Table searches the registry for the specific File.


       INILocator contains data needed to search for an INI file


       CompLocator Table has the necessary information contained in it that enables it
to search for a file or directory using the installer’s configuration data


       DrLocator Table contains the information needed to search for a file or directory
in the directory tree


       AppSearch Table holds the properties that must be set to the search result or a
corresponding file signature.


       CCPSearch Table Has a list of file signatures of which at least one will be
required to be present on a user’s machine for the compliance checking program (CCP)


       Signature Table Has a list of file signatures which is normally the path of the file
to be located.



Registry Tables Group


This group of tables is concerned with the registry and in particular with the registry
entries. It is important to note that the installer has specific tables for the different types
of registry entries


We should always try to minimize the number of entries put into the registry table and
instead use other more specific registry tables. Why (you might ask)? This is because
the installer can have difficulty distinguishing between different types of registry entries
in the registry table and it will be easier for it to identify them in more specific tables.
                                                           Windows Installer Technology



Some of the following tables are contained in the Registry Tables Group:


       Typelib Table Provides the information required by the installer for the
registration of type libraries


       Class Table Registers Class ID’s and other information for COM objects


       ProgId Table Associates Program Id’s with Class Id’s


       The Registry Table Holds the information that the application needs to put into
the system registry. Things like default settings, user data or COM settings


       Remove Registry Table Holds the information the application will need as to
know what to delete from the system registry at the time of Installation


       SelfRegTable Provides information needed to self-register modules.         Self-
registration offers backward compatibility but is not recommended as a method for
populating the registry


       Environment Table is used to set the values of environment variables, and in
Windows NT/Windows 2000 the Environment table writes to the registry as well
Windows Installer Technology
                                                          Windows Installer Technology




Registry Tables Group

The Systems Tables Group


The Systems Tables Group tracks the tables and columns of the installation database
and contains the following tables:


      The _Validation Table tracks the types and ranges that are allowed in every
column in the database. This table is mainly used for validation purposes and ensures
that all columns are accounted for and have correct values. This table is not shipped
with the installer database.



What good is a GUID (Globally Unique Identifier)

Windows installer makes heavy use of these almost unreadable alphanumeric strings in
curly braces, also known as "GUID", like this:


       {50EFC3E0-8AF8-11D4-94C7-00E09876D9C4}


GUID is the abbreviation for Globally Unique Identifier. It is a 128 bit number,
represented as a string of hexadecimal digits. There is an operating system function that
can create such unique numbers. To a "very high degree of certainty" (as Microsoft puts
it), this function returns a unique value – no other invocation, on the same or any other
system, should return the same value. To ensure uniqueness across machines, the ID of
the network card is used (among others) to compute the number. Therefore it is
advisable that your development machine be equipped with a network card; else there is
a slight chance that another computer could generate an identical GUID.
                                                          Windows Installer Technology

GUIDs are nothing new. For instance they are used to identify classes, objects and
interfaces in ActiveX applications. However Windows Installer has introduced a new
requirement for GUIDs: While tools like Visual Studio often use lower case letters to
represent hex digits, GUIDs used in Windows Installer must be in all upper case
characters.


The sections below describe some of the locations where GUIDs are used, and why it is
vital to have identifiers that are unique across development teams and companies.



Component ID


Components are the building blocks of an msi package. They can include files, registry
entries and shortcuts. The Windows Installer reference counting mechanism is based
on this component code: Two components that share the same component ID are
treated as multiple instances of the same component regardless of their actual content.
Only a single instance of any component is installed on a user's computer. Therefore, no
file, registry entry, shortcut, or other resources should ever be shipped as a member of
more than one component. This applies across products, product versions, and
companies. If you can't guarantee this rule, you must isolate this resource as its own
component and set its "shared" flag to "yes". The same should be done if the file is also
used in legacy setup packages that don't use the Windows Installer service.


If you change the component ID, you must also change the names and/or locations of all
included resources, and vice versa: if you change the name of an application file, you
must also change its component ID.



Package Code


As the name implies, the package code identifies a specific msi file – (IMPORTANT: not
a product, but an msi file). No two msi files that are not identical copies of each other
should ever have the same package code, even if they install (different versions of) the
                                                           Windows Installer Technology

same product. Windows Installer keeps copies of all installed msi files in a cache. If you
start a Windows Installer setup, the runtime engine first checks to see if an msi file with
the same package code already exists in the cache, and uses this copy instead. So
whenever you rebuild your msi file you should give it a new package code. You must do
this for each package that you release to a customer.


To change the package code, go to the Setup Editor – Product Tab - Summary, put the
cursor in the Package Code field, and press the "Generate GUID" button.



Product Code


This code should only be changed if significant changes are made to the application -
changes that warrant calling it a different product. If you are just releasing a new version
of your program, the product code should not be changed. Of course, two different
products should never have the same product code. If you have two flavors of a product,
say "YourApp Express" and "YourApp Professional", these should have different product
codes. The same is true for different language versions of a program - they must use
different product codes. Windows Installer cannot install two instances of the same
product (i.e. two msi packages with the same product code) on the same machine.


Using different product codes is required to allow two applications to coexist on the
same computer. If you try to install two msi packages with different package codes, but
with the same product code, you will get an error message as shown in figure 1:




       Figure 1: Reinstallation error message
                                                           Windows Installer Technology




Upgrade Code


All applications in a product family shared the same upgrade code. Such a group of
related applications can consist of different versions and different language versions of
the same product. You should never change this code, unless you want to prevent major
upgrades.


EXAMPLE: A major upgrade could replace YourApp Express with YourApp Professional.
Therefore both members of the YourApp family should have the same upgrade code.
When you install YourApp Professional, Windows Installer will detect that another family
member is already installed, and automatically remove YourApp Express before
installing YourApp Professional. Windows Installer is smart enough to keep any
components that a shared in both editions on the system, thus reducing installation time
to a minimum. Of course this requires that you properly populated the Upgrade Table.



Upgrades


The following Table summarizes when to change the package, product and upgrade
codes, and the product version:


Update Type        Package Code        Product Version   Product Code    Upgrade Code

Small update       change              Don't change      don't change    don't change

Minor update       change              change            don't change    don't change

Major upgrade      change              change            change          don't change


Major upgrades are more reliable than minor.


Minor – Example: If you install application e.g. UltraEdit and want to add a few files, but
don’t want to uninstall and reinstall it.
                                                           Windows Installer Technology



Major – Example: You already have Version 9 – create version 10, Uninstall version 9
and reinstall new app (version 10)


To overwrite the existing product with a newer version, you should perform a small or
minor update. This requires that you set the following properties on the MSIEXEC
command line:


MSIEXEC /I <Yourapp.msi> REINSTALLMODE=vomus REINSTALL=ALL


The important part is the "v" in the reinstall mode settings. It forces the use of the new
msi file instead of the cached copy. Therefore it can't be set inside the package. The
rest of the REINSTALLMODE flags make sure that existing files get updated, new files
get installed, registry entries are re-written and shortcuts are created. REINSTALL=ALL
means that only those features, that were selected by the user during the install of the
old version get updated. Unselected features should not be added.


Small and minor updates are very similar. The only difference is that in a minor update
the product version is increased, while a small update leaves the version number
unchanged or increases only the fourth field of the number. You can update your product
with a small or minor update package only if the product code is unchanged. To replace
an existing application with a package that has a different product code, a major upgrade
is required.


The following changes in your setup project require that you change the product code:
               The name of the .msi file has been changed.
               The component code of an existing component has changed
               A component has been added or removed from an existing feature.
               An existing feature has been made into a child of an existing feature.
               An existing child feature has been removed from its parent feature


Note that adding a new feature (top level or child), consisting entirely of new
components, does not require changing the product code.
                                                             Windows Installer Technology

Patches


Because installation packages contain all the information required for an installation, as
well as the files that make up the application, information can be updated within the
following parts of the installation package. Upgrade is an msi – can look at tables
add/remove files. Patch is pre-compiled and deploys files into folder


        The .MSI file
        The files of the applications
        The windows installer registration information.


There are 3 main types of updates
        Small upgrade:- If the update changes the .msi file as well as application files,
         without changing the product code or product version.
        Minor Upgrades:- If the update changes the product version but does not
         change the product code.
        Major Upgrade:- If the update changes the installation into an entirely different
         product the product code must change and the update is a major upgrade.

Patches should only be used for applying Minor Updates .Typically these will be used as
‘Hotfixes’ for when a package has passed UAT, gone live and a problem has come to
light requiring a ‘quick fix’. Another good use for patches is for very large packages that
require small updates regularly.

The patch install is a special type of install that performs an upgrade of an installed
application. If you want to update a few files to an existing windows installer package
you can apply a Patch File (extension .msp), which will update your application with the
new changes. The patch file will contain only the bits that are different between two
application files as opposed to copying over the complete file itself. When the patch is
applied to the earlier application file, it is turned into the newer application file, changing
out those bits that are different between the two files. One of the major advantages of
using a patch file over re-installing a full setup program is that the patch file is very small
and preserves user customizations. A Patch can be used regardless of whether there is
a minor version change between the two applications or there is a major version change.
                                                            Windows Installer Technology

There is however certain restriction with using patch files for updates. You have less
ability to customize the update. You cannot change feature states, leave certain files
installed or perform custom actions on the version of the installed app.

Patch Dos and Don'ts

 The first step in preparing to patch is to update the project/MSI. Patching works best
 when the structural differences between the two MSIs are minimal, the files may all
 be changed but the components can not be moved from one feature to another.


 Once you have made all the changes to the MSI a good way of being able to
 compare the two is to use the MSIPackageDiff program from DevStudio by going to
 the Tools menu.


Do:


         Change the PackageCode (in the Summary Information Stream) and the
          ProductVersion property.
         Follow the advice in the PatchValidation
         Be aware that a component will only be upgraded if its key file has changed.
          If only non-key data has changed then the component may not get installed.


Don’t:


         Change the ProductCode or UpgradeCode properties.
         Remove files/components from the new version, MSI does not cope very well
          with this.
         Change the filename of the MSI

How to create a Patch

Make Changes to the Project


         Modify the project file to reflect changes to incorporate into the patch. Make
          all the changes normally made to a new project. E.g. Package Version etc.
         Build a new MSI for the project.
                                                    Windows Installer Technology

   Use MSIPackageDiff program from DevStudio Tools ( or menu to review the
    differences between the original production and new MSIs. The two MSIs
    should be kept as similar as possible.
   Create admin image of both the msi.
   Change the PackageCode and the ProductVersion property.
   Open wise Package studio , Select ‘Patch Creation’ from tab ‘Tool’




   Click on ‘Next’
Windows Installer Technology
                                                    Windows Installer Technology




   Click on ‘Next’




   Click on ‘Add’ then the following screen appears and brows the previous MSI
    in ‘Previous MSI path textbox. And click ‘OK’
                                                       Windows Installer Technology




   The following screen appears with the older version of MSI . Click on ‘Next’ .
    Note that the .MSI files must have all files placed outside of the installation
    because the patching engine compares the contents of files, it needs to be able
    to see those files.
    If your MSI is in compressed format then the Wizard will ask you where you
    want to decompress the files to. Choose a temporary folder as this can be
    safely deleted once the patch has been made.
Windows Installer Technology
                                                    Windows Installer Technology




   Specify the updated MSI path with the help of ‘Browse’ button. Then click on
    ‘Next’ button.
                                                      Windows Installer Technology




   Select the destination path for the patch package , then click on ‘Next’
                                                       Windows Installer Technology




   Click ‘Finish’ and the .msp and .psp files are ready in the specified folder.




   Install the original application package MSI with any Transforms.
   Locate the Patch .MSP which by default is created in a sub-folder below that
    containing the new MSI.
   To apply the patch use the following command line
                                                             Windows Installer Technology

               msiexec /p <MyPatch.msp> /qb! ALLUSERS=1 REINSTALL=ALL




Permissions


Security Permissions


Permissions can be set for selected files\directories\registry entries. If you want to
protect your application's files, directories or registry entries against getting accidentally
deleted or changed. The permissions you set are applied to the domain and user you
specify e.g. you can set different file permissions for the same file for different users.


Setup Editor – Tables – Lock Permissions


LockObject         Table              Domain              User               Permissions


LockObject – go to file table to locate key e.g. EMlaunch.dll


Table – File, Registry or CreateFolder Table is inserted into this field


Domain - Specifies the domain of the user for which permissions are to be set. This is
the name of a stand-alone machine or a domain name. With Windows Installer version
2.0 or later, you may use the string [%USERDOMAIN] in this field to get the value of the
USERDOMAIN environment variable for the current domain. To get any other domain
requires using a custom action.


User – “Everyone” unless otherwise instructed


Permissions - An integer description of system privileges. The following gives the most
commonly used values:
                                                        Windows Installer Technology

GENERIC_ALL                                  Read, write, and execute access
0X10000000
268435456
GENERIC_EXECUTE                              Execute access
0X20000000
536870912
GENERIC_WRITE                                Write access
0X40000000
1073741824



Setting Permissions


Permissions can be set on the following:
      Registry Keys
      Directories
      File



Setting permissions on Registry Keys


Registry key has to be installed
IMPORTANT: Registry permissions propagate upwards and not downwards in registry
keys


Example of an entry:-

LockObject        Table             Domain           User             Password
Registry23        Registry                           Everyone         268435456



Setting permissions on Directories
                                                         Windows Installer Technology

Use the CreateFolder table when setting the table value and ensure that the table you
want to set permissions to is in the CreateFolder Table otherwise you cannot set
permissions on this directory.


For Example:-

LockObject         Table              Domain           User              Password
WinAmp             CreateFolder                        Everyone          268435456


IMPORTANT:       Unlike Registry permission CreateFolder          permissions propagate
downwards and not upwards.



Setting permissions on a File



LockObject         Table              Domain           User              Password
Winamp32.exe       File                                Everyone          268435456


Give the name of the file and set the table to File.



The Registry – Intermediate Level

Introducing the Registry


The Registry is a repository of configuration information for the Windows OS. It’s
not just the OS configuration information, but also details of applications and hardware
installed.


The contents of the Registry may be viewed by using a Registry editor such as
regedit.exe or regedt32.exe.


The Registry is organized in a tree structure with Root keys/Subtrees, Subkeys, Hives
and Entries. In general, the 5 Registry Subtrees can be categorized as either machine-
specific or user-specific.
                                                            Windows Installer Technology

Machine-specific entries correspond to configuration information that is present
regardless of which user is logged on to the machine; user-specific entries are only
relevant and valid when a given user is logged on.


The Root Keys are the main organizational unit in the Registry. All data in the Registry
is organized into one of the five root keys:
              HKEY_CLASSES_ROOT
              HKEY_CURRENT_USER
              HKEY_LOCAL_MACHINE
              HKEY_CURRENT_CONFIG
              HKEY_USERS


Of the 5 Subtrees, HKEY_CLASSES_ROOT (HKCR), HKEY_LOCAL_MACHINE
(HKLM), and HKEY_CURRENT_CONFIG (HKCC) are all machine-specific.


HKEY_CURRENT_USER (HKCU) is user-specific and only exists when a user is logged
on to a workstation.


HKEY_USERS (HKU) actually has elements of both when a user is logged on, but is
generally machine-specific.


HKEY_CLASSES_ROOT


HKEY_CLASSES_ROOT (HKCR) is an alias for “HKLM\Software\Classes Subkey” as
well as “HKCU\Software\Classes” and is a direct descendant of the REG. DAT file
found in Windows.
The idea here is that HKCR represents the classes registered for both machine and user
in one Subtree.


This important Subkey holds the Win2K system’s Explorer shell file associations, as well
as Object Linking and Embedding (OLE) and Component Object Model (COM) class
registrations. When you click on a .doc file, Win2K looks in Classes to find out what
application to launch for .doc files, and where that application resides.
                                                               Windows Installer Technology

Within the context of COM, classes are simply pieces of functionality and data that a
program can call at runtime, to perform a specific task. A COM component can include
one or more classes. The behavior of a button on a form might, for example be defined
by a class. When that button class is invoked by an application and the user clicks the
button, the functionality defined by that class is executed.



Class IDs


Classes are identified in the Registry by Class IDs (CLSIDs). CLSIDs are easy to spot
because they are stored by their Globally Unique Identifier, (GUID), which is represented
as a 32-character hexadecimal number.


HKEY_Classes_Root is home to more than just Class GUIDs. At the top of HKCR, you
find all of the file extensions that are registered on the system.


For example:
If you have installed Microsoft Word, you should see the .doc extension registered. If
you drill into this key, you will find an associated Program Identifier, or ProgID.



ProgID


A Prog ID is Win2K’s way of wrapping a familiar name around the unfamiliar COM GUID.
In the case of .doc files, depending upon the version of Word you have installed, it refers
to a ProgID in HKCR named Word.Document.X, where X is the version number of Word.
Under the Word.Document.X key, you find references to the Class ID that Word has
registered for use with .doc files. Under this ProgID key, you find directions on the
location from which Word is to be launched, which is used when the user double-clicks a
.doc file. You also find other information, such as which icon should represent .doc files
in the user interface.


In HKEY_CLASSES_ROOT, there are also other important Subkeys.:-
                                                          Windows Installer Technology

              AppID Subkey
              Interface Subkey
              TypeLibrary Subkey



The AppID Subkey (HKCR\AppID)

The App ID Subkey (HKCR\AppID) holds information related to DCOM components
registered on a system. DCOM is an extension of COM that allows components that are
distributed across multiple Win2K machines, to communicate with one another. DCOM
components use their own security model to determine under which security context the
component can be instantiated and who can start or access a particular DCOM
component. This information is stored in the AppID key on a per component basis. Both
GUIDs and ProgIDs are kept within AppID, depending upon how they were written.



Interface Subkey (HKCR\Interface)


Each registered COM component includes a number of Interfaces that define pieces of
functionality within that component. Interfaces are further broken down into methods,
properties, and constants. Interfaces use GUIDs to uniquely identify themselves in the
Registry.   One or more Interfaces, with their associated methods, properties and
constants, define a COM component.



Type Library definitions (HKCR\TypeLib)


The Type Library is a programming aid to assist a COM developer in identifying which
registered Interfaces are available for a given COM Component at runtime and when the
object is instantiated. Type libraries are typically stored in a compiled binary file that
ends with a .tlb extension.


HKEY_CURRENT_USER (HKCU)
                                                          Windows Installer Technology

HKEY_CURRENT_USER (HKCU) stores information specific to the user currently
logged on to the system. This information includes the user’s preferences, desktop
configuration as well as the contents of the Start menu and Favorites menu. Data for
HKEY_CURRENT_USER is retrieved from the NTUSER file when the user logs on to
the system.



HKEY_LOCAL_MACHINE (HKLM)


HKEY_LOCAL_MACHINE (HKLM) is the main key representing the hardware
configuration of the machine as well as security and network connections configuration
data. This RootKey is broken down into the following:-


              \HARDWARE
              \SYSTEM
              \SECURITY
              \SOFTWARE



HKEY_LOCAL_MACHINE \ HARDWARE


Displays all hardware attached to the system as well as their settings. This key is
populated when the OS boots during kernel initialization, writing details of devices found
(i.e. mouse, keyboard, video adapters, floppy disks and communication and parallel
ports) to the Registry. In general, all values found in the Hardware key are fixed — that
is, you can’t change the way the system behaves by changing a key or value in this part
of the Registry. If you do change a value, it will be reset to the detected value the next
time Win2K boots.



HKEY_LOCAL_MACHINE \ SYSTEM


Holds data needed to boot the computer. The HKLM\System\CurrentControlSet\Enum
key is where plug-and-play devices that were discovered at boot time are enumerated.
                                                          Windows Installer Technology

Other Subkeys contain Control Sets as back ups should the system encounter problems
at boot time, allowing the user to choose the "Last Known Good" configuration. In effect,
this choice loads another CurrentControlSet that was saved from the last time you
successfully booted prior to your configuration change



HKEY_LOCAL_MACHINE \ SECURITY


This holds security specific data including user and group policies e.g. Information about
the network security provider and remote administration capabilities.



HKEY_LOCAL_MACHINE \ SOFTWARE


Holds all the data on the software installed on the OS. It is within this key that all
Microsoft and most third-party applications write their configuration information.    The
data here is per-machine as opposed to per-user so this Subkey lists a full inventory of
the software installed on the machine regardless of which user installed it, or what
access rights are present.


It is now a Windows Logo requirement for Win2K that applications keep their
configuration and policy information within specific keys in the Registry, and most of
those keys reside in the Software key. The general idea is that under Software, an
application vendor would place a key, usually the company name, and then under that
key the Subkey’s and values would be created for the company’s installed application.
For example, if you installed software from the ABC Software Company, you should see
Registry entries under HKLM\Software\ABCSoftware that pertain to that product’s
configuration options. The Software key also contains the Classes Subkey, which is the
source of HKCR.



HKEY_CURRENT_CONFIG (HKCC)
                                                          Windows Installer Technology

HKEY_CURRENT_CONFIG (HKCC) holds the data from the control set that was used
to successfully boot the system.          This Rootkey mirrors the data stored at
“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current”



HKEY_USERS (HKU)


HKEY_USERS (HKU) contains the profile information from HKCU as well as the default
profile. HKU should display at least three Subkeys; the .DEFAULT, the Current User
SID and the Current User SID Classes. The long numbers, beginning with S- are the
currently logged on user’s SID (Security Identifier). There are two keys for a given user,
one suffixed by _Classes. This Subkey holds the Classes associated with each SID,
which in turn comprises the user-specific Class registrations Win2K now keeps. Each
user ID stored under HKU has its corresponding Classes key. Storing this information
on the per-user basis is tightly integrated with the whole Win2K notion of reducing the
cost of maintaining users and machines.


The default profile is used when a new user or a user without a profile logs on to the
system. Current User SID holds the same data as HKCU. Current User SID Classes
contains any file extension association or component embedding information that
overrides the defaults established for the installation in HKCR and HKLM\Software.


NOTE
When you install a Win2K application, any file associations and COM registrations that
belong to that application get installed in the user-specific Classes key, unless the
application installation specifies machine-based installation only. This let’s users roam
from workstation to workstation, carrying application information with them as they go.



Registry Data Types


Registry values can be of several different data types, which define the type of data that
can be stored in that Registry value. If you are familiar with programming concepts, you
recognize that the Registry data type is equivalent to a declared variable type, such as
                                                           Windows Installer Technology

character string, integer, or long. The Win2K Registry supports seven different data
types, which are listed in Table 1, with descriptions of the kinds of data they
accommodate.


TABLE 1: REGISTRY VALUE DATA TYPES

Data Type                                Description

REG_SZ                                   Used for text strings.

REG_EXPAND_SZ                            Used for text strings, but can accommodate
                                         expandable        variables   that   a   program
                                         evaluates when it reads the Registry. For
                                         example, a REG_EXPAND_SZ value that
                                         contains %systemroot% would expand to
                                         c:\winnt when an application that uses that
                                         value reads it.

                                         Note:    Not       all   applications    support
                                         REG_EXPAND_SZ             values.    Applications
                                         generally must be coded explicitly to accept
                                         these types of values.

REG_MULTI_SZ                             Used for an array of text strings within a
                                         single Registry value. Each value is usually
                                         delimited in some way (e.g., space, comma).

REG_DWORD                                Used for a four-byte-long numeric value.

REG_BINARY                               Used to store raw binary data. For example,
                                         some device drivers store configuration
                                         information as actual binary data (1s and
                                         0s). This value is most often used by
                                         hardware configurations, but it can be found
                                         in applications.

REG_FULL_RESOURCE_DESCRIPTOR Used exclusively by hardware drivers to
                                                           Windows Installer Technology


                                             store arrays of information. This type of data
                                             can hold a number of parameters, and the
                                             Registry   editor    presents   them   in   an
                                             organized fashion.

REG _RESOURCE_LIST                           Found only in the hardware portion of the
                                             Registry, this value type also stores arrays of
                                             information. You most commonly see data of
                                             this type enumerating information about
                                             which PC bus a given device occupies.



The last two value types, REG_FULL_RESOURCE_DESCRIPTOR and REG_FULL_
RESOURCE_LIST, are found only in the Hardware key of HKEY_LOCAL_MACHINE.
Rarely would you ever encounter or have the need to change either of these data types
in your day-to-day Win2K administration.


The hardest data type to manipulate manually is the REG_BINARY type. These values
hold binary data that does not correspond to simple configuration options. For example,
options with respect to how a user’s Microsoft Outlook profile is configured are kept
within REG_BINARY values in HKEY_CURRENT_USER.                    The normal method for
modifying these configuration options is through the Outlook client configuration menus.
Therefore, attempts to change these values directly through one of the available
Registry editors can often result in corrupt data.



Learn how the Registry is organized and managed


The Registry is the centralized configuration database for Windows NT and Windows
2000 (Win2K), as well as for applications.


The Configuration Manager—the kernel subsystem that implements the Registry—
organizes the Registry's on-disk files. The Configuration Manager manages the Registry
as applications and other OS components read and change Registry keys and values.
                                                           Windows Installer Technology

The Configuration Manager tries to ensure that the Registry is always in a recoverable
state, even if the system crashes while you're modifying the Registry.



Hives


On disk, the Registry isn't simply one large file but a set of discrete files called hives.
Each hive contains a Registry tree, which has a key that serves as the root (i.e., starting
point) of the tree. Subkeys and their values reside beneath the root. You might think that
NT/Win2k stores each root key you see when you run one of the Registry editors
(regedit or regedt32) in a separate hive, but such is not the case. The correlation
between the keys that regedit displays and the content of the hives isn't straightforward,
as Table 2, below, shows. In fact, none of the root keys correlate to hives.


TABLE 2: Regedit Root Keys

Key                           Description

HKEY_CLASSES_ROOT             Symbolic                        link                       to
                              HKEY_LOCAL_MACHINE\SOFTWARE\Classes.

HKEY_CURRENT_USER             Symbolic link to a key under HKEY_USERS representing a
                              user's profile hive.

HKEY_LOCAL_MACHINE            Placeholder with no corresponding physical hive. This key
                              contains other keys that are hives.

HKEY_USERS                    Placeholder that contains the user-profile hives of logged-
                              on accounts.

HKEY_CURRENT_CONFIG Symbolic link to the key of the current hardware profile
                              under                  HKEY_LOCAL_MACHINE\SYSTEM\
                              CurrentControlSet\ Control\IDConfigDB\Hardware Profiles.
                                                          Windows Installer Technology

USING COM REGISTRATION TABLES IN WISE



What is COM?


Component Object Model (COM) is architecture and supporting infrastructure for
building, using, and evolving component software in a robust manner. It provides a
framework for integrating components that supports interoperability and reusability of
distributed objects by allowing developers to build systems by assembling reusable
components from different vendors that communicate via COM. COM is independent of
platforms and of programming languages.          Therefore components created using
different programming languages like C, C++, VB and even BASIC can be used to
create COM components. COM is the underlying architecture that facilitates high-level
software services.



Self-Registration


The installer provides self-registration only for backward compatibility and it is not
recommended as a method for populating the registry. All .OCXs and some .DLLs
support self-registration. If the COM registration tables are used to register the .DLLs
and .OCXs then there should not be an entry in the SelfReg Table for these files.


You can just edit the SelfReg Table i.e. if you don’t want a certain file to be self-
registered you can delete the entry relating to that file from the SelfReg Table in the
Setup Editor.



Why we use COM registration tables instead of self-registration


With traditional scripted set-up programs, self-registration was the accepted method for
installing COM objects.     However, the Windows Installer cannot perform rollback
installations and registration of self-registered COM objects. It also cannot advertise
those objects. This is because self-registering COM objects do not pass their installation
                                                            Windows Installer Technology

and registration information to the Windows installer. Therefore the installer does not
have the information necessary for rollback or advertisement.


If an application is advertised, only the interfaces required for loading and launching the
application are presented to the user or other applications. If a user or application
activates an advertised interface the installer then proceeds to install the necessary
components.


To support rollback of component installation and registration if your product installation
fails, as well as component advertisement on the target machine, you must register
installed COM objects by establishing the necessary associations. Therefore you must
install those COM objects in a manner compliant with Windows Installer requirements.
The following are the tables in Windows Installer which are used for advertisement and
COM components:


              Extension Table
              Verb Table
              ProgID Table
              MIME Table
              AppID Table
              Class Table
              Typelib Table
              Registry Table


The following section discusses these tables in more detail.



COM Registration Tables Group


The installer uses specific tables for the different types of registry entries.       When
populating the registry it is important to try to minimize the number of entries put into the
Registry Table and maximizes the use of the other, specific, registry tables.        This is
because the installer cannot distinguish between different types of registry entries in the
                                                            Windows Installer Technology

Registry table and cannot use the internal logic necessary to take full advantage of all
the installer features, such as advertising.


The COM Registration Tables Group contains the following tables of specific registry
entries:



Extension Table


This table contains all of the filename extensions your application uses along with their
associated features and components. This information must be generated as part of
product advertisement. Each row generates a set of registry keys and values such as
HKCR\{.file extension name}


Extension      ProgID_       Feature_     Component_         MIME_
CIW            ciwfile       Complete     Notepad.exe        application/x-Inst-for-
                                                             Scientific-Info




Columns


       Extension – This field contains the extension associated with the table row.
Enter the extension in this field without the preceding period. I.e. for the extension .CIW
just enter CIW into this field.
       ProgId_ – This is a foreign key into the ProgId Table specifying the ProgId
associated with the extension. This field contains the ProgId value that will be written
under the following key: HKCR\{.file extension name}\ , default = “{ProgId}”
       Feature – This is a foreign key into the Feature table. It specifies the feature that
provides the extension server.
       Component – This is a foreign key into the Component table. It references the
component that controls the installation of the environment values.
       MIME – This is a foreign key into the MIME table containing the Content Type
that is to be written for the Extension column. This field contains the Content Type that
                                                           Windows Installer Technology

will be written under the following key: HKCR\{.file extension name} \ , ContentType
=“{MIME_}”
The Extension, Component and Feature fields are not nullable.



Verb Table


This table contains command-verb information associated with the file extensions listed
in the Extension Table. This information must be generated as part of product
advertisement.    Each row generates a set of registry keys and values such as
HKCR\{ProgId}\shell\Open\command.


Extension_        Verb               Command            Argument          Sequence
CIW               Open                                  “%1”              {null}


Columns


       Extension – This field contains the extension associated with the table row. This
is a foreign key into The Extension table.
       Verb – This contains the verb for the command.
       Command – This field contains the localizable text displayed on the context
menu.
       Argument – This field contains the value for the command arguments.
       Sequence – The sequence of commands.


Note on Registered verbs (Command and Shell):


Verbs are commands that are associated with file extensions, and set out the actions
available for the relevant file extension. When a verb is associated with a file extension,
the verb is shown in Windows Explorer when you right click on the appropriate file type.
For example the verb Open with word documents or .doc file types.
                                                            Windows Installer Technology

ProgId Table


This table contains information for the Program Ids and version independent Program
Ids. This includes information like the icon file that is associated with the ProgId. This
table creates entries like HKCR\{ProgId}.


An important thing to note is that the ProgId table cannot be used without the Class
Table unless it is a version independent ProgId. In this case the Class_ field must be left
null.


ProgId           ProgId_Pare    Class_      Description       Icon_          Icon Index
                 nt
Ciwfile                                     ISI   Common IconCB2.exe 0
                                            Export Format


Columns:


         ProgId – This contains the program ID or version independent program
ID
         ProgId_Parent –      This field is defined only for version independent
program IDs. This is a foreign key into the ProgId column.
         Class – This is an optional foreign key into the Class table. This field
must be Null for a version independent ProgId
         Description – This contains an optional localized description of the
associated program ID.
         Icon – This is an optional foreign key into the Icon table that specifies the
icon file associated with this ProgId. This is written under the DefaultIcon key
associated with this ProgId. This column must be null for a version independent
progId
         IconIndex – The Icon index into the icon file. This field must be Null for a
version independent ProgId.
                                                          Windows Installer Technology

MIME Table


The MIME Table associates a MIME content type with a file extension or a CLSID to
generate the extension or COM server information required for advertisement of the
MIME content.


MIME means Multipurpose Internet Mail Extensions, and refers to the official Internet
standard that specifies how messages must be formatted so that they can be exchanged
between different email systems. You can establish new MIME types installed with your
product, give each MIME type a name, and associate MIME types with extensions and
COM objects.


ContentType                          Extension_              CLSID
application/x-Inst-for-Scientific-   CIW
Info




Columns:


               ContentType – This field is an identifier for the MIME content.     It is
commonly written in the form of type/format
               Extension – contains the server extension that is to be associated with
the MIME content, without the dot. This is a foreign key into the Extension Table
               CLSID - This column contains the COM server CLSID that is to be
associated with the MIME content. The CLSID in this column can be a foreign key into
the Class table or it can be a CLSID that already exists on the user’s machine.
Note:
Setting up MIME types and their associations makes it possible for the target machine to
handle your installed MIME types correctly (just as setting up document types with their
extension and verb associations makes it possible for the target machine to handle
document types correctly).
                                                                Windows Installer Technology

   AppId Table


   This table is used to register common security and configuration settings for DCOM
   objects. This table is processed at the installation of the component associated with the
   DCOM server. An AppID is not advertised.


   Distributed COM (DCOM) is an extension to COM that allows network-based component
   interaction.   While COM processes can run on the same machine but in different
   address spaces, the DCOM extension allows processes to be spread across a network.
   With DCOM, components operating on a variety of platforms can interact, as long as
   DCOM is available within the environment.


AppId      RemoteServ       Local      ServicePara     DllSurroga    ActivateAtStor    RunAsInt
           erName           Servic     meters          te            age               eractiveU
                            e                                                          ser




   Columns:
                  AppId - This contains the AppId value that will be written under the CLSID
   and creates the AppId guid key under HKCR\AppId
                  RemoteServerName        –    This   column     contains   the   value     of
   “RemoteServerName” = <xxxx> that will be written under HKCR\AppId\{AppId}\
                  LocalService - This field contains the value of LocalService that will be
   written under HKCR\AppId\{<AddId>}, “LocalService” = <xxx>
                  ServiecParameters – This field contains the value of ServiceParameters
   that will be written Under HKCR\AppId\{<AppId>}, “ServiceParameters”.
                  DllSurrogate - This field contains the value of DllSurrogate that will be
   written under HKCR\AppId\{<AppId>}, “DllSurrogate” = <xxx>. If this column is preset it
   will typically be an empty string
                  ActivateAtStorage - This field contains the value of ActivateAtStorage that
   will be written under HKCR\AppId\{<AppId>}, “ActivateAtStorage” = “Y”
                                                              Windows Installer Technology

              RunAsInteractiveUser      -   This    field        contains   the   value   of
RunAsInteractiveUser that will be written under HKCR\AppId\{<AppId>}, “RunAs” =
“InteractiveUser”


Note: The AppId table does not have a column for registering a Default name. Therefore
in cases where you need to write a user-friendly name as the Default name value, you
must register using the Registry table



Class Table


This table is used to register Class Ids and other information for COM objects. This
table contains COM server-related information that must be generated as part of the
product advertisement. The associated ProgId information is included in this table. This
table creates the entries in HKCR\CLSID\{GUID}.


CLSI    Contex      Compone     ProgId_De     Descrip        AppI     FileType     Icon_
D       t           nt          fault         tion           d_       Mask




IconIndex           DefInprocHan     Argument           Feature_              Attributes
                    dler




Columns:


      CLSID - The Class identifer (ID) of a COM server
      Context - The server context for this server. This may be one of the following
values: LocalServer, LocalServer32, InprocServer, InprocServer32
      Component - Foreign key into the component table specifying the component
whose key file provides the COM server
      ProgId_Default - Foreign key into the ProgId table specifying the Program ID
associated with this CLSID
      Description - Description associated with the CLSID and Prog ID
                                                             Windows Installer Technology

       AppId_ - Foreign key into the AppId table specifying the Application ID
containing DCOM information for the associated application (string GUID)
       FileTypeMask -         Contains information for the HKCR (this CLSID) key
       Icon_ - Foreign key into the Icon table specifying the file associated with this
CLSID.The Installer writes this entry under the Default Icon key associated with the
ProgId. If this field is null, the COM server provides the icon resource. Advertised file
associations and shortcuts require a non-null value in this column to display properly.
       IconIndex - Icon index into the icon file. This field can be left null. Non-negative
numbers Only
       DefInprocHandler - Default inproc handler. Optional.           Provided only when
Context = LocalServer or LocalServer32. For more info see SDK
       Argument - Optional. Provided only when Context = LocalServer or
LocalServer32. For more info see SDK.
       Feature_ - Foreign key into the Feature table specifying the feature that provides
the COM Server
       Attributes - If you set this column to 1 then you are setting the
msidbClassAttributesRelative Path which means that the bare file name can be used for
COM servers. i.e. the installer registers the file name only instead of the complete path

TypeLib Table


This table provides information that the installer places in the registry for the registration
of type libraries. Type library entries are not written at the time of advertisement. The
installer writes the type library entries at the time the components associated with the
library are installed.


LibID      Langua        Compone Version        Descript    Director       Feature   Cost
           ge            nt_                    ion         y_             _




Columns:
       LibID - This field contains the GUID that identifies the library
       Language - The language of the type library. This must be a non-negative
number
                                                            Windows Installer Technology

       Component - Foreign key into the Component table which identifies the
component belonging to the Feature whose key file is the type library being registered
       Version - This is the version of the library. The major and minor versions are
encoded in the two-byte integer with the minor version in the lower eight bit and the
major version in the upper eight bits.
       Description - Description of the library
       Directory - Foreign key into the directory table identifying the Help path for the
type library. This column is ignored during advertising
       Feature -       Foreign key into the Feature table specifying the feature that must
be installed for the type library to be operational
       Cost - The cost associated with the registration of the type libraries in bytes. This
must be a non-negative number or null



Registry Table


The Registry table holds any other information that the application needs to put into the
system registry. This would include default settings, user information or data, or COM
registration not supported by the above tables.


Registry         Root           Key             Name           Value           Component
                                                                               _




Columns:
       Registry -      Primary key used to identify a registry record
       Root - The predefined root key for the registry value. To force the registry value
to be written under a particular key, enter one of the following values:
0 = HKEY_CLASSES_ROOT
1 = HKEY_CURRENT_USER
2 = HKEY_LOCAL_MACHINE
3 = HKEY_USERS
                Enter a value of –1 in this field to make the root key dependent on the
type of installation.
                                                              Windows Installer Technology

       Key - The key for the registry value
       Name - This field contains the registry value name. If this is Null, then the data
entered into the value field is written to the default registry key.
Note: If the Value field is null then the following strings +, - and * have special
significance.
       Value - This field contains the registry value. This field is formatted and can hold
properties.
       Component- Foreign key into the component table referencing the component
that controls the installation of the registry value
Note:


1.              It is recommended that registry entries to the HKCU have reference a
component having the RegistryKeyPath bit set in the Attributes column of the
Component table. This ensures that the installer writes the necessary registry entries
when there are multiple users on the same computer.
2.              The installer removes a registry key after removing the last value or
subkey under the key. To prevent an empty registry key from being removed when
uninstalling, write a dummy value under the key you need to keep and enter + in the
Name column



SelfReg Table


This table contains information on modules that need to be self-registered


NOTE: It is strongly recommended that installation package authors not use self-
registration. Instead they should register files by authoring one or more of the other
tables in the installer.


File_                                          Cost




Columns:
                                                               Windows Installer Technology

               File_ - Foreign key into the File Table. Indicates the file that needs to be
registered
               Cost - The cost of registering the module in bytes. This must be a non-
negative number.



Reasons why the SelfReg Table should not be used


1.      A rollback of an installation with self-registered modules cannot be safely done
using DllUnregisterServer because there is no way of telling if the self-registered keys
are used by another feature or application.
2.      The ability to use advertisement is reduced if Class or Extension server
registration is performed within self-registration routines.
3.      The installer automatically handles HKCR keys in the registry table for both per-
user and per-machine installations. DllRegisterServer routines currently do not support
the notion of a per-user HKCR key
4.      If multiple users are attempting to use a self-registered application on a
computer, each user will need to install the application on first run because the installer
cannot easily determine that the proper HKCU registry keys exist for that user.
5.      The DLLRegisterServer can be denied access to network resources such as type
libraries if a component is specified as run-from-source and is listed in the SelfReg table.
This can cause the installation of the component to fail to during an administrative
installation.
6.      Self-registering DLLs are more susceptible to coding errors because the new
code required for DllRegisterServer is commonly different for each DLL. Instead use the
registry table in the database to take advantage of existing code provided by the
installer.
7.      Self-registering DLLs can sometimes link to auxiliary DLLs that are not present or
are the wrong version. In contrast, the installer can register the DLLs using the registry
table with no dependency on the current state of the system.



IMPORTANT - Helpful Tips
                                                             Windows Installer Technology

You can use the following as examples of how to use the registry to solve problems in
an application:


1. If an application is installing ODBC data sources, drivers, or translators and you are
having problems with them i.e. an ODBC error message may pop up during the
installation, then you can check the registry to see if there is a problem


For Data sources go to HKLM\SOFTWARE\ODBC\ODBC.INI registry key which holds
information on all of the ODBC data sources installed on the machine


For Drivers and Translators go to HKLM\SOFTWARE\ODBC\ODBCINST.INI registry
key which holds information on all of the Drivers or Translators installed


2. If you are having problems with Services that you are installing then go to
HKLM\SYSTEM\CurrentControlSet\Services. This registry key holds information on the
services installed on the machine.


3. For      information      on      Environment        Variables       go     to     HKLM\
SYSTEM\CurrentControlSet\Control\Session Manager \Environment.



What is an .INI File?


INI files are plain-text files that contain configuration information. These files are used by
Windows and Windows-based applications to save information about your preferences
and operating environment. "INI" stands for initialization



Format of .INI Files


INI files contain one or more sections. Each section begins with a section name, which is
followed by zero or more entries. An entry associates a keyname with a value. The
general format is:
                                                             Windows Installer Technology

[section]
keyname=value


Comments can also be included in the file by prefacing the comment with a
semicolon (;).


Windows and Windows for Workgroups use several standard .INI files for storing
configuration information.
These files are:


WIN.INI
SYSTEM.INI
PROTOCOL.INI
PROGMAN.INI
CONTROL.INI
WINFILE.INI
MSMAIL.INI
SHARED.INI
SCHDPLUS.INI


Windows-based programs may also add sections and entries to WIN.INI, and they may
add .INI files in the Windows directory.



INI Files Page


      The .INI Files Page allows you to create a new .INI file to store your program’s
settings, or you can update the contents of an existing .INI files during the installation
      Open the .INI Files link. If you have multiple features in your install, you must first
choose the feature to which these settings will pertain. The INI changes will only be
implemented when that feature is installed.

Adding / Editing (INI) files
                                                             Windows Installer Technology

Because .INI files use only plain text, they can be edited using any text editor or word
processor.




      Select the folder in which you want to create the new folder.
      Click the New Folder button. The Create New Folder dialog box opens.
      Enter the desired name in the New Folder Name field.
      Click OK to add the folder to the tree.


      Select the folder in which you want to create the .INI file.
      Click the New File button to open the INI File Details dialog box.
      In the INI Filename field, enter the name for this new file. On the destination



 LAB – Create a New INI File

       computer this file will be created if it does not already exist, otherwise it will edit
       the existing file of the same name. For this reason you must take care your
       section headings are correct or you may accidentally overwrite an already
       existing entry. Once entered, the name of your .INI file cannot be changed,
       without first deleting the .INI and then creating a new one.
      In the INI File Details window, enter the settings that you want to appear in this
       file. You must enter at least one section and one command line in the INI
       Settings window for the file to be created. As mentioned earlier the text you
       enter must be in the correct syntax, i.e. section names must be in square
       brackets and the contents in the form of variable=value. For example:
             [SECTION HEADING]
             My Example=My Value


       Properties can also be written to an INI file in much the same way. Be sure to
       surround the property with square brackets, much like the section heading.
             [SECTION HEADING]
             My Example= [MYPROPERTY]
                                                              Windows Installer Technology

      Click the OK button to create the file. The new INI file is listed in the right half of
       the INI File page.


LAB - Make Changes to an Existing INI File


      Select the folder where the existing system file is located.
      Click the New File button and enter the name of the system file that you want to
       edit. e.g. WIN.INI
      In the INI Settings field, enter the information that you want to merge into this
       system file. Use the general format e.g. [TEST] etc.
      Click OK.




LAB - Delete an Existing INI File


To remove any Existing INI File, select the specific INI File and click the Delete button.




Services

A System Service refers to a set of functions (primitive or elaborate) provided by the
operating system. They can perform a number of functions such as System Event
Notification, which tracks system events such as Windows Logon, network and power
events and notifies COM+ event subscribers of these events. Another service would be
“Windows Timer”, which sets the computer clock. Application Programming Interfaces
(API’s) enable developers to call several system services, directly or indirectly, that work
in the background and that aren’t visible to the user.


The Service Control Manager maintains a database of Installed Services and Driver
Services, and provides a unified and secure means of controlling them. The database
includes information on how each service should be started and enables System
Administrators to customize security requirements for each service, thereby controlling
access to the service.
                                                          Windows Installer Technology



WIN NT is the only operating system that properly supports services. The service can be
started automatically at system boot by a user in the control panel or by an application
that uses the service functions included in the Microsoft Win32 API.


The two main database tables that deal with Services are the ServiceInstall and
ServiceControl tables. The ServiceInstall table holds the list of parameters a program
would pass into the Win32 CreateService API to create the Service. The
ServiceControl    table is more generic. You can use the entries in this table to control
any service on the system.

Controlling Services on the Destination Computer


On the Services page in the Installation Expert, you can configure Service Events in
your installation using the Add button. The Service Control option in the drop down
menu lets you start, stop, and delete services that are installed on the Destination
computer.


Before you can add a service you must use the Files page to add the file that runs the
service. When you add the service, you also set parameters that determine how it runs.
                                                              Windows Installer Technology

LAB – Create a Service

      Go to the Installation Expert and select the Files page.
      Select a feature or condition from the feature dropdown list, and add the EXE,
VXD, SYS or .386 file that runs the service.
      Go to the Services page and click Add > Create Service
      Click on the file to run the service from the list of files on the right pane that are
associated with the selected feature.
      The Create Service Details dialog box appears and it is here that we fill in the
relevant entries, which are explained in each section of the dialog box.
                                                            Windows Installer Technology

Click on the Add button and select Service Control to bring up the dialog box below.




Service Name


You can select a service contained in the currently selected feature from the drop down
list or enter the name of a service required. This name is used internally by the service to
register itself properly in the registry.


Arguments


This field is for any arguments to be passed to the service on the command line at
Startup.


Install Action


Select the actions to perform on the services during installation of your application.


Uninstall Action
                                                              Windows Installer Technology



Select the actions to perform on the service during un-installation of your application.


NOTE:


       If you want to both stop and delete a service, do not mark the Stop Service and
Delete Service checkboxes in the same control service action; instead create two
Service Control actions. On the first Service Control action, mark Stop Service and Wait
for Service action to complete before continuing. On the second Service Control
action, mark Delete Service. This ensures that the service is completely stopped before
the installation attempts to remove it.
       After uninstalling the application, it is important to check that the service installed
has been completely removed and does not leave any traces or errors behind Services
located under:
Windows 2000 and XP - Control Panel / Administrative Tools / Services
NT                         - Control Panel / Services,
But will vary depending on type of Operating System.



Checking Service Name


Example: (work on UltraEdit application using Macromedia Licensing.exe as service)
If you need to manipulate a service do not use name given in Administrative Tools e.g.
Print Spooler = friendly name
Use Third Party Tool to find out real name of service e.g. FreshDiagnose Software
       Install software
       Select Services
       Select specific Service from drop down menu –
This lets you see all services (including hidden services) running on machine – showing
friendly and real names.
Example below shows the friendly Service name in the drop down section as Print
Spooler and the real name in the section below as SPOOLER. This real name should be
used when manipulating a service e.g. Start or stop a service.
       In Msi – enter real name to stop and start service.
                                                            Windows Installer Technology




To Check a Service is running correctly


Check in Services to see that the service is running correctly without error, if an error is
received after reboot it will inform you to look in the EventViewer.


Event Viewer is located under Control Panel - Administrative Tools – Event Viewer.


The EventViewer display details of any issues with that particular service, this should
point you in the direction of how to go about fixing the problem.
                                                          Windows Installer Technology

Open Database Connectivity (ODBC)

What is ODBC?


ODBC is an abbreviation for Open Database Connectivity.         It is a protocol access
method to databases developed by Microsoft. Open Database Connectivity (ODBC) is a
standard application programming interface (API) that allows a program to access data
in any ODBC-compliant relational database language.



Purpose of ODBC
It is to allow the user to access data from any application regardless of which Database
Management System (DBMS) being used. It achieves this by creating a middle layer
between the application and the DBMS. This layer is known as the Driver.


At present there are a number of databases available and each one of these databases
uses a different language. It may therefore be difficult for a programmer to write a
program that can access data from many different database sources. However, by
using ODBC, a developer only needs to create an application capable of operating with
the ODBC API. The ODBC layer of the application interface operates with the ODBC-
compliant database to return information to the application. In effect ODBC therefore
provides a uniform, controlled access to a resource and ODBC drivers can access
information stored in just about any type of database. Widely used desktop application
tools such as word processors, spreadsheets and application development tools are
ODBC enabled and provide a means of easily bringing data from ODBC-compliant data
sources.



ODBC Driver


The function of a driver in the ODBC is to translate the application’s data queries into
commands that the DBMS can recognize. The DBMS then sends the answers back to
the driver, which translates the results into a format that the front-end application can
understand. For this to operate correctly the application and the DBMS must be ODBC
                                                         Windows Installer Technology

compliant. The application must be capable of giving the ODBC commands and the
DBMS must be able to respond to these commands. Numerous ODBC drivers may be
installed on the user’s computer allowing the application to access many databases
concurrently.


The type of driver you use depends on the type of database you want to connect to, for
example, an Oracle database requires an Oracle SQL*Net driver and a Microsoft Access
database requires a Microsoft Access driver. A list of databases and the drivers already
installed on your system that are used to connect to them can be seen in the Control
Panel – Administrative Tools under Data Sources (ODBC).




            Application
                                    The ODBC driver interprets queries given
                                    by the application into commands the
                                    DBMS can understand.


            Driver




            DBMS

                    The Diagram above shows the function of a driver.
                                                           Windows Installer Technology




Adding an ODBC Driver

In Installation Expert on the ODBC page – Select Add –Driver
The ODBC Driver dialog box appears when an ODBC driver is being added or modified.




Driver Name
Input the name of the driver. If you are unable to remember the exact names click the
Import button.


Driver DLL
Use the Browse button parallel to give the exact path of the DLL for this driver.


Setup DLL
Use the Browse button parallel to give the exact path of the DLL used to configure the
driver.


Driver Attributes
Input the associated attributes for the driver here, in
Keyword=value format.
                                                           Windows Installer Technology

LAB - How to add an ODBC Driver to your installation?

   1. Go to the ODBC Page in the Installation Expert.
   2. Again click on the Add command button.
   3. This time select Driver from the drop down list. The ODBC Driver dialog will
      appear.
   4. Enter the name for the driver or click on the Import command button to import
      driver information from a saved driver file.
   5. Click on the first Browse command button to specify the path to the DLL used for
      this driver.
   6. Click on the second Browse command button to specify the path to the DLL used
      to configure this driver.
   7. Now enter the attributes for the driver in the Driver Attributes widow, one per line,
      using format: Keyword=Value.
   8. Click OK. The driver is now recorded on the ODBC Page. If you wish to edit the
      driver, double click on the driver name.
                                                         Windows Installer Technology




ODBC Data Source

A Data Source processes requests from the driver and returns the results. Essentially a
data source is a back-end source of data with the connection information needed to
connect the front-end application to the back-end database. In ODBC architecture an
application connects to the ODBC Driver Manager, it in-turn selects the correct driver to
connect to the DBMS.


A database server can have any number of operating databases. A Unique Data Source
Name (DSN) must be given to the data source to specify which database to use.


The Data Source allows the user to select between three connections, User, System and
File DSN’s.


      User DSN’s are used for the connection of an individual user to a data source.
This connection is very secure, but is not a good solution if distributed access is
required. The DSN will only be visible to the specific user when he or she is logged on.
User DSN connection information is stored in the HKEY_CURRENT_USER_ Registry
key
      Systems DSN’s are good solutions when a single computer is expected to
access the database. They are independent of who is logged onto the console. The
connection information for a System DSN is stored in the HKEY_Local_Machine\
Registry. The major drawback in using System DSN connections is that the connections
are dependent on the machine on which they have been set up
      File DSN is located on the network and does not reside on any particular
machine. File DSNs are available to all users who have the same drivers installed. In
this way, multiple computers can use a single File DSN to access a Web server.



Adding an ODBC Data Source
                                                          Windows Installer Technology

The ODBC Data Source Details dialog box appears when an ODBC data source is
being added or modified on the ODBC page in the Installation Expert. The following are
the fields and their function.




Data Source Name
Put the name of the data source here. If you are unable to remember the exact name
use the Import button, which shows all the data sources on the Destination computer.
Driver
Put in the name of the driver that will access the data source. If you are unable to enter
the name of the driver click the import button.
Registration
Register Per Machine
This should be checked if you want every user who logs on to the destination machine to
be able to access the data source.
Register Per User
                                                            Windows Installer Technology

This should be checked if you only want the user who installed the data source to have
access to it.
Source Attributes
Input the associated attributes for the data source here.



LAB - How to add an ODBC Data Source to your installation?



In the Installation Expert select ODBC Page from the Feature Details section at the left
of your screen.




The ODBC Page is used to define the ODBC Drivers, Data Sources and Translators you
are to include in your installation
                                                           Windows Installer Technology

    1. Click on the Add command button. A drop down list will appear containing Data
       Source, Driver and Translator.
    2. Select Data Source from the list. The ODBC Data Source dialog will appear
.

    3. Enter the name of the data source or click on the Import command button to
       import data source information from a saved data source file.
    4. Enter the driver that will be used to access this data source.
    5. In the Registration group box select either Register Per Machine or Register Per
       User radio buttons. If you wish to allow all users on the destination machine to
       access the data source then select Register Per Machine. If you wish to allow
       only the user who installs the MSI to access the data source then select Register
       Per User.
    6. Now enter the attributes for the data source in the Source Attributes widow, one
       per line, using format: Keyword=Value.
    7. Click OK. The data source is now recorded on the ODBC Page. If you wish to
       edit the data source, double click on the data source name.
                                                              Windows Installer Technology




ODBC Translator

Adding an ODBC Translator


The ODBC Translator Details dialog box appears when an ODBC Translator item is
being added or modified on the ODBC page in the Installation expert.




Description
Put in a description of the translator here or click the corresponding Import button to
import an existing translator.
Translator File
Click the Browse button parallel to identify the file that holds the translator.
Setup File
Click the Browse button parallel to identify the file that holds the configuration for the
translator chosen above.




LAB - How to add an ODBC Translator to your installation?


   1. Go to the ODBC Page in the Installation Expert.
   2. Again click on the Add command button.
   3. This time select Translator from the drop down list. The ODBC Translator dialog
       will appear.
                                                             Windows Installer Technology

   4. Enter a description of the translator or click on the Import command button to
      import and existing translator.
   5. Click on the first Browse command button to specify the file that contains the
      translator.
   6. Click on the second Browse command button to specify the file that contains
      configuration data for the selected translator.
   7. Click OK. The translator is now recorded on the ODBC Page. If you wish to edit
      the translator, double click on the translator name.




You have now recorded your ODBC data source, driver and translator on the ODBC
page. The ODBC page should now look something like our example below.
                                                        Windows Installer Technology




To remove an item
Simply select it from the ODBC Page and click the Delete command button.



Merge Modules

Merge Modules are a new feature provided by the Windows Installer MSI technology
which enables the encapsulation of a component or set of related components and their
resources. Merge modules are simplified MSI files, pre-compiled bundles of components
(files, registry changes, and other modules) that enable you to easily add third party
features to your installation.
                                                              Windows Installer Technology

Merge modules cannot be run separately and are used to add information to an
installation package at compile time. After the merge is complete all the information in
the merge module is incorporated into the MSI.


Wise for Windows Installer ships with already created merge modules, which install
commonly, used Microsoft software packages such as MDAC, ActiveX controls, MFC,
and DCOM. A merge module cannot be installed alone. It must be merged into an
installation package (MSI) with a merge tool.


Merge modules contain tables which are not found in an MSI such as ModuleSignature
and ModuleComponents are required. These tables list the information identifying the
merge module and the components included in the merge module respectively.



When to make merge modules


        When an application installation is packaged, the files contained in the
installation will be found during an install capture. It is then necessary to separate files:
           used only by the application, and
           those that are Shared Components
        Shared Components are files which are used by other applications. Such files
are: .DLL, .OCX, .TLB, .OLB, .EXE and other support files as required (e.g. HLP)
        These files are usually files that install to WinNT\System32, WinNT\System,
Program Files\Common Files\Vendor Name or Program Files\Common Files\System\
        Both 16-bit and 32-bit components installed in a shared directory should normally
be considered shared
        Both registered and unregistered components installed in a shared directory
should normally be considered shared:
           Normally any component that an application setup installs to a shared
     directory is a shared component. Even if unregistered
           An unregistered shared component can be moved to the application
     directory. It then must be checked if the application works with it or not
                                                            Windows Installer Technology

       Sometimes it is possible that a setup may install a component to a shared
directory, but it is really not shared. The first thing to do is to check the vendor name of
the DLL/OCX in the shared directory if unsure
       If the vendor name is different from the other vendor names of the files in the
shared directory then try to put it in the application directory. This should only be done if
the packager is sure that the application function will not be jeopardized by this change
Different applications provided by the same vendor may use some shared components
the application vendor created. In this case such components should be considered as
being shared, since they are shared between applications provided by the same
application vendor.

Encapsulate files as much as possible


If a set of files go together, they should be created as a Merge Module. Merge Modules
can contain other Merge Modules in a hierarchical way, so this technique can be used
where Merge Modules are dependent on other Merge Modules.


The following cases indicate where this should be done:
OCX + dependent files (DLL’s, TLB’s, HLP’s etc)
DLL + dependent DLL’s
File suites where it is not clear exactly which files are used. In this case the safest thing
to do is to include all (E.g. Crystal Reports Runtime).
Although it is always possible to create a Merge Module for each file, it is not necessary,
since this would include adding a lot of Merge Modules to a package rather than one.



Versions of Files


When you have two identical files and you are not sure which one to use. Check the
version of each file and use the file with the higher version. However, if the difference
between versions is minor use the older version if it works with the application. Only
when there is a significant change in the version number should the higher version of the
file is used.
                                                               Windows Installer Technology

Where are they used and what are the Advantages

          The primary reason for using merge modules is to put together a package that
           other groups can use in their installations
          If a piece of functionality is likely to be reused within multiple products it should
           be set up in it’s own merge module
                 Merge modules contain all the information required in a single file
                 They can save the user from having to individually install the same files,
                  registry entries and other components to several installations
                 This helps prevent potential problems, which could be encountered when
                  manually installing files, registry entries, etc. In doing so merge modules
                  provide re-usable code thus reducing TCO (total cost of ownership)
                 For example, suppose you have many applications that require the same
                  version of Visual Basic runtime. Well, instead of individually adding the
                  files, registry entries, etc., to each of your installations, you can create a
                  merge module that installs and configures the Visual Basic runtime, and
                  then you simply add this merge module to each application package
                 When we need to update the configuration of the Visual Basic runtime,
                  instead of updating all the installation packages, we simply update the
                  merge module and then recompile the packages containing that module

When not to make Merge Module
A component should not be made into a merge module if:
               The application installs the file into it’s own directory
               Files found in WINNT\System32\Dllcache are used for Windows File
                  Protection. Also files found in this location should not be in any package

Merge Modules - Their Relationship to MSI Files
A merge module has the same basic format as an MSI file containing a relational
database and a summary information stream, only difference is that merge module
contains no features. It has a MSM extension. The module itself is assigned a GUID
(Globally Unique Identifier) and keys for every row in every table are assigned the same
GUID.
           A merge module represents what can be placed under a single feature in an
            installation
                                                                  Windows Installer Technology

            Merge modules cannot be run separately and are used to add information to an
             installation package at compile time.        After the merge is complete all the
             information in the merge module is incorporated into the MSI.

Steps in Building a Merge Module


First we have to search for the available merge modules provided by third party on
internet or on central database. If there is no standard merge module then follow the
following steps to build the merge module.


Merge modules cannot have multiple features (obviously merge modules can belong to
multiple features, and where this occurs the module should be added to all of them).


          First capture the registry information of the .dll/ .ocx /.tlb /.exe file with the help of
WiseComCapture.exe . This will give you .reg file containing the registry information of
the file


          Open Windows Installer Editor , choose New tab from ‘File ‘ tab and select
Template for merge module from File-New tab
                                                        Windows Installer Technology




   Fill the general information for the merge module
                                    Windows Installer Technology




   Create new component as below
                                                     Windows Installer Technology




   Select menu ‘Tools’  Select submenu ‘Options’  Select tab ‘Advertising ‘
    Set Advertising Setting to “Do not scan advertising information” as shown below
                                                                Windows Installer Technology




   Then import the required file (.dll / .ocx / .tlb /.exe).
                                                      Windows Installer Technology



   Again Select menu ‘Tools’ Select submenu ‘Options’ Select tab ‘Advertising‘
    Set Advertising Setting to “Scan advertising information into advertising tables”
    as shown below
                                                        Windows Installer Technology




      Now import the registry information under the component.




      Save WSM
      Compile the merge module with standard naming convention. Validate the merge
module and remove all the errors and warnings.
      Your merge module is now ready.


       IMPORTANT:
       Turn on reference counting – right click on component and go to details – check
       ‘Always increment shared DLL count”
                                                           Windows Installer Technology



To add the merge module to your MSI


   Select Tab ‘Install Expert’  Select Tab ‘Feature Details’  Select ‘Merge Module’
   Click button ‘Add’
   Specify the directory from where the merge modules has to be searched.
   Select the required merge module form the list of merge modules.




The AppSearch
A common requirement of an installation program is to search for existing files or registry
data on the target system. To search for a file or directory on the target system it is
necessary to add a record to the Signature table of the MSI database, which describes
                                                                 Windows Installer Technology

the file or directory being sought. In addition it requires a record to be entered in the
AppSearch table. The AppSearch table has a foreign key to the Signature table and a
property whose value will be set to the full path to the file, if found. These tables along
with the relevant locator database tables allow Windows Installer to search for a
particular file or directory during an installation. They may be used for example to
determine whether the user has already installed a particular version of an application or
a file.


The AppSearch Action searches the user’s system using unique file signatures
(specified in the APPSearch table) based on name, version, date, size and language
recorded in the Signature table along with one of the following locator database tables
(in the order listed) for a suggested file location:
           CompLocator table: searches based on a component GUID
           RegLocator table: searches for a registry value
           IniLocator table: searches for information contained within an INI file
           DrLocator table: searches by querying the directory tree
         If the file signature is listed in the CompLocator table, the suggested search
  location is the key path of a component
         If the signature is not listed in this table or not installed at the suggested location,
  the installer next queries the RegLocator table for a suggested location. If the file
  signature is listed in the RegLocator table, the suggested search location is a key path
  written in the user's registry
         If the signature is not listed in this table or not installed at the suggested location,
  the installer queries the IniLocator table for a suggested location. If the file signature is
  listed in the IniLocator table, the suggested search location is a key path written in an
  .INI file present in the default Windows directory of the user's system
         If the signature is not listed in this table or not installed at the suggested location,
  the installer queries the DrLocator table for a suggested location. If the file signature is
  listed in the DrLocator table, the suggested search location is a path in the user's
  directory tree. The depth of subdirectory levels to search below this location is also
  specified in this table.
                                                            Windows Installer Technology

The first time the installer finds the file signature at a suggested location; it stops
searching for this file or directory and sets the corresponding property in the AppSearch
table to the location of the file or directory.



Uses of AppSearch


The information contained in the property in the AppSearch table (this is a public
property) can be used to determine the outcome of the current installation.


It can be used as a condition. Certain components, features or an entire product may
require that a file or application is currently installed on the user machine. If the
AppSearch locates the required information the condition will resolve to true and the
installation will continue. If however the AppSearch fails to locate the required file a
warning dialog may appear request that the user installs the file(s). Alternatively the
prerequisite files may be installed automatically.


By entering the AppSearch property into the Directory table it is possible for the
packager to specify the desired installation location of components currently being
installed. It may be requested that certain files be installed based on the location of other
files already installed on the user machine.


During an installation, you might want to remove existing files from the destination
machine, to save on disk space or to avoid possible file conflicts between a previous
installation and a new installation. In addition it may be required that files and folders
created at run-time are removed. If we know the exact location of these files we can hard
code the remove file table to find and remove the unwanted file. More commonly an
AppSearch is used to locate the file. The AppSearch sets a property to the value of the
path to the file. The Remove File table then uses that property to remove the file.




  LAB – Performing an AppSearch using DrLocator

The installer can search for a particular file, registry entry or directory during an
installation. These searches are important in determining whether the user has already
                                                           Windows Installer Technology

installed a version of an application, setting a property from a registry entry or locating
unwanted run time files that may be left on the machine after an uninstall so they can
easily be deleted.
 1.    Create an Empty MSI project
 2.    In the Installation Expert – Features Detail – Files - add at least one file to the
       installation to create a component
 3.    Create a file to search for e.g. In Notepad create mysearch.txt and save it to
       C:\Program Files
 4.    In the Setup Editor click on Tables tab, then go to Property table, right click and
       select New - Row. Create a property called APP_TEST and set value equal to 1
       . This property, when set to 1, allows the user to make use of the DRLocator
       table and RegLocator table with the AppSearch table to search for and retrieve
       files paths or registry key values.
                                                      Windows Installer Technology

   There are three tables that you need to populate to search for a file; AppSearch,
   Signature, and DrLocator.
5. Select AppSearch table. Right click and select New Row. Under the       Property
   field set the name of the property you want the search to populate           (i.e
   APP_TEST)
6. In the AppSearch table the Signature is a name that will link the AppSearch table
   to the Signature table as well as the DrLocator table. Highlight Signature_ field
   and enter a signature name (i.e MyFile)




7. In the Signature table right-click to create a new row. Under the Signature field
   enter the name of the signature as previously chosen in step 5 (i.e MyFile).
   Remember this name links all the tables together
                                                        Windows Installer Technology

8. Still in the Signature table the FileName is set to the name of the file that you are
   searching for (a unique file name). You must also include the file extension




 If you want to look for certain versions of the file you can fill out the MinVersion
       and MaxVersion fields
                                                         Windows Installer Technology

   If you want to look for certain sizes of the file you can fill out the MinSize and
         MaxSize fields
   If you want to look for certain dates of the file you can fill out the MinDate and
         MaxDate fields
   You can also look for certain languages of the file by populating the Language
         field


9. In the DrLocator table, again right click to create a new row. Under the Signature
   field set the name to the signature name previously chosen in step 5 (i.e MyFile)




      In the DrLocator table the ParentDirectory can be null or you can populate it
         with another entry located in the Dr Locator table and then the path that you
         choose would be added to the parent directory
      In the DrLocator table the Path can be filled with a hard coded path to search
         for that file in that specified location
                                                              Windows Installer Technology

       If you leave both the ParentDirectory and the Path fields blank it will search
          all fixed drives on the user's PC
       In the DrLocator table the search depth is how deep you want the search to
          go down the directory structure to find the required file. If you set the depth to
          0 then it will only give the files that match in root. For example, if you set it to
          0 it will find C:\mysearch.txt, but will not find C:\Program Files\My
          App\mysearch.txt which has a search depth of 2
10.   The property that you have created in the AppSearch table (i.e APP_TEST) will
      populate with the location of the file if it is found
11.   To check to make sure that your file has been found you can display this
      Property on a dialog. You can do this by creating text on a dialog and the text
      you will display is [PropertyName]
12.   Go to the Dialogs tab and highlight a dialog box, which will be displayed during
      your practice install/test. Select actual dialog box and right-click on this Dialog
      box, select Add, select Text
13.   In the Properties text panel, tab down to the Control Text window and enter the
      Property name (i.e [APP_TEST]). Be sure to include the square brackets [ ] so
      the MSI knows to display the value assigned to the property and not just the text
      string ‘APP_TEST’
                                                           Windows Installer Technology




14. Now Compile and Run. Your chosen dialog box should display the full path to the
   file you’ve been searching for (i.e. the file added in step 3.)
                                                           Windows Installer Technology




NOTE: If result displays “1” go to Explorer – View – Options – View Folder – Show
hidden file extensions e.g. mysearch.txt.txt


Remove an existing file during an installation


During an installation, you might want to remove existing files from the destination
machine. One reason for this is to save on disk space. Another reason is to avoid
possible file conflicts between a previous installation and a new installation. This may
cause errors during installation or may cause files that have previous versions on the
destination machine, not to be installed.


One of the main features of Wise for Windows Installer is for all files and references to
the product to be completely removed on uninstall. On uninstall Wise for Windows
Installer follows the installation script to remove any files or registry entries that were
                                                                Windows Installer Technology

installed. Because the application may produce run time files that aren’t contained in the
install script, they get left behind on uninstall, along with their folders.


If we know the exact location of these files we can hard code the remove file table to find
and remove the unwanted file. The problem with this is the installation path of the
application may be changed at a later date, which would render the remove file entry
redundant. We can overcome this problem by first using an AppSearch to locate the file.
The AppSearch sets a property to the value of the path to the file. The Remove File table
then uses that property to remove the file.




LAB – How to Remove a File using Appsearch


Below is an example of a ‘remove file’, using Appsearch to initially locate the file.


Firstly create a new text file, call it mysearch.txt and place it in any folder on the
destination machine.


  1) The first part of the procedure is to locate the file mysearch.txt. We first populate
      the AppSearch table. Make sure to place the property name in caps. The signature
      field is a user-defined entry
  2) The next table is the DrLocator table. The DrLocator table holds the information
      needed to find a file or directory by searching the directory tree. The Signature
      column is an external key to the first column of the Signature table. This field may
      represent a unique file signature listed in the Signature table. If the value in this
      column is absent from the Signature table, then the search is assumed to be for a
      directory pointed to by the DrLocator table. If the parent field is left blank the
      search checks all fixed drives for the file to a dept specified by the depth column
      (i.e. depth 0 = C:\, depth 1 = C:\Program Files)
  3) In the DrLocator table create two entries – one which searches for MyFile (MyFile
      returns the Path+FileName) and another entry which searches for MyFileFolder
      (MyFileFolder returns the Path only). Note that MyFile is the parent of MyFileFolder
Windows Installer Technology
                                                         Windows Installer Technology




4)   Our next table is the Signature Table in the ‘Remove File Process’. In this table we
     specify the file name to be deleted (followed by its extension). We can specify
     versions, sizes, date or language of the required file.      For this example the
     Signature Table should contain – Signature = MyFile and FileName=mysearch.txt
5)   Amend AppSearch Table to search for parent e.g. MyFileFolder which will return
     path instead of path + file name
                                                         Windows Installer Technology




6) Now the file should have been located (if present) with the AppSearch routine
   above. The next step is to remove the file
7) In the RemoveFile table each column should be populated as follows: FileKey is
   just primary key do not use signature here - create primary key e.g. Key1. We must
   select a component that is always installed as part of the MSI. A Component that is
   part of the Feature Complete can be chosen because the Complete Feature is
   always installed. If the file name is left empty here the Remove File Action will
   remove the specified folder, if it is empty
                                                 Windows Installer Technology




FileName contains the file you want to remove
DirProperty should contain name of appsearch e.g. APP_TEST


The Install Mode Column can contain the following flags:
                                                               Windows Installer Technology

                1 - Removes file when associated Component is installed
                2 - Removes file when associated Component is uninstalled
                3 - Removes on the two above scenarios
We should now have a fairly good idea how to remove files that were resident on the
destination computer. We use the same operation to remove runtime files.



LAB – Performing an AppSearch using RegLocator


Using the example of the WinZip.msi application package perform the following steps to
create an AppSearch using the RegLocator table.
 1)    Create a copy of the WinZip.msi file and call it WinZip2.msi
 2)    Under Product Details in the Installation Expert generate a new product code
 3)    Double click on the System Search link under Target System in the left hand
       frame
 4)    Click ‘Add’ and choose ‘Registry’
 5)    Call the ‘Property’ REGLOCATE (ensure that you use all capital letters as this is
       a public property)
 6)    Under ‘Operation’ choose ‘Read directory name from Registry’
 7)    Set ‘Root’ to HKEY_LOCAL_MACHINE
 8)    Set     ‘Key’   to   the   registry   key   you   are    going   to   search   for   i.e
       SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\winzip32.exe
 9)    Set the ‘Value Name’ to a specific value contained under this key. In the above
       example Path is the value name
 10)   Go to the Setup Editor and click on the Tables tab. Open the Property table
 11)   Add a new property called REGLOCATE and set its value to NO
 12)   Go to Setup Editor, Product tab and select Launch Conditions
 13)   Add a new Launch Condition setting the Condition to REGLOCATE ~= “NO”. Set
       the Description to “Please Uninstall the previous version of WinZip”
 14)   Next go to the InstallExecuteSequence table in the Setup Editor. Ensure that
       AppSearch has a lower value than LaunchCondition
 15)   Next go to the InstallUISequence table in the Setup Editor. Ensure that
       AppSearch has a lower value than LaunchCondition
                                                           Windows Installer Technology

 16)   Compile the WinZip2.msi and to test it first install WinZip.msi. Now try to install
       WinZip2.msi on top. What error message do you get? It should correspond to the
       Description that you set in your Launch Condition
       install WinZip.msi and try to install WinZip2.msi. What happens now? The
       installation continues without an error message because the registry value that
       we were searching for does not exist.



Transforms


What is a Transform


A transform is a special type of windows installer file (MST) that customizes a windows
installer Installation Package.



What do Transforms do?


A transform is a collection of changes in the form of .MST files that you apply to a base
installation package at installation. When you apply transforms to an .MST, Windows
Installer can add or modify data in the installation database. This may involve modify
information in tables or adding or removing tables completely. Transforms are applied at
run-time (using a command line) along with the base MSI to apply changes to that MSI.



Why use a Transform?
By applying a transform to a base MSI (Installation Package), the installer can customize
this installation by adding or replacing data in the MSI database.


Although optional you can use transform for a variety reasons including:
1)             Encapsulating numerous customizations of a base package required by
different groups. In a large organization you may only need a single .msi file and a library
of appropriate transforms for each group of users
2)             Adding new features to an existing application package
                                                              Windows Installer Technology

3)             To replace manufacturers defaults with defaults appropriate to a specific
organization. Allows the administrator to eliminate or reduce user intervention
The installer registers a list of transforms required by the product during the installation.
The installer must apply these transforms to the product's installation package when
configuring or installing the product. If a listed transform is unavailable, and if the
transform source resiliency cannot restore it, the installation fails.


EXAMPLE:
Suppose you are a systems administrator who is deploying a new version of workgroup
software. You can use the transform to customize the installation for the needs of
different departments.    You can turn on multi-language support components for the
International Marketing Department, and Install extra spreadsheet functions for the
Accounting Department. To achieve this we need to create 2 different transforms based
on the main installation of the workgroup software. In each transform you make the
specific changes.     Then during the installation, you make sure that the appropriate
transform is applied for each department.


Transforms alter the installation database and can be used to encapsulate the various
customizations of a base package required by different groups of users.


For Example:
In organizations where the Finance and Staff Support departments require different
installations of a product, the product's base package can be made available to
everyone at one administrative installation point with the appropriate customizations
distributed to each group of users separately as transforms. Administrators can also
apply multiple transforms on-the-fly during an installation to efficiently assign the most
appropriate installation to different users.


Compared to command line modifications Transforms:-
    Are persistent
    Can modify public and private properties
    Can modify the registry
    Specify the install state (advertised, run locally or run from source)
    Make a feature unavailable to users
                                                          Windows Installer Technology

    Add modify or remove shortcuts
    Modify the upgrade behavior



How do I apply a transform to an installation?


A transform must be applied to a base installation database during installation; it cannot
be applied beforehand. It must be applied using a command line option.
EXAMPLE
To apply a transform while running an installation:
Where MyApp.msi is the name of your .MSI, and TransformName.mst is the name of
your transform. Your command line would read as follows:


Msiexec /i MyApp.msi TRANSFORMS=TransformName.mst



Applying Multiple Transforms to an msi


Ensure that the .MST files and the .msi are located in the same location. Ensure
command line is changed to display the location of the transform and msi. Use name of
msi and transforms (not the full path).


Syntax
msiexec /I app.msi TRANSFORMS=transform1.mst;transform2.mst


EXAMPLE:
Both the msi and MST are located in D:\Data\Dramweaver
Correct command line to use:-
D:\Data\Dreamweaver> msiexec /I dreamweaver.msi TRANSFORMS=trans1; trans2




Transforms – Types of Methods
                                                            Windows Installer Technology

The following are two methods which can be used when applying a transform to an .msi


Dynamic method: place .MST and msi in same folder and configure installation to
reference transform. Original msi unchanged. Multiple sets can be used to for e.g. set an
organizations/ department templates followed by another transform specifically adapted
for a particular group of users. The transform(s) is applied to the msi at deployment and
the customizations are persistent unless the app is uninstalled / installed.


Static method: run against the administrative image of an application to permanently
change the administrative msi. Less commonly used.



Types of Windows Installer Transforms
There are four types:-
      Embedded transforms
      Un-embedded transforms
      Secured transforms
      Unsecured transforms
Embedded transforms are stored inside the .msi file of the package. This guarantees
to users that the transform is always available when the installation package is available.
Alternatively for example if the installation source is read only such as a CD or network
share, transforms may be provided to users as stand-alone .MST files. To add an
embedded transform to the transforms list, add a colon (:) prefix to the filename.
Because the installer can always obtain the transform from storage in the .msi file,
embedded transforms are not cached on the user's computer. Embedded transforms
may be used in combination with secured or unsecured transforms.


Un-embedded transforms are stored separate from the .msi file of the original package
and these transforms are cached separately on the user's computer. They may be used
in combination with secured or unsecured transforms.


Secured transforms are sometimes necessary for security reasons to prevent users
with low rights from modifying an unsecured transform. Secured transforms are stored
locally on the user's computer in a location where, on a secure file system, such users
                                                              Windows Installer Technology

don’t have write access. These transforms are cached in this location during the
installation or advertisement of the package. During subsequent install-on-demand or
administration installation of the package, the installer uses the cached transforms. The
removal of the product by any user removes all secured transforms for that product from
the user's computer. If the installer finds that a secured transform is not locally available,
it then attempts to restore the transform cache from a source. Secure transforms can be
secure-at-source (restored from the root of the source of the .msi file) or secure-full-path
(restored from the original full path specified by the transforms list): To specify secured
transform storage, set the Transform Security policy, set the TRANSFORMSECURE
property, or pass the @ or | symbol in the transforms list.


Unsecured Transforms are those that have not been secured as described. When a
package is installed or advertised as a per-user installation, and has unsecured
transforms, the installer saves the unsecured transforms in the Application Data folder in
the user' profile. This enables a user to maintain their customization of a product while
moving between computers. When the package is installed or advertised as a per-
machine installation, and uses unsecured transforms, the installer saves the unsecured
transforms in the %windir%\Installer folder. If the cached copy of the transform becomes
unavailable, the installer can restore the transform cache using a source listed in the
SOURCELIST property. You cannot include secured and unsecured transforms in the
same transforms list.



Conditional Logic



Conditions

Conditions are expressions that can be either evaluated to true or false. By associating a
condition with an element such as a property, feature or component within your MSI, you
can determine whether something happens or not during the installation of that MSI.
Through evaluating a condition to either true or false the MSI can allow or disallow an
installation to continue, display certain dialogs depending on user input, install or not
install certain features or components, execute or not execute certain actions.
                                                             Windows Installer Technology

As part of the Wise for Windows Installer tool, conditions are already created for you
where appropriate. However, conditions are integral to most complex installations and in
order to carry out advanced customization of your MSI they will almost certainly need to
be used.



Conditional Statement Syntax

The table below summarizes the syntax to use in conditional expressions.

 Item                     Syntax
 value                    symbol | literal | integer
 comparison-operator < | > | <= | >= | = | <>
 term                     value | value comparison-operator value | ( expression )|
 Boolean-factor           term | NOT term
 Boolean-term             Boolean-factor | Boolean-factor AND term
 expression               Boolean-term | Boolean-term OR expression
 symbol                   property | %environment-variable | $component-action | ?component-
                          state | &feature-action | !feature-state

        Symbol names and values are case-sensitive.

        Environment variable names are not case-sensitive.

        Literal text must be enclosed between quotation marks ("text").

        Non-existent property values are treated as empty strings.

        Floating point numeric values are not supported.

        Operators and precedence are the same as in the BASIC and SQL languages.

        Arithmetic operators are not supported.

        Parentheses can be used to override operator precedence.

        Operators are not case-sensitive.

        For string comparisons, a tilde "~" prefixed to the operator performs a
         comparison that is not case-sensitive.

        Comparison of an integer with a string or property value that cannot be converted
         to an integer is always msiEvaluateConditionFalse, except for the comparison
                                                               Windows Installer Technology

       operator "<>", which returns msiEvaluateConditionTrue




Access Prefixes

The following table shows the prefixes to use to access various system and installer
information for use in conditional expressions.

 Symbol type                    Prefix            Value
 Installer property             (none)            Value of property
 Environment variable           %                 Value of environment variable.
 Component table key            $                 Action state of the component.
 Component table key            ?                 Installed state of the component.
 Feature table key              &                 Action state of the feature.
 Feature table key              !                 Installed state of the feature.



Logical Operators

The following table shows the logical operators in conditional expressions, in high to low
precedence order.

 Operator        Meaning
 Not             Prefix unary operator; inverts state of following term.
 And             TRUE if both terms are TRUE.
 Or              TRUE if either or both terms are TRUE.
 Xor             TRUE if either but not both terms are TRUE.
 Eqv             TRUE if both terms are TRUE or both terms are FALSE.
 Imp             TRUE if left term is FALSE or right term is TRUE.



Comparative Operators

The following table shows the comparison operators used in conditional expressions.
These comparison operators can only occur between two values.

 Operator        Meaning
 =               TRUE if left value is equal to right value.
 <>              TRUE if left value is not equal to right value.
                                                                Windows Installer Technology

 >               TRUE if left value is greater than right value.
 >=              TRUE if left value is greater than or equal to right value.
 <               TRUE if left value is less than right value.
 <=              TRUE if left value is less than or equal to right value.



Substring Operators

The following table shows the substring operators used in conditional expressions.
Substring operators can occur between two string values.

 Operator        Meaning
 ><              TRUE if left string contains the right string.
 <<              TRUE if left string starts with the right string.
 >>              TRUE if left string ends with the right string.



Bitwise Numeric Operators

The following table shows the bitwise numeric operators in conditional expressions.
These operators can occur between two integer values.

 Operator        Meaning
 ><              Bitwise AND, TRUE if the left and right integers have any bits in common.
 <<              True if the high 16-bits of the left integer are equal to the right integer.
 >>              True if the low 16-bits of the left integer are equal to the right integer.



Where can you create conditions?


Conditions can be created in five main areas within Wise for Windows Installer –
     1. The Feature Page
     2. Launch conditions
     3. Conditions for Controls on Dialogs
     4. Conditions attached to Components
     5. Conditions for Actions
                                                              Windows Installer Technology

1. Feature page
You can add conditions on the Features page on the Installation Expert. The condition
will then appear in the features drop down list. For example you could add system
changes to a feature and these changes will only be installed if the feature is installed.
You could then set a condition under the feature so that these changes are only installed
if the feature is installed and the condition evaluates to true.




LAB – Adding a Condition to a Feature


1.     On the feature page in the Installation Expert - click on the name of the feature to
       which you want to add a condition. You will see in the example below that
       “Feature1” is selected.
                                                         Windows Installer Technology




2.     Click on the Add Condition command button situated on the right of the dialog.
       The Feature Condition dialog box appears.
3.     Click on the Build command button and create you condition using the Condition
       Builder




2. Launch Conditions

What are Launch Conditions?
Launch Conditions are requirements that the destination computers computer system
must meet for the installation to be successful.
                                                             Windows Installer Technology

Launch Conditions are set in the Launch Conditions icon under the Products Tab in the
Setup Editor. The Launch Conditions icon lets you create new launch conditions and
edit existing launch conditions.


Through setting a Launch Condition you can set some of the basic requirements such as
the required operating system or screen attributes. For example the following condition
ensures that the installation will only continue if the target computer has a screen
resolution of 800 x 600


ScreenX >= 800 AND ScreenY >= 600


You can also set a Launch Condition to make sure the user installing your application
has Administrator privileges by using the condition "AdminUser". If the user does not
have the required Administrative privileges, the AdminUser property is not set and the
condition evaluates to false, causing the installation to abort.



Why Use Launch Conditions?
We use them to define more complex system requirements. For example you can set
them up to check values of environment variables on the destination computer or the
values of properties.


It Contains 2 columns: Conditions and Description.
      Values in the Condition’s column represent conditions that must be true for the
       installation to begin.
      If the condition is not true or does not meet the specified standard the text in the
       Description Column is displayed to explain to the user why the installation
       cannot continue.
Windows Installer Technology
                                                          Windows Installer Technology

3. Conditions for Controls on Dialogs
You can also apply conditions to controls that appear on dialogs such as radio buttons,
check boxes and text boxes. You can set conditions to enable, disable, show, hide or set
as default a control. For example, if you double click on the “Next” command button in
the License Dialog under the Dialogs tab on the Setup Editor and select the Condition
tab you will see where Wise for Windows Installer has already set a condition for you.
                                                           Windows Installer Technology



These conditions determine whether the user can proceed with the installation. As soon
as the user accepts the license agreement, “Accept” is set to “Yes” and the next button
will then be enabled and the user can continue to the next dialog and with the
installation.


Conditions can also be set in the Events tab on a Dialog. The example below is applied
to a Dialog where the user is required to enter a Password and a Confirm password
before he or she will be allowed to continue with the installation. In the first screen shot
below, you can see that a condition “PASS And (PASS = CONFIRMPASS)” has been
set, where “PASS” is the property given to the password field and “CONFIRMPASS” is
the property given to the Confirm Password field.


This ensures that the user must complete the password field and that the information
inputted into the password field matches the information inputted into the Confirm Pass
field. Then he or she will be allowed to proceed to a new dialog called
Start_Installation_Dialog.


The screen shot below states that if the user either fails to enter a password or the
password and Confirm password do not match then the installation will move onto a
warning dialog explaining that these items must be completed before he or she will be
allowed to continue with the installation.
                                                           Windows Installer Technology




4. Conditions attached to Components


You can also attach conditions to components under the Components tab in the Setup
Editor. If you do this, then the component will only be installed if the condition evaluates
to true.   To attach a condition to a component, go to that component under the
Component tab in the Setup Editor and right click on it. Select Details from the drop
down list. Again you can create your condition by Clicking on the Build command button
and using the Condition Builder.
                                                           Windows Installer Technology




5. Conditions for Actions
You can also set conditions on actions by selecting MSI Script tab. The MSI Script tab
contains a number of standard Wise for Windows Installer actions whose conditions
should not be altered. However, you may find the need to set a condition for any custom
actions you may have created as part of the installation. Below is an example of a
custom action that has been set up to register a DLL. The condition that is included at
the bottom of the dialog “Not Installed” is simply giving the instruction that if the DLL is
not already installed on the system to install it.


(See also section on Custom Actions)
                                                           Windows Installer Technology




The Condition Builder
Perhaps the easiest way to create a condition is through the use of the Condition
Builder. The Condition Builder helps remove some of the common mistakes that are
made when creating conditions by providing you with a list of existing Features,
Components, Environment Variables and Properties to choose from. The selection of
operator buttons that are available to you when building a condition in Wise for Windows
Installer are also provided along with the tilde button (~), parentheses button and
quotation button ( “ ). When you have built your condition you can check that the syntax
of that conditional statement is correct by clicking on the Check Syntax button. This will
bring any errors to your attention through the use of an error box.
                                                              Windows Installer Technology




Operators and precedence are the same as in the BASIC and SQL languages.



Values Types inside a Condition
You can use 4 different types of values inside a condition:
   1. Properties
   2. Environment Variables
   3. Integers
   4. String Values



1. Using Properties in a condition

Property values in Wise for Windows Installer are case sensitive by default. However,
you can make them case insensitive by placing a tilde (~) before the operator. You can
either check whether a property is true or not or check whether a property evaluates to a
certain value.
                                                             Windows Installer Technology




If you wish to check that a property evaluates to a certain value you should use the
Condition Builder.


      In the Condition Builder dialog box select the Property folder from the list of
       objects in the Fields list. The Values list will display the list of properties that are
       available to you as part of the installation.
      From the Values list double click on the property you require. This property will
       now appear in the Condition list box.
      Select the equals sign (=) from the selection of operators in the middle of the
       dialog. An equal’s sign will therefore be inserted in the Condition list box.
      Click on the Condition list box after the equals sign and enter the value you wish
       to check your property against.
      Click the OK button on the Condition Builder dialog box
                                                            Windows Installer Technology

2. Using Environment Variables in a condition
Environment Variables are not case sensitive but must be preceded with a percent
symbol (%). To build a condition that checks an environment table you will again make
use of the Condition Builder. The same steps are taken to create this condition as were
taken when building the condition to check a property. However, on this occasion you
will select the Environment Variable folder from the list of objects in the Fields list and
the Values list will display the list of Environment Variables that are available to you on
the destination computer



3. Using Integers in a condition
Any Integer from –32,767 to 32,767 can be entered into a condition. However, floating
point numeric values are not supported by Wise for Windows Installer.



4. Using String Values in a condition
Text values can also be included in your condition. However, all literal text values must
be enclosed in double quotes.
For example: “string”



Condition - Checks if a Feature/Component is currently installed
A condition cannot only check if a feature or component is currently installed but you can
also create a condition to see how a feature or component is installed. A feature may be
installed to run advertised, locally or from source all of which are options you can set
when installing a feature or component.


LAB – Building Condition that checks installed state of Feature/Component


      In the Condition Builder dialog box select the feature folder from the list of objects
       available in the Fields list. The features being installed by the MSI will appear in
       the Values list. In the example below, there are 3 features – Client, Common
       and Server.
                                                            Windows Installer Technology

      Single click on the Feature you wish to check. You will see in the example below
       we have clicked on the Client feature.
      In the State list double click on Installed.
      Click the equals (=) command button.
      In the Install/Action state list double click on Absent, Advertised, Local or Source.
      When you have completed the condition, it should look something like our
       example below.
      Click OK in the Condition Builder Box




LAB – Building Condition that checks if a Feature/Component will be installed


      In the Condition Builder dialog box select the feature folder from the list of objects
       available in the Fields list. The features being installed by the MSI will appear in
       the Values list.    Again in the example below there are 3 features – Client,
       Common and Server.
                                                            Windows Installer Technology

      Single click on the Feature you wish to check. You will see in the example below
       we have clicked on the Server feature.
      In the State list double click on Action.
      Click the equals (=) command button.
      In the Install/Action state list double click on Absent, Advertised, Local or Source.
      When you have completed the condition, it should look something like our
       example below.
      Click OK in the Condition Builder Box.




Dialogs

Introduction
The Dialogs tab in the Setup Editor provides the user with a comprehensive list of
dialogs. You can tick the checkbox adjacent to a dialog to select it for your installation.
Some checkboxes cannot be ‘un-ticked’.
                                                            Windows Installer Technology



Dialogs can be divides into three different groups:
1. Install Dialogs, which are used for a new installation
2. Maintenance Dialogs, which can be employed in a repeat or an upgrade installation
3. Admin Dialogs, which are used for installation on a server.


All Dialogs - To view a complete list of all dialogs in your installation, expand the All
Dialogs folder. To expand or collapse a selected dialog set's children, use the right-click
menu.
Along with being able to select certain Dialog boxes, the Setup Editor allows the User to
edit these Dialogs and to add new ones if the ones provided are not sufficient for the
installation.



Working with Dialogs
In working with Dialogs you will learn to how to modify and add Dialogs, to use the
Dialog Controls.

       Dialogs can be edited to not only appear different, but to incorporate logic into
        the way they work.
       Dialogs are tied in with the MSI Script tab. The MSI Script tab contains three
        sequences: The Install Sequence, the Admin Sequence and the Advertising
        Sequence.
       Each of these sequences contains actions and Dialog Actions is one of these.
        Each sequence is included in every installation created, but these sequences are
        only run under certain circumstances.
       These action sequences are set up in a way that is considered standard and it is
        recommended that this order not be changed.


In most application - it is important that all Install Dialogs except the following are un-
clicked: Exit Dialog, User Dialog, Fatal Error Dialog.


The following illustrates how one of the three categories of Dialogs, is
employed for each sequence:
                                                                Windows Installer Technology

How the Setup Program is Run              Action Sequences           Dialogs
Application hasn’t been installed yet.    Install sequence           Install Dialogs
Launch Setup program to begin
installation.


The same version of the application       Install Sequence           Maintenance Dialogs
has been installed already. Launch
the Setup program or choose to edit
it in the Add/Remove Programs
control panel
The Setup Program is launched with        Admin Sequence             Admin Dialogs
the /a command line, which starts the
application in administrative mode.



Types of Dialogs


Welcome Dialog
It welcomes a user to the installation and can suggest closing other application for the
duration of the install or anything appropriate at this time.


License Dialog
Display the License Agreement for your application and is usually accompanied by an ‘I
accept the above license agreement’….’ and ‘I do not accept……..’ button.


ReadMe Dialog
This displays the ReadMe file for your application. .RTF/TXT files can be imported and
edited here.


User Information Dialog
This can be used to request information about the user, e.g. name and company.


Single Feature Destination Dialog
                                                              Windows Installer Technology

The Destination Folder Dialog displays the default directory for the installation, providing
the user with an option to browse for a different location.


Installation Type Dialog
This adds the Select Installation Type Dialog which lets the end user choose one of
three installations: Complete, Typical or Custom.


Select Feature Dialog
This is where a user chooses which feature they will install. How much a user can
choose or change is dependant on how much control you have allowed for when
creating the dialog.


Start Installation Dialog
Under this dialog are three options. As it is the user’s final chance to exit the installation
it is advisable not to untick the Cancel Checkbox. The other two checkboxes are:
‘WaitingForCosting’ , which displays the message “Please wait while the installer
determines your disk space requirements...”      and ‘OutofDisk’ which tells the user that
they are ”Out of disk space. The highlighted volumes do not have enough disk space
available for the selected features.”



Using the Dialogs Page
Essentially the Dialogs page is used to choose the dialogs that you want to appear
during your installation. Which dialogs and the amount of dialogs that you select
determine the amount of control an end user has over the installation. The Dialogs page
in the Installation Expert is the most straightforward way to determine which of the main
dialog boxes will appear and which won’t. However, all of the dialogs shown cannot be
disabled in the Installation Expert. If you try to do so an error message will appear.
                                                            Windows Installer Technology




In order to exert a more exacting control over the Dialogs we need to switch to the Setup
Editor and click on the Dialogs tab.


In the Dialogs tab you can modify and edit the appearance, contents and behavior of
dialogs. Dialogs can be turned on or off by ‘unticking’ the checkboxes adjacent to each
dialog. It must be noted that this does not work for all dialogs such as the User Exit or
Fatal Error dialogs which can appear whether they have been marked/unmarked or not.


It is also possible to introduce more control into your dialogs. This can be done by going
to the Dialogs tab in the Setup Editor and selecting the dialog that you wish to modify.
Right click and select Add> and whichever element you want to insert. For most controls
a Properties dialog will appear and it is within these that the dialogs can be edited.
                                                          Windows Installer Technology

Creating New Dialogs
Right-click in the list of dialogs where you want the new dialog to be and Select New>
Dialog. Go through the process of creating a new dialog, editing and selecting properties
and values. All controls are associated with a Property and there are many types of
controls that can be added to a dialog: Billboards, Checkboxes, Buttons, etc.


The properties dialog for any control contains several tabs: Control, Graphic, Events,
Help item or a Condition. It must be noted that all controls do not have the same tabs.
(E.g. a Billboard does not have a Graphic tab).


The Control Tab in the properties dialog is what determines what the dialog looks like
and how it behaves. See the graphic below for details on the various settings that can be
employed. (Again these settings vary depending on which control, the example below is
the properties tab for a button.)
                                                         Windows Installer Technology




Setting an Event on a Control


The Events option determines the events that the control can send and receive. It can
be used to control the way in which dialogs are displayed. When an event is generated it
is considered published. The Events page of the control’s Properties dialog determines
which events a given control publishes and which is subscribes to. The keys to the right
of the Publish Events window are for editing, adding or removing the events. If you
want to add an Event, select the Add button and the Publish Event Details dialog box
appear.
                                                             Windows Installer Technology




The Event field is for entering the type of event you want added to your dialog.


The Argument field is used to provide the argument for the event. The Event will be
ignored if this field has no value.


The Condition field is for building a condition, which must be true if the event is to be
included. Use the Build button to the right of the Condition field to build a condition. In
the case of the condition field being left blank the Event will simply occur by default.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:27
posted:8/27/2012
language:English
pages:151
Description: Windows_Installer_Training_Material