tags:

views:

671

answers:

4

Hi,

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.

Regards,

tvks

+2  A: 

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.

Wim Coenen
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.
David Newcomb
@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.
Wim Coenen
+2  A: 

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.

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, and 3) won't grow substantially in size over time. And normally it is impossible to predict any of this. Typically you will quickly get new requirements such as:

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 full QA 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 much easier for "slimmer" MSI files than fat ones.

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.

Glytzhkof
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. Then you got a "George is getting upset" situation. No happy place, no happy place.
Glytzhkof
A: 

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.

DSO
A: 

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.

David Newcomb
*Concurrent Installations* is a **deprecated** feature of Windows Installer. http://msdn.microsoft.com/en-us/library/aa368010(VS.85).aspx
Wim Coenen