viernes, 21 de junio de 2013

La CLR y .NET Framework

Durante este artículo haré una descripción general del propósito de .NET Framework y una de sus partes integrales fundamentales para la ejecución de aplicaciones escritas en cualquier de los lenguajes soportados por .NET (i.e., C#, VB.NET, Managed C++, Delphi.NET, F#); con esto me refiero a la CLR (de la cual ya he hablado en otro artículo: Relación de C# con la CLR).

- ¿Qué es .NET Framework?:

De acuerdo [1], es un marco de trabajo para software, diseñado primariamente para la plataforma Microsoft Windows. Posee varias características para la escritura de software robusto, seguro, escalable. Además, facilita escribir código en un lenguaje de programación, como puede ser C#, y provee interoperabilidad con otros lenguajes (C++, Delphi.NET, F#, VB.NET, entre otros). Está compuesto por una máquina virtual conocida como CLR -Common Language Runtime-, y un conjunto vasto de librerías para la construcción de aplicaciones Windows y Web. Estas aplicaciones en lugar de ejecutarse en un ambiente hardware (como lo hacen las escritas en C o C++ tradicionales), lo hace sobre un ambiente software (máquina virtual).

El conjunto de librerías base (Base Class Library -BCL- [3]) del Framework constituye elementos para:
  • Creación de interfaces gráficas de usuario
  • Conexión a base de datos
  • Acceso a datos
  • Comunicaciones de red
  • Desarrollo de aplicaciones Web
  • Criptografía
  • Algoritmos numéricos

- El Framework y librerías:

Las librerías que acompañan a la CLR comprenden:
  • Librerías núcleo
  • Librerías aplicaddas (éstas son dependientes de las anteriores).
En la Figura 1 [4] se presenta las relaciones entre estos dos conjuntos de librerías:

Figura 1. Librerías en el Framework .NET
Figura 1. Librerías en el Framework .NET.

Además, en la Figura 1 se observa que el assembly mscorlib.dll es uno de los elementos claves para la escritura de aplicaciones, dado que contiene las estructuras, algoritmos, mecanismos, etc., fundamentales para empezar la escritura de código para el diseño de nuevos aplicaciones.

A continuación, se muestra lo que ocurre con el código de las aplicaciones que utilizan los assemblies de .NET Framework.


- Managed Code y la CLR:

¿Qué es managed code? En la red existen numerosas respuestas a este nuevo término introducido por Microsoft para referirse a piezas de código que requieren de una manipulación más sofisticada, óptima, y rápida que pudiera lograr el propio programador de una aplicación. El código gestionado (si así se pudiera traducir), conceptualmente, es manejado por los principios modernos de ingeniería de software: gestión automática de memoria, colección de basura (garbage collection), imposición de medidas de seguridad en el host, entre otros servicios que le suministran mayo eficacia, rendimiento, y eficiencia las aplicaciones que escribamos.

Otras definiciones: [5], [6]

El código que escribamos en C#, dado que por su naturaleza es uno de los tantos lenguajes de programación gestionados (managed language), tendrá varias de las características de gestión automática (la propia CLR lo llevará a cabo) mencionadas en la definición anterior. Nuestro código quedará empaquetado en un assembly en forma de proceso o ejecutable (.EXE), o como una librería (.dll), e inclusive una metadescripción de tipos [4], estructuras, etc.

El managed code queda representando en Lenguaje Intermedio (para los que conozcan un algo de Java, lo llamaríamos bytecode) -Intermediate Language (IL)-. Cuando pase como entrada la máquina virtual de la CLR, el IL se transformará (a través del compilador JIT de la Common Language Runtime) en código nativo de la máquina adyacente (x86, x64).


- ¿Qué debemos hacer para examinar un assembly?:

Les he hablado sobre una de las características fundamentales de C#: lenguaje gestionado. Y la producción de assemblies (ejecutables de proceso o de librería) que están representados en lenguaje intermedio (IL), es decir que nuestra representación original en código fuente C# ha sido modificada y no podremos recuperarla de manera directa. ¿Qué hacemos? Para esto tenemos una solución conocida como .NET Reflector [7] [8] que facilita la decompilación para devolvernos la representación original (código fuente) de una librería escrita en cualquier de los lenguajes soportados por la CLR.


Conclusiones:

Durante el desarrollo de este texto, se ha mostrado el papel fundamental que juega el .NET Framework, su composición (CLR, BCL, librerías, entre otros). El juego de librerías (interfaz gráfica, conectividad a base de datos, criptografía, y otros) que provee el Framework facilita la escritura de programas en cualquier de los lenguajes compatibles, además de su interoperabilidad. Es importante, además, el entendimiento del concepto de managed code y su relación con la CLR. Finalmente, la presentación de .NET Reflector para la decompilación de assemblies a código legible para los programadores.


Glosario:

- Ambiente Hardware
- Ambiente Software
- BCL
- Bytecode
- Framework
- Interoperabilidad
- Managed code

Referencias:

[1] .NET Framework - https://en.wikipedia.org/wiki/.NET_Framework
[2] Common Language Runtime - http://en.wikipedia.org/wiki/Common_Language_Runtime
[4] C# 5.0 in a Nutshell by Joseph Albahari and Ben Albahari. Copyright 2012 Joseph Albahari and Ben Albahari, 978-1-449-32010-2.
[5] What is managed code?
http://blogs.msdn.com/b/brada/archive/2004/01/09/48925.aspx?wa=wsignin1.0
[6] What exactly is "managed" code? - http://stackoverflow.com/questions/57923/what-exactly-is-managed-code
[7] Red Gate .NET Reflector - http://www.red-gate.com/products/dotnet-development/reflector/
[8] .NET Reflector - http://en.wikipedia.org/wiki/.NET_Reflector

J

No hay comentarios:

Publicar un comentario

Envíe sus comentarios, dudas, sugerencias, críticas. Gracias.