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<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
https://lists.sourceforge.net/lists/listinfo/wix-devs

Reply via email to