Visual Studioプロジェクト用のスタンドアロンビルドシステム

Question

私たちはMakeを使用して、C、C++、Java、およびその他のビットを含む製品をコンパイルします。可能な限り、私たちはソース管理にチェックされたすべてをコンパイルするために必要なすべてのツールを持っています。ローカルの依存関係を排除し、開発マシン間での一貫性を保証します。

最近、Visual Studioを使用してC＃で記述されたいくつかのコンポーネントが追加され、Visual Studioソリューションで同様のアプローチを採用したいと考えています。 devenvにシェリングするのは良い選択ではありません。 csc.exeを直接呼び出すと（私がNantを使用する前に行ったように）、ビルドスクリプトでファイルの依存関係を追跡する必要があります。

MSBuildのデフォルトの場所は%windir%\Microsoft.NET\Framework\[version]\ですが、パスの[バージョン]と[Framework64]と[Framework64]の両方が表示されるため、マシン間のばらつきが気になります。ディレクトリ。すべての開発者が.NETフレームワークのバージョンをインストールしているという要件はありますが、私はあなたのv3.5が私と同じではないかもしれないと心配しています。

誰にでもこのようなソリューションがありますか？あなたが本当に好きではないものを試してみましたか？

Answer 1

MSBuildは確かに最低の摩擦オプションです。異なるfxバージョンは、ビルド時にはそれほど大きなものではありません。インストールされているものよりも高いバージョンのfxから重要なものを使用している場合、ビルドされません。私が最後に行ったのは、NAntをベースにした巨大なマルチ環境構築システムを構築し、NAntのMSBuildタスクを使ってMSBuildに接続しました。 MSBuildはMSの作業をしているだけであれば問題ありませんが、MSBuildがネイティブにサポートしていなかったものがたくさんあり、したがってNAntラッパーです。

Answer 2

MSBuildはこの仕事に適したツールです。使用しているVisual Studioにバンドルされているフレームワークのバージョンとフレームワークのバージョンを一致させるだけです。

32ビットと64ビットの違いはありません。私は確信していません。Csc.exeの32ビット版と64ビット版のどちらも、他のプラットフォームとクロスコンパイルできます。 MSBuildプロジェクトファイル（*。* proj XMLファイル）には、MSBuildがアプリケーションを構築するために必要なものすべてが含まれている必要があります。

Answer 3

私は他の人と同意します。簡単にするには、vsvars.bat（Visual Studioのコマンドプロンプトであるバッチファイル）をビルドスクリプトの一部にして、MSBuildを動作させるだけです。

Answer 4

Nantを使用してmsbuildを駆動します。さまざまなバージョンのフレームワーク、特にサービスパックについて心配している場合は、FxCopを使用して、予期せぬ依存関係が詰まっていないことを確認してください。詳細はthis answerです。