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

2025-09-11

このトピックでは、ほとんどの XAML ファイルのルート要素にある XML/XAML 名前空間 (xmlns) マッピングについて説明します。また、カスタム型とアセンブリに対して同様のマッピングを生成する方法についても説明します。

XAML 名前空間とコード定義とタイプライブラリの関係

XAML は、一般的な目的と Windows ランタイムアプリプログラミングへのアプリケーションの両方で、オブジェクト、オブジェクトのプロパティ、階層として表されるオブジェクトとプロパティのリレーションシップを宣言するために使用されます。 XAML で宣言するオブジェクトは、他のプログラミング手法や言語で定義されているタイプライブラリまたはその他の表現によってサポートされます。これらのライブラリは次のようになります。

Windows ランタイムのオブジェクトの組み込みセット。これは固定されたオブジェクトのセットであり、XAML からこれらのオブジェクトにアクセスするには、内部型マッピングとアクティブ化ロジックが使用されます。
Microsoft またはサードパーティによって提供される分散ライブラリ。
アプリに組み込まれているサードパーティ製コントロールの定義とパッケージの再配布を表すライブラリ。
プロジェクトの一部であり、ユーザーコード定義の一部またはすべてを保持する独自のライブラリ。

バッキング型情報は、特定の XAML 名前空間定義に関連付けられています。 Windows ランタイムなどの XAML フレームワークでは、複数のアセンブリと複数のコード名前空間を集計して、1 つの XAML 名前空間にマップできます。これにより、大規模なプログラミングフレームワークまたはテクノロジをカバーする XAML ボキャブラリの概念が可能になります。 XAML ボキャブラリは非常に広範囲に及ぶ場合があります。たとえば、このリファレンスの Windows ランタイムアプリに関して文書化されている XAML のほとんどは、1 つの XAML ボキャブラリを構成します。 XAML ボキャブラリも拡張可能です。バッキングコード定義に型を追加して拡張し、XAML ボキャブラリのマップされた名前空間ソースとして既に使用されている型をコード名前空間に含めるようにします。

XAML プロセッサは、ランタイムオブジェクト表現を作成するときに、その XAML 名前空間に関連付けられているバッキングアセンブリから型とメンバーを検索できます。これが、オブジェクト構築動作の定義を形式化して交換する方法として XAML が役立つ理由と、XAML が Windows ランタイムアプリの UI 定義手法として使用される理由です。

一般的な XAML マークアップの使用における XAML 名前空間

XAML ファイルは、ほとんどの場合、ルート要素で既定の XAML 名前空間を宣言します。既定の XAML 名前空間は、プレフィックスで修飾せずに宣言できる要素を定義します。たとえば、要素 <Balloon />宣言した場合、XAML パーサーは要素 Balloon が存在し、既定の XAML 名前空間で有効であると想定します。これに対し、 Balloon が定義済みの既定の XAML 名前空間にない場合は、代わりにその要素名をプレフィックス (例: <party:Balloon />) で修飾する必要があります。プレフィックスは、要素が既定の名前空間とは異なる XAML 名前空間に存在することを示し、この要素を使用する前に XAML 名前空間をプレフィックス パーティ にマップする必要があります。 XAML 名前空間は、宣言されている特定の要素と、XAML 構造体内のその要素に含まれるすべての要素にも適用されます。このため、XAML 名前空間は、ほとんどの場合、この継承を利用するために XAML ファイルのルート要素で宣言されます。

既定および XAML 言語の XAML 名前空間宣言

ほとんどの XAML ファイルのルート要素内には、2 つの xmlns 宣言があります。最初の宣言では、XAML 名前空間が既定としてマップされます。 xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

これは、UI 定義マークアップ形式としても XAML を使用する、いくつかの先行する Microsoft テクノロジで使用されるのと同じ XAML 名前空間識別子です。同じ識別子を使用することは意図的であり、C++、C#、または Visual Basic を使用して、以前に定義した UI を Windows ランタイムアプリに移行する場合に役立ちます。

2 番目の宣言では、XAML で定義された言語要素用の別の XAML 名前空間をマップし、それを (通常は) "x:" プレフィックスにマッピングします。 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

この xmlns 値と、それがマップされる "x:" プレフィックスも、XAML を使用するいくつかの先行する Microsoft テクノロジで使用される定義と同じです。

これらの宣言間の関係は、XAML が言語定義であり、Windows ランタイムは XAML を言語として使用し、その型が XAML で参照される特定のボキャブラリを定義する実装の 1 つです。

XAML 言語は特定の言語要素を指定します。これらの各要素は、XAML 名前空間に対して動作する XAML プロセッサ実装を通じてアクセスできる必要があります。 XAML 言語 XAML 名前空間の "x:" マッピング規則の後に、プロジェクトテンプレート、サンプルコード、言語機能のドキュメントが続きます。 XAML 言語名前空間では、基本的な Windows ランタイムアプリでも必要な一般的に使用される機能がいくつか定義されています。たとえば、部分クラスを介して分離コードを XAML ファイルに結合するには、そのクラスに、関連する XAML ファイルのルート要素の x:Class 属性として名前を付ける必要があります。または、XAML ページで ResourceDictionary および XAML リソース参照のキー付きリソースとして定義されている要素には、対象のオブジェクト要素に x:Key 属性が設定されている必要があります。

既定の XAML 名前空間にマップされるコード名前空間

既定の XAML 名前空間に現在マップされているコード名前空間の一覧を次に示します。

Windows.UI
Windows.UI.Xaml
Windows.UI.Xaml.Automation
Windows.UI.Xaml.Automation.Peers
Windows.UI.Xaml.Automation.Provider
Windows.UI.Xaml.Automation.Text
Windows.UI.Xaml.Controls
Windows.UI.Xaml.Controls.Primitives
Windows.UI.Xaml.Data
Windows.UI.Xaml.Documents
Windows.UI.Xaml.Input
Windows.UI.Xaml.Interop
Windows.UI.Xaml.Markup
Windows.UI.Xaml.Media
Windows.UI.Xaml.Media.Animation
Windows.UI.Xaml.Media.Imaging
Windows.UI.Xaml.Media.Media3D
Windows.UI.Xaml.Navigation
Windows.UI.Xaml.Resources
Windows.UI.Xaml.Shapes
Windows.UI.Xaml.Threading
Windows.UI.Text

その他の XAML 名前空間

既定の名前空間と XAML 言語の XAML 名前空間 "x:" に加えて、Microsoft Visual Studio によって生成されたアプリの最初の既定の XAML には、他のマップされた XAML 名前空間も表示される場合があります。

d: (`http://schemas.microsoft.com/expression/blend/2008`)

"d:" XAML 名前空間は、デザイナーのサポート、特に Microsoft Visual Studio の XAML デザインサーフェイスでのデザイナーのサポートを目的としています。 "d:" XAML 名前空間を使用すると、XAML 要素のデザイナー属性またはデザイン時属性を使用できます。これらのデザイナー属性は、XAML の動作の設計面にのみ影響します。アプリの実行時に Windows ランタイム XAML パーサーによって同じ XAML が読み込まれると、デザイナー属性は無視されます。一般に、デザイナー属性は任意の XAML 要素で有効ですが、実際には、デザイナー属性を自分で適用することが適切な特定のシナリオしかありません。特に、デザイナー属性の多くは、XAML とデータバインディングを使用するコードを開発しているときに、データコンテキストやデータソースと対話するためのエクスペリエンスを向上させることを目的としています。

d:DesignHeight 属性と d:DesignWidth 属性: これらの属性は、Visual Studio または別の XAML デザイナーサーフェイスによって自動的に作成される XAML ファイルのルートに適用される場合があります。たとえば、これらの属性は、アプリプロジェクトに新しい UserControl を追加した場合に作成される XAML の UserControl ルートに設定されます。これらの属性を使用すると、XAML コンテンツの構成を簡単に設計できるため、XAML コンテンツがコントロールインスタンスまたはより大きな UI ページの他の部分に使用された後に存在する可能性のあるレイアウト制約を期待できます。

手記 Microsoft Silverlight から XAML を移行する場合は、UI ページ全体を表すルート要素にこれらの属性がある可能性があります。この場合は、属性を削除できます。シミュレーターなどの XAML デザイナーの他の機能は、 d:DesignHeight と d:DesignWidth を使用した固定サイズのページレイアウトよりも、スケーリングとビューステートを適切に処理するページレイアウトの設計に役立つ可能性があります。
d:DataContext 属性: この属性は、ページルートまたはコントロールに設定して、オブジェクトが持つ明示的または継承された DataContext をオーバーライドできます。
d:DesignSource 属性:CollectionViewSource のソースをオーバーライドするデザイン時データソースを指定する。
d:DesignInstance および d:DesignData マークアップ拡張:これらのマークアップ拡張機能は、d:DataContext または d:DesignSource のデザイン時データリソースを提供するために使用されます。ここでは、デザイン時データリソースの使用方法については完全には説明しません。詳細については、「 Design-Time 属性」を参照してください。使用例については、デザイン画面のサンプルデータとプロトタイプ作成に関するページを参照してください。

mc: (`http://schemas.openxmlformats.org/markup-compatibility/2006`)

"mc:" は、XAML を読み取るためのマークアップ互換性モードを示し、サポートします。通常、"d:" プレフィックスは mc :Ignorable 属性に関連付けられます。この手法により、ランタイム XAML パーサーは "d:" のデザイン属性を無視できます。

local: と common:

"local:" は、多くの場合、テンプレート化された UWP アプリプロジェクトの XAML ページ内でマップされるプレフィックスです。これは、app.xaml を含むすべての XAML ファイルの x:Class 属性とコードを格納するために作成されたのと同じ名前空間を参照するようにマップされます。この同じ名前空間で XAML で使用するカスタムクラスを定義する限り、 local: プレフィックスを使用して XAML でカスタム型を参照できます。テンプレート化された UWP アプリプロジェクトから取得される関連プレフィックスは 一般的です。このプレフィックスは、コンバーターやコマンドなどのユーティリティクラスを含む入れ子になった "Common" 名前空間を参照し、 ソリューションエクスプローラー ビューの [共通] フォルダーで定義を見つけることができます。

vsm:

使用しないでください。 "vsm:" は、他の Microsoft テクノロジからインポートされた古い XAML テンプレートで見られるプレフィックスです。名前空間は、もともと従来の名前空間ツールの問題に対処しました。 Windows ランタイムで使用する XAML で "vsm:" の XAML 名前空間定義を削除し、代わりに既定の XAML 名前空間を使用するように VisualState、 VisualStateGroup 、および関連オブジェクトのプレフィックスの使用法を変更する必要があります。 XAML の移行の詳細については、「 Silverlight または WPF XAML/コードを Windows ランタイムアプリに移行する」を参照してください。

XAML 名前空間とプレフィックスへのカスタム型のマッピング

XAML 名前空間をマップして、XAML を使用して独自のカスタム型にアクセスできるようにします。つまり、カスタム型を定義するコード表現に存在するコード名前空間をマッピングし、使用するプレフィックスと共に XAML 名前空間を割り当てます。 XAML のカスタム型は、Microsoft .NET 言語 (C# または Microsoft Visual Basic) または C++ で定義できます。マッピングは、 xmlns プレフィックスを定義することによって行われます。たとえば、 xmlns:myTypes では、すべての使用法にトークン myTypes:のプレフィックスを付けることでアクセスされる新しい XAML 名前空間を定義します。

xmlns 定義には、値とプレフィックスの名前付けが含まれます。値は、等号の後に引用符で囲まれた文字列です。一般的な XML 規則は、一意性と識別の規則が存在するように、XML 名前空間を URI (Uniform Resource Identifier) に関連付ける方法です。また、この規則は、既定の XAML 名前空間と XAML 言語 XAML 名前空間、および Windows ランタイム XAML で使用される使用頻度の低い XAML 名前空間についても確認できます。ただし、カスタム型をマップする XAML 名前空間では、URI を指定する代わりに、トークン "using:" でプレフィックス定義を開始します。 "using:" トークンに続けて、コード名前空間に名前を付けます。

たとえば、"CustomClasses" 名前空間を参照し、その名前空間またはアセンブリのクラスを XAML のオブジェクト要素として使用できる "custom1" プレフィックスをマップするには、XAML ページにルート要素に次のマッピングを含める必要があります。 xmlns:custom1="using:CustomClasses"

同じページスコープの部分クラスをマップする必要はありません。たとえば、ページの XAML UI 定義からイベントを処理するために定義したイベントハンドラーを参照するためにプレフィックスは必要ありません。また、Windows ランタイムアプリ用に Visual Studio で生成されたプロジェクトの開始 XAML ページの多くは、プロジェクト指定の既定の名前空間と部分クラス定義で使用される名前空間を参照する "local:" プレフィックスを既にマップしています。

CLR 言語規則

.NET 言語 (C# または Microsoft Visual Basic) でバッキングコードを記述する場合は、名前空間名の一部としてドット (".") を使用してコード名前空間の概念階層を作成する規則を使用している可能性があります。名前空間定義にドットが含まれている場合、ドットは "using:" トークンの後に指定する値の一部である必要があります。

分離コードファイルまたはコード定義ファイルが C++ ファイルの場合、XAML 構文に違いがないように、共通言語ランタイム (CLR) 言語形式に従う特定の規則があります。 C++ で入れ子になった名前空間を宣言する場合、"using:" トークンに続く値を指定する場合、連続する入れ子になった名前空間文字列の間の区切り記号は "::" ではなく "." にする必要があります。

XAML で使用するコードを定義するときは、入れ子になった型 (クラス内の列挙体の入れ子など) を使用しないでください。入れ子になった型は評価できません。 XAML パーサーが、ドットが名前空間名の一部ではなく、入れ子になった型名の一部であることを区別する方法はありません。

カスタム型とアセンブリ

XAML 名前空間のバッキング型を定義するアセンブリの名前は、マッピングで指定されていません。アセンブリを使用できるロジックは、アプリ定義レベルで制御され、基本的なアプリのデプロイとセキュリティの原則の一部です。 XAML のコード定義ソースとして含めるアセンブリを、プロジェクト設定の依存アセンブリとして宣言します。詳細については、「 C# および Visual Basic での Windows ランタイムコンポーネントの作成」を参照してください。

プライマリアプリのアプリケーション定義またはページ定義からカスタム型を参照している場合、これらの型は依存アセンブリの構成なしで使用できますが、それらの型を含むコード名前空間をマップする必要があります。一般的な規則は、指定された XAML ページの既定のコード名前空間のプレフィックス "local" をマップすることです。この規則は、多くの場合、XAML プロジェクトのプロジェクトテンプレートの開始に含まれています。

添付プロパティ

添付プロパティを参照する場合、添付プロパティ名の所有者型の部分は、既定の XAML 名前空間内にあるか、プレフィックスを付ける必要があります。要素とは別に属性のプレフィックスを付けることはまれですが、これは、特にカスタム添付プロパティに必要な場合の 1 つです。詳細については、「カスタム添付プロパティ」を参照してください。

フィードバック

このページはお役に立ちましたか?