ThreadAbortException at ExportToHttpResponse()

[dorrit.Riemenschneider]

I've developed a sharepint webpart (ASP.NET 2.0 application) with use
of the CrystalReportViewer web control
(CrystalDecisions.Web.CrystalReportViewer). All works fine except the
export of the report associated to the CrystalReportViewer. I use the
following source code:

CrystalDecisions.Web.CrystalReportViewer crViewer = new
CrystalDecisions.Web.CrystalReportViewer();
CrystalDecisions.Web.CrystalReportSource crSource = new
CrystalDecisions.Web.CrystalReportSource();
CrystalDecisions.CrystalReports.Engine.ReportDocument crSource = null;
crSource.Report.FileName = reportFilename;
crDocument = crSource.ReportDocument;
this.Controls.Add(crViewer);
//...some other stuff
//...
//here comes the export
ExportOptions options = new ExportOptions();
options.ExportFormatType = ExportFormatType.PortableDocFormat;
crDocument.ExportToHttpResponse(options, this.Page.Response, true,
"report");

The export itsself works but a ThreadAbortException is thrown at the
ExportToHttpResponse method and the execution of the page stops.

I've already found that it is a new feature at ASP.NET 2.0 to abort
the thread at Response.End or Response.Redirect (see http://
support.microsoft.com/kb/312629/EN-US/). But this doesn't really solve
my problem.

How can I prevent the ThreadAbortException from being thrown?

Thanks, Dorrit

 

[Guest]

This is because, Response.End is called internally in ExportToHttpResponse
method:


public virtual void ExportToHttpResponse(ExportOptions options, HttpResponse
response, bool asAttachment, string attachmentName)
{
if ((options.ExportFormatType == ExportFormatType.HTML40) ||
(options.ExportFormatType == ExportFormatType.HTML32))
{
throw new
NotSupportedException(CREngineRes.GetString("IDS_ERROR_EXPORT_TO_RESPONSE_IN_HTML_FORMAT_NOT_SUPPORTED"));
}
try
{
Stream stream1 = this.ExportToStream(options);
response.Clear();
SharedUtils.SetResponseContent(response,
options.ExportFormatType, asAttachment, attachmentName);

SharedUtils.WriteToResponse(response, stream1, true);
}
catch (COMException exception1)
{
if (!ConvertDotNetToErom.ThrowDotNetException(exception1))
{
throw;
}
}
}

public static void WriteToResponse(HttpResponse response, Stream
inputStream, bool exclusive)
{
if (inputStream != null)
{
int num1;
Stream stream1 = response.OutputStream;
byte[] buffer1 = new byte[0x1000];
while ((num1 = inputStream.Read(buffer1, 0, 0x1000)) > 0)
{
stream1.Write(buffer1, 0, num1);
}
stream1.Flush();
if (exclusive)
{
response.End();
}
}
}

Therefore, when you call ExportToHttpResponse wrap it with try catch block:

try
{
ExportToHttpResponse(...);
}
catch (System.Threading.ThreadAbortException)
{

}

and You're done.

 

[Dorrit]

I've already wrapped the call in a try catch block but my problem is
this: the thread is actually aborted after the call of
ExportToHttpResponse and no events (button_click etc.) are fired. I
have to manually reload the page (F5 in browser) in order to "reawake"
the page.

If there is no possibility to prevoid the ThreadAbortException from
beeing thrown:

1. How can I do the "reawake" of the page programmatically?

2. Even better: Is there a possibility to call ExportToHttpResponse
not with "this.Page.Response" but rather with another responce object
(a clon or so ... which may be aborted...)?

Thanks, Dorrit

 

[Guest]

Hi there again,

I don't actually think so. Could you just use iframe with a page that takes
reposibility of this task?

 

[Dorrit]

Hi again,

I have implemented the following workaround: I export the report not
to http resonse (this kills the thread and throws the exception - no
chance) but to disk. I then open a new browser window with java script
and navigate to an aspx page. I give the filename of the exported file
and the content type corresponding to the export format to the page.
In the Load event of the aspx page I load the exported file into the
page. In the Unload event I delete the exported file from disk.

This is not a very nice but working solution.

Dorrit

 

[Guest]

Hi Dorrit gaian,

Good to hear you solved the problem. In case you have any issues in future,
use Reflector (http://www.aisto.com/roeder/dotnet/) to investigate the code
yourself.

Regards