.net NAnt 或 MSBuild，该选择哪一个？何时选择？

NAnt or MSBuild, which one to choose and when?

提问by Yordan Pavlov

I am aware there are other NAntand MSBuildrelated questions on Stack Overflow, but I could not find a direct comparison between the two and so here is the question.

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

When should one choose NAnt over MSBuild? Which one is better for what? Is NAnt more suitable for home/open source projects and MSBuild for work projects? What is the experience with any of the two?

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

采纳答案by Ogre Psalm33

I've done a similar investigation this week. Here's what I've been able to determine:

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

NAnt:

南特：

• Cross-platform (supports Linux/Mono). It may be handy for installing a web site to multiple targets (that is, Linux Apache and Windows IIS), for example.
• 95% similar in syntax to Ant (easy for current Ant users or Java builders to pick up)
• Integration with NUnit for running unit tests as part of the build, and with NDoc for producting documentation.

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

MSBuild:

MSBuild：

• Built-in to .NET.
• Integrated with Visual Studio
• Easy to get started with MSBuild in Visual Studio - it's all behind the scenes. If you want to get deeper, you can hand edit the files.

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

Subjective Differences:(YMMV)

主观差异：（YMMV）

• NAnt documentation is a little more straightforward. For example, the MSBuild Task Referencelists "Csc Task - Describes the Csc task and its parameters. " (thanks for the "help"?), vs the NAnt Task Reference"csc - Compiles C# programs." UPDATE:I've noticed the MSBuild documentationhas been improved and is much better now (probably on par with NAnt).
• Not easy to figure out how to edit the build script source (*.*proj file) directly from within Visual Studio. With NAnt I just have Visual Studio treat the .build script as an XML file.
• Apparently, in Visual Studio, Web Application Projects don't get a *.*proj file by default, so I had great difficulty figuring out how to even get MSBuild to run on mine to create a deployment script.
• NAnt is not built-in to Visual Studio and has to be added, either with an Add-In, or as an "External Tool". This is a bit of a pain to set up.
• (Edit:) One of my coworkers brought this up--if you want to set up a build machine using CruiseControlfor continuous integration, CruiseControl integrates with NAnt nicely out of the box. UPDATE:CruiseControl also has an MSBuild task.
• Please see comments below for full and up-to-date discussion of subjective differences.

• NAnt 文档更简单一些。例如，MSBuild 任务参考列出了“Csc 任务 - 描述 Csc 任务及其参数。”（感谢“帮助”？），对比NAnt 任务参考“csc - 编译 C# 程序”。更新：我注意到MSBuild 文档已经改进，现在好多了（可能与 NAnt 相当）。
• 很难弄清楚如何直接从 Visual Studio 中编辑构建脚本源（*.*proj 文件）。使用 NAnt，我只让 Visual Studio 将 .build 脚本视为 XML 文件。
• 显然，在 Visual Studio 中，Web 应用程序项目默认不会获得 *.*proj 文件，因此我很难弄清楚如何甚至让 MSBuild 在我的上运行以创建部署脚本。
• NAnt 不是 Visual Studio 内置的，必须通过插件或“外部工具”添加。设置起来有点麻烦。
• （编辑：）我的一位同事提出了这一点——如果您想使用CruiseControl设置构建机器以进行持续集成，CruiseControl 可以很好地与 NAnt 集成开箱即用。更新：CruiseControl 也有一个MSBuild 任务。
• 有关主观差异的完整和最新讨论，请参阅下面的评论。

回答by Milan Gardian

One of the major draws of MSBuild for me (on Windows platforms) is that it comes as part of .NET itself. That means that any Windows machine that is up-to-date with Windows Update will have MSBuild available. Add to this the fact that C# compiler is also part of .NET itself and you have a platform that can build projects on clean machines. No need to install Visual Studio behemoth. NAnt, on the other hand, has to be explicitly installed before a build can be triggered.

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

Just for the record, I've used NMake, Make, Ant, Rake, NAnt and MSBuild on non-trivial builds in the past (in that order). My favourite is MSBuild, hands down (and I do not favour it because "that's what Visual Studio uses"). IMHO, it is a very under-appreciated build tool.

只是为了记录，我过去曾在非平凡的构建中使用过 NMake、Make、Ant、Rake、NAnt 和 MSBuild（按此顺序）。我最喜欢的是 MSBuild，毫无疑问（我不喜欢它，因为“这是 Visual Studio 使用的”）。恕我直言，这是一个非常不被重视的构建工具。

I would compare NAnt vs. MSBuild to the difference between procedural and functional programming. NAnt is quite straightforward and you-get-what-you-see. MSBuild on the other hand requires a bit more thought. The learning curve is steeper. But once you "get it", you can do some amazing things with it.

我会将 NAnt 与 MSBuild 与过程编程和函数式编程之间的区别进行比较。NAnt 非常简单，一目了然。另一方面，MSBuild 需要更多思考。学习曲线更陡峭。但是一旦你“得到它”，你就可以用它做一些了不起的事情。

So I would recommend looking at MSBuild if you also gravitate towards functional or logical style programming - if you are willing to invest a bit of time and effort before seeing tangible results (of course, I also strongly believe that the investment eventually pays off and you can do more powerful things more efficiently).

因此，如果您也倾向于函数式或逻辑风格的编程，我建议您查看 MSBuild - 如果您愿意在看到实际结果之前投入一些时间和精力（当然，我也坚信投资最终会得到回报，并且您可以更高效地做更强大的事情）。

回答by Jon Skeet

Personally, I use both - for the same project.

就个人而言，我将两者都用于同一个项目。

MSBuild is great at building Visual Studio solutions and projects - that's what it's made for.

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

NAnt is more easily hand-editable, in my opinion - particularly if you already know Ant. NAnt can call MSBuild very easily with NAntContrib. So, I hand-craft a NAnt script to do things like copying built files, cleaning up etc - and call MSBuild to do the actual "turn my C# source code into assemblies" part.

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

If you want an example of that, look at my Protocol Buffers build file. (I wouldn't claim it's a fabulous NAnt script, but it does the job.)

如果您想要一个示例，请查看我的Protocol Buffers 构建文件。（我不会声称这是一个很棒的 NAnt 脚本，但它确实可以。）

回答by Konstantin Tarkus

NAnthas more features out of the box, but MSBuildhas a much better fundamental structure (item metadata rocks) which makes it much easier to build reusable MSBuild scripts.

NAnt具有更多开箱即用的功能，但MSBuild具有更好的基本结构（项目元数据岩石），这使得构建可重用的 MSBuild 脚本变得更加容易。

MSBuild takes a while to understand, but once you do it's very nice.

MSBuild 需要一段时间才能理解，但是一旦你理解它就非常好。

Learning materials:

学习资料：

• Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build
  by Sayed Ibrahim Hashimi (Jan, 2009)
• Deploying .NET Applications: Learning MSBuild and ClickOnce by Sayed
  by Y. Hashimi (Sep, 2008)

• 在 Microsoft Build Engine 中：使用 MSBuild 和 Team Foundation Build
  ，作者 Sayed Ibrahim Hashimi（2009 年 1 月）
• 部署 .NET 应用程序：
  Y. Hashimi Sayed的《学习 MSBuild 和 ClickOnce》（2008 年 9 月）

回答by Squirrel

KISS= Use MSBuild.

KISS= 使用 MSBuild。

Why add something else into the mix when you have something that will do a reasonable job out of the box? When MSBuild arrived, NAnt died. And Monowill have an MSBuild implementation, (xbuild).

当您有一些可以立即完成合理工作的东西时，为什么还要添加其他东西呢？当 MSBuild 到来时，NAnt 就死了。而单将有一个MSBuild实现，（xbuild）。

DRY= Use MSBuild.

DRY= 使用 MSBuild。

Ask yourself what do you want out of a build system? I want a build system that is also used by my IDErather than the maintaining two different configurations.

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

Personally, I'd love to hear some real arguments for NAnt, because I just can't think of any that really hold water.

就我个人而言，我很想听听 NAnt 的一些真实论据，因为我想不出任何真正站得住脚的论据。

回答by CleverPatrick

One thing I noticed several posters mention was having to hand edit the .csproj (or .vbproj, etc.) files.

我注意到一些海报提到的一件事是必须手动编辑 .csproj（或 .vbproj 等）文件。

MSBuild allows customization of these .*proj files through the use of .user files. If I have a project named MyCreativelyNamedProject.csprojand want to customize the MSBuild tasks inside of it, I can create a file named MyCreativelyNamedProject.csproj.userand use the CustomBeforeMicrosoftCommonTargetsand CustomAfterMicrosoftCommonTargetsto customize those files.

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

Also, both NAnt and MSBuild can be customized to the heart's content through custom MSBuild tasks and through NantContrib extensions.

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

So, using NAnt or MSBuild really comes down to familiarity:

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

• If you are already familiar with Ant, use NAnt. The learning curve will be very easy.
• If you are not familiar with either tool, MSBuild is integrated with Visual Studio already and requires no additional tools.

• 如果您已经熟悉 Ant，请使用 NAnt。学习曲线将非常容易。
• 如果您不熟悉任一工具，MSBuild 已与 Visual Studio 集成，不需要其他工具。

It is also worth adding that MSBuild is pretty much guaranteed to work with all new versions of .NETand Visual Studio as soon as they are released, whereas NAnt may have some lag.

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

回答by CleverPatrick

I use both in that my NAntscripts call MSBuild. My main reason for staying with NAnt is isolation. Let me explain why I feel this is important:

我使用这两者，因为我的NAnt脚本调用 MSBuild。我留在 NAnt 的主要原因是隔离。让我解释一下为什么我觉得这很重要：

1. Adding dependencies to your project. The NAnt build file is alien to Visual Studio (in my case I consider this a pro) so Visual Studio does not attempt to do anything with it. MSBuild tasks are embedded so part of the solution and can refer to other MSBuild tasks. I've received source code from someone else only to find out I could not build, because the MSBuild community tasks were not installed. What I find particularly frustrating is that Visual Studio just would not build and threw a bunch of errors that made me loose time debugging. This, despite the fact that the build being requested could have gone ahead (as a debug build for instance) without some of the extras of the MSBuild task. In short: I don't like adding dependencies to my project if I can avoid it.

2. I don't trust Visual Studio as far as I could throw its development team. This stems back to the early days of Visual Studio when it would massacre my HTML. I still do not use the designer for instance (at a conference recently I found colleagues did the same). I have found that Visual Studio can screw up dependencies and version numbers in the DLL file (I cannot replicate this, but it did happen in a project consistently and caused a lot of grief and lost time). I have resorted to a build procedure that uses Visual Studio to build in debug mode only. For production, I use NAnt so that I control everything externally. Visual Studio just cannot interfere any longer if I build using NAnt.

1. 向您的项目添加依赖项。NAnt 构建文件与 Visual Studio 无关（在我的情况下，我认为这是一个专业人士），因此 Visual Studio 不会尝试用它做任何事情。MSBuild 任务是嵌入的，因此是解决方案的一部分，可以参考其他 MSBuild 任务。我从其他人那里收到了源代码，却发现我无法构建，因为没有安装 MSBuild 社区任务。我觉得特别令人沮丧的是，Visual Studio 只是不会构建并抛出一堆错误，这让我没有时间调试。尽管事实上请求的构建可能已经进行（例如作为调试构建）而没有 MSBuild 任务的一些额外功能。简而言之：如果可以避免的话，我不喜欢在我的项目中添加依赖项。

2. 我不信任 Visual Studio，因为我可以抛弃它的开发团队。这可以追溯到 Visual Studio 的早期，当时它会屠杀我的 HTML。例如，我仍然不使用设计器（最近在一次会议上我发现同事也这样做）。我发现 Visual Studio 可以搞砸 DLL 文件中的依赖项和版本号（我无法复制这一点，但它确实在项目中持续发生，并造成了很多痛苦和浪费时间）。我求助于使用 Visual Studio 仅在调试模式下构建的构建过程。对于生产，我使用 NAnt 以便从外部控制一切。如果我使用 NAnt 构建，Visual Studio 就不能再干扰了。

PS: I'm a web developer and do not do Windows Forms development.

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

回答by mmacaulay

While I'm not very familiar with MsBuild, I'm under the impression that some of key differences on both sides can be supplemented by additions:

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

• MsBuildTasks
• NantContrib

• 构建任务
• 南特贡献

I recently had to build a Silverlight project in Nant. I discovered that life would be easier if I just did this with MsBuild - I ended up calling a MsBuild task from within a Nant script so I suppose it's not too out of the ordinary to mix and match the two.

我最近不得不在南特建立一个 Silverlight 项目。我发现如果我只是用 MsBuild 来做这件事，生活会更容易 - 我最终从 Nant 脚本中调用了一个 MsBuild 任务，所以我想混合和匹配两者并不太不寻常。

Beyond that, I suppose it's going to be a question of personal preference - obviously you can manage some/most of MsBuild's functionality from within Visual Studio, if that's your thing. Nant seems more flexible and better suited if you prefer to write scripts by hand, and if you come from the Java world you'll likely be right at home with it.

除此之外，我想这将是个人偏好的问题 - 显然，您可以在 Visual Studio 中管理部分/大部分 MsBuild 功能，如果这是您的事的话。如果您更喜欢手工编写脚本，那么 Nant 似乎更灵活，更适合，如果您来自 Java 世界，您可能会对它感到宾至如归。

回答by Ash

I ended up using both. When redesigning our build system, I was facing a tricky problem. Namely, I couldn't get rid of .vcproj (and family) because we everybody was using VS to update the project files, settings, and configurations. So without a huge duplication and error prone process, we couldn't base our build system on a new set of files.

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

For this reason, I decided to keep the 'proj' files of VS and use MSBuild (they are MSBuild files, at least VS2005 and VS2008 use MSBuild project files). For everything else (custom configuration, unit testing, packaging, preparing documentation...) I used NAnt.

为此，我决定保留VS的'proj'文件并使用MSBuild（它们是MSBuild文件，至少VS2005和VS2008使用MSBuild项目文件）。对于其他所有内容（自定义配置、单元测试、打包、准备文档...），我使用了 NAnt。

For continuous integration, I used CruiseControl. So we had CC scripts that triggered NAnt jobs, which for building used MSBuild.

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

One final note: MSBuild does NOT support Setup projects! So you're stuck with calling DevEnv.com or using Visual Studio directly. That's what I ended up doing, but I disabled the setup project by default from all solution configurations, since developers wouldn't normally need to build them, and if they do, they can manually select to build them.

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

回答by mcdon

The documentation and tutorials available for NAnt make it easier to begin learning build scripts with NAnt. Once I got the hang of NAnt and creating build scripts I started translating that knowledge to MSBuild (I did X in NAnt, how do I do X in MSBuild?). Microsoft's documentation usually assumes a pretty high level of knowledge before it is useful.

可用于 NAnt 的文档和教程使开始学习使用 NAnt 构建脚本变得更加容易。一旦我掌握了 NAnt 并创建了构建脚本，我就开始将这些知识翻译成 MSBuild（我在 NAnt 中做了 X，我如何在 MSBuild 中做 X？）。Microsoft 的文档在有用之前通常假定知识水平相当高。

The reason for switching from NAnt to MSBuild is because MSBuild is more current. Unfortunately the last release of NAnt was in December 8 2007, while MSBuild 4.0 (.NET 4.0) isn't far off. It looks like the NAnt project has died.

从 NAnt 切换到 MSBuild 的原因是因为 MSBuild 是最新的。不幸的是，NAnt 的最后一次发布是在 2007 年 12 月 8 日，而 MSBuild 4.0 (.NET 4.0) 也不远了。看起来 NAnt 项目已经死了。

If you find good documentation for someone just beginning to learn creating build scripts using MSBuild, then skip NAnt and go straight for MSBuild. If NAnt ever comes out with a new release then I'd consider sticking with NAnt, but they're lagging behind now.

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