Validating product and patch packages
New in version 2.2.0
The following examples run Internal Consistency Evaluators (ICE) on product packages. In order for the default
to be used automatically, you must Orca or MsiVal2 installed which are available in the
Basic validation using default ICEs
If Orca or MsiVal2 are installed, test-msiproduct
will automatically find and use it.
By default this only emits warnings and errors but you can show informational messages using the default
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
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
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 to run ICEs on the changes a patch would make. The applicable transforms have to be applied to a product, so the
cmdlets supports just that. What special about cmdlets is that it applies patches in authored sequence order if using Windows Installer 3.0-style patches (i.e. with an
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
- despite the order you specified - patch1.msp
is still applied first.