如何复制 Visual Studio 安装项目的“检测到的依赖项”功能?

发布于 2024-12-06 23:17:33 字数 1086 浏览 1 评论 0原文

问题

是否有一个固定的解决方案可以(递归地)检测给定 Visual Studio 项目文件的所有依赖项?这基本上就是 Visual Studio 安装项目的“检测到的依赖项”功能的作用 - 但我需要以编程方式访问依赖项列表(最好是从 MSBuild)。

背景(如果您想了解我正在尝试解决的实际问题,请阅读)

我正在研究利用第三方 UI 库的 WinForms 应用程序的自动构建。为了成功构建应用程序,必须在构建/开发计算机上“安装”库(通过供应商的安装程序)(这会将程序集放入 GAC 并安装许可组件)。然后必须通过我们的项目文件中的 GAC 引用供应商的 dll。不幸的是,没有办法避免这种“安装”要求(我很想使用从我的源代码控制系统获取的本地引用,就像我对几乎所有其他第 3 方引用所做的那样,但这在本例中是不可能的案件)。

我们利用“插件”架构,因此可执行项目不会直接引用任何这些组件——它们都是通过“插件”项目间接引用的(而“插件”项目又被可执行项目引用)。因此,在“插件”项目中将 GAC 引用设置为“copy local = true”只会将供应商 dll 复制到插件项目的输出目录中;它们不会递归地复制到可执行项目的输出目录。因此,可执行项目输出目录的 xcopy 部署无法在未安装这些供应商 dll 的计算机上运行,​​因为它们不存在于输出目录中。

我们当前使用 msi 部署(通过 Visual Studio 安装项目)并希望切换到 xcopy 部署。供应商 dll 目前正在打包到我们的 msi 中,因为安装项目的“检测到的依赖项”功能中发生的任何魔术都会“检测到”依赖项。我使 xcopy 部署工作的解决方案是只要求可执行项目直接引用其引用的插件使用的供应商 dll,并将“copy local”设置为 true。为了确保以这种方式引用所有必需的供应商 dll,我想生成可执行项目的“检测到的依赖项”列表,断言所有这些依赖项都存在于可执行项目的输出目录中,并使构建失败如果他们没有全部到场。

我可以通过分析 csproj 文件、编译所有“参考”条目的列表并递归地跟踪项目参考来自己完成此操作。然而,我希望有一个固定的功能可以做到这一点——特别是考虑到“检测到的依赖项”足够聪明,可以过滤掉框架 dll,但包括我的 GAC 引用的供应商 dll。

谢谢!

Question

Is there a canned solution that will detect (recursively) all dependencies of a given visual studio project file? This is basically what a visual studio setup project's "detected dependencies" functionality does -- but I need programmatic access to the list of dependencies (ideally from MSBuild).

Background (read if you want to know about the actual problem I'm trying to solve)

I am working on the automated build for a WinForms application that utilizes third party UI libraries. In order to successfully build the application, the libraries must be "installed" (via the vendor's installer) on build/dev machines (this puts the assemblies in the GAC and installs licensing components). The vendor's dlls must then be referenced via the GAC in our project files. Unfortunately, there is no way to avoid this "installation" requirement (I would love to use local references that are fetched from my source control system, as I do with nearly all of our other 3rd party references, but this is not possible in this case).

We utilize a "plugin" architecture, so the executable project does not directly reference any of these components -- they are all indirectly referenced via the "plugin" projects (which are in turn referenced by the executable project). Therefore, setting the GAC references to "copy local = true" in the "plugin" projects only copies the vendor dlls into the output directory of the plugin project; they are not recursively copied to the output directory of the executable project. Hence, an xcopy deployment of the executable project's output directory does not work on a machine without these vendor dlls installed, as they are not present in the output directory.

We currently use msi deployment (via a visual studio setup project) and would like to switch to xcopy deployment. The vendor dlls are currently getting packaged into our msi because the dependency is "detected" by whatever magic happens inside the setup project's "detected dependencies" functionality. My solution to make xcopy deployment work is to just require that the executable project directly reference the vendor dlls used by its referenced plugins with "copy local" set to true. To ensure that all required vendor dlls have been referenced in this manner, I would like to generate a list of the "detected dependencies" of the executable project, assert that all those dependencies are present in the executable project's output directory, and fail the build if they are not all present.

I could do this myself by analyzing the csproj file, compiling a list of all "Reference" entries and recursively following project references. However, I am hoping that there is canned functionality somewhere that does this -- especially considering that "detected dependencies" is smart enough to filter out the framework dlls but includes my GAC-referenced vendor dlls.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

夏末 2024-12-13 23:17:33

您很可能可以使用反射来解决这个问题 - 您的插件及其主机很可能有一个通用的接口契约。您的代码将在构建后扫描所有程序集以查找一组已知接口协定的使用情况,并通过 IDE 可扩展性自动化将它们添加/更新到安装程序项目。编写手动执行此刷新的插件可能是一种选择,编写和注册 MSBuild 任务更好。

我知道这不是一个“罐装解决方案”,但所需的工作量应该少于 1 个 KLOC。

Most possibly you can solve this with Reflection - your plugins and their host most likely have a common interface contract. Your code would scan all assemblies for the usage of a set of known interface contracts after they are built and add / update these to the installer project by IDE extensibility automation. Writing a plugin that does this refresh manually may be one option, writing and registering an MSBuild task the better one.

I know this is not a 'canned solution' but the amount of work required should be less than one KLOC.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文