Best Practice Guidelines for Building Quality Installs: Part 1, the Basics

项目
09/27/2005

This is the first in a series of Best Practice Guidelines for Building Quality Installs. Let's start with the basics of quality Windows Installer (MSI) package. Prior postings the series: Introduction.

Build Components According to Component Rules

To ensure that the installation or removal of one program does not harm any other programs on the system and that the Windows Installer service correctly removes all resources connected with that program, your application installation package must adhere to the component rules.

All Components have a proper ComponentId GUIDs

Though the Component table’s ComponentId field is a nullable, the consequences for not providing a ComponentId is that the component is not uninstallable or manageable via the Windows Installer APIs.

Testability: scan Component table and for any row, confirm there is a component GUID in the ComponentID column.

All COM Servers must be a KeyPath of a Component

Do not include more than one COM server per component (per Organizing Applications into Components). If a component contains a COM server, this must be the KeyPath for the component.

Testability: scan file table and media for com servers. For any com server found, make sure it’s the KeyPath for a component.

Do not specify more than one file per component as a target for the Start menu or a Desktop shortcut (per Organizing Applications into Components).

Testability: scan shortcut and directory tables for Start menu or a Desktop shortcut targets. Make sure no component has more than one Start menu or a Desktop shortcut target.

Pass MSI Validation Testing

Any error from the Internal Consistency Evaluators validation suite must be fixed. Warnings represent design guidance to the package author which should be studied for applicability. If warnings do not apply or will not be fixed, they must be added to the Vendor Questionnaire to inform testing automation and customers.

Customer Impact: Highly desired by corporate customers.

Testability: boot Orca on MSI file , click Tools | Validate, in Validaiton Output dialog uncheck the Show "INFO" Messages click Go, run without errors, document any warnings

Uninstallation

Your application’s package must correctly and fully uninstall the application. A pure MSI package does this automatically. If your package includes custom actions, you may need to proactively ensure that your application properly uninstalls with an uninstall custom action.

Customer Impact: Highly desired by corporate and retail customers.

Testability: snap system before install and after uninstall and any thing remaining on the system should be listed in the vendor questionnaire.

[Author: Robert Flaming]

This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm.

Comments

Anonymous
September 29, 2005
As we once discussed previously, I see passing ICE validation as the most important "take home message" for all the package developers out there. We are involved with enterprise deployment at a number of large corporates and ICE validation (and conflict detection) are the only measurables that they have of package quality.

Most vendor packages (including Microsoft unfortunately) have various errors and warnings that imply validation has not even been performed. Out of hundreds of vendor packages, we can count the "neat and clean" ones with our fingers!

Note that each update to the MSI SDK has an updated version of ORCA which carries an updated copy of the validation suite - get the latest - don't just use any old copy laying about :)

通过