We are having a System.BadImageFormatException in our MSI installers. I have already read about the target frameworks, but we already checked and it's targeting the correct framework (.NET Framework 4.5 same with our QA machines).
We have exactly the same source codes, but the results of the msi installer compiled by our 'build team' fails, but the msi installer compiled by us 'dev' works. Question is, does the environment where an application was built and compiled affects the output (example: msi installers)?
There are basically two reasons for this error:
A cross-architecture call from 32-bit code to 64-bit (or vice versa). Different architectures require different MSI setups Heath Stewarts blog and so everything in a 32-bit setup (especially managed custom action code) should be explicitly 32-bit and explicitly 64-bit in a 64-bit install. For example, when an x64 system encounters AnyCpu code it might load the X64 runtime, and then a reference to a 32-bit assembly will fail and get this error.
A .NET framework runtime attempt to load the "wrong" framework. The NET 4 runtime is somewhat backwards compatible, so you are most likely to get this error when code expecting the NET 2 runtime encounters a NET 4 engine. The devil is in the details here, but again, this is much like the architecture issue. If anything loads the NET 2 runtime and the calling sequence tries to call a NET 4 assembly to run in the 2.0 FW it will fail with this message.
Having said that, it's not clear exactly how you are calling the managed code, whether through DTF or something else (such as the Visual Studio InstallUtilLib mechanism). And finally the machine you build on makes no difference to the eventual runtime environment. It's no different from a code file which will work on one machine but fail on another because (for example) it can't find the C++ runtime. The issue isn't the build machine, it's the environment of the target machine.
Some Suggested Debugging Steps
So it is the actual MSI file which triggers these errors, or the application after installation?
Below are some thoughts and questions to consider when trying to debug issues such as these (in no particular order). My bet is on issue 3 in this first list:
Does this exception occur as you run the MSI itself (or is it a setup.exe?), or as you try to launch the application after installation? Just to verify - I assume the MSI.
Do you have custom actions in the setup? If you have managed code custom actions in your MSI, what platforms do you target in your build? Any CPU I would presume? Please verify. I think there are some issues with COM-interop here, but I am fuzzy on the details. Sometimes you may have to pick a specific platform. In this case you can get such error messages (bad image). See section "Managed Code" below for a whole "rant" about managed code and deployment - and some problems that may result.
Regardless of the above, in your WiX source file, what is the value of the Platform attribute in the Product element? Possible values: x86, x64, intel64, intel, arm, ia64. Please report (and try to test with other values as well - x86, x64 for example). This affects the MSI's platform setting. If you don't use WiX - open the compiled MSI file, and check the summary stream for the Platform setting. Using Orca this is View => Summary Information... - look for Platform.
Do you have any malware scanners, security software or other "potential blockers" for MSI compilation and / or installation on your build computer? Or on the test system where you try to install? (We must always mention these issues - people can waste days if we don't - even if it rarely seems to be the only issue).
Is this a localized MSI using Asian characters? (or Arabic, or any other complex character sets?). This I just mention - frankly I don't see how this is 100% relevant, but I want to clarify this "variable" for your scenario (i.e can we eliminate this as a potential error source). It would generally cause runtime errors, not System.BadImageFormatException issues - I believe.
I assume a compare of the different MSI files may not work because one of the files is a "bad image"? Did you try? Maybe it is still a valid COM structured storage file - but the msiexec.exe engine can't handle it? If it is, then tools may be able to read the content inside the file just fine - I don't know, give it a try.
For your scenario: I initially thought a single, compiled MSI behaved differently in different locations (environments) - and hence suggested to check for any damage in transit (network issues, samba issues, storage issues, malware issue, etc...) by doing a binary diff on the copies in the different locations (bit-level comparison). Since you seem to compile two (or more) MSI files from the same sources, such a binary compare is obviously meaningless. Differences are certain.
However, a "content compare" could tell you something - this compares actual content in the tables / streams inside the MSIs. I think I will add a Q/A on how to compare MSI files that I can link to from here (added: How can I compare the content of two (or more) MSI files?). This presumes that the MSI is readable - even if it is not runnable. Only way to know is to try.
I hope and believe that the above list should help you sort out your problem.
I wrote myself off a cliff below on the subject of managed code issues. The idea was to describe a couple of issues to check, but it became a long discussion. I may delete all the stuff below and perhaps resurrect it elsewhere. It may not be relevant for you at all. The overall topic is managed code and how it can crash in new and "interesting" ways:
Managed Code
This is another one of those sprawling answers that got out of hand. I
think it still has value, leaving it in.
A couple of further issues with regards to .NET custom actions (managed code). I am far from an expert on this topic, since I shun them like the plague (for now - this may change over time).
Some of this veered quite a bit off topic - for your purpose - but I will leave it in as general comments on managed code for MSI use.
MSI expert Chris Painter is the man for this topic - he has taken on this potential "world of pain" and seem to benefit from such custom actions too, but these managed custom actions seem generally accepted to be problematic - if you approach them in a naive way. Be pragmatic and weigh benefits against potential problems listed below.
A friendly piece of advice: for worldwide distribution I would never use managed code as of now - though it is "getting safer" - we have to admit that. There are too many potential error sources for a large scale distribution MSI package using such custom actions (home users may uninstall .NET, corporate users may see versions of .NET disabled, and the whole list of problems below, and I fear "catch 22" uninstall problems more than anything - a whole section on this below, etc...).
As I said, I am not an expert, but there are many, and serious problems. Maybe Chris can correct me if they are "sorted" by now. The DTF framework (distributed along with WiX) features support for embedding a managed code custom action dll inside a regular win32 dll wrapper. This helps reliability. I will dig up a few links here for reference. Chris has been a pioneer and early-adopter here.
Partial list of managed code problems for custom action use:
The .NET framework may be missing, disabled or corrupted (entirely or in the version requested / needed for your code). Now, what if all your 3000 corporate packages have a .NET dll with managed code embedded in them? They can't even uninstall in this case - much less upgrade. More below in issue #5.
When targeting different versions of the .NET runtime with different custom actions, all will load the same CLR version. So they tell me (I could not believe it whilst reading it - please read it!). Enough for me to run for the hills :-). "This can blow up in any number of ways" is what I hear myself think. Apply suitable paranoia accordingly! The resident evil of all things rears its ugly head again - etc... Seriously, don't listen to paranoia, but be on alert for serious problems. Is this problem managable? I guess - I would have to say yes, but it is not a problem to ignore. Serious UAT / QA needed on many different OS and .NET versions. Would a native dll do better? I think so.
Components installed to the GAC can not be used as dependencies for your managed custom actions in the setup (chicken or the egg - I suppose). This has to do with the commit models of Fusion / MSI.
Bob Arnson has commented on this - check it out (he is on the core WiX team). I don't know if this still is his top issue with managed code - along with rollback.
Small digression: I have read Arnson stating that VBScript actions are worse than managed code (Painter certainly agrees, and definitely the WiX boss himself Rob Mensching - blog). I think this is true for just about all cases, but not for corporate application package scenarios (which I have experience with) - or ad-hoc testing that will never be used in production (quick and easy).
I describe the reasoning behind this here (pragmatic issue): Windows Installer fails on Win 10 but not Win 7 using WIX (essentially anything compiled adds a source control problem in the real, chaotic world - and corporate packagers have to pick up each other's work on the fly and a fully embedded, transparent source file in the MSI saves the day - all the time, and there is a skill set issue as well, and there is more...).
I do not recommend VBScript for anything but corporate use in controlled environments (standardized workstations). VBScript is not good enough for public, worldwide MSI releases in any shape or form. They can work for read-only custom actions returning no error codes and set to ignore all runtime errors, but no - there are better ways.
UPDATE: I can add that in a snag I would use VBScript in read-only custom actions in the GUI sequence (just a property setter script) in order to get rid of the .NET framework as a dependency altogether. The time will come when the .NET framework is on all target machines, but it is not quite there yet (and even if it is there it could be broken. Windows now actively fixes ActiveScript to always be running - and MSI hosts its own ActiveScripting runtime - scripts will run, but you could easily mess up the code yourself to make the custom actions horrendous still).
I should add that my recommendation to use Javascript over VBScript in the link above will be removed soon. Javascript has proved just as bad as VBScript in practical use, with some added snags that are too detailed to go into. The enhanced exception handling offered by Javascript does not make up for the fact that the MSI API seems to have been tested with VBScript during its development. Javascript was probably not, and hence has a few clunky issues when working with the MSI API that are not immediately apparent. I have wasted costly time on this - I would recommend you don't waste yours.
I also use scripting for testing, prototyping and debugging my MSI packages (to debug property settings, app searches, override command lines for testing, etc...). I find this the quickest way (who wants to compile something ad-hoc for this?). Just don't roll with your script test code for release! If using Installshield I use Installscript for such "scripting".
And for the future: one good use for managed code would be embedded
directly in the MSI, in inspectable (and reusable) form - making custom actions white box - with full source embedded and with full code access security too, making them unable to run with freebasing elevated rights. Just thinking about what could come - let us see what you are doing in this custom action of yours?
To elaborate issue 1, managed code may hard-code a certain .NET runtime version that is not available. I guess this is probably the easier problem to deal with? Correct me if I am wrong Chris. I am just a dabbler with this. Setting "lastest version" could still cause issues though...
Let me add a pet peeve of mine as well: if a managed custom action fails during uninstall due to a corrupt .NET framework (or for any other reason - focused on managed code issues - for example a design / security change in Windows itself from Windows Update) - you can't uninstall and thereby not (major)-upgrade your existing installation. A serious catch 22 in my opinion. Try this if you have 3000 live packages and thousands of desktops to manage and the dll is embedded in each MSI...
Creating custom action code of any kind that trigger errors on uninstall / upgrade was my big fear when making a C++ custom action dll as well - so it is not unique to managed code. A classic error is to set custom actions after InstallFinalize or in the UI sequence to "check exit code" - and a trivial error returned causes full rollback of a major upgrade. A classic "catch 22" - now you can not upgrade without fixing the problem in the old product's uninstall sequence.
Despite this being a general problem for all custom action code, I feel the risk is heightened quite a bit with managed code. What if some weird policy change to the .NET framework makes all packages in a large corporation un-uninstallable and un-upgradeable since they all have embedded the same problematic custom action dll? Or worse yet, it is a Windows design change that you can't roll-back?
A contingency should be available in such cases. This is the core reason I stay away from managed code entirely - I like down to the wire better - fewer layers to depend upon. Minimal dependencies, minimal entanglements (no imperial entanglements). If a minimal dependency C++ dll does not run, then the core of Windows is generally broken and the system needs a rebuild in most cases anyway. For .NET custom actions you would minimally have to fix the .NET framework (which might be easier than I think - for all I know - don't think so though).
I was looking at ways to make the DLL external to all corporate packages in a pre-requisite package (ideally with a minimal, baseline, embedded DLL in the setup itself as well - if the external DLL is missing / not found). The idea being that an external DLL is preferred once available, and upgradable for all packages by a single, updated "prerequisite package". All 3000 packages fixed - all at once?
I never got around to determining the technical feasibility of this. Bear with me, I am getting off topic for your purpose. If the WiX guys are reading - what are the technical possibilities here off the top off your head? Essentially I am expecting to hear "impossible" - and then I am done with it. When thinking about this I was preparing for potential problems with the embedded DLL in Asian and Arabic locations (potentially serious and unexpected and fatal runtime failures due to Unicode / code page issues), and also for any unexpected security changes in Windows (that we keep seeing - Windows 10 ransomware protection which currently intermittently triggers runtime failure for files installed to userprofile folders, or the sudden need for admin rights for MSI repair - kb2918614 which appeared out of the blue on Vista, and whatever else they keep changing unexpectedly...). I did not want to sit with thousands of un-upgradable, un-uninstallable packages - already deployed to tens of thousands of machine.
My "last resort" contingency for corporate use was to "hack patch" all cached MSI files in the local, super-hidden MSI cache folder using a "home grown" patcher EXE deployed by a hotfix package. Generally insane in every way, but it looked technically possible (until digital signatures shuts off the possibility?). And for me the only acceptable "last resort" I could think of if tens of thousands of trading floor machines were hit by disaster suddenly.
I can think of at least two other options - one of which is to minor upgrade affected packages (lots of work, cleaner, guaranteed to work). The last option will not be mentioned :-) - (Voldemort, "those we do not speak of", etc...).
An auto generation feature for minor upgrade patches to patch the embedded custom action dll's was also on my list of contingencies - the minor upgrade would only patch the dll - no other changes. Then problems could be handled on a package-by-package basis. This patch should be available at the click of a button when pointing to a live MSI package in need of patching. An "embedded custom action dll hotfixer". A thing that should not ever be used if at all possible. Contingency "solutions" are rarely pretty.
My two cents: I can think of few scenarios where minimal dependencies are more important than for an embedded custom action in an MSI. It must work on any machine, in any state, in any language, in any location in any installation mode (and uninstall is the catch 22 here) ideally without any non-standard dependencies at all. I statically link C++ code for this very reason. For worldwide distribution I feel this is the only thing that is currently good enough - statically linked C++ code - (with the possible exception of Installscript - from Installshield - which is now running without dependencies apparently - embedded runtime? I don't know how they do it - in the olden days there were legendary problems with the required runtime pre-requisite for the Installscript language. It should be fixed since version 12 of Installshield).
This is not a complete list. It is my "run for the hills list" :-).
No fear though - just be aware of it all - and use the benefits of managed code if they are substantial enough for you, but don't expect entirely smooth sailing is my take on it. I would be upfront with my manager about these potential bear traps, without sounding like a total, paranoid lunatic. A good manager will be able to "sell" any contingency plans as necessities, that you can get time to work on and even demonstrate quickly (believe me, attention span here is short - it has to be the quickest demo ever). The big question is whether you have one package to deal with, or thousands like we do in corporate deployment. Things change a lot for the latter. Risk must be minimized for all features that are embedded in all deployed packages.
If I am 100% honest, it is not as bad with managed code as it used to be. Using DTF and other frameworks have helped. But the potential runtime issues for uninstall problems are worrying. A global change to the .NET framework in the company - and all your packages can no longer uninstall? Or a newer version of the .NET framework reveals unknown bugs in the custom action not found when it was deployed? It may suddenly "manifest itself" on attempted uninstall / upgrade. Managable, but you will curse yourself...
I would prepare your support guys for the above managed code issues - they should know about the issues and really understand what .NET is about.
"We have never seen any problems with our managed code custom actions" - famous last words - to be honest.
If your target computers are uniform and standardized (SOE environment) - which is normal for corporations - then your packages may appear better than they really are (now this is true for packages with scripts too). Just wait for the next SOE version based on a new operating system... I would pilot test early with all packages in the package estate.
You could still face the irony that all target computers start failing in exactly the same way (Windows design changes in Windows Updates, security software updates that trigger interference, SOE updates that fail for some locations, etc...).
For worldwide distribution things are quite different and things tend to fail in any number of ways that are hard to debug and fix or even work out at all. You normally have no access to the problem system at all - for starters. Maybe read some further comments in "The Complexity of Deployment"-section here: Windows Installer and the creation of WiX.
So I would never use managed code for global distribution of a complex package - unless you are delivering a very specific product and know the nature of your target machines in more detail than normal. Cost / benefit.
I would have a contingency for what to do if many machines are affected by unforeseen triggers of "deadlocks" such as not being able to uninstall / upgrade. Some paranoia in this scenario, but not impossible. Silly "war games". Risk is for your manager to manage, and for you to handle technically.
Adding a link to an aging, but still valid FAQ entry from installsite.org on the topic of managed custom actions and their problems: How can I create Custom Actions in Managed Languages, like C#?.
And be skeptical of any custom actions in the first place!
Managed code just adds to custom action volatility. Custom actions are complex and difficult to get right in the first place. They run impersonated or in the wrong context unintentionally, they run twice unexpectedly, they don't run at all when expected to, they run in the wrong installation mode, they crash due to missing dependencies, they cause exceptions due to bad coding that fail upgrades and uninstalls alike by triggering rollback, you hard code references to localized folders so your setup crashes in non-English machines, you name it...
Built-in constructs in MSI itself, or pre-written custom actions (with rollback support) in frameworks such as WiX or commercial tools such as Installshield and Advanced Installer have been tested by thousands, millions or even billions (!) of users - and they are written by the best deployment experts available. Even for these components, bugs are still found - which says it all. Do you think you could do it better on your own? Always prefer ready-made, tested and maintained solutions - if available.
A whole rant about the problems with custom actions in general: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?
"Sources"
Some further links (some of this content may be showing its age by now, but these are trustworthy sources - not to be ignored - Mensching is the WiX benevolent dictator):
Don’t use managed code to write your custom actions!
Link to more details about the dangers of managed code custom actions in an MSI.
Managed Code CustomActions, no support on the way and here's why.
How do I create a localized windows installer package for my WPF application, it has support for 6 languages and I want to have EULA document being localized when user installs the application
I see you tagged Wix and InstallShield, so maybe you are open to try other tools too. Advanced Installer (disclaimer, I work on its development) has in the Professional edition support for multilingual packages.
You just select the languages desired from Translations page, then go to Dialogs page and add a new predefined dialog, select "LicenseAgreementDlg". Advanced Installer will see that you have multiple languages in the package so it will ask you select the EULA file for each language. In roughly 10 minutes you will get your first installer up and running.
I am not quite up to speed on WIX and localization (language support). This online tutorial is a good starting point for you: http://wix.tramontana.co.hu/tutorial/user-interface/do-you-speak-english . Just read through the different User Interface sections.
I don't know which bundling you intend, but in my experience a multi-language setup is less desirable than compiling one MSI file per language. This is easier and faster to compile and work with (very important for large packages), more flexible if you need to bug fix something in a single language, allows you to add new languages easily without full UAT for all languages, and you can deliver the English version as soon as the code is done without waiting several days or weeks for localized files (if any are required).
If you plan to use Windows Installer XML, you can check my answer here. Note that the method is undocumented and not supported by Microsoft, however MS uses it itself and it is working very well.
Just provide a different file for every language transform to the WixVariable WixUILicenseRtf.
When using Wix/Votive to create setup projects with Visual Studio integration, it seems like COM registration is a big hole in the feature set. Both Visual Studio and the integrated Visual Studio setup projects do this almost effortlessly. Wix, on the other hand, makes it positively painful.
During the build process, Votive calls Heat.exe to harvest referenced projects. Why could it not at that point also harvest the registry entries necessary for COM Interop? This would integrate the process into the build and free up developers from this mind-deadening chore. It would also maintain a declarative/data-driven install process.
Has anyone looked into doing something like this? I imagine it would be necessary to edit some of the Wix MSBuild targets, I'm not confident enough with MSbuild to do it myself. I'd be really interested to hear from anyone who's had a stab at it though.
I don't believe in dynamically generating components during the build. I've written entire articles on the fragility and non-deterministic behavior of that pattern. Instead I treat my installer source just like the rest of the system and author it up front and check it in for the build to merely compile.
In that situation I use heat to generate the registry data for my COM/COM Visible dll's. Being lazy, I wrote a tiny winforms utility that puts a filesystem watcher on a dirctory and whenever there is a change notification I pass the directory off to heat. I then get heat's output and load it into the winform using an XML editor to provide highlighting. I look at what it wrote and if I like it I copy and paste it into my wxs files.
Updated with URL upon request:
Dealing with very large number of files
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.
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:
Always be used together by end users
Always get updated at the same time
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
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.
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.
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.
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.
I'm currently learning how to create msi installers using WiX and it seems I've hit a wall.
All is well when I create an MSI containing everything needed for a single environment.
I have features, and components, and can install my MSI.
Now I'm at the stage where I want to convert this in a SQL Server-style installer, where you have multiple instances support.
At the start I want to user to get a screen which allows him to create a new instance, or manage already existing instances. (to update/remove them)
I've spend 2 full days looking everywhere for a solution, without much luck.
I've found the following resources with some info on it, but either they're limited in the number of instances, or don't describe how to such a bootstrapper which gives a user the option described above.
Multiple Instance MSI's and InstallShield 12
Multiple Instance Transforms Walkthrough
Multiple instance installations and patching
Has anyone achieved this already using WiX? Or can anyone point me towards some working examples on how this is achieved?
I know Installshield 2009 can do this, but since this is just a hobby, I don't have the money to buy that. Also I'd like to do it in WiX, since the upcoming Visual Studio 2010 will improve support for it.
Creating multiple instances is pretty easy with WiX v3. You just use the InstanceTransform and Instance elements to create everything. Now, the bootstrapper problem requires something outside of the WiX toolset since we don't have burn, yet. I'm not sure we'll get this functionality in WiX v3.5 (with burn) but it is on our list for burn post v3.5.
Although I've never created a multi-instance setup, I also noticed that Acresso announced MI support in IS 2009. We have IS 2009 but didnt use this feature.
However, Installshield often simply makes use of new MSI features by offering an "intuitive" frontend to them (like for chaining multiple MSIs together into one). So you might want to look for general information on how to achieve that by using the MSI SDK.
Here are some useful links that might point you to the right direction:
Authoring Multiple Instances with Instance Transforms
Multiple Instance Transforms Walkthrough, Proposed Simple Addition to WiX to Make Them Easier