WPF アプリケーション (WPF) のビルドBuilding a WPF Application (WPF)

Windows Presentation Foundation (WPF) アプリケーションは、.NET Framework の実行可能ファイル (.exe)、ライブラリ (.dll)、または両方の種類のアセンブリの組み合わせとしてビルドできます。Windows Presentation Foundation (WPF) applications can be built as .NET Framework executables (.exe), libraries (.dll), or a combination of both types of assemblies. このトピックでは、WPFWPF アプリケーションをビルドする方法を紹介し、ビルド プロセスの主な手順について説明します。This topic introduces how to build WPFWPF applications and describes the key steps in the build process.

WPF アプリケーションのビルドBuilding a WPF Application

WPF アプリケーションは、次の方法でコンパイルできます。A WPF application can be compiled in the following ways:

WPF ビルド パイプラインWPF Build Pipeline

WPFWPF プロジェクトがビルドされるときには、言語固有のターゲットと WPFWPF 固有のターゲットの組み合わせが呼び出されます。When a WPFWPF project is built, the combination of language-specific and WPFWPF-specific targets are invoked. これらのターゲットを実行するプロセスはビルド パイプラインと呼ばれます。主要な手順を次の図に示します。The process of executing these targets is called the build pipeline, and the key steps are illustrated by the following figure.

WPF のビルドプロセスWPF build process

ビルド前の初期化Pre-Build Initializations

ビルドする前に、MSBuild は次のような重要なツールとライブラリの場所を決定します。Before building, MSBuild determines the location of important tools and libraries, including the following:

  • .NET Framework。The .NET Framework.

  • Windows SDK ディレクトリ。The Windows SDK directories.

  • WPFWPF 参照アセンブリの場所。The location of WPFWPF reference assemblies.

  • アセンブリ検索パスのプロパティ。The property for the assembly search paths.

MSBuild がアセンブリを検索する最初の場所は、参照アセンブリディレクトリ (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\) です。The first location where MSBuild searches for assemblies is the reference assembly directory (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\). この手順では、ビルド プロセスはさまざまなプロパティと項目グループを初期化し、必要なクリーンアップ作業も実行します。During this step, the build process also initializes the various properties and item groups and performs any required cleanup work.

参照の解決Resolving References

ビルド プロセスは、アプリケーション プロジェクトのビルドに必要なアセンブリを探して、バインドします。The build process locates and binds the assemblies required to build the application project. このロジックは、ResolveAssemblyReference タスクに含まれます。This logic is contained in the ResolveAssemblyReference task. プロジェクト ファイル内で Reference として宣言されたすべてのアセンブリは、検索パスに関する情報と、すでにシステムにインストールされているアセンブリのメタデータと共にタスクに渡されます。All assemblies declared as Reference in the project file are provided to the task along with information on the search paths and metadata on assemblies already installed on the system. タスクは、アセンブリを検索し、インストールされているアセンブリのメタデータを使用して、出力マニフェストに含める必要のないコアの WPFWPF アセンブリをフィルターして除外します。The task looks up assemblies and uses the installed assembly's metadata to filter out those core WPFWPF assemblies that need not show up in the output manifests. これは、ClickOnce マニフェストに冗長な情報が含まれるのを避けるために行われます。This is done to avoid redundant information in the ClickOnce manifests. たとえば、プレゼンテーションフレームワーク .dll は、に組み込まれているアプリケーションの代表者として、WPFWPF と、さらに、.NET Framework がインストールされているすべてのコンピューター上のすべての WPFWPF アセンブリが存在するため、マニフェスト内のすべての .NET Framework 参照アセンブリに関する情報をすべて含める必要はありません。For example, since PresentationFramework.dll can be considered representative of an application built on and for the WPFWPF and moreover since all WPFWPF assemblies exist at the same location on every machine that has the .NET Framework installed, there is no need to include all information on all .NET Framework reference assemblies in the manifests.

マークアップ コンパイル - パス 1Markup Compilation—Pass 1

この手順では、XAMLXAML ファイルを解析してコンパイルし、ランタイムが XML の解析とプロパティ値の検証に時間を費やすことがないようにします。In this step, XAMLXAML files are parsed and compiled so that the runtime does not spend time parsing XML and validating property values. コンパイルされた XAMLXAML ファイルを事前にトークン化するため、実行時の読み込みは、XAMLXAML ファイルを読み込むよりもはるかに短時間で終わります。The compiled XAMLXAML file is pre-tokenized so that, at run time, loading it should be much faster than loading a XAMLXAML file.

この手順では、Page ビルド項目である XAMLXAML ファイルごとに、次のアクティビティが実行されます。During this step, the following activities take place for every XAMLXAML file that is a Page build item:

  1. XAMLXAML ファイルがマークアップ コンパイラによって解析されます。The XAMLXAML file is parsed by the markup compiler.

  2. XAMLXAML 用にコンパイル済みの表現が作成されて、obj\Release フォルダーにコピーされます。A compiled representation is created for that XAMLXAML and copied to the obj\Release folder.

  3. 新しい部分クラスの CodeDOM 表現が作成され、obj\Release フォルダーにコピーされます。A CodeDOM representation of a new partial class is created and copied to the obj\Release folder.

さらに、XAMLXAML ファイルごとに、言語固有のコード ファイルが生成されます。In addition, a language-specific code file is generated for every XAMLXAML file. たとえば、Visual Basic プロジェクトの Page1 ページの場合は、Page1 が生成されます。C#プロジェクトの Page1 ページの場合、Page1.g.cs が生成されます。For example, for a Page1.xaml page in a Visual Basic project, a Page1.g.vb is generated; for a Page1.xaml page in a C# project, a Page1.g.cs is generated. ファイル名の ".g" は、ファイルが生成されたコードであり、マークアップ ファイルのトップレベルの要素 (PageWindow など) に対する部分クラス宣言を持つことを示しています。The ".g" in the file name indicates the file is generated code that has a partial class declaration for the top-level element of the markup file (such as Page or Window). クラスは、(Visual Basic でExtends) のC# partial 修飾子を使用して宣言し、他の場所 (通常は分離コードファイル Page1.xaml.cs) に別の宣言があることを示します。The class is declared with the partial modifier in C# (Extends in Visual Basic) to indicate there is another declaration for the class elsewhere, usually in the code-behind file Page1.xaml.cs.

部分クラスは、適切な基本クラス (ページの Page など) から拡張され、System.Windows.Markup.IComponentConnector インターフェイスを実装します。The partial class extends from the appropriate base class (such as Page for a page) and implements the System.Windows.Markup.IComponentConnector interface. IComponentConnector インターフェイスには、コンポーネントを初期化し、そのコンテンツ内の要素の名前とイベントを接続するメソッドがあります。The IComponentConnector interface has methods to initialize a component and connect names and events on elements in its content. その結果、生成されたコード ファイルには、次のようなメソッドの実装が含まれます。Consequently, the generated code file has a method implementation like the following:

public void InitializeComponent() {
    if (_contentLoaded) {
        return;
    }
    _contentLoaded = true;
    System.Uri resourceLocater =
        new System.Uri(
            "window1.xaml",
            System.UriKind.RelativeOrAbsolute);
    System.Windows.Application.LoadComponent(this, resourceLocater);
}
Public Sub InitializeComponent() _

    If _contentLoaded Then
        Return
    End If

    _contentLoaded = True
    Dim resourceLocater As System.Uri = _
        New System.Uri("mainwindow.xaml", System.UriKind.Relative)

    System.Windows.Application.LoadComponent(Me, resourceLocater)

End Sub

既定では、マークアップコンパイルは MSBuild エンジンと同じ AppDomain で実行されます。By default, markup compilation runs in the same AppDomain as the MSBuild engine. これにより、パフォーマンスが大幅に向上します。This provides significant performance gains. この動作は、AlwaysCompileMarkupFilesInSeparateDomain プロパティで切り替えることができます。This behavior can be toggled with the AlwaysCompileMarkupFilesInSeparateDomain property. これには、個別の AppDomainをアンロードすることによって、すべての参照アセンブリをアンロードするという利点があります。This has the advantage of unloading all reference assemblies by unloading the separate AppDomain.

マークアップ コンパイル - パス 2Markup Compilation—Pass 2

マークアップ コンパイルのパス 1 ですべての XAMLXAML ページがコンパイルされるわけではありません。Not all XAMLXAML pages are compiled at during pass 1 of markup compilation. ローカルで定義された型参照 (同じプロジェクト内の他のコードで定義された型の参照) を含む XAMLXAML ファイルは、この時点ではコンパイルから除外されます。XAMLXAML files that have locally defined type references (references to types defined in code elsewhere in the same project) are exempt from compilation at this time. これは、ローカルで定義された型は、ソース内にのみ存在し、まだコンパイルされていないためです。This is because those locally defined types exist only in source and have not yet been compiled. これを判別するために、パーサーは、マークアップ ファイル内で x:Name などの項目を検索するヒューリスティックを使用します。In order to determine this, the parser uses heuristics that involve looking for items such as x:Name in the markup file. このようなインスタンスが見つかると、そのマークアップ ファイルのコンパイルは、コード ファイルがコンパイルされるまで延期され、その後、2 階目のマークアップ コンパイル パスで、これらのファイルが処理されます。When such an instance is found, that markup file’s compilation is postponed until the code files have been compiled, after which, the second markup compilation pass processes these files.

ファイルの分類File Classification

ビルド プロセスは、配置されるアプリケーション アセンブリに基づいて、出力ファイルを異なるリソース グループに分けます。The build process puts output files into different resource groups based on which application assembly they will be placed in. 一般的なローカライズされないアプリケーションでは、Resource としてマークされたすべてのデータ ファイルは、メイン アセンブリ (実行可能ファイルまたはライブラリ) に配置されます。In a typical nonlocalized application, all data files marked as Resource are placed in the main assembly (executable or library). プロジェクトで UICulture が設定されると、コンパイル済みのすべての XAMLXAML ファイルと、言語固有として明示的にマークされたリソースは、サテライト リソース アセンブリに配置されます。When UICulture is set in the project, all compiled XAMLXAML files and those resources specifically marked as language-specific are placed in the satellite resource assembly. さらに、言語に依存しないすべてのリソースは、メイン アセンブリに配置されます。Furthermore, all language-neutral resources are placed in the main assembly. ビルド プロセスのこの手順で、この決定が行われます。In this step of the build process, that determination is made.

プロジェクト ファイル内の ApplicationDefinitionPage、および Resource ビルト アクションは、Localizable メタデータで拡張でき (受け入れられる値は truefalse)、これによって、ファイルが言語固有か、言語に依存しないかを指定します。The ApplicationDefinition, Page, and Resource build actions in the project file can be augmented with the Localizable metadata (acceptable values are true and false), which dictates whether the file is language-specific or language-neutral.

コア コンパイルCore Compilation

コア コンパイル手順では、コード ファイルのコンパイルが行われます。The core compile step involves compilation of code files. これは Microsoft.CSharp.targets や Microsoft.VisualBasic.targets など、言語固有のターゲット ファイル内のロジックによって調整されます。This is orchestrated by logic in the language-specific targets files Microsoft.CSharp.targets and Microsoft.VisualBasic.targets. ヒューリスティックによってマークアップ コンパイラの 1 回のパスでは不十分であると判断されると、メイン アセンブリが生成されます。If heuristics have determined that a single pass of the markup compiler is sufficient, then the main assembly is generated. ただし、プロジェクト内の 1 つ以上の XAMLXAML ファイルにローカルで定義された型の参照が含まれている場合、一時的な .dll ファイルが生成され、これによってマークアップ コンパイルの 2 回目のパスが完了すると、最終的なアプリケーション アセンブリが作成されます。However, if one or more XAMLXAML files in the project have references to locally defined types, then a temporary .dll file is generated so the final application assemblies may be created after the second pass of markup compilation is complete.

マニフェストの生成Manifest Generation

ビルドプロセスの最後に、すべてのアプリケーションアセンブリとコンテンツファイルの準備が整ったら、アプリケーションの ClickOnce マニフェストが生成されます。At the end of the build process, after all the application assemblies and content files are ready, the ClickOnce manifests for the application are generated.

配置マニフェスト ファイルは、配置モデル (現在のバージョン、更新動作、およびパブリッシャーの ID とデジタル署名) を記述します。The deployment manifest file describes the deployment model: the current version, update behavior, and publisher identity along with digital signature. このマニフェストは、配置を処理する管理者が作成します。This manifest is intended to be authored by administrators who handle deployment. ファイル拡張子は、xbap (XAML ブラウザーアプリケーション (Xbap) 用) と、インストールされているアプリケーションのアプリケーションです。The file extension is .xbap (for XAML browser applications (XBAPs)) and .application for installed applications. 前者は HostInBrowser プロジェクト プロパティによって指定されるため、マニフェストはアプリケーションがブラウザーによってホストされることを識別します。The former is dictated by the HostInBrowser project property and as a result the manifest identifies the application as browser-hosted.

アプリケーション マニフェスト (.exe.manifest ファイル) は、アプリケーション アセンブリと依存ライブラリを記述し、アプリケーションに必要なアクセス許可をリストします。The application manifest (an .exe.manifest file) describes the application assemblies and dependent libraries and lists permissions required by the application. このファイルは、アプリケーション開発者が作成します。This file is intended to be authored by the application developer. ClickOnce アプリケーションを起動するために、ユーザーはアプリケーションの配置マニフェストファイルを開きます。In order to launch a ClickOnce application, a user opens the application's deployment manifest file.

これらのマニフェストファイルは、常に Xbap 用に作成されます。These manifest files are always created for XBAPs. インストール型アプリケーションの場合、プロジェクト ファイル内で GenerateManifests プロパティの値が true に指定されない限り、作成されません。For installed applications, they are not created unless the GenerateManifests property is specified in the project file with value true.

Xbap は、一般的なインターネットゾーンのアプリケーションに割り当てられているアクセス許可に対して、WebBrowserPermissionMediaPermissionの2つの追加のアクセス許可を取得します。XBAPs get two additional permissions over and above those permissions assigned to typical Internet zone applications: WebBrowserPermission and MediaPermission. WPFWPF ビルド システムは、これらのアクセス許可をアプリケーション マニフェストで宣言します。The WPFWPF build system declares those permissions in the application manifest.

インクリメンタル ビルドのサポートIncremental Build Support

WPFWPF ビルド システムは、インクリメンタル ビルドをサポートします。The WPFWPF build system provides support for incremental builds. これは、マークアップやコードに加えられた変更を検出し、変更の影響を受けるアイテムだけをコンパイルするという高度な機能です。It is fairly intelligent about detecting changes made to markup or code, and it compiles only those artifacts affected by the change. インクリメンタル ビルド メカニズムは、次のファイルを使用します。The incremental build mechanism uses the following files:

  • $(AssemblyName)_MarkupCompiler.Cache ファイル。コンパイラの現在の状態を保持します。An $(AssemblyName)_MarkupCompiler.Cache file to maintain current compiler state.

  • $(AssemblyName)_MarkupCompiler.lref ファイル。ローカルで定義された型への参照を持つ XAMLXAML ファイルをキャッシュします。An $(AssemblyName)_MarkupCompiler.lref file to cache the XAMLXAML files with references to locally defined types.

インクリメンタル ビルドを制御する規則のセットを次に示します。The following is a set of rules governing incremental build:

  • ビルド システムが変更を検出する最小単位は、ファイルです。The file is the smallest unit at which the build system detects change. そのため、コード ファイルの場合、ビルド システムは、型が変更されたかどうか、またはコードが追加されたかどうかを検出できません。So, for a code file, the build system cannot tell if a type was changed or if code was added. プロジェクト ファイルの場合も同様です。The same holds for project files.

  • インクリメンタル ビルドのメカニズムは、XAMLXAML ページがクラスを定義するのか、他のクラスを使用するのかを認識できなければなりません。The incremental build mechanism must be cognizant that a XAMLXAML page either defines a class or uses other classes.

  • Reference エントリが変更された場合は、すべてのページを再コンパイルします。If Reference entries change, then recompile all pages.

  • コード ファイルが変更された場合は、ローカルで定義された型の参照を含むすべてのページを再コンパイルします。If a code file changes, recompile all pages with locally defined type references.

  • XAMLXAML ファイルが変更された場合:If a XAMLXAML file changes:

    • XAMLXAML がプロジェクトで Page として宣言されている場合: XAMLXAML にローカルで定義された型の参照が含まれていない場合は、その XAMLXAML とローカル参照を含むすべての XAMLXAML ページを再コンパイルします。XAMLXAML にローカル参照が含まれる場合は、ローカル参照が含まれているすべての XAMLXAML ページを再コンパイルします。If XAMLXAML is declared as Page in the project: if the XAMLXAML does not have locally defined type references, recompile that XAMLXAML plus all XAMLXAML pages with local references; if the XAMLXAML has local references, recompile all XAMLXAML pages with local references.

    • XAMLXAML がプロジェクトの ApplicationDefinition として宣言されている場合: すべての XAMLXAML ページを再コンパイルします (理由: 各 XAMLXAML に、変更された可能性のある Application 型への参照が含まれています)。If XAMLXAML is declared as ApplicationDefinition in the project: recompile all XAMLXAML pages (reason: each XAMLXAML has reference to an Application type that may have changed).

  • プロジェクト ファイルがコード ファイルを XAMLXAML ファイルではなくアプリケーション定義として宣言している場合:If the project file declares a code file as application definition instead of a XAMLXAML file:

    • プロジェクト ファイル内の ApplicationClassName 値が変更されたかどうか (新しいアプリケーションの種類があるかどうか) を確認します。Check if the ApplicationClassName value in the project file has changed (is there a new application type?). 変更されていた場合は、アプリケーション全体を再コンパイルします。If so, recompile the entire application.

    • 変更されていなかった場合は、ローカル参照を含んでいるすべての XAMLXAML ページを再コンパイルします。Otherwise, recompile all XAMLXAML pages with local references.

  • プロジェクト ファイルが変更された場合、上記のすべての規則を適用し、再コンパイルする必要があるものを確認します。If a project file changes: apply all preceding rules and see what needs to be recompiled. AssemblyNameIntermediateOutputPathRootNamespace、および HostInBrowser プロパティが変更された場合は、再コンパイルが必要です。Changes to the following properties trigger a complete recompile: AssemblyName, IntermediateOutputPath, RootNamespace, and HostInBrowser.

次のような再コンパイルのシナリオが考えられます。The following recompile scenarios are possible:

  • アプリケーション全体が再コンパイルされる。The entire application is recompiled.

  • ローカルで定義された方参照を含んでいる XAMLXAML ファイルのみが再コンパイルされる。Only those XAMLXAML files that have locally defined type references are recompiled.

  • 何も再コンパイルされない (プロジェクトに何も変更が加えられていない場合)。Nothing is recompiled (if nothing in the project has changed).

関連項目See also