Professional Documents
Culture Documents
NET Framework
Algo está cambiando
El mundo del desarrollo de aplicaciones se encuentra sumido en una nueva etapa de transformación y evolución hacia nuevos esquemas de trabajo.
Los factores determinantes de dicho cambio los podemos encontrar en la necesidad de utilizar Internet como vehículo de intercambio por parte de
diversos sectores de la economía.
Las empresas requieren establecer relaciones comerciales más dinámicas con sus clientes, de modo que su volumen de negocio se incremente a
través del canal de ventas electrónico (el denominado comercio electrónico o e-commerce). Por otro lado también necesitan unas relaciones
empresariales más ágiles en este mismo marco del ciberespacio (el llamado B2B o Bussiness to bussiness).
Aparte de todos estos elementos, nos encontramos con que el usuario de este medio, Internet, dispone de dispositivos cada vez más sofisticados para
desplazarse por la Red, no sólo el PC; y además, exige que todos ellos permitan un acceso rápido y sencillo, a múltiples aplicaciones simultáneamente,
con un mayor grado de interacción, y obteniendo información de un amplio conjunto de fuentes de datos; todo esto, naturalmente, sin los tradicionales
esfuerzos de configuración que requieren algunas aplicaciones.
Con el paso del tiempo, Internet se ha convertido en el principal entorno de trabajo para el desarrollo de aplicaciones que gestionan información,
haciendo que su alcance sea mayor que ningún otro medio hasta el momento. Baste pensar, que con un simple dispositivo que tenga acceso a Internet
(léase un PC) y un programa navegador, es posible acceder a infinidad de sitios web basados en este paradigma.
Sin embargo, actualmente, la comunicación entre servidores es complicada (sobre todo si residen en plataformas distintas), y la integración de
aplicaciones en dispositivos que no sean el típico PC, es limitada con las herramientas disponibles hasta la fecha. Pero no desesperemos, nos
encontramos en un momento crucial, en el que todos esos inconvenientes pueden ser salvados gracias a un nuevo avance tecnológico: Microsoft .NET.
¿Qué es .NET?
.NET es toda una nueva arquitectura tecnológica, desarrollada por Microsoft para la creación y distribución del software como un servicio. Esto quiere
decir, que mediante las herramientas de desarrollo proporcionadas por esta nueva tecnología, los programadores podrán crear aplicaciones basadas
en servicios para la web.
Las características principales que conforman .NET son las siguientes:
La plataforma .NET Framework, que proporciona la infraestructura para crear aplicaciones y el entorno de ejecución para las mismas.
Los productos de Microsoft enfocados hacia .NET, entre los que se encuentran Windows .NET Server, como sistema operativo que incluirá de
forma nativa la plataforma .NET Framework; Visual Studio .NET, como herramienta integrada para el desarrollo de aplicaciones; Office .NET;
b.Central para .NET, etc.
Servicios para .NET desarrollados por terceros fabricantes, que podrán ser utilizados por otras aplicaciones que se ejecuten en Internet.
Existen adicionalmente un conjunto de productos, que bajo la etiqueta de Servidores Empresariales para .NET (.NET Enterprise Servers) se incluyen
dentro de la estrategia .NET. Entre estos productos podemos encontrar a SQL Server 2000, BizTalk Server, Commerce Server 2000, etc. Sin embargo,
hemos de hacer una puntualización importante: estos productos no están basados en .NET Framework, pueden funcionar dentro del entorno de
ejecución de .NET Framework, pero el único producto actualmente desarrollado bajo el nuevo entorno es Visual Studio .NET.
Gracias a .NET y a su modelo de desarrollo basado en servicios, se flexibiliza y enriquece el modo en el que hasta ahora se construían aplicaciones
para Internet. La idea que subyace bajo esta tecnología, es la de poblar Internet con un extenso número de aplicaciones, que basadas en servicios para
la web (Web Services), formen un marco de intercambio global, gracias a que dichos servicios están fundamentados en los estándares SOAP y XML,
para el intercambio de información.
En este sentido, un programador puede crear Web Services para que sean utilizados por sus propias aplicaciones a modo de componentes (pero de
una forma mucho más avanzada que empleando el modelo COM clásico), siguiendo una estructura de programación ya conocida. Ver Figura 1.
Sin embargo, los Web Services traen de la mano un nuevo modelo de distribución del software; el basado en el desarrollo y publicación de Web
Services y en la suscripción a los mismos por parte de otras aplicaciones, potenciales usuarios de tales servicios. Ver Figura 2.
Proporciona un desarrollo de aplicaciones más sencillo y rápido gracias a que gran parte de las funcionalidades que tradicionalmente debía de
crear el programador, vienen implementadas en el entorno de ejecución.
Administra el código en tiempo de ejecución, en todo lo referente a su carga, disposición en memoria, recuperación de memoria no utilizada a
través de un recolector de memoria, etc.
Implementa características de gestión a bajo nivel (administración de memoria, por ejemplo), que en ciertos lenguajes, eran labor del
programador.
Proporciona un sistema común de tipos para todos los lenguajes del entorno.
Gestiona la seguridad del código que es ejecutado.
Dispone de un diseño abierto a lenguajes y herramientas de desarrollo creadas por terceros fabricantes.
Facilita enormemente la distribución e instalación de aplicaciones, ya que en teoría, es posible instalar una aplicación simplemente copiando los
ficheros que la componen en uno de los directorios del equipo en el que se vaya a ejecutar, eliminando los temibles conflictos de versiones entre
librerías, problema conocido también con el nombre de Infierno de las DLL o DLL Hell.
Todas las implementaciones de clases, interfaces, estructuras, etc., ya sean nativas de la plataforma o creadas por el programador, se pueden
considerar tipos válidos de .NET.
Todos los tipos que manipulamos dentro de .NET Framework son objetos.
En la Figura 5 se muestra un esquema de funcionamiento del CTS; en él, tenemos una aplicación en VB.NET y otra en C#, en las que ambas declaran y
crean dos variables; una pertenece a un tipo de dato de la plataforma y otra a una clase. En esta situación, el CTS se encarga de dar las oportunas
instrucciones sobre como instanciar y proporcionar el dato y el objeto a cada una de las aplicaciones cuando sean ejecutadas, con la ventaja de que no
es necesario tener una implementación específica para cada lenguaje, al disponer de un sistema de tipos unificado, y un motor de manipulación de
esos tipos, que es el CTS.
El Código fuente 1 muestra un ejemplo de esta situación escrito en dos de los lenguajes soportados por la plataforma: VB.NET y C#; esto además, nos
sirve para ilustrar como podemos conseguir los mismos resultados con lenguajes diferentes, gracias a las características multilenguaje del entorno de
ejecución; sólo debemos tener en cuenta las particularidades sintácticas del lenguaje empleado. El soporte hacia distintos lenguajes será comentado
más adelante.
' VB.NET
' ------
Dim sNombre As String
sNombre = "coche"
MessageBox.Show(sNombre.Length) ' devuelve 5
MessageBox.Show(sNombre.ToUpper()) ' devuelve COCHE
// C#
// ---
string sNombre;
sNombre="coche";
MessageBox.Show(Convert.ToString(sNombre.Length)); // devuelve 5
MessageBox.Show(sNombre.ToUpper());// devuelve COCHE
Código fuente 1. Manipulación de variable como objeto
En cada una de las versiones de este ejemplo, declaramos una variable de tipo String (cadena de caracteres), y a continuación le asignamos un valor;
hasta aquí, todo igual que en versiones anteriores. Pero ahora viene lo novedoso, ya que manipulamos la variable igual que un objeto, obteniendo la
longitud de su valor mediante la propiedad Length y convertimos su valor a mayúsculas ejecutando el método ToUpper(); en ambos casos mostramos el
resultado usando un objeto MessageBox.
En este fuente y otros que utilicemos a lo largo de este tema, el lector percibirá la importancia de las características OOP con que se ha dotado a la
plataforma
La Tabla 1 muestra una relación de los principales tipos de datos de .NET Framework
Categorías de tipos
Los tipos creados por el CTS pueden clasificarse en dos grupos principales, según el modo en el que se almacenan y manipulan en memoria:
Tipos por valor. Un tipo creado por valor, almacena un dato que puede ser accedido de forma directa. Los tipos por valor se organizan a su vez
en varios subgrupos, como son los tipos de datos nativos de la plataforma .NET, tipos de datos creados por el programador y tipos enumerados.
Tipos por referencia. Un tipo creado por referencia, contiene la dirección de memoria en donde reside un dato. Para acceder a dicho dato, lo
hacemos de forma indirecta utilizando esa dirección de memoria o referencia. Los tipos por referencia se organizan a su vez en varios subgrupos,
como son las clases propias de la plataforma, las clases creadas por el programador, interfaces, delegates, etc.
El Código fuente 2 muestra un ejemplo de creación y asignación de valores a cada uno de estos tipos.
End Cla
Module Gestio
ImportePrim = 100
ImporteSeg = ImportePrim
' -------------------------------------------
' declarar dos objetos (tipos por referencia)
Dim oClienteUno As New Cliente()
Dim oClienteDos As Cliente
oClienteUno.Calculo = 85000
' al asignar un objeto a otra variable
' ambas variables apuntan al mismo objeto
' o dirección de memoria
oClienteDos = oClienteUno
End Sub
End Module
Si traducimos el anterior esquema a código en alguno de los lenguajes de .NET Framework (en este caso VB.NET), el resultado quedaría como
muestra el Código fuente 3.
' embalaje:
End Class
' embalaje:
' asignamos el tipo por valor a
' una variable Object
Dim oOtroVal As Object = iImporte
'-----------------------
' desembalaje:
End Sub
End Class
VB.NET.
C#.
C++ con Extensiones Administradas.
JScript.NET.
Por integración de lenguajes podemos definir algo tan poderoso como el hecho de escribir una clase en C#, y heredar de dicha clase desde VB.NET.
Esto permite formar grupos de trabajo heterogéneos, en los que cada integrante del grupo, puede escribir el código de una aplicación en el lenguaje de
su preferencia. Gracias a que el entorno de ejecución es común, y el código compilado no pasa directamente a código ejecutable puro, sino a un
código intermedio (lo veremos más adelante), podemos crear nuestros programas en el lenguaje con el que nos sintamos más cómodos en cuanto a
sintaxis y prestaciones, con la ventaja de que la velocidad de ejecución será muy parecida a la obtenida habiendo escrito el código en otro lenguaje en
principio más rápido como C++.
El CLS (Common Language Specification)
La integración entre lenguajes mencionada en el anterior apartado, puede llevar a preguntarnos cómo es posible conseguir que lenguajes de distinta
naturaleza y sintaxis se entiendan.
La respuesta la hallamos en la Especificación Común de Lenguajes o CLS (Common Language Specification), que consiste en un conjunto de
características comunes, que deben cumplir todos los lenguajes de la plataforma, para poder integrarse entre sí.
Esto tiene varias finalidades, que describimos a continuación:
Independencia del lenguaje. En muchas ocasiones el programador se ve obligado a escribir el código en un lenguaje que no es de su agrado;
la causa de ello es que dicho lenguaje le provee de funcionalidades de las cuales carece su lenguaje preferido. Con .NET, esto no ocurre, puesto
que es la propia plataforma la que proporciona la funcionalidad de modo independiente al lenguaje, por lo que podemos escribir nuestras
aplicaciones utilizando el lenguaje con el que nos sintamos más cómodos, ya que el resultado será el mismo.
Integración entre lenguajes. Es posible escribir, por ejemplo, una librería de clases en un lenguaje, y utilizarla desde otro lenguaje distinto
(siempre que ambos lenguajes cumplan con las normas del CLS). Este concepto no es nuevo, hasta ahora también podíamos escribir una librería
en C++ y utilizarla desde VB, pero gracias al CLS, se extiende y se potencia este modo de trabajo, ya que al basarse los lenguajes en un conjunto
de reglas comunes, el acceso en el caso antes mencionado, a una librería de clases, se facilita enormemente desde cualquier otro lenguaje
creado en base al CLS.
Apertura a nuevos lenguajes. Finalmente, al ser esta, una especificación abierta, es posible incorporar a .NET Framework nuevos lenguajes,
aparte de los actualmente disponibles, y no sólo creados por Microsoft, sino por cualquier otro fabricante. Mediante el CLS, un fabricante de
software sabe qué requisitos debe observar un nuevo lenguaje que él desarrolle, para poder integrase en el entorno de .NET Framework.
Terceros fabricantes ya han anunciado en este sentido, su intención de proporcionar nuevos lenguajes para .NET; de esta forma aparecerán
progresivamente versiones para esta plataforma de Cobol, Perl, Smalltalk, etc., en una lista en la que actualmente figuran más de veinte lenguajes
candidatos.
Ejecución administrada
La ejecución administrada se trata de un conjunto de elementos existentes en .NET Framework, que supervisan el código del programa durante su
ejecución dentro del CLR, asegurándose de que el código cumple todos los requisitos para poder hacer uso de los servicios proporcionados por el
entorno de ejecución, y beneficiarse de sus ventajas.
Código administrado
El código que escribamos orientado a utilizar todas las cualidades del CLR se denomina código administrado. Por defecto el código escrito en
VB.NET, C# y JScript.NET es administrado, con lo que el programador no debe preocuparse en configurar de manera especial su proyecto.
Por el contrario, el código escrito en C++ no es administrado por defecto, lo que significa que el entorno no lo supervisa y no garantiza su fiabilidad al
ser ejecutado por el CLR. Si el programador de C++ quiere que su código sea administrado debe utilizar las extensiones administradas que la
plataforma proporciona para este lenguaje y activarlas a través de una opción del compilador.
El hecho de que el entorno realice labores de comprobación sobre el código, supone evidentemente, una labor extra que repercute sobre el rendimiento
final a la hora de ejecutar el programa. Sin embargo, las pruebas realizadas ofrecen como resultado una pérdida de un 10% en el rendimiento del
código administrado con respecto al código no administrado.
Teniendo en cuenta los niveles de seguridad que nos ofrece el código administrado y dado que la velocidad de los procesadores evoluciona, esta
pérdida de rendimiento que supone la ejecución administrada posiblemente no sea significativa en un corto plazo de tiempo.
Datos administrados
De forma similar al código, los datos administrados son datos los datos de la aplicación gestionados en memoria por el CLR a través de un mecanismo
denominado recolector de basura.
Al igual que en el punto anterior, los datos son administrados por defecto en las aplicaciones escritas en C#, VB.NET y JScript.NET. Si utilizamos en
cambio C++, los datos de la aplicación no son administrados por defecto, debiéndolo indicar en el código del programa.
Independencia de plataforma
Ya que el código máquina ejecutable, es obtenido a través de un compilador JIT, con las instrucciones adecuadas para un procesador determinado,
.NET Framework proporciona varios compiladores JIT para cada una de las plataformas que soporta, consiguiendo así que la aplicación, una vez
escrita, pueda funcionar en distintos sistemas operativos, y haciendo realidad el objetivo de que nuestro código sea independiente de la plataforma en
la que se vaya a ejecutar, actuando .NET Framework como una capa intermedia, que aísla el código del sistema operativo. Ver Figura 13
Figura 13. Una misma aplicación se ejecuta en distintos sistemas a través de .NET Framework.
Dominios de aplicación
En .NET Framework se han reforzado las características de seguridad y aislamiento hasta un nivel que permite la ejecución de múltiples aplicaciones en
un mismo proceso. A este contexto de ejecución de un programa se le denomina dominio de aplicación (Application Domain).
La técnica utilizada tradicionalmente para conseguir aislar las aplicaciones, de modo que no se produzcan colisiones entre las mismas, ha sido a través
de procesos. Cada aplicación se carga en un proceso separado, que proporciona el adecuado nivel de aislamiento; de este modo, se evitan posibles
conflictos entre las direcciones de memoria utilizadas por cada programa. Sin embargo, esto supone un gran consumo de recursos, cuando las
aplicaciones deben hacer llamadas a otras aplicaciones que residan en procesos distintos, debido a que se debe de realizar un traspaso de procesos
entre la aplicación que realiza la llamada y la aplicación destino. Esta técnica ha sido mejorada en .NET, de modo que se consigue tener en un mismo
proceso, varias aplicaciones en ejecución.
El código administrado en .NET Framework, para poder ser considerado como seguro, debe pasar en primer lugar una fase de comprobación,
efectuada por el CLR, que asegure el hecho de que no realice ningún acceso no permitido a direcciones de memoria u otras operaciones que puedan
provocar un fallo del sistema. Una vez superada dicha comprobación, el código es marcado como seguro a nivel de tipos (type-safe), y la aplicación
ejecutada.
Superada esta fase de verificación, el programa se ejecutará en un dominio de aplicación, que como hemos comentado antes, consiste en una técnica
que permite ejecutar varias aplicaciones en un único proceso, con el mismo nivel de aislamiento que si se estuvieran ejecutando en procesos
separados, y la ventaja de eliminar la sobrecarga producida cuando distintas aplicaciones están situadas en diferentes procesos y deben hacerse
llamadas entre sí. Cada aplicación se ejecuta en su propio dominio de aplicación
Los dominios de aplicación incrementan notablemente la capacidad de crecimiento de los servidores al ejecutar múltiples aplicaciones en un mismo
proceso. La Figura 14 muestra un esquema del proceso de carga y ejecución de aplicaciones en sus correspondientes dominios de aplicación.
Para acceder desde el código de una aplicación, a una clase contenida dentro de un espacio de nombre, debemos indicarlo en la aplicación realizando
una operación que en VB.NET se denomina Importar. Existen dos medios para importar un espacio de nombre: usar la palabra clave Imports en la
cabecera del módulo de código junto al nombre del namespace y clase a la que queremos acceder; o bien usar la descripción calificada completa en
cada momento que necesitemos hacer referencia a la clase. El Código fuente 5 muestra algunos ejemplos:
Imports Gestion.Contabilidad
Imports System.Windows.Forms
'............
'............
'............
End Sub
End Class
En el caso de C#, para hacer referencia a un espacio de nombres, el término utilizado es Usar. El Código fuente 6 muestra un ejemplo de espacio de
nombres para este lenguaje.
using System;
using System.Windows.Forms;
using Gestion.Contabilidad;
namespace Datos
{
/// <summary>
/// Descripción breve de Cliente.
/// </summary>
public class Cliente
{
public Cliente()
{
//
// TODO: agregar aquí la lógica del constructor
//
}
Button oPulsa;
oPulsa=new Button();
}
}
}
De esta forma, la línea mostrada en el Código fuente 7 , nos permitirá instanciar en el código del módulo donde esté declarada, objetos de la clase File,
que está en el namespace IO, este último a su vez contenido en el namespace System.
Imports System.IO
El nuevo sistema de clases está mucho mejor organizado, y provee al programador de una potencia y versatilidad para sus aplicaciones nunca
antes lograda en versiones anteriores de Visual Studio.
Podemos crear una nueva clase, heredando de una clase propia de la plataforma, para extender su funcionalidad.
Desplazando la funcionalidad de las clases fuera de los lenguajes, y haciéndolas por lo tanto, independientes de los mismos, simplifica el proceso
de desarrollo.
Al ser las clases de .NET Framework, comunes a todos los lenguajes, se eliminan las barreras tradicionales que impedían a los programadores
abordar ciertos proyectos por el hecho de usar un lenguaje que no disponía de cierta funcionalidad que sí tenía otro lenguaje. Ahora cualquier
programador, con independencia del lenguaje que elija, tiene pleno acceso a todas las funcionalidades que le brinda la plataforma .NET.
El ejemplo del Código fuente 8 muestra la declaración y asignación de valor a una variable desde VB.NET y C#. Con las salvedades particulares
de cada lenguaje, en ambos casos se instancia una variable de la misma clase o tipo: Integer.
// código C#
int MiDato=20;
Código fuente 8. Instanciación de objetos de la misma clase de .NET Framework desde distintos lenguajes.
Dentro de .NET Framework, System designa al espacio de nombre principal o raíz, a partir del cual, descienden todos los espacios de nombre y clases
de la plataforma.
Además de las clases que proporcionan acceso a los tipos de datos intrínsecos de .NET Framework, System nos permite el acceso a otros servicios
entre los que se encuentran los mostrados en la Tabla 2.
Estáticos. Es el tipo más corriente de ensamblado, y es creado por el programador en tiempo de diseño.
Dinámicos. Son ensamblados creados en tiempo de ejecución.
El contenido de un ensamblado
Un ensamblado está compuesto por los siguientes elementos:
Manifiesto del ensamblado, que contiene información acerca de los elementos que forman el ensamblado.
Metadatos sobre los tipos que contiene el ensamblado.
Módulos de código con los tipos compilados en IL.
Recursos adicionales.
De los puntos que acabamos de describir, los cuatro primeros forman lo que se denomina la identidad del ensamblado.
El manifiesto se almacena, dependiendo del modo de creación del ensamblado, de las siguientes maneras:
Si el ensamblado es de fichero único, la información del manifiesto se añade al fichero ejecutable .EXE o DLL (con formato PE) resultante.
Si el ensamblado es de fichero múltiple, la información del manifiesto se graba en un fichero independiente (también con formato PE, pero que en
este caso no es ejecutable), que sólo contiene los datos del manifiesto (aunque también se puede añadir a uno de los ficheros DLL o EXE que
componen el ensamblado).
La siguiente sección, nos proporciona una información más detallada del lugar en el que es grabado el manifiesto dependiendo del tipo de
ensamblado.
Ensamblado de fichero único. Está compuesto por un sólo fichero con formato PE (ejecutable transportable), bien .EXE o .DLL, en el que se
incluyen todos los elementos necesarios. En este tipo de ensamblado, el manifiesto se encuentra integrado dentro del propio fichero. Ver Figura
19 .
En una situación como esta, podemos agrupar las clases específicas en una librería y las de utilidad en un módulo independiente, dejando el gráfico en
su propio fichero, que sólo consumirá recursos cuando sea referenciado, optimizando de esta manera el rendimiento de la aplicación. El manifiesto en
este caso, puede ser creado en un fichero aparte.
La Figura 20 muestra un esquema de ensamblado con múltiples ficheros.
Figura 21. El manifiesto de cada ensamblado maneja las referencias a los ficheros que componen el ensamblado.
Privados. Un ensamblado privado es aquél que sólo es empleado por la aplicación, quedando situado en su mismo directorio. Como hemos
indicado anteriormente, este es el modo por defecto en que se crean los ensamblados.
Compartidos. Un ensamblado compartido, como su propio nombre indica, puede ser utilizado por varias aplicaciones. A diferencia de un
ensamblado privado, que sólo es visible desde la propia aplicación, y se encuentra instalado en el directorio de esta, un ensamblado compartido
debe exponer su funcionalidad al exterior; este motivo, hace que deban ser tenidos en cuenta factores adicionales, como la localización del
ensamblado, seguridad en cuanto a accesos, versiones, etc., para que no entren en conflicto con el resto de ensamblados compartidos del
sistema. Estos aspectos serán tratados a continuación
Unicidad. A través de las dos claves únicas que componen el nombre del ensamblado, nos aseguramos de que dicho ensamblado también es
único, es decir, ningún otro programador podrá generar un nombre igual.
Descendencia asegurada. Gracias a los nombres seguros, nadie puede crear siguientes versiones de nuestro ensamblado.
Integridad a nivel de contenido. Las comprobaciones de seguridad que realiza el entorno de ejecución, nos aseguran que el ensamblado no ha
sido modificado desde que fue generado. A pesar de todo, el propio nombre seguro no constituye en sí mismo, un elemento de confianza sobre la
integridad del ensamblado; dicha confianza es alcanzada a través de la firma digital con el certificado.
Para alcanzar un nivel de confianza en un ensamblado, además del nombre seguro, es necesario utilizar una herramienta como SIGNCODE.EXE,
que proporciona una firma digital para el ensamblado. Esta utilidad requiere una autoridad de emisión de certificados, que podemos integrar en el
ensamblado para cumplir los requerimientos de confianza necesarios en ciertos niveles.
Versiones de ensamblados
Todos los ensamblados deben disponer de su correspondiente versión, que es almacenada en el manifiesto. Los datos de la versión de un ensamblado
se indican de dos maneras:
Incompatible. Este nivel viene determinado por los números superior e inferior de la versión, lo que quiere decir, que al realizar un cambio en
cualquiera de esos números, el ensamblado se hace incompatible con otras versiones del mismo ensamblado, que difieran en estos números.
Posiblemente compatible. Este nivel viene determinado por el número de construcción, y significa que una nueva versión del mismo
ensamblado, en la que haya un cambio sólo en este número, permite el uso de dicha versión, aunque esto no implica que puedan aparecer ciertas
incompatibilidades.
Actualización rápida. Este tipo de compatibilidad, también denominado QFE (Quick Fix Engineering) se indica mediante el número de revisión,
e indica al entorno que se trata de una actualización de urgencia para resolver problemas puntuales importantes.
Ficheros de configuración
Cuando el CLR necesita hacer uso de un ensamblado, toma su número de versión del manifiesto, realiza una búsqueda del ensamblado y lo ejecuta en
caso de encontrarlo. Este es el comportamiento por defecto de entorno de ejecución.
Sin embargo, puede haber ocasiones en las que se haga necesario el uso de una versión diferente del ensamblado, para lo cual, debemos redirigir al
CLR hacia dicha versión específica que deseamos ejecutar, en lugar de la versión por defecto.
Esto lo conseguimos a través de los ficheros de configuración, que son unos ficheros con extensión .CFG, basados en etiquetas XML, en los que a
través de un conjunto de etiquetas clave ordenamos al entorno la ejecución de una determinada versión del ensamblado. En el ejemplo del Código
fuente 9 indicamos mediante un fichero de configuración el uso de una versión específica de un ensamblado.
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="GestVentas"
publickeytoken="32ab4ba45e0a69a1"
culture="sp" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
<codeBase version="2.0.0.0"
href="http://www.AcmeFac.com/GestVentas.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Verificación de versión. En primer lugar, el CLR comprueba si la versión del ensamblado es correcta, examinando la existencia de posibles
ficheros de configuración.
Los ficheros de configuración permiten el establecimiento o cambio de valores de configuración del ensamblado en tres niveles: aplicación,
políticas de autor, máquina. Los posibles ficheros de configuración son buscados también en este orden.
Ensamblados previamente utilizados. A continuación, se verifica si el ensamblado ya ha sido cargado por una llamada anterior. En caso
afirmativo, se utiliza dicho ensamblado, evitando tener que cargarlo de nuevo.
Comprobación de la caché global de ensamblados. Si no se emplea un ensamblado ya cargado, se busca seguidamente en la caché global.
Localización mediante codebases o sondeo. Una vez averiguada la versión del ensamblado, se intenta localizar el ensamblado a través de
sus ficheros de configuración, en primer lugar mediante un codebase, que consiste en una de las etiquetas que pueden incluirse en este tipo de
ficheros y que proporcionan información sobre la versión.
Si no existe un codebase, se aplica una técnica denominada sondeo (probing), que consiste en realizar una búsqueda por aproximación utilizando
los siguientes elementos:
Ruta en la que se está ejecutando la aplicación.
Datos culturales del ensamblado.
Nombre del ensamblado.
Lista de subdirectorios situados en la ruta de ejecución de la aplicación.
Dominio único. El ensamblado no está optimizado para ser usado por múltiples aplicaciones.
Dominio múltiple. El ensamblado está optimizado para ser usado por múltiples dominios de aplicación, en los que cada aplicación de
cada dominio ejecuta el mismo código.
Dominio múltiple de entorno. El ensamblado se optimiza para ser usado por múltiples dominios de aplicación, en los que cada dominio
ejecuta diferente código
Si quiere ver más textos en este formato, visítenos en: http://www.lalibreriadigital.com.
Este libro tiene soporte de formación virtual a través de Internet, con un profesor a su disposición,
tutorías, exámenes y un completo plan formativo con otros textos. Si desea inscribirse en alguno de
nuestros cursos o más información visite nuestro campus virtual en: http://www.almagesto.com.
Si quiere información más precisa de las nuevas técnicas de programación puede suscribirse
gratuitamente a nuestra revista Algoritmo en: http://www.algoritmodigital.com.
Si quiere hacer algún comentario, sugerencia, o tiene cualquier tipo de problema, envíelo a la dirección
de correo electrónico lalibreriadigital@eidos.es.
© Grupo EIDOS
http://www.eidos.es