Compartir a través de

  • Artículo

Este artículo proviene de un motor de traducción automática.

Windows en tiempo de ejecución y CLR

Una visita al interior de .NET y Windows en tiempo de ejecución

Shawn Farkas

 

El tiempo de ejecución de Windows (WinRT) proporciona un amplio conjunto de nuevas API para los desarrolladores de la experiencia de Windows. El CLR 4.5, que barcos como parte de Microsoft .NET Framework 4.5 en Windows 8, permite a los desarrolladores escribir código para utilizar las APIs de forma natural, administrado sólo como si fueran otra biblioteca de clases. Puede agregar una referencia al archivo de metadatos de Windows (WinMD) que define las APIs que desea llamar y luego llame a ellos al igual que con un estándar API administrada. Visual Studio agrega automáticamente una referencia a la incorporada en el conjunto de APIs WinRT a nuevos proyectos de la interfaz de usuario de Windows, por lo que su aplicación simplemente puede comenzar a utilizar esta nueva API.

Bajo el capó, el CLR proporciona la infraestructura para el código administrado a consumir WinMD archivos y transición entre código administrado y el tiempo de ejecución de Windows. En este artículo, te voy a mostrar algunos de estos detalles. Llegarás lejos con una mejor comprensión de lo que ocurre detrás de las escenas cuando su programa administrado llama a una API de WinRT.

Consumo de WinMD archivos de código administrado

WinRT APIs se definen en los archivos de WinMD, que son codificados usando el formato de archivo se describe en ECMA-335 (bit.ly/sLILI). Aunque los archivos WinMD y ensamblados de .NET Framework comparten una codificación común, no son lo mismo. Una de las principales diferencias en los metadatos surge del hecho de que el sistema de tipo de WinRT es independiente del sistema de tipo de .NET.

Programas como el compilador de C# y Visual Studio utilizan los metadatos CLR API (como IMetaDataImport) leer los metadatos del ensamblado de .NET Framework y ahora pueden leer metadatos de archivos de WinMD así. Porque los metadatos no están exactamente lo mismo que un ensamblado .NET, el lector de metadatos CLR inserta un adaptador entre el API de metadatos y el archivo WinMD que se está leyendo. Esto permite archivos de WinMD leerse como si fueran ensamblados .NET (ver figura 1).

The CLR Inserts a Metadata Adapter Between WinMD Files and the Public Metadata Interface
Figura 1 CLR inserta un adaptador de metadatos entre los archivos de WinMD y la interfaz pública de metadatos

Ejecutando ILDasm le ayuda a comprender las modificaciones que realiza el adaptador de metadatos CLR en un archivo de WinMD. De forma predeterminada, ILDasm muestra el contenido de un archivo WinMD en su forma cruda, como está codificado en el disco sin el adaptador de metadatos CLR. Sin embargo, si pasa el parámetro de línea de comandos/Project ILDasm, permite al adaptador de metadatos, puede ver los metadatos como el CLR y administrados herramientas va a leer.

Mediante la ejecución de copias de ILDasm al lado — uno con el parámetro/Project y uno sin — usted puede explorar fácilmente los cambios que hace que el adaptador de metadatos CLR en un archivo de WinMD.

El tiempo de ejecución de Windows y los sistemas de tipo de .NET

Una de las principales operaciones que realiza el adaptador de metadatos es combinar los sistemas de tipo WinRT y. net. En un nivel alto, cinco diferentes categorías de tipos de WinRT pueden aparecer en un archivo de WinMD y necesitan ser consideradas por el CLR. Éstos se enumeran en figura 2. Echemos un vistazo a cada categoría con más detalle.

Figura 2 tipos de WinRT para un archivo de WinMD

Categoría Ejemplos
Tipos de WinRT estándar Windows.Foundation.Collections.PropertySet, Windows.Networking.Sockets.DatagramSocket
Tipos primitivos Byte, Int32, String, objeto
Tipos de proyecciones Windows.Foundation.Uri, Windows.Foundation.DateTime
Interfaces proyectadas Windows.Foundation.Collections.IVector <T>, Windows.Foundation.Iclosable
Tipos con ayudantes de .NET Windows.Storage.Streams.IInputStream, Windows.Foundation.IasyncInfo

Tipos estándar de WinRT mientras que el CLR tiene soporte especial para muchas categorías de tipos expuestos por el tiempo de ejecución de Windows, la mayoría de tipos de WinRT no es tratada especialmente por el CLR en absoluto. En cambio, estos tipos parecen desarrolladores .NET sin modificar, y puede utilizarse como una biblioteca de gran clase para permitir escribir Windows tienda aplicaciones.

Tipos primitivos este conjunto de tipos primitivos se codifica en un archivo de WinMD mediante la enumeración de ELEMENT_TYPE misma que uso de ensamblados .NET. El CLR interpreta automáticamente estos tipos primitivos como si fueran los equivalentes. net.

En su mayor parte, tratando de tipos de winrt primitivos como tipos primitivos de .NET sólo funciona. Por ejemplo, un entero de 32 bits tiene el mismo patrón de bits en tiempo de ejecución de Windows como lo hace en. NET, el CLR puede tratar un DWORD WinRT como un System.Int32 .NET sin ningún problema. Pero dos excepciones notables son cadenas y objetos.

En el tiempo de ejecución de Windows, las cadenas están representadas con el tipo de datos HSTRING, que no es lo mismo que un .NET System.String. Asimismo, ELEMENT_TYPE_OBJECT significa System.Object a. NET, mientras que significa IInspectable * el tiempo de ejecución de Windows. Para cadenas y objetos, el CLR debe calcular las referencias de objetos en tiempo de ejecución para convertir entre las representaciones de los tipos WinRT y .NET. Verás cómo este cálculo de referencias funciona más adelante en este artículo.

Proyecta tipos hay algunos tipos de .NET fundamentales existentes que tienen equivalentes en el sistema de tipo de WinRT. Por ejemplo, el tiempo de ejecución de Windows define una estructura TimeSpan y una clase de Uri, los cuales tienen tipos correspondientes en .NET Framework.

Para evitar forzar a los programadores de .NET para convertir y hacia atrás entre estos tipos de datos fundamentales, el CLR proyectos de la versión de WinRT en su equivalente de .NET. Estas proyecciones son efectivamente combinar puntos que CLR inserta entre el .NET y WinRT tipo de sistemas.

Por ejemplo, la sindicación de tiempo de ejecución de Windows­Client.RetrieveFeedAsync API toma un WinRT Uri como su parámetro. En lugar de requerir a los desarrolladores de .NET crear manualmente una nueva instancia de Windows.Foundation.Uri para pasar a esta API, los proyectos CLR el tipo como un System.Uri, que permite a los desarrolladores .NET utilice el tipo que están más familiarizados con.

Otro ejemplo de una proyección es la Windows.Founda­ción.HResult estructura, que se proyecta por el CLR para el tipo de System.Exception. En. NET, los desarrolladores se utilizan para ver la información de error transmitido como una excepción en lugar de un error HRESULT, así que tener una API de WinRT como IAsycn­Info.ErrorCode express-información del error como una estructura de HResult no sienta natural. En cambio, el CLR proyectos HResult a excepción, lo que hace una API de WinRT como IAsyncInfo.ErrorCode más utilizable para los desarrolladores. net. Aquí está un ejemplo de la propiedad de IAsyncInfo ErrorCode codificado en Windows.winmd:

.class interface public windowsruntime IAsyncInfo
{
  .method public abstract virtual
    instance valuetype Windows.Foundation.HResult
    get_ErrorCode()
}

Y aquí está la propiedad IAsyncInfo ErrorCode después de la proyección de CLR:

 

.class interface public windowsruntime IAsyncInfo
{
 .method public abstract virtual
   instance class [System.Runtime]System.Exception
   get_ErrorCode()
}

Proyecta Interfaces el tiempo de ejecución de Windows también proporciona un conjunto de interfaces fundamentales que tienen equivalentes en. net. El CLR realiza proyecciones de tipo en estas interfaces así, volver a combinar los sistemas de tipo en estos puntos fundamentales.

Los ejemplos más comunes de interfaces proyectadas son las interfaces de colección de WinRT, como IVector <T>, IIterable <T> e IMap < K, V >. Los desarrolladores que utilicen .NET están familiarizados con interfaces de colección como IList <T>, IEnumerable <T> y IDictionary < K, V >. Los proyectos CLR WinRT colección de interfaces con sus equivalentes en .NET y también oculta el WinRT interfaces para que los desarrolladores no tienen que lidiar con dos sistemas funcionalmente equivalentes de tipos que hacen lo mismo.

Además de proyectar estos tipos cuando aparecen como parámetros y devolver tipos de métodos, el CLR también debe sobresalir estas interfaces cuando aparecen en la lista de interfaces de la aplicación de un tipo. Por ejemplo, el tipo de WinRT PropertySet implementa el WinRT IMap < string, object > interfaz. Sin embargo, el CLR, proyectará PropertySet como un tipo que implementa IDictionary < string, object >. Al realizar esta proyección, los miembros de PropertySet que se utilizan para implementar IMap < string, object > están ocultos. En cambio, los desarrolladores .NET acceder PropertySet a través de la correspondiente IDictionary < string, object > métodos. Ésta es una vista parcial de PropertySet como codificados en Windows.winmd:

.class public windowsruntime PropertySet
  implements IPropertySet,
    class IMap`2<string,object>,
    class IIterable`1<class IKeyValuePair`2<string,object> >
{
  .method public instance uint32 get_Size()
  {
    .override  method instance uint32 class 
      IMap`2<string,object>::get_Size()
  }
}

Y ésta es una vista parcial de PropertySet después de la proyección de CLR:

.class public windowsruntime PropertySet
  implements IPropertySet,
    class IDictionary`2<string,object>,
    class IEnumerable`1<class KeyValuePair`2<string,object> >
{
  .method private instance uint32 get_Size()
  {
  }
}

Observe que se producen las proyecciones de tres tipos: IMap < string, object > IDictionary < string, object >, IKeyValuePair < string, object > KeyValuePair < string, object > y IIterable <IKeyValuePair> a IEnumerable <KeyValuePair>. También observe que el método de get_Size de IMap está oculto.

Tipos con .NET Framework ayudantes el tiempo de ejecución de Windows tiene varios tipos que no tienen una combinación de todo punto en el sistema de tipo de .NET pero son lo suficientemente importantes como para la mayoría de las aplicaciones .NET Framework proporciona métodos auxiliares para trabajar con ellos. Dos de los mejores ejemplos son las interfaces de WinRT stream y async.

Aunque el CLR no proyecto Windows.Storage.Streams.IRandomAccess­Stream a System.Stream, proporcionan un conjunto de métodos de extensión para IRandom­AccessStream que permite su código tratar estas corrientes de WinRT como si fueran arroyos. net. Por ejemplo, puede leer fácilmente una secuencia de WinRT con el StreamReader .NET llamando al método de extensión OpenStreamForReadAsync.

El tiempo de ejecución de Windows proporciona un conjunto de interfaces que representan las operaciones asincrónicas, como la interfaz de IAsyncInfo. En .NET Framework 4.5, hay compatibilidad integrada para las operaciones asincrónicas, que los desarrolladores desean utilizar con APIs de WinRT de la misma manera que lo hacen para API de .NET a la espera.

Para ello, .NET Framework se suministra con un conjunto de métodos de extensión GetAwaiter para las interfaces de async WinRT. Estos métodos son utilizados por el C# y Visual Basic compiladores para habilitar operaciones asincrónicas de espera WinRT. Aquí está un ejemplo:

private async Task<string> ReadFilesync(StorageFolder parentFolder, 
  string fileName)
{
  using (Stream stream = await parentFolder.OpenStreamForReadAsync(fileName))
  using (StreamReader reader = new StreamReader(stream))
  {
    return await reader.ReadToEndAsync();
    }
}

Etapa de transición entre el .NET Framework y theWindows Runtime el CLR proporciona un mecanismo para código administrado llamar perfectamente WinRT APIs y para el tiempo de ejecución de Windows devolver la llamada al código administrado.

En su nivel más bajo, el tiempo de ejecución de Windows está construido sobre conceptos de COM, por lo que no es ninguna sorpresa que el apoyo CLR para llamar a WinRT APIs está construido sobre la infraestructura de interoperabilidad COM existente.

Una diferencia importante entre la interoperabilidad de la WinRT y la interoperabilidad COM es cuánto menos configuración tienes que tratar en el tiempo de ejecución de Windows. Archivos de WinMD tienen metadatos enriquecidos que describe todas las API que están exponiendo con una asignación definida en el sistema de tipo. NET, por lo que no es necesario utilizar ningún atributo MarshalAs en código administrado. Asimismo, debido a que Windows 8 se suministra con archivos WinMD para su WinRT APIs, no necesita tener un ensamblado de interoperabilidad primario liado con su aplicación. En cambio, el CLR utiliza los archivos de WinMD en caja para averiguar todo lo que necesita saber acerca de cómo llamar WinRT APIs.

Estos archivos de WinMD proporcionan las definiciones de tipo administrado que se utilizan en tiempo de ejecución para permitir a los desarrolladores gestionados acceso al tiempo de ejecución de Windows. Aunque las APIs que CLR Lee de un archivo WinMD contienen una definición de método que se ha formateado para ser utilizado fácilmente desde el código administrado, la API de WinRT subyacente utiliza una firma de API diferente (a veces denominado la interfaz binaria de aplicaciones o ABI, firma). Un ejemplo de una diferencia entre los API y ABI firmas es que, como COM estándar, WinRT APIs devolver valores HRESULT, y el valor devuelto de una API de WinRT es realmente un parámetro de salida en la firma ABI. Te voy a mostrar un ejemplo de cómo una firma de método administrado se transforma en una firma de WinRT ABI cuando miro cómo CLR llama a una API de WinRT más adelante en este artículo.

Runtime Callable envolturas y contenedores que se puede llamar de COM

Cuando un objeto de WinRT entra en el CLR, tiene que ser exigible como si se tratara de un objeto. net. Para que esto suceda, el CLR envuelve cada objeto WinRT un runtime callable wrapper (RCW). El RCW es interactúa con qué código administrado y es la interfaz entre el código y el objeto de WinRT que está utilizando su código.

Por el contrario, cuando se utilizan objetos administrados desde el tiempo de ejecución de Windows, que necesitan para ser llamado como si fueran objetos de WinRT. En este caso, los objetos administrados están envueltos en un contenedor COM invocable (CCW) cuando estás enviaban al tiempo de ejecución de Windows. Porque el tiempo de ejecución de Windows utiliza la misma infraestructura como COM, puede interactuar con CCWs a la funcionalidad de acceso sobre el objeto administrado (ver figura 3).

Using Wrappers for Windows Runtime and Managed Objects
Figura 3 usando envolturas para tiempo de ejecución de Windows y objetos administrados

Cálculo de referencias de talones

Cuando pasa de código administrado a través de cualquier límite de interoperabilidad, incluyendo WinRT las fronteras deben ocurrir varias cosas:

  1. Convertir parámetros de entrada administrados en equivalentes de WinRT, incluyendo la construcción CCWs para objetos administrados.
  2. Encuentra la interfaz que implementa el método de WinRT que se llama desde el RCW que se llama el método de.
  3. Llame al método WinRT.
  4. Convertir parámetros de salida de WinRT (incluidos los valores de retorno) en equivalentes administrados.
  5. Convertir cualquier falla de valores HRESULT de la API de WinRT una excepción administrada.

Estas operaciones se producen en un trozo de cálculo de referencias, que el CLR genera en nombre de su programa. Los talonarios de cálculo de referencias sobre un RCW son qué código administrado llama antes de la transición hacia una API de WinRT. Del mismo modo, el tiempo de ejecución de Windows llama talones de cálculo de referencias generadas por el CLR en un CCW cuando pasa a código administrado.

Talones de cálculo proporcionan el puente que atraviesa el espacio entre el tiempo de ejecución de Windows y .NET Framework. Comprender cómo funcionan le ayudará a obtener una comprensión más profunda de lo que sucede cuando el programa se llama en el tiempo de ejecución de Windows.

Una llamada de ejemplo

Imaginar una API de WinRT que toma una lista de cadenas y concatena, con una cadena de separador entre cada elemento. Esta API puede tener una firma administrada tales como:

public string Join(IEnumerable<string> list, string separator)

El CLR debe llamar al método como se define en el ABI, por lo que necesita averiguar la firma ABI del método. Afortunadamente, un conjunto de transformaciones deterministas puede aplicarse para obtener inequívocamente una firma ABI dada una firma de API. La primera transformación es reemplazar los tipos de datos proyectados con sus equivalentes de WinRT, que devuelve la API a la forma en que se define en el archivo WinMD antes de que el adaptador de metadatos había cargado. En este caso, IEnumerable <T> es realmente una proyección de IIterable <T>, por lo que la vista de la WinMD de esta función es en realidad:

public string Join(IIterable<string> list, string separator)

Cadenas de WinRT se almacenan en un tipo de datos HSTRING, así que para el tiempo de ejecución de Windows, esta función realmente parece ser:

public HSTRING Join(IIterable<HSTRING> list, HSTRING separator)

En la capa ABI, donde realmente ocurre la llamada, WinRT APIs tienen HRESULT valores de retorno y el valor devuelto de su firma es un parámetro de salida. Además, los objetos son punteros, por lo que sería la firma ABI para este método:

HRESULT Join(__in IIterable<HSTRING>* list, HSTRING separator, __out HSTRING* retval)

Todos los métodos de WinRT deben ser parte de una interfaz que implementa un objeto. Nuestro método de combinación, por ejemplo, podría ser parte de una interfaz de IConcatenation apoyada por una clase de StringUtilities. Antes de hacer un método unirse a una llamada, el CLR debe coger el puntero de interfaz IConcatenation para hacer la llamada de.

El trabajo de un talón de cálculo de referencias es convertir el original administrado a llamada en un RCW en WinRT final en una interfaz WinRT. En este caso, podría ser el pseudo-código para el cálculo de referencias stub como figura 4 (con llamadas de limpieza omitidas para mayor claridad).

Figura 4 ejemplo de un talón de cálculo de referencias para realizar una llamada desde el CLR al tiempo de ejecución de Windows

public string Join(IEnumerable<string> list, string separator)
{
  // Convert the managed parameters to WinRT types
  CCW ccwList = GetCCW(list);
  IIterable<HSTRING>* pCcwIterable = ccwList.QueryInterface(IID_IIterable_HSTRING);
  HSTRING hstringSeparator = StringToHString(separator);
  // The object that managed code calls is actually an RCW
  RCW rcw = this;
  // You need to find the WinRT interface pointer for IConcatenation
  // implemented by the RCW in order to call its Join method
  IConcatination* pConcat = null;
  HRESULT hrQI = rcw.QueryInterface(IID_ IConcatenation, out pConcat);
  if (FAILED(hrQI))
    {
      // Most frequently this is an InvalidCastException due to the WinRT
      // object returning E_NOINTERFACE for the interface that contains
      // the method you're trying to call
      Exception qiError = GetExceptionForHR(hrQI);
      throw qiError;
    }
    // Call the real Join method
    HSTRING returnValue;
    HRESULT hrCall = pConcat->Join(pCcwIterable, hstringSeparator, &returnValue);
    // If the WinRT method fails, convert that failure to an exception
    if (FAILED(hrCall))
    {
      Exception callError = GetExceptionForHR(hrCall);
      throw callError;
    }
    // Convert the output parameters from WinRT types to .NET types
    return HStringToString(returnValue);
}

En este ejemplo, el primer paso es convertir los parámetros gestionados desde su representación administrada a su representación de WinRT. En este caso, el código crea una Convención para el parámetro de la lista y el parámetro System.String convierte en un HSTRING.

El siguiente paso es encontrar la interfaz WinRT que suministra la aplicación de ingreso. Esto se produce mediante la emisión de una llamada QueryInterface al objeto WinRT que es envuelto por el RCW que el código administrado llamado unirse en. La razón más común que una InvalidCastException obtiene arrojado desde una llamada al método de WinRT es si esta llamada QueryInterface falla. Esto puede ocurrir una de las razones es que el objeto WinRT no implementa todas las interfaces que espera que el llamador.

Ahora se produce la acción real — el stub de interoperabilidad que hace la llamada al método WinRT Join, proporciona una ubicación para almacenar la lógica real regresar en valor HSTRING. Si falla el método de WinRT, esto indica con un error HRESULT, que el trozo de interoperabilidad se convierte en una excepción y lanza. Esto significa que si el código administrado ve una excepción de una llamada al método de WinRT, es probable que el método de WinRT que se llama devuelve un error HRESULT y CLR produjo una excepción para indicar que ese estado de fallo en el código.

El paso final es convertir los parámetros de salida de su representación de WinRT a su forma. net. En este ejemplo, la lógica devolver valor es un parámetro de salida de la convocatoria de ingreso y debe convertirse en un HSTRING en una cadena. net. Este valor puede devolverse luego como resultado del codo.

Llamando desde el tiempo de ejecución de Windows en código administrado

Llamadas que se originan en el tiempo de ejecución de Windows y el destino consiguió trabajo de código de una manera similar. El CLR responde a las llamadas a QueryInterface que el componente de tiempo de ejecución de Windows hace contra él con una interfaz que tiene una tabla de función virtual que se rellena con métodos de interoperabilidad de código auxiliar. Estos talones realizan la misma función que la mostré anteriormente, pero en sentido inverso.

Consideremos el caso de la API de unirse de nuevo, excepto esta vez asumir se implementa en código administrado y se llama en desde un componente de tiempo de ejecución de Windows. Pseudo-código para un código auxiliar que permite esta transición ocurra podría parecerse figura 5.

Figura 5 ejemplo de un talón de cálculo de referencias para realizar una llamada desde el tiempo de ejecución de Windows al CLR

HRESULT Join(__in IIterable<HSTRING>* list, 
  HSTRING separator, __out HSTRING* retval)
{
  *retval = null;
  // The object that native code is calling is actually a CCW
  CCW ccw = GetCCWFromComPointer(this);
  // Convert the WinRT parameters to managed types
  RCW rcwList = GetRCW(list);
  IEnumerable<string> managedList = (IEnumerable<string>)rcwList;
  string managedSeparator = HStringToString(separator);
  string result;
  try
  {
    // Call the managed Join implementation
    result = ccw.Join(managedList, managedSeparator);
  }
  catch (Exception e)
  {
    // The managed implementation threw an exception -
    // return that as a failure HRESULT
    return GetHRForException(e);
  }
  // Convert the output value from a managed type to a WinRT type
  *retval = StringToHSTring(result);
  return S_OK;
}

En primer lugar, este código convierte los parámetros de entrada de sus tipos de datos de WinRT en tipos administrados. Suponiendo que la lista de entrada es un objeto de WinRT, el talón debe obtener un RCW para representar ese objeto para permitir que el código administrado utilizarlo. El valor de cadena se convierte simplemente en un HSTRING a un System.String.

A continuación, se realiza la llamada a la implementación administrada del método Join en la Convención. Si este método produce una excepción, el stub interoperabilidad atrapa y lo convierte en un error HRESULT que se devuelve al llamador WinRT. Esto explica por qué algunas excepciones desde el código administrado por componentes de tiempo de ejecución de Windows no crash el proceso. Si el componente de tiempo de ejecución de Windows controla el error HRESULT, es lo mismo que captura y manejo de la excepción producida.

El paso final es convertir el parámetro de salida de su tipo de datos de .NET para el tipo de datos equivalente de WinRT, en este caso convertir la System.String a un HSTRING. El valor devuelto se coloca en el parámetro de salida y un éxito que HRESULT devuelto.

Interfaces proyectadas

Anteriormente, he mencionado que el CLR proyectará algunas interfaces de WinRT en las interfaces de .NET equivalentes. Por ejemplo, IMap < K, V > se proyecta a IDictionary < K, V >. Esto significa que cualquier mapa de WinRT es accesible como un diccionario. NET y viceversa. Para habilitar esta proyección trabajar, otro conjunto de talones es necesario para implementar la interfaz WinRT en términos de la interfaz de .NET que se proyecta a y viceversa. Por ejemplo, IDictionary < K, V > tiene un método TryGetValue, pero IMap < K, V > no contiene este método. Para permitir que administrado a quienes llaman a utilizar TryGetValue, el CLR proporciona un stub que implementa este método en términos de métodos que tienen IMap. Esto podría ser similar al figura 6.

Figura 6 aplicación Conceptual de IDictionary en términos de IMap

bool TryGetValue(K key, out V value)
{
  // "this" is the IMap RCW
  IMap<K,V> rcw = this;
  // IMap provides a HasKey and Lookup function, so you can
  // implement TryGetValue in terms of those functions
  if (!rcw.HasKey(key))
    return false;
  value = rcw.Lookup(key);
  return true;
}

Observe que para hacer su trabajo, este trozo de conversión hace varias llamadas a la implementación subyacente de IMap. Por ejemplo, digamos que usted escribió el siguiente bit de código administrado para ver si un objeto Windows.Foundation.Collections.PropertySet contiene la clave "Exacted":

 

object value;
if (propertySet.TryGetValue("NYJ", out value))
{
  // ...
}

Como la llamada TryGetValue determina si el conjunto de propiedades contiene la clave, la pila de llamadas se parece figura 7.

Pila de llamadas de la figura 7 para TryGetValue llamada

Pila Descripción
PropertySet::HasKey Aplicación de WinRT PropertySet
HasKey_Stub Cálculo de referencias de stub conversión llamada de HasKey del esbozo de diccionario en una llamada de WinRT
TryGetValue_Stub Trozo de implementar IDictionary en términos de IMap
Aplicación Código de la aplicación llamada PropertySet.TryGetValue administrado

En resumen

El apoyo CLR para el tiempo de ejecución de Windows permite a los desarrolladores administrados llame WinRT API definidas en los archivos de WinMD tan fácilmente como pueden llamar API administradas definidas en un ensamblado de .NET estándar. Bajo el capó, el CLR utiliza un adaptador de metadatos para realizar proyecciones que ayudan a combinar el sistema de tipo de WinRT con el sistema de tipo de .NET. También utiliza un conjunto de talones de interoperabilidad para permitir código .NET llamar a métodos de WinRT y viceversa. Tomados en conjunto, estas técnicas hacen fácil para que los desarrolladores administrados llamar WinRT APIs desde sus aplicaciones de tienda de Windows.

Shawn Farkas ha trabajado en el CLR para 10 años y actualmente es el responsable de desarrollo a cargo de la proyección de tiempo de ejecución de CLR Windows y la interoperabilidad de .NET. Antes de Microsoft .NET Framework 4.5, trabajó en el modelo de seguridad CLR. Su blog se puede encontrar en blogs.msdn.com/shawnfa.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Ryan Byington, Layla Driscoll y Yi Zhang