Standard-XAML-Schemakontext und WPF-XAML-Schemakontext
Ein XAML-Schemakontext gibt vor, wie eine XAML-Produktion, die ein bestimmtes XAML-Vokabular verwendet, mit dem Objektschreibverhalten interagiert, einschließlich der Auflösungweise von Typzuordnungen, wie Assemblys geladen werden und wie bestimmte Reader- und Writereinstellungen interpretiert werden. In diesem Artikel werden die Features von .NET XAML Services und der dazugehörige standardmäßige 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 nicht immer vollständig in der API der XamlSchemaContext-Klasse sichtbar. In vielen Fällen ist jedoch das Verhalten, das der standardmäßige XAML-Schemakontext beeinflusst, beobachtbar über die allgemeine API des XAML-Typsystems, z. B. Member von XamlMember oder XamlType, oder über APIs, die für XAML-Leser und XAML-Writer verfügbar gemacht werden, die den standardmäßigen XAML-Schemakontext verwenden.
Sie können ein XamlSchemaContext erstellen, in dem sich das Standardverhalten befindet, 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 nicht explizit einen XamlSchemaContext-Eingabeparameter übernehmen.
Der standardmäßige XAML-Schemakontext basiert sein Typzuordnungsverhalten auf der CLR-Entsprechung. Dies umfasst die Untersuchung der definierenden CLR Type, und der verwandten PropertyInfo oder MethodInfo. Außerdem werden CLR-Zuordnungen für Typen oder Member verwendet, um spezifische Daten für XAML-Typ- oder XAML-Memberinformationen auszufüllen, die den CLR-Unterstützungstyp verwenden. Der standardmäßige XAML-Schemakontext erfordert keine Systemerweiterungstechniken 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 jeglichen Assemblywerten, die in XAML-Namespacezuordnungen bereitgestellt werden. Außerdem kann LocalAssembly darauf hinweisen, dass eine Assembly geladen werden kann, z. B. für Szenarien wie das Laden interner Typen.
WPF-XAML-Schemakontext
Der WPF-XAML-Schemakontext wird in diesem Artikel beschrieben, da die WPF-Implementierung eine interessante Veranschaulichung der Arten von Features bereitstellt, die durch Implementieren eines nicht standardmäßigen XAML-Schemakontexts eingeführt werden können. Außerdem wird das Konzept des XAML-Schemakontexts in der WPF-Dokumentation, die WPF-XAML behandelt, kaum behandelt; das Verhalten, für den der XAML-Schemakontext sorgt, ist möglicherweise nur vollständig verständlich, wenn er Teil eines Gesprächs darüber ist, wie der standardmäßige XAML-Schemakontext funktioniert. Der WPF-XAML-Schemakontext implementiert das folgende Verhalten.
Nachschlagen von Überschreibungen: WPF verfügt über einige Inhaltsmodelle für XAML, mit XAML-Inhaltseigenschaften, die ohne ContentPropertyAttribute-Attribution funktionieren. LookupContentProperty-Überschreibungen 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.
Typsystem-Suchoptimierungen: 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 seine Typsuche mithilfe von Nachschlagetabellen und anderen Techniken. Dies bietet Leistungsverbesserungen über den standardmäßigen XAML-Schemakontext und die CLR-basierte Typsuche. In Fällen, in denen keine Typen in einer Nachschlagetabelle vorhanden sind, verwendet das Verhalten XAML-Schemakontexttechniken, die dem standardmäßigen XAML-Schemakontext ähneln.
XamlMember-Erweiterung: WPF erweitert Eigenschaftenkonzepte 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 XamlMember, und 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 System.Windows.Markup.XamlReader oder System.Windows.Markup.XamlWriter von WPF basieren, 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.GetWpfSchemaContext abrufen. Sie können diesen Wert dann als Initialisierung für andere API verwenden, die eine XamlSchemaContext verwendet. Beispielsweise können Sie zur Initialisierung XamlXmlReader aufrufen und den WPF-XAML-Schemakontext übergeben. Oder Sie können den WPF-XAML-Schemakontext für XAML-Typsystemvorgänge verwenden. Dies kann die Erstellungsinitialisierung eines XamlType oder XamlMember, oder das Aufrufen von XamlSchemaContext.GetXamlType umfassen.
Beachten Sie, dass bei Zugriff auf bestimmte Aspekte von WPF-XAML aus einer reinen XAML-Knotenstreamperspektive einige der WPF-Frameworkfunktionen möglicherweise noch nicht ausgeführt wurden. Beispielsweise könnten WPF-Vorlagen für Steuerelemente noch nicht angewendet sein. Wenn Sie daher auf eine Eigenschaft zugreifen, die zur Laufzeit möglicherweise mit einer vollständigen visuellen Struktur gefü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 Objektgraph zu schreiben.
Laden von XAML und Assemblys
Das Laden von Assemblys für XAML und .NET XAML Services ist in das durch CLR-definierte Konzept AppDomain integriert. Ein XAML-Schemakontext interpretiert zur Laufzeit oder zur Entwurfszeit, wie entweder Assemblies geladen oder Typen gefunden werden. Dies ist von der Verwendung von AppDomain und anderen Faktoren abhängig. Die Logik unterscheidet sich geringfügig, je nachdem, ob der XAML-Code für einen XAML-Reader loses XAML ist, durch XamlBuildTask in eine DLL kompiliert wird oder ob BAML durch den PresentationBuildTask von WPF generiert wird.
Der XAML-Schemakontext für WPF integriert das WPF-Anwendungsmodell, das wiederum auch AppDomain und andere Faktoren verwendet, die WPF-Implementierungsdetails sind.
XAML-Readereingabe (loses XAML)
Der XAML-Schemakontext iteriert durch die AppDomain der Anwendung, um nach einer bereits geladenen Assembly zu suchen, die mit allen Aspekten des Namens übereinstimmt, beginnend mit der zuletzt geladenen Assembly. Wenn eine Übereinstimmung gefunden wird, wird diese Assembly verwendet.
Andernfalls werden eine der folgenden Techniken basierend auf der CLR-Assembly-API verwendet, um eine Assembly zu laden:
Wenn der Name in der Zuordnung qualifiziert ist, rufe 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.LoadWithPartialName auf.
XamlBuildTask
XamlBuildTask wird für Windows Communication Foundation (WCF) und Windows Workflow Foundation verwendet.
Beachten Sie, dass Assemblyverweise über XamlBuildTask immer vollqualifiziert sind.
Rufen Sie Assembly.Load(String) auf dem 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.
BAML (PresentationBuildTask)
Es gibt zwei Aspekte beim Laden von Assemblys mit BAML: Laden der ersten Assembly, die die BAML als Komponente enthält, und Laden der typenunterstützenden Assemblys für alle Typen, auf die von der BAML-Produktion verwiesen wird.
Laden von Assemblys für das anfängliche Markup:
Verweise auf die Assembly zum Laden des Markups sind immer nicht qualifiziert.
Der WPF-XAML-Schemakontext iteriert durch die AppDomain der WPF-Anwendung, um nach einer bereits geladenen Assembly zu suchen, die mit allen Aspekten des Namens übereinstimmt, beginnend mit der zuletzt geladenen Assembly. Wenn eine Übereinstimmung gefunden wird, wird diese Assembly verwendet.
Wenn der vorherige Schritt fehlschlägt, verwenden Sie den Kurznamen (und das öffentliche Schlüsseltoken, falls vorhanden), um Assembly.Load(String) aufzurufen.
Assemblyverweise von BAML-Typen:
Assemblyverweise für Typen, die in der BAML-Produktion verwendet werden, sind als Ausgabe der Buildaufgabe immer vollqualifiziert.
Der WPF-XAML-Schemakontext iteriert durch die AppDomain der WPF-Anwendung, um nach einer bereits geladenen Assembly zu suchen, die mit allen Aspekten des Namens übereinstimmt, beginnend mit der zuletzt geladenen Assembly. Wenn eine Übereinstimmung gefunden wird, wird diese Assembly verwendet.
Andernfalls wird eine der folgenden Techniken zum Laden einer Assembly verwendet:
Rufen Sie Assembly.Load(String) auf dem qualifizierten Namen auf.
Wenn eine Kombination aus kurzem Namen + öffentlichem Schlüsseltoken der Assembly entspricht, aus der die BAML geladen wurde, verwenden Sie diese Assembly.
Verwenden Sie den Kurznamen + öffentlichen Schlüssel, um Assembly.Load(String) aufzurufen.
Weitere Informationen
.NET Desktop feedback