私たちの.netプロジェクトでは、サードパーティ独自のCLI DLLを参照しています。このDLLは、独自のC++ライブラリへのインターフェイスに過ぎません。私たちのプロジェクトはasp.net（MVC4/Web API）Webアプリケーションです。不安定なDLLの参照
C++アンマネージドライブラリは、むしろ不安定です。場合によっては、例えばぶら下がっているポインタ。私たちはそれを解決する方法がなく、このライブラリを使用することはファーストクラスの顧客要件です。
アプリケーションがクラッシュすると、IISのアプリケーションプールは応答しなくなります。私たちはそれを再起動しなければなりません。そうするには数分かかります。
この不安定なDLLがアプリケーションをクラッシュさせないようにします。それをする最善の方法は何ですか？ CLI DLLを別のAppDomainに保存できますか？どうやって？
ありがとうございます。
私は最初にIISプロセスのリクライニング速度を高めます。特定の呼び出し回数の後、またはプロセスが一定量のメモリ使用量に達した後に、DLLコードが失敗する可能性があります。
現在地IIS 7.0リサイクルオプションの設定についての情報を見つけることができます：あなたがアプリケーションにあまり負荷が知っているとき、あなたの場合はhttp://technet.microsoft.com/en-us/library/cc753179(v=ws.10).aspx
私は、特定の時間にプロセスをリサイクルします。そして、特定の数のリクエスト（デフォルトよりも低い）の後で、ほとんどの場合「新鮮な」プロセスを試してみてください。
リサイクルプロセスは、古いプロセスが置き換えられるまで準備が整っていないという意味では優雅です。そのため、顕著なダウンタイムは発生しません。 リサイクルメカニズムの詳細はこちらhttp://technet.microsoft.com/en-us/library/cc745955.aspx 上記の問題が解決しない場合は、不安定なDLLの実行を管理する独自のコードで呼び出しをラップします。
このコードは、たとえば、失敗した呼び出しを結果が得られるまで繰り返すことで、失敗から回復する必要があります。
内部的には、不安定なDLLへの呼び出しは、生成されたスレッドで行うこともできますし、Process.Startで起動できる新しい外部実行可能ファイルにコードを組み込むこともできます。
この最後のオプションにはオーバーヘッドがありますが、これは唯一のオプションです。これに関する詳細については、この質問を参照してください：How do you handle a thread that has a hung call?
私はこの質問に対するすべての答えが回避されると思います。
私の回避策は、WebアプリケーションのDLLと直接対話しないことです。
代わりに、Webアプリケーションからの要求をMessage QueueまたはSQLテーブルに書き込んでください。その後、要求を読み取り、DLLとやりとりして、Webアプリケーションが読み取れるように結果を書き戻すWindowsサービスなどの別のアプリケーションを作成することができます。
私はSQL /メッセージキューが正しい方法であると言っているわけではありませんが、私は一般的なプロセスの流れについてもっと考えています。
私は以下の解決策を提案します。
このdllを別のWebアプリケーションでラップします。次のいずれかになります。あなたはすでにWeb APIを使用しているので、あなたに最も適しています。
コントロールあなたのp-呼び出すあなたはどんなバグを持っていないようにコードを？以下の記事を参照してください。
私は、ハードウェアのコピー保護ドングルとの相互作用のために保護されたメモリをアクセスするサードパーティのライブラリを使用してこの正確な問題を抱えていました。コンソールやwinformsアプリでうまく動作しましたが、IISアプリケーションから呼び出されたときに狂ったようにクラッシュしました。
いくつかのことを試しましたが、そのいくつかはこのページの他の回答に記載されています。しかし、究極的には、私たちのための最善の解決策は、非常に古い技術 - .Net Remotingでした。私は知っています - それは最近、いくらか眉をひそめています。しかし、それはこの特別な必要性をきちんと適合させます。
不安定なコードがWindowsサービスアプリケーションに配置されました。 Webアプリケーションは、このサービスにリモート呼び出しを行い、コマンドをサードパーティライブラリに中継しました。
WCF、ソケットなどでも同じことができると思いますが、リモーティングはセットアップが簡単で簡単でした。同じサーバーと話すだけなので、ポートを開くことなく動作します。それはちょうど名前付きパイプで話します。
これは、Webアプリケーション以外にインストールする2番目のサービスを意味しますが、これは私の特定のユースケースでは受け入れられるものでした。
同様のことを行い、サードパーティのコードが実際にサービスをクラッシュさせた場合は、メインアプリケーションにコードを書き込んでバックアップすることができます。
おそらくプロセス境界は、不安定なコードで競合するときにアプリケーションドメインよりも有用です。
あなたは何を観察しましたか？一定数のコールの後にプロセスがハングアップしますか？不安定なDLLにメモリリークがあると思われますか？ – xpereta
今までメモリリークは問題ではありませんでした。開発中に、DLLがメモリアクセス違反で開発サーバーをクラッシュさせることがあります。場合によっては、プロセスを終了するまで、開発サーバーがCPUの約70％を使用することもあります。IISに展開すると、クラッシュやCPUの問題は実際にはあまり起こりませんが、IISプロセスが応答を停止し、IISの再起動に時間がかかります。 – Schiavini
IISプロセスのリサイクル率を上げようとしましたか？ – xpereta