3.9.702 Bundle update behavior

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

3.9.702 Bundle update behavior

Phill Hogland
I upgraded from 3.8.1128 to 3.9.702 a few days ago, and I am observing a change in behavior in the why my bundles are updated.  (I am aware that there are new features in 3.9 related to bundle updating, but was not expecting this behavior change.  At the same time I did not revert my build system back to 3.8 and validate that this observation is related to upgrading the wix tools.)

Previously I would create a new build of my bundle and post the build to my web host site, with the external packages, and an atom feed file, similar to the implementation in the Wix toolset setup.  IF the user ran an older build, the mba/engine checks the atom feed url, and if a newer build is detected the 'Update Available' button is presented.  The user clicks the button and the remote bundle is downloaded and started moving from say build 1.0.5 to 1.0.10  (even if previously I had launched 1.0.5 and installed an then uninstalled 1.0.7 prior to creating the 1.0.10 build).  Also the bundle seemed to be cached in a folder under c:\ProgramData.

Now when the user runs 1.0.5  (with no packages cached in ProgramData, or the local setup folder), 'Update Available' is presented and when clicked, the bundle then runs 1.0.6 and presents 'Update Available' again.  The user clicks and it runs 1.0.7 and presents 'Update Available' again, etc marching up to the latest which it finally downloads from the web site.   It seems to have ached these files under the user's ..\AppData\Local\Package Cache\.

So is this the expected desired behavior to present the older bundles first before getting the build that I posted to the web site?

Is there a code change I can implement (in my mba?) to get back to the behavior where it gets the latest bundle I posted to the web site?

Thanks.  Phill
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
Hmm, what does your detect sequence look like in your MBA?

Did you implement
  OnDetectUpdateBegin, OnDetectUpdate, OnDetectUpdateComplete?

In OnDetectUpdateBegin are you:
        Returning a recommendation of IDOK (not certain of the managed equivalence of this is)?

In OnDetectUpdate, are you (if you found an update):
        Calling Engine->SetUpdate
        Setting the launch action to UpdateReplace?
        Returning a recommendation of IDOK?


-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Thursday, July 10, 2014 2:51 PM
To: [hidden email]
Subject: [WiX-users] 3.9.702 Bundle update behavior

I upgraded from 3.8.1128 to 3.9.702 a few days ago, and I am observing a change in behavior in the why my bundles are updated.  (I am aware that there are new features in 3.9 related to bundle updating, but was not expecting this behavior change.  At the same time I did not revert my build system back to 3.8 and validate that this observation is related to upgrading the wix tools.)

Previously I would create a new build of my bundle and post the build to my web host site, with the external packages, and an atom feed file, similar to the implementation in the Wix toolset setup.  IF the user ran an older build, the mba/engine checks the atom feed url, and if a newer build is detected the 'Update Available' button is presented.  The user clicks the button and the remote bundle is downloaded and started moving from say build
1.0.5 to 1.0.10  (even if previously I had launched 1.0.5 and installed an then uninstalled 1.0.7 prior to creating the 1.0.10 build).  Also the bundle seemed to be cached in a folder under c:\ProgramData.

Now when the user runs 1.0.5  (with no packages cached in ProgramData, or the local setup folder), 'Update Available' is presented and when clicked, the bundle then runs 1.0.6 and presents 'Update Available' again.  The user clicks and it runs 1.0.7 and presents 'Update Available' again, etc marching
up to the latest which it finally downloads from the web site.   It seems to
have ached these files under the user's ..\AppData\Local\Package Cache\.

So is this the expected desired behavior to present the older bundles first before getting the build that I posted to the web site?

Is there a code change I can implement (in my mba?) to get back to the behavior where it gets the latest bundle I posted to the web site?

Thanks.  Phill



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
Note, it may be just the ordering of your updates in the feed.  I don't think there is anything preventing you from caching the newest update in your MBA (after each OnDetectUpdate call, just don't return IDOK which aborts the looping through the updates), and then in OnDetectUpdateComplete doing the SetUpdate call along with setting the launch action (Not certain if the action is required, as I don't have my PC rebuilt yet).

-----Original Message-----
From: Hoover, Jacob [mailto:[hidden email]]
Sent: Thursday, July 10, 2014 3:30 PM
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

Hmm, what does your detect sequence look like in your MBA?

Did you implement
  OnDetectUpdateBegin, OnDetectUpdate, OnDetectUpdateComplete?

In OnDetectUpdateBegin are you:
        Returning a recommendation of IDOK (not certain of the managed equivalence of this is)?

In OnDetectUpdate, are you (if you found an update):
        Calling Engine->SetUpdate
        Setting the launch action to UpdateReplace?
        Returning a recommendation of IDOK?


-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Thursday, July 10, 2014 2:51 PM
To: [hidden email]
Subject: [WiX-users] 3.9.702 Bundle update behavior

I upgraded from 3.8.1128 to 3.9.702 a few days ago, and I am observing a change in behavior in the why my bundles are updated.  (I am aware that there are new features in 3.9 related to bundle updating, but was not expecting this behavior change.  At the same time I did not revert my build system back to 3.8 and validate that this observation is related to upgrading the wix tools.)

Previously I would create a new build of my bundle and post the build to my web host site, with the external packages, and an atom feed file, similar to the implementation in the Wix toolset setup.  IF the user ran an older build, the mba/engine checks the atom feed url, and if a newer build is detected the 'Update Available' button is presented.  The user clicks the button and the remote bundle is downloaded and started moving from say build
1.0.5 to 1.0.10  (even if previously I had launched 1.0.5 and installed an then uninstalled 1.0.7 prior to creating the 1.0.10 build).  Also the bundle seemed to be cached in a folder under c:\ProgramData.

Now when the user runs 1.0.5  (with no packages cached in ProgramData, or the local setup folder), 'Update Available' is presented and when clicked, the bundle then runs 1.0.6 and presents 'Update Available' again.  The user clicks and it runs 1.0.7 and presents 'Update Available' again, etc marching
up to the latest which it finally downloads from the web site.   It seems to
have ached these files under the user's ..\AppData\Local\Package Cache\.

So is this the expected desired behavior to present the older bundles first before getting the build that I posted to the web site?

Is there a code change I can implement (in my mba?) to get back to the behavior where it gets the latest bundle I posted to the web site?

Thanks.  Phill



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
In reply to this post by Hoover, Jacob
My mba which has been working in this regard for about a year, is based on the Wix toolset Setup\WixBA\UpdateViewModel code which implements DetectUpdateBegin and DetectComplete.  Some time ago I added some customization to these handlers to allow our build process to place builds into a dev, test, and live area, and allow the mba to detect whether the setup is running on a marked dev or test system and get builds from those staging areas.  But those changes have also been working prior to seeing this new behavior.

DetectUpdateBegin spawns worker_DoWork which calls Engine.SetUpdate and return codes.  This code is the same as in the wix toolset source.

My atom feed document is generated at build time and I only include information for the one build that I intend to post to the web site, so it surprised me that the other intermediate bundles (other than the one the user launched) were still around on the local system to be reused.
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
Ahh, so you are doing your own downloading of the atom feed.  In 3.9, the engine will download the feed automatically if IDOK is returned from OnDetectUpdateBegin and there is an <Update /> element in the BA's manifest.  It is possible that the changes I made to the engine are triggering an unintended side effect, but I can't see a clear path for how it could happen.

In DetectUpdateBegin, are you doing anything to the result?  IE, are you modifying e.Result?  It should default to IDNOACTION, but if you returned IDOK then the engine would attempt to download and parse your Atom feed for you, and notify your BA of what it finds for updates via a series of callbacks to OnDetectUpdate. If you aren't modifying e.Result, then the changes I implemented in the engine should not impact you.

A snip from the WixBA:

                   SyndicationFeed feed;
                    using (XmlReader reader = XmlReader.Create(response.GetResponseStream()))
                    {
                        feed = SyndicationFeed.Load(reader);
                    }

                    var updates = from entry in feed.Items
                                  from link in entry.Links
                                  from extension in entry.ElementExtensions
                                  where String.Equals(link.RelationshipType, "enclosure", StringComparison.Ordinal) &&
                                        String.Equals(extension.OuterNamespace, this.AppSyndicationNamespace, StringComparison.Ordinal) &&
                                        String.Equals(extension.OuterName, "version", StringComparison.Ordinal)
                                  select new Update()
                                  {
                                      Url = link.Uri.AbsoluteUri,
                                      Size = link.Length,
                                      Version = new Version(extension.GetObject<string>())
                                  };

                    Update update = updates.Where(u => u.Version > WixBA.Model.Version).OrderByDescending(u => u.Version).FirstOrDefault();
                    if (update == null)
                    {
                        WixBA.Model.Engine.SetUpdate(null, null, 0, UpdateHashType.None, null);
                        this.State = UpdateState.Current;
                    }
                    else
                    {
                        WixBA.Model.Engine.SetUpdate(null, update.Url, update.Size, UpdateHashType.None, null);
                        this.State = UpdateState.Available;
                    }


Is it getting the right update from " Update update = updates.Where(u => u.Version > WixBA.Model.Version).OrderByDescending(u => u.Version).FirstOrDefault(); " ?

What values are you passing to SetUpdate? IE, are you passing the incremental update, or the largest update?
-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Thursday, July 10, 2014 4:07 PM
To: [hidden email]
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

My mba which has been working in this regard for about a year, is based on the Wix toolset Setup\WixBA\UpdateViewModel code which implements DetectUpdateBegin and DetectComplete.  Some time ago I added some customization to these handlers to allow our build process to place builds into a dev, test, and live area, and allow the mba to detect whether the setup is running on a marked dev or test system and get builds from those staging areas.  But those changes have also been working prior to seeing this new behavior.

DetectUpdateBegin spawns worker_DoWork which calls Engine.SetUpdate and return codes.  This code is the same as in the wix toolset source.

My atom feed document is generated at build time and I only include information for the one build that I intend to post to the web site, so it surprised me that the other intermediate bundles (other than the one the user launched) were still around on the local system to be reused.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595765.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
Jacob, thanks for all of the information.

My code is exactly the same as the snippet that you posted (except I added a couple of calls to Engine.Log to see what the Url is that was passed to Engine.Setup.)  I thought that this code snippet related to parsing the atom feed for multiple entries, however my atom feed only ever has the one (latest) entry.   (Someday I may provide information on multiple versions in my feed, but right now I generate the atom feed document at build time with only the information for that particular build.)

In my experiments yesterday I found on the test box, under user's ..\AppData\Local\Package Cache\.  This is where the Bundle was getting the intermediate versions of the Bundle on each click of 'Update Available'.  So I deleted that tree and then the 'Update Available' resulted in getting the version of the Bundle that I had posted to the web site.

I had not noticed the ..\AppData\Local\Package Cache\  behavior before, and since I deleted it, I now need to go through the process of creating and installing multiple builds to get back to that behavior and investigate your questions more carefully.  (I should have renamed that folder tree rather than just deleting it.)

So thanks for the info.  I think the issue is related to ..\AppData\Local\Package Cache\ in some way and I will try to collect more information.

Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
A related behavior that I am observing is that when a Bundle is installed on a system, it is being cached under both:
C\ProgramData\Package Cache\<guid>
<path to user's profile>\AppData\Local\Package Cache\<different guid>

When a bundle is "completely" Uninstalled, the entries under C:\ProgramData are removed, but the entries under ..\AppData\Local\Package Cache\ persist.  So the next time the bundle is launched it seems to run from this location first prior to using any other location.

I am adding more logging statements to my mba to collect more information.

Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
Is the concern with the leftover bundle in the user specific package cache, or is the concern with the incremental upgrades instead of taking the largest leap possible?

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Friday, July 11, 2014 8:00 AM
To: [hidden email]
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

A related behavior that I am observing is that when a Bundle is installed on a system, it is being cached under both:
C\ProgramData\Package Cache\<guid>
<path to user's profile>\AppData\Local\Package Cache\<different guid>

When a bundle is "completely" Uninstalled, the entries under C:\ProgramData are removed, but the entries under ..\AppData\Local\Package Cache\ persist.
So the next time the bundle is launched it seems to run from this location first prior to using any other location.

I am adding more logging statements to my mba to collect more information.





--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595774.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
My concern is with "incremental upgrades instead of taking the largest leap possible", which as I investigate seems to be related to the leftover bundle in the user specific package cache.

When a user launches Bundle.exe 1.05 (and if 1.0.10 is available on the web site, but if intermediate bundles were ever installed) then they have to press the 'Update Available' button multiple times to march through each cached intermediate bundle to get to the latest update.

Also if they do the above (so the latest, 1.0.10 is installed) and if they launch 1.0.5 Bundle.exe again (say to uninstall) the uninstall and repair buttons are hidden until they update to the latest.  (This is the same behavior as the Wix toolset installer).  However now the user must click on the 'Update Available' multiple times to march through the cached bundles, before they get to the installed version, and the Uninstall or Repair buttons are displayed.
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
So if you have bundels A,B,C, and D, where A is the installed version of 1.0.1.0, and B->D are 1.0.2.0->1.0.4.0, you are seeing a behavior where if A is installed and B was cached previously, that when going to ARP and selecting modify that the update check invokes B instead of downloading D?

Are you using a single feed, such that A knows about D, or do you have a chain of feeds?

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Friday, July 11, 2014 8:29 AM
To: [hidden email]
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

My concern is with "incremental upgrades instead of taking the largest leap possible", which as I investigate seems to be related to the leftover bundle in the user specific package cache.

When a user launches Bundle.exe 1.05 (and if 1.0.10 is available on the web site, but if intermediate bundles were ever installed) then they have to press the 'Update Available' button multiple times to march through each cached intermediate bundle to get to the latest update.

Also if they do the above (so the latest, 1.0.10 is installed) and if they launch 1.0.5 Bundle.exe again (say to uninstall) the uninstall and repair buttons are hidden until they update to the latest.  (This is the same behavior as the Wix toolset installer).  However now the user must click on the 'Update Available' multiple times to march through the cached bundles, before they get to the installed version, and the Uninstall or Repair buttons are displayed.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595782.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
>>>you are seeing a behaviour where if A is installed and B was cached previously, that when going to ARP and selecting modify that the update check invokes B instead of downloading D?

If the user goes to ARP and D is already installed, then D is launched.

However if the user does not use ARP, but rather launches the Bundle.exe (version A) which he downloaded to his desktop (or somewhere), then it detects from the atom at the Update/@Location that an update is available.  The atom only describes D.   Then clicks on 'Update Available' and the bundles launches a cached (previously installed and uninstalled or upgraded) Bundle B.  The user must repeat this process to get to D, whether the user intends to Uninstall or Repair D, (or if an newer version is on the web site to update to the newer version).

I think the behavior is related to InstallationViewModel::ResolveSource, similar to the WixBA
            this.downloadRetries.TryGetValue(e.PackageOrContainerId, out retries);
            this.downloadRetries[e.PackageOrContainerId] = retries + 1;

            e.Result = retries < 3 && !String.IsNullOrEmpty(downloadUrl) ? Result.Download : Result.Ok;

The following snippets from verbose logs describe the situation where Bundle A is launched, Bundle D has already been installed.  (Why, because the user has Bundle A at a convenient location and wants to either run maintenance on the installed Bundle D or get the latest version from the download site.)

Bundle A:
[089C:0AA4][2014-07-11T08:48:15]i001: Burn v3.9.702.0, Windows v6.2 (Build 9200: Service Pack 0), path: D:\product\product.exe, cmdline: '--l=*v'
...
[089C:0A5C][2014-07-11T08:48:15]i000: Checking for an 'update' at: http://www.company.com/product/v1.0/feed/index.html.
[089C:0A5C][2014-07-11T08:48:21]i000: Called SetUpdate with URL: http://www.company.com/product/v1.0/release/product.exe, Size: 1210192.
[089C:0AA4][2014-07-11T08:48:26]i200: Plan begin, 10 packages, action: UpdateReplace
[089C:0AA4][2014-07-11T08:48:26]w321: Skipping dependency registration on package with no dependency providers: {a7bb9_guid}
[089C:0AA4][2014-07-11T08:48:26]i211: Planned upgrade bundle: {a7bb9_guid}, default requested: Present, ba requested: Present, execute: Install, rollback: None, dependency: None
[089C:0AA4][2014-07-11T08:48:26]i299: Plan complete, result: 0x0
[089C:0AA4][2014-07-11T08:48:26]i300: Apply begin
[089C:02B4][2014-07-11T08:48:26]w343: Prompt for source of package: {a7bb9_guid}, payload: {a7bb9_guid}, path: D:\product\update\product.exe
[089C:02B4][2014-07-11T08:48:26]i338: Acquiring package: {a7bb9_guid}, payload: {a7bb9_guid}, download from: http://www.company.com/product/v1.0/release/product.exe
[089C:02B4][2014-07-11T08:48:26]i304: Verified existing payload: {a7bb9_guid} at path: C:\Users\this.user\AppData\Local\Package Cache\{a7bb9_guid}\product.exe.
[089C:0AA4][2014-07-11T08:48:26]i301: Applying execute package: {a7bb9_guid}, action: Install, path: C:\Users\this.user\AppData\Local\Package Cache\{a7bb9_guid}\product.exe, arguments: '"C:\Users\this.user\AppData\Local\Package Cache\{a7bb9_guid}\product.exe"  --l=*v -burn.related.update'
[089C:0AA4][2014-07-11T08:48:27]i319: Applied execute package: {a7bb9_guid}, result: 0x0, restart: None
[089C:0AA4][2014-07-11T08:48:27]i000: Automatically closing the window since updated bundle should be running.

In the above the user pressed 'Update Available' and now Bundle B is running (Bundle D was expected)
[09E8:03EC][2014-07-11T08:48:26]i001: Burn v3.9.702.0, Windows v6.2 (Build 9200: Service Pack 0), path: C:\Users\this.user\AppData\Local\Package Cache\{a7bb9_guid}\product.exe, cmdline: '--l=*v -burn.related.update'
[09E8:03EC][2014-07-11T08:48:26]i003: This bundle is being run by a related bundle as type 'Update'.
...
[09E8:03EC][2014-07-11T08:48:27]i107: Detected forward compatible bundle: {f8ce2b_guid}, type: Upgrade, scope: PerMachine, version: 1.0.17.0, enabled: No
[09E8:03EC][2014-07-11T08:48:27]i102: Detected related bundle: {f8ce2b_guid}, type: Upgrade, scope: PerMachine, version: 1.0.17.0, operation: Downgrade
...
[09E8:03EC][2014-07-11T08:48:27]i103: Detected related package: {37EA28_guid}, scope: PerMachine, version: 1.0.436.0, language: 0 operation: Downgrade
[09E8:03EC][2014-07-11T08:48:27]i103: Detected related package: {37B8B5E_guid}, scope: PerMachine, version: 1.0.381.0, language: 0 operation: Downgrade
...
[09E8:0B80][2014-07-11T08:48:27]i000: Checking for an 'update' at: http://www.company.com/product/v1.0/feed/index.html.
[09E8:03EC][2014-07-11T08:48:27]i000: Setting string variable 'svCDDTransform' to value '1033.mst'
[09E8:03EC][2014-07-11T08:48:27]i199: Detect complete, result: 0x0
[09E8:0B80][2014-07-11T08:48:27]i000: Called SetUpdate with URL: http://www.company.com/product/v1.0/release/product.exe, Size: 1210192.
[09E8:03EC][2014-07-11T08:48:31]i200: Plan begin, 12 packages, action: UpdateReplace
[09E8:03EC][2014-07-11T08:48:31]w321: Skipping dependency registration on package with no dependency providers: {d494a8_guid}
[09E8:03EC][2014-07-11T08:48:31]i211: Planned upgrade bundle: {d494a8_guid}, default requested: Present, ba requested: Present, execute: Install, rollback: None, dependency: None
[09E8:03EC][2014-07-11T08:48:31]i299: Plan complete, result: 0x0
[09E8:03EC][2014-07-11T08:48:31]i300: Apply begin
[09E8:0B28][2014-07-11T08:48:31]w343: Prompt for source of package: {d494a8_guid}, payload: {d494a8_guid}, path: C:\Users\this.user\AppData\Local\Package Cache\{a7bb9_guid}\update\product.exe
[09E8:0B28][2014-07-11T08:48:31]i338: Acquiring package: {d494a8_guid}, payload: {d494a8_guid}, download from: http://www.company.com/product/v1.0/release/product.exe
[09E8:0B28][2014-07-11T08:48:31]i304: Verified existing payload: {d494a8_guid} at path: C:\Users\this.user\AppData\Local\Package Cache\{d494a8_guid}\product.exe.
[09E8:03EC][2014-07-11T08:48:31]i301: Applying execute package: {d494a8_guid}, action: Install, path: C:\Users\this.user\AppData\Local\Package Cache\{d494a8_guid}\product.exe, arguments: '"C:\Users\this.user\AppData\Local\Package Cache\{d494a8_guid}\product.exe"  --l=*v -burn.related.update'
[09E8:03EC][2014-07-11T08:48:31]i319: Applied execute package: {d494a8_guid}, result: 0x0, restart: None
[09E8:03EC][2014-07-11T08:48:31]i000: Automatically closing the window since updated bundle should be running.

Bundle C is not running.  Do the above again to get to the next bundle, etc.  Finally get to:
[0888:0224][2014-07-11T08:48:33]i001: Burn v3.9.702.0, Windows v6.2 (Build 9200: Service Pack 0), path: C:\Users\this.user\AppData\Local\Package Cache\{cfe7da2f-4698-4bb0-bf50-c5f12ec3c6ed}\product.exe, cmdline: '--l=*v -burn.related.update'
[0888:0224][2014-07-11T08:48:33]i003: This bundle is being run by a related bundle as type 'Update'.
[0888:0224][2014-07-11T08:48:33]i103: Detected related package: {37EA28_guid}, scope: PerMachine, version: 1.0.436.0, language: 0 operation: Downgrade
[0888:0224][2014-07-11T08:48:33]i103: Detected related package: {37B8B5E_guid}, scope: PerMachine, version: 1.0.381.0, language: 0 operation: Downgrade
[0888:0F48][2014-07-11T08:48:33]i000: Checking for an 'update' at: http://www.Company.com/product/v1.0/feed/index.html.
[0888:0F48][2014-07-11T08:48:33]i000: Called SetUpdate with URL: http://www.Company.com/product/v1.0/release/product.exe, Size: 1210192.

I'm still researching this issue and appreciate any insights.
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
After adding more logging statements that information is the same as above but confirms that the DetectUpdateBegin and worker_DoWork detect the latest version (on the web site if available).

But apparently prior to that event, when there are intermediate versions cached locally (meaning a version that is higher than the exe that was launched, but not the latest (either installed or available for download),  the DetectRelatedBundle is detecting the intermediate versions of the same bundle if they were ever run on this machine.

The log entry notes the version and says Operation:Downgrade.

The related code is at Line 157 of wix39_702\src\burn\engine\detect.cpp

I don't quite understand why if the running exe is A, and the detected "related bundle" (which is really a MajorUpgrade of the same bundle) is B, (and the available update from Update/@Location is C), why is marking B as a 'downgrade' to A, and then launching Bundle B as an 'update' rather than launching Bundle C?

Still digging.

Also for clarification I do not have any 'related' bundles (as I understood related bundle), but I do define the following, so that in the future after this bundle is released I will be able to create another Bundle to deploy patches or updates.  Generally I hope to only deploy MajorUpgrade of this bundle, but reality will probably force me to create a patch and deploy it as a separate but related bundle.  I read somewhere that I should plan for that event in this manner.
In Bundle (of product.exe)
    <RelatedBundle Action='Detect' Id='$(var.product_RelatedBundleCode)' />
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
So A->D all have the same RelatedBundle GUID?

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Friday, July 11, 2014 11:05 AM
To: [hidden email]
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

After adding more logging statements that information is the same as above but confirms that the DetectUpdateBegin and worker_DoWork detect the latest version (on the web site if available).

But apparently prior to that event, when there are intermediate versions cached locally (meaning a version that is higher than the exe that was launched, but not the latest (either installed or available for download), the DetectRelatedBundle is detecting the intermediate versions of the same bundle if they were ever run on this machine.

The log entry notes the version and says Operation:Downgrade.

The related code is at Line 157 of wix39_702\src\burn\engine\detect.cpp

I don't quite understand why if the running exe is A, and the detected "related bundle" (which is really a MajorUpgrade of the same bundle) is B, (and the available update from Update/@Location is C), why is marking B as a 'downgrade' to A, and then launching Bundle B as an 'update' rather than launching Bundle C?

Still digging.

Also for clarification I do not have any 'related' bundles (as I understood related bundle), but I do define the following, so that in the future after this bundle is released I will be able to create another Bundle to deploy patches or updates.  Generally I hope to only deploy MajorUpgrade of this bundle, but reality will probably force me to create a patch and deploy it as a separate but related bundle.  I read somewhere that I should plan for that event in this manner.
In Bundle (of product.exe)
    <RelatedBundle Action='Detect' Id='$(var.product_RelatedBundleCode)' />




--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595793.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
This post was updated on .
Yes.  It is just defined so that someday in the future I could, if needed, deploy a patch, addon, or upgrade.  But at this point A - D are all MajorUpdate of A  (and I did not redefine the ReleatedBundle_GUID between then.  Should I change that with each MajorUpgrade?  (I have been dong this for most of the last year with 3.7 and 3.8 and never encountered this behavior, which would have been noted.  It is pretty obvious when observed.)

I wonder if this behavior, which I did not observe with 3.8.1128, is related to the following discussion.  I am still trying to understand the discussion and research it.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Is-adding-a-method-to-a-Burn-COM-Interface-breaking-td7594427.html
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
FYI - I have confirmed (using a different project which has not been changed for some time) that when the bundle is built using wix 3.8.1128 it does not have the behavior observed when the bundle is compiled using 3.9.702.  Specifically:

Bundle A (built using 3.8.1128)
Bundle B (built using 3.9.702)
Bundle C (built using 3.9.702)
Bundle D (built using 2.9.702)

Bundle A on local test system installed.  Then either do update to later build, or do uninstall and launch install again.  (Two different test cases, with similar behavior.)
Bundle B installed as result of 'update' when Bundle A was launched.  Uninstall Bundle B.
Launch Bundle A, update to Bundle C (posted to web after Bundle B was installed (or uninstalled).  Expected result, in that it did not reinstall Bundle B as 3.9.702 code is doing.

Start over, but start at Bundle B (which is same code as Bundle A, but compiled with Wix 3.9.702)
Bundle B.exe is downloaded to local box.  Installed (and uninstalled or left installed to test update.  Two similar test cases.)
Launch Bundle A.exe (with Bundle D available on web site.  DetectUpdate detects Bundle D.  Related Bundles and Forward-Compatible detect Bundle C.  Bundle C gets installed instead of Bundle D, which is the expected behavior.

In all cases above the mba does not have a handler relate to ForwardCompatible.  I am not sure if I should be implementing something to get the Wix 3.8 behavior.


Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
What value are you passing to Plan? Is it BA.Plan(LaunchAction.UpdateReplace)?

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Friday, July 11, 2014 3:40 PM
To: [hidden email]
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

FYI - I have confirmed (using a different project which has not been changed for some time) that when the bundle is built using wix 3.8.1128 it does not have the behavior observed when the bundle is compiled using 3.9.702.
Specifically:

Bundle A (built using 3.8.1128)
Bundle B (built using 3.9.702)
Bundle C (built using 3.9.702)
Bundle D (built using 2.9.702)

Bundle A on local test system installed.  Then either do update to later build, or do uninstall and launch install again.  (Two different test cases, with similar behavior.) Bundle B installed as result of 'update' when Bundle A was launched.
Uninstall Bundle B.
Launch Bundle A, update to Bundle C (posted to web after Bundle B was installed (or uninstalled).  Expected result, in that it did not reinstall Bundle B as 3.9.702 code is doing.

Start over, but start at Bundle B (which is same code as Bundle A, but compiled with Wix 3.9.702) Bundle B.exe is downloaded to local box.  Installed (and uninstalled or left installed to test update.  Two similar test cases.) Launch Bundle A.exe (with Bundle D available on web site.  DetectUpdate detects Bundle D.  Related Bundles and Forward-Compatible detect Bundle C.
Bundle C gets installed instead of Bundle D, which is the expected behavior.

In all cases above the mba does not have a handler relate to ForwardCompatible.  I am not sure if I should be implementing something to get the Wix 3.8 behavior.






--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595801.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
Yes UpdateReplace is indicated in the verbose log.

Back when I used the WixStdBA and a BAFunction I could step into the Engine functions using WinDbg (a long time ago now), but I have not found a way to do that running my mba on a test box (which is network isolated from my development system so Remote debugging has not been successful.)  I am in the process of adding a DetectedForwardCompatibleBundle handler to the mba to see if that is related, as the log seems to indicate.
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
This post was updated on .
I have been reading the wix source code for ideas.  I do not really understand what a Forward Compatible bundle (in contrast to or in relationship to a Relate bundle) is?
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Phill Hogland
Removing the ReleatedBundle Action='Detect' from the bundle, and repeating the experiments on Bundles A-D does not change the behavior.  With Wix 3.9.702 the version designated in the atom feed is ignored if there are intermediate 'related' bundles cached, but not installed on the local system.
Reply | Threaded
Open this post in threaded view
|

Re: 3.9.702 Bundle update behavior

Hoover, Jacob
This may be a regression, so if you haven't already please log the bug with steps to reproduce (and if possible artifacts).

I wonder if I did this. Do you have a build environment for Wix?  If so, have a look near line 310 of PlanDefaultPackageRequestState in Plan.cpp.

It used to be:

    else if (BOOTSTRAPPER_PACKAGE_STATE_SUPERSEDED == currentState && !BOOTSTRAPPER_ACTION_UNINSTALL == action)
    {
        // Superseded means the package is on the machine but not active, so only uninstall operations are allowed.
        // All other operations do nothing.
        *pRequestState = BOOTSTRAPPER_REQUEST_STATE_NONE;
    }

And I had changed it to

    else if (BOOTSTRAPPER_PACKAGE_STATE_SUPERSEDED == currentState && BOOTSTRAPPER_ACTION_UNINSTALL != action)
    {
        // Superseded means the package is on the machine but not active, so only uninstall operations are allowed.
        // All other operations do nothing.
        *pRequestState = BOOTSTRAPPER_REQUEST_STATE_NONE;
    }

-----Original Message-----
From: Phill Hogland [mailto:[hidden email]]
Sent: Saturday, July 12, 2014 8:42 AM
To: [hidden email]
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior

Removing the ReleatedBundle Action='Detect' from the bundle, and repeating the experiments on Bundles A-D does not change the behavior.  With Wix
3.9.702 the version designated in the atom feed is ignored if there are intermediate 'related' bundles cached, but not installed on the local system.



--
View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595805.html
Sent from the wix-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
12