問題タブ [marshalbyrefobject]

こんにちは、みんな

これらのケースで、ポリシー インジェクション アプリケーション ブロックを使用してメソッドのエントリと終了をログに記録する方法をお尋ねしたいと思います。

ケース1 : Web フォーム コントロールのイベント ハンドラーをログに記録する場合、クラスSystem.Web.UI.Page から _Default を継承する必要があるとしましょう。そのため、 MarshalByRefObjectクラスからクラスを継承できないため、ログは機能しません。 .

ケース 2 :静的クラスがあり、メソッドをログに記録する必要がある場合、ログを取得するためにMarshalByRefObjectカルスからこのクラスを継承するためにできること。

C#のような優れた複数継承の切断された言語で「MarshalByRefObjectでなければならない」を解決する方法は?

問題は非常に単純です。場合によっては、このクラスから継承する必要があります (インフラストラクチャ要件)。ここでは、どちらの場合でも問題ありません。では、他のクラス (ドメイン モデルの要件) から既に継承している場合はどうすればよいでしょうか。

ところで、spring.net のような優れたアプリケーション フレームワークでは、クラスに適用する必要があるインフラストラクチャの種類に関係なく、このクラスから継承する必要はありません。

ここで-3票を獲得しているのは何ですか?? :)

プラグインに大きく依存する .net アプリケーションを開発しています。アプリケーション自体には、リモート サーバーへの接続が含まれています。

最近、私はアプリケーション ドメインを掘り下げて、アプリケーションの残りの部分からプラグイン コードを分離するための理想的なソリューションであると考えました。

ただし、プラグインをホストするアプリケーション ドメインを実装できない大きな欠点が 1 つあります。接続オブジェクトへの参照を渡すために必要な別のアプリケーション ドメインへの参照によってオブジェクトを渡す方法はないようです。

そのオブジェクトへの参照を渡すことができるように、誰かが回避策を教えてくれることを望んでいました。

注: プロキシの作成は問題外です。クラスは自動生成されるため、接続レイヤーは既にプロキシとして機能します。

注 2: System.AddIn は、コンパクト フレームワークでは使用できないため、使用できません。

MarshalByRef オブジェクトを使用して、サーバー側でスレッドがどのように処理されるかを知りたいです。

リモート化された MarshalByRef クラスが与えられた場合:

クライアント コード (シングル スレッド):

サーバー側では、2 つの書き込み操作があります。スレッドは ThreadPool からのものであると想定しています。ただし、クラスは MarshalByRef であるため、両方の操作は別々のリモート プロシージャ コールです。それらは別のスレッドで実行されますか? はいの場合、操作 1 が終了する前に操作 2 が実行される可能性はありますか?

PS: MyRemotedClass MarshalByRef を作成するのは悪い決定です。しかし、それを変更することはできませんので、提案しないでください。

了解しました。この質問が以前に行われたことがあるかどうかはわかりません。このような2つのクラスがあるとしましょう

ご覧のとおり、ClassAはClassBへの参照を保持していますが、クラスBはMarshalByRefObjectクラスを継承しています。私の質問は、ClassAを別のAppDomainに渡そうとしたときに、_dataフィールドを透過プロキシとして新しいAppDomainに渡す以外は、ClassAを通常の方法でシリアル化するにはどうすればよいですか？

どんな助けでも大歓迎です:)

私は別のSOスレッドからのこの回答に興味を持っており、誰かが私にコンセプトに光を当てるのを手伝ってくれることを望んでいました。

プライマリAppDomainと、プライマリAppDomainによって作成および初期化される子AppDomainの束があるとします。擬似コードの場合：

プライマリAppDomain：

子AppDomain：

Init（）中に、子AppDomainはPOCOオブジェクトをインスタンス化します。これは、定義上、マーシャリングできません。また、その点で変更できないと仮定しましょう。

リンクされた回答は、それをContainer<T>（それ自体がマーシャリング可能である）でラップすると、プライマリAppDomainに戻すことができるようにする必要があることを示唆しています。Container<MyInfo>実際に渡されるのはインスタンスへのプロキシであるため、これを理解しています。

私が理解していないのは、プライマリAppDomainがコンテナのプロキシを介してコンテナ内のPOCOインスタンスにアクセスする方法です。オーバーロードされた暗黙のキャスト演算子が表示されContainer<T>、含まれているPOCOインスタンスが返されることを理解しています。しかし、そのインスタンスはそれ自体がプロキシされていません-それはまだ子AppDomainにあります！だから、これは壊れるべきではありませんか？

ここで実際に何が起こっているのですか？

複数の AppDomains でいくつかのロジックを並行して実行しようとしています。これを行っているのは、「変更不可能」なレガシー コードを使用しており、いくつかを並列化してパフォーマンスを向上させたいからです。問題は、1 つの AppDomain 内で複数のインスタンスを実行すると、それらはすべていくつかの静的データ構造に依存し、互いに干渉することです。

私の実装は簡単です。「ExecutionHarness」クラスの複数のインスタンスをそれぞれ独自の AppDomain で実行したいので、各 AppDomains でインスタンス化するクラス「ExecutionHarnessProxy : MarshalByRefObject」を作成しました (ExecutionHarness は MarshalByRefObject から継承されないため)。次に、「ExecutionData[] データ」パラメーターを「ExecutionHarnessProxy.Execute()」メソッドに渡します。その後、この男は「ExecutionHarness.Execute()」を呼び出し、すべて問題ありません。

私の問題は、データの配列をプロキシクラスに渡すたびに、永遠にかかることです。ExecutionData クラスには [Serializable] 属性があり、機能的にはすべて機能しますが、これを高速化する方法があるかどうか疑問に思っていました。

1. AppDomain 境界の両側で、自分でシリアル化/逆シリアル化を行うと、より高速になりますか?
2. このすべての時間はシリアライズに費やされていますか? それとも、AppDomains 間のシリアル化されたデータの転送だけですか?

私はいくつかのことを理解しようとして頭を叩いてきました。そこで、アドバイスや調査資料を (リンク経由で) 探しています。シナリオは次のとおりです。

他のいくつかのアプリケーション (AppA、AppB、AppC など) が必要とするリソースを含むライブラリ (CommonLib など) があります。これが現在機能している方法は AppA インスタンスで、特定のポートが使用可能かどうかを確認します。そうでない場合は、CommonLib をキックし ("Hey, wake up")、サービスを開始します。その後、AppA は満足して出発します。

現在、Remoting.Channels について多くの調査を行った結果、「レガシー」と見なされるテクノロジに基づいて構築されたアプリケーションを開始しようとしているという結論に達しました。うーん...私はそれが好きではありません。正直なところ、WCF は必要以上にオーバーヘッドが大きく、Mono では完全に実装されていません。マルチプラットフォームの互換性 (Windows、Mono、Linux) をターゲットにしているため、すべてのオプションを調査しています。

そもそも、リモーティングのアイデアが始まったのは、CommonLib を単一のインスタンスとして保証したかったからです (私が理解しているように、シングルトンは特定の AppDomain 内のシングルトンであることがほとんど保証されているだけです。間違っています）。とにかく、私はリモート処理の威力を実感し、実験的な実装を開始することにしました。MarshalByRefObject の最初の使用に成功しました。しかし、私は、このレガシー テクノロジーの継続的な実装について懸念しています。

それで、これらすべてで... CommonLib を（ホストアプリケーションとして）実装し、リモート処理なしで、ストリーム、標準の TCP ソケット、またはその他の方法で MarshalByRefObject を実装する方法を検討しています。私が考えているのは、AppA をインスタンス化して CommonLib を実行する代わりに、CommonLib をベース アプリとして実装することです。次に、CommonLib 内でインスタンス化するアプリ (実際には単に「ホストされている」.dll) を選択します。次に、CommonLib は、その .dll を、ホストされているアプリが使用するカスタム コントロールと共に CommonLib フレームワークに読み込みます。この考えに加えて、CommonLib が本物のシングルトンでなければならないという要件 (今のところ) は差し控えたいと思います。

これがシナリオの詳細です。繰り返しますが、私の質問は実際には 2 つの部分です: (a) どのテクノロジを調査する必要があるか、および (b) リモート処理テクノロジのレガシー ステータスに関心を持つ必要がありますか?

その他のアドバイス、コメント、または質問は大歓迎です。

更新 1:このスニペットから始めます。これにより、インストールされているアプリ (またはプラグイン) のリストを含むファイル (またはスクリプト) を読み込むことができます。このファイルを Xml またはバイナリ形式で作成できます。新しいアプリをインストールすると、ファイルとパスを追加できます。うーん...必ずしも MarshalByRefObject を使用する必要はありません。