Windows-Metadatendateien (WinMD-Dateien)

Artikel
07/20/2023

Windows-Runtime -APIs (WinRT) werden in .winmd maschinenlesbaren Metadatendateien mit der Erweiterung (auch als Metadaten bezeichnet) Windows beschrieben. Diese Metadatendateien werden von Tools und Sprachprojektionen verwendet, um die Sprachprojektion zu ermöglichen.

Allgemeine Hinweise

Windows enthält Metadaten für alle vom System bereitgestellten WinRT-APIs. Windows stellt APIs bereit, um Sprachprojektionen bei der Auflösung von Namespaces und Typen zu unterstützen, die diese Metadaten zur Laufzeit benötigen. Das Windows SDK stellt eine Kopie der Systemmetadaten in einer einzelnen Datei zur Verwendung durch Sprachprojektionen bereit, die diese Metadaten zur Kompilierzeit benötigen.

Drittanbieter können ihre eigenen WinRT-APIs entwickeln, die wie die vom System bereitgestellten APIs an der Sprachprojektion teilnehmen können. WinRT-APIs von Drittanbietern müssen Metadaten genau wie System-APIs bereitstellen. Windows-APIs für Namespace- und Typauflösung funktionieren für Metadaten von Drittanbietern wie für Systemmetadaten.

Alle öffentlichen Typen in einer WinMD-Datei müssen WinRT-Typen sein und das Flag tdWindowsRuntime enthalten (Details zu den zu befolgenden Typflags). WinMD-Dateien können Metadaten für Nicht-WinRT-Typen enthalten. Alle Nicht-WinRT-Typen in einer WinMD-Datei dürfen nicht öffentlich sein. Semantik für Nicht-WinRT-Typen ist implementierungsdefiniert und außerhalb des Bereichs dieses Dokuments.

Alle member der öffentlichen Schnittstelle (Methoden, Eigenschaften und Ereignisse) für WinRT-Typen müssen WinRT-Schnittstellenmitglieder sein. WinRT-Typen können Metadaten für Nicht-WinRT-Schnittstellenelemente enthalten. Nicht-WinRT-Schnittstellenmitglieder sind möglicherweise nicht öffentlich. Semantik für Nicht-WinRT-Schnittstellenmitglieder ist implementierungsdefiniert und außerhalb des Bereichs dieses Dokuments.

WinMD-Dateien

WinMD-Dateiformat

WinMD-Dateien verwenden das gleiche physische Dateiformat wie CLR-Assemblys (Common Language Runtime), wie in der ECMA-335-Spezifikation definiert. Obwohl das physische Dateiformat identisch ist, unterscheiden sich die Regeln für gültige Kombinationen von Daten für WinMD-Dateien und CLR-Assemblys. In diesem Dokument werden die Deltas zwischen WinMD-Dateien und CLR-Assemblys aufgeführt.

Vom System bereitgestellte WinMD-Dateien sind reine Metadaten. WinMD-Dateien von Drittanbietern können Code enthalten. Insbesondere verwaltete WinMD-Dateien enthalten MSIL-Code (Microsoft Intermediate Language), genau wie herkömmliche CLR-Assemblys.

Jede WinMD-Datei enthält die Definitionen von null oder mehr WinRT-Typen. Leere WinMD-Dateien sind technisch gültig.

Es gibt keine spezifischen WinRT-Einschränkungen für die PEKind- oder Computerarchitektur, die in einer WinMD aufgeführt sind.

Die WinMD-Versionszeichenfolge muss "Windows-Runtime 1.2" enthalten.

WinMD-Dateiname

Der Name (ohne Erweiterung) einer WinMD-Datei muss mit der Namensspalte der Assemblytabelle innerhalb der WinMD-Datei übereinstimmen. Beispielsweise muss die Datei "Foo.Bar.winmd" in der Namensspalte der Assemblytabelle "Foo.Bar" enthalten. Da die Groß-/Kleinschreibung im Dateisystem nicht beachtet wird, kann sich die Groß-/Kleinschreibung des Dateinamens vom Spaltenwert des Assemblytabellennamens unterscheiden.

Alle WinRT-Typen in einer bestimmten WinMD-Datei müssen sich unter einem Namespace befinden, der dem Namen der WinMD-Datei und dem Spaltenwert des Assemblytabellennamens entspricht. Da die Groß-/Kleinschreibung im Dateisystem nicht beachtet wird, kann sich die Groß-/Kleinschreibung des Dateinamens vom Namespace aller WinRT-Typen in einer bestimmten WinMD-Datei unterscheiden. Der Namespace aller WinRT-Typen in einer bestimmten WinMD muss genau mit dem Spaltenwert des Assemblytabellennamens übereinstimmen (d. h. die Schreibung wird beachtet). Beispielsweise müssen sich alle Typen in der Datei mit "Foo.Bar" in der Namensspalte der Assemblytabelle im Namespace "Foo.Bar" befinden. Bei den Typen kann es sich entweder um direkte untergeordnete Daten dieses Namespace (z. B. Foo.Bar.MyType) oder um untergeordnete Namespaces dieses Namespace (z. B. Foo.Bar.Baz.MyType) befinden. Der Name der Datei muss "Foo.Bar.winmd" sein, kann jedoch im Fall von "foo.bar.winmd" und "FOO" variieren. BAR. WINMD" wäre auch als Dateinamen für diese Metadatendatei zulässig.

WinMD-Komposition

Die Metadaten für alle Typen im System sind auf mehrere WINMD-Dateien verteilt. Ein AppX-Paket kann null oder mehr WINMD-Dateien enthalten, die WinRT-Komponenten von Drittanbietern beschreiben, die im Anwendungspaket enthalten sind.

In allen WINMD-Dateien, die vom System bereitgestellt oder in einer bestimmten App enthalten sind, müssen die Metadaten jedes WinRT-Typs in der WinMD-Datei gespeichert werden, und der längste Name muss mit dem Namespace des Typs übereinstimmen. Alle Typen, die direkte children eines bestimmten Namespaces sind, müssen sich in derselben Datei befinden. Wenn ein AppX-Paket beispielsweise Dateien vom Typ Foo.winmd und Foo.Bar.winmd enthält, muss sich der Typ Foo.Bar.Baz.MyType in der Datei Foo.Bar.winmd befinden, da dies die Datei mit dem längsten Namespacevergleichsdateinamen für den Typ im Paket ist.

TypeDef-Umleitung

Vom System bereitgestellte Metadatendateien verweisen nie direkt auf TypeDefs. Selbst wenn auf einen Typ verwiesen wird, der in derselben Metadatendatei definiert ist, verweisen Systemmetadatendateien immer auf eine TypeRef, die wiederum auf typeDef verweist. Dies erfolgt, um die CLR-Typumleitung zu unterstützen (z. B. das Projektieren von IVectorT<> als IListT<>).

Metadatendateien von Drittanbietern können TypeDef direkt verwenden oder alle Typverweise über eine TypeRef umleiten, ähnlich wie Systemmetadatendateien.

Typsystemcodierung

Alle Typen in diesem Dokument aus dem Systemnamespace aus der mscorlib-Assembly werden von WinRT als Marker verwendet. Diese Typen werden verwendet, um Informationen zu Typen anzugeben, und sollten nie aufgelöst werden. Dies schließt (aber nicht beschränkt auf) System.Object, System.Guid, System.ValueType, System.Enum, System.MulticastDelegate und System.Attribute ein. Beachten Sie, dass diese Namen aus Kompatibilitäts- und CLR-Kompatibilitäts- ausgewählt wurden. Die CLR-Definition dieser Typen ist Teil ihres Typsystems und hat nichts mit WinRT zu tun.

Beachten Sie, dass viele der hier beschriebenen Konstrukte C#-Syntax verwenden. Dies liegt einfach daran, dass es praktisch ist, bestimmte Common Language Infrastructure(CLI)-Metadatenkonstrukte mithilfe der C#-Syntax zu darstellen. Die tatsächlichen Konstrukte sind reine CLI-Metadatenkonstrukte.

Namespace

WinRT codiert den Namespace und den lokalen Namen eines Typs in eine einzelne durch Trennzeichen getrennte Zeichenfolge. Beispielsweise ist der in diesem Codeausschnitt definierte Typ "Windows. Foundation.ISimpleInterface".

namespace Windows {
    namespace Foundation {
        interface ISimpleInterface {
            HRESULT Method1(int paramOne);
        };
    };
};

Zur Optimierung des Speicherplatzes stellt die TypeDef-Tabelle in DEN CLI-Metadaten separate Spalten für Typname und Namespacename bereit. Auf API-Ebene macht die TypeDef-Eigenschaft jedoch nur den Typnamen verfügbar.

Grundlegende Typen

Alle grundlegenden WinRT-Typen mit Ausnahme von Guid verfügen über explizite konstante Werte für die Verwendung in CLI-Metadatenblobs und anderen Typverweisen. Diese konstanten Werte werden in Partition 2, Abschnitt 23.1.16 der CLI-Spezifikation beschrieben.

WinRT-Typ	Name des CLI-Elementtyps	WERT DES CLI-Elementtyps
Int16	ELEMENT_TYPE_I2	0x06
Int32	ELEMENT_TYPE_I4	0x08
Int64	ELEMENT_TYPE_I8	0x0a
UInt8	ELEMENT_TYPE_U1	0x05
UInt16	ELEMENT_TYPE_U2	0x07
UInt32	ELEMENT_TYPE_U4	0x09
UInt64	ELEMENT_TYPE_U8	0x0b
Single	ELEMENT_TYPE_R4	0x0c
Double	ELEMENT_TYPE_R8	0x0d
Char16	ELEMENT_TYPE_CHAR	0x03
Boolesch	ELEMENT_TYPE_BOOL	0x02
String	ELEMENT_TYPE_STRING	0x0e

Da sie keinen expliziten konstanten ELEMENT_TYPE_*-Wert aufweisen, werden GUIDs in Metadaten als TypeRef für den System.Guid-Typ aus der mscorlib-Assembly dargestellt.

Enumerationen

Enumerationen werden als Zeile in der TypeDef-Tabelle (ECMA II.22.37) dargestellt, wobei die Spalten wie folgt festgelegt sind.

Flaggen. Legen Sie auf Public | fest. Versiegelte | tdWindowsRuntime (0x4101).
Name. Ein Index im Zeichenfolgenheap, der den Namen des Typs enthält.
Namespace. Ein Index im Zeichenfolgenheap, der den Namespace des Typs enthält.
Erweitert. Legen Sie auf eine TypeRef-Klasse fest, die auf die System.Enum-Klasse in der mscorlib-Assembly verweist.
FieldList. Ein Index in der Feldtabelle, der den ersten einer zusammenhängenden Ausführung von Feldern markiert, die sich im Besitz dieses Typs befinden.
MethodList. Muss leer sein.

Eine Enumeration verfügt über ein einzelnes Instanzfeld, das den zugrunde liegenden ganzzahligen Typ für die Enumeration sowie null oder mehr statische Felder angibt. eine für jeden durch den Enumerationstyp definierten Enumerationswert.

Der zugrunde liegende ganzzahlige Typ der Enumeration wird als erste Zeile in der Feldtabelle (ECMA II.22.15) angezeigt, die dem Typ zugeordnet ist (d. h. die Zeile, auf die in der oben angegebenen FieldList-Spalte verwiesen wird). Die Spalten in der Tabelle Feld für den Enumerationstyp sind wie folgt.

Flags: Private | SpecialName | RTSpecialName (0x601).
Name: Ein Index im Zeichenfolgenheap, der den Namen "value__" enthält.
Signatur: Ein Index im Blobheap, der ein FieldSig-Blob (ECMA II.23.2.4) enthält, wobei type entweder auf ELEMENT_TYPE_I4 oder ELEMENT_TYPE_U4 festgelegt ist, da WinRT-Enumerationswerte 32-Bit-Ganzzahlen mit Vorzeichen oder ohne Vorzeichen sein müssen.

Nachdem die Enumerationswertdefinition eine Felddefinition für jeden der Werte in der Enumeration enthält.

Flags: öffentliche | statische | Literal| hasdefault (0x8056).
Name: Ein Index im Zeichenfolgenheap, der den Namen des Enumerationswerts enthält.
Signatur: Ein Index im Blobheap, der ein FieldSig-Blob (ECMA II.23.3.4) enthält, wobei der Typ auf die TypeDef des Enumerationstyps festgelegt ist.

Für jede Enumerationswertdefinition gibt es eine entsprechende Zeile in der Konstantentabelle (ECMA II.22.9), um den ganzzahligen Wert für den Enumerationswert zu speichern.

Type (Typ). Ein Byte, das den zugrunde liegenden Typ der Enumeration darstellt, entweder ELEMENT_TYPE_I4 oder ELEMENT_TYPE_U4, gefolgt von einer Byteauffüllung 0 (null) gemäß ECMA-Spezifikation.
Übergeordnetes Element: Index in die Feldtabelle, die den zugeordneten Enumerationswertdatensatz enthält.
Wert: Index in die Blobtabelle, die den ganzzahligen Wert für den Enumerationswert enthält.

Darüber hinaus muss das System.FlagsAttribute der TypeDef-Enumerationszeile für alle Enumerationen mit einem zugrunde liegenden UInt32-Typ hinzugefügt werden. FlagsAttribute darf der TypeDef-Enumerationszeile für Enumerationen mit einem zugrunde liegenden Int32-Typ nicht hinzugefügt werden.

Für alle vom System bereitgestellten Enumerationen muss das VersionAttribute der TypeDef-Enumerationszeile hinzugefügt werden. Optional kann das VersionAttribute einer beliebigen statischen Feldzeile hinzugefügt werden. Falls vorhanden, muss der Versionswert aus versionAttribute für alle Enumerationsfeldzeilen größer oder gleich dem Wert aus versionAttribute in der TypeDef-Enumerationszeile sein.

Strukturen

Strukturen werden als Zeile in der TypeDef-Tabelle (ECMA II.22.37) implementiert, wobei die Spalten wie folgt festgelegt sind.

Flags – Öffentliche | Versiegelte | Sequenzielle | tdWindowsRuntime (0x4109).
Name: Ein Index im Zeichenfolgenheap, der den Namen des Typs enthält.
Namespace: Ein Index im Zeichenfolgenheap, der den Namespace des Typs enthält.
Erweitert : Wird auf eine TypeRef-Klasse festgelegt, die auf die System.ValueType-Klasse in der mscorlib-Assembly verweist.
FieldList: Ein Index in der Field-Tabelle, der die erste zusammenhängende Ausführung von Feldern markiert, die sich im Besitz dieses Typs befinden.
MethodList: muss leer sein.

Strukturen verfügen über mindestens einen Feldtabelleneintrag.

Flags: public.
Name: Ein Index im Zeichenfolgenheap, der den Namen des Felds enthält.
Signatur: Ein Index im Blobheap, der ein FieldSig-Blob (ECMA II.23.2.4) enthält, wobei type auf das Metadatentoken für den Feldtyp festgelegt ist.
- Strukturfelder müssen grundlegende Typen, Enumerationen oder andere Strukturen sein.

Für alle vom System bereitgestellten Strukturen muss das VersionAttribute der TypeDef-Strukturzeile hinzugefügt werden.

Delegaten

Delegaten werden als Zeile in der TypeDef-Tabelle (ECMA II.22.37) implementiert, wobei die Spalten wie folgt festgelegt sind.

Flags: Auf Öffentliche | festgelegt Versiegelte | tdWindowsRuntime (0x4101).
Name: Ein Index im Zeichenfolgenheap, der den Namen des Typs enthält.
Namespace: Ein Index im Zeichenfolgenheap, der den Namespace des Typs enthält.
Erweitert: Wird auf ein TypeRef festgelegt, das auf die System.MulticastDelegate-Klasse in der mscorlib-Assembly verweist.
FieldList: muss leer sein.
MethodList: Ein Index in der MethodDef-Tabelle (ECMA II.22.26), der die erste zusammenhängende Ausführung von Methoden markiert, die sich im Besitz dieses Typs befinden.

Die TypeDef-Zeilen von Delegaten müssen über ein GuidAttribute verfügen.

Delegaten verfügen über genau zwei MethodDef-Tabelleneinträge. Der erste definiert einen Konstruktor. Dieser Konstruktor ist ein Kompatibilitätsmarker, weshalb er Nicht-WinRT-Konstrukte wie native int und Parameter verwendet, die weder in noch outsind. WinRT-Delegaten haben keine solche Konstruktormethode.

RVA: 0 (dies ist ein abstraktes Konstrukt).
ImplFlags: Runtime (0x03).
Flags: private | hidebysig | specialname | RTSpecialName (0x1881).
Name: Ein Index in der Zeichenfolgentabelle, der den Namen ".ctor" enthält.
Signatur: Ein Index im Blobheap, der ein MethodDefSig-Blob (ECMA II.23.2.1) für eine Methode mit einem Objekt und einem nativen int-Wert in Parametern und ohne Rückgabewert enthält.
ParamList: Ein Index in der Param-Tabelle (ECMA II.22.33), der den ersten in einer Ausführung von Param-Zeilen enthält, die dieser Methode zugeordnet sind. Jede Zeile in der Param-Tabelle enthält die folgenden Informationen.
- Objektparameter
  - Sequenz 1
  - Name "Objekt"
  - Flags: none (0x00)
- Nativer Int-Parameter
  - Sequenz 2
  - Name "Methode"
  - Flags: none (0x00)

Der zweite MethodDef-Eintrag definiert die Invoke-Methode.

RVA: 0 (dies ist ein abstraktes Konstrukt)
ImplFlags: Runtime (0x03)
Flags: öffentliche | Virtuelle | HideBySig-| specialname (0x08C6)
Name: Ein Index in der Zeichenfolgentabelle mit dem Namen "Invoke"
Signatur: Ein Index im Blobheap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das die Parametertypen und den Rückgabetyp des Delegaten enthält. Wenn der Delegat parametrisiert ist, sollte das MethodDefSig-Blob über den GENERICINST-codierten Typ (gemäß ECMA II.23.2.12) auf jeden der Delegattypparameter verweisen. Details zu parametrisierten Delegaten, die folgen sollen.
ParamList: Ein Index in der Param-Tabelle (ECMA II.22.33), der den ersten in einer Ausführung von Param-Zeilen enthält, die dieser Methode zugeordnet sind. Jede Zeile in der Param-Tabelle enthält die folgenden Informationen.
- Flags : ein- oder ausgehend, je nach Parameter
- Sequence: Sequenzreihenfolge des Parameters. 0 (null) ist für den Rückgabewert der Methode reserviert.
- Name: Index in den Zeichenfolgenheap, der den Namen des Parameters enthält. Für alle vom System bereitgestellten Delegaten muss versionAttribute der TypeDef-Zeile des Delegaten hinzugefügt werden.

Parametrisierte Delegaten

Parametrisierte Delegaten haben die folgenden zusätzlichen Anforderungen.

Der Name eines parametrisierten Delegaten wird mit einem Backtick und einer Zahl angefügt, die die Anzahl der Typparameter des parametrisierten Delegaten darstellt. Beispiel: die Windows. Der Foundation.EventHandlerT-Typ<> wird in Metadaten mit dem Namen Windows gespeichert. Foundation.EventHandler'1.
Parametrisierte Delegaten weisen eine Zeile in der GenericParam-Tabelle (ECMA II.22.20) für jeden Typparameter auf, wobei die Spalten wie folgt festgelegt sind.
- Number: Der Index des generischen Parameters, nummeriert von links nach rechts, beginnend bei 0 (null).
- Flags: Keine.
- Besitzer: Index in die TypeDef-Tabelle für die Zeile, die die Schnittstelle enthält.
- Name: Index in den Zeichenfolgenheap, der den Namen des generischen Parameters enthält.

Die TypeSpec-Tabelle (ECMA II.23.2.14) wird verwendet, um Instanzen parametrisierter Delegaten zu definieren. Diese TypeSpecs können dann ähnlich wie TypeRefs in Methodensignaturen verwendet werden.

Schnittstellen

Schnittstellen werden als Zeile in der TypeDef-Tabelle (ECMA II.22.37) implementiert, wobei die Spalten wie folgt festgelegt sind.

Flags:
- | public | abstrakte | tdWindowsRuntime (0x40A1) oder
- | NotPublic| abstrakte | tdWindowsRuntime (0x40A0)
Name: Ein Index in der Zeichenfolgentabelle, die den Schnittstellennamen enthält.
Namespace: Ein Index im Zeichenfolgenheap, der den Namespace des Typs enthält.
Erweitert: NULL.
FieldList: muss leer sein.
MethodList: Ein Index in der MethodDef-Tabelle, der den ersten einer zusammenhängenden Ausführung von Methoden markiert, die sich im Besitz dieses Typs befinden. Einzelheiten zum Inhalt der MethodDef-Tabelle finden Sie in den Unterabschnitten des aktuellen Abschnitts.

Die TypeDef-Zeilen der Schnittstellen müssen sowohl über ein GuidAttribute als auch über ein VersionAttribute verfügen.

Jede WinRT-Schnittstelle mit privater Sichtbarkeit muss über ein einzelnes ExclusiveToAttribute verfügen. Jede WinRT-Schnittstelle mit öffentlicher Sichtbarkeit darf kein ExclusiveToAttribute aufweisen. Falls vorhanden, muss exclusiveToAttribute auf eine Laufzeitklasse verweisen.

Erforderliche Schnittstellen für eine Schnittstelle werden durch Zeilen in der InterfaceImpl-Tabelle (ECMA II.22.23) dargestellt, wobei die Spalten wie folgt festgelegt sind.

Klasse: Ein Index in der TypeDef-Tabelle für die Zeile, die die Schnittstelle enthält.
Schnittstelle: Ein Index in der TypeDef-, TypeRef- oder TypeSpec-Tabelle, der die erforderliche Schnittstelle angibt. Beachten Sie, dass dies in vom System bereitgestellten Metadatendateien niemals eine TypeDef ist, auch wenn die erforderliche Schnittstelle in derselben Metadatendatei definiert ist. Weitere Informationen finden Sie im Abschnitt TypeDef-Umleitung.

Parametrisierte Schnittstellen

Parametrisierte Schnittstellen stellen die folgenden zusätzlichen Anforderungen her.

Der Name einer parametrisierten Schnittstelle wird mit einem Backtick und einer Zahl angefügt, die die Anzahl der Typparameter des parametrisierten Delegaten darstellt. Beispiel: die Windows. Der Foundation.Collections.IVectorT-Typ<> wird in Metadaten mit dem Namen Windows gespeichert. Foundation.Collections.IVector'1.

Parametrisierte Schnittstellen weisen eine Zeile in der GenericParam-Tabelle (ECMA II.22.20) für jeden Typparameter auf, wobei die Spalten wie folgt festgelegt sind.

Number: Der Index des generischen Parameters, nummeriert von links nach rechts, beginnend bei 0 (null).
Flags: Keine.
Besitzer: Index in die TypeDef-Tabelle für die Zeile, die die Schnittstelle enthält.
Name: Index in den Zeichenfolgenheap, der den Namen des generischen Parameters enthält.

Die TypeSpec-Tabelle (ECMA II.23.2.14) wird verwendet, um Instanzen parametrisierter Schnittstellen zu definieren. Diese TypeSpecs können dann ähnlich wie TypeRefs in Methodensignaturen und Schnittstellenimplementierungen verwendet werden.

Interface members (Schnittstellenmember)

Arrayparameter

Beim Codieren eines Arrayparameters für einen beliebigen Schnittstellenmembertyp wird der Arraylängenparameter, der unmittelbar vor dem Arrayparameter steht, sowohl aus dem MethodDefSig-Blob als auch aus der params-Tabelle weggelassen.

Die Richtung des Arrayparameters wird direkt in Metadaten codiert. Die Richtung des Arraylängenparameters kann wie folgt abgeleitet werden.

Wenn der Arrayparameter ein in-Parameter ist, muss der Arraylängenparameter auch ein in-Parameter sein.
Wenn der Arrayparameter ein out-Parameter ist und den BYREF-Marker nicht trägt, ist die Arraylänge ein in-Parameter.
Wenn der Arrayparameter ein out-Parameter ist und den BYREF-Marker enthält, ist die Arraylänge ein out-Parameter.

Methoden

Um die erwartete Projektion von Methoden sowie die CLR-Kompatibilität besser zu modellieren, wird der erforderliche HRESULT-Rückgabewert nicht in Metadaten codiert. Stattdessen wird der out-Parameter, der als Rückgabewert verwendet werden soll, als Rückgabewert in der methodDefSig codiert. Für Methoden, die keinen out-Parameter deklarieren, der als Rückgabewert verwendet werden soll, muss methodDefSig den Rückgabetyp als void deklarieren (gemäß ECMA II.23.2.11).

Jede Methode für eine Schnittstelle wird als Zeile in der MethodDef-Tabelle dargestellt. Jede Methoddef-Zeile enthält die folgenden Informationen.

RVA: 0x00
ImplFlags: 0x00
Flags: öffentliche | Virtuelle | HideBySig-| Abstrakte | NewSlot-| Instanz (0x5c6)
Name: Ein Index in der Zeichenfolgentabelle, der den Namen der Methode enthält.
Signatur: Ein Index im Blobheap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das die Parametertypen und den Rückgabetyp der Methode enthält. Wenn die Schnittstelle parametrisiert ist, sollte das MethodDefSig-Blob über den GENERICINST-codierten Typ (gemäß ECMA II.23.2.12) auf jeden Typparameter der Schnittstelle verweisen. Details zu parametrisierten Schnittstellen, die folgen sollen.
ParamList: Ein Index in der Param-Tabelle (ECMA II.22.33), der den ersten in einer Ausführung von Param-Zeilen enthält, die dieser Methode zugeordnet sind.

Jeder Parameter der -Methode (plus des Rückgabewerts, falls angegeben) verfügt über eine entsprechende Zeile in der Param-Tabelle (ECMA II.22.33).

Flags: keine, ein- oder ausgehende Flags, die für den Parameter geeignet sind.
- Rückgabewerte sind immer keine.
- Andere Parameter sind immer ein- oder ausgehend.
Sequence: Sequenzreihenfolge des Parameters.
- 0 (null) ist für den Rückgabewert der Methode reserviert.
Name: Index in den Zeichenfolgenheap, der den Namen des Parameters enthält.

Jede Methode kann optional über ein OverloadAttribute verfügen, das den eindeutigen Methodennamen (innerhalb des Bereichs der Schnittstelle) enthält. Jede Methode kann optional über ein DefaultOverloadAttribute verfügen, das angibt, welche überladene Methode der gleichen Arität (Anzahl von in Parametern) in schwachen, dynamisch typisierten Sprachen projiziert werden soll.

Eigenschaften

Jede Eigenschaft in einer Schnittstelle wird in den Tabellen Property (ECMA II.22.34), PropertyMap (ECMA II.22.35), MethodSemantics (ECMA II.22.28) und MethodDef (ECMA II.22.26) als Zeilen definiert.

Jede Schnittstelle mit einer oder mehreren Eigenschaften wird als einzelne Zeile in der PropertyMap-Tabelle dargestellt, die die folgenden Informationen enthält.

Übergeordnetes Element: Ein Index in der TypeDef-Tabelle, der die Schnittstelle enthält, die die Eigenschaften enthält.
PropertyList: Ein Index in der Property-Tabelle, der den ersten in einer Ausführung von Zeilen enthält, die diesem Typ zugeordnet sind.

Jede Eigenschaft wird als einzelne Zeile in der Property-Tabelle dargestellt, die die folgenden Informationen enthält.

Flags: Keine.
Name: Ein Index im Zeichenfolgenheap, der den Namen der Eigenschaft enthält.
Typ: Index in den Blobheap, der ein PropertySig-Blob (ECMA II.23.2.5) enthält, das die Typinformationen für die Eigenschaft enthält.

Jede Eigenschaft wird in der MethodDef-Tabelle als eine oder zwei Zeilen dargestellt. Schreibgeschützte Eigenschaften werden als einzelne Methode mit dem Präfix "get_" dargestellt, während Lese-/Schreibeigenschaften als zwei Methoden dargestellt werden, eine mit dem Präfix "get_" und die andere mit dem Präfix "put_". Die Signatur für die get-Methode nimmt keine Parameter an und gibt einen Wert des Eigenschaftstyps zurück. Die Signatur für die set-Methode verwendet einen einzelnen Parameter des Eigenschaftstyps und gibt nichts zurück.

Die MethodDef-Zeilen für die -Eigenschaft enthalten Folgendes.

RVA: 0
ImplFlags: Keine
Flags: öffentliche | virtuelle | HideBySig-| newSlot | abstrakte | specialname (0xDC6)
Name: Ein Index in der Zeichenfolgentabelle, der je nach Bedarf "get_<PropertyName>" oder "put_<PropertyName>" enthält.
Signatur: Ein Index im Blobheap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das die Parametertypen und den Rückgabetyp der Methode enthält, wie oben beschrieben.
ParamList: Ein Index in der Param-Tabelle (ECMA II.22.33), der den ersten in einer Ausführung von Param-Zeilen enthält, die dieser Methode zugeordnet sind. Die Werte in der Param-Tabelle sind wie unter den oben beschriebenen Methoden angegeben.

Jeder MethodDef-Zeile für die Eigenschaft ist eine Zeile in der MethodSemantics-Tabelle zugeordnet, die die folgenden Informationen enthält.

Semantik: Getter oder Setter nach Bedarf.
Methode: Index in die MethodDef-Tabelle, die die Getter- oder Settermethode enthält.
Zuordnung: Index in die Property-Tabelle, die die Eigenschaft enthält.

Ereignisse

Jedes Ereignis auf einer Schnittstelle wird als Zeilen in den Tabellen Event (ECMA II.22.13), EventMap (ECMA II.22.12), MethodSemantics (ECMA II.22.28) und MethodDef (ECMA II.22.26) definiert.

Jede Schnittstelle mit einem oder mehreren Ereignissen wird als einzelne Zeile in der EventMap-Tabelle dargestellt, die die folgenden Informationen enthält.

Übergeordnetes Element: Ein Index in der TypeDef-Tabelle, der die Schnittstelle enthält, die die Eigenschaften enthält.
EventList: Ein Index in der Event-Tabelle, der den ersten in einer Ausführung von Zeilen enthält, die diesem Typ zugeordnet sind.

Jedes Ereignis wird als einzelne Zeile in der Tabelle Event dargestellt, die die folgenden Informationen enthält.

EventFlags: Keine.
Name: Ein Index im Zeichenfolgenheap, der den Namen der Eigenschaft enthält.
EventType: Eine TypeDefOrRef,die in die entsprechende Tabelle indiziert, die den Delegattyp des Ereignisses enthält.

Jedes Ereignis wird in der MethodDef-Tabelle als zwei Zeilen dargestellt, eine mit dem Präfix "add_" zum Hinzufügen von Ereignislistenern und eine mit dem Präfix "remove_" zum Entfernen von Ereignislistenern. Die add-Methode nimmt eine Delegatinstanz entgegen und gibt eine Windows zurück. Foundation.EventRegistrationToken, das die Ereignisregistrierung darstellt. Die remove-Methode verwendet das eventRegistrationToken, das von der add-Methode zurückgegeben wird, um die Registrierung des Ereignisses aufzuheben.

Die MethodDef-Zeilen für das Ereignis enthalten Folgendes.

RVA: 0
ImplFlags: Keine
Flags: öffentliche | Letzte | virtuelle | hidebysig | newslot | specialname (0x09e6)
Name: Ein Index in der Zeichenfolgentabelle, der je nach Bedarf "add_<PropertyName>" oder "remove_<PropertyName>" enthält.
Signatur: Ein Index im Blobheap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das den Parameter und die Rückgabetypen der Methode enthält, wie unten beschrieben.
- Add_ Methode verwendet einen einzelnen Parameter des Delegattyps und gibt einen Windows zurück. Foundation.EventRegistrationToken.
- Remove_-Methode verwendet eine einzelne Windows. Foundation.EventRegistrationToken-Parameter und gibt nichts zurück.
ParamList: Ein Index in der Param-Tabelle (ECMA II.22.33), der den ersten in einer Ausführung von Param-Zeilen enthält, die der -Methode zugeordnet sind. Die Werte in der Param-Tabelle sind wie unter den oben beschriebenen Methoden angegeben.

Beiden MethodDef-Zeilen für das Ereignis ist eine Zeile in der MethodSemantics-Tabelle zugeordnet, die die folgenden Informationen enthält.

Semantik: AddOn oder RemoveOn nach Bedarf.
Methode: Index in die MethodDef-Tabelle, die die Listenermethode zum Hinzufügen oder Entfernen enthält.
Zuordnung: Index in die Ereignistabelle, die das Ereignis enthält.

Laufzeitklassen

Laufzeitklassen werden als Zeile in der TypeDef-Tabelle (ECMA II.22.37) implementiert, wobei die Spalten wie folgt festgelegt sind.

Flags: Alle Laufzeitklassen müssen die Flags public, auto layout, class und tdWindowsRuntime tragen.
- Nur statische Klassen haben das abstrakte Flag. Alle anderen Klassen haben nicht das abstrakte Flag.
- Klassen, die nicht composable sind, tragen das versiegelte Flag. Die klassenfähigen Klassen tragen nicht das versiegelte Flag.
Name: Ein Index in der Zeichenfolgentabelle, die den Klassennamen enthält.
Namespace: Ein Index im Zeichenfolgenheap, der den Namespace des Typs enthält.
Erweitert: ein Index in TypeRef, der entweder auf eine composable-Klasse oder auf System.Object in mscorlib verweist.
FieldList: muss leer sein.
MethodList: Ein Index in der MethodDef-Tabelle, der den ersten einer zusammenhängenden Ausführung von Methoden markiert, die sich im Besitz dieses Typs befinden. Einzelheiten zum Inhalt der MethodDef-Tabelle finden Sie unten.

Für alle vom System bereitgestellten Klassen muss versionAttribute der TypeDef-Zeile der Klasse hinzugefügt werden.

Implementierte Schnittstellen

Schnittstellen, die von Laufzeitklassen implementiert werden, werden durch Zeilen in der InterfaceImpl-Tabelle (ECMA II.22.23) dargestellt, wobei die Spalten wie folgt festgelegt sind.

Klasse: Ein Index in der TypeDef-Tabelle für die Zeile, die den Typ enthält.
Schnittstelle: Ein Index in der TypeDef-, TypeRef- oder TypeSpec-Tabelle, der die implementierte Schnittstelle angibt. Beachten Sie, dass dies in vom System bereitgestellten Metadatendateien niemals eine TypeDef ist, auch wenn die erforderliche Schnittstelle in derselben Metadatendatei definiert ist. Weitere Informationen finden Sie im Abschnitt TypeDef-Umleitung.

Laufzeitklassen müssen das DefaultAttribute für genau eine ihrer InterfaceImpl-Zeilen angeben.

Laufzeitklassen können overridableAttribute oder ProtectedAttribute für eine ihrer InterfaceImpl-Zeilen angeben. Sie dürfen nicht sowohl OverridableAttribute als auch ProtectedAttribute in derselben Zeile angeben.

Optional kann das VersionAttribute einer beliebigen interfaceImpl-Zeile der Klasse hinzugefügt werden. Der Versionswert aus versionAttribute in den interfaceImpl-Zeilen einer beliebigen Klasse muss größer oder gleich dem Wert aus versionAttribute in der TypeDef-Zeile der Klasse sein.

Statische Schnittstellen

Laufzeitklassen verfügen über 0 (null) oder mehr benutzerdefinierte StaticAttribute-Attribute. Es ist zulässig, mehr als ein benutzerdefiniertes StaticAttribute-Attribut anzugeben, solange jedes über unterschiedliche angegebene Parameter verfügt. Jedes StaticAttribute wird als Zeile in der CustomAttribute-Tabelle mit den folgenden Informationen angezeigt.

Parent: Die Laufzeitklasse, der StaticAttribute zugeordnet ist.
Typ: Ein Verweis auf staticAttributes .ctor.
Wert: Ein benutzerdefiniertes Attributblob, das den statischen System.Type-Schnittstellenparameter und den Uint32-Versionsparameter enthält.

Aktivierung

Laufzeitklassen verfügen über 0 (null) oder mehr benutzerdefinierte Attribute von ActivatableAttribute. Es ist zulässig, mehr als ein benutzerdefiniertes ActivatableAttribute-Attribut anzugeben, solange jedes über unterschiedliche angegebene Parameter verfügt. Alle ActivatableAttributes werden als Zeile in der CustomAttribute-Tabelle mit den folgenden Informationen angezeigt.

Parent: Die Laufzeitklasse, der ActivatableAttribute zugeordnet ist.
Typ: Ein Verweis auf einen der beiden Ctors von ActivatableAttribute.
- Direkte Aktivierung: .ctor, der nur den Uint32-Versionsparameter verwendet.
- Factoryaktivierung: der .ctor, der den System.Type-Factoryschnittstellenparameter und den Uint32-Versionsparameter verwendet.
Wert: Ein benutzerdefiniertes Attributblob, das den System.Type-Factoryschnittstellenparameter (sofern angegeben) und den Uint32-Versionsparameter enthält.

Zusammensetzung

Laufzeitklassen verfügen über 0 (null) oder mehr benutzerdefinierte ComposableAttribute-Attribute. Es ist zulässig, mehr als ein benutzerdefiniertes ComposableAttribute-Attribut anzugeben, solange jedes über unterschiedliche angegebene Parameter verfügt. Jedes ComposableAttribute-Attribut wird als Zeile in der CustomAttribute-Tabelle mit den folgenden Informationen angezeigt.

Parent: Die Laufzeitklasse, der das ComposableAttribute zugeordnet ist.
Typ: Ein Verweis auf den .ctor von ComposableAttribute.
Wert: ein benutzerdefiniertes Attributblob, das den Schnittstellenparameter der System.Type-Kompositionsfactory, einen CompositionType-Enumerationswert (Öffentlich oder Geschützt) und den Uint32-Versionsparameter enthält.

Klassenmethoden

Eine Laufzeitklasse enthält eine Zeile in der MethodDef-Tabelle für jede Methode auf jeder Schnittstelle, die der Klasse zugeordnet ist. Dazu gehören Memberschnittstellen (normal, geschützt und überschreibbar), statische Schnittstellen, Aktivierungsfactoryschnittstellen und konfigurierbare Factoryschnittstellen. Darüber hinaus enthält eine Klasse, die die direkte Aktivierung unterstützt, auch eine Zeile in der MethodDef-Tabelle, um dies anzugeben.

Memberschnittstellenmember

Jede Methode aus einer Memberschnittstelle (einschließlich geschützter und überschreibbarer Schnittstellen) wird durch eine Zeile in der MethodDef-Tabelle der Klasse dargestellt. Die methodDef-Tabelle der Klasse enthält eine genaue Kopie der MethodDef-Informationen aus der ursprünglichen deklarierenden Schnittstelle, einschließlich Param-Tabellenzeilen und benutzerdefinierten Attributen, mit den folgenden Ausnahmen.

Laufzeitklassen können alternative Namen für Methoden angeben, die für Memberschnittstellen definiert sind.
Methoden für Laufzeitklassen erhalten das Abstract-Flag nicht.
Methoden für Laufzeitklassen erhalten das Runtime MethodImpl-Flag.
Methoden aus nicht überschreibbaren Schnittstellen erhalten zusätzlich das Final-Flag. Methoden von überschreibbaren Schnittstellen erhalten das Final-Flag nicht.

Jede Zeile in der MethodDef-Tabelle einer Klasse aus einer Memberschnittstelle wird wie folgt mit der Schnittstellenmethode verbunden, die die Methode ursprünglich über einen Eintrag in der MethodImpl-Tabelle (ECMA II.22.27) mit Werten definiert hat.

Klasse: Ein Index in der TypeDef-Tabelle, der auf die Klasse verweist, die die -Methode enthält (beachten Sie, dass dieser Index nicht der TypeDef-Umleitung unterliegt).
MethodBody: Ein Index in der MethodDef-Tabelle, der auf die -Klassenmethode verweist.
MethodDeclaration: Ein Index in der MethodDef- oder MemberRef-Tabelle, der auf die ursprünglich deklarierte Schnittstellenmethode verweist.

Statische Schnittstellenmember

Jede Methode aus einer statischen Schnittstelle wird durch eine Zeile in der MethodDef-Tabelle der Klasse dargestellt. Die methodDef-Tabelle der Klasse enthält eine genaue Kopie der MethodDef-Informationen aus der ursprünglichen deklarierenden Schnittstelle, einschließlich Param-Tabellenzeilen und benutzerdefinierten Attributen, mit den folgenden Ausnahmen.

Statische Member erhalten die Flags Virtual, Abstract, NewSlot und Instance nicht.
Statische Member erhalten die Flags Static und Class.
Statische Methoden für Laufzeitklassen erhalten das Runtime MethodImpl-Flag.

Aktivierungsmitglieder

Klassen, die die direkte, parameterlose Aktivierung unterstützen, verfügen über eine Konstruktorzeile in der MethodDef-Tabelle der Klasse mit den folgenden Spaltenwerten.

RVA: 0x00
ImplFlags: Runtime
Flags: öffentliche | HideBySig-| SpecialName | RTSpecialName | Instanz
Name: Ein Index in der Zeichenfolgentabelle, der ".ctor" enthält.
Signatur: Ein Index im Blob-Heap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das keine Parameter enthält und NULL zurückgibt.
ParamList: muss leer sein

Klassen, die die Factoryaktivierung unterstützen, verfügen über eine Konstruktorzeile in der MethodDef-Tabelle der Klasse für jede Methode in jeder implementierten Factoryschnittstelle mit den folgenden Spaltenwerten.

RVA: 0x00
ImplFlags: Runtime
Flags: öffentliche | HideBySig-| SpecialName-| RTSpecialName | Instanz
Name: Ein Index in der Zeichenfolgentabelle, der ".ctor" enthält.
Signatur: Ein Index im Blob-Heap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das die Eingabeparameter enthält und NULL zurückgibt.
ParamList: Zeiger in die Params-Tabelle mit einer Zeile für jeden Parameter, die genau aus der Params-Tabelle für die ursprünglich deklarative Factorymethode kopiert wurde.

Kompositionsmitglieder

Klassen, die die Kompositions factory-Aktivierung unterstützen, verfügen über eine Konstruktorzeile in der MethodDef-Tabelle der Klasse für jede Methode in jeder implementierten Factoryschnittstelle mit den folgenden Spaltenwerten.

RVA: 0x00
ImplFlags: Runtime
Flags: öffentliche | HideBySig-| SpecialName-| RTSpecialName | Instanz
Name: Ein Index in der Zeichenfolgentabelle, der ".ctor" enthält.
Signatur: Ein Index im Blob-Heap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das die benutzerdefinierten Eingabeparameter enthält und NULL zurückgibt. Der steuernde IInspectable*-Parameter [in] und der nicht delegierende IInspectable**-Parameter [out] werden nicht in der Methodensignatur widergespiegelt.
ParamList: Zeiger in die Params-Tabelle mit einer Zeile für jeden Parameter mit Ausnahme des steuernden IInspectable*-Parameters [in] und des nicht delegierenden IInspectable**-Parameters [out], der genau aus der Params-Tabelle für die ursprünglich deklarierende Factorymethode kopiert wurde.

Benutzerdefinierte Attribute

Benutzerdefinierte Attribute verfügen über null oder mehr Konstruktormethoden, von denen jede null oder mehr Parameter aufgibt, wobei der Parametertyp auf die grundlegenden Typen, Enums und System.Type beschränkt ist. Jeder Konstruktor im benutzerdefinierten Attribut wird als Zeile in der MethodDef mit den folgenden Informationen angezeigt.

RVA (relative virtuelle Adresse): NULL
ImplFlags: Keine
Flags: öffentliche | HideBySig-| specalname | RTSpecialName (0x1886)
Name: Ein Index in der Zeichenfolgentabelle, der den Namen ".ctor" enthält.
Signatur: Ein Index im Blob-Heap, der ein MethodDefSig-Blob (ECMA II.23.2.1) enthält, das die Parametertypen und den Rückgabetyp der Methode enthält.
ParamList: Ein Index in der Param-Tabelle (ECMA II.22.33), der die erste in einer Ausführung von Param-Zeilen enthält, die dieser Methode zugeordnet sind.

Benutzerdefinierte Attribute für Metadatenkonstrukte werden als Zeilen in der CustomAttribute-Tabelle (ECMA II.22.10) gespeichert, und die Spalten werden wie folgt festgelegt.

Übergeordnetes Element: Index in der Metadatentabelle, an die das benutzerdefinierte Attribut angefügt ist.
Typ: Index in der MethodDef- oder MemberRef-Tabelle, die einen Verweis auf den Konstruktor des Attributtyps enthält.
Wert: Index im Blob-Heap, der positions- und benannte Attributparameter enthält (ECMA II.23.2). Da benutzerdefinierte WinRT-Attribute keine Eigenschaften aufweisen dürfen, enthält das blob des benutzerdefinierten Attributs niemals benannte Argumente im PROPERTY-Stil.

Freigeben über