MSBuild (または NAnt) のようなツールを使用してプロジェクトのコレクションをビルドすることと、コマンド ラインから DevEnv.exe を実行することの利点を説明できる人はいますか?
過去に一緒に働いていた同僚は、(少なくとも古いバージョンの Visual Studio では) DevEnv.exe を使用すると、他の手法よりもはるかに遅いと説明していましたが、その証拠を読んでいないか、それが現在2005 年以降、Visual Studio は内部で MSBuild を使用しています。
MSBuild を使用する利点の 1 つは、ビルド マシンに Visual Studio をインストールしなくてもプロジェクトをビルドできることを知っていますが、他に利点があるかどうかはわかりませんでした。
その理由の 1 つは、製品をコンパイルするだけでなく、製品を構築することがもっとたくさんあるからです。インストールの作成、バージョン番号の更新、エスクローの作成、最終的なパッケージの配布などのタスクは、これらのツール (およびその拡張機能) が提供するものにより、はるかに簡単になります。
これらすべてを通常のスクリプトで行うこともできますが、NAnt または MSBuild を使用すると、これらすべてを行うための強固なフレームワークが得られます。ダウンロード可能な追加のタスク ( MSBuild Community Tasks Projectなど) を含め、両方に対して多くのコミュニティ サポートがあります。さらに、多数のサードパーティおよびオープン ソース製品でサポートされています。
(ビルド プロセス全体ではなく) コンパイルだけに関心がある場合は、MSBuild の時間を節約できる利点の 1 つは、複数のプロセッサを使用したビルドのサポートであることに気付くかもしれません。
C# に関する限り、devenv.exe 2005 はコンパイラをインプロセスで実行するため、大規模なソリューションでメモリ不足の例外が発生する可能性があります。Msbuild は、プロジェクトごとに csc.exe プロセスを起動します。devenv /build でコンパイルされないプロジェクトは、msbuild で正常に動作します。この理由を気に入っていただければ幸いです。
NAnt や MsBuild などの外部ビルド ツールを使用する主な理由は、ビルド プロセスを自動化し、システムのステータスに関する継続的なフィードバックを提供できることです。また、それらは「純粋な」ビルド以外にもさまざまな用途に使用でき、そこから実際に価値を得ることができます。単一のコマンドでアプリケーションをビルドおよびテストできることは非常に価値があります。
また、メトリクスの収集、リリース バイナリのパッキング、およびそのようなあらゆる種類の気の利いたものなどの追加を開始することもできます。
DevEnv から、内部で MsBuild を使用するツール (Visual Build Pro) に切り替える実験を行っていますが、必要のないプロジェクトで "System.Drawing... のアセンブリに参照が必要です" エラーが発生しました。 Visual Studio で問題なくビルドできます。
C#、マネージ C++、および単純な古いアンマネージ C++ アセンブリ/dll で構成される大規模なシステムがあります。プレーンな古い C++ コードに依存するマネージド C++ コードに依存する C# コードに依存するマネージド C++ コードに依存する C++ コードがあります (うわー!)。数年前に自動ビルド環境をセットアップしていたときに、MSBuild.exe がすべての依存関係を適切に処理していないことに気付きました。
Microsoft と協力して、一部の問題を解決できましたが、すべてではありませんでした。私の記憶が正しければ、マネージド C++ dll に依存する C# アセンブリをビルドすることはできませんでした。そのため、コマンド ラインから devenv.exe を呼び出すカスタム ビルド スクリプトを作成したところ、問題なく動作しました。
もちろん、これは VS2005 の場合で、現在は修正されている可能性がありますが、スクリプトはまだ機能しているため、この問題を再検討していません。