Leveraging the ASP.NET ReportViewer Control

Related: "Getting Started with ASP.NET" and "HTML5 for the ASP.NET Developer."

Reporting is gaining increasing importance within business applications, and SQL Server Reporting Services (SSRS) does a great job of making reporting easy. Even better, SQL Server 2008 adds some really great power and flexibility in terms of new options and graphing capabilities. But what about integrating reporting functionality into existing websites or non-intranet sites?

The ASP.NET ReportViewer Control

If you're like most developers, you've probably heard about the ASP.NET ReportViewer control, at least in passing. It's been around awhile: It shipped with Visual Studio 2005 and .NET Framework 2.0. This control frequently gets overlooked by developers looking to create reporting or graphing capabilities within their sites. This is really too bad, because it tool offers a number of huge benefits.

Ease of Use

The first benefit of ASP.NET ReportViewer is that it's easy to use. Provided that you have SSRS reports that you've authored on an existing Reporting Services server, you can set up reports within your web applications in just a matter of minutes. And, if setting up your own Reporting Server sounds like too much work, then read on, because there's an option to use this control without a Reporting Server. Otherwise, if you're doing any sort of reporting, you're going to be very hard pressed to find anything that equals SSRS in terms of flexibility, performance, and cost.

Of course, my assessment of how great SSRS is isn't to say that it's perfect or that there aren't a couple of issues with the learning curve that won't drive you nuts. But I've used it on numerous projects now, and every time I work with it I'm always amazed at just how powerful, flexible, and approachable it really is. Knowing how to author reports with it can also add a great boost to your resume, as many businesses these days are (mistakenly) prone to identifying reporting with business intelligence (BI).

In terms of how easy the ReportViewer control is to use, all you need to do is drop the control into an ASP.NET WebForm (its post-back model is incompatible with ASP.NET MVC pages), make a change to your web.config, and then point the control at your Reporting Services Server. Amazingly, everything you need to set up and configure is actually outlined in the documentation. Well, there is one thing missing—if you’re working in Remote mode, and dynamically populate the parameters, you'll need to call the ServerReport object's Refresh() method, as outlined below:

protected void Page_Load(object sender, EventArgs e){    if (Request.IsAuthenticated        && SiteSecurity.UserIsInRole("Analyst|LabTech"))    {        this.rptControl1.ServerReport.ReportServerUrl =            new Uri("http://myIntranetSSRS_Server/reportserver");        this.rptControl1.ServerReport.ReportPath =            "/FolderName/Ditto/MyActualTestName_NoExtensions_Etc";         string assoc = Request.QueryString["associationId"];         ReportParameter p = new ReportParameter();        p.Name = "AssociationId";        pIn.Values.Add(assoc);         this.rptControl1.ServerReport.SetParameters(            new ReportParameter[] { pIn });         // turn off controls:        this.rptControl1.ShowParameterPrompts = false;         rptControl1.ServerReport.Refresh();    }    else    {       // or... redirect to login... whatever.        throw new HttpException(403, "Not Authorized");        Response.End();    }}

 But other than that little tidbit, you can easily set up very powerful and robust reporting within mere minutes on your ASP.NET sites. (I've even added reports to MVC sites by “cheating” with the addition of “classic” ASP.NET pages thrown into the mix.) 

Security

To me, this is easily the biggest reason to use the ReportViewer control. Without it, your options for presenting SSRS-generated reports to web users are sparse. With SSRS 2005, you could open up anonymous access to the virtual directory being used on your web-server to host SSRS reports. But because SSRS 2008 no longer uses IIS (it's using its own web server), you no longer have that option. And, because a critical component of SSRS is the fact that its reports are rendered, or hosted, by a web-server, you'll find that you must provide windows credentials to be able to access the web server hosting your reports.

You can get around this limitation if you're using the Enterprise Edition of SQL Server 2008 Reporting Services and have a few extra days to try and figure out how to build your own authentication provider, or if you're willing to throw security completely to the wind and implement a couple of really spooky hacks listed out on the internet. Otherwise, anyone who wants to view your SSRS reports will need trusted, or Windows, authentication in order to be able to access reports, which obviously isn't compatible with forward-facing internet sites.

What makes the ReportViewer control so great though, is that it acts as a proxy that communicates with your sandboxed SSRS server, grabs reporting details for your users, and then renders those results out to your forward-facing website as needed. Best of all, as you can see in the code sample listed above, this lets you very easily integrate your own security functionality into place to restrict access to data by user or user type.

The secret to getting this proxying functionality to work is to tweak your web site's web.config to get it to impersonate a user that has Windows, or trusted, access to your Reporting Server. This could be NETWORK SERVICE if you want to grant it access to your Reporting Server, or it can be a specialized domain account (a much better option) that has been severely restricted. Either way, with just a quick tweak to your web.config (as outlined in the documentation) you're up and running.

Manageability

Of course, proxying data can add a bit of performance overhead. And if that poses a problem, you've got another very cool option as well: to run the report in Local Processing Mode. When reports are run in local mode, you don't even need a Reporting Services Server instance in the mix at all. (Meaning that you can run SSRS Reports without, well, a Reporting Server.)

Local Processing offers some very cool flexibility, and can be used to boost performance. But it does come with one or two penalties. First, if you're moving copies of existing reports down to your web server for local mode processing, then you'll end up creating two different definitions of your report (more on this in a second). This alone is enough to dissuade me from using local mode processing in all but the most specialized cases  because I don't want to have to make changes in two locations if I need to update formatting or change reporting options.

Closely related is the second problem, which is a fairly obvious issue: if you're creating SSRS reports without a Reporting Server, you won't be able to use the underlying DataSets created on your Reporting Server to populate the data in your reports. Obviously, that's not a big deal if you're creating these reports from scratch. But if you're converting existing reports for performance reasons, the previous penalty becomes compounded because Local Mode and Remote Mode reports use slightly differing report definition language (RDL) or syntax. Actually, the syntax (XML) is effectively the same. It's just that native SSRS Reports (which use .rdl extensions) contain integrated definitions for which data sources, DataSets, and other resources to use from the Reporting Server when it comes time to Render a Report. On the other hand, while Local-Mode reports use virtually the same syntax to define the parameters and formatting or layout, they're not able to take advantage of SSRS data-management infrastructure and have to be 'wired up' to use ADO.NET Data Sets created, or defined, on your Web Server. This slight difference in RDL files is enough to merit a new extension for Local Mode reports (.rdlc - where the "c" stands for 'client'), but it does make it 100% possible to create SQL Server Reporting Services Reports without any Reporting Server in the mix. (And this is true of WinForms applications as well.)

Putting the ReportViewer Control into Action

The best part though, is that you can set up your test of a Remote-Mode Processing report in less time than it's taken you to read this. Local-Mode reports will obviously take a bit more time to set up, but that's really only because you have to author the report first (as well as set up the data sources).

Either way, if you're looking for reporting functionality in any web site, you're missing out if you haven't take a solid look at what this control has to offer.