AnyCPU/x86/x64 para la aplicación C#y su dependencia de C++/CLI

windows 64-bit

Question

Soy desarrollador de Windows, estoy usando Microsoft Visual Studio 2008 SP1. Mi máquina reveladora es de 64 bits.

El software en el que estoy trabajando actualmente está administrado .exe escrito en C #. Desafortunadamente, no pude resolver todo el problema únicamente en C #. Es por eso que también desarrollé una pequeña DLL administrada en C ++ / CLI. Ambos proyectos están en la misma solución.

Mi objetivo de compilación de C # .exe es "Cualquier CPU". Cuando mi objetivo de compilación de DLL de C ++ es "x86", la DLL no se carga. Por lo que entendí cuando busqué en Google, la razón es el lenguaje C ++ / CLI, a diferencia de otros lenguajes .NET, se compila en el código nativo, no en el código administrado.

Cambié el objetivo de compilación de DLL de C ++ a x64, y todo funciona ahora. Sin embargo, AFAIK todo dejará de funcionar tan pronto como mi cliente instale mi producto en un sistema operativo de 32 bits. Tengo que admitir Windows Vista y 7, versiones de 32 y 64 bits de cada uno de ellos.

No quiero volver a 32 bits. Esas 250 líneas de código C ++ en mi DLL son solo el 2% de mi código base. Y esa DLL solo se usa en varios lugares, por lo que en el escenario de uso típico ni siquiera se carga.

Mi DLL implementa dos objetos COM con ATL, por lo que no puedo usar la configuración del proyecto " /clr:safe ".

¿Hay alguna forma de configurar la solución y los proyectos para que el proyecto C # genere la versión "Cualquier CPU", el proyecto C ++ genere versiones de 32 y 64 bits, luego en el tiempo de ejecución cuando el .EXE administrado se está iniciando, usa cualquiera de los 32 DLL de bits o DLL de 64 bits dependiendo del sistema operativo?

¿O tal vez hay una solución mejor que no conozco?

¡Gracias por adelantado!

Answer 1

Hay una manera: tener una envoltura C # "AnyCPU" y un proyecto C ++ por arquitectura, y dejar que la envoltura C # cargue el proyecto C ++ correcto en el tiempo de ejecución.

Para el proyecto C ++, cree una versión por arquitectura diferente (x86, x64) y compílelas todas. Luego en el envoltorio hacer:

public class CppWrapper
{
// C++ calls that will be dynamically loaded from proper architecture:
public static readonly Func<long> MyCplusplusMethodUsableFromCsharpSpace;
// Initialization:
static CppWrapper()
{
if(Environment.Is64BitProcess)
{
MyCplusplusMethodUsableFromCsharpSpace = CppReferences64.MyCplusplusClass.Method;
// Add your 64-bits entry points here...
}
else
{
MyCplusplusMethodUsableFromCsharpSpace = CppReferences32.MyCplusplusClass.Method;
/* Initialize new 32-bits references here... */
}
}
// Following classes trigger dynamic loading of the referenced C++ code
private static class CppReferences64
{
public static readonly Func<long> MyCplusplusMethod = Cpp64.MyCplusplusMethod;
/* Add any64-bits references here... */
}
private static class CppReferences32
{
public static readonly Func<long> MyCplusplusMethod = Cpp32.MyCplusplusMethod;
/* Add any 32-bits references here... */
}
}

Y en el código C ++, uso las mismas fuentes que dije, pero compilaré en diferentes espacios de nombres dependiendo de la arquitectura de compilación :

#ifdef _M_X64
namespace Cpp64 {
#else
namespace Cpp32 {
#endif
public ref class MyCPlusPlusClass
{
public: static __int64 Method(void) { return 123; }
};
}

Answer 2

No hay una manera fácil de evitarlo. Si tiene código nativo (es decir, su C ++) y necesita compatibilidad con x86, debe compilar x86 (a menos que quiera trabajar en el mundo WOW ... es decir, ejecutar código de 32 bits en entornos de 32 y 64 bits). Puede tener distribuciones tanto de x86 como de x64, pero si soporta 32 y 64 bits, y tiene código nativo o introp COM, entonces debe tener binarios de 32 y 64 bits. "Cualquier CPU" solo es realmente útil cuando no hay código nativo o interoperabilidad, entonces obtienes ese beneficio.