解决依赖项目

Question

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

只是为了展示这种情况下的主要参与者，以及一个简单的重现方法： 解决方案包含 ExeProject 和 MainDllProject，MainDllProject 依赖于不属于解决方案的 SubDllProject（但在文件系统的同一层次结构中）。 ExeProject依赖MainDllProject的MainDllProjectClass1（该类不依赖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 构建解决方案时，构建成功。奇怪的是，尽管有参数 /p:Configuration=Release，但还是构建了 SubDllProject 的调试版本。

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

注意：这种情况类似于Visual studio build non-dependent projects in solution，但恰恰相反... 我从http://blogs.msdn.com/b/visualstudio/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx 了解到，msbuild 将 sln 文件转换为自己的格式 - 但 sln.metaproj 文件也没有显示对 SubDllProject 的任何引用。

Answer 1

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

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

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