sp3 para net framework descargar .net visual-studio windows-xp 64bit

framework - El equipo va de XP32 a XP64 para el desarrollo.NET-¿Alguna de las Gotchas?



net framework windows xp (12)

Mi equipo está consiguiendo nuevas estaciones de trabajo XP64. Hemos estado usando XP32 hasta ahora. La mayor parte de nuestro trabajo se realiza en C # / VS2008 / .net 3.5 y SQL Server 2005. Sin embargo, tenemos un par de aplicaciones que todavía están en VS2005 / .net 2.0. La mayoría de nuestras aplicaciones son aplicaciones webforms de ASP.NET y servicios WCF que se ejecutan en servidores de 64 bits en producción. Sin embargo, tenemos algo de desarrollo de WPF que tendrá que ejecutarse en máquinas de 32 bits.

¿Hay algún problema o dolores de transición que debemos tener en cuenta?


Depende.

¿Has usado P / Invoke en tu código?

¿Has usado código no administrado y datos recopilados desde y hacia él? Si es así, tendrá que pasar por este código con un peine de dientes finos :(.

Sin embargo, si su código es C # puro que no ha usado P / Invoke, entonces la única diferencia que debería ver es un ligero aumento en el rendimiento y un mejor rendimiento de la memoria :).

Sin embargo, puede encontrarse con gremlins para encontrar controladores para sus máquinas de desarrollo.

Si tiene un código de 32 bits, entonces tal vez podría crear una interfaz WCF (los tubos con nombre son muy, muy rápidos) y usarlo para hablar con un servicio de 32 bits. Sé que no puede tener código de 32 bits en un proceso de 64 bits, pero creo que puede abrir un conducto para un proceso de 32 bits, a menos que tenga ese error. Siempre puedes usar TCP / IP en ese caso. Podría ahorrarle la necesidad de volver a escribir el código crítico en su sistema y permitirle usar WOW64 o una máquina virtual para hacer frente a un problema de migración.


He estado desarrollando en la plataforma de 64 bits durante algún tiempo. Este es un pequeño consejo que puede ahorrarte un dolor de cabeza.

Si obtienes la excepción

"BadImageFormatException" (por ejemplo, "No se pudo cargar o ensamblar" Microsoft.TeamFoundation, etc. o una de sus dependencias. Se intentó cargar un programa con un formato incorrecto ")

hay una alta probabilidad de que la aplicación no pueda encontrar una versión de 64 bits del ensamblaje.

Experimentamos este error frecuentemente cuando accedemos a bases de datos usando controladores OLEDB / Jet. También he experimentado esto con herramientas que se integran con TFS.

Para solucionar esto, dirígete a la pestaña "Compilar" en la configuración de tu proyecto, "Opciones de compilación avanzada" y selecciona "x86" como la CPU de destino.

¡Espero que esto ayude!


He usado XP 64 bit durante algunos meses el año pasado. Mi experiencia fue que la pila de desarrollo de Microsoft se instaló y funcionó sin problemas, incluida una versión de SQL Server de 64 bits.

Tuve problemas con los controladores de red de la tarjeta de red Marvell Yukon de mi placa Asus. Los controladores de 64 bits tuvieron problemas serios que no fueron inmediatamente obvios, pero se hicieron evidentes luego de varios meses de pruebas intensas. Las tasas de transferencia de red en una red Gigabit no eran las esperadas, y cuando dos procesos accedían al mismo recurso de red, Windows se bloqueaba.

Mi recomendación es, al igual que el otro póster sugerido, probar la configuración del hardware del software antes de pasar a todo el equipo. Es más probable que vea problemas.


Si hace referencia a archivos DLL de terceros compilados para 32 bits, tendrá que orientar sus aplicaciones a 32 bits. Esto se puede hacer cambiando la configuración del proyecto o usando la aplicación corflags con el parámetro / 32BIT +.

El único "problema" que he encontrado en mis muchos meses de XP x64 como estación de trabajo de desarrollo es que Edit-And-Continue no funciona en el depurador de Visual Studio en aplicaciones de 64 bits.


Sun tiene un buen artículo al respecto. http://developers.sun.com/solaris/articles/ILP32toLP64Issues.html

No es inusual que las aplicaciones actuales de 32 bits suponen que el tipo int, el tipo largo y los punteros son del mismo tamaño. Debido al tamaño del cambio de puntero y largo en el modelo de datos LP64, este cambio solo es la causa principal de los problemas de conversión de ILP32 a LP64.


No podrá hablar con bases de datos de MS Access desde .NET x64, ya que no hay controladores x64 Jet.

Considero que esta es una excelente razón para pasar a x64.


TFS no es compatible con 64 bits (servidor TFS, no estoy seguro para el explorador de equipo)


  • La depuración en modo mixto es un problema si usa C ++ y C # con aplicaciones de 64 bits.
  • Todavía hay muchas herramientas de desarrollo que no admiten la ejecución en Windows x64 o no son compatibles con el trabajo con archivos binarios de 64 bits. Tomemos como ejemplo, Compuware DevPartner. Actualmente, solo es compatible con el desarrollo de aplicaciones de 32 bits, pero la aplicación se ejecutará en Windows de 64 bits.

Habrá dos conjuntos de orígenes de datos ODBC (DSN) ahora: 32 bits y 64 bits. Algunas bases de datos no tienen actualmente controladores actualizados para 64 bits, por lo que se verá obligado a utilizar los controladores de 32 bits o simplemente puede esperar.


Nos encontramos con 2 tipos diferentes de problemas:

  1. Tuvimos un componente de terceros que envolvió un dll nativo de 32 bits. El proveedor no ofreció una versión de 64 bits, por lo que tuvimos que apuntar al desarrollo de 32 bits.

  2. Algunos problemas con el conductor. XP-64 no había captado mucho (¿lo tiene ahora?) Cuando lo probamos. Los problemas no estaban relacionados con el desarrollo, pero tuvimos algunos problemas con los controladores de impresora, los controladores de red, etc.). En Vista, cambiaron el modelo de controlador, por lo que ahora puede haber más controladores de 64 bits, pero no sé si serán retrocompatibles con XP.


Puede ejecutar un problema con string.GetHashCode () devolviendo un valor diferente para la misma cadena en máquinas de 32 bits y de 64 bits, ya que ejecutarán diferentes versiones de la CLR.

Crucial:

"El comportamiento de GetHashCode depende de su implementación, que puede cambiar de una versión del tiempo de ejecución de lenguaje común a otra. Una razón por la que esto podría suceder es mejorar el rendimiento de GetHashCode ".

Más información aquí y aquí .


espero que esto ayude

Registro de COM 32 bit DLL para asp de 64 bits llamada

Muchos enlaces sobre convenciones 32-64 bits

Preguntas frecuentes generales Acerca de Windows de 64 bits

Diseño de sistema de 64 bits

vea estos consejos también ¿ Mejoría de rendimiento más grande que haya tenido con el cambio más pequeño?

más sugerencias de blog: volver a lo básico: confusión de 32 bits y 64 bits alrededor de x86 y x64 y .NET Framework y CLR

Windows Application Quality Cookbook de Microsoft

DevReadiness.org
Este sitio está dedicado a ayudar al ecosistema ISV de Windows a desarrollar aplicaciones de alta calidad para las nuevas versiones de la plataforma. Windows 7 fue anunciado recientemente en la conferencia PDC 2008, un enlace a la nueva aplicación de preparación "libro de cocina" se proporciona a la derecha

Los chicos de Microsoft.com OPS han blogueado sobre su migración a x64 y cómo funciona todo.
Ejecutando Microsoft.com en 64 bits ... Las dependencias, la bondad, lo conseguido