ServersWindows Installer Best Practices

Windows Installer Best Practices

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.





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

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories