Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Actualización: noviembre 2007
Las API de metadatos de Common Language Runtime (CLR) permiten obtener acceso a los metadatos de un componente sin que el motor en tiempo de ejecución tenga que cargar la clase. La API está diseñada específicamente para maximizar el rendimiento y minimizar las sobrecargas. El motor de metadatos hace que los datos estén disponibles pero no permite proporcionar acceso directo a las estructuras de datos de la memoria. Por el contrario, cuando se carga una clase en tiempo de ejecución, el cargador importa los metadatos a sus propias estructuras de datos, que se pueden examinar mediante los servicios de reflexión del motor en tiempo de ejecución.
API de metadatos y servicios de reflexión
Los servicios de reflexión hacen mucho más trabajo que las API de metadatos. Por ejemplo, recorrer automáticamente la jerarquía de herencia para obtener información sobre los métodos y campos heredados. La API de metadatos devuelve sólo las declaraciones de miembros directos para una clase determinada y requiere que el cliente de API realice llamadas adicionales para recorrer la jerarquía y enumerar los métodos heredados. El sistema de los servicios de reflexión expone una vista de nivel superior de los metadatos, mientras que el sistema de la API de metadatos deja que el cliente de API se encargue de recorrer las estructuras de datos.
Ámbito
En un momento dado, puede haber varias áreas de memoria que contengan metadatos. Por ejemplo, puede haber un área que asigne todos los metadatos de un módulo existente en el disco. Al mismo tiempo, pueden estar emitiéndose metadatos en otra área independiente que más adelante se guardará como un módulo en un archivo.
Nota
En este contexto, la palabra módulo hace referencia a un archivo que contiene metadatos. Normalmente será un archivo .obj, .exe o .dll que contenga metadatos y código de lenguaje intermedio de Microsoft (MSIL), pero también puede ser un archivo que sólo contenga metadatos.
Cada área de metadatos en memoria se conoce como ámbito. Cada ámbito corresponde a un módulo. A menudo, los módulos se guardan como archivos en disco, pero no es obligatorio. Por ejemplo, las herramientas de secuencias de comandos con frecuencia generan metadatos que nunca se conservan en un archivo.
Se utiliza el término ámbito porque representa la región en la que se definen los tokens de metadatos. Por ejemplo, un token de metadatos con el valor N identifica los detalles de una definición de clase, dentro de un ámbito determinado. Sin embargo, un token de metadatos con el mismo valor N puede corresponder a un conjunto de detalles totalmente diferente para un ámbito diferente.
Para establecer un ámbito de metadatos en memoria, se ha de llamar al método CComPtrBase::CoCreateInstance de la interfaz IMetaDataDispenser. Este método crea un ámbito nuevo o abre un conjunto existente de estructuras de metadatos desde una ubicación en memoria o archivo. Con cada llamada al método IMetaDataDispenser::DefineScope o IMetaDataDispenser::OpenScope, el llamador especifica qué API se va a recibir:
La interfaz IMetaDataEmit permite que las herramientas escriban en un ámbito de metadatos.
La interfaz IMetaDataEmit permite que las herramientas lean en un ámbito de metadatos.
Comprobación de errores
La API de metadatos realiza una comprobación mínima de errores semánticos. Los métodos de la API de metadatos suponen que las herramientas y los servicios que emiten metadatos exigen las reglas del sistema de objetos que se describen en el sistema de tipos común, y que cualquier comprobación adicional por parte del motor de metadatos en tiempo de desarrollo es superflua.