0

別のアプリケーションでプラグインとして使用されるネイティブ C++ DLL があります。この DLL にはマニフェストが埋め込まれており、アプリケーション外部のフォルダーにあるプライベート アセンブリに依存しています。DLL が見つからないプライベート アセンブリに依存しているため、アプリケーションはプラグイン DLL のロードに失敗します (このアセンブリは、アプリケーション ディレクトリにも winsxs フォルダーにもありませんが、場所がによって制御されていないプラグイン ディレクトリにあります)。アプリケーション）。問題は、システムが自分の特定のディレクトリにあるプライベート アセンブリを見つけられるようにするにはどうすればよいかということです。類推として、 setDllDirectory() に相当するものが必要ですが、アセンブリ用です。または、システムが私のプライベートアセンブリを見つける別の方法。

制約:

私の DLL はプラグインであるため、アプリケーションのディレクトリとサブディレクトリには何もインストールできません。また、アプリケーションの動作を変更することもできません。
winsxs でアセンブリを共有することは避けたいと思います。
また、バージョンの競合を避けるために、単純な DLL (LoadLibrary でロードできる) ではなく、アセンブリを使用する必要があります。

ありがとう。

4

1 に答える 1

0

（java-terminologyからの）クラスパスを形成するディレクトリのリストを提供できるグローバルな場所が必要です。このリストを取得したら、ディレクトリをトラバースしてdllを探します。

私はこれのためにウィンドウズのレジストリを使用しました。Linuxの環境変数または/etcフォルダーも同様です。

これはリンカーが行う方法であり、これは.NET GACが行う1つの方法です（レジストリキー内のディレクトリのリストを指定します）。

-編集1--

あなたの問題はかなり不快なミックスのようです、それは：Pでストレートジャケットを着て食べようとしているようなものです。アセンブリ要件を削除し、バージョン識別子（name-version）を返すネイティブDLLの関数を作成してから、DLLを使用できるかどうかを判断するためのアプリケーションロジックを作成してみませんか。

たとえば、file-name（fn）=monkey-1-1であり、関数呼び出しは構造体を返します。

struct version-id
{
   const char * name;
   int major_number;
   int minor_number;
};

その場合、fnmonkey-1-2はファイル名または内部変換で競合しません。また、プログラミング規約またはアプリケーションロジックにより、不利な衝突が発生しないことが保証されます。

于 2009-12-08T11:46:58.063 に答える