Migrando aplicaciones .NET a 64 bits

¡Quien me iba a decir a mí que hoy lunes iba a tener ocasión de trastear con un Windows XP de 64 bits! ¿Qué pasa? Pues no, hasta hoy no lo había probado, ¿y? La diferencia con el Windows XP Professional "de toda la vida" (el de 32 bits) es que éste limita la memoria física y virtual a 4Gb, mientras que esta versión con instrucciones de 64 bits a priori sube el techo hasta los 128 Gb, con lo que si te lo propones, tienes slots y sobre todo, un buen bolsillo, puedes acabar con toda la RAM de la tienda de informática de tu barrio.

El caso es que me han encomendado probar en dicha máquina por temas de compatibilidad, algunas aplicaciones software que se han desarrollado recientemente, en especial, una aplicación Windows Forms (C# con .NET Framework 2.0) que se pelea a través de una serie de formularios contra una base de datos Access muy sencilla.

Suponía que iba a haber algún que otro problemilla, y os adelanto, que los ha habido. Seguramente será porque después de copiar todos los archivos de la aplicación al nuevo pepino no he rezado lo suficiente a la patrona de los informáticos, Santa Tecla. El caso es que según he hecho doble clic en el .exe......cataclón:

Como la aplicación trabaja contra Access a través del driver OleDB, utilizando el motor de base de datos Microsoft Jet 4.0, he pensado que simplemente tendría que registrar (con el comando regsvr32) alguna DLL o como mucho, instalar una versión de dicho motor compatible con arquitecturas de 64 bits. He ido raudo y veloz a Google, y como siempre, he respirado hondo al ver que una vez más, se ha cumplido la máxima del programador: "siempre hay alguien a quien le ha pasado lo mismo antes que a ti". Y por lo visto, la solución no era instalar una versión específica de Microsoft Jet 4.0 para arquitecturas de 64 bits (de hecho no la hay...), sino simplemente cambiar el target platform de la aplicación desde el propio Visual Studio 2005, tal y como se suele hacer con los proyectos para dispositivos móviles desarrollados con .NET Compact Framework, donde tan pronto cambiamos de PocketPC 2003 a Windows Mobile 5, como de WM 5.0 a WM 6.0.

Así que nada, empezando a digerir una nueva lección impartida por el Profesor Internet, abrimos la página de propiedades del proyecto de Visual Studio 2005, donde vemos que el proyecto está compilado para "Any CPU", la configuración por defecto para cualquier proyecto:

Pero claro, nuestro proyecto no es "cualquier proyecto", es una aplicación que ha de correr tanto en 32 como en 64 bits. ¡Ahí es nada! Pues bien, es tan fácil como desplegar la combo de target platform, seleccionar x86, guardar los cambios y compilar:

Al querer que la aplicación corra en 64 bits, más de uno (me incluyo) hubiera seleccionado ipso facto x64 en vez de x86, acción muy lógica, pero errónea. Seleccionando x86, estamos indicando que independientemente de la arquitectura y bits que tengan las instrucciones de la máquina, esta aplicación es una aplicación específica para plataformas x86, es decir, ha de correr en un entorno de ejecución gobernado por instrucciones de 32 bits. Y para ello, Windows XP Professional x64 Edition trae un emulador para x86 denominado WOW64, el cual permite correr aplicaciones de 32 bits sin problemas en una arquitectura Windows de 64 bits. ¡A tope!

Tan sólo queda copiar los archivos generados en esta compilación "especial" a la máquina destino y rezar 64 plegarias a San Blador (Santo de los programadores). Con la aplicación funcionando perfectamente sobre un Windows XP de 64 bits (lógicamente sigue funcionando para 32 bits), si vamos al task manager podremos ver que el identificador del proceso lleva la coletilla "*32", señal inequívoca de la naturaleza de la aplicación:

Una vez más, lección realmente interesante y productiva la de hoy, me voy tranquilo y muy contento a la camita. SaludoX.