特集 MSBuild完全攻略（前編） .NETビルド・エンジン「MSBuild」使いこなし術 デジタルアドバンテージ　一色 政彦 2006/04/15

Page1 Page2

　.NET Framework 2.0では、CLR上で動作するプログラム（以降、.NETプログラム）を生成するための新たなビルド・エンジンとして「MSBuild」が搭載された。

　そこで本特集では、前・後編の2回に分けてMSBuildの詳細を解説する。前編では、「MSBuildとは何かについてとその利用方法」について、後編では「ビルドの手順（以降、ビルド・プロセス）を記述したMSBuild用ファイルの読み方や書き方、またMSBuildにカスタムの機能を追加して拡張する方法」について説明する。

　それではさっそくMSBuildとは何かから説明していこう。

1. 「MSBuild」および「MSBuildファイル」とは？

　MSBuildとは、独自のXMLフォーマットのファイル（以降、MSBuildファイル）を解釈して、それに従い.NETプログラムをビルドするためのツールである。

　MSBuildファイルは、いわば、従来（Visual C++ 6.0以前）のビルド用スクリプト・ファイルである「makefile」のXML版といえるもので、またそのファイルを解釈するMSBuildは、従来のビルド・ツールである「NMake」の.NET Framework版*1ともいえるものだ。

*1 実際にMSBuildの開発コード名は「XMake」だった。

　とはいっても、MSBuildは新しいツールだけあって、その機能は強力である。

　例えばMSBuildには、ビルド時に必要になる作業（例えばファイル・コピー作業など）を実現するための機能（以降、タスク）が最初から豊富に用意されているだけでなく、独自のタスク（以降、カスタム・タスク）を追加して柔軟に現実のビルド・プロセスに対応させられるなど、高い拡張性と自由度を兼ね備えているのだ。

　さらにMSBuildファイルは、マークアップ言語のXMLで記述されているので、人間が参照・編集しやすいだけでなく、ソフトウェアからも参照・編集しやすいという特長がある。要するに、ビルド用スクリプト・ファイルの作成が従来のmakefileファイルよりも簡単なのである。

　.NET Framework 2.0からは、.NETプログラムのビルド環境が基本的にこのMSBuildに統一され、プログラムの生成手順がとてもシンプルになっている。例えば次に示すさまざまなビルド環境では、基本的にMSBuildを使ってビルドすることが推奨される。

（1）Visual Studio 2005環境（IDE）
（2）コマンドライン環境（コマンド・プロンプト）
（3）バッチ・スクリプト環境（バッチ処理ファイル）

　.NET Framework 1.xまでは、例えば（1）の環境ではIDEの実体である「devenv.exe」が独自にビルド処理を行っていた。また、（2）や（3）の環境では、コマンドラインからdevenv.exeを呼び出すか、（Visual Studio .NETのIDEがない環境では）「csc.exe」や「vbc.exe」など各言語のコンパイラを直接、あるいはバッチ処理ファイル（「.bat」ファイルや「WSH」ファイルなど。以降、バッチ・ファイル）に記述して呼び出していた。

　しかし、これらの環境でビルドを行う際には個別にコンパイラ・オプションを指定する必要がある。そしてコンパイラ・オプションは多岐にわたっており非常に複雑だ。そのため、それぞれのビルド環境でまったく同じ出力が得られるようにするのはかなり大変な作業だったのだ。できることなら一度指定したコンパイラ・オプションをどの環境にも使い回したいと考えるのが普通だろう。

　そのようなコンパイラ・オプションを含め、ビルド・プロセスをスクリプト・ファイル化して使い回せるのが、.NET Framework 2.0のMSBuildなのである。MSBuildは.NET Framework 2.0のラインタイム（＝実行環境）に標準で含まれているので、本当にいつでもどこでもまったく同じビルド・プロセスを実行でき、同じ.NETプログラムを生成できる。

　また、（1）の環境ではVisual Studio 2005（以降、VS 2005）のプロジェクト・ファイル（「*.*proj」という名前のファイル。例えば「*.csproj」や「*.vbproj」など）そのものが実はMSBuildファイルであり、IDE上でプロジェクトのビルドを実行した場合、その内部動作でMSBuildと同じビルド・エンジンが使われてビルドが実行される。

　一方、（2）や（3）の環境では、devenv.exeやcsc.exe／vbc.exeを細かなコンパイラ・オプションを付けて直接呼び出すのではなく、ビルド・プロセスを記述したMSBuildファイルを使ってビルドが行えるのだ。つまりVS 2005が生成したプロジェクト・ファイルをMSBuildファイルとして使い回せるわけである。

　このように、MSBuildによってビルド・プロセスがさまざまな環境で統一され、一連のビルド処理の実行が簡単になっている。このことは、それを自動化することも容易になったことを意味する。特にチームでソフトウェア開発を行っている場合では一連のビルド処理を自動化することが一般的なので、そのような場面でMSBuildは役立ってくれるだろう。

　そこで次に、そのような場面で実際にどうやってMSBuildを使えばよいのかを示すとしよう。

【コラム】MSBuildとNAntの違い NAgileで始める実践アジャイル開発 .NET開発者のための開発プロセス入門 　MSBuildと同じようなビルド機能を持つオープン・ソースのツールとして「NAnt」が以前から存在するのをご存じの読者も多いだろう。確かに実際にMSBuildはNAntから多くのコンセプトを学んで作成されたといわれているが、その根底にある思想はまったく異なっていると筆者は認識している。 　具体的には、MSBuildがビルド・プロセスの統一と自動化を目標としているのに対し、NAntは最終的には（ビルド・プロセスだけでなく）アジャイル開発のプラクティス（＝実践項目）の1つである「継続的インテグレーション」（＝継続的なビルドとテストの自動実行を行うこと。「常時結合」とも呼ばれる）を実現することを目的としている。そのためNAntの方が、例えばテスト・ツール「NUnit」の呼び出しが標準機能だけで可能なことなど、あらかじめ用意されているタスクがMSBuildよりも豊富である。 　もちろんMSBuildでもカスタム・タスクを作成することはできるが（詳細次回）、NAntならば最初からすぐに使えるという点などで、アジャイル開発を実践するにはNAntを利用する方が理にかなっていると考えられる。逆にMSBuildの方が良い点を挙げるならば、VS 2005がそれをそのまま利用してくれるということである。

2. MSBuild実行を完全無人自動化して作業効率を高めよう！

　チームによるソフトウェア開発で一連のビルド処理を自動化するために、従来では各種ビルド・ツール（例えばdevenv.exe）の実行やフォルダの作成、ファイルの移動、単体テストの実行などのさまざまなタスクを、バッチ・ファイルに記述することが多いだろう（このようにバッチ処理で完全に機械任せにすることで、人的ミスを軽減する効果もある）。その場合、このバッチ・ファイルは次のような方法によって実行されることになる。

（A）ビルドしたいタイミングで手動により実行

（B）WindowsのATコマンドやWindowsタスク・スケジューラにより（人が作業していない真夜中などに）定期的に実行

　ここでは、（B）のATコマンドを使う方法で、「AutoBuild.bat」というバッチ・ファイルを実行することにしよう。具体的には次のようなATコマンドを発行して定期実行を登録した。

C:\>at 2:00 /every:M,T,W,Th,F,S,Su C:\MSBuildSample\AutoBuild.bat

毎日2時にバッチ・ファイル（AutoBuild.bat）を自動実行する設定

ATコマンドで「月、火、水、木、金、土、日ごと」（＝毎日）の「2:00」に「C:\MSBuildSample\AutoBuild.bat」を定期実行するようにしているところ。

　なお、大半のビルド・プロセスはMSBuildファイルに記述するので、このバッチ・ファイルには単にMSBuildの実行しか記述しない。

■MSBuildの基本的な呼び出し方

　その肝心のバッチ・ファイルの中身だが、それを記述する前に本稿でビルドに使用する、VS 2005で作成したサンプル・アプリケーションの構成内容を次の図に示しておく。

サンプル・アプリケーションの構成内容

この図にはドライブが表示されていないが、本稿ではCドライブのルート・フォルダに「MSBuildSample」フォルダが配置されているという想定である。よって、バッチ・ファイルの「AutoBuild.bat」は「C:\MSBuildSample」フォルダ内にあり、アプリケーションのプロジェクト・ファイルの「ConsoleApplication1」は「C:\MSBuildSample\ConsoleApplication1」フォルダ内にある。

　この図を見れば分かるように、サンプル・アプリケーションは「ConsoleApplication1」という名前のコンソール・アプリケーションである。その最上位に「MSBuildSample」フォルダがあり、その配下にバッチ・ファイルの「AutoBuild.bat」を作成している。このバッチ・ファイルの記述内容は、次のとおりだ。

@Set Path=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;%PATH% msbuild ConsoleApplication1\ConsoleApplication1\ConsoleApplication1.csproj

MSBuildの実行を記述したバッチ・ファイルの中身

当然ながら「msbuild」はMSBuildの実体「msbuild.exe」の拡張子を省略したものだ。

　1行目の「@Set……」では、環境変数のPATHに対して「C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727」というフォルダ・パスを追加している。このフォルダの配下にMSBuildの実体「msbuild.exe」が存在する。要するに、MSBuildへのパスを通しているわけだ。ちなみに、冒頭の「@」はコマンド・プロンプト上にその行自体が出力されないようにするためのものだ（このようにしているのは単にパスを通す処理を暗黙的に実行したいから）。

　2行目が実際のMSBuildの実行コマンドである。msbuild.exeのコマンドライン引数には「*.*proj」という名前のMSBuildファイル（例えば「ConsoleApplication1.csproj」や「ConsoleApplication1.vbproj」などのVS 2005のプロジェクト・ファイルや、独自に命名した「ConsoleApplication1.myproj」など）を指定する。この例では「ConsoleApplication1.csproj」を指定している。

　なおmsbuild.exeはコマンドライン引数を指定せずに呼び出すと、カレント・ディレクトリのMSBuildファイルを自動的に見つけ出してビルドを行う。従って、バッチ・ファイルの内容を次のように記述してもOKだ。

@Set Path=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;%PATH% cd ConsoleApplication1\ConsoleApplication1 msbuild

MSBuildファイルを明示的に指定しないMSBuildコマンドの呼び出し

この場合は、「ConsoleApplication1.csproj」が自動的にMSBuildファイルとして使われてビルドが実行される。ちなみにフォルダ内に2つ以上のMSBuildファイルが存在する場合はエラーとなる。

　なお、MSBuildファイルの名前が「*.*proj」以外だとそのファイルが自動的に検出されないので注意が必要である。

【コラム】「*.*proj.user」ファイルもMSBuildファイル！？ 　以前からVisual Studioでは、「*.*proj」というプロジェクト・ファイルのほかに、「*.*proj.user」というユーザー情報を含むプロジェクト・ファイル（以降、プロジェクト・ユーザー・ファイル）が生成される。実はこのプロジェクト・ユーザー・ファイルもMSBuildファイルで、プロジェクト・ファイルにマージ（＝結合）する形で用いられるようである。

　ここまでの説明で、VS 2005などで作成したプロジェクト・ファイル（＝MSBuildファイル）、もしくは手動で作成したMSBuildファイル（例えば「test.myproj」ファイルなど）の呼び出し方法はご理解いただけただろう。

　しかしVS 2005では、プロジェクトの上位概念としてソリューションという単位がある。これをMSBuildで呼び出せないのだろうか？

INDEX
	MSBuild完全攻略
	.NETビルド・エンジン「MSBuild」使いこなし術（前編）
	1．「MSBuild」および「MSBuildファイル」とは？
	2．コマンドラインからMSBuildを使いこなす！
	ビルド・エンジン「MSBuild」を思いのままに操る技（後編）
	3．MSBuildファイルの基本要素を理解する
	4． プロジェクト項目、プロパティ、条件分岐の記述
	5． カスタム・タスクでMSBuildを思いのままに操る！

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）