About Opentopia
Opentopia Directory Encyclopedia Tools

Windows Installer

Encyclopedia : W : WI : WIN : Windows Installer

The Windows Installer (previously known as Microsoft Installer, codename Darwin) is an engine 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 Compound Storage Files and commonly known as "MSI files", from their default file extension (compare: .deb, RPM). Windows Installer is a significant improvement over its predecessor, Setup API: several new features, such as a GUI framework, the automatic generation of the uninstallation sequence and the powerful deploying capabilities, made Windows Installer a viable alternative to stand-alone executable installer frameworks such as older versions of InstallShield and WISE (later versions are based on Windows Installer) and NSIS.

Third parties are encouraged to use Windows Installer as the basis for installation frameworks, so that they synchronize correctly with other installers and keep the internal database of installed products consistent. Important features such as rollback and versioning (see DLL Hell) depend on a consistent internal database for reliable operation.

Contents

Logical structure of packages

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

Components

A component is the minimal 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, groups of 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.

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"). Most installation programs 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.

Setup phases

Acquisition

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. The acquisition phase is sometimes called immediate mode.

Execution

In this phase, the script built in the previous phase 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.) This phase is sometimes called deferred mode.

Rollback

In case any script action fails, 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. This mechanism can lead to the surprising situation whereby a failed uninstall leads to the application being re-installed.

Other features

Advertisement

Windows Installer can advertise a product rather than actually installing it. The product will appear installed to the user, but it will not actually be installed until it is run for the first time (by means of a Start menu shortcut, by opening a document that the product is configured to handle, or by invoking an advertised COM class).

Installation on demand

Similar to advertisement, it consists in the installation of features as soon as the user tries to use them.

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 and registry entries; it can resolve component identifiers into paths, allowing applications to avoid hard-coded file paths; and it natively supports patches and other customizations of packages through manipulations (transforms) of a package's relational database.

It is also unique among installation software frameworks for Windows in that it is highly transparent. The full API and all command-line options are documented; packages are freely viewable and editable, both with free tools and programmatically (as opposed to the proprietary and even weakly encrypted packages of InstallShield); and the format for file archives is the well documented Microsoft Cabinet.

Windows Vista

Windows Installer 4.0, which will only ship with Windows Vista, will incorporate new capabilities to take advantage of Vista's User Account Control architecture. MSI packages can be marked as not requiring elevated privileges to install, thus allowing a package to install without prompting the user for Administrator credentials. Windows Installer will also work in conjunction with the Restart Manager; when installing or updating an application or system component with "full" user interface mode, the user will be displayed a list of affected applications that can be shut down, and then restarted after files have been updated. Installer actions running in silent mode will perform these application restarts automatically. System services and tray applications can also be restarted in this manner.

Diagnostic Logging

Windows Installer supports detailed logging as a powerful diagnostic tool. Logging can be enabled in the following four ways:
:msiexec /i Package.msi /l*v c:\package.log
:Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
:Value Name: Logging
:Type: REG_SZ
:Data: voicewarmup
The resulting log is named MSI###.log (where "###" is a unique random identifier) and is placed in the system's Temp directory.
:Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer -> Logging.
Although verbose logs are very useful for diagnosing Windows Installer problems, they can be very long and difficult to read without practice. A quick way to find the location of a problem in the log is to open it in a text editor (such as Notepad) and search for the phrase "Return Value 3". This entry commonly appears in logs close to the point where a critical error has occurred. The Windows Installer SDK provides a tool called WiLogUtl, which parses and annotates Windows Installer log files.

To output debug information in the log file, pass "x" on the command line or add it to the Logging registry value. For example, the following command installs Package.msi and outputs debug, verbose logging to c:\Package.log:

:msiexec /i Package.msi /l*vx c:\package.log

External links

Information and tools from Microsoft

Tools for creating MSI files from other vendors

Community sites

 

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.

Search Titles
0123456789
ABCDEFGHIJ
KLMNOPQRST
UVWXYZ?

E-mail this article to:

Personal Message: