Windows Installer is a powerful yet complex technology. There are a lot of rules that have to be followed to be able to successfully install, maintain, and uninstall your product and to retain the functionality and tidy clean-up capabilities of Windows Installer. To this end, Internal Consistency Evaluators (ICEs) exist to aid in validating that you have followed many of the rules and should be part of anyone’s exit criteria who’s building an installation for their product using Windows Installer.

ICEs check the Windows Installer package database for violation of rules. Many of these are serious, such as duplicate component IDs in the same package or a component ID with lowercase letters. All errors reported by an ICE validator should be fixed, and warnings should be given some discretion.

Errors regarding component IDs are always important to fix, because if the component IDs aren’t unique within a package or aren’t using all uppercase letters the components are not registered right and may be incorrect installed, impossible to service, or won’t be uninstalled.

A lot of warnings such as string overflow warnings reported by ICE03 can typically be ignored, but it is recommended that you fix them. In at least one case it’s more important that you fix string overflow warnings for the Feature table or the MsiEnumFeatures function will only return part of the feature name.

There are lots of ways you can run validation, both manually and automatically.

One way to run these manually is to open your .msi file in Orca (available as part of the Windows Installer SDK, but a separate install using orca.msi), click on the Tools menu, and click Validate…. You can also install msival2.msi from the same folder as orca.msi to use a command-line interface which would also be useful for automated testing.

Besides msival2.exe for automatic testing, a COM server exists and is installed as part of Orca, named EvalCom2. Unfortunately this is not an automation server but is still pretty easy to use and integrate into your own automation tools.

ICEs are fairly simple and you can even write your own. They are custom actions that are merged into an .msi or an .msm file and run explicitly to access data in the current database. They output messages in a particular format using either the MsiProcessMessage function or the Session.Message method.

With a good set of ICEs you should be able to easily validate your packages. A good reference can be found online in the Windows Installer SDK – many times with possible solutions to validation issues – for ICEs provided in “ice cubes” (since the ICE packages typically have a .cub extension) that ship as part of orca.msi and msival2.msi.

You should also check out the Best Practice Guidelines from the Windows Installer team. I also can’t emphasize rule #1 enough – truly understand Windows Installer before starting to use it and use a commercial tool or a tool that otherwise gives you complete control over your packages such as WIX.