In the previous article, we discussed two new industry trends impacting .NET reporting tools and components. .NET Reporting Tool Example (Ref: ActiveReports) In this article we will review the traditional requirements for developer focused reporting capabilities that the best .NET reporting tools must meet. In an upcoming article, we will drill down into the new requirements (based on identified industry trends).

1. Deep integration with Microsoft Visual Studio™

A developer's primary environment for building applications is Microsoft Visual Studio™, where they combine code, components and tools to create the final solution. A reporting tool should be seamlessly integrated with Visual Studio's projects, controls and libraries, allowing developers to use it just like any other component.

2. Allow creation of documents such as income tax and W4 forms

Thanks to the trend of paper-intensive processes going electronic in government and administration and because of the increasing need for regulatory compliance, reporting tools are increasingly being used to generate precise, fixed-layout paper forms and documents.

3. Offer a variety of report formatting elements

A reporting tool should allow developers to combine tables, charts, crosstabs and a ton of business data visualization elements within the reports.

4. Programming interface for easy integration and dynamic reporting

A .NET reporting tool or component should allow developers the freedom to architect, develop and test reporting code just as they would write code for other parts of an application. Check for a granular and flexible API complete with support for event-based programming that allows complete control over reports at run time. To assess how easy it is to use the API, try to write a reporting application with a medium degree of complexity. It should feel reasonably intuitive to design, write and maintain the code.

5. Report viewing options for all platforms and devices

Even expertly crafted reports hold little value if end users cannot access them easily. The tool should allow end users to interactively view reports regardless of whether they are using a desktop, Web browser or a mobile application. From a developer's perspective, the tools should support report viewing for popular Windows development platforms such as for WinForms, WPF, ASP.NET, Silverlight and Flash.

6. Provide a stand-alone end user report designer that's embeddable

A stand-alone Windows-based end user report designer allows non-developer IT users to make changes in reports outside of Microsoft Visual Studio™. Look for the end user report designer to be also available as a control that can be dropped into your applications to provide the same capabilities for power users once the application has shipped.

7. Built-in charts, bar codes and other data visualization elements

No reporting tool is complete without ways to visually present data. Make sure that the chosen reporting tool not only includes a wide variety of commonly used 2D and 3D charts, XY charts, financial charts, barcodes and other formats, but that it also makes it easy to embed, customize and aggregate groups of charts within one report.

8. Reporting off relational, .NET and cloud data sources

In addition to connecting to standard databases, a .NET reporting tool should be able to report off .NET in-memory objects and collections. Also verify that the tool can work with unbound data, because that means that the tool can report on practically any data format from any stream. Note that to be able to render the data within a Windows Azure application, the tool must be compatible with the Windows Azure run-time environment.

9. Export reports to Microsoft Office, Adobe PDF, Google Docs and Images

In addition to seamless online viewing, end users will need to share their reports with their peers and other stakeholders in offline formats. They will expect to save reports as Adobe PDF™, Microsoft Word™, Excel, RTF, Google Docs, XML documents, and even as images for easy sharing. Check if the chosen .NET reporting tool allows this using the report viewers and via code written within applications. It should be flexible enough to provide both options.

10. Fast performance when dealing with large data sets

Report generation will commonly involve corralling large data sets that may result in the production of hundreds of thousands of records. The reporting tool should be fast and efficient in how it processes large rows of data, and it should provide ways to further optimize report generation. For extremely large data, the tool should gracefully handle any processing delays and exceptions that might occur and provide ways to minimize slow response times.

11. Advanced printing capabilities.

Printing is an essential requirement for any reporting tool. Printing reports should be not only easy but powerful and fast as well. Developers should be able to configure duplex printing, printing of multiple copies and page orientation both at design time and at run time. The tool should enable end users to print a report from multiple bins available in a printer. Be sure to check for advanced printing options such as page scaling, n-up printing and watermarks. Finally, the reporting tool should be able to handle large print orders and gracefully handle any printer or connection errors.

12. Proven internationalization and localization capabilities

Developers should build applications that are internationalized from the ground up. To enable this, the tool should use an architecture that is localization-friendly. For example, using standard .NET localization satellite assemblies allows localized labels for the user interface within the report layout. Also, check if the reports themselves are enabled for localization: the reporting engine should be able to use locale-specific text and formatting without the need to create multiple reports.