NAnt或MSBuild，哪一个select什么时候？
我知道有堆栈溢出其他NAnt和MSBuild相关的问题，但我找不到两者之间的直接比较，所以这里是问题。
什么时候应该selectNAnt over MSBuild？ 哪一个更好？ NAnt更适合家庭/开源项目和MSBuild工作项目吗？ 两者中的任何一个有什么经验？
本周我做了类似的调查。 这是我能够确定的：
楠：
- 跨平台（支持Linux / Mono）。 例如，将网站安装到多个目标（即Linux Apache和Windows IIS）可能会很方便。
- 95％的语法与Ant类似（易于当前的Ant用户或Java构build者接受）
- 与NUnit集成，用于运行unit testing作为构build的一部分，用NDoc用于产品文档。
的MSBuild：
- 内置到.NET。
- 与Visual Studio集成
- 在Visual Studio中轻松开始使用MSBuild – 这一切都在幕后。 如果你想深入，你可以手工编辑文件。
主观差异:( YMMV）
- NAnt文档更简单一点。 例如， MSBuild任务参考列出了“Csc任务 – 描述Csc任务及其参数”（感谢“帮助”？），而NAnt任务参考 “csc – 编译C＃程序”。 更新：我注意到MSBuild文档已经改进，现在好多了（可能与NAnt相提并论）。
- 不容易弄清楚如何直接从Visual Studio中编辑构build脚本源（*。* proj文件）。 与NAnt我只是有Visual Studio对待.build脚本作为一个XML文件。
- 显然，在Visual Studio中，Web应用程序项目默认没有得到*。* proj文件，所以我很难搞清楚如何让MSBuild运行在我的程序中来创build一个部署脚本。
- NAnt不是内置于Visual Studio中的，必须添加，或者使用Add-In，或者作为“外部工具”。 这是一个痛苦的设置。
- （编辑:)我的同事之一带来了这个 – 如果你想build立一个使用CruiseControl的生成机器持续集成，CruiseControl与NAnt很好地集成在一起。 更新： CruiseControl也有一个MSBuild任务 。
- 有关主观差异的完整和最新讨论，请参阅下面的评论。
MSBuild对于我来说（在Windows平台上）的一个主要吸引点是它本身就是.NET的一部分。 这意味着任何与Windows Update最新的Windows机器都将具有MSBuild。 除此之外，C＃编译器也是.NET本身的一部分，你有一个可以在干净的机器上构build项目的平台。 无需安装Visual Studio庞然大物。 另一方面，NAnt必须在构build可触发之前明确安装。
只是为了logging，我在过去使用了NMake，Make，Ant，Rake，NAnt和MSBuild（依次）。 我最喜欢的是MSBuild，而且我不赞成，因为“这就是Visual Studio使用的”。 恕我直言，这是一个非常低估的构build工具。
我会比较NAnt与MSBuild程序和function编程之间的区别。 NAnt是相当简单的，你得到你所看到的。 MSBuild另一方面需要更多的思想。 学习曲线陡峭。 但是一旦你“明白了”，你就可以用它做一些了不起的事情。
所以我build议你看看MSBuild，如果你也喜欢function或逻辑风格的编程 – 如果你愿意投入一点时间和精力，然后才能看到明显的结果（当然，我也坚信，投资最终会带来回报，而你可以更有效地做更强大的事情）。
就我个人而言，我同时使用 – 用于同一个项目。
MSBuild非常擅长构buildVisual Studio解决scheme和项目 – 这就是它所做的。
在我看来，NAnt更易于手工编辑，特别是如果您已经了解Ant的话。 NAnt可以很方便地用NAntContrib调用MSBuild。 所以，我手工制作了一个NAnt脚本来完成复制构build文件，清理等工作，并且调用MSBuild来完成“将我的C＃源代码转换为程序集”部分。
如果你想要一个例子，看看我的协议缓冲区生成文件 。 （我不会声称这是一个神话般的NAnt脚本，但它做的工作。）
NAnt具有更多的function，但MSBuild具有更好的基本结构（项目元数据块），这使得构build可重用的MSBuild脚本变得更容易。
MSBuild需要一段时间才能理解，但是一旦你做到了，那就非常好了。
学习资料：
- 在Microsoft Build Engine中：使用MSBuild和Team Foundation Build
Sayed Ibrahim Hashimi（Jan，2009） - 部署.NET应用程序：通过Sayed学习MSBuild和ClickOnce
Y. Hashimi（2008年9月）
KISS =使用MSBuild。
为什么当你有什么东西可以做一个合理的开箱工作的时候添加别的东西？ 当MSBuild到达时，NAnt死了。 而单声道将有一个MSBuild实现，（ xbuild ）。
DRY =使用MSBuild。
问自己，你想从一个构build系统中得到什么？ 我想要一个也由我的IDE使用的构build系统，而不是维护两种不同的configuration。
就我个人而言，我很想听听NAnt的一些真实的论点，因为我想不出任何真正的水。
有一件事我注意到几个海报提到的是手工编辑.csproj（或.vbproj等）文件。
MSBuild允许通过使用.user文件来定制这些.proj文件。 如果我有一个名为MyCreativelyNamedProject.csproj的项目，并且想要自定义其中的MSBuild任务，我可以创build一个名为MyCreativelyNamedProject.csproj.user的文件，并使用CustomBeforeMicrosoftCommonTargets和CustomAfterMicrosoftCommonTargets来定制这些文件。
而且，NAnt和MSBuild都可以通过自定义的MSBuild任务和NantContrib扩展来定制到心脏的内容。
所以，使用NAnt或MSBuild真的归结为熟悉：
- 如果您已经熟悉Ant，请使用NAnt。 学习曲线将会非常简单。
- 如果你不熟悉这两种工具，MSBuild已经与Visual Studio集成，不需要额外的工具。
另外值得一提的是，MSBuild在发布的时候能够很好地与.NET和Visual Studio的所有新版本一起工作，而NAnt可能会有一些滞后。
我使用两个，我的NAnt脚本调用MSBuild。 留在NAnt的主要原因是孤立的 。 让我解释一下为什么我觉得这很重要：
-
添加依赖到你的项目。 NAnt构build文件与Visual Studio是不同的（在我的例子中，我认为这是一个专业版），所以Visual Studio不会试图用它做任何事情。 MSBuild任务embedded解决scheme的一部分，可以参考其他MSBuild任务。 我收到了别人的源代码，只是发现我无法构build，因为MSBuild社区任务没有安装。 我觉得特别令人沮丧的是，Visual Studio只是不会构build，并抛出了一堆错误，这使得我没有时间去debugging。 尽pipe事实上被请求的构build可能已经提前（作为一个debugging版本），没有一些额外的MSBuild任务。 简而言之： 如果我能避免的话，我不喜欢添加依赖到我的项目 。
-
我不相信Visual Studio，因为我可以抛开它的开发团队。 这可以追溯到Visual Studio的早期，它会屠杀我的HTML。 我仍然不使用devise师（最近在一个会议上，我发现同事也是这样做的）。 我发现Visual Studio可以搞砸在DLL文件中的依赖和版本号（我不能复制这个，但它确实发生在一个项目中，造成了很多的悲伤和失去了时间）。 我已经使用了Visual Studio的构build过程来构builddebugging模式。 为了生产，我使用NAnt，这样我就可以控制所有的东西。 如果我使用NAnt构build，Visual Studio就不能再干预了。
PS：我是一个Web开发人员，不做Windows窗体开发。
虽然我对MsBuild不是很熟悉，但是我觉得双方的一些关键差异可以通过补充来补充：
- MsBuildTasks
- NantContrib
我最近不得不在南特build立一个Silverlight项目。 我发现生活会更容易，如果我只是用MsBuild做到这一点 – 我最终从一个Nant脚本中调用了一个MsBuild任务，所以我认为混合和匹配这两个并不太常见。
除此之外，我想这将是一个个人喜好的问题 – 显然你可以在Visual Studio中pipe理一些/大部分的MsBuild的function，如果这是你的事情。 南特似乎更灵活，更适合，如果你喜欢手写脚本，如果你来自Java世界，你可能会在家里与它。
我结束了使用两个。 当重新devise我们的构build系统时，我面临一个棘手的问题。 也就是说，我无法摆脱.vcproj（和家庭），因为我们每个人都使用VS来更新项目文件，设置和configuration。 因此，如果没有大量的重复和容易出错的过程，我们不能将我们的构build系统build立在一组新的文件上。
出于这个原因，我决定保留VS的'proj'文件并使用MSBuild（他们是MSBuild文件，至lessVS2005和VS2008使用MSBuild项目文件）。 对于其他一切（自定义configuration，unit testing，打包，准备文档…）我使用NAnt。
为了持续集成，我使用了CruiseControl。 所以我们有触发NAnt作业的CC脚本，这些作业用于构build使用的MSBuild。
最后一个注意：MSBuild不支持安装项目！ 所以你一直在调用DevEnv.com或直接使用Visual Studio。 这就是我最终做的，但是我默认情况下禁用了所有解决schemeconfiguration中的安装项目，因为开发人员通常不需要构build它们，如果他们这样做，他们可以手动select构build它们。
我最近从NAnt切换到了MSBuild，因为它能够构buildVS解决scheme。 但我仍然偶尔使用NAnt。
您也可能想要查看MSBuild社区任务 ，就像NAntContrib。
NAnt提供的文档和教程使得开始使用NAnt学习构build脚本变得更加容易。 一旦我得到了NAnt的窍门并创build了构build脚本，我开始将这些知识转化为MSBuild（我在NAnt中做了X，如何在MSBuild中做X）。 微软的文档通常会在其有用之前就具有相当高的知识水平。
从NAnt切换到MSBuild的原因是因为MSBuild更加stream行。 不幸的是，NAnt的最后一个版本是2007年12月8日，而MSBuild 4.0（.NET 4.0）并不遥远。 看起来NAnt项目已经死亡。
如果你刚刚开始学习使用MSBuild创build构build脚本的人find好的文档，那么跳过NAnt并直接进入MSBuild。 如果NAnt出现了新的版本，那么我会考虑与NAnt保持联系，但现在它们已经落后了。
Manoj的YDeliver是一个构build在PSake之上的构build框架。 它具有丰富的库function，定义工作stream程的能力，我们已经使用它来交付超过六个企业项目的生产。
将其与TeamCity ， CruiseControl或任何可以运行PowerShell的任何东西结合使用。
我们使用两个。 NAnt负责所有“脚本”的工作，比如复制，在IIS上部署，创build包，MSBuild负责构build解决scheme。 然后，我们可以通过新版本的NAnt避免不支持.NET 4.0的问题。
NAnt也更具可扩展性。 如果我们想将部署脚本迁移到生产服务器，我们只复制构build文件并安装适当的.NET版本 – 没有Visual Studio与csproj文件的问题:)
我们使用FlubuCore。 这是一个开源C＃库，用于构build项目并使用C＃代码执行部署脚本。
如何使用flubu的简单例子：
protected override void ConfigureTargets(ITaskContext session) { var compile = session.CreateTarget("compile") .SetDescription("Compiles the solution.") .AddTask(x => x.CompileSolutionTask()) .DependsOn("generate.commonassinfo"); } 你可以find更多关于flubu的信息，以及如何从这里开始： choice-for-build-tool-msbuild-nant-or-something-else
