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