Question

我知道Stack Overflow上还有其他NAnt和MSBuild相关问题，但我找不到两者之间的直接比较，所以这就是问题。

什么时候应该选择NAnt而不是MSBuild？哪个更适合什么？ NAnt更适合家庭/开源项目和MSBuild工作项目吗？这两个中的任何一个有什么经验？

Answer 1

本周我做了类似的调查。这是我能够确定的：

<强>恶性：

跨平台（支持Linux / Mono）。例如，将网站安装到多个目标（即Linux Apache和Windows IIS）可能很方便。
95％的语法与Ant相似（当前Ant用户或Java构建器易于接收）
与NUnit集成以作为构建的一部分运行单元测试，并使用NDoc生成产品文档。

<强>的MSBuild：

内置于.NET。
与Visual Studio集成
在Visual Studio中轻松开始使用MSBuild - 这一切都在幕后进行。如果您想深入了解，可以手动编辑文件。

主观差异： （YMMV）

NAnt文档稍微简单一些。例如，MSBuild Task Reference列出“Csc任务 - 描述Csc任务及其参数。”（感谢“帮助”？），与NAnt Task Reference“csc - 编译C＃程序”。 更新： 我注意到MSBuild documentation已得到改善，现在好多了（可能与NAnt相提并论）。
不容易弄清楚如何直接从Visual Studio中编辑构建脚本源（*。* proj文件）。使用NAnt，我只需让Visual Studio将.build脚本视为XML文件。
显然，在Visual Studio中，Web应用程序项目默认情况下不会获得*。* proj文件，因此我很难弄清楚如何让我的MSBuild运行以创建部署脚本。
NAnt不是Visual Studio内置的，必须使用加载项或“外部工具”添加。设置这有点痛苦。
（编辑:)我的一位同事提出了这个问题 - 如果您想使用CruiseControl建立一台构建机器以进行持续集成，CruiseControl可以很好地与NAnt集成。 更新： CruiseControl还有MSBuild task。
请参阅以下评论，了解主观差异的完整和最新讨论。

Answer 2

MSBuild对我（在Windows平台上）的主要吸引力之一是它本身就是.NET的一部分。这意味着任何与Windows Update一起更新的Windows计算机都将具有MSBuild。除此之外，C＃编译器也是.NET本身的一部分，你有一个可以在干净的机器上构建项目的平台。无需安装Visual Studio庞然大物。另一方面，NAnt必须在触发构建之前显式安装。

仅仅为了记录，我在过去的非平凡构建中使用了NMake，Make，Ant，Rake，NAnt和MSBuild（按此顺序）。我最喜欢的是MSBuild，请放手（我不喜欢它，因为“这就是Visual Studio使用的”）。恕我直言，这是一个非常不受重视的构建工具。

我会将NAnt与MSBuild比较为程序编程和函数编程之间的区别。 NAnt非常简单，你可以看到你所看到的。另一方面，MSBuild需要更多的思考。学习曲线更陡峭。但是一旦你“得到它”，你就可以用它来做一些令人惊奇的事情。

所以我建议你看看MSBuild，如果你也倾向于功能或逻辑风格的编程 - 如果你愿意在看到实际结果之前投入一点时间和精力（当然，我也坚信投资最终会付出代价）关闭，你可以更有效地做更强大的事情。）

Answer 3

就我个人而言，我同时使用两个项目。

MSBuild非常擅长构建Visual Studio解决方案和项目 - 这就是它的用途。

在我看来，NAnt更容易手工编辑 - 特别是如果你已经了解Ant。 NAnt可以使用NAntContrib轻松调用MSBuild。因此，我手工制作一个NAnt脚本来执行复制内置文件，清理等操作 - 并调用MSBuild来实际“将我的C＃源代码转换为程序集”部分。

如果您想要一个例子，请查看我的Protocol Buffers build file。（我不会声称它是一个神话般的NAnt脚本，但它可以完成这项工作。）

Answer 4

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 by Sayed
作者：Y。Hashimi（2008年9月）

Answer 5

KISS =使用MSBuild。

为什么在你有一些能够开箱即用的合理工作的东西中添加其他东西？当MSBuild到达时，NAnt死了。 Mono将有一个MSBuild实现，（xbuild）。

DRY =使用MSBuild。

问问自己，你想从构建系统中得到什么？我想要一个我的IDE也使用的构建系统，而不是维护两种不同的配置。

就个人而言，我很想听听NAnt的一些真实论点，因为我无法想到任何真正存在水的事。

Answer 6

有一件事我注意到有几个海报提到必须手工编辑.csproj（或.vbproj等）文件。

MSBuild允许通过使用.user文件自定义这些。* proj文件。如果我有一个名为 MyCreativelyNamedProject.csproj 的项目并想要自定义其中的MSBuild任务，我可以创建一个名为 MyCreativelyNamedProject.csproj.user 的文件并使用 CustomBeforeMicrosoftCommonTargets 和 CustomAfterMicrosoftCommonTargets 来自定义这些文件。

此外，NAnt和MSBuild都可以通过自定义MSBuild任务和NantContrib扩展来自定义内容。

所以，使用NAnt或MSBuild真的归结为熟悉：

如果您已熟悉Ant，请使用NAnt。学习曲线非常简单。
如果您不熟悉这两种工具，MSBuild已经与Visual Studio集成，不需要其他工具。

同样值得补充的是，MSBuild几乎可以保证在发布后立即与所有新版本的.NET和Visual Studio一起使用，而NAnt可能会有一些延迟。

Answer 7

我使用两者都是因为我的NAnt脚本调用了MSBuild。我坚持使用NAnt的主要原因是隔离。让我解释为什么我觉得这很重要：

为项目添加依赖项。 NAnt构建文件与Visual Studio不同（在我的情况下，我认为这是专业人员）因此Visual Studio不会尝试对它做任何事情。 MSBuild任务是嵌入式解决方案的一部分，可以引用其他MSBuild任务。我收到了其他人的源代码，但发现我无法构建，因为没有安装MSBuild社区任务。我觉得特别令人沮丧的是，Visual Studio不会构建并抛出一堆错误，这些错误使我无法进行调试。尽管事实上所请求的构建可以继续（例如作为调试构建）而没有MSBuild任务的一些额外内容。简而言之：我不喜欢在我的项目中添加依赖项，如果我可以避免它。
我不相信Visual Studio，因为我可以抛弃它的开发团队。这可以追溯到Visual Studio的早期阶段，当时它会屠杀我的HTML。我仍然没有使用设计师（最近在一次会议上我发现同事也这样做了）。我发现Visual Studio可以搞砸DLL文件中的依赖项和版本号（我不能复制它，但它确实在一个项目中发生并且引起了很多的悲伤并且浪费了时间）。我已经使用了一个构建过程，该过程使用Visual Studio仅在调试模式下构建。对于制作，我使用NAnt，以便控制外部的所有内容。如果我使用NAnt构建，Visual Studio就不能再干涉了。

PS：我是一名Web开发人员，不进行Windows窗体开发。

Answer 8

虽然我对MsBuild不是很熟悉，但我认为双方的一些关键差异可以通过增加来补充：

我最近不得不在Nant中构建一个Silverlight项目。我发现如果我只是使用MsBuild做生活会更容易 - 我最终在Nant脚本中调用了一个MsBuild任务，所以我认为混合和匹配两者并不是太常见。

除此之外，我认为这将是个人偏好的问题 - 显然你可以在Visual Studio中管理MsBuild的一些/大部分功能，如果这是你的事情。如果你喜欢手工编写脚本，Nant似乎更灵活，更适合你，如果你来自Java世界，你很可能会在家里用它。

Answer 9

我最终都使用了两者。在重新设计我们的构建系统时，我遇到了一个棘手的问题。也就是说，我无法摆脱.vcproj（和系列），因为我们每个人都在使用VS来更新项目文件，设置和配置。因此，如果没有庞大的重复和容易出错的过程，我们就无法将构建系统建立在一组新文件上。

出于这个原因，我决定保留VS的'proj'文件并使用MSBuild（它们是MSBuild文件，至少VS2005和VS2008使用MSBuild项目文件）。对于其他一切（自定义配置，单元测试，打包，准备文档......）我使用了NAnt。

为了持续集成，我使用了CruiseControl。所以我们有CC脚本触发了NAnt作业，用于构建使用过的MSBuild。

最后一点：MSBuild不支持安装项目！因此，您不得不直接调用DevEnv.com或使用Visual Studio。这就是我最终要做的事情，但我默认从所有解决方案配置中禁用了安装项目，因为开发人员通常不需要构建它们，如果他们这样做，他们可以手动选择构建它们。

Answer 10

由于能够构建VS解决方案，我最近已从NAnt切换到MSBuild。不过，我偶尔会使用NAnt。

您可能还想查看MSBuild Community Tasks，就像NAntContrib。

Answer 11

NAnt提供的文档和教程使您可以更轻松地开始使用NAnt学习构建脚本。一旦我掌握了NAnt并创建构建脚本，我就开始将这些知识翻译成MSBuild（我在NAnt中做了X，我如何在MSBuild中做X？）。微软的文档通常假定知识水平相当高。

从NAnt切换到MSBuild的原因是因为MSBuild更新。不幸的是，NAnt的最后一个版本是在2007年12月8日，而MSBuild 4.0（.NET 4.0）并不遥远。看起来NAnt项目已经死了。

如果您为刚刚开始学习使用MSBuild创建构建脚本的人找到了很好的文档，那么请跳过NAnt并直接进入MSBuild。如果NAnt出现了新版本，那么我会考虑坚持使用NAnt，但现在它们已经落后了。

Answer 12

我们同时使用两者。 NAnt负责所有“脚本”工作，例如复制，在IIS上部署，创建包，MSBuild负责构建解决方案。然后我们可以通过新版本的NAnt来避免不受支持的.NET 4.0的问题。

NAnt也更具可扩展性。如果我们要将部署脚本迁移到生产服务器，我们只复制构建文件并安装适当版本的.NET - csproj文件没有Visual Studio问题：）

Answer 13

Manoj的

YDeliver是一个建立在PSake之上的构建框架。它具有丰富的库函数，定义工作流的能力，并且我们已经使用它将六个以上的企业项目交付给生产。

将其与TeamCity，CruiseControl或任何可以投放PowerShell的内容结合使用。

Answer 14

我们使用FlubuCore。它是一个开源C＃库，用于使用C＃代码构建项目和执行部署脚本。

如何使用flubu的简单示例：

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

您可以在此找到有关flubu以及如何入门的更多信息： choice-for-build-tool-msbuild-nant-or-something-else

NAnt或MSBuild，哪一个可以选择？

14 个答案: