When I was visiting a customer a while ago, I ran into a software packager wearing a funny t-shirt. I do not remember the name of the company which was promoting their packaging tool with that t-shirt at the time. However, the back of the t-shirt said “Real packagers do it on ICE”. :)

Every software packager involved with Windows Installer possibly knows that it is not easy to do it on ICE, right?

Even though Microsoft created the ICE validation rules to enforce consistency within the MSI database, you may need to deal with many validation errors and warnings which do not have obvious cause or resolution. Whether you deal with a repackaged application as MSI or a vendor-supplied MSI, you may see hundreds of validation errors and warnings. Some errors and warnings can safely be left in packages and others should be resolved.

Internal Consistency Evaluators (ICEs)

Internal consistency evaluators are simply custom actions written in VBScript, JScript, or as a DLL or EXE. When these custom actions are executed, they scan the database for entries in database records that are valid when examined individually but that may cause incorrect behavior in the context of the whole installation database.

ICE custom actions return four kinds of messages.

• Errors: Error messages report database authoring that cause incorrect behavior. Errors may cause run-time problems for the installation database and/or the application which can be installed from the installation database. For example, using the same GUID for two components is not allowed and this will result in an ICE error during validation.
• Warnings: Warning messages report database authoring that causes incorrect behavior in certain cases. Warnings can also report unexpected side-effects of database authoring. For example, entering the same property name in two conditions that differ only by the case of letters in the name. Because the installer is case-sensitive, the installer treats these as different properties.
• Failures: Failure messages report the failure of the ICE custom action. Failure is commonly caused by a database with such severe problems that the ICE cannot even run.
• Informational: Informational messages provide information from the ICE and do not indicate a problem with the database. Often they are information about the ICE itself, such as a brief description. They can also provide progress information as the ICE runs.

The mechanism to do a package validation is fairly simple. To validate a database, you will need to use a special validation tool to merge a .cub file (sometimes called ice cubes) containing the Internal Consistency Evaluators (ICEs) into your database, execute the ICEs, and report the results. You can use “MSI Validation Tool” that comes with MS Platform SDK or use third party utilities like “Wise Package Validation Wizard”.

Authors of installation packages can also write ICE custom actions or use the standard set of ICEs included in the .cub files provided with the SDK. A .CUB file is a special type of database that can also be opened by an MSI editing tool like ORCA (Orca comes with MS Platform SDK).