Utilidades WMI

Hola a todos,
Siguiendo la temática del post anterior, me gustaría profundizar un poco más en como podemos explotar WMI desde nuestras aplicaciones. Desde el área de sistemas siempre ha sido más habitual utilizar WMI que no desde el área de desarrollo, por ello podemos encontrar más herramientas enfocadas a sistemas para explotar sus posibilidades. Sin embargo, estas herramientas también pueden ser muy útiles para el programador, entre ellas me gustaría destacar WMI Code Creator, Script-o-matic, wmic y PowerShell.
 

WMI Code Creator

Como su propio nombre indica, esta herramienta permite generar código para acceder a WMI. Genera código tanto en VB.Net y C# como en VBScript. Su objetivo principal era ayudar a el personal de IT y desarrolladores a generar scripts para consultar WMI pero, además de esto, también nos permite ejecutar métodos de clases WMI, recibir eventos y navegar por todas las clases WMI que tengamos instaladas en nuestro ordenador. Aunque el código generado no sea muy complejo ni nos permita acceder a la información mediante propiedades fuertemente tipadas, como hace la utilidad mgmtclassgen que ya comenté en mi post anterior, es una utilidad muy práctica para explorar la información que podemos extraer de WMI y para generar código de ejemplo para realizar tareas básicas.

Sin embargo, uno de los aspectos que más me atrae de esta utilidad es que está escrita en C#. No es una aplicación que tengamos que tomar como ejemplo a la hora de nuestros desarrollos, incluso diría que se podrían haber esforzado un poco en separar el acceso a la información de la interfaz gráfica. No obstante, leer el código ajeno es una de las mejores maneras de aprender, y, en un solo archivo cs descargable, podemos aprender un montón acerca de como está estructurado WMI y de como podemos acceder tanto a su esquema como a sus valores. Además, si utilizamos a menudo WMI o tenemos que generar scripts con asiduidad, siempre podemos modificar el código para que se adapte a nuestras necesidades.
WMI Code Creator puede descargarse del Microsoft Download Center aquí.
 

Scriptomatic 2.0

Esta utilidad es ampliamente conocida en el mundo del scripting. Es un archivo HTA (es decir HTML y VB Script), no genera código .Net sino VBScript, JScript, Perl y Python. Es bastante más limitada que WMI Code Creator desde el punto de vista del desarrollador pero aún así útil para enseñarnos los entresijos de escribir scripts para WMI. También está disponible en el Microsoft Download Center aquí.
 

WMIC

WMIC es sencillamente una utilidad de línea de comandos que nos permite acceder a WMI, es la utilidad más básica de las que he comentado pero es imprescindible conocerla si vas a trabajar extrayendo información del sistema por una u otra razón, ya que es la manera más sencilla de hacerlo y en algún momento tendrás la necesidad de corroborar de manera rápida los valores que retorna WMI. La desventaja es que hay que aprender a utilizarlo ya que, por una razón que escapa a mi conocimiento, utiliza alias para las clases y verbos para las acciones que son ligeramente distintos a los nombres de las clases WMI. Esta utilidad viene con el sistema operativo desde Windows XP, aquí os dejo el enlace que explica su sintaxis.
 

PowerShell Get-WmiObject

Para los que tengan la suerte de tener disponible PowerShell, existe el comando Get-WmiObject que nos da acceso a las clases de WMI desde la línea de comandos. Está claro que PowerShell es un gran avance para los administradores de sistemas pero como está basado en .Net también tiene una gran utilidad para los desarrolladores que sin apenas curva de aprendizaje podemos realizar scripts realmente complejos. Por ejemplo, con esta línea podemos recuperar todos los adaptadores de red

   1:  $NetworkAdapters = Get-WmiObject -Class Win32_NetworkAdapter 

y en la linea siguiente deshabilitar uno de ellos:

   2:  $NetworkAdapters[0].Disable() 

Aquí tenéis el enlace con la documentación de este método.

Hola a tots,

Seguint la temàtica del post anterior, m'agradaria aprofundir una mica més en com podem explotar WMI des de les nostres aplicacions. Des de l'àrea de sistemes sempre ha estat més habitual utilitzar WMI que no des de l'àrea de desenvolupament, per això podem trobar més eines enfocades a sistemes per explotar les seves possibilitats. No obstant això, aquestes eines també poden ser molt útils per al programador, entre elles m'agradaria destacar WMI Code Creator, Script-o-matic, wmic i PowerShell.

 

WMI Code Creator

Com el seu propi nom indica, aquesta eina permet generar codi per accedir a WMI. Genera codi tant en VB.Net i C # com en VBScript. El seu objectiu principal era ajudar el personal d'IT i desenvolupadors a generar scripts per consultar WMI però, a més d'això, també ens permet executar mètodes de classes WMI, rebre esdeveniments i navegar per totes les classes WMI que tingueu instal al nostre ordinador. Encara que el codi generat no sigui molt complex ni ens permeti accedir a la informació mitjançant propietats fortament tipadas, com fa la utilitat mgmtclassgen que ja vaig comentar en el meu post anterior, és una utilitat molt pràctica per descobrir la informació que podem extreure de WMI i per generar codi d'exemple per a realitzar tasques bàsiques.

 

No obstant això, un dels aspectes que més m'atrau d'aquesta utilitat és que està escrita en C#. No és una aplicació que hàgim de prendre com a exemple a l'hora dels nostres desenvolupaments, fins i tot diria que es podrien haver esforçat una mica a separar l'accés a la informació de la interfície gràfica. En qualsevol cas, llegir el codi d’una altra persona és una de les millors maneres d'aprendre, i, en un sol arxiu cs descarregable, podem aprendre un munt sobre com està estructurat WMI i de com podem accedir tant al seu esquema com als seus valors. A més, si utilitzem sovint WMI o hem de generar scripts amb assiduïtat, sempre podem modificar el codi perquè s'adapti a les nostres necessitats.

WMI Code Creator pot descarregar del Microsoft Download Center aquí.

 

Scriptomatic 2.0

Aquesta utilitat és àmpliament coneguda en el món del scripting. És un arxiu HTA (és a dir HTML i VB Script), no genera codi. Net sinó VBScript, JScript, Perl i Python. És bastant més limitada que WMI Code Creator des del punt de vista del desenvolupador però tot i així útil per ensenyar-nos els secrets d'escriure scripts per WMI. També està disponible al Microsoft Download Center aquí.

 

WMIC

WMIC és senzillament una utilitat de línia de comandes que ens permet accedir a WMI, és la utilitat més bàsica de les que he comentat però és imprescindible conèixer si vas a treballar extraient informació del sistema per una o altra raó, ja que és la manera més senzilla de fer-ho i en algun moment tens la necessitat de corroborar de manera ràpida els valors que retorna WMI. El desavantatge és que cal aprendre a utilitzar-lo ia que, per una raó que escapa al meu coneixement, utilitza àlies per a les classes i verbs per a les accions que són lleugerament diferents als noms de les classes WMI. Aquesta utilitat ve amb el sistema operatiu des de Windows XP, aquí us deixo l'enllaç que explica la seva sintaxi.

 

PowerShell Get-WmiObject

Per als que tinguin la sort de tenir disponible PowerShell, hi ha l'ordre Get-WmiObject que ens dóna accés a les classes de WMI des de la línia d'ordres. És clar que PowerShell és un gran avanç per als administradors de sistemes però com està basat en .Net també té una gran utilitat per als desenvolupadors que gairebé sense corba d'aprenentatge podem realitzar scripts realment complexos. Per exemple, amb aquesta línia podem recuperar tots els adaptadors de xarxa

   1:  $NetworkAdapters = Get-WmiObject -Class Win32_NetworkAdapter 

i en la línia següent desactivar un d'ells:

   2:  $NetworkAdapters[0].Disable() 

Aquí teniu l'enllaç amb la documentació d'aquest mètode.

WMI fuertemente tipado

Hola a tots,

feia molt de temps que no tenia l'ocasió de treballar amb WMI (Windows Management Instrumentation) i com que sempre m'ha semblat un recurs excepcional, m'he decidit a dedicar-li un post.

WMI ens proporciona una manera unificada d'accedir a la informació del sistema, és extensible per les nostres aplicacions i fàcilment consultable mitjançant WQL, evitant d'aquesta manera les consultes enutjoses a les API de Windows o al registre. WMI és accessible des de .Net a través de l'espai de noms System.Management i des d’script, ja que està exposat per COM.

WMI és molt potent perquè, a més a més de consultar informació del sistema, també podem modificar-la i fins i tot realitzar un ampli ventall d'operacions que van des d’iniciar processos a habilitar adaptadors de xarxa, passant per formatar particions. Però potser, el que li atorga major versatilitat, és poder realitzar aquestes operacions en ordinadors remots, sempre que tinguem suficients privilegis, és clar.

També té inconvenients, com tot en aquesta vida. Alguns d'ells són, per exemple, que no ens lliurem d'incompatibilitats entre les diferents versions del sistema operatiu, el servei Winmgmt ha d'estar executant-se en la màquina, les consultes poden tenir un rendiment molt pobre, a l'hora de creuar informació entre taules el WQL és poc intuïtiu i bastant complicat i segur que moltes altres més que ara mateix no recordo.

Mgmtclassgen

Us recomano aquesta utilitat que ens permet generar classes .Net a partir de classes WMI, de manera que podrem accedir als atributs i operacions d'aquests objectes mitjançant mètodes i propietats fortament tipats. Les classes generades són bastant bàsiques i serà treball nostre modificar-les en el cas que vulguem realitzar consultes complexes o bé optimitzar l'accés a les dades, però ens estalvia una gran quantitat de codi que ens permet tenir una aplicació molt més llegible.

Aquí us deixo un enllaç que explica l'ús d'aquesta utilitat: http://msdn.microsoft.com/en-us/library/2wkebaxa(v=VS.100).aspx

Per exemple, si executem la comanda mgmtclassgen win32_process, se'ns generarà l'arxiu Process.cs que inclourà la classe Process,

De manera que passarem a accedir a la informació de la següent manera:

   1:  foreach(Process ps in Process.GetInstances())

   2:  {

   3:      Console.WriteLine(ps.Name);

   4:  }

En comptes del que hauríem de fer abans:

   1:  System.Management.ManagementScope mgmtScope = new System.Management.ManagementScope();

   2:  mgmtScope.Path.NamespacePath = "root\\CimV2";

   3:  System.Management.ManagementPath pathObj = new System.Management.ManagementPath();

   4:  pathObj.ClassName = "win32_process";

   5:  pathObj.NamespacePath = "root\\CimV2";

   6:  System.Management.ManagementClass clsObject = new System.Management.ManagementClass(mgmtScope, pathObj, null);

   7:  System.Management.EnumerationOptions enumOptions = new System.Management.EnumerationOptions();

   8:  enumOptions.EnsureLocatable = true;

   9:  foreach (System.Management.ManagementBaseObject obj in clsObject.GetInstances(enumOptions))

  10:  {

  11:      Console.WriteLine(obj["Name"].ToString());

  12:  }

Guanyant no només llegibilitat en el nostre codi sinó també comprovació de tipus en temps de compilació i evitem errors en temps d'execució per exemple per haver escrit malament el nom d'un atribut.

Un altre aspecte a tenir en compte és que aquesta utilitat es basa en l'esquema existent a la màquina on s'executa la utilitat, de manera que les classes generades poden variar el comportament si s'executen en altres sistemes operatius.

 

Early vs Late Bound

Les classes generades per aquesta utilitat intenten proporcionar-nos un enfocament early-bound en lloc del late-bound que és el que tenim per defecte utilitzant les classes sota System.Management. Això vol dir que hem de decidir entre fer servir una aproximació late-bound o un accés fortament tipat? Res més lluny de la realitat, la utilíssima propietat AutoCommit que podem establir a false en qualsevol moment ens permet treballar amb l'objecte en memòria abans d'enllaçar amb l'objecte real. A més, també disposem de la propietat LateBoundObject que ens proporciona accés a l'objecte WMI subjacent.

Treballar amb early bound és la manera recomanada per Microsoft i la que hauríem d’emprar en la majoria de les ocasions pels avantatges que he comentat prèviament. No obstant això, hi han ocasions en què és necessari utilitzar un enfocament late-bound. Per exemple, si no coneixem en temps de disseny si un mètode o atribut existirà en temps d'execució. També podem trobar-nos que hi ha operacions que són impossibles de realitzar amb una aproximació early-bound a causa del disseny del component, com ara la instal.lació d'un nou driver d'impressora. A continuació mostro un exemple d'ús de la propietat AutoCommit:

   1:  Printerdriver driver = Printerdriver.CreateInstance();

   2:  driver.AutoCommit = false;

   3:  driver.LateBoundObject["Name"] = "Epson AL-2600";

   4:  driver.SupportedPlatform = "Windows x64";

   5:  uint rc = Printerdriver.AddPrinterDriver(driver.LateBoundObject);

 

Més info a:

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

Hola a todos,

hacía mucho tiempo que no tenía la ocasión de trabajar con WMI (Windows Management Instrumentation) y como siempre me ha parecido un recurso excepcional, me he decidido a dedicarle un post.

WMI nos proporciona una manera unificada de acceder a la información del sistema, es extensible por nuestras aplicaciones y fácilmente consultable mediante WQL, evitando de esta forma las consultas engorrosas a las APIs de Windows o al registro. WMI es accesible desde .Net a través del espacio de nombres System.Management y desde script, ya que está expuesto por COM.

WMI es muy potente porque, además de consultar información del sistema, también podemos modificarla e incluso realizar un amplio abanico de operaciones que van desde iniciar procesos a habilitar adaptadores de red, pasando por formatear particiones. Pero quizás, lo que le otorga mayor versatilidad, es poder realizar estas operaciones en ordenadores remotos, siempre que tengamos suficientes privilegios, claro está.

También tiene inconvenientes, como todo en esta vida. Algunos de ellos son, por ejemplo, que no nos libramos de incompatibilidades entre las diferentes versiones del sistema operativo, el servicio Winmgmt debe estar ejecutándose en la máquina, las consultas pueden tener un rendimiento muy pobre, a la hora de cruzar información entre tablas el WQL es poco intuitivo y bastante complicado y seguro que muchas otras más que ahora mismo no recuerdo.

Mgmtclassgen

Os recomiendo esta utilidad que nos permite generar clases .Net a partir de clases WMI, de tal manera que podremos acceder a los atributos y operaciones de estos objetos mediante métodos y propiedades fuertemente tipados. Las clases generadas son bastante básicas y será trabajo nuestro modificarlas en el caso de que queramos realizar consultas complejas o bien optimizar el acceso a los datos, pero nos ahorra una gran cantidad de código que nos permite tener una aplicación mucho más legible.

Aquí os dejo una enlace que explica el uso de esta utilidad: http://msdn.microsoft.com/en-us/library/2wkebaxa(v=VS.100).aspx

Por ejemplo si ejecutamos el comando mgmtclassgen win32_process, se nos generará el archivo Process.cs que incluirá la clase Process,

De manera que pasaremos a acceder a la información de la siguiente manera:

   1:  foreach(Process ps in Process.GetInstances())

   2:  {

   3:      Console.WriteLine(ps.Name);

   4:  }

En lugar de lo que teníamos que hacer antes:

   1:  System.Management.ManagementScope mgmtScope = new System.Management.ManagementScope();

   2:  mgmtScope.Path.NamespacePath = "root\\CimV2";

   3:  System.Management.ManagementPath pathObj = new System.Management.ManagementPath();

   4:  pathObj.ClassName = "win32_process";

   5:  pathObj.NamespacePath = "root\\CimV2";

   6:  System.Management.ManagementClass clsObject = new System.Management.ManagementClass(mgmtScope, pathObj, null);

   7:  System.Management.EnumerationOptions enumOptions = new System.Management.EnumerationOptions();

   8:  enumOptions.EnsureLocatable = true;

   9:  foreach (System.Management.ManagementBaseObject obj in clsObject.GetInstances(enumOptions))

  10:  {

  11:      Console.WriteLine(obj["Name"].ToString());

  12:  }

Ganando no solo legibilidad en nuestro código sino también comprobación de tipos en tiempo de compilación y evitamos errores en tiempo de ejecución por ejemplo por haber escrito mal el nombre de un atributo.

Otro aspecto a tener en cuenta es que esta utilidad se basa en el esquema existente en la máquina donde se ejecuta la utilidad, con lo que las clases generadas pueden variar el comportamiento si se ejecutan en otros sistemas operativos.

Early vs Late Bound

Las clases generadas por esta utilidad intentan proporcionarnos un enfoque early-bound en lugar del late-bound que es el que tenemos por defecto utilizando las clases bajo System.Management. ¿Esto quiere decir que tenemos que decidir entre usar una aproximación late-bound o un acceso fuertemente tipado? Nada más lejos de la realidad, la utilísima propiedad AutoCommit que podemos establecer a false en cualquier momento nos permite trabajar con el objeto en memoria antes de enlazarlo con el objeto real. Además, también disponemos de la propiedad LateBoundObject que nos proporciona acceso al objeto WMI subyacente.

Trabajar con early bound es la manera recomendada por Microsoft y la que deberíamos utilizar en la mayoría de las ocasiones por las ventajas que he comentado previamente. Sin embargo, hay ocasiones en las que es necesario utilizar un enfoque late-bound. Por ejemplo, si no conocemos en tiempo de diseño si un método o atributo existirá en tiempo de ejecución. También podemos encontrarnos que hay operaciones que son imposibles de realizar con una aproximación early-bound debido al diseño del componente, como por ejemplo la instalación de un nuevo driver de impresora. A continuación muestro un ejemplo de uso de la propiedad AutoCommit:

   1:  Printerdriver driver = Printerdriver.CreateInstance();

   2:  driver.AutoCommit = false;

   3:  driver.LateBoundObject["Name"] = "Epson AL-2600";

   4:  driver.SupportedPlatform = "Windows x64";

   5:  uint rc = Printerdriver.AddPrinterDriver(driver.LateBoundObject);

Más info en:

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

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