次の方法で共有

WPF アプリケーションをコンパイルする

Windows Presentation Foundation (WPF) アプリケーションは、.NET Framework 実行可能ファイル (.exe)、ライブラリ (.dll)、または両方の種類のアセンブリの組み合わせとして構築できます。 このトピックでは、WPF アプリケーションをビルドする方法について説明し、ビルド プロセスの主要な手順について説明します。

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

WPF アプリケーションは、次の方法でコンパイルできます。

WPF ビルド パイプライン (ソフトウェア開発のための)

WPF プロジェクトがビルドされると、言語固有のターゲットと WPF 固有のターゲットの組み合わせが呼び出されます。 これらのターゲットを実行するプロセスをビルド パイプラインと呼び、主な手順を次の図に示します。

WPF ビルド プロセス

ビルド前の初期化

ビルドする前に、MSBuild は、次のような重要なツールとライブラリの場所を決定します。

  • .NET Framework。

  • Windows SDK ディレクトリ。

  • WPF 参照アセンブリの場所。

  • アセンブリ検索パスのプロパティ。

MSBuild がアセンブリを検索する最初の場所は、参照アセンブリ ディレクトリ (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\) です。 この手順では、ビルド プロセスによって、さまざまなプロパティと項目グループも初期化され、必要なクリーンアップ作業が実行されます。

参照を解決する

ビルド プロセスは、アプリケーション プロジェクトのビルドに必要なアセンブリを見つけてバインドします。 このロジックは、 ResolveAssemblyReference タスクに含まれています。 プロジェクト ファイルで Reference として宣言されているすべてのアセンブリは、システムに既にインストールされているアセンブリの検索パスとメタデータに関する情報と共にタスクに提供されます。 タスクはアセンブリを検索し、インストールされているアセンブリのメタデータを使用して、出力マニフェストに表示する必要のないコア WPF アセンブリを除外します。 これは、ClickOnce マニフェストの冗長な情報を回避するために行われます。 たとえば、PresentationFramework.dll は WPF でビルドされたアプリケーションを表していると見なすことができるため、すべての WPF アセンブリは、.NET Framework がインストールされているすべてのコンピューター上の同じ場所に存在するため、マニフェスト内のすべての .NET Framework 参照アセンブリに関するすべての情報を含める必要はありません。

マークアップ コンパイル - Pass 1

この手順では、ランタイムが XML の解析とプロパティ値の検証に時間を費やさないように、XAML ファイルが解析およびコンパイルされます。 コンパイル済みの XAML ファイルは事前トークン化されているため、実行時に読み込む方が XAML ファイルの読み込みよりもはるかに高速になります。

この手順では、 Page ビルド項目であるすべての XAML ファイルに対して、次のアクティビティが実行されます。

  1. XAML ファイルはマークアップ コンパイラによって解析されます。

  2. コンパイル済みの表現がその XAML 用に作成され、obj\Release フォルダーにコピーされます。

  3. 新しい部分クラスの CodeDOM 表現が作成され、obj\Release フォルダーにコピーされます。

さらに、言語固有のコード ファイルは、すべての XAML ファイルに対して生成されます。 たとえば、Visual Basic プロジェクトの Page1.xaml ページの場合、Page1.g.vbが生成されます。C# プロジェクトの Page1.xaml ページの場合は、Page1.g.csが生成されます。 ファイル名の ".g" は、マークアップ ファイルの最上位要素 ( Page や Windowなど) の部分クラス宣言を持つ、ファイルが生成されたコードであることを示します。 クラスは C# の partial 修飾子 (Visual Basic では Extends ) で宣言され、他の場所 (通常は分離コード ファイル Page1.xaml.cs内) にクラスの別の宣言があることを示します。

部分クラスは、適切な基底クラス (ページの Page など) から拡張され、 System.Windows.Markup.IComponentConnector インターフェイスを実装します。 IComponentConnector インターフェイスには、コンポーネントを初期化し、そのコンテンツ内の要素の名前とイベントを接続するメソッドがあります。 その結果、生成されたコード ファイルには、次のようなメソッド実装があります。

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 で実行されます。 これにより、パフォーマンスが大幅に向上します。 この動作は、 AlwaysCompileMarkupFilesInSeparateDomain プロパティで切り替えることができます。 これには、個別の AppDomainをアンロードすることによって、すべての参照アセンブリをアンロードする利点があります。

マークアップ コンパイル - パス 2

マークアップ コンパイルのパス 1 の間にすべての XAML ページがコンパイルされるわけではありません。 ローカルで定義された型参照 (同じプロジェクト内の別の場所のコードで定義された型への参照) を持つ XAML ファイルは、現時点ではコンパイルから除外されます。 これは、ローカルに定義された型はソースにのみ存在し、まだコンパイルされていないためです。 これを判断するために、パーサーは、マークアップ ファイル内の x:Name などの項目を検索するヒューリスティックを使用します。 このようなインスタンスが見つかると、そのマークアップ ファイルのコンパイルはコード ファイルがコンパイルされるまで延期され、その後、2 番目のマークアップ コンパイル パスはこれらのファイルを処理します。

ファイル分類

ビルド プロセスでは、配置されるアプリケーション アセンブリに基づいて、出力ファイルが異なるリソース グループに配置されます。 一般的な非ローカライズ アプリケーションでは、 Resource としてマークされているすべてのデータ ファイルがメイン アセンブリ (実行可能ファイルまたはライブラリ) に配置されます。 プロジェクトで UICulture 設定すると、コンパイルされたすべての XAML ファイルと、言語固有として特別にマークされたリソースがサテライト リソース アセンブリに配置されます。 さらに、言語に依存しないすべてのリソースがメイン アセンブリに配置されます。 ビルド プロセスのこの手順では、その決定が行われます。

プロジェクト ファイル内の ApplicationDefinition、 Page、および Resource のビルド アクションは、 Localizable メタデータ (許容される値は true と false) で拡張できます。これは、ファイルが言語固有か言語に依存しないかを指定します。

コア コンパイル

コア コンパイル 手順には、コード ファイルのコンパイルが含まれます。 これは、言語固有のターゲット ファイル Microsoft.CSharp.targets と Microsoft.VisualBasic.targets のロジックによって調整されます。 ヒューリスティックがマークアップ コンパイラの単一パスで十分であると判断した場合は、メイン アセンブリが生成されます。 ただし、プロジェクト内の 1 つ以上の XAML ファイルにローカル定義型への参照がある場合は、マークアップ コンパイルの 2 回目のパスが完了した後に最終的なアプリケーション アセンブリが作成されるように、一時的な .dll ファイルが生成されます。

マニフェストの生成

ビルド プロセスの最後に、すべてのアプリケーション アセンブリとコンテンツ ファイルの準備ができたら、アプリケーションの ClickOnce マニフェストが生成されます。

配置マニフェスト ファイルには、デプロイ モデル (現在のバージョン、更新動作、発行元 ID とデジタル署名) が記述されています。 このマニフェストは、配置を処理する管理者が作成することを目的としています。 ファイル拡張子は .xbap (XAML ブラウザー アプリケーション (XBAP) 用) とインストールされているアプリケーション用の .application です。 前者は HostInBrowser プロジェクト プロパティによって指示され、その結果、マニフェストはアプリケーションをブラウザーでホストされているものとして識別します。

アプリケーション マニフェスト (.exe.manifest ファイル) には、アプリケーション アセンブリと依存ライブラリが記述され、アプリケーションに必要なアクセス許可が一覧表示されます。 このファイルは、アプリケーション開発者が作成することを目的としています。 ClickOnce アプリケーションを起動するために、ユーザーはアプリケーションの配置マニフェスト ファイルを開きます。

これらのマニフェスト ファイルは、常に XBAP 用に作成されます。 インストールされているアプリケーションの場合、値がGenerateManifestsのプロジェクト ファイルで true プロパティが指定されていない限り、アプリケーションは作成されません。

XBAP には、一般的なインターネット ゾーン アプリケーションに割り当てられたアクセス許可 ( WebBrowserPermission と MediaPermission) の 2 つ以上の追加のアクセス許可が付与されます。 WPF ビルド システムは、アプリケーション マニフェストでこれらのアクセス許可を宣言します。

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

WPF ビルド システムでは、増分ビルドがサポートされます。 マークアップまたはコードに加えられた変更の検出に関してはかなりインテリジェントであり、変更の影響を受ける成果物のみをコンパイルします。 増分ビルド メカニズムでは、次のファイルが使用されます。

  • 現在のコンパイラの状態を維持するための $(AssemblyName)_MarkupCompiler.Cache ファイル。

  • ローカルで定義された型への参照を含む XAML ファイルをキャッシュする $(AssemblyName)_MarkupCompiler.lref ファイル。

増分ビルドを管理する一連のルールを次に示します。

  • ファイルは、ビルド システムが変更を検出する最小の単位です。 そのため、コード ファイルの場合、ビルド システムは型が変更されたかどうか、またはコードが追加されたかどうかを確認できません。 プロジェクト ファイルの場合も同じです。

  • 増分ビルド メカニズムは、XAML ページがクラスを定義するか、他のクラスを使用することを認識する必要があります。

  • Referenceエントリが変更された場合は、すべてのページを再コンパイルします。

  • コード ファイルが変更された場合は、ローカルで定義された型参照を持つすべてのページを再コンパイルします。

  • XAML ファイルが変更された場合:

    • XAML がプロジェクトで Page として宣言されている場合:XAML にローカルで定義された型参照がない場合は、その XAML とローカル参照を持つすべての XAML ページを再コンパイルします。XAML にローカル参照がある場合は、ローカル参照を使用してすべての XAML ページを再コンパイルします。

    • XAML がプロジェクトで ApplicationDefinition として宣言されている場合: すべての XAML ページを再コンパイルします (理由: 各 XAML には、変更された可能性がある Application 型への参照があります)。

  • プロジェクト ファイルが XAML ファイルではなくアプリケーション定義としてコード ファイルを宣言する場合:

    • プロジェクト ファイルの ApplicationClassName 値が変更されているかどうかを確認します (新しいアプリケーションの種類はありますか? その場合は、アプリケーション全体を再コンパイルします。

    • それ以外の場合は、ローカル参照を使用してすべての XAML ページを再コンパイルします。

  • プロジェクト ファイルが変更された場合: 上記のすべてのルールを適用し、再コンパイルする必要がある内容を確認します。 次のプロパティを変更すると、完全な再コンパイルがトリガーされます: AssemblyName、 IntermediateOutputPath、 RootNamespace、および HostInBrowser。

次の再コンパイル シナリオが可能です。

  • アプリケーション全体が再コンパイルされます。

  • ローカルで定義された型参照を持つ XAML ファイルのみが再コンパイルされます。

  • 再コンパイルは行われません (プロジェクト内で何も変更されていない場合)。

こちらも参照ください