Validating product and patch packages

The following examples run Internal Consistency Evaluators (ICE) on product packages. In order for the default darice.cub to be used automatically, you must Orca or MsiVal2 installed which are available in the Windows SDK.

• Basic validation using default ICEs
• Basic validation using custom ICEs
• Validating a product with patches applied

Basic validation using default ICEs

If Orca or MsiVal2 are installed, test-msiproduct will automatically find and use it.

test-msiproduct product.msi

By default this only emits warnings and errors but you can show informational messages using the default -Verbose parameter.

test-msiproduct product.msi -v

Because rich objects are returned, you can filter the objects as you can with any other objects. If you want to avoid even running certain ICEs - like ICE03 which can take a while to run - you can do that with the -Include and -Exclude parameters.

test-msiproduct product -v -include ICE0* -exclude ICE03

This would run ICE01 through ICE09 except for ICE03.

Basic validation using custom ICEs

You can also use custom ICEs in addition to or in lieu of the default ICEs.

test-msiproduct product.msi -add custom.cub

To use only the custom ICEs, pass the -NoDefault parameter.

test-msiproduct product.msi -add custom.cub -nodefault

You can include and exclude custom ICEs just like with default ICEs.

Validating a product with patches applied

There's no supported way in the Windows Installer SDK to run ICEs on the changes a patch would make. The applicable transforms have to be applied to a product, so the test-msiproduct cmdlet supports that. What special about this cmdlet is that it applies patches in authored sequence order if using Windows Installer 3.0-style patches (i.e. with an MsiPatchSequence table in this case).

You can also specify any arbitrary transforms, which are applied in specified order.

test-msiproduct product.msi -patch patch2.msp, patch1.msp -transform ja-JP.mst

Transforms are applied first, and assuming that patch2.msp sequences after patch1.msp - despite the order you specified - patch1.msp is still applied first.