This is more likely a server problem ie. having the whole file help in
memory. I wonder if this is a limitation tied to IIS and/or HTTP (i.e the
request needs to be entirely read before passed to ASP.NET ????).
What is it ?
My first though would be to reduce the file size (for example upload
differences), to install something client side if this is for specific
users, to handle this using something different if for general usee (FTP,
client side control with PUT access, Webdav or whatever else that doesn't
use up the memory).
Hopefully someone will tell us if this is limitation that can't be
workaround using HTTP...
Patrice
--
"Uncle Ben" <spamfree@nospam.com> a écrit dans le message de
news:Oau2jv2LFHA.244@TK2MSFTNGP12.phx.gbl...
[quoted text, click to view] > Not entirely. But for now, I'd like to know if anyone has implemented the
> FileUpload control in ASP.NET 2.0 beta 1 and if so, how well it works.
>
>
> "Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
> wrote in message news:ut8AiW2LFHA.1172@TK2MSFTNGP12.phx.gbl...
> > You have lowered your expectation from 4Gigs and + to only a scanty
2Gigs?
> >
> > S. L.
> >
> > "Uncle Ben" <spamfree@nospam.com> wrote in message
> > news:uO1cE51LFHA.3616@TK2MSFTNGP09.phx.gbl...
> > > How strong and reliable is the new ASP.NET 2.0 FileUpload control? By
> > > that,
> > > I mean is it reliable enough to accept 2-gigabyte file uploads per
> upload
> > > session?
> > >
> > > Also, is it possible or easy to implement an upload progress bar using
> > > this
> > > FileUpload control?
> > >
> > > Thanks.
> > >
> > >
> >
> >
>
>