Freigeben über

Standardmäßiger XAML-Schemakontext und WPF-XAML-Schemakontext

  • Artikel

Ein XAML-Schemakontext ist eine konzeptionelle Entität, die qualifiziert, wie eine XAML-Produktion, die ein bestimmtes XAML-Vokabular verwendet, mit dem Objektschreibverhalten interagiert, einschließlich der Auflösung von Typzuordnungen, der Art des Ladens von Assemblys, der Interpretation bestimmter Lese- und Schreibeinstellungen. In diesem Thema werden die Features von .NET XAML Services und der zugehörige Standard-XAML-Schemakontext beschrieben, der auf dem CLR-Typsystem basiert. In diesem Thema wird auch der XAML-Schemakontext beschrieben, der für WPF verwendet wird.

Standardmäßiger XAML-Schemakontext

.NET XAML Services implementiert und verwendet einen standardmäßigen XAML-Schemakontext. Das standardmäßige XAML-Schemakontextverhalten ist in der API der XamlSchemaContext-Klasse nicht immer vollständig sichtbar. In vielen Fällen ist jedoch das Verhalten, das der Standard-XAML-Schemakontext beeinflusst, über die allgemeine API des XAML-Typsystems, z. B. Member von XamlMember oder XamlType, oder über APIs, die für XAML-Leser und XAML-Autoren verfügbar gemacht werden, die den standardmäßigen XAML-Schemakontext verwenden, erkennbar.

Sie können eine XamlSchemaContext erstellen, die das Standardverhalten kapselt, indem Sie den XamlSchemaContext-Konstruktor aufrufen. Dadurch wird explizit der Standardmäßige XAML-Schemakontext erstellt. Derselbe standardmäßige XAML-Schemakontext wird implizit erstellt, wenn Sie einen XAML-Reader oder XAML-Writer mithilfe von APIs initialisieren, die keinen XamlSchemaContext Eingabeparameter explizit verwenden.

Der standardmäßige XAML-Schemakontext basiert auf DER CLR-Spiegelung für sein Typzuordnungsverhalten. Dies umfasst die Untersuchung der definierenden CLR-Typeund verwandter PropertyInfo oder MethodInfo. Darüber hinaus wird die CLR-Zuordnung zu Typen oder Membern verwendet, um die Besonderheiten für XAML-Typ- oder XAML-Memberinformationen auszufüllen, die den CLR-Sicherungstyp verwenden. Der standardmäßige XAML-Schemakontext erfordert keine Typensystemerweiterungstechniken wie das Invoker Muster, da die erforderlichen Informationen aus dem CLR-Typsystem verfügbar sind.

Bei Assemblyladelogik basiert der Standardmäßige XAML-Schemakontext hauptsächlich auf allen Assemblywerten, die in XAML-Namespacezuordnungen bereitgestellt werden. Darüber hinaus können LocalAssembly für Szenarien wie das Laden interner Typen eine Assembly aufführen.

WPF-XAML-Schemakontext

Der WPF-XAML-Schemakontext wird in diesem Thema beschrieben, da die WPF-Implementierung eine interessante Darstellung der Arten von Features bietet, die durch Implementieren eines nicht standardmäßigen XAML-Schemakontexts eingeführt werden können. Außerdem wird das XAML-Schemakontextkonzept in der WPF-Dokumentation, in der WPF XAML behandelt wird, nicht sehr behandelt. Das Verhalten, das der XAML-Schemakontext ermöglicht, ist möglicherweise nur vollständig verständlich, wenn er in eine Erläuterung der Funktionsweise des standardmäßigen XAML-Schemakontexts integriert ist. Der WPF-XAML-Schemakontext implementiert das folgende Verhalten.

Nachschlageüberschreibungen: WPF verfügt über einige Inhaltsmodelle für XAML, in denen XAML-Inhaltseigenschaften vorhanden sind, die funktionieren, ohne ContentPropertyAttribute attributiert zu werden. LookupContentProperty Außerkraftsetzungen für WPF implementieren dieses Verhalten.

Verzögerung für WPF-Ausdrücke: WPF verfügt über mehrere Ausdrucksklassen, die einen Wert zurückstellen, bis ein Laufzeitkontext verfügbar ist. Außerdem ist die Vorlagenerweiterung ein Laufzeitverhalten, das auf Verzögerungstechniken basiert.

Suchoptimierungen des Typsystems: WPF verfügt über ein umfangreiches XAML-Vokabular und Objektmodell, einschließlich Basisklassenmemberdefinitionen, die buchstäblich Hunderte von WPF-definierten Klassen erben. Außerdem ist WPF selbst auf mehrere Assemblys verteilt. WPF optimiert den Typsuchvorgang mithilfe von Nachschlagetabellen und anderen Techniken. Dies bietet Leistungsverbesserungen gegenüber dem Standardmäßigen XAML-Schemakontext und der CLR-basierten Typsuche. In Fällen, in denen Typen in einer Nachschlagetabelle nicht vorhanden sind, verwendet das Verhalten XAML-Schemakontexttechniken, die dem standardmäßigen XAML-Schemakontext ähneln.

XamlType- und XamlMember-Erweiterung: WPF erweitert Eigenschaftskonzepte mit Abhängigkeitseigenschaften und Ereigniskonzepten mit Routingereignissen. Um diesen Konzepten eine größere Sichtbarkeit für XAML-Verarbeitungsvorgänge zu verleihen, erweitert WPF XamlType und XamlMemberund fügt interne Eigenschaften hinzu, die Abhängigkeitseigenschaft und Routingereigniseigenschaften melden.

Zugreifen auf den WPF-XAML-Schemakontext

Wenn Sie XAML-Techniken verwenden, die auf dem WPF-System.Windows.Markup.XamlReader oder System.Windows.Markup.XamlWriterbasieren, wird der WPF-XAML-Schemakontext bereits für diese XAML-Reader- und XAML-Writer-Implementierungen verwendet.

Wenn Sie andere XAML-Reader- oder XAML-Writer-Implementierungen verwenden, die nicht mit dem WPF-XAML-Schemakontext initialisiert werden, können Sie möglicherweise einen funktionierenden WPF-XAML-Schemakontext aus XamlReader.GetWpfSchemaContextabrufen. Sie können diesen Wert dann als Initialisierung für andere API verwenden, die eine XamlSchemaContextverwenden. Sie können z. B. XamlXmlReader für die Initialisierung aufrufen und den WPF-XAML-Schemakontext übergeben. Sie können auch den WPF-XAML-Schemakontext für XAML-Typsystemvorgänge verwenden. Dies kann die Erstellungsinitialisierung eines XamlType oder XamlMemberoder das Aufrufen von XamlSchemaContext.GetXamlTypeumfassen.

Beachten Sie, dass einige der WPF-Frameworkfunktionen möglicherweise noch nicht reagiert haben, wenn Sie aus reinen XAML-Knotenstreams auf bestimmte Aspekte von WPF-XAML zugreifen. Beispielsweise werden WPF-Vorlagen für Steuerelemente noch nicht angewendet. Wenn Sie also auf eine Eigenschaft zugreifen, die zur Laufzeit möglicherweise mit einer vollständigen visuellen Struktur aufgefüllt wird, wird möglicherweise nur ein Eigenschaftswert angezeigt, der auf eine Vorlage verweist. Der für WPF-Markuperweiterungen bereitgestellte Dienstkontext ist möglicherweise auch nicht korrekt, wenn er von einer Nicht-Laufzeitsituation bereitgestellt wird, und kann zu Ausnahmen führen, wenn versucht wird, ein Objektdiagramm zu schreiben.

Laden von XAML und Assembly

Assembly loading for XAML and .NET XAML Services integrations with the CLR-defined concept of AppDomain. Ein XAML-Schemakontext interpretiert, wie Assemblys geladen oder Typen zur Laufzeit oder Entwurfszeit gefunden werden, basierend auf der Verwendung von AppDomain und anderen Faktoren. Die Logik unterscheidet sich geringfügig, je nachdem, ob der XAML-Code für einen XAML-Reader lose XAML ist, von XamlBuildTaskin eine DLL kompiliert wird oder von WPFs PresentationBuildTaskgeneriert wird.

Der XAML-Schemakontext für WPF ist in das WPF-Anwendungsmodell integriert, das wiederum AppDomain sowie andere Faktoren verwendet, die WPF-Implementierungsdetails sind.

XAML-Leseeingabe (loses XAML)

  1. Der XAML-Schemakontext durchläuft die AppDomain der Anwendung und sucht nach einer bereits geladenen Assembly, die allen Aspekten des Namens entspricht, beginnend mit der zuletzt geladenen Assembly. Wenn eine Übereinstimmung gefunden wird, wird diese Assembly für die Auflösung verwendet.

  2. Andernfalls werden eine der folgenden Techniken verwendet, die auf CLR Assembly-API basieren, um eine Assembly zu laden:

    • Wenn der Name in der Zuordnung qualifiziert ist, rufen Sie Assembly.Load(String) für den qualifizierten Namen auf.

    • Wenn der vorherige Schritt fehlschlägt, verwenden Sie den Kurznamen (und das öffentliche Schlüsseltoken, falls vorhanden), um Assembly.Load(String)aufzurufen.

    • Wenn der Name in der Zuordnung nicht qualifiziert ist, rufen Sie Assembly.LoadWithPartialNameauf.

XamlBuildTask

XamlBuildTask wird für Windows Communication Foundation (WCF) und Windows Workflow Foundation verwendet.

Beachten Sie, dass Assemblyverweise über XamlBuildTask immer vollqualifizierte sind.

  1. Rufen Sie Assembly.Load(String) für den qualifizierten Namen auf.

  2. Wenn der vorherige Schritt fehlschlägt, verwenden Sie den Kurznamen (und das öffentliche Schlüsseltoken, falls vorhanden), um Assembly.Load(String)aufzurufen.

BAML (PresentationBuildTask)

Es gibt zwei Aspekte für die Montageladevorgang für BAML: Laden der ursprünglichen Assembly, die die BAML als Komponente enthält, und Laden der Typensicherungsassemblys für alle Typen, auf die von der BAML-Produktion verwiesen wird.

Assemblyladevorgang für anfängliches Markup:

Der Verweis auf die Assembly zum Laden des Markups ist immer nicht qualifiziert.

  1. Der WPF-XAML-Schemakontext durchläuft die AppDomain der WPF-Anwendung und sucht nach einer bereits geladenen Assembly, die allen Aspekten des Namens entspricht, beginnend mit der zuletzt geladenen Assembly. Wenn eine Übereinstimmung gefunden wird, wird diese Assembly für die Auflösung verwendet.

  2. Wenn der vorherige Schritt fehlschlägt, verwenden Sie den Kurznamen (und das öffentliche Schlüsseltoken, falls vorhanden), um Assembly.Load(String)aufzurufen.

Assemblyverweise durch BAML-Typen:

Assemblyverweise für Typen, die in der BAML-Produktion verwendet werden, sind immer vollqualifizierte, als Ausgabe der Buildaufgabe.

  1. Der WPF-XAML-Schemakontext durchläuft die AppDomain der WPF-Anwendung und sucht nach einer bereits geladenen Assembly, die allen Aspekten des Namens entspricht, beginnend mit der zuletzt geladenen Assembly. Wenn eine Übereinstimmung gefunden wird, wird diese Assembly für die Auflösung verwendet.

  2. Andernfalls wird eine der folgenden Techniken zum Laden einer Assembly verwendet:

    • Rufen Sie Assembly.Load(String) für den qualifizierten Namen auf.

    • Wenn eine Kombination aus kurzem Namen +Public Key-Token mit der Assembly übereinstimmt, aus der die BAML geladen wurde, verwenden Sie diese Assembly.

    • Verwenden Sie short name + public key token, um Assembly.Load(String)aufzurufen.

Siehe auch