我目前使用nant，ccnet（巡航控制），svn，mbunit。我使用msbuild来做我的sln构建只是因为它更容易出壳。
将整个构建脚本切换到MSBuild是否有任何优点？我需要能够运行测试，watir样式测试，xcopy部署。这更容易吗？
更新：任何引人注目的功能会导致我从nant转移到msbuild吗？
答案 0 :(得分：31)
我喜欢MSBuild。一个原因是.csproj文件是msbuild文件，VS中的构建就像在命令行中构建一样。另一个原因是TeamCity的良好支持，这是我一直在使用的CI服务器。如果您开始使用MSBuild，并且希望在构建过程中执行更多自定义操作，请获取MSBuild Community Tasks。他们为您提供了许多额外的好工作。我已经好几年没用过NAnt了，我并没有后悔。
另外，正如Ruben所提到的，CodePlex上有SDC Tasks个任务。
为了更有趣，还有MSBuild Extension Pack on CodePlex，其中包含推特任务。
答案 1 :(得分：27)
我的建议正好相反 - 避免像瘟疫那样的MSBuild。 NANT更容易设置您的构建以进行自动测试，部署到多个生产环境，与cruisecontrol集成以用于入口环境，与源代码控制集成。我们通过TFS / MSBuild（使用TFSDeployer，自定义PowerShell脚本等）经历了如此多的痛苦，以使它能够完成我们能够用NANT开箱即用的功能。不要浪费你的时间。
答案 2 :(得分：12)
使用MSBuild的最令人信服的理由（至少在.NET 3.5及更高版本中） - 构建引擎可以同时构建。
这意味着在您拥有多个内核/处理器的构建中可以大幅提升。
在3.5之前，MSBuild没有进行并行构建。
答案 3 :(得分：9)
我觉得MSBuild和Nant相当可比。如果您使用其中一种，我通常不会在它们之间切换，除非您选择的产品中缺少令人信服的功能。
我个人使用MSBuild进行任何新项目，但您的里程可能会有所不同。
希望有所帮助！
编辑： @ChanChan - @Jon提到Nant没有构建.NET 3.5应用程序。这可能足以成为改变或至少并行使用它们的理由。随着我越来越倾向于MSBuild，我可能不是最明智的人，可以用这两种技术突出显示任何其他showstoppers。
编辑：Nant现在正在构建.NET 3.5应用程序。
答案 4 :(得分：3)
NAnt已经存在更长时间，并且是一种相当成熟的产品，而且IMO也更容易使用。如果您有兴趣构建可以在Mono以及.NET和Silverlight下运行的应用程序，那么有很多社区专业知识可供使用，它也是跨平台的。开箱即用，它比MSBuild做得更多。哦，是的，你可以从NAnt打电话给MSBuild（好的，来自NAntContrib）： - ）
从消极方面来看，NAnt及其姐妹项目NAntContrib确实停滞不前，最近的更新是在2007年底。
我看到的MSBuild的主要优点是它随.NET Framework一起提供，因此它的安装产品少了一个;而且还有更积极的发展（虽然在赶上老NAnt的地方）。
就个人而言，我觉得它的语法有点难以接受，但我确信继续接触ti会让事情变得更容易。
结论？如果您正在使用现有的NAnt脚本，请坚持使用它们，这不值得移植麻烦。如果你正在开始一个新项目，并且你正在冒险，那就给MSBuild一个去吧。
答案 5 :(得分：2)
答案 6 :(得分：2)
我们也从nant切换到msbuild。如果您的构建非常标准，那么设置它不会有太多问题，但如果您有许多特定的构建任务，则必须编写自定义的ms构建任务，因为msbuild的自定义任务更少。
如果你想显示合理的构建结果，你将不得不搞乱自定义记录器等。整个团队的构建并不像nant那样成熟。
但真正的好处是与TFS源代码控制和报告服务的集成。如果您没有使用TFS作为源控制系统，那就不值得了。
答案 7 :(得分：1)
@Brad Leach
除非有一个令人信服的功能缺失，否则我通常不会在它们之间切换
使用msbuild有哪些令人信服的理由？有缺点吗？
到目前为止，我得到了一个非常好的，“从你的回答中不要打扰”。
答案 8 :(得分：1)
我从NANT切换到MSBuild。该项目在.Net 4.0中运行。
我在南特的经历很好。该项目有点死亡。当.Net 4.0出现时，是时候重新评估构建过程了。
自Nant上次发布以来，MSBuild已经出现了问题。在这一点上，MSBuild是要走的路。它易于使用，有很多扩展。我在一天半的时间里重写了我的Nant脚本。 MSBuild脚本的大小是Nant脚本的1/3。
Nant脚本中的大部分工作都是设置不同的环境。在MsBuild / .Net 4.0中它是内置的。
答案 9 :(得分：1)
与Visual Studio集成的MSBuild为程序员提供了更少的摩擦来使用构建系统。它主要归结为他们只需要“构建解决方案”并且一切正常，而不是必须使用自定义构建步骤和其他类似的东西，或者更糟糕的是，通过启动某种外部脚本迫使开发人员构建。
现在，我更倾向于选择MSBuild而不是NAnt，因为它更简单。当然，NAnt有更多功能，更强大等等，但它很快就会失控。如果你和你的构建工程师有纪律保持NAnt脚本简单，那么这一切都很好。然而，我已经看到太多基于NAnt的系统向南走到了一个没有人理解它正在做什么的地步，并且没有真正的方法来调试它，除了做相当于一个好的'printf。一旦你开始使用一些if / else语句或for循环，那就是恕我直言，它开始闻起来。
另一方面，MSBuild具有基于元数据和较简洁语法的坚实基础。它的简单性（或缺少功能......取决于你如何看待它）迫使你通过新任务在.NET代码中编写逻辑，而不是在XML标记中编写逻辑。这鼓励了可重用性，最重要的是，它允许您在真正的调试器中实际调试构建系统。
MSBuild的唯一问题是不那么偶然的错误（特别是在第一个版本中）或模糊（尽管记录在案）的行为。并且，如果那种真正困扰你的事情，那就是与微软联系在一起。
答案 10 :(得分：1)
我认为没有任何理由转换。 MsBuild本身会将您锁定在您正在使用的框架中。如果您使用NAnt，您可以在许多框架中使用它，并将其发送到msbuild以实际为您执行构建任务。
在这方面我是NAnt的粉丝，因为它将你与框架分离了一点。
我创建了一个框架，将约定放入自动构建中，并在NAnt上构建它。它被称为UppercuT，它是一个非常容易使用的Build Framework。
自动构建与（1）解决方案名称，（2）源控制路径，（3）大多数项目的公司名称一样简单！
http://code.google.com/p/uppercut/
这里有一些很好的解释：UppercuT
答案 11 :(得分：1)
Nant 具有更多功能，但 MSBuild 具有更好的基本结构（项目元数据），这使得构建可重用的MSBuild脚本变得更加容易。
MSBuild需要一段时间才能理解，但一旦你做到这一点非常好。
学习资料：
答案 12 :(得分：1)
我实际上仍在尝试自己解决这个问题，但MSBuild在这里有一个很大的好处：通过直接调用msbuild.exe使用相同的构建文件进行本地持续集成，同时还能够使用VSTS的服务器 - 与同一构建文件的持续集成（尽管很可能是不同的属性/设置）。
即。与TeamCity对MSBuild脚本的支持相比，VSTS 仅 支持MSBuild脚本！我曾经在MSBuild中执行NAnt攻击过这个问题。我已经看到其他人推荐这种做法以及相反的做法，但它对我来说似乎只是笨蛋，所以如果我可以避免它，我尽量不这样做。因此，当您使用“完整的Microsoft堆栈”（VSTS和TFS）时，我建议您坚持使用MSBuild脚本。
答案 13 :(得分：1)
我仍在自动构建中使用nAnt而不是msbuild的主要原因是我对构建进行了更细粒度的控制。由于msbuild使用csproj有它的构建文件，该项目中的所有源代码都被编译成一个程序集。这导致我在我的解决方案中为我分离逻辑的大型项目中有很多项目。好吧，我可以安排我的构建，我可以将我想要的东西编译成一个项目的多个程序集。
我喜欢这条路线，因为它让我无法在我的解决方案中使用很多项目文件。我可以有一个项目，文件夹拆分图层，然后使用nant将每个图层构建到自己的程序集中。
但是，我确实将nant和msbuild结合使用来构建一些构建任务，比如构建WPF应用程序。使用nant中的msbuild目标编译WPF应用程序要容易得多。
要结束这一点，我的回答是我喜欢并排使用它们，但是当我在这个配置中使用msbuild时，它通常用于直接编译，而不执行任何构建自动化任务，如将文件复制到例如，目录，生成帮助文档或运行我的单元测试。
答案 14 :(得分：1)
我认为它们在功能和易用性方面都具有相对的可比性。仅仅基于C＃我发现msbuild比nants更容易使用，尽管这并不是一个令人信服的理由转换。
究竟什么不能为你做什么？或者你只是希望你可能会错过一些很酷的功能？ ：）
关于C＃的一个非常好的事情是，如果你有.net框架，你拥有运行msbuild所需的一切。当您在大型团队/项目上工作并拥有人员/硬件营业额时，这非常棒。
我个人更喜欢SCons而不是两个：）
答案 15 :(得分：0)
我可以看到使用msbuild的唯一原因是你想使用像巡航控制这样的自动构建服务器。如果你不打算转换，那我就不管它了。
答案 16 :(得分：0)
我使用MSBuild 和 Nant，因为当前版本的Nant还不能编译.NET 3.5应用程序（当.NET 2.0首次出现时也是如此）。
答案 17 :(得分：0)
我使用Nant而我喜欢它。我使用了MSBuild并且因为这些而讨厌它：
Microsoft迫使你遵循他们自己的构建过程，这些过程对于他们的行为是如此内在，至少我无法使其工作（我必须编译NET1.1所以我必须混合Nant和MSbuild） 。我知道你可以创建自己的MSBuild文件，但我认为理解和维护起来很复杂。
要执行文件操作的ItemTypes太难以遵循。你可以让Nant做同样的事情，更容易和更直接（我必须创建一个ItemType列表，然后传递给文件操作）。
在MsBuild中你必须创建自己的任务dll，在Nant中你可以这样做，或者你可以在你的脚本中嵌入C＃代码，所以它更容易推进并且只是构建整个项目。
Nant适用于Net1.1，MsBuild不支持。
要安装nant，我甚至可以解压缩并在我自己的存储库中找到它来运行它。安装MsBuild要困难得多，因为它取决于Visual Studio等许多东西（也许我错了，但这似乎是事实）。
这些是我的意见......