有谁可以解释使用像MSBuild（或NAnt）这样的工具构建项目集合与从命令行运行DevEnv.exe有什么好处？
我过去曾与之合作的一位同事解释说（至少使用较旧版本的Visual Studio）使用DevEnv.exe比其他技术慢得多，但我还没有看到任何证据，或者如果那样现在是一个没有实际意义的问题，从2005年开始，Visual Studio使用了MSBuild。
我知道使用MSBuild的一个优点是允许您构建项目而无需在构建计算机上安装Visual Studio，但我不确定是否还有其他人。
答案 0 :(得分：16)
一个原因是因为构建产品不仅仅是编译产品。由于这些工具（及其扩展）提供的功能，创建安装，更新版本号，创建托管，分发最终包等任务变得更加容易。
虽然您可以使用常规脚本完成所有这些操作，但使用NAnt或MSBuild为您提供了一个可靠的框架来完成所有这些操作。社区支持很多，包括可以下载的其他任务（例如MSBuild Community Tasks Project）。此外，还有许多第三方和开源产品支持它们。
如果您只对编译感兴趣（而不是整个构建过程），您可能会发现MSBuild的一次性节约优势是support for building with multiple processors。
答案 1 :(得分：6)
我的团队明显的答案是并非所有人都安装了Visual Studio ，特别是我们不会将Visual Studio安装到我们的构建/ CI服务器上。
答案 2 :(得分：2)
使用NAnt或MsBuild等外部构建工具的主要原因是能够自动化构建过程，从而提供有关系统状态的持续反馈。除了“纯粹”构建之外，它们还可以用于大量事物，而这正是您真正开始从中获取价值的地方，能够使用单个命令构建和测试应用程序是极其有价值的事情。
您还可以开始添加指标集合，发布二进制文件的打包以及各种类似的漂亮内容。
答案 3 :(得分：2)
就C＃而言，devenv.exe 2005运行编译器进程，这可能导致大量解决方案的内存不足。 Msbuild尝试为每个项目启动csc.exe进程。不使用devenv / build编译的项目可以正常使用msbuild。希望你喜欢这个理由。
答案 4 :(得分：0)
我们正在尝试从DevEnv切换到使用MsBuild的工具（Visual Build Pro），我们得到了一个“需要参考组件'System.Drawing ...”错误的项目不需要它在Visual Studio中构建得很好。
答案 5 :(得分：0)
我们有一个由C＃，托管C ++和普通的非托管C ++程序集/ dll组成的大型系统。 C ++代码依赖于托管C ++代码，这些代码依赖于C＃代码，这些代码依赖于依赖于普通旧C ++代码的托管C ++代码（哇！）。几年前，当我们设置自动构建环境时，我们发现MSBuild.exe没有正确处理我们拥有的所有依赖项。
与Microsoft合作，我们能够解决一些问题，但不是全部问题。如果我的记忆为我服务，我们永远无法获得依赖托管C ++ dll构建的C＃程序集。所以我们最终制作了一个自定义构建脚本，它从命令行调用了devenv.exe，它运行得很好。
当然，那是VS2005，它现在可能已修复，但脚本仍在运行，所以我们没有重新讨论这个问题。