XAML-Namespaces und Namespacezuordnung für WPF-XAML
Aktualisiert: November 2010
In diesem Thema werden das Vorhandensein und der Zweck der beiden XAML-Namespacezuordnungen erläutert, die häufig im Stammtag einer WPF-XAML-Datei enthalten sind. Außerdem wird beschrieben, wie ähnliche Zuordnungen für das Verwenden von Elementen erzeugt werden, die in Ihrem eigenen Code und/oder innerhalb von separaten Assemblys definiert sind.
Dieses Thema enthält folgende Abschnitte.
- Was ist ein XAML-Namespace?
- WPF- und XAML-Namespacedeklarationen
- Zuordnen zu benutzerdefinierten Klassen und Assemblys
- Zuordnen von CLR-Namespaces zu XML-Namespaces in einer Assembly
- Designernamespaces und andere Präfixe aus XAML-Vorlagen
- WPF und Laden von Assemblys
- Verwandte Abschnitte
Was ist ein XAML-Namespace?
Ein XAML-Namespace ist eine Erweiterung des Konzepts eines XML-Namespaces. Die Techniken zum Angeben eines XAML-Namespaces sind abhängig von der XML-Namespacesyntax, der Konvention für die Verwendung von URIs als Namespacebezeichner, der Verwendung von Präfixen zum Verweisen auf mehrere Namespaces aus derselben Markupquelle usw. Das primäre Konzept, das der XAML-Definition des XML-Namespaces hinzugefügt wird, besteht darin, dass ein XAML-Namespace einen Bereich der Eindeutigkeit für die Markupverwendungen bedeutet und außerdem beeinflusst, wie Markupentitäten potenziell von bestimmten CLR-Namespaces und Assemblys, auf die verwiesen wird, unterstützt werden. Die zweite Überlegung wird auch durch das Konzept eines XAML-Schemakontexts beeinflusst. Hinsichtlich der Funktionsweise von WPF mit XAML-Namespaces können Sie sich jedoch im Allgemeinen XAML-Namespaces in Bezug auf einen Standard-XAML-Namespace, den XAML-Sprachnamespace und weitere XAML-Namespaces als bestimmten CLR-Unterstützungsnamespaces und Assemblys, auf die verwiesen wird, von XAML-Markup direkt zugeordnet vorstellen.
WPF- und XAML-Namespacedeklarationen
Innerhalb der Namespacedeklarationen im Stammtag vieler XAML-Dateien sind normalerweise zwei XML-Namespacedeklarationen vorhanden. Die erste Deklaration ordnet den Gesamt-WPF-Client/Framework-XAML-Namespace als Standard zu:
xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
Die zweite Deklaration ordnet einen separaten XAML-Namespace zu und ordnet ihn dabei (in der Regel) dem x:-Präfix zu.
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
Zwischen diesen Deklarationen besteht folgende Beziehung: Die x:-Präfixzuordnung unterstützt die systeminternen Komponenten, die Teil der XAML-Sprachdefinition sind, und WPF ist eine Implementierung, die XAML als Sprache verwendet und ein Vokabular der Objekte für XAML definiert. Da das WPF-Vokabular viel häufiger verwendet wird als die XAML-Interna, wird das WPF-Vokabular als Standard zugeordnet.
Die x:-Präfixkonvention für die Zuordnung der Unterstützung für die systeminternen Funktionen der XAML-Sprache wird von Projektvorlagen, Beispielcode und der Dokumentation der Sprachfeatures in SDK gefolgt. Der XAML-Namespace definiert viele häufig verwendete Features, die auch für grundlegende WPF-Anwendungen notwendig sind. Um beispielsweise Code-Behind mit einer XAML-Datei mittels einer partiellen Klasse zusammenzufügen, müssen Sie diese Klasse als das x:Class-Attribut im Stammelement der relevanten XAML-Datei benennen. Auch sollte für jedes Element, das auf einer XAML-Seite definiert ist, auf die Sie als Ressource mit Schlüssel zugreifen möchten, das x:Key-Attribut für das jeweilige Element festgelegt sein. Weitere Informationen zu diesen und anderen Aspekten von XAML finden Sie unter Übersicht über XAML (WPF) oder Ausführliche Erläuterung der XAML-Syntax.
Zuordnen zu benutzerdefinierten Klassen und Assemblys
Sie können unter Verwendung einer Reihe von Token innerhalb einer xmlns-Präfixdeklaration XML-Namespaces zu Assemblys zuordnen, ähnlich wie der Standard-WPF-Namespace und XAML-Namespace des systeminternen XAML Präfixen zugeordnet werden.
Die Syntax verwendet die folgenden möglichen benannten Token und die folgende Werte:
clr-namespace: Der CLR-Namespace, der innerhalb der Assembly deklariert ist, in der die als Elemente verfügbar gemachten öffentlichen Typen enthalten sind.
assembly= Die Assembly, die einen Teil oder den gesamten CLR-Namespace enthält, auf den verwiesen wird. Dieser Wert ist in der Regel nur der Name der Assembly, nicht der Pfad, und enthält keine Erweiterung (z. B. .dll oder .exe). Der Pfad zu dieser Assembly muss als Projektreferenz in der Projektdatei festgelegt werden, die das XAML enthält, das zugeordnet werden soll. Der assembly-Wert kann eine Zeichenfolge gemäß der Definition durch das AssemblyName-Element sein, um die Versionsverwaltung und die Signierung mit starkem Namen zu integrieren.
Beachten Sie, dass das Token clr-namespace durch einen Doppelpunkt (:) als Trennzeichen von seinem Wert getrennt wird, während das assembly-Token durch ein Gleichheitszeichen (=) als Trennzeichen von seinem Wert getrennt wird. Das zwischen diesen zwei Token zu verwendende Zeichen ist ein Semikolon. Verwenden Sie auch an keiner Stelle in der Deklaration Leerzeichen.
Beispiel für einfache benutzerdefinierte Zuordnung
Der folgende Code definiert ein Beispiel für eine benutzerdefinierte Klasse:
namespace SDKSample {
public class ExampleClass : ContentControl {
public ExampleClass() {
...
}
}
}
Namespace SDKSample
Public Class ExampleClass
Inherits ContentControl
...
Public Sub New()
End Sub
End Class
End Namespace
Diese benutzerdefinierte Klasse wird dann in eine Bibliothek kompiliert, die gemäß den (nicht gezeigten) Projekteinstellungen SDKSampleLibrary genannt wird.
Um auf diese benutzerdefinierte Klasse zu verweisen, müssen Sie sie auch als Verweis für das aktuelle Projekt einschließen. Dazu verwenden Sie in der Regel die Projektmappen-Explorer-Benutzeroberfläche in Visual Studio.
Wenn Sie über eine Bibliothek mit einer Klasse und einen Verweis zur Klasse in den Projekteinstellungen verfügen, können Sie die folgende Präfixzuordnung als Teil des Stammelements in XAML hinzufügen:
xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary"
Um alles zusammensetzen: das Folgende ist XAML, das die benutzerdefinierte Zuordnung mit den typischen Standard- und x:-Zuordnungen im Stammtag enthält und dann einen Verweis mit Präfix verwendet, um ExampleClass in dieser Benutzeroberfläche zu instanziieren:
<Page x:Class="WPFApplication1.MainPage"
xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="https://schemas.microsoft.com/winfx/2006/xaml"
xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary">
...
<custom:ExampleClass/>
...
</Page>
Zuordnen zu aktuellen Assemblys
assembly kann ausgelassen werden, wenn der clr-namespace, auf den verwiesen wird, innerhalb derselben Assembly definiert ist wie der Anwendungscode, der auf die benutzerdefinierten Klassen verweist. Die Syntax kann in diesem Fall auch in der Angabe von assembly= bestehen, ohne dass ein Zeichenfolgetoken auf das Gleichheitszeichen folgt.
Benutzerdefinierte Klassen können nicht als Stammelement einer Seite verwendet werden, wenn sie in derselben Assembly definiert sind. Partielle Klassen müssen nicht zugeordnet werden; nur Klassen, die keine partiellen Klassen einer Seite in einer Anwendung sind, müssen zugeordnet werden, wenn Sie beabsichtigen, diese Klassen als Elemente in XAML zu referenzieren.
Zuordnen von CLR-Namespaces zu XML-Namespaces in einer Assembly
WPF definiert ein CLR-Attribut, das von XAML-Prozessoren verwendet wird, um mehrere CLR-Namespaces einem einzigen XAML-Namespace zuzuordnen. Dieses Attribut, XmlnsDefinitionAttribute, wird auf Assemblyebene in den Quellcode eingefügt, der die Assembly erzeugt. Der WPF-Assembly-Quellcode verwendet dieses Attribut, um die verschiedenen allgemeinen Namespaces, wie z. B. System.Windows und System.Windows.Controls, dem https://schemas.microsoft.com/winfx/2006/xaml/presentation-Namespace zuzuordnen.
Das XmlnsDefinitionAttribute-Element verwendet zwei Parameter, den XML/XAML-Namespacenamen und den CLR-Namespacenamen. Es kann mehr als ein XmlnsDefinitionAttribute-Element vorhanden sein, um mehrere CLR-Namespaces demselben XML-Namespace zuzuordnen. Sobald die Zuordnung erfolgt ist, kann auf Member dieser Namespaces gegebenenfalls auch ohne vollständige Qualifikation verwiesen werden, indem die entsprechende using-Anweisung auf der Code-Behind-Seite der partiellen Klasse hinzugefügt wird. Weitere Informationen finden Sie unter XmlnsDefinitionAttribute.
Designernamespaces und andere Präfixe aus XAML-Vorlagen
Wenn Sie mit Entwicklungsumgebungen und/oder Entwurfstool für WPF-XAML arbeiten, stellen Sie unter Umständen fest, dass es andere definierte XAML-Namespaces/Präfixe innerhalb des XAML-Markups gibt.
WPF Designer für Visual Studio verwendet einen Designernamespace, der normalerweise dem Präfix d: zugeordnet ist. In aktuellen Projektvorlagen für WPF wird dieser XAML-Namespace möglicherweise vorab zugeordnet, um den Austausch von XAML zwischen WPF Designer für Visual Studio und anderen Entwurfsumgebungen zu unterstützen. Dieser Entwurfs-XAML-Namespace wird zum Beibehalten des Entwurfszustands bei Roundtrips XAML-basierter Benutzeroberfläche im Designer verwendet. Er wird außerdem für Funktionen wie d:IsDataSource verwendet, die Laufzeitdatenquellen in einem Designer aktivieren.
Ein anderes Präfix, das möglicherweise zugeordnet wurde, ist mc:. mc: dient der Markupkompatibilität und nutzt ein Markupkompatibilitätsmuster, das nicht unbedingt XAML-spezifisch ist. In gewissem Maße können die Markupkompatibilitätsfunktionen unter anderem dazu verwendet werden, um XAML zwischen Frameworks oder über andere Grenzen der Unterstützungsimplementierung hinweg auszutauschen, zwischen XAML-Schemakontexten zu arbeiten oder Kompatibilität für beschränkte Modi in Designern bereitzustellen. Weitere Informationen zu Markupkompatibilitätskonzepten und deren Bezug auf WPF finden Sie unter Markupkompatibilität (mc:) – Sprachfeatures.
WPF und Laden von Assemblys
Der XAML-Schemakontext für WPF ist in das WPF-Anwendungsmodell integriert, das wiederum das in CLR definierte Konzept von AppDomain verwendet. Die folgende Schrittfolge beschreibt, wie der XAML-Schemakontext basierend auf der WPF-Verwendung von AppDomain und anderen Faktoren bestimmt, wie zur Entwurfszeit oder Laufzeit Assemblys geladen werden oder nach Typen gesucht wird.
Die AppDomain wird durchlaufen, um nach einer bereits geladenen Assembly zu suchen, die mit allen Aspekten des Namens übereinstimmt (beginnend mit der zuletzt geladenen Assembly).
Wenn der Name qualifiziert ist, wird Assembly.Load(String) für den qualifizierten Namen aufgerufen.
Wenn der Kurzname und das öffentliche Schlüsseltoken eines qualifizierten Namens mit der Assembly übereinstimmen, aus der das Markup geladen wurde, wird diese Assembly zurückgegeben.
Der Kurzname und das öffentliche Schlüsseltoken werden verwendet, um Assembly.Load(String) aufzurufen.
Wenn der Name nicht qualifiziert ist, wird Assembly.LoadWithPartialName aufgerufen.
Bei Loose XAML wird Schritt 3 nicht verwendet, da es keine Assembly gibt, aus der Markup geladen wird.
Bei kompiliertem XAML für WPF (generiert mit XamlBuildTask) werden die bereits geladenen Assemblys aus AppDomain nicht verwendet (Schritt 1). Zudem darf der Name aus der XamlBuildTask-Ausgabe niemals nicht qualifiziert sein. Daher gilt Schritt 5 nicht.
Bei kompiliertem BAML (generiert mit PresentationBuildTask) werden alle Schritte verwendet, obwohl BAML keine qualifizierten Assemblynamen enthalten sollte.
Siehe auch
Konzepte
Weitere Ressourcen
Änderungsprotokoll
Datum |
Versionsgeschichte |
Grund |
|---|---|---|
November 2010 |
Ein fehlendes Visual Basic-Beispiel wurde hinzugefügt. |
Korrektur inhaltlicher Fehler. |