I was testing with per-machine bundles. When Bundle B upgraded Bundle A,
then Bundle A was removed from the per-machine cache. But the problem is
with the cache in the user's temp directory, and the original Bundle A is
on the user's desktop or some other easily accessible location.
On Tue, Jul 15, 2014 at 3:32 PM, Hoover, Jacob <jacob.hoo...@greenheck.com>
wrote:
> But the successful install of B should remove bundle A from the cache as
> it’s an upgrade not a patch. Is the install of B in your test not removing
> A?
>
>
>
> *From:* Sean Hall [mailto:r.sean.h...@gmail.com]
> *Sent:* Tuesday, July 15, 2014 3:24 PM
> *To:* WiX toolset developer mailing list
> *Subject:* Re: [WiX-devs] Wix 3.9: Bundle Self Updates
>
>
>
> That's not good enough. Here's what's happening. When the Bundle A's BA
> asks the engine to download the update (Bundle B), it always caches it in
> the same place: C:\Users\%username%\AppData\Local\Package
> Cache\{Bundle-A-Guid}. If the file is already in that location, then it
> assumes that it was already downloaded and doesn't download the new bundle.
> Bug 4472 shows that if you go on to update to Bundle B, run Bundle A
> again, and then try to update to Bundle C, that the engine will not
> download Bundle C and just run the .exe that was already downloaded (Bundle
> B).
>
>
>
> With 3.8 (and my pull request returns 3.9 to the 3.8 behavior), Bundle A
> tries to delete Bundle B from the user's Package Cache. In my testing and
> Phill's experience with his bundle, Bundle B does get deleted even if
> Bundle A's log shows that there was an error (my testing showed it was
> deleted without a reboot). With Jacob's committed change (and this new
> proposed change), Bundle A would not even try to delete Bundle B from the
> user's Package Cache. This causes Bug 4472. The downloaded bundle needs
> to be deleted, and this proposed change doesn't do that.
>
>
>
> On Tue, Jul 15, 2014 at 2:51 PM, Hoover, Jacob <jacob.hoo...@greenheck.com>
> wrote:
>
> That is only part of the fix, we also need to flag the pseudo bundle
> cacheType as BURN_CACHE_TYPE_YES. In my local testing, inside of
> EngineForApplication.cpp, in SetUpdate I added:
>
>
>
> // Prevent this package from being cleaned if we actually
> Plan an UpdateReplace.
>
> m_pEngineState->update.package.cacheType = BURN_CACHE_TYPE_YES;
>
>
>
> After PseudoBundleInitialize.
>
>
>
> Without this change, you will see bundle A’s cleanup trying to remove
> bundle B. If bundle B is a fast update and bundle A is slow to tear down,
> you would end up with a bundle installed but removed from the cache.
>
>
>
>
>
> *From:* Rob Mensching [mailto:r...@firegiant.com]
> *Sent:* Tuesday, July 15, 2014 2:21 PM
> *To:* WiX toolset developer mailing list
> *Subject:* Re: [WiX-devs] Wix 3.9: Bundle Self Updates
>
>
>
> What did you think of Sean’s change?
> https://github.com/wixtoolset/wix3/pull/110
>
>
>
>
>
> _______________________________________________________________
>
> FireGiant | Dedicated support for the WiX toolset |
> http://www.firegiant.com/
>
>
>
> *From:* Hoover, Jacob [mailto:jacob.hoo...@greenheck.com
> <jacob.hoo...@greenheck.com>]
> *Sent:* Tuesday, July 15, 2014 10:32 AM
> *To:* WiX toolset developer mailing list
> *Subject:* [WiX-devs] Wix 3.9: Bundle Self Updates
>
>
>
> Ref: http://wixtoolset.org/issues/4472/
>
>
>
> Rob/Bob,
>
> I’ve dug into this more, and I think the proper fix is to revert my
> change in PlanCleanPackage and modify the PsuedoBundle package to have a
> cacheType
> of yes. This should prevent the planned cleanup when the older bundle
> exits, and should eliminate the fallout I think I caused where the updated
> bundle isn’t cleaning up the out of date packages. My only question is
> should I make this the default behavior of PseudoBundleInitialize, or
> should SetUpdate modify the package after it’s been initialized.
>
>
>
>
>
> Thanks,
>
> Jacob
>
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
