Exploring the Windows Installer

Windows Installer is a piece of technology that we all are aware of but that few of us really know well. If you work in a small company or as a freelance developer you probably don't need to learn the complexity of Microsoft Installer and you can simply do XCopy deployments to your customers.

If you work in a medium/big company, however, releasing the software for Windows using the Microsoft Installer is the norm and it is important to understand how it works.

The installation process of a product can be extremely complex and could consist of:

• Installing software dependencies
• Installing services (that might require stopping/restarting other services)
• Installing/replacing files (some could be in use)
• Supporting rollback in case of errors
• Supporting hot fix and upgrades
• ...

Windows Installer provide a standard way to install, maintain and uninstall software.

Here some of the features:

• Support for atomic installation (all or nothing)
• Support for repair (fix a broken application)
• Ability to share files
• Integrated into Windows
• WMI provider to query configuration, installed products and MSI files
• Built-in support for installing .Net assemblies into the GAC
• Ability to install per-user or per-machine (registry keys in HKCU or HKLM)
• Support for upgrade and fixes
• Support to run custom code (custom actions)

The latest version of Windows Installer is Windows Installer 5.0 that is available only for Microsoft Windows 7 and Windows Server 2008 R2. This is quite limiting and for this reason is probably reasonable to use an older version like Windows Installer 3.1 that support Windows Server 2003, Windows XP, or Windows 2000 with Service Pack 3 (SP3).

More information in Windows Installer on MSDN.

There are two important components:

• Windows Installer Package (MSI file)
• Windows Installer Service

The MSI file represents a setup file that the user can launch in order to install an application while the Installer Service is a Windows Service that is responsible of the installation process.

There are different ways of creating installer packages and the three more important are:

• Visual Studio Setup and Deployment Projects
• InstallShield 2010 Limited Edition
• Windows Installer XML Toolset (Wix)

In the following page if can see a feature comparison of these tools: Choosing a Windows Installer Deployment Tool

It is clear that Wix is the more flexible and powerful way for generation MSIs. The disadvantages are that is difficult to learn and the absence of a designer to customise the installer. Anyway, I don't want to talk about Wix in this post and I will simply use the Visual Studio Setup project.

It is important to notice that Microsoft intention is to drop the support of the Visual Studio Setup project in the future versions of Visual Studio:

Caution: Future versions of Visual Studio will not include the Visual Studio Installer project templates. To preserve existing customer investments in Visual Studio Installer projects, Microsoft will continue to support the Visual Studio Installer projects that shipped with Visual Studio 2010 per the product life-cycle strategy.

In order to explore the windows installer I created a simple WPF app called MyApp and a setup project. It is all so easy.

If you build the setup project, the result will be an MSI file that you can delivery to customer:

 The setup experience is something we are quite familiar:

The interesting think about MSI file is the following:

• An MSI file is substantially a database made of tables with rows and columns.

There is a tool called Orca that can be used to explore the content of an MSI. This tool has been created by Microsoft but it is not more officially supported. An alternative is SuperOrca.
Once you installed Orca you can right click an MSI file and edit the file in Orca.

You can see the tables in the left panel and the rows in the right panel. As you can see, there is a single component (MyApp.exe) with the version 1.0.0.0

The table Property contain various properties with values. An important property is ProductCode that is a GUID that identify the product uniquely. The Windows Installer Services uses it to determine whether your product is already present on a system.

In addition there is the PackageCode that identify the individual MSI and it is used to distinguish between different builds of the same product:

If I try to run the same installer again (same ProductCode and Package code), the system recognise that the product is already installed and prompt for repairing or removing the product.

Instead, if I rebuild the setup project in Visual Studio I get an new MSI with a new PackageCode (while the ProductCode will remain the same). In that case, when I try run the installer, I get an error:

You can find the simple code in my personal repository:

• Basic Visual Studio Setup Project

The important lesson to take away are:

• Windows Installer is the standard way to install, maintain and uninstall software on Windows.
• Wix is the more flexible way to generate MSI files.
• The Visual Studio Setup Project is the easiest way to generate MSI files.
• An MSI file is a database.
• You can explore the content of an MSI file using the tool Orca.
• The ProductCode identify the product uniquely.
• The PackageCode identify the individual MSI.