Framework .net

.NET Framework David Gañán Jiménez P08/B0036/01625

© FUOC • P08/B0036/01625 .NET Framework

Índice

Introducción.......................................................................................... 5

Objetivos................................................................................................. 6

1. El .NET Framework....................................................................... 7

1.1. Ventajas principales del .NET Framework ................................ 8

1.2. Versiones de NET ...................................................................... 10

2. Common Language Runtime (CLR).......................................... 12

2.1. Funciones del CLR .................................................................... 12

2.2. Proceso de ejecución de una aplicación .NET .......................... 14

2.2.1. Compilación .................................................................. 14

2.2.2. Enlazado ......................................................................... 15

2.2.3. Creación de un dominio de aplicación ......................... 15

2.2.4. Cargador de clases ......................................................... 16

2.2.5. Compilación JIT ............................................................. 16

2.2.6. Ejecución CLR ................................................................ 18

3. Common type system (CTS).......................................................... 19

3.1. Elementos del CTS .................................................................... 19

3.2. Tipos valor frente a Tipos referencia ........................................ 19

3.3. Tipos de miembros .................................................................... 20

3.4. Visibilidad .................................................................................. 20

3.5. CLS Common language specification........................................... 21

4. Framework Class Library (FCL)................................................. 22

4.1. Funcionalidades principales de la FCL ..................................... 23

4.2. Otros namespaces de la FCL ...................................................... 24

5. Ensamblados.................................................................................... 25

5.1. Características de los ensamblados ........................................... 25

5.2. Tipos de ensamblados ............................................................... 26

5.3. Estructura de un ensamblado ................................................... 26

5.3.1. Visualización del contenido de un archivo PE .............. 28

5.3.2. Internacionalización ...................................................... 29

5.4. Global assembly cache .............................................................. 30

5.4.1. Strong name...................................................................... 31

5.4.2. Instalación en la GAC ................................................... 32

5.4.3. Versionado ..................................................................... 32

5.4.4. Ejecución 'side-by-side' .................................................... 33

© FUOC • P08/B0036/01625 .NET Framework

Bibliografía............................................................................................ 35

© FUOC • P08/B0036/01625 5 .NET Framework

Introducción

El .NET Framework es el componente principal de Microsoft .NET. Constituye

la plataforma de desarrollo de las aplicaciones .NET e incluye las herramien-

tas y componentes necesarios para desarrollar diferentes tipos de aplicaciones

(Windows, web, para dispositivos móviles, etc.). El resto de herramientas y

tecnologías .NET se basan en dicha plataforma.

En este tema, veremos los conceptos básicos del .NET Framework, necesarios

para entender el proceso de creación y ejecución de aplicaciones .NET.


Objetivos

El material que se os presenta a continuación ha sido elaborado teniendo en

cuenta los siguientes objetivos específicos:

1. Conocer en profundidad del .NET Framework: características, ventajas y

componentes principales del .NET Framework.

2. Conocer el proceso de compilación y ejecución de aplicaciones .NET.

3. Saber el concepto de ensamblado y sus características principales.

4. Ser capaces de escribir los componentes principales de la plataforma.


1. El .NET Framework

El .NET Framework es el conjunto de componentes y herramientas que per-

miten la ejecución de aplicaciones .NET. Para desarrollar aplicaciones .NET se

utilizan las herramientas del .NET Framework SDK. Dentro del .NET Frame-

work podemos distinguir las tres partes principales siguientes:

• CLR (common language runtime). Permite la ejecución de aplicaciones .NET

dentro de un entorno gestionado. Gracias al CLR, las aplicaciones .NET se

pueden instalar y desinstalar más fácilmente, con una mejor gestión de

versiones, y control de seguridad. Además, dado que todos los lenguajes

comparten el CLR, el desarrollo, la depuración y la ejecución de aplicacio-

nes puede realizarse, aunque la aplicación esté desarrollada en diferentes

lenguajes de programación.

• CLS (common language specification) y lenguajes .NET. CLS es una especifi-

cación de las características de los lenguajes de programación compatibles

con el .NET Framework. Esta especificación es precisamente la que permite

que se puedan implementar nuevos lenguajes de programación adaptados

a la plataforma.

El .NET Framework incluye cinco lenguajes de programación: Visual Basic

.NET, Visual C++ .NET, C#, J# y JScript. No obstante, permite que otros len-

guajes desarrollados por terceros puedan acoplarse fácilmente a la plata-

forma, y ya existe una gran variedad de ellos, entre los cuales podemos en-

contrar versiones de COBOL, FORTRAN, Ada, Pascal, Haskell, Eiffel, Delp-

hi, etc.

• FCL (framework class library). La biblioteca de clases comunes está com-

puesta por una serie de clases con las herramientas y utilidades básicas

necesarias para empezar a desarrollar aplicaciones, todas ellas disponibles

para todos los lenguajes .NET gracias al CLS. Dentro de la FCL, podemos

destacar algunas de las librerías más importantes, como las funcionalida-

des básicas del sistema operativo (Base Class Library BCL), además de otras

tecnologías como ASP.NET, WinForms para creación de interfaces graficas,

ADO.NET para acceso a datos, etc.


Estructura del .NET Framework

1.1. Ventajas principales del .NET Framework

El hecho de que .NET Framework esté desarrollado sobre estándares confiere

una gran ventaja a esta plataforma. Tanto el componente principal del .NET

Framework (CLR), como la especificación de los lenguajes .NET (CLS) y el len-

guaje C#, han sido estandarizados por ECMA (European Computer Manufac-

turers Association). Por otro lado, muchas de las tecnologías que utiliza el .NET

Framework son estándares, como XML, SOAP, UDDI, WDSL, etc.

La utilización de estándares favorece otras ventajas del .NET Framework como

son la integración de aplicaciones o la interoperabilidad entre lenguajes. A

continuación, repasamos las ventajas más importantes:

• Integración de componentes y aplicaciones. Los servicios web proporcio-

nan una arquitectura ágil del sistema, tanto interna como externamente,

simplificando la integración de aplicaciones o componentes por medio de

intranets o de Internet.

Además, permiten la integración de aplicaciones ya existentes de forma

sencilla y sin necesidad de grandes modificaciones, con independencia de

la plataforma y lenguaje utilizado para desarrollar la aplicación. Esto es

posible gracias a que los servicios web están basados en el estándar XML.

• Interoperabilidad entre lenguajes. El .NET Framework proporciona un en-

torno común de desarrollo y ejecución para todos los lenguajes .NET. To-

dos los lenguajes .NET permiten desarrollar aplicaciones Windows, Web

Services, páginas ASP.NET o aplicaciones para dispositivos móviles.

Todos los lenguajes .NET comparten la librería de clases (FCL), el sistema

de depuración1, el sistema de excepciones, la gestión automática de me-

moria, etc. De hecho, se pueden utilizar diferentes lenguajes .NET para

desarrollar partes distintas de una misma aplicación. Esto facilita que los

programadores puedan escoger el lenguaje de programación en función

de sus preferencias y no de la potencia del lenguaje, ya que todos ellos

tienen acceso a las mismas funcionalidades.

(1) La depuración, la gestión de ex-cepciones y la gestión de memoriason tareas del CLR, como veremosmás adelante. Tanto la FCL comoel CLR son comunes para todos loslenguajes .NET.


El .NET Framework incluye cuatro lenguajes de programación desarrolla-

dos por Microsoft: C#, Visual Basic .NET, C++.NET y J#. Aparte de estos

lenguajes, existen otros lenguajes .NET desarrollados por otras compañías

o grupos de entusiastas. La creación de lenguajes .NET por grupos o em-

presas ajenas a Microsoft es posible gracias a que la especificación de los

lenguajes .NET es un estándar.

• Facilita el desarrollo. El .NET Framewok está diseñado enteramente bajo el

paradigma de la orientación a objetos. Esto facilita el desarrollo de nuevos

componentes, y el uso de los componentes disponibles en la librería de

clases.

La librería de clases de .NET Framework incluye multitud de componen-

tes que encapsulan tareas comunes, como el acceso a bases de datos, la

creación y gestión de formularios de usuario, la creación y control de th-

reads2 de ejecución, etc.

Además, algunas de las tareas necesarias en COM como la gestión de me-

moria o el control de punteros, que son fuente de muchos de los proble-

mas de falta de memoria o de accesos incorrectos, han sido eliminados,

gracias a la implementación de un gestor automático de memoria, y al

uso de referencias en vez de punteros3.

(2) Los threads o hilos de ejecuciónson subprogramas que se ejecu-tan dentro de un mismo procesosimultáneamente, compartiendosus recursos

(3)Tanto los punteros como las re-ferencias contienen direccionesde memoria. La diferencia funda-mental es que mediante un punte-ro se puede consultar la direcciónde memoria que almacena, mien-tras que con una referencia sólo sepuede acceder al valor que se al-macena en la dirección de memo-ria que indica la referencia.

• Simplifica la instalación. Los componentes .NET no necesitan añadir in-

formación en el registro del sistema para funcionar, ni es necesario definir

interfaces MIDL4 para su utilización, ya que son autodescriptivos. Esto im-

plica que los componentes .NET se pueden instalar simplemente copian-

do los ensamblados correspondientes en la carpeta deseada de la máquina

destino. El único requisito es que el motor de ejecución del .NET Frame-

work esté instalado.

Por otro lado, es posible tener más de una versión de un mismo compo-

nente coexistiendo en el mismo ordenador, de forma que si una deter-

minada aplicación necesita una versión anterior a otra más moderna, re-

cientemente instalada, puede seguir funcionando sin problemas. De esta

forma, se soluciona el problema del llamado DLL 5 Hell de los componen-

tes COM, en que al instalar una nueva versión de una dll se sobrescribía la

anterior, de forma que si una aplicación requería la versión antigua, ésta

podía dejar de funcionar, por ejemplo porque una de las funciones que

utilizaba de la dll antigua ya no estaba disponible o tenía un comporta-

miento diferente en la nueva.

• Seguridad. El .NET Framework permite definir los permisos otorgados a

un programa para realizar unas u otras acciones. Por ejemplo, se puede

(4)MIDL (Microsoft interface defini-tion language) es el lenguaje utili-zado para describir los componen-tes COM y sus funcionalidades, pa-ra que puedan ser utilizados porotras aplicaciones.

(5)DLL (dynamic link library). Fiche-ros binarios que contienen un con-junto de funcionalidades comunesque forman parte de una aplica-ción. Las dll se pueden compartirentre aplicaciones, favoreciendo asíla reutilización de componentes.Las librerías .NET también tienenextensión .dll, pero el formato delfichero es totalmente distinto.


permitir a un programa que lea de un fichero pero que no pueda escribir

sobre él.

1.2. Versiones de NET

Desde la aparición de la primera versión estable de .NET en 2002, Microsoft

ha continuado añadiendo funcionalidades a la plataforma y mejorando sus

herramientas de desarrollo.

A continuación, veremos las diferentes versiones de .NET existentes. Todas

ellas pueden coexistir en un mismo sistema operativo, de forma que se pue-

den ejecutar aplicaciones realizadas en una u otra versión sin problemas de

compatibilidad, y están disponibles como descarga independiente y gratuita

en el sitio de descargas de Microsoft:

• .NET Framework 1.0. La primera versión del .NET Framework apareció en

2002, aunque ya existían algunas betas desde finales de 2000. Junto con

esta versión del .NET Framework aparece también Visual Studio .NET 2002,

la nueva versión del entorno de desarrollo de Microsoft, después de la ver-

sión 6.0 para tecnologías anteriores a .NET.

• .NET Framework 1.1. La versión 1.1 aparece en 2003 junto con la nueva

versión de la herramienta de desarrollo Visual Studio .NET 2003 y el sis-

tema operativo Windows Server 2003. Este sistema operativo incluye el

.NET Framework como componente instalable.

En esta versión, se mantiene el mismo motor de ejecución que en la an-

terior, aunque incluye bastantes mejoras respecto de la versión 1.0, entre

otras incluye una versión del .NET Framework para dispositivos móviles

conocido como .NET Compact Framework. También se incluyen herra-

mientas para interoperar con la suite ofimática Office 2003, que también

aparece este mismo año.

• .NET Framework 2.0. Esta nueva versión del .NET aparece en 2005, junto

con Visual Studio 2005 (la palabra .NET desaparece del nombre del pro-

ducto) y SQL Server 2005 (la nueva versión del motor de bases de datos de

Microsoft, después de 5 años). También se crea una nueva revisión del sis-

tema operativo Windows Server 2003 R2, que incluye esta nueva versión

del .NET Framework en vez de la versión 1.1.

Esta versión incluye cambios sustanciales tanto en el CLR como en los len-

guajes .NET, como son los tipos genéricos o los tipos abstractos. También

aparece una segunda versión del .NET Compact Framework para disposi-

tivos móviles. Otra de las mejoras importantes consiste en la integración

del CLR dentro del motor de bases de datos SQL Server 2005, de forma que

es posible crear elementos de programación de la base de datos, utilizando

lenguajes y tecnologías .NET.


• .NET Framework 3.0. Junto con la aparición de Windows Vista en 2006,

aparece también la nueva versión del .NET Framework, incluida como

componente de dicho sistema operativo. A pesar de que es un cambio de

versión importante (de la 2 a la 3), la versión 3.0 mantiene el mismo motor

de ejecución y librerías que la versión 2.0. La gran novedad en esta versión

son las cuatro nuevas tecnologías que incorpora a las ya existentes en el

.NET 2.0, son las siguientes:

– Windows presentation foundation (WPF).Proporciona un conjunto de

funcionalidades para desarrollar interfaces gráficas independientes de

la plataforma, que utilicen todo tipo de elementos gráficos avanzados

como dibujo vectorial, gráficos en 3-D, vídeo, audio, etc.

– Windows communication foundation (WCF). Ofrece un conjunto de fun-

cionalidades que facilitan la creación de aplicaciones SOA orientadas

a servicio (Service Oriented Architecture).

– Windows workflow foundation (WWF). Incluye funcionalidades y herra-

mientas para crear flujos de trabajo que se pueden ejecutar desde una

aplicación.

– Windows cardspace (WCS). Permite almacenar de forma segura la iden-

tidad digital de una persona y proporciona una interfaz unificada para

escoger la identidad para una transacción particular como por ejemplo

autenticarse en un website.

Estructura del .NET Framework 3.0

• .NET Framework 3.5. La siguiente versión del .NET Framework está previs-

ta para finales de 2007, principios de 2008, junto a la aparición de Visual

Studio 2008, SQL Server 2008 y Windows Server 2008, que incluirá esta

versión como componente del sistema operativo. También aparecerá por

entonces la correspondiente versión del Framework para dispositivos mó-

viles (.NET Compact Framework 3.5).

En esta versión del Framework sí que se incluye una nueva versión del mo-

tor de ejecución de .NET, para ofrecer las funcionalidades necesarias para

algunas de las características que se incluyen en ella, como por ejemplo

LINQ o lambda expressions.


2. Common Language Runtime (CLR)

El componente principal del .NET Framework es el CLR 6(common language

runtime), que como su nombre indica, es el motor de ejecución de las aplica-

ciones .NET, es decir, que sin CLR las aplicaciones .NET no se podrían ejecutar.

En este apartado, estudiaremos las funciones que realiza el CLR, y cuál es el

proceso de ejecución de una aplicación .NET.

2.1. Funciones del CLR

La principal función del CLR es la de ejecutar aplicaciones .NET dentro de un

entorno gestionado7. El proceso de ejecución de aplicaciones .NET se explica

más adelante dentro de este mismo capítulo. Otras funcionalidades del CLR,

relacionadas con la ejecución de aplicaciones, son las siguientes:

• Verificación de código. El CLR comprueba que el código sea correcto, es

decir, que no realice operaciones inseguras, como accesos ilegales a me-

moria o llamadas incorrectas a métodos.

• Seguridad. Durante la ejecución de una aplicación .NET, el CLR comprueba

que las acciones que realiza una aplicación están permitidas por la política

de seguridad establecida. En caso contrario se lanza una excepción y se

termina la ejecución de la aplicación.

• Gestión automática de memoria. El CLR gestiona automáticamente la me-

moria utilizada por las aplicaciones .NET. Cuando una porción de memo-

ria deja de ser utilizada por la aplicación, uno de los componentes del CLR,

llamado garbage collector (recolector de basura), libera automáticamente

esa zona de memoria para que vuelva a estar disponible de nuevo.

• Control de excepciones y depuración. El control de excepciones (errores) y

los mecanismos de depuración, son controlados por el CLR. De este modo,

es posible realizar la depuración de una aplicación multilenguaje, o lanzar

excepciones entre tipos creados en lenguajes distintos.

• Gestión de versiones. Cada componente o aplicación .NET tiene asociado

un número de versión, que permite al CLR determinar los componentes

necesarios que son compatibles con la versión de la aplicación a ejecutar.

Si no se encuentra ninguna versión compatible de alguno de los compo-

nentes necesarios, se produce un error de compatibilidad. Por otro lado,

es posible tener más de una versión del mismo componente instalado en

el sistema, de forma que si se instala una versión nueva de un componen-

(6)Existe una especificaciónECMA del CLR, llamada CLI(Common Language Infrastruc-ture), disponible en <http://msdn.microsoft.com/ca-es/netfra-mework/default(en-us).aspx>.Por otro lado, existe una imple-mentación libre del CLI desarrolla-da por Microsoft, llamada SSCLI(Share source CLI) y disponible en<http://code.msdn.microsoft.com/ssclimsbuild>.

(7)Un entorno gestionado es uncontexto de ejecución de aplica-ciones que gestiona los recursos, lamemoria, asegura la ejecución decódigo seguro, etc.

http://msdn.microsoft.com/ca-es/netframework/default(en-us).aspx



http://code.msdn.microsoft.com/ssclimsbuild

http://code.msdn.microsoft.com/ssclimsbuild


te, las aplicaciones que utilizan la versión antigua siguen funcionando co-

rrectamente.

• Instalación simplificada. El CLR no necesita guardar ninguna información

de los componentes .NET en el registro del sistema para su ejecución. Esto

evita los problemas de integridad del registro que pueden provocar que

una aplicación deje de funcionar.

El hecho de que no se necesite ninguna información adicional para ejecu-

tar una aplicación, aparte de los ficheros de la propia aplicación, hace que

el impacto de instalación sea cero, y que sea mucho más sencillo instalar

aplicaciones; simplemente, basta con copiar los ficheros del lugar de ins-

talación al directorio destino.

• Interoperabilidad con código no gestionado. Aparte de ejecutar aplicacio-

nes gestionadas, el CLR permite interactuar con código no gestionado8.

Todo el código que no es ejecutable por el CLR se denomina unmanaged co-

de (código no gestionado o no administrado). Por ejemplo, todas las apli-

caciones de win32 o COM son unmanaged code.

.NET ofrece una serie de ventajas sobre el código no administrado, pero

a veces no es posible traducir todas las aplicaciones de una empresa a la

nueva plataforma por el coste que ello supondría. Por eso, el CLR ofrece

mecanismos de interoperabilidad con código no administrado, de forma

que se puedan desarrollar nuevas funcionalidades en .NET aprovechando

lo anterior, y sin problemas de interacción. Concretamente el CLR sopor-

ta:

(8) Se conoce como código gestio-nado el código que administra ogestiona el CLR, es decir, el códi-go generado por lenguajes .NET.El código no gestionado, por lotanto, es aquel código que no es.NET, y que no se ejecuta dentrodel CLR.

• Código gestionado que utiliza funciones no gestionadas desde una .dll. El

mecanismo de P/Invoke9 permite realizar llamadas a funciones que se en-

cuentran en librerías dinámicas o dll del sistema o de aplicaciones win32.

• Código gestionado que utiliza componentes COM. El .NET Framework

incorpora la herramienta TlbImp.exe, que permite crear un componente

.NET que describe el objeto COM y que permite comunicarse con él.

Utilización de un componente COM desde un objeto .NET

• Código no gestionado que utiliza un tipo gestionado. Mediante las herra-

mientas Tlbexp.exe y Regasm.exe, incluidas en el .NET Framework, es po-

sible crear un objeto COM que describa y se comunique con el tipo ges-

tionado, y registrarlo en el sistema de forma que otras aplicaciones COM

puedan utilizarlo.

(9) P/Invoke: Plattform Invoke


Utilización de un objeto .NET desde un componente COM

2.2. Proceso de ejecución de una aplicación .NET

Desde que se escribe el código fuente de una aplicación en un determinado

lenguaje de programación .NET, hasta que la aplicación se ejecuta en el CLR,

existe una serie de pasos o transformaciones. El siguiente gráfico resume estos

pasos, que estudiaremos a continuación:

Proceso de compilación y ejecución de una aplicación .NET

Los rectángulos amarillos representan los diferentes estados por los que pasa

el código, mientras que los verdes representan las etapas por las que pasa el

código hasta ser ejecutado. El recuadro azul delimita las etapas que lleva a cabo

el CLR.

2.2.1. Compilación

Los programas o componentes .NET se escriben en ficheros de código fuente,

generalmente ficheros de texto con una u otra extensión en función del len-

guaje de programación utilizado.

El proceso de compilación consiste en traducir el código fuente a código IL,

también llamado MSIL (intermediate language o Microsoft intermediate langua-

ge), un lenguaje intermedio parecido al código máquina, pero que no puede ser

ejecutado directamente por el procesador (es independiente del procesador).


Todos los lenguajes de .NET compilan a un código intermedio común deno-

minado MSIL (MicroSoft intermediate language) o simplemente IL (intermediate

language). De esta forma, los componentes se ejecutan igual en el CLR inde-

pendientemente del lenguaje y de la plataforma en los que fueron creados.

La tarea de compilación se lleva a cabo mediante una aplicación llamada com-

pilador. Cada compilador permite compilar código fuente escrito en un len-

guaje de programación concreto. Todos los compiladores de lenguajes .NET

traducen el código fuente a IL.

El código IL generado por los compiladores se almacena en un fichero llamado

PE (portable executable), que contiene el código IL junto con sus metadatos.

Los metadatos son la descripción de los tipos de datos definidos en el código

IL, sus métodos, sus atributos, etc. Los metadatos son necesarios para ejecutar

aplicaciones, para verificar que el código IL que se ejecuta es correcto y evitar

operaciones inválidas. Veremos la estructura de los ficheros PE en el apartado

de ensamblados, más adelante en este mismo capítulo.

2.2.2. Enlazado

Para que el CLR pueda ejecutar una aplicación, es necesario agrupar todos los

archivos PE generados en una estructura lógica llamada ensamblado10 . Este

paso se denomina enlazado (link), y por lo general se realiza conjuntamente

con el proceso de compilación.

Un ensamblado puede estar formado por uno o más ficheros PE como ya ve-

remos más adelante, aunque generalmente los ensamblados están formados

por un único fichero PE con extensión .dll o .exe.

Los ensamblados contienen, además de los ficheros PE, un conjunto de infor-

mación acerca del propio ensamblado (versión, referencias externas, etc.), que

se denomina manifest. Hablaremos con más detalle de los ensamblados más

adelante en otro apartado.

2.2.3. Creación de un dominio de aplicación

Todas las aplicaciones .NET se ejecutan dentro de un dominio de aplicación

(application domain), una estructura del CLR que es la unidad de aislamiento

de la aplicación, garantizando que ésta no puede acceder directamente a los

recursos o al código de otras aplicaciones, y que un fallo en una aplicación

no afecta a las demás.

El concepto de application domain es similar al de un proceso del sistema ope-

rativo; la diferencia está en que un dominio de aplicación requiere menos re-

cursos que un proceso del sistema. De hecho, un proceso puede alojar más de

un dominio de aplicación.

(10) Aunque la extensión de los en-samblados coincide con la de las li-brerías dinámicas (.dll) o los archi-vos ejecutables de Windows (.exe),el contenido de estos ficheros sólose puede ejecutar mediante el CLR.


Al ejecutarse una aplicación .NET, existe una aplicación llamada CLR Host,

que se encarga de iniciar un proceso con el CLR (si no está ya iniciado), y crear

uno o más dominios de aplicación en el proceso del CLR para poder ejecutar

la aplicación. Ejemplos de aplicaciones CLR Host son ASP.NET, y el cargador

de aplicaciones .exe del shell de Windows.

2.2.4. Cargador de clases

Una vez creado el domino de la aplicación, el cargador de clases del CLR se

encarga de buscar y cargar en memoria las clases necesarias para ejecutar la

aplicación. Las clases necesarias se pueden encontrar en el propio ensamblado

de la aplicación o en otros ensamblados referenciados por éste.

2.2.5. Compilación JIT

Los procesadores actuales no son capaces de ejecutar las instrucciones IL di-

rectamente, aunque puede que esto sea posible en el futuro. Por ello, es nece-

sario un proceso de traducción de código IL al código máquina del procesador

en el que se está ejecutando la aplicación.

Antes de ejecutar un método, el CLR detecta todos los tipos de datos referen-

ciados en su código y guarda, en una estructura de datos interna, toda la in-

formación sobre los métodos de estos tipos y las direcciones donde se puede

encontrar su código fuente.

La primera vez que un método gestionado es invocado, el código IL correspon-

diente es traducido a código máquina por un compilador llamado JIT compi-

ler (just-in-time compiler). El código máquina generado por el JIT compiler se

almacena en memoria, de forma que la próxima vez que se ejecuta ese método

no es necesario volver a traducir su código IL a nativo.

No obstante, el código nativo generado se borra una vez termina la ejecución

de la aplicación, es decir, que la próxima vez que se ejecute se volverá a traducir

el código IL a nativo. Aunque esto pueda parecer una pérdida de eficiencia

respecto a las aplicaciones nativas, el proceso de conversión de IL a código

nativo está optimizado para cada tipo de procesador, por lo que en global el

rendimiento es similar. En todo caso, es posible precompilar una aplicación

.NET para un procesador concreto con la aplicación Ngen.exe incorporada

en el .NET Framework SDK si es necesario maximizar el rendimiento, pero

entonces perderemos la compatibilidad con otras plataformas.

Durante el proceso de JIT, aparte de traducir el código a nativo, se verifica el

código para asegurar que no realiza operaciones de acceso a memoria inco-

rrectas, que los métodos se llaman con el número de parámetros correctos,


que los tipos de los parámetros y del retorno coinciden, etc. Para realizar estas

comprobaciones, el CLR utiliza la información sobre los tipos de datos alma-

cenados en los metadatos del ensamblado.

Si se determina que el código IL no es seguro, se lanza una excepción y el

método no se ejecuta. Los compiladores de C#, Visual Basic .NET y J# producen

siempre código IL seguro.

Los tipos de compilador JIT son los siguientes:

• Normal. El código nativo generado a partir del código MSIL está optimi-

zado para aprovechar al máximo las prestaciones de la máquina en la que

se ejecuta la aplicación. Es un proceso más lento, pero el código generado

es más eficiente y rápido.

• Econo. No optimiza el código nativo; simplemente traduce el código MSIL

a nativo. Es más rápido, pero el código resultante es más lento.

• Pre-JIT. El código MSIL se traduce enteramente a código nativo y se alma-

cena para próximos usos.

Las características de la compilación JIT son las siguientes:

• Independencia de la plataforma. El código MSIL es común para todas las

plataformas. Es en el proceso de compilación JIT cuando se transforman

en código nativo, por eso no es necesario compilar una versión diferente

de la aplicación para cada plataforma.

• Interoperabilidad entre lenguajes. Todos los compiladores de lenguajes

.NET generan código MSIL, que es posteriormente compilado por el JIT-

compiler, independientemente del lenguaje original en el que fue desarro-

llada la aplicación. Es más, diferentes ensamblados pueden proceder de

código fuente escrito en lenguajes diferentes.

• Compilación bajo demanda. El código MSIL se va traduciendo a código

nativo a medida que se va necesitando, es decir, a medida que el progra-

ma se va ejecutando se compilan los métodos solicitados que no han si-

do compilados previamente. El código nativo generado se guarda para su

posterior uso. Esto evita que se compilen partes del código MSIL que qui-

zás no se usen casi nunca hasta que no sea necesario.


2.2.6. Ejecución CLR

El código generado por el compilador JIT se denomina código nativo gestio-

nado, porque se ejecuta dentro del entorno del CLR, es decir, el CLR gestiona

la ejecución de ese código de forma que no se puedan producir referencias in-

válidas, controla la memoria, comprueba la seguridad, etc. Este código sí que

es ejecutable directamente por el procesador.


3. Common type system (CTS)

El CTS o sistema común de tipos, define las reglas que debe cumplir la defini-

ción de un tipo para que pueda ser gestionado por el CLR. El CTS permite la

interoperabilidad de tipos entre distintos lenguajes .NET, ya que todos ellos

deben seguir las normas establecidas en el CTS. Entre otras ventajas del CTS

conviene destacar las siguientes:

• Facilita la reutilización de código

• Provee a los lenguajes .NET de un modelo de objetos uniforme (misma

forma de gestionar los eventos, excepciones, etc.)

• Proporciona un modelo de ejecución común

3.1. Elementos del CTS

Los elementos del CTS son los siguientes:

• Un modelo de objetos común (.NET framework)

• Implementación común de los tipos de datos básicos (FCL)

• Una especificación común para asegurar la compatibilidad entre lenguajes

(CLS)

3.2. Tipos valor frente a Tipos referencia

Todos los tipos .NET heredan directa o indirectamente del tipo predefinido

System.Object, independientemente del lenguaje de programación utilizado.

El CTS divide los tipos de datos en las dos categorías siguientes:

• Tipos valor. Son los tipos primitivos del lenguaje: enteros, reales, caracte-

res, etc. Los tipos valor de .NET, a diferencia de otros lenguajes orientados

a objeto, son también objetos, y por lo tanto se pueden utilizar en los mis-

mos contextos en los que se utilizan el resto de tipos.

• Tipos referencia. Los tipos referencia representan objetos más complejos,

con una serie de propiedades y de funcionalidades.

La diferencia fundamental entre los tipos valor y referencia es que los tipos

valor se almacenan en la pila de ejecución del programa, mientras que los

tipos referencia se almacenan en una zona especial de memoria denomi-

nada heap. En la pila de ejecución, se añade una referencia (dirección de

memoria) que indica la localización de los datos del tipo en el heap.


3.3. Tipos de miembros

Todos los tipos tienen a su vez un conjunto de 0 o más miembros o elementos

que definen el estado y el comportamiento del tipo. Los diferentes tipos de

miembro definidos por el CTS son los siguientes:

• Campo (field). Una variable que forma parte del estado del objeto. Se iden-

tifican por su nombre y su tipo.

• Método. Una función o acción que ejecuta una operación o cambio sobre

el estado del objeto.

• Propiedad. Una propiedad es un método doble (lectura/escritura) de un

campo del tipo. Las propiedades se pueden utilizar como un campo públi-

co, aunque realmente están formadas por uno o dos métodos de acceso.

• Evento. Un evento es un mecanismo de notificación entre objetos. Los

objetos interesados se registran en el evento, y cuando sucede un cambio

en el estado del objeto relacionado con el evento se les notifica.

3.4. Visibilidad

La visibilidad define, para cada elemento o miembro de un tipo, quién puede

acceder a su información:

• Privado. El miembro sólo es accesible desde el propio tipo.

• Familiar. El miembro sólo es accesible desde el propio tipo o desde cual-

quier tipo derivado.

• Ensamblado. El miembro es accesible desde cualquier tipo que se encuen-

tre dentro del mismo ensamblado.

• Público. El miembro es accesible desde cualquier otro tipo.

Las palabras clave para definir el tipo de visibilidad de un miembro depen-

den del lenguaje de programación. En C# estas palabras son respectivamente:

private, protected, internal y public.

Aparte de los tipos de visibilidad anteriores, también existen los dos siguien-

tes, menos frecuentes y no disponibles en todos los lenguajes, aunque si so-

portados por el CTS:


• Familiar y ensamblado. El miembro es accesible por tipos derivados que

estén en el mismo ensamblado. En C# no existe este tipo de visibilidad.

• Familiar o ensamblado. El miembro es accesible por tipos derivados y por

los tipos que estén en el mismo ensamblado. En C# se define como pro-

tected internal.

3.5. CLS Common language specification

Los lenguajes de programación tienen muchas diferencias entre sí. Si se quiere

que todos los tipos de datos que se creen con un lenguaje sean compatibles

con otros lenguajes .NET, es necesario utilizar sólo aquellas características que

estén disponibles en otros lenguajes. Para ello, Microsoft ha definido la Com-

mon language specification (CLS), que determina el conjunto mínimo de carac-

terísticas que tienen que soportar los compiladores para poder emitir código

IL que funcione sobre el CLR y que sea compatible con otros lenguajes.

El CLR/CTS soporta muchas más funcionalidades de las que se definen en el

CLS, por lo que, si la interoperabilidad entre lenguajes no es importante, se

pueden utilizar estas características para crear tipos más complejos, aunque no

estarán disponibles desde otros lenguajes.

Los lenguajes de programación como C#, Visual Basic .NET, o cualquier otro

lenguaje .NET, implementan todas las características descritas en el CLS, aparte

de otras características disponibles en el CLR/CTS, es decir, que cada lenguaje

implementa un superconjunto del CLS, y un subconjunto diferente, (aunque

posiblemente no disjunto), del CLR/CTS. El siguiente gráfico ilustra lo ante-

rior:

Esquema de compatibilidad entre lenguajes


4. Framework Class Library (FCL)

La librería de tipos comunes (FCL, framework class library) es el conjunto de

clases y otros componentes que incorpora el .NET Framework. Su principal

característica es que es independiente del lenguaje de programación utilizado,

es decir, están disponibles para todos los lenguajes .NET. La FCL incluye los

tipos básicos necesarios para desarrollar cualquier tipo de aplicación en .NET;

entre otros, los siguientes:

• Servicios web

• Formularios Windows (WinForms)

• Formularios web (ASP.NET)

• Aplicaciones de consola

• Servicios de Windows

• Librerías de componentes

La FCL está diseñada completamente bajo el concepto de orientación a obje-

tos, por lo que es mucho más sencilla de utilizar y de comprender que otras

APIs de programación anteriores como COM11, ATL12 o MFC13.

La FCL está organizada como una estructura de directorios, para organizar los

tipos por funcionalidades. Los directorios se denominan namespaces (espacios

de nombres), y pueden a su vez contener tipos u otros namespaces.

Cada namespace se identifica por un nombre descriptivo de la funcionalidad

de los tipos que contiene. Dentro de un namespace cada elemento (tipo o na-

mespace) debe tener un nombre único.

No obstante, pueden existir elementos con el mismo nombre si se hallan en

namespaces distintos. Por ello, para identificar y diferenciar elementos con el

mismo nombre, se utiliza toda la ruta de acceso al elemento.

La ruta completa de acceso a un elemento es una lista de los nombres de names-

paces en los que está contenido el elemento, separada por puntos. Por ejemplo,

el elemento C contenido en el namespace B que, a su vez, está contenido en el

elemento A, se identifica unívocamente como indica la siguiente expresión:

A.B.C

El namespace principal del .NET Framework es 'System', donde se en-

cuentran clases básicas como Object, Console o los tipos pri-

mitivos. El namespace System contiene a su vez otros namespa-

(11)COM (Component Object Mo-del).

(12)ATL (Active Template Library).

(13)MFC (Microsoft FoundationClass Library).


ces como System.Windows, System.Web, System.WebServices,

System.Security, o System.Data, que a su vez contienen nuevos tipos

y otros namespaces.

4.1. Funcionalidades principales de la FCL

Dentro de las muchas funcionalidades existentes en la FCL, podemos destacar

algunas de las tecnologías más importantes de .NET, que son las siguientes:

• Acceso a las funciones del sistema operativo. La FCL contiene clases y mé-

todos que permiten acceder a las diferentes funcionalidades del sistema

operativo, entre ellas las siguientes:

– Gestión del sistema de ficheros (System.IO)

– Gestión de seguridad (System.Security)

– Comunicaciones de red (System.Net)

– Threads y procesos (System.Threading)

• ASP.NET (System.Web). ASP.NET es la nueva versión de páginas web di-

námicas de Microsoft. Es un nuevo entorno, desarrollado desde cero (no

está basado en ASP14, la versión anterior) que se ejecuta en Internet Infor-

mation Services (IIS) y simplifica a los programadores la escritura de códi-

go para construir páginas web basadas en HTML que se muestran en un

explorador.

ASP.NET caracteriza una forma nueva, independiente del lenguaje, de es-

cribir código y ligarlo a peticiones de páginas web. Introduce los formula-

rios de web de .NET, que consiste en un modelo de programación dirigido

por eventos para interactuar con controles que hace que la programación

de una página web parezca muy similar a la programación de un formu-

lario de Windows Forms.

ASP.NET contiene características importantes de seguridad y administra-

ción del estado de la sesión. Es más robusto y contiene muchas mejoras

en su comportamiento respecto al ASP original.

• WinForms (System.Windows.Forms) WinForms es el homólogo a los for-

mularios web de ASP.NET para las aplicaciones de Windows. Permite de-

sarrollar fácilmente interfaces gráficas potentes, sin tener que escribir más

código de la cuenta. Visual Studio proporciona un diseñador de formula-

rios, que permite desarrollar la interfaz gráfica con WinForms de manera

visual.

• ADO.NET (System.Data). ADO.NET es una versión mejorada y rediseña-

da dentro de .NET de la librería de acceso a fuentes de datos ADO. Como

cosas más interesantes, ADO.NET incorpora mejores funcionalidades para

trabajar con datos XML, y permite trabajar con fuentes de datos en modo

desconectado, es decir, sin necesidad de mantener abierta la conexión con

(14)ASP (Active Server Pages) esuna tecnología para desarrollarpáginas web dinámicas. El clienterealiza una petición al servidor, és-te la procesa, y devuelve una pági-na HTML generada dinámicamen-te en función de las peticiones delusuario. ASP y ASP.NET se ejecu-tan sobre IIS, el servidor de pági-nas web de Microsoft Windows


la base de datos todo el rato, únicamente cuando es necesario. Esto hace

que mejore el rendimiento de las aplicaciones.

• Enterprise Services (COM+) (System.EnterpriseServices). COM+, co-

nocido dentro de Microsoft .NET como Enterprise Services, es una versión

mejorada de COM que pretende solucionar alguno de los problemas que

presenta el antiguo COM. El .NET Framework proporciona acceso total

a los servicios COM+ mediante el mecanismo de interoperabilidad con

COM.

Además, COM+ ofrece todo un conjunto nuevo de funcionalidades que

facilitan el desarrollo de aplicaciones empresariales como transacciones,

object pooling o queued components.

4.2. Otros namespaces de la FCL

A continuación, se enumeran otros namespaces de la FCL:

• System. Tipos de datos básicos, generales.

• System.Collections. Tipos de datos utilizados para almacenar otros

tipos de datos: listas, pilas, colas, tablas de hash, etc.

• System.Diagnostics. Utilidades de depuración de aplicaciones.

• System.Drawing. Tipos para dibujo en 2D.

• System.Globalization. Utilidades para facilitar la internacionaliza-

ción de aplicaciones.

• System.Reflection. Utilidades para inspeccionar tipos en tiempo de

ejecución.

• System.Text. Utilidades para trabajar con texto en diferentes codifica-

ciones (ASCII, unicode, etc.)

• System.Xml. Utilidades que permiten trabajar con documentos XML.


5. Ensamblados

Un ensamblado (assembly en inglés), es la unidad mínima de organización de

las aplicaciones .NET, es decir, una aplicación .NET se compone de uno o más

ensamblados. Tal y como vimos en el proceso de ejecución de una aplicación

.NET, los ensamblados son el resultado de la compilación y enlazado, y el pun-

to de entrada al CLR. En este apartado, estudiaremos a fondo las características

de los ensamblados y su utilización.

5.1. Características de los ensamblados

Las características de los ensamblados son las siguientes:

• Definen una barrera de seguridad. El ensamblado es la unidad más peque-

ña sobre la que se pueden pedir y conceder permisos de seguridad.

• Crean un marco de definición de tipos. Cada tipo está identificado por el

ensamblado en el que se encuentra. De este modo, dos tipos con el mismo

nombre pero en ensamblados diferentes pueden ser diferenciados.

• Son autodescriptivos. Un ensamblado contiene el código IL necesario para

ejecutar los tipos incluidos en él, además de la descripción de su estruc-

tura (metadatos), información necesaria para acceder a ellos y utilizarlos

correctamente, y un conjunto de información adicional sobre el ensam-

blado, conocido como manifest.

Una de las mayores ventajas de esta característica es que los ensamblados

y, por lo tanto, las aplicaciones .NET en general son independientes del

registro del sistema, ya que incorporan toda la información necesaria para

ser ejecutados, no necesitan añadir ninguna entrada al registro del sistema.

• Son la unidad mínima de instalación. Al instalar una aplicación, ésta in-

cluye todos los ensamblados que necesita para ser ejecutada. Si se elimina

la aplicación, sólo se eliminan los ensamblados correspondientes, por lo

que el resto de aplicaciones continúan funcionando correctamente.

• Son la unidad mínima de versionado. A todos los tipos incluidos dentro de

un ensamblado se les asigna la misma versión. En los metadatos se incluye

información sobre las dependencias entre versiones con otros ensambla-

dos.

Es posible mantener varias versiones de un mismo ensamblado en la mis-

ma máquina. A la hora de ejecutar una aplicación que utilice ese ensam-

blado, se buscará y utilizará una versión del ensamblado que sea compa-

tible con ella.


5.2. Tipos de ensamblados

Existen tres tipos de clasificaciones para los ensamblados:

• Estáticos o dinámicos. Un ensamblado estático es un ensamblado alma-

cenado en uno o más ficheros. Los ensamblados dinámicos, en cambio,

son ensamblados generados en tiempo de ejecución y se almacenan en

memoria.

Para poder instalar y ejecutar una aplicación en una máquina son necesa-

rios ensamblados estáticos. Los ensamblados dinámicos se utilizan cuan-

do es necesario crear programas y ejecutarlos durante la ejecución de una

aplicación.

• Fichero único o múltiples ficheros. Como ya hemos visto en el proceso de

ejecución de una aplicación .NET, el código IL de un programa se almacena

en un fichero PE (portable executable) también llamado modulo gestionado

(porque contiene código gestionado, es decir código IL). Existen tres tipos

de archivo PE: .netmodule, .DLL y .EXE. Por otro lado, el manifest de un

ensamblado se almacena siempre dentro de un fichero .EXE o .DLL.

En conclusión, un ensamblado puede estar formado por un único fichero

.DLL o .EXE o por más de un fichero .netmodule más un fichero .DLL o

.EXE.

• Ensamblados públicos o privados. Un ensamblado privado es utilizado,

únicamente, por una aplicación, y se almacena en el directorio en el que se

encuentra esa aplicación. Los ensamblados públicos o compartidos se ins-

talan en un directorio común de ensamblados llamado Global Assembly

Cache o GAC, de forma que es accesible desde cualquier aplicación .NET

instalada en la máquina.

5.3. Estructura de un ensamblado

En el proceso de ejecución de una aplicación .NET, comentamos que, aparte

del conjunto de ficheros PE, un ensamblado contiene una serie de informa-

ción adicional específica, denominada manifest. Esta información puede estar

contenida junto con los metadatos de uno de los archivos PE del ensamblado,

o bien en un archivo PE aparte. Además, un ensamblado puede contener una

serie de recursos como imágenes o iconos utilizados por la aplicación. La in-

formación contenida en el manifest es la siguiente:

• Los datos identificadores del ensamblado son los siguientes:

– Nombre del ensamblado

– Número de versión

– Lenguajes soportados

– Procesadores y sistemas operativos soportados

Bibliografía

Más información sobre elmanifest en: NET FrameworkDeveloper's Guide, AssemblyManifest.

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




– Información de strong name

• Una tabla de ficheros que indica todos los ficheros que forman parte del

ensamblado, incluyendo ficheros .netmodule y recursos incluidos.

• Información de los tipos contenidos en el ensamblado.

• Una lista de dependencias externas a librerías dll u otros archivos externos

necesarios.

Un ensamblado está formado por un conjunto de ficheros. Por lo general, la

forma más común de ensamblado es la de un único fichero PE con la infor-

mación del manifest incluida. Este es el tipo de ensamblados que se obtienen

cuando se crea un fichero PE de tipo .dll o .exe y no se añade ningún otro

archivo PE mediante la opción /addmodule del compilador (Los ensamblados

que produce Visual Studio se componen siempre de un único fichero).

Estructura de un ensamblado de un único fichero

La opción /addmodule permite crear ensamblados de múltiples ficheros PE de

tipo .netmodule. En este caso, el manifest estará en un archivo PE .dll o .exe

resultado de la compilación, o en uno independiente. Los ensamblados de

múltiples ficheros son útiles, sobre todo, cuando se quiere incluir en un mismo

ensamblado módulos que provienen de lenguajes de programación distintos.


Estructura de un ensamblado multifichero, con manifest incluido en uno de los módulos

Estructura de un ensamblado multifichero, con manifest por separado

Otra forma de agrupar varios ficheros PE en un ensamblado es mediante la

utilidad de enlazado Al.exe, incluida en el .NET Framework SDK.

5.3.1. Visualización del contenido de un archivo PE

El .NET Framework SDK proporciona una herramienta llamada Ildasm.exe pa-

ra visualizar el contenido de un archivo PE. Con esta herramienta, podemos

ver el contenido del manifest (si se trata de un ensamblado), de los metadatos,

así como la estructura de tipos y elementos que contiene y el código MSIL

generado por el compilador.

Bibliografía

Más información sobre estaherramienta en: .NET Frame-work Developer's Guide. As-sembly Linker (Al.exe).

http://msdn.microsoft.com/en-us/library/c405shex(VS.80).aspx




Ventana principal de Ildasm. Estructura del archivo PE

Contenido del manifest de un ensamblado

5.3.2. Internacionalización

Los ensamblados también pueden tener un lenguaje o cultura asociados. En

general, cuando se desarrollan ensamblados, éstos se generan como cultura

neutral, pero cuando es necesario internacionalizar la aplicación, se puede

asignar una o más culturas al ensamblado, de forma que en función de la cul-

tura del sistema operativo donde se ejecute la aplicación, se mostrará un len-

guaje u otro.

Si se definen varias culturas para un ensamblado, se generará un ensamblado

común que contiene la funcionalidad y otros ensamblados llamados ensam-

blados satélite (uno para cada lenguaje), que contienen toda la información

referente a la cultura.


5.4. Global assembly cache

Los ensamblados comunes o compartidos son los utilizados por varias aplica-

ciones instaladas en la máquina. Por ejemplo, los ensamblados del .NET Fra-

mework son ensamblados comunes.

Anteriormente a .NET, la gestión de las librerías comunes tenía múltiples pro-

blemas, como la dependencia con el registro del sistema y los problemas de

compatibilidad entre versiones, llamado frecuentemente como el infierno de

las DLL. La gestión de ensamblados en .NET ha sido diseñada para solucionar

estos problemas.

La GAC permite compartir varias versiones de un mismo ensamblado, de for-

ma que diferentes aplicaciones que necesiten versiones diferentes puedan fun-

cionar correctamente. Las ventajas principales de almacenar un ensamblado

en la GAC son las siguientes:

• Mejora del rendimiento. Al estar en la GAC, el ensamblado no necesita ser

comprobado cada vez que se carga. Además, si hay más de una aplicación

que lo referencia sólo se carga una instancia en memoria. Por último, el

entorno de ejecución puede encontrar el ensamblado más rápidamente,

ya que es el primer lugar donde el entorno de ejecución busca los ensam-

blados referenciados por una aplicación.

• Seguridad de ficheros. Sólo el administrador del sistema puede borrar en-

samblados de la GAC.

• Gestión de versiones. Diferentes copias de un mismo ensamblado con el

mismo nombre, pero diferente versión, pueden coexistir dentro de la GAC.

Los ensamblados comunes son almacenados en un directorio llamado GAC

(global assembly cache). El contenido de este directorio se puede visualizar ex-

plorando el directorio 'Assembly' dentro de la carpeta donde están instalados

los ficheros de Windows, por ejemplo, 'C:\Windows\Assembly'. También po-

demos ver su contenido mediante la utilidad 'Configuración de Microsoft .NET

Framework 2.0' dentro de 'Herramientas administrativas' del panel de control.

Esta herramienta nos permite, además, agregar nuevos ensamblados a la GAC

o eliminar alguno de los existentes.


Visualización del contenido de la global assembly cache

Podemos desinstalar o ver las propiedades de un ensamblado mediante las

opciones del menú contextual que aparece al pulsar el botón derecho del ratón

sobre cada uno de ellos.

Propiedades de un ensamblado de la GAC

5.4.1. Strong name

Antes de compartir un ensamblado en la GAC, es necesario asignarle un strong

name. El strong name es un mecanismo de identificación única para cada en-

samblado, formado por las siguientes partes:

• Un nombre simple

• La clave publica de una clave criptográfica


• Una firma digital generada con la clave privada de la misma clave cripto-

gráfica

La clave criptográfica se puede generar con la herramienta Sn.exe del .NET

Framework. La instrucción crea una clave nueva y la guarda en el fichero

clave.snk:

sn –k clave.snk

Para firmar un ensamblado con una clave criptográfica, podemos utilizar el ar-

gumento /keyfile al compilar el ensamblado utilizando alguno de los com-

piladores de los lenguajes .NET. También es posible modificar las propiedades

del proyecto en Visual Studio para que se firme el ensamblado automática-

mente al generar el proyecto.

El strong name garantiza que el ensamblado no ha sido modificado después de

su compilación. Al ejecutar un ensamblado, el CLR realiza una comprobación

criptográfica, y si ha sido modificado desde su compilación no se ejecuta. Para

asegurar, además, que el ensamblado proviene de un origen de confianza, es

necesario utilizar certificados digitales para crear el strong name.

5.4.2. Instalación en la GAC

Una vez hemos creado un strong name para un ensamblado, ya podemos co-

locarlo dentro de la GAC. Para ello, se utiliza la herramienta GACUtil.exe del

.NET Framework SDK. Con la opción /i podemos instalar un ensamblado en la

GAC, mientras que con la opción /u podemos desinstalarlo. Para utilizar esta

herramienta, es necesario pertenecer al grupo de Administradores del equipo.

5.4.3. Versionado

El CLR usa un sistema de versionado para controlar las actualizaciones y ase-

gurar la compatibilidad. La gestión de versiones se aplica a los ensamblados

compartidos, ya que los ensamblados privados se instalan siempre en el propio

directorio de la aplicación (es responsabilidad del distribuidor de la aplicación

de que todos los componentes sean compatibles entre sí).

Cada ensamblado tiene asignadas las dos versiones siguientes:

• Un número de versión de compatibilidad formado por 4 enteros, que tiene

la siguiente estructura:

<versión mayor>.<versión menor>.<numero de

compilación>.<revisión>

Los dos primeros números identifican la versión del producto, mientras

que el tercero identifica el número de compilaciones del ensamblado que

se han realizado. Finalmente, el cuarto número se utiliza cuando hay que

repetir alguna compilación fallida.


A la hora de buscar la versión compatible de un ensamblado, se compara la

versión requerida por la aplicación con las versiones del ensamblado dis-

ponibles en el GAC. Si la versión mayor o menor es diferente, esa versión

es incompatible con la aplicación. Si la versión mayor y menor coinciden,

pero no el número de compilación, existe un riesgo de incompatibilidad,

pero si no existe ninguna otra versión con el mismo número de compa-

tibilidad se escoge el más cercano a la versión requerida. En caso de que

el único número que difiera sea el de revisión o que todos los números

coincidan, se considera que la versión es compatible.

• Un nombre a efectos de documentación.

5.4.4. Ejecución 'side-by-side'

El CLR es capaz de ejecutar varios ficheros con el mismo nombre pero situados

en lugares distintos del disco, dentro del mismo espacio de direcciones. Este

mecanismo permite la compatibilidad entre diferentes versiones de un mismo

ensamblado.


Bibliografía

Richter, Jeffrey (2002). Applied Microsoft .NET Framework Programming. Microsoft Press.

http://msdn.microsoft.com/netframework/

http://msdn.microsoft.com/netframework/

Framework .net

Education

Transcript of Framework .net