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
