通知服务自定义传递通道DLL信任问题

本文关键字：DLL 信任 问题 通道 服务 自定义 通知 | 更新日期: 2023-09-27 18:14:46

我们有一个SQL notificationservices实例，我们为它编写了一个自定义交付通道。我们在运行Windows Server 2003和SQL Server 2005的QA环境中启动并运行了这个过程。这花了一点时间来获得自定义DLL的信任，但我们让它全部工作。

我们已经将这些代码部署到Live环境中。这运行Windows Server 2008与一个SQL 2005的通知服务实例，但我们有一个SQL 2008的实例，它承载了通知服务的实际DB实例。通知服务可以正常工作，但是我们无法使自定义DLL受到信任，因为自定义传递通道无法工作。我们只得到错误

That assembly does not allow partially trusted callers

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

我们现在几乎没有主意了，希望有人能提出一些建议?

通知服务自定义传递通道DLL信任问题

我们已经设法解决了问题。Windows Server 2008似乎在代码访问的实现上更加严格。通过授予对. dll的强名称而不是路径的访问权限，通知服务可以访问代码。

Notification Services没有错。

我认为你有两个选择:

  1. 拥抱SQL 2008并摆脱通知服务，因为它已被弃用。使用报告服务或SSIS做你需要的。

  2. 返回SQL 2005

恕我直言，我会选择选项1。继续使用已弃用的工具进行构建将很快使您陷入难以获得支持(社区或供应商)的境地。

注释太长

我不想让你太头疼，但继续为一项3年前就已经结束生命的技术开发应用程序是第一个错误。EOL的声明是公开的。

第二个是拥有一个与生产完全不同的QA环境。在将任何部署到生产环境之前，QA环境应该是相同的……相同类型的硬件，相同的操作系统，相同的服务器版本和补丁级别。否则，你会发现QA就是个笑话。

现在，至于"解决方案"，实际上只有一条路径:将生产环境恢复到SQL 2005，并安装适当的补丁。

祝你好运

相关文章：