Since Windows Installer Package is the core technology for PACE Suite, we decided to create a concise overview of it. This blog post will be helpful both for newcomers to application packaging and for experienced engineers who want to refresh their knowledge of some peculiarities of Windows Installer.
About Windows Installer
In order to create a streamlined process for installing and managing applications, Microsoft developed the Windows Installer service. It consists of a set of guidelines, an Application Programming Interface (API), and a runtime service to help make application installation and ongoing management a part of the basic Windows system services. The Windows Installer service is not an installation-authoring tool, but rather an installation engine and a rule set for installation packages.
The Windows Installer engine resides on the destination computer as part of the operating system. The executable – msiexec.exe – reads the installation database (.MSI), performs the installation, and performs any subsequent management that becomes necessary – such as self-repair.
Instead of an installation executable (such as setup.exe), your installation is in the form of a database file, an .MSI, which contains instructions and can enclose installation files. Because this database uses highly structured and uniform data tables, there is 100% accountability of where each file is installed, and with the advanced logging, each step of the installation process can be tracked. Due to this, individual files can readily be restored to repair damaged applications.
Each table is dedicated to a particular type of installation information such as Class, Components, Features, Files, Execution Sequence, and Registry. Certain logic is built into the Windows Installer engine, such as when to prompt for a reboot, disk space checking and file version replacement rules. When Windows Installer package is opened, msiexec.exe reads the data stored in the database and builds an internal script to follow. It then performs the actions in the script to complete the installation. If the installation fails, Windows Installer package contains functionality to roll back the machine to its previous state.
Advantages of the technology
There are many advantages of using Windows Installer. These advantages result in a solid, more robust installation that can reduce the total cost of ownership (TOC) for your organization. Because Windows Installer is part of the operating system, it provides features not available in traditional software distribution technologies.
- Advertisement – also called install-on-demand. Windows Installer gives you the ability to set features to be advertised. Advertised features are not actually installed, but they appear installed to the user. When the user invokes an advertised feature, installation of the feature occurs.
- Componentization – Windows Installer gives you the ability to divide your installation into smaller, more manageable parts. These parts are called components. Components give you more control over application resources during installation setup and runtime. Windows Installer package uses components for repair.
- Standardization – Windows Installer package has global rules it applies to every file installed with an application. These rules look at a file’s version and its shared DLLs to prevent conflicts between applications.
- Version Rules – Windows Installer package uses version rules to decide whether to install a file to a directory or not. The rules look at the file’s date, language and whether the file is versioned, the modified date on a non-versioned file, and the highest version of the file.
- Reference counting – to track DLLs shared among components (from different installations), Windows Installer uses reference counters. The reference count occurs both at the component level and in the registry for the component’s key file. At the registry level, Windows Installer counts the number of times a DLL is installed or removed.
- Customization – you can customize installations to users’ needs by creating transforms. Transforms apply changes to a Windows Installer installation in order to tailor the installed application to the needs of a particular group of users.
- Assignment – you can use the user’s profile to place applications either advertised or installed on the destination machine. An administrator sets applications in a user’s profile, and when the user logs in on the destination machine, the designated applications are installed on the machine. With the assignment, the users have no control over the applications they receive. You must have Active Directory or another distribution tool for this to work. It also works in a locked down environment by using elevated privileges.
- Publishing – as an administrator, you can publish applications to the Programs and Features applet (Add/Remove Programs). The advertising attributes for the applications in Programs and Features are stored in Active Directory and are not placed on a user’s machine unless the user installs the application. Publishing lets the user decide whether to install the published applications.
- Open Architecture – Windows Installer package open architecture gives you the ability to create custom solutions that add value to your projects. The architecture contains a standard, consistent set of guidelines that provide integrity for every installation and allow you to choose best of breed authoring software.
- Total Cost of Ownership – Windows Installer makes installations easier to install, maintain and support for your customers. This reduces the time you spend assisting the customer and reduces the time they need to spend troubleshooting the application installation.
- Rollback – Windows Installer installations are transactional. Because each process is a transaction, when one of the processes in the installation fails, Windows Installer reverts to the installation’s previously installed state. Rollback prevents you from having an incomplete or broken application.
- Dynamic Source List – a source list provides source resiliency for features that are installed-on-demand. The list contains all of the locations in which Windows Installer searches for an application’s source files. Windows Installer package adds the most recently used directory to the source list, then goes to that source first the next time it needs to install files. Windows Installer updates the list automatically whenever features are added to an installation.
- Self-healing – also called automatic repair, is the ability of the application to repair missing components such as files or registry entries. When you start an application, Windows Installer checks a list of key paths. If any broken key paths – e.g. missing files or registry entries – are found, Windows Installer repairs the application.
- Group Policy and Security – Windows Installer sets privileges for the installation and the user. Elevated privileges control the user and application rights, and provide a more secure environment. Because of elevated privileges, the application can have more privileges than a user during an installation.
- User Policy – the policies that you set define the type of privileges that a user has.
- System Policy – the policies you set on a per machine basis define the types of privileges that the machine has. This gives you the ability to run an entire installation under elevated privileges and define only those rights users have while an installation runs.
Windows Installer Package structure
An installation package contains all of the information that the Windows Installer requires to install or uninstall an application or product and to run the setup user interface. Each installation package includes an .msi file, containing an installation database, a summary information stream, and data streams for various parts of the installation. MSI package can also contain one or more transforms, internal source files, and external source files or cabinet files required by the installation.
Application developers must author an installation to use the installer. Because the installer organizes installations around the concept of components and features, and stores all information about the installation in a relational database, the process of authoring an installation package broadly entails the following steps:
The next section discusses installer components and features. The choice of features is commonly determined by the application’s functionality from the user’s perspective. It is recommended that developers use a standard procedure for choosing components.
- Identify the features to be presented to users.
- Organize the application into components.
- Populate the installation database with information.
- Validate the installation package.
Package authors can use third-party package creation tools or a table editor (for instance, PACE Suite) and the Windows Installer SDK to populate the installation database. All installation packages must be validated for internal consistency.
Components and Features
Windows Installer package organizes an installation around the concepts of components and features. A feature is a part of the application’s total functionality that a user recognizes and may decide to install independently. For example, a feature could be a spell-checker, a thesaurus, or a set of clip art. Hierarchical relationships of parent and child features commonly exist so if a child feature is installed, the parent feature is automatically installed as well.
A component is a piece of the application or product to be installed. Examples of components include single files, a group of related files, COM objects, registration, registry keys, shortcuts, resources, libraries grouped into a directory, or shared pieces of code such as MFC or DAO. The installer service installs or removes a component as a single coherent piece. It tracks every component by the respective component ID GUID specified in the ComponentId column of the Component table.
Note 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. Several features or applications may therefore share some components.
Because components are commonly shared, the author of an installation package must follow strict rules when specifying the components of a feature or application. This is essential for the correct operation of the Windows Installer reference-counting mechanism. Each component must be stored in a single folder.
Note 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. Authors of installation packages need to decide how to divide their application into features and components. The selection of features is primarily determined by the application’s functionality from the user’s perspective. Because components commonly must be shared across applications, or even across products, it is recommended that authors follow a standard method for selecting components.
MSI Installation mechanism
There are two phases to a successful installation process: acquisition and execution. If the installation is unsuccessful, a rollback phase may occur.
At the beginning of the acquisition phase, an application or a user instructs the installer to install a feature or an application. Windows Installer package then progresses through the actions specified in the sequence tables of the installation database. These actions query the installation database and generate a script that gives a step-by-step procedure for performing the installation.
During the execution phase, the installer passes the information to a process with elevated privileges and runs the script.
If an installation is unsuccessful, the installer restores the original state of the computer. When Windows Installer package processes the installation script, it simultaneously generates a rollback script. In addition to the rollback script, the installer saves a copy of every file it deletes during the installation. These files are kept in a hidden, system directory. Once the installation is complete, the rollback script and the saved files are deleted.
When Windows Installer package processes the installation script for the installation of a product or application, it simultaneously generates a rollback script and saves a copy of every file deleted during the installation. These files are kept in a hidden system directory and are automatically deleted once the installation is successfully completed. If however the installation is unsuccessful, the installer automatically performs a rollback installation that returns the system to its original state.
Automatic rollback of an unsuccessful installation is the default behavior of the installer. To disable rollback during an installation use one of the following:
Whenever rollback is disabled, the installer sets the RollbackDisabled property. If an installation uses custom actions, additional authoring of Windows Installer package is required to use rollback functionality.
- DISABLEROLLBACK Property
- PROMPTROLLBACKCOST Property
- DisableRollback Action
- EnableRollback ControlEvent
Windows Installer packageprovides many built-in actions for performing the installation process.
Standard actions are sufficient to execute an installation in most cases. However, there are situations where the developer of an installation package finds it necessary to write a custom action.
Let’s review some main aspects of Custom actions.
- You want to launch an executable during installation that is installed on the user’s machine or that is being installed with the application.
- You want to call special functions during an installation that are defined in a dynamic-link library (DLL).
- You want to use functions written in the development languages Microsoft Visual Basic Scripting Edition or Microsoft JScript literal script text during an installation.
- You want to defer the execution of some actions until the time when the installation script is being executed.
- You want to add time and progress information to a ProgressBar control and a TimeRemaining Text control.
Deferred Execution Custom Actions
The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed. This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in a call to MsiDoAction. A deferred execution custom action enables a package author to specify system operations at a particular point within the execution of the installation script.
The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead, the installer writes the custom action into the installation script. The only mode parameter the installer sets in this case is MSIRUNMODE_SCHEDULED.
A deferred execution custom action must be scheduled in the execute sequence table within the section that performs script generation. Deferred execution custom actions must come after InstallInitialize and come before InstallFinalize in the action sequence.
Custom actions that set properties, feature states, component states, or target directories or schedule system operations by inserting rows into sequence tables can often use immediate execution safely. However, custom actions that change the system directly or call another system service must be deferred to the time when the installation script is executed. See Synchronous and Asynchronous Custom Actions for more information about potential clashes between their custom actions and the main installation thread.
Because the installation script can be executed outside of the installation session in which it was written, the session may no longer exist during execution of the installation script. This means that the original session handle and property data set during the installation sequence is not available to a deferred execution custom action. Deferred custom actions that call dynamic-link libraries (DLLs) pass a handle that can only be used to obtain a very limited amount of information, as described in Obtaining Context Information for Deferred Execution Custom Actions.
Note that deferred custom actions, including rollback custom actions and commit custom actions, are the only types of actions that can run outside the users security context.
Synchronous and Asynchronous Custom Actions
The Windows Installer processes custom actions as a separate thread from the main installation. During synchronous execution of a custom action, the installer waits for the thread of the custom action to complete before continuing the main installation. During asynchronous execution, the installer runs the custom action simultaneously as the current installation continues. Authors of custom actions must therefore be aware of any asynchronous threads that may be making changes to the installation database between function calls.
In particular, calls to MsiGetTargetPath and MsiSetTargetPath should be avoided in asynchronous custom actions. Instead use MsiGetProperty to obtain a target path. Bulk database operations such as import, export, and transform operations should be avoided in any type of custom action.
Option flags can be set in the Type field of the CustomAction table to specify that the main and custom action threads run synchronously or asynchronously.
The installer can only execute Rollback Custom Actions and Concurrent Installation actions as synchronous custom actions.
Rollback Custom Actions
When Windows Installer package processes the installation script, it simultaneously generates a rollback script. In addition to the rollback script, the installer saves a copy of every file it deletes during the installation. These files are kept in a hidden system directory. Once the installation is complete, the rollback script and the saved files are deleted. If an installation is unsuccessful, the installer attempts to rollback the changes made during the installation and restore the original state of the computer.
Although custom actions that schedule system operations by inserting rows into database table are reversed by a rollback of the installation, custom actions that change the system directly, or that issue commands to other system services, cannot always be reversed by a rollback. A rollback custom action is an action that the installer executes only during an installation rollback, and its purpose is to reverse a custom action that has made changes to the system.
A rollback custom action is a type of deferred execution custom action because its execution is deferred when it is invoked during the installation sequence. It differs from a regular deferred custom action in that it is only executed during a rollback. A rollback custom action must always precede the deferred custom action it rolls back in the action sequence. A rollback custom action should also handle the case where the deferred custom action is interrupted in the middle of execution. For example, if the user were to press the Cancel button while the custom action was executing. Note that Rollback Custom Actions cannot run asynchronously.
A commit custom action is complementary to a rollback custom action. . The installer executes a commit custom action during the installation sequence and copies the custom action into the rollback script but does not execute the action during rollback.
Note that a rollback custom action may not be able to remove all of the changes made by commit custom actions. Although Windows Installer package writes both rollback and commit custom actions into the rollback script, commit custom actions only run after the installer has successfully processed the installation script. Commit custom actions are the first actions to run in the rollback script. If a commit custom action fails, the installer initiates rollback but can only rollback those operations already written to the rollback script. This means that depending on the commit custom action, a rollback may not be able to undo the changes made by the action. You can ignore failures in commit custom actions by authoring the custom action to ignore return codes.
When the installer runs a rollback custom action, the only mode parameter it will set is MSIRUNMODE_ROLLBACK. A rollback custom action can be specified by adding an option flag to the Type field of the CustomAction table.
Windows Installer package can advertise the availability of an application to users or other applications without actually installing the application. 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 as described in Installation on-demand.
The two existing types of advertising are assigning and publishing. An application appears installed to a user when that application is assigned to the user. The Start menu contains the appropriate shortcuts, icons are displayed, files are associated with the application, and registry entries reflect the application’s installation. When the user tries to open an assigned application, it is installed upon demand.
The installer supports the advertisement of applications and features according to the operating system. The installer registers COM class information for assigned applications beginning with the Windows 2000 and Windows XP systems. This enables the installer to install the application upon the creation of an instance of an advertised class. For more information, see Platform Support of Advertisement.
You can publish an application from the server beginning with the Windows 2000 Server. The published application is then installed through its file association or Multipurpose Internet Mail Extension (MIME) type. Publishing does not populate the user interface with any of the application’s icons. The client operating system can install a published application beginning with the Windows 2000 and Windows XP systems.
Platform Support of Advertisement
Windows Installer package supports advertisement of applications and features. The following advertisement capabilities are available:
Note AppId and Typelib information is only written when an advertised component is installed.
- Shortcuts and their icons.
- Windows Installer package supports advertisement of applications and features.
- Extensions and their icons specified in the ProgId Table.
- Shell and command Verbs registered underneath the ProgId key.
- CLSID contexts and InProcHandler.
- Install-On-Demand through OLE is only available programmatically through CoCreateInstance (C/C++), and CreateObject Function (Visual Basic) or GetObject Function (Visual Basic).
To support file name extensions, the application must be published to Active Directory by an administrator using Group Policy.
The installation of the product may not require a restart, but any advertised shortcuts do not work until the machine is restarted. The advertised shortcuts of subsequent installations work without a restart. To ensure that advertised shortcuts work correctly, the package author should schedule a forced restart at the end of the installation. To avoid unnecessary restarts of the system, schedule a restart to run only if no version of the Windows Installer is installed. Conditional statements can check the ShellAdvtSupport property and Version9X property.
With traditional installation technology, it is necessary to exit an application and rerun setup to perform an installation task. This commonly occurred when a user ran a feature or product that had not been installed during the first run of setup. This often made the process of product configuration inefficient because it required the user to anticipate the functionality required before they ever used the product.
Installation-on-demand makes it possible to offer functionality to users and applications in the absence of the files themselves. This notion is known as advertisement. The Windows Installer has the capability to advertise functionality and to make installation-on-demand of application features or entire products possible. When a user or application activates an advertised feature or product, the installer proceeds with installation of the needed components. This shortens the configuration process because additional functionality can be accessed without having to exit and rerun another setup procedure.
When a product uses the installer, a user can initially choose which features or applications to install and which to advertise. Then, if while running an application the user requests an advertised feature that has not yet been installed, the application calls the installer to enact a just-in-time feature level installation of the necessary files. If the user activates an advertised product that has not yet been installed, the operating system calls the installer to enact a just-in-time product level installation.
Advertising mechanism and Installation on-demand can also facilitate system management by enabling administrators to designate applications as required or optional for different groups of users. There are two types of advertising known as “assigning” and “publishing.” If an administrator assigns an application to a group, then these users can install the application on-demand. If, however, the administrator publishes the application to the group, no entry points appear to these users and installation-on-demand is only activated if another application activates the published application.
Self-Healing mechanism of Windows Installer Package
The following flowchart is representing the way how self-healing mechanism of MSI works:
This concludes our overview of Windows Installer Package (MSI) technology. Though we tried to cover the entire topic, you can always find more information on MSDN if you think something is missing.