Buenas a tod@s
Como podéis apreciar ya he vuelto de vacaciones jeje.
La vacaciones muy biejeje. Este verano me he dedicado a viajar por Europa y he visitado Bélgica e Inglaterra. Belgica me ha encantado Brujas es una maravilla y aunque la gente prefiere Gante... Yo me quedo con Brujas. En Inglaterra he visitado Londres y el pueblo más antiguo de Inglaterra, Colchester. Es curioso como una rebelión puede hacer que se moviera la capital del Colchester a Londres... es lo que tienen las rebeliones.
El problema del Office, .NET y los equipos de 64 bits
Bueno volviendo un poco al tajo, os voy a contar un problema que tengo identificado para el cual no tengo una fácil solución. Tengo varias alternativas pero la solución que sería ideal no existe ya me gustaría poderla postear, pero por el momento no es posible y lo creo que lo sea en un futuro.
Cuando desarrollamos una aplicación bajo la plataforma .NET de Microsoft entre todas las opciones que tenemos para realizar la compilación hay una que normalmente pasa desapercibida que es la de CPU. Normalmente las maquinas con las que solemos trabajar a dia de hoy (a menos que sean servidores) suelen ser de 32 bits. Windows XP tiene mucha culpa de esto ya que a día de hoy sigue siendo muy utilizado, pero aunque no tengamos XP también hay versiones de Windows Vista (si ese también existe), Windows 7 o Windows 8 de 32 bits.
Cuando realizamos una aplicación normalmente en la opciones de complicación dejamos la opción de CPU como viene por defecto, es decir en ANY.
No sé si sabéis muy bien como funciona .NET, voy a explicarlo un poco por encima. Cuando realizas el ejecutable de una aplicación realmente esta aplicación no está compilada en código maquina (como haría por ejemplo C), sino que esta se genera en un código intermedio llamado CLR (Common Language Runtime). La primera vez que ejecutamos la aplicación en la máquina, el Framework de .NET se encarga de compilar este código para generar el ejecutable real. Porque se funciona así, es sencillo, no existe una aplicación más optimizada para una máquina que la que se compila dentro de ella misma. Un buen ejemplo lo tenéis en la distribución Linux Gentoo que al instalarse compila cada uno de los paquetes para que su ejecución sea lo más óptima posible, el problema es que tardas muchísimo en instalarlo. Esa es la razón por la que siempre que ejecutamos una aplicación de .NET por primera vez tarda más en ejecutarse que las siguientes ejecuciones.
Hasta aquí todo correcto, si ejecutamos una aplicación de .NET en la cual no hemos especificado una CPU en un equipo de 64 Bits. La aplicación será compilada en 64 bits y funcionara de forma correcta.
Pero ¿qué ocurre si nuestro programa utiliza Excel o Access para acceder a los datos?
Si tenemos la versión de Office de 64 bits funcionará correctamente, pero si tenemos la de 32 Bits (que Microsoft a día de hoy recomienda) no funcionará. Obtendremos un bonito error diciendo que no se encuentran los controladores específicos de acceso a datos.
Entonces… la solución pasa porque siempre un equipo de 64 bits se instale Office de 64 bits.
Si, esta es una solución, pero… no tan rápido amigo. ¿Qué pasa si tenemos aplicaciones antiguas por ejemplo en VB6 o en C que utilizan los componentes de Office? Creo que lo habéis adivinado, el mismo error que daba la aplicación de 64 bits con el Office de 32.
Evidentemente la solución ideal, sería instalar los controladores de ambos Office, pero esto no es posible a día de hoy y no creo que lo sea nunca, dado que la nueva versión de Office 2013 tampoco lo permite.
La solución que nos queda, es forzar la compilación de nuestra aplicación a X86, es decir a 32 bits, sacrificando algo de rendimiento.
El último de los problemas encontrado, es que si realizamos una publicación mediante ClicOnce y nos encontramos con este problema, debemos realizar una nueva publicación. No vale con recompilar, ya que si republicamos sobre la anterior, no se actualizará en los equipos, porque lo detectará como una versión diferente. Por lo que hay que realizar una nueva publicación y reinstalar todos los clientes.
Como podéis ver, el problema que a priori parece una cosa sencilla, se complica mucho.
Entonces… ¿Qué interesa instalar Office de 32 bits o de 64 bits?
Está claro que si queremos tener compatibilidad con programas antiguos realizados para Windows XP que utilicen el Office, estamos forzados a instalar office de 32 bits. Pero si no tenemos este problema, y todos nuestros programas están hechos en .Net (contra lo que Microsoft recomienda) bajo mi punto de vista es recomendable instalar office de 64 bits. Claro que para esto tenemos que tener en cuenta los programas de terceros que a saber cómo estarán. Si no necesitan acceso a Office y solo los de gestión propia lo necesitan, o sabemos que los que tenemos de terceros lo soportan será mejor así, ganaremos rendimiento y compatibilidad. Pero sino no es estaremos condenados a instalar el de 32 bits y a forzar la compilación a X86.
Mala solución tiene esto, ojala la gente de Microsoft se dé cuenta y busquen una solución porque por el momento no la hay.
Espero que este tema haya resultado interesante, no muy aburrido, que ahorre un dolor a mas de uno y sobre todo que sirva para algo
Muy importante, si decides comentar o republicar parte de este articulo porque te ha sido útil, por favor cita la fuente y el autor del mismo (vamos cítame) y pon un enlace al artículo de mi blog
Muchas gracias por leerme.
Saludetes a todos
P.D. Podéis seguirme en Twitter @jberron y linkedin
