In looking at that, and also what I know about the ThreadAbortException, I would say that it seems, from the code, that it works correctly. Whenever you do a Response.End() or a Response.Redirect(), a ThreadAbortException is thrown. This is normal behavior. But, you might try this method: From MSDN String FileName; FileStream MyFileStream; IntPtr FileHandle; long StartPos = 0, FileSize; FileName = "c:\\temp\\Login.txt"; MyFileStream = new FileStream(FileName, FileMode.Open); FileHandle = MyFileStream.Handle; FileSize = MyFileStream.Length; ... Response.WriteFile(FileHandle, StartPos, FileSize); MyFileStream.Close();
It might work a bit better, either that, or, provide a link for the user to click on to download the pdf themselves. At a minimum, I would wrap a try catch around the code and see what is going on aside from the ThreadAbortException. Soemthing like this: try { ... downloading code here } catch(ThreadAbortException tex) { ... do nothing here, we don't care about the exception, we just don't want to throw it. } catch(Exception ex) { ... see what other exceptions might be creeping up... }
Also, on another thought, it could possibly be Acrobat that is causing the problem. With the WriteFile, the file itself is written into the response stream. Now, I know on my machine, when I download a pdf and view it in the browser, the Acrobat OCX always wants to check for a newer version and will hang my browser at times. MAybe something like this is happening? HTH, Bill P. Oakland, CA
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCM/MU/B dpu s--:-- a32 C++++$ ULH+++ P+++ L++ E+ W+++$ N++ o K? w++++$ O-- M V-- PS+ PE+ Y++ PGP++ t++@ 5++@ X++ R+@ tv b++ DI++ D+++>++++ G++ e++ h---- r+++ y++++ -----END GEEK CODE BLOCK-----