Skip to main content

Designing MSI Installations

Introduction​

MSI (Microsoft Installer), also known as Windows Installer, is an engine that can perform complex software installations. Currently, a growing number of applications use Windows Installer as their installation engine. The reason is because not only is Windows Installer the Microsoft endorsed method of performing installations on Windows operating systems, but also because Windows Installer is highly flexible in its core design, allowing for very complex installations. For example, Microsoft Visual Studio .NET (roughly 2 GB when fully installed) uses Windows Installer to perform all of its installation tasks. In fact, most new programs now use Windows Installer for installation.

Windows Installer works by parsing MSI files (also known as installation databases) and performing the actions configured inside these databases. Wise Installation Studio acts as a development environment for creating these installation databases easily, without you having to know the database file format. However, although you don't need to know the intricacies of Windows Installer, it helps to know a few basic design principles that drive MSI.

The seven stages of setup development​

There are seven essential stages of design and development for installations in general. These are outlined below.

  1. Defining user interface and product details This involves modeling the user interface of the installer. This includes creating the welcome and finish pages, and setup UI functionality, as well as defining the product to be installed and basic install properties. More specifically, the product ID and version information are assigned in this stage.
  2. Specifying files and system modifications This means putting all the product’s files together into one package and defining the core of the installer, such as features and components. This stage also involves creating registry entries, and executing other actions after copying files.
  3. Determining dependencies In this stage, you select what other software your product depends on. This could be the .NET Framework, DirectX 9.0, or any other Windows Installer managed product or merge module. These are managed by the Wise Installation Studio bootstrapper unless they are merge modules.
  4. Choosing a method of distribution This occurs on a per-build basis. In this stage, you decide what sources / source lists / media to distribute the product on. You choose, for example, if the setup should be a web setup or a normal setup, whether or not to span the CAB files, whether or not to integrate the CAB files in the main MSI, whether to use a bootstrapper, and how the final setup directory is organized.
  5. Building the installer You must eventually build the installer. The build process is entirely automated and does not ask you any questions. When the build is complete, you are able to see the results of the build and whether or not it was successful.
  6. Testing and validating the installer You can execute the installer in a special debug mode from the development environment, with logging capabilities, to see exactly how the installer runs. You can also inspect the properties of the installer at runtime.
  7. Distributing the installer You can take the installer and upload it to the web, or put it on a floppy disk or CD-ROM. This is normally done individually outside of the development environment, using compression tools like WinRAR and CD-ROM burning tools like Nero.

Features​

Windows Installer divides product installations into features. Each feature represents a standalone unit of a product that can be installed and uninstalled separately and represents a particular piece of functionality of the product. Features constitute a tree-like structure: each feature can have one or more child features.

Features have install levels, which indicate when the feature will be installed. A typical use for install levels is in creating install configurations like Typical and Compact. Typical would have a different threshold install level compared to Compact.

For this section, we'll use a fictitious product as an example: ACME Tools. ACME Tools consists of a set of three separate system utilities, online documentation, and shared application files. ACME Tools can be divided into the following features:

  • Shared Program Files (Required) (Feature Name: ProgFiles)
  • Online Documentation (Optional) (Feature Name: HelpFiles)
  • System Utilities (Required) (Feature Name: SysUtils) ** System Utility A (Optional) (Feature Name: SysUtilA) ** System Utility B (Optional) (Feature Name: SysUtilB) ** System Utility C (Optional) (Feature Name: SysUtilC)

Thus, the user only needs to install the shared program files and typically one system utility to install the product. The other features, being optional, can be installed later. Also, the features are independent of each other for the most part. Note that, in this example, the system utilities depend on the shared program files. It is up to you how you divide your program into features, but you should follow these guidelines and make sure it also makes sense to the user who will be running the installation.

Components​

Components are small parts of an application; much smaller than features. They are registered with the system and are an integral part of your product's installation. They cannot be installed and uninstalled separately. A component can be as small as a single file or as large as a set of ODBC drivers.

It is usually recommended that you keep components small, as you can have an infinite number of them in an installation and they are easier to manage when they are small. That is, keep each component associated with only a single file, ODBC resource, or registry tree. It is important to keep in mind that a component isn't limited to just a file. You can add file associations, assembly registration, COM classes, NT services, and many other things to a single component containing a single file.

Each component should be added to a feature in order for it to be installed. All components in a certain feature are installed only if that feature is selected. Furthermore, you can add the same component to more than one feature. You can only have up to 800 components per feature. However, you can have unlimited sub-features. Therefore, there really is no limit to how many components you can have in a feature.

Product codes and upgrade codes​

It is important to understand when to change the product and upgrade code of your package. Please refer to the MSDN documentation, on patching and upgrades, for more information.