我的buildbot已经运行了3年，使用devenv.com在Windows上编译项目。
现在devenv.com在构建64位版本时遇到了麻烦：将配置作为“Debug | x64”传递会因管道字符而产生命令行错误。转义和括在引号之间导致其他错误，有些是因为目录名中的空格，有些是因为奇怪的命令行。
我尝试了vcbuild.exe和MSBuild.exe。 vcbuild.exe完美运行：我想坚持下去。另一方面，MSBuild.exe有一个完全奇怪和复杂的输出，我的同事觉得很糟糕。但它被吹捧为 THE 构建的方式。
问题是：devenv.com，vcbuild.exe和MSBuild.exe中哪一个最有可能持续的方法？
答案 0 :(得分：4)
MSBuild（在Visual Studio 2010 / .NET 4之前）本身并不构建C ++项目。它调用vcbuild.exe。因此，如果您不喜欢使用MSBuild，那么我会坚持使用C ++项目。对于托管项目（以及使用VS 2010的C ++），请使用MSBuild。
答案 1 :(得分：3)
我遇到了同样的问题，并通过Windows-shell转义管道字符来解决它：
"Debug^|Win32"
答案 2 :(得分：3)
MSBuild是“最有可能持续”的方法。 VCBuild.exe已经死了;它的最后一个版本是2008.如果需要从VS2008或更早版本构建VC项目，MSBuild 4.0仍将使用它。至于devenv.exe - 当然，它只是无头的Visual Studio。在功能上它与在VS中命中构建相同。这意味着，这些天，它基本上只是传递给MSBuild，但有时并没有比msbuild.exe更少的并行性。您可能仍然必须使用devenv.exe的主要原因是.vdproj（部署）项目。这些遗留的东西有一个硬编码到VS的构建过程。我建议使用基于MSBuild的WiX或Installshield等替代方案。不久，直到VS中的所有内容都是MSBuild。
简而言之 - MSBuild是未来，除非您有部署项目或其他特殊情况，否则请使用它。
丹
答案 3 :(得分：0)
msbuild.exe没有（没有？）知道如何构建安装项目。 devenv.exe没有。