Mi aplicación no está administrada. ¿Dónde empiezo a presentar el código administrado?

Question

Toda mi aplicación (que es bastante grande, con un ejecutable de 20 MB) está escrita en C ++ no administrado. Debido a que puedo ver claramente las ventajas en el uso del código administrado, quiero comenzar a presentar el código administrado en mi aplicación, pero ¿por dónde empiezo?

¿Puedo comenzar fácilmente a usar C ++/CLI y vincularlo con el resto de mi aplicación? (Aunque la sintaxis C ++/CLI parece bastante 'exótica').

¿O es mejor moverse a C#, pero cuál es la mejor manera de 'vincular' esto junto con mi código C ++ no administrado?

¿Tiene sentido compilar todo mi código C ++ con la opción /CLR? esto funcionara?

¿Tengo que preocuparme por mariscal? ¿Esto le da una sobrecarga o puedo cambiar entre administrado y sin administrar sin una penalización de rendimiento (tal como lo hice hace 20 años al mezclar Fortran y C)? El rendimiento es realmente importante en mi aplicación, ya que es una aplicación científica que a veces procesa varios gigabytes de memoria.

¿O solo tiene sentido rediseñar la interfaz de usuario, y solo escribir esto en C#y mantener el resto de mi aplicación (lógica de cálculo, lógica de negocios, interfaz de base de datos, ...) en C ++ sin administrar?

Dado que mi aplicación a veces necesita manejar varios gigabytes de memoria, tengo una variante de 64 bits. ¿Es fácil tener un código administrado de 64 bits? ¿El recolector de basura sigue siendo eficiente si se usa tanta memoria?

Simplemente indique: ¿por dónde empiezo?

Patricio

Answer 1

Por el momento, considere esta pregunta cerrada.

Me di cuenta de que la respuesta no es mezclar C ++ y C#, sino obtener la arquitectura en primer lugar.

Si la arquitectura es correcta y se separa donde debe separarse, ya que cambiar partes de la aplicación por otros módulos (externos, otro idioma, ...) debería ser más fácil.

Con respecto a los problemas de rendimiento durante el mariscal, tendremos que esperar hasta que .NET haya madurado aún más.

Answer 2

Perfente la aplicación, decida en qué puntos de integración puede romper la línea de lógica C# y dividir en C ++ y viceversa. Organice estos en un plan para que un patrón de diseño de fachada se mueva a través del sistema reemplazando gradualmente a C ++ con C#. La preocupación clave es la CPU y el costo de la memoria al decidir cambiar los idiomas en cada fachada / interfaz candidata.

Deberá poder incorporar ediciones para que sea mejor apagado con un conjunto de código fuente y repositorio de código fuente para el código C ++ original y otro conjunto y repositorio para la fachada más la C#.

Luego, a medida que el trabajo de mejoras/mantenimiento viene en la bandeja, lo aplica a ambas bases de código, e intenta asegurarse de que la fachada se mueva a través del sistema que comienza con el código menos probable que cambie en mejoras o mantenimiento para minimizar la duplicación de los cambios funcionan .

También idealmente estructura tu trabajo para que puedas revertir la fachada para regresar al 100% C ++ en la caída de un sombrero si golpeas un enganche.

Para probar si un par de módulos C ++ particularmente inescrutables se pueden separar en una pieza de C ++ y una pieza de C#, ejecutarlos en dos procesos Win32 C ++ diferentes que se comunican con una tubería o un zócalo. De esa manera, tendrá una mejor idea de si hay problemas con la gestión de la memoria o el rendimiento que necesitan arreglar antes de que pueda dividir la cadena de llamadas en ese punto.

Answer 3

Hacemos exactamente lo que describió en una aplicación de misión crítica que usa miles de usuarios. Básicamente, mantuvimos la aplicación existente tal como está, por lo que el ejecutable sigue siendo un ejecutable 100% no administrado (no C ++/CLI). Luego colocamos todo nuestro nuevo código C# en DLLS .NET que consiste en objetos comerciales, controles de usuario y código GUI, etc. ....

Básicamente, todo el código nuevo está escrito en C#. Tenemos 1 DLL que es C ++/CLI que es solo pegamento. Esto nos permite introducir fácilmente entre el código administrado y no administrado, sin tener que hacer el código C ++ existente CLR. Esto limita la cantidad de código C ++/CLI que tenemos que escribir. El código nativo habla con el código de modo mixto, que puede hablar con el código administrado. El modo mixto DLL puede enganchar eventos en las clases de C# para que el código C# pueda disparar el evento para comunicarse con el C ++/CLI (que puede hablar con el código nativo).

También podemos alojar .NET UserControls en una aplicación C ++ existente (WinForms es solo un envoltorio alrededor del Winapi de todos modos, por lo que funciona bastante bien).

Esto funciona muy bien y le permite mantener su código existente sin tener que reescribir toda la GUI en C#.