問題タブ [appdomain]

次のコードで問題が発生しています。

このコードは、カスタムアプリドメインのCreateInstanceFromAndUnwrap（）を介して作成したプロキシを介して呼び出されます。これは、IsPluginAssembly（）がカスタムアプリドメインのコンテキストで実行されることを意味します。

問題は、IsSubclassOf（）の呼び出しは、IMHOがtrueを返す必要がある場合でも、常にfalseを返すことです。問題の「タイプ」は実際にはClientPluginから継承されます-それについては疑いの余地はありません。

ClientPluginは、上記のコードフラグメントで明らかなように、手動で解決している別のプライベートアセンブリで定義されています。

行にブレークポイントを設定し、if (type.IsSubclassOf(...))この式がfalseであることを確認しました。

一方、この式は真です。

これはどのように可能ですか？どうしたの？

更新：ケント・ブオゴールは私を正しい方向に向けました。私はもう少しウェブを検索して、このブログ投稿に出くわしました。これを機能させるには、Load / LoadFrom/ReflectionOnlyLoadFromの競合を解決する必要があるようです。

クラス「Place」と整数を返す関数「Where」で構成される.NETDLLがあるとします。dllをアプリケーションドメインにロードし、関数を実行して、アプリケーションドメインをアンロードする必要があります。

この行は失敗します：

このエラーメッセージの場合：

ファイルはバッファにあるので、依存関係の.dllだと思います。ただし、ベースプログラムディレクトリでそれらを見つける必要があります。

エラーの原因について何か考えはありますか？

アセンブリをAppDomainにロードし、関数を実行してから、AppDomainをアンロードするためのテスト済みのサンプルコードをいただければ幸いです。

（ところで、私はグーグルで検索しましたが、有用なサンプルは見つかりませんでした。）

AppDomainとは何ですか? AppDomains の利点、または Microsoft が AppDomains の概念を導入した理由、AppDomains がない場合の問題は何ですか?

詳しく教えてください。

複数の AppDomains で実行される WPF UI の作成を検討しています。アプリ ドメインの 1 つはアプリケーションを実行し、残りの AppDomain は一連のユーザー コントロールとロジックをホストします。もちろん、この考え方は、これらのユーザー コントロールとロジックをメイン アプリケーションからサンドボックス化することです。

MAF/System.AddIn を使用してこれを行う例を次に示します。他の人はこれについてどのような経験をしていますか? このソリューションは、1 つのユーザー コントロール内で発生する可能性がある RoutedEvents/Commands をどのように処理し、これらを AppDomains 間で適切にシリアル化しますか? WPF リソースはどうですか? AppDomain 間でシームレスにアクセスできますか?

AppDomains 全体でオブジェクトを使用したいと考えています。

このために、[Serializeable] 属性を使用できます。

または、MarshalByRefObject からサブクラス化します。

どちらの場合も、次のようにクラスを使用できます。

両方のアプローチが同じ効果があるように見えるのはなぜですか? 両方のアプローチの違いは何ですか？あるアプローチを他のアプローチよりも優先する必要があるのはいつですか?

編集: 表面的には、両方のメカニズムに違いがあることはわかっていますが、誰かが茂みから飛び出して私に質問をした場合、私は彼に適切な答えを与えることができませんでした. 質問はかなりオープンな質問です。誰かが私よりもうまく説明できることを願っていました。

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

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

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

アプリケーション ドメインについて説明しているリソースへのリンクも役立ちます。それらについての情報があまりないMSDNをすでにチェックアウトしました。

NUnitを使用してC＃コードをテストしようとしましたが、すでにC ++コードに接続されています（NUnitがないと、アプリケーションは完全に機能します）。

私のテストでは、AppDomain.CurrentDomain.ExecuteAssembly（..）を介してメイン関数を実行しますが、C＃コードがC ++と「通信」しようとすると、例外がスローされ、テストがクラッシュします。例外はSystem.Reflection.TargetInvocationExceptionです。誰かがそれが発生する理由を知っていて、それが非常に役立つと考えている場合...ありがとう、Naama

私が現在抱えている問題と解決策について説明しましょう。おそらく、それが悪い考えである理由（そうだと仮定して）と、それをより良いシステムにするために私ができることについて教えてください。

現在、ファイルを解析してcsvまたは他の形式にリッピングする600個の「リッパー」があります。リッパーはすべて、共通のインターフェースと基本クラスを実装しています。ジョブの構成に応じてジョブがキューに入れられる時点で、リフレクションを使用して特定のリッパーが呼び出されます。

すべてのリッパーには、インターフェースがそれらを縮小する「Rip（）」と呼ばれる関数が実装されています。

現在のコードを使用すると、600個のアセンブリをロードした後（必要なときにロードされるため）、使用後にアンロードしないと少し遅くなり始めるという問題があります。

あなたは何を提案しますか？

サイトが回答を受け入れるか、賞金を追加するように求めているため、これを編集してトリミングして閉じようとしました。

コンソール アプリによって参照されるライブラリで GetUserStoreForAssembly と GetUserStoreForDomain を呼び出す実験を行いましたが、予想よりも多くのストアを取得する場合と少ない場合がある理由がわかりませんでした。

Preet は実験の調整に役立ちましたが、2 つのわずかに異なる問題が発生しました。

• コンソール アプリを別のディレクトリにコピーしたとき (そのため名前は同じままでした)、2 つのユーザー/アセンブリ ストアを取得しました。

• ライブラリをコンソール アプリ内の複数のドメインにロードしたとき、共有しないと予想していたときに、それらはすべて同じユーザー/アセンブリ/ドメイン ストアを使用していました。

その時までに、質問は冷たいものでした。私は自分で読んだので、答えを見つけたと思ったので、誰かが確認/修正してくれることを期待して自分で質問に答えました。しかし、それはリストのはるか下にあり、チャンスはありませんでした. 私はちょうどそれを残すつもりでしたが、賞金を受け入れるか追加するように求められました.

そのため、回答をここに移動しました。確認または修正するための役立つコメントを誰かに追加してもらい、それを受け入れて、これが実際に分離ストレージをよりよく理解したいと考えている他の人にとって役立つことを知る必要があります。

最初の質問に対する可能な答え:

もちろん、厳密な名前のアセンブリは厳密な名前で識別されます。弱い名前 (それが正式な用語かどうかはわかりませんが、何でも) は、URL またはファイルの場所によって識別されます。したがって、別のディレクトリにコピーされた同じ弱い名前のアセンブリには、独自の分離されたストアがあります。

2番目の質問に対する可能な回答（これについてはあまり確信が持てません）：

GetUserStoreForDomain によって返されるスコープは、マシン、ユーザー、アプリケーション、およびアセンブリ、特に特定のアプリケーション内で実行されているアセンブリに制限されます。

私の実験では複数の追加ドメインが作成されましたが、それらはすべて同じアプリケーションにあります。したがって、それらはすべて同じドメイン ストアを使用しています。

したがって、ドメインの分離をシミュレートするには、実際には 2 つの異なるコンソール アプリケーションからライブラリを参照する必要があります。

これは、ライブラリ (したがって両方のコンソール アプリケーション) に厳密な名前が付けられている場合にのみ適切に機能します。アセンブリを参照すると、アセンブリがコピーされます。つまり、名前が弱い場合、別の分離ストアが作成されます。

厳密な名前を付けて実験全体を試したところ、予想どおり 2 つのドメイン ストアと 1 つのアセンブリ ストアが得られました。