我应该从nant切换到msbuild吗？

Question

我目前使用nant，ccnet（巡航控制），svn，mbunit。我使用msbuild来做我的sln构建只是因为它更容易出壳。

将整个构建脚本切换到MSBuild是否有任何优点？我需要能够运行测试，watir样式测试，xcopy部署。这更容易吗？

更新：任何引人注目的功能会导致我从nant转移到msbuild吗？

Answer 1

我喜欢MSBuild。一个原因是.csproj文件是msbuild文件，VS中的构建就像在命令行中构建一样。另一个原因是TeamCity的良好支持，这是我一直在使用的CI服务器。如果您开始使用MSBuild，并且希望在构建过程中执行更多自定义操作，请获取MSBuild Community Tasks。他们为您提供了许多额外的好工作。我已经好几年没用过NAnt了，我并没有后悔。

另外，正如Ruben所提到的，CodePlex上有SDC Tasks个任务。

为了更有趣，还有MSBuild Extension Pack on CodePlex，其中包含推特任务。

Answer 2

我的建议正好相反 - 避免像瘟疫那样的MSBuild。 NANT更容易设置您的构建以进行自动测试，部署到多个生产环境，与cruisecontrol集成以用于入口环境，与源代码控制集成。我们通过TFS / MSBuild（使用TFSDeployer，自定义PowerShell脚本等）经历了如此多的痛苦，以使它能够完成我们能够用NANT开箱即用的功能。不要浪费你的时间。

Answer 3

使用MSBuild的最令人信服的理由（至少在.NET 3.5及更高版本中） - 构建引擎可以同时构建。

这意味着在您拥有多个内核/处理器的构建中可以大幅提升。

在3.5之前，MSBuild没有进行并行构建。

Answer 4

我觉得MSBuild和Nant相当可比。如果您使用其中一种，我通常不会在它们之间切换，除非您选择的产品中缺少令人信服的功能。

我个人使用MSBuild进行任何新项目，但您的里程可能会有所不同。

希望有所帮助！

编辑： @ChanChan - @Jon提到Nant没有构建.NET 3.5应用程序。这可能足以成为改变或至少并行使用它们的理由。随着我越来越倾向于MSBuild，我可能不是最明智的人，可以用这两种技术突出显示任何其他showstoppers。

编辑：Nant现在正在构建.NET 3.5应用程序。

Answer 5

NAnt已经存在更长时间，并且是一种相当成熟的产品，而且IMO也更容易使用。如果您有兴趣构建可以在Mono以及.NET和Silverlight下运行的应用程序，那么有很多社区专业知识可供使用，它也是跨平台的。开箱即用，它比MSBuild做得更多。哦，是的，你可以从NAnt打电话给MSBuild（好的，来自NAntContrib）： - ）

从消极方面来看，NAnt及其姐妹项目NAntContrib确实停滞不前，最近的更新是在2007年底。

我看到的MSBuild的主要优点是它随.NET Framework一起提供，因此它的安装产品少了一个;而且还有更积极的发展（虽然在赶上老NAnt的地方）。

就个人而言，我觉得它的语法有点难以接受，但我确信继续接触ti会让事情变得更容易。

结论？如果您正在使用现有的NAnt脚本，请坚持使用它们，这不值得移植麻烦。如果你正在开始一个新项目，并且你正在冒险，那就给MSBuild一个去吧。

Answer 6

• 除非你有一个非常有说服力的理由（至少），否则不要切换。
• NAnt是开源的，如果不是，我将无法自定义我们的构建系统，MSBuild不是。
• NAnt可以很容易地运行MSBuild，我不确定相反的方式。
• 如果您使用VS2005或更新版本（项目文件 MSBuild文件），则已经为您编写了MSBuild脚本。
• 如果您使用NAnt，并且使用VS编辑项目文件，设置和配置，则必须编写转换器/同步工具以从VS Project文件更新NAnt文件。

Answer 7

我们也从nant切换到msbuild。如果您的构建非常标准，那么设置它不会有太多问题，但如果您有许多特定的构建任务，则必须编写自定义的ms构建任务，因为msbuild的自定义任务更少。

如果你想显示合理的构建结果，你将不得不搞乱自定义记录器等。整个团队的构建并不像nant那样成熟。

但真正的好处是与TFS源代码控制和报告服务的集成。如果您没有使用TFS作为源控制系统，那就不值得了。

Answer 8

@Brad Leach

  

除非有一个令人信服的功能缺失，否则我通常不会在它们之间切换

使用msbuild有哪些令人信服的理由？有缺点吗？

到目前为止，我得到了一个非常好的，“从你的回答中不要打扰”。

Answer 9

我从NANT切换到MSBuild。该项目在.Net 4.0中运行。

我在南特的经历很好。该项目有点死亡。当.Net 4.0出现时，是时候重新评估构建过程了。

自Nant上次发布以来，MSBuild已经出现了问题。在这一点上，MSBuild是要走的路。它易于使用，有很多扩展。我在一天半的时间里重写了我的Nant脚本。 MSBuild脚本的大小是Nant脚本的1/3。

Nant脚本中的大部分工作都是设置不同的环境。在MsBuild / .Net 4.0中它是内置的。

Answer 10

与Visual Studio集成的MSBuild为程序员提供了更少的摩擦来使用构建系统。它主要归结为他们只需要“构建解决方案”并且一切正常，而不是必须使用自定义构建步骤和其他类似的东西，或者更糟糕的是，通过启动某种外部脚本迫使开发人员构建。

现在，我更倾向于选择MSBuild而不是NAnt，因为它更简单。当然，NAnt有更多功能，更强大等等，但它很快就会失控。如果你和你的构建工程师有纪律保持NAnt脚本简单，那么这一切都很好。然而，我已经看到太多基于NAnt的系统向南走到了一个没有人理解它正在做什么的地步，并且没有真正的方法来调试它，除了做相当于一个好的'printf。一旦你开始使用一些if / else语句或for循环，那就是恕我直言，它开始闻起来。

另一方面，MSBuild具有基于元数据和较简洁语法的坚实基础。它的简单性（或缺少功能......取决于你如何看待它）迫使你通过新任务在.NET代码中编写逻辑，而不是在XML标记中编写逻辑。这鼓励了可重用性，最重要的是，它允许您在真正的调试器中实际调试构建系统。

MSBuild的唯一问题是不那么偶然的错误（特别是在第一个版本中）或模糊（尽管记录在案）的行为。并且，如果那种真正困扰你的事情，那就是与微软联系在一起。

Answer 11

我认为没有任何理由转换。 MsBuild本身会将您锁定在您正在使用的框架中。如果您使用NAnt，您可以在许多框架中使用它，并将其发送到msbuild以实际为您执行构建任务。

在这方面我是NAnt的粉丝，因为它将你与框架分离了一点。

我创建了一个框架，将约定放入自动构建中，并在NAnt上构建它。它被称为UppercuT，它是一个非常容易使用的Build Framework。

自动构建与（1）解决方案名称，（2）源控制路径，（3）大多数项目的公司名称一样简单！

http://code.google.com/p/uppercut/

这里有一些很好的解释：UppercuT

Answer 12

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

MSBuild需要一段时间才能理解，但一旦你做到这一点非常好。

学习资料：

• Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build
  作者：Sayed Ibrahim Hashimi（2009年1月）
• Deploying .NET Applications: Learning MSBuild and ClickOnce by Sayed
  作者：Y。Hashimi（2008年9月）

Answer 13

我实际上仍在尝试自己解决这个问题，但MSBuild在这里有一个很大的好处：通过直接调用msbuild.exe使用相同的构建文件进行本地持续集成，同时还能够使用VSTS的服务器 - 与同一构建文件的持续集成（尽管很可能是不同的属性/设置）。

即。与TeamCity对MSBuild脚本的支持相比，VSTS 仅 支持MSBuild脚本！我曾经在MSBuild中执行NAnt攻击过这个问题。我已经看到其他人推荐这种做法以及相反的做法，但它对我来说似乎只是笨蛋，所以如果我可以避免它，我尽量不这样做。因此，当您使用“完整的Microsoft堆栈”（VSTS和TFS）时，我建议您坚持使用MSBuild脚本。

Answer 14

我仍在自动构建中使用nAnt而不是msbuild的主要原因是我对构建进行了更细粒度的控制。由于msbuild使用csproj有它的构建文件，该项目中的所有源代码都被编译成一个程序集。这导致我在我的解决方案中为我分离逻辑的大型项目中有很多项目。好吧，我可以安排我的构建，我可以将我想要的东西编译成一个项目的多个程序集。

我喜欢这条路线，因为它让我无法在我的解决方案中使用很多项目文件。我可以有一个项目，文件夹拆分图层，然后使用nant将每个图层构建到自己的程序集中。

但是，我确实将nant和msbuild结合使用来构建一些构建任务，比如构建WPF应用程序。使用nant中的msbuild目标编译WPF应用程序要容易得多。

要结束这一点，我的回答是我喜欢并排使用它们，但是当我在这个配置中使用msbuild时，它通常用于直接编译，而不执行任何构建自动化任务，如将文件复制到例如，目录，生成帮助文档或运行我的单元测试。

Answer 15

我认为它们在功能和易用性方面都具有相对的可比性。仅仅基于C＃我发现msbuild比nants更容易使用，尽管这并不是一个令人信服的理由转换。

究竟什么不能为你做什么？或者你只是希望你可能会错过一些很酷的功能？ ：）

关于C＃的一个非常好的事情是，如果你有.net框架，你拥有运行msbuild所需的一切。当您在大型团队/项目上工作并拥有人员/硬件营业额时，这非常棒。

我个人更喜欢SCons而不是两个：）

Answer 16

我可以看到使用msbuild的唯一原因是你想使用像巡航控制这样的自动构建服务器。如果你不打算转换，那我就不管它了。

Answer 17

我使用MSBuild 和 Nant，因为当前版本的Nant还不能编译.NET 3.5应用程序（当.NET 2.0首次出现时也是如此）。

Answer 18

我使用Nant而我喜欢它。我使用了MSBuild并且因为这些而讨厌它：

1. Microsoft迫使你遵循他们自己的构建过程，这些过程对于他们的行为是如此内在，至少我无法使其工作（我必须编译NET1.1所以我必须混合Nant和MSbuild） 。我知道你可以创建自己的MSBuild文件，但我认为理解和维护起来很复杂。

2. 要执行文件操作的ItemTypes太难以遵循。你可以让Nant做同样的事情，更容易和更直接（我必须创建一个ItemType列表，然后传递给文件操作）。

3. 在MsBuild中你必须创建自己的任务dll，在Nant中你可以这样做，或者你可以在你的脚本中嵌入C＃代码，所以它更容易推进并且只是构建整个项目。

4. Nant适用于Net1.1，MsBuild不支持。

5. 要安装nant，我甚至可以解压缩并在我自己的存储库中找到它来运行它。安装MsBuild要困难得多，因为它取决于Visual Studio等许多东西（也许我错了，但这似乎是事实）。

这些是我的意见......