Bundle update behavior, ignores latest downloadable bundle in favor of cached bundle.

[wixbot]

This behavior change was observed after upgrading from Wix 3.8.1128 to 3.9.702. I have confirmed that this behavior does not exist in 3.8.1128 by reverting and testing various failure modes.

The general design a Bundle using a mba, which implements the Update/@location functionality, in a manner similar to wixtoolset src/Setup/WixBA. This bundle has Bundle/@ProviderKey defined but that does not seem to be related to the issue, because the behavior is observed when that attribute is removed.. This Bundle also has RelatedBundle, detect, defined (although a bundle with the Id has not been created yet). The issue exists even when ReleatedBundle element is removed. The Bundle has multiple packages which are also not compressed and downloadable from the web site. I have multiple products which follow this same general outline and all products exhibit the reported behavior after upgrading the tools to 3.9.702.

Steps to Reporduce:
There are multiple paths to reproduce this issues. A user will copy Bundle.exe A to a local folder on target system. The issues is observed after several MajorUpdate, compliant builds are created and posted to the web site. The atom feed only provides information about the latest build posted to the web site. The user may have 'updated' to each build as announced or may skip announcements, but in 3.8 when Bundle.exe A is launched it detects the latest bundle announced on the web site and restarts the Bundle using that version (say D, where B and C were intermediate builds.). For Wix 3.9.702 when Bundle A is launched it detects Bundle D, and marks it to be Downloaded, and puts Burn in Update_Replace mode. OnResolveSource gets called with the correct download path for Bundle D, however the acquired bundle is an intermediate build, Bundle.exe B, which is launched (and Bundle A is terminated).

The user must press 'Update Available' again (when again Bundle D is detected), yet the acquired and restarted bundle will now be Bundle C. The user must repeat this process again to run Bundle D.

If Bundle D is installed, and at a later time the user launches Bundle A, the user must repeat the above steps, for each intermediate build, before the Bundle D maintenance options of Uninstall or Repair are displayed.

This thread includes posted logs:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-td7595761.html

I tried to create a simple demo package, but I am not sure how to approach that given the use of a remote web site to host the downloads. Please let me know if more information would be helpful.

Originally opened by phogland

[wixbot]

From: Sean Hall
Sent: Sunday, July 13, 2014 11:57 AM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

I've tracked this down to Jacob's change to plan.cpp https://github.com/wixtoolset/wix3/pull/29/files#diff-6, where he made it so that the downloaded bundle isn't cleaned from the cache. Do you remember why you changed this Jacob?

Originally posted by jchoover

[wixbot]

If I revert that one line change, in my test BA I am seeing:

Unable to remove cached package: {4c8dcf61-GUID}, from path: C:\Users\hoover\AppData\Local\Package Cache{4c8dcf61-GUID}, reason: 0x80070020. Continuing...

The execution of the updated bundle is done async, and after the update is invoked the cached package is locked because it's running so the original bundle can't clean it. I also still see both packages in the local package cache after the updated bundle completed.

I think the right way for this to work is for the updated bundle to plan the cleaning of the outdated bundle upon successful completion of the upgrade.

Originally posted by jchoover

[wixbot]

After reverting that line I also see that error, but after the upgrade bundle exits it is deleted. The C:\Users%username%\AppData\Local\Package Cache{Original-Bundle-Guid} folder still exists, but it's empty. This error was also seen in 3.8.1128 and this bug didn't exist, so I think it should be reverted.

Originally posted by rseanhall

[wixbot]

I finally got a debug environment working (sorry for being so slow at picking up some of this stuff, I don't think I did the GitHub clone step properly but I got the project to build. I am stepping into Burn. Should I post comments here or over in the wix-users forum?)

I setup the scenario where there is a newer build of the bundle on the web server, and it was detected in DetectUpdateCompete. As I step into OnResolveSource, in AcquireContainerOrPayload (ln apply.cpp line 1127) I don't see how fDownload is ever true. At the same time I am wondering if I am causing this problem in OnResolveSource by calling Engine.SetDownloadSource with the url to the bundle. The UpdateViewModle already called Engine.SetUpdate. In ResolveSource I am trying to point the Url for certain payloads to a different web site at run time, however ResolveSource is also called with the correct Url for the bundle. At apply.cpp line 1101 fDownload is initialized to FALSE and I don't see stepping through the code where it is ever set TRUE prior to line 1127.

Originally posted by phogland

[wixbot]

I take that back, I see where PromptForSource should get Result.Download which is returned from OnResolveSource.

Originally posted by phogland

[wixbot]

AssignedTo set to shall
Resolution set to fixed
Status changed from Untriaged to Resolved