The Report Viewer control allows web application developers to leverage full-featured reports and present them to the user in an easy to use and intuitive interface. The Report Viewer 2008 ships as a part of Visual Studio, along with the integrated Report Designer. Reports can contain tabular, aggregated and multi-dimensional data. The ReportViewer Control also comes in a WindowsForm version for building report-enabled custom applications.
The ReportViewer allows the consume two types of reports, after some configuration via the web.config file:
- Local Reports: These are reports that are processed by the client application, via the ReportViewer control. Visual Studio 2008 contains a "Report Project" template to allow easy creation of these types of reports. Local Reporting is geared towards custom web applications.
- Remote Reports: These are reports tht are hosted via the Microsoft SQL Server Reporting Services report server. The ReportViewer control is used as a display mechanism to a report already defined and published in the Report Server. All processing of the data is rendered on the report server itself. Remote Reporting is geared towards larger scope applications in an enterprise environment.
The ReportViewer is one of the most overlooked and underdocumented tools in the Visual Studio arsenal. One of the primary issues with using the ReportViewer in a web environment is due to nebulous error messages, making it very difficult to pinpoint where the problem may be. Through this article, I intend to address "gotchas" that I've run into as I've developed hundreds of reports for a large scale enterprise, both in Local and Remote reporting modes.
Another important use of ReportViewer in ASP.NET applications is the ability to use the web site authentication over the Reporting Services reports. You can grant permissions over the reports using your ASP.NET application easily without dealing with details in SSRS authentication and authorization.
One of the most useful and undocumented features of the ReportViewer is its ability to consume a LinqDataSource as the ReportDataSource. Though Visual Studio automatically adds an ObjectDataSource when you first add the viewer, this is only useful if you plan on using a DataSet to collect your data from the database. However, as Linq becomes more prevelant for manipulating data, you'll want to investigate tying your reports directly to a DataContext rather than managing DataSet and DataContext objects in the same project.
To Be Included
- Creating a basic report
- Adding ReportViewer to your web application
- Provide data via ObjectDataSource
- Provide data via DataSet, CodeBehind
- Provide data via LinqDataSource and Linq to SQL