我们有一个 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，因为通知服务需要这样做。
我们目前几乎没有想法，希望有人能提出建议吗？
我们已经设法解决了我们的问题。看起来 Windows Server 2008 在代码访问的实现上更加严格。通过通过强名称而不是路径授予对 .DLL 的访问权限，Notification Services 可以访问代码。
通知服务没有错。
我认为您有以下两种选择之一：
拥抱 SQL 2008 并摆脱通知服务，因为它已被弃用。使用 Reporting Services 或 SSIS 来完成您需要的工作。
恢复到 SQL 2005。
恕我直言，我会选择选项 1。继续使用已弃用的工具进行构建将很快发现您处于极难获得支持（社区或供应商）的情况。
更新
评论太长了。
不要太过头，但继续为 3 年前 EOL（生命终结）的技术开发应用程序是第一个错误。EOL 声明非常公开。
第二个是拥有与生产完全不同的 QA 环境。在将任何东西部署到生产环境之前，QA 环境应该是相同的……相同类型的硬件、相同的操作系统、相同的服务器版本和补丁级别。否则，正如您所发现的，QA 就是个笑话。
现在，至于“解决方案”，实际上只有一条路径：将您的生产环境恢复到 SQL 2005，并安装适当的补丁。
祝你好运。