MSI Package Validation

What is Package Validation?

Package Validation checks a Windows Installer package for errors based on rules in one or more validation modules. It validates installation files (.MSI and .WSI), merge modules (.MSM and .WSM), and transforms (.MST). Package Validation contains predefined validation modules. The validation modules are fully customizable to accommodate corporate standards. It is strongly recommended that a Packager should run validation on every new or newly modified installation package before attempting to install the package for the first time. It is process of evaluating the consistency of the windows installer package in a working environment.

What are the types of validations?

The Different types of validations are:

1. Internal Validation
2. String-Pool Validation
3. DBCS String Tests
4. Reference Count Verification
5. Internal Consistency Evaluators – ICEs

Internal Validation

When authoring an installation package, one can use the MsiViewModify function or the View.Modify method to ensure that the data entered is syntactically correct. At the lowest level, a database table’s column can store integers (short or long), strings, or binary data. However, an installation package requires specific integers or strings in certain tables. These specifications are maintained in the _Validation table. For example, the FileName column of the File table is a string column, but it specifically stores a file name. Therefore, not only should the entry be a string, but it should also follow the requirements for naming files. The various validation enum values used with the MsiViewModify function allow for immediate validation at different levels. The MSIMODIFY_VALIDATE_FIELD enum can be used to validate individual fields of a record. It does not validate foreign keys. The MSIMODIFY_VALIDATE enum validates an entire row and includes foreign key validation. If a new row is inserted into a table, use the MSIMODIFY_VALIDATE_NEW enum to verify that one are adding valid data as well as using unique primary keys. An insert fails if the primary keys are not unique. If a call to MsiViewModify with one of the validation enums returns an error, one can make repeated calls to MsiViewGetError for diagnosing the problem. MsiViewGetError indicates the column where the error occurred as well as the enum value to help fix the problem.

Internal validation can be used to ensure that other authors enter data correctly into the custom table. Add each of the columns of the custom table to the _Validation table using the custom table name and column name as the primary key. Provide a description or purpose of each column in the Description column of the _Validation table. Enter the applicable requirements for each column using the Nullable, MinValue, MaxValue, KeyTable, KeyColumn, Category, and Set columns:

• If the column is Nullable, enter a ‘Y’. If not, enter a ‘N’.
• If the column is an integer column and can contain a range of integers, enter that range using the MinValue and MaxValue columns.
• Foreign key columns are identified using the KeyTable and KeyColumn columns.
• For string columns, specify a Category such as Filename, GUID, Identifier, etc.
• If the data can only pertain to a specific number of values (string or integer), use the Set column to list the acceptable values.

The following is a list of the columns (in addition to Table, Column, and Description) in the _Validation table that can be filled in if the column is of the specified type.

Authoring environments may make use of MSIMODIFY_VALIDATE_DELETE. This enum assumes that one want to delete the row. No field or foreign key validation is performed. This enum actually performs a reverse foreign key validation. It checks the _Validation table for references in the KeyTable and KeyColumn columns for the table to which the “deleted” row belongs. If there are columns that list the table containing the “deleted” row as a potential foreign key, it cycles through that column to see if any of the values reference values in the “deleted” row. An error return means that one break the relational integrity of the database by deleting the row.

String-Pool Validation

The Windows Installer stores all database strings in a single shared string pool to reduce the size of the database and to improve performance. The only means of validating the string pool is to use the MsiInfo tool found in the Windows Installer SDK. String pool verification consists of two main checks:

• DBCS string tests
• Reference count verification

DBCS String Tests

The DBCS string tests scan each string in the database for two criteria: For packages with a neutral code page marked, if any character is an extended character (greater than 127), the string is flagged and a message is displayed saying that the code page of the database is invalid because these characters require a specific code page to be rendered consistently on all systems. If the database has a code page, each string is scanned for an invalid DBCS indicator. If a non-neutral string has been improperly marked, the characters will not render correctly. (This is most commonly caused by forcing the code page to a particular value using the _ForceCodepage table with non-neutral strings already in the database.) Note that this check requires that the code page of the database be installed on the system. If there is a code page problem, the user may fix the error by using the _ForceCodepage table to force the code page of the database to the appropriate value.

Reference Count Verification

To verify the reference counts of all strings, every table is scanned for string values, a count of each distinct string is kept, and the result is compared to the stored reference count in the database string pool. If there is a string reference count problem, the user should immediately export each table of the database using MsiDatabaseExport, create a new database, and import the tables into the new database using MsiDatabaseImport. The new database then has the same content as the old database, but the string reference counts are correct. Adding or deleting data from a database with a corrupt string pool can increase corruption of the database and loss of data, so taking these steps quickly is important to prevent further data loss. When rebuilding databases, remember to embed any necessary storages and streams in the new database (see _Streams Table and _Storages Table) and be aware of code page issues. Also remember to set each of the necessary Summary Information Stream properties.

Internal Consistency Evaluators – ICEs

Internal consistency evaluators, also called ICEs, are 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 database. Note that this is different than the validation done on individual records using MsiViewModify. For example, the Component table may list several components that are all valid when tested individually with MsiViewModify. However, MsiViewModify would not catch the error when two components use the same GUID as their component code. The custom action ICE08 is designed to validate that the Component table does not contain duplicate component code GUIDs.

ICE custom actions return four kinds of messages:

1. Errors Error messages report database authoring that cause incorrect behavior. For example, duplicate component GUIDs cause the installer to incorrectly register components.
2. 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.
3. 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.
4. 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.

Note: Merge modules should be validated by using the method described in Validating Merge Modules.

Why validation is required?

To evaluate the consistency of the windows installer package in the required environment. If validation is ignored then application may fail to work in the production environment.

How we can use the validations?

Using ORCA, Windows Installer package can be validated. The process of validation is described as under:

1. Open the .msi file with ORCA.
2. Under the Tools menu click on Options.
3. Go to the Validation tab and do the following settings:

4. Click on OK button.

5.Now Press Ctrl + L to start the validation.

6.Click GO.