How can I use the SSRS ReportViewer from VS 2008 in a VS2010 project?

Question

I'm working on an ASP.NET MVC 2 / .NET 3.5 project which includes SSRS 2008 reports. After migrating to VS 2010 RC, the new web forms report viewer has been giving so much trouble that I'd like to use the old report viewer from VS 2008 again. Now I'm just wondering what would be the easiest way to do that.

The report viewer is embedded in a Webforms ASPX file which is loaded in an IFrame by the the MVC view. Report parameters are currently stored as session variables, and for security reasons I would prefer not to change that for HTTP POST or GET parameters. So I can't just put the report viewer in a separate application and build that with VS2008.

Moving the entire project back to VS 2008 is not an option.

So, what's the easiest way for me to use the VS 2008 ReportViewer in VS 2010? Is there way to grab an assembly from VS 2008 and use that in my project?

Thanks,

Adrian

Edit: The problems I am having with the VS2010 version of the ReportViewer are related to AJAX requests. For instance, AsyncRendering=True fails to load the report and using the paging controls or the reload button does not work either. The export button works fine, but that's because it's not related to AJAX requests.

If you have any idea how I can fix this, I'd really prefer to keep the new report viewer. It's just that I have previously asked about this on SO, on social.msdn.com and on MS Connect and have not found an answer yet.

Answer 1

You have several options depending on the problem(s) you are experiencing. If one of these suggestions does not work for you, please describe the issues you are having with the control in more detail. For example, are you having trouble with the control in the designer, Microsoft changed its functionality or API, or is it misbehaving at runtime?

• If the issue is with the API or the runtime behavior of the report viewer, and if you have both VS 2008 and VS 2010 installed, you can very easily remove the reference to the 2010 version (actually version 10.0) of Microsoft.ReportViewer.WebForms under your project references. Then you can use the add reference dialog to choose the version from 2008 (actually version 9.0). You will also need to update each page that uses the report viewer and replace the version 10 declaration with the version 9 declaration below.

On each page replace:

<%@ Register assembly="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" namespace="Microsoft.Reporting.WebForms" tagprefix="rsweb" %>

With:

<%@ Register assembly="Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" namespace="Microsoft.Reporting.WebForms" tagprefix="rsweb" %>

And in the web.config replace:

<add assembly="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
<add assembly="Microsoft.ReportViewer.Common, Version=10.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />

With:

<add assembly="Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

And in the web.config replace:

<add path="Reserved.ReportViewerWebControl.axd" verb="*" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="false" />

With:

<add path="Reserved.ReportViewerWebControl.axd" verb="*" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>

And in the web.config replace:

<add extension=".rdlc" type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

With:

<add extension=".rdlc" type="Microsoft.Reporting.RdlBuildProvider, Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

• If only the designer is crashing on you or giving you trouble, you could wrap the 2010 version of the control in a user control or custom control and consume it that way in your pages. You will still not have very good designer experience, but if the designer is your issue, this might be the best workaround to avoid crashes or other issues.

• If you still can't get this to work, you could drop back into VS2008 and wrap up the 2008 version of the report viewer in a custom server control. You could then reference your new control in your 2010 project. Again, you would lose designer support this way.

In addition to these steps you should to log into Microsoft Connect and report the trouble you are having in detail, so they can fix it and include it in the RTM of Visual Studio 2010 (or perhaps a patch).

Answer 2

Brian Hartman has a blog devoted to Report Viewer that covers this very topic: AsyncRendering and all the Baggage that Comes With It

The AsyncRendering property on the ASP.Net ReportViewer control is one of the most misunderstood properties on the ReportViewer. And that’s our fault. There are a lot of side effects to setting this property that you wouldn’t expect from the name. In fact, most of the time that I see users setting this property they are doing it for the side effects rather than for its true intention. Those side effects are gone in Visual Studio 2010 because you can get the effects you want in either mode. But to understand how things have changed, let’s first go through some background information.

The intention of AsyncRendering

Traditionally, the HTML of a web page is not sent to the browser until all of the web controls on the page have generated their content. For controls such as text boxes and buttons, this makes perfect sense. But the ReportViewer is much more complicated than that. It can take the viewer a long time to generate the HTML for a report. In most cases, it makes more sense to send the rest of the page back to the browser and then make another request to get the report content asynchronously. This allows the user to interact with the rest of the page as well as see a "loading indicator" so that they know the server is doing something. This is the default behavior - AsyncRendering = true.

But there are also cases where you want the block the entire page until the report is processed. A good example is a dashboard type of page that is rendering several small reports, perhaps each one containing a single chart or small table. In this case, you may not want the user to be bombarded with multiple wait indicators. If you know the reports are quick to process, blocking the page for a short time may be a better overall experience. This is the intention of AsyncRendering = false.

Asynchronous mode in Visual Studio 2005 and 2008

The mode you choose has a significant effect on the HTML that is ultimately generated. The ReportViewer control was originally designed long before the appearance of ASP.Net AJAX. When you render a report synchronously, the HTML for the report content is embedded directly in the entire page. But when you render asynchronously, the ReportViewer uses a frame. The frame content is retrieved by the browser separately from the main page, so it allows the main page to be visible while the report is generated in a separate request to the web server.

Frames are at the root of all of the side effects to AsyncRendering. The use of frames results in the following differences between the two modes:

The document map is only visible in asynchronous mode, in part because it relies on frames to handle resizing relative to the report area. Because the report is rendered in a frame and not part of the ASP.Net page that hosts the viewer, there is no chance for developers to handle events that occur while processing the report. The most frequent complaint we receive in this area is the inability to handle the ReportError event when rendering asynchronously. The size of the frame is difficult for the viewer to calculate and is therefore usually wrong. It’s based on the sizing mode of the viewer (percentage or fixed size), the height of the toolbar, and the existence of parameters. This is the leading cause to seeing an excessive number of scrollbars in the viewer, particularly when using standards mode or non-IE browsers. Developers often switch to synchronous rendering to alleviate this. Along a similar line to sizing of the frame is the fact that the SizeToReportContent property is ignored in asynchronous mode. The frame does not adjust its size based on the content, so there is no easy way to show an arbitrary report embedded in a page without scrollbars, unless you switch to synchronous mode. These side effects tend to rank higher in terms of requirements when building an application than whether the report shows up synchronously. So it’s no surprise that these issues became the driving factor in which mode developers choose.

The Story in Visual Studio 2010

One of the biggest features of the ASP.Net ReportViewer in VS 2010 is the fact that it relies heavily on ASP.Net AJAX. By default, the viewer will use asynchronous postbacks for all of its operations. This means that we no longer need to rely on frames to retrieve report data asynchronously from the rest of the ASP.Net page. With VS 2010, once a report has finished loading, the HTML displayed in the browser will be the same, regardless of whether you use synchronous or asynchronous rendering.

All of the previous side effects of AsyncRendering are now gone. Both modes support the document map. Both modes support the SizeToReportContent property. Asynchronous postbacks are generally treated the same as traditional postbacks, so you can handle events that occur during report processing. And because of the extensive work we’ve put into this release for standards mode HTML and Firefox and Safari rendering, you should never see double (or triple!) scrollbars in the viewer.

With VS 2010, AsyncRendering has returned to its true intention – it controls whether the initial processing of the report blocks the entire ASP.Net page, and nothing else.