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<mailto: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<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<mailto: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<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 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<mailto: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<mailto: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
