Video Screencast Help

Application Packaging Best Practices for Windows XP: Part 2

Created: 21 May 2007 • Updated: 09 Apr 2009
Language Translations
Scott Hardie's picture
+1 1 Vote
Login to vote

The Setup Editor is an alternate view of your installation package, which allows you to edit the .MSI database tables directly. This view gives you fine control over every aspect of the installation, including some settings which are not available from the Installation Expert.

Editor's Note: Here's a list of the other articles in this series: Introduction, Part 1, Part 2, Part 3, Part 4, Part 5.

Using the Setup Editor

Any changes made in the Setup Editor are automatically reflected in the Installation Expert, and vice versa. Within the Setup Editor, there are six tabs containing various types of information for the .MSI database. This section will highlight a few of the more commonly used tables and functions that may be used in a .MSI package.

Components Table

The Components table lists all of the components associated with an application. A component is a collection of files, registry keys, and other resources that are all installed or uninstalled together. One of the resources within a component is designated as the keypath for that component. Typically, a file or registry value is chosen as the keypath. The Windows Installer service checks for the existence of the keypath when verifying whether a Windows Installer component is properly installed. If the keypath resource is missing for any reason, the Windows Installer service treats that component as broken and will install all resources associated with that component.

To view the Components table, do the following:

  • In the Setup Editor, go to the Tables tab.
  • Select the Components table from the left side of screen.

The Components table is an at-a-glance view of all components contained within an application package. Each entry lists the directory and keypath associated with a component. A keypath can be a file, registry entry or ODBC data source. Use the Components tab to view all resources associated with each component.

The Components tab can be used to add, delete and/or modify components and associated resources (files, registry entries, shortcuts etc.) as needed.

As a general rule, the keypath specified for each component should be necessary for the application to function properly. The keypath of a component is identified by a key symbol next to the file, registry entry or data source. At times, it may be necessary to change the keypath for a component. For example, a readme.txt file should not be set as a keypath for a component. If a readme.txt file is set as a keypath, this file can be moved to another component such as the component containing application executable.

To set a keypath, do the following:

  • In the Components table, select the component which to alter the keypath.
  • In the component, select the resource containing the file, registry entry or ODBC data source to be defined as the keypath.
  • Click right mouse button on registry entry or ODBC data source to be defined then select Set as Key from the menu.

Directory Table

The Directory table lists the directory layout for the application. Each directory is listed with a Directory property, a Directory_Parent and DefaultDir entry. Windows Installer refers to the entries in the Directory table to determine the directories need to install an application. By default, Windows Installer sets properties for a standard set of system folder paths in the Directory table. (ie. ProgramFilesFolder, ProgramFilesMenuFolder, WindowsFolder, System32Folder etc.) Refer to the Windows Installer SDK and search on System Folder Properties for a complete list of standard system folder paths. All directory properties listed in the directory table have to be linked back to the TARGETDIR directory property. TARGETDIR is defined as the root drive in which the application will be installed. Typically this is the drive with the most disk space. When creating application packages or running SetupCapture, the Directory table is populated with the appropriate directory entries needed to install the application.

To view the Directory table, do the following:

  • In the Setup Editor, goto the Tables tab.
  • Select the Directory table from the left side of screen.

Examples, the directory entries listed below refer to the path C:\Program Files\Citrix\ICA Client.

Directory Property Directory_Parent DefaultDir
ProgramFilesFolder TARGETDIR .:ProgramF|Program Files
INSTALLDIR ProgramFilesFolder Citrix
ICA_Client INSTALLDIR ICACLI~1|ICA CLIENT

Registry Table

The Registry table lists all of registry entries to be installed with the application. Registry entries can be added, modified or deleted using the Installation Expert or SetupEditor views.

To view a list of registry entries for an application package, do the following:

  • In the Setup Editor, go to the Tables tab.
  • Select the Registry table from the left side of screen.

The following registry entries are commonly captured in an application package and can be deleted.

HKCU\Software\Policies and All Subkeys
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer and All Subkeys
HKCU\Software\Microsoft\Internet Explorer\Toolbar\ShellBrowser and All Subkeys
HKCU\Microsoft\Windows\CurrentVersion\Internet Settings and All Subkeys
HKLM\Software\Policies and All Subkeys
HKLM\Software\Microsoft\Cryptography and All Subkeys	
HKLM\Software\Microsoft\Windows NT\CurrentVersion Winlogon\GPExtensions and All Subkeys
HKLM\System\CurrentControlSet\Services\TCPIP and All Subkeys
HKLM\System\CurrentControlSet\Services\KMixer and All Subkeys


Additional registry entries may appear in an application package and must be handled on an individual application specific basis. Registry entries can be deleted from the Registry page under Installation Expert or from the Registry Table under Setup Editor. As always, use caution and discretion when deleting entries from the registry.

Standard Actions

Standard actions are typical functions performed during the installation or maintenance of an application. The Windows Installer service contains many built-in standard actions, which are used in .MSI packages. Below is an example of some built-in standard actions:

Action Description
InstallFiles Copies files from the source directory to the destination directory
MoveFiles Locates existing files and moves or copies files to a new locations
WriteIniValues Writes .ini file information
ResolveSource Determines the source location of the application package and sets the SourceDir property.

A sequence number organizes all actions within tables in the Windows Installer package database. The sequence number specifies the order of execution for the standard actions which controls the installation process.

ResolveSource action

As mentioned above, the ResolveSource action determines the source location of the application package and sets the SourceDir property within .MSI package. Setting this action enables flexibility within an application package during installation by allowing an installation to reference the source location of the application package without hard coding a path in the application package. For example, if an external executable must be called during an installation, the necessary file can be copied to the application package directory then reference by using the following syntax:

[SourceDir]Filename.exe
[SourceDir]Directory\Filename.exe


In order to use or reference the SourceDir property in an application package, the ResolveSource action must be called first. The SourceDir property cannot be used until after the ResolveSource property has been called in the InstallExecuteSequence table. The ResolveSource action is included in the CompanyNamestandard templates for use in all application packages created in-house. This action has been defined as follows:

Action Condition Sequence
ResolveSource NOT Installed 820

The 'NOT Installed' condition disables this action from running when uninstalling the application. The ResolveSource property must also be specified after the CostInitialize action (sequence 800) in the InstallExecuteSequence table. Refer to the Windows Installer SDK for additional information on this topic.

Legacy Packaging Technique - Isolated Components

Isolated components (also known as side-by-side DLLs) allow different versions of shared system files to be run from the application directory. In the past, application installations would overwrite shared system files in the System directory with newer or older versions causing other applications to break. Windows installer enables application packages to copy shared files (commonly shared DLLs) of an application into the application directory rather than to a shared location. This private set of files (DLLs) is then used only by the application. This functionality provides the following advantages:

  • The application always uses the versions of shared files with which it was deployed.
  • Installing the application does not overwrite other versions of the shared files by other applications.
  • Subsequent installations of other applications using different versions of the shared files cannot overwrite the files used by this application.

To enable applications to keep a private copy of shared system files, Windows XP checks for the presence of a .LOCAL file in the application's folder. This file is created by Windows Installer and typically has the same as the application's .exe with .LOCAL appended.

To create an isolated component, do the following:

  1. In the Setup Editor, select the Components tab.
  2. In the Components window, find the primary application executable and expand the list.
  3. Right click on the component in which to create an isolated component, select New > Isolated Component.
    *** NOTE: As a general rule, isolated components should be associated with the primary application executable in the application package.
  4. Use the drop-down arrow and select the appropriate shared system file to isolate, click OK.

The shared system file will now display as an isolated component for the application.

Commonly Used Properties

A property in Windows Installer is equivalent to a variable. Properties contain information which is used during the installation of the application. The following are a few of the common properties that can be authored into an application package:

Property Description
ALLUSERS Determines where configuration information is stored
ARPSYSTEMCOMPONENT Prevents the program from being displayed in the Add/Remove Programs tool list
APPS_TEST Enables search functionality within a .MSI package
ROOTDRIVE Default drive for the install
REBOOT Force or suppress rebooting
SOURCELIST Appends additional source locations to the source list for the application
TRANSFORMS List of transforms to be applied to the database

Refer to the Windows Installer SDK for additional information on setting these properties and many others. Property names must appear in All Caps to be recognized by the Windows Installer service. Custom properties can also be authored into an application package as needed. (ie. Property Name - WINAPPS, Value - W:\)

 

 

  • In the Setup Editor view, select the Product tab, and then select Properties option in the left pane.
  • Right click in the right pane and then select New > Property.
  • In the Property Settings window, enter the name of the property in the Name field and the appropriate value in the Value field. All properties authored into an .MSI package must be in ALL CAPS.

Application Packaging Best Practices for Windows XP: Part 1

Application Packaging Best Practices for Windows XP: Part 3