Utilizar servidores COM nativos de .NET
Actualización: noviembre 2007
Esta sección describe las opciones disponibles para utilizar los componentes COM existentes de las aplicaciones de .NET, y esquematiza las ventajas y desventajas de cada enfoque. Generalmente, el método recomendado es Interoperabilidad de C++.
Utilizar TLBIMP
Importador de la biblioteca de tipos (TlbImp.exe) de Kit de desarrollo de software de Windows (SDK) es una herramienta que expone una biblioteca de tipos COM como un ensamblado llamado ensamblado de interoperabilidad. Este ensamblado define los equivalentes administrados, o contenedores, para cada interfaz COM en una biblioteca de tipos determinada.
Cuando se llama a los métodos de ensamblado de interoperabilidad, se ejecuta una transición de administrado a no administrado y el control pasa al componente COM. Igualmente, cuando se devuelve la función COM no administrada, se ejecuta una transición de no administrado a administrado. De forma predeterminada, se comprueba que no haya errores en HRESULT de COM y se inicia una excepción si HRESULT no es correcto. El ensamblado de interoperabilidad realiza de igual forma la inicialización de componentes COM y las consultas de interfaz, y por consiguiente las oculta del código de llamada.
Los ensamblados de interoperabilidad no reemplazan a los componentes COM que representan; las funciones COM no administradas siguen en el componente COM, por lo que el componente debe estar instalado en los equipos de destino o las llamadas al ensamblado de interoperabilidad producirán errores.
Utilizar Tlbimp es el modo más fácil de utilizar un componente COM del código administrado pero existen algunas desventajas serias, especialmente para las interfaces COM grandes o complejas. Estas desventajas son las siguientes:
Tlbimp genera interfaces administradas para cada interfaz COM en la biblioteca de tipos. No hay ninguna manera de suprimir este comportamiento, por lo que los ensamblados resultantes pueden ser muy grandes. (Por ejemplo, el ensamblado de interoperabilidad generado por Tlbimp para Mshtml.dll ocupa más de 8 MB.) No hay también ninguna manera de ocultar una interfaz que sólo sirve para el uso dentro del componente COM.
Tlbimp admite un número limitado de tipos de datos. Los tipos no admitidos normalmente se importan al mundo administrado como tipos IntPtr genéricos sin seguridad de tipos, y requieren un código propenso a errores y con un cálculo de referencias tedioso para utilizar el ensamblado pero a veces Tlbimp.exe no puede exponer en absoluto miembros de una interfaz.
Tlbimp genera un ensamblado de interoperabilidad independiente que se debe implementar con la aplicación final.
Si estas desventajas son aceptables, vea Cómo: Utilizar Servidores COM nativos con TLBIMP para obtener un ejemplo.
Modificar MSIL
Se pueden mitigar algo las desventajas de Tlbimp desensamblando el ensamblado de interoperabilidad, mediante Desensamblador de MSIL (Ildasm.exe), editando MSIL para quitar las definiciones de interfaz innecesarias y reemplazar tipos de argumento, y ensamblando de nuevo MSIL mediante Ensamblador de MSIL (Ilasm.exe). Este proceso es propenso a errores y requiere conocimiento de MSIL, tipos no administrados y tipos de .NET. Además, esto se tiene que rehacer si se actualizan las interfaces COM.
Interoperabilidad de C++
Se pueden evitar las desventajas de Tlbimp, y de editar MSIL, por completo en Visual C++ porque, a diferencia de Visual Basic y C#, Visual C++ puede utilizar objetos COM directamente usando los mecanismos de COM habituales (como CoCreateInstance y QueryInterface). Esto es posible debido a las características de interoperabilidad de C++ que hacen que el compilador inserte automáticamente el código de transición para desplazarse de las funciones administradas a las no administradas y viceversa.
Con la interoperabilidad de C++, se pueden utilizar componentes COM tal como se usan normalmente o se pueden ajustar dentro de las clases de C++. Estas clases contenedoras se denominan contenedores personalizados que se pueden llamar en tiempo de ejecución o CRCW (custom runtime callable wrappers) y tienen dos ventajas en comparación con el uso de COM directamente en el código de aplicación:
La clase resultante se puede utilizar en lenguajes distintos de Visual C++.
Los detalles de la interfaz COM se pueden ocultar del código de cliente administrado. Se pueden utilizar tipos de datos de .NET en lugar de tipos nativos y es posible ejecutar los detalles de cálculo de referencias de datos de forma transparente dentro de CRCW.
El uso de Visual C++ para ajustar las interfaces COM se muestra en Cómo: Utilizar Servidores COM nativos con CRCWs.
Independientemente de si se utiliza COM directamente o a través de CRCW, se deben calcular las referencias de los tipos de argumento que no sean los de los tipos sencillos y representables como bits o bytes. Para obtener información sobre el cálculo de referencias de datos, vea Utilizar la interoperabilidad de C++ (PInvoke implícito).
.gif "Nota") Nota: |
|---|
Se deben inicializar las aplicaciones MFC como apartamento de un único subproceso (STA, single threaded apartment). Si llama a CoInitializeEx en el reemplazo de InitInstance, especifique COINIT_APARTMENTTHREADED (en lugar de COINIT_MULTITHREADED). Para obtener más información, vea PRB: MFC Application Stops Responding When You Initialize the Application as a Multithreaded Apartment (828643) en https://support.microsoft.com/default.aspx?scid=kb;en-us;828643. |