¿Cómo manejar la interacción del proyecto C# - C++ de la manera correcta?

Question

Estoy realmente en la necesidad de obtener una comprensión más profunda de cómo configurar las cosas correctamente para obtener una interacción elegante entre mis bases de código C++ y C#. Lo que quiero lograr es un editor en el juego escrito en C# para mi motor de juegos (C++/DX). Para hacerlo, dejé que VS creara mi motor como un dll C++ con algunas funciones adicionales (código no administrado) para acceder a la funcionalidad requerida de mi motor desde la base de código del editor C#. Hasta aquí todo bien.

Lo primero que me molesta es que tengo que construir el dll con soporte CLR. De lo contrario, C# no acepta el dll por algún motivo. Ni siquiera me permite agregarlo a los recursos ("No se pudo agregar una referencia a 'C: \ Users ... \ frame_work \ Test \ frame_workd.dll'. Asegúrese de que el archivo esté accesible, y que es un ensamblado válido o un componente COM ").

Y cuando construyo el dll con soporte CLR y lo agrego a las referencias en C#, reconstruyo sin soporte CLR, inicio mi editor y realizo una llamada de función desde el dll luego obtengo una excepción HRESULT: 0x8007007E. Lo busqué, pero lo único que encontré tenía que ver con las dependencias, pero eso no se ajusta a la alerta que recibo cuando agrego el dll a los recursos.

El otro punto es que siempre tengo que cambiar el tipo de configuración entre la aplicación (.exe) y dll. en VS C++ dependiendo de si quiero ejecutar mi motor directamente o desde el editor y cada vez que el proyecto completo es completamente nuevo.

Entonces, ¿podría alguien explicarme cómo organizar esto de la manera correcta? ¿Y cuál podría ser una posible razón por la cual C# quiere que el dll sea compilado con soporte CLR?

Gracias chicos/chicas.

Answer 1

Hay dos formas de solucionar esto.

O bien haces que tu código C++ proporcione una API que tenga un objeto COM totalmente compatible. Si el objeto es COM, entonces C# puede interoperar directamente con él. (Esta es la razón por la que no puede agregarlo como referencia directamente)

Sin embargo, creo que lo que realmente desea hacer involucrará un P/Invoke (llamando al código nativo C/C++ desde C#). Esto es completamente posible, pero no siempre es fácil. Debe tratar las conversiones entre su API C++ y su C#, punteros y debe tener mucho cuidado de anotar cualquier referencia a la que escriba su código C++ en la aplicación C#.

Answer 2

El código de C# es código administrado (se ejecuta en el CLR) y solo puede directamente ^* conjuntos gestionados de referencia. Por lo tanto, desde el curso , se genera un error cuando compila contra un ensamblado administrado, y luego se infiltra y reemplaza esa DLL administrada con una DLL no administrada (incompatible). Básicamente, estás tratando de mentirle al compilador, y eso generalmente no termina bien.

Si desea que su C++ DLL sea accesible desde C#, la forma más sencilla de hacerlo es compilarlo como un ensamblado administrado (es decir, compatibilidad con CLR). Lo que estás haciendo es . Simplemente elimine el paso adicional en el que reemplaza la DLL administrada que funciona con una no administrada que no funciona.

también:

DLL

C++ con algunas funciones adicionales (código no administrado) para acceder a la funcionalidad requerida de mi motor de la C# editor

Eso no le ayudará, porque C# puede 't directamente ^* llamar código no administrado. La forma más sencilla de hacer que esto funcione es hacer que administrado clases y métodos adicionales en su C++ DLL. Entonces su ensamblado C# podrá usar directamente esas clases administradas.

^* Como Spence noted, puede utilizar -indirect- medios (P/Invoke y COM) para tener acceso a código no administrado desde C#. Pero eso hará que su vida sea mucho más complicada de lo que es ahora, sin mencionar cómo complicará su construcción y despliegue. Ya estás cerca de algo que debería funcionar: no agregues toda esa complejidad extra.

Answer 3

Al llamar a las funciones con P/Invoke, no agrega la DLL a los recursos del proyecto C# (o lo que probablemente quiso decir, referencias, tampoco).

Lo agregará a la lista de archivos en su proyecto de MSI, por supuesto.