0

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 在解决方案中构建非依赖项目，但恰恰相反......我从http://blogs.msdn.com/b/visualstudio/archive/2010/12/21了解到/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx msbuild 将 sln 文件转换为自己的格式 - 但 sln.metaproj 文件也没有显示对 SubDllProject 的任何引用。

4

1 回答 1

0

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

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

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

于 2013-10-06T21:11:44.680 回答