MRU CONSULTING PTY LTD

MRU Consulting - MS SQL Server Reporting Services in WPF - What Are The Options?

Microsoft SQL Server Reporting Services is reasonably capable and one of the most-used reporting engine on the market. Although it is used by hundreds of developers in thousands of applications, SSRS always behind the newly appearing technologies. Introducing new development platforms, such as WPF, Silverlight and now WinRT, Microsoft forgets about poor Reporting Services developers which in order to follow the trends have to abandon SSRS, migrate to other reporting tools or spend weeks trying to find a workaround to adopt their reports to the latest technologies.

What are the most popular and "easy" ways to develop WPF, Silverlight, WinRT, etc applications and keep the Reporting Services there? This is a question I would like to answer in the series of articles and I let me start with WPF.

Reporting Services and WPF. Possible Solutions.

The subject is actively discussed in MSDN since 2008 and in the end Microsoft guys have offered some workarounds allowing integrating SSRS into WPF applications. The most popular of the offered solutions is to use WindowsFormsHost to host the ReportViewer control in a WPF application. Here you can find a detailed description of the approach:

http://msdn.microsoft.com/en-us/library/hh273267.aspx. Browsing the same MSDN among dozens of tips and tricks, I came across one more option that deserves attention. It's a third party tool - WPF Viewer for Reporting Services by Perpetuum Software. It is a WPF Viewer component that renders report in XAML format and displays them in a native

WPF viewer.

To my opinion, these are the most suitable options for using MS SQL Server Reporting Services in a WPF app. But what are the pros and cons of both these solutions? Let's try to see it by the most important features: appearance, integration, and the reports look and feel.

Appearance of the Viewer

First of all, the workaround suggested by Microsoft implies mixing two technologies: WinForms and WPF with all the consequences that come with it. The Viewer that displays reports using this approach is a standard WinForms viewer and of course it looks like a WinForms component without all the WPF "beauty" and features. As for Perpetuum

Viewer, it is a native WPF component that can be customized using styles and templates. It is possible there to create a custom toolbar, skin, background and other UI elements to make it fit the application interface. That is an obvious advantage of the Perpetuum component.

Integration and Configuration

Another aspect is integration and configuration. To use WindowsFormsHost for hosting the ReportViewer control is much easier approach in terms of integration and configuration comparing with WPF Viewer by Perpetuum.

Using Microsoft's WinForms Viewer

So, below are the basic steps required to enable view of SSRS report in WPF application using MS's workaround.

Create WPF app

Drag a WindowsFormsHost control onto the design surface for MainWindow.xaml to add the required assemblies

Add Reference to the Microsoft.ReportViewer.WinForms assembly

Add several lines of code to the XAML view to create an instance of ReportViewer:

Next, we just create a RDLC report (that is by the way, is not supported by WPF Viewer by Perpetuum) or take it from a server and display it in the ReportViewer control.

The main difficulty and disadvantage of Perpetuum Viewer is the necessity to install and configure a custom rendering extension on the server where the Reporting Services is installed. But, let's consider the required actions step-by-step:

Create a WPF application

Add references to the required assemblies

Create a WPF Viewer from the application: by adding xml namespace for the PerpetuumSoft.ReportingServices.Viewer.WPF

Open the MainPage.xaml.cs source code and add a few lines of code

Install PerpetuumSoft Xaml Rendering extension. The extension can be installed only to the SQL Server Editions which support custom rendering extensions, so it can be MS

SQL Reporting Services 2008/2008 R2/2012 Developer, Enterprise or Standard editions.

As it's mentioned above, the installation and configuration of the custom rendering extension is the most complicated and tricky part here, but as soon as everything is set up, it is possible to create new or add existing SSRS reports to your application. Thus, comparing the integration approaches of Microsoft and Perpetuum solutions, Microsoft obviously wins.

SSRS Reports Look-and-Feel

What about the quality of final Reporting Services reports presentation? Who wins this battle? Let's see...

From the Microsoft approach you may already conclude that reports comes in native Reporting Services view, thus, they look and feel the same as in a classic Reporting Services with all the information presentation features and abilities. But it lacks all WPF nativity features.

As for Perpetuum WPF Viewer, it renders a report in XAML format, and that is a native format for WPF. This ensures better quality of the reports presentation with all the advantages of WPF features - zoom in and out, panning, navigation, etc and without any loss of quality.

But XAML rendering differs from the standard Reporting Services rendering method, thus in some cases, a report in Perpetuum Viewer can slightly differ from the original SSRS report. And this can bring additional difficulties with a report template adjustment. But generally, the reports are presented "AS IS" with the support for original features, such as parameters, drill-through, drill-down, etc.

And now let's resume the main pros and cons of Microsoft and Perpetuum solutions in a single table to see better which one is better:

As we can see both approaches have pros and cons. If choose the easy and free way, without paying too much attention to the quality of Viewer appearance and report presentation quality, then Microsoft's workaround works pretty well. But if you want to keep WPF nativity of your application look-and-feel, and quality report presentation then the right option is WPF Viewer for Reporting Services by Perpetuum. And the last thing - Perpetuum solution is not for free.

Any alternatives?

Of course there are alternatives - we can always find another reporting tool for WPF. There are plenty of them on the market: Telerik Reporting, XtraReports by DevExpress,

SharpShooter Reports. WPF by the mentioned Perpetuum Software, etc. Using these tools, you can develop report templates and integrate into your WPF application using the

WPF Viewers. That's simple and straightforward approach. But this is one more tool for a developer to buy, explore, and the most important - redesign the report templates. And this can be a big problem if your application has dozens of functional reports which already took much time on development.