Package definition

A package contains all the information Windows Installer needs for installing or uninstalling an application or a software product, and for rolling the graphical interface for the user.

The package is represented by a file with the .msi extension (Windows Installer database), which includes the database, and the data streams for different parts of the installation.

The .msi file can also have one or more transforms (.mst files), internal or external files, needed for the installation.

Application developers must authorize installations to use Windows Installer.

Because Windows Installer organizes the installations around features and components, and deposits all the information in a relational database, the authorization process for the installation of a package requires the following steps:

• identifying the features which will be presented to the users
• organizing the application in components
• populating the database with information about the installation
• validating the package

Package structure

• Features
• Components:
  • Files
  • Registries
  • Shortcuts
  • Extensions
  • Services
  • Odbcs
  • System variables
• Custom Actions

MSI Package Resources - Features

Applications are divided into features according to their functionality.

A feature represents a functional part of an application and it can be installed independently from the entire application.

Note: The relationships between features are hierarchical.

Observations:

• With captured applications, we have one mandatory feature in the package (the number of components that can be added to a feature should not exceed 1600 exceeding this number will, create new features)
• Vendor MSI applications are left as they are and will be controlled using the properties or Transform Files

The specific feature tables allocated towards Windows Installer are Feature and FeatureComponent.

More details about Feature Properties can be found here.

Feature Table

This table defines the logical structure of the features. In it, you can find information such as how features are related (in the columns Feature and Feature_Patent), the title of the feature with its description (in the Title and Description column), and the feature’s installation level.

A feature can have many subfeatures. The dependency between subfeatures and parent features is the following: if a subfeature is set to be installed, the parent feature will be automatically installed at the same time, but if the parent feature is set to be installed, it is not mandatory for the subfeature to be installed.

A feature can be set to be installed (or not) by modifying the value of the column Level.

Setting the value to 0 stops the feature from being on display. For a feature to be installed, the value from the column Level must be higher than 0 and at the same time, smaller or equal to the current INSTALLLEVEL.

Read the Properties section, for more information about the INSTALLLEVEL property.

FeatureComponents Table

The FeaturesComponents table defines the relationship between features and components. For each feature, this table lists all the components that add up to a feature.

Columns:

Feature - an external key from the first column of the Feature table.

Component - an external key from the first column of the Component table.

Remarks: there is a maximum limit of 1600 components per feature using Windows NT/Windows 2000 and a limit of 800 components per feature using Windows 95 and Windows 98.

Components can be shared by two or more features, meaning that the same component can be referred to by two or more features.

Components

Windows Installer installs and uninstalls an application in pieces called components, each of which has a unique code assigned called a GUID. Components are collections of resources that are always installed or uninstalled as a whole on the computer. Resources could be files, registries, shortcuts, or basically anything else that can be installed..

Components represent the base unit of a package, a piece of the application/products that will be installed. They contain a file or group of files, COMs (Component Object Model, they can be a dll or an exe), registries, shortcuts, etc.

Components are hidden from the user and when a user chooses to install a feature, Windows Installer will determine which components must be installed to produce that feature.

As you will see, Windows Installer always installs or uninstalls a component as a whole piece; it monitors each component on the base of the GUID id, specified in the Component table.

Observation: If two components have the same ID, they are treated as multiple instances of the same component, regardless of their content. Only one instance of a component can be installed on the computer at a time.

Since components are often shared, packagers must follow strict rules when specifying the components of a feature or an application.

This is essential for the correct functioning of Windows Installer’s “component tracking mechanism”.

More information about Component Properties can be found here.

The Rules to Organizing the Applications into Components

Components must be created so they can be installed and uninstalled without damaging other components. Uninstalling a component should not leave resources (such as unused files, registries, or shortcuts) behind. To make sure we don’t do this, we need to organize the resources we have into components following the next set of rules:

• You should never create two components that install a resource using the same name or the same location. When you duplicate a resource, we recommend using a unique name and location for every component.
• Two components can not have the same files as a “key path”. The key path must be a certain file or directory that belongs strictly to a component and allows Windows Installer to detect the component. If two components have the same file as a key path, Windows Installer will not know which of them is installed and which one is not. Two components can have the same directory as a key path, they just can’t have the same files.
• It’s not recommended to create components with resources that require to be installed in multiple directories on the user’s system. Windows Installer installs all the resources from a component in the same directory. It is not possible to install specific resources in subdirectories.
• Multiple COMs shouldn’t be included in the same component. If a component contains a COM, it must be a key path.
• More than one folder from a component shouldn’t be mentioned as a target for a shortcut.

Defining the Components

To organize an application into components, we recommend to follow the next steps:

1. Determine the hierarchical structure of all the directories and files (as well as other resources) used by the application.
2. Identify files, registries, shortcuts, and other resources used by various applications -- these are provided by components that already exist, like Merge Modules.
3. Define new components for each .exe,.dll, and .ocx type file. Those files are defined as the key path for the component to which they belong -- and a GUID is attributed to each component.
4. Define a component for each file that is the target of a shortcut. Those files are set as the key path for the component to which they belong.
5. Group the remaining resources from all the directories since they should be delivered together. If a pair of resources need to be delivered separately in the future (in a newer package version), it is recommended for them to be put into separate directories. A component for each directory must be defined.
6. To improve the performance of a package, it is a good practice to keep a small number of components. When Windows Installer has to rigorously verify the validity of the application, it will be divided into many components. In which case, any file can be chosen as a key path.
7. Add registries to already created components. Any registry that references a file must be included in the component that contains that file. All the other registries must be grouped logically together with the files that need them.

Component Table

You can find a list of Components in the Component table which includes the following columns:

Component

• the primary key of the table which identifies the registered component

Component id

• a unique identifier of the GUID component
• all the letters from GUID are capital
• if the column is null, Windows Installer does not register the component and it can not uninstall or repair it.

Directory

• an external key of an entrance from the Directory table

Attributes

• this column contains a bit flag that specifies diverse settings of the component

Basic attributes:

0 = the component has a file as a key path (for more detailed information consult msi.chm)

4 = the component has a registry as a key path

32 = the component has an ODBC as a key path Settings (various values for different settings are being added the three basic attributes)

8 = a shared dll is being incremented

16 = Windows Installer reevaluates the condition from the Condition column at the reinstallation of the package

128 = Windows Installer does not install or reinstall a component if the key path of the component already exists.

Condition - this column contains a conditional statement, which controls if a component is or isn’t already installed; if the condition is null or evaluated as true, then the component is installed; if the evaluation condition is false, the component does not install.

Key path - this value points towards a file or directory which belongs to the component that Windows Installer uses to detect the component.

Two components can not share the same resource as a key path. If the column isn’t null, then the key path can be a key from the Registry table, ODBC Data Source, or Files depending on the value from the Attributes column.

If the column is null, you can use the directory from the Directory column as a key path.

To install an empty component or create an empty directory on the machine, you need to create an entry in the Create Folder table.

If the component contains WFP files, those must be specified as Key Path.