私はアプリケーションドメインを理解していません

Question

.NETには、アプリケーションドメインの概念があります。これは、アセンブリにメモリをロードするために使用できることを理解しています。私はApplication Domainsに関するいくつかの調査を行っただけでなく、この主題に関するいくつかの追加知識のために私の地元の本屋に行っていますが、それは非常に不足しているようです。

私がアプリケーションドメインで行うことができることは、メモリにアセンブリをロードすることができ、私が望むときにアンロードできることです。

私がアプリケーションドメインについて述べた以外の機能は何ですか？スレッドはアプリケーションドメインの境界を尊重しますか？通信のパフォーマンスを超えてメインアプリケーションドメイン以外の異なるアプリケーションドメインにアセンブリをロードすることには何らかの欠点がありますか？

アプリケーションドメインについて議論するリソースへのリンクもいいでしょう。私はすでにMSDNをチェックアウトしていますが、それについてはそれほど多くの情報はありません。

Answer 1

AppDomainsは、非常に軽量のプロセスとして最もよく視覚化されます。

.NetプロセスごとにN個のAppDomainsが存在する可能性がありますが、一般的に1つのみです。 AppDomainsの本当の利点は、プロセス内で分離境界を提供することです。オブジェクトは、リモート処理またはシリアル化を介してAppDomain境界を越えてのみ互いに​​話すことができます。

プロセス内の完全に異なるセキュリティレベルで2つのAppDomainsを実行することもできます。これにより、信頼できないプラグインをはるかに低い信頼レベルで実行している間、フル・トラストでメイン・アプリケーションを実行できます。

スレッドがAppDomainを尊重しているかどうかを「はい」または「いいえ」と言うのは難しいです。単一のスレッドがN個の異なるAppDomainsに存在する可能性があります。このような状況は、あるAppDomain内のオブジェクトが別のAppDomain内のオブジェクトへのリモート呼び出しを行う場合に可能です。完了するためにスレッドはAppDomains間で遷移する必要があります。

AppDomainsの欠点は、主に複雑さです。 Remotingは頭を悩ませるために少し時間がかかり、AppDomainを適切に設定することは簡単ではありません。

AppDomainsのMSDNのドキュメントを参照してください。さまざまな複雑な機能を備えているため、それらを説明するサクシントのチュートリアルを見つけるのは難しいです。これは、あなたの質問に直接答えることができない場合は、少なくとも適切な場所にあなたを指し示す素晴らしい概要を提供します。

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

この文書は、もはや更新されたバージョンのためにこれを参照してください維持されていない： https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Answer 2

あなたがのAppDomainで行うことができますいくつかのもの：

• あなたはせずにそれをシャットダウンすることができますあなたのプログラムの安定性を危険にさらします。
• プロセスを完全に信頼するが、別のAppDomainにコードをロードしても、ディスク上にファイルを作成することはできません。コードをロードして、このプロセスに十分な権限を与えないでください。
• 未処理の例外プロセスをクラッシュさせることなくAppDomainを使用できます。
• など

単純に言えば、セキュリティの境界であり、すべてのプロセス境界です。パフォーマンスが向上する限り、プロセス内の複数のAppDomainsは重大なオーバーヘッドを表しません。 AppDomainの代わりに別のプロセスを起動すると、はるかにコストがかかります。

Answer 3

JaredParの答えは良いですが、彼はAppDomainsのraison d'etreに注意していますが、AppDomainをアンロードしてアセンブリをアンロードすることしかできません。長時間実行されているOSプロセスで、をロードしてその後で何らかの理由でアセンブリをアンロードする必要がある場合は、AppDomainが必要です。ここのプロトタイプの例はASP.NETです。ASP.NETは、アプリケーションコードアセンブリをオンデマンドでロードし、その後、アプリケーションが積極的に使用されなくなったときにアンロードすることができます。

アンロードするための費用は独立しているため、AppDomainの境界を越えて通信する必要があります。簡単なメソッド呼び出しを行うことはできません。 AppDomainのライフサイクルを管理する必要があります。など

あなただけ動的にアセンブリをロードする必要があり、あなたは、あなたはおそらくが複数のAppDomainを実行する必要はありません、単一のプロセスの寿命の間に、彼らにをアンロードする必要がありますとは思わない場合。ここでの良い例は、プラグインモデルをサポートするリッチなアプリケーションです。プラグインモデルでは、プラグインアセンブリを「etc」ディレクトリにスニッフィングし、すべてをロードします。ただし、プラグインモデルでプラグインをアンロードする必要がある場合は...。

もっとシナリオがあります。同様に、2つの異なるバージョンのアセンブリを同時にロードしたいとします。あなたがAppDomainsとそれらを分離しない場合、落とし穴に遭遇することができます。しかしそれはかなり稀です。

AppDomainsの存在を正当化するコアシナリオは、アセンブリをアンロードできる必要がある長期実行プロセスです。

もちろん、アセンブリをアンロードするときにアプリケーションがOSプロセスに依存する可能性があります。言い換えれば、3つまたは4つの連携プロセスを実行し、それぞれ独自のアセンブリセットを使用できます。アセンブリをアンロードする場合は、そのアセンブリをホストするプロセスをシャットダウンするだけです。しかし、AppDomainは、前に説明したAppDomain間の通信よりも重い、プロセスの停止/開始やクロスプロセス通信を必要とせずに、これを実行するための高性能なメカニズムを提供しています。私はそれがまだリモーティングしていることを意味しますが、それはより遅く、より多くの文脈の切り替えです。