RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Building Report-enabled Applications with the New ReportViewer Controls (Part 1 of 2)

Reporting is an integral part of every complete application. The Report Viewer controls greatly reduce the development effort required to report-enable .NET applications. Part one of this two-part article shows you how you can leverage the Windows Forms ReportViewer to integrate your Windows Forms .NET applications with Reporting Services 2005.

icrosoft SQL Server 2005 Reporting Services (SSRS) provides open protocols for integrating reporting clients regardless of the targeted programming language and platform. A noticeable missing piece in its integration strategy was a presentation layer to deliver the generated reports to the end users. The RS 2005 Windows Forms and Web Report Viewer controls fill in this gap.

To understand how the report viewers simplify integrating RS with your applications, recall that the Report Server provides two communication façades (HTTP Handler and Web service) hosted by Internet Information Server (IIS).

HTTP Handler
The RS HTTP handler lets external clients request a report by submitting HTTP GET or POST requests that specify the report URL, a feature usually termed "URL addressability." For example, here is how you can render the Customer Orders report used in this article in PDF format. The example below assumes that the report was uploaded to the Prologika folder and takes two parameters.


As you would probably agree, requesting reports with URL addressability is easy. In its simplest implementation, you can embed the report URL link in your application. On the downside, in some cases URL addressability may present security risks because it exposes the report parameters. Another limitation with URL addressability is that it supports requesting reports only. You cannot use this integration option to perform management tasks. Because of these limitations, URL addressability may be deprecated in the long run in favor of the RS Web service.

RS Web Service
One significant limitation of the RS 2000 Web service was that it didn't support interactive report features such as drilldown, toggled visibility, document maps, etc. As a result, developers were forced to use URL addressability when business requirements called for rich report experiences. Fortunately, this limitation has been lifted in RS 2005 and the RS Web service now supports interactive features. In fact, due to the sheer number of new rendering APIs, the RS team has split the Web service into two endpoints: the ReportExecution2005 Web service (ReportExecution2005.asmx), which handles report rendering tasks only, and the ReportService2005 (ReportService2005.asmx) Web service, which provides report management APIs. The RS 2000 Web service (ReportService.asmx) is still supported for backward compatibility.

However, it's inherently more difficult to integrate report clients with the Web service than via the URL addressability option, because developers need to know how to access the SSRS. Web service programmatically and take extra steps to handle report images, report sessions, and other features that come for free with URL addressability. Supporting interactive features (toggle, drilldown, etc) presents additional challenges. This is where the report viewers come in. They shield developers from the Web service technicalities so you could spend less time writing plumbing code to deliver your reports to the end user.

Introducing the Report Viewers
The Windows Forms WinReporter sample application that accompanies this article demonstrates various features of the Windows Forms ReportViewer control. You can find the source code of WinReporter and the sample reports demonstrated in article by opening the Report Viewers solution. Figure 1 shows the WinReporter in action.

Figure 1. WinReporter Application: The Windows Forms Report Viewer supports local and remote integration modes.
The WinReporter Application
End users can request the Customer Orders report either remotely, in which case the report is generated by the Report Server, or locally. In remote mode, they can set the Date parameter by picking a date from the interface (see Figure 1). This causes the CustomerID parameter to refresh because the application shows only the customers who have placed orders on the selected date. When a user clicks the Run Report button, the Report Viewer submits the report request to the Report Server. The Customer Orders report also supports interactive features. For example, users can expand the customer field to see all the orders submitted by that customer (toggled visibility) or click on an order number to launch a Sales Order Details report (report drillthrough). Behind the scenes, the Report Viewer carries out these actions via calls to the SSRS Web service, which has been enhanced to support interactive features.

In contrast, in local mode, the Report Viewer bypasses the Report Server. The application supplies the report with parameters and data. The Report Viewer processes and renders the report. To end users, there's little difference; the local version of the Customer Orders supports the same interactive features as its server counterpart.

ReportViewer Features
The ReportViewer supports a cornucopia of features, including:

  • Automatically handling report images and sessions.
  • Interactive features such as toggled visibility, document map, bookmarks, interactive sorting, etc.
  • Printing and print preview.
  • Export to multiple formats.
  • In remote mode, integration with managed report server environment: security, caching, scheduling, delivery, etc.
The end-user features can be initiated from the toolbar. For example, the end user can page through the report or export the report in one of the supported export formats. In remote mode, the ReportViewer can optionally display a parameter area which generates a parameter control for each parameter defined in the report. The ReportViewer supports a certain degree of customization. For example, if the application supplies all the report parameters, the parameter area is redundant and can be hidden.

Installing the Report Viewer Controls
Although they're related to Reporting Services, the report viewers are not shipped with either Reporting Services or Business Intelligence Studio. Instead, they are bundled with VS.NET 2005. Therefore, to use the report viewers in your applications, you need a copy of VS.NET 2005. The viewers are physically implemented in five .NET assemblies, as shown in Table 1.

Table 1. ReportViewer Assemblies: The table lists the five assemblies that implement the Web Forms and Windows Forms report viewers.
Assembly File Description
Microsoft.ReportViewer.WinForms.dll The Windows Forms control implementation.
Microsoft.ReportViewer.WebForms.dll The Web Forms control implementation.
Microsoft.ReportViewer.Common.dll Functionality common to both controls.
Microsoft.ReportViewer.ProcessingObjectModel.dll The Processing Object Model accessed by expressions in the report.
Microsoft.ReportViewer.Design.dll Design-time functionality of both controls. Not required at run-time.

The report viewers are freely redistributable. To facilitate distributing the controls to end users, Microsoft has provided a Microsoft ReportViewer Redistributable 2005 package. The report viewers have a dependency on .NET 2.0, so prior to deploying your application you need to install the .NET Framework 2.0 on the client machine. Remote mode is supported only with RS 2005.

For the purposes of running the sample code accompanying this article, you also need to install the AdventureWorks sample SQL Server database, which is included in the SQL Server setup but is not installed by default. To so install it, run SQL Server setup, and in the Feature Selection step, click the Advanced button. Expand the Sample Databases folder and select the AdventureWorks database. In addition, before running the code samples, open the report viewer solution and deploy the Reports project to deploy the sample reports to the Report Server.

Figure 2. Adding a ReportViewer: You can drag-and-drop a ReportViewer control to a form and configure it at design time.
Configuring the ReportViewer
To embed the ReportViewer in your Windows Forms .NET applications, open Visual Studio.NET 2005 and create a Windows Forms project. Open your form in design mode, expand the Data tab of the VS.NET toolbox and select the ReportViewer control (see Figure 2). Then, drag and drop it to the design canvas of your form.

As with other Windows Forms controls, you can configure the ReportViewer during design time using the VS.NET 2005 Smarts Tags feature (Tasks panel) or the Properties Window. For example, you can set up the Tasks panel to render a specific server or local report. Or, you can disable the toolbar buttons or the entire toolbar by setting the ShowToolBar property in the Properties window.

The ReportViewer also exposes a comprehensive object model that you can control programmatically, as the WinReporter sample demonstrates. In remote mode, you interact with the ServerReport object (reportViewer.ServerObject), while in local mode you use the LocalReport object (reportViewer.LocalObject). These objects expose almost identical programming interfaces, so switching from one mode to another is easy.

Now that I've given you a high-level overview of the Windows Forms ReportViewer, let's find how you can use it to request server and local reports.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date