Notification Services 自定义传递通道 DLL 信任问题答案

【问题标题】：Notification Services custom delivery channel DLL trust issueNotification Services 自定义传递通道 DLL 信任问题
【发布时间】：2011-12-29 14:17:34
【问题描述】：

我们有一个 SQL 通知服务实例，我们为此编写了一个自定义传递通道。我们在运行 Windows Server 2003 和 SQL Server 2005 的 QA 环境中启动并运行了这个过程。为了让自定义 DLL 受信任，我们进行了一些调整，但我们让这一切正常运行。

我们已经将此代码部署到我们的 Live 环境中。这运行 Windows Server 2008 和通知服务的 SQL 2005 实例，但是我们有一个 SQL 2008 实例，它托管通知服务的实际数据库实例。 Notification Services 可以正常工作，但是我们无法让自定义 DLL 受信任，因为自定义传递通道无法正常工作。我们只是得到错误

That assembly does not allow partially trusted callers

我们已经尝试使用 .NET 配置实用程序和 caspol.exe 来给予 .dll 完全信任，但一点运气都没有。 .dll 被编译为 .NET 2 dll，因为通知服务需要这样做。

目前我们几乎没有想法，希望有人能提出建议吗？

【问题讨论】：

标签： c# sql-server trust notificationservices

【解决方案1】：

我们已经设法解决了我们的问题。看起来 Windows Server 2008 在代码访问的实现上更加严格。通过使用强名称而不是路径授予对 .DLL 的访问权限，Notification Services 可以访问代码。

通知服务没有错。

【讨论】：

【解决方案2】：

我认为你有两个选择之一：

拥抱 SQL 2008 并摆脱通知服务，因为它已被弃用。使用 Reporting Services 或 SSIS 完成您需要的工作。
恢复到 SQL 2005。

恕我直言，我会选择选项 1。继续使用已弃用的工具进行构建将很快发现您处于极难获得支持（社区或供应商）的情况。

更新

这对 cmets 来说太长了。

不要太过分了，但继续为 3 年前 EOL（生命周期结束）的技术开发应用程序是第一个错误。停产声明相当公开。

第二个是与生产环境截然不同的 QA 环境。在将任何东西部署到生产环境之前，QA 环境应该是相同的……相同类型的硬件、相同的操作系统、相同的服务器版本和补丁级别。否则 QA 就是个笑话，正如您所发现的那样。

现在，至于“解决方案”，实际上只有一个途径：将您的生产环境恢复到 SQL 2005，并安装适当的补丁。

祝你好运。

【讨论】：

是的，我很欣赏理想世界中会发生的情况，但是删除/替换通知服务需要大量工作。我不完全相信问题与不匹配有关。由于通知服务按预期在 2005 年运行。它只是与位于其他地方的数据库进行通信。
事后诸葛亮总是让我们更聪明。不过，这并不能回答所提出的问题，此处不能选择删除通知服务。
感谢 QA 需要更新。除了简单地撕掉一些东西并重新开始之外，这不是一个可行的选择。如果每个问题的答案都是撕毁并做其他事情，那么我们将永远无法完成任何事情。就像我之前说的，我不认为这是通知服务的问题，只是框架/窗口中内置的安全性。如果这是直接与 NS 相关的问题，那么它不会在 QA 中起作用。