Without something like the bundle, the cached MSI is without its CABs ("Thank
You Windows Installer" for stripping the embedded cabs and for not storing the
external ones either) and thus Repair is broken unless the MSI is placed in
some protected area by its bootstrapper (which most don't do).
The bundle provided by burn supplies a cache external to Windows Installer for
the MSI with its CABs (which will only be cleaned if the bundle's ARP is used
instead of the MSIs, as pointed out by Rob).
Burn promotes usability on many levels (not withstanding the occasional error)
<smile/>.
Also, for most teams after picking baseline source code for their BA the UI is
easier to maintain for a bundle than it is for MSIs (another plus once you've
taken the initial cost).
Blair
> From: rhal...@hotmail.com
> To: wix-users@lists.sourceforge.net
> Date: Fri, 5 Jul 2013 19:04:16 -0500
> Subject: Re: [WiX-users] Removing bundle after installing MSI's
>
> I think what you're missing is that you're assuming every package in the
> chain has a user interface. My typical installer has my application MSI, and
> at least one prerequisite (i.e. .NET). I want the bootstrapper to silently
> install the prerequisites, and only show UI for the MSI. Once the
> bootstrapper has done its thing, there's no reason for it anymore. All
> modify/repair/uninstall logic is in the MSI, which should have been cached.
>
> Where is the logic to install the bundle? Could there be a PrerequisiteBA
> that performs this functionality, or would you have to modify the engine to
> do this?
>
> Sean
>
> > From: r...@robmensching.com
> > Date: Fri, 5 Jul 2013 14:04:28 -0700
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Removing bundle after installing MSI's
> >
> > 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
>
> ------------------------------------------------------------------------------
> 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
