コマンドラインからDevEnv.exeを実行するよりもMSBuildまたはNAntを使用する利点

Question

MSBuild（またはNAnt）などのツールを使用してプロジェクトのコレクションを構築することと、コマンドラインからDevEnv.exeを実行することの利点を説明できますか？

過去に働いていた同僚は、（少なくとも古いバージョンのVisual Studioでは）DevEnv.exeを使用することは他の技術よりもはるかに遅いと説明していましたが、その証拠や2005年以降、Visual Studioは内部でMSBuildを使用するようになりました。

MSBuildを使用する利点の1つは、ビルドマシンにVisual Studioをインストールしなくてもプロジェクトをビルドできることですが、他にあるかどうかはわかりませんでした。

Answer 1

1つの理由は、単に製品をコンパイルするだけではなく、製品を構築することの方がはるかに多いためです。インストールの作成、バージョン番号の更新、エスクローの作成、最終パッケージの配布などのタスクは、これらのツール（およびその拡張機能）が提供するものであるため、はるかに簡単です。

これらすべてを通常のスクリプトで実行できますが、NAntまたはMSBuildを使用すると、これらすべてを実行するための強固なフレームワークが得られます。ダウンロード可能な追加のタスク（ MSBuild Community Tasks Project など）を含む、両方のコミュニティサポートが多数あります）。さらに、多くのサードパーティ製品およびオープンソース製品でサポートされています。

（ビルドプロセス全体ではなく）コンパイルだけに興味がある場合、MSBuildの1つの時間節約の利点が複数のプロセッサを使用したビルドのサポート。

Answer 2

私のチームからの明白な答えは、すべての人がVisual Studioをインストールしているわけではない、特にVisual Studioをビルド/ CIサーバーにインストールしないことです。

Answer 3

NAntやMsBuildなどの外部ビルドツールを使用する主な理由は、ビルドプロセスを自動化し、システムのステータスに関する継続的なフィードバックを提供する機能です。また、「純粋」以外の負荷にも使用できます。ビルドし、そこから本当に価値を得ようとします。1つのコマンドでアプリケーションをビルドおよびテストできることは非常に価値のあることです。

また、メトリックの収集、リリースバイナリのパッキングなど、あらゆる種類の気の利いたものの追加を開始できます。

Answer 4

C＃に関する限り、devenv.exe 2005はコンパイラのインプロセスを実行します。これにより、サイズの大きなソリューションでメモリ不足の例外が発生する可能性があります。 Msbuildは、プロジェクトごとにcsc.exeプロセスを起動します。 devenv / buildでコンパイルしないプロジェクトは、msbuildで正常に動作します。この理由が気に入っていただければ幸いです。

Answer 5

DevEnvから、フードの下でMsBuildを使用するツール（Visual Build Pro）に切り替える実験を行っており、「System.Drawing ...」アセンブリに必要な参照が得られました。不要でVisual Studioで正常にビルドされるプロジェクトのエラー。

Answer 6

C＃、マネージドC ++、プレーンアンマネージドC ++アセンブリ/ dllで構成される大規模システムがあります。プレーンな古いC ++コードに依存するマネージC ++コードに依存するC＃コードに依存するマネージC ++コードに依存するC ++コードがあります（なんと！）。数年前に自動ビルド環境をセットアップしていたときに、MSBuild.exeが所有しているすべての依存関係を適切に処理できないことがわかりました。

マイクロソフトと協力して、すべてではなくいくつかの問題を解決することができました。私の記憶が役立ったなら、マネージC ++ dllに依存するC＃アセンブリをビルドすることはできませんでした。そのため、コマンドラインからdevenv.exeを呼び出すカスタムビルドスクリプトを作成しましたが、正常に機能しました。

もちろん、これはVS2005で発生しましたが、現在修正されている可能性がありますが、スクリプトはまだ機能しているため、この問題を再検討することはありません。