C ++ COM C# Interoperación en modo mixto

Question

Estoy tratando de entender mis opciones para llamar a una implementación de la biblioteca C# de C ++ no administrado.

Mi módulo de nivel superior es una DLL C ++ COM/ATL no administrado. Me gustaría integrar la funcionalidad de una C# DLL administrada existente. Tengo, y puedo recompilar la fuente de ambas bibliotecas.

Entiendo de leer artículos como esta descripción general en msdn y esta pregunta que podría ser posible crear una DLL de "modo mixto" que permita que el código C ++ nativo llame a la biblioteca C#.

Tengo un par de preguntas sobre este enfoque:

1. ¿Cómo hago para configurar esto? ¿Puedo simplemente cambiar algunas propiedades en el proyecto COM/ATL existente para permitir el uso de los módulos C#?
2. ¿Cómo diferirán estas llamadas de modo mixto en el rendimiento de las llamadas de interop? ¿Existe un formato de cadena común que pueda usarse para evitar la conversión o copias profundas entre los módulos?
3. Si esta DLL se crea en modo mixto, ¿puede ser interactuado/utilizado de la misma manera por sus clientes de COM, o necesitan estar conscientes de modo mixto?
4. ¿La inclusión del CLR impondrá una sobrecarga sustancial al cargar este objeto COM?

Soy nuevo en el desarrollo de Windows, así que por favor comente si hay algo en la declaración de preguntas que necesita aclaración o corrección.

Gracias por adelantado.

Answer 1

¿Cómo hago para configurar esto? ¿Puedo simplemente cambiar algunas propiedades en el proyecto COM/ATL existente para permitir el uso de los módulos C#?

Si controla completamente ese proyecto, por lo que cambiar dicha configuración no es un problema, entonces seguro. Todo lo que necesitas es habilitar /clr Para este proyecto (en las propiedades del proyecto, abra la página "General" y busque soporte de "tiempo de ejecución del idioma común"). Ahora puede usar manijas administradas (^) y otros bits C ++/CLI en su proyecto según sea necesario. Todo el código existente escrito en C ++ simple debería seguir funcionando (ahora se compilará a MSIL, en la medida de lo posible, pero su semántica permanecerá sin cambios).

¿Cómo diferirán estas llamadas de modo mixto en el rendimiento de las llamadas de interop? ¿Existe un formato de cadena común que pueda usarse para evitar la conversión o copias profundas entre los módulos?

Una llamada de modo mixto será más rápido, porque utiliza convenciones de llamadas más rápidas y no realiza ningún ensangrado como lo hace COM Inerop (usa tipos inherentemente compatibles o realizan sus propias conversiones explícitas).

No hay formato de cadena común: el problema es que System::String Ambos asignan y posee su amortiguador, y también requiere que sea inmutable; Entonces no puedes crear un búfer tú mismo y luego envolverlo como String, o crear un String y luego úselo como un búfer para emitir texto.

Si esta DLL se crea en modo mixto, ¿puede ser interactuado/utilizado de la misma manera por sus clientes de COM, o necesitan estar conscientes de modo mixto?

Se puede interconectar igual, pero si se ingresa a través de un punto de entrada nativo, intentará cargar el CLR en el proceso, a menos que uno ya esté cargado. Si el cliente de llamadas ya había cargado CLR antes de la llamada (o el cliente se llamaba desde el código administrado), obtendrá el CLR que ya está cargado, que puede ser diferente del CLR que requiere su código (por ejemplo, Cliente puede haber cargado 1.1 y su código necesita 2.0).

¿La inclusión del CLR impondrá una sobrecarga sustancial al cargar este objeto COM?

Depende de lo que defina por encima. Tamaño del código? ¿Sanciones en tiempo de ejecución? Huella de memoria?

En cualquier caso, cargar el CLR significa que obtienes toda la maquinaria GC y JIT. Esos no son baratos. Dicho esto, si necesita llamar al código administrado en última instancia de todos modos, no hay forma de evitar esto, lo hará tener Cargar CLR en algún proceso para hacer esto. Las penalizaciones no van a diferir entre los ensamblados COM C ++/CLI de modo mixto.

Answer 2

No puedo decir mucho sobre los detalles como, por ejemplo, los problemas de la cadena, ya que nunca usé activamente este enfoque.

Pero puede consumir fácilmente cualquier interfaz COM de cualquier código C# simplemente dejando que un asistente VS cree un proxy para usted, no hay una sobrecarga de rendimiento, excepto la que siempre tiene al invocar com y .net.

La otra dirección, solo tienes que configurar tus conjuntos de C# ' ComVisibleAttribute a verdadero (en VS es una casilla de verificación simple en las propiedades del proyecto), y luego el compilador creará automáticamente interfaces COM para usted. Nuevamente, no hay una penalización de rendimiento adicional.

¡Hth!