I have both issues figured out, by adding retry/TryAgain processing to
CacheAcquireComplete, CacheVerifyComplete, and CachePackageComplete.
Thanks for the assistance.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Addressing-download-failures-i
I have continued to research this issue (between local network disruptions).
While I have done many experiments to try and understand a rare download
failure of a 90mb payload cab file, I have focused on Rob's comment about
Burn's use of http being reliable 'with retries' (in contrast to BITS). I
Thanks, I have been using Fiddler, and have not seen any of the payload
download activity.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Addressing-download-failures-in-Burn-driven-MSI-tp7597272p7597332.html
Sent from the wix-users mailing list a
: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Addressing download failures in Burn driven MSI
Thank you for the information.
What are the drawbacks or risks of using bits:// protocol?
We target Windows 7/WS2008R2 and later with MSI ver 500, using WiX 3.9.1006.
I changed the 90 Mb
Thank you for the information.
What are the drawbacks or risks of using bits:// protocol?
We target Windows 7/WS2008R2 and later with MSI ver 500, using WiX 3.9.1006.
I changed the 90 Mb cab file to use the bits:// protocol and I have not been
able to reproduce the failure in my tests since that
1. No.
2. BITS is not more reliable than the Burn http downloader with retries.
___
FireGiant | Dedicated support for the WiX toolset |
http://www.firegiant.com/
-Original Message-
From: Phill Hogland [mailto:phogl...@rima
6 matches
Mail list logo