Puedo construir mi proyecto C# para x86 y para x64. ¿Por qué? Pensé que genera un código especial que no es específico de la plataforma en absoluto.por qué los ensamblados .net difieren para diferentes arquitecturas?
En primer lugar, permítanme ser franco y decir que no conozco toda la historia aquí, voy a responder con lo que creo saber. Con gusto borraré o cambiaré mi respuesta si alguien me puede decir dónde estoy equivocado.
De la forma en que lo entiendo, esta configuración es una bandera que dice "se supone que el ensamblado se ejecuta en este tipo de arquitectura". Eso es para la configuración x86 y x64. La configuración de MSIL/.NET solo dice: "No me importa, puedo ejecutar cualquiera de los dos, así que elija el que sea óptimo o esté disponible".
Por ejemplo, es posible que realice llamadas a las funciones de API de Win32 a través de P/Invoke, en cuyo caso el ensamblado no funcionará en x64 y deberá marcarlo como x86.
Así que si he entendido bien, así es como las tres banderas hacen la carrera de montaje (nota, es el conjunto principal, el conjunto de programas, que dicta esto, no cada montaje individual por sí mismos) en diferentes plataformas:
Setting x86 x64 <-- Platform (CPU/OS)
MSIL/.NET 32-bit 64-bit
x86 32-bit 32-bit
x64 N/A (*) 64-bit
El N/A para x64 ensamblado en x86 significa que el ensamblaje no se cargará, y obtendrá una excepción si lo intenta.
También tenga en cuenta que las configuraciones conflictivas que involucran a x86 y x64 harán que su programa falle en un punto u otro. Si el ensamblaje principal está configurado en x86, se ejecutará como un proceso de 32 bits en un sistema operativo de 32 bits y de 64 bits, y cualquier intento de cargar ensamblajes marcados como x64 fallará. Del mismo modo, si el ensamblaje principal está configurado a x64, solo se ejecutará en el sistema operativo de 64 bits y cualquier intento de cargar un conjunto de ensamblaje en x86 fallará.
Un ensamblado ejecutable principal MSIL se ejecutará como 32 bits en un sistema operativo de 32 bits (como si estuviera configurado en x86, con el punto de falla anterior) y como 64 bits en un sistema operativo de 64 bits (como si estuviera en x64, con el punto de falla anterior.)
Obviamente
Normalmente, desea ir con la configuración de MSIL si no está llamando a los conjuntos que están marcados como algo específico, y siempre ya que no está haciendo P/Invoke que no es portátil en 32 bits y 64 bits (no tengo idea si esto funciona, si las funciones P/Invoke to win-api se correlacionarán con una dll con bits correctamente colocada o no).)
Desde la referencia s son punteros, y los punteros se almacenan como una dirección nativa de x bits en las dos plataformas, dependiendo de la cantidad de referencias que tenga, usted podría tener un caso en contra de simplemente ir con MSIL. Sin embargo, debe verificar que esto sea un problema antes de realizar un cambio en su configuración.
Esa marca es importante para los archivos EXE. Decide si se ejecuta en un proceso de 32 o 64 bits. Si utiliza archivos DLL "nativos" de su código .NET, debe seguir la arquitectura de esos archivos DLL.
La "Cualquier CPU" en archivos EXE elegirá x64 si está disponible.
Creo que la razón por la que hay diferentes objetivos se debe al tamaño de los tipos escalares. Creo que también afecta la forma en que se manejan los objetos COM.
Tengo una situación en la que tengo una biblioteca .NET de terceros que si se utiliza dentro de una aplicación de 64 bits el programa falla al llamar a la biblioteca, por lo que tengo que restringirme al modo de solo 32 bits.
Primero, establecer Platform Target en x86 en su proyecto .exe es muy útil cuando depura su proyecto en una versión de Windows de 64 bits. El depurador VS2005/8 no admite Editar + Continuar en el código de 64 bits.
Elegir x86 en la versión de lanzamiento es algo que debe hacer si el programa tiene una dependencia en un componente que solo funciona en código de 32 bits. No es infrecuente, hay toneladas de componentes COM que nunca tuvieron y nunca serán portados a un código no administrado de 64 bits. Un ejemplo clásico es el motor de base de datos Microsoft Jet.
Elegir x64 es muy inusual, no hay mucho código no administrado que solo está disponible en la versión de 64 bits. Es notable que recibirá advertencias cuando construya su ensamblaje; existen varios ensamblados de .NET framework que contienen código no administrado; solo las versiones de 32 bits están disponibles en c: \ windows \ microsoft.net. Puede ignorar esas advertencias de forma segura, las versiones de 64 bits están realmente instaladas en el GAC.
Una arruga al seleccionar x64 es que el compilador C# 3.0 emitirá un binario que le pide a Windows que cree el subproceso de inicio con un tamaño de pila de 4 megabytes, en lugar del predeterminado de 1 megabyte. Eso está algo justificado, el código de 64 bits necesita más pila para almacenar punteros y devolver direcciones.
Finalmente, el SDK de Windows tiene la herramienta Corflags.exe disponible para cambiar la bit-ness de un ensamblado una vez que está construido. La opción/32BIT + es equivalente a establecer Target Platform en x86. El uso de/32BIT- asegura que el ensamblaje se ejecutará en modo de 64 bits en un sistema operativo de 64 bits. Es posible cambiar el tamaño de pila predeterminado con la herramienta Editbin.exe.
int es Int32 y no cambia según esta configuración. IntPtr tiene 4 bytes cuando ejecuta 32 bits y 8 bytes cuando ejecuta 64 bits. –