4

Microsoftが提供するCOMDLL(dsofile.dll)を、私たちが作成したC#dll(アセンブリA)で使用しています。COM dllを登録する必要をなくすために、dsofile.dllへの参照のIsolatedプロパティをtrueに切り替えました。

つまり、dllをコンパイルすると、Visual Studioはdsofile.dll、Interop.DSOfile.dll、およびネイティブマニフェストファイルをソリューションのbinフォルダーにコピーし、dsofile.dllを登録しなくてもアプリケーションを実行できます。

このアプローチは、小規模なテストアプリケーションで成功しました。

ただし、実際のアプリケーションでは、アセンブリAは他のいくつかのdll(アセンブリBおよびアセンブリC)とアプリケーションEXEによって参照されます。ネイティブマニフェストファイルと相互運用DLLがアプリケーションのbinフォルダーにコピーされると、最初のdllを参照する各dllが独自のコピーを作成するため、各ファイルの異なるコピーが使用されます。

これにより、セットアッププロジェクトで参照として表示されるファイルの複数のコピーが作成されます(つまり、アセンブリA、B、CおよびEXEフォルダーのdsofile.dll、アセンブリA、B、CおよびEXEフォルダーのInterop.DSOFile.dll、アセンブリA、B、CおよびEXEフォルダーからのNative.Assembly A.manifest)およびコンパイラー警告(「2つ以上のオブジェクトが同じターゲット位置を持っている」)。

さらに、最終フォルダーにコピーされたマニフェストおよび相互運用機能dllがアセンブリAフォルダーから直接取得されなかった場合(重複ファイルが相互に上書きするため)、アプリケーションはCOMDLLを正常にロードできません。

セットアップの依存関係からファイルの重複したコープを手動で除外することを余儀なくされましたが、ソリューションがリロードまたは再構築されると、それらは再表示されます。

誰かがCOMdllの分離された展開を達成するためのより良い方法を手伝うことができますか?可能であればマニフェストも埋め込みたいのですが、今のところうまくいっていません。

別の方法として、Visual Studio Automation用のEnvDTEを使用して重複コピーを除外するタスクの自動化を調査してきましたが、検出された依存関係ノードにアクセスしてそれらを識別および除外できる方法を見つけることができませんでした。UIHierarchyItemインターフェイスを使用してそれらにアクセスすると、セットアッププロジェクトの名前がす​​べてのファイルのnameプロパティとして表示され、除外オプションはありません。

何かアドバイスをいただければ幸いです。

4

1 に答える 1

3

アセンブリ自体ではなくプロジェクトを参照することで、過去に同様の問題を解決しました。展開プロジェクトには、ソリューションでビルドされているアセンブリへの複数の参照に関するいくつかの問題があります。

于 2009-10-21T17:37:08.933 に答える