Probablemente la mejor manera de ir aquí es el uso de P/Invoke o invocación de plataforma. Dependiendo de la estructura o su interfaz C++ dll, es posible que desee envolverlo en una interfaz C pura; es más fácil si su interfaz solo usa tipos blittable. Si limita su interfaz dll a tipos blittables (Int32, Single, Boolean, Int32 [], Single [], Double [] - los conceptos básicos) no necesitará hacer una compleja recopilación de datos entre managed (C#) y no administrados (C) espacios de memoria.
Por ejemplo, en su código C# define las llamadas disponibles en su dll C/C++ utilizando el atributo DllImport.
[DllImport, "ExactDllName.dll"]
static extern boolean OneOfMyCoolCRoutines([In] Double[] x, [In] Double[] y, [Out] Double result)
La pequeña [A] 's y [Fuera]' s no son estrictamente necesarias, pero pueden acelerar el proceso. Ahora que ha agregado su "ExactDllName.dll" como referencia para su proyecto C#, puede llamar a su función C/C++ desde su código C#.
fixed(Double *x = &x[0], *y = &y[0])
{
Boolean returnValue = OneOfMyCoolCRoutines(x, y, r);
}
Tenga en cuenta que esencialmente estoy pasando punteros hacia atrás y cuarto entre mi dll y el código C#. Eso puede causar errores de memoria porque el colector de basura CLR puede cambiar las ubicaciones de esas matrices, pero el dll de C/C++ no sabrá nada al respecto. Así que para protegerme de eso, simplemente arreglé esos punteros en mi C#, y ahora no se moverán en la memoria mientras mi dll esté operando en esas matrices. Este es ahora un código inseguro y tendré que compilar mi código C# con esa bandera.
Hay muchos detalles finos en la interoperabilidad del lenguaje, pero eso debería hacerlo funcionar. Mantener una interfaz C sin estado de tipos blittables es una gran política si es posible. Eso mantendrá su código de interoperabilidad del idioma más limpio.
Buena suerte,
Paul
¿Ha considerado la adición de una interfaz COM? Dado que, en mi humilde opinión, pasar los argumentos y los datos del programa con contenedores COM puede ser una solución. –