最佳的.NET生成工具

Best .NET build tool

本问题已经有最佳答案，请猛点这里访问。

Possible Duplicate:
NAnt or MSBuild, which one to choose and when?

.NET的最佳构建工具是什么？

我目前使用NAnt，但仅是因为我有使用Ant的经验。是MSBuild首选吗？

我们实际上将NAnt和MSBuild与CruiseControl结合使用。 NAnt用于脚本流控制，并调用MSBuild来编译项目。触发物理构建后，将使用NAnt将单个项目的构建输出发布到共享位置。

我不确定这是最好的过程。我认为我们许多人仍在寻找出色的构建工具。我最近在.NET Rocks上第362集上听到的一个很有前途的事情是James Kovac的PSake，这是他完全基于PowerShell的构建系统。听起来确实很有希望，因为从理论上讲，您可以使用PowerShell进行的操作是无限的。

我只想将FinalBuilder加入其中。它不是免费的，但是如果您对编辑XML文件感到厌倦，并且想要在一个更好的(IMO)环境中工作，我将为您提供帮助。

我已经与所有这些人一起工作，并且总是回到FinalBuilder。

还有另一个名为NUBuild的新构建工具(非常智能的package器)。它是轻量级的，开源的，并且非常易于设置，并且几乎没有接触维护。我真的很喜欢这个新工具，我们已经将它作为我们持续构建和集成项目的标准工具(我们在75个开发人员中拥有大约400个项目)。试试吧。

http://nubuild.codeplex.com/

易于使用的命令行界面
能够定位所有.NET Framework
版本，即1.1、2.0、3.0和3.5
支持基于XML的配置
支持项目和文件
参考
自动生成"完整
给定的构建清单"
项目–无需触摸维护。
能够检测和显示
循环依赖
执行并行构建-
自动决定哪个
生成的构建列表中的项目
可以独立构建。
处理代理程序集的能力
提供构建的视觉线索
过程，例如显示"完成百分比"，
"当前状态"等
都生成详细的执行日志
XML和文本格式
轻松整合
CruiseControl.NET连续
整合系统
可以使用自定义记录器，例如XMLLogger
定位到2.0版本时
解析错误日志的能力
能够将构建的程序集部署到
用户指定的位置
能够同步源代码
带源控制系统
版本管理能力

我完全使用MSBuild进行构建。这是我的通用MSBuild脚本，该脚本在树中搜索.csproj文件并进行构建：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\\bin\\xUnit\\xunitext.runner.msbuild.dll" TaskName="XunitExt.Runner.MSBuild.xunit"/>
<PropertyGroup>
<Configuration Condition="'$(Configuration)'==''">Debug</Configuration>
<DeployDir>$(MSBuildProjectDirectory)\\Build\\$(Configuration)</DeployDir>
<ProjectMask>$(MSBuildProjectDirectory)\\**\\*.csproj</ProjectMask>
<ProjectExcludeMask></ProjectExcludeMask>
<TestAssembliesIncludeMask>$(DeployDir)\\*.Test.dll</TestAssembliesIncludeMask>
</PropertyGroup>

<ItemGroup>
<ProjectFiles Include="$(ProjectMask)" Exclude="$(ProjectExcludeMask)"/>
</ItemGroup>

<Target Name="Build" DependsOnTargets="__Compile;__Deploy;__Test"/>

<Target Name="Clean">
<MSBuild Projects="@(ProjectFiles)" Targets="Clean"/>
<RemoveDir Directories="$(DeployDir)"/>
</Target>

<Target Name="Rebuild" DependsOnTargets="Clean;Build"/>


<Target Name="__Compile">
<MSBuild Projects="@(ProjectFiles)" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="AssembliesBuilt"/>
</MSBuild>
<CreateItem Include="@(AssembliesBuilt -> '%(RootDir)%(Directory)*')">
<Output TaskParameter="Include" ItemName="DeployFiles"/>
</CreateItem>
</Target>

<Target Name="__Deploy">
<MakeDir Directories="$(DeployDir)"/>
<Copy SourceFiles="@(DeployFiles)" DestinationFolder="$(DeployDir)"/>
<CreateItem Include="$(TestAssembliesIncludeMask)">
<Output TaskParameter="Include" ItemName="TestAssemblies"/>
</CreateItem>
</Target>

<Target Name="__Test">
<xunit Assembly="@(TestAssemblies)"/>
</Target>
</Project>

(很抱歉，如果它有点密集。Markdown似乎正在删除空白行。)

这很简单，但是一旦您了解了概念，并且所有依赖项都会自动处理。我应该注意，我们使用Visual Studio项目文件，这些文件中内置了很多逻辑，但是该系统允许人们在Visual Studio IDE或命令行中几乎完全相同地进行构建，并且仍然可以灵活地添加内容到您在上面的脚本中看到的xUnit测试之类的规范构建。

一个PropertyGroup是所有配置发生的地方，并且可以对其进行自定义，例如从构建中排除某些项目或添加新的测试程序集掩码。

ItemGroup是发生逻辑的地方，该逻辑在树中找到所有.csproj文件。

然后有一些目标，大多数熟悉make，nAnt或MSBuild的人都应该能够遵循。如果您调用Build目标，它将调用__Compile，__Deploy和__Test。清理目标在所有项目文件上调用MSBuild来清理它们的目录，然后删除全局部署目录。重建调用先清理，然后再构建。

Rake和Albacore是出色的组合。 Ruby的力量，没有XML。

.NET开放源5-Liam McLennan的Rake和Albacore的.NET自动化[Tekpub.com]

我们正在使用Bounce，这是C#中用于更干净的构建脚本的框架。

我使用商业软件Automated Build Studio进行构建。

我们使用MSBuild，因为我们从VisualStudio2005(现在为VisualStudio2008)开始，并且MSBuild已"内置"到SDK中-构建服务器上的维护较少。确实，这是一个NAnt克隆-两种工具都具有无限的灵活性，因为它们可以让您在代码中创建自定义构建任务，并且都已经创建了一套不错的社区构建任务。

MSBuild社区任务
NAntContrib

使用动态脚本语言(如Python，BOO，Ruby等)创建和维护构建脚本可能是NAnt等基于XML的良好选择。 (它们倾向于比XML更干净。)

这也取决于您要构建的内容。 MSBuild SDC任务库具有几个特殊任务。例如，对于AD，BizTalk等。

There are over 300 tasks included in
this library including tasks for:
creating websites, creating
application pools, creating
ActiveDirectory users, running FxCop,
configuring virtual servers, creating
zip files, configuring COM+, creating
folder shares, installing into the
GAC, configuring SQL Server,
configuring BizTalk 2004 and BizTalk
2006, etc.

我既使用过又喜欢使用NAnt。我很难说一个比另一个"好"。

UppercuT使用NAnt进行构建，并且使用Build Framework非常容易。

对于大多数项目，自动构建就像(1)解决方案名称，(2)源代码控制路径，(3)公司名称一样容易！

http://projectuppercut.org/

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

我同时使用了MSBuild和NAnt，我更喜欢MSBuild，主要是因为默认情况下它需要的配置要少得多。尽管您可以使事情变得过于复杂，并通过大量的配置垃圾来加载MSBuild，但最简单的是，您可以将其指向解决方案/项目文件，然后将其移至大多数情况下，足够。

通常来说，与MSBuild相比，我觉得NAnt提供了更多的灵活性，而(由于我的相对简单的需求)到目前为止，我对后者感到满意。