How can I compare the content of two (or more) MSI files?

MSI Files

An MSI file contains a primitive MS SQL database embedded in a COM-structured storage file (a file system in a file with storage streams of various types - the old MS Office COM/OLE format).

You can extract files from an MSI, or you can actually decompile the whole MSI with all its streams. Each approach is described briefly below.

With decompilation (almost) full transparency is possible, with the exception of compiled custom actions (generally written in C/C++). Managed, compiled code (C#) may actually be (theoretically) decompiled.

In order to determine (roughly) what a black-box custom action actually does, you can capture an MSI install using a repackaging tool - which scans the system before and after installation listing any changes - you see what has happened, but not how it has happened. Very few people have the need for this level of scrutiny.

File Compare Only

This is old news, but if all you are concerned with is comparing the files embedded in the MSI / setup.exe, you can use an administrative installation to extract the files embedded in the MSI / setup.exe and then use any file compare tool to compare the files extracted for each version:

• setup.exe /a
• msiexec.exe /a "MySetup.msi"

If the MSI lacks proper GUI to allow you to specify an output folder interactively, you can try to specify it via the command line:

• msiexec.exe /a "MySetup.msi" TARGETDIR="C:\MyOutputFolder

Setup.exe files containing embedded MSI files may be of various types, some pointers:

• Some Installshield-specific information on setup.exe
• Handling other setup.exe types

Essentially an administrative installation extracts the setup's files from the embedded CAB files in the MSI itself (CABS can also be external) and outputs them in a neat folder structure roughly reflecting their intended target destinations upon install. Several forms of compression may be used in an MSI - all handled by the administrative installation. Please do not unzip MSI files!

Finally the Media table is adjusted to use the now extracted source files instead of the internal CAB files - and the internal CAB files are deleted potentially making the output MSI much smaller than the original. Crucially any digital signatures are removed.

It used to be that MSI files were cached in %SystemRoot%\Installer stripped of their CAB files (making them small), but they are now cached full-size, potentially dramatically increasing storage requirements. Using administrative installs is a way to reduce this caching size (with the penalty of the removed digital signatures). More on this here: Why does MSI require the original .msi file to proceed with an uninstall?

Further details on administrative installations here:

• What is the purpose of administrative installation initiated using msiexec /a?

• Extract MSI from EXE - performing an admin install

"MSI Content Compare"

If you want to determine in more detail what is different between two MSI files (for example version 1 and 2 of a package), you can get a little more involved using a proper MSI file viewer or MSI decompiler.

I wrote a blurb on stackoverflow.com on how to compare MSI files. It has been suggested to me to add a link here on serverfault.com to this content. Maybe it is helpful for system administrators.

I don't want to have a dual-source problem, so I will just link to the stackoverflow-version (hope that is OK practice): How can I compare the content of two (or more) MSI files? This answer lists several tools (both free and commercial) that can help you get a "real comparison" done.

The advanced MSI decompilation abilities of dark.exe from the WiX toolkit may be of particular interest. In addition to MSI file decompilation, the linked content also describes how to decompress setup.exe files created with the WiX toolkit (a bootstrapper feature that can install several MSI files and embedded EXE files in sequence). The decompressed content can in turn be dissembled by the same dark.exe file (provided they are MSI files).

Let me also throw in a link on how to handle setup.exe files made with other deployment tools.