Strange download problem!

  • Thread starter Thread starter James Wong
  • Start date Start date
J

James Wong

Hi! everybody,

I'm facing a quite strange download problem. I use the following code to
download an XML file to client side:

With Response
' clear buffer
Call .Clear()

' specify the type of the downloadable file
.ContentType = "application/octet-stream" ' I have
also tried to change this statement to Response.ContentType = "Text/XML"
, but the result is same

' det the default filename in the FileDownload dialog box
Call .AddHeader("Content-Disposition", "attachment;
filename=""Download.XML""")

' force to flush buffer
Call .Flush()

' download the file
Call .WriteFile("Original.XML")
End With

When the download is finished, I found that some HTML code are attached to
the end of my original XML statements in download file. The HTML code is
what exact the form just before download. I would like to know what causes
this result and the solution. Certainly, I need the XML content only.

Thanks for your attention and kindly advice!

Regards,
James
 
One suggestion, try Response.Write(file) instead of writefile, that may cure
the ailment.
 
Alvin,

Thanks for your response. But even I change it to Response.Write, the
strange behavior still be there.

Regards,
James
 
Hello James,

Thanks for posting in the group.

Please try adding Call.End() before "End With" to see if it works.

I used the following code and it works great for me:

string filename = "C:\MyFolder\MyFile.xml";
System.IO.FileInfo file = new System.IO.FileInfo(fileName);
Response.Clear(); // clear the current output content from the buffer
Response.AppendHeader("Content-Disposition", "attachment; filename=" +
file.Name);
Response.AppendHeader("Content-Length", file.Length.ToString());
Response.ContentType = "application/octet-stream";
Response.WriteFile(file.FullName);
Response.End();

Does that answer your question? If the problem is still there, please feel
free to post here.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
After call Call .WriteFile("Original.XML") type
Response.End();
Will work.


Thanks,

sswalia
MCSD, MCAD, OCA
 
Hi! Yanhong and SSW,

Thanks for your reply! I works by adding Call .End() and solve my problem.

However, there is a side-effect by doing so. Threading.ThreadAbortException
is fired once the .End() method is called. My workround is to handle this
exception and put all remaining statements after the .End() method under
this exception handling routine. Do you have a better idea to overcome this
side-effect?

Anyway, thanks for your effort!

Regards,
James
 
Hello

Put the remaining state after the .End() statement. The .NET Framework will
handle the ThreadAbortException

Best regards
Sherif
 
Hello, Sherif,

I have my own exceptional handler which handles all unexpected exceptions.
So if I don't handle it, this exception will fire my default exceptional
handling routine which logs exception details in my self-defined log and
also sends an e-mail to me. That's why I have to handle it. Do you think
there is other better workaround?

Regards,
James
 
Hello

ThreadAbortException is special in that even if your handler catches it, it
will be rethrown again at the end of the catch block, unless you call
Thread.ResetAbort(). In your case it is not appropriate to call
ResetAbort(), because this means the rendering of the page will continue.
If you don't want to call Response.End() which throws the
ThreadAbortException, you can override the Render Method and not call the
base class Render method.

Best regards
Sherif

James Wong said:
Hello, Sherif,

I have my own exceptional handler which handles all unexpected exceptions.
So if I don't handle it, this exception will fire my default exceptional
handling routine which logs exception details in my self-defined log and
also sends an e-mail to me. That's why I have to handle it. Do you think
there is other better workaround?

Regards,
James

Sherif ElMetainy said:
Hello

Put the remaining state after the .End() statement. The .NET Framework will
handle the ThreadAbortException

Best regards
Sherif

James Wong said:
Hi! Yanhong and SSW,

Thanks for your reply! I works by adding Call .End() and solve my problem.

However, there is a side-effect by doing so. Threading.ThreadAbortException
is fired once the .End() method is called. My workround is to handle this
exception and put all remaining statements after the .End() method under
this exception handling routine. Do you have a better idea to
Click to expand...
overcome
this
side-effect?

Anyway, thanks for your effort!

Regards,
James

"Yan-Hong Huang[MSFT]" <[email protected]> ¦b¶l¥ó
¤¤¼¶¼g...
Hello James,

Thanks for posting in the group.

Please try adding Call.End() before "End With" to see if it works.

I used the following code and it works great for me:

string filename = "C:\MyFolder\MyFile.xml";
System.IO.FileInfo file = new System.IO.FileInfo(fileName);
Response.Clear(); // clear the current output content from the buffer
Response.AppendHeader("Content-Disposition", "attachment; filename=" +
file.Name);
Response.AppendHeader("Content-Length", file.Length.ToString());
Response.ContentType = "application/octet-stream";
Response.WriteFile(file.FullName);
Response.End();

Does that answer your question? If the problem is still there,
Click to expand...
please
feel
free to post here.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.
Click to expand...
Click to expand...
Click to expand...
 
Hello James,

Thanks for your response.

The Response.End method ends the page execution and shifts the execution to
the Application_EndRequest event in the application's event pipeline. The
line of code that follows Response.End is not executed. So
ThreadAbortException exception occurs.

To work around this problem, For Response.End, call the
ApplicationInstance.CompleteRequest method instead of Response.End to
bypass the code execution to the Application_EndRequest event.

For detailed info on it, please refer to MSDN article:
"PRB: ThreadAbortException Occurs If You Use Response.End,
Response.Redirect, or Server.Transfer"
http://support.microsoft.com/?id=312629

Does that answer your questoin?

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hello Yan-Hong,

Thanks for you reply again!

I think this is a quite interesting case since when I use
ApplicationInstance.CompleteRequest instead of Response.End, no more
exception is captured. However, the original problem, HTML codes are
included in the downloaded file, comes again!

Until now, I think using Reponse.End with additional exceptional handler (in
which the remaining codes after Response.End are there) may be the best way
to solve my problem.

If you have any other good idea, please let me know and share with all
others here.

Regards,
James
 
Hello Sherif,

Thanks again for your reply!

Do you mean that I should put all remaining codes outside the
Try...Catch...End Try block? On the other hand, I don't understand what
class's Render method you suggest me to override.

Regards,
James
 
Hi James,

Just now I found this good article for you. :)

It contains a good sample in ASP.NET on how to download and upload file.

"Downloading and Uploading Files"
http://msdn.microsoft.com/library/en-us/dnaspp/html/aspnet-jspmig-downloadin
ganduploading.asp?frame=true#aspnet-jspmig-downloadinganduploading_topic6

Hope that helps.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hi Yan-Hong,

Thanks again for your effort on my problem. I'll study the document to
solve my problem.

Regards,
James
 
Hi James,

It is my pleasure. :)

Thanks very much for participating the community.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! ¨C www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top