Wix to Install multiple Applications

Question

I probably have a strange request.

I have develop a msi to install two softwares. After the EULA a screen with two checkboxes must come and on selection of either or both of these checkboxes the corresponding softwares have to be installed.

I have used to install a single software earlier never for two.

I would be obliged for any leads.

Neusatz

Answer 1

Windows installer has a concept of "features" which can be selected for installation or omitted. If you have already created a working installer, then you have at least one <Feature> element in your WIX files.

Simply create multiple <Feature> elements and then use <UIRef Id="WixUI_Mondo" /> or <UIRef Id="WixUI_FeatureTree" /> to allow the user to choose which features he wants to install.

Radmen

You can fake-up 2 applications in 1 MSI by splitting it into features. However when it comes to applying patches you will never get the chance to update one feature but not another and so the whole thing falls apart. – Sonni

@David: do you have an example of how this "falls apart"? I don't immediately see any blocking problem. Feel free to blog about it, I've subscribed to your feed. – Radmen

This is a very bad idea, from the installer stand-point. Features are meant as parts of the same program, not separate programs all together. The way to handle installation of multiple programs would be through a chainer or a bootstrapper. I would put my money with chainer, but that is personal taste and experience talking. – Ejection

Who is to define what is a "separate program" and what is a "feature"? If I search for .exe files in the program files folder of visual studio 2010 express, I find 14 executables. Should these all have separate installers? Glytzhkof makes some good arguments for separate installers, but obviously these arguments don't always apply. – Radmen

Wim, good point. These executables generally won't take on a life-cycle on their own since they are delivered local to the visual studio product folder and function as part of a product suite. They are generally not standalone binaries which will be invoked as a program in the start menu, but utilities that are invoked from visual studio itself. On the other hand the visual studio installer does include several other installers as part of its installation chainer. These installers are designed to be cohesive so they can be updated separately from the rest of the product suite. – Annalee

Answer 2

Cohesion & Coupling: Bundling applications together in a single MSI file, may seem like a good idea. It seems intuitively nice and simple. However, speaking from real world experience I almost always end up splitting applications to install via their own MSI files, and I don't like multi-lingual setups either (true multi-lingual setups are difficult because translated content is typically not ready when marketing and sales push to release the native language version quickly - typically the English version).

The only time it is really safe to deploy applications together is when they are guaranteed to:

1. Always be used together by end users
2. Always get updated at the same time
3. Won't grow substantially in size over time (Localization, New Prerequisites, etc...)

And normally it is impossible to predict any of this. Typically you will get new requirements quickly.

Central Challenge: What will likely take on a release-cycle of its own? (split it right now). Things tend to happen suddenly! Here are some common challenges:

Bug fixes: if only one application has a bug, management will want to deliver only one new MSI and leave application 2 untouched and without the need to do a whole new QA-run for both applications after install. This is to reduce risk and to deliver a smaller update that is also quicker to test and verify. Patching is very complicated, and generally safer for MSI files that are as simple as possible without too many languages, custom actions or GUI constructs.

Localization: suddenly you get a requirement to make application 1 available in Italian, application 2 does not need to be translated. Language support tends to greatly increase the complexity of a setup, not to mention the size of it. Your "nice and simple" MSI has now suddenly gotten complicated to maintain, and sluggish to build. It is also a real pain if you need a single setup, and you translate it in many languages - you won't be able to compile the RTM version until all the language updates are in. I can tell you right now that marketing / sales people will have no concept of holding back the English version until all localized versions are ready.

QA / UAT: if the applications are large, delivering 2 separate MSI files will make it easier to split the testing effort between different QA teams and to deliver new updates via nightly builds etc...

Release schedule: suddenly the release schedule for the applications change - application 1 is now updated every month, whilst application 2 is updated only every six months. If different users use the applications, how do you deliver updates? Build it all in one MSI and give it a new version number only to have application 2 users install the same application over again?

Apply the overall developer principles of cohesion and coupling to deployment packages, and you will save yourself a lot of trouble. If the applications now OR in the future may take on their own life cycle - split their deployment right away. And who can see into the future?

Please note that you generally will wrap multiple MSI files in a bootstrapper so that users still have only one file to relate to, even if the products are installed via separate MSI files.

Wix update: With the advent of Wix to create complex setups it has become easier to build Wix include files that can be compiled into several MSI files. This effectively becomes a more flexible type of merge module. This may simplify the splitting or merging of MSI files in the future. See a discussion of this feature here. One more link.

Sheer setup size: There are some limitations with regards to how many components and files you can have in a single MSI. Some details:

• What are the limits for a large MSI package?
• Limitations of a Large MSI package
• Authoring a Large Package
• UPDATE: WiX allows preprocessor constructs and Burn bundles that can be used to split large setups.
• Long description here: Wix Installer : Setting component condition property when doing a MSIEXEC admin install at command line (markup towards bottom)
• And about different "variable types" in WiX: WiX (Windows Installer Xml), Create universal variables (there are many: precompiler, localization, burn, etc...)

It can be helpful to "decompose" a huge MSI into several related MSI for this reason and other reasons listed above - in order to make maintenance easier (build and compile speed, rebuild of just one of many MSI files, etc...). Finally you should stick to using a single file per component to make upgrading and patching work properly. Several MSI files can be installed in sequence using bootstrappers or launcher applications such as Burn from WiX, or features in commercial tools such as Installshield and Advanced Installer. Here is an answer which touches on this topic. And just trowing in another answer which is a little bit similar.

---

Links:

• Installing SQL Server 2014 Express as a prerequisite in boostrapper

Derman

Did you mean to say Chainer, instead of bootstrapper? – Ejection

Separate setups do have drawbacks. With separate but very similar setups, you run into dual source issues. Making the same update many times in different places. Use common code included by both setups for this, and branch when the setup logic diverges - which it will. Expect the unexpected, but reuse what you can as long as you can and for God's sake get a version control system capable of branching. Management has a way to turn requirements around quicker than you can write yourself unmanageable code. – Annalee

Answer 3

You cannot install multiple applications from a single MSI. Even if you figure out a way to do this you really should not.

Instead have separate MSIs for each app and use a bootstrapper to install both. E.g. you can use Inno Setup to generate a self-contained bootstrapper exe which installs both MSIs (and any pre-requisites as well).

BTW, Wix does not handle creating bootstrappers so you need to use it in conjunction with another tool.

Brushwood

Wix now has support for bootstrappers with the Burn tool. Here is a blog from Rob Mensching himself: robmensching.com/blog/posts/2009/7/14/lets-talk-about-burn – Annalee

Answer 4

You can do nested msi pre windows installer 4.

But you shouldnt anyway it was deprecated for a reason.

The replacement api is to call msiembeddedui and create a transaction chainer.

Underset

Answer 5

You can create multiple MSI's then bundle them into 1 containing MSI. The "parent" MSI allows you to choose which application to install then just runs that MSI.

If you really want 2 applications then there are non-MSI installer builders (like NSIS) that let you do that, but you have to do all the work yourself.

Sonni

Concurrent Installations is a deprecated feature of Windows Installer. msdn.microsoft.com/en-us/library/aa368010(VS.85).aspx – Radmen