私は自分のものを構築するために MSBuild を使用しています。Build Server のように CruiseControl.net を使いたい。
現在、CCNET は nAnt をよく参照していますが、プロジェクト構成と msbuild を通じて nant が実行できるほとんどのことを ccnet が実行できるように見えます。また、nAnt は、現在ほぼ 1 年前のベータ リリースで、少しサポートされていないようです。
要するに、私は実際には MSBuild に非常に満足しており (特に "公式" コンパイラのフロント エンドであるため)、nAnt には少し不快ですが、時期尚早に判断したくありません。
MSBuild よりも nAnt を使用する理由は何ですか? 特にccnetでは、機能の点でnantと少し重複しているようです（および自動ビルド関連のものを追加しています）
MSBuild に満足しているなら、私は MSBuild を使い続けるでしょう。これは、最初に学習したツールが好みのツールである場合の 1 つかもしれません。私は NAnt から始めましたが、MSBuild に慣れることができません。きっと二人ともしばらく居続けることでしょう。
この 2 つには根本的な違いがいくつかありますが、おそらくこれは、一部の NAnt ファンと Microsoftie の間のこの会話によって最もよく強調されています。
興味深いことに、Jeremy Millerは昨年 、彼のブログで正反対の質問をしました。
私の意見では、それは個人的な好みの問題です。nAntは優れたフレームワークであり、MSBuildはほぼ同じように機能します。（両方のフレームワークで）カスタムタスクを簡単に開発できるため、必要なほとんどすべてのことを実行できます。
私はあなたの質問の「まだサポートされている」部分に答えることはできませんが、あなたがすでにnAntに慣れているなら、それはおそらく実行可能だと思います。あなた（またはあなたのグループの誰か）がMSBuildに精通しているなら、それも良い方法です。
nAnt で使用するカスタム タスクが既に多数ある場合は、そのまま使用してください。MSBuild で得られるものはあまりありません。そうは言っても、nAnt にできることで MSBuild にできないことはないようです。どちらも外部ツールを呼び出すことができ、どちらも .Net ベースのカスタム タスクを実行でき、両方とも多数のコミュニティ タスクを持っています。
ここでは、あなたと同じ理由で MSBuild を使用しています。これは現在、VS のデフォルトのビルド システムであり、心配する nAnt 固有のものはありませんでした。
MSBuildCommunityTasksは、最初に使用するサードパーティ製の優れたタスク ベースであり、VSS や Subversion のサポートなど、私が nAnt で行ったカスタム作業のほとんどをカバーしています。
CC.NET は単なるビルド サーバー テクノロジであり、ビルド スクリプト テクノロジではありません。仕事で CC.NET を使用して、MSBuild ビルド スクリプトを問題なく呼び出すことができます。
NAnt はより古く、より成熟したビルド スクリプト言語ですが、動作方法は似ています。NAnt で実行できて MSBuild でも実行できないことはほとんどないため、実際には、どちらが使いやすいかによって決まります。NAnt のアクティブ度については、最後のリリースがいつだったかではなく、最後のナイトリー ビルドがいつだったかを調べてください。NAnt はリリースからリリースまで時間がかかる傾向にありますが、ナイトリー ビルドは通常かなり安定しています。
正直なところ、それはあなたの環境により良く適合するものに依存します。Microsoft以外のツール、nunit、ccnet、ncoverを多数使用している場合。あなたはおそらくnantでより良いサポートを見つけるでしょう。または、MSTest、TFSBuildを使用している場合は、MSBuildの方が優れた環境であることがわかります。私は両方を学び、すべてがあなたの環境によりスムーズに適合するものを使用します。
非常に多くの人がすでに指摘しているように、ここでの答えは「場合による」です。NAnt では、操作の繰り返しなど、より単純でクリーンな処理がいくつかあります。これに関する議論については、MSDN フォーラムを参照してください。
特に大規模なプロジェクトでは、ハイブリッド アプローチも使用できることがわかりました。新しいコンポーネントが開発されると、多くの nant スクリプトが msbuild に変換されます。どちらも同じ主要機能をサポートしており、一方ではネイティブにサポートされているが他方ではサポートされていないタスクが見つかった場合は、相互に呼び出すことができます。
新しい .NET 開発の場合、MSBuild で開始すると、ソリューション ファイルを直接実行できるため、多くの時間を節約できます。メインのコンパイルから拡張して他のタスク (ソース管理、展開など) を実行することは、非常にうまく機能します。