Build the project, then right-click on the project and select Add > New Item… Under the Reporting category, choose the Report Wizard template. This will be the structure of the data you'll use for the report. Then edit the Class1.cs file generated by the template, rename both the file and the class to OrderInformation, and add properties to it, as shown in Figure 1.įigure 1: The OrderInformation.cs data structure used by the report Name the project CloudReporting.Reports and name the solution CloudReporting. I'm going to use the Class Library project template.Ĭreate a new Solution with a Class Library project. Pretty much any project type except MVC supports the ReportViewer control.
As a work-around, I'm going to create the reports in a different project.
As of Visual Studio 2015 Update 3, this is still the case. I'm going to save you a lot of time and research by telling you right off that the ReportViewer control isn't supported in MVC projects and that you won't be a happy camper if you try to use it one in an MVC project. NET business application framework to see how you'd really build the services for maximum effectiveness.
For this article, I'm going to keep it simple and only build for Web API, but see the sidebar about using CODE Framework, a free and open source.
Of course, services are services, so you could just as easily host them in WCF or even as a classic Web Service. I'll also create an ASP.NET MVC application to demonstrate calling the reports from a browser, so you're going to use that website to host the services and kill two birds with one website. In this article, I'll be exposing reports via Web API.
Here's how to move your report generation into your services where you can run them on-premises or in the cloud and share them among browser, mobile, desktop, and B2B systems. Still, there was no reason it shouldn't work, and it did work. Why not use the ReportViewer control in a service to render and export reports without a UI control? We'd already done something similar in some WPF applications to send reports directly to a printer without first displaying the ReportViewer control on screen, but that was all done in the client. There's nothing preventing us from instantiating a TextBox in code and never showing it on a screen (nor is there any reason I can think of to do so). What if we used the controls as report generators instead of viewers? After all, like every UI control, they're just classes.
The ReportViewer controls were designed to be placed on Windows Forms or Web Forms as a way to view reports, but the controls can also render the reports and export them to various formats. In the past, our team had done all the usual work-arounds to use the ReportViewer control in our WPF and ASP.NET MVC apps and it worked okay, but when we stumbled across a bunch of articles while researching how to print reports without first pulling up the report within the control, a fun, new thought came to mind. Although I find the report designers in SSRS and VS to be a bit clunky and temperamental, I've always liked the way they store report definitions in a non-proprietary XML format and the fact that they're well known, built into the tools we use every day, and free. That's when I brought up Visual Studio reports again. SQL Server Reporting Services (SSRS) fared a little better because it has powerful server-side rendering features and can be called as a service as well as having a native browser-based user interface, but it was set aside because it can be expensive to set up and run, especially in the cloud where it has to be run and maintained on expensive virtual machines. Visual Studio comes with a report designer, but that idea was scuttled early because Visual Studio's reporting capabilities are stuck in old technologies like WinForms and Web Forms and nobody wanted to go there. None of the ideas were proposed with much enthusiasm and none were received with much enthusiasm either.
A few ideas were thrown out during the meeting about how to handle the system's reporting needs, ranging from rendering Web pages in a print-friendly format so that they can be printed from the browser, to using custom libraries to render the lists in PDF format, to offloading the whole endeavor to a tool like Crystal Reports that wasn't integrated into the system. These days, the attention goes to increasingly novel ways of delivering information. It's a subject that doesn't get much press and not many developers give it much thought anymore, as it's a subject widely considered to have been solved years ago. Reporting isn't a sexy subject, but most business applications still need reports sometimes they need lots and lots of reports. I was surprised recently when a group of highly capable developers discussing the architecture of a new cloud-based system got stuck on the topic of how to do reports.