Visual Studio Solutionファイルの代わりにMSBuildを使用する必要があるのはなぜですか？

TeamCityを使用して継続的な統合を行い、ソリューションファイル（.sln）を介してリリースを構築しています。過去にさまざまなシステムでMakefileを使用してきましたが、msbuildを使用したことはありません（Makefile + XMLマッシュアップのように聞こえます）。ソリューションファイルの代わりにmsbuildを直接使用する方法に関する多くの投稿を見てきましたが、なぜそれを行うべきかについての明確な答えは見当たりません。

それでは、なぜソリューションファイルからMSBuildの「メイクファイル」に移行する必要があるのでしょうか？#define（機能化ビルド）が異なるリリースがいくつかありますが、ほとんどの部分はすべて機能します。

大きな懸念は、プロジェクト/ソースコードを追加するときに2つのシステムを維持する必要があることです。

更新：

人々は、次の3つのコンポーネントのライフサイクルと相互作用に光を当てることができますか？

1. Visual Studio .slnファイル
2. 多くのプロジェクトレベルの.csprojファイル（「サブ」msbuildスクリプトを理解しています）
3. カスタムmsbuildスクリプト

カスタムmsbuildスクリプトは手書きで、通常は既存の個々の.csprojを「現状のまま」消費しますが、Visual Studio IDE GUI内から通常どおり.slnと.csprojを消費/維持すると言うのは安全ですか？これは、メンテナンスの重複/重複を減らす方法の1つです...

他の人々の運用経験から、これに関するいくつかの光をいただければ幸いです

実際の最初のポイントは、MSBuildが実行すると、ソリューションファイルがほとんど魔法のようにMSBuildファイルになることです。これは、Visual Studioでソリューションをビルドすると発生します。さらに、これらのプロジェクトファイルはすべて、Visual Studioで管理されるmsbuildファイルです。実際、プロジェクトファイルは、ソリューションから構築する場合でも、カスタムmsbuildスクリプトから構築する場合でも、ほとんどの実際のダーティな作業を処理します。

また、TeamCityを使用してアプリケーションをビルドおよび公開します。通常、ほとんどのプロジェクトでカスタムmsbuildスクリプトが使用されます。これらのスクリプトが果たす役割（ソリューションファイルでは簡単ではありません）は、展開または配布のためにプロジェクトをパッケージ化することです。通常、これらのスクリプトは、Webプロジェクトを特定のフォルダーにビルドする、開発構成ではなく実行構成をコピーするなど、操作上のいくつかの側面を処理します。面倒な作業はプロジェクトファイル自体で処理される傾向があります。ビルドスクリプトはそれらを参照するだけで、そのホイールを再作成しようとはしません。全体的にはうまく機能し、コードの複製はあまり多くありません。

msbuildのメイクファイルは、.slnファイル（またはvcprojファイル）です。

典型的なmsbuildコマンドラインは次のようになります。

msbuild /p:Configuration=Release BigProject.sln

msbuildを使用するポイントは、スクリプトを作成してビルドプロセスを自動化できるようにすることです。気付いていようといまいと、TeamCityはずっとmsbuildを使用しています。

この質問に対する私の意見を申し上げます。

確かに.SLNファイルを単に「ビルドプロセス」として使用できますが、ファイル自体は実際にはビルドプロセスを構成しません。ソリューションファイルは実際にはVisual Studioの一部であり、開発に使用されます。ただし、Visual Studioはビルドおよびリリースプロセスの一部にすぎません。ソリューションを使用してビルドを管理することはできません。また、ソリューションは確かにスケーラブルなビルド状況を提供しません。

ビルドプロセスを確立する目的は、信頼できるビルドを作成することです。つまり、ビルドプロセスは非常に信頼性が高いため、ビルド構成に関係なく、予測可能なビルド出力が得られます。毎回、すべてのマシン。予測可能で信頼性の高いビルドの結果、テスト、展開、およびリリースのプロセスを高度に自動化できるため、人的エラーのリスクがさらに軽減されます。

ビルドプロセスを確立するには投資が必要ですが、場合によっては投資が必要です。msbuildプロセスを支持するいくつかの要因を次に示します。

• 製品には、同じチームプロジェクトで作業している複数のチーム（クロスファンクショナルまたはそれ以外）があります
• 組織にはチームプロジェクトが1つしかありません（開発者が200人以上いる場合でも、従来のショップの99％に当てはまります）
• ビルドする必要のあるプロジェクトが20以上あり、そのうちのいくつかは他のプロジェクトに依存しており、異なるチームによって管理されています
• 製品には、複数の.NETテクノロジー（C＃、C ++、VB、F＃、ASP.NETなど）、または非.NETテクノロジー（Grunt、node、npm、Javaなど）が組み込まれています
• 製品には重い依存関係があるか、重いプラットフォームの上に構築されています。例としてのSharePoint

最後のポイントを拡張する例を挙げましょう。私の現在の会社はSharePoint開発を行っています。SharePoint開発には、少なくともSharePointプロジェクトでビルドを実行するためにSharePoint Foundationをインストールする必要があります。軽量のビルドサーバーの観点から言えば、ビルドサーバーにSharePointをインストールすることを要求することは完全に非現実的です。SharePointは要件が高いだけでなく、ビルドのパフォーマンスに深刻な影響を与えるだけでなく、ビルドは可能な限り高速で無駄のないものになるはずです。MSBuildを活用することで、ビルドサーバーでのこのインストール要件を排除できます。実際、ビルドサーバーには、.NETフレームワーク（MSBuildで必要）とNode以外のインストール要件はありません。

参考として、Sayed Ibrahim Hashimiによるこの本をチェックすることをお勧めします。http：//www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1 ？ ie = UTF8＆qid = 1412014650＆sr = 8-1-fkmr0＆keywords = msbuild + reliable + build

これはまさに数ヶ月前に私自身に尋ねた質問です！すべてがうまくセットアップされました。

• リポジトリのルートにあるソリューションファイル
• 以下のようなTeamcityで構成されたビルド手順
  • NuGetパッケージを復元する
  • ビルドソリューション
  • 単体テストの実行
  • 統合テスト環境のセットアップ
  • 統合テストを実行する
  • 統合テスト環境の分解
  • 展開パッケージを作成する
  • ビルド移行スクリプト

そして、再現性に関しては、このスコアが低いことが明らかになりました。TeamCityをビルドスクリプトにすると、開発マシンで同様の結果を信頼性の高いものとして再現することが難しくなります。

ビルドスクリプトを作成すると、ビルドスクリプトは実行する必要のあるすべてのことを認識し、すべての変数を設定します。CIサーバーをビルドスクリプトとして使用すると、複雑なテストが失敗したり、展開パッケージを手動でビルドする必要があるなど、いくつかの問題が発生した場合（私の例のように）、ビルドのすべてのステップを手動でまとめる必要があります。

だから、要するに、なぜ（MS）ビルドスクリプト？なぜなら、ビルドに関してはより多くの要件が必要になるからです。おそらく、いくつかのテストを実行し、そこからいくつかの成果物を生成する必要があります。おそらくデプロイメントを行いたいでしょう。そして、ビルドサーバー上であろうとマシン上であろうと、必要なものすべてを実行可能にする必要がある場合、ビルドスクリプト以外の場所には行きません。