アプリケーションドメインがわかりません

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

アプリケーションドメインでできることは、アセンブリをメモリにロードすることだけで、必要なときにアンロードできます。

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

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

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

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

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

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

AppDomainsの欠点は、主に複雑さです。リモーティングは頭を動かすのに少し時間がかかることがあり、AppDomainを適切に設定することは簡単なプロセスではありません。

AppDomainsのMSDNドキュメントを確認することをお勧めします。それらはさまざまな複雑な機能を備えているため、それらを説明する簡潔なチュートリアルを見つけるのは困難です。これは、質問に直接答えない場合でも、少なくとも適切な場所を示すための優れた概要を提供します。

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

このドキュメントは保守されなくなりました。更新されたバージョンについては、https：//msdn.microsoft.com/en-us/library/2bh4z9hs（v = vs.110）.aspxを参照して ください。

JaredParの答えは良いですが、AppDomainの存在理由については言及していません。つまり、AppDomainをアンロードすることによってのみアセンブリをアンロードできます。長時間実行されているOSプロセスであり、ロードしてから後でアンロードする必要があると予想される場合、何らかの理由でアセンブリをする必要がある場合は、AppDomainが必要です。ここでの典型的な例はASP.NETです。これは、アプリコードアセンブリをオンデマンドでロードし、後でアプリがアクティブに使用されなくなったときにそれらをアンロードできます。

アンロードする機能に支払うコストは、その独立性です。AppDomainの境界を越えて通信する必要があり、単純なメソッド呼び出しを行うことはできません。AppDomainのライフサイクルを管理する必要があります。等。

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

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

AppDomainの存在を正当化するコアシナリオは、アセンブリをアンロードできなければならない長時間実行プロセスです。

もちろん、アセンブリをアンロードする場合、アプリケーションはOSプロセスに依存する可能性があります。つまり、3つまたは4つの協調プロセスを実行し、それぞれに独自のアセンブリセットを設定し、アセンブリをアンロードする場合は、そのアセンブリをホストするプロセスをシャットダウンするだけです。ただし、AppDomainは、プロセスの停止/開始やクロスプロセス通信を必要とせずに、これを行うためのより高いパフォーマンスのメカニズムを提供します。これは、前述のクロスAppDomain通信よりもさらに重いものです。私はそれがまだリモーティングしていることを意味しますが、それはより遅く、より多くのコンテキスト切り替えです。

AppDomainsでできること：

• プログラムの安定性を損なうことなくシャットダウンできます。
• コードをロードして、独自のプロセスよりも少ない特権を与えることができます（たとえば、プロセスは完全に信頼されて実行されますが、ディスク上にファイルを作成することさえできない別のAppDomainにコードをロードします）。
• プロセスをクラッシュさせることなく、AppDomainの未処理の例外を処理できます。
• 等。

簡単に言えば、これはセキュリティの境界であり、ほとんどの場合プロセスの境界です。パフォーマンスに関する限り、プロセス内の複数のAppDomainは大きなオーバーヘッドを表しません。AppDomainの代わりに別のプロセスを起動すると、はるかにコストがかかります。