dcsimg

Windows Installer Best Practices

By ServerWatch Staff (Send Email)
Posted Nov 13, 2000


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? Ive compiled the following list of 'Best Practices' to consider when writing MSI Packages, based on my experience. This list is by no mean exhaustive, but quality MSI information is so hard to find at the moment, that hopefully these suggestions will prove to be useful to those of you in the process of, or considering, doing some MSI packaging....

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: [\[[<mystring>[\]]
  • 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.

Page 1 of 1


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.