I create a bug here:
http://wixtoolset.org/issues/4472/
Please let me know if more or different information would be helpful.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595814.html
Sent from the
On 14-Jul-14 19:34, Hoover, Jacob wrote:
I did some digging today, and if I revert my change then in the case of
Bundle A launching Bundle B for an update, it's an async update and when A
completes it tries to clean B. It may be a fringe case, but I could see
this causing issues if B
.
// All other operations do nothing.
*pRequestState = BOOTSTRAPPER_REQUEST_STATE_NONE;
}
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Saturday, July 12, 2014 8:42 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 3.9.702 Bundle update
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?
On Sat, Jul 12, 2014 at 8:41 AM, Phill Hogland
I will plan to post a bug tomorrow at work. I do not have a wix build
environment for wix 3.9. I tried both at work and at home and have not been
successful yet. I previously built debug versions of wix 3.7 and 3.8 but
still working to get a debug version of wix 3.9. I have been reading the
Sorry for prior post. I did not see Sean's post. Thanks for the assistance.
Should I still post a bug?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-tp7595761p7595811.html
Sent from the wix-users mailing list
reproduce the original problem.
-Original Message-
From: Sean Hall [mailto:r.sean.h...@gmail.com]
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
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.
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,
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
-users@lists.sourceforge.net
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
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
?
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:phogl...@rimage.com]
Sent: Friday, July 11, 2014 8:29 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior
My
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
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
So A-D all have the same RelatedBundle GUID?
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, July 11, 2014 11:05 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior
After adding more logging statements
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 ReleatedBundl_GUID between
then. Should I change that with each MajorUpgrade? (I have been dong this
for
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
What value are you passing to Plan? Is it BA.Plan(LaunchAction.UpdateReplace)?
-Original Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Friday, July 11, 2014 3:40 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior
FYI - I have
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
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.)
--
View this message in context:
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
@lists.sourceforge.net
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
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
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,
@lists.sourceforge.net
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
26 matches
Mail list logo
