Thanks for the good feedback Don! My questions and comments inline, > Removal: It sounds like you are asking the removal of your app to remove > the prerequisites that the bootstrapper installed. Bootstrappers are not > designed to do this because it is a bad idea. Other programs may need > these prerequisites, including the PIA assemblies.
I did not mean uninstall would uninstall OS SPs or the framework, I agree that would not be a good idea. I just want uninstall to remove all application components (ie exe+interop dll), regardless if those components where installed at first install (primary scenario) or in a second "module" install according to the secondary scenario. > You could provide separate downloads for each installation. In this case, > your build process would build separate MSIs and would generate a separate > bootstrapper EXE for each partner. If at all possible, I would really want to keep the integrity of "one" app MSI, so professional organizations would use this same app MSI but without the bootstrapper. This would reduce the corp confusion and team maintenance pain of having multiple app MSIs. > A second alternative is to include customization dialogs as part of the > MSI that set properties based on the selected partners. This is what I want to do, but there might not have to be any dialogs. For a partner distribution these MSI properties should be filled in with partner specific values at some point (not by end user who has no clue, see below). During installation, these MSI properties are written to app.config (or similar). Pro customers can use msiexec to set these properties at will, or accept the default property values. My question for this scenario is rather my options in how to apply and set these properties and when. Would I have to apply a transform (?) or set them in some other way before the bootstrapper executes? If transform, can this be applied after building the boostrapper, or does it have to be before (CI/build issue). Or, maybe the bootstrapper itself can include the property values in play so all we have to have per partner is a different bootstrap exe (and the app MSI in distributed format can be identical for all customers and partners while avoiding transforms altogether)? As you can see, my knowledge of Windows Installer technology is a bit fuzzy on the whole transform thing and how to best combine it with what a bootstrapper can do in terms of customization and what it can carry in terms of usable payload. > The third alternative is to design this partner-specific customization > into the app itself, post-installation. There will of course have to be some new code in the app that knows what to do with these property values, which mostly has to do with how to connect to which servers and create user configuration information the first time the app starts. This is why some information must be provided before install time. The whole idea is for the customer to not have to fill in that fragile mumbo jumbo information manually. And in doing so get the user up and running as fast as possible by magic, while reducing customer service issues (due to fat fingers, confusion and whatnot). > Post-installation execution of Excel: The bootstrapper cannot really > handle this automatically because the bootstrapper does not run again > after the app is installed. In fact, the user may have deleted the > installation EXE once your app is installed. Your app should detect the > missing PIA scenario and initiate the PIA installation. Yeah, the app would of course have to have some code to shell to msiexec or just ask the user to install it and restart. The bootstrapper, at most, would put some sort of installation module/MSI-thingy on disk containing only the PIA packages and corresponding app DLLs based on Excel-version (or the URL to that thingy in app.config). My confusion here is not so much how a bootstrapper fits into this (or rather not) but more about what would be *best practice* for this kind of post install, extra MSI-module install scenario that does not fragment the main installation scenario into a big mess of sub-MSI-packages per Office version?? Here, I fall a little short in my knowledge about merge modules (?), how to combine pieces of one installation into another, etc. Any pointers would be appreciated. > I might also suggest not trying to bootstrap OS service packs Ok, seems reasonable. Thanks, we'll follow that advice. > Your users should know how to uninstall a program. Yes, you would think. I agree...! ;) Again, I appreciate the quality response Don. /Mathias ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
