Question

我正在考虑使用PowerShell和/或C＃编写自己的交付代码，可能会炮轰到NAnt或MSBuild。

为什么不这样？这真的很难吗？与使用NAnt或MSBuild相比，努力？
任何可以提供帮助的好书，现代书？
有更好的想法吗？

背景（P.S.这对某些人来说是宗教问题。没有侮辱意图）：

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

我已经开始干涉NAnt，并试图关注Expert .Net Delivery Using NAnt and CruiseControl.Net。整个“交付”问题已经解决，现在是时候“解冻”了。但是，我不知道该走哪条路。从我所学到的：

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 vs. scripts：

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

Answer 1

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

一些优秀的无XML构建框架：

Rake http://rake.rubyforge.org/（基于Ruby）非常好，并且存在一些特定于.NET的任务，我认为IronRuby现在运行它。
PSake http://code.google.com/p/psake/（基于Powershell） - 非常有前途
假装http://code.google.com/p/fake/喜欢F＃

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

Answer 2

不要使用C＃来构建脚本，因为在对其进行更改时不想编译它。

如果您打算使用PowerShell，请查看PSake。

如果您对XML友好，那么请使用MSBuild或NAnt。也许those build scripts对你有价值。 MSBuild有一个优点：Ctrl + F5在Visual Studio中构建此脚本。

我一直在慢慢地转向Rake，因为它更好，Ruby是编程语言（这意味着你可以做任何事情）：I blogged about how nice it could be, but you have to translate it or look at code only。如果您喜欢，那么您可能希望看到full script和dependencies。

Good book about continuous integration is from Paul Duvall, Steve Matyas and Andrew Glover (Continuous Integration: Improving Software Quality and Reducing Risk).

Answer 3

在一天结束时，MSBuild和NAnt任务都可以发送到命令行，因此最终他们可能支持非MS内容。

我个人赞成MSBuild，并且让像CCNET的TeamCity这样的构建服务器进行构建和部署等。它非常灵活。

Answer 4

我看不出没有理由不在Powershell中进行简单的构建过程。

我将以下内容用于我的沙箱项目：

#Types
Add-Type -Path D:\Code\OSLib\SharpSvn-x64\SharpSvn.dll

#Tools
$svn = New-Object SharpSvn.SvnClient
$msbuild = 'D:\Windows\Microsoft.NET\Framework64\v4.0.21006\msbuild'
$mstest = 'D:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\mstest'

#Sandbox
$sandbox = New-Object SharpSvn.SvnUriTarget -argumentlist "http://dan:password@sevenmagoo:81/svn/sandbox/trunk/"
$workingdir = 'D:\Code\sandbox'
$builddir = 'D:\Build\sandbox'
$solution = $builddir + '\sandbox.sln'
$tests = '/testcontainer:D:\Build\sandbox\sandbox.Tests\bin\Debug\sandbox.Tests.dll'

function sandbox() { ii D:\Code\sandbox\sandbox.sln }
function build()
{   
     echo 'Empty build directory and recreate'
    rm -r -Force $builddir | out-null;
    md $builddir  | out-null; 

    echo 'Checkout successful? '
    $svn.Checkout($sandbox, $builddir);;


    echo 'Building'
    .$msbuild $solution /nologo;

    echo 'Testing'
    .$mstest $tests /nologo;;  
}

Ayende Rahien也做过类似的事情，here。

希望有所帮助，

善，

丹

Answer 5

最大的问题是维护构建脚本。如果您发现您的项目或环境保持一定的静态，那么就没有理由不使用您自己的构建，打包和部署脚本。

事情通常会像项目那样复杂得多。 MSBuild，nAnt和其他（商业）产品提供的一些优点是预先支持与常见服务或概念集成（例如，压缩文件），并且将它用于构建过程的时间要少得多。

只要您可以合理地预测自动化需求，就会有成本（实际或努力），走向对您的环境有意义的方向。

我为您认为最适合的方法添加了一些注意事项here它们可能有助于确定自动化的范围。

Answer 6

如果您打算继续成为“一人店”并且您的项目通常很小，那么您可以通过滚动自己的构建系统来实现。我仍然建议不要这样做，因为有了常用构建环境的经验对你的简历来说是件好事。

我编写了一个自定义构建系统，我们在大约五年前使用它来处理我们拥有的一些相当复杂的多目标构建。我们从2003年左右开始使用它并继续使用它。但是，由于以下原因，我一直试图将其转向Ant甚至是Make：

我编写的构建系统在Windows上运行，我们需要其他平台。它可以被重写为相当容易在别处运行，但是流程管理代码很难轻松移植。
如果您使用的是完全自定义的环境，则集成到CI环境会很麻烦。
添加对不同SCM技术的支持是一个负担。到目前为止，我们需要支持Visual SourceSafe，Subversion和Perforce。
扩展和维护“不会增加客户价值”的大量工作。

现在我们的环境比大多数情况要复杂得多，因为我们进行嵌入式系统开发，因此在Windows上使用两个或三个不同的工具链构建单个产品构建并通常通过ssh外壳到Linux机器并不罕见对于仅限Linux的目标，以及psexec到远程Windows机器以使用节点锁定编译器。回顾一下并认为我们用单个批处理文件开始的构建系统是用Perl重写以容纳声明性语句和编程语言语句的混合物，然后再次用类似Ant的XML声明来编写，这真的很有趣。炮轰批处理或shell的样式。现在我正在考虑用Ant + Maven + Ivy或类似的链替换所有这些。

滚动我自己的构建系统对我来说是正确的决定，因为我们是一个非常小的商店，做主要基于命令行工具的构建，当时没有多种工具可供使用。但是，今天我建议您仔细查看可用的工具。毕竟，编写自己的构建系统意味着您将花费时间和金钱编写和维护它，而不是编写生产代码。

现在有很多工具可用于处理几乎任何你想出的扭曲想法。我认为学习现有系统并扩展它以满足您的需求所花费的时间可能更值得。我发现编写Ant任务的经验非常有趣。总的来说，即使我在使用Ant和CruiseControl发布文档的合同工作中做到这一点，这也是一次很好的学习体验。

Answer 7

到目前为止，我还没有多少提及：依赖/重建管理。一个好的构建系统（即使是古老的make）也会为你处理这个问题，如果你构建自己的构建系统，你会做两件事之一：

经常重建一切（或者至少比你需要的更多）
自行重新实现依赖关系跟踪和更新逻辑

从这个角度来看，在推出自己的解决方案之前，我会认真思考。

这是可悲听到楠快不行了，虽然;虽然它有一定的瑕疵，但Ant是一个合理而灵活的构建系统。

构建过程 - 使用什么？

7 个答案: