Freigeben über

XAML-Namespaces und Namespacemapping für WPF-XAML

In diesem Thema werden außerdem die Anwesenheit und der Zweck der beiden XAML-Namespacezuordnungen erläutert, die häufig im Stammtag einer WPF-XAML-Datei zu finden sind. Außerdem wird beschrieben, wie ähnliche Zuordnungen für die Verwendung von Elementen erstellt werden, die in Ihrem eigenen Code und/oder in separaten Assemblys definiert sind.

Was ist ein XAML-Namespace?

Ein XAML-Namespace ist wirklich eine Erweiterung des Konzepts eines XML-Namespace. Die Techniken zum Angeben eines XAML-Namespaces basieren auf der XML-Namespacesyntax, der Konvention der Verwendung von URIs als Namespacebezeichner und das Verwenden von Präfixen, um auf mehrere Namespaces aus derselben Markupquelle zu verweisen, und so weiter. Das primäre Konzept, das der XAML-Definition des XML-Namespace hinzugefügt wird, besteht darin, dass ein XAML-Namespace sowohl einen Bereich der Eindeutigkeit für die Markupverwendungen impliziert, als auch beeinflusst, wie Markupentitäten potenziell durch bestimmte CLR-Namespaces und referenzierte Assemblys gesichert werden. Letzteres wird auch durch das Konzept eines XAML-Schemakontexts beeinflusst. Für die 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 alle weiteren XAML-Namespaces vorstellen, die ihrem XAML-Markup direkt bestimmten zugrunde stehenden CLR-Namespaces und referenzierten Assemblys zugeordnet werden.

Die WPF- und XAML-Namespacedeklarationen

Innerhalb der Namespacedeklarationen im Stammtag vieler XAML-Dateien sehen Sie, dass es in der Regel zwei XML-Namespacedeklarationen gibt. Die erste Deklaration legt den WPF-Client-/Framework-XAML-Namespace als Standard fest.

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Die zweite Deklaration ordnet einen separaten XAML-Namespace zu und ordnet ihn (in der Regel) dem x: Präfix zu.

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Die Beziehung zwischen diesen Deklarationen besteht darin, dass die x: Präfixzuordnung die systeminternen Elemente unterstützt, die Teil der XAML-Sprachdefinition sind, und WPF ist eine Implementierung, die XAML als Sprache verwendet und ein Vokabular seiner Objekte für XAML definiert. Da die Verwendungen des WPF-Vokabulars wesentlich häufiger sind als die systeminternen XAML-Verwendungen, wird das WPF-Vokabular als Standard zugeordnet.

Projektvorlagen, Beispielcode und die Dokumentation von Sprachmerkmalen in diesem SDK folgen der Präfixkonvention x: zur Zuordnung der XAML-Sprachintrinsik. Der XAML-Namespace definiert viele häufig verwendete Features, die auch für grundlegende WPF-Anwendungen erforderlich sind. Um beispielsweise CodeBehind mit einer XAML-Datei über eine partielle Klasse zu verbinden, müssen Sie diese Klasse als x:Class Attribut im Stammelement der relevanten XAML-Datei benennen. Oder jedes Element, das in einer XAML-Seite definiert ist, auf die Sie als Schlüsselressource zugreifen möchten, sollte das x:Key Attribut für das betreffende Element festgelegt haben. Weitere Informationen zu diesen und anderen Aspekten von XAML finden Sie unter XAML in WPF oder XAML-Syntax im Detail.

Zuordnung zu benutzerdefinierten Klassen und Assemblys

Sie können XML-Namespaces mithilfe einer Reihe von Token in einer xmlns-Präfixdeklaration Assemblys zuordnen, ähnlich wie die Standard-WPF- und XAML-intrinsischen XAML-Namespaces Präfixen zugeordnet werden.

Die Syntax verwendet die folgenden möglichen benannten Token und die folgenden Werte:

clr-namespace: Der CLR-Namespace, der innerhalb der Assembly deklariert ist, die die öffentlichen Typen enthält, die als Elemente verfügbar gemacht werden sollen.

assembly= Die Assembly, die einen oder alle referenzierten CLR-Namespace enthält. Dieser Wert ist in der Regel nur der Name der Assembly, nicht der Pfad, und enthält nicht die Erweiterung (z. B. .dll oder .exe). Der Pfad zu dieser Assembly muss als Projektverweis in der Projektdatei eingerichtet werden, die den XAML-Code enthält, den Sie zuordnen möchten. Um eine Versionsverwaltung und starke Namenssignatur einzufügen, kann der assembly-Wert eine Zeichenfolge sein, wie sie von AssemblyName definiert ist, anstatt nur ein einfacher Zeichenfolgenname.

Beachten Sie, dass das Zeichen, das das clr-namespace Token von seinem Wert trennt, ein Doppelpunkt ist (:), während das Zeichen, das das assembly Token von seinem Wert trennt, ein Gleichheitszeichen (=) ist. Das Zeichen, das zwischen diesen beiden Token verwendet werden soll, ist ein Semikolon. Schließen Sie in der Deklaration auch keine Leerzeichen ein.

Beispiel für eine einfache benutzerdefinierte Zuordnung

Der folgende Code definiert eine benutzerdefinierte Beispielklasse:

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 Projekteinstellungen (nicht angezeigt) benannt SDKSampleLibrarywird.

Um auf diese benutzerdefinierte Klasse zu verweisen, müssen Sie sie auch als Referenz für Ihr aktuelles Projekt einschließen, das Sie in der Regel mit der Benutzeroberfläche des Projektmappen-Explorers in Visual Studio verwenden würden.

Nachdem Sie nun eine Bibliothek mit einer Klasse und einen Verweis darauf in den Projekteinstellungen haben, können Sie die folgende Präfixzuordnung als Teil des Stammelements in XAML hinzufügen:

xmlns:custom="clr-namespace:SDKSample;assembly=SDKSampleLibrary"

Um alles zusammenzuführen, ist im Folgenden XAML dargestellt, das die benutzerdefinierte Zuordnung zusammen mit den typischen Standard- und x-Zuordnungen im Stammtag enthält, und dann einen mit Präfix versehenen Verweis verwendet, um ExampleClass in dieser Benutzeroberfläche zu instanziieren.

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

Zuordnung zu aktuellen Assemblys

assembly kann weggelassen werden, wenn der clr-namespace Verweis innerhalb derselben Assembly definiert wird wie der Anwendungscode, der auf die benutzerdefinierten Klassen verweist. Oder ist es eine entsprechende Syntax für diesen Fall, assembly= anzugeben, ohne dass nach dem Gleichheitszeichen ein Zeichenfolgentoken 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 nicht die partielle Klasse einer Seite in Ihrer Anwendung sind, müssen zugeordnet werden, wenn Sie sie als Elemente in XAML referenzieren möchten.

Zuordnen von CLR-Namespaces zu XML-Namespaces in einer Assembly

WPF definiert ein CLR-Attribut, das von XAML-Prozessoren genutzt wird, um mehrere CLR-Namespaces einem einzelnen XAML-Namespace zuzuordnen. Dieses Attribut wird XmlnsDefinitionAttributeauf Assemblyebene im Quellcode platziert, 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.

Dies XmlnsDefinitionAttribute umfasst zwei Parameter: den XML/XAML-Namespacenamen und den CLR-Namespacenamen. XmlnsDefinitionAttribute Es können mehrere CLR-Namespaces demselben XML-Namespace zugeordnet werden. Nach der Zuordnung können Elemente dieser Namespaces bei Bedarf auch ohne vollständige Qualifikation referenziert werden, indem die entsprechende using Anweisung in der partiellen Code-Behind-Seite bereitgestellt wird. Weitere Details finden Sie unter XmlnsDefinitionAttribute.

Designernamespaces und andere Präfixe aus XAML-Vorlagen

Wenn Sie mit Entwicklungsumgebungen und/oder Entwurfstools für WPF-XAML arbeiten, stellen Sie möglicherweise fest, dass im XAML-Markup andere definierte XAML-Namespaces/Präfixe vorhanden sind.

WPF Designer für Visual Studio verwendet einen Designernamespace, der in der Regel dem Präfix d:zugeordnet ist. Neuere Projektvorlagen für WPF können diesen XAML-Namespace vorab zuordnen, um den Austausch von XAML zwischen WPF Designer für Visual Studio und anderen Entwurfsumgebungen zu unterstützen. Dieser XAML-Design-Namespace wird verwendet, um den Entwurfszustand zu bewahren, während XAML-basierte UI im Designer hin- und hergeschickt wird. Sie wird auch für Features wie d:IsDataSourcez. B. verwendet, die Laufzeitdatenquellen in einem Designer aktivieren.

Ein weiteres Präfix, das möglicherweise angezeigt wird, ist mc:. mc: ist für die Markupkompatibilität vorgesehen und nutzt ein Markupkompatibilitätsmuster, das nicht unbedingt XAML-spezifisch ist. In einigen Fällen können die Markupkompatibilitätsfeatures verwendet werden, um XAML zwischen Frameworks oder über andere Grenzen der Sicherungsimplementierung auszutauschen, zwischen XAML-Schemakontexten zu arbeiten, Kompatibilität für eingeschränkte Modi in Designern usw. bereitzustellen. Weitere Informationen zu Markupkompatibilitätskonzepten und deren Beziehung zu WPF finden Sie unter Features für die Markupkompatibilität (mc:) Language.

Laden von WPF und Assembly

Der XAML-Schemakontext für WPF ist in das WPF-Anwendungsmodell integriert, das wiederum das CLR-definierte Konzept verwendet AppDomain. Die folgende Sequenz beschreibt, wie der XAML-Schemakontext interpretiert, wie Assemblies geladen oder Typen zur Laufzeit oder Entwurfszeit gefunden werden, basierend auf der Verwendung von AppDomain sowie anderen Faktoren in WPF.

  1. Durchlaufen Sie die AppDomainBereits geladene Assembly, die allen Aspekten des Namens entspricht, beginnend mit der zuletzt geladenen Assembly.

  2. Wenn der Name qualifiziert ist, rufen Sie Assembly.Load(String) den qualifizierten Namen auf.

  3. Wenn der Kurzname + das öffentliche Schlüsseltoken eines qualifizierten Namens mit der Assembly übereinstimmt, aus der das Markup geladen wurde, geben Sie diese Assembly zurück.

  4. Verwenden Sie den Kurznamen + das öffentliche Schlüsseltoken, um Assembly.Load(String) aufzurufen.

  5. Wenn der Name nicht qualifiziert ist, rufen Sie auf Assembly.LoadWithPartialName.

Loose XAML verwendet Schritt 3 nicht; es gibt keine aus einer Assembly geladene Komponente.

Kompiliertes XAML für WPF (generiert über XamlBuildTask) verwendet nicht die bereits geladenen Assemblys aus AppDomain (Schritt 1). Außerdem sollte der Name niemals von der XamlBuildTask-Ausgabe nicht qualifiziert werden, sodass Schritt 5 nicht angewendet wird.

Kompilierte BAML (generiert über PresentationBuildTask) verwendet alle Schritte, obwohl BAML auch keine nicht qualifizierten Assemblynamen enthalten sollte.

Siehe auch