XAML-Namespaces und Namespacezuordnung für WPF-XAML

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.

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="http://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="http://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.

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

namespace SDKSample {
    public class ExampleClass : ContentControl {
        public ExampleClass() {
        ...
        }
    }
}

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

Zuordnen zu aktuellen Assemblys

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 http://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.

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.

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.

1. 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).

2. Wenn der Name qualifiziert ist, wird Assembly.Load(String) für den qualifizierten Namen aufgerufen.

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

4. Der Kurzname und das öffentliche Schlüsseltoken werden verwendet, um Assembly.Load(String) aufzurufen.

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

Konzepte

Weitere Ressourcen