次の方法で共有

WPF XAML の XAML 名前空間と名前空間マッピング

  • [アーティクル]

このトピックでは、WPF XAML ファイルのルート タグでよく見られる 2 つの XAML 名前空間マッピングの存在と目的についてさらに説明します。 また、独自のコードや個別のアセンブリ内で定義されている要素を使用するための同様のマッピングを生成する方法についても説明します。

XAML 名前空間とは

XAML 名前空間は、実際には XML 名前空間の概念の拡張です。 XAML 名前空間を指定する手法は、XML 名前空間の構文、URI を名前空間識別子として使用する規則、プレフィックスを使用して同じマークアップ ソースから複数の名前空間を参照する手段を提供する規則などに依存します。 XML 名前空間の XAML 定義に追加される主な概念は、XAML 名前空間がマークアップ使用の一意性のスコープの両方を意味し、マークアップ エンティティが特定の CLR 名前空間と参照されるアセンブリによってサポートされる可能性がある方法にも影響を与えるということです。 後者の考慮事項は、XAML スキーマ コンテキストの概念の影響も受けます。 通常、WPF が XAML 名前空間とどのように連携するかについては、既定のXAML 名前空間、XAML 言語名前空間、および XAML マークアップによって特定のバッキングCLR 名前空間や参照されるアセンブリに直接マップされる他のXAML 名前空間と考えることができます。

WPF と XAML 名前空間の宣言

多くの XAML ファイルのルート タグ内の名前空間宣言内には、通常、2 つの XML 名前空間宣言があることがわかります。 最初の宣言では、WPF クライアント/フレームワーク XAML 名前空間全体が既定としてマップされます。

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

2 番目の宣言は、別の XAML 名前空間をマップし、それを (通常は) x: プレフィックスにマッピングします。

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

これらの宣言間の関係は、x: プレフィックス マッピングが XAML 言語定義の一部である組み込みをサポートしていることです。WPF は、XAML を言語として使用し、XAML のオブジェクトのボキャブラリを定義する実装の 1 つです。 WPF ボキャブラリの使用法は XAML 組み込み関数の使用法よりもはるかに一般的であるため、WPF ボキャブラリは既定としてマップされます。

XAML 言語組み込みサポートをマッピングするための x: プレフィックス規則の後に、プロジェクト テンプレート、サンプル コード、およびこの SDK 内の言語機能のドキュメントが続きます。 XAML 名前空間は、基本的な WPF アプリケーションでも必要な、よく使用される多くの機能を定義します。 たとえば、部分クラスを介して分離コードを XAML ファイルに結合するには、そのクラスに関連する XAML ファイルのルート要素の x:Class 属性として名前を付ける必要があります。 または、キー付きリソースとしてアクセスする XAML ページで定義されている要素には、対象の要素に x:Key 属性が設定されている必要があります。 XAML のこれらの要素とその他の側面の詳細については、WPF の XAML 、または XAML 構文の詳細を参照してください。

カスタム クラスとアセンブリへのマッピング

標準の WPF および XAML 組み込み XAML 名前空間をプレフィックスにマップする方法と同様に、xmlns プレフィックス宣言内で一連のトークンを使用して、XML 名前空間をアセンブリにマップできます。

構文は、次の可能な名前付きトークンと次の値を受け取ります。

clr-namespace: 要素として公開するパブリック型を含むアセンブリ内で宣言された CLR 名前空間。

assembly= 参照される CLR 名前空間の一部またはすべてを含むアセンブリ。 この値は通常、パスではなくアセンブリの名前に過ぎず、拡張子 (.dll や .exeなど) は含まれません。 そのアセンブリへのパスは、マップしようとしている XAML を含むプロジェクト ファイル内のプロジェクト参照として確立する必要があります。 バージョン管理と厳密な名前の署名を組み込むために、assembly の値には、単純な文字列名ではなく、AssemblyNameで定義された文字列を指定できます。

clr-namespace トークンを値から分離する文字はコロン (:)一方、assembly トークンを値から分離する文字は等号 (=) であることに注意してください。 これら 2 つのトークンの間で使用する文字はセミコロンです。 また、宣言のどこにも空白を含めないでください。

基本的なカスタム マッピングの例

次のコードでは、カスタム クラスの例を定義します。

namespace SDKSample {  
    public class ExampleClass : ContentControl {  
        public ExampleClass() {  
        ...  
        }  
    }  
}  

Namespace SDKSample  
    Public Class ExampleClass  
        Inherits ContentControl  
         ...  
        Public Sub New()  
        End Sub  
    End Class  
End Namespace

その後、このカスタム クラスはライブラリにコンパイルされ、プロジェクト設定 (表示されません) に従って SDKSampleLibraryという名前が付けられます。

このカスタム クラスを参照するには、現在のプロジェクトの参照として含める必要もあります。これは通常、Visual Studio のソリューション エクスプローラー UI を使用して行います。

これで、クラスを含むライブラリと、プロジェクト設定でそのクラスへの参照が作成されたので、XAML のルート要素の一部として次のプレフィックス マッピングを追加できます。

xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary"

すべてをまとめるために、以下にカスタム マッピングと典型的な既定および x: マッピングを含む XAML を示します。次に、その UI 内でプレフィックス付きの参照を使用して ExampleClass をインスタンス化します。

<Page x:Class="WPFApplication1.MainPage"  
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
    xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary">  
  ...  
  <custom:ExampleClass/>  
...  
</Page>

現在のアセンブリへのマッピング

参照 clr-namespace が、カスタム クラスを参照しているアプリケーション コードと同じアセンブリ内で定義されている場合は、assembly を省略できます。 または、この場合の同等の構文は、等号の後に文字列トークンを含まない assembly=を指定することです。

同じアセンブリで定義されている場合、カスタム クラスをページのルート要素として使用することはできません。 部分クラスをマップする必要はありません。XAML で要素として参照する場合は、アプリケーション内のページの部分クラスではないクラスのみをマップする必要があります。

アセンブリ内の XML 名前空間への CLR 名前空間のマッピング

WPF は、複数の CLR 名前空間を 1 つの XAML 名前空間にマップするために、XAML プロセッサによって使用される CLR 属性を定義します。 この属性 XmlnsDefinitionAttributeは、アセンブリを生成するソース コードのアセンブリ レベルに配置されます。 WPF アセンブリのソース コードでは、この属性を使用して、System.Windows や System.Windows.Controlsなど、さまざまな一般的な名前空間を http://schemas.microsoft.com/winfx/2006/xaml/presentation 名前空間にマップします。

XmlnsDefinitionAttribute は、XML/XAML 名前空間名と CLR 名前空間名の 2 つのパラメーターを受け取ります。 複数の XmlnsDefinitionAttribute が存在して、複数の CLR 名前空間を同じ XML 名前空間にマップできます。 マップされると、必要に応じて、部分クラス分離コード ページで適切な using ステートメントを指定することで、これらの名前空間のメンバーを完全な修飾なしで参照することもできます。 詳細については、XmlnsDefinitionAttributeを参照してください。

XAML テンプレートからのデザイナー名前空間とその他のプレフィックス

WPF XAML の開発環境やデザイン ツールを使用している場合は、XAML マークアップ内に他の定義済みの XAML 名前空間/プレフィックスがあることに気付く場合があります。

WPF Designer for Visual Studio では、通常、プレフィックス d:にマップされるデザイナー名前空間を使用します。 WPF 用の新しいプロジェクト テンプレートでは、この XAML 名前空間を事前にマップして、Visual Studio 用 WPF デザイナーと他のデザイン環境間の XAML の交換をサポートする場合があります。 このデザイン XAML 名前空間は、デザイナーで XAML ベースの UI をラウンドトリップしながらデザイン状態を永続化するために使用されます。 また、デザイナーでランタイム データ ソースを有効にする d:IsDataSourceなどの機能にも使用されます。

マップされている可能性があるもう 1 つのプレフィックスは、mc:です。 mc: はマークアップ互換性を目的としており、必ずしも XAML 固有ではないマークアップ互換性パターンを利用しています。 マークアップ互換性機能がある程度は、フレームワーク間またはバッキング実装の他の境界を越えて XAML を交換したり、XAML スキーマ コンテキスト間で動作したり、デザイナーの限られたモードの互換性を提供したりするために使用できます。 マークアップ互換性の概念とその WPF との関係の詳細については、「マークアップ互換性 (mc:) 言語機能の」を参照してください。

WPF とアセンブリの読み込み

WPF の XAML スキーマ コンテキストは WPF アプリケーション モデルと統合され、次に CLR で定義された AppDomainの概念が使用されます。 次のシーケンスでは、WPF での AppDomain とその他の要因に基づいて、アセンブリを読み込む方法、または実行時またはデザイン時に型を検索する方法を XAML スキーマ コンテキストがどのように解釈するかについて説明します。

  1. AppDomainを反復処理し、最後に読み込まれたアセンブリから開始して、名前のすべての側面に一致する既に読み込まれているアセンブリを探します。

  2. 名前が修飾されている場合は、修飾された名前で Assembly.Load(String) を実行します。

  3. 修飾名の短い名前 + 公開キー トークンが、マークアップが読み込まれたアセンブリと一致する場合は、そのアセンブリを返します。

  4. Assembly.Load(String)を呼び出すには、短い名前と公開キー トークンを使用します。

  5. 名前が特定されていない場合は、Assembly.LoadWithPartialNameを呼び出してください。

Loose XAML では、手順 3 は使用されません。アセンブリから読み込まれるものはありません。

WPF 用のコンパイル済み XAML (XamlBuildTask を使用して生成) では、AppDomain から既に読み込まれているアセンブリは使用されません (手順 1)。 そのため、XamlBuildTask 出力において名前は常に修飾されるべきであり、手順 5 は適用されません。

コンパイル済み BAML (PresentationBuildTask 経由で生成) ではすべての手順が使用されますが、BAML には修飾されていないアセンブリ名も含めてはなりません。

関連項目