关于构建过程:我应该从nant切换到msbuild吗?

关于构建过程:我应该从nant切换到msbuild吗?

Should I switch from nant to msbuild?

我目前使用nant,ccnet(巡航控制),svn,mbunit。 我使用msbuild进行sln构建只是因为它更易于安装。

将我的整个构建脚本切换到MSBuild有什么好处吗? 我需要能够运行测试,watir样式测试,xcopy部署。 这样容易吗?

更新:有什么引人入胜的功能会导致我从nant转到msbuild?


我喜欢MSBuild。原因之一是.csproj文件是msbuild文件,而在VS中进行构建就像在命令行中进行构建一样。另一个原因是TeamCity的良好支持,这是我一直在使用的CI服务器。如果您开始使用MSBuild,并且想要在构建过程中执行更多自定义操作,请获取MSBuild社区任务。他们给您带来许多不错的额外任务。我已经好几年没有使用NAnt了,我并不后悔。

另外,如Ruben所述,CodePlex上还有SDC Tasks任务。

为了获得更多乐趣,在CodePlex上提供了MSBuild扩展包,其中包括一个twitter任务。


我的建议恰恰相反-避免像瘟疫一样使用MSBuild。 NANT可以很容易地设置您的构建以进行自动测试,部署到多个生产环境,与用于进口环境的CruiseControl集成,与源代码控制集成。我们在使用TFS / MSBuild(使用TFSDeployer,自定义Powershell脚本等)方面经历了很多痛苦,以使其能够立即使用NANT进行处理。不要浪费你的时间。


使用MSBuild的最引人注目的原因(至少在.NET 3.5及更高版本中)-构建引擎可以同时构建。

这意味着在拥有多个内核/处理器的情况下,构建速度将大大提高。

在3.5之前的版本中,MSBuild并未进行并行构建。


我觉得MSBuild和Nant相当。如果您使用的是其中一种,除非您选择的产品中缺少引人注目的功能,否则我通常不会在它们之间切换。

我个人将MSBuild用于任何新项目,但是您的工作量可能会有所不同。

希望有帮助!

编辑:@ChanChan-@Jon提到Nant不会构建.NET 3.5应用程序。这可能足以改变或至少并行使用它们。随着我更加朝着MSBuild迈进,我可能不是最有见地的人,重点介绍使用这两种技术的任何其他热门产品。

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


NAnt已经存在了很长时间,并且是相当成熟的产品,而且IMO更易于使用。如果您对构建可在Mono以及.NET和Silverlight下运行的应用程序感兴趣,那么有很多社区专业知识可以利用,并且它也是跨平台的。开箱即用,它的功能比MSBuild多得多。哦,是的,您可以从NAnt调用MSBuild(确定,从NAntContrib):-)

不利的一面是,NAnt及其姊妹项目NAntContrib似乎停滞了,最新更新是在2007年末。

我所看到的MSBuild的主要优点是,它随.NET Framework一起提供,因此它是一种较少安装的产品。而且还有更积极的发展(尽管在某些地方可以赶上较早的NAnt)。

就个人而言,我发现它的语法有点难理解,但是我确信继续接触ti会使事情变得更容易。

结论?如果您正在使用现有的NAnt脚本,请坚持使用它们,不值得进行移植的麻烦。如果您正在开始一个新项目,并且感到冒险,那么请尝试使用MSBuild。


  • 除非您有令人信服的理由(至少),否则不要切换。
  • NAnt是开源的,如果不是,那么我将无法自定义我们的构建系统,而MSBuild则不是。
  • NAnt可以轻松运行MSBuild,但我不确定其他方法。
  • 如果您使用VS2005或更高版本,则已经为您编写了MSBuild脚本(项目文件是MSBuild文件。)
  • 如果使用NAnt,并且使用VS编辑项目文件,设置和配置,则必须编写转换器/同步工具以从VS Project文件更新NAnt文件。

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

如果您想显示合理的构建结果,则必须使用自定义记录器等。整个团队的构建还不如Nant成熟。

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


@布拉德·里奇

I generally wouldn't switch between them unless there was a compelling feature that was missing

使用msbuild的令人信服的理由是什么?有缺点吗?

到目前为止,我的回答是非常不错的,"不打扰"。


我认为它们在功能和易用性方面都相对可比。仅仅基于C#,我发现msbuild比nant更易于使用,尽管这并不是切换的迫切理由。

南特究竟对您没有做什么?还是只是希望您可能缺少一些很棒的功能? :)

关于C#的一件非常好的事情是,如果您拥有.net框架,则您拥有运行msbuild所需的一切。当您在大型团队/项目中工作并且人员/硬件周转时,这真是太棒了。

就我个人而言,我更喜欢SCons :)


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

即,与TeamCity对MSBuild脚本的支持相比,VSTS仅支持MSBuild脚本!过去,我是通过执行MSBuild的NAnt来解决这个问题的。我已经看到其他人也推荐这种做法以及相反的做法,但是对我来说似乎有点不合时宜,所以如果可以避免的话,我尽量不要这样做。因此,当您使用"完整的Microsoft堆栈"(VSTS和TFS)时,建议只使用MSBuild脚本。


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

MSBuild需要花一些时间来理解,但是一旦完成,它就会非常好。

学习资料:

  • 在Microsoft Build Engine内部:使用MSBuild和Team Foundation Build
    Sayed Ibrahim Hashimi(2009年1月)
  • 部署.NET应用程序:Sayed学习MSBuild和ClickOnce
    Y.Hashimi撰写(2008年9月)

我看不出有任何理由要切换。 MsBuild本身会将您锁定在您正在使用的框架中。如果使用NAnt,则可以在许多框架中使用它,并外壳使用msbuild来真正为您完成构建任务。

在这方面,我是NAnt的粉丝,因为它使您与框架略有脱离。

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

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

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

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


与Visual Studio集成的MSBuild使程序员在使用构建系统时减少了摩擦。这主要归结于他们只需要"构建解决方案"就可以了,而不必使用自定义构建步骤和其他类似的东西,或者更糟的是,迫使开发人员通过启动某种外部脚本来进行构建。

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

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

MSBuild的唯一问题是不是偶尔发生的错误(尤其是在第一个版本中)或晦涩(尽管已记录)的行为。而且,如果那种事情真的让您感到困扰,请与Microsoft捆绑。


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

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

自Nant上次发布以来,MSBuild一直在发展。在这一点上,MSBuild是必经之路。它易于使用,具有许多扩展。我在一天半的时间内重写了我的Nant脚本。 MSBuild脚本的大小是Nant脚本的1/3。

Nant脚本中的许多工作是建立不同的环境。在MsBuild / .Net 4.0中,它是内置的。


我仍然在msbuild上使用nAnt而不是msbuild来进行自动构建的主要原因是,我对构建具有更精细的控制。由于使用csproj的msbuild具有其生成文件,因此该项目中的所有源代码都被编译为一个程序集。这导致我的解决方案中有很多项目需要用于分离逻辑的大型项目。借助nant,我可以安排构建,在其中可以将我想要的内容从一个项目编译成多个程序集。

我喜欢这种方法,因为它使我不必在解决方案中使用许多项目文件。我可以有一个项目,其中的文件夹将各层分开,然后使用nant将每一层构建到自己的程序集中。

但是,对于某些构建任务,例如构建WPF应用程序,我确实同时使用了nant和msbuild。使用nant中的msbuild目标编译WPF应用程序要容易得多。

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


我使用Nant,我喜欢它。由于以下原因,我使用了MSBuild并讨厌它:

  • Microsoft强迫您遵循他们自己的构建过程,这对于他们的工作是如此内在,以至于我至少无法使其正常工作(我必须编译NET1.1,因此必须将Nant和MSbuild混合使用)。我知道您可以创建自己的MSBuild文件,但是我认为理解和维护它很复杂。

  • 用于执行文件操作的ItemTypes很难遵循。您可以让Nant做完全相同的事情,并且更加轻松和直接(我必须创建一个ItemType列表,然后传递给文件操作)。

  • 在MsBuild中,您必须创建自己的任务dll,在Nant中,您可以执行此操作,也可以在脚本中嵌入C#代码,因此,进行开发非常容易,并且只需构建整个项目即可。

  • Nant可以与Net1.1一起使用,而MsBuild则不能。

  • 要安装nant,我什至可以解压缩并找到自己的存储库以运行它。安装MsBuild更加困难,因为它依赖于Visual Studio等中的许多东西(也许我在这里错了,但这似乎是事实)。

  • 这些是我的意见...


    我可以看到使用msbuild的唯一原因是您是否想使用诸如巡航控制之类的自动化构建服务器。如果您不打算切换,那么我将不理会它。


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


    推荐阅读