我这周进行了类似的调查，以下是我的研究结果:
NAnt:
- 跨平台（支持Linux/Mono）。例如，安装网站到多个目标（即Linux Apache和Windows IIS）可能非常方便。
- 在语法上与Ant相似度达95%（对于当前Ant用户或Java构建者来说很容易上手）
- 集成了NUnit，可作为构建的一部分运行单元测试，并与NDoc集成以生成文档。
MSBuild:
- .NET内置。
- 与Visual Studio集成
- 在Visual Studio中很容易开始使用MSBuild——它全部都在幕后。如果你想深入学习，可以手动编辑文件。
主观差异: （YMMV）
- NAnt文档更加简明。例如，MSBuild任务参考 列出了“Csc Task-描述Csc任务及其参数”。（感谢“帮助”？），而NAnt任务参考“csc-编译C#程序。”更新：我注意到MSBuild文档已经得到改进，现在已经好多了（可能与NAnt相当）。
- 不容易从Visual Studio中直接编辑构建脚本源代码（*.*proj文件）。对于NAnt，我只需让Visual Studio将.build脚本视为XML文件即可。
- 显然，在Visual Studio中，Web应用程序项目默认没有*.*proj文件，因此我很难弄清楚如何运行MSBuild来创建部署脚本。
6
对我来说，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需要更多的思考。学习曲线更陡峭。但是，一旦你“get it”，你就可以用它做一些惊人的事情。
因此，如果您也倾向于函数式或逻辑式编程，并且愿意在看到有形结果之前投入一些时间和精力，我建议您查看MSBuild（当然，我也坚信这种投资最终会得到回报，您可以更有效地做更强大的事情）。
5
就我个人而言，我会同时使用这两种工具来完成同一个项目。
MSBuild非常适合构建Visual Studio解决方案和项目 - 这是它的专长所在。
在我看来，NAnt更容易手动编辑 - 特别是如果你已经了解Ant。NAnt可以使用NAntContrib轻松调用MSBuild。因此，我手工编写NAnt脚本来执行诸如复制已构建文件、清理等操作 - 然后调用MSBuild来完成实际的“将我的C#源代码转换为程序集”的部分。
如果您想要一个示例，请查看我的Protocol Buffers构建文件。（我不会声称它是一个绝妙的NAnt脚本，但它能够胜任工作。）
3
NAnt拥有更多的开箱即用功能，但是MSBuild拥有更好的基本结构（元数据非常实用），这使得构建可重用的MSBuild脚本变得更加容易。
要理解MSBuild可能需要一些时间，但一旦理解，就会发现它很好用。
学习材料:
- 《深入了解 Microsoft 构建引擎：使用 MSBuild 和 Team Foundation Build》
作者：Sayed Ibrahim Hashimi (2009年1月) - 《部署 .NET 应用程序：学习 MSBuild 和 ClickOnce》
作者：Y. Hashimi (2008年9月)
1
3
我注意到几篇帖子提到需要手动编辑.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可能会有一些滞后。
3
将依赖项添加到项目中。 NAnt构建文件与Visual Studio不兼容（在我的情况下，我认为这是优点），因此Visual Studio不会尝试对其进行任何操作。MSBuild任务被嵌入到解决方案中，可以引用其他MSBuild任务。我曾经收到过来自其他人的源代码，结果发现无法构建，因为MSBuild社区任务未安装。我感到特别沮丧的是，即使请求的构建可以继续进行（例如调试构建），Visual Studio也会抛出一堆错误，浪费我调试的时间。简而言之：如果可能，我不喜欢向我的项目添加依赖项。
我不相信Visual Studio的开发团队。这源于Visual Studio早期时会破坏我的HTML。例如，我仍然不使用设计师（最近在会议上我发现同事们也是这样做的）。我发现Visual Studio可能会搞乱DLL文件中的依赖项和版本号（我无法复制此问题，但它在一个项目中始终发生，并导致了很多痛苦和时间的浪费）。我已经采用了一个构建过程，只使用Visual Studio以调试模式构建。对于生产，我使用NAnt来控制一切外部。如果我使用NAnt构建，Visual Studio就不会再干扰。
PS: 我是一名网页开发者，不从事Windows Forms开发。
虽然我对MsBuild不是很熟悉，但我认为双方的一些关键差异可以通过以下方式进行补充：
最近我需要在Nant中构建一个Silverlight项目。我发现如果我只使用MsBuild会更容易 - 最终我在Nant脚本中调用了一个MsBuild任务，所以混合使用两者并不太出奇。
除此之外，我认为这将是个人喜好的问题 - 如果你习惯于在Visual Studio中管理部分/大部分MsBuild功能，那么显然你可以做到这一点。如果你更喜欢手写脚本，并且来自Java世界，那么Nant似乎更灵活、更适合你。
1
因此，我决定保留 VS 的 'proj' 文件，并使用 MSBuild（它们是 MSBuild 文件，至少 VS2005 和 VS2008 使用 MSBuild 项目文件）。对于其他所有任务（自定义配置、单元测试、打包、准备文档等），我使用 NAnt。
对于持续集成，我使用了 CruiseControl。因此，我们有 CC 脚本触发 NAnt 作业，而构建过程则使用 MSBuild。
最后请注意：MSBuild 不支持安装程序项目！因此，您只能调用 DevEnv.com 或直接使用 Visual Studio。这就是我最终所做的，但我默认禁用了所有解决方案配置中的安装项目，因为开发人员通常不需要构建它们，如果他们需要可以手动选择构建它们。
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，但现在他们已经落后了。
1
原文链接