問題タブ [probing]

CLRアセンブリをプロービングする方法は知っていますが、知りたいのは次のとおりです。CLRプロービングアセンブリはGACフォルダーにありますか？

AssemblyName.CodeBase を設定すると、アセンブリが LoadFrom コンテキストに読み込まれますか?

私は一種のプラグインシステムに取り組んでいます。Type.GetType などを使用できるようにする必要があります。コードのどの場所でも、Type がプラグイン dll からのものかどうかを知る必要はありません。

私のプラグインは、私のアプリケーション (windows/web) の bin ディレクトリの下のフォルダー Plugins にあり、各プラグインは独自のフォルダーにあります。

プローブ パスをプラグイン (または bin;bin\Plugins for web) に設定しますが、プラグインはサブ フォルダーにあるため違いはありません。

そして、このようにプラグインをロードします

注: PluginInfo は、プラグインの状態を保持する単なるクラスです。

アセンブリ名 Assembly.Load の CodeBase プロパティを設定したため、プローブ パスになくてもアセンブリを見つけることができます。これは、アセンブリが既定のコンテキストまたはコンテキストからロードされることを意味しますか?

エントリ アセンブリの後で AssemblyResolve イベントが再度発生するのは正常ですか?

Windows Server AppFabric キャッシュは初めてです。XML モードで構成し、基本的なサンプル プログラムを試しました。現在、独自のキャッシュを開発しようとしています。AppFabric で調査手法 (線形、二次、ハッシュなど) を使用することは可能ですか? また、はいの場合、それを使用することをお勧めしますか?

特定のハッシュ値に対して、線形プローブによって生成されるインデックスは次のとおりです。

h、h+1、h+2、h+3など。

特定のハッシュ値に対して、二次プロービングによって生成されるインデックスは次のとおりです。

h、h+1、h+4、h+9など。

線形の場合はクラスターが形成されますが、二次の場合はクラスターが形成されません。

しかし、両方のプロセス（メソッド）が挿入または検索に同じ数のステップを必要とする場合、二次は線形よりも効率的です。ありがとう！

更新 - 以下の元の質問

追加のテストを行った結果、問題の原因は .NET がアセンブリを検索する方法にあると考えています。

以下で言及したように、サブディレクトリには .dll ファイルがありますが、以下で言及した .dll ファイルは、各ディレクトリ内の唯一の .dll ファイルではありません。たとえば、\translation\Customer ディレクトリには、Customer.dll ファイルといくつかの標準ファイル (Translation.dll、Mapping.dll、Execute.dll) があります。\translation\Standard ディレクトリには、Standard.dll とその他の標準ファイル (Translation.dll、Mapping.dll、Execute.dll) があります。これらのファイルはすべて (異なるプロジェクトから) 生成されたコードであるため、各ディレクトリには標準ファイルのコピーと、サブディレクトリに直接関連するファイルがあります。

Customer.dll ファイルのメソッドが Windows サービス アプリケーションで実行されると、標準アセンブリ (Translation.dll、Mapping.dll など) の他のメソッドも呼び出されます。他の .dll ファイルへの呼び出しは、同じディレクトリ内の .dll で実行されていないと思います。

たとえば、/translation/Customer/Customer.dll のメソッドを呼び出すと、Translation.dll のメソッドが呼び出されます。ただし、/translation/Customer/Translation.dll でメソッドを呼び出す代わりに、アプリケーションは最初に /translation/Standard/Translation.dll を見つけて、そのファイルでメソッドを呼び出します。

同じディレクトリ内のこれらの関連する .dll ファイルへの呼び出しを .NET に強制することは可能ですか? または、各ディレクトリで一意の名前の「標準」アセンブリを作成するために何かをする必要がありますか?

元の質問:

ディレクトリを監視し、着信ファイルを処理する C# Windows サービス アプリケーションがあります。処理される各ファイルには、ファイルに対して実行される構成可能な一連のタスクがあります。各タスクのコードは、リフレクションを使用して実行時に動的にロードされる外部 .dll に含まれています。外部の .dll はメイン アプリケーション フォルダのいくつかのサブディレクトリに存在し、それらへのアクセスは app.config<probing>ファイル内のアプリケーションの要素のエントリを介して許可されます。

最近、外部の .dll をより適切に整理するためにサブディレクトリの数を増やしましたが、<probing>要素で予期しない機能が発生しました。ファイルに対して 2 つのタスクを実行する必要があるファイルを処理するテストを実行しています。最初のタスクはファイル Customer.dll に存在し、「\translation\Customer」というサブフォルダーにあります。2 番目のタスクは Standard.dll ファイルであり、「\translation\Standard」というサブフォルダーにあります。

私の調査要素がこのように見える場合<probing privatePath="translation\Customer;translation\Standard">、2 番目のタスク ("Standard" フォルダー内の .dll でメソッドを実行する) は実行に失敗します。

ただし、プローブ要素がこのように見えるようにこれらのエントリを切り替えると、<probing privatePath="translation\Standard;translation\Customer">両方のタスクが正常に実行されます。

プローブ要素内のサブディレクトリの順序が、それらのサブディレクトリ内に含まれる .dll の実行に影響を与える理由を理解できる人はいますか?

このコード (出所不明の LZW 圧縮プログラムから抜粋) は、0 から 5020 までのインデックスが付けられたサイズ 5021 のハッシュ テーブルで空のスロットを見つけます。

これは、典型的な線形または二次プロービングではありません。なぜそのように調査するのですか？これは既知のプロービング アルゴリズムですか? 詳細はどこで確認できますか?

リフレクションによって作成されたときに間違ったアセンブリが使用されるという奇妙な状況があります。

これは私のセットアップです（簡略化）：

Project1: クラス ライブラリ

Project2: クライアント アプリ

• Project2 は、特定のパス (C:\Project1) からのリフレクションによって Project1.dll を作成します。
• Project2 はさらに、さまざまな機能のために Project1.dll への参照を持っています。この参照は、C:\Project2\bin\Debug の Project1.dll をコピーします。

関連するリフレクション コードは次のとおりです。
Assembly assembly = Assembly.LoadFrom(path);

問題: リフレクションによって Project1 を呼び出すと、C:\Project1 パスを指定しても、実際には bin\Debug コピーが使用されます (これは必ずしも正しいバージョンではありません)。

質問: 最初に見つかったバージョンではなく、指定したパスが使用されるようにするにはどうすればよいですか?

私の理想的な解決策は、Project1 をリフレクション用と参照用の 2 つに分割することですが、それは私の場合のオプションではありません (そうですが、追加の問題があります)。

ありがとう、
サイモン

私が今取っているデータ構造とアルゴリズムのクラスは、アルゴリズムがどのように機能するかについての多くのペンと紙の理解ですが、実際のコーディングはほとんどありません. 私はプログラミング初心者なので、これはばかげた質問かもしれません。

概念的には、ハッシュとさまざまな方法の理由を理解していますが、この割り当てをコーディングする方法についてはわかりません。

基本的に、必要なソース コードを使用できます。本のコードは、 http: //users.cis.fiu.edu/~weiss/dsaajava3/code/SeparateChainingHashTable.javaおよびhttp://users.cis.fiu.edu/~weiss/dsaajava3/code/QuadraticProbingHashTable です。ジャワ

これらのコードのいずれかを使用すると、キーをテーブルに挿入するのに問題があるようです。このブロックを使用して挿入しています：

これは実際にはテーブルに何も挿入していないように見えますが、挿入の量にかかわらずサイズは一定のままです。また、必要なプローブの数を決定する方法もわかりません。