x:Class ディレクティブ

マークアップとコードビハインドの間で部分クラスを結合するように、XAML マークアップのコンパイルを構成します。 コードの部分クラスは、共通言語仕様 (CLS) 言語の別のコード ファイルで定義されているのに対し、マークアップの部分クラスは、通常、XAML のコンパイルの間にコード生成によって作成されます。

XAML 属性の使用方法

<object x:Class="namespace.classname"...>
  ...
</object>

XAML 値

依存関係

x:Class は、XAML の運用環境のルート要素にのみ指定できます。 x:Class は、XAML の運用環境に親があるオブジェクトでは無効です。 詳細については、[MS-XAML] セクション 6.3.1.6 を参照してください。

Remarks

namespace の値にドットを追加し、関連する名前空間を名前階層に編成することができます。これは、.NET プログラミングにおける一般的な手法です。 namespace と classname. を区切るものと解釈されるのは、x:Class 値の文字列内の最後のドットのみです。入れ子になったクラスを x:Class として使用することはできません。 入れ子になったクラスを許可すると、x:Class 文字列のドットの意味の判別が曖昧になるため、入れ子になったクラスは使用できません。

x:Class を使用する既存のプログラミング モデルでは、XAML ページにコードビハインドがなくてもまったく有効であるという意味で、x:Class は省略可能です。 ただし、その機能は、XAML を使用するフレームワークによって実装されるビルド アクションと相互作用します。 また、x:Class の機能は、アプリケーション モデルとそれに対応するビルド アクションにおける、XAML によって指定された内容のさまざまな分類の役割によっても影響を受けます。 XAML で、イベント処理属性の値の宣言またはカスタム要素のインスタンス化が行われていて、それを定義するクラスがコードビハインドに含まれる場合は、コードビハインドの適切なクラスに対する x:Class ディレクティブ参照 (または x:Subclass) を指定する必要があります。

x:Class ディレクティブの値は、アセンブリ情報が含まれない、クラスの完全修飾名を指定する文字列である必要があります (Type.FullName と同じ)。 単純なアプリケーションで、コードビハインドもそのような方法 (コード定義がクラス レベルで始まっている) で構造化されている場合は、CLR 名前空間の情報を省略できます。

ページまたはアプリケーションの定義のコードビハインド ファイルは、コンパイルされたアプリケーションが生成され、マークアップのコンパイルが含まれるプロジェクトの一部としてインクルードされるコード ファイル内に存在する必要があります。 CLR クラスの名前の規則に従う必要があります。 詳細については、「フレームワーク デザインのガイドライン」を参照してください。 既定では、コードビハインド クラスは public である必要があります。ただし、x:ClassModifier ディレクティブを使用することにより、異なるアクセス レベルで定義することもできます。

x:Class 属性のこの解釈は、CLR ベースの XAML の実装 (具体的には .NET XAML サービス) にのみ適用されます。 CLR に基づいておらず、.NET XAML サービスを使用していない他の XAML の実装では、XAML マークアップとバックの実行時コードを結び付けるために、別の解決式が使用されている場合があります。 x:Class のより一般的な解釈の詳細については、[MS-XAML] を参照してください。

アーキテクチャの特定のレベルでは、x:Class の意味が .NET XAML サービスで定義されていません。 これは、.NET XAML サービスでは、XAML マークアップとバッキング コードの接続に使用されるプログラミング モデルが指定されていないためです。 XAML マークアップと CLR ベースのコードビハインドを接続する方法がプログラミング モデルまたはアプリケーション モデルを使用して定義されている特定のフレームワークによって、x:Class ディレクティブの他の使用方法が実装されている場合があります。 フレームワークごとに独自のビルド アクションを使用して、ビルド環境に含まれる必要がある動作または特定のコンポーネントの一部を有効にすることができます。 フレームワーク内では、コードビハインドに使用される特定の CLR 言語に応じて、ビルド アクションが異なる場合もあります。

WPF プログラミング モデルでの x:Class

WPF アプリケーションと WPF アプリケーション モデルでは、XAML ファイルのルートであり、コンパイルされている任意の要素の属性として (XAML が Page ビルド アクションを使用する WPF アプリケーション プロジェクトに含まれる場合)、またはコンパイル済み WPF アプリケーションのアプリケーション定義での Application ルートに対する属性として、x:Class を宣言できます。 ページ ルートまたはアプリケーション ルート以外の要素で、またはコンパイルされていない WPF XAML ファイルで、x:Class を宣言すると、.NET Framework 3.0 および .NET Framework 3.5 の WPF XAML コンパイラではコンパイル時エラーが発生します。 WPF での x:Class の処理に関するその他の側面については、「WPF における分離コードと XAML」を参照してください。

Windows Workflow Foundation の x:Class

Windows Workflow Foundation の場合は、x:Class で、XAML で完全に構成されているカスタム アクティビティのクラスの名前、またはコードビハインドを使用したアクティビティ デザイナー用の XAML ページの部分クラスの名前を指定します。

Silverlight の使用上の注意

Silverlight 用の x:Class に関しては、別途ドキュメントが用意されています。 詳細については、XAML 名前空間 (x:) 言語機能 (Silverlight) に関するページを参照してください。

関連項目

• x:Subclass ディレクティブ
• WPF における XAML とカスタム クラス
• x:ClassModifier ディレクティブ
• WPF から System.Xaml に移行した型