.net - sp1 - net framework 4 full español x86 x64

¿Hay alguna consideración que deba tomarse al ejecutar su programa.net en x64 vs x86?

Question

Creo que el tipo de arquitectura (x86 frente a x64) se abstrae para usted al crear programas .Net, pero ¿hay alguna otra consideración que pueda causar problemas?

Answer 1

Este artículo tiene muchos problemas importantes que debe tener en cuenta: http://osnews.com/story/20330/Windows_x64_Watch_List

Personalmente, mi jefe tiene una computadora Vista de 64 bits y yo programo en un modo de 32 bits. Nos encontramos con los siguientes problemas:

• El registro para aplicaciones de 32 bits se oculta (más o menos) en una carpeta Wow6432Node. No todas las aplicaciones a las que está acostumbrado a encontrar una ruta en el registro estarán en ese nodo (SQL Server no lo hará, por ejemplo).

• SysWow64 en la carpeta C: / Windows puede causar que los DLL no estén donde se necesitan (tuvimos este problema con un componente de licencia de terceros).

• A veces, los archivos que necesita están en "C: / Archivos de programa (x86)", en lugar de "C: / Archivos de programa". Apesta también.

Answer 2

Tenga cuidado con las bibliotecas COM de terceros o las bibliotecas .NET de terceros que secretamente hacen llamadas win32. Ahí es donde tuvimos nuestros mayores dolores de cabeza.

Answer 3

x64 le permitirá direccionar más memoria, pero dado el mismo código, usará más memoria que x86.

Answer 4

En mi experiencia, portar una aplicación Asp.NET era básicamente perfecto. Ejecutar en la máquina de 32 bits y en 64 bits y no ocurre ningún problema, además de tener más memoria disponible. Esto sucede porque muchos de los problemas ya mencionados (registro, subprocesamiento, etc.) han sido gestionados por Asp.NET y es necesario corregirlos para que se ejecuten en el entorno Asp.NET.

En el lado del cliente (formulario de Windows) sucedió lo mismo, pero si ha utilizado algunas API "inseguras" para obtener carpetas especiales o acceso al registro, entonces puede haber algún problema, como ya se señaló.

Saludos Massimo

Answer 5

MSDN había publicado un pequeño documento sobre los problemas de trasladar aplicaciones de 32 bits al entorno de ejecución de 64 bits.

http://msdn.microsoft.com/en-us/library/ms973190.aspx

Otros dos bloggers habían escrito anteriormente sobre el desarrollo de 64 bits cuando trabajaban en el equipo de CLR

• Gaurav Seth
• SpankyJ

Answer 6

Desde MSDN doco , entre otras consideraciones:

En muchos casos, los ensamblajes se ejecutarán igual en el CLR de 32 bits o de 64 bits. Algunas de las razones por las que un programa se comporta de manera diferente cuando las ejecuta el CLR de 64 bits incluyen:

• Estructuras que contienen miembros que cambian de tamaño según la plataforma, como cualquier tipo de puntero.

• Aritmética del puntero que incluye tamaños constantes.

• Invocación de plataforma incorrecta o declaraciones COM que utilizan Int32 para identificadores en lugar de IntPtr.

• Transmitir IntPtr a Int32

Además, ubicaciones de archivos predeterminadas.

Answer 7

• Leer y escribir en valores de 64 bits no es seguro para subprocesos en una plataforma de 32 bits. Leer un valor de 64 bits requiere dos operaciones que podrían verse interrumpidas por un cambio de contexto. Consulte el artículo de MSDN sobre Threading.Interlocked.Read para obtener más información.

• ¡También estoy de acuerdo por completo con las respuestas de Torial ! :-)