使用MSBuild或NAnt与从命令行运行DevEnv.exe的优点

Question

有谁可以解释使用像MSBuild（或NAnt）这样的工具构建项目集合与从命令行运行DevEnv.exe有什么好处？

我过去曾与之合作过的一位同事解释说（至少使用旧版本的Visual Studio）使用DevEnv.exe比其他技术要慢得多，但我还没有看到任何证据，或者如果那样现在是一个没有实际意义的问题，从2005年开始，Visual Studio使用了MSBuild。

我知道使用MSBuild的一个优点是允许您构建项目而无需在构建计算机上安装Visual Studio，但我不确定是否还有其他人。

Answer 1

一个原因是因为构建产品不仅仅是编译产品。由于这些工具（及其扩展）提供的功能，创建安装，更新版本号，创建托管，分发最终包等任务变得更加容易。

虽然您可以使用常规脚本完成所有这些操作，但使用NAnt或MSBuild为您提供了一个可靠的框架来完成所有这些操作。社区支持很多，包括可以下载的其他任务（例如 MSBuild社区任务项目 ）。此外，还有许多第三方和开源产品支持它们。

如果您只对编译感兴趣（而不是整个构建过程），您可能会发现MSBuild的一次性节省是支持使用多个处理器进行构建。

Answer 2

我的团队明显的答案是并非所有人都安装了Visual Studio ，特别是我们不会将Visual Studio安装到我们的构建/ CI服务器上。

Answer 3

使用NAnt或MsBuild等外部构建工具的主要原因是能够自动化构建过程，从而提供有关系统状态的持续反馈。除了“纯粹”之外，它们还可用于大量物品。构建，这就是你真正开始从中获取价值的地方，能够用一个命令构建和测试你的应用程序是一件非常有价值的事情。

您还可以开始添加指标集合，发布二进制文件的打包以及各种类似的漂亮内容。

Answer 4

就C＃而言，devenv.exe 2005运行编译器进程，这可能导致大量解决方案的内存不足。 Msbuild尝试为每个项目启动csc.exe进程。不使用devenv / build编译的项目可以正常使用msbuild。希望你喜欢这个理由。

Answer 5

我们正在尝试从DevEnv切换到一个使用MsBuild的工具（Visual Build Pro），我们得到了一个“参考所需的汇编'System.Drawing ......”不需要它的项目的错误，以及在Visual Studio中构建良好的项目。

Answer 6

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

与Microsoft合作，我们能够解决一些问题，但不是全部问题。如果我的记忆为我服务，我们永远无法获得依赖托管C ++ dll构建的C＃程序集。所以我们最终制作了一个自定义构建脚本，它从命令行调用了devenv.exe，它运行得很好。

当然，那是VS2005，它现在可能已修复，但脚本仍在运行，所以我们没有重新讨论这个问题。