Freigeben über

x:Class Directive

  • Artikel

Konfiguriert die XAML-Markupkompilierung, um partielle Klassen zwischen Markup und CodeBehind zu verbinden. Die Partielle Codeklasse wird in einer separaten Codedatei in einer CLS-Sprache (Common Language Specification) definiert, während die Markupteilklasse in der Regel während der XAML-Kompilierung von Code generiert wird.

XAML-Attributverwendung

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

XAML-Werte

Wert Beschreibung
namespace Wahlfrei. Gibt einen CLR-Namespace an, der die durch classnameidentifizierte Partielle Klasse enthält. Wenn namespace angegeben ist, trennt ein Punkt (.) namespace und classname. Siehe Anmerkungen.
classname Erforderlich. Gibt den CLR-Namen der partiellen Klasse an, die den geladenen XAML-Code und den CodeBehind für diesen XAML-Code verbindet.

Abhängigkeiten

x:Class kann nur für das Stammelement einer XAML-Produktion angegeben werden. x:Class ist für jedes Objekt ungültig, das über ein übergeordnetes Objekt in der XAML-Produktion verfügt. Weitere Informationen finden Sie unter [MS-XAML] Section 6.3.1.6.

Bemerkungen

Der namespace-Wert kann zusätzliche Punkte enthalten, um verwandte Namespaces in Namenshierarchien zu organisieren, was eine gängige Technik in der .NET-Programmierung ist. Nur der letzte Punkt in einer Zeichenfolge von x:Class Werten wird interpretiert, um namespace zu trennen und classname. Die Klasse, die als x:Class verwendet wird, kann keine geschachtelte Klasse sein. Geschachtelte Klassen sind nicht zulässig, da das Bestimmen der Bedeutung von Punkten für x:Class Zeichenfolgen mehrdeutig ist, wenn geschachtelte Klassen zulässig sind.

In vorhandenen Programmiermodellen, die x:Classverwenden, ist x:Class optional, da sie vollständig gültig ist, um eine XAML-Seite ohne CodeBehind zu verwenden. Diese Funktion interagiert jedoch mit den Buildaktionen, die von Frameworks implementiert werden, die XAML verwenden. x:Class Funktion wird auch von den Rollen beeinflusst, die verschiedene Klassifizierungen von XAML-angegebenen Inhalten in einem Anwendungsmodell und in den entsprechenden Buildaktionen aufweisen. Wenn Ihr XAML Attributwerte für die Ereignisbehandlung deklariert oder benutzerdefinierte Elemente instanziiert, bei denen sich die definierenden Klassen in der CodeBehind-Klasse befinden, müssen Sie den x:Class Direktivenverweis (oder x:Subclass) der entsprechenden Klasse für CodeBehind bereitstellen.

Der Wert der x:Class-Direktive muss eine Zeichenfolge sein, die den vollqualifizierten Namen einer Klasse, jedoch ohne Assemblyinformationen (entspricht dem Type.FullName) angibt. Bei einfachen Anwendungen können Sie CLR-Namespaceinformationen weglassen, wenn der CodeBehind auch auf diese Weise strukturiert ist (Codedefinition beginnt auf Klassenebene).

Die CodeBehind-Datei für eine Seite oder Anwendungsdefinition muss sich in einer Codedatei befinden, die als Teil des Projekts enthalten ist, das eine kompilierte Anwendung erzeugt und die Markupkompilierung umfasst. Sie müssen Namensregeln für CLR-Klassen befolgen. Weitere Informationen finden Sie unter Framework Design Guidelines. Standardmäßig muss die CodeBehind-Klasse publicsein; Sie können sie jedoch auf einer anderen Zugriffsebene definieren, indem Sie die x:ClassModifier-Direktiveverwenden.

Diese Interpretation des attributs x:Class gilt nur für eine CLR-basierte XAML-Implementierung, insbesondere für .NET XAML-Dienste. Andere XAML-Implementierungen, die nicht auf CLR basieren und nicht .NET XAML Services verwenden, verwenden möglicherweise eine andere Auflösungsformel zum Verbinden von XAML-Markup und Sichern von Laufzeitcode. Weitere Informationen zu allgemeineren Interpretationen von x:Classfinden Sie unter [MS-XAML].

Auf einer bestimmten Architekturebene ist die Bedeutung von x:Class in .NET XAML-Diensten nicht definiert. Dies liegt daran, dass .NET XAML Services nicht das Programmiermodell angibt, mit dem XAML-Markup und Sicherungscode verbunden sind. Zusätzliche Verwendungen der x:Class-Direktive können von bestimmten Frameworks implementiert werden, die Programmiermodelle oder Anwendungsmodelle verwenden, um zu definieren, wie XAML-Markup und CLR-basierter CodeBehind verbunden werden. Jedes Framework kann über eigene Buildaktionen verfügen, die ein bestimmtes Verhalten oder bestimmte Komponenten aktivieren, die in der Buildumgebung enthalten sein müssen. Innerhalb eines Frameworks können Buildaktionen auch abhängig von der spezifischen CLR-Sprache variieren, die für den CodeBehind verwendet wird.

x:Class im WPF-Programmiermodell

In WPF-Anwendungen und dem WPF-Anwendungsmodell können x:Class als Attribut für jedes Element deklariert werden, das der Stamm einer XAML-Datei ist und kompiliert wird (wobei der XAML-Code in einem WPF-Anwendungsprojekt mit Page Buildaktion enthalten ist) oder für den Application Stamm in der Anwendungsdefinition einer kompilierten WPF-Anwendung. Das Deklarieren von x:Class in einem anderen Element als einem Seitenstamm oder Anwendungsstamm oder in einer nicht kompilierten WPF-XAML-Datei führt zu einem Kompilierungsfehler unter .NET Framework 3.0 und .NET Framework 3.5 WPF XAML-Compiler. Informationen zu anderen Aspekten der x:Class Behandlung in WPF finden Sie unter Code-Behind und XAML in WPF-.

x:Class für Windows Workflow Foundation

Bei Windows Workflow Foundation benennt x:Class die Klasse einer benutzerdefinierten Aktivität, die vollständig in XAML verfasst wurde, oder benennt die partielle Klasse der XAML-Seite für einen Aktivitäts-Designer mit CodeBehind.

Silverlight-Verwendungshinweise

x:Class für Silverlight wird separat dokumentiert. Weitere Informationen finden Sie unter XAML-Namespace (x:) Language Features (Silverlight).

Siehe auch