Los lenguajes de programación suelen componerse de un compilador y un entorno de ejecución. El compilador convierte el código que escribe en código ejecutable que puede ser ejecutado por los usuarios. El entorno de ejecución pro- porciona al código ejecutable un conjunto de servicios de sistema operativo. Estos servicios están integrados en una capa de ejecución de modo que el código no necesite preocuparse de los detalles de bajo nivel de funcionamiento con el siste- ma operativo. Operaciones como la gestión de memoria y la entrada y salida de archivos son buenos ejemplos de servicios realizados por un entorno de ejecu- ción.
Antes de que se desarrollara .NET, cada lenguaje constaba de su propio entor- no de ejecución. Visual Basic consta de un módulo de ejecución llamado MSVBVM60.DLL, Visual C++ utiliza una DLL llamada MSVCRT.DLL. Cada uno de estos módulos de entorno de ejecución proporcionaba un conjunto de ser- vicios de bajo nivel para codificar lo que los programadores escribían. Los pro- gramadores escribían código y luego lo compilaban con el apropiado módulo de ejecución en mente. El código ejecutable incluiría su propio módulo de ejecución, que puede ser instalado en el equipo del usuario si aún no estaba presente.
El principal problema que presentan estos entornos de ejecución es que esta- ban diseñados para usar un solo lenguaje. El tiempo de ejecución de Visual Basic proporcionaba algunas funciones estupendas para operaciones como trabajar con memoria e iniciar objetos COM, pero estas funciones estaban disponibles sólo para los usuarios de Visual Basic. Los programadores que usaban Visual C++ no podían usar las funciones del tiempo de ejecución de Visual Basic. Los usuarios de Visual C++ tenían su propio tiempo de ejecución, con su propia larga lista de funciones, pero esas funciones no estaban disponibles para los usuarios de Visual Basic. Este enfoque de "módulos de ejecución separados" impedía que los lengua- jes pudiesen funcionar conjuntamente sin problemas. No es posible, por ejemplo, tomar algo de memoria en un fragmento de código en Visual Basic y luego pasár- selo a una parte de código en Visual C++, lo que liberaría la memoria. Los diferentes módulos de ejecución implementan su propio conjunto de funciones a su manera. Los conjuntos de funciones de los diferentes módulos de ejecución son inconsistentes. Incluso las funciones que se encuentran en más de un módulo de ejecución se implementan de diferentes formas, haciendo imposible que dos frag- mentos de código escritos en diferentes lenguajes trabajen juntos.
Uno de los objetivos de diseño de .NET Framework era unificar los motores de ejecución para que todos los programadores pudieran trabajar con un solo conjunto de servicios de ejecución. La solución de .NET Framework se llama Entorno común de ejecución (CLR). El CLR proporciona funciones como la ges- tión de memoria, la seguridad y un sólido sistema de control de errores, a cual- quier lenguaje que se integre en .NET Framework. Gracias al CLR, todos los lenguajes .NET pueden usar varios servicios de ejecución sin que los programa- dores tengan que preocuparse de si su lenguaje particular admite una función de ejecución.
El CLR también permite a los lenguajes interactuar entre sí. La memoria puede asignarse mediante código escrito en un lenguaje (Visual Basic .NET, por ejemplo) y puede ser liberada con código escrito en otro (por ejemplo, C#). Del mismo modo, los errores pueden ser detectados en un lenguaje y procesados en otro.
Bibliotecas de clase .NET
A los programadores les gusta trabajar con código que ya ha sido probado y ha demostrado que funciona, como el API Win32 y la biblioteca de clase MFC. La reutilización del código lleva mucho tiempo siendo el objetivo de la comunidad de desarrolladores de software. Sin embargo, la posibilidad de reutilizar el código no ha estado a la altura de las expectativas.
Muchos lenguajes han tenido acceso a cuerpos de código previamente com- probados y listos para ser ejecutado. Visual C++ se ha beneficiado de las biblio- tecas de clase, como las Clases de fundación Microsoft (MFC), que permitió a los programadores de C++ crear aplicaciones Windows rápidamente, y la Biblio- teca activa de plantillas (ATL), que proporciona ayuda para crear objetos COM. No obstante, la naturaleza específica del lenguaje de estas bibliotecas las ha hecho inservibles para ser usadas en otros lenguajes. Los programadores de Vi- sual Basic tienen vetado el uso de ATL para crear sus objetos COM.
.NET Framework proporciona muchas clases que ayudan a los programadores a reutilizar el código. Las bibliotecas de clases .NET contienen código para pro- gramar subprocesos, entrada y salida de archivos, compatibilidad para bases de datos, análisis XML y estructuras de datos, como pilas y colas. Y lo mejor de todo, toda esta biblioteca de clases está disponible para cualquier lenguaje de programación compatible con .NET Framework. Gracias al CLR, cualquier len- guaje .NET puede usar cualquier clase de la biblioteca .NET. Como ahora todos los lenguajes admiten los mismos módulos de ejecución, pueden reutilizar cual- quier clase que funcione con .NET Framework. Esto significa que cualquier funcionalidad disponible para un lenguaje también estará disponible para cual- quier otro lenguaje .NET.
El cuadro de reutilización de bibliotecas de clases dibujado por .NET Framework se vuelve aún mejor cuando se da cuenta de que la reutilización se extiende a su código, no sólo al código que Microsoft lanza con .NET. El código
de Microsoft sólo es código que fue escrito usando un lenguaje que .NET admitía y se compilaba usando una herramienta de desarrollo .NET. Esto significa que Microsoft está usando las mismas herramientas que usará para escribir su códi- go. Puede escribir código capaz de ser usado en otros lenguajes .NET, exacta- mente lo mismo que Microsoft con su biblioteca de clases. .NET Framework permite escribir código en C#, por ejemplo, y enviárselo a programadores en Visual Basic .NET, que pueden usar ese código que compiló en sus aplicaciones. La figura 1.2 ilustra una visión muy general de las bibliotecas de clases .NET.
Figura 1.2. Las bibliotecas de clases .NET Framework