n the first part of this article, you saw how to use the Windows Forms version of the ReportViewer control. This article walks you through the differences and discusses the process for using the Web version of the control.

Comparing the Report Viewers
To minimize the learning curve, the Report Services (RS) team has gone to great lengths to unify the appearance and programming interfaces of the WinForms and Web report viewers. Still, there are some notable discrepancies because they target different platforms.

You'll find the Web ReportViewer programming model very similar (but not identical) to the WinForms ReportViewer. For example, both controls expose the same set of properties to control the processing mode and toolbar. Similarly, you can add the Web ReportViewer control to a Web form by dragging it from the Data section of the VS.NET Toolbox and dropping it on the form. Both controls have the same look and feel, support remote and local processing modes, and expose similar object models.

Naturally, there are architectural differences between the two report viewers that reflect the constraints of the underlying technology. For example, the WinForms ReportViewer is responsible for both requesting and rendering the report, while the Web ReportViewer delegates report rendering to the browser. From a deployment standpoint, you need to distribute the WinForms ReportViewer to each computer that will run your WinForms application. In comparison, the Web ReportViewer requires zero client deployment because you need to install the control on the Web server only.

Figure 1. Opening WebReporter: Open the ASP.NET project as a Web site from the local IIS server.

Another noticeable difference is that the default presentation format of the WinForms ReportViewer is GDI (through the new RGDI extension) renderable by any WinForm-based .NET 2.0 client. In contrast, the Web ReportViewer renders reports in HTML (see this MSDN page for more information about browser support). Finally, the WinForm ReportViewer uses the .NET framework for report printing, while the Web ReportViewer performs this task by downloading an ActiveX control from the server.

Because of their similarities, discussing the Web ReportViewer in detail would be redundant. Instead, this article demonstrates both processing modes by emphasizing the architectural and integration differences.

You can find the code samples accompanying this article in the WebReporter folder created by unzipping the downloadable WebReporter sample project. To test the security scenarios discussed in this article, make sure to open the sample Web application as a Web site in order to execute the code under IIS. To do so, create an IIS virtual folder named WebReporter) that points to the WebReporter physical folder. Next, open VS.NET 2005 and open the application straight from IIS by choosing File —> Open —> Web site (see Figure 1). If you open the project from the file system (a new capability with VS.NET 2005), you'll find that the Windows security samples don't work as expected. That's because, in File System mode, VS.NET always executes the application under your identity. For your convenience, the download contains a VS.NET solution (WebReportReviewer.sln) that hosts both the WebReporter Web site and the sample reports in one solution.