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ón
1
, 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 memoria
son tareas del CLR, como veremos
más adelante. Tanto la FCL como
el CLR son comunes para todos los
lenguajes .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-
reads
2
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 punteros
3
.
(2)
Los threads o hilos de ejecución
son subprogramas que se ejecu-
tan dentro de un mismo proceso
simultáneamente, compartiendo
sus recursos
(3)
Tanto los punteros como las re-
ferencias contienen direcciones
de memoria. La diferencia funda-
mental es que mediante un punte-
ro se puede consultar la dirección
de memoria que almacena, mien-
tras que con una referencia sólo se
puede 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 MIDL
4
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 por
otras aplicaciones.
(5)
DLL (dynamic link library). Fiche-
ros binarios que contienen un con-
junto de funcionalidades comunes
que forman parte de una aplica-
ción. Las dll se pueden compartir
entre aplicaciones, favoreciendo así
la reutilización de componentes.
Las librerías .NET también tienen
extensión .dll, pero el formato del
fichero 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 gestionado
7
. 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ón
ECMA 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 un
contexto de ejecución de aplica-
ciones que gestiona los recursos, la
memoria, asegura la ejecución de
código seguro, etc.

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 gestionado
8
.
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 o
gestiona el CLR, es decir, el códi-
go generado por lenguajes .NET.
El código no gestionado, por lo
tanto, es aquel código que no es
.NET, y que no se ejecuta dentro
del CLR.
• Código gestionado que utiliza funciones no gestionadas desde una .dll. El
mecanismo de P/Invoke
9
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 ensamblado
10
. 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ólo
se 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 COM
11
, ATL
12
o MFC
13
.
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 Foundation
Class 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 ASP
14
, 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) es
una tecnología para desarrollar
páginas web dinámicas. El cliente
realiza 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 del
usuario. 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 el
manifest en: NET Framework
Developer's Guide, Assembly
Manifest.

– 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 esta
herramienta en: .NET Frame-
work Developer's Guide. As-
sembly Linker (Al.exe).

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:WindowsAssembly'. 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/

Framework .net

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (12)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Framework .net

Ähnlich wie Framework .net (20)

Mehr von magister845

Mehr von magister845 (10)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Framework .net