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 u
Message-
From: Phill Hogland [mailto:phogl...@rimage.com]
Sent: Monday, July 14, 2014 8:23 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] 3.9.702 Bundle update behavior
I create a bug here:
http://wixtoolset.org/issues/4472/
Please let me know if more or different information wou
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 wix-us
e if I can 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'
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 arc
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
3.
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 wrote:
> Removin
perations are allowed.
// 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-
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.
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:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/3-9-702-Bundle-update-behavior-t
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 R
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
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.70
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 mos
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 t
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
>>>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, b
ding 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: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 behavi
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
-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\
\AppData\Local\Package Cache\
When a bundle is "compl
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\
\AppData\Local\Package Cache\
When a bundle is "completely" Uninstalled, the entries under C:\ProgramData
are removed, but the entries under ..\AppData
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, how
ailto:phogl...@rimage.com]
Sent: Thursday, July 10, 2014 4:07 PM
To: wix-users@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 Dete
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,
n 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
ers@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 t
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 b
27 matches
Mail list logo