目前，我们所有的报告都写在存储过程中。我们希望开始将其从 SQL 平台移开，而是将大部分逻辑集中在 .NET 代码中。原因包括使用我们的 ORM 实体、易于调试、并行处理、与业务逻辑更加统一等。
我们面临的问题是，通过将报表逻辑移动到 .NET 代码中，我们无法像在生产环境中运行脚本那样轻松地部署支持修复。发布二进制文件意味着整个企业必须停止使用我们的应用程序，这在办公时间几乎是不可能的。
一种解决方案是将每个报告分离到一个新项目中并仅发布该 DLL。问题在于我们有超过 500 份报告。维持这将是一场噩梦。
有没有人遇到过类似的事情或有任何其他解决方案来解决这个问题？
谢谢，戴夫
为什么不使用报告服务？它就是为此而生的！您甚至可以培训业务人员（非开发人员）为您创建报告并发布。用户可以利用的功能太多了。认证/授权、订阅、导出（PDF、Excel、Word）等
如果我是你，我不会投资重建 Reporting Services。作为应用程序或“代码”的一部分，我总是不去写报告。
如果您真的非常想这样做（我完全认为您不应该这样做），那么我将开发一个单独的服务来生成您可以从主应用程序调用的报告（在单独的端点上）。当您需要更新时，在中间放置一个存储“报告请求”的队列，并且可以在重新启动后处理请求。
其他选择是动态加载程序集。让 filewatcher 监视一个文件夹，一旦有新的 dll 动态加载它。卸货更困难。您可以在不太忙时重新启动服务以从内存中删除旧报告，或者您需要创建可以卸载的单独应用程序域。
有很多选择，但同样，您将浪费时间构建和测试自定义报告框架。我会选择纯 SQL，即使你真的喜欢 C#，这样你就可以雇佣一个可以创建报告而不是开发人员的 BI 人员。
我非常同意@bart 的回答。我的第一反应是，这似乎是一种不必要的改造。
但是，如果您确实需要 .net 代码和声明性代码的便利性，那么为什么不使用基于 DLR 的语言，例如 Iron python？
我们已经在数据库中存储了 Iron python 并按需加载它。一旦 jitted 它与任何非基于 dlr 的代码没有什么不同，部署修复程序就是一个梦想。