我知道Stack Overflow上还有其他与NAnt和MSBuild相关的问题,但是我找不到两者之间的直接比较,所以这就是问题所在.
什么时候应该选择NAnt而不是MSBuild？哪个更适合什么？NAnt更适合家庭/开源项目和MSBuild工作项目吗？这两个中的任何一个有什么经验？
我本周做了类似的调查.这是我能够确定的:
楠:
跨平台(支持Linux/Mono).例如,将网站安装到多个目标(即Linux Apache和Windows IIS)可能很方便.
语法与Ant的95%相似(当前Ant用户或Java构建器很容易获取)
与NUnit集成以作为构建的一部分运行单元测试,并使用NDoc生成产品文档.
的MSBuild:
内置于.NET.
与Visual Studio集成
在Visual Studio中轻松开始使用MSBuild - 这一切都在幕后.如果您想要更深入,可以手动编辑文件.
主观差异: (YMMV)
NAnt文档更简单一些.例如,MSBuild任务参考列出了"Csc任务 - 描述Csc任务及其参数."(感谢"帮助"？),与NAnt任务参考 "csc - 编译C#程序"相比.更新:我注意到MSBuild文档已得到改进,现在好多了(可能与NAnt相当).
不容易弄清楚如何直接从Visual Studio中编辑构建脚本源(*.*proj文件).使用NAnt我只需要Visual Studio将.build脚本视为XML文件.
显然,在Visual Studio中,Web应用程序项目默认情况下不会获得*.*proj文件,因此我很难弄清楚如何让我的MSBuild运行以创建部署脚本.
NAnt不是Visual Studio内置的,必须使用加载项或"外部工具"添加.设置这有点痛苦.
(编辑:)我的一位同事提出了这个问题 - 如果你想使用CruiseControl建立一台用于持续集成的构建机器,CruiseControl可以很好地与NAnt集成.更新: CruiseControl还有一个MSBuild任务.
请参阅以下评论,了解主观差异的完整和最新讨论.
对我来说,MSBuild的主要吸引力之一(在Windows平台上)是它本身就是.NET的一部分.这意味着任何与Windows Update一起更新的Windows计算机都将具有MSBuild.除此之外,C#编译器也是.NET本身的一部分,你有一个可以在干净的机器上构建项目的平台.无需安装Visual Studio庞然大物.另一方面,必须在触发构建之前显式安装NAnt.
仅仅为了记录,我在过去的非平凡构建中使用了NMake,Make,Ant,Rake,NAnt和MSBuild(按此顺序).我最喜欢的是MSBuild,请放手(我不喜欢它,因为"这就是Visual Studio使用的").恕我直言,这是一个非常不受重视的构建工具.
我会比较NAnt和MSBuild对程序和函数编程之间的区别.NAnt非常简单,你可以看到你所看到的.另一方面,MSBuild需要更多的思考.学习曲线更陡峭.但是一旦你"得到它",你就可以用它做一些惊人的事情.
所以我建议你看看MSBuild,如果你也倾向于功能或逻辑风格的编程 - 如果你愿意在看到实际结果之前投入一点时间和精力(当然,我也坚信投资最终会得到回报而你可以更有效地做更强大的事情).
就个人而言,我同时使用两个 - 用于同一个项目.
MSBuild非常擅长构建Visual Studio解决方案和项目 - 这就是它的用途.
在我看来,NAnt更容易手工编辑 - 特别是如果你已经知道Ant了.NAnt可以使用NAntContrib轻松调用MSBuild.因此,我手工制作一个NAnt脚本来执行复制构建文件,清理等操作 - 并调用MSBuild来实际执行"将我的C#源代码转换为程序集"部分.
如果您想要一个示例,请查看我的Protocol Buffers构建文件.(我不会声称它是一个神话般的NAnt脚本,但它完成了这项工作.)
NAnt具有更多开箱即用的功能,但MSBuild具有更好的基本结构(项目元数据),这使得构建可重用的MSBuild脚本变得更加容易.
MSBuild需要一段时间来理解,但是一旦你做到这一点非常好.
学习资料:
在Microsoft Build Engine中:使用MSBuild和Team Foundation Build
by Sayed Ibrahim Hashimi(2009年1月)
部署.NET应用程序:学习MSBuild和ClickOnce by Sayed
by Y. Hashimi(2008年9月)
KISS =使用MSBuild.
为什么在你有一些能够开箱即用的合理工作的东西中添加其他东西？当MSBuild到达时,NAnt死了.而单将有一个MSBuild实现,(xbuild).
DRY =使用MSBuild.
问问自己,你想从构建系统中得到什么？我想要一个我的IDE也使用的构建系统,而不是维护两种不同的配置.
就个人而言,我很想听听NAnt的一些真实论点,因为我无法想到任何真正存在水的东西.
有一件事我注意到有几个海报提到要编辑.csproj(或.vbproj等)文件.
MSBuild允许通过使用.user文件自定义这些.*proj文件.如果我有一个名为MyCreativelyNamedProject.csproj的项目并想要自定义其中的MSBuild任务,我可以创建一个名为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构建文件与Visual Studio不同(在我的情况下,我认为这是专业人员)因此Visual Studio不会尝试对它做任何事情.MSBuild任务是嵌入式解决方案的一部分,可以引用其他MSBuild任务.我收到了其他人的源代码,但发现我无法构建,因为没有安装MSBuild社区任务.我觉得特别令人沮丧的是,Visual Studio不会构建并抛出一堆错误,这些错误使我无法进行调试.尽管事实上所请求的构建可以继续(例如作为调试构建)而没有MSBuild任务的一些额外内容.简而言之:如果我可以避免,我不喜欢在我的项目中添加依赖项.
我不相信Visual Studio,因为我可以抛弃它的开发团队.这可以追溯到Visual Studio的早期阶段,当时它会屠杀我的HTML.我仍然没有使用设计师(最近在一次会议上我发现同事也这样做了).我发现Visual Studio可以搞砸DLL文件中的依赖项和版本号(我不能复制它,但它确实在一个项目中发生并且引起了很多的悲伤并且浪费了时间).我已经使用了一个构建过程,该过程使用Visual Studio仅在调试模式下构建.为了制作,我使用NAnt以便我在外部控制所有内容.如果我使用NAnt构建,Visual Studio就不能再干涉了.
PS:我是一名Web开发人员,不做Windows Forms开发.
虽然我对MsBuild不太熟悉,但我的印象是双方的一些关键差异可以通过增加补充:
MsBuildTasks
NantContrib
我最近不得不在Nant建立一个Silverlight项目.我发现如果我只是使用MsBuild来生活会更容易 - 我最终在Nant脚本中调用了一个MsBuild任务,所以我认为混合和匹配两者并不是太常见.
除此之外,我想这将是一个个人偏好的问题 - 显然你可以在Visual Studio中管理MsBuild的一些/大部分功能,如果这是你的事情.如果您喜欢手工编写脚本,Nant似乎更灵活,更适合,如果您来自Java世界,那么您可能会在家中使用它.
京公网安备 11010802040832号 | 京ICP备19059560号-6 