为什么在有MSBuild的情况下，我还要继续使用Nant呢？

Question

我已经看到了prior的问题和答案。在那个问题中，原帖作者问了一个跟进问题：

“使用msbuild的有力理由是什么？有缺点吗？”

我没有看到对此的回答。我也想知道反过来的情况。Nant有哪些引人注目的特性？

我认为，对于nant来说，跨平台是很重要的。对于msbuild来说，它是与Visual Studio的货币和集成。这样听起来对吗？还有其他的吗？

编辑/添加：有人有功能列表比较吗？有人说“nant开箱即用的功能更多。” 是哪些？

将这些项目合并起来，共同努力以互惠互利，这有意义吗？有人问过微软是否愿意像WiX一样向社区贡献msbuild吗？机会有多大？

编辑2：我刚刚找到了this prior discussion，不确定为什么之前找不到它。

- Cheeso

---

关于跨平台 - 请注意，Mono也可以读取csproj（msbuild）文件。 - Marc Gravell

哦哦哦，很酷。Mono的构建工具是什么？ - Cheeso

抱歉，我本应该重新表述一下：“nant”可以很好地与msbuild文件配合使用。 - Marc Gravell

Answer 1

Nant拥有更多的功能，但是MSBuild有更好的基本结构（项目元数据很棒），这使得构建可重用的MSBuild脚本变得更加容易。

要了解MSBuild需要一些时间，但一旦你学会了，就会觉得它非常好用。

学习资料：

• 《Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build》，Sayed Ibrahim Hashimi著，2009年1月出版。
• 《Deploying .NET Applications: Learning MSBuild and ClickOnce》，Sayed Y. Hashimi著，2008年9月出版。

- Koistya Navin

---

我有完全相反的经历。我发现 MSBuild 脚本令人困惑，而 NAnt 脚本则很直观。我建议人们自己比较工具并得出自己的结论。 - TrueWill

Answer 2

我认为使用NAnt更容易。我敢说这部分原因是由于我的Ant背景，但是相比于为MiscUtil构建MSBuild文件，为Protocol Buffers构建NAnt文件要简单得多。即使现在在MiscUtil的构建中有一些我想包含但无法包含的东西——我IRC记得，似乎将任务的输出转储到文本文件中非常困难。概念更简单，而且在评估文件集合的时间等方面似乎没有太多陷阱。

目前，我喜欢使用之前认为非常愚蠢的设置——我使用NAnt作为“主”构建文件，但调用MSBuild来执行实际的“.NET项目编译”步骤。在同一个项目中使用两个构建系统的想法令人憎恶，但我基本上不将MSBuild部分视为完整的构建系统——它只是一种方便的编译方式，我从不需要手动检查项目文件。（我只通过Visual Studio与它互动。）我通过这种方式很容易地发展了我的Protocol Buffers构建，并且我怀疑如果我使用了MSBuild，我不会有同样的经历。

很快我将尝试使用Mono构建所有内容（等到2.4发布时——在此之前，gmcs中有致命缺陷），届时我们将看到这种策略的可移植性如何...

- Jon Skeet

---

那个怎么样了？三年过去了，你对构建系统有什么感觉？你还会推荐“在nant中使用msbuild”吗？ - Weeble

@Weeble：对于协议缓冲区，我们现在完全使用MSbuild - 但坦白地说，我并不理解构建系统。对于Noda Time，我甚至没有真正的构建系统。我看到了许多关于psake的好东西，需要抽时间深入了解一下... - Jon Skeet

Answer 3

您会继续使用nant，因为您已经在使用它。如果您正在使用msbuild，并想知道为什么要切换到nant，则答案是没有真正的理由要切换。至少您知道msbuild不会消失，而nant自2007年12月以来就没有更新了。

- Pablote

Answer 4

考虑到NAnt是基于Java的Ant开发的，这可能足以让我们坚持使用它。其他构建工具也是基于Ant开发的，比如PHP的Phing。当我开始使用这个工具时，由于我已经熟悉NAnt，所以很快就掌握了它。

- Grant Palin

Answer 5

我们采用混合方法，因为在 MS-Build 可用之前，我们开始使用 NANT。但是，在不依赖的项目上，MS-Build 可以进行并行构建，在适当情况下，可以显著缩短构建时间。让 NANT 与 SVN 交互、部署，并让 MS-Build 进行编译，将我们的构建时间缩短了约 45%，根据您如何构建解决方案而异。

- MikeJ

Answer 6

我想到了一些要点：

• 如果你正在使用Windows Workflow Foundation（编译*.xoml文件），则必须使用msbuild（WPF可能也是如此）
• 如果你使用wix来构建安装程序.msi文件，可以使用VisualStudio或msbuild编译wix脚本（如果出现错误，VS可以跳转到有问题的wix脚本行）
• msbuild允许你拥有与开发/Visual Studio环境尽可能相似的构建环境（例如，在使用msbuild进行构建时，会执行postbuild事件，你不必手动维护一个*.cs文件列表以进行csc任务等）

在我的工作中，我们目前正在使用NAnt脚本和NAntContrib中的msbuild任务。

- Petar Repac