Windows Installer Best Practices

by John Loomes

OK, we’ve all read Microsoft’s
MSI Whitepapers (well some of us have, the rest of you probably get
out more often….), but how do you really go about producing
quality MSI-based packages?

This article assume that you
are familiar with MSI terminology – so apologies if the remainder of
this is ‘Greek’ to you!!

• Set the Property ALLUSERS =
  2 in the property table. This will force the application
  to install for all users, if installed under an Admin account, and
  to Current User, if using a non-admin account…
• Set the Property ROOTDRIVE =
  C: in the property table – This will force applications
  to install to drive C:. Otherwise, if you have more than one
  drive in the target machine, MSI will look for the one with most
  free space. this means you cant always gaurantee when your
  applications will install to.
• Ensure that all user specific parts of
  the install i.e. all HKEY_CURRENT _USER registry entries, are
  contained in a separate component. When a new user logs into a
  machine, the self-heal functionality of MSI will detect a missing
  component in the users profile, and will populate the users
  registy with the settings for the application in
  question.
• Be sure to generate a new Product ID
  for each application – otherwise you will encounter installation
  problems when trying to install more than on MSI application on a
  single machine.
• Ensure that any INI file changes are
  recorded in the INI file table, rather than just as files in the
  file table. This will ensure that INI files are edited if they
  exist already, rather than replaced with the version within the
  MSI Package.
• Set the property REBOOT =
  Force in the property table to force a reboot at the end
  of the installation – if one is required.
• In the registry table, anything
  enclosed in square brackets [ ] is assumed to be an MSI property,
  and Windows Installer will attempt to resolve it. Whilst this is
  often quite useful, sometime you WANT to have square brackets in a
  registry value. To acheive this use the following syntax:
  [[[[]]
• Follow the components rules: Dont mix
  user and machine specific entries in a single component. Ensure
  that only one .exe exists in each component. Ensure that
  components are UNIQUE i.e. dont have a .dll that exists in more
  than one component.
• Dont use Custom Actions to make any
  critical system changes. Anything done in a custom action doesnt
  have any rollback capability, so if your install goes ‘pear
  shaped’ you cant roll back changes made during a custom
  action.
• Generate Merge Modules (MSM’s), for
  any common components, and use the Merge Module in any application
  that requires the component. Try to source and use commercially
  produced Merge Modules if you can. If you can’t (and you wont be
  able to for most things…) then produce your
  own….
• Make custom configuration changes
  using Transforms (MST’s), rather than by editing the MSI itself.
  This will make it easier to produce ‘generic’ packages that can be
  modified for several environments.