如何在 VS2010 项目中使用 VS 2008 中的 SSRS ReportViewer？

发布于 2024-08-24 22:11:31 字数 1160 浏览 5 评论 0原文

我正在开发一个 ASP.NET MVC 2 / .NET 3.5 项目，其中包括 SSRS 2008 报告。迁移到 VS 2010 RC 后，新的 Web 表单报表查看器给我带来了很多麻烦，因此我想再次使用 VS 2008 中的旧报表查看器。现在我只是想知道最简单的方法是什么。

报表查看器嵌入在 Webforms ASPX 文件中，该文件由 MVC 视图加载到 IFrame 中。报告参数当前存储为会话变量，出于安全原因，我不想更改 HTTP POST 或 GET 参数的设置。所以我不能只是将报表查看器放在一个单独的应用程序中并使用 VS2008 构建它。

将整个项目移回 VS 2008 并不是一种选择。

那么，在 VS 2010 中使用 VS 2008 ReportViewer 最简单的方法是什么？有没有办法从 VS 2008 获取程序集并在我的项目中使用它？

谢谢，

Adrian

编辑： 我在使用 VS2010 版本的 ReportViewer 时遇到的问题与 AJAX 请求有关。例如， AsyncRendering =True 无法加载报告和使用分页控件或重新加载按钮也不起作用。导出按钮工作正常，但那是因为它与 AJAX 请求无关。

如果您知道如何解决此问题，我真的更愿意保留新的报告查看器。只是我之前曾在 SO、social.msdn.com 和 MS Connect 上询问过此问题，但尚未找到答案。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

听风吹 2024-08-31 22:11:31

根据您遇到的问题，您有多种选择。如果这些建议之一对您不起作用，请更详细地描述您在使用控件时遇到的问题。例如，您是否在设计器中的控件方面遇到问题，Microsoft 是否更改了其功能或 API，或者它在运行时是否行为不当？

如果问题与 API 或报表查看器的运行时行为有关，并且您同时安装了 VS 2008 和 VS 2010，则可以轻松删除对 Microsoft.ReportViewer.WebForms 2010 版本（实际上是版本 10.0）的引用在您的项目参考下。然后您可以使用添加引用对话框选择 2008 年的版本（实际上是 9.0 版）。您还需要更新使用报表查看器的每个页面，并将版本 10 声明替换为下面的版本 9 声明。

在每个页面上替换：

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

在

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

在 web.config 中替换：在 web.config 中替换：

<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" />

web.config

<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"/>

中替换：

<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" />

在 web.config 中替换：

<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"/>

在 web.config 中替换：

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

在

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

如果设计器让你崩溃或给你如果您遇到麻烦，您可以将 2010 版本的控件包装在用户控件或自定义控件中，并在页面中以这种方式使用它。您仍然不会有很好的设计器经验，但如果设计器是您的问题，这可能是避免崩溃或其他问题的最佳解决方法。
如果您仍然无法使其工作，您可以返回到 VS2008 并将 2008 版本的报表查看器封装在自定义服务器控件中。然后，您可以在 2010 年项目中引用新控件。同样，您会以这种方式失去设计人员的支持。

除了这些步骤之外，您还应该登录 Microsoft Connect 并详细报告您遇到的问题，以便他们可以修复它并将其包含在 Visual Studio 2010 的 RTM（或者可能是补丁）中。

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).

回复收藏 0 原文

夜巴黎 2024-08-31 22:11:31

Brian Hartman 有一个专门介绍报告查看器的博客，其中涵盖了这个主题：
异步渲染以及随之而来的所有包袱

ASP.Net ReportViewer 控件上的 AsyncRendering 属性是 ReportViewer 上最容易被误解的属性之一。那是我们的错。设置此属性会产生许多您从名称中看不到的副作用。事实上，大多数时候我看到用户设置此属性是为了副作用而不是其真正意图。这些副作用在 Visual Studio 2010 中消失了，因为您可以在任一模式下获得所需的效果。但为了了解事情发生了怎样的变化，让我们首先了解一些背景信息。
AsyncRendering的意图
传统上，直到页面上的所有 Web 控件都生成其内容后，网页的 HTML 才会发送到浏览器。对于文本框和按钮等控件来说，这是非常有意义的。但 ReportViewer 比这复杂得多。查看者可能需要很长时间才能生成报告的 HTML。在大多数情况下，将页面的其余部分发送回浏览器，然后发出另一个请求以异步获取报表内容更有意义。这允许用户与页面的其余部分进行交互，并看到“加载指示器”，以便他们知道服务器正在执行某些操作。这是默认行为 - AsyncRendering = true。
但也有一些情况，您希望阻止整个页面，直到处理报告。一个很好的例子是仪表板类型的页面，它呈现多个小报告，可能每个报告都包含一个图表或小表格。在这种情况下，您可能不希望用户受到多个等待指示器的轰炸。如果您知道报告处理速度很快，那么短时间阻止该页面可能会带来更好的整体体验。这就是AsyncRendering = false的意图。
Visual Studio 2005 和 2008 中的异步模式
您选择的模式对最终生成的 HTML 有重大影响。 ReportViewer 控件最初是在 ASP.Net AJAX 出现之前很久就设计的。当您同步呈现报表时，报表内容的 HTML 会直接嵌入到整个页面中。但是当您异步渲染时，ReportViewer 使用框架。浏览器从主页中单独检索框架内容，因此它允许在向 Web 服务器发出单独请求时生成报告时主页可见。
帧是 AsyncRendering 所有副作用的根源。框架的使用导致两种模式之间存在以下差异：
文档结构图仅在异步模式下可见，部分原因是它依赖于框架来处理相对于报表区域的大小调整。
由于报表是在框架中呈现的，而不是托管查看器的 ASP.Net 页面的一部分，因此开发人员没有机会处理处理报表时发生的事件。我们在这方面收到的最常见的抱怨是异步渲染时无法处理 ReportError 事件。
观看者很难计算框架的大小，因此通常是错误的。它基于查看器的大小调整模式（百分比或固定大小）、工具栏的高度以及参数的存在。这是在查看器中看到过多滚动条的主要原因，特别是在使用标准模式或非 IE 浏览器时。开发人员经常切换到同步渲染来缓解这种情况。
与调整框架大小类似的是，SizeToReportContent 属性在异步模式下被忽略。框架不会根据内容调整其大小，因此没有简单的方法可以显示嵌入在没有滚动条的页面中的任意报告，除非切换到同步模式。
在构建应用程序时，这些副作用往往比报告是否同步显示的要求更高。因此，这些问题成为开发者选择模式的驱动因素也就不足为奇了。
Visual Studio 2010 中的故事
VS 2010 中 ASP.Net ReportViewer 的最大功能之一是它严重依赖 ASP.Net AJAX。默认情况下，查看器将对其所有操作使用异步回发。这意味着我们不再需要依赖框架从 ASP.Net 页面的其余部分异步检索报告数据。使用 VS 2010，一旦报表加载完成，无论您使用同步渲染还是异步渲染，浏览器中显示的 HTML 都将是相同的。
之前 AsyncRendering 的所有副作用现在都消失了。两种模式都支持文档结构图。两种模式都支持 SizeToReportContent 属性。异步回发的处理方式通常与传统回发相同，因此您可以处理报表处理期间发生的事件。由于我们在此版本中针对标准模式 HTML 以及 Firefox 和 Safari 渲染进行了大量工作，因此您永远不会在查看器中看到双（或三重！）滚动条。
在 VS 2010 中，AsyncRendering 又回到了它的真正目的 - 它控制报表的初始处理是否阻塞整个 ASP.Net 页面，而不是其他任何东西。

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.