Hay múltiples ocasiones en las que tenemos que utilizar código nativo desde una aplicación manejada en .NET. Es el caso habitual de tener que reutilizar aplicaciones o componentes COM antiguos, desarrollados tiempo atrás en lenguajes como el obsoleto Visual Basic y para los que no está prevista una migración a .NET, o bien cuando debemos trabajar con drivers y componentes a bajo nivel, programados habitualmente en C/C++. En esos casos, tenemos que vérnoslas con Interop y, de paso, con la conversión de tipos entre las distintas tecnologías.
Dicha tarea no tiene porqué ser necesariamente dificultosa (aunque puede provocarnos más de un dolor de cabeza si decide no funcionar, a la hora de llevar a cabo depuraciones y averiguar a qué componente corresponde la responsabilidad del problema que nos estemos encontrando), pero sí es, como mínimo, tediosa. Por eso, los chicos de Microsoft lanzaron hace tiempo una herramienta que, he de confesarlo, no había probado hasta ahora, que andaba investigando un poco el tema y me he topado de frente con ella. Se trata de PInvoke Interop Assistant, un asistente que genera automáticamente el código en C# o VB.NET que maneja las llamadas a la API de Windows y DLLs provenientes de código no manejado (desarrollado en C).
Como puede verse en las capturas que adjunto, basta con consultar en la API de Windows, de la que ya trae información, o cargar una DLL que contenga su correspondiente manifiesto para obtener el código fuente correspondiente.
Toda una ayuda para los desarrolladores que tengan que enfrentarse al marshalling entre código manejado y nativo. La herramienta, documentación y código fuente asociados pueden descargarse desde la página del grupo en CodePlex.
Un par de dudillas, que no sé si he entendido bien...esta herramienta genera código managed (una especie de proxy con atributos DLLImport etc.) para llamar a las librerías unmanaged, que siguen siendo necesarias, ¿no? ¿O directamente traduce las librerías unmanaged a managed code?
ResponderEliminarPuff, da igual, haga lo que haga creo que me hubiese venido de perlas en más de una ocasión en las que he tenido que lidiar con código del 500 a.c. y con tipos de datos más raros que un perro verde.
Ésta es de taggear, tanto tu entrada como el proyecto de Codeplex ;-).
¡SaludoX crack!
¡Muy buenas tocayo!
ResponderEliminarLa herramienta lo que hace es crear, como decías en primer lugar, una especie de "proxy" que interactúa entre el código manejado y el nativo, facilitando el marshalling ya que, de otra forma, deberíamos programar a mano toda la conversión de la interfaz entre los componentes (sustitución de tipos, firma de los métodos...). Es más, llega a hacerlo en los dos sentidos (de código no manejado a manejado y viceversa). La DLL original sigue siendo así necesaria, pero su uso es un poco más "racional", desde el punto y hora en que nos evitamos recordar: ¿qué tipo era XXX en C? ¿y en el CLS de .NET? evitando así numerosas consultas a la increíble PInvoke.net.
Eso sí, no funciona con código C++ (al menos, con código C++ con clases y demás, posiblemente sí si usamos C++ al modo C de toda la vida, pero a saber un componente antiguo cómo lo han montado), pero viene a ser útil en cualquier caso en bastantes ocasiones.
Su publicación coincidió con la del artículo Marshaling between Managed and Unmanaged Code de la MSDN de Enero del pasado año, así que en el mismo puede encontrarse información de cómo trabaja.
Pues nada, a disfrutarlo, y gracias por la recomendación de "taggeo". A ver si este fin de semana aprovecho e investigo eso :)
¡Saludos, y buen fin de semana campeón!