Microsoft（dsofile.dll）が提供するCOM DLLを、私たちが作成したC＃dll（アセンブリA）で使用しています。 COM dllの登録を避けるため、dsofile.dllへの参照のIsolatedプロパティをtrueに切り替えました。COM相互運用性、分離と重複参照の除外
これは、dllをコンパイルすると、Visual Studioがソリューションのbinフォルダにdsofile.dll、Interop.DSOfile.dllおよびネイティブマニフェストファイルをコピーし、アプリケーションがdsofile.dllを登録せずに実行できることを意味します。
このアプローチは、小さなテストアプリケーションで成功しました。
実際のアプリケーションでは、アセンブリAは、他のいくつかのDLL（アセンブリBとアセンブリC）とアプリケーションEXEによって参照されます。ネイティブマニフェストファイルとinterop dllがアプリケーションのbinフォルダにコピーされると、最初のdllを参照する各dllが独自のコピーを作成するため、各ファイルの異なるコピーが使用されます。
この結果、セットアッププロジェクトの参照として表示される複数のファイルが作成されます（アセンブリA、B、CおよびEXEフォルダのdsofile.dll、アセンブリA、B、CのInterop.DSOFile.dll）。アセンブリA、B、C、およびEXEフォルダのNative.Assembly A.manifest）とコンパイラの警告（「2つ以上のオブジェクトが同じターゲット場所を持つ」）が含まれています。
さらに、最終フォルダにコピーされたマニフェストおよびinteropのDLLが、（重複するファイルが上書きされるため）Assembly Aフォルダから直接アクセスできない場合、アプリケーションはCOM DLLを正常にロードできません。
セットアップの依存関係から複製されたファイルのコピーを手動で除外するように強制されましたが、ソリューションが再読み込みまたは再構築されたときに再び表示されます。
COM DLLの独立した展開を実現するためのより良い方法をお持ちの方はいらっしゃいますか？可能であればマニフェストを埋め込むこともしたいと思いますが、これまでこれを成功させていません。
代わりに、Visual Studio Automation用にEnvDTEを使用して複製コピーを除外するタスクの自動化について調査していますが、検出された依存ノードにアクセスする方法を見つけられませんでした。それらを除外する。 UIHierarchyItemインターフェイスでそれらにアクセスすると、セットアッププロジェクトの名前が各ファイルの名前プロパティとして表示され、除外オプションはありません。
アドバイスをいただければ幸いです。