*.csproj
/*.vbproj
などのファイル(プロジェクトファイル)は、ビルドの設定と動作を定義するためのファイルで、.NETのビルドエンジンMSBuildによって処理されるXML形式のファイルです。
プロジェクトファイルはProject要素をルート要素として、プロパティ・アイテム・ターゲット・タスク・条件などを表すXML要素・属性から構成されます。 ここではそれらの基本的な要素や、その背景となるMSBuildの概念など、MSBuildプロジェクトファイルに共通する事項について解説します。
また、プロジェクトファイルを編集・拡張する際に必要となる、プロジェクトファイルで使用されるプロパティとアイテムについて解説します。 あわせて、コマンドラインインターフェイスであるdotnet
コマンド(.NET CLI)およびmsbuild
コマンドについても必要に応じて触れています。
ここでは、SDKスタイルのプロジェクトあるいは.NET Core形式と呼ばれる、.NET Core/.NET 5以降で用いられる形式のプロジェクトファイル(以下.NET形式)を中心に扱います。
.NET Frameworkで用いられる形式のプロジェクトファイル(以下.NET Framework形式)については、基本的な要素と概念を含むほとんどの部分は.NET形式のものと共通しますが、一部のプロジェクト設定(プロパティやアイテム)は.NET Framework形式では使用できないもの・当てはまらないものもあります。
プロジェクトファイルの基本事項とMSBuildの概念
プロジェクトファイルはXMLで記述されるファイル形式です。 プロジェクトファイルはフレームワークによって2種類の定義があり、一つは<Project Sdk="...">
で始まる.NET形式のプロジェクトファイル(ドキュメントではSDKスタイルあるいは.NET Core形式と記載されている)と、もう一つは<Project ToolsVersion="...">
で始まる.NET Framework形式の2種類が存在します。
.NET Framework形式では多くの指定値を明示的に記述する必要があるため必要最低限でも記述量が多くなる一方、.NET形式ではよく使われる指定値はデフォルト値として定義されているため、比較すると記述量が少なく大幅に簡略化されています。
.NET形式および.NET Framework形式のプロジェクトファイルは、どちらもビルドエンジンMSBuildによって解析・処理・実行されるファイル形式であるMSBuildプロジェクトファイルをベースとする形式です。 そのため、初期値や定義済みの設定(プロパティやアイテム)、MSBuildのバージョンごとにサポートされる機能の違いを除けば、基本的な構造・動作・機能はどちらも共通しています。
MSBuildプロジェクトファイルは、単に設定値に基づくビルドを行うだけでなく、ビルド前後に設定値に基づく何らかの追加処理を行う、逆に何らかの処理の結果に基づいて設定値の決定などを行うことができます。 そのため、MSBuildプロジェクトファイルは単に設定値を羅列した設定ファイルではなく、データ定義とデータ処理の両方を行うことができるビルドスクリプトとして動作します。
またMSBuildプロジェクトファイルは、何らかの成果物の生成(コンパイル)を目的としたビルドスクリプトとしてだけでなく、外部コマンドの実行と結果の取得を組み合わせて定形処理を行うバッチファイルとして用いることもできます。 このためMSBuildプロジェクトファイルは、XML形式で記述される一種のプログラミング言語・スクリプト言語と見ることもできます。
.NET Framework形式のプロジェクトファイルに対するコマンドラインでのビルド・実行はmsbuild
コマンドを用いることができますが、.NET形式では主にdotnet
コマンドを用います。 dotnet
コマンドではプロジェクトファイルに対するビルド・実行だけでなく、他のプロジェクトやパッケージの参照など、プロジェクトファイルに対するよく使われる変更操作も一部サポートされています。
ここでは.NET形式および.NET Framework形式のプロジェクトファイルの概念や構造・機能など、基本的な部分について解説します。 以下で解説する事項はMSBuildプロジェクトファイルの仕様に基づくものであるため、.NET形式・.NET Framework形式のどちらにも共通する事項となっていますが、例として使用している一部の定義済みプロパティ・定義済みアイテムは.NET形式でのみ使用できるものとなっている場合がある点に注意してください。
プロジェクトファイルの作成・実行
.NET形式のプロジェクトファイルを作成する場合は、dotnet new
コマンドを使用することができます。 このコマンドでは、プロジェクトファイル(*.csproj
/*.vbproj
)のほか、テンプレート生成されるソースコードファイルなど、プロジェクトのファイル一式が作成されます。
このほか、Visual StudioなどのIDEで新規プロジェクトを作成することにより、.NET形式・.NET Framework形式のプロジェクトファイルを作成することができます。
クラスライブラリのプロジェクトを作成する方法・クラスライブラリを使用するプロジェクトの作成についてはクラスライブラリの作成 §.コマンドラインでの作成手順を参照してください。
作成したプロジェクトをビルドし、生成された実行可能ファイルを実行するには、IDE上のビルドメニュー・実行メニューを実行するか、次のコマンドで実行することができます。
.NET形式のプロジェクトファイルではdotnet build
あるいはdotnet run
コマンドを使ってビルド・実行することができます。 .NET Framework形式のプロジェクトファイルではmsbuild
コマンドを使ってビルド・実行します。
特にオプションで指定しない場合、デフォルトでは通常Debug構成でビルド・実行されます。 構成については§.ビルド構成 (Configurationプロパティ)を参照してください。
最小限のMSBuildプロジェクトファイル (Hello, world!)
ソースコードのコンパイルやビルド成果物の生成を一切行わない、実行可能な最小限のMSBuildプロジェクトファイルは次のような内容になります。 MSBuildプロジェクトファイルの拡張子は任意で、ここでは*.msbuild.xml
としています。
このプロジェクトをビルドするには次のようにします。 ビルドするといっても、このプロジェクトではコンパイル対象ファイルやコンパイラ呼び出し等を一切定義していないため、ビルド成果物は何ら生成されず、単にメッセージが出力されるのみとなります。
プロジェクトファイルの基本構造 (<Project>
)
プロジェクトファイルは、<Project>
要素をルート要素とするXML文書として記述します。 (Project 要素 (MSBuild) - Visual Studio | Microsoft Docs)
MSBuildで処理されるプロジェクトファイルでは、XML宣言(<?xml ... ?>
)は省略可能です。 また、XML名前空間(xmlns
)の指定も省略することができますが、Project
要素のXML名前空間はhttp://schemas.microsoft.com/developer/msbuild/2003
と定められているため、明示的に指定する場合はこれを指定します。
<Project>
要素は、ビルドに関する設定を記述するプロパティ(PropertyGroup)や、ビルド時に参照されるパッケージや他のプロジェクトファイル、その他の外部ファイルなどの選択を記述するアイテム(ItemGroup)などから構成されます。 設定だけでなく、何らかの処理を定義するターゲット(Target)を記述することもできます。
.NET形式のプロジェクトでは、<Project>
要素のSdk
属性に使用するSDK(Software Development Kit)を選択します。 SDKを選択することにより、ビルドや実行などの既定の動作やコンパイラ等のツールのパス、その他各種設定のデフォルト値などがインポートされます。
コンソールアプリケーション等ではSdk属性
にMicrosoft.NET.Sdk
を指定します。 .NET 5より前ではWindows Formsを使用する場合はMicrosoft.NET.Sdk.WindowsDesktop
を指定する必要がありましたが、.NET 5以降ではMicrosoft.NET.Sdk
となり、単にプロパティUseWindowsForms
を指定するだけで使用できるようになっています。
プロパティ (<PropertyGroup>
)
ビルドに関する設定は、プロパティとして定義します。 プロパティは変数のように名前付きで扱うことができる値、あるいは名前と値のペア(name-value pair)を構成するものです。 プロパティは<PropertyGroup>
要素の子要素として定義し、子要素の名前がプロパティ名となります。 (MSBuild プロパティ - Visual Studio | Microsoft Docs)
プロパティに設定されている値は、$(プロパティ名)
とすることで参照・展開することができます。 未定義のプロパティの場合でもヌル参照とはならず、単に空の文字列として展開されます。 同じ名前のプロパティを再定義することで、プロパティの値を変更することができます。
コンパイラに渡すパラメータなどの設定値や実行時のパスなど、予約済みプロパティとして定められているものがあります。 また予約済みプロパティは既定値が設定されている場合もあります。 そういったプロパティについては§.予約済み・定義済みのプロパティとアイテムを参照してください。 これらのプロパティと一致しない名前である限り、独自にプロパティを定義して任意に値を設定することもできます。
また、条件(Condition属性)を指定することにより、特定の条件の場合のみプロパティを定義する、あるいは条件ごとにプロパティで定義される値を変えるといったことができます。
コマンドラインでのプロパティの定義 (-p
,-property
)
msbuild
およびdotnet build
コマンドでは、プロパティをコマンドライン引数で指定することができます。 コマンドライン引数で指定した場合、新たにプロパティを定義できるほか、プロジェクトファイルで定義されているプロパティを上書きすることもできます。 コマンドライン引数はオプション-p
/-property
を使用し、プロパティをname=value
の形式で指定します。
dotnet
コマンドでは-c
/--configuration
(ビルド構成(Configuration))、-f
/--framework
ターゲットフレームワーク(TargetFramework)など、特定のプロパティに対応する専用のコマンドラインオプションが個別に用意されているものもあるため、これを用いることもできます。
コマンドライン引数で複数のコンパイラ定数などを指定する場合、バージョンによっては区切り文字の;
, ,
が正しく解釈されない場合があるようです。 この場合、URLエンコードして%3B
, %2C
にエスケープします。 詳細は§.コンパイラ定数 (<DefineConstants>)を参照してください。
環境プロパティ(環境変数に基づくプロパティ)
プロジェクトファイルが読み込まれる際、環境変数は自動的にプロパティとして定義されます(環境プロパティ)。 このため、例えば環境変数LANG
は、プロジェクトファイルではプロパティ$(Lang)
として参照・値を展開することができます。 プロパティとして参照する場合、環境変数名とプロパティ名の大文字小文字の違いは無視されるようです。
プロジェクトファイルで環境変数と同じ名前のプロパティが定義されている場合(プロジェクトファイルで環境プロパティが再定義される場合)、その値はプロジェクトファイルでの定義で上書きされます。 つまり、プロパティは「環境変数 < プロジェクトファイル < コマンドライン引数」の優先順位で値が上書きされます。
環境変数が指定されていない場合、環境プロパティは単に空の文字列として展開されるため、Condition属性を使用して環境変数が指定されていない場合はデフォルト値で上書きするようにすることができます。
アイテム (<ItemGroup>
)
ビルド時に参照されるパッケージや他のプロジェクトファイル、成果物や出力ディレクトリに含める外部ファイルなどは、アイテムとして定義します。 アイテムは<ItemGroup>
要素の子要素として定義し、子要素の名前がアイテム名となります。 MSBuildのドキュメントでは、アイテムではなく項目と訳されているようです。 (MSBuild 項目 - Visual Studio | Microsoft Docs)
プロパティとアイテムは、どちらも名前が与えられた値、ある種の変数のようなものという点は同じです。 一方、プロパティでは何らかの値(スカラ値)を定義するのに対し、アイテムは何らかの複数の値(ベクタ値)あるいは値のリストを定義します。 また、プロパティでは要素のテキストで値を定義するのに対し、アイテムではアイテムとして含める対象を属性で選択します。
アイテムに含める対象を選択するにはInclude
属性を使用します。 Include
属性とともにExclude
属性を指定することで、選択の際に除外する対象を指定することもできます。 条件(Condition属性)を指定することにより、特定の条件の場合のみアイテムを定義する、あるいはアイテムに含めるといったことができます。
プロパティに設定されている値は、@(アイテム名)
とすることで参照・展開することができます。 また、@(アイテム名, '区切り文字')
とすることで任意の区切り文字で連結した状態で展開することもできます。 未定義のアイテムの場合でもヌル参照とはならず、単に空のリストあるいは空の文字列として展開されます。
プロパティと同様、コンパイル対象のファイルを表すアイテムなどは予約済みアイテムとして定められているものがあります。 そういったアイテムについては§.予約済み・定義済みのプロパティとアイテムを参照してください。 これらのアイテムと一致しない名前である限り、独自にアイテムを定義して任意に値を設定することもできます。
アイテムはリストであるため通常複数個の値が設定されますが、アイテム名は複数形ではなく単数形とすることがほとんどのようです。
条件分岐
条件 (@Condition
)
プロパティやアイテムの定義、ターゲットやタスクの実行では、Condition
属性を指定することにより条件付きでの定義・実行とすることができます。 例えば、ビルド構成がDebugの場合のみビルド対象とするファイルを定義したり、特定のプラットフォーム向けのビルドでのみ必要となるパッケージ参照を追加したりする場合には、Condition
属性でその条件を指定します。
Condition属性で指定する条件式では、プロパティの値を参照することができます。 条件式では、演算子として==
, !=
, And
, Or
, !
(否定)などを使用することができ、また文字列比較や文字列加工のメソッド(StartsWith
やTrim
)などを用いることもできます。 (詳細:MSBuild の条件 - Visual Studio | Microsoft Docs)
Condition属性はPropertyGroup要素・ItemGroup要素自体にも指定することができます。
また、文字列クラスのメソッドだけでなく、Regex.IsMatchメソッドなどの静的メソッドを使用することもできるため、プロパティの値が正規表現にマッチするかどうかを条件とすることもできます。
上記の例の場合、TargetFrameworkからTargetFrameworkIdentifierを取得する目的にMSBuildの関数GetTargetFrameworkIdentifier
を使うことができるため、次のように簡略化することができます。
その他使用できる静的メソッドや、MSBuild固有の関数として定義されているものはプロパティ関数 - Visual Studio | Microsoft Docsにて一覧として挙げられています。
Condition属性を指定する以外に、Choose要素を用いることで構造化された条件分岐を行うこともできます。
条件構造 (<Choose>
+<When>
/<Otherwise>
)
Condition属性は、いわばPerlやRuby等における後置if(run() if condition;
)のようなものです。 条件付きとしたい要素が多い場合、そのすべてにCondition属性を指定する必要があり、記述が煩雑化しやすくなります。 複数のCondition属性で指定する条件が共通する場合は、Choose
要素を使うことで条件分岐の記述を構造化・簡略化できます。 (MSBuild の条件構造 - Visual Studio | Microsoft Docs)
Choose
要素は、if文あるいはswitch文のように条件に基づいて分岐させることができる要素です。 Choose
要素は、それ自体には条件を記述せず、if/else ifに相当するWhen
要素、elseに相当するOtherwise
要素を包摂する要素となります。 When
要素はChoose
要素の子要素として1個以上記述することができ、それぞれのWhen
要素に条件となるCondition
属性を指定します。 When
要素のどの条件にも一致しない場合の分岐先として、Otherwise
要素を記述することもできます。
When
・Otherwise
要素内でさらにChoose
要素を記述して条件分岐を入れ子にすることができる一方、それ以外ではPropertyGroup要素またはItemGroup要素のみがChoose
要素の子要素となることができます。 つまり、Choose
要素内ではプロパティとアイテムの定義のみを条件分岐できます。 Condition属性とは異なり、ターゲットやタスクの実行分岐のためにChoose
要素を使用することはできません。
Choose
要素でターゲットやタスクの実行分岐を行いたい場合は、条件に一致した場合に何らかの独自のプロパティを定義しておき、実行箇所においてCondition属性でそのプロパティをチェックするなどします。
ターゲット(<Target>
)・タスク(<Task>
)
ターゲット(target)とは、ビルドを行う(Build
)、以前のビルド成果物を削除する(Clean
)、ビルドした成果物を実行する(Run
)など、プロジェクトに対する何らかの動作を定義するものです。
より具体的には、ターゲットはコンパイラ呼び出しやコマンドの実行、ファイルのコピーや削除など、タスク(task)と呼ばれる一連の処理をひとまとめにして構成したものです。 dotnet build
ではBuild
タスク、dotnet run
コマンドではRun
タスクが実行されるなど、一つのプロジェクトファイルに対して複数の動作を実行できるのは、一連の処理がターゲットとして定義されているためです。 (MSBuild ターゲット - Visual Studio | Microsoft Docs, MSBuild タスク - Visual Studio | Microsoft Docs)
ターゲットは他のターゲットとの依存性(dependency)を定義することができ、例えばRun
する際は先にBuild
して成果物を生成する、といったように、あるターゲットを実行する際の前提として必要となる別のターゲットを自動的に実行させることができます。
Build
などの定義済みのターゲットのほか、<Target>
要素を使って独自にターゲットを定義することができます。 独自にターゲットを定義する場合、BeforeTargets
属性やAfterTargets
属性でBuild
などの他のターゲットを指定することで、そのターゲットの前後に実行するよう指定することができます。 これを利用して、例えばビルド前後に独自の処理を追加する、といったことができます。 このほか、ルート要素<Project>
のInitialTargets
属性でターゲットを指定すれば、毎回最初に行うべき処理を行うように定義することもできます。 これらの属性で複数のターゲットを指定する場合、Target1;Target2;Target3...
のようにターゲット名を;
で区切って指定します。
タスクには、任意の実行可能ファイルやコマンドを実行するExecタスクや、メッセージ・警告・エラーを出力するMessage/Warning/Errorタスクなどがあります。 CallTarget
タスクを用いることで、任意のターゲットをタスクとして呼び出すこともできます。
ターゲットおよびタスクには、実行の条件をCondition属性で指定することもできます。
タスクによっては出力パラメータが定義されているものがあります。 タスクをメソッドと見た場合、タスクの出力パラメータはout
引数やreturn
によるメソッドの戻り値に相当するものです。
タスクの出力パラメータは<Output>要素で取得することができ、この要素で指定したプロパティにタスクの処理結果を格納させることができます。 通常は省略可能となっているため、タスクの実行だけ行い、出力パラメータは無視して破棄することもできます。 出力パラメータを使った具体例は§.Execタスク(コマンドの実行)を参照してください。
定義済みのタスクは複数用意されているほか、Taskクラスから派生して独自にタスクを定義することもできます。
Message/Warning/Errorタスク(メッセージの出力)
プロジェクトファイルを直接編集する際、プロパティやアイテムとして設定されている内容を確認する目的に使えるのがMessageタスクです。 これはConsole.WriteLine
のように実行中のログを出力するためのタスクです。
MessageタスクではText
属性で出力する文字列を指定します。 単に文字列を指定できるほか、$(プロパティ名)
あるいは@(アイテム名)
とすることでプロパティおよびアイテムに設定されている値を展開して表示することもできます。
Importance
属性で出力の重要度を指定します。 重要度にはhigh
/normal
/low
のいずれかを指定することができ、省略した場合はnormal
として出力します。 dotnet run
コマンドを実行した場合のビルド時出力などは重要度normal
でも出力されなくなるため、常に出力させたいような場合は重要度をhigh
にします。
WarningタスクおよびErrorタスクを使うことでもログを出力することができ、これらのタスクを使った場合は警告あるいはエラーとしてメッセージを出力することができます。 これらのタスクで出力した警告・エラーは、コンパイル時の警告・エラーと同様に計上された上で結果が表示されます。
Execタスク(コマンドの実行)
Execタスクを用いることにより、任意の実行ファイルを実行することができます。 Execタスクを用いることで、外部のバッチファイルやシェルスクリプトとして記述したものを実行する、あるいは何らかのコマンドを直接実行することにより、独自の処理や外部ツールを実行させることができます。
定義済みのタスクを含むすべてのタスクは、Taskクラスの派生クラスとして実装されているため、独自のタスクを定義したい場合にはこのクラスを派生して実装することになりますが、Execタスクを使えば既存のコマンドやスクリプトをそのまま使って処理を行うことができます。
Execタスクでは、Command
属性で実行するコマンドライン、あるいはバッチファイル・シェルスクリプトなどの実行可能ファイルを指定します。 コマンドラインにダブルクオーテーション"
を含む場合は実体参照"
に置き換えます。
Execタスクでは、EnvironmentVariables
属性で環境変数を、WorkingDirectory
で作業ディレクトリ(コマンドを実行する際のデフォルトディレクトリ)を指定することができます。
また、Execタスクでコマンドの出力(標準出力・標準エラー)をキャプチャする場合は、ConsoleToMSBuild
属性にtrue
を指定し、Execタスクの出力パラメータConsoleOutput
を取得するようにします。 また、コマンドの終了コードは、Execタスクの出力パラメータExitCode
から取得できます。
タスクの出力パラメータは<Exec>
要素の子要素<Output>
で取得することができ、TaskParameter
属性で取得したい出力パラメータの名前、PropertyName
属性で出力パラメータの内容を格納するプロパティの名前を指定します。 コマンドの出力を取得したい場合はTaskParameter
にConsoleOutput
を、終了コードを取得したい場合はExitCode
を指定します。
作業ディレクトリやコマンドに指定するパスを構築する際に必要となるプロジェクトファイルのパスやターゲット実行時のパスなど、パスに関する定義済みプロパティについては§.ディレクトリとパスに関する予約済みプロパティを参照してください。
ビルド構成 (Configurationプロパティ)
ビルド構成(build configuration)、あるいは単に構成とは、一連のビルド時の設定やオプション、出力先ディレクトリなどのプロパティをひとまとめにしてグループ化する概念です。
ビルド構成はMSBuildの概念ではなく、単にConfigurationプロパティとして定義される値(Debug
やRelease
など)と、その値をもとに条件付きで定義される一連のプロパティ・アイテムの総称です。 しかし、.NET形式・.NET Framework形式のプロジェクトファイルでは、ビルド設定をグループ化し、また容易にそれを切り替えられるようにするための概念として使用されています。
.NET形式のプロジェクトファイルではDebug
とRelease
の二種類の構成がデフォルトで定義され、IDE等で作成した.NET Framework形式のプロジェクトファイルでもこの二種類の構成が自動的に生成されます。 これらの構成はDebug構成・Release構成のように呼ばれ、またその構成を使ったビルドとビルド成果物はDebugビルド・Releaseビルドのように呼ばれます。
Debug構成とRelease構成の主な違いとして、デフォルト設定のDebugビルドではビルド成果物としてデバッグ情報(.pdbファイル)等が出力される一方、Releaseビルドでは出力されなくなります。 また、ビルド成果物は構成によって個別の出力ディレクトリ(bin\Debug\
またはbin\Release\
)に分けて出力されます。
dotnet
コマンドでは、構成を指定してビルド・実行するための専用のオプションが用意されています。 構成を指定してビルド・実行するにはdotnet build -c [Debug|Release]
のように-c
/--configuration
オプションで使用する構成を指定します。
DebugとRelease以外のビルド構成を独自に定義することもできます。 例として、エミュレータ向けビルドと実機向けビルド、機能制限ビルドとフル構成ビルドなど、任意に構成を定義することができます。 Visual Studioに存在する構成マネージャのように、IDE上で構成を定義することもできます。
ビルド構成に従ってコンパイラに渡すコンパイラ定数を変えたいような場合は、上記の例のようにDefineConstantsプロパティを指定します。
予約済み・定義済みのプロパティとアイテム
MSBuildでは、パスなどの実行時情報やランタイム情報などの値を参照するためのプロパティが用意されています。 また、.NET形式・.NET Framework形式のプロジェクトファイルでは、プロジェクト設定のプロパティ名・ソースファイルや参照パッケージのアイテム名など、名前があらかじめ定められているもの、あるいは既定値が設定済みで定義されているプロパティ・アイテムが存在します。
予約済みのプロパティ・アイテムは、名前と値が設定され、かつ値の再設定(上書き・オーバーライド)ができない参照専用のプロパティ・アイテムです。 対して定義済み(既知)のプロパティ・アイテムは、必要に応じて値を再設定することができるプロパティ・アイテムです。
MSBuildプロジェクト共通のプロパティ
ここではMSBuildプロジェクトに共通するプロパティについて解説します。
ディレクトリとパスに関する予約済みプロパティ
以下はディレクトリとパスに関するプロパティの抜粋です。 これらのプロパティは予約済みであるため、設定されている値を変更・上書きすることはできません。
プロパティ名 | 意味 | 値の例 |
MSBuildStartupDirectory | ビルドを開始したときのカレントディレクトリ あるいはMSbuildコマンドを実行したときのディレクトリ このプロパティは終端のディレクトリ区切り記号を含まない |
C:\Users\user
|
---|---|---|
MSBuildThisFileで始まるプロパティ |
現在のプロジェクトファイルのパス このプロパティを参照しているプロジェクトファイル自身のパスを表す |
(以下はプロジェクトファイルのフルパスがC:\Users\user\app\project.csproj の場合の例) |
MSBuildThisFileFullPath | 同上、フルパス |
C:\Users\user\app\project.csproj
|
MSBuildThisFileDirectory | 同上、ディレクトリ部分のみ このプロパティは終端のディレクトリ区切り記号を含む |
C:\Users\user\app\
|
MSBuildThisFile | 同上、ファイル名のみ |
project.csproj
|
MSBuildThisFileName | 同上、拡張子を除いたファイル名のみ |
project
|
MSBuildThisFileExtension | 同上、ファイル名の拡張子のみ |
.csproj
|
MSBuildProjectで始まるプロパティ |
ビルドを開始したプロジェクトファイルのパス エントリポイントとして読み込まれたプロジェクトのパスはMSBuildProject*、そこから読み込まれたサブプロジェクトなどのパスはMSBuildThisFile*でそれぞれ取得できる |
(以下はプロジェクトファイルのフルパスがC:\Users\user\app\project.csproj の場合の例) |
MSBuildProjectFullPath | 同上、フルパスのみ |
C:\Users\user\app\project.csproj
|
MSBuildProjectDirectory | 同上、ディレクトリ部分のみ このプロパティは終端のディレクトリ区切り記号を含まない |
C:\Users\user\app
|
MSBuildProjectFile | 同上、ファイル名のみ |
project.csproj
|
MSBuildProjectName | 同上、拡張子を除いたファイル名のみ |
project
|
MSBuildProjectExtension | 同上、ファイル名の拡張子のみ |
.csproj
|
プロパティ名 | 意味 | 値の例 |
実行環境情報に関する予約済みプロパティ
以下は実行環境の情報にプロパティの抜粋です。 これらのプロパティは予約済みであるため、設定されている値を変更・上書きすることはできません。
プロパティ名 | 意味 | 値の例 |
MSBuildRuntimeType | 現在MSBuildを実行しているランタイムの種類を表す文字列 |
Core :.NET Core/.NET 5以降Full :4.8までの.NET FrameworkMono : Mono |
---|---|---|
MSBuildBinPath | 現在実行しているMSBuildの実行可能ファイルのパス | |
MSBuildVersion | 現在実行しているMSBuildのバージョン | |
MSBuildToolsPath | 現在実行しているMSBuildを含むツール一式のインストールパス | |
MSBuildToolsVersion | 現在実行しているMSBuildを含むツール一式のバージョン | |
プロパティ名 | 意味 | 値の例 |
プロジェクト設定のプロパティとアイテム
ここでは.NET形式・.NET Framework形式のプロジェクトファイルで使用される、プロジェクト設定に関するプロパティとアイテムについて解説します。 コンパイラに指定するパラメータや入力ファイルは、プロジェクト設定としてプロパティとアイテムで指定することができます。
ビルド対象のファイル
ビルド対象のファイル、また対象から除外するファイルの指定は以下のアイテムで指定します。 IDE上では、ビルドアクションでファイルがどのアイテムに該当するかを指定することができます。
アイテム | 意味・目的 | 既定の属性値(.NET形式のプロジェクトファイル) | ||
---|---|---|---|---|
Include | Exclude | Remove | ||
<Compile>
|
コンパイル対象となるソースファイル(*.csや*.vb)を指定する |
**/*.cs (csprojの場合)**/*.vb (vbprojの場合) |
**/*.user
**/*.*proj
**/*.sln
**/*.vssscc
|
- |
<EmbeddedResource>
|
アセンブリにリソースとして埋め込むファイルを指定する |
**/*.resx
|
- | |
<None>
|
ビルド処理の対象外とするファイルを指定する |
**/*
|
**/*.cs
**/*.vb
**/*.resx
|
|
<Content>
|
ビルド成果物として出力ディレクトリにコピーするファイルを指定する | - | - | - |
対象として含めるファイルの指定にはInclude
などの属性を使用します。 これらの属性では、ワイルドカードとして?
, *
, **
を使用することができ、複数のディレクトリ・ファイルを指定することができます。
.NET形式のプロジェクトファイルでは、各アイテムには既定値での属性Include
・Exclude
・Remove
が暗黙的に指定されています。 このため、例えば<Compile>
アイテムでは、プロジェクトファイルのあるディレクトリを基点としたディレクトリツリー内のソースファイルが自動的に含められます。 明示的にアイテムに含めるファイルを指定したい場合は、EnableDefaultItemsなどのプロパティにfalse
を指定します。
コンパイル対象のソースファイル (<Compile>
)
コンパイル対象のソースファイルはCompile
アイテムに含めます。 .NET形式のプロジェクトファイルでは、プロジェクトファイルのあるディレクトリを基点としたディレクトリツリー内のソースファイルが自動的に含められます。
そのためCompile
アイテムは、主にプロジェクトのディレクトリツリー外にあるソースファイルをコンパイル対象に含めたいような場合、ディレクトリツリー内にあるが構成によって除外したいファイルがある場合などに指定します。
明示的なアイテムの選択 (<EnableDefaultItems>
)
.NET形式のプロジェクトファイルでは、Compile
などのアイテムには暗黙的なInclude属性が指定されているため、明示的に指定しなくても自動的にファイルが選択されます。
一方、例えばCompile
アイテムでは、ディレクトリツリー内にコンパイル対象ではないソースファイルが配置されている場合など、暗黙的(自動的)な選択では不都合が起こる状況もあり得ます。 こういった場合は、EnableDefaultCompileItems
プロパティにfalse
を指定することでCompile
アイテムでの暗黙的な選択を行わないようにすることができます。
EnableDefaultCompileItems
プロパティにfalse
を指定した場合は、コンパイル対象となるファイルすべてを明示的にCompile
アイテムで選択する必要があります。
EnableDefaultCompileItems
プロパティはCompile
アイテムのみに対して適用されます。 他のアイテムに対して適用する場合は、以下のプロパティを指定します。
プロパティ | 対象となるアイテム |
---|---|
EnableDefaultItems
|
以下のすべて |
EnableDefaultCompileItems
|
Compile
|
EnableDefaultEmbeddedResourceItems
|
EmbeddedResource
|
EnableDefaultNoneItems
|
None
|
EnableDefaultContentItems
|
Content
|
ビルド成果物となるファイル (<Content>
)
コンパイル対象ではないものの、ビルド成果物として出力ディレクトリにコピーしたいファイルはContent
アイテムに含めます。 実行可能ファイルの実行時に必須の設定ファイルや構成ファイル(*.config)、LICENSEファイルやREADMEファイルなど、ビルド成果物として出力したいファイルや、パッケージ化する際に同梱したいファイルがある場合にこのアイテムとして指定します。
アセンブリに埋め込まれるリソース (<EmbeddedResource>
)
アセンブリ(*.exeや*.dll)に埋め込まれるリソースとしたいファイルは、EmbeddedResource
アイテムに含めます。
アセンブリのリソースとしてファイルを埋め込みむ方法・読み込んで使用する方法についてはリソースの埋め込みと読み込みで詳しく解説しています。 また、リソースの論理名を指定するLogicalName属性と、同属性を指定しなかった場合のデフォルト動作についてはリソースの埋め込みと読み込み §.埋め込むリソースの論理名を定義するを参照してください。
ビルド処理対象外のファイル (<None>
)
プロジェクトのファイルには含まれるものの、特に処理される必要のないファイルは、None
アイテムに含めます。 このアイテムは、IDE上(例えばVisual Studioのソリューションエクスプローラ)で参照できるようにプロジェクトに含めたいファイルなどがある場合に指定します。 何らかのリファレンス・ドキュメントや、コンパイル対象ではない参照用のソースコードなどをこのアイテムに含めておくことができます。
バージョン情報・アセンブリ情報
アセンブリバージョンなどのバージョン情報、プロジェクトファイルでのアセンブリ情報の定義、AssemblyInfoファイルの自動生成などに関しては、以下を参照してください。
コンパイラ定数 (<DefineConstants>
)
コンパイラ定数を定義するにはDefineConstants
プロパティを使用します。
定義する定数が複数ある場合は、C#プロジェクトファイル(*.csproj)ではセミコロン;
、VBプロジェクトファイル(*.vbproj)ではカンマ,
で区切ります。 また、定数に値を持たせる場合はname=value
の形式で名前と値を指定します。 ただし、C#プロジェクトファイルで定数に値をもたせた場合は警告MSB3052
が発生し、指定は無視され定数が定義されません。
デフォルトではTRACE
が共通して定義され、ビルド構成がReleaseの場合はRELEASE
、DebugではDEBUG
が追加で定義されます。 <DefineConstants>
で定数を定義するとRELEASE
またはDEBUG
のみが自動的に追加されます。
dotnet build
などのコマンドラインでのビルド時に、コマンドライン引数としてビルド構成・コンパイラ定数を指定することもできます。 コマンドライン引数での指定については、§.コマンドラインでのプロパティの定義 (-p,-property)を参照してください。
なお、コマンドライン引数で複数のコンパイラ定数を指定する場合、バージョンによって区切り文字;
および,
はURLエンコードした形式、つまり%3B
および%2C
に置き換える必要があるようです。 例として、dotnet
コマンドでコンパイラ定数を指定してビルド・実行する場合は次のようにします。
.NET形式のプロジェクトファイルで定義されるコンパイラ定数
.NET形式のプロジェクトファイルでは、TargetFrameworkプロパティの値によって次のコンパイラ定数が自動的に追加定義されます。
ターゲットフレームワーク | TargetFrameworkプロパティ | 定義されるコンパイラ定数 | |
---|---|---|---|
各バージョン共通で定義される定数 | バージョン別に定義される定数 | ||
.NET 5〜 |
net5.x 〜 |
NET
NETCOREAPP
|
NET5_0
|
.NET Core 1.0〜3.1 |
netcoreapp1.x 〜netcoreapp3.x |
NETCOREAPP
|
NETCOREAPP3_1 , NETCOREAPP3_0 , NETCOREAPP2_2 , NETCOREAPP2_1 , NETCOREAPP2_0 , NETCOREAPP1_1 , NETCOREAPP1_0 |
.NET Standard 1.0〜2.1 |
netstandard1.x 〜netstandard2.x |
NETSTANDARD
|
NETSTANDARD2_1 , NETSTANDARD2_0 , NETSTANDARD1_6 , NETSTANDARD1_5 , NETSTANDARD1_4 , NETSTANDARD1_3 , NETSTANDARD1_2 , NETSTANDARD1_1 , NETSTANDARD1_0 |
.NET Framework 1.0〜4.8 |
net1x 〜net4xy |
NETFRAMEWORK
|
NET48 , NET472 , NET471 , NET47 , NET462 , NET461 , NET46 , NET452 , NET451 , NET45 , NET40 , NET35 , NET20 |
整数演算でのオーバーフロー・アンダーフローの例外化 (<CheckForOverflowUnderflow>
, <RemoveIntegerChecks>
)
整数演算でのオーバーフロー・アンダーフローをチェックして、それを例外OverflowExceptionとしてスローさせるか、あるいはチェックを抑止してオーバーフロー・アンダーフローを許容するか、その動作を指定するには、CheckForOverflowUnderflow
(C#)/RemoveIntegerChecks
(VB)プロパティを指定します。
C#プロジェクトファイルでは、CheckForOverflowUnderflow
にtrue
を指定するとチェックが有効となり例外がスローされるようになります。 VBプロジェクトファイルでは、RemoveIntegerChecks
にtrue
を指定するとチェックが無効となり例外はスローされなくなります。
このプロパティによる動作の違いについては整数型のオーバーフローとチェックを参照してください。
XMLドキュメントの生成 (<DocumentationFile>
)
ソースコードに記述されたXMLドキュメントコメントからXMLドキュメントを生成するには、DocumentationFile
プロパティにて生成するXMLドキュメントのファイル名を指定します。
具体例についてはXMLドキュメントコメントを用いたドキュメントの作成 §.プロジェクトファイルでの設定を参照してください。
エントリポイントクラスの指定 (<StartupObject>
)
コード中にMainメソッドの定義が複数ある場合に、どのクラスのMainメソッドをエントリポイントとして使用するかを指定するには、StartupObject
プロパティを指定します。
具体例についてはプロセス §.複数のMainメソッド (エントリポイントの指定)を参照してください。
その他
その他のプロパティとアイテムについては以下を参照してください。