MSI Installers

MSI Installer files, with .msi at the end, were an attempt by Microsoft to make installation manageable, to recover from the chaos that third party Graphical Installers were making of the OS installations.

Features

• The MSI file is an OLE structure storage file containing different modules to install.
• Modules can be inter-dependent, to correctly install the needed modules.
• Some prepackaged items can be nested inside your own MSI. If, for example, your application needs to include an IE7 or .NET3.0 update, it could possibly be merged into the larger MSI.
• Can contain more than declarative information to be interpreted by the msi service
• Can also contain binary code to be executed at install-time.

Advantages

• A single format that different installer generator tools can create.
• Windows Active Directory and other management tools can push .MSI files out to target machines, so that they get autoinstalled on reboot, or when a user selects a file.
• There are basic MSI tools in Visual Studio releases.
• Third party products such as InstallShield make generating an MSI file easy.
• Microsoft have open sourced a .NET tool, WiX, to generate MSI files.
• Install-time binaries make it extensible and flexible and allows third party installers to provide enhancements and lets you migrate pre-MSI installations to the format.

Disadvantages

• There's a definite bias towards end-user applications, to pushing out programs to many client machines...it is not so suited to server maintenance.
• No cross-MSI dependency management.
• The internal structure is so complex due to the goal of fitting the base installer on a single floppy drive. Some of those design decisions may no longer be valid.
• If you nest other installer packages into your own, you get to field the support calls when the nested installation of IE7 or .NET breaks something. Such big installations will be traumatic; those support calls can be expensive.
• Can only be installed by someone with administrative rights, into the OS. This is because they may change Pattern - The Windows Registry, and the OS-managed parts of the file system.
• Install-time binaries prevent the OS from determining exactly what changes an installed application has made to the OS. This prevents the OS from performing any rollback -it can only hope the MSI rolls everything back cleanly. Nor can the OS determine which application "owns" files in the filesystem, or entries in the registry.

There's a good history of the MSI format, which explains some of the design decisions. When you compare them to RPM or .deb installers, there are some obvious differences

1. There's no notion of a source only distribution. This is clearly not a product concept the design team considered.
2. There's no cross-MSI dependency graph. You can nest installers, but not include a declaration
3. They've been harder to create and maintain.

SmartFrog support

We don't do anything with these, or repackage SmartFrog as a .MSI file. We could use the WiX toolset to do the latter, by way of Ant.