当MSBuild可用时，为什么我要继续使用Nant？

Question

我看过prior个问题和答案。在那个问题中，原始海报提出了一个后续问题：

  

使用msbuild有哪些令人信服的理由？有缺点吗？

我没有看到答案。我也想知道反过来。 Nant有哪些引人注目的特征？

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

编辑/添加：任何人都有功能列表比较？有人说“nant开箱即用了更多功能。”哪个？

将这些项目结合起来，结合努力以便相互受益是否有意义？有没有人问MS他们是否愿意为社区贡献msbuild，比如WiX？有什么机会？

EDIT2 ：我刚发现this prior discussion，不知道为什么我以前找不到它。

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月）

Answer 2

您将继续使用nant，因为您已经在使用它。如果您正在使用msbuild，并想知道为什么要切换到nant，那么答案是没有真正的理由切换。至少你知道msbuild不会出现任何问题，自2007年12月以来还没有更新过。

Answer 3

考虑到NAnt基于Ant for Java，可能有足够的理由坚持下去。其他构建工具基于Ant - Phing是一个，用于PHP。当我开始使用该工具时，我很快就把它拿起来，因为我已经熟悉了NAnt。

Answer 4

我只是觉得NAnt更容易使用。我敢说这部分是由于我在Ant中的背景，但我发现为协议缓冲区构建一个NAnt文件比为MiscUtil构建MSBuild文件更简单。 更简单。 （即使现在MiscUtil构建中有些东西我想包括但不能 - 将任务的输出转储到文本文件IIRC似乎非常困难。）概念更简单，似乎在评估文件集合等方面会有更少的陷阱。

我目前喜欢使用我之前认为非常愚蠢的设置 - 我使用NAnt作为我的“主”构建文件，但是调用MSBuild来执行实际的“编译我的.NET项目”步骤。为同一个项目建立两个构建系统的想法是令人憎恶的，但我基本上不把MSBuild部分视为一个完整的构建系统 - 它只是一种简单的编译方式，我从不需要手动检查项目文件。 （我只通过Visual Studio与它进行交互。）我已经能够以这种方式非常容易地发展我的Protocol Buffers构建，并且我怀疑如果我使用MSBuild，我将获得相同的体验。

很快我就会尝试用Mono构建它（当2.4发布时 - 直到那时gmcs中有showstoppers），此时我们将看到策略的可移植性......

Answer 5

我们使用混合方法，因为我们在MS-Build可用之前开始使用NANT。然而，MS-Build cna对不依赖的项目执行并行buid，这些项目可以在适当的情况下显着减少构建时间。让NANT与SVN进行交互，部署并且只进行MS-build编译会使我们的构建时间缩短约45％YMMV，具体取决于您构建sln的方式。

Answer 6

浮现在脑海中的一些观点：

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

在我工作的地方，我们目前正在使用来自NAntContrib的msbuild任务的NAnt脚本。