¿Por qué los desarrolladores .NET ofrecen versiones de 32 bits/64 bits de ensamblados .NET?

Question

Evey de vez en cuando veo las versiones x86 y x64 de un ensamblado .NET. Considere lo siguiente web part for SharePoint. ¿Por qué el desarrollador no debería ofrecer una sola versión y dejar que el compilador JIT se encargue del resto? Cuando veo este tipo de ofertas, ¿es solo que el desarrollador decidió crear una imagen nativa usando una herramienta como ngen para evitar un JIT?

Alguien ayúdeme por favor aquí, siento que me falta algo de importancia.

Actualizado

De lo que tengo a continuación, x86 y x64 construye se ofrecen debido a una o más de las siguientes razones:

1. El desarrollador quería evitar JITing y creó un nativo imagen de su código, apuntando a una arquitectura determinada usando una herramienta como ngen.exe.

2. El ensamblado contiene llamadas COM específicas de la plataforma, por lo que no tiene sentido construirlo como AnyCPU. En estos casos, las compilaciones que se dirigen a diferentes plataformas pueden contener códigos diferentes.

3. El ensamblaje puede contener llamadas Win32 utilizando pinvoke que no será reasignado por un JIT y por lo tanto la compilación debe apuntar a la plataforma a la que está vinculado.

Answer 1

Si utilizan una API específica que no es .Net, entonces puede haber dos bases de código para esto, un ejemplo perfecto son los controles COM.

ngen es otra muy buena razón para esto como usted mencionó.

Answer 2

Cuando compila una aplicación .net, debe elegir un objetivo de plataforma en la configuración de compilación. Las opciones son AnyCPU, x86 y x64.

Un error común es especificar AnyCPU en un proyecto que incluye archivos DLL nativos compilados para x86. Esto dará lugar a errores cuando se ejecute en máquinas de 64 bits, una buena razón para probar en una máquina de 64 bits.

Por lo tanto, para ayudar a las personas que se ven obligadas por sus otras dependencias a compilar directamente para x86 o x64, el ensamblado ofrece ambas.

Answer 3

COM maneja la clasificación y eliminación de límites de 32/64 bits. Sin embargo, no proporciona ningún soporte para cargar el tipo alternativo de binario en el ancho de puntero incorrecto del apartamento.

Muchos ensambles se basan en código nativo (la mayoría de los controladores SQL están escritos en C o C++, por ejemplo). Esto es increíblemente evidente para cualquier cosa que use p/invoke; por lo tanto, tener diferentes anchos de puntero compilados y distribuidos significa que el paquete para la versión de 64 bits probablemente contenga archivos DLL nativos de 64 bits, y la versión de 32 bits probablemente contenga archivos DLL nativos de 32 bits. Este es el caso incluso si las versiones de 32 y 64 bits del conjunto se compilan a partir del mismo código.

csc producirá las imágenes nativas (pre-JITted) si así lo solicita.