XAML 名前空間および WPF XAML の名前空間の割り当てXAML Namespaces and Namespace Mapping for WPF XAML

このトピックでは、WPF XAML ファイルのルート タグでよく見られる 2 つの XAML 名前空間マッピングの存在と目的についてさらに説明します。This topic further explains the presence and purpose of the two XAML namespace mappings as often found in the root tag of a WPF XAML file. また、独自のコードで定義された要素や、個別のアセンブリ内で定義されている要素を使用するための同様のマッピングを生成する方法についても説明します。It also describes how to produce similar mappings for using elements that are defined in your own code, and/or within separate assemblies.

XAML 名前空間とは何ですか?What is a XAML Namespace?

XAML 名前空間は、XML 名前空間の概念の拡張です。A XAML namespace is really an extension of the concept of an XML namespace. XAML 名前空間を指定する手法は、XML 名前空間構文、名前空間識別子として URI を使用する規則、プレフィックスを使用して、同じマークアップ ソースから複数の名前空間を参照する手段などを使用します。The techniques of specifying a XAML namespace rely on the XML namespace syntax, the convention of using URIs as namespace identifiers, using prefixes to provide a means to reference multiple namespaces from the same markup source, and so on. XML 名前空間の XAML 定義に追加される主な概念は、XAML 名前空間はマークアップの使用に対して一意性のスコープを意味し、マークアップ エンティティが特定の CLR 名前空間によって潜在的にサポートされ、参照される方法に影響を与えるということです。アセンブリ。The primary concept that is added to the XAML definition of the XML namespace is that a XAML namespace implies both a scope of uniqueness for the markup usages, and also influences how markup entities are potentially backed by specific CLR namespaces and referenced assemblies. この後者の考慮事項は、XAML スキーマ コンテキストの概念によっても影響されます。This latter consideration is also influenced by the concept of a XAML schema context. しかし、WPF が XAML 名前空間を使用する方法を目的として、XAML 名前空間は、通常、既定の XAML 名前空間、XAML 言語名前空間、および XAML マークアップによって特定のバッキング CLR に直接マップされた XAML 名前空間を考えることができます。名前空間と参照アセンブリ。But for purposes of how WPF works with XAML namespaces, you can generally think of XAML namespaces in terms of a default XAML namespace, the XAML language namespace, and any further XAML namespaces as mapped by your XAML markup directly to specific backing CLR namespaces and referenced assemblies.

WPF 名前空間宣言と XAML 名前空間宣言The WPF and XAML Namespace Declarations

多くの XAML ファイルのルート タグ内の名前空間宣言内では、通常 2 つの XML 名前空間宣言があることがわかります。Within the namespace declarations in the root tag of many XAML files, you will see that there are typically two XML namespace declarations. 最初の宣言では、WPF クライアント /フレームワーク XAML 名前空間全体が既定としてマップされます。The first declaration maps the overall WPF client / framework XAML namespace as the default:

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

2 番目の宣言は、個別の XAML 名前空間をマップしx:、(通常は) プレフィックスに対応付けます。The second declaration maps a separate XAML namespace, mapping it (typically) to the x: prefix.

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

これらの宣言間の関係は、x:プレフィックス マッピングが XAML 言語定義の一部である組み込み関数WPFWPFをサポートし、XAML を言語として使用し、XAML のオブジェクトのボキャブラリを定義する 1 つの実装です。The relationship between these declarations is that the x: prefix mapping supports the intrinsics that are part of the XAML language definition, and WPFWPF is one implementation that uses XAML as a language and defines a vocabulary of its objects for XAML. WPF ボキャブラリの使用法は XAML 組み込み関数の使用法よりもはるかに一般的であるため、WPF ボキャブラリは既定としてマップされます。Because the WPF vocabulary's usages will be far more common than the XAML intrinsics usages, the WPF vocabulary is mapped as the default.

XAMLx:言語組み込みサポートをマッピングするためのプレフィックス規則の後には、プロジェクト テンプレート、サンプル コード、およびこの SDK 内の言語機能のドキュメントが続きます。The x: prefix convention for mapping the XAML language intrinsics support is followed by project templates, sample code, and the documentation of language features within this SDK. XAML 名前空間は、基本的な WPF アプリケーションにも必要な、一般的に使用される多くの機能を定義します。The XAML namespace defines many commonly-used features that are necessary even for basic WPF applications. たとえば、部分クラスを通じて分離コードを XAML ファイルに結合するには、関連する XAML ファイルのルート要素x:Classの属性としてそのクラスに名前を付ける必要があります。For instance, in order to join any code-behind to a XAML file through a partial class, you must name that class as the x:Class attribute in the root element of the relevant XAML file. または、キー付きリソースとしてアクセスする XAML ページで定義されている要素には、対象のx:Key要素に属性が設定されている必要があります。Or, any element as defined in a XAML page that you wish to access as a keyed resource should have the x:Key attribute set on the element in question. XAML のこれらの側面と他の側面の詳細については、「 XAML の概要 (WPF)またはXAML 構文の詳細」を参照してください。For more information on these and other aspects of XAML see XAML Overview (WPF) or XAML Syntax In Detail.

カスタム クラスおよびカスタム アセンブリへのマッピングMapping to Custom Classes and Assemblies

標準 WPF および XAML 組み込み XAML 名前空間xmlnsがプレフィックスにマップされるのと同様に、プレフィックス宣言内の一連のトークンを使用して、XML 名前空間をアセンブリにマップできます。You can map XML namespaces to assemblies using a series of tokens within an xmlns prefix declaration, similar to how the standard WPF and XAML-intrinsics XAML namespaces are mapped to prefixes.

構文には、次の名前付きトークンと次の値が使用されます。The syntax takes the following possible named tokens and following values:

clr-namespace:要素として公開するパブリック型を含むアセンブリ内で宣言された CLR 名前空間。clr-namespace: The CLR namespace declared within the assembly that contains the public types to expose as elements.

assembly=参照先 CLR 名前空間の一部またはすべてを含むアセンブリ。assembly= The assembly that contains some or all of the referenced CLR namespace. この値は、通常、パスではなく、アセンブリの名前に過ぎず、拡張子 (.dll や .exe など) は含まれません。This value is typically just the name of the assembly, not the path, and does not include the extension (such as .dll or .exe). そのアセンブリへのパスは、マップする XAML を含むプロジェクト ファイル内のプロジェクト参照として確立する必要があります。The path to that assembly must be established as a project reference in the project file that contains the XAML you are trying to map. バージョニングと厳密な名前の署名を組み込assemblyむために、値は単純な文字列名AssemblyNameではなく、 で定義された文字列にすることができます。In order to incorporate versioning and strong-name signing, the assembly value can be a string as defined by AssemblyName, rather than the simple string name.

トークンとその値をclr-namespace区切る文字はコロン (:)一方、トークンとその値assemblyを区切る文字は等号 (=) です。Note that the character separating the clr-namespace token from its value is a colon (:) whereas the character separating the assembly token from its value is an equals sign (=). これらの 2 つのトークンの間で使用する文字はセミコロンです。The character to use between these two tokens is a semicolon. また、宣言のどこにも空白を含まないでください。Also, do not include any white space anywhere in the declaration.

基本的なカスタム マッピングの例A Basic Custom Mapping Example

次のコードは、カスタム クラスの例を定義しています。The following code defines an example custom class:

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という名前が付けられます。This custom class is then compiled into a library, which per the project settings (not shown) is named SDKSampleLibrary.

このカスタム クラスを参照するには、Visual Studio のソリューション エクスプローラー UI を使用する、現在のプロジェクトの参照としてこのクラスを含める必要があります。In order to reference this custom class, you also need to include it as a reference for your current project, which you would typically do using the Solution Explorer UI in Visual Studio.

クラスを含むライブラリとプロジェクト設定での参照ができたので、XAML のルート要素の一部として次のプレフィックス マッピングを追加できます。Now that you have a library containing a class, and a reference to it in project settings, you can add the following prefix mapping as part of your root element in XAML:

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

すべてをまとめると、ルート タグの一般的な既定と x: マッピングと共にカスタム マッピングを含む XAML を次ExampleClassに示します。To put it all together, the following is XAML that includes the custom mapping along with the typical default and x: mappings in the root tag, then uses a prefixed reference to instantiate ExampleClass in that UI:

<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>  

現在のアセンブリへのマッピングMapping to Current Assemblies

assembly参照先がカスタム クラスclr-namespaceを参照しているアプリケーション コードと同じアセンブリ内で定義されている場合は省略できます。assembly can be omitted if the clr-namespace referenced is being defined within the same assembly as the application code that is referencing the custom classes. または、等号の後に文字列トークンを指定assembly=しない、 この場合の同等の構文を指定します。Or, an equivalent syntax for this case is to specify assembly=, with no string token following the equals sign.

同じアセンブリで定義されている場合、カスタム クラスをページのルート要素として使用することはできません。Custom classes cannot be used as the root element of a page if defined in the same assembly. 部分クラスをマップする必要はありません。XAML の要素として参照する場合は、アプリケーションのページの部分クラスではないクラスのみをマップする必要があります。Partial classes do not need to be mapped; only classes that are not the partial class of a page in your application need to be mapped if you intend to reference them as elements in XAML.

CLR 名前空間をアセンブリ内の XML 名前空間にマップするMapping CLR Namespaces to XML Namespaces in an Assembly

WPF では、複数の CLR 名前空間を 1 つの XAML 名前空間にマップするために、XAML プロセッサによって使用される CLR 属性を定義します。WPF defines a CLR attribute that is consumed by XAML processors in order to map multiple CLR namespaces to a single XAML namespace. この属性はXmlnsDefinitionAttribute、アセンブリを生成するソース コードのアセンブリ レベルに配置されます。This attribute, XmlnsDefinitionAttribute, is placed at the assembly level in the source code that produces the assembly. WPF アセンブリ ソース コードでは、この属性を使用して、 やSystem.WindowsSystem.Windows.Controlsなどのさまざまな一般的http://schemas.microsoft.com/winfx/2006/xaml/presentationな名前空間を名前空間にマップします。The WPF assembly source code uses this attribute to map the various common namespaces, such as System.Windows and System.Windows.Controls, to the http://schemas.microsoft.com/winfx/2006/xaml/presentation namespace.

にはXmlnsDefinitionAttribute、XML/XAML 名前空間名と CLR 名前空間名の 2 つのパラメーターを使用します。The XmlnsDefinitionAttribute takes two parameters: the XML/XAML namespace name, and the CLR namespace name. 複数のXmlnsDefinitionAttributeCLR 名前空間を同じ XML 名前空間にマップするために複数存在できます。More than one XmlnsDefinitionAttribute can exist to map multiple CLR namespaces to the same XML namespace. いったんマップされた名前空間のメンバーは、部分クラスの分離コード ページに適切なusingステートメントを提供することで、必要に応じて完全な修飾なしで参照することもできます。Once mapped, members of those namespaces can also be referenced without full qualification if desired by providing the appropriate using statement in the partial-class code-behind page. 詳細については、「XmlnsDefinitionAttribute」を参照してください。For more details, see XmlnsDefinitionAttribute.

XAML テンプレートからのデザイナー名前空間とその他のプレフィックスDesigner Namespaces and Other Prefixes From XAML Templates

WPF XAML の開発環境やデザイン ツールを使用している場合は、XAML マークアップ内に他の定義済みの XAML 名前空間やプレフィックスがあることに気付く場合があります。If you are working with development environments and/or design tools for WPF XAML, you may notice that there are other defined XAML namespaces / prefixes within the XAML markup.

Visual Studio の WPF デザイナーでは、通常はプレフィックスd:にマップされるデザイナー名前空間を使用します。WPF Designer for Visual Studio uses a designer namespace that is typically mapped to the prefix d:. WPF の最近のプロジェクト テンプレートでは、この XAML 名前空間を事前にマップして、Visual Studio 用 WPF デザイナーと他のデザイン環境との間で XAML の交換をサポートする場合があります。More recent project templates for WPF might pre-map this XAML namespace to support interchange of the XAML between WPF Designer for Visual Studio and other design environments. このデザイン XAML 名前空間は、デザイナーで XAML ベースの UI をラウンドしながらデザイン状態を永続化するために使用されます。This design XAML namespace is used to perpetuate design state while roundtripping XAML-based UI in the designer. また、デザイナーでランタイム データd:IsDataSourceソースを有効にする などの機能にも使用されます。It is also used for features such as d:IsDataSource, which enable runtime data sources in a designer.

マップされたもう 1 つのプレフィックスmc:は です。Another prefix you might see mapped is mc:. mc:はマークアップの互換性を保つために使用され、必ずしも XAML 固有ではないマークアップ互換性パターンを利用しています。mc: is for markup compatibility, and is leveraging a markup compatibility pattern that is not necessarily XAML-specific. ある程度、マークアップ互換性機能を使用して、フレームワーク間またはバッキング実装の他の境界を越えて XAML を交換したり、XAML スキーマ コンテキスト間での作業、デザイナーのモードが制限されている場合に互換性を提供したりできます。To some extent, the markup compatibility features can be used to exchange XAML between frameworks or across other boundaries of backing implementation, work between XAML schema contexts, provide compatibility for limited modes in designers, and so on. マークアップ互換性の概念と、それらが WPF とどのように関連しているかについて詳しくは、マークアップ互換性 (mc:) を参照してください。言語機能:For more information on markup compatibility concepts and how they relate to WPF, see Markup Compatibility (mc:) Language Features.

WPF とアセンブリの読み込みWPF and Assembly Loading

WPF の XAML スキーマ コンテキストは、WPF アプリケーション モデルと統合され、CLR で定義AppDomainされた概念の を使用します。The XAML schema context for WPF integrates with the WPF application model, which in turn uses the CLR-defined concept of AppDomain. 次のシーケンスでは、実行時またはデザイン時に、WPF の使用やその他の要因に基づいて、XAML スキーマ コンテキストがどのようにしてアセンブリを読AppDomainみ込むか、またはデザイン時に型を検索するかを解釈する方法について説明します。The following sequence describes how XAML schema context interprets how to either load assemblies or find types at run time or design time, based on the WPF use of AppDomain and other factors.

  1. AppDomainを反復処理して、最後に読み込まれたアセンブリから始めて、名前のすべての側面に一致する既に読み込まれたアセンブリを探します。Iterate through the AppDomain, looking for an already-loaded assembly that matches all aspects of the name, starting from the most recently loaded assembly.

  2. 名前が修飾されている場合は、Assembly.Load(String)修飾名を呼び出します。If the name is qualified, call Assembly.Load(String) on the qualified name.

  3. 修飾名の短縮名 + 公開キー トークンが、マークアップの読み込み元のアセンブリと一致する場合は、そのアセンブリを返します。If the short name + public key token of a qualified name matches the assembly that the markup was loaded from, return that assembly.

  4. 短縮名 + 公開鍵トークンを使用Assembly.Load(String)して を呼び出します。Use the short name + public key token to call Assembly.Load(String).

  5. 名前が修飾されていない場合は、Assembly.LoadWithPartialNameを呼び出します。If the name is unqualified, call Assembly.LoadWithPartialName.

ルーズ XAML では手順 3 は使用されません。読み込みからアセンブリがありません。Loose XAML does not use Step 3; there is no loaded-from assembly.

WPF 用にコンパイルされた XAML (XamlBuildTask を使用して生成) はAppDomain、既に読み込まれているアセンブリを使用しません (手順 1)。Compiled XAML for WPF (generated via XamlBuildTask) does not use the already-loaded assemblies from AppDomain (Step 1). また、名前は XamlBuildTask 出力から修飾されないようにする必要があるため、手順 5 は適用されません。Also, the name should never be unqualified from XamlBuildTask output, so Step 5 does not apply.

コンパイルされた BAML (プレゼンテーションビルドタスクを介して生成された) はすべての手順を使用しますが、BAML には非修飾のアセンブリ名も含めるべきではありません。Compiled BAML (generated via PresentationBuildTask) uses all steps, although BAML also should not contain unqualified assembly names.

関連項目See also