|
|
You're in the
dotnet distributed apps
group:How to prevent corrupted binary downloads
dotnet distributed apps:
We've experienced two types of problems: 1) downloading assemblies from a
web-based application base and 2) downloading an MSI to install components on a client machine. We never made much headway with the first problem, the app would just fail to run on some machines. There was a client exe installed on the client machine which created an AppDomain with an http: base and downloaded components. This would work most of the time and fail to load other times. But it might be related to the second problem. A small percentage of users would experience install failures due to a corrupt MSI file. For these users the problem was repeatable, but other users had no problem. Deleting temporary internet files would generally solve the problem, so my theory was that somehow a corrupt version was downloaded and got in the cache and subsequent requests just reloaded the corrupt data from the cache. We finally solved the problem by giving the download directory a 1-minute expiration, so the cache copy would not get reused. This could potentially explain the first problem too, but we never tried it. It also is not very satisfactory for running a web application base, since you really want the cache to reduce download traffic. Only a small percentage of users saw this problem, but even 1% seems pretty poor for a TCP transfer. Is there a more reliable way?
I've seen problems like these (nasty, usually not easily reproduced) with
large HTTP transfers and web services when working over certain types of proxies. If just a few of your customers are experiencing this issue try to find out what proxy they use (on *their* side, nothing to do with yours) and see if they have something in common there. Sometimes asking the IT folks at the client sites to adjust their proxy settings solved the problems... and sometimes it didn't. It's really a hit-and-miss thing, not easy to diagnose. -- Klaus H. Probst, MVP http://www.simulplex.net/ [quoted text, click to view] "Trumba" <trumba@discussions.microsoft.com> wrote in message news:146C2540-C96B-4835-8D15-71E35CA6A4B9@microsoft.com... > We've experienced two types of problems: 1) downloading assemblies from a > web-based application base and 2) downloading an MSI to install components > on > a client machine. > > We never made much headway with the first problem, the app would just fail > to run on some machines. There was a client exe installed on the client > machine which created an AppDomain with an http: base and downloaded > components. This would work most of the time and fail to load other times. > But it might be related to the second problem. > > A small percentage of users would experience install failures due to a > corrupt MSI file. For these users the problem was repeatable, but other > users > had no problem. Deleting temporary internet files would generally solve > the > problem, so my theory was that somehow a corrupt version was downloaded > and > got in the cache and subsequent requests just reloaded the corrupt data > from > the cache. We finally solved the problem by giving the download directory > a > 1-minute expiration, so the cache copy would not get reused. > > This could potentially explain the first problem too, but we never tried > it. > It also is not very satisfactory for running a web application base, since > you really want the cache to reduce download traffic. > > Only a small percentage of users saw this problem, but even 1% seems > pretty > poor for a TCP transfer. Is there a more reliable way? > > Thanks
Does anyone know if the new 2.0 support for ClickOnce deployment handles
these kinds of errors more robustly? My experience is that you can probably avoid the problems with some cache management and error retry code, but a naive download strategy will fail. Thanks Peter [quoted text, click to view] "Klaus H. Probst" wrote:
> I've seen problems like these (nasty, usually not easily reproduced) with > large HTTP transfers and web services when working over certain types of > proxies. If just a few of your customers are experiencing this issue try to > find out what proxy they use (on *their* side, nothing to do with yours) and > see if they have something in common there. > > Sometimes asking the IT folks at the client sites to adjust their proxy > settings solved the problems... and sometimes it didn't. It's really a > hit-and-miss thing, not easy to diagnose. > > > -- > Klaus H. Probst, MVP > http://www.simulplex.net/ > > > "Trumba" <trumba@discussions.microsoft.com> wrote in message > news:146C2540-C96B-4835-8D15-71E35CA6A4B9@microsoft.com... > > We've experienced two types of problems: 1) downloading assemblies from a > > web-based application base and 2) downloading an MSI to install components > > on > > a client machine. > > > > We never made much headway with the first problem, the app would just fail > > to run on some machines. There was a client exe installed on the client > > machine which created an AppDomain with an http: base and downloaded > > components. This would work most of the time and fail to load other times. > > But it might be related to the second problem. > > > > A small percentage of users would experience install failures due to a > > corrupt MSI file. For these users the problem was repeatable, but other > > users > > had no problem. Deleting temporary internet files would generally solve > > the > > problem, so my theory was that somehow a corrupt version was downloaded > > and > > got in the cache and subsequent requests just reloaded the corrupt data > > from > > the cache. We finally solved the problem by giving the download directory > > a > > 1-minute expiration, so the cache copy would not get reused. > > > > This could potentially explain the first problem too, but we never tried > > it. > > It also is not very satisfactory for running a web application base, since > > you really want the cache to reduce download traffic. > > > > Only a small percentage of users saw this problem, but even 1% seems > > pretty > > poor for a TCP transfer. Is there a more reliable way? > > > > Thanks > >
If there is a problem with your download code to begin with, then sure,
using something else will fix the issue. If the problem is the proxy (like I said) or some other environmental factor, then probably no. -- Klaus H. Probst, MVP http://www.simulplex.net/ [quoted text, click to view] "Trumba" <trumba@discussions.microsoft.com> wrote in message news:6851D137-2ED7-4B63-8AB7-26C101197BA3@microsoft.com... > Does anyone know if the new 2.0 support for ClickOnce deployment handles > these kinds of errors more robustly? My experience is that you can > probably > avoid the problems with some cache management and error retry code, but a > naive download strategy will fail. > > Thanks > Peter > > "Klaus H. Probst" wrote: > >> I've seen problems like these (nasty, usually not easily reproduced) with >> large HTTP transfers and web services when working over certain types of >> proxies. If just a few of your customers are experiencing this issue try >> to >> find out what proxy they use (on *their* side, nothing to do with yours) >> and >> see if they have something in common there. >> >> Sometimes asking the IT folks at the client sites to adjust their proxy >> settings solved the problems... and sometimes it didn't. It's really a >> hit-and-miss thing, not easy to diagnose. >> >> >> -- >> Klaus H. Probst, MVP >> http://www.simulplex.net/ >> >> >> "Trumba" <trumba@discussions.microsoft.com> wrote in message >> news:146C2540-C96B-4835-8D15-71E35CA6A4B9@microsoft.com... >> > We've experienced two types of problems: 1) downloading assemblies from >> > a >> > web-based application base and 2) downloading an MSI to install >> > components >> > on >> > a client machine. >> > >> > We never made much headway with the first problem, the app would just >> > fail >> > to run on some machines. There was a client exe installed on the client >> > machine which created an AppDomain with an http: base and downloaded >> > components. This would work most of the time and fail to load other >> > times. >> > But it might be related to the second problem. >> > >> > A small percentage of users would experience install failures due to a >> > corrupt MSI file. For these users the problem was repeatable, but other >> > users >> > had no problem. Deleting temporary internet files would generally solve >> > the >> > problem, so my theory was that somehow a corrupt version was downloaded >> > and >> > got in the cache and subsequent requests just reloaded the corrupt data >> > from >> > the cache. We finally solved the problem by giving the download >> > directory >> > a >> > 1-minute expiration, so the cache copy would not get reused. >> > >> > This could potentially explain the first problem too, but we never >> > tried >> > it. >> > It also is not very satisfactory for running a web application base, >> > since >> > you really want the cache to reduce download traffic. >> > >> > Only a small percentage of users saw this problem, but even 1% seems >> > pretty >> > poor for a TCP transfer. Is there a more reliable way? >> > >> > Thanks >> >> >>
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |