How to manage changes to reports in .NET?_问答_开发者

I need to offer the ability to to view and print reports from a .NET app. But I need to be able to modify the report templates without having to re-compile the app. I see that there are 2 options:

use a reporting component such as Microsoft.Reporting or Crystal Reports which uses a .rpt (or similar) file that can be modified as required without having to re-compile the app
use System.Drawing.Printing and store template data in a database, which keeps things simpler and avoids problems of bulky reporting components

Does option 1 work, and does it avoid the need to re-compile the app?

Is option 2 viable? How would you store the template dat开发者_StackOverflowa in a database so that it can modified without having to re-compile the app?

EDIT: with Option 1, do you need to define 'data sources' prior to compiling?

In my opinion and from my experience, Crystal Reports is a maintenance nightmare. I believe it takes more effort to maintain these reports over their life that it does to create. It is an old product DOS product that has been "hacked" too many times.

I really like Microsoft Reports. Easy to create and easy to maintain. I especially like the standalone reports (rdlc) that eliminates the need for Sql Server Reporting Services. (I am not sure the last sentence is technically correct, but you get the idea.)

I have used System.Drawing.Printing for simple printing of information displayed by the user-interface. (Simple includes multiple pages across and down.) I always consider Microsoft Reports first before coding. Especially, since users always change what they want once they see the actual report. Therefore, coding can take considerable effort. That is why I usually only do user-interface information, such as listing, forms, or other well-defined information, where I can take advantage of a control's existing "draw-to-bitmap" methods.

I have no experience with a "report template". Microsoft's rdl and rdlc are XML files. Therefore, they are easy to manipulate and store. You should have no problem storing the XML in a database, in the file system, or as a resource. I have stored binary Microsoft Excel Workbooks as resource files, modified them based on user criteria, then opened them in Excel as templates. If I can do this for Excel, a Report should be easy.

I do not know about later versions of Crystal Reports, but modifying the layout and data fields of reports of older versions at run-time was from impossible to unbearably difficult. I did this once years ago. I could not add or remove fields, so I had to include all fields then hide/show each field as needed. It made designing the report difficult due to all the static fields. I think I could have coded the report by hand faster than it took to create the report through Crystal Reports.

Crystal Reports is a separate deployment and install. There are licensing issues that you need to read up on. Microsoft Reports are part of the .NET Framework.

That is my two cents. I strongly recommend that you avoid Crystal Reports. I really like Microsoft Reports. I cannot make a recommendation of other reporting systems, but I heard good things about ActiveReports and ComponentOne. Microsoft also provides a free charting library. (Search MSDN Downloads.)

I have never worked with the previously mentioned Microsoft Report engines, so I can't say anything about them.

I have made very good experiences with combit List&Label. It's a template based report enginge (your reports can evolve independent from your application). All you need to do is handing it over the data for your reports (it supports object sources and DataTable's) and tell it which template to use.

List&Label includes a great report designer you can distribute alongside your application, has ready-to-use preview components and supports PDF printing out of the box.

In terms of maintenance, there's only one thing you need to take care of: Changing the schema of the datasource breaks already deployed report templates, there is no way you can automatically migrate them.

Besides that and the price tag (I think it's around 1.5k but it's a developer license, which means you can deploy it with as many applications for as many users as you wish) it's a very flexible and solid solution.

Your #1 is "host a component that displays documents" - so it should be fine. If you were hosting MSWord in your application, changing a .doc file wouldn't mean you'd have to rebuild the app. This would be the same principle.

#2 is doable, but since you're evidently doing something complicated enough to consider Crystal Reports or ReportViewer, it's probably not viable. You're basically suggesting that you write your own simpler (and buggier, and harder-to-maintain) version of Crystal. Unless you have a really compelling reason to do otherwise, I'd stick with the off-the-shelf solution.

You can add your report as an .rdlc file (choose Report as your new item in Visual Studio), and use Winforms.ReportViewer (this is your option 1 ... I think, except it's not Crystal). No third party components, it's all built into .NET. In my opinion it's easier to work with than Crystal for basic reporting. Working with .rdlc has some gotchas but then so does Crystal. But because it's baked in, it's certainly easier to deploy than Crystal.

The report template file is saved with an .rdlc extension, but really it's just XML and you can specify that it lives outside the compiled app. Certainly you can modify the XML file without recompiling. Our apps are set up that way, because like you we needed to be able to allow modification.

Modifying the XML allows you full control to change the report's layout and/or data. The DataSets node in the XML specifies the data objects the report expects to have pushed at it. So if you want to send a completely different type of data to the report then, yes, that's possible by rewriting that node. It isn't tolerant of any mismatch between what you send to the report and what it expects to receive. That's the only thing that makes it extra fiddly.

Option #1 definitely works with ActiveReports' RPX format. See this page for more information. Indeed, ActiveReports is more "bulky" than no component at all, but xcopy deployment flexibility and tiny DLLs make it less bulky than most.