x:Class-Direktive

Artikel
05/04/2023

Konfiguriert die XAML-Markupkompilierung, um partielle Klassen zwischen Markup und CodeBehind zu verknüpfen. Die partielle Codeklasse wird in einer separaten Codedatei in einer Common Language Specification(CLS)-Sprache definiert, während die partielle Markupklasse üblicherweise von der Codegenerierung während der XAML-Kompilierung erstellt wird.

Verwendung von XAML-Attributen

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

XAML-Werte

Wert	Beschreibung
`namespace`	Optional. Gibt einen CLR-Namespace an, der die partielle Klasse, die durch `classname` identifiziert wird, enthält. Bei Angabe von `namespace` werden `namespace` und `classname` durch einen Punkt (.) getrennt. Siehe Hinweise.
`classname`	Erforderlich. Gibt den CLR-Namen der partiellen Klasse an, die das geladene XAML und Ihr CodeBehind für dieses XAML verbindet.

Abhängigkeiten

x:Class kann nur für das Stammelement der 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] Abschnitt 6.3.1.6.

Hinweise

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

In vorhandenen Programmiermodellen, die x:Class verwenden, ist x:Class optional in dem Sinne, dass es vollständig gültig ist, eine XAML-Seite ohne CodeBehind zu erstellen. Diese Funktionalität interagiert jedoch mit den Buildaktionen, die von Frameworks implementiert werden, die XAML verwenden. Die x:Class-Funktion wird auch von den Rollen beeinflusst, die verschiedene Klassifizierungen von mit XAML spezifizierten Inhalten in einem Anwendungsmodell und in den entsprechenden Buildaktionen haben. Wenn Ihr XAML Attributwerte zur Ereignisbehandlung deklariert oder benutzerdefinierte Elemente instanziiert, bei denen sich die definierenden Klassen in der CodeBehind-Klasse befinden, müssen Sie den Anweisungsverweis x:Class (oder x:Subclass) für die entsprechende Klasse für CodeBehind bereitstellen.

Der Wert der x:Class-Anweisung muss eine Zeichenfolge sein, die den vollqualifizierten Namen einer Klasse angibt, aber ohne Assemblyinformationen (entspricht dem Type.FullName). Für einfache Anwendungen können Sie CLR-Namespaceinformationen auslassen, wenn der CodeBehind auch auf diese Weise strukturiert ist (Codedefinition beginnt auf Klassenebene).

Die CodeBehind-Datei für eine Seiten- oder Anwendungsdefinition muss sich in einer als Teil des Projekts enthaltenen Codedatei befinden, die eine kompilierte Anwendung erzeugt und bei der Markupkompilierung. Sie müssen Namensregeln für CLR-Klassen befolgen. Weitere Informationen finden Sie unter Frameworkentwurfsrichtlinien. Standardmäßig muss public die CodeBehind-Klasse sein. Sie können sie jedoch auf einer anderen Zugriffsebene definieren, indem Sie die x:ClassModifier-Anweisung verwenden.

Diese Interpretation des x:Class-Attributs gilt nur für eine CLR-basierte XAML-Implementierung, insbesondere für .NET XAML Services. 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 unterstützendem Laufzeitcode. Weitere Informationen zu allgemeineren Interpretationen von x:Class finden Sie unter [MS-XAML].

Auf einer bestimmten Ebene der Architektur ist die Bedeutung von x:Class in .NET XAML-Diensten nicht definiert. Dies liegt daran, dass .NET XAML Services nicht das Programmiermodell spezifiziert, durch das XAML-Markup und unterstützender Code verbunden sind. Zusätzliche Verwendungen der x:Class-Anweisung können durch bestimmte 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 einige der Verhalten oder spezifischen Komponenten ermöglichen, die in der Buildumgebung enthalten sein müssen. Innerhalb eines Frameworks können Buildaktionen auch je nach der spezifischen CLR-Sprache variieren, die für den CodeBehind verwendet wird.

x:Class im WPF-Programmiermodell

In WPF-Anwendungen und dem WPF-Anwendungsmodell kann x:Class als Attribut für jedes Element deklariert werden, das der Stamm einer XAML-Datei ist und kompiliert wird (wenn der XAML-Code in einem WPF-Anwendungsprojekt mit der Buildaktion Page enthalten ist) oder für den Application-Stamm in der Anwendungsdefinition einer kompilierten WPF-Anwendung. Das Deklarieren von x:Class für ein anderes Element als einen Seiten- oder Anwendungsstamm oder eine WPF-XAML-Datei, die nicht kompiliert ist, verursacht einen Kompilierzeitfehler unter dem .NET Framework 3.0- und .NET Framework 3.5-WPF-XAML-Compiler. Weitere Informationen zur Handhabung von x:Class in WPF finden Sie unter CodeBehind und XAML in WPF.

x:Class für Windows Workflow Foundation

In Windows Workflow Foundation benennt x:Class die Klasse einer benutzerdefinierten Aktivität, die vollständig in XAML erstellt wurde, oder benannt die Teilklasse der XAML-Seite für einen Aktivitätsdesigner mit CodeBehind.

Silverlight-Verwendungshinweise

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

Freigeben über