我们在我们编写的 C# dll（程序集 A）中使用 Microsoft 提供的 COM DLL（dsofile.dll）。为了避免必须注册 COM dll，我已将对 dsofile.dll 的引用的isolated 属性切换为 true。
这意味着当我们编译 dll 时，Visual Studio 会将 dsofile.dll、Interop.DSOfile.dll 和 Native 清单文件复制到我们解决方案的 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， Native.Assembly A.manifest（来自程序集 A、B 和 C 以及 EXE 文件夹）和编译器警告（“两个或多个对象具有相同的目标位置”）。
此外，如果复制到最终文件夹中的清单和互操作 DLL 不是直接来自 Assembly A 文件夹（因为重复文件相互覆盖），则应用程序无法成功加载 COM DLL。
我被迫从安装依赖项中手动排除文件的重复副本，但在重新加载或重建解决方案时它们会重新出现。
谁能提供更好的方法来实现 COM dll 的隔离部署？如果可能的话，我还想嵌入清单，但到目前为止我还没有成功做到这一点。
作为替代方案，我一直在研究使用 EnvDTE for Visual Studio Automation 排除重复副本的任务的自动化，但无法发现如何以允许我识别和排除它们的方式访问检测到的依赖项节点。使用 UIHierarchyItem 界面访问它们会显示安装项目的名称作为每个文件的名称属性，并且没有排除选项。
任何意见，将不胜感激。
我过去通过引用项目而不是程序集本身解决了类似的问题。部署项目存在一些问题，涉及对解决方案中正在构建的程序集的多个引用。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
