为什么对于相同的解决方案，VS2008 构建与 msbuild 不同？

Question

我继承了一个由多个项目组成的解决方案，混合了 VB.NET 和 C#。使用 IDE“构建解决方案”按钮可以很好地构建。它不会使用“msbuild foo.sln”从命令行构建；错误消息表明项目 A（引用项目 B）找不到项目 B。事实上，在使用“msbuild”后检查“bin”文件夹的内容并将其与使用 IDE 后的内容进行比较后，我可以发现大量DLL丢失，包括B.dll。

简而言之：项目 A 确实引用了项目 B，但 B.DLL 仅在使用 IDE 时复制到 A 的 bin 目录，而在使用 msbuild 时则不会。如果我在 IDE 构建后运行 msbuild，它会起作用，因为引用的 DLL 已被复制。

我天真地相信“msbuild foo.sln”与 foo.sln 的 IDE 版本相同。事实似乎并非如此。 Stack Overflow 上至少还有其他三个类似的问题，但我无法引用它们，因为“新用户只能发布一个超链接”（！！）。对不起。以下是问题标题，以便您可以自行搜索：

• 使用 msbuild project.sln 构建与 vs2008 IDE 构建的不同结果
• MSBuild 使用项目引用正确构建项目，但不是来自解决方案
  • 这里，John Saunders 的回答建议使用“devenv”，这对我来说确实有效。
• MSBuild 不获取引用项目的引用

现在我的问题是：

1. 在哪里可以找到“构建解决方案”时 Visual Studio 所做的准确记录？
2. 配置 Visual Studio 和持续集成服务器（例如 Hudson）以使开发人员工作站构建与 CI 构建相同的最佳实践是什么？
   • 我们应该按照上面 John Saunders 的建议设置 CI 服务器来使用 devenv 吗？
   • 或者我们应该为 Visual Studio 编写一个 MSBuild 脚本来按照 http://brennan.offwhite.net/blog/2007/05/31/running-msbuild-from-visual-studio/？
   • 还有别的事吗……？

我来自 Unix 世界，所以请随时给我新手指点。

Answer 1

John Weldoon 是正确的，Visual Studio 和 MSBuild 的构建非常相似，但有时可能不同。一种情况是 VS 对于引用更加宽松。假设你有三个项目 A、B 和 C。A 依赖于 B，B 依赖于 C。然后在 VS 中，如果项目 A 仅引用 B，那么它可以，但 MSBuild 可能会抱怨，因为它缺少对项目 C 的引用。
存在一些差异的一个重要原因是 VS 有一个主机编译器，用于帮助增强 IDE 体验。如果您想要降级 IDE 体验，则可以将 MSBuild 属性 UseHostCompilerIfAvailable 设置为 false，以强制 Visual Studio 使用 MSBuild。例如，

<PropertyGroup>
    <UseHostCompilerIfAvailable>false</UseHostCompilerIfAvailable>
</PropertyGroup>

我不建议这样做，但如果您绝对需要它，则可以使用该选项。

Answer 2

在我看来，您应该使用 msbuild 构建 CI 脚本和一般构建脚本。

IDE 并不总是使用与 msbuild 引擎相同的引擎进行构建，尽管我认为他们正在越来越多地这样做。