.net - 最高の .NET ビルドツール

Question

重複の可能性:
NAnt または MSBuild、どちらをいつ選択するか?

.NETに最適なビルドツールは何ですか?

私は現在NAntを使用していますが、それは Antの経験があるからです。MSBuildが優先されますか?

score 28 · Accepted Answer

実際にはNAntとMSBuildをCruiseControlと組み合わせて使用します。NAnt はスクリプトフロー制御に使用され、MSBuild を呼び出してプロジェクトをコンパイルします。物理的なビルドがトリガーされた後、NAnt を使用して個々のプロジェクトのビルド出力を共有の場所に発行します。

これが最良のプロセスであるかどうかはわかりません。私たちの多くはまだ優れたビルドツールを探していると思います。最近 .NET Rocks のエピソード 362で聞いた有望な話の 1 つは、James Kovac の PSake です。これは、彼が完全に PowerShell に基づいたビルドシステムです。PowerShell でできることは、理論上かなり無限であるため、非常に有望に思えます。

score 18 · Accepted Answer

FinalBuilderをミックスに投入したいと思います。これは無料ではありませんが、XMLファイルの編集にうんざりしていて、もう少し優れた ( IMO ) 環境で作業したい場合は、試してみてください。

私はそれらすべてを使用してきましたが、常に FinalBuilder に戻ってきました。

score 8 · Accepted Answer

NUBuildと呼ばれる別の新しいビルドツール (非常にインテリジェントなラッパー) があります。軽量でオープンソースであり、セットアップが非常に簡単で、メンテナンスはほとんど必要ありません。私はこの新しいツールをとても気に入っており、プロジェクトの継続的なビルドと統合のための標準ツールにしています (75 人の開発者で約 400 のプロジェクトがあります)。やってみて。

http://nubuild.codeplex.com/

使いやすいコマンドラインインターフェイス
すべての.NET Framework バージョン (1.1、2.0、3.0、および 3.5)をターゲットにする機能
XML ベースの構成をサポート
プロジェクト参照とファイル参照の両方をサポート
特定のプロジェクトの「順序付けられた完全なビルドリスト」を自動的に生成します。タッチメンテナンスは不要です。
循環依存関係を検出して表示する機能
並列ビルドを実行 - 生成されたビルドリスト内のどのプロジェクトを個別にビルドできるかを自動的に決定します。
プロキシアセンブリを処理する機能
たとえば、「% 完了」、「現在のステータス」などを表示するなど、ビルドプロセスの視覚的な手がかりを提供します。
XML 形式とテキスト形式の両方で詳細な実行ログを生成します
CruiseControl.NET継続的統合システムと簡単に統合
2.0 以降のバージョンを対象とする場合、XMLLogger のようなカスタムロガーを使用できます。
エラーログを解析する機能
ビルドされたアセンブリをユーザー指定の場所に展開する機能
ソースコードをソース管理システムと同期する機能
バージョン管理機能

score 8 · Accepted Answer

ビルドには完全に MSBuild を使用しています。ツリーで .csproj ファイルを検索してビルドする汎用の MSBuild スクリプトを次に示します。

<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 テストのような正規のビルドに。

1 つの PropertyGroup は、すべての構成が行われる場所であり、特定のプロジェクトをビルドから除外したり、新しいテストアセンブリマスクを追加したりするなど、カスタマイズできます。

ItemGroup は、ツリー内のすべての .csproj ファイルを検索するロジックが発生する場所です。

次に、make、nAnt、または MSBuild に精通しているほとんどの人が従うことができるはずのターゲットがあります。Build ターゲットを呼び出すと、__Compile、__Deploy、および __Test が呼び出されます。Clean ターゲットは、すべてのプロジェクトファイルに対して MSBuild を呼び出してディレクトリをクリーンアップし、グローバル展開ディレクトリを削除します。Rebuild は Clean を呼び出してから Build を呼び出します。

score 4 · Accepted Answer

レーキとアルバコアは素晴らしい組み合わせです。XML を使用しない Ruby のパワー。

.NET オープンソース 5 - Liam McLennan による Rake と Albacore による .NET 自動化[Tekpub.com]

score 3 · Accepted Answer

Visual Studio 2005 (現在は Visual Studio 2008) から開始し、MSBuild は既に SDK に "組み込まれている" ため、MSBuild を使用します。ビルドサーバーのメンテナンスは少なくて済みます。これは本当に NAnt のクローンです。どちらのツールも、コードでカスタムビルドタスクを作成できるという点で無限の柔軟性を備えており、適切なコミュニティビルドタスクのセットが既に作成されています。

score 3 · Accepted Answer

C# のクリーンビルドスクリプトのフレームワークであるBounceを使用しています。

score 2 · Accepted Answer

2

ビルドには商用ソフトウェアのAutomated Build Studioを使用しています。

于 2008-09-10T08:26:42.367 に答える

score 1 · Accepted Answer

私は両方を使用しており、NAntを好みます。一方が他方よりも「優れている」と言うのは本当に難しいです。

score 1 · Accepted Answer

Python、BOO、Ruby などの動的スクリプト言語を使用してビルドスクリプトを作成および維持することは、NAnt などの XML ベースのスクリプトに代わる良い方法かもしれません。(XML よりも読みやすくなる傾向があります。)

score 1 · Accepted Answer

また、何を構築するかによっても異なります。MSBuild SDC タスクライブラリには、いくつかの特別なタスクがあります。たとえば、AD、BizTalkなど。

このライブラリには、Web サイトの作成、アプリケーションプールの作成、ActiveDirectory ユーザーの作成、 FxCopの実行、仮想サーバーの構成、zip ファイルの作成、COM+の構成、フォルダー共有の作成、 GACへのインストール、 SQL Serverの構成など、300 を超えるタスクが含まれています。、BizTalk 2004 および BizTalk 2006 の構成など。

score 0 · Accepted Answer

一般的に言えば、NAnt は MSBuild に比べて柔軟性が高いという印象を受けますが、(私の比較的単純なニーズでは) これまでのところ MSBuild で問題ありませんでした。

score 0 · Accepted Answer

私は MSBuild と NAnt の両方を使用してきましたが、主にデフォルトで必要な構成がはるかに少ないため、MSBuild の方がずっと好きです。物事を過度に複雑にし、MSBuild を多くの構成ジャンクでロードすることもできますが、最も単純な方法として、ソリューション/プロジェクトファイルをポイントして実行することができます。ほとんどの場合、ほとんどの場合、足りる。

.net - 最高の .NET ビルド ツール

14 に答える 14

Related

Reference

.net - 最高の .NET ビルドツール