Compartilhar via

Arquivos de metadados do Windows (WinMD)

  • Artigo

APIs .winmd Windows Runtime (WinRT) são descritas em arquivos de metadados que podem ser lidos pelo computador com a extensão (também conhecidas como Windows metadados). Esses arquivos de metadados são usados por ferramentas e projeções de linguagem para habilitar a projeção de linguagem.

Observações gerais

Windows inclui metadados para todas as APIs winRT fornecidas pelo sistema. Windows fornece APIs para auxiliar projeções de linguagem na resolução de namespaces e tipos que precisam desses metadados em runtime. O Windows SDK fornece uma cópia dos metadados do sistema em um único arquivo para uso por projeções de linguagem que precisam desses metadados em tempo de compilação.

Terceiros podem desenvolver suas próprias APIs do WinRT que podem participar da projeção de linguagem, como as APIs fornecidas pelo sistema. AS APIs winRT de terceiros devem fornecer metadados, assim como as APIs do sistema. Windows APIs para namespace e resolução de tipos funcionam em metadados de terceiros, como fazem para metadados do sistema.

Todos os tipos públicos em um arquivo WinMD devem ser tipos WinRT e devem carregar o sinalizador tdWindowsRuntime (detalhes sobre sinalizadores de tipo a seguir). Os arquivos WinMD podem incluir metadados para tipos não WinRT. Os tipos não WinRT em um arquivo WinMD não devem ser públicos. A semântica para tipos não WinRT são definidas pela implementação e fora do escopo deste documento.

Todos os membros da interface pública (métodos, propriedades e eventos) em tipos WinRT devem ser membros da interface WinRT. Os tipos winRT podem incluir metadados para membros de interface não WinRT. Os membros da interface não WinRT podem não ser públicos. A semântica para membros da interface não WinRT é definida pela implementação e está fora do escopo deste documento.

Arquivos WinMD

Formato de arquivo WinMD

Os arquivos WinMD usam o mesmo formato de arquivo físico que assemblies CLR (Common Language Runtime), conforme definido pela especificação ECMA-335. No entanto, embora o formato de arquivo físico seja o mesmo, as regras para combinações válidas de dados são diferentes para arquivos WinMD e assemblies CLR. Este documento lista os deltas entre arquivos WinMD e assemblies CLR.

Os arquivos WinMD fornecidos pelo sistema são metadados puros. Arquivos WinMD de terceiros podem conter código. Em particular, os arquivos WinMD gerenciados incluem o código MSIL (Microsoft Intermediate Language), assim como os assemblies CLR tradicionais.

Cada arquivo WinMD contém as definições de zero ou mais tipos de WinRT. Arquivos WinMD vazios são tecnicamente válidos.

Não há restrições específicas do WinRT no PEKind ou na arquitetura do computador listados em um WinMD.

A cadeia de caracteres de versão do WinMD deve conter "Windows Runtime 1.2".

Nome do arquivo WinMD

O nome (sem extensão) de um arquivo WinMD deve ser uma corresponder à coluna de nome da tabela de assembly dentro do arquivo WinMD. Por exemplo, o arquivo "Foo.Bar.winmd" deve ter "Foo.Bar" na coluna name da tabela de assembly. Como o sistema de arquivos não diferencia maiúsculas de minúsculas, o caso do nome do arquivo pode ser diferente do valor da coluna de nome da tabela do assembly.

Todos os tipos WinRT em um determinado arquivo WinMD devem estar em um namespace que corresponde ao nome do arquivo WinMD e ao valor da coluna de nome da tabela do assembly. Como o sistema de arquivos não diferencia maiúsculas de minúsculas, o caso do nome do arquivo pode ser diferente do namespace de todos os tipos WinRT em um determinado arquivo WinMD. O namespace de todos os tipos WinRT em um determinado WinMD deve corresponder exatamente ao valor da coluna de nome da tabela de assembly (ou seja, com a sensibilidade a minúsculas). Por exemplo, todos os tipos no arquivo com "Foo.Bar" na coluna de nome da tabela de assembly devem estar no namespace "Foo.Bar". Os tipos podem ser filhos diretos desse namespace (por exemplo, Foo.Bar.MyType) ou em sub-namespaces desse namespace (por exemplo, Foo.Bar.Ltd.MyType). O nome do arquivo deve ser "Foo.Bar.winmd", mas pode variar no caso , ou seja, "foo.bar.winmd" e "FOO. BAR. WINMD" também seria permitido como nomes de arquivo para esse arquivo de metadados.

Composição do WinMD

Os metadados de todos os tipos no sistema são distribuídos em vários arquivos .winmd. Um pacote AppX pode incluir zero ou mais arquivos .winmd que descrevem componentes WinRT de terceiros incluídos no pacote de aplicativos.

Em todos os arquivos .winmd fornecidos pelo sistema ou incluídos com um determinado aplicativo, todos os metadados do tipo WinRT devem ser armazenados no arquivo WinMD, com o nome mais longo que corresponde ao namespace do tipo. Todos os tipos que são filhos diretos de um determinado namespace devem estar localizados no mesmo arquivo. Por exemplo, se um pacote AppX incluir arquivos Foo.winmd e Foo.Bar.winmd, o tipo Foo.Bar.Plus.MyType deverá estar localizado no arquivo Foo.Bar.winmd, pois esse é o arquivo com o nome de arquivo mais longo que corresponde ao namespace para o tipo no pacote.

Redirecionamento de TypeDef

Os arquivos de metadados fornecidos pelo sistema nunca referenciam TypeDefs diretamente. Mesmo ao referenciar um tipo definido no mesmo arquivo de metadados, os arquivos de metadados do sistema sempre referenciam um TypeRef que, por sua vez, faz referência ao TypeDef. Isso é feito para dar suporte ao redirecionamento de tipo CLR (projetando IVectorT<> como IListT<>, por exemplo).

Arquivos de metadados de terceiros podem usar TypeDef diretamente ou redirecionar todas as referências de tipo por meio de um TypeRef semelhante ao que os arquivos de metadados do sistema fazem.

Codificação do sistema de tipos

Todos os tipos neste documento do namespace System do assembly mscorlib são usados como marcadores pelo WinRT. Esses tipos são usados para indicar informações sobre tipos e nunca devem ser resolvidos. Isso inclui (mas não está limitado a) System.Object, System.Guid, System.ValueType, System.Enum, System.MulticastDelegate e System.Attribute. Observe que esses nomes foram escolhidos para compatibilidade com CLR. A definição de CLR desses tipos faz parte de seu sistema de tipos e não tem nada a ver com o WinRT.

Observe que muitos dos constructos descritos aqui usam sintaxe C#. Isso é simplesmente porque é conveniente representar determinados constructos de metadados Common Language Infrastructure (CLI) usando a sintaxe C#. Os constructos reais são constructos de metadados puros da CLI.

Namespace

O WinRT codifica o namespace de um tipo e o nome local em uma única cadeia de caracteres delimitada por período. Por exemplo, o tipo definido neste snippet de código é "Windows. Foundation.ISimpleInterface".

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

Para otimização de espaço, a tabela TypeDef nos metadados da CLI fornece colunas separadas para o nome do tipo e o nome do namespace. No entanto, no nível da API, a propriedade TypeDef expõe apenas o nome do tipo.

Tipos fundamentais

Todos os tipos fundamentais do WinRT, exceto Guid, têm valores constantes explícitos para uso em blobs de metadados da CLI e outras referências de tipo. Esses valores constantes são descritos na Partição 2, Seção 23.1.16 da especificação da CLI.

Tipo WinRT Nome do tipo de elemento da CLI Valor do tipo de elemento da 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
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

Como não tem nenhum valor constante ELEMENT_TYPE_ * explícito para eles, os GUIDs são representados nos metadados como TypeRef para o tipo System. GUID do assembly mscorlib.

Enumerações

As enumerações são representadas como uma linha na tabela TypeDef (ECMA II. 22.37) com as colunas definidas da seguinte maneira.

  • Flags. Definir como público | Lacrado | tdWindowsRuntime (0x4101).
  • Nome. Um índice no heap de cadeia de caracteres que contém o nome do tipo.
  • Namespace. Um índice no heap de cadeia de caracteres que contém o namespace do tipo.
  • Estende. Defina como um TypeRef que faz referência à classe System. Enum no assembly mscorlib.
  • FieldList. Um índice na tabela de campos, marcando o primeiro de uma execução contígua de campos pertencentes a esse tipo.
  • Methodlist. Deve estar vazio.

Um enum tem um único campo de instância que especifica o tipo inteiro subjacente para a enumeração, bem como zero ou mais campos estáticos; um para cada valor de enumeração definido pelo tipo de enumeração.

O tipo de inteiro subjacente da enumeração aparece como a primeira linha na tabela de campos (ECMA II. 22.15) associada ao tipo (ou seja, a que é referenciada na coluna FieldList especificada acima). As colunas na tabela de campos para o tipo enum são as seguintes.

  • Sinalizadores: particular | SpecialName | RTSpecialName (0x601).
  • Nome: um índice no heap de cadeia de caracteres que contém o nome "value__".
  • Assinatura: um índice no heap de BLOB que contém um blob FieldSig (ECMA II. 23.2.4) em que o tipo é definido como ELEMENT_TYPE_I4 ou ELEMENT_TYPE_U4, pois os valores de enum do WinRT devem ser assinados ou sem sinal, números inteiros de 32 bits.

Após a definição do valor de enumeração vem uma definição de campo para cada um dos valores na enumeração.

  • Sinalizadores: público | estático | literal | HasDefault (0x8056).
  • Nome: um índice no heap de cadeia de caracteres que contém o nome do valor de enumeração.
  • Assinatura: um índice no heap de BLOB que contém um blob FieldSig (ECMA II. 23.3.4) com o tipo definido como o TypeDef do tipo de enumeração.

Para cada definição de valor de enumeração, há uma linha correspondente na tabela constante (ECMA II. 22.9) para armazenar o valor inteiro para o valor de enumeração.

  • Digite. Um byte para representar o tipo subjacente da enumeração, seja ELEMENT_TYPE_I4 ou ELEMENT_TYPE_U4, seguido de um preenchimento de byte zero de acordo com a especificação ECMA.
  • Pai: índice na tabela de campos que contém o registro de valor de enumeração associado.
  • Valor: indexe na tabela de BLOB que contém o valor inteiro para o valor de enumeração.

Além disso, o System. FlagsAttribute deve ser adicionado à linha de TypeDef de enumeração para quaisquer enums com um tipo UInt32 subjacente. O FlagsAttribute não deve ser adicionado à linha de TypeDef de enumeração para enums com um tipo Int32 subjacente.

Para todas as enumerações fornecidas pelo sistema, o Versionattribute deve ser adicionado à linha de TypeDef de enumeração. Opcionalmente, o Versionattribute pode ser adicionado a qualquer linha de campo estático. Se estiver presente, o valor da versão do Versionattribute em qualquer linha de campo de enumeração deverá ser maior ou igual ao valor do Versionattribute na linha de TypeDef de enumeração.

Estruturas

As estruturas são implementadas como uma linha na tabela TypeDef (ECMA II. 22.37) com as colunas definidas da seguinte maneira.

  • Sinalizadores – público | Lacrado | Sequencial | tdWindowsRuntime (0x4109).
  • Nome – um índice no heap de cadeia de caracteres que contém o nome do tipo.
  • Namespace – um índice no heap de cadeia de caracteres que contém o namespace do tipo.
  • Estende – defina para um TypeRef que faz referência à classe System. ValueType no assembly mscorlib.
  • FieldList – um índice na tabela de campos, marcando o primeiro de uma execução contígua de campos pertencentes a esse tipo.
  • Methodlist – deve estar vazio.

As estruturas têm uma ou mais entradas de tabela de campo.

  • Sinalizadores: público.
  • Nome: um índice no heap de cadeia de caracteres que contém o nome do campo.
  • Assinatura: um índice no heap de BLOB que contém um blob FieldSig (ECMA II. 23.2.4) com o tipo definido como o token de metadados para o tipo de campo.
    • Os campos de struct devem ser tipos fundamentais, enums ou outras estruturas.

Para todas as structs fornecidas pelo sistema, o Versionattribute deve ser adicionado à linha de TypeDef de struct.

Delegados

Os delegados são implementados como uma linha na tabela TypeDef (ECMA II. 22.37) com as colunas definidas da seguinte maneira.

  • Sinalizadores: definido como público | Lacrado | tdWindowsRuntime (0x4101).
  • Nome – um índice no heap de cadeia de caracteres que contém o nome do tipo.
  • Namespace – um índice no heap de cadeia de caracteres que contém o namespace do tipo.
  • Estende: definido como um TypeRef que faz referência à classe System. MulticastDelegate no assembly mscorlib.
  • FieldList: deve estar vazio.
  • Methodlist: um índice na tabela MethodDef (ECMA II. 22.26), marcando o primeiro de uma execução contígua de métodos pertencentes a esse tipo.

As linhas de TypeDef de delegados devem ter um GuidAttribute.

Delegados têm exatamente duas entradas de tabela MethodDef. A primeira define um construtor. Esse construtor é um marcador de compatibilidade, que é o motivo pelo qual ele usa construções não WinRT, como native int, e parâmetros que in nem nem out . Os delegados do WinRT não têm tal método construtor.

  • RVA: 0 (trata-se de uma construção abstrata).
  • ImplFlags: tempo de execução (0x03).
  • Sinalizadores: particular | HideBySig | SpecialName | RTSpecialName (0x1881).
  • Nome: um índice na tabela de cadeia de caracteres que contém o nome ". ctor".
  • Assinatura: um índice no heap de BLOB que contém um blob MethodDefSig (ECMA II. 23.2.1) para um método com um objeto e um int nativo em parâmetros e nenhum valor de retorno.
  • Paramlist: um índice na tabela param (ECMA II. 22.33) que contém o primeiro em uma execução de linhas param associadas a esse método. Cada linha na tabela param contém as informações a seguir.
    • Parâmetro de objeto
      • Sequência 1
      • Nome "objeto"
      • Sinalizadores: nenhum (0x00)
    • Parâmetro int nativo
      • Sequência 2
      • Nome "método"
      • Sinalizadores: nenhum (0x00)

A segunda entrada MethodDef define o método Invoke.

  • RVA: 0 (trata-se de uma construção abstrata)
  • ImplFlags: tempo de execução (0x03)
  • Sinalizadores: público | Virtual | HideBySig | SpecialName (0x08C6)
  • Nome: um índice na tabela de cadeia de caracteres que contém o nome "Invoke"
  • Assinatura: um índice no heap de BLOB que contém um blob MethodDefSig (ECMA II. 23.2.1) que contém os tipos de parâmetro e o tipo de retorno do delegado. Se o delegado for parametrizado, o blob MethodDefSig deverá fazer referência a cada um dos parâmetros de tipo de delegados por meio do tipo codificado GENERICINST (de acordo com a ECMA II. 23.2.12). Detalhes sobre delegados com parâmetros a serem seguidos.
  • Paramlist: um índice na tabela param (ECMA II. 22.33) que contém o primeiro em uma execução de linhas param associadas a esse método. Cada linha na tabela param conterá as informações a seguir.
    • Sinalizadores – dentro ou fora, conforme apropriado para o parâmetro
    • Sequence – ordem de sequência do parâmetro. Zero é reservado para o valor de retorno do método
    • Nome – índice no heap de cadeia de caracteres que contém o nome do parâmetro Para todos os delegados fornecidos pelo sistema, VersionAttribute deve ser adicionado à linha TypeDef do delegado.

Delegados parametrizados

Delegados parametrizados têm os seguintes requisitos adicionais.

  • O nome de um delegado parametrizado é anexado com um backtick e um número que representa o número de parâmetros de tipo que o delegado parametrizado tem. Por exemplo, o Windows. O tipo Foundation.EventHandlerT<> é armazenado em metadados com o nome Windows. Foundation.EventHandler'1.
  • Delegados parametrizados têm uma linha na tabela GenericParam (ECMA II.22.20) para cada parâmetro de tipo com as colunas definidas da seguinte forma.
    • Número: o índice do parâmetro genérico, numerado da esquerda para a direita, começando em zero.
    • Sinalizadores: Nenhum.
    • Proprietário: indexe na tabela TypeDef para a linha que contém a interface .
    • Nome: indexe no heap de cadeia de caracteres que contém o nome do parâmetro genérico.

A tabela TypeSpec (ECMA II.23.2.14) é usada para definir instâncias de delegados parametrizados. Esses TypeSpecs podem ser usados em assinaturas de método da mesma forma que TypeRefs.

Interfaces

As interfaces são implementadas como uma linha na tabela TypeDef (ECMA II.22.37) com as colunas definidas da seguinte forma.

  • Sinalizadores:
    • interface | public | abstrata | tdWindowsRuntime (0x40A1) ou
    • interface | NotPublic| abstrata | tdWindowsRuntime (0x40A0)
  • Nome: um índice na tabela de cadeia de caracteres que contém o nome da interface.
  • Namespace – um índice no heap de cadeia de caracteres que contém o namespace do tipo.
  • Estende: nulo.
  • FieldList: deve estar vazio.
  • MethodList: um índice na tabela MethodDef, marcando a primeira de uma série contígua de métodos pertencentes a esse tipo. As especificações sobre o conteúdo da tabela MethodDef são detalhadas nas subseções da seção atual.

As linhas TypeDef das interfaces devem ter um GuidAttribute, bem como um VersionAttribute.

Qualquer interface WinRT com visibilidade privada deve ter um único ExclusiveToAttribute. Qualquer interface WinRT com visibilidade pública não deve ter um ExclusiveToAttribute. Se estiver presente, ExclusiveToAttribute deverá referenciar uma classe de runtime.

As interfaces necessárias para uma interface são representadas por linhas na tabela InterfaceImpl (ECMA II.22.23) com as colunas definidas da seguinte maneira.

  • Classe: um índice na tabela TypeDef para a linha que contém a interface .
  • Interface: um índice na tabela TypeDef, TypeRef ou TypeSpec que especifica a interface necessária. Observe que, em arquivos de metadados fornecidos pelo sistema, isso nunca será um TypeDef, mesmo que a interface necessária seja definida no mesmo arquivo de metadados. Consulte a seção Redirecionamento de TypeDef para obter mais detalhes.

Interfaces parametrizadas

As interfaces parametrizadas são os requisitos adicionais a seguir.

O nome de uma interface parametrizada é anexado com um backtick e um número que representa o número de parâmetros de tipo que o delegado parametrizado tem. Por exemplo, o Windows. O tipo Foundation.Collections.IVectorT<> é armazenado em metadados com o nome Windows. Foundation.Collections.IVector'1.

As interfaces parametrizadas têm uma linha na tabela GenericParam (ECMA II.22.20) para cada parâmetro de tipo com as colunas definidas da seguinte forma.

  • Número: o índice do parâmetro genérico, numerado da esquerda para a direita, começando em zero.
  • Sinalizadores: Nenhum.
  • Proprietário: indexe na tabela TypeDef para a linha que contém a interface .
  • Nome: indexe no heap de cadeia de caracteres que contém o nome do parâmetro genérico.

A tabela TypeSpec (ECMA II.23.2.14) é usada para definir instâncias de interfaces parametrizadas. Esses TypeSpecs podem ser usados em assinaturas de método e implementações de interface de forma semelhante a TypeRefs.

Membros da interface

Parâmetros de matriz

Ao codificar um parâmetro Array para qualquer tipo de membro de interface, o parâmetro de comprimento da matriz que precede imediatamente o parâmetro de matriz é omitido do blob MethodDefSig, bem como da tabela params.

A direção do parâmetro de matriz é codificada diretamente nos metadados. A direção do parâmetro de comprimento da matriz pode ser inferida da seguinte forma.

  • Se o parâmetro array for um parâmetro in, o parâmetro de comprimento da matriz também deverá ser um parâmetro in.
  • Se o parâmetro de matriz for um parâmetro out e não estiver carregando o marcador BYREF, o comprimento da matriz será um parâmetro in.
  • Se o parâmetro de matriz for um parâmetro out e tiver o marcador BYREF, o comprimento da matriz será um parâmetro out.

Métodos

Para modelar melhor a projeção esperada de métodos, bem como a compatibilidade com CLR, o valor de retorno HRESULT necessário não é codificado em metadados. Em vez disso, o parâmetro out a ser usado como o valor de retorno é codificado como o valor de retorno no methodDefSig. Para métodos que não declaram um parâmetro out a ser usado como o valor de retorno, o methodDefSig deve declarar o tipo de retorno como nulo (de acordo com ECMA II.23.2.11).

Cada método em uma interface será representado como uma linha na tabela MethodDef. Cada linha methoddef conterá as informações a seguir.

  • RVA: 0x00
  • ImplFlags: 0x00
  • Sinalizadores: public | Virtual | HideBySig | Resumo | NewSlot | Instância (0x5c6)
  • Nome: um índice na tabela de cadeia de caracteres que contém o nome do método
  • Assinatura: um índice no heap de blob que contém um blob MethodDefSig (ECMA II.23.2.1) que contém os tipos de parâmetro e o tipo de retorno do método. Se a interface for parametrizada, o blob MethodDefSig deverá referenciar cada um dos parâmetros de tipo da interface por meio do tipo codificado GENERICINST (de acordo com ECMA II.23.2.12). Detalhes sobre interfaces parametrizadas a seguir.
  • ParamList: um índice na tabela Param (ECMA II.22.33) que contém o primeiro em uma sequência de linhas Param associadas a esse método.

Cada parâmetro do método (mais o valor de retorno, se especificado) terá uma linha correspondente na tabela Param (ECMA II.22.33).

  • Sinalizadores – nenhum, dentro ou fora, conforme apropriado para o parâmetro .
    • Os valores de retorno são sempre nenhum
    • Outros parâmetros estão sempre dentro ou fora
  • Sequência – ordem de sequência do parâmetro.
    • Zero é reservado para o valor de retorno do método
  • Nome – índice no heap de cadeia de caracteres que contém o nome do parâmetro.

Opcionalmente, cada método pode ter um OverloadAttribute que carrega o nome do método exclusivo (dentro do escopo da interface). Opcionalmente, cada método pode ter um DefaultOverloadAttribute que indica qual método sobrecarregado da mesma arity (número de em parâmetros) deve ser projetado em linguagens fraca e dinamicamente digitadas.

Propriedades

Cada propriedade em uma interface é definida como linhas nas tabelas Property (ECMA II.22.34), PropertyMap (ECMA II.22.35), MethodSemantics (ECMA II.22.28) e MethodDef (ECMA II.22.26).

Cada interface com uma ou mais propriedades será representada como uma única linha na tabela PropertyMap que contém as informações a seguir.

  • Pai: um índice na tabela TypeDef que contém a interface que contém as propriedades.
  • PropertyList: um índice na tabela Property que contém o primeiro em uma sequência de linhas associadas a esse tipo.

Cada propriedade será representada como uma única linha na tabela Property que contém as informações a seguir

  • Sinalizadores: Nenhum.
  • Nome: um índice no heap de cadeia de caracteres que contém o nome da propriedade.
  • Tipo: índice no heap de blob que contém um blob PropertySig (ECMA II.23.2.5) que contém as informações de tipo da propriedade.

Cada Propriedade será representada como uma ou duas linhas na tabela MethodDef. As propriedades somente leitura são representadas como um único método com o prefixo "get_", enquanto as propriedades de leitura/gravação são representadas como dois métodos, um com o "get_" e o outro com o prefixo "put_". A assinatura para o método get não recebe parâmetros e retorna um valor do tipo da propriedade. A assinatura do método set pega um único parâmetro do tipo da propriedade e não retorna nada.

As linhas MethodDef para a propriedade contêm o seguinte.

  • RVA: 0
  • ImplFlags: Nenhum
  • Sinalizadores: public | virtual | HideBySig | newSlot | abstrata | specialname (0xDC6)
  • Nome: um índice na tabela de cadeia de caracteres que contém "get_<PropertyName>" ou "put_<PropertyName>", conforme apropriado
  • Assinatura: um índice no heap de blob que contém um blob MethodDefSig (ECMA II.23.2.1) que contém os tipos de parâmetro e o tipo de retorno do método, conforme descrito acima.
  • ParamList: um índice na tabela Param (ECMA II.22.33) que contém o primeiro em uma sequência de linhas Param associadas a esse método. Os valores na tabela Param são conforme especificado nos métodos acima.

Cada linha MethodDef para a propriedade terá uma linha associada na tabela MethodSemantics que contém as informações a seguir.

  • Semântica: Getter ou Setter conforme apropriado.
  • Método: indexe na tabela MethodDef que contém o método getter ou setter.
  • Associação: índice na tabela Property que contém a propriedade .

Eventos

Cada evento em uma interface é definido como linhas nas tabelas evento (ECMA II. 22.13), EventMap (ECMA II. 22.12), MethodSemantics (ECMA II. 22.28) e MethodDef (ECMA II. 22.26).

Cada interface com um ou mais eventos será representada como uma única linha na tabela EventMap que contém as informações a seguir.

  • Parent: um índice na tabela TypeDef que contém a interface que contém as propriedades.
  • EventList: um índice na tabela de eventos que contém o primeiro em uma execução de linhas associadas a esse tipo.

Cada evento será representado como uma única linha na tabela de eventos que contém as informações a seguir.

  • EventFlags: nenhum.
  • Nome: um índice no heap de cadeia de caracteres que contém o nome da propriedade.
  • EventType: um Typedeforref inválido que indexa na tabela apropriada que contém o tipo delegado do evento.

Cada evento será representado como duas linhas na tabela MethodDef, uma com o prefixo "add_" para adicionar ouvintes de evento e outra com o prefixo "remove_" para remover ouvintes de evento. O método Add usa uma instância de delegado e retorna um Windows. Foundation. EventRegistrationToken que representa o registro do evento. O método remove usa o EventRegistrationToken retornado pelo método Add para cancelar o registro do evento.

As linhas MethodDef do evento contêm o seguinte.

  • RVA: 0
  • ImplFlags: nenhum
  • Sinalizadores: público | Final | virtual | HideBySig | NewSlot | SpecialName (0x09e6)
  • Nome: um índice na tabela de cadeia de caracteres que contém "add_ < PropertyName > " ou "remove_ < PropertyName > ", conforme apropriado.
  • Assinatura: um índice no heap de BLOB que contém um blob MethodDefSig (ECMA II. 23.2.1) que contém os tipos de parâmetro e de retorno do método, conforme descrito abaixo.
    • Add_ método usa um único parâmetro do tipo delegado e retorna um Windows. Foundation. EventRegistrationToken.
    • Remove_ método usa uma única Windows. Parâmetro Foundation. EventRegistrationToken e não retorna nada.
  • Paramlist: um índice na tabela param (ECMA II. 22.33) que contém o primeiro em uma execução de linhas param associadas ao método. Os valores na tabela param são especificados em métodos acima.

As duas linhas MethodDef para o evento terão uma linha associada na tabela MethodSemantics que contém as informações a seguir.

  • Semântica: complemento ou removimentação conforme apropriado.
  • Método: indexe na tabela MethodDef que contém o método adicionar ou remover ouvinte.
  • Associação: índice na tabela de eventos que contém o evento.

classes de runtime

As classes de tempo de execução são implementadas como uma linha na tabela TypeDef (ECMA II. 22.37) com as colunas definidas da seguinte maneira.

  • Flags: todas as classes de tempo de execução devem transportar os sinalizadores público, layout automático, classe e tdWindowsRuntime.
    • As classes somente estáticas carregam o sinalizador abstrato. Todas as outras classes não carregam o sinalizador abstract.
    • As classes não combináveis carregam o sinalizador lacrado. As classes combináveis não carregam o sinalizador lacrado.
  • Nome: um índice na tabela de cadeia de caracteres que contém o nome da classe.
  • Namespace – um índice no heap de cadeia de caracteres que contém o namespace do tipo.
  • Estende: um índice para o TypeRef que faz referência a uma classe combinável ou System. Object em mscorlib.
  • FieldList: deve estar vazio.
  • Methodlist: um índice na tabela MethodDef, marcando o primeiro de uma execução contígua de métodos pertencentes a esse tipo. As informações específicas sobre o conteúdo da tabela MethodDef são detalhadas abaixo.

Para todas as classes fornecidas pelo sistema, o Versionattribute deve ser adicionado à linha de TypeDef da classe.

Interfaces implementadas

Interfaces implementadas por classes de tempo de execução são representadas por linhas na tabela InterfaceImpl (ECMA II. 22.23) com as colunas definidas da seguinte maneira.

  • Classe: um índice na tabela de TypeDef para a linha que contém o tipo.
  • Interface: um índice na tabela TypeDef, TypeRef ou TypeSpec que especifica a interface implementada. Observe que, em arquivos de metadados fornecidos pelo sistema, isso nunca será um TypeDef, mesmo se a interface necessária estiver definida no mesmo arquivo de metadados. Consulte a seção redirecionamento de TypeDef para obter mais detalhes.

As classes de tempo de execução devem especificar o Defaultattribute em exatamente uma das linhas InterfaceImpl.

As classes de tempo de execução podem especificar Overridableattribute ou Protectedattribute em qualquer uma de suas linhas InterfaceImpl. Eles não podem especificar Overridableattribute e Protectedattribute na mesma linha.

Opcionalmente, o Versionattribute pode ser adicionado a qualquer uma das linhas interfaceImpl da classe. O valor da versão do Versionattribute nas linhas interfaceImpl de qualquer classe deve ser maior ou igual ao valor do Versionattribute na linha de TypeDef da classe.

Interfaces estáticas

As classes de tempo de execução têm zero ou mais atributos personalizados estaticamente. É legal especificar mais de um atributo personalizado de Staticattribute, desde que cada um tenha parâmetros especificados diferentes. Qualquer Staticattribute será exibido como uma linha na tabela CustomAttribute com as informações a seguir.

  • Parent: a classe de tempo de execução à qual o Staticattribute está associado.
  • Type: uma referência a Staticattribute. ctor.
  • Value: um blob de atributo personalizado que contém o parâmetro de interface estática System. Type e o parâmetro de versão UInt32.

Ativação

As classes de tempo de execução têm zero ou mais atributos personalizados ActivatableAttribute. É legal especificar mais de um ActivatableAttribute atributos personalizados, desde que cada um tenha parâmetros especificados diferentes. Qualquer ActivatableAttributes será exibido como uma linha na tabela CustomAttribute com as informações a seguir.

  • Parent: a classe de tempo de execução à qual o ActivatableAttribute está associado.
  • Tipo: uma referência a um dos dois. ctor de ActivatableAttribute.
    • Ativação direta: o. ctor assumindo apenas o parâmetro de versão UInt32.
    • Ativação de fábrica: o. ctor que assume o parâmetro de interface de fábrica System. Type e o parâmetro de versão UInt32.
  • Valor: um blob de atributo personalizado que contém o parâmetro de interface de fábrica System. Type (se fornecido) e o parâmetro de versão UInt32.

Composição

As classes de tempo de execução têm zero ou mais atributos personalizados ComposableAttribute. É legal especificar mais de um ComposableAttribute atributos personalizados, desde que cada um tenha parâmetros especificados diferentes. Qualquer ComposableAttribute será exibido como uma linha na tabela CustomAttribute com as informações a seguir.

  • Parent: a classe de tempo de execução à qual o ComposableAttribute está associado.
  • Tipo: uma referência ao ComposableAttribute. ctor.
  • Value: um blob de atributo personalizado que contém o parâmetro de interface de interface de fábrica de composição System. Type, um valor de enumeração compositiontype (público ou protegido) e o parâmetro de versão UInt32.

Métodos de classe

Uma classe de tempo de execução tem uma linha na tabela MethodDef para cada método em cada interface associada à classe. Isso inclui interfaces de membro (normal, protegida e substituível), interfaces estáticas, interfaces de fábrica de ativação e interfaces de fábrica combináveis. Além disso, uma classe que dá suporte à ativação direta também terá uma linha na tabela MethodDef para indicar isso.

Membros da interface do membro

Cada método de uma interface de membro (incluindo interfaces protegidas e substituíveis) é representado por uma linha na tabela MethodDef da classe. A tabela methodDef da classe contém uma cópia exata das informações de MethodDef da interface original declarativa, incluindo as linhas da tabela param e os atributos personalizados, com as seguintes exceções.

  • As classes de tempo de execução podem especificar nomes alternativos para métodos definidos em interfaces de membro.
  • Métodos em classes de tempo de execução não obtêm o sinalizador abstract.
  • Métodos em classes de tempo de execução obtêm o sinalizador MethodImpl de tempo de execução.
  • Os métodos de interfaces não substituíveis também obtêm o sinalizador final. Métodos de interfaces substituíveis não obtêm o sinalizador final.

Cada linha na tabela MethodDef de uma classe de uma interface de membro é conectada de volta ao método de interface que originalmente definiu o método por meio de uma entrada na tabela MethodImpl (ECMA II. 22.27) com valores como a seguir.

  • Classe – um índice na tabela TypeDef que faz referência à classe que está carregando o método (Observe que esse índice não está sujeito ao redirecionamento de TypeDef).
  • MethodBody – um índice na tabela MethodDef que faz referência ao método de classe.
  • MethodDeclaration – um índice na tabela MethodDef ou MemberRef que faz referência ao método de interface declarado originalmente.
Membros de interface estática

Cada método de uma interface estática é representado por uma linha na tabela MethodDef da classe. A tabela methodDef da classe contém uma cópia exata das informações de MethodDef da interface original declarativa, incluindo as linhas da tabela param e os atributos personalizados, com as seguintes exceções.

  • Os membros estáticos não obtêm os sinalizadores virtual, abstract, NewSlot e instance.
  • Membros estáticos obtêm os sinalizadores de classe e estáticos.
  • Métodos estáticos em classes de tempo de execução obtêm o sinalizador MethodImpl de tempo de execução.
Membros da ativação

Classes que dão suporte à ativação direta sem parâmetros têm uma linha de Construtor na tabela MethodDef da classe com os valores de coluna a seguir.

  • RVA: 0x00
  • ImplFlags: tempo de execução
  • Sinalizadores: público | HideBySig | SpecialName | RTSpecialName | Cópia
  • Name: um índice na tabela de cadeias de caracteres que contém ". ctor"
  • Assinatura: um índice no heap de BLOB que contém um blob MethodDefSig (ECMA II. 23.2.1) que não contém parâmetros e retorna NULL
  • Paramlist: deve estar vazio

As classes que dão suporte à ativação de fábrica têm uma linha de Construtor na tabela MethodDef da classe para cada método em cada interface de fábrica implementada com os valores de coluna a seguir.

  • RVA: 0x00
  • ImplFlags: tempo de execução
  • Sinalizadores: público | HideBySig | SpecialName | RTSpecialName | Cópia
  • Nome: um índice na tabela de cadeia de caracteres que contém ". ctor".
  • Assinatura: um índice no heap de BLOB que contém um blob MethodDefSig (ECMA II. 23.2.1) que contém os parâmetros de entrada e retorna NULL.
  • Paramlist: ponteiro para a tabela params com uma linha para cada parâmetro, copiado exatamente da tabela params para o método Factory declarando originalmente.
Membros da composição

As classes que dão suporte à ativação de fábrica de composição têm uma linha de Construtor na tabela MethodDef da classe para cada método em cada interface de fábrica implementada com os valores de coluna a seguir.

  • RVA: 0x00
  • ImplFlags: tempo de execução
  • Sinalizadores: público | HideBySig | SpecialName | RTSpecialName | Cópia
  • Nome: um índice na tabela de cadeia de caracteres que contém ". ctor".
  • Assinatura: um índice no heap de BLOB que contém um blob MethodDefSig (ECMA II. 23.2.1) que contém os parâmetros de entrada personalizados e retorna NULL. O parâmetro de controle IInspectable * [in] e o parâmetro de não delegação de IInspectable * * [out] não são refletidos na assinatura do método.
  • Paramlist: ponteiro para a tabela params com uma linha para cada parâmetro, exceto o parâmetro IInspectable * [no] e o parâmetro não delegation IInspectable * * [out], copiado exatamente da tabela params para o método Factory que o declarava originalmente.

Atributos personalizados

Os atributos personalizados têm zero ou mais métodos de construtor, cada um com zero ou mais parâmetros em que o tipo de parâmetro é limitado aos tipos fundamentais, enums e System. Type. Cada Construtor no atributo personalizado aparece como uma linha no MethodDef com as informações a seguir.

  • RVA (também conhecido como endereço virtual relativo): nulo
  • ImplFlags: nenhum
  • Sinalizadores: público | HideBySig | specalname | RTSpecialName (0x1886)
  • Nome: um índice na tabela de cadeia de caracteres que contém o nome ". ctor".
  • Assinatura: um índice no heap de BLOB que contém um blob MethodDefSig (ECMA II. 23.2.1) que contém os tipos de parâmetro e o tipo de retorno do método.
  • Paramlist: um índice na tabela param (ECMA II. 22.33) que contém o primeiro em uma execução de linhas param associadas a esse método.

Os atributos personalizados em construções de metadados são armazenados como linhas na tabela CustomAttribute (ECMA II. 22.10) com as colunas definidas da seguinte maneira.

  • Pai: índice na tabela de metadados à qual o atributo personalizado está anexado.
  • Tipo: index na tabela MethodDef ou MemberRef que contém uma referência ao construtor do tipo de atributo.
  • Valor: índice no heap de BLOB que contém parâmetros de atributo posicionais e nomeados (ECMA II. 23.2). Observe que, como os atributos personalizados do WinRT não têm permissão para ter propriedades, o blob de atributo personalizado nunca conterá o estilo de propriedade denominado argumentos.