2009-07-01 11 views
15

Según tengo entendido, puedo usar P/Invoke inversa para llamar C# desde C++. Invertir P/Invocar es simplemente un caso de:Llamando a C# desde C++, Invertir P/invocar, DLLs de modo mixto y C++/CLI

  1. Cree su clase administrada (C#).
  2. Cree un proyecto de biblioteca de clases C++/cli (anteriormente administrado C++). Use esto para llamar a la clase C# administrada (presumiblemente a través de una referencia).
  3. Llame al código C++/cli desde C++ nativo.

Preguntas:

  1. es así?
  2. ¿La DLL creada en el paso 2 se conoce como DLL de modo mixto?
  3. ¿C++/CLI ha reemplazado por completo a C++ administrado en lo que respecta a MS?
  4. ¿Se evita por completo COM con este enfoque?
  5. ¿En qué punto se crearía y ejecutaría el CLR, y por quién?

Gracias de antemano

+1

Al hacer esto, encontrará la clase de plantilla gcroot <> útil. –

Respuesta

20

Aquí están las respuestas a lo mejor de mi conocimiento:

  1. Sí, es una DLL de modo mixto (De hecho, usted puede hacer uno archivo de su proyecto C++ nativo administrado y cree esta clase C++/CLI en ese archivo y llame al código directamente desde ese archivo. Ni siquiera necesita una DLL separada para lograr esto.
  2. C++/CLI y Managed C++ ambos representan mismo t Hing. La única diferencia es que en la versión anterior hasta Visual Studio 2003, se denominó Managed C++. Más tarde, la sintaxis se cambió bastante y se renombró como C++/CLI. Eche un vistazo a this link para más detalles.
  3. CLR se utilizará siempre que se realice una llamada a la DLL administrada.
+1

Podría hacer con un botón +10 - gracias. – ng5000

+0

¿Es realista esperar tomar una biblioteca Win32 C++ existente y volver a compilar usando C++/CLI? – ng5000

+2

no realmente ... C++/CLI es un idioma diferente y C++ con CLR encendido es diferente. Si desea hacer esto con CLR activado en un proyecto de Visual C++, puede hacerlo, pero puede haber problemas durante la compilación.Dependerá de la implementación de esa biblioteca específica. – Aamir

2

Nota, también puede hacer una ida y vuelta de la C# dll y exportar métodos estáticos, que funcionan básicamente igual que las exportaciones en C++/CLI. Sin embargo, este es siempre un paso posterior a la compilación, y tiene some caveats (que también tiene su exportación C++/CLI, por cierto).

Puede ILDASM las DLL C# y C++/CLI para ver cómo se exportan; es algo como esto (de a sample on the net):

// unmexports.il 
// Compile with : ilasm unmexports.il /dll 
assembly extern mscorlib {} 
..assembly UnmExports {} 
..module UnmExports.dll 
// This flag is important 
..corflags 0x00000002 
// This instructs the CLR to create a marshaling thunk for the unmanaged caller 
..vtfixup [1] int32 fromunmanaged at VT_01 
..data VT_01 = int32(0) 
..method public static void foo() 
{ 
..vtentry 1:1 
..export [1] as foo 
ldstr "Hello from managed world" 
call void [mscorlib]System.Console::WriteLine(string) 
ret 
} 
1

Con ilasm 2.0 se necesita menos código, ya que puede generar la mayor parte de la suciedad por sí mismo. Solo la directiva .export es realmente necesaria ahora.

// unmexports.il 
// Compile with : ilasm unmexports.il /dll 
.assembly extern mscorlib { auto } 
.assembly UnmExports {} 
.module UnmExports.dll 
.method public static void foo() 
{ 
    .export [1] as foo 
    ldstr "Hello from managed world" 
    call void [mscorlib]System.Console::WriteLine(string) 
    ret 
}