为什么VS2008构建与msbuild的同一解决方案不同？

Question

我继承了一个由多个项目组成的解决方案，混合了VB.NET和C＃。它使用IDE“Build Solution”按钮构建得很好。它不是使用“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上至少还有三个类似的问题，但我不能引用它们，因为“新用户只能发布一个超链接”（!!）。抱歉。以下是问题标题，您可以自己搜索：

• different results using msbuild project.sln build vs vs2008 IDE build
• MSBuild builds projects with project references correctly but not from solution
  • 在这里，John Saunders的回答建议使用“devenv”，这对我有用。
• MSBuild doesn’t pick up references of the referenced project

现在我的问题是：

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

我来自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引擎一样使用相同的引擎进行构建，尽管我认为他们正在努力做更多的事情。