There are some really good Windows Installer guidelines up on the Windows Installer Team Blog.  Part 1 went up yesterday and Part 2 went up today.  Most the rules I follow already, due to constant beating of the forehead against the wall experience that I call working with Windows Installer, but it was help to see the rest of them.  I listed them below, with my own comments.  Visit the links for Part 1 and Part 2 for the full text behind each rule.

Rule 1: Learn the Windows Installer Technology

This is key.  I picked up a lot from Wise’s support forums.  A really good book is The Definitive Guide to Windows Installer by Phil Wilson (ISBN: 1590592972)

Rule 2: Know Your Way Around the Installer SDK

I’m just starting to get under the hood with the SDK.  I wrote a console app in Delphi that allowed me to upgrade ProductCode and Package code of .msi/.wsi files.  It was part of a plan to heav each build of our application be able to upgrade from each previous build.  Other considerations led to me to shelf that plan, but it was interesting working in the SDK

Rule 3: Use the “Windows Logo” Program as a Basis For Good Practices
Rule 4: Always Use the Latest Version of the Installer

Both are common sense.

Rule 5: Build Setup Into Your Application Development from the Start

On my last project, I fought constantly with the project lead over this.  Having done several installer projects in the past, I knew what I was getting into and planned for the installers from the start.  This made life much easier.

Rule 6: Get to Know ORCA

Simply the best tool for diagnosing problems with a .msi file.  You can get from the Windows Server Software Development Kit.  The current version is the “Windows® Server 2003 R2 Platform SDK”.

Rule 7: Work On a Copy

More common sense.

Rule 8: Never Cancel a Package Build Before it Finishes

I never knew about that one.  With installer tool that I’m using (Wise), I don’t see that is being a real issue.

Rule 9: Use a Clean System for Repackaging
Rule 10: Do Not Repackage Microsoft Updates
Rule 11: Do Not Repackage MSI-Based Applications

Still more common sense.

Rule 12: Modify Vendor Packages Using Transforms

I may be doing this in the near future.  I haven’t had to do any package transforms, but I understand the basic concepts.

Rule 13: Be careful with Installer GUIDS

It took a while to sink into my head over the Gang of Three GUIDS, but it’s in my firmware now.

Rule 14: Use Consistent Package Naming Conventions
Rule 15: Do Not Try to Replace Protected System Files

Common sense again

Rule 16: Follow Component Rules

I need to study this more.

Rule 17: Understand File Versioning Rules

One of my pet peeves with Windows Installer.  Why does it ignore the last number of a version number?  If it could use all four parts of the version number, I could have my build to build upgrades and there would be much rejoicing in the land of Queue-ay.

Rule 18: Improve Performance by Limiting System Restore During Setup
Rule 19: Avoid Using the SelfReg Table

Good tips

Rule 20: Avoid Nested Installs

Having one .msi calling another .msi is something I seriously plan on avoiding.  Just follow Spengler’s warning and don’t cross the streams.

Rule 21: Avoid Using Configuration Data You Don’t Own
Rule 22: Differentiate Between User and Application Data
Rule 23: Don’t Use Resources You are Installing

Still more common sense.

Rule 24: Use Cabinet Files to Reduce Package Sizes

I need to look into that more.  I wonder how that would play with installers for web sites.  I could toss all of the .ascx files into a .cab file and the assemblys as separate files.  For Win32 executables, I usually pre-compress them using UPX as part of the build process, putting them into .cab files would gain nothing.

Rule 25: Follow Custom Action Rules

Some good tips.  I don’t use many custom actions, but it’s good know what not to do

Rule 26: Consider Storing User-specific Data in a File

This an interesting one.  Our .NET apps follow this methodology, but our Win32 apps use the registry for most user specific settings.   Something to consider going forward.

Rule 27: Consider Maintaining Setup in Text File Format

I would to be able to do this with Wise’s .wsi files.  The problem is that the .wsi is actually a .msi file, and I have yet to see a tool that will reliably convert a .wsi/.msi file to text and back again. I tried MSIDIFF, but something always gets mangled and when you convert a file from one to the other and back again, you don’t always get the same file back.  That’s not a good thing.

Rule 28: Think about Localisation

Something I don’t have to deal with…

Rule 29: Follow the Assembly Rules

Wise does a good job with this, I usually don’t have to worry about assemblies.

Tags: