3

カスタム配信チャネルを作成したSQL通知サービスのインスタンスがあります。このプロセスは、SQLServer2005でWindowsServer2003を実行しているQA環境で実行されました。カスタムDLLを信頼できるようにするために少し調整が必要でしたが、すべて機能しました。

その後、このコードをライブ環境にデプロイしました。これにより、NotificationServices用のSQL2005のインスタンスを使用してWindowsServer 2008が実行されますが、NotificationServices用の実際のDBインスタンスをホストするSQL2008のインスタンスがあります。Notification Servicesは正常に機能しますが、カスタムDLLを信頼できるようにすることはできません。その結果、カスタム配信チャネルは機能しません。単にエラーが発生します

That assembly does not allow partially trusted callers

.NET構成ユーティリティとcaspol.exeを使用して、.dllに完全な信頼を与えることを試みましたが、まったく運がありませんでした。通知サービスがこれを必要とするため、.dllは.NET2dllとしてコンパイルされます。

現在、私たちはほとんどアイデアがなく、誰かが何かを提案できることを望んでいますか？

4

2 に答える 2

3

問題を修正することができました。Windows Server 2008は、コードアクセスの実装がより厳格であるように思われます。パスではなく厳密な名前で.DLLへのアクセスを許可することにより、NotificationServicesがコードにアクセスできるようになりました。

通知サービスに問題はありませんでした。

于 2011-11-22T11:49:39.973 に答える
-1

私はあなたが2つの選択肢のうちの1つを持っていると思います：

  1. SQL 2008を採用し、非推奨となったため、NotificationServicesを削除します。Reporting ServicesまたはSSISを使用して、必要なことを実行します。

  2. SQL2005に戻します。

私見、私はオプション1に行きます。非推奨のツールを使用してビルドを続けると、サポート（コミュニティまたはベンダー）を入手するのが非常に困難になる状況ですぐにあなたを見つけることができます。

アップデート

これはコメントするには長すぎました。

頭を悩ませることはありませんが、3年以上前にEOL（保守終了）されたテクノロジのアプリケーションを開発し続けることが最初の間違いでした。EOLステートメントはかなり公開されました。

2つ目は、本番環境とは根本的に異なるQA環境を用意することでした。本番環境に何かをデプロイする前に、QA環境は同一である必要があります...同じタイプのハードウェア、同じOS、同じサーバーバージョン、およびパッチレベル。そうでなければ、あなたが見つけたように、QAは冗談です。

さて、「解決策」に関しては、実際には1つのパスしかありません。適切なパッチを適用して本番環境をSQL2005に戻します。

私はあなたの幸運を祈ります。

于 2011-11-15T15:14:50.690 に答える