Hi Rob, Thanks for clearing up my confusion - I think I have a better understanding of how it works now, but I do have a couple of follow-up questions:
Re debugging, when you say that there are two processes if elevation is required, is this affected by whether UAC is enabled (it's not enabled on my box) or is it affected by whether the embedded packages are specified as PerMachine / ALLUSERS=2? Also, does bitness affect this at all, such as debugging a bootstrapper that contains x86 MSIs? 2. I thought it was probably the same mechanism, but all the examples I found basically used the same code. If setting the usual properties works in the same way as for the standard BA, then I think that would serve our needs. Thanks! John On 2 April 2013 14:30, Rob Mensching <r...@robmensching.com> wrote: > 1. Debugging - there are two *Bootstrapper Applications* (the .dlls that > get loaded by the engine to drive the user experience) but there is still > only one executable (one engine). If the managed BA cannot be loaded the > host tells the engine to fallback and load the "mbapreq" BA instead to get > NETFX installed. If that happens without a restart then the "mbapreq" says > to go load the managed BA. That all happens in the same process. > > 2. Debugging - you will see two executables running when elevation is > required. If you start the process elevated, you'll immediately see the > user mode process executable get created. *That* makes debugging harder but > if you debug from an unelevated process debugging is very straight forward. > > 3. Customize - the "mbapreq" is just the "wixstdba" with a tiny bit of > different internal logic (like "reload mba host" when complete instead of > "close when complete"). That means all the customizations you can do to > wixstdba, you can do to the mbapreq. > > > On Tue, Apr 2, 2013 at 4:08 AM, John Ludlow <john.ludlow...@gmail.com > >wrote: > > > Forgot to mention - I'm using WiX 3.6 > > > > > > On 2 April 2013 11:59, John Ludlow <john.ludlow...@gmail.com> wrote: > > > > > Hi, > > > > > > I've been looking at developing a custom managed bootstrapper > > application, > > > based on the examples in the following articles: > > > > > > > > > > > > http://wrightthisblog.blogspot.co.uk/2013/01/part-1-of-writing-your-own-net-based.html > > > > > > > > > > > > http://bryanpjohnston.com/2012/09/28/custom-wix-managed-bootstrapper-application/ > > > > > > > > > > > > http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx > > > > > > These seem to use the ManagedBootstrapperApplicationHost, which does a > > few > > > things around checking for and installing .NET. I'd like to know if I > can > > > customize this behaviour (or perhaps even remove it). > > > > > > My understanding of how this works is that there are actually two > > > bootstrappers - an unmanaged one which checks for .NET, and installs it > > if > > > necessary (but is generally hidden from the developer), and a managed > one > > > which is the actual install. This has caused some concerns amongst our > > > team. > > > > > > One of these concerns was the slightly more painful debugging > experience, > > > because the process which would get launched is not the 'real' process > > > which we want to debug. There are tricks you can use (Heath Stewart > > > described a way of setting up Global Flags to first break into the > first > > > one, F5 to continue, then break into the managed code) but it seemed > like > > > it would be simpler if the bootstrapper project could just kick out the > > > managed bootstrapper output on its own without the unmanaged > bootstrapper > > > getting in the way (at least for debugging purposes). > > > > > > The second concern was whether we can customize the unmanaged > > bootstrapper > > > at all, changing the logo, descriptive text, and perhaps also changing > > the > > > action to show an error rather than installing .NET automatically. > > > > > > Are these things possible? I was thinking that we could build a > WixStdBA > > > bootstrapper which calls our managed bootstrapper. > > > > > > Thanks > > > > > > John > > > > > > > > ------------------------------------------------------------------------------ > > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > > Rise to greatness in Intel's independent game demo contest. Compete > > for recognition, cash, and the chance to get your game on Steam. > > $5K grand prize plus 10 genre and skill prizes. Submit your demo > > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
