构建过程 - 使用什么?

Avi*_*Avi 10 msbuild nant build-process

我正在考虑使用PowerShell和/或C#编写自己的交付代码,可能是对NAnt或MSBuild进行炮轰.

  1. 我为什么这样走?与使用NAnt或MSBuild相比,这是一项非常艰苦的努力吗?
  2. 任何好的,现代的书都能提供帮助吗?
  3. 有更好的想法吗?

背景(PS这对某些人来说是宗教问题.没有侮辱意图):

一人开店,多个探索性项目.作为我们大多数人 - 现在的Windows和ASP.Net.考虑移动和云.

我已经开始干涉NAnt了,并试图使用NAnt和CruiseControl.Net跟踪Expert .Net Delivery.整个"交付"问题已经解决,现在是时候"解冻"了.但是,我不知道该走哪条路.从我所学到的:

NAnt正在显示它的年龄.它很笨拙:理解和维护比C#等现代的OO语言更难理解和维护.即使在我读完这本书之后,在一个神秘的环境中工作似乎很奇怪,你想要执行的是XML,循环和继承(据我记得在"冰河时代"之前)很难做到.

MSBuid是MS特定的.我甚至不确定它是否会支持非MS环境.团队基础服务器很贵.

即便如此,他们似乎都提供了价值,因为在我的SO搜索中我没有听到任何人使用他们自己的自定义软件.但是,我不明白为什么不使用C#并根据需要简单地调用NAnt和/或MSBuild任务.

SO - NAnt Vs. 的MSBuild

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

SO - NAnt与脚本:

构建产品远不仅仅是编译产品.由于这些工具(及其扩展)提供的功能,创建安装,更新版本号,创建托管,分发最终包等任务变得更加容易.虽然您可以使用常规脚本完成所有这些操作,但使用NAnt或MSBuild为您提供了一个可靠的框架来完成所有这些操作

Yan*_*rtz 9

NAnt作为一个项目已经死亡,或者生命支持(最后一个版本是两年前的0.86 beta 1).MSBuild的发布基本上缩短了它.NAnt很好,我觉得MSBuild还可以,但是我觉得越来越多地将代码编写成一种语言,而不是一些基于XML的程序性东西.使用基于XML的构建框架,调试体验非常糟糕,并且最终通过在c#中嵌入"脚本"来欺骗,这违背了声明而不是编程的目的.与XSLT一样,悲伤的故事也是如此.

一些不错的无XML构建框架:

我仍然使用MSBuild,因为它是csproj文件的格式,但对于特定的东西,我避免在XML中构建逻辑(没有自定义的MSBuild任务).