解决相关项目

本文关键字：项目 解决 | 更新日期: 2023-09-27 18:03:57

msbuild和Visual studio似乎以不同的方式解决项目依赖关系:解决方案文件包含主可执行文件的项目，以及可执行文件所依赖的dll的一些项目。其中一个dll项目依赖于另一个不是解决方案一部分的项目。

只是为了展示在这种情况下的主要参与者，以及一个简单的方法来复制它:解决方案包含ExeProject和MainDllProject, MainDllProject依赖于SubDllProject，后者不是解决方案的一部分(但在文件系统上处于相同的层次结构中)。ExeProject依赖于MainDllProjectClass1的MainDllProject(这个类不依赖于SubDllProject;只有MainDllProjectClass2依赖于SubDllProject，但它不被ExeProject和MainDllProjectClass1使用:

Solution
    ExeProject
        Form1 (depends on MainDllProject.MainDllProjectClass1)
    MainDllProject
        MainDllProjectClass1
        MainDllProjectClass2 (depends on SubDllProject.SubDllProjectClass)
Not part of the solution
    SubDllProject
        SubDllProjectClass

当使用Visual Studio 2010构建解决方案时，它失败了:MainDllProject无法构建，因为无法找到SubDllProject。

使用msbuild构建解决方案时，构建成功。奇怪的是，SubDllProject的调试版本被构建，尽管参数/p:Configuration=Release.

msbuild的日志文件大约是374kb，你有一些提示如何分析它吗?我想了解为什么它构建SubDllProject，为什么它是调试版本，以及最终如何防止它在未引用时被构建(我希望解决方案包含所有引用的项目，当一个依赖项被遗忘时，我想看到一个错误消息)。

注意:这种情况类似于Visual studio在解决方案中构建非依赖项目，但完全相反…我从http://blogs.msdn.com/b/visualstudio/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx了解到msbuild将sln文件转换为自己的格式-但是sln。metaproj文件也没有显示任何对SubDllProject的引用

解决相关项目

对，我刚刚遇到了一个听起来非常相似的问题。
我们在版本控制的同一个目录下有很多解决方案，其中一些共享项目。我们在解决方案1中将项目A改为引用项目B，但忘记了解决方案2也使用项目A，但不包括项目B。

msbuild碰巧在项目B构建时找到它，因为路径引用解析为一个真实的东西，但显然在解决方案中没有构建它的说明，所以使用默认值(调试)。

长话短说;如果您有多个解决方案项目引用多个共享项目，请确保所有解决方案都有所有项目。

相关文章：