Migrando aplicaciones .Net de 32 a 64 bits

Hola a tots,

ja sé que no és un tema nou però aquesta setmana he estat migrant unes aplicacions a 64 bits, i això ha fet que em trobi amb algunes coses interessants que m'agradaria compartir.

El primer que vaig pensar quan em van assignar la tasca va ser: per què he de revisar una aplicació .Net perquè funcioni en 64 bits si només generem assemblies que estan en IL, no en codi natiu? Bé, de seguida em vaig respondre a mi mateix, ja que, llevat que s'hagi compilat l'aplicació amb l'opció, /clr:safe no seria realista pensar que qualsevol aplicació s'executarà d'igual manera en arquitectures de 64 o de 32 bits. Microsoft diu que s'han de revisar les aplicacions sobretot si en el nostre codi fem alguna d'aquestes coses: invocar API de la plataforma via p / invoke, invocar objectes COM, utilitzar codi no segur, utilitzar marshaling com a mecanisme d'intercanvi d'informació o utilitzar la serialització com una manera de persistir l'estat. Les dues primeres estan a l'ordre del dia així que serà bastant difícil que no hàgim de fer almenys una petita revisió al nostre codi.

Framework64

La principal restricció que ens trobem quan treballem amb. Net Framework en un sistema operatiu de 64 bits és que des d'una aplicació carregada en l'entorn de 32 bits no es poden carregar components de 64 bits i viceversa, si ho intentem ens trobarem amb un FileNotFoundException o BadImageFormatException depenent del tipus de component a carregar. Això és així perquè en els sistemes de 64 bits tenim dos entorns d'execució des de la versió 2.0, l'entorn que s'executa en 64 bits i que es troba al directori %windir%\Microsoft.Net\Framework64 i el de 32 bits que s'executa sota el wow64 (Windows on Windows) i està en %windir%\Microsoft.Net\Framework.

Ldr64

Per habilitar l'entorn de 64 bits, el .Net Framework crea la clau Enable64bits en el registre de Windows que indica, si té el valor 1, que s'utilitzarà aquest entorn i que, per tant, els assemblies sense marca, s'intentaran carregar com assemblies de 64 bits. Al revés, si el que volem és fer que els assemblies compilats amb "Any CPU" s'executin sota el WoW, podem establir aquest valor a 0. Per modificar aquest valor, millor que fer-ho a mà, podem utilitzar la utilitat ldr64.exe que es troba al directori Framework64. Amb això, a més a més, aconseguim que s'apliqui immediatament la configuració seleccionada i que els assemblies del. Net Framework que s'utilitzin siguin els de la plataforma indicada.

La utilitat ldr64 té una sintaxi molt senzilla, ja que només se li poden indicar els paràmetres query, setwow o set64, que són autoexplicatius. No he trobat a la Web molta documentació d'aquesta utilitat i no sé de la seva robustesa més enllà de per a ser usada per programadors però podria ser interessant utilitzar-la en entorns de producció que disposin d'un sistema operatiu de 64 bits però amb molts assemblies amb dependències 32 bits, d'aquesta manera no seria necessari recompilar-los.

CorFlags

Un cop instal·lats tots dos frameworks, quan s'executa una aplicació, el CLR ha de decidir en quin d'aquests dos entorns es carregarà el procés i per això utilitza uns flags que s'estableixen en el PE de l'executable (portable execution header). Per poder veure aquestos flags sobre un assembly i fins i tot modificar-los sense haver de recompilar, encara que Microsoft no ho recomana, tenim la utilitat corflags.exe, disponible amb el Visual Studio. Compte amb els assemblies signats amb un strong name, perquè si canviem els flags amb aquesta utilitat haurem de tornar-los a signar.

Cal tenir en compte que quan seleccionem el tipus de plataforma en Visual Studio, principalment estem definint el valor d'alguns d'aquests flags, concretament el flag 32bit. Aquest flag funciona d'una manera una mica peculiar ja que establir-lo indica que, en un SO de 64 bits, s'executarà sota el wow64, mentre que no ho establir-lo indica que el CLR podrà carregar-lo com un assembly de 64 bits si així ho desitja.

Aquí mostro els flags que s'estableixen amb cada configuració:

Plataforma	PE	32BIT
anycpu	PE32	0
x86	PE32	1
x64	PE32+	0

Per qui no ho sàpiga, podem descobrir quins processos s'executen en 32 bits simplement mirant a la pestanya Processos de l'administrador de tasques, els processos que s'executen sota el wow64 tenen afegit * 32 al final del nom. També podem utilitzar el mètode Module.GetPEKind per comprovar programàticament la configuració d'un ensamblat. Mentre que en temps d'execució podem consultar la propietat IntPtr.Size (4 en 32 bits, 8 en 64). Precisament, un dels problemes habituals en migrar codi a 64 bits que fa crides a codi natiu és utilitzar el tipus de dades int en lloc de la classe IntPtr quan es fa referència a punters, clar que si realitzem aquest tipus de pràctiques hauríem de fer servir la classe SafeHandle, pero aquest tema es mereix un Post sencer així doncs, ho comentarem en una propera ocasió.

GAC_64

Al principi del Post vaig comentar que podríem trobar-nos amb una FileNotFoundException, aquesta excepció pot llançar-se a causa de l'algorisme de recerca del assembly ja que en instal·lar el framework de 64 bits, igual que es crea una carpeta Framework64, també es crea una nova carpeta gac_64 sota el directori c:\windows\assembly. Aquesta carpeta, que contindrà els assemblies específics de 64 bits, s'afegeix a les ja existents: gac (per frameworks 1.0 i 1.1), gac_32 i gac_msil (per assemblies "platform agnostic"). Dins de c:\windows\assembly també observarem que, si hem generat imatges natives per al nostres assemblies mitjançant la utilitat Ngen, aquestes estaran instal·lades a carpetes del tipus NativeImages_%framework_version%_%platform%, és a dir, per exemple, NativeImages_v2.0.50727_64. Així doncs, quan el CLR busqui un assembly, primer buscarà al directori propi de la plataforma i després en gac_msil. Això pot ocasionar que no es trobi l'assembly en el cas que l'aplicació s'estigui executant sota el context de 64 bits i l'assembly necessari es trobi en el directori gac_32 o al revés. Aquesta casuística es pot veure molt clarament gràcies a utilitats com Process Monitor o Fuslogvw, que ens mostren els fitxer que la nostra aplicació ha provat d'obrir sense èxit.

Més info els segïents enllaços:

Corflags.exe
http://msdn.microsoft.com/en-us/library/ms164699(v=VS.100).aspx

How to switch between the 32-bit versions of ASP.NET 1.1 and the 64-bit version  of ASP.NET 2.0 on a 64-bit version of Windows
http://support.microsoft.com/kb/894435

Migrating 32-bit Managed Code to 64-bit
http://msdn.microsoft.com/en-us/library/ms973190.aspx

64-bit Applications
http://msdn.microsoft.com/en-us/library/ms241064(v=VS.100).aspx

Run 32 bit .NET applications on 64 bit machines
http://techdhaan.wordpress.com/2010/03/15/run-32-bit-net-applications-on-64-bit-machines/

Moving from 32-bit to 64-bit application development on .NET Framework
http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx

Parlen del ldr64
http://blogs.technet.com/b/sbs/archive/2010/07/19/case-in-the-corner-series-x64-framework-not-working.aspx

Hola a todos,

ya sé que no es un tema novedoso pero esta semana he estado migrando unas aplicaciones a 64 bits, y esto a hecho que me encuentre con algunas cosas interesantes que me gustaría compartir.

Lo primero que pensé cuando me asignaron la tarea fue ¿por qué tengo que revisar una aplicación .Net para que funcione en 64 bits si solamente generamos ensamblados que están en IL, no en código nativo? Bueno, en seguida me respondí a mi mismo, ya que, salvo que se haya compilado la aplicación con la opción, /clr:safe no seria realista pensar que cualquier aplicación se ejecutará de igual manera en arquitecturas de 64 o de 32 bits. Microsoft dice que se deben revisar las aplicaciones sobre todo si en nuestro código hacemos alguna de estas cosas: invocar APIs de la plataforma via p/invoke, invocar objetos COM, utilizar código no seguro, utilizar marshaling como mecanismo de intercambio de información o utilizar la serialización como una manera de persistir el estado.  Las dos primeras están a la orden del día así que será bastante difícil que no tengamos que hacer al menos una pequeña revisión en nuestro código.

Framework64

La principal restricción que nos encontramos cuando trabajamos con .Net Framework en un sistema operativo de 64 bits es que desde una aplicación  cargada en el entorno de 32 bits no se pueden cargar componentes de 64  bits y viceversa, si lo intentamos nos encontraremos con un  FileNotFoundException o BadImageFormatException dependiendo del tipo de  componente a cargar. Esto es así porque en los sistemas de 64 bits tenemos dos entornos de  ejecución desde la versión 2.0, el entorno que se ejecuta en 64 bits y  que se encuentra en el directorio %windir%\Microsoft.Net\Framework64 y  el de 32 bits que se ejecuta bajo el wow64 (Windows on windows) y está  en  %windir%\Microsoft.Net\Framework .

Ldr64

Para habilitar el entorno de 64 bits,  .Net Framework  crea la clave Enable64bits en el registro  de Windows que indica, si tiene el valor 1, que se utilizará este entorno y que, por lo tanto, los ensamblados sin marca, se intentarán cargar como  ensamblados de 64 bits. A la inversa, si lo que queremos es forzar que  los ensamblados compilados con "Any CPU" se ejecuten bajo el WoW,  podemos establecer este valor a 0. Para modificar este valor, mejor que  hacerlo a mano, podemos utilizar la utilidad ldr64.exe que se encuentra  en el directorio Framework64. Con esto conseguimos además que se aplique inmediatamente la configuración  seleccionada y que los ensamblados del .Net Framework que se utilicen sean los de la plataforma indicada.

La utilidad ldr64 tiene una sintaxis muy sencilla, ya que  solo se le pueden indicar los parámetros query, setwow o set64, que son  autoexplicativos. No he encontrado en la Web mucha documentación de esta utilidad y no sé  de su robustez más allá de para ser usada por programadores pero podría ser interesante utilizarla en entornos de producción que dispongan de un sistema operativo de 64 bits pero con muchos ensamblados con dependencias en 32 bits, de esta manera no sería necesario recompilarlos.

CorFlags

 Una vez instalados ambos frameworks, cuando se ejecuta una aplicación, el CLR debe decidir en
cual de estos  dos entornos se cargará el proceso y para eso utiliza unos flags que se establecen en el PE del ejecutable (portable execution header). Para  poder ver estos flags sobre un ensamblado e incluso modificarlos sin tener que recompilar, aunque  Microsoft no lo recomienda, tenemos la utilidad corflags.exe,  disponible con el Visual Studio. Cuidado con los ensamblados firmados con un strong name, porque si cambiamos los flags con esta utilidad tendremos que volverlos a firmar.

Hay que tener en cuenta que  cuando seleccionamos el tipo de plataforma  en Visual Studio, principalmente estamos definiendo el valor de algunos de estos flags, concretamente el flag 32BIT. Este flag funciona de una manera un tanto peculiar ya que  establecerlo indica que, en un SO de 64 bits, se ejecutará bajo el  wow64, mientras que no establecerlo indica que el CLR podrá cargarlo como ensamblado de 64 bits si así lo desea.

Aquí muestro los flags que se establecen con cada configuración:

Plataforma	PE	32BIT
anycpu	PE32	0
x86	PE32	1
x64	PE32+	0

 Para quien no lo sepa, podemos descubrir que procesos se ejecutan en 32 bits simplemente mirando en la pestaña Procesos del administrador de tareas, los procesos que se ejecutan bajo el wow64 tienen añadido *32 al final del nombre. También podemos utilizar el método Module.GetPEKind para comprobar programáticamente la configuración de un ensamblado. Mientras que en tiempo de ejecución podemos consultar la propiedad IntPtr.Size (4 en 32 bits, 8 en 64). Precisamente, uno de los problemas habituales al migrar código a 64 bits que hace llamadas código nativo es utilizar el tipo de datos int en lugar de la clase IntPtr cuando se hace referencia a punteros, claro que si realizamos este tipo de prácticas deberíamos usar la clase SafeHandle, pero este tema se merece un Post entero así que ya lo comentaremos en otra ocasión.

GAC_64

Al principio del Post comenté que podríamos encontrarnos con una FileNotFoundException, esta excepción puede  lanzarse a causa del algoritmo de búsqueda del ensamblado ya que al instalar  el framework de 64 bits, igual que se crea una carpeta Framework64, también  se crea una nueva carpeta gac_64 bajo el directorio  c:\windows\assembly. Esta carpeta, que contendrá los ensamblados  específicos de 64 bits, se añade a las ya existentes: gac (para  frameworks 1.0 y 1.1), gac_32 y gac_msil (para ensamblados "platform  agnostic"). Dentro de c:\windows\assembly también observaremos que, si hemos generado imágenes nativas para nuestro ensamblados mediante la utilidad ngen, éstas estarán instaladas en carpetas del tipo NativeImages_%framework_version%_%platform%, es decir, por ejemplo, NativeImages_v2.0.50727_64.

Así pues, cuando el CLR busque un ensamblado, primero  buscará en el directorio propio de la plataforma y luego en gac_msil.  Esto puede ocasionar que no se encuentre el ensamblado en el caso de que  la aplicación se esté ejecutando bajo el contexto de 64 bits y el  ensamblado necesario se encuentre en el directorio gac_32 o a la  inversa.  Esta casuística se puede ver muy claramente gracias a utilidades como Process Monitor o Fuslogvw, que nos muestra los archivos que nuestra aplicación ha intentado abrir sin éxito.

Mas info en los siguientes enlaces:

Corflags.exe

http://msdn.microsoft.com/en-us/library/ms164699(v=VS.100).aspx

How to switch between the 32-bit versions of ASP.NET 1.1 and the 64-bit version  of ASP.NET 2.0

on a 64-bit version of Windows

http://support.microsoft.com/kb/894435

Migrating 32-bit Managed Code to 64-bit

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

64-bit Applications

http://msdn.microsoft.com/en-us/library/ms241064(v=VS.100).aspx

Run 32 bit .NET applications on 64 bit machines

http://techdhaan.wordpress.com/2010/03/15/run-32-bit-net-applications-on-64-bit-machines/

Moving from 32-bit to 64-bit application development on .NET Framework

http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx

Hablan del ldr64 pero para ponerlo en set64

http://blogs.technet.com/b/sbs/archive/2010/07/19/case-in-the-corner-series-x64-framework-not-working.aspx