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