1. El Common Language Runtime El código intermedio Como ya se ha explicado, los compiladores de los lenguajes .NET no generan código binario para su ejecución directa en los sistemas. En su lugar se genera un código intermedio (Microsoft IntermediateLanguage o MSIL). Éste lenguaje es el que comprende el entorno de ejecución CLR y el que se encarga de traducir, a código binario (compilar), para el sistema en el que se esté ejecutando. Para ello dispone de dos opciones diferenciadas: Compilación instantánea o Just-In-Time: es la que realiza de forma automática el CLR y lanza la ejecución. Compilación bajo demanda: es de tipo incremental, es decir, sólo compila aquello que se utiliza, en lugar del programa completo. Esto optimiza el rendimiento ya que la mayoría de los usuarios sólo utilizan una pequeña parte del código de los programas y no todas las funcionalidades disponibles.

2. El Common Language Runtime Evidentemente, esto se ha planteado de esta forma para que exista un entorno de ejecución CLR específico para cada tipo de procesador, pero una única versión de código MSIL. Con lo que los desarrollos son totalmente independientes de la plataforma sobre la que vaya a ejecutarse posteriormente el código, contrastando con los desarrollos anteriores. Junto con el código MSIL, los compiladores generan, en función de lo que el desarrollador indica, los metadatos, que son la información complementaria al programa que el entorno necesita para poder gestionar la ejecución. Estos metadatos y el código intermedio, junto con los recursos adicionales que pueda requerir el proceso se empaquetan en lo que se conoce como ensamblados o Assemblies, por su nombre en Inglés.

3. El Common Language Runtime Además de las funcionalidades ofrecidas al desarrollo, hay una nueva serie de ventajas enfocadas al entorno de desarrollo que pasamos a comentar. Para un mejor control de seguridad y aislamiento de los procesos en ejecución, dentro de la máquina, el Framework dispone de los Application Domaino dominios de aplicación. Estos permiten, al margen de los beneficios ya comentados de seguridad y aislamiento, la ejecución concurrente de varias aplicaciones en un mismo proceso. Hasta ahora, para gestionar el aislamiento, se ejecutaba una única aplicación en cada proceso, lo cual reportaba evidentes beneficios a la hora de separar los recursos utilizados por cada una de ellas y evitaba las colisiones entre ellas a la hora de recurrir a ellos. Pero tenía unos graves problemas de rendimiento cuando una de las aplicaciones en ejecución tenía que hacer referencias o llamadas a recursos o módulos de otra de las aplicaciones en ejecución.

4. El Common Language Runtime Ahora, con las técnicas utilizadas por el .NET Framework, es muy fácil incluir varias aplicaciones de forma que se ejecuten conjuntamente en un mismo proceso, con lo cual el consumo de recursos en las llamadas entre ellas se ven enormemente reducidos, facilitando la programación orientada a componentes, que más adelante se comentará en mayor detalle. De todas formas, antes de lanzar una ejecución en un dominio de aplicación, el Framework efectúa varias validaciones del código en cuanto a temas de seguridad, acceso a áreas de memoria, ejecución de operaciones del sistema que puedan provocar fallos,..etc. Cuando estás validaciones han pasado, el código es marcado como Type-Safe, es decir seguro a nivel de tipos, ya se ha comentado el tema de los tipos comunes del .NET Framework.

5. El Common Language Runtime Este tipo de arquitectura de ejecuciones permite los que se conoce como side-by-side execution, es decir, la ejecución concurrente de distintas versiones de la misma aplicación o componente. La ejecución de los dominios de aplicación, dentro del CLR, la llevan a cabo los Runtime-Hosts, o servidores de entorno, que no es más que una nueva denominación para los típicos sub-sistemas de ejecución, como puedan ser el Windows Shell, para las aplicaciones de escritorio, el ASP.NET, para las aplicaciones basadas en la Web o Internet Explorer, para la navegación por la red, entre otros. Para el control del acceso a los recursos del sistema, el .NET Framework utiliza lo que denomina Access Control ListoACL, las cuales pueden ser creadas o modificadas desde código, ampliando las facilidades en la entrada y salida, gestión de hilos y manipulación del registro, permitiendo o denegando el acceso a los recursos del sistema. Microsoft SQL Server™ Microsoft BizTalk™ Server Microsoft Host Integration Server Microsoft Exchange Enterprise Server Microsoft Application Center Microsoft Internet Security and Acceleration Server Microsoft Commerce Server Microsoft SharePoint™ Portal Server Microsoft Mobile Information Server Microsoft Content Management Server

6. El Common Language Runtime Namespace o Espacios de nombres Ya hemos comentado que toda la funcionalidad ofrecida por el .NET Framework a los lenguajes, al tiempo que utilizado por él mismo para su funcionamiento está ubicada en la librería básica de clases (Base Class LibraryoBCL). Como hay varios miles de clases en esta librería, el tenerlas todas en línea sería totalmente inabordable, al menos para el común de los mortales. La forma de evitar este lío es la organización de las mismas en los que se denomina Namespace o espacios de nombres. Sólo es una denominación específica para una estructura en árbol, en la que las clases se van situando, agrupadas por temas específicos, con las necesarias subdivisiones por especialidades, hasta llegar al último nivel de detalle.

7. El Common Language Runtime Para poder utilizar las clases incluidas en un Namespace de forma sencilla, es necesario declarar su utilización al principio del módulo de código en el que se vaya a hacer uso de alguna de sus clases. En Visual Basic esta operación se realiza con la palabra clave Imports, en C# con la instrucción Using aunque cada lenguaje utiliza una sintaxis específica para esta tarea. Esta declaración permite que hagamos referencia directa al nombre de la clase que deseemos utilizar, sin tener que calificarla con su nombre completo, que sería el caso si no hubiéramos realizado la “importación” inicial. Como ejemplo puede valer el siguiente. Para manejar un botón en un formulario se ha de utilizar la clase Button. Sin el espacio de nombres, su nombre calificado completo sería System.Windows.Forms.Button. El uso de los espacios de nombres es el que habilita la referencia automática del IntelliSense.

8. El Common Language Runtime Una funcionalidad que hasta ahora no teníamos disponible es la de poder heredar de una clase del sistema, cosa que ya se puede efectuar, al estar todas las clases de la BCL a nuestra disposición, para su modificación o ampliación de funcionalidades. Una de las ventajas de la organización de las clases del entorno en la BCL es que estas son externas a cualquier lenguaje y están, en cambio, disponibles para todos los soportados, lo cual redunda en beneficio de los desarrolladores y de la independencia del lenguaje, ya que esta característica, la “heredan” también nuestras propias clases y cualquier clase que desarrollemos, sea con el lenguaje que sea, estará disponible para su consumo o utilización desde una función desarrollada con cualquier otro lenguaje de los incluidos en el entorno. Algunas de los principales, o más usados, espacios de nombres son los que a continuación se muestran. Microsoft.Aspnet.Snapin Microsoft.Build.BuildEngine Microsoft.Build.Framework Microsoft.Build.Tasks Microsoft.Build.Tasks.Deployment.Bootstrapper Microsoft.Build.Tasks.Deployment.ManifestUtilities Microsoft.Build.Utilities Microsoft.CSharp Microsoft.JScript Microsoft.SqlServer.Server Microsoft.VisualBasic Microsoft.VisualBasic.ApplicationServices Microsoft.VisualBasic.CompilerServices Microsoft.VisualBasic.Devices Microsoft.VisualBasic.FileIO Microsoft.VisualBasic.Logging Microsoft.VisualBasic.MyServices Microsoft.VisualBasic.MyServices.Internal Microsoft.VisualBasic.Vsa Microsoft.VisualC Microsoft.Vsa Microsoft.Vsa.Vb.CodeDOM Microsoft.Win32 Microsoft.Win32.SafeHandles Microsoft.WindowsCE.Forms Microsoft.WindowsMobile.DirectX Microsoft.WindowsMobile.DirectX.Direct3D Microsoft_VsaVb System System.CodeDom System.CodeDom.Compiler System.Collections System.Collections.Generic System.Collections.ObjectModel System.Collections.Specialized System.ComponentModel System.ComponentModel.Design System.ComponentModel.Design.Data System.ComponentModel.Design.Serialization System.Configuration System.Configuration.Assemblies System.Configuration.Install System.Configuration.Provider System.Data System.Data.Common System.Data.Design System.Data.Linq System.Data.Linq.Mapping System.Data.Odbc System.Data.OleDb System.Data.OracleClient System.Data.Sql System.Data.SqlClient System.Data.SqlServerCE System.Data.SqlTypes System.Diagnostics System.Diagnostics.CodeAnalysis System.Diagnostics.Design System.Diagnostics.SymbolStore System.DirectoryServices System.DirectoryServices.ActiveDirectory System.DirectoryServices.Protocols System.Drawing System.Drawing.Design System.Drawing.Drawing2D System.Drawing.Imaging System.Drawing.Printing System.Drawing.Text System.EnterpriseServices System.EnterpriseServices.CompensatingResourceManager System.EnterpriseServices.Internal System.Globalization System.IO System.IO.Compression System.IO.IsolatedStorage System.IO.Ports System.Linq System.Linq.Expressions System.Management System.Management.Instrumentation System.Messaging System.Messaging.Design System.Net System.Net.Cache System.Net.Configuration System.Net.Mail System.Net.Mime System.Net.NetworkInformation System.Net.Sockets System.Reflection System.Reflection.Emit System.Resources System.Resources.Tools System.Runtime System.Runtime.ConstrainedExecution System.Runtime.Hosting System.Runtime.CompilerServices System.Runtime.InteropServices System.Runtime.InteropServices.ComTypes System.Runtime.InteropServices.CustomMarshalers System.Runtime.InteropServices.Expando System.Runtime.Remoting System.Runtime.Remoting.Activation System.Runtime.Remoting.Channels System.Runtime.Remoting.Channels.Http System.Runtime.Remoting.Channels.Ipc System.Runtime.Remoting.Channels.Tcp System.Runtime.Remoting.Contexts System.Runtime.Remoting.Lifetime System.Runtime.Remoting.Messaging System.Runtime.Remoting.Metadata System.Runtime.Remoting.Metadata.W3cXsd2001 System.Runtime.Remoting.MetadataServices System.Runtime.Remoting.Proxies System.Runtime.Remoting.Services System.Runtime.Serialization System.Runtime.Serialization.Formatters System.Runtime.Serialization.Formatters.Binary System.Runtime.Serialization.Formatters.Soap System.Security System.Security.AccessControl System.Security.Cryptography System.Security.Cryptography.Pkcs System.Security.Cryptography.X509Certificates System.Security.Cryptography.Xml System.Security.Permissions System.Security.Policy System.Security.Principal System.ServiceProcess System.Text System.Text.RegularExpressions System.Threading System.Timers System.Transactions System.Transactions.Configuration System.Web System.Web.Caching System.Web.Compilation System.Web.Configuration System.Web.Handlers System.Web.Hosting System.Web.Mail System.Web.Management System.Web.Mobile System.Web.Profile System.Web.RegularExpressions System.Web.Security System.Web.Services System.Web.Services.Configuration System.Web.Services.Description System.Web.Services.Discovery System.Web.Services.Protocols System.Web.SessionState System.Web.UI System.Web.UI.Adapters System.Web.UI.Design System.Web.UI.Design.MobileControls System.Web.UI.Design.MobileControls.Converters System.Web.UI.Design.WebControls System.Web.UI.Design.WebControls.WebParts System.Web.UI.HtmlControls System.Web.UI.MobileControls System.Web.UI.MobileControls.Adapters System.Web.UI.MobileControls.Adapters.XhtmlAdapters System.Web.UI.WebControls System.Web.UI.WebControls.Adapters System.Web.UI.WebControls.WebParts System.Web.Util System.Windows.Forms System.Windows.Forms.ComponentModel.Com2Interop System.Windows.Forms.Design System.Windows.Forms.Design.Behavior System.Windows.Forms.Layout System.Windows.Forms.PropertyGridInternal System.Xml System.Xml.Schema System.Xml.Serialization System.Xml.XPath System.Xml.Xsl System.Xml.Xsl.Runtime System.Xml.Xsl

9. El Common Language Runtime El código administrado por el CLR obtiene las funcionalidades aportadas por el mismo, como pueden ser: Integración de lenguajes. Pase de excepciones entre módulos, incluso de diferentes lenguajes. El control de seguridad ya mencionado, de tipos y acceso a recursos. Pero para ello, los programas deben tener generados los correspondientes metadatos para que el CLR disponga de las descripciones de los tipos, las referencias y los miembros componentes de dicho código, los cuales han de ser almacenados junto con el propio código. En estos metadatos figura la relación de todos los recursos utilizados por el módulo, así como, en los casos pertinentes, las versiones específicas de los mismos necesarias para la correcta ejecución del módulo. Lo cual permite que el CLR pueda efectuar el control necesario, antes de lanzar la ejecución del módulo, de que todos los recursos necesarios están presentes y en la versión adecuada, evitando las interrupciones de proceso debidas a estos problemas.

10. El Common Language Runtime El colocar en los metadatos está información permite evitar el tener que situarla en el registro del sistema, facilitando la existencia de varias versiones de las aplicaciones y la gestión de las mismas. EL CLRse encarga, dentro de la parte de administración de memoria, de gestionar la liberación de la memoria no utilizada y de los recursos que ya no se vayan a referenciar, después de haberlos colocados en ella al hacerse referencia a los mismos desde el código, dándosele el nombre de datos administrados a todos los que entran en esta gestión. Una de las ventajas adicionales del sistema del .NET Framework es que la instalación de las aplicaciones se ha visto grandemente facilitada, reduciéndose, en muchas ocasiones, a una simple copia de archivos, al estar toda la configuración necesaria incluida en el propio paquete.

11. El Common Language Runtime El sistema de tipos comunes (CTS) Los tipos son la forma de definir la representación de un dato, sus métodos y propiedades. El CTS define cómo definir, utilizar y administrar los tipos en el CLR. Es uno de los fundamentos de la integración entre lenguajes, junto con la BCL. Algunas de sus funcionalidades son: Establece las reglas a seguir por los lenguajes para poder integrarse en tiempo de ejecución. Define el modelo de orientación a objetos utilizado por todos los lenguajes del Framework Sienta las bases para que el CLR pueda ejecutar sus funciones de control de la seguridad de tipos. Es decir, el CTS es quien establece cómo el CLR ha de administrar el código en ejecución.

12. El Common Language Runtime Los ensamblados o Assembliesson el resultado de nuestros esfuerzos en desarrollo, lo que producimos, desde Visual Studio, para que se ejecute en los sistemas. Contienen, evidentemente, el código compilado a lenguaje MSIL, los Metadatos y el manifiesto del ensamblado, que se comentará más adelante. Con esta información, el CLR, en tiempo de ejecución, podrá efectuar sus validaciones de seguridad de tipos y acceso a recursos, sabrá que recursos debe preparar para la ejecución y que versión de cada uno de ellos debe ubicar, sabrá que autorizaciones de acceso debe otorgar. Los ensamblados pueden ser estáticos y dinámicos, siendo los dinámicos aquellos cuya ejecución se lanza directamente, sin haber sido guardados previamente, pudiendo guardarse tras la ejecución, pasando a ser estáticos a partir de ese momento. Es decir los ensamblados estáticos son aquellos que han sido guardados en disco o directamente creados en tiempo de desarrollo.

13. El Common Language Runtime Los ensamblados se pueden crear con diferentes herramientas, desde Visual Studio, con las herramientas específicas del SDK y desde el CLR con Reflection.Emit, entre otras. Aunque, como ya se ha comentado, al generar un nuevo proyecto desde Visual Studio ya es, automáticamente, un nuevo ensamblado. Los ensamblados son la solución al problema habitual de las nuevas versiones y de las DLLs compartidas. Ya no nos ocurrirá que una nueva versión de una DLL machaque la versión anterior, con lo que dejaban de funcionar otros programas. Ahora, al no estar registradas en el registro de Windows, no existe este problema. Cada versión de cada DLL está listada dentro del manifiesto del o de los ensamblados a los que pertenece y estos son los que se encargarán de ubicarla y recuperar la versión correcta para el ensamblado en ejecución, ya que ahora se guardarán, normalmente, en el mismo directorio que el ejecutable y el resto de recursos necesarios para su ejecución.

14. El Common Language Runtime Además de la ventaja anterior, que ya es enorme de por sí, los ensamblados son los que facilitan muchísimo la instalación de las aplicaciones, al ser auto-descriptivos, y también permiten facilitar la desinstalación de las aplicaciones, por los mismos motivos. Los ensamblados están compuestos por varios elementos: Manifiesto: contiene los metadatos del ensamblado, único elemento obligatorio. Metadatos sobre los tipos contenidos en el ensamblado. El código MSIL del módulo. Recursos adicionales. Los ensamblados pueden ser de archivo único, cuando lo colocamos todo en un único archivo por ser de pequeño tamaño, o de múltiples archivos, cuando vamos colocando los distintos componentes del módulo en varios archivos.

15. El Common Language Runtime Esta última opción es la que se suele utilizar cuando estamos ante aplicaciones bastante grandes o con muchas funcionalidades diversas que los usuarios no utilizarán necesariamente todas. Al estar en archivos separados, se facilita su descarga, caso en acceso por la red, al no descargarse un archivo hasta no ser referenciado desde el código en ejecución. Lo que está claro es que aunque el ensamblado sea de múltiples archivos, el manifiesto del mismo será único y será el encargado de ir indicando en que archivo se encuentra cada módulo requerido, debiendo ir en un archivo independiente cuando se trate de un ensamblado de archivos múltiples. Al ser los manifiestos relaciones de los recursos del ensamblado, los módulos que lo componen no están compilados, por lo que pueden fácilmente ser reutilizados desde otros manifiestos en diferentes ensamblados, reafirmando la orientación a objetos y componentes del entorno.

16. El Common Language Runtime El manifiesto del ensamblado está compuesto por: Nombre del ensamblado, una cadena de caracteres con el nombre del ensamblado. Número de versión, principal y secundaria, revisión y compilación, las que condicionan las compatibilidades controladas posteriormente por el CLR. Referencia a la cultura, información sobre idioma y otros elementos culturales que soporta el ensamblado. Información de nombre seguro, clave pública, si el ensamblado tiene nombre seguro. Lista de ficheros, nombre y resumen de cada fichero de los que forman el ensamblado, siempre ubicados en el mismo directorio. Referencia de tipos, información usada por el entorno para localizar el código IL de cada uno de los tipos que contiene el ensamblado. Ensamblados referenciados, lista de los ensamblados con los que el actual mantiene dependencias, plenamente identificados. Los cuatro primeros elementos forman la identidad del ensamblado.

17. El Common Language Runtime Recolección de basura (GarbageCollection): El CLR utiliza el Garbage Collector para gestionar la memoria que utilizan los tipos por referencia. El Garbage Collectorgarantiza que un objeto se destruye una y sólo una vez y sólo cuando ya no sea utilizado. El Garbage Collectorejecutará el contenido del método destructor o Finalize que hayamos codificado para liberar recursos utilizados por nuestro objeto. El orden de ejecución de los destructores no puede ser garantizado. No deben incluir código dependiente de tiempos o intervenciones de usuario.