Windows Installer (MSI), Backward and Forward

You’ve reached an archived blog post that may be out of date. Please visit the blog homepage for the most current posts.

It’s safe to say that Windows Installer (MSI) isn’t going away any time soon. Since its introduction with Microsoft Office 2000 and Windows 2000, the MSI package format is preferred by many enterprises for providing a consistent installation, rollback, and customization experience. (Of course, not every benefit caught on: raise your hand if your application code interacts with MSI, or supports feature-level installation on demand.) Because of the benefits of Windows Installer, more people enter the field every day, either as an installation developer or build engineer, or in a role related to application readiness.

Having worked with Windows Installer from the beginning, more or less, here are the first few things I was glad to know early on:

  • How to validate a build. Windows Installer documentation contains a great many guidelines about populating the tables of an MSI database, and the collection of guidelines is impossible for me to keep in mind at once. (See the “Remarks” section of almost any table description in the help library, and multiply by a couple hundred.) Luckily, Windows Installer defines a set of internal-consistency rules (ICE rules) that test for authoring errors that violate the recommendations, and in InstallShield you can run the validation suite on a build by pulling down the Build menu and selecting the desired suite from the Validate submenu. Beyond that, InstallShield provides its own best-practice suite (ISBP rules) and upgrade-validation rules to flag additional potential problems. (You can read more in my two white papers, Fixing Design-Time Validation Errors and Validating MSI Updates and Patches.)
  • How to create a log file. Where validation detects potential errors before deployment, a Windows Installer log file is an installer’s running commentary about what it’s doing in a particular environment. A log file tells you why it did or didn’t install a feature, component, or file; what a property was set to, and when; why an upgrade did or didn’t run; why a custom action ran or didn’t; and so on. Look under the InstallShield Tools menu for utilities to help you create a log file, and more importantly to help you analyze a log file.
  • “InstallShield” is not “MSI”. “Windows Installer” refers to the technology, database format, or run-time engine, where InstallShield is the authoring environment that generates a Windows Installer package. While InstallShield extends Windows Installer functionality—with its XML, SQL, IIS, Flash billboards, virtual-machine detection, enhanced permissions support, InstallScript actions, and the rest of the long list of add-on functionality—the core technology is handled by the installer engine. For that reason, some installer characteristics are just a fact of life: dialog boxes don’t publish edit-field-changed messages; the feature-selection control shows subfeature options even if a feature has no subfeatures; file-overwrite rules are what they are; and so on.

In future posts, I’d like to share some big ideas and small tips that have helped me along the way, from Windows Installer features that have been around from the beginning to the newest InstallShield features, and I hope you’ll join me.

Leave a Reply

Your email address will not be published. Required fields are marked *