Building Report-enabled Applications with the New ReportViewer Controls (Part 2 of 2) : Page 5

Local Mode
The local processing mode of the Web ReportViewer is almost identical to the WinForms ReportViewer, so porting the code from the first part of this article was trivial. There are only a few things worth mentioning.

First, since the external images now reside on the server (not on the local hard drive), you need to set the Value property of the image to its URL address. For example, the URL address of the logo image in the Customer Orders report is http://localhost/WebReporter/Reports/AWC.jpg. To implement this, I changed the GetAppPath embedded function inside the report, as follows:

   Public Function GetAppPath() As String
      return  String.Format("http://{0}{1}/", 
         System.Web.HttpContext.Current.Server.MachineName, 
         System.Web.HttpContext.Current.
         Request.ApplicationPath)
   End Function 

As a prerequisite, I had to reference the System.Web.dll in the report properties. In addition, I had to configure the Web ReportViewer to trust this assembly by adding the following line in the RunLocal function:

   reportViewer.LocalReport.
      AddTrustedCodeModuleInCurrentAppDomain(
      "System.Web, Version=2.0.0.0, Culture=neutral," + 
      "PublicKeyToken=b03f5f7f11d50a3a");

Finally, due to the different targeted platform, the Web ReportViewer supports a somewhat different set of events. The most noticeable missing event is the Hyperlink event. To implement a similar functionality, I had to change the "Jump to URL" link of the Customer field in the Customer Orders report.

   =Code.GetAppPath() & "default.aspx?customerId=" 
      & Fields!CustomerID.Value

In my case, I wanted the page to post back and pass the customer identifier as a query string when user clicks on the customer field. The Page.Load event reacts to this condition by calling the ReportHyperlink, which can then handle the event any way it deems necessary.

The Web ReportViewer can help you tremendously to report-enable your custom ASP.NET 2.0 applications. You should definitely consider it to reduce the amount of plumbing code required to integrate with Reporting Services. Intranet applications should leverage the Windows security infrastructure already in place. If Internet-facing applications don't need to pass the user identity to the Report Server, consider the trusted subsystem approach. If this is not the case, configure the Report Server and the ReportViewer for custom security.

I hope that this two-part article gave you a good understanding of how the ReportViewer controls work. From here, I suggest you review the resources available on the ReportViewer Web site. Also, make sure to check the ReportViewer newsgroup on MSDN where you can post questions and get feedback from the technical community.

Previous Page