You're welcome to use the rarely-active IRC channel :) http://webchat.freenode.net/?channels=%23wix
2014-07-15 20:14 GMT-03:00 Hoover, Jacob <jacob.hoo...@greenheck.com>: > It's times like this I wish I could call an impromptu meeting w/ Rob, Bob, > and Sean... > > > On Jul 15, 2014, at 4:32 PM, "Sean Hall" <r.sean.h...@gmail.com> wrote: > > Sorry, per-user cache not temp directory. > > > On Tue, Jul 15, 2014 at 4:19 PM, Hoover, Jacob <jacob.hoo...@greenheck.com> > wrote: >> >> Users temp directory or the Per-User package cache? Is this a custom BA, >> or the user is just executing bundle A again? >> >> >> >> On my testing VM: >> >> >> >> Install Bundle A: >> >> A is cached in the Per-Machine package Cache. >> >> Nothing is left in the per-user cache >> >> >> >> <Create and Delpoy B> >> >> >> >> Run BA, Check for Updates, Install Bundle B: >> >> A is removed from Per-Machine package Cache >> >> B is cached in the Per-Machine package cache >> >> Nothing is left in the per-user cache >> >> >> >> <Create and Delpoy C> >> >> >> >> Run BA, Check for Updates, Install Bundle C: >> >> B is removed from Per-Machine package Cache >> >> C is cached in the Per-Machine package cache >> >> C is left in the per-user cache… Hmm…. >> >> >> >> I’m going to do a bit more digging. >> >> >> >> >> >> From: Sean Hall [mailto:r.sean.h...@gmail.com] >> Sent: Tuesday, July 15, 2014 3:37 PM >> To: WiX toolset developer mailing list >> Subject: Re: [WiX-devs] Wix 3.9: Bundle Self Updates >> >> >> >> 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] >> 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 ac ------------------------------------------------------------------------------ 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
