Freigeben über

XAML-Namespaces und Namespacezuordnung

  • Artikel

In diesem Thema werden die XML/XAML-Namespacezuordnungen erläutert, die im Stammelement der meisten XAML-Dateien zu finden sind. Außerdem wird beschrieben, wie ähnliche Zuordnungen für benutzerdefinierte Typen und Assemblys erstellt werden.

Beziehung zwischen XAML-Namespaces und Codedefinitions- und Typbibliotheken

Sowohl in ihrem allgemeinen Zweck als auch für die Anwendung zur Windows-Runtime App-Programmierung wird XAML verwendet, um Objekte, Eigenschaften dieser Objekte und Objekteigenschaftsbeziehungen zu deklarieren, die als Hierarchien ausgedrückt werden. Die in XAML deklarierten Objekte werden durch Typbibliotheken oder andere Darstellungen unterstützt, die durch andere Programmiertechniken und Sprachen definiert werden. Folgende Bibliotheken können sein:

  • Die integrierte Gruppe von Objekten für die Windows-Runtime. Dies ist ein fester Satz von Objekten, und der Zugriff auf diese Objekte aus XAML verwendet interne Typzuordnungs- und Aktivierungslogik.
  • Verteilte Bibliotheken, die entweder von Microsoft oder von Dritten bereitgestellt werden.
  • Bibliotheken, die die Definition eines Drittanbietersteuerelements darstellen, das Ihre App enthält, und das Paket weiterverteilt.
  • Ihre eigene Bibliothek, die Teil Ihres Projekts ist und einige oder alle Ihre Benutzercodedefinitionen enthält.

Hintergrundtypinformationen sind bestimmten XAML-Namespacedefinitionen zugeordnet. XAML-Frameworks wie die Windows-Runtime können mehrere Assemblys und mehrere Codenamespaces aggregieren, um einem einzelnen XAML-Namespace zuzuordnen. Dies ermöglicht das Konzept eines XAML-Vokabulars, das ein größeres Programmierframework oder eine größere Technologie abdeckt. Ein XAML-Vokabular kann recht umfangreich sein, z. B. die meisten xaml-Dokumente für Windows-Runtime Apps in dieser Referenz stellen ein einzelnes XAML-Vokabular dar. Ein XAML-Vokabular ist auch erweiterbar: Sie erweitern es durch Hinzufügen von Typen zu den zugrunde stehenden Codedefinitionen, um sicherzustellen, dass die Typen in Codenamespaces eingeschlossen werden, die bereits als zugeordnete Namespacequellen für das XAML-Vokabular verwendet werden.

Ein XAML-Prozessor kann Typen und Member aus den diesem XAML-Namespace zugeordneten Sicherungsassemblys nachschlagen, wenn eine Laufzeitobjektdarstellung erstellt wird. Aus diesem Grund ist XAML nützlich, um Definitionen des Objektkonstruktionsverhaltens zu formalisieren und auszutauschen, und warum XAML als UI-Definitionstechnik für eine UWP-App verwendet wird.

XAML-Namespaces in typischer XAML-Markupverwendung

Eine XAML-Datei deklariert fast immer einen standardmäßigen XAML-Namespace im Stammelement. Der standardmäßige XAML-Namespace definiert, welche Elemente Sie deklarieren können, ohne sie durch ein Präfix zu qualifizieren. Wenn Sie z. B. ein Element <Balloon />deklarieren, erwartet ein XAML-Parser, dass eine Elementsprechblase vorhanden ist und im Standardmäßigen XAML-Namespace gültig ist. Wenn sich die Sprechblase dagegen nicht im definierten STANDARD-XAML-Namespace befindet, müssen Sie stattdessen diesen Elementnamen mit einem Präfix qualifizieren, z<party:Balloon />. B. . Das Präfix gibt an, dass das Element in einem anderen XAML-Namespace vorhanden ist als der Standardnamespace, und Sie müssen dem Präfixanbieter einen XAML-Namespace zuordnen, bevor Sie dieses Element verwenden können. XAML-Namespaces gelten für das spezifische Element, für das sie deklariert sind, und auch für jedes Element, das in der XAML-Struktur enthalten ist. Aus diesem Grund werden XAML-Namespaces fast immer für Stammelemente einer XAML-Datei deklariert, um diese Vererbung zu nutzen.

Die XAML-Namespacedeklarationen der Standard- und XAML-Sprache

Innerhalb des Stammelements der meisten XAML-Dateien gibt es zwei XMLns-Deklarationen . Die erste Deklaration ordnet einen XAML-Namespace als Standard zu: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Dies ist der gleiche XAML-Namespacebezeichner, der in mehreren Vorgängertechnologien von Microsoft verwendet wird, die auch XAML als Markupformat für DIE UI-Definition verwenden. Die Verwendung desselben Bezeichners ist bewusst und ist hilfreich, wenn Sie zuvor definierte Ui zu einer Windows-Runtime App mit C++, C# oder Visual Basic migrieren.

Die zweite Deklaration ordnet einen separaten XAML-Namespace für die XAML-definierten Sprachelemente zu, wobei sie (in der Regel) dem Präfix "x:" zugeordnet wird: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Dieser XMLns-Wert und das Präfix "x:" ist ebenfalls identisch mit den Definitionen, die in mehreren Vorgängertechnologien von Microsoft verwendet werden, die XAML verwenden.

Die Beziehung zwischen diesen Deklarationen besteht darin, dass XAML eine Sprachdefinition ist und die Windows-Runtime eine Implementierung ist, die XAML als Sprache verwendet und ein bestimmtes Vokabular definiert, auf das in XAML verwiesen wird.

Die XAML-Sprache gibt bestimmte Sprachelemente an, und jeder dieser Elemente sollte über XAML-Prozessorimplementierungen zugänglich sein, die mit dem XAML-Namespace arbeiten. Auf die Zuordnungskonvention "x:" für den XAML-Sprach-XAML-Namespace folgen Projektvorlagen, Beispielcode und die Dokumentation für Sprachfeatures. Der XAML-Sprachnamespace definiert mehrere häufig verwendete Features, die auch für einfache Windows-Runtime Apps mit C++, C# oder Visual Basic erforderlich sind. Um z. B. 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 als Schlüsselressource in einem ResourceDictionary- und XAML-Ressourcenverweise definiert ist, muss das x:Key-Attribut für das betreffende Objektelement festgelegt sein.

Codenamespaces, die dem standardmäßigen XAML-Namespace zugeordnet sind

Es folgt eine Liste der Codenamespaces, die derzeit dem standardmäßigen XAML-Namespace zugeordnet sind.

  • Windows.UI
  • Windows.UI.Xaml
  • Windows.UI.Xaml.Automation
  • Windows.UI.Xaml.Automation.Peers
  • Windows.UI.Xaml.Automation.Provider
  • Windows.UI.Xaml.Automation.Text
  • Windows.UI.Xaml.Controls
  • Windows.UI.Xaml.Controls.Primitives
  • Windows.UI.Xaml.Data
  • Windows.UI.Xaml.Documents
  • Windows.UI.Xaml.Input
  • Windows.UI.Xaml.Interop
  • Windows.UI.Xaml.Markup
  • Windows.UI.Xaml.Media
  • Windows.UI.Xaml.Media.Animation
  • Windows.UI.Xaml.Media.Imaging
  • Windows.UI.Xaml.Media.Media3D
  • Windows.UI.Xaml.Navigation
  • Windows.UI.Xaml.Resources
  • Windows.UI.Xaml.Shapes
  • Windows.UI.Xaml.Threading
  • Windows.UI.Text

Andere XAML-Namespaces

Zusätzlich zum Standardnamespace und dem XAML-Sprach-XAML-Namespace "x:" werden möglicherweise auch andere zugeordnete XAML-Namespaces im anfänglichen Standard-XAML für Apps angezeigt, die von Microsoft Visual Studio generiert werden.

d: (http://schemas.microsoft.com/expression/blend/2008)

Der "d:"-XAML-Namespace ist für die Designerunterstützung vorgesehen, insbesondere die Designerunterstützung in den XAML-Entwurfsoberflächen von Microsoft Visual Studio. Der "d:"-XAML-Namespace ermöglicht Designer- oder Entwurfszeitattribute für XAML-Elemente. Diese Designerattribute wirken sich nur auf die Entwurfsaspekte der Funktionsweise von XAML aus. Die Designerattribute werden ignoriert, wenn derselbe XAML-Code vom Windows-Runtime XAML-Parser geladen wird, wenn eine App ausgeführt wird. Im Allgemeinen sind die Designerattribute für jedes XAML-Element gültig, aber in der Praxis gibt es nur bestimmte Szenarien, in denen das Anwenden eines Designer-Attributs selbst geeignet ist. Insbesondere sollen viele der Designerattribute eine bessere Erfahrung für die Interaktion mit Datenkontexten und Datenquellen bieten, während Sie XAML und Code entwickeln, die datenbindung verwenden.

  • d:DesignHeight- und d:DesignWidth-Attribute: Diese Attribute werden manchmal auf den Stamm einer XAML-Datei angewendet, die Visual Studio oder eine andere XAML-Designeroberfläche für Sie erstellt. Diese Attribute werden beispielsweise im UserControl-Stammverzeichnis des XAML-Codes festgelegt, das erstellt wird, wenn Sie Ihrem App-Projekt ein neues UserControl-Objekt hinzufügen. Diese Attribute vereinfachen das Entwerfen der Komposition des XAML-Inhalts, sodass Sie die Layouteinschränkungen erwarten, die möglicherweise vorhanden sind, sobald der XAML-Inhalt für eine Steuerelementinstanz oder einen anderen Teil einer größeren UI-Seite verwendet wird.

Hinweis : Wenn Sie XAML aus Microsoft Silverlight migrieren, verfügen Sie möglicherweise über diese Attribute für Stammelemente, die eine gesamte UI-Seite darstellen. Möglicherweise möchten Sie die Attribute in diesem Fall entfernen. Andere Features der XAML-Designer wie der Simulator sind wahrscheinlich nützlicher für das Entwerfen von Seitenlayouts, die Skalierungs- und Ansichtszustände gut verarbeiten, als ein Seitenlayout mit fester Größe mit d:DesignHeight und d:DesignWidth.

  • d:DataContext-Attribut: Sie können dieses Attribut auf einem Seitenstamm oder einem Steuerelement festlegen, um explizite oder geerbte DataContext außer Kraft zu setzen, über die das Objekt andernfalls verfügt.
  • d:DesignSource-Attribut: Gibt eine Entwurfszeit-Datenquelle für eine CollectionViewSource an, die Quelle überschreibt.
  • d:DesignInstance und d:DesignData-Markuperweiterungen: Diese Markuperweiterungen werden verwendet, um die Entwurfszeitdatenressourcen für d:DataContext oder d:DesignSource bereitzustellen. Wir werden hier nicht vollständig dokumentieren, wie Entwurfszeitdatenressourcen verwendet werden. Weitere Informationen finden Sie unter Designzeitattribute. Einige Verwendungsbeispiele finden Sie unter Beispieldaten auf der Entwurfsoberfläche und zur Prototyperstellung.

mc: (http://schemas.openxmlformats.org/markup-compatibility/2006)

"mc:" gibt einen Markupkompatibilitätsmodus zum Lesen von XAML an und unterstützt sie. In der Regel ist das Präfix "d:" dem Attribut mc:Ignorable zugeordnet. Mit dieser Technik können Laufzeit-XAML-Parser die Entwurfsattribute in "d:" ignorieren.

lokal: und häufig:

"local:" ist ein Präfix, das häufig innerhalb der XAML-Seiten für ein vorlagenbasiertes UWP-App-Projekt zugeordnet wird. Es ist zugeordnet, um auf denselben Namespace zu verweisen, der erstellt wird, um das x:Class-Attribut und Code für alle XAML-Dateien einschließlich "app.xaml" zu enthalten. Solange Sie benutzerdefinierte Klassen definieren, die Sie in XAML in diesem Namespace verwenden möchten, können Sie das lokale Präfix verwenden, um auf Ihre benutzerdefinierten Typen in XAML zu verweisen. Ein verwandtes Präfix, das aus einem vorlagenbasierten UWP-App-Projekt stammt, ist häufig:. Dieses Präfix bezieht sich auf einen geschachtelten "Common"-Namespace, der Hilfsklassen wie Konverter und Befehle enthält, und Sie finden die Definitionen im gemeinsamen Ordner in der ansicht Projektmappen-Explorer.

vsm:

Nicht verwenden.. "vsm:" ist ein Präfix, das manchmal in älteren XAML-Vorlagen angezeigt wird, die aus anderen Microsoft-Technologien importiert wurden. Der Namespace hat ursprünglich ein Problem mit legacy-Namespace-Tools behoben. Sie sollten XAML-Namespacedefinitionen für "vsm:" in jedem XAML-Code löschen, den Sie für die Windows-Runtime verwenden, und alle Präfixverwendungen für VisualState, VisualStateGroup und zugehörige Objekte ändern, um stattdessen den standardmäßigen XAML-Namespace zu verwenden. Weitere Informationen zur XAML-Migration finden Sie unter Migrieren von Silverlight oder WPF-XAML/Code zu einer Windows-Runtime-App.

Zuordnen von benutzerdefinierten Typen zu XAML-Namespaces und Präfixen

Sie können einen XAML-Namespace zuordnen, sodass Sie XAML für den Zugriff auf Ihre eigenen benutzerdefinierten Typen verwenden können. Anders ausgedrückt: Sie ordnen einen Codenamespace zu, da er in einer Codedarstellung vorhanden ist, die den benutzerdefinierten Typ definiert, und ihm einen XAML-Namespace zusammen mit einem Präfix für die Verwendung zuweist. Benutzerdefinierte Typen für XAML können entweder in einer Microsoft .NET-Sprache (C# oder Microsoft Visual Basic) oder in C++ definiert werden. Die Zuordnung erfolgt durch Definieren eines XMLns-Präfixes . Definiert beispielsweise einen neuen XAML-Namespace, auf den zugegriffen wird, xmlns:myTypes indem alle Verwendungen dem Token myTypes:vorangestellt werden.

Eine XMLns-Definition enthält einen Wert sowie die Präfixbenennung. Der Wert ist eine Zeichenfolge, die sich innerhalb von Anführungszeichen befindet und auf ein Gleichheitszeichen folgt. Eine allgemeine XML-Konvention besteht darin, den XML-Namespace einem Uniform Resource Identifier (URI) zuzuordnen, sodass es eine Konvention für Eindeutigkeit und Identifikation gibt. Sie sehen auch diese Konvention für den Standard-XAML-Namespace und den XAML-Sprach-XAML-Namespace sowie für einige weniger verwendete XAML-Namespaces, die von Windows-Runtime XAML verwendet werden. Aber für einen XAML-Namespace, der benutzerdefinierte Typen zuordnet, anstatt einen URI anzugeben, beginnen Sie mit der Präfixdefinition mit dem Token "using:". Nach dem Token "using:" benennen Sie dann den Codenamespace.

Um beispielsweise ein Präfix "custom1" zuzuordnen, mit dem Sie auf einen "CustomClasses"-Namespace verweisen und Klassen aus diesem Namespace oder dieser Assembly als Objektelemente in XAML verwenden können, sollte Ihre XAML-Seite die folgende Zuordnung für das Stammelement enthalten: xmlns:custom1="using:CustomClasses"

Partielle Klassen desselben Seitenbereichs müssen nicht zugeordnet werden. Sie benötigen z. B. keine Präfixe, um auf Ereignishandler zu verweisen, die Sie für die Verarbeitung von Ereignissen aus der XAML-UI-Definition Ihrer Seite definiert haben. Außerdem ordnen viele der Start-XAML-Seiten von Visual Studio generierte Projekte für eine Windows-Runtime-App mit C++, C# oder Visual Basic bereits einem Präfix "local:" zu, das auf den projektspezifischen Standardnamespace und den Namespace verweist, der von partiellen Klassendefinitionen verwendet wird.

CLR-Sprachregeln

Wenn Sie Ihren Sicherungscode in einer .NET-Sprache (C# oder Microsoft Visual Basic) schreiben, verwenden Sie möglicherweise Konventionen, die einen Punkt (".") als Teil von Namespacenamen verwenden, um eine konzeptionelle Hierarchie von Codenamespaces zu erstellen. Wenn Ihre Namespacedefinition einen Punkt enthält, sollte der Punkt Teil des Werts sein, den Sie nach dem Token "using:" angeben.

Wenn Ihre CodeBehind-Datei oder Codedefinitionsdatei eine C++-Datei ist, gibt es bestimmte Konventionen, die weiterhin dem ClR-Sprachformular (Common Language Runtime) entsprechen, sodass es keinen Unterschied in der XAML-Syntax gibt. Wenn Sie geschachtelte Namespaces in C++ deklarieren, sollte das Trennzeichen zwischen den aufeinander folgenden geschachtelten Namespacezeichenfolgen "." statt "::" sein, wenn Sie den Wert angeben, der auf das Token "using:" folgt.

Verwenden Sie keine geschachtelten Typen (z. B. das Schachteln einer Enumeration innerhalb einer Klasse), wenn Sie Ihren Code für die Verwendung mit XAML definieren. Geschachtelte Typen können nicht ausgewertet werden. Es gibt keine Möglichkeit für den XAML-Parser zu unterscheiden, dass ein Punkt Teil des geschachtelten Typnamens und nicht Teil des Namespacenamens ist.

Benutzerdefinierte Typen und Assemblys

Der Name der Assembly, die die Sicherungstypen für einen XAML-Namespace definiert, wird in der Zuordnung nicht angegeben. Die Logik, für die Assemblys verfügbar sind, wird auf App-Definitionsebene gesteuert und ist Teil der grundlegenden App-Bereitstellungs- und Sicherheitsprinzipien. Deklarieren Sie alle Assemblys, die Sie als Codedefinitionsquelle für XAML als abhängige Assembly in den Projekteinstellungen enthalten möchten. Weitere Informationen finden Sie unter Erstellen von Windows-Runtime Komponenten in C# und Visual Basic.

Wenn Sie auf benutzerdefinierte Typen aus der Anwendungsdefinition oder Seitendefinition der primären App verweisen, stehen diese Typen ohne weitere abhängige Assemblykonfiguration zur Verfügung. Sie müssen jedoch dennoch den Codenamespace zuordnen, der diese Typen enthält. Eine allgemeine Konvention besteht darin, das Präfix "lokal" für den Standardcodenamespace einer beliebigen XAML-Seite zuzuordnen. Diese Konvention ist häufig beim Starten von Projektvorlagen für XAML-Projekte enthalten.

Angefügte Eigenschaften

Wenn Sie auf angefügte Eigenschaften verweisen, muss sich der Besitzertypteil des Angefügten Eigenschaftsnamens entweder im Standardmäßigen XAML-Namespace befinden oder dem Präfix vorangestellt sein. Es ist selten, Attribute separat von ihren Elementen zu präfixieren, aber dies ist ein Fall, in dem es manchmal erforderlich ist, insbesondere für eine benutzerdefinierte angefügte Eigenschaft. Weitere Informationen finden Sie unter benutzerdefinierte angefügte Eigenschaften.