Jetons de métadonnées

Les métadonnées désignent des informations déclaratives sur les abstractions, y compris les types au moment de l'exécution (classes, types valeur et interfaces), les fonctions globales et les variables globales. Les métadonnées sont stockées dans des tables ; une table pour chaque catégorie d'abstraction et une ligne de la table pour chaque déclaration d'une abstraction. Un jeton (un objet de type mdToken) est utilisé pour localiser l'enregistrement qui contient les métadonnées pour une abstraction. Le moteur de métadonnées utilise ce jeton pour indexer dans une table de métadonnées particulière dans une portée de métadonnées spécifique.

Structure de jeton de métadonnées

Un jeton de métadonnées est une valeur stockée sur quatre octets. L'octet le plus significatif spécifie le type de jeton, et identifie par conséquent l'abstraction et sa table de métadonnées associée. Par exemple, une valeur de 1 dans l'octet le plus significatif indique que le jeton est un jeton mdTypeRef, qui représente une référence de type, et ses métadonnées sont stockées dans la table de métadonnées TypeRef. Une valeur de 4 dans l'octet le plus significatif correspond à un jeton mdFieldDef. L'énumération CorTokenType sert à spécifier les types de jetons.

Les trois octets inférieurs, appelés identificateur d'enregistrement (RID, Record Identifier), contiennent l'index de la ligne dans la table de métadonnées à laquelle l'octet le plus significatif du jeton fait référence. Par exemple, le jeton de métadonnées avec la valeur 0x02000007 fait référence à la ligne 7 dans la table TypeDef dans la portée actuelle. De la même manière, le jeton 0x0400001A fait référence à la ligne 26 (décimal) dans la table FieldDef dans la portée actuelle. La ligne 0 d'une table de métadonnées ne contient jamais de données ; par conséquent, un jeton de métadonnées dont l'identificateur d'enregistrement est égal à zéro est appelé jeton nil. L'API de métadonnées définit un hôte pour ces jetons nil, un pour chaque type de jeton, tel que mdTypeRefNil, avec la valeur 0x01000000.

Remarque

L'explication ci-dessus concernant les identificateurs d'enregistrement est conceptuelle ; en réalité, la disposition physique des métadonnées est beaucoup plus complexe.De plus, les jetons de chaîne (mdString) sont légèrement différents ; les trois octets inférieurs ne sont pas des identificateurs d'enregistrement, mais représentent un offset pour l'emplacement de départ de la chaîne dans le pool de chaînes de métadonnées.

Utilisation des jetons de métadonnées

Chaque méthode DefineXXX dans l'API de métadonnées retourne un jeton qui peut être passé à une méthode GetXXX pour obtenir ses attributs associés.

Les jetons de métadonnées sont définis dans une portée. Par exemple, un jeton de métadonnées avec la valeur N identifie entièrement, dans une portée donnée, un enregistrement qui contient des détails sur une définition de type. Toutefois, dans une portée différente, un jeton de métadonnées avec cette même valeur N peut spécifier un enregistrement complètement différent.

Un jeton de métadonnées n'est pas un identificateur d'objet de métadonnées immuable. Lorsque deux portées sont fusionnées, les jetons de la portée importée sont remappés à des jetons dans la portée émise. Lorsqu'une portée de métadonnées est enregistrée, plusieurs optimisations de format peuvent provoquer un remappage des jetons.

Types de jetons

La table suivante répertorie les types de jetons de métadonnées, l'abstraction que chaque type de jeton représente, et le nom de la table de métadonnées qui contient les métadonnées de l'abstraction. Tous les types de jetons sont des variations de mdToken, qui est le type de jeton de base.

Type de jeton	Table de métadonnées	Abstraction
mdModule	Module	Module : unité de compilation, fichier exécutable ou autre unité de développement, unité de déploiement ou unité d'exécution. Il est possible (bien que non indispensable) de déclarer des attributs sur le module dans son ensemble, y compris un nom, un GUID, des attributs personnalisés, etc.
mdModuleRef	ModuleRef	Référence de module : référence au moment de la compilation pour un module, qui enregistre la source pour les importations de membre et de type.
mdTypeDef	TypeDef	Déclaration de type : déclaration d'un type référence de runtime (classe ou/et interface) ou d'un type valeur.
mdTypeRef	TypeRef	Type référence : référence à un type référence de runtime ou à un type valeur. D'une certaine manière, la collection de références de type dans un module est la collection de dépendances d'importation de compilation.
mdMethodDef	MethodDef	Définition de méthode : définition d'une méthode comme membre d'une classe ou d'interface, ou comme méthode de niveau de module globale.
mdParamDef	ParamDef	Déclaration de paramètre : définition d'une structure de données facultative qui stocke des métadonnées supplémentaires pour le paramètre. Il n'est pas nécessaire d'émettre une structure de données pour chaque paramètre dans une méthode. Toutefois, lorsqu'il existe des métadonnées supplémentaires à rendre persistantes pour le paramètre, telles que des informations de marshaling ou de mappage de type, une structure de données de paramètre facultative peut être créée.
mdFieldDef	FieldDef	Déclaration de champ : déclaration d'une variable comme membre de données d'une classe ou d'une interface, ou une déclaration d'une variable de niveau de module globale.
mdProperty	Propriété	Déclaration de propriété : déclaration d'une propriété comme un membre d'une classe ou d'une interface.
mdEvent	Événement	Déclaration d'événement : déclaration d'un événement nommé en tant que membre d'une classe ou d'une interface.
mdMemberRef	MemberRef	Référence de membre : référence à une méthode ou un champ. Une référence de membre est générée dans des métadonnées pour chaque appel de méthode ou accès à un champ qui est effectué par une implémentation dans le module actuel, et un jeton est rendu persistant dans le flux MSIL. Il n'existe aucune prise en charge runtime pour les références d'événement ou de propriété.
mdIfaceImpl	IfaceImpl	Implémentation d'interface : implémentation d'une classe spécifique d'une interface spécifique. Cette abstraction de métadonnées permet le stockage d'informations qui sont l'intersection de ce qui n'est spécifique ni à la classe, ni à l'interface.
mdMethodImpl	MethodImpl	Implémentation de méthode : implémentation d'une classe spécifique d'une méthode héritée via l'héritage de l'interface. Cette abstraction de métadonnées permet de rendre les informations persistantes pour l'implémentation plutôt que pour le contrat. Les informations de déclaration de méthode ne peuvent pas être modifiées par la classe d'implémentation.
mdCustomAttribute	CustomAttribute	Attribut personnalisé : structure de données arbitraire associée à tout objet de métadonnées qui peut être référencé avec un mdToken. (Notez que les attributs personnalisés eux-mêmes ne peuvent pas avoir d'attributs personnalisés.)
mdPermission	Autorisation	Jeu d'autorisations : jeu d'autorisations de sécurité déclarative associé à mdTypeDef, mdMethodDef et mdAssembly. Pour plus d'informations, consultez Ajout de la prise en charge de la sécurité déclarative.
mdTypeSpec	TypeSpec	Constructeur de type : méthode qui obtient un jeton pour un type (tel qu'un type valeur boxed) qui peut être utilisé comme entrée dans toute instruction MSIL qui prend un type.
mdSignature	Signature	Signature autonome : signature de variable locale dans le fichier exécutable portable (PE) ou signature de méthode passée à une instruction MSIL.
mdString	String	Chaîne utilisateur : chaîne qui est passée à une instruction MSIL.

Remarque
La liste précédente n'inclut pas deux types de jetons séparés, un pour une référence de champ et un autre pour une référence de méthode, comme on pourrait s'y attendre.Les références de champ et de méthode partagent la même table et peuvent être référencées à l'aide du type de jeton mdMemberRef.

Extensibilité et abstractions

Les métadonnées de runtime sont extensibles, ce qui est important dans les scénarios suivants :

• Pour représenter des contraintes ou des abstractions de niveau supérieur définies par la CLS (Common Language Specification). La CLS est une spécification pour les conventions que les langages et les outils prennent en charge de manière uniforme pour une meilleure intégration du langage. La CLS peut contraindre des parties du modèle de système de type commun et peut introduire des abstractions de niveau supérieur qui sont organisées en couches sur le système de type commun. Les métadonnées doivent pouvoir capturer ces types d'abstractions de développement utilisées par les outils, bien que les abstractions ne soient pas reconnues ou prises en charge explicitement par le runtime.

• Pour représenter des abstractions spécifiques au langage qui ne font pas partie du système de type commun et ne sont pas des abstractions CLS. Ainsi, les langages tels que Visual C ne requièrent pas des fichiers IDL ou des fichiers d'en-tête séparés pour utiliser les types, les méthodes et les données membres exportés par les modules compilés.

• Pour encoder les types de signature dans les membres et les modificateurs de type qui sont utilisés dans la surcharge spécifique au langage.

L'extensibilité des métadonnées se traduit comme suit :

• Chaque objet de métadonnées peut prendre en charge les attributs personnalisés, et les API de métadonnées offrent un moyen pour déclarer, énumérer et récupérer les attributs personnalisés. Les attributs personnalisés peuvent être identifiés par une référence de type (mdTypeDef et mdTypeRef). La structure de l'attribut personnalisé est autodescriptive avec les données membres déclarées sur le type, et l'encodage de valeur peut être exploré par tout outil incluant les services de réflexion du runtime.

• Outre l'extension du système de type commun, il est possible d'émettre des modificateurs personnalisés dans les signatures de membre. Le runtime honorera ces modificateurs pour la surcharge de méthode et le masquage ainsi que pour la liaison, mais il n'appliquera aucune syntaxe de langue.

Voir aussi

Concepts

Vue d'ensemble des métadonnées