Acerca de...
El equipo
Encuestas
Política de privacidad
WinTablets

Encuesta

¿Cual crees que triunfará?

Ver Resultados

Cargando ... Cargando ...

últimas entradas importantes

Categorías

Archivos

14
Sep 2014
DesarrolloInteroprfogdevtrucos

Excepción TypeLoadException o TypeInitializationException al usar mi DLL nativa o instalada con NuGet en Windows Phone

En la entrada anterior hemos explicado cómo usar una DLL escrita en C++/CX para envolver a una nativa o simplemente para utilizar código Win32 que no tenga equivalente en el API ofrecido por el SDK correspondiente.

Pero en muchas ocasiones, pese a seguir los pasos de forma adecuada y conforme está documentado (como se explicó en la entrada anterior), obtenemos una excepción de uno de los dos tipos arriba indicados, si no las dos una seguida de otra a la hora de ejecutar el código de dicha DLL.

Os explico aquí la solución al problema.

Cuando añadimos la referencia de la DLL (o bien lo hace por nosotros NuGet), durante el proceso de compilación de la aplicación, se debe producir un paso más de forma automática, que es modificar el fichero WMAppManifest.xaml para añadir una secuenca XML que es la que posibilitará el registro de la DLL (el objeto COM de que hablábamos en la entrada anterior).

Para los que no lo sepan, el fichero WMAppManifest.xaml es el manifiesto de la aplicación, en donde se indican toda una serie de metadatos para que tanto el cargador del sistema operativo sepa qué hacer con el ejecutable embebido en el paquete, como que el propio ejecutable sepa qué tiene dentro y qué puede usar de la plataforma en la que se ejecuta.

Por tanto, es ahí donde va toda la información de los objetos externos que la aplicación pueda levantar, como una posible comunicación entre un teórico backend ejecutándose dentro del núcleo del sistema operativo (como el soporte para VOIP) o simplemente un proceso multimedia.

Pues bien, ocurre a veces que las líneas que hay que añadir ahí cuando se inserta un componente de Windows Runtime no son insertadas durante el proceso de compilación y enlazado por lo que posiblemente sea un bug del compilador.

En el caso que nos ocupa, se debería haber añadido el siguiente bloque XML dentro de la sección <ActivatableClasses>:

 <InProcessServer>
<Path>NetHelper.DLL</Path>
<ActivatableClass ActivatableClassId=»NetHelper.DeviceName» ThreadingModel=»MTA» />
</InProcessServer>

En general, aunque todavía no está completamente determinado, ocurre cuando ya existe algún elemento añadido dentro de <ActivatableClasses>. O bien el compilador asume que ya lo has añadido tu, o bien es un simple bug. En cualquier caso, todo esto está sin documentar de forma oficial.

¿Para qué sirve ese XML? Casi está descrito por sí mismo a poco que se haya leído la entrada anterior: dentro de las clases COM activables, tenemos una que se va a ejecutar dentro de nuestro propio proceso (<InProcessServer>) cuya ruta es NetHelper.dll y el nombre de la clase, DeviceName desde el espacio de nombres NetHelper.

Es la forma que nos ofrece Microsoft para simplificar todo el tema del registro y carga de objetos COM, que otro modo deberíamos hacer de forma manual y posiblemente utilizando un API que tampoco se nos ofrece de manera pública.

De todos modos, el problema vino, en mi caso, cuando añadí a mi aplicación la biblioteca llamada Microsoft.Bcl.Compression mediante NuGet, que se supone también realiza todos los pasos de forma automática. Esta biblioteca utiliza por debajo otra nativa basada en GZIP, y es aquí donde viene el baile y donde también podría fallar todo el sistema.

Es decir, Microsoft.Compression utiliza la técnica de envolver una DLL nativa con otra escrita en C++/CX (o supongo que también en C# con Interop por atributos, no lo sé), o incluso envolver una escrita en C++/CX con otra en C#. Ignoro completamente cómo está por debajo, lo único que sé es que tardé unos dos días a encontrar la solución, porque aplicando el código XML arriba descrito sobre la propia biblioteca tampoco funcionaba hasta que, mirando con más detalle, no era la DLL principal la que no se registraba, sino una secundaria con otro nombre.

La solución al uso de Microsoft.Bcl.Compression cuando te da una excepción de alguno de los dos tipos descritos arriba es añadir a la misma sección de arriba el siguiente bloque XML:

Pasted Graphic

NOTA: Yo lo llamo objetos COM y tecnología COM pero realmente no son tales, sino que es la evolución lógica de ese concepto aplicado primero a .NET y luego a las aplicaciones de la Tienda de Windows y, dado que ignoro si tienen otro nombre, o si acaso lo tienen, es que he decidido darles.

Por RFOG | 3 Comentarios | Enlaza esta entrada
contacto@wintablet.info tema WinTablet.info por Ángel García (Hal9000)