谁能解释使用MSBuild(或者NAnt)之类的工具来构建项目集合与从命令行运行DevEnv.exe相比有什么优势？

我过去与之合作的一位同事曾解释说(至少使用旧版本的Visual Studio)使用DevEnv.exe的速度比其他技术要慢得多，但是我没有读过任何证据，或者如果现在是现在的讨论要点是，从2005年开始，Visual Studio在后台使用MSBuild。

我知道使用MSBuild的一个优点是可以在不要求将Visual Studio安装在生成机器上的情况下生成项目，但是我不确定是否还有其他优点。

解决方案

使用诸如NAnt或者MsBuild之类的外部构建工具的主要原因是能够自动执行构建过程，从而持续提供有关系统状态的反馈。它们还可以用于除"纯"构建之外的其他事物，这是我们真正从中获得价值的地方，能够使用单个命令构建和测试应用程序是非常有价值的事情。

我们还可以开始添加诸如度量标准收集，打包发行二进制文件之类的东西，以及诸如此类的各种漂亮的东西。

原因之一是，构建产品不仅仅是编译产品。由于这些工具(及其扩展名)提供了哪些功能，因此创建安装，更新版本号，创建托管，分发最终软件包等任务会变得更加容易。

尽管可以使用常规脚本来完成所有这些操作，但是使用NAnt或者MSBuild可以为我们提供一个可靠的框架来完成所有这些操作。两者都有很多社区支持，包括可以下载的其他任务(例如MSBuild社区任务项目)。另外，许多第三方和开源产品都对它们提供了支持。

如果我们只对编译感兴趣(而不是对整个构建过程感兴趣)，则可能会发现MSBuild的一项节省时间的好处是支持使用多个处理器进行构建。

我们正在尝试从DevEnv切换到在幕后使用MsBuild的工具(Visual Build Pro)，并且对于不需要它的项目和哪个项目，我们收到"组装'System.Drawing ...所需的参考"错误。在Visual Studio中构建良好。

我的团队的明显答案是，并不是每个人都安装了Visual Studio，特别是我们没有将Visual Studio安装到我们的build / CI服务器上。

就Cgoes而言，devenv.exe 2005在运行过程中运行编译器，这可能会导致相当大的解决方案出现内存不足异常。 Msbuild依靠为每个项目启动csc.exe进程。不使用devenv / build进行编译的项目可以使用msbuild正常工作。希望你喜欢这个理由。

我们有一个由C＃，托管C ++和普通的旧非托管C ++程序集/ dll组成的大型系统。存在依赖于托管C ++代码的C ++代码，而依赖于托管C ++代码的Ccode依赖于依赖于普通的旧C ++代码的Whew！几年前，当我们设置自动化构建环境时，我们发现MSBuild.exe不能正确处理我们拥有的所有依赖项。

与Microsoft合作，我们能够解决部分问题，但并非全部。如果我的记忆对我有用，我们将永远无法获得依赖于托管C ++ dll来构建的Cassemblies。因此，我们最终制作了一个自定义构建脚本，该脚本从命令行调用了devenv.exe，并且运行良好。

当然，这是VS2005的问题，现在可能已修复，但是脚本仍在起作用，因此我们没有再讨论此问题。