Multi-Product Shared Component Setup with WiX and MSI?

Question

Pitch

I'm looking for high level advise on how to structure a WiX and Burn MSI based installer solution for an application suite.

Question

Given the layout below how many distinct MSI packages should an installer suite utilize when all apps/features and shared libs go into the same installation directory?

• One single MSI package for the whole suite is clearly too large (as shown by the current system)
• One (complete) MSI package per application would duplicate the dll libraries shared between the apps, which would mean a duplication of 100s of MB worth of DLLs. (Plus, to me, unknown headaches with MSI refcounting)
• One MSI package per binary library and executable?
  • I.e., many MSI files would only contain a single DLL or a single EXE
  • Can I make sure the EXE MSI package is only installed when its prerequisite library packages are installed?

Background

Our application suite is layed out a bit like MS Office in that we have one installation folder where a series of applications is installed to together with all their shared library files. That is:

 C:\ProgramFiles\MyApplicationSuite
                                   \ - App1.exe
                                   \ - App2.exe
                                   \ - App3.exe
                                   \ - ...
                                   \ - libxy.dll
                                   \ - qt.dll
                                   \ - ...

Up until now, we had one single InnoSetup installer, that could install all of the apps as features, that is, there was only one single Programs entry in the Windows Programs list. This worked well because most of the time the whole suite was installed anyway, and some installations would maybe not use one or two apps.

Since the single setup approach start to break, and Corporate Requirements force me to switch to an MSI based installation, I'm looking into how to structure such a beast the best way using WiX, Burn and granular MSI packages.

Escort

A file installed to the same location should always have the same component id across products and versions. WiX can generate an id for you if you use a consistent source path across your setup projects. I would create a post-build audit tool to make sure, though (see WiX DTF or Windows Installer SDK). As Rob Mensching recommends, test upgrading to a prototypical version 2 before releasing version 1. – Covin

Answer 1

Some thoughts along the lines of what you already state on the topic of splitting or merging setups: Wix to Install multiple Applications. Have a skim of this and see if there are any variables that apply (release schedule, localization, build speed, etc...).

You can use merge modules or WiX include files (basically works like a normal header file include in C++, it is a preprocessor operation) to include shared components in several setups. They will then be properly reference counted and you can distribute updates to them in a controlled fashion.

Personally I like to split shared components completely away from my main MSI and install them via a separate prerequisite setup and then bundle it all together in a bootstrapper made with Burn or equivalent toolkits designed to allow installation of several MSI and / or EXE files in sequence. I find this yields good cohesion / coupling. This is debatable. An MSI is more "self-contained" when it contains shared, embedded components (merge modules / include files), but particularly for corporate deployment I like to split all shared components to their own prerequisite MSI. There are some very technical reasons for this that I would need more time to explain than what is available.

I will leave it at that for now, possibly returning and updating later.

---

Some Links (primarily for easy retrieval):

• How to express a file dependency using WiX
• WiX (Windows Installer Xml), Create universal variables
• Wix Installer : Setting component condition property when doing a MSIEXEC admin install at command line
• Merge module files into different locations
• MSI Reference Counting: Two products install the same MSIs

Rooke

The "shared prerequisite setup" thing is one I'd like to try (as mentioned in bullet 3 of my question ("One MSI package per binary library and executable"). However, unlike with the components/fragments you mention, I don't have a clear picture on how this would work out wrt. refcounting and prerequisite checks. Could you maybe elaborate on this? – Escort