I don't understand the reasoning here "I''m unwilling at this point to let the bundle take over the handling of the MSI". What is the real difference between having the Bundle registered as the ARP entry vs. the MSI registered as the ARP entry?
Random note: Burn will clean up the package cache during uninstall, one more reason (that just came to mind) it should be the ARP entry. To address your question, "what do we do about MSI's that require user input?" - you interact with the user in the Bundle and pass the results to the MsiPackage via the MsiProperty element. This does require moving your user interaction out of the MSI into the BA so it takes dev work. As noted in the blog entry, The goal for Burn is to provide is a unified user experience for installation. You'll fight Burn if you truly desire a disjointed installation experience. Now, I have yet to have anyone describe a scenario where their ultimate goal is to provide users a installation experience where multiple things pop up such that users must interact with the install multiple times as it progresses. I've certainly never seen such an experience test well with users. User's want to click "Install" then see "Success!" with as little time and interaction as possible. That said, sometimes all you have time to develop is a disjoint user experience. If so, you can get that if you treat the Bundle as the "main MSI" and hide the "main MSI" ARP entry. Alternatively you can use a different bootstrapper. There are plenty of bootstrappers out there that provide disjoint user experiences for installation. Burn exists because nothing provided the seamless user experience user's wanted. This comes up enough that I feel like I'm missing something. On Fri, Jul 5, 2013 at 6:15 AM, Miller, Bill (QuickWire) < bmil...@quickwire.com> wrote: > I was faced with the same dilemma. I wanted to simply use the bundle to > pave the way for my main MSI. > As it is I've set the Permanent & Visible attribute of all the Package > elements in the bundle to "yes". > Thus when the bundle is finished it has an entry in the ARP but > uninstalling it essentially does nothing. > > However, we both don't want this. Here is an entry from Rob Mensching's > blog that sums up what he thinks about bundles. > > http://robmensching.com/blog/posts/2012/6/25/b-is-for-bundle-and-thats-good-enough-for-me > > It makes sense, but what do we do about MSI's that require user input? > My MSI requires an alternate install location so I need to use its > interface. I'm unwilling at this point to let the bundle take over the > handling of the MSI - by setting Permanent & Visible to 'no' (as the issue > I'm now having as seen in my previous msg) > I suppose if I did then there would simply be one entry in the ARP and > life would be better (like a beer commercial). > > So I'm on the fence right now about bundles myself. > > Bill > > > -----Original Message----- > From: James McConville [mailto:james.mcconvi...@orbussoftware.com] > Sent: Friday, July 5, 2013 5:39 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Removing bundle after installing MSI's > > Hello all, > > Need to find out if this is possible or if I've completely missed the > point of Bundles. > > Is it possible to remove all traces of the bundle after installation, not > just hide it. > > Essentially I want to use the bundle purely as a delivery method for the > app and its dependent apps (which I want to leave alone if I remove the > msi). > > Is it possible to do this or should I be looking at another solution? > > Thanks for your help! > James. > > > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
