After some preliminary research, we created a shortlist of the most commonly used tools to choose from:

• SQL Server Reporting Services (SSRS)
• ActiveReports (by ComponentOne)
• Combit Reports
• Telerik Reporting
• Crystal Reports (by SAP)

The project had a very tight deadline, so we had to make the selection fast. Given the limited time we had, we decided to cut the list even further. Our (subjective) opinion was that Telerik and Combit seemed to be inferior in terms of the amount of online support available and number of active users. SSRS was too dependent on the DB system, which would require additional administration/deployment attention. We were looking for a more standalone solution – possibly, a fairly small library that we could use in our code. We decided to limit our options to ActiveReports and Crystal Reports as they both seemed to fit our needs best. Both of them could be used with Visual Studio, which was a must-have feature for us as C# developers. They also utilized the Visual Studio graphic designer, which made working on layouts easier. We created a short proof-of-concept which showed that ActiveReports was easier to work with (especially when it came to binding data in runtime) and there seemed to be more support for its integration with Visual Studio.  So, without further ado, we proceeded with ActiveReports. Here are some insights on the key issues we were faced with when working with ActiveReports 8.

Custom object datasources

Although each of the tools provide a wide choice of data sources to use, we needed the data to be bound in runtime (right in C# code). ActiveReports proved to have a really straightforward support for that. It was as simple as assigning a collection of objects as a report’s datasource. This gave us enough flexibility to customize the reports in C# code (which is what developers like best).

Multiple datasources in one report

Our goal was to create a multi-page PDF, with each page essentially being a separate table, each bound in runtime. Needless to say, the task was more complex than a typical one-table report you can find in most of the available tutorials . With that said, after the POC work we decided to drop the initial approach of creating a ‘Page Report’ (one of report types available in ActiveReports) and went with a code-based ‘Section Report’ instead. This proved to play much better with our complex data-binding schemes (this method of dealing with data-binding also seemed more natural from a developer’s perspective).

Stylesheets

One particular area where ActiveReports fell short is the way it handles stylesheets. First of all, the options are limited almost exclusively to font style (as can be seen in the screenshot, not quite as many properties as we’re used to in CSS). Also, reusing the styles over multiple reports is not as straightforward as expected. Of course, styles can be exported to a file (XML) but every time the file changes it needs to be imported again to each report separately – which can be painful and should be something to consider when using multiple subreports (as many as 10 in our case…). The ability to point to a style file without having to click-through and re-import styles would have made it much easier.

Conclusion

To sum up, ActiveReports seem to be a decent choice when you’re looking for a reporting tool that can be used from C# code. It has some limitations that at times might be frustrating to someone used to HTML/CSS web development. But it seems to be good value for an out-of-the-box support for typical reporting needs, since in most cases such documents don’t require flashy styling.

‍