通知服務自定義傳遞通道DLL信任問題

我們有一個SQL通知服務的實例，我們爲其編寫了自定義傳遞通道。我們在運行帶有SQL Server 2005的Windows Server 2003的QA環境中運行了這個過程。它花費了一點時間來調整獲取自定義DLL的信任度，但是我們得到了一切。通知服務自定義傳遞通道DLL信任問題

我們已經將此代碼部署到我們的Live環境中。這將運行帶有SQL 2005實例的Notification Services實例的Windows Server 2008，但接下來我們有一個SQL 2008實例，它承載Notification Services的實際數據庫實例。 Notification Services可以正常工作，但由於定製傳遞通道無法工作，導致我們無法獲得自定義DLL。我們只是得到錯誤

That assembly does not allow partially trusted callers

我們使用.NET配置實用程序和的Caspol.exe給沒有運氣在所有.dll完全信任嘗試。 .dll被編譯爲.NET 2 DLL，因爲通知服務要求這樣做。

我們現在幾乎沒有想法，希望有人能提出一些建議嗎？

來源

2011-11-15 thisispaulsmith

我們設法解決了我們的問題。看起來，Windows Server 2008在其代碼訪問的實現方面更爲嚴格。通過以強名稱授予對.DLL的訪問權限，而不是允許Notification Services訪問代碼的路徑。

通知服務沒有錯。

來源

2011-11-22 11:49:39 thisispaulsmith

-1

我認爲你有兩個選擇：

擁抱SQL 2008和擺脫通知服務，因爲它已被否決。使用Reporting Services或SSIS來執行您所需的操作。
恢復到SQL 2005

恕我直言，我會去選擇（一）繼續建立與過時的工具，是要迅速找到你的情況下支持（社區或供應商）是將很難得到。

更新

這是徵求意見太長。

不要打得太多，但繼續開發3年前發生的EOL（生命結束）技術的應用程序是第一個錯誤。 EOL聲明已經公開。

第二個是質量保證環境與生產截然不同。在將任何東西部署到生產之前，QA環境應該是相同的......相同類型的硬件，相同操作系統，相同服務器版本和補丁級別。否則，正如你所發現的，質量保證是一個笑話。

現在，對於「解決方案」，實際上只有一條路徑：使用適當的補丁將生產環境恢復到SQL 2005。

祝你好運。

來源

2011-11-15 15:14:50 NotMe

是的我很欣賞在理想的世界中會發生什麼，然而刪除/替換通知服務需要大量的工作。我並不完全相信問題與不匹配有關。正如預期的，通知服務正在2005年之下運行。它只是與位於別處的數據庫進行通信。 – thisispaulsmith

事後總是讓我們更聰明。這並不回答問題，但是刪除通知服務在這裏不是一個選項。 – jaywayco

讚賞QA需要更新。除了簡單地撕掉一些東西並重新開始不是一個可行的選擇。如果每個問題的答案都是撕裂並做其他事情，那麼我們就不會做任何事情。就像我之前所說的，我不認爲這是通知服務的問題，只是內置在框架/窗口中的安全問題。如果直接是NS的問題，那麼它就不會在質量保證中起作用。 – thisispaulsmith

通知服務自定義傳遞通道DLL信任問題

回答

相關問題