回答:
今週も同様の調査を行いました。これが私が決定できたことです：
NAnt：
MSBuild：
主観的な違い： （YMMV）
（Windowsプラットフォームでの）私にとってのMSBuildの主要な魅力の1つは、.NET自体の一部として提供されることです。つまり、Windows Updateで最新のWindowsマシンであれば、MSBuildを利用できます。これに加えて、C＃コンパイラーも.NET自体の一部であり、クリーンなマシンでプロジェクトをビルドできるプラットフォームがあるという事実を追加します。Visual Studio behemothをインストールする必要はありません。一方、NAntは、ビルドをトリガーする前に明示的にインストールする必要があります。
参考までに、過去の重要なビルドでは、NMake、Make、Ant、Rake、NAnt、MSBuildを（この順序で）使用しました。私のお気に入りはハンドダウンのMSBuildです（そして「それがVisual Studioが使用するものなので」私は好みません）。私見、それは非常に評価されていないビルドツールです。
NAntとMSBuildを、手続き型プログラミングと関数型プログラミングの違いと比較します。NAntは非常に単純で、何を見ても簡単です。一方、MSBuildでは、もう少し考える必要があります。学習曲線は急です。しかし、「取得」したら、それを使って驚くべきことができます。
ですから、関数型または論理型のプログラミングにも引き付けられる場合は、MSBuildを検討することをお勧めします。具体的な結果を確認する前に少しの時間と労力を費やすことをいとわない場合（もちろん、最終的には投資が報われ、より強力なことをより効率的に行うことができます）。
個人的には、同じプロジェクトで両方を使用しています。
MSBuildは、Visual Studioソリューションとプロジェクトの構築に優れています。
私の意見では、NAntはより簡単に手動で編集できます-特にAntを既に知っている場合はなおさらです。NAntはNAntContribを使用して非常に簡単にMSBuildを呼び出すことができます。だから、私はNAntスクリプトを手作りして、ビルドされたファイルのコピー、クリーンアップなどのようなことを行い、MSBuildを呼び出して実際の「C＃ソースコードをアセンブリに変換する」部分を実行します。
その例が必要な場合は、プロトコルバッファのビルドファイルを参照してください。（素晴らしいNAntスクリプトであるとは言いませんが、それでうまくいきます。）
NAntには追加設定なしでより多くの機能がありますが、MSBuildの基本構造（アイテムメタデータロック）ははるかに優れているため、再利用可能なMSBuildスクリプトを簡単に構築できます。
MSBuildを理解するには少し時間がかかりますが、一度理解すれば非常に便利です。
学習資料：
KISS = MSBuildを使用します。
箱から出して合理的な仕事をするものがあるのに、なぜ他のものをミックスに追加するのですか？MSBuildが到着したとき、NAntは亡くなりました。また、MonoにはMSBuild実装（xbuild）があります。
DRY = MSBuildを使用します。
ビルドシステムに何が欲しいのか自問してみてください。2つの異なる構成を維持するのではなく、IDEでも使用されるビルドシステムが必要です。
個人的には、NAntに関する実際の議論を聞きたいと思っています。本当に水を保持しているものは考えられないからです。
いくつかの投稿者が言及していることに気付いた1つのことは、.csproj（または.vbprojなど）ファイルを手動で編集する必要があることでした。
MSBuildでは、.userファイルを使用してこれらの。* projファイルをカスタマイズできます。というプロジェクトがある場合 MyCreativelyNamedProject.csprojをし、その中のMSBuildタスクをカスタマイズしたい、私は名前のファイルを作成することができMyCreativelyNamedProject.csproj.userを使いCustomBeforeMicrosoftCommonTargetsとCustomAfterMicrosoftCommonTargetsをこれらのファイルをカスタマイズします。
また、NAntとMSBuildの両方は、カスタムのMSBuildタスクとNantContrib拡張機能を使用して、ハートのコンテンツに合わせてカスタマイズできます。
したがって、NAntまたはMSBuildを使用することは、実際には親しみやすさに帰着します。
MSBuildは、.NETおよびVisual Studioのすべての新しいバージョンがリリースされるとすぐに動作することがほぼ保証されていますが、NAntには多少の遅れがある可能性があります。
私はNAntスクリプトがMSBuildを呼び出すという点で両方を使用しています。NAntにとどまる私の主な理由は、隔離です。これが重要だと思う理由を説明しましょう。
プロジェクトに依存関係を追加します。NAntビルドファイルはVisual Studio（私の場合、私はこれをプロだと考えています）とは無関係なので、Visual Studioは何もしません。MSBuildタスクは埋め込まれているため、ソリューションの一部であり、他のMSBuildタスクを参照できます。MSBuildコミュニティタスクがインストールされていなかったため、ビルドできないことを確認するためだけに他の人からソースコードを受け取りました。私が特に苛立たしいと思うのは、Visual Studioがビルドせず、たくさんのエラーをスローして、デバッグに時間を費やしてしまったことです。これは、要求されているビルドが（たとえば、デバッグビルドとして）MSBuildタスクの追加機能なしに進んでいる可能性があるという事実にもかかわらずです。要するに、回避できるのであれば、依存関係をプロジェクトに追加したくありません。
Visual Studioを開発チームに任せることができる限り、私はVisual Studioを信頼していません。これは、私のHTMLを大量虐殺するVisual Studioの初期の時代にさかのぼります。私は今でも例としてデザイナーを使用していません（最近の会議で同僚が同じことをしたことがわかりました）。Visual StudioがDLLファイルの依存関係とバージョン番号を台無しにできることを発見しました（これを複製することはできませんが、プロジェクトで一貫して発生し、多くの悲しみと時間の損失を引き起こしました）。Visual Studioを使用してデバッグモードでのみビルドするビルドプロシージャを使用しました。プロダクションでは、NAntを使用して、すべてを外部で制御します。NAntを使用してビルドした場合、Visual Studioはもはや干渉できません。
PS：私はWeb開発者であり、Windowsフォームの開発は行っていません。
私はMsBuildについてはあまり詳しくありませんが、両側の重要な違いのいくつかは追加で補完できるという印象を受けています。
最近、NantでSilverlightプロジェクトを構築する必要がありました。私はMsBuildでこれを行うだけで生活が楽になることを発見しました-結局、Nantスクリプト内からMsBuildタスクを呼び出すことになりました。
それを超えて、私はそれが個人的な好みの問題になると思います-それがあなたのことであれば、明らかに、Visual Studio内からMsBuildの機能の一部またはほとんどを管理できます。Nantは、スクリプトを手動で記述したい場合や、Javaの世界から来た場合は、慣れ親しんでいる場合に、より柔軟で適しているようです。
両方使ってしまいました。ビルドシステムを再設計するとき、私はトリッキーな問題に直面していました。つまり、誰もがVSを使用してプロジェクトファイル、設定、構成を更新していたため、.vcproj（およびファミリ）を取り除くことができませんでした。そのため、大量の重複とエラーが発生しやすいプロセスがなければ、ビルドシステムを新しいファイルセットに基づくことができませんでした。
このため、VSの「proj」ファイルを保持し、MSBuildを使用することにしました（これらはMSBuildファイルであり、少なくともVS2005およびVS2008はMSBuildプロジェクトファイルを使用します）。それ以外のすべて（カスタム構成、単体テスト、パッケージ化、ドキュメントの準備...）には、NAntを使用しました。
継続的な統合には、CruiseControlを使用しました。そのため、ビルドにMSBuildを使用するNAntジョブをトリガーするCCスクリプトがありました。
最後に、MSBuildはセットアッププロジェクトをサポートしていません。したがって、DevEnv.comを呼び出すか、Visual Studioを直接使用することに行き詰まっています。それが私がやったことですが、開発者は通常それらをビルドする必要がないので、デフォルトですべてのソリューション構成からセットアッププロジェクトを無効にしました。そうする場合、手動で選択してビルドすることができます。
VSソリューションを構築できるため、最近NAntからMSBuildに切り替えました。ただし、まだ時々NAntを使用しています。
NAntContribのようなMSBuildコミュニティタスクをチェックアウトすることもできます。
NAntで利用可能なドキュメントとチュートリアルにより、NAntでビルドスクリプトの学習を開始しやすくなります。NAntのコツをつかんでビルドスクリプトを作成したら、その知識をMSBuildに変換し始めました（NAntでXを実行しましたが、MSBuildでXを実行するにはどうすればよいですか？）。Microsoftのドキュメントは通常、役立つ前にかなり高いレベルの知識があることを前提としています。
NAntからMSBuildに切り替える理由は、MSBuildの方が最新であるためです。残念ながら、NAntの最後のリリースは2007年12月8日でしたが、MSBuild 4.0（.NET 4.0）はそれほど遠くないです。NAntプロジェクトが終了したようです。
MSBuildを使用してビルドスクリプトの作成を学び始めたばかりの人向けの優れたドキュメントを見つけたら、NAntをスキップしてMSBuildに直接進んでください。NAntが新しいリリースでリリースされた場合は、NAntを使用することを検討しますが、現在は遅れています。
YDeliver by Manojは、PSake上に構築されたビルドフレームワークです。豊富なライブラリ機能とワークフローを定義する機能があり、6つ以上のエンタープライズプロジェクトを本番環境に提供するために使用しています。
TeamCity、CruiseControl、またはPowerShellを実行できるものと組み合わせて使用します。
FlubuCoreを使用しています。これは、プロジェクトをビルドし、C＃コードを使用してデプロイメントスクリプトを実行するためのオープンソースのC＃ライブラリです。
flubuの使い方の簡単な例：
protected override void ConfigureTargets(ITaskContext session)
{
var compile = session.CreateTarget("compile")
.SetDescription("Compiles the solution.")
.AddTask(x => x.CompileSolutionTask())
.DependsOn("generate.commonassinfo");
}flubuの詳細と開始方法については、こちらをご覧ください： choice-for-build-tool-msbuild-nant-or-something-else