We had some experience with two similar scenarios and used to have one big MSI. That quickly turned out to be impractical in the long run, today we have a dozen MSIs that all install with a similar configuration, most frequently on a 1-box setup. I definitely suggest you follow the "many simple MSIs" vs. "one complicated MSI" route and use a bootstrapper.
So you've been warned ;) Now you decided not to listen. Supplying a configuration file to the MSI is no different than supplying a list of parameters on the command-line. An executable that launches your MSI is a bootstrapper. Now we're just haggling over technology (XML vs. command-line). I have two stories of real-world implementation of configuration-driven installers. Story 1: We have introduced a "Setup Support Files" MSI that writes general settings, such as location of the suite to registry. We chose to use a bootstrapper (http://dotnetinstaller.codeplex.com) that chains the MSIs and ask the questions in the bootstrapper. We've been experimenting with the HTML UI in DNi 2.0 asking quite a few questions, such as destination folder or database username/password. We pass shared settings, such as install location, to the Setup Support Files MSI and write that value to registry. Then we use the registry as a hint for the value(s) in other MSIs. This avoids relying on the bootstrapper too much and allows us to reload the values on upgrade (from registry). Setup support files was a good paradigm as it brought in the uninstaller (the bootstrapper itself) for the suite. Story 2: Our most frequent scenario was a distributed one. We have two dozen MSIs that deploy the system. We developed a deployment tool (not open-source) that manages dependencies and order and uses WMI to remote-deploy the MSI. We described in XML what MSIs we have and various scenarios. What we built is a remote-deploy bootstrapper that's XML-driven. That worked well for 1-box setups as well - users would supply the XML "scenario" and fill in the blanks, such as machine names or credentials. Eventually I'd like dotNetInstaller to do this. Hope this helps, -dB. -----Original Message----- From: Timur Faizrakhmanov [mailto:aliv...@gmail.com] Sent: Wednesday, November 17, 2010 4:11 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Installer architecture design question Hi WiX community, I have a question considering Architectural Design of an Installer rather than explicit WiX usage. I would like to address this question to expert Installer developers and MSI guru's. We would like to have an installer, actually a set of installers, (preferably pure msi, no exe's or bootstrappers) that could be initiated via config.xml file. I.e. configuration file (xml format) would have a set of elements and attributes that "describe" what and where we would like to install. For example: InstallPath and a set of features. This will be used mostly in unattended scenarios. This file is supposed to be in the folder along with main setup.msi. For now, if I'm not mistaken, the only way I can read XML file and initialize properties would be the usage of Custom Actions. Our main app is written entirely on .NET platform, so, I guess, managed CustomAction and DTF would be fine. At least I would like to change the INSTALLLOCATION and some other properties (Feature install condition). This approach should be able to update itself using only MajorUpgrade (Bob, thanks for this "syntactic sugar" with this command, it really makes WiX code simplerJ with updates). So, when updates come to happen, new msi's should read configuration file again for the previous and maybe some changed values (InstallPath could be changed, set of features could be changed, etc.). So the question goes here. Is this approach is good in terms of MSI Design Guidelines. Maybe this whole approach, using CA to "tell" MSI what to do, is an anti-pattern and should be avoided in Production Development. I've already created a prototype of this approach and already have issues with property initializations, especially for the Feature conditions. I could not have 100% deterministic behavior during initial install and further upgrades. As an alternate approach I thought of using separate executable that would parse xml file and launch msi's with corresponding parameters (INSTALLDIR, feature selection), by the way, this approach gives 99,999% probability of successful installations. But still we would like to initiate the process launching only msi file, and no EXE. That's why I'm addressing this question to WiX community. I guess someone has already encountered this scenario before and has his thoughts of this. For those who didn't, the conclusions of this topic it could help them in future. So I guess this topic would be valuable to discuss for installer developers. Any advices, ideas and conclusions would be greatly appreciated! Thanks in advanced! Tim ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
