File Windows Metadata (WinMD)

  • Articolo

Windows Runtime (WinRT) sono descritte nei .winmd file di metadati leggibili dal computer con l'estensione (nota anche come Windows metadati). Questi file di metadati vengono usati dagli strumenti e dalle proiezioni del linguaggio per abilitare la proiezione del linguaggio.

Note generali

Windows metadati per tutte le API WinRT fornite dal sistema. Windows api per facilitare le proiezioni del linguaggio nella risoluzione di spazi dei nomi e tipi che necessitano di questi metadati in fase di esecuzione. L Windows SDK fornisce una copia dei metadati di sistema in un singolo file per l'uso da parte delle proiezioni del linguaggio che necessitano di questi metadati in fase di compilazione.

Terze parti possono sviluppare le proprie API WinRT che possono partecipare alla proiezione del linguaggio come fanno le API fornite dal sistema. Le API WinRT di terze parti devono fornire metadati esattamente come le API di sistema. Windows le API per lo spazio dei nomi e la risoluzione dei tipi funzionano sui metadati di terze parti come per i metadati di sistema.

Tutti i tipi pubblici in un file WinMD devono essere tipi WinRT e devono contenere il flag tdWindowsRuntime (dettagli sui flag di tipo da seguire). I file WinMD possono includere metadati per i tipi non WinRT. Tutti i tipi non WinRT in un file WinMD non devono essere pubblici. La semantica per i tipi non WinRT è definita dall'implementazione e non rientra nell'ambito di questo documento.

Tutti i membri dell'interfaccia pubblica (metodi, proprietà ed eventi) nei tipi WinRT devono essere membri dell'interfaccia WinRT. I tipi WinRT possono includere metadati per i membri dell'interfaccia non WinRT. Tutti i membri dell'interfaccia non WinRT potrebbero non essere pubblici. La semantica per i membri dell'interfaccia non WinRT è definita dall'implementazione e non rientra nell'ambito di questo documento.

File WinMD

Formato di file WinMD

I file WinMD usano lo stesso formato di file fisico degli assembly CLR (Common Language Runtime), come definito dalla specifica ECMA-335. Tuttavia, mentre il formato di file fisico è lo stesso, le regole per le combinazioni valide di dati sono diverse per i file WinMD e gli assembly CLR. Questo documento elenca i differenziali tra i file WinMD e gli assembly CLR.

I file WinMD forniti dal sistema sono metadati puri. I file WinMD di terze parti possono contenere codice. In particolare, i file WinMD gestiti includono codice MSIL (Microsoft Intermediate Language), proprio come fanno gli assembly CLR tradizionali.

Ogni file WinMD contiene le definizioni di zero o più tipi WinRT. I file WinMD vuoti sono tecnicamente validi.

Non sono presenti restrizioni WinRT specifiche per l'architettura PEKind o del computer elencata in un winmd.

La stringa di versione di WinMD deve contenere "Windows Runtime 1.2".

Nome file WinMD

Il nome (senza estensione) di un file WinMD deve corrispondere senza distinzione tra maiuscole e minuscole alla colonna del nome della tabella dell'assembly all'interno del file WinMD. Ad esempio, il file "Foo.Bar.winmd" deve avere "Foo.Bar" nella colonna name della tabella dell'assembly. Poiché la file system non fa distinzione tra maiuscole e minuscole, la distinzione tra maiuscole e minuscole del nome file può differire dal valore della colonna del nome della tabella dell'assembly.

Tutti i tipi WinRT in un determinato file WinMD devono essere in uno spazio dei nomi corrispondente al nome del file WinMD e al valore della colonna del nome della tabella dell'assembly. Poiché la file system non fa distinzione tra maiuscole e minuscole, la distinzione tra maiuscole e minuscole del nome file può differire dallo spazio dei nomi di tutti i tipi WinRT in un determinato file WinMD. Lo spazio dei nomi di tutti i tipi WinRT in un determinato WinMD deve corrispondere esattamente al valore della colonna del nome della tabella dell'assembly, ovvero con distinzione tra maiuscole e minuscole. Ad esempio, tutti i tipi nel file con "Foo.Bar" nella colonna del nome della tabella assembly devono essere nello spazio dei nomi "Foo.Bar". I tipi possono essere figli diretti di questo spazio dei nomi (ad esempio, Foo.Bar.MyType) o negli spazi dei nomi secondari di questo spazio dei nomi ,ad esempio Foo.Bar.Baz.MyType. Il nome del file deve essere "Foo.Bar.winmd", ma può variare in base alle maiuscole e minuscole, ovvero "foo.bar.winmd" e "FOO. BAR. WINMD" sarebbe consentito anche come nomi di file per questo file di metadati.

Composizione WinMD

I metadati per tutti i tipi nel sistema vengono distribuiti tra più file con estensione winmd. Un pacchetto AppX può includere zero o più file con estensione winmd che descrivono componenti WinRT di terze parti inclusi nel pacchetto dell'applicazione.

In tutti i file con estensione winmd forniti dal sistema o inclusi in una determinata app, i metadati di ogni tipo WinRT devono essere archiviati nel file WinMD, con il nome più lungo corrispondente allo spazio dei nomi del tipo. Tutti i tipi che sono figli diretti di un determinato spazio dei nomi devono trovarsi nello stesso file. Ad esempio, se un pacchetto AppX include i file Foo.winmd e Foo.Bar.winmd, il tipo Foo.Bar.Baz.MyType deve trovarsi nel file Foo.Bar.winmd, poiché si tratta del file con il nome file più lungo corrispondente allo spazio dei nomi per il tipo nel pacchetto.

Reindirizzamento di TypeDef

I file di metadati forniti dal sistema non fanno mai riferimento direttamente a TypeDef. Anche quando si fa riferimento a un tipo definito nello stesso file di metadati, i file di metadati di sistema fanno sempre riferimento a un TypeRef che a sua volta fa riferimento a TypeDef. Questa operazione viene eseguita per supportare il reindirizzamento dei tipi CLR ,ad esempio proiettando IVectorT<> come IListT<>.

I file di metadati di terze parti possono usare Direttamente TypeDef o reindirizzare tutti i riferimenti ai tipi tramite un TypeRef in modo simile al funzionamento dei file di metadati di sistema.

Codifica del sistema dei tipi

Tutti i tipi in questo documento dallo spazio dei nomi System dell'assembly mscorlib vengono usati come marcatori da WinRT. Questi tipi vengono usati per indicare informazioni sui tipi e non devono mai essere risolti. Sono inclusi (ma non solo) System.Object, System.Guid, System.ValueType, System.Enum, System.MulticastDelegate e System.Attribute. Si noti che questi nomi sono stati scelti per la compatibilità con CLR. La definizione di questi tipi da parte di CLR fa parte del sistema di tipi e non ha nulla a che fare con WinRT.

Si noti che molti dei costrutti descritti qui usano la sintassi C#. Questo è semplicemente perché è utile rappresentare determinati costrutti di metadati Common Language Infrastructure (CLI) usando la sintassi C#. I costrutti effettivi sono costrutti di metadati dell'interfaccia della riga di comando puri.

Spazio dei nomi

WinRT codifica lo spazio dei nomi e il nome locale di un tipo in una singola stringa delimitata da punti. Ad esempio, il tipo definito in questo frammento di codice è "Windows. Foundation.ISimpleInterface".

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

Per l'ottimizzazione dello spazio, la tabella TypeDef nei metadati dell'interfaccia della riga di comando fornisce colonne separate per il nome del tipo e il nome dello spazio dei nomi. Tuttavia, a livello di API, la proprietà TypeDef espone solo il nome del tipo.

Tipi fondamentali

Tutti i tipi fondamentali WinRT, ad eccezione di Guid, hanno valori costanti espliciti da usare nei BLOB dei metadati dell'interfaccia della riga di comando e in altri riferimenti al tipo. Questi valori costanti sono descritti nella partizione 2, sezione 23.1.16 della specifica dell'interfaccia della riga di comando.

Tipo WinRT Nome del tipo di elemento dell'interfaccia della riga di comando Valore del tipo di elemento dell'interfaccia della riga di comando
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
Boolean ELEMENT_TYPE_BOOL 0x02
string ELEMENT_TYPE_STRING 0x0e

Poiché non ha un valore ELEMENT_TYPE_* esplicito, i GUID vengono rappresentati nei metadati come TypeRef per il tipo System.Guid dall'assembly mscorlib.

Enumerazioni

Le enumerazioni sono rappresentate come riga nella tabella TypeDef (ECMA II.22.37) con le colonne impostate come indicato di seguito.

  • Bandiere. Impostare su Public | Sealed | tdWindowsRuntime (0x4101).
  • Name. Indice nell'heap delle stringhe che contiene il nome del tipo.
  • Namespace. Indice nell'heap delle stringhe che contiene lo spazio dei nomi del tipo.
  • Si estende. Impostare su un TypeRef che fa riferimento alla classe System.Enum nell'assembly mscorlib.
  • Elencocampi. Indice nella tabella Field, che contrassegna la prima di un'esecuzione contigua di campi di proprietà di questo tipo.
  • MethodList. Deve essere vuoto.

Un'enumerazione ha un singolo campo di istanza che specifica il tipo integer sottostante per l'enumerazione, nonché zero o più campi statici. uno per ogni valore enum definito dal tipo enum.

Il tipo integer sottostante dell'enumerazione viene visualizzato come prima riga nella tabella Field (ECMA II.22.15) associata al tipo , ovvero quella a cui si fa riferimento nella colonna FieldList specificata in precedenza. Le colonne nella tabella Field per il tipo enum sono le seguenti.

  • Flag: | Nome | RTSpecialName (0x601).
  • Name: indice nell'heap delle stringhe che contiene il nome "value__".
  • Firma: indice nell'heap dei BLOB contenente un BLOB FieldSig (ECMA II.23.2.4) in cui Type è impostato su ELEMENT_TYPE_I4 o ELEMENT_TYPE_U4, perché i valori di enumerazione WinRT devono essere interi con o senza segno a 32 bit.

Dopo la definizione del valore di enumerazione viene fornita una definizione di campo per ognuno dei valori nell'enumerazione .

  • Flag: public | static | valore letterale | hasdefault (0x8056).
  • Name: indice nell'heap delle stringhe che contiene il nome del valore di enumerazione.
  • Firma: indice nell'heap dei BLOB contenente un BLOB FieldSig (ECMA II.23.3.4) con type impostato sul TypeDef del tipo enum.

Per ogni definizione di valore Enum è presente una riga corrispondente nella tabella Constant (ECMA II.22.9) per archiviare il valore intero per il valore enum.

  • Digitare Un byte per rappresentare il tipo sottostante dell'enumerazione, ELEMENT_TYPE_I4 o ELEMENT_TYPE_U4, seguito da uno zero di riempimento di byte in base alla specifica ECMA.
  • Parent: indice nella tabella dei campi che contiene il record del valore di enumerazione associato.
  • Value: indice nella tabella BLOB che contiene il valore intero per il valore enum.

È inoltre necessario aggiungere System.FlagsAttribute alla riga TypeDef dell'enumerazione per tutte le enumerazioni con un tipo UInt32 sottostante. FlagsAttribute non deve essere aggiunto alla riga TypeDef dell'enumerazione per le enumerazioni con un tipo Int32 sottostante.

Per tutte le enumerazioni fornite dal sistema, VersionAttribute deve essere aggiunto alla riga TypeDef dell'enumerazione. Facoltativamente, VersionAttribute può essere aggiunto a qualsiasi riga di campo statico. Se presente, il valore della versione di VersionAttribute in qualsiasi riga del campo di enumerazione deve essere maggiore o uguale al valore di VersionAttribute nella riga TypeDef dell'enumerazione.

Struct

Gli struct vengono implementati come riga nella tabella TypeDef (ECMA II.22.37) con le colonne impostate come indicato di seguito.

  • Flag : | Sealed | Dati sequenziali | tdWindowsRuntime (0x4109).
  • Name: indice nell'heap delle stringhe che contiene il nome del tipo.
  • Spazio dei nomi: indice nell'heap delle stringhe che contiene lo spazio dei nomi del tipo.
  • Estende : impostato su un TypeRef che fa riferimento alla classe System.ValueType nell'assembly mscorlib.
  • FieldList: indice nella tabella Field, che contrassegna la prima di un'esecuzione contigua di campi di proprietà di questo tipo.
  • MethodList: deve essere vuoto.

Gli struct hanno una o più voci della tabella Field.

  • Flag: public.
  • Name: indice nell'heap delle stringhe che contiene il nome del campo.
  • Firma: indice nell'heap dei BLOB contenente un BLOB FieldSig (ECMA II.23.2.4) con type impostato sul token di metadati per il tipo di campo.
    • I campi struct devono essere tipi fondamentali, enumerazioni o altri struct.

Per tutti gli struct forniti dal sistema, VersionAttribute deve essere aggiunto alla riga TypeDef dello struct.

Delegati

I delegati vengono implementati come riga nella tabella TypeDef (ECMA II.22.37) con le colonne impostate come indicato di seguito.

  • Flag: impostato su Public | Sealed | tdWindowsRuntime (0x4101).
  • Name: indice nell'heap delle stringhe che contiene il nome del tipo.
  • Spazio dei nomi: indice nell'heap delle stringhe che contiene lo spazio dei nomi del tipo.
  • Estende: impostato su un TypeRef che fa riferimento alla classe System.MulticastDelegate nell'assembly mscorlib.
  • FieldList: deve essere vuoto.
  • MethodList: indice nella tabella MethodDef (ECMA II.22.26), che contrassegna la prima di un'esecuzione contigua di metodi di proprietà di questo tipo.

Le righe TypeDef dei delegati devono avere guidAttribute.

I delegati hanno esattamente due voci di tabella MethodDef. La prima definisce un costruttore. Questo costruttore è un marcatore di compatibilità ed è per questo motivo che usa costrutti non WinRT, ad esempio native int, e parametri che non sono né inout. I delegati WinRT non hanno un metodo costruttore di questo tipo.

  • RVA: 0 (costrutto astratto).
  • ImplFlags: runtime (0x03).
  • Flag: | hidebysig | specialname | RTSpecialName (0x1881).
  • Name: indice nella tabella di stringhe contenente il nome ".ctor".
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) per un metodo con un oggetto e native int nei parametri e nessun valore restituito.
  • ParamList: indice nella tabella Param (ECMA II.22.33) contenente il primo in un'esecuzione di righe Param associate a questo metodo. Ogni riga della tabella Param contiene le informazioni seguenti.
    • Parametro dell'oggetto
      • Sequenza 1
      • Nome "object"
      • Flag: nessuno (0x00)
    • Native Int - parametro
      • Sequenza 2
      • Nome "metodo"
      • Flag: nessuno (0x00)

La seconda voce MethodDef definisce il metodo Invoke.

  • RVA: 0 (costrutto astratto)
  • ImplFlags: runtime (0x03)
  • Flag: public | Ambiente | HideBySig | specialname (0x08C6)
  • Name: indice nella tabella di stringhe contenente il nome "Invoke"
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che contiene i tipi di parametro e il tipo restituito del delegato. Se il delegato è con parametri, il BLOB MethodDefSig deve fare riferimento a ognuno dei parametri di tipo delegati tramite il tipo con codifica GENERICINST (in base a ECMA II.23.2.12). Dettagli sui delegati con parametri da seguire.
  • ParamList: indice nella tabella Param (ECMA II.22.33) contenente il primo in un'esecuzione di righe Param associate a questo metodo. Ogni riga della tabella Param conterrà le informazioni seguenti.
    • Flag: in o out in base alle esigenze del parametro
    • Sequenza: ordine di sequenza del parametro. Zero è riservato per il valore restituito del metodo
    • Name: indice nell'heap delle stringhe contenente il nome del parametro. Per tutti i delegati forniti dal sistema, VersionAttribute deve essere aggiunto alla riga TypeDef del delegato.

Delegati con parametri

I delegati con parametri hanno i requisiti aggiuntivi seguenti.

  • Il nome di un delegato con parametri viene aggiunto con un'anteceto e un numero che rappresenta il numero di parametri di tipo del delegato con parametri. Ad esempio, il Windows. Il tipo Foundation.EventHandlerT<> viene archiviato nei metadati con il nome Windows. Foundation.EventHandler'1.
  • I delegati con parametri hanno una riga nella tabella GenericParam (ECMA II.22.20) per ogni parametro di tipo con le colonne impostate come indicato di seguito.
    • Number: indice del parametro generico, numerato da sinistra a destra, a partire da zero.
    • Flag: nessuno.
    • Owner: indice nella tabella TypeDef per la riga contenente l'interfaccia.
    • Nome: indice nell'heap delle stringhe contenente il nome del parametro generico.

La tabella TypeSpec (ECMA II.23.2.14) viene usata per definire istanze di delegati con parametri. Questi TypeSpec possono quindi essere usati nelle firme dei metodi in modo analogo a TypeRefs.

Interfacce

Le interfacce vengono implementate come riga nella tabella TypeDef (ECMA II.22.37) con le colonne impostate come indicato di seguito.

  • Flags:
    • Interfaccia | public | abstract | tdWindowsRuntime (0x40A1) o
    • Interfaccia | NotPublic| abstract | tdWindowsRuntime (0x40A0)
  • Name: indice nella tabella di stringhe contenente il nome dell'interfaccia.
  • Spazio dei nomi: indice nell'heap delle stringhe che contiene lo spazio dei nomi del tipo.
  • Estende: null.
  • FieldList: deve essere vuoto.
  • MethodList: indice nella tabella MethodDef, che contrassegna la prima di un'esecuzione contigua di metodi di proprietà di questo tipo. Le specifiche sul contenuto della tabella MethodDef sono dettagliate nelle sottosezioni della sezione corrente.

Le righe TypeDef delle interfacce devono avere un GuidAttribute e un VersionAttribute.

Qualsiasi interfaccia WinRT con visibilità privata deve avere un singolo ExclusiveToAttribute. Qualsiasi interfaccia WinRT con visibilità pubblica non deve avere un ExclusiveToAttribute. Se presente, ExclusiveToAttribute deve fare riferimento a una classe di runtime.

Le interfacce necessarie per un'interfaccia sono rappresentate da righe nella tabella InterfaceImpl (ECMA II.22.23) con le colonne impostate come indicato di seguito.

  • Classe: indice nella tabella TypeDef per la riga contenente l'interfaccia.
  • Interface: indice nella tabella TypeDef, TypeRef o TypeSpec che specifica l'interfaccia richiesta. Si noti che nei file di metadati forniti dal sistema non si tratta mai di un TypeDef anche se l'interfaccia richiesta è definita nello stesso file di metadati. Per altri dettagli, vedere la sezione Reindirizzamento TypeDef.

Interfacce con parametri

Le interfacce con parametri sono i requisiti aggiuntivi seguenti.

Al nome di un'interfaccia con parametri viene aggiunto un punto di riferimento indietro e un numero che rappresenta il numero di parametri di tipo del delegato con parametri. Ad esempio, il Windows. Il tipo Foundation.Collections.IVectorT<> viene archiviato nei metadati con il nome Windows. Foundation.Collections.IVector'1.

Le interfacce con parametri hanno una riga nella tabella GenericParam (ECMA II.22.20) per ogni parametro di tipo con le colonne impostate come indicato di seguito.

  • Number: indice del parametro generico, numerato da sinistra a destra, a partire da zero.
  • Flag: nessuno.
  • Owner: indice nella tabella TypeDef per la riga contenente l'interfaccia.
  • Nome: indice nell'heap delle stringhe contenente il nome del parametro generico.

La tabella TypeSpec (ECMA II.23.2.14) viene usata per definire istanze di interfacce con parametri. Questi TypeSpec possono quindi essere usati nelle firme dei metodi e nelle implementazioni dell'interfaccia in modo analogo a TypeRefs.

Membri di interfaccia

Parametri matrice

Quando si codifica un parametro Array per qualsiasi tipo di membro di interfaccia, il parametro di lunghezza della matrice che precede immediatamente il parametro di matrice viene omesso sia dal BLOB MethodDefSig che dalla tabella params.

La direzione del parametro di matrice viene codificata direttamente nei metadati. La direzione del parametro di lunghezza della matrice può essere dedotto come indicato di seguito.

  • Se il parametro della matrice è un parametro in , anche il parametro della lunghezza della matrice deve essere un parametro in .
  • Se il parametro della matrice è un parametro out e non contiene il marcatore BYREF, la lunghezza della matrice è un parametro in.
  • Se il parametro della matrice è un parametro out e contiene il marcatore BYREF, la lunghezza della matrice è un parametro out.

Metodi

Per modellare meglio la proiezione prevista dei metodi e la compatibilità CON CLR, il valore restituito HRESULT richiesto non viene codificato nei metadati. Il parametro out da usare come valore restituito viene invece codificato come valore restituito in methodDefSig. Per i metodi che non dichiarano un parametro out da usare come valore restituito, methodDefSig deve dichiarare il tipo restituito come void (come da ECMA II.23.2.11).

Ogni metodo in un'interfaccia verrà rappresentato come riga nella tabella MethodDef. Ogni riga methoddef conterrà le informazioni seguenti.

  • RVA: 0x00
  • ImplFlags: 0x00
  • Flag: public | Ambiente | HideBySig | Astratto | NewSlot | Istanza (0x5c6)
  • Name: indice nella tabella di stringhe contenente il nome del metodo
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che contiene i tipi di parametro e il tipo restituito del metodo. Se l'interfaccia è con parametri, il BLOB MethodDefSig deve fare riferimento a ognuno dei parametri di tipo dell'interfaccia tramite il tipo con codifica GENERICINST (in base a ECMA II.23.2.12). Informazioni dettagliate sulle interfacce con parametri da seguire.
  • ParamList: indice nella tabella Param (ECMA II.22.33) contenente il primo in un'esecuzione di righe Param associate a questo metodo.

Ogni parametro del metodo (più il valore restituito se specificato) avrà una riga corrispondente nella tabella Param (ECMA II.22.33).

  • Flag: nessuno, in o out in base alle esigenze per il parametro .
    • I valori restituiti sono sempre nessuno
    • Altri parametri sono sempre in o out
  • Sequenza: ordine di sequenza del parametro.
    • Zero è riservato per il valore restituito del metodo
  • Name: indice nell'heap delle stringhe contenente il nome del parametro.

Ogni metodo può facoltativamente avere un OverloadAttribute che contiene il nome univoco del metodo (all'interno dell'ambito dell'interfaccia). Ogni metodo può facoltativamente avere un defaultOverloadAttribute che indica quale metodo di overload dello stesso livello (numero di parametri in) deve essere proiettato in linguaggi tipizzati in modo debole e dinamico.

Proprietà

Ogni proprietà in un'interfaccia è definita come righe nelle tabelle Property (ECMA II.22.34), PropertyMap (ECMA II.22.35), MethodSemantics (ECMA II.22.28) e MethodDef (ECMA II.22.26).

Ogni interfaccia con una o più proprietà verrà rappresentata come una singola riga nella tabella PropertyMap contenente le informazioni seguenti.

  • Parent: indice nella tabella TypeDef contenente l'interfaccia che contiene le proprietà.
  • PropertyList: indice nella tabella Property contenente il primo in un'esecuzione di righe associate a questo tipo.

Ogni proprietà verrà rappresentata come una singola riga nella tabella Property contenente le informazioni seguenti

  • Flag: nessuno.
  • Name: indice nell'heap delle stringhe contenente il nome della proprietà.
  • Tipo: indice nell'heap dei BLOB contenente un BLOB PropertySig (ECMA II.23.2.5) contenente le informazioni sul tipo per la proprietà.

Ogni proprietà verrà rappresentata come una o due righe nella tabella MethodDef. Le proprietà di sola lettura sono rappresentate come un singolo metodo con il prefisso "get_", mentre le proprietà di lettura/scrittura sono rappresentate come due metodi, uno con "get_" e l'altro con il prefisso "put_". La firma per il metodo get non accetta parametri e restituisce un valore del tipo della proprietà. La firma per il metodo set accetta un singolo parametro del tipo della proprietà e non restituisce alcun valore.

Le righe MethodDef per la proprietà contengono quanto segue.

  • RVA: 0
  • ImplFlags: Nessuno
  • Flag: public | virtual | HideBySig | NewSlot | abstract | specialname (0xDC6)
  • Nome: indice nella tabella di stringhe contenente "get_<PropertyName>" o "put_<PropertyName>" in base alle esigenze
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che contiene i tipi di parametro e il tipo restituito del metodo come descritto in precedenza.
  • ParamList: indice nella tabella Param (ECMA II.22.33) contenente il primo in un'esecuzione di righe Param associate a questo metodo. I valori nella tabella Param sono specificati nei metodi precedenti.

A ogni riga MethodDef per la proprietà sarà associata una riga nella tabella MethodSemantics contenente le informazioni seguenti.

  • Semantica: Getter o Setter in base alle esigenze.
  • Metodo: indice nella tabella MethodDef contenente il metodo getter o setter.
  • Associazione: indice nella tabella Property contenente la proprietà.

evento

Ogni evento in un'interfaccia è definito come righe nelle tabelle Event (ECMA II.22.13), EventMap (ECMA II.22.12), MethodSemantics (ECMA II.22.28) e MethodDef (ECMA II.22.26).

Ogni interfaccia con uno o più eventi verrà rappresentata come una singola riga nella tabella EventMap contenente le informazioni seguenti.

  • Parent: indice nella tabella TypeDef contenente l'interfaccia che contiene le proprietà.
  • EventList: indice nella tabella Event contenente il primo in un'esecuzione di righe associate a questo tipo.

Ogni evento verrà rappresentato come una singola riga nella tabella Event contenente le informazioni seguenti.

  • EventFlags: Nessuno.
  • Name: indice nell'heap delle stringhe contenente il nome della proprietà.
  • EventType: TypeDefOrRef che indicizza nella tabella appropriata che contiene il tipo delegato dell'evento.

Ogni evento verrà rappresentato come due righe nella tabella MethodDef, una con il prefisso "add_" per l'aggiunta di listener di eventi e una con il prefisso "remove_" per la rimozione dei listener di eventi. Il metodo add accetta un'istanza del delegato e restituisce un Windows. Foundation.EventRegistrationToken che rappresenta la registrazione dell'evento. Il metodo remove accetta l'oggetto EventRegistrationToken restituito dal metodo add per annullare la registrazione dell'evento.

Le righe MethodDef per l'evento contengono quanto segue.

  • RVA: 0
  • ImplFlags: Nessuno
  • Flag: public | Final | virtual | hidebysig | Esempio di newslot | specialname (0x09e6)
  • Nome: indice nella tabella di stringhe contenente "add_<PropertyName>" o "remove_<PropertyName>" in base alle esigenze.
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che contiene il parametro e i tipi restituiti del metodo, come descritto di seguito.
    • Add_ metodo accetta un singolo parametro del tipo delegato e restituisce un Windows. Foundation.EventRegistrationToken.
    • Remove_ metodo accetta un singolo Windows. Foundation.EventRegistrationToken e non restituisce alcun valore.
  • ParamList: indice nella tabella Param (ECMA II.22.33) contenente il primo in un'esecuzione di righe Param associate al metodo . I valori nella tabella Param sono specificati nei metodi precedenti.

Entrambe le righe MethodDef per l'evento avranno una riga associata nella tabella MethodSemantics contenente le informazioni seguenti.

  • Semantica: AddOn o RemoveOn in base alle esigenze.
  • Metodo: indice nella tabella MethodDef contenente il metodo add o remove listener.
  • Associazione: indice nella tabella Event contenente l'evento.

Classi di runtime

Le classi di runtime vengono implementate come riga nella tabella TypeDef (ECMA II.22.37) con le colonne impostate come indicato di seguito.

  • Flag: tutte le classi di runtime devono contenere i flag public, auto layout, class e tdWindowsRuntime.
    • Le classi solo statiche hanno il flag astratto. Tutte le altre classi non hanno il flag astratto.
    • Le classi non componibili trasportano il flag sealed. Le classi componibili non hanno il flag sealed.
  • Name: indice nella tabella di stringhe contenente il nome della classe.
  • Spazio dei nomi: indice nell'heap delle stringhe che contiene lo spazio dei nomi del tipo.
  • Estende: indice in TypeRef che fa riferimento a una classe componibile o a System.Object in mscorlib.
  • FieldList: deve essere vuoto.
  • MethodList: indice nella tabella MethodDef, che contrassegna la prima di un'esecuzione contigua di metodi di proprietà di questo tipo. Di seguito sono riportate informazioni dettagliate sul contenuto della tabella MethodDef.

Per tutte le classi fornite dal sistema, VersionAttribute deve essere aggiunto alla riga TypeDef della classe.

Interfacce implementate

Le interfacce implementate dalle classi di runtime sono rappresentate da righe nella tabella InterfaceImpl (ECMA II.22.23) con le colonne impostate come indicato di seguito.

  • Classe: indice nella tabella TypeDef per la riga contenente il tipo.
  • Interface: indice nella tabella TypeDef, TypeRef o TypeSpec che specifica l'interfaccia implementata. Si noti che nei file di metadati forniti dal sistema non si tratta mai di un TypeDef anche se l'interfaccia richiesta è definita nello stesso file di metadati. Per altri dettagli, vedere la sezione Reindirizzamento TypeDef.

Le classi di runtime devono specificare DefaultAttribute in una delle rispettive righe InterfaceImpl.

Le classi di runtime possono specificare OverridableAttribute o ProtectedAttribute in una delle rispettive righe InterfaceImpl. Non possono specificare sia OverridableAttribute che ProtectedAttribute nella stessa riga.

Facoltativamente, VersionAttribute può essere aggiunto a una delle righe interfaceImpl della classe. Il valore della versione di VersionAttribute nelle righe interfaceImpl di qualsiasi classe deve essere maggiore o uguale al valore di VersionAttribute nella riga TypeDef della classe.

Interfacce statiche

Le classi di runtime hanno zero o più attributi staticattribute personalizzati. È possibile specificare più di un attributo personalizzato StaticAttribute, purché ognuno abbia parametri specificati diversi. Tutti gli elementi StaticAttribute verranno visualizzati come riga nella tabella CustomAttribute con le informazioni seguenti.

  • Parent: classe di runtime a cui è associato StaticAttribute.
  • Tipo: riferimento al .ctor di StaticAttribute.
  • Valore: BLOB di attributi personalizzati contenente il parametro dell'interfaccia statica System.Type e il parametro di versione Uint32.

Activation

Le classi di runtime hanno zero o più attributi personalizzati ActivatableAttribute. È possibile specificare più di un attributo personalizzato ActivatableAttribute, purché ognuno abbia parametri specificati diversi. Qualsiasi ActivatableAttributes verrà visualizzato come riga nella tabella CustomAttribute con le informazioni seguenti.

  • Padre: classe di runtime a cui è associato ActivatableAttribute.
  • Tipo: riferimento a uno dei due ctor di ActivatableAttribute.
    • Attivazione diretta: il ctor che prende solo il parametro di versione Uint32.
    • Attivazione della factory: il ctor che prende il parametro dell'interfaccia factory System.Type e il parametro di versione Uint32.
  • Valore: UN BLOB di attributi personalizzato contenente il parametro dell'interfaccia factory System.Type (se specificato) e il parametro di versione Uint32.

Composizione

Le classi di runtime hanno zero o più attributi personalizzati ComposableAttribute. È possibile specificare più di un attributo personalizzato ComposableAttribute, purché ognuno abbia parametri specificati diversi. Tutti gli elementi ComposableAttribute verranno visualizzati come riga nella tabella CustomAttribute con le informazioni seguenti.

  • Padre: classe di runtime a cui è associato ComposableAttribute.
  • Tipo: riferimento al .ctor di ComposableAttribute.
  • Valore: UN BLOB di attributi personalizzato contenente il parametro dell'interfaccia factory di composizione System.Type, un valore di enumerazione CompositionType (Public o Protected) e il parametro di versione Uint32.

Metodi della classe

Una classe di runtime include una riga nella tabella MethodDef per ogni metodo in ogni interfaccia associata alla classe. Sono incluse le interfacce membro (normali, protette e sottoponibili a override), le interfacce statiche, le interfacce della factory di attivazione e le interfacce factory componibili. Inoltre, una classe che supporta l'attivazione diretta avrà anche una riga nella tabella MethodDef per indicare questa operazione.

Membri dell'interfaccia membro

Ogni metodo di un'interfaccia membro (incluse le interfacce protette e sottoponibili a override) è rappresentato da una riga nella tabella MethodDef della classe. La tabella methodDef della classe contiene una copia esatta delle informazioni di MethodDef dall'interfaccia dichiarante originale, incluse le righe della tabella Param e gli attributi personalizzati, con le eccezioni seguenti.

  • Le classi di runtime possono specificare nomi alternativi per i metodi definiti nelle interfacce membro.
  • I metodi nelle classi di runtime non ottengono il flag Abstract.
  • I metodi nelle classi di runtime ottengono il flag MethodImpl di runtime.
  • I metodi da interfacce non sottoponibili a override ottengono anche il flag Final. I metodi delle interfacce sottoponibili a override non ottengono il flag Final.

Ogni riga della tabella MethodDef di una classe da un'interfaccia membro è connessa al metodo di interfaccia che in origine ha definito il metodo tramite una voce nella tabella MethodImpl (ECMA II.22.27) con i valori seguenti.

  • Classe: indice nella tabella TypeDef che fa riferimento alla classe che trasporta il metodo (si noti che questo indice non è soggetto al reindirizzamento TypeDef).
  • MethodBody: indice nella tabella MethodDef che fa riferimento al metodo della classe.
  • MethodDeclaration: indice nella tabella MethodDef o MemberRef che fa riferimento al metodo di interfaccia originariamente dichiarato.
Membri di interfaccia statici

Ogni metodo di un'interfaccia statica è rappresentato da una riga nella tabella MethodDef della classe. La tabella methodDef della classe contiene una copia esatta delle informazioni di MethodDef dall'interfaccia dichiarante originale, incluse le righe della tabella Param e gli attributi personalizzati, con le eccezioni seguenti.

  • I membri statici non ottengono i flag Virtual, Abstract, NewSlot e Instance.
  • I membri statici ottengono i flag Static e Class.
  • I metodi statici nelle classi di runtime ottengono il flag MethodImpl di runtime.
Membri di attivazione

Le classi che supportano l'attivazione diretta senza parametri dispongono di una riga del costruttore nella tabella MethodDef della classe con i valori di colonna seguenti.

  • RVA: 0x00
  • ImplFlags: Runtime
  • Flag: public | HideBySig | Nome | RTSpecialName | Istanza
  • Nome: indice nella tabella di stringhe contenente ".ctor"
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che non contiene parametri e restituisce Null
  • ParamList: deve essere vuoto

Le classi che supportano l'attivazione della factory hanno una riga del costruttore nella tabella MethodDef della classe per ogni metodo in ogni interfaccia factory implementata con i valori di colonna seguenti.

  • RVA: 0x00
  • ImplFlags: Runtime
  • Flag: public | HideBySig | Nome | RTSpecialName | Istanza
  • Nome: indice nella tabella di stringhe contenente ".ctor".
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che contiene i parametri di input e restituisce Null.
  • ParamList: puntatore alla tabella Params con una riga per ogni parametro, copiato esattamente dalla tabella params per il metodo factory che dichiara in origine.
Membri di composizione

Le classi che supportano l'attivazione della factory di composizione dispongono di una riga del costruttore nella tabella MethodDef della classe per ogni metodo in ogni interfaccia factory implementata con i valori di colonna seguenti.

  • RVA: 0x00
  • ImplFlags: Runtime
  • Flag: public | HideBySig | Nome | RTSpecialName | Istanza
  • Nome: indice nella tabella di stringhe contenente ".ctor".
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che contiene i parametri di input personalizzati e restituisce Null. Il parametro IInspectable* [in] di controllo e il parametro IInspectable** [out] non delegante non vengono riflessi nella firma del metodo.
  • ParamList: puntatore alla tabella Params con una riga per ogni parametro, ad eccezione del parametro IInspectable* [in] di controllo e del parametro IInspectable** [out] non delegante, copiato esattamente dalla tabella params per il metodo factory che dichiara originariamente.

Attributi personalizzati

Gli attributi personalizzati hanno zero o più metodi costruttore, ognuno con zero o più parametri in cui il tipo di parametro è limitato ai tipi fondamentali, alle enumerazioni e a System.Type. Ogni costruttore nell'attributo personalizzato viene visualizzato come riga in MethodDef con le informazioni seguenti.

  • RVA (noto anche come indirizzo virtuale relativo): null
  • ImplFlags: Nessuno
  • Flag: public | HideBySig | specalname | RTSpecialName (0x1886)
  • Name: indice nella tabella di stringhe contenente il nome ".ctor".
  • Firma: indice nell'heap dei BLOB contenente un BLOB MethodDefSig (ECMA II.23.2.1) che contiene i tipi di parametro e il tipo restituito del metodo.
  • ParamList: indice nella tabella Param (ECMA II.22.33) contenente il primo in un'esecuzione di righe Param associate a questo metodo.

Gli attributi personalizzati nei costrutti di metadati vengono archiviati come righe nella tabella CustomAttribute (ECMA II.22.10) con le colonne impostate come indicato di seguito.

  • Padre: indice nella tabella di metadati a cui è collegato l'attributo personalizzato.
  • Tipo: indice nella tabella MethodDef o MemberRef che contiene un riferimento al costruttore del tipo di attributo.
  • Valore: indice nell'heap blob che contiene i parametri degli attributi posizionali e denominati (ECMA II.23.2). Si noti che, poiché gli attributi personalizzati WinRT non possono avere proprietà, il BLOB di attributi personalizzati non conterrà mai argomenti denominati in stile PROPERTY.