nAnt 是否仍受支持并适用于 .net 3.5/VS2008？

Question

我正在使用 MSBuild 来构建我的东西。我想通过构建服务器使用 CruiseControl.net。

现在，CCNET 经常引用 nAnt，但看起来 ccnet 可以通过项目配置和 msbuild 完成 nant 可以完成的大部分工作。另外，nAnt 似乎有点不受支持，因为 Beta 版本已经发布快一年了。

简而言之：事实上，我对 MSBuild 非常满意（特别是因为它是“官方”编译器前端），对 nAnt 有点不舒服，但我不想过早做出判断。

使用 nAnt 而不是 MSBuild 的原因是什么？特别是 ccnet，它在功能方面似乎与 nant 有点重叠（并添加了自动构建相关的东西）

Answer 1

如果您对 MSBuild 非常满意，那么我会坚持使用 MSBuild。这可能是您首先学习的工具是您更喜欢的工具的情况之一。我从 NAnt 开始，不太习惯 MSBuild。我确信他们都会存在相当长一段时间。

两者之间存在一些根本差异，最能强调的可能是 一些 NAnt 粉丝和 Microsoftie 之间的对话.

有趣的是， 杰里米·米勒 问了完全相反的问题 在他的博客上 去年。

Answer 2

在我看来，这更多是个人喜好的问题。nAnt 是一个很棒的框架，MSBuild 几乎同样强大。通过轻松开发自定义任务（在两个框架中）的能力，您几乎可以完成您需要做的任何事情。

我无法回答您问题中“仍然受支持”的部分，但我想说，如果您已经对 nAnt 感到满意，那么它可能是可行的。如果您（或您团队中的某人）熟悉 MSBuild，那么这也是一个很好的方法。

Answer 3

如果您已经有了一堆与 nAnt 一起使用的自定义任务，请坚持使用 - MSBuild 不会给您带来太多好处。也就是说，nAnt 似乎没有什么是 MSBuild 无法做到的。两者都可以调用外部工具，都可以运行基于.Net 的自定义任务，并且都有大量社区任务。

我们在这里使用 MSBuild 的原因与您相同 - 它现在是 VS 的默认构建系统，并且我们没有任何 nAnt 特定的东西需要担心。

这 MSBuild社区任务 是一个很好的第三方任务库，涵盖了我在 nAnt 中做过的大部分自定义内容，包括 VSS 和 Subversion 支持。

Answer 4

老实说，这取决于什么更适合您的环境。如果你使用很多非微软工具，nunit、ccnet、ncover。您可能会在 nant 中找到更好的支持。或者，如果您使用 MSTest、TFSBuild，您可能会发现 MSBuild 是一个更好的环境。我会学习并使用两者，其中每一个都更适合您的环境。

Answer 5

CC.NET 只是构建服务器技术，而不是构建脚本技术。我们在工作中使用 CC.NET 非常成功地调用 MSBuild 构建脚本，没有出现任何问题。

NAnt 是一种更古老、更成熟的构建脚本语言，但它们的工作方式相似。在 NAnt 中可以做的事情很少在 MSBuild 中也不能做，所以这实际上取决于您更喜欢哪一项。至于 NAnt 的活跃程度，不要关注最后一次发布的时间……而是关注最后一次夜间构建的时间。NAnt 往往会在发布之间持续很长时间，但夜间构建通常相当稳定。

Answer 6

就像很多人已经指出的那样，这里的答案是“这取决于”。有一些事情像 重复操作 在 NAnt 中更简单、更清晰。看 MSDN 论坛 对此进行讨论。

Answer 7

我发现您也可以使用混合方法，尤其是在较大的项目中。当开发新组件时，我们的许多 nant 脚本正在转换为 msbuild。两者都支持相同的主要功能，并且如果您发现其中一个本身支持但另一个不支持的任务，则可以互相调用。

对于新的 .NET 开发，从 MSBuild 开始可以节省大量时间，因为它可以直接运行解决方案文件。从主编译扩展到执行其他任务（源代码控制、部署等）效果很好。