RDLC在程序集中重新初始化静态数据

Question

我有一个带有 RDLC 报告的 ASP.NET 应用程序。魔术发生在我在主 ASP 应用程序中引用的单独程序集中。我在这个程序集中有一些静态数据，我想在它们被 RDLC 报告系统序列化和反序列化后在我的对象中引用它们。

我发现静态字段在 RDLC 报告运行期间重新初始化，也许 RDLC 正在加载程序集的新副本。因此，我的对象在静态数据上命中 null refs，而我期待之前设置的数据。

这里发生了什么？有没有办法确保只加载一个程序集的副本？

Answer 1

原因似乎是 RDLC ReportViewer 在单独的 AppDomain 中运行，因此不与主应用共享内存。

我花了几个小时重构我的数据库类，以便它们可以被序列化然后反序列化，这一切都是为了 RDLC 的利益，结果发现在反序列化之后他们无法分配正确的数据库提供程序，因为那是坐在 RDLC 看不到的静态类中，因为它在不同的 AppDomain 中运行。

这是我第一次真正听说过 AppDomains，所以我无法搜索这些相关的问题来阐明这个问题：

• Does ReportViewer run in a separate AppDomain?
• .NET LocalReport / .rdlc AppDomain issues
• What happens to the static data in a class if it is accessed across app domains?
• Sharing data between AppDomains

我找到了强制报告在当前 AppDomain 中运行的提示，该 AppDomain 已过时并且需要启用 CAS，但我无法在我的项目中使用它（我只尝试了一小会儿）：

• https://msdn.microsoft.com/en-us/library/microsoft.reporting.winforms.localreport.executereportincurrentappdomain.aspx
• https://docs.microsoft.com/en-us/dotnet/framework/misc/code-access-security-policy-compatibility-and-migration

最后，我决定正确的解决方案不是做代码体操来欺骗 ReportViewer 处理我的数据 - 而是为报告提供一个简单的 POCO，它可以轻松序列化和反序列化，并且没有复杂的依赖关系.

这就是为什么 DB 对象应该简单且易于序列化的一个很好的理由，并且业务逻辑应该位于 DB 对象之上的单独对象/包装器中。我这些复杂的“神物”已经困扰了我一段时间了！