Mixed methods approach

Entre otras cosas, los ensamblados pueden ser librerías; en caso de que lo sean, existe la posibilidad de utilizarlas en diferentes escenarios y aplicaciones, dado su carácter compar- tido (shared). También es posible que existan otros desarrolladores en la misma organiza- ción que desarrollen sus propias librerías.

Aunque remota, existe la probabilidad de que dos desarrolladores distintos generen, para utilizar en una misma aplicación, una librería compartida con el mismo nombre. De permi- tirlo .NET, se caería en la misma situación caótica de los DLL que tanto quisimos evitar en Windows DNA.

Afortunadamente, en el caso de las librerías .NET compartidas, éstas deben registrarse en un recurso llamado Caché global para ensamblados (GAC, Global Assembly Cache). Este recurso almacena las entradas de los componentes y librerías .NET, registrando para cada uno diferentes especificaciones, de entre las cuales destaca PublicKeyToken, que constitu- ye un identificador único del componente.

En el GAC se encuentran las referencias lógicas de los componentes que, junto con la re- ferencia física que especificamos al momento de compilar, evita la utilización accidental de un recurso. Puede haber dos componentes compartidos del mismo nombre físico, pero un programa sabrá siempre cuál es el que debe utilizar.

Administrador de GAC. Existe una herramienta de .NET Framework, llamada gacutil. exe, que permite administrar el registro de componentes compartidos en el GAC.

Dependiendo de lo que se quiera hacer,gacutil.exepermite listar los componentes registrados en GAC, registrar un nuevo componente compartido o eliminar uno previamente registrado.

Ejercicio 1.1

Análisis de las entradas del Caché global para ensamblado (GAC,

Global Assembly Cache)

Se utilizará el administrador de GAC para conocer cuáles son los componentes .NET disponi- bles. Esta práctica asume que se tiene instalado .NET Framework 2.0SDK, English version. 1. Abra el Panel de control y seleccione Herramientas administrativas – .NET Frame-

work 2.0 Configuration. Se despliega la herramienta de configuración de .NET Frame-

work 2.0.

2. En el panel de la izquierda haga clic en el nodo My Computer; en el panel de la derecha aparecerá el vínculo Manage the Assembly Cache (Global Assembly Cache).

1

3. Haga clic en el vínculo View List of Assemblies in the Assembly Cache.

4. Existe una columna llamada Locale, y no todos los ensamblados tienen el mismo valor en dicha columna, ¿qué cree que signifique eso?

5. Existe una columna llamada Public Key Token, que contiene una clave GUID (Identifi- cador global único,Global Unique Identifier), ¿para qué cree que sirva dicha clave?

6. Cierre el programa de configuración de .NET Framework 2.0.

.NET PE (.NET Portable Executable) versus PE/COFF

Si tanto usted como la empresa en que trabaja se están iniciando en la experiencia llamada .NET, es probable que desee conocer cuáles son las diferencias entre los ejecutables gene- rados en versiones anteriores de Visual Basic 6.0 y los generados en .NET. Es muy proba- ble que al tratar de implementar proyectos en .NET surjan cuestiones del porqué hay que instalar .NET Framework en las máquinas para poder ejecutar los programas .NET. Esto genera suspicacias y dudas: ¿seguirán trabajando mis aplicaciones existentes?¿comenzará a fallar mi equipo?, ¿tengo que pagar algo para poder ejecutar aplicaciones .NET? Para ejecutar aplicaciones .NET es necesario instalar .NET Framework en los equipos, pe- ro no la versión de desarrollo, sino el núcleo del producto, que es gratuito e independiente de la instalación que un equipo tenga, por lo que no modifica las aplicaciones existentes.

Lo que sí se modifica es el cargador de programas(program loader); es decir, la par- te del sistema operativo que se encarga de reconocer a un programa ejecutable y de ejecu- tar las acciones.

Archivo PE. Un ejecutable de Windows(Windows executable), sea EXE o DLL, debe poseer un formato llamado PE Format(Portable Executable Format), que es un derivado del Microsoft Common Object File Format(COFF). A los programas ejecu- tables, por cumplir con la especificación PE, se les ha dado a llamar también Archivos PE. Tanto PE como COFF están claramente especificados y disponibles públicamente, de tal forma que todos los desarrolladores cuyas aplicaciones generen ejecutables puedan utili- zarlos para incluir en ellas los elementos que permitirán a los programas generados ser re- conocidos como tales. Cualquier compilador o aplicación que desee generar ejecutables de Windows debe cumplir con la especificación PE/COFF.

Un programa ejecutable contiene dos secciones: la sección de encabezados PE/COFF (PE/COFF Headers) y la sección de imagen nativa del programa(Native Image Section). La sección de encabezados PE/COFF indica al sistema operativo cómo está compuesto el pro- grama y cómo debe ser ejecutado; la sección de imagen nativa se encarga de contener al progra- ma en sí, así como los recursos que lo componen, usando para ello subsecciones bastante co- nocidas para los que han desarrollado compiladores, como lo son .data,.rdata,.rsrc, y .text. Archivo .NET PE. Un archivo PE de .NET es más complejo pues contiene dos secciones más: la sección de encabezados CLR(CLR Header Section) y la sección de datos CLR(CLR Data Section).

El encabezado CLR almacena información que identifica al programa como ejecutable de .NET para que como tal sea tratado por el cargador de programas. Por otro lado, la sección de datos CLR contiene metadatos y el código intermedio, lo que determina la forma en que el programa será ejecutado.

Como puede ver, las secciones del archivo PE permanecen. Si usted no tiene instalado .NET Framework, el cargador de programas de Windows encontrará secciones no recono- cidas (encabezado CLR y datos CLR), y no sabrá qué hacer con ellas. Como no fueron re- conocidas dichas secciones y el código ejecutable de .NET no es código nativo, el progra- ma generará un error. Sólo teniendo .NET Framework instalado será posible reconocer las nuevas secciones del ejecutable, que ordenarán la compilación JIT de la información con- tenida en datos CLR.

Tiempos de compilación de CLR

1

Desensamblador de ensamblados. .NET Framework posee una herramienta de línea de comando para desensamblar los archivos ejecutables, llamada ildasm.exe. Con ella es po- sible comprobar si un programa es o no .NET, mediante la ejecución del siguiente comando:

ildasm/TEXTNombreEjecutable/HEADER

Donde NombreEjecutablees el nombre del ejecutable a analizar. La especificación /TEXT

provoca que la salida sea a consola, y /HEADERprovoca que aparezcan en el resultado to- dos los encabezados del ejecutable.

Sólo si las definiciones muestran que el programa posee encabezados CLR, el programa es .NET.

Desensamblará dos ejecutables para determinar cuál de los dos es un ejecutable .NET. 1. Abra el directorio APVBNETVS\Cap01; ése será su directorio de trabajo.

2. En ese directorio hay dos programas:HolaMundoA.exey HolaMundoB.exe. Los dos ha- cen lo mismo, pero sólo uno de ellos es un .NET PE.

3. Ejecute el desensamblador de .NET Framework (ILDASM.EXE), que se encuentra en el directorio base de .NET (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727). 4. Seleccione Inicio – Todos los programas – Microsoft .NET Framework SDK v2.0 – SDK

Command Prompt.

FIGURA1.4

Diferencia de ejecutables .NET

Ejercicio 1.2

Identificación de diferencias en programas ejecutables, usando el desen- samblador de .NET (ildasm.exe)

5. Vaya al directorio de trabajo. En la línea de comandos escriba lo siguiente:

cd c:\APVBNETVS\Cap01

ildasm /TEXT HolaMundoA.exe /HEADER >a.txt ildasm /TEXT HolaMundoB.exe /HEADER >b.txt

6. Es muy evidente cuál de los dos archivos no contiene un ejecutable .NET, dado que no puede ser desensamblado.

7. Edite el archivo b.txty busque la sección Metadata Version. ¿Qué ensambles externos se mandan llamar desde este programa?

8. Cierre la sesión de línea de comandos. FIN DEL EJERCICIO*