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 api dll, a setup program that installs a service the API uses and any prerequisite files (VC++, .NET framework, etc). This setup would be built by Wix bootstrapper into a .exe file. End customers could then drop our .exe setup into their installer and run it silently to install everything needed to run our API.
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.
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):
