次の方法で共有

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

  • [アーティクル]

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

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

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

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

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

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

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

XAML ファイルは、ほとんどの場合、ルート要素で既定の XAML 名前空間を宣言します。 既定の XAML 名前空間は、プレフィックスで修飾せずに宣言できる要素を定義します。 たとえば、 <Balloon />要素を宣言する場合、XAML パーサーは、要素 Balloon が存在し、既定の XAML 名前空間で有効であることが想定されます。 これに対し、 Balloon が定義済みの既定の XAML 名前空間にない場合は、代わりに、 <party:Balloon />などのプレフィックスでその要素名を修飾する必要があります。 プレフィックスは、要素が既定の名前空間とは異なる XAML 名前空間に存在することを示し、この要素を使用する前に、XAML 名前空間をプレフィックス party にマップする必要があります。 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 言語名前空間は、C++、C#、または Visual Basic を使用する基本的なWindows ランタイム アプリでも必要な、よく使用されるいくつかの機能を定義します。 たとえば、部分クラスを介して分離コードを XAML ファイルに結合するには、そのクラスに x:Class 属性として名前を付け 関連する XAML ファイルのルート要素に名前を付ける必要があります。 または、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 の動作の設計面にのみ影響します。 アプリの実行時に同じ XAML が Windows ランタイム 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 attribute: この属性をページ ルートまたはコントロールに設定して、明示的または継承された DataContext をオーバーライドできます。
  • d:DesignSource attribute: CollectionViewSource のデザイン時データ ソースを指定し、 Source をオーバーライドします。
  • d:DesignInstance および d:DesignData マークアップ拡張: これらのマークアップ拡張機能は、 d:DataContext または d:DesignSource のデザイン時データ リソースを提供するために使用されます。 ここでは、デザイン時データ リソースの使用方法については完全には説明しません。 詳細については、「デザイン時属性」を参照してください。 使用例については、 デザイン画面のサンプル データとプロトタイプ作成に関するを参照してください。

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:です。 このプレフィックスは、コンバーターやコマンドなどのユーティリティ クラスを含む入れ子になった "Common" 名前空間を参照し、ソリューション エクスプローラー ビューの 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 名前空間、および XAML で使用される使用頻度の低い XAML 名前空間についても、この規則Windows ランタイム参照してください。 ただし、カスタム型をマップする XAML 名前空間では、URI を指定する代わりに、トークン "using:" でプレフィックス定義を開始します。 "using:" トークンに続けて、コード名前空間に名前を付けます。

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

同じページ スコープの部分クラスをマップする必要はありません。 たとえば、ページの XAML UI 定義からイベントを処理するために定義したイベント ハンドラーを参照するためにプレフィックスは必要ありません。 また、Visual Studio から生成された、C++、C#、または Visual Basic を使用して、Windows ランタイム アプリ用に生成された 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 つです。 詳細については、「 Custom 添付プロパティを参照してください。