Msbuild 构建过程-使用什么？

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

我为什么不走这条路？这真的很难吗 与使用NAnt或MSBuild进行比较

有什么好的，现代的书能帮上忙吗

还有更好的主意吗

---

背景（请注意，对某些人来说这是一个宗教问题，无意冒犯）：

一人购物，多个探索项目。和我们大多数人一样-现在是windows和ASP.Net。考虑到移动和云

我已经开始干预南特，并试图跟进。整个“交付”问题都被搁置了，现在是时候“解冻”它了。然而，我不确定该走哪条路。据我所知：

南特正在显示它的年龄。它很笨拙：它比现代的面向对象语言（如C#）更难理解和维护。即使在我看完这本书之后，在一个你想要执行的是XML的神秘环境中工作似乎也很奇怪，而循环和继承（据我记忆中的“冰河时代”之前）是很难做到的

MSBuid是MS特定的。我甚至不确定它是否支持非MS环境。Team Foundation服务器是昂贵的。 即便如此，它们似乎都提供了价值，因为在我的so搜索中，我没有听到有人使用他们自己的定制软件。但是，我不明白为什么不使用C#并根据需要调用NAnt和/或MSBuild任务

我的建议正好相反——像瘟疫一样避免MSBuild。NANT更容易设置您的构建以进行自动测试、部署到多个生产环境、与cruisecontrol集成以进入环境、与源代码管理集成。我们在使用TFS/MSBuild（使用TFSDeployer、自定义powershell脚本等）时经历了太多的痛苦，让它完成了我们能够用NANT开箱即用的功能。不要浪费你的时间

:

构建一个产品不仅仅是编译它。由于这些工具（及其扩展）所提供的功能，创建安装、更新版本号、创建escrow、分发最终软件包等任务可能会容易得多。虽然您可以使用常规脚本完成所有这些操作，但使用NAnt或MSBuild可以为您提供一个坚实的框架来完成所有这些操作

---

我认为没有理由不在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也做了类似的事情

希望有帮助

善良

---

Dan

最大的问题是构建脚本的维护。如果您看到您的项目或环境保持某种程度的静态，那么就没有理由不编写自己的构建、打包和部署脚本

事情通常会变得比你的项目复杂得多。MSBuild、nAnt和其他（商业）产品提供的一些优势是预烘焙支持与公共服务或概念的集成（例如，压缩文件），并且将其固定到构建过程中所需的时间大大减少

这是有成本的（真实的，或者从努力的角度），所以只要您能够合理地预测您的自动化需求，就朝着对您的环境有意义的方向前进

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

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

如果您计划使用PowerShell，请查看

如果您对XML友好，那么使用MSBuild或NAnt。也许对你来说很有价值。MSBuild有一个优点：Ctrl+F5在VisualStudio中生成此脚本

我一直在慢慢地转向Rake，因为它更好，Ruby是编程语言（这意味着你可以做任何事情）：。如果你喜欢的话，那么你可能会想去看看

---

最后，MSBuild和NAnt任务都可以发送到命令行，因此最终它们可以支持非MS任务

---

我个人倾向于使用MSBuild，并且会让CCNET的TeamCity这样的构建服务器进行构建和部署等。它的灵活性令人难以置信。

NAnt因为一个项目已经结束，或者是生命支持（上一个版本是0.86 beta 1，两年前）。MSBuild的发布基本上缩短了这一过程。NAnt很不错，我想MSBuild也不错，但我觉得越来越倾向于用一种语言而不是一些基于XML的过程性东西来编写代码。使用基于XML的构建框架，调试体验非常糟糕，最终会通过在c#中嵌入“脚本”来作弊，这违背了声明而非编程的目的。就这一点而言，与XSLT一样的悲惨故事

一些好的无XML构建框架：

• Rake（基于Ruby）相当不错，并且存在一些特定于.NET的任务，我认为IronRuby现在运行它
• PSake（基于Powershell）-非常有前途
• 为热爱F的冒险精神而伪装#

---

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

如果您打算继续成为“一人工作室”，并且您的项目通常很小，那么您可能可以使用自己的构建系统。我仍然建议不要这样做，因为在你的简历上有使用常用构建环境的经验是一件好事

大约五年前，我编写了一个定制构建系统，我们在工作中使用该系统来处理一些相当复杂的多目标构建。我们大约从2003年开始使用它，并将继续使用它。然而，出于以下原因，我一直在尝试将其移向Ant，甚至使其更具吸引力：

我编写的构建系统在Windows上运行，我们需要其他平台。它可以很容易地重写以在其他地方运行，但流程管理代码很难轻松移植

集成到