最佳 .NET 构建工具 [重复]答案

【问题标题】：Best .NET build tool [duplicate]最佳 .NET 构建工具 [重复]
【发布时间】：2010-09-06 04:53:33
【问题描述】：

可能重复：
NAnt or MSBuild, which one to choose and when?

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

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

【问题讨论】：

看看Fake。

标签： .net build-process nant

【解决方案1】：

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

我不确定这是最好的过程。我认为我们中的许多人仍在寻找出色的构建工具。我最近在 .NET Rocks 上听到的一件很有希望的事情，episode 362，是 James Kovac's PSake，他是一个完全基于 PowerShell 的构建系统。这听起来很有希望，因为理论上你可以用 PowerShell 做的事情是无限的。

【讨论】：

嘿彼得 - 我们做同样的事情，但我们对 NAnt 进行了模板化并使其可重用。我们最终发布了一个名为 UppercuT 的产品 - projectuppercut.org
我去看看。我曾多次考虑过模板化 NAnt 脚本，但一直没有解决。我们过程中最大的痛点是繁琐的复制/粘贴/编辑周期来配置新项目以进行构建。这很容易，因为我们现在有明确定义的约定，但是，正如我所说，乏味......感谢您提供的信息。

【解决方案2】：

我只想将FinalBuilder 加入其中。它不是免费的，但如果您厌倦了编辑 XML 文件并想要一个更好的 (IMO) 环境来工作，我会试一试。

我与他们所有人都合作过，并且总是回到 FinalBuilder。

【讨论】：

+1 来自我。毫无疑问，FinalBuilder 是一个很棒的工具。
我使用过 FinalBuilder，它帮助我加快了速度。几年前它更容易使用，但现在它似乎也变得复杂了。不过比其他选项快得多。

【解决方案3】：

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

<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"/>

  <!--
  ===== Targets that are meant for use only by MSBuild =====
  -->
  <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。 Clean 目标对所有项目文件调用 MSBuild 以清理其目录，然后删除全局部署目录。 Rebuild 调用 Clean 然后 Build。

【讨论】：

【解决方案4】：

还有另一种名为NUBuild的新构建工具（一个非常智能的包装器）。它是轻量级的、开源的并且非常容易设置并且提供几乎无接触的维护。我真的很喜欢这个新工具，我们已经将它作为我们持续构建和集成项目的标准工具（我们有大约 400 个项目，涉及 75 个开发人员）。试试看。

http://nubuild.codeplex.com/

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

【讨论】：

看起来很有趣。但是现在是.NET 4.5，好像没有更新。

【解决方案5】：

Rake 和 Albacore 是一个很好的组合。 Ruby 的强大功能，没有 XML。

.NET Open Source 5 - .NET Automation with Rake and Albacore by Liam McLennan[Tekpub.com]

【讨论】：

这是一个史诗般的视频，我也开始使用它作为我的构建工具:)，一旦你看过视频看看code-magazine.com/Article.aspx?QuickID=1006101

【解决方案6】：

我们使用 MSBuild，因为我们从 Visual Studio 2005（现在的 Visual Studio 2008）开始，并且 MSBuild 已经“内置”到 SDK - 构建服务器上的维护较少。这是一个 NAnt 克隆，真的 - 这两个工具都非常灵活，因为它们允许您在代码中创建自定义构建任务，并且都已经创建了一组体面的社区构建任务。

【讨论】：

【解决方案7】：

我们正在使用Bounce，这是一个用于在 C# 中更清晰地构建脚本的框架。

【讨论】：

【解决方案8】：

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

【讨论】：

【解决方案9】：

使用 Python、BOO、Ruby 等动态脚本语言来创建和维护构建脚本可能是替代 NAnt 等基于 XML 的良好选择。（它们往往比 XML 更易于阅读。）

【讨论】：

对于以 .NET 为中心的项目，如果使用动态脚本语言，首选将/应该是 PowerShell。

【解决方案10】：

我都用过，更喜欢NAnt。我真的很难说一个比另一个“更好”。

【讨论】：

【解决方案11】：

这还取决于您要构建的什么。 MSBuild SDC Task library 有几个特殊任务。比如AD、BizTalk等。

其中包含 300 多个任务该库包括以下任务：创建网站，创建应用程序池，创建 ActiveDirectory 用户，运行FxCop，配置虚拟服务器，创建 zip 文件，配置COM+，创建文件夹共享，安装到 GAC，配置SQL Server，配置 BizTalk 2004 和 BizTalk 2006 年等。

【讨论】：

【解决方案12】：

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

【讨论】：

【解决方案13】：

UppercuT 使用 NAnt 进行构建，它是极其容易使用的构建框架。

自动化构建就像 (1) 解决方案名称、(2) 源代码管理路径、(3) 大多数项目的公司名称一样简单！

http://projectuppercut.org/

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

【讨论】：

第一个链接已失效。项目可能不再处于积极开发阶段。
UppercuT 正准备实施 Cake，因此开发工作即将开始。但你是对的，该链接需要更新。

【解决方案14】：

一般来说，我的印象是 NAnt 与 MSBuild 相比提供了更大的灵活性，而（根据我相对简单的需求）到目前为止，我对后者很好。

【讨论】：