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

【问题标题】：Why would I want to continue to use Nant when MSBuild is available?当 MSBuild 可用时，我为什么要继续使用 Nant？
【发布时间】：2010-10-16 04:18:16
【问题描述】：

我看过prior 的问题和答案。在那个问题中，原发帖人提出了一个后续问题：

使用 msbuild 的令人信服的理由是什么？有缺点吗？

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

我认为，对于 nant 来说，跨平台很大。对于 msbuild，它是与 Visual Studio 的通用和集成。这听起来对吗？还有什么？

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

将这些项目结合起来，共同努力以互惠互利是否有意义？有没有人问过 MS，他们是否愿意为社区贡献 msbuild，比如 WiX？机会有多大？

EDIT2：我刚找到this prior discussion，不知道为什么之前找不到。

【问题讨论】：

重新跨平台 - 请注意，mono 也会读取 csproj (msbuild)。
哇哦，酷。 Mono 的构建工具是……？
对不起 - 我应该重新措辞； nant 将愉快地使用 msbuild 文件

标签： c# .net msbuild nant

【解决方案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 月）

【讨论】：

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

【解决方案2】：

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

【讨论】：

【解决方案3】：

考虑到 NAnt 基于 Ant for Java，可能有足够的理由继续使用它。其他构建工具基于 Ant - Phing 就是其中之一，用于 PHP。当我开始使用该工具时，我很快就学会了，因为我已经熟悉了 NAnt。

【讨论】：

【解决方案4】：

我们使用混合方法，因为我们在 MS-Build 可用之前就开始使用 NANT。但是，MS-Build cna 在不依赖的项目上执行并行构建，这可以在适当的情况下显着减少您的构建时间。让 NANT 与 SVN 交互、部署和仅让 MS-build 进行编译将我们的构建时间缩短了约 45% YMMV，具体取决于您构建 sln 的方式。

【讨论】：

【解决方案5】：

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

我目前喜欢使用我以前认为非常愚蠢的设置 - 我将 NAnt 用于我的“主”构建文件，但调用 MSBuild 来执行实际的“编译我的 .NET 项目”步骤。为同一个项目拥有两个构建系统的想法令人厌恶，但我基本上不会将 MSBuild 部分视为完整的构建系统——它只是一种简单的编译方式，而且我永远不需要手动检查项目文件。（我只通过 Visual Studio 与之交互。）我已经能够通过这种方式非常轻松地改进我的 Protocol Buffers 构建，如果我使用 MSBuild，我怀疑我是否会有同样的体验。

很快我将尝试使用 Mono 构建它（当 2.4 发布时 - 在那之前 gmcs 中会出现停止），此时我们将看到该策略的可移植性...

【讨论】：

效果如何？三年过去了，您对构建系统有何看法？你还会推荐“msbuild inside nant”吗？
@Weeble：对于协议缓冲区，我们现在完全使用 MSbuild - 但坦率地说，我不了解构建系统。对于 Noda Time，我什至没有真正构建系统。我已经看到了关于 psake 的好东西，并且需要一段时间来掌握它......

【解决方案6】：

想到的几点：

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

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

【讨论】：