Windows Installer

The Windows Installer (previously known as Microsoft Installer) is a software component used for the installation, maintenance, and removal of software on modern Microsoft Windows systems. The installation information, and often the files themselves, are packaged in installation packages, loosely relational databases structured as OLE COM Structured Storages and commonly known as "MSI files", from their default file extension. Windows Installer contains significant changes from its predecessor, Setup API. New features include a GUI framework and automatic generation of the uninstallation sequence. Windows Installer is positioned as an alternative to stand-alone executable installer frameworks such as older versions of InstallShield and Wise (later versions of both products are based on Windows Installer) and NSIS.

Logical structure of packages

A package describes the installation of one or more full products (Windows Installer does not handle dependencies between products) and is universally identified by a GUID (the PackageCode property). A product is made up of components, grouped into features.

Products

A single, installed, working program (or set of programs) is a product. A product is identified by a unique GUID (the ProductCode property) provides an authoritative identity throughout the world. The GUID, in combination with the version number (ProductVersion property) allow for release management of the software's files and registry keys. A product is not the same as a package: a package is identified by a unique GUID (stored in the Summary Information Stream) and provides identity and release management for all the contents of the .MSI file. Release management of a Product pertains only to changes in the files and registry keys that make up a software application. Release management of a package includes the package logic and other meta data that relates to how the package executes when running. For example, changing an EXE in the software application may require the ProductCode and/or ProductVersion to be changed for release management of the software application. Only adding a launch condition (with the software application remaining exactly the same as the previous version) would still require the PackageCode to change for release management of the .MSI file itself.

Features

A feature is a hierarchical group of components—a feature can contain any number of components and other features (a feature contained in another feature is called a "subfeature"). Many software packages only involve one feature. More complex installation programs usually display a "custom setup" dialog box at run time, from which the end user can select which features to install or remove.

The package author defines the product features. A word-processing program, for example, might provide features for the main program executable, the program's help files, and optional spelling checker and stationery modules.

Components

A component is the atomic part of a product—each component is treated by Windows Installer as a unit: the install developer cannot, for example, use a condition to specify to install just part of a component. Components can contain files, directories, COM components, registry keys, shortcuts, and other data. The end user does not directly interact with components.

Components are identified globally by GUIDs, thus the same component can be shared among several features of the same package or multiple packages, ideally through the use of Merge Modules (although, for this to work correctly, different components should not share any sub-components).

Key paths

A key path is a specific file, registry key, or ODBC data source that the package author specifies as critical for a given component. Because a file is the most common type of key path, the term key file is commonly used. A component can contain at most one key path; if a component has no explicit key path, the component's destination directory is taken to be the key path. When an MSI-based application is launched, Windows Installer checks the existence of these critical files or registry keys (that is, the key paths). If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This process is also known as self-healing or self-repair. No two components should use the same key path.

Setup phases

User interface

The user interface phase typically queries the target system and displays an installation wizard and enables the user to change various options that will affect the installation.

Execute

When the user clicks the Finish or Install button in a typical MSI installation wizard, installation proceeds to the Execute phase, in which software components are actually installed. The Execute phase makes system changes, but does not display any user-interface elements.

Execute phase happens in two steps:

Immediate mode. In this phase, Windows Installer receives instructions, either from a user or an application, to install or uninstall features of a product. The requests cause the execution of sequences of actions, which query the installation database to build an internal script describing the execution phase in detail.

Deferred mode. In this phase, the script built in immediate mode is executed in the context of the privileged Windows Installer service (specifically, the LocalSystem account). The script must be executed by a privileged account because of the heterogeneity of the scenarios in which a setup operation is initiated—for example, elevated privileges are necessary to serve on-demand installation requests from non-privileged users. (In order to run with elevated privileges, however, the package must be deployed by a local administrator or advertised by a system administrator using Group Policy.)

Execute sequence actions for a normal installation are stored in the InstallExecuteSequence table. An MSI database can also contain AdminExecuteSequence and AdvtExecuteSequence tables to define actions to perform for administrative and advertised installations.

Rollback

All installation operations are transactional. For each operation that Windows Installer performs, it generates an equivalent undo operation that would undo the change made to the system. In case any script action fails during deferred execution, or the operation is cancelled by the user, all the actions performed until that point are rolled back, restoring the system to its original state. Standard Windows Installer actions automatically write information into a rollback script; package authors who create custom actions that change the target system should also create corresponding rollback actions (as well as uninstallation actions and uninstallation-rollback actions). As a design feature, if applied correctly this mechanism will also rollback a failed uninstall of an application to a good working state.

Miscellaneous

Windows Installer allows applications to run directly from a network share, without the need for a local copy (run from source); it can repair broken installations by restoring damaged or deleted files, registry entries and application shortcuts; it supports per-user installation of applications; it can resolve component identifiers into paths, allowing applications to avoid hard-coded file paths; and it natively supports patches (.msp files made out of patch creation properties) and other customizations of packages through manipulations (transforms or .mst files) of a package's relational database. Version 2.0 onwards, it supports digital signatures and version 3.0 onwards, delta compression for patches.