I want to re-iterate what Blair said here.
The Burn engine does a whole lot of stuff to get your packages on the
machine correctly and get them off correctly. Caching the packages is a
very important part of that. If you don't register the Bundle as the ARP
entry there isn't anything to clean up the cache.
Now, you could mark the packages Cache='no' but then you're no better off
than using one of those other
fire-and-forget/disjoint-user-experience bootstrappers that won't help you
improve your install success rate. Burn wasn't designed to be that.
Note: With Burn and a custom BA that shows the MSI UI, you can get the
experience Sean Hall wants. However, I'd argue you want some UI while the
packages are downloaded/uncompressed, so you need some UI in the BA. There
is a thread about this and how I noted it was a reasonable feature request
but I wasn't interested in volunteering my time to write it. <smile/>
Finally, there are some powerful mechanisms you can use when the Bundle is
registered as well when it comes to related bundles. I appreciate that if
you many not be using any of the additional functionality, yet. However, I
hope you can see there are many reasons for the current design and how they
try to point you in the direction of a very robust installation experience.
That's what we're trying to do any way (delta bugs <smile/>).
On Sat, Jul 6, 2013 at 3:59 AM, Blair Murri <os...@live.com> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
