Fichiers WinMD (Windows Metadata)

Article
07/20/2023

les api Windows Runtime (WinRT) sont décrites dans les fichiers de métadonnées lisibles par ordinateur avec l’extension .winmd (également appelée métadonnées Windows). Ces fichiers de métadonnées sont utilisés par des outils et des projections de langage pour activer la projection de langue.

Remarques générales

Windows comprend des métadonnées pour toutes les api WinRT fournies par le système. Windows fournit des api pour aider les projections de langage dans la résolution des espaces de noms et des types qui ont besoin de ces métadonnées au moment de l’exécution. le SDK Windows fournit une copie des métadonnées système dans un fichier unique pour une utilisation par les projections de langage qui ont besoin de ces métadonnées au moment de la compilation.

Des tiers peuvent développer leurs propres API WinRT qui peuvent participer à une projection de langage comme le font les API fournies par le système. Les API WinRT tierces doivent fournir des métadonnées tout comme les API système. les api Windows pour l’espace de noms et la résolution de type fonctionnent sur des métadonnées tierces comme elles le font pour les métadonnées système.

Tous les types publics dans un fichier WinMD doivent être des types WinRT et doivent contenir l’indicateur tdWindowsRuntime (détails sur les indicateurs de type à suivre). Les fichiers WinMD peuvent inclure des métadonnées pour les types non WinRT. Tous les types non WinRT dans un fichier WinMD ne doivent pas être publics. La sémantique des types non WinRT est définie par l’implémentation et est en dehors de la portée de ce document.

Tous les membres de l’interface publique (méthodes, propriétés et événements) sur les types WinRT doivent être des membres d’interface WinRT. Les types WinRT peuvent inclure des métadonnées pour les membres d’interface non WinRT. Tous les membres d’interface non WinRT ne sont peut-être pas publics. La sémantique pour les membres d’interface non WinRT est définie par l’implémentation et est en dehors de la portée de ce document.

Fichiers WinMD

Format de fichier WinMD

Les fichiers WinMD utilisent le même format de fichier physique que les assemblys CLR (Common Language Runtime), comme défini par la spécification ECMA-335. Toutefois, bien que le format de fichier physique soit le même, les règles pour les combinaisons de données valides sont différentes pour les fichiers WinMD et les assemblys CLR. Ce document répertorie les deltas entre les fichiers WinMD et les assemblys CLR.

Les fichiers WinMD fournis par le système sont des métadonnées pures. Les fichiers WinMD tiers peuvent contenir du code. En particulier, les fichiers WinMD managés incluent le code MSIL (Microsoft Intermediate Language), tout comme les assemblys CLR traditionnels.

Chaque fichier WinMD contient les définitions de zéro, un ou plusieurs types WinRT. Les fichiers WinMD vides sont techniquement valides.

Il n’existe aucune restriction WinRT spécifique sur l’architecture de PEKind ou d’ordinateur répertoriée dans un WinMD.

la chaîne de version WinMD doit contenir « Windows Runtime 1,2 ».

Nom du fichier WinMD

Le nom (sans extension) d’un fichier WinMD doit être une correspondance ne respectant pas la casse de la colonne Name de la table assembly dans le fichier WinMD. Par exemple, le fichier « foo. bar. winmd » doit avoir « Foo.Bar » dans la colonne Name de la table assembly. Étant donné que le système de fichiers ne respecte pas la casse, la casse du nom de fichier peut différer de la valeur de la colonne de nom de table de l’assembly.

Tous les types WinRT dans un fichier WinMD donné doivent se trouver sous un espace de noms qui correspond au nom du fichier WinMD et à la valeur de la colonne nom de la table de l’assembly. Étant donné que le système de fichiers ne respecte pas la casse, la casse du nom de fichier peut différer de l’espace de noms de tous les types WinRT dans un fichier WinMD donné. L’espace de noms de tous les types WinRT dans un WinMD donné doit correspondre exactement à la valeur de colonne du nom de table de l’assembly (autrement dit, en respectant la casse). Par exemple, tous les types du fichier avec « Foo.Bar » dans la colonne Name de la table assembly doivent figurer dans l’espace de noms « Foo.Bar ». Les types peuvent être soit des enfants directs de cet espace de noms (par exemple, foo. bar. MyType), soit des sous-espaces de noms de cet espace de noms (par exemple, foo. bar. Baz. MyType). Le nom du fichier doit être « foo. bar. winmd », mais peut varier en cas, autrement dit, « foo. bar. winmd » et « FOO ». Bars. WINMD» est également autorisé comme nom de fichier pour ce fichier de métadonnées.

Composition WinMD

Les métadonnées de tous les types du système sont réparties sur plusieurs fichiers. winmd. Un package AppX peut inclure zéro, un ou plusieurs fichiers. winmd décrivant des composants WinRT tiers inclus dans le package d’application.

Dans tous les fichiers. winmd fournis par le système, ou inclus avec une application donnée, les métadonnées de chaque type WinRT doivent être stockées dans le fichier WinMD, avec le nom le plus long correspondant à l’espace de noms du type. Tous les types qui sont des enfants directs d’un espace de noms donné doivent se trouver dans le même fichier. Par exemple, si un package AppX contient des fichiers foo. winmd et foo. bar. winmd, le type foo. bar. Baz. MyType doit se trouver dans le fichier foo. bar. winmd, car il s’agit du fichier avec le nom de fichier le plus long correspondant à l’espace de noms pour le type dans le package.

Redirection TypeDef

Les fichiers de métadonnées fournis par le système ne référencent jamais TypeDefs directement. Même lorsque vous référencez un type défini dans le même fichier de métadonnées, les fichiers de métadonnées système référencent toujours un TypeRef qui, à son tour, fait référence à TypeDef. Cette opération est effectuée pour prendre en charge la redirection de type CLR (en projetant IVector < t > comme IList < t >, par exemple).

Les fichiers de métadonnées tiers peuvent utiliser TypeDef directement, ou rediriger toutes les références de type via un TypeRef, de la même manière que les fichiers de métadonnées système.

Codage du système de type

Tous les types de ce document issus de l’espace de noms System de l’assembly mscorlib sont utilisés comme marqueurs par WinRT. Ces types sont utilisés pour indiquer des informations sur les types et ne doivent jamais être résolus. Cela comprend (mais n’est pas limité à) System. Object, System. Guid, System. ValueType, System. Enum, System. MulticastDelegate et System. Attribute. Notez que ces noms ont été choisis pour la compatibilité avec CLR. La définition du CLR de ces types fait partie de leur système de type et n’a rien à faire avec WinRT.

Notez que la plupart des constructions décrites ici utilisent la syntaxe C#. C’est tout simplement parce qu’il est pratique de représenter certaines constructions de métadonnées Common Language Infrastructure (CLI) à l’aide de la syntaxe C#. Les constructions réelles sont des constructions de métadonnées CLI pures.

Espace de noms

WinRT encode l’espace de noms et le nom local d’un type dans une chaîne délimitée par un point unique. Par exemple, le type défini dans cet extrait de code est «Windows. Foundation. ISimpleInterface».

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

Pour l’optimisation de l’espace, la table TypeDef dans les métadonnées CLI fournit des colonnes distinctes pour le nom de type et le nom de l’espace de noms. Toutefois, au niveau de l’API, la propriété TypeDef expose uniquement le nom du type.

Types fondamentaux

Tous les types fondamentaux de WinRT, à l’exception de GUID, ont des valeurs constantes explicites à utiliser dans les objets BLOB de métadonnées CLI et d’autres références de type. Ces valeurs de constantes sont décrites dans la partition 2, section 23.1.16 de la spécification CLI.

Type WinRT	Nom du type d’élément CLI	Valeur du type d’élément CLI
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
Unique	ELEMENT_TYPE_R4	0x0c
Double	ELEMENT_TYPE_R8	0x0D
Char16	ELEMENT_TYPE_CHAR	0x03
Boolean	ELEMENT_TYPE_BOOL	0x02
String	ELEMENT_TYPE_STRING	0x0E

Comme il n’a pas de valeur de constante ELEMENT_TYPE_ * explicite pour eux, les GUID sont représentés dans les métadonnées en tant que TypeRef du type System. Guid de l’assembly mscorlib.

Énumérations

Les énumérations sont représentées sous la forme d’une ligne dans la table TypeDef (ECMA II. 22.37) avec les colonnes définies comme suit.

Père. Définir sur public | Sealed | tdWindowsRuntime (0x4101).
Nom. Index dans le tas de chaîne qui contient le nom du type.
Espace de noms. Index dans le tas de chaîne qui contient l’espace de noms du type.
Dure. Définissez sur un TypeRef qui fait référence à la classe System. Enum de l’assembly mscorlib.
FieldList. Index dans la table de champs, qui marque la première d’une série contiguë de champs appartenant à ce type.
MethodList. Doit être vide.

Une énumération a un champ d’instance unique qui spécifie le type d’entier sous-jacent pour l’énumération, ainsi que zéro, un ou plusieurs champs statiques ; une pour chaque valeur enum définie par le type enum.

Le type d’entier sous-jacent de l’énumération apparaît en tant que première ligne dans la table de champs (ECMA II. 22.15) associée au type (c’est-à-dire celui référencé dans la colonne FieldList spécifiée ci-dessus). Les colonnes de la table Field pour le type enum sont les suivantes.

Indicateurs : privé | SpecialName | RTSpecialName (0x601).
Name : index dans le tas de chaîne qui contient le nom « value__ ».
Signature : index dans le tas d’objets blob contenant un objet BLOB FieldSig (ECMA II. 23.2.4) où le type est défini sur ELEMENT_TYPE_I4 ou ELEMENT_TYPE_U4, car les valeurs enum de WinRT doivent être des entiers signés ou non signés 32 bits.

Une fois que la définition de la valeur enum est une définition de champ pour chacune des valeurs de l’énumération.

Indicateurs : public | statique | littéral | HasDefault (0x8056).
Name : index dans le tas de chaîne qui contient le nom de la valeur enum.
Signature : index dans le tas d’objets blob contenant un objet BLOB FieldSig (ECMA II. 23.3.4) avec le type défini sur le TypeDef du type enum.

Pour chaque définition de valeur enum, il existe une ligne correspondante dans la table constante (ECMA II. 22.9) pour stocker la valeur entière de la valeur enum.

Type. Un octet pour représenter le type sous-jacent de l’énumération, ELEMENT_TYPE_I4 ou ELEMENT_TYPE_U4, suivi d’un zéro de remplissage d’octets par la spécification ECMA.
Parent : index dans la table de champs qui contient l’enregistrement de valeur enum associé.
Valeur : index dans la table d’objets BLOB qui contient la valeur entière pour la valeur enum.

En outre, System. FlagsAttribute doit être ajouté à la ligne d’énumération TypeDef pour toute énumération avec un type UInt32 sous-jacent. FlagsAttribute ne doit pas être ajouté à la ligne enum TypeDef pour les enums avec un type Int32 sous-jacent.

Pour tous les enums fournis par le système, VersionAttribute doit être ajouté à la ligne d’énumération TypeDef. Éventuellement, le VersionAttribute peut être ajouté à une ligne de champ statique. Si elle est présente, la valeur de version de VersionAttribute sur toute ligne de champ enum doit être supérieure ou égale à la valeur de VersionAttribute sur la ligne enum TypeDef.

Structures

Les structs sont implémentés en tant que ligne dans la table TypeDef (ECMA II. 22.37) avec les colonnes définies comme suit.

Indicateurs-public | Sealed | Séquentiel | tdWindowsRuntime (0x4109).
Name : index dans le tas de chaîne qui contient le nom du type.
Espace de noms : index dans le tas de chaîne qui contient l’espace de noms du type.
Extends : défini sur un TypeRef qui fait référence à la classe System. ValueType dans l’assembly mscorlib.
FieldList : index de la table de champs, qui marque la première d’une série contiguë de champs appartenant à ce type.
MethodList : doit être vide.

Les structs ont une ou plusieurs entrées de table de champs.

Flags : public.
Name : index dans le tas de chaîne qui contient le nom du champ.
Signature : index dans le tas d’objets blob contenant un objet BLOB FieldSig (ECMA II. 23.2.4) avec le type défini sur le jeton de métadonnées pour le type de champ.
- Les champs de struct doivent être des types fondamentaux, des enums ou d’autres structs.

Pour tous les structs fournis par le système, VersionAttribute doit être ajouté à la ligne struct TypeDef.

Délégués

Les délégués sont implémentés en tant que ligne dans la table TypeDef (ECMA II. 22.37) avec les colonnes définies comme suit.

Flags : défini sur public | Sealed | tdWindowsRuntime (0x4101).
Name : index dans le tas de chaîne qui contient le nom du type.
Espace de noms : index dans le tas de chaîne qui contient l’espace de noms du type.
Extends : défini sur un TypeRef qui fait référence à la classe System. MulticastDelegate dans l’assembly mscorlib.
FieldList : doit être vide.
MethodList : index de la table MethodDef (ECMA II. 22.26), qui marque la première d’une série contiguë de méthodes appartenant à ce type.

Les lignes TypeDef des délégués doivent avoir un GuidAttribute.

Les délégués ont exactement deux entrées de table MethodDef. Le premier définit un constructeur. Ce constructeur est un marqueur de compatibilité, ce qui explique pourquoi il utilise des constructions non WinRT telles que native int et des paramètres qui ne sont in ni ni out . Les délégués WinRT n’ont pas de méthode de constructeur de ce type.

RVA : 0 (il s’agit d’une construction abstraite).
ImplFlags : Runtime (0x03).
Indicateurs : privé | HideBySig | SpecialName | RTSpecialName (0x1881).
Nom : index de la table de chaînes contenant le nom « . ctor ».
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) pour une méthode avec un objet et native int dans des paramètres et aucune valeur de retour.
ParamList : index de la table param (ECMA II. 22.33) contenant le premier d’une série de lignes param associées à cette méthode. Chaque ligne de la table param contient les informations suivantes.
- Paramètre de l’objet
  - Séquence 1
  - Nom « objet »
  - Indicateurs : aucun (0x00)
- Paramètre int natif
  - Séquence 2
  - Nom « méthode »
  - Indicateurs : aucun (0x00)

La deuxième entrée MethodDef définit la méthode Invoke.

RVA : 0 (il s’agit d’une construction abstraite)
ImplFlags : Runtime (0x03)
Indicateurs : public | Virtuel | HideBySig | SpecialName (0x08C6)
Nom : index de la table de chaînes contenant le nom « Invoke ».
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui contient les types de paramètres et le type de retour du délégué. Si le délégué est paramétré, l’objet BLOB MethodDefSig doit référencer chacun des paramètres de type des délégués via le type encodé GENERICINST (conformément à la norme ECMA II. 23.2.12). Détails sur les délégués paramétrables à suivre.
ParamList : index de la table param (ECMA II. 22.33) contenant le premier d’une série de lignes param associées à cette méthode. Chaque ligne de la table param contient les informations suivantes.
- Flags : in ou out approprié pour le paramètre
- Sequence : ordre de séquence du paramètre. Zéro est réservé pour la valeur de retour de la méthode
- Name : index dans le tas de chaîne contenant le nom du paramètre pour tous les délégués fournis par le système, VersionAttribute doit être ajouté à la ligne TypeDef du délégué.

Délégués paramétrés

Les délégués paramétrés présentent les exigences supplémentaires suivantes.

Le nom d’un délégué paramétré est ajouté avec un surcycle et un nombre représentant le nombre de paramètres de type que le délégué paramétrable possède. Par exemple, le Windows. Le type Foundation. EventHandler < T > est stocké dans les métadonnées portant le nom Windows. Foundation. EventHandler' 1.
Les délégués paramétrables ont une ligne dans la table GenericParam (ECMA II. 22.20) pour chaque paramètre de type avec les colonnes définies comme suit.
- Number : index du paramètre générique, numéroté de gauche à droite, à partir de zéro.
- Flags : aucun.
- Owner : index dans la table TypeDef pour la ligne contenant l’interface.
- Nom : index dans le tas de chaîne contenant le nom du paramètre générique.

La table TypeSpec (ECMA II. 23.2.14) est utilisée pour définir des instances de délégués paramétrables. Ces TypeSpecs peuvent ensuite être utilisés dans les signatures de méthode de la même façon que TypeRefs.

Interfaces

Les interfaces sont implémentées sous la forme d’une ligne dans la table TypeDef (ECMA II. 22.37) avec les colonnes définies comme suit.

Flags :
- interface | public | Abstract | tdWindowsRuntime (0x40A1) ou
- interface | NotPublic | Abstract | tdWindowsRuntime (0x40A0)
Nom : index de la table de chaînes contenant le nom de l’interface.
Espace de noms : index dans le tas de chaîne qui contient l’espace de noms du type.
Étend : null.
FieldList : doit être vide.
MethodList : index de la table MethodDef, qui marque la première d’une série contiguë de méthodes appartenant à ce type. Les détails sur le contenu de la table MethodDef sont détaillés dans les sous-sections de la section active.

Les lignes TypeDef des interfaces doivent avoir un GuidAttribute et un VersionAttribute.

Toute interface WinRT avec visibilité privée doit avoir un seul ExclusiveToAttribute. Toute interface WinRT avec visibilité publique ne doit pas avoir de ExclusiveToAttribute. S’il est présent, ExclusiveToAttribute doit faire référence à une classe d’exécution.

Les interfaces requises pour une interface sont représentées par des lignes dans la table InterfaceImpl (ECMA II. 22.23) avec les colonnes définies comme suit.

Classe : index de la table TypeDef pour la ligne contenant l’interface.
Interface : index de la table TypeDef, TypeRef ou TypeSpec qui spécifie l’interface requise. Notez que dans les fichiers de métadonnées fournis par le système, il ne s’agira jamais d’un TypeDef même si l’interface requise est définie dans le même fichier de métadonnées. Pour plus d’informations, consultez la section redirection TypeDef.

Interfaces paramétrables

Interfaces paramétrées les spécifications supplémentaires suivantes.

Le nom d’une interface paramétrable est ajouté avec un surcycle et un nombre représentant le nombre de paramètres de type que le délégué paramétrable possède. Par exemple, le Windows. Le type Foundation. Collections. IVector < T > est stocké dans les métadonnées portant le nom Windows. Foundation. Collections. IVector' 1.

Les interfaces paramétrables ont une ligne dans la table GenericParam (ECMA II. 22.20) pour chaque paramètre de type avec les colonnes définies comme suit.

Number : index du paramètre générique, numéroté de gauche à droite, à partir de zéro.
Flags : aucun.
Owner : index dans la table TypeDef pour la ligne contenant l’interface.
Nom : index dans le tas de chaîne contenant le nom du paramètre générique.

La table TypeSpec (ECMA II. 23.2.14) est utilisée pour définir des instances d’interfaces paramétrables. Ces TypeSpecs peuvent ensuite être utilisés dans les signatures de méthode et les implémentations d’interface de la même façon que TypeRefs.

Membres d’interfaces

Paramètres de tableau

Lors de l’encodage d’un paramètre de tableau pour un type de membre d’interface, le paramètre de longueur de tableau qui précède immédiatement le paramètre de tableau est omis à la fois de l’objet BLOB MethodDefSig et de la table params.

La direction du paramètre de tableau est directement encodée dans les métadonnées. La direction du paramètre de longueur du tableau peut être déduite comme suit.

Si le paramètre de tableau est un paramètre in, le paramètre de longueur du tableau doit également être un paramètre in.
Si le paramètre de tableau est un paramètre de sortie et qu’il ne porte pas le marqueur BYREF, la longueur du tableau est un paramètre in.
Si le paramètre de tableau est un paramètre de sortie et qu’il transporte le marqueur BYREF, la longueur du tableau est un paramètre de sortie.

Méthodes

Afin de mieux modéliser la projection attendue des méthodes, ainsi que la compatibilité du CLR, la valeur de retour HRESULT requise n’est pas encodée dans les métadonnées. Au lieu de cela, le paramètre out à utiliser comme valeur de retour est encodé comme valeur de retour dans methodDefSig. Pour les méthodes qui ne déclarent pas de paramètre out à utiliser comme valeur de retour, methodDefSig doit déclarer le type de retour void (comme par ECMA II. 23.2.11).

Chaque méthode sur une interface est représentée sous la forme d’une ligne dans la table MethodDef. Chaque ligne MethodDef contiendra les informations suivantes.

RVA : 0x00
ImplFlags : 0x00
Indicateurs : public | Virtuel | HideBySig | Abstract | NewSlot | Instance (0x5c6)
Nom : index de la table de chaînes contenant le nom de la méthode.
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui contient les types de paramètres et le type de retour de la méthode. Si l’interface est paramétrable, l’objet BLOB MethodDefSig doit référencer chacun des paramètres de type de l’interface via le type encodé GENERICINST (conformément à la norme ECMA II. 23.2.12). Détails sur les interfaces paramétrables à suivre.
ParamList : index de la table param (ECMA II. 22.33) contenant le premier d’une série de lignes param associées à cette méthode.

Chaque paramètre de la méthode (plus la valeur de retour, s’il est spécifié) aura une ligne correspondante dans la table param (ECMA II. 22.33).

Flags : aucun, in ou out, en fonction du paramètre.
- Les valeurs de retour sont toujours None
- Les autres paramètres sont toujours in ou out
Sequence : ordre de séquence du paramètre.
- Zéro est réservé pour la valeur de retour de la méthode
Name : index dans le tas de chaîne contenant le nom du paramètre.

Chaque méthode peut éventuellement avoir un OverloadAttribute qui contient le nom de la méthode unique (dans l’étendue de l’interface). Chaque méthode peut éventuellement avoir un DefaultOverloadAttribute qui indique quelle méthode surchargée de la même arité (nombre de paramètres in) doit être projetée dans des langages de type faiblement typés de manière dynamique.

Propriétés

Chaque propriété d’une interface est définie en tant que lignes dans les tables de propriétés (ECMA II. 22.34), PropertyMap (ECMA II. 22.35), MethodSemantics (ECMA II. 22.28) et MethodDef (ECMA II. 22.26).

Chaque interface avec une ou plusieurs propriétés est représentée sous la forme d’une ligne unique dans la table PropertyMap contenant les informations suivantes.

Parent : index de la table TypeDef contenant l’interface qui contient les propriétés.
PropertyList : index de la table de propriétés contenant le premier d’une série de lignes associées à ce type.

Chaque propriété est représentée sous la forme d’une ligne unique dans la table de propriétés contenant les informations suivantes :

Flags : aucun.
Name : index dans le tas de chaîne contenant le nom de la propriété.
Type : index dans le tas d’objets blob contenant un objet BLOB PropertySig (ECMA II. 23.2.5) contenant les informations de type pour la propriété.

Chaque propriété est représentée sous la forme d’une ou de deux lignes dans la table MethodDef. Les propriétés en lecture seule sont représentées sous la forme d’une méthode unique avec le préfixe « get_ », tandis que les propriétés de lecture/écriture sont représentées sous la forme de deux méthodes, l’une avec le « get_ » et l’autre avec le préfixe « put_ ». La signature de la méthode d’extraction n’accepte aucun paramètre et retourne une valeur du type de la propriété. La signature de la méthode Set accepte un seul paramètre du type de la propriété et ne retourne rien.

Les lignes MethodDef pour la propriété contiennent les éléments suivants.

RVA : 0
ImplFlags : aucun
Indicateurs : public | virtuel | HideBySig | newSlot | Abstract | SpecialName (0xDC6)
Nom : index de la table de chaînes contenant « get_ < PropertyName > » ou « Put_ < PropertyName > », selon le cas
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui contient les types de paramètres et le type de retour de la méthode, comme décrit ci-dessus.
ParamList : index de la table param (ECMA II. 22.33) contenant le premier d’une série de lignes param associées à cette méthode. Les valeurs de la table param sont les mêmes que celles spécifiées dans les méthodes ci-dessus.

Chaque ligne MethodDef pour la propriété aura une ligne associée dans la table MethodSemantics contenant les informations suivantes.

Sémantique : accesseur Get ou Setter, le cas échéant.
Méthode : index dans la table MethodDef contenant la méthode Getter ou Setter.
Association : index dans la table de propriétés contenant la propriété.

Événements

Chaque événement sur une interface est défini en tant que lignes dans les tables d’événements (ECMA II. 22.13), EventMap (ECMA II. 22.12), MethodSemantics (ECMA II. 22.28) et MethodDef (ECMA II. 22.26).

Chaque interface avec un ou plusieurs événements est représentée sous la forme d’une ligne unique dans la table EventMap contenant les informations suivantes.

Parent : index de la table TypeDef contenant l’interface qui contient les propriétés.
EventList : index de la table d’événements contenant le premier d’une série de lignes associées à ce type.

Chaque événement est représenté sous la forme d’une ligne unique dans la table d’événements contenant les informations suivantes.

EventFlags : aucun.
Name : index dans le tas de chaîne contenant le nom de la propriété.
EventType : TypeDefOrRef qui indexe dans la table appropriée qui contient le type délégué de l’événement.

Chaque événement est représenté sous la forme de deux lignes dans la table MethodDef, l’une avec le préfixe « add_ » pour l’ajout d’écouteurs d’événements et l’autre avec le préfixe « remove_ » pour la suppression des écouteurs d’événements. La méthode Add prend une instance de délégué et retourne un Windows. Foundation. EventRegistrationToken qui représente l’inscription de l’événement. La méthode Remove prend le EventRegistrationToken retourné par la méthode Add pour annuler l’inscription de l’événement.

Les lignes MethodDef pour l’événement contiennent les éléments suivants.

RVA : 0
ImplFlags : aucun
Indicateurs : public | Final | virtuel | HideBySig | newslot | SpecialName (0x09e6)
Nom : index de la table de chaînes contenant « add_ < PropertyName > » ou « remove_ < PropertyName > », le cas échéant.
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui contient le paramètre et les types de retour de la méthode, comme décrit ci-dessous.
- Add_ méthode accepte un seul paramètre du type délégué et retourne un Windows. Foundation. EventRegistrationToken.
- Remove_ méthode prend une seule Windows. Le paramètre Foundation. EventRegistrationToken et ne retourne rien.
ParamList : index de la table param (ECMA II. 22.33) contenant le premier d’une série de lignes param associées à la méthode. Les valeurs de la table param sont les mêmes que celles spécifiées dans les méthodes ci-dessus.

Les deux lignes MethodDef pour l’événement auront une ligne associée dans la table MethodSemantics contenant les informations suivantes.

Sémantique : AddOn ou RemoveOn, le cas échéant.
Méthode : index dans la table MethodDef contenant la méthode d’écouteur Add ou Remove.
Association : index dans la table d’événements contenant l’événement.

Classes runtime

Les classes d’exécution sont implémentées en tant que ligne dans la table TypeDef (ECMA II. 22.37) avec les colonnes définies comme suit.

Flags : toutes les classes d’exécution doivent comporter les indicateurs public, auto Layout, Class et tdWindowsRuntime.
- Les classes statiques contiennent l’indicateur abstract. Toutes les autres classes ne contiennent pas l’indicateur abstract.
- Les classes non composables composent l’indicateur sealed. Les classes composables ne contiennent pas l’indicateur sealed.
Nom : index de la table de chaînes contenant le nom de la classe.
Espace de noms : index dans le tas de chaîne qui contient l’espace de noms du type.
Étend : index dans le TypeRef référençant une classe composable ou System. Object dans mscorlib.
FieldList : doit être vide.
MethodList : index de la table MethodDef, qui marque la première d’une série contiguë de méthodes appartenant à ce type. Les détails sur le contenu de la table MethodDef sont détaillés ci-dessous.

Pour toutes les classes fournies par le système, VersionAttribute doit être ajouté à la ligne TypeDef de la classe.

Interfaces implémentées

Les interfaces implémentées par les classes d’exécution sont représentées par des lignes dans la table InterfaceImpl (ECMA II. 22.23) avec les colonnes définies comme suit.

Classe : index dans la table TypeDef pour la ligne qui contient le type.
Interface : index de la table TypeDef, TypeRef ou TypeSpec qui spécifie l’interface implémentée. Notez que dans les fichiers de métadonnées fournis par le système, il ne s’agira jamais d’un TypeDef même si l’interface requise est définie dans le même fichier de métadonnées. Pour plus d’informations, consultez la section redirection TypeDef.

Les classes d’exécution doivent spécifier DefaultAttribute sur une seule de leurs lignes InterfaceImpl.

Les classes d’exécution peuvent spécifier OverridableAttribute ou ProtectedAttribute sur l’une de leurs lignes InterfaceImpl. Ils ne peuvent pas spécifier à la fois OverridableAttribute et ProtectedAttribute sur la même ligne.

Éventuellement, le VersionAttribute peut être ajouté à l’une des lignes interfaceImpl de la classe. La valeur de version de VersionAttribute sur les lignes interfaceImpl de toute classe doit être supérieure ou égale à la valeur de VersionAttribute sur la ligne TypeDef de la classe.

Interfaces statiques

Les classes Runtime contiennent zéro, un ou plusieurs attributs personnalisés StaticAttribute. Il est légal de spécifier plusieurs attributs personnalisés StaticAttribute, tant que chacun a des paramètres spécifiés différents. Tout StaticAttribute apparaît sous la forme d’une ligne dans la table CustomAttribute avec les informations suivantes.

Parent : la classe d’exécution à laquelle le StaticAttribute est associé.
Type : référence au. ctor du StaticAttribute.
Valeur : objet blob d’attribut personnalisé contenant le paramètre d’interface statique System. type et le paramètre de version UInt32.

Activation

Les classes Runtime contiennent zéro, un ou plusieurs attributs personnalisés ActivatableAttribute. Il est légal de spécifier plusieurs attributs personnalisés ActivatableAttribute, tant que chacun a des paramètres spécifiés différents. Tout ActivatableAttributes apparaît sous la forme d’une ligne dans la table CustomAttribute avec les informations suivantes.

Parent : la classe d’exécution à laquelle le ActivatableAttribute est associé.
Type : référence à l’un des deux. ctor de ActivatableAttribute.
- Activation directe : le constructeur. ctor n’accepte que le paramètre de version UInt32.
- Activation de la fabrique : le. ctor qui accepte le paramètre d’interface de fabrique System. type et le paramètre de version UInt32.
Valeur : objet blob d’attribut personnalisé contenant le paramètre d’interface de fabrique System. type (s’il est fourni) et le paramètre de version UInt32.

Composition

Les classes Runtime contiennent zéro, un ou plusieurs attributs personnalisés ComposableAttribute. Il est légal de spécifier plusieurs attributs personnalisés ComposableAttribute, tant que chacun a des paramètres spécifiés différents. Tout ComposableAttribute apparaît sous la forme d’une ligne dans la table CustomAttribute avec les informations suivantes.

Parent : la classe d’exécution à laquelle le ComposableAttribute est associé.
Type : référence au. ctor du ComposableAttribute.
Valeur : objet blob d’attribut personnalisé contenant le paramètre d’interface d’interface de fabrique de la composition System. type, une valeur d’énumération CompositionType (public ou protégé) et le paramètre de version UInt32.

Méthodes de classe

Une classe Runtime a une ligne dans la table MethodDef pour chaque méthode sur chaque interface associée à la classe. Cela comprend les interfaces de membre (normale, protégée et substituable), les interfaces statiques, les interfaces de fabrique d’activation et les interfaces de fabrique composable. En outre, une classe qui prend en charge l’activation directe aura également une ligne dans la table MethodDef pour indiquer cela.

Membres de l’interface membre

Chaque méthode d’une interface membre (y compris les interfaces protégées et remplaçables) est représentée par une ligne dans la table MethodDef de la classe. La table methodDef de la classe contient une copie exacte des informations MethodDef de l’interface de déclaration d’origine, y compris les lignes de table de paramètres et les attributs personnalisés, avec les exceptions suivantes.

Les classes d’exécution peuvent spécifier d’autres noms pour les méthodes définies sur les interfaces de membre.
Les méthodes sur les classes d’exécution n’obtiennent pas l’indicateur abstract.
Les méthodes sur les classes d’exécution obtiennent l’indicateur MethodImpl du Runtime.
Les méthodes d’interfaces non remplaçables obtiennent également l’indicateur final. Les méthodes d’interfaces Overridable n’obtiennent pas l’indicateur final.

Chaque ligne de la table MethodDef d’une classe d’une interface membre est reconnectée à la méthode d’interface qui a initialement défini la méthode via une entrée de la table MethodImpl (ECMA II. 22.27) avec des valeurs comme suit.

Class : index dans la table TypeDef qui fait référence à la classe qui exécute la méthode (Notez que cet index n’est pas soumis à la redirection TypeDef).
MethodBody : index de la table MethodDef qui fait référence à la méthode de la classe.
MethodDeclaration : index de la table MethodDef ou MemberRef qui fait référence à la méthode d’interface initialement déclarée.

Membres d’interface statiques

Chaque méthode d’une interface statique est représentée par une ligne dans la table MethodDef de la classe. La table methodDef de la classe contient une copie exacte des informations MethodDef de l’interface de déclaration d’origine, y compris les lignes de table de paramètres et les attributs personnalisés, avec les exceptions suivantes.

Les membres statiques n’obtiennent pas les indicateurs Virtual, abstract, NewSlot et instance.
Les membres statiques obtiennent les indicateurs statiques et de classe.
Les méthodes statiques sur les classes d’exécution obtiennent l’indicateur MethodImpl du Runtime.

Membres d’activation

Les classes qui prennent en charge l’activation directe sans paramètre ont une ligne de constructeur dans la table MethodDef de la classe avec les valeurs de colonne suivantes.

RVA : 0x00
ImplFlags : Runtime
Indicateurs : public | HideBySig | SpecialName | RTSpecialName | Instancié
Name : index de la table de chaînes contenant « . ctor »
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui ne contient aucun paramètre et retourne la valeur null
ParamList : doit être vide

Les classes qui prennent en charge l’activation de la fabrique ont une ligne de constructeur dans la table MethodDef de la classe pour chaque méthode dans chaque interface de fabrique implémentée avec les valeurs de colonne suivantes.

RVA : 0x00
ImplFlags : Runtime
Indicateurs : public | HideBySig | SpecialName | RTSpecialName | Instancié
Name : index de la table de chaînes contenant « . ctor ».
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui contient les paramètres d’entrée et retourne la valeur null.
ParamList : pointeur dans la table params avec une ligne pour chaque paramètre, copiée exactement à partir de la table params pour la méthode de fabrique de déclaration initiale.

Membres de composition

Les classes qui prennent en charge l’activation de la fabrique de composition ont une ligne de constructeur dans la table MethodDef de la classe pour chaque méthode dans chaque interface de fabrique implémentée avec les valeurs de colonne suivantes.

RVA : 0x00
ImplFlags : Runtime
Indicateurs : public | HideBySig | SpecialName | RTSpecialName | Instancié
Name : index de la table de chaînes contenant « . ctor ».
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui contient les paramètres d’entrée personnalisés et retourne la valeur null. Le paramètre de contrôle IInspectable * [in] et le paramètre IInspectable * * [out] non déléguer ne sont pas reflétés dans la signature de la méthode.
ParamList : pointeur vers la table params avec une ligne pour chaque paramètre, à l’exception du paramètre Control IInspectable * [in] et du paramètre IInspectable * * [out] non déléguer, copiés exactement à partir de la table params pour la méthode de fabrique de déclaration initiale.

Attributs personnalisés

Les attributs personnalisés possèdent zéro, une ou plusieurs méthodes de constructeur, chacune avec zéro, un ou plusieurs paramètres où le type de paramètre est limité aux types fondamentaux, aux enums et à System. type. Chaque constructeur de l’attribut personnalisé apparaît sous la forme d’une ligne dans le MethodDef avec les informations suivantes.

RVA (également appelé adresse virtuelle relative) : null
ImplFlags : aucun
Indicateurs : public | HideBySig | specalname | RTSpecialName (0x1886)
Nom : index de la table de chaînes contenant le nom « . ctor ».
Signature : index dans le tas d’objets blob contenant un objet BLOB MethodDefSig (ECMA II. 23.2.1) qui contient les types de paramètres et le type de retour de la méthode.
ParamList : index de la table param (ECMA II. 22.33) contenant le premier d’une série de lignes param associées à cette méthode.

Les attributs personnalisés sur les constructions de métadonnées sont stockés sous la forme de lignes dans la table CustomAttribute (ECMA II. 22.10) avec les colonnes définies comme suit.

Parent : index dans la table de métadonnées à laquelle l’attribut personnalisé est attaché.
Type : index dans la table MethodDef ou MemberRef qui contient une référence au constructeur du type d’attribut.
Valeur : index dans le tas d’objets BLOB qui contient des paramètres d’attribut positionnels et nommés (ECMA II. 23.2). Notez que puisque les attributs personnalisés WinRT ne sont pas autorisés à avoir des propriétés, l’objet blob d’attribut personnalisé ne contiendra jamais d’arguments nommés de style de propriété.

Partager via