Visual Studio Solutionファイルの代わりにMSBuildを使用する必要があるのはなぜですか？
継続的な統合にTeamCityを使用しており、ソリューションファイル（.sln）を介してリリースを構築しています。私は過去にさまざまなシステムでMakefileを使用したことがありますが、msbuildは使用していません（Makefile + XMLマッシュアップのようなものだと聞いています）。ソリューションファイルの代わりにmsbuildを直接使用する方法に関する多くの投稿を見てきましたが、whyに対して明確な答えが見当たらない。
では、なぜソリューションファイルからMSBuildの「makefile」に移行する必要があるのでしょうか。 #define（機能強化ビルド）が異なるいくつかのリリースがありますが、ほとんどの場合、すべてが機能します。
より大きな懸念は、プロジェクト/ソースコードを追加するときに、2つのシステムを維持する必要があることです。
PDATE：
人々は、次の3つのコンポーネントのライフサイクルと相互作用に光を当てることができますか？
- Visual Studio .slnファイル
- 多くのプロジェクトレベルの.csprojファイル（「サブ」msbuildスクリプトを理解しています）
- カスタムmsbuildスクリプト
.slnと.csprojは、Visual Studio IDE GUI内から通常どおりに消費/保守されていると言っても安全ですが、カスタムmsbuildスクリプトは手書きであり、通常は既存の個々の.csprojを消費します。そのまま"？これは、メンテナンスで重複/重複を減らすことができる方法の1つです...
他の人々の運用経験からこれについていくつかの光をいただければ幸いです
実際の最初のポイントは、MSBuildが実行すると、ソリューションファイルがほとんど魔法のようにMSBuildファイルになるということです。これは、Visual Studioでソリューションをビルドすると起こります。さらに、これらのプロジェクトファイルはすべて、Visual Studioによって管理されるmsbuildファイルにすぎません。実際、プロジェクトファイルは、ソリューションからビルドする場合でも、カスタムmsbuildスクリプトからビルドする場合でも、ここで実際のダーティな作業のほとんどを処理します。
また、TeamCityを使用してアプリケーションをビルドおよび公開します。通常、ほとんどのプロジェクトでカスタムmsbuildスクリプトが作成されます。これらのスクリプトが果たす役割（ソリューションファイルでは簡単ではありません）は、プロジェクトを展開または配布用にパッケージ化することです。通常、これらのスクリプトは、Webプロジェクトを特定のフォルダーにビルドしたり、開発構成ではなく実行中の構成をコピーしたりするなど、操作に関するいくつかの側面を処理します。重労働はプロジェクトファイル自体で処理される傾向があります。ビルドスクリプトはそれらを参照するだけで、そのホイールを再作成することはしません。全体的にそれはうまく機能し、実際にはあまり重複したコードではありません。通常、ビルドスクリプトを取得したら、プロジェクトに大幅な変更があり、ビルドを大幅に変更する必要があるまで、スクリプトに触れる必要はほとんどありません。
Msbuildのmakefile is .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で必要）とノード以外のインストール要件はありません。
参考として、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）ビルドスクリプトなのでしょうか。ビルドに関しては、より多くの要件を持つことになるからです。おそらくいくつかのテストを実行し、そこからアーティファクトを生成したいと思うでしょう。おそらくデプロイメントを行いたいでしょう。そして、ビルドサーバー上であれ、マシン上であれ、必要なものがすべて実行可能である必要がある場合は、ビルドスクリプト内でしか実行できません。