msbuild - nantからmsbuildに切り替える必要がありますか？

Question

私は現在、nant、ccnet（クルーズコントロール）、svn、mbunitを使用しています。シェルアウトが簡単だったという理由だけで、msbuildを使用してslnビルドを実行します。

ビルドスクリプト全体をMSBuildに切り替えるメリットはありますか？テスト、watirスタイルのテスト、xcopyデプロイを実行できる必要があります。これは簡単ですか？

更新：nantからmsbuildに移行する原因となる魅力的な機能はありますか？

score 31 · Accepted Answer

私は MSBuild が好きです。理由の 1 つは、.csproj ファイルが msbuild ファイルであり、VS でのビルドがコマンドラインでのビルドと同じであることです。もう 1 つの理由は、私が使用している CI サーバーである TeamCity からの優れたサポートです。MSBuild の使用を開始し、ビルドプロセスでさらにカスタム処理を行いたい場合は、MSBuild コミュニティタスクを入手してください。彼らはあなたに素晴らしい追加のタスクをたくさん与えてくれます。ここ数年、NAnt を使用していませんが、後悔していません。

また、Ruben が言及しているように、CodePlex にはSDC タスクタスクがあります。

さらにお楽しみいただくために、Twitter タスクを含むMSBuild Extension Pack on CodePlexがあります。

score 27 · Accepted Answer

私のアドバイスは正反対です - 疫病のように MSBuild を避けてください。NANT は、自動テストの実行、複数の本番環境へのデプロイ、エントリー環境用の CruiseControl との統合、ソース管理との統合を行うためのビルドのセットアップがはるかに簡単です。TFS/MSBuild (TFSDeployer、カスタム PowerShell スクリプトなどを使用) を使用して、NANT ですぐに実行できたことを実行できるようにするために、非常に苦労しました。時間を無駄にしないでください。

score 12 · Accepted Answer

MSBuild を使用する最も説得力のある理由 (少なくとも .NET 3.5 以降) - ビルドエンジンは同時にビルドできます。

これは、複数のコア/プロセッサがある場合に、ビルドが大幅に高速化されることを意味します。

3.5 より前では、MSBuild は並列ビルドを行いませんでした。

score 9 · Accepted Answer

MSBuildとNantはかなり似ていると思います。これらのいずれかを使用している場合、選択した製品に欠けている魅力的な機能がない限り、通常はそれらを切り替えません。

私は個人的に新しいプロジェクトにMSBuildを使用していますが、マイレージは異なる場合があります。

お役に立てば幸いです。

編集： @ChanChan-@Jonは、Nantが.NET3.5アプリケーションをビルドしないと述べています。これは、変更するか、少なくともそれらを並行して使用するのに十分な理由である可能性があります。私はMSBuildに移行しているので、どちらのテクノロジでも他のショートッパーを強調するのに最も知識のある人ではないでしょう。

編集： Nantが.NET3.5アプリケーションをビルドするようになりました。

score 3 · Accepted Answer

NAnt は以前から存在しており、かなり成熟した製品であり、IMO も使いやすいです。Mono だけでなく .NET や Silverlight で実行できるアプリの構築に興味がある場合は、利用できるコミュニティのノウハウがたくさんあり、クロスプラットフォームでもあります。箱から出してすぐに、MSBuild よりもはるかに多くのことを行います。そうそう、NAnt から MSBuild を呼び出すことができます (OK、NAntContrib から) :-)

マイナス面としては、NAnt とその姉妹プロジェクトである NAntContrib は停滞しているようで、最新の更新は 2007 年後半です。

MSBuild の主な利点は、.NET Framework に付属しているため、インストールする製品が 1 つ少ないことです。そして、より活発な開発が進行中です (ただし、古い NAnt に追いつくための場所ではあります)。

個人的には、その構文を理解するのは少し難しいと思いますが、引き続き ti にさらされることで物事が容易になると確信しています。

結論？既存の NAnt スクリプトを使用している場合は、それらに固執してください。移植の手間をかける価値はありません。新しいプロジェクトを開始していて、冒険心がある場合は、MSBuild を試してみてください。

score 2 · Accepted Answer

また、nantからmsbuildに切り替えました。ビルドがかなり標準的なものであれば、セットアップにそれほど問題はありませんが、特定のビルドタスクがたくさんある場合は、msbuildのカスタムタスクがはるかに少ないため、カスタムmsビルドタスクを作成する必要があります。

妥当なビルド結果を表示したい場合は、カスタムロガーなどをいじる必要があります。チーム全体のビルドは、nantほど熟していません。

しかし、本当のメリットは、TFSソース管理およびレポートサービスとの統合です。ソース管理システムとしてTFSを使用していない場合は、それだけの価値はありません。

score 1 · Accepted Answer

私は実際にまだこの質問を自分で理解しようとしていますが、ここでMSBuildに大きなボーナスが1つあります。msbuild.exeを直接呼び出すことでローカル継続的インテグレーションに同じビルドファイルを使用し、VSTSのサーバー側継続的インテグレーションも使用できることです。同じビルドファイルとの統合（ほとんどの場合、異なるプロパティ/設定ですが）。

つまり、TeamCityのMSBuildスクリプトのサポートと比較すると、VSTSはMSBuildスクリプトのみをサポートしています。私は過去にMSBuildからNAntを実行することでこれをハックしました。他の人がこの方法とその逆を推奨しているのを見たことがありますが、それは私には厄介なように思われるので、回避できる場合はそれを行わないようにしています。したがって、「完全なMicrosoftスタック」（VSTSおよびTFS）を使用している場合は、MSBuildスクリプトを使用することをお勧めします。

score 1 · Accepted Answer

@ブラッドリーチ

欠けている魅力的な機能がない限り、私は一般的にそれらを切り替えませんでした

msbuildを使用する説得力のある理由は何ですか？短所はありますか？

これまでのところ、私はあなたの答えから「気にしないでください」というかなり良いものを得ています。

score 1 · Accepted Answer

MSBuildがVisualStudioと統合されているため、プログラマーはビルドシステムを使用する際の摩擦が少なくなります。それは主に「ソリューションのビルド」に進むだけですべて機能しますが、カスタムビルドステップなどを使用する必要はなく、さらに悪いことに、開発者に何らかの外部スクリプトを起動してビルドさせる必要があります。

今では、単純なため、NAntよりもMSBuildを好む傾向があります。もちろん、NAntにはもっと多くの機能があり、より強力ですが、すぐに手に負えなくなる可能性があります。あなたとあなたのビルドエンジニアがNAntスクリプトをシンプルに保つための規律を持っているなら、それはすべて良いことです。しかし、NAntベースのシステムがあまりにも多く南下して、それが何をしているのか誰も理解できなくなっているのを見てきました。また、古き良きprintfと同等のことを行う以外に、デバッグする実際の方法はありません。if / elseステートメントまたはforループを使い始めた瞬間、私見では、匂いがし始めます。

一方、MSBuildは、メタデータとそれほど冗長でない構文に基づいた強固な基盤を備えています。その単純さ（または機能の欠如...見方によっては...）により、XMLマークアップでロジックを記述する代わりに、新しいタスクを介して.NETコードでロジックを記述する必要があります。これにより、再利用が促進され、何よりも、実際のデバッガーでビルドシステムを実際にデバッグできるようになります。

MSBuildの唯一の問題は、それほど頻繁ではないバグ（特に最初のバージョン）またはあいまいな（文書化されているが）動作です。そして、それが本当にあなたを悩ませているようなものなら、マイクロソフトに縛られています。

score 1 · Accepted Answer

機能も使いやすさもどちらも同等だと思います。C# ベースであるというだけで、msbuild は nants よりも扱いやすいと思いますが、それは乗り換える説得力のある理由にはなりません。

ナントはあなたのために何をしていないのですか？それとも、見逃しているかもしれないクールな機能があることを望んでいますか? :)

C# の非常に優れた点の 1 つは、.net フレームワークがあれば、msbuild を実行するために必要なものがすべて揃っていることです。これは、大規模なチームやプロジェクトで作業していて、人員やハードウェアの入れ替わりがある場合に最適です。

個人的には、どちらよりも SCons の方が好きです :)

score 1 · Accepted Answer

自動ビルドに msbuild ではなく nAnt を使用している主な理由は、ビルドをより細かく制御できるからです。csproj を使用する msbuild にはビルドファイルがあるため、そのプロジェクトのすべてのソースが 1 つのアセンブリにコンパイルされます。これにより、ロジックを分離している大規模なプロジェクトのソリューションに多くのプロジェクトが含まれることになります。nant を使用すると、必要なものを 1 つのプロジェクトから複数のアセンブリにコンパイルできるビルドを配置できます。

ソリューションに多くのプロジェクトファイルが必要ないため、この方法が気に入っています。レイヤーを分割するフォルダーを含む 1 つのプロジェクトを作成し、nant を使用して各レイヤーを独自のアセンブリに構築できます。

ただし、WPF アプリケーションのビルドなど、一部のビルドタスクでは nant と msbuild の両方を組み合わせて使用します。nant 内で msbuild ターゲットを使用して WPF アプリケーションをコンパイルする方がはるかに簡単です。

これを終わらせるために、私の答えの要点は、それらを並べて使用するのが好きだということですが、この構成で msbuild を使用する場合、通常は直接コンパイルするためのものであり、ファイルをディレクトリにコピーしたり、ファイルを生成したりするようなビルド自動化タスクは実行しません。たとえば、ヘルプドキュメントを参照したり、単体テストを実行したりします。

score 1 · Accepted Answer

Nantにはすぐに使える多くの機能がありますが、MSBuildにははるかに優れた基本構造 (アイテムメタデータロック) があり、再利用可能な MSBuild スクリプトの作成がはるかに簡単になります。

MSBuild は理解するのに時間がかかりますが、一度理解すると非常に便利です。

学習教材:

Microsoft Build Engine の内部: MSBuild と Team Foundation Build の使用
by Sayed Ibrahim Hashimi (2009 年 1 月)
Deploying .NET Applications: Learning MSBuild and ClickOnce by Sayed
by Y. Hashimi (2008 年 9 月)

score 1 · Accepted Answer

NANT から MSBuild に切り替えました。プロジェクトは.Net 4.0で実行されています。

ナントでの私の経験は良かったです。プロジェクトは一種の死にました。そして、.Net 4.0 が登場したとき、ビルドプロセスを再評価する時が来ました。

Nant が最後にリリースされて以来、MSBuild は順調に進んでいます。現時点では、MSBuild が最適です。使いやすく、多くの拡張機能があります。Nant スクリプトを 1 日半で書き直しました。MSBuild スクリプトは、Nant スクリプトの 1/3 のサイズです。

Nant スクリプトでの作業の多くは、さまざまな環境のセットアップでした。MsBuild/.Net 4.0 では組み込みです。

score 0 · Accepted Answer

現在のバージョンのNantはまだ.NET3.5アプリケーションをコンパイルできないため（.NET 2.0が最初にリリースされたときも同じでした）、Nantと一緒にMSBuildを使用しています。

score 0 · Accepted Answer

msbuildを使用するために私が見ることができる唯一の理由は、クルーズコントロールのような自動ビルドサーバーを使用したい場合です。あなたが切り替えるつもりがないなら、私はそれを放っておくでしょう。

score 0 · Accepted Answer

私はナントを使っていて、とても気に入っています。私は MSBuild を使用しましたが、次の理由で嫌いでした。

Microsoft は独自のビルド手順に従うことを強制していますが、これは彼らのやり方に非常に固有のものであるため、少なくとも私はそれを機能させることができませんでした (NET1.1 をコンパイルする必要があったため、Nant と MSbuild を混在させる必要がありました)。独自の MSBuild ファイルを作成できることは知っていますが、理解して維持するのは複雑だと思いました。
ファイル操作を行うための ItemTypes は、従うのが難しすぎます。Nant にまったく同じことをさせることができますが、はるかに簡単かつ直接的です (ItemType リストを作成してから、ファイル操作に渡す必要がありました)。
MsBuild では、独自のタスク dll を作成する必要があります。Nant では、これを行うか、スクリプト内に C# コードを埋め込むことができるため、プロジェクト全体を進めてビルドするのがはるかに簡単になります。
Nant は Net1.1 で動作しますが、MsBuild は動作しません。
nant をインストールするには、解凍して自分のリポジトリ内に配置して実行することもできます。MsBuild をインストールするのは、Visual Studio などからの多くのものに依存するため、はるかに困難です (ここで間違っているかもしれませんが、それは真実のようです)。

さて、これらは私の意見です...

msbuild - nantからmsbuildに切り替える必要がありますか？

18 に答える 18

Related

Reference