我应该从nant切换到msbuild吗?

时间:2008-08-14 03:36:55

标签: msbuild build-process build-automation nant

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

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

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

18 个答案:

答案 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)

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

答案 6 :(得分:2)

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

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

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

答案 7 :(得分:1)

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

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

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

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

答案 8 :(得分:1)

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

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

学习资料:

答案 9 :(得分:1)

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

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

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

自动构建与(1)解决方案名称,(2)源控制路径,(3)大多数项目的公司名称一样简单!

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

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

答案 10 :(得分:1)

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

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

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

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

答案 11 :(得分:1)

@Brad Leach

  

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

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

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

答案 12 :(得分:1)

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

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

答案 13 :(得分:1)

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

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

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

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

答案 14 :(得分:1)

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

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

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

我个人更喜欢SCons而不是两个:)

答案 15 :(得分:0)

我使用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等许多东西(也许我错了,但这似乎是事实)。

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

答案 16 :(得分:0)

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

答案 17 :(得分:0)

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