Can a WiX based windows installer be used within other installers?

Question

Is a setup built using WiX bootstrapper generally capable of running within other installers?

I am wanting to create a distributable set of files that contains an ap

Answer 1

The Short Answer: Your setup.exe can be installed by another setup.exe as long as it does not kick of several MSI files to install concurrently, and the other setup.exe also runs things in sequence without spawning multiple MSI installs at once. Technical explanation below.

Essentially you can deliver your setup as a setup.exe, an MSI or as a merge module or all of the above.

UPDATE: I want to check if you are familiar with WiX include files?

---

InstallExecuteSequence Mutex: Two MSI files can not run their actual install operations (the actions that actually change the system) concurrently for very fundamental, technical reasons (a mutex is set when the InstallExecuteSequence runs between InstallInitialize and InstallFinalize).

Multiple MSI GUIs: I have written about this issue many times, but I think the most straight forward explanation is this one from serverfault. Essentially the system is locked to ensure all changes can be rolled back if an error occurs during installation. It should be noted that you can launch several MSI files at once and get to their GUI sequences (in other words show the setup dialogs preparing for actual install), but you can only kick one off at a time doing actual system changes - in technical terms that means running the InstallExecuteSequence.

Sequenced MSI Files: MSI files can run "one after the other" without problems, provided they are all well designed. The WiX bootstrapper Burn is made specifically for this purpose (and a few other complimentary purposes: downloader, bootstrapper, sequencer, allow external, custom setup GUI, etc...).

---

Potential Approaches: It seems your setup will be included as part of other software suite's installations? There are several options here.

• Run in Sequence: If the other software vendor is OK with this, they can include your setup.exe in theirs and let it run to completion before continuing with their own setup. That would mean them doing this from their own setup.exe created with WiX (Burn), or an equivalent setup.exe generated using Advanced Installer, Installshield or another commercial tool (or even just dotnetInstaller - which is a free bootstrapper).

• Merge Module (a Symantec article): Alternatively you can make a "merge module" out of your own setup - which is a consumable, binary "bundle" that can be merged into any MSI setup at compile / build time. It is a little database fragment, or a partial database if you like. It will contain all your components set to install in an appropriate fashion. Essentially the merge module is your setup delivered as a consumable, whole component that becomes an actual part of other setups - without installing as a separate pre-requisite setup. In other words it is an alternative way to deliver your runtime, without delivering a separate setup. It is how MSI originally intended for pre-requisites to be deployed, and it basically still is - althought alternatives such as Burn now exists.

  • Making merge modules: Advanced Installer (merge modules general info), WiX (maybe check IsWiX's installer source, it uses merge modules), Installshield (merge module projects).
• MSI File: Frankly my favorite approach is to not worry about a setup.exe launcher that does a lot of pre-requisite installation, but to deliver a standards compliant MSI file that your customers can run in sequence before their own installation. Your MSI could set launch conditions to refuse installation if the appropriate runtimes have not been installed. This way your MSI can "update itself" if bugs are found, and in theory it can be distributed alone - without a need to recompile all setups that bundled the merge module - to any computers with the first version of your software installed. I like this de-coupling.

---

Real-World Story: Many people like merge modules. I have to admit that I am not a huge fan, but when done right they work quite well. At times I have been forced to deal with merge modules that ruin perfectly good setups with their incredible built-in design flaws (the SOAP merge module from back in the day comes to mind - it drastically - and single-handedly - raised my setup's error rate and had to be removed). Not a problem of merge modules per-se as a technology, but practical issues that more than once have caused problems.

The moral of the story: don't deliver a bad merge module with lots of custom actions that fail and weird requirements that bloat the "parent setup" with unnecessary frailty and content. If you deliver a standards-compliant merge module that does its task "minimally" - then that is a good way to deploy your runtime and even preferred by some vendors.

Core OS Runtimes: I would recommend to not bundle the .NET framework with your setup - especially if it is for corporate use. Dot NET is now close to being always available via the OS itself, and the runtimes included in setups will quickly merely be outdated bloat and "fat" that corporate application packagers will spend a great deal of time getting rid off from your package. Dot NET updates are best distributed via Windows Update (or equivalent corporate deployment mechanisms).

Instead it seems to be a normal approach to have a one-page (PDF) document explaining (see a bit down the page) what pre-requisites your application needs in order to operate properly. Certainly for a merge module component you would document this as you can't include core runtimes with your own merge module - generally you can only install your own files.

---

Some Links (just for reference):

• Can Windows installer install two msi files at the same time?
• Why Windows Installer can only install a single program at a time?
• Other installation In Progress Hanging my Wix Install
• Wix Custom Action Sequence
• Prerequisites button disabled - MSI installer
• How to make an installer that automatically install all the prerequisite programs for the application
• Wix - How to run/install application without UI