Answers:
我这周做了类似的调查。这是我能够确定的：
NAnt：
MSBuild：
主观差异： （YMMV）
对我而言（在Windows平台上）MSBuild的主要吸引力之一是它是.NET本身的一部分。这意味着，任何具有Windows Update的最新Windows机器都将具有MSBuild。除此之外，C＃编译器也是.NET本身的一部分，并且您拥有一个可以在干净机器上构建项目的平台。无需安装Visual Studio庞然大物。另一方面，必须先明确安装NAnt，然后才能触发构建。
仅出于记录目的，我过去（按此顺序）在非平凡的构建中使用了NMake，Make，Ant，Rake，NAnt和MSBuild。我最喜欢的是MSBuild，放手使用（我不喜欢它，因为“这就是Visual Studio使用的”）。恕我直言，这是一个非常未被重视的构建工具。
我可以将NAnt与MSBuild进行比较，以了解程序和函数编程之间的区别。NAnt非常简单，您可以看到。另一方面，MSBuild需要更多的思考。学习曲线更陡峭。但是，一旦“获得”，就可以用它做一些令人惊奇的事情。
因此，如果您还偏向于函数式或逻辑式编程，那么我建议您看一下MSBuild-如果您愿意花一些时间和精力在看到切实的结果之前（当然，我也坚信投资最终会有所回报，并且您可以更有效地执行更强大的任务）。
就个人而言，我将两者都用于同一项目。
MSBuild非常适合构建Visual Studio解决方案和项目-这就是它的用途。
我认为，NAnt更容易手动编辑-特别是如果您已经了解Ant。NAnt可以使用NAntContrib轻松调用MSBuild。因此，我手工制作了一个NAnt脚本来执行诸如复制生成的文件，清理等工作，然后调用MSBuild进行实际的“将C＃源代码转换为程序集”部分。
如果您想要一个示例，请查看我的协议缓冲区构建文件。（我不会说这是一个很棒的NAnt脚本，但确实可以完成。）
NAnt具有更多可用的功能，但是MSBuild具有更好的基本结构（项目元数据结构），这使得构建可重用的MSBuild脚本变得更加容易。
MSBuild需要花一些时间来理解，但是一旦完成，它就会非常好。
学习资料：
吻 =使用MSBuild。
当您开箱即用时可以做一些合理的工作，为什么还要添加其他内容呢？MSBuild到达时，NAnt死亡。而单将有一个MSBuild实现，（xbuild）。
DRY =使用MSBuild。
问问自己，您要从构建系统中获得什么？我想要一个IDE也可以使用的构建系统，而不是维护两个不同的配置。
就我个人而言，我很想听听有关NAnt的一些真实论点，因为我只是想不出任何真正可以解决的问题。
我注意到几位张贴者提到的一件事是必须手动编辑.csproj（或.vbproj等）文件。
MSBuild允许通过使用.user文件来自定义这些。* proj文件。如果我有一个名为MyCreativelyNamedProject.csproj的项目，并且想在其中自定义MSBuild任务，则可以创建一个名为MyCreativelyNamedProject.csproj.user的文件，并使用CustomBeforeMicrosoftCommonTargets和CustomAfterMicrosoftCommonTargets来自定义这些文件。
而且，可以通过自定义MSBuild任务和NantContrib扩展来针对心脏的内容自定义NAnt和MSBuild。
因此，使用NAnt或MSBuild确实可以使您熟悉：
还值得补充的是，MSBuild几乎可以保证在所有新版本的.NET和Visual Studio发行后就可以使用，而NAnt可能会有一些滞后。
在我的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 Forms开发。
虽然我对MsBuild不太熟悉，但我的印象是双方的一些关键差异可以通过添加来补充：
我最近不得不在南特建立一个Silverlight项目。我发现，如果只是使用MsBuild进行操作，生活会更轻松-我最终从Nant脚本中调用了MsBuild任务，因此我想将两者混合并匹配并不太常见。
除此之外，我想这将是个人喜好问题-显然，您可以在Visual Studio中管理MsBuild的某些/大部分功能。如果您更喜欢手工编写脚本，那么Nant似乎更灵活并且更适合，并且如果您来自Java世界，那么您很可能会熟悉它。
我最终都使用了。重新设计构建系统时，我遇到了一个棘手的问题。也就是说，我无法摆脱.vcproj（及其家族），因为我们每个人都在使用VS更新项目文件，设置和配置。因此，如果没有庞大的重复和容易出错的过程，我们就无法基于新的文件集构建系统。
因此，我决定保留VS的“ proj”文件并使用MSBuild（它们是MSBuild文件，至少VS2005和VS2008使用MSBuild项目文件）。对于其他所有内容（自定义配置，单元测试，包装，准备文档...），我使用了NAnt。
为了进行持续集成，我使用了CruiseControl。因此，我们拥有触发NAnt作业的CC脚本，这些脚本用于构建使用过的MSBuild。
最后一点：MSBuild不支持安装项目！因此，您不得不调用DevEnv.com或直接使用Visual Studio。这就是我最终要做的，但是默认情况下，我从所有解决方案配置中禁用了安装项目，因为开发人员通常不需要构建它们，如果需要，则可以手动选择构建它们。
我最近从NAnt切换到MSBuild，因为它具有构建VS解决方案的能力。不过，我偶尔还是会使用NAnt。
您可能还需要签出类似于NAntContrib的MSBuild社区任务。
可用于NAnt的文档和教程使您更容易开始使用NAnt学习构建脚本。一旦掌握了NAnt并创建了构建脚本，我便开始将该知识转换为MSBuild（我在NAnt中做过X，如何在MSBuild中做X？）。Microsoft的文档通常会在有用之前先假定他们具有很高的知识水平。
从NAnt切换到MSBuild的原因是因为MSBuild最新。不幸的是，NAnt的最新版本是2007年12月8日，而MSBuild 4.0（.NET 4.0）也相距不远。看起来NAnt项目已经死了。
如果您为刚开始学习如何使用MSBuild创建构建脚本的人找到了很好的文档，请跳过NAnt并直接使用MSBuild。如果NAnt曾经发布过新版本，那么我会考虑坚持使用NAnt，但是现在他们落后了。
我们都使用。NAnt负责所有“脚本”工作，例如复制，在IIS上部署，创建程序包，而MSBuild负责构建解决方案。然后，可以通过新版本的NAnt避免不支持的.NET 4.0的问题。
NAnt也更具可扩展性。如果要将部署脚本迁移到生产服务器，则仅复制构建文件并安装.NET的正确版本-csproj文件不会出现Visual Studio问题：）
Manoj的YDeliver是建立在PSake之上的构建框架。它具有丰富的库功能，定义工作流的能力，并且我们已使用它将六个以上的企业项目交付生产。
与TeamCity，CruiseControl或任何可以运行PowerShell的东西一起使用。
我们使用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