如何管理 .NET 中报表的更改？
我需要提供从 .NET 应用程序查看和打印报告的功能。但我需要能够修改报告模板，而无需重新编译应用程序。我看到有 2 个选项：
- 使用报告组件，例如
Microsoft.Reporting或Crystal Reports使用.rpt（或类似）文件 可以根据需要修改，无需 必须使用 System.Drawing.Printing 重新编译应用程序 - 并将模板数据存储在数据库中，这使事情变得更简单 并避免庞大的报告组件的问题
选项 1 是否有效，是否可以避免重新编译应用程序？
方案2可行吗？如何将模板数据存储在数据库中，以便无需重新编译应用程序即可对其进行修改？
编辑：使用选项 1，您是否需要在编译之前定义“数据源”？
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
orCrystal Reportswhich uses a.rpt(or similar) file that
can be modified as required without
having to re-compile the app - use
System.Drawing.Printingand 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 data 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根据我的观点和经验，Crystal Reports 是维护的噩梦。我相信在这些报告的生命周期中维护这些报告需要付出比创建报告更多的努力。它是一个老产品DOS产品，已经被“黑客攻击”了太多次。
我真的很喜欢微软报告。易于创建且易于维护。我特别喜欢独立报告 (rdlc)，它消除了对 Sql Server Reporting Services 的需求。 （我不确定最后一句在技术上是否正确，但您明白了。）
我使用 System.Drawing.Printing 来简单打印用户界面显示的信息。 （简单包括横向和纵向的多个页面。）我总是在编码之前首先考虑 Microsoft Reports。特别是，因为用户在看到实际报告后总是会更改他们想要的内容。因此，编码可能需要付出相当大的努力。这就是为什么我通常只处理用户界面信息，例如列表、表单或其他明确定义的信息，在这些信息中我可以利用控件现有的“绘制位图”方法。
我对“报告模板”没有经验。微软的rdl和rdlc是XML文件。因此，它们易于操作和存储。将 XML 存储在数据库、文件系统或作为资源中应该没有问题。我已将二进制 Microsoft Excel 工作簿存储为资源文件，根据用户条件对其进行修改，然后在 Excel 中将其作为模板打开。如果我可以在 Excel 中执行此操作，那么报告应该很容易。
我不知道水晶报表的更高版本，但在运行时修改旧版本报表的布局和数据字段是从不可能到难以忍受的困难。我几年前做过一次。我无法添加或删除字段，因此我必须包含所有字段，然后根据需要隐藏/显示每个字段。由于所有静态字段，这使得设计报告变得困难。我认为我可以比通过 Crystal Reports 创建报告更快地手动编写报告。
Crystal Reports 是单独部署和安装的。您需要阅读一些许可问题。 Microsoft Reports 是.NET Framework 的一部分。
这是我的两分钱。我强烈建议您避免使用 Crystal Reports。我真的很喜欢微软报告。我无法推荐其他报告系统，但我听说过有关 ActiveReports 和 ComponentOne 的好消息。微软还提供了一个免费的图表库。 （搜索 MSDN 下载。）
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.)
我从未使用过前面提到的 Microsoft 报表引擎，所以我不能对它们说什么。
我在 combit List&Label。它是一个基于模板的报告引擎（您的报告可以独立于您的应用程序而发展）。您需要做的就是将报告的数据交给它（它支持对象源和数据表）并告诉它要使用哪个模板。
List&Label 包含一个出色的报表设计器，您可以与您的应用程序一起分发，具有随时可用的预览组件，并支持开箱即用的 PDF 打印。
在维护方面，您只需要注意一件事：更改数据源的架构
破坏已部署的报告
模板，没有办法
自动迁移它们。
除此之外，价格标签（我认为大约 1.5k，但它是开发人员许可证，这意味着您可以根据需要为任意数量的用户部署任意数量的应用程序），这是一个非常灵活和可靠的解决方案。
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.
你的#1 是“托管一个显示文档的组件”——所以应该没问题。如果您在应用程序中托管 MSWord，则更改 .doc 文件并不意味着您必须重新构建应用程序。这也是同样的原理。
#2 是可行的，但由于您显然正在做一些复杂到需要考虑 Crystal Reports 或 ReportViewer 的事情，因此它可能不可行。您基本上是建议您编写自己的更简单（且有问题且更难以维护）的 Crystal 版本。除非您有真正令人信服的理由不这样做，否则我会坚持使用现成的解决方案。
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.
您可以将报告添加为 .rdlc 文件（在 Visual Studio 中选择报告作为新项目），并使用
Winforms.ReportViewer（这是您的选项 1 ...我想，除了它不是水晶）。没有第三方组件，全部内置于 .NET 中。在我看来，它比 Crystal 更容易用于基本报告。使用 .rdlc 有一些问题，但 Crystal 也有一些问题。但由于它是内置的，因此它肯定比 Crystal 更容易部署。报告模板文件以 .rdlc 扩展名保存，但实际上它只是 XML，您可以指定它位于编译的应用程序之外。当然，您可以修改 XML 文件而无需重新编译。我们的应用程序就是这样设置的，因为像您一样，我们需要能够允许修改。
修改 XML 允许您完全控制更改报表的布局和/或数据。
XML 中的
DataSets节点指定报表期望推送给它的数据对象。因此，如果您想向报告发送完全不同类型的数据，那么可以通过重写该节点来实现。它不能容忍您发送到报告的内容与期望收到的内容之间存在任何不匹配。这是唯一让它变得格外繁琐的事情。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
DataSetsnode 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.选项 #1 绝对适用于 ActiveReports 的 RPX 格式。有关详细信息，请参阅此页面。事实上，ActiveReports 比没有组件更“庞大”，但 xcopy 部署灵活性和微小的 DLL 使其比大多数组件都更“笨重”。
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.