I find myself in a similar situation as Vitalii. Our situation is thus: - The MSI file for our product has a large number of features which the end-user needs to be able to select between. Most of these features are optional and based upon what software the end-user wants our product to integrate with. I don't see any feature selection options in the current StdUX, and I'm not sure what is planned for future releases or what kind of timeframe any enhancements would be on. - The only feature of a bootstrapper we need is chaining. Our product requires MS SQL CE and a hardware key driver (which is only provided as an EXE installer), which both need to just be installed without user interaction and can be safely left on the system if our product is uninstalled.
From my point of view, while writing a custom UX for Burn is possible, it would require a lot of work on my part as I'm not at all fluent in COM, and I haven't written a raw Windows API program in years. It seems to me that allowing the UI from my MSI to be used would get me where I need to be with the least amount of effort on my part. My 2 cents. Thanks for all your efforts so far. Daniel Moody | QA Engineer | Gibbs and Associates Phone: 805-523-0004 Email:dani...@gibbscam.com www.GibbsCAM.com On 1/12/2011 12:11 AM, wix-users-requ...@lists.sourceforge.net wrote: > Date: Tue, 11 Jan 2011 23:13:34 -0800 > From: Rob Mensching<r...@robmensching.com> > Subject: Re: [WiX-users] Burn issue > > Again, Burn is more about creating a unified installation experience than > displaying a "collection of random installation experiences". I suggest > playing with Burn and seeing how it caches content for you then executes the > installs to better understand the flow and why I'm challenging the > assumptions.<smile/> > > Of course, Burn is still under development and there are future releases to > come as well so if we can get crisp about the scenarios and they make sense > we can always look at adding more code to the Burn engine. > > In your first example, I don't understand, why you have to create a UI in > your MSI. Burn will show UI for all scenarios (install, repair, uninstall, > upgrade patch) so you do not need a UI in your MSIs. I agree that it may > appear easier to just reuse UI in your MSI until you factor in caching and > some progress while running pre-requisite installs. > > I don't follow your second scenario. Or, rather, I don't see how it is > different from the previous scenario. Can you provide more details? > > > On Tue, Jan 11, 2011 at 12:22 PM, Vitalii Dolia<vdo...@hotmail.com> wrote: > >> Rob Mensching<rob<at> robmensching.com> writes: >> >>> Maybe. It's not really in the model Burn was designed for. Burn was >> intended >>> to provide a seamless installation experience not pop up a bunch of >>> different installation wizards. >> [skipped] >>> Burn is designed to provide >>> the antithesis of that experience.<smile/> >> What if someone still wants to install main msi-package (using the package >> UI) >> and deploy it's dependencies in a silent mode? The dependencies are a >> subject to >> remain on user machine (almost always) permanently (Windows Installer >> redist, >> Visual Studio redist etc.) I'd like to use UI from the main package, which >> I >> have to create anyway. >> >> Another scenario, when I need to install a single msi-package conditionally >> from >> a single multi-package installer. In that case I'd prefer to use UI of >> embedded >> msi-package, rather than create new UI for bootstrapper. Unfortunately the >> old >> bootstrapper from WiX 3.5 doesn't support chain conditions, but Burn >> doesn't >> show UI of embedded packages. Am I forced to write my own bootstrapper or >> extension to Burn in that case? >> >> -- >> Vitalii Dolia >> ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
