1. Doh, sorry about that. I usually start with a general search engine, but I should now begin my searches on the WiX website.
2. Cool, this is good. Clearly, the trouble with being in the current transition period is the confusion between the two concurrent approaches in WiX, which I understand is a necessary evil. 2a. Ah, so if I understand correctly, the move is towards a more intuitive way for WiX developers to make things happen in their installer without necessarily knowing/understanding the complexities and confusing aspects of the Windows Installer engine. Model-View-Controller stuff, if I'm correct. Cool! 2b. Again, looks like you're going with an MVC approach (at least that's kind of what it looks like), which sounds like a good plan. Thanks for giving me a peek into the backend design decisions! Once again, it's clear you know what you're doing. :-) Alain -----Original Message----- From: Rob Mensching [mailto:r...@robmensching.com] Sent: June 1, 2013 00:55 To: afor...@cmu.edu; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Skip restore point in bootstrapper bundle 1. I searched the WiX.chm for "restore point" and got one hit on the Chain element which has an attribute named "DisableSystemRestore". I think that'll do what you want. 2. Bundles are not Products. Completely different engines and we're trying to learn from the mistakes of the engines before us. 2a. Bundles don't support Properties they support Variables. They can act quite similarly but are in completely different namespaces. Thus we purposefully named them differently to force an understanding that they are different. Bundle's also don't tend to use "specially named" Variables to control behavior of the engine. Windows Installer does do that with Properties (ProductName, ProductVersion, UpgradeCode, ARPSYSTEMCOMPONENT and ALLUSERS for example) and it's a thing that we've found often causes confusion. As a result, in the WiX toolset, we're slowly creating strongly typed constructs to hide the "specially named" Properties (most recent addition is the Package/@InstallScope that takes care of ALLUSERS and a couple other things for you correctly). We've tried to solve this correctly from the beginning with the Burn engine so there aren't Variables to set that control behavior directly. That said, many strongly typed constructs are exposed as "built-in" Variables to make it easy for a BootstrapperApplication to access. 2b. The Burn engine avoids displaying *any* UI today so it doesn't do general purpose Conditions today. Tremendous amounts of code goes into trying to allow UI to be customized so the Burn engine just stays out of the way. The three places Burn shows UI I can think of are: Bundle/@Condition, the splash screen, Internet proxy password prompt. The Bundle/@Condition failures display a system message that basically says this operating system is not supported. It's basically designed so people can say, "I know Burn will run on Windows XP but my product won't so just bail." That message shows up in the system UI and is a boring MessageBox(). The splash screen is a bitmap provided by the user. Finally, the proxy password prompt is an Internet Explorer dialog box shown in very special cases and only if the BA says it is okay so that's not even really Burn showing the UI. Thus, the Burn engine doesn't support general purpose Condition's because there is no localization story and you'd be stuc k with, at best, MessageBox() behavior. Rather than provide that, Burn allows a BootstrapperApplication to handle all the UI. Thus there is the bal:Condition which is a condition construct supported by the wixstdba and that all comes with the BalExtension. On Fri, May 31, 2013 at 12:15 PM, Alain Forget <afor...@cmu.edu> wrote: I know that <Property Id="MSIFASTINSTALL" Value="1" /> in a <Product> will skip the restore point, but how can this also be done in a <Bundle>? In general, how do I set properties like that in a bootstrapper? lso, why can't elements like <Property> and <Condition> be used in a bootstrapper's <Bundle> the same way they are for a <Product> in a single MSI? Alain *************************************** Alain Forget, Ph.D. Postdoctoral Researcher CyLab, Carnegie Mellon University afor...@cmu.edu http://cups.cs.cmu.edu/~aforget/ *************************************** ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
