問題タブ [appdomain]

.EXE が実行されている同じディレクトリから App.Config ファイルを提供するのではなく、ネットワーク共有から App.Config ファイルを設定する方法はありますか。たとえば、次のようなことはできますか :

実行時にすべての構成パラメーターが設定されるため、null 例外なしで .cs ファイルでこのようなことを実行できます。

アイデアや提案があれば、本当に感謝しています。

ありがとう

Castle Windsor を使用してコンポーネントを作成し、個別のスレッドで実行するマルチスレッド サービスを作成しました。I 各スレッドのパラメーターを使用して名前でコンポーネントを解決します。

コンポーネントで使用されるサードパーティ ライブラリで同時実行の問題が発生しています。これらのコンポーネントを別の AppDomains に分離することで問題が解決すると思われます。

別の AppDomain を使用して Resolve にコンポーネントを作成させる方法はありますか?

を診断して最小化または防止するにはどうすればよいAppDomainUnloadedExceptionですか?

NUnit 2.5.2 はAppDomainUnloadedException、PLINQ を含む長い (10 秒を超える) テストの後、一貫してスローします。

2008 年 7 月にさかのぼると、Stephen Toub は次のように述べています。

はい、CTP のスケジューラはスレッドの中止を適切に処理しません。これにより、シャットダウン中のドメインにライブ スケジューラが存在する場合にプロセスがクラッシュすることがよくあります (AppDomain のシャットダウンにより、そのドメイン内のスタック フレームを持つすべてのスレッドでスレッドが中止されるため)。 ）。将来のリリースに向けてこれを強化するために取り組んでいます。

次のような多くの回避策を試しました。

• 別のメソッドでテストを実行して、浮遊参照を排除する
• /domain:NoneNUUnit 引数として指定する
• legacyUnhandledAppDomainPolicy要素を削除するnunit-console.exe.config

パラメトリック テストを高速化するには PLINQ が必要なため、競合状態の可能性を減らすためにNUnit をバックグレードすることはできません。問題のない NUnit のバージョンは、パラメトリック テストをサポートしていません。

Assembly asm = AppDomain.CurrentDomain.Load(SomeByteArray); と書くと、

SomeByteArray が .net .exe から読み取られた場合はすべて問題なく、C++ から読み取られた場合はエラーになります。

この機能は、.net exe を使用して重要です。

はいの場合は、他の方法でこれを行ってください。

ありがとう

ログイン/ログアウト機能を備えたアプリがあります。ユーザーがログアウトしたら、すべてのクラスと変数を完全にリセットしたいと思います（静的クラスを使用しているため、問題がさらに難しくなります）。

リセットをそのままにして、アプリを完全にリロードするのが最善だと判断しました。ユーザーは違いを知らず、考えられるパンくずリストをクリアします。

だから私は次のいずれか（最も良い/最も簡単な方）についていくつかのアイデアが欲しいです

1）プロセス自体を閉じて再起動することにより、アプリをリロードします2）アプリを実行し続け、すべてのデータと変数（ウィンドウを含む）をリセットします-おそらくAppDomain.Unload/Loadまたはいくつかのコンボによって

何かアドバイス？

AppDomain.AppendPrivatePath（）は廃止されたため、まったく新しいAppDomainを起動せずに、プロジェクト内の現在のAppDomainにPrivateBinPathを指定し、後でアクセスできるようにする方法を見つけようとしています。

AppDomainSetupオブジェクトにPrivateBinPathを設定できることを知っています（新しいAppDomainを作成したい場合は問題ありません）。また、次のようにapp.configに追加できることも知っています。

ただし、このエントリをapp.configに追加すると、AppDomain.CurrentDomain.SetupInformation.PrivateBinPathプロパティがnullになります。

ADO.NET OLE DB プロバイダーを介して FoxPro データベースに接続するプラグインを起動するプラグイン マネージャーがあります。

あるクライアント サイトでは問題なく接続が開閉されますが、別のクライアント サイトでは「connection.Open();」でスタックします。数秒以内に 1GB を超えるメモリが割り当てられます。

その後 1 分以内に別の 1GB が割り当てられ、System.OutOfMemoryException がスローされます。

プラグイン マネージャーは AppDomain をアンロードして続行します。

これをどこからデバッグし始めますか?

少し前に、プラグインのアクセスを制限する方法を尋ねたところ (ディスクまたはネットワークへの書き込みを防止したい)、AppDomainを使用するように言われました。これを機能させる方法を検索して試しましたが、失敗しました。

ファイルまたはネットワークへの書き込みを許可しない AppDomain を作成するだけです。

ラムダ式を IL バイトのストリームとしてセカンダリ AppDomain に渡し、DynamicMethod を使用してそこに戻して呼び出すことができるようにすることは可能ですか?

そもそもこれが正しい方法かどうかはよくわからないので、この質問をする（詳細な）理由は次のとおりです...

私のアプリケーションでは、リフレクションのためにいくつかのアセンブリをロードする必要がある場合が多いため、次にそれらをどうするかを決定できます。問題の部分は、アセンブリを検討し終わった後にアセンブリをアンロードできるようにする必要があることです。これは、別の を使用してそれらをロードする必要があることを意味しますAppDomain。

さて、私のケースのほとんどは、完全ではないことを除いて、似たようなものです。たとえば、簡単な確認を返す必要がある場合もあれば、アセンブリからのリソース ストリームをシリアル化する必要がある場合もあり、1 回または 2 回のコールバックを行う必要がある場合もあります。

AppDomainそのため、同じやや複雑な一時的な作成コードを何度も何度も書きMarshalByRefObject、新しいドメインと元のドメインの間で通信するカスタム プロキシを実装することになります。

これはもはや受け入れられないため、次のAssemblyReflectorように使用できるクラスをコーディングすることにしました。

AssemblyReflectorAppDomainのおかげでアンロードが自動化され、別のリフレクション コードを透過的に保持するタイプのラムダIDisposableを実行できるようになります。Func<Assembly,object>AppDomain

問題は、ラムダを他のドメインに簡単に渡すことができないことです。そのため、検索した後、まさにそれを行う方法のように見えるものを見つけましAppDomainた.ILストリームとしてラムダを新しいものに渡します-そして、それは元の質問に私をもたらします.

これが私が試したものですが、うまくいきませんでした（BadImageFormatException新しいデリゲートを呼び出そうとしたときに問題がスローされていました）：

私は近づいていますか（何が欠けていますか？）、それともこれは無意味な練習ですか？

注:これが機能した場合でも、参照に関してラムダに何を入れるかについて注意する必要があることを認識しています。しかし、それは問題ではありません。

更新: もう少し先に進むことができました。メソッドを再構築するには、単純に呼び出すだけでSetCode(...)は十分ではないようです。必要なものは次のとおりです。

トリックは次のとおりです。元の IL には、元のメソッドのコンテキストでのみ有効な特定のメタデータ トークンが含まれています。IL を解析し、それらのトークンを新しいコンテキストで有効なものに置き換える必要がありました。これは、 Drew WilsonとHaibo LuoILTokenResolverの 2 つのソースから採用した特別なクラス を使用して行いました。

これにはまだ小さな問題があります。新しい IL は正確には有効ではないようです。ラムダの正確な内容に応じて、実行時に InvalidProgramException がスローされる場合とスローされない場合があります。

簡単な例として、これは機能します：

これはしませんが：

まだ決定されていない違いに応じて、機能するかどうかのより複雑な例もあります。小さいながらも重要な詳細を見逃している可能性があります。しかし、ildasm の出力をより詳細に比較すれば、それが見つかると確信しています。発見したら、ここに投稿します。

編集：ああ、男。この質問がまだ未解決であることを完全に忘れていました。しかし、おそらくそれ自体が明らかになったので、これを解決することを断念しました。私はそれについて満足していません、それは確かです。本当に残念ですが、これを再試行する前に、フレームワークや CLR からのサポートが改善されるのを待つことにします。これを機能させるには多くのハックを行う必要があり、それでも信頼性は高くありません。興味を持ってくださった皆様、申し訳ありません。

.net System.AddIns フレームワークを使用してアセンブリを個別のプロセスとアプリ ドメインにロードする wcf サービスがあります。パフォーマンスを向上させるために、クロスドメイン FastPath を有効にしたいと考えています。

ドキュメントによると、ホスト アプリケーションのメイン メソッドに LoaderOptimizationAttribute 属性を追加する必要があります。ただし、サービスを使用しているため、メインメソッドはありません。

それで、属性を使用することは可能ですか？そうでない場合、アドイン アセンブリがドメイン ニュートラルとして読み込まれるようにするにはどうすればよいですか?

ありがとう。