Metadatentokens
Metadaten verweisen auf deklarative Informationen über Abstraktionen, z. B. Laufzeittypen (Klassen, Werttypen und Schnittstellen), globale Funktionen und globale Variablen. Die Metadaten werden in Tabellen gespeichert. Jede Abstraktionskategorie wird dabei in einer Tabelle und jede Deklaration einer Abstraktion in einer Tabellenzeile gespeichert. Mit einem Token (d. h. einem Objekt vom Typ mdToken) wird der Datensatz gesucht, der die Metadaten für eine Abstraktion enthält. Das Metadatenmodul verwendet das Token, um in einer spezifischen Metadatentabelle in einem bestimmten Metadatenbereich einen Index zu erstellen.
Struktur von Metadatentoken
Ein Metadatentoken ist ein 4-Byte-Wert. Das signifikanteste Byte (Most Significant Byte, MSB) gibt den Tokentyp an und identifiziert somit die Abstraktion und die zugeordnete Metadatentabelle. Beispiel: Der Wert 1 im MSB bedeutet, dass es sich bei dem Token um ein mdTypeRef-Token handelt, das einen Typverweis darstellt, und dass die zugehörigen Metadaten in der TypeRef-Metadatentabelle gespeichert werden. Der Wert 4 im MSB entspricht einem mdFieldDef-Token. Mithilfe der CorTokenType-Enumeration werden die Tokentypen angegeben.
Die unteren drei Bytes werden als Datensatzbezeichner (Record Identifier, RID) bezeichnet und enthalten den Index der Zeile in der Metadatentabelle, auf die das MSB des Tokens verweist. Beispiel: Das Metadatentoken mit dem Wert 0x02000007 verweist im aktuellen Bereich auf Zeile 7 in der TypeDef-Tabelle. Gleichermaßen verweist das Token 0x0400001A im aktuellen Bereich auf Zeile 26 (dezimal) in der FieldDef-Tabelle. Die Zeile 0 (null) einer Metadatentabelle enthält niemals Daten. Daher werden Metadatentoken, deren RID 0 (null) ist, als nil-Token bezeichnet. Die Metadaten-API definiert eine Vielzahl solcher nil-Token – eines für jeden Tokentyp, z. B. mdTypeRefNil mit dem Wert 0x01000000.
.gif "Hinweis") Hinweis |
|---|
Die vorangegangene Erläuterung von RIDs dient der Begriffserklärung. Tatsächlich ist das physikalische Layout der Metadaten wesentlich komplizierter.Darüber hinaus verhält es sich bei Zeichenfolgetoken (mdString) ein wenig anders: Die unteren drei Bytes sind kein Datensatzbezeichner, sondern ein Offset zur Anfangsposition der Zeichenfolge im Metadatenzeichenfolgenpool. |
Verwenden von Metadatentoken
Jede DefineXXX-Methode in der Metadaten-API gibt ein Token zurück, das an eine GetXXX-Methode übergeben werden kann, um die zugehörigen Attribute abzurufen.
Metadatentoken werden innerhalb eines Bereichs definiert. Beispiel: Innerhalb eines bestimmten Bereichs identifiziert ein Metadatentoken mit dem Wert N vollständig einen Datensatz, der Details zu einer Typdefinition enthält. In einem anderen Bereich gibt ein Metadatentoken mit demselben Wert N jedoch unter Umständen einen ganz anderen Datensatz an.
Ein Metadatentoken ist kein unveränderlicher Metadaten-Objektbezeichner. Bei einer Zusammenführung zweier Bereiche werden Token aus dem importierten Bereich Token im ausgegebenen Bereich neu zugeordnet. Wenn ein Metadatenbereich gespeichert wird, können verschiedene Formatoptimierungen zu einer Neuzuordnung von Token führen.
Tokentypen
In der folgenden Tabelle werden die Metadatentokentypen, die Abstraktion, die jeder Tokentyp darstellt, und der Name der Metadatentabelle aufgelistet, die die Metadaten der Abstraktion enthält. Alle Tokentypen sind Variationen von mdToken, dem grundlegenden Tokentyp.
Tokentyp |
Metadatentabelle |
Abstraktion |
|---|---|---|
mdModule |
Modul |
Modul: Eine Kompilierungseinheit, eine ausführbare Datei oder eine andere Entwicklungseinheit, Bereitstellungseinheit oder Laufzeiteinheit. Es ist möglich (aber nicht erforderlich), Attribute für das gesamte Modul zu deklarieren, einschließlich Name, GUID, benutzerdefinierten Attributen usw. |
mdModuleRef |
ModuleRef |
Modulverweis: Ein Kompilierzeitverweis auf ein Modul, der die Quelle für Typ- und Memberimporte erfasst. |
mdTypeDef |
TypeDef |
Typdeklaration: Deklaration eines Laufzeitverweistyps (Klasse oder Schnittstelle) oder eines Werttyps. |
mdTypeRef |
TypeRef |
Typverweis: Verweis auf einen Laufzeitverweistyp oder einen Werttyp. Die Auflistung von Typverweisen in einem Modul ist in gewisser Hinsicht eine Auflistung von Importabhängigkeiten für die Kompilierzeit. |
mdMethodDef |
MethodDef |
Methodendefinition: Definition einer Methode als Member einer Klasse oder Schnittstelle oder als globale Methode auf Modulebene. |
mdParamDef |
ParamDef |
Parameterdeklaration: Definition einer optionalen Datenstruktur, in der zusätzliche Metadaten für den Parameter gespeichert werden. Es ist nicht notwendig, für jeden Parameter in einer Methode eine Datenstruktur auszugeben. Wenn jedoch zusätzliche Metadaten für den Parameter beibehalten werden sollen, beispielsweise Marshalling- oder Typzuordnungsinformationen, kann eine optionale Datenstruktur erstellt werden. |
mdFieldDef |
FieldDef |
Felddeklaration: Deklaration einer Variablen als Datenmember einer Klasse oder Schnittstelle bzw. Deklaration einer globalen Variablen auf Modulebene. |
mdProperty |
Property |
Eigenschaftendeklaration: Deklaration einer Eigenschaft als Member einer Klasse oder Schnittstelle. |
mdEvent |
Event |
Ereignisdeklaration: Deklaration eines benannten Ereignisses als Member einer Klasse oder Schnittstelle. |
mdMemberRef |
MemberRef |
Memberverweis: Verweis auf eine Methode oder ein Feld. Für jeden Methodenaufruf oder Feldzugriff durch eine beliebige Implementierung im aktuellen Modul wird in den Metadaten ein Memberverweis generiert. Dabei wird im MSIL-Stream (Microsoft Intermediate Language) ein Token beibehalten. Für Eigenschaften- oder Ereignisverweise besteht keine Laufzeitunterstützung. |
mdIfaceImpl |
IfaceImpl |
Schnittstellenimplementierung: Die Implementierung einer bestimmten Schnittstelle für eine bestimmte Klasse. Diese Metadatenabstraktion ermöglicht die Speicherung von Informationen, die die Schnittmenge der Elemente bildet, die weder für die Klasse noch für die Schnittstelle spezifisch sind. |
mdMethodImpl |
MethodImpl |
Methodenimplementierung: Die Implementierung einer durch Schnittstellenvererbung vererbten Methode für eine bestimmte Klasse. Diese Metadatenabstraktion ermöglicht die Speicherung von Informationen, die beibehalten werden sollen und die nicht für den Vertrag, sondern für die Implementierung spezifisch sind. Methodendeklarationsinformationen können von der Implementierungsklasse nicht geändert werden. |
mdCustomAttribute |
CustomAttribute |
Benutzerdefiniertes Attribut: Eine beliebige Datenstruktur, die jedem Metadatenobjekt zugeordnet wird, auf das mit einem mdToken verwiesen werden kann. (Dabei besteht die Ausnahme, dass benutzerdefinierte Attribute selbst keine benutzerdefinierten Attribute haben können.) |
mdPermission |
Berechtigung |
Berechtigungssatz: Ein deklarativer Sicherheitsberechtigungssatz, der mdTypeDef, mdMethodDef und mdAssembly zugeordnet ist. Weitere Informationen finden Sie unter Hinzufügen der Unterstützung der deklarativen Sicherheit. |
mdTypeSpec |
TypeSpec |
Typkonstruktor: Eine Methode, die ein Token für einen Typ (z. B. einen geschachtelten Werttyp) abruft, der als Eingabe für jede MSIL-Anweisung verwendet werden kann, die einen Typ akzeptiert. |
mdSignature |
Signatur |
Eigenständige Signatur: Die Signatur einer lokalen Variablen in der übertragbaren ausführbaren Datei (Portable Executable, PE) oder die Signatur einer Methode, die an eine MSIL-Anweisung übergeben wird. |
mdString |
String |
Benutzerzeichenfolge: Eine Zeichenfolge, die an eine MSIL-Anweisung übergeben wird. |
| Hinweis |
|---|
Anders, als vielleicht erwartet werden könnte, enthält die obige Liste nicht zwei separate Tokentypen (einen für einen Feldverweis und einen anderen für einen Methodenverweis).Feld- und Methodenverweise verwenden gemeinsam dieselbe Tabelle. Mit dem Tokentyp mdMemberRef kann auf sie verwiesen werden. |
Erweiterbarkeit und Abstraktionen
Laufzeitmetadaten können erweitert werden. Dies ist in folgenden Szenarien wichtig:
Zur Darstellung von Einschränkungen oder höheren Abstraktionsebenen, die von der Common Language Specification (CLS) definiert werden. Das CLS ist eine Spezifikation für Konventionen, die Sprachen und Tools zur Erzielung einer besseren Sprachintegration übereinstimmend unterstützen. Das CLS schränkt möglicherweise Teile des Modells des allgemeinen Typsystems ein und führt unter Umständen höhere Abstraktionsebenen ein, die über dem allgemeinen Typsystem angeordnet sind. Die Metadaten müssen diese von Tools verwendeten Typen von Entwicklungszeitabstraktionen erfassen können, selbst wenn die Abstraktionen von der Laufzeit nicht explizit erkannt oder unterstützt werden.
Zur Darstellung von sprachspezifischen Abstraktionen, die dem allgemeinen Typsystem nicht angehören und keine CLS-Abstraktionen sind. Hierdurch können Sprachen wie Visual C auch ohne separate Headerdateien oder IDL-Dateien Typen, Methoden und Datenmember verwenden, die von kompilierten Modulen exportiert wurden.
Zum Codieren von memberinternen Signaturtypen und Typmodifizierern, die beim sprachspezifischen Überladen verwendet werden.
Metadaten können auf folgende Arten erweitert werden:
Jedes Metadatenobjekt kann benutzerdefinierte Attribute unterstützten. Die Metadaten-APIs bieten eine Möglichkeit, benutzerdefinierte Attribute zu deklarieren, aufzulisten und abzurufen. Benutzerdefinierte Attribute können durch einen Typverweis (mdTypeDef und mdTypeRef) identifiziert werden. Die Struktur der benutzerdefinierten Attribute ist selbstbeschreibend. Dabei werden Datenmember verwendet, die für den Typ deklariert wurden. Die Codierung von Werten kann mit einem beliebigen Tool, z. B. den Reflektionsdiensten der Laufzeit, durchsucht werden.
Neben einer Erweiterung des allgemeinen Typsystems besteht die Möglichkeit, benutzerdefinierte Modifizierer in Membersignaturen auszugeben. Die Laufzeit berücksichtigt diese Modifizierer für das Überladen und Ausblenden von Methoden sowie für Bindungen. Sie erzwingt jedoch keine sprachspezifische Semantik.