Curso de Visual Basic.NET

Sigamos con mas conceptos básicos sobre .NET. Una aplicación .NET se compone como hemos dicho antes de uno o mas ensamblados, cada uno de los cuales estará formado por uno o mas archivos. La aplicación por tanto puede ser tan simple como un sólo archivo .EXE o un conjuntos de varios archivos de código y elementos externos.

Las aplicaciones .NET se ejecutan en lo que se llama "dominio de la aplicación" que es como un espacio donde se ejecuta nuestra aplicación y está aislada del resto de las aplicaciones que se están ejecutando en Windows. Perfecto para la seguridad y para que un fallo de aplicación no afecte a los demás...

Antes de continuar con otro sencillo ejemplo vamos a conocer un poco sobre el entorno de desarrollo de Visual Studio .NET, (que es obviamente el que utilizamos con Visual Basic .NET), para que podamos configurar algunos aspectos, por ejemplo para indicar cómo se comportará el compilador e intérprete sobre el código que escribamos o para configurar los ensamblados (assemblies) que se usarán en nuestras aplicaciones. (Recuerda que Visual Basic .NET usa una serie de librerías (de clases) con las funciones que necesitemos en cada momento...)

Sigamos, para poder mostrar un texto en la consola, necesitamos tener disponible la librería en la cual está declarada la clase Console, para que podamos acceder a las funciones que dicha clase pone a nuestra disposición, (por ejemplo Write o Read); en este caso la librería en la que está la clase Console es: System. System realmente es un Namespace o espacio de nombres, no es una librería o assembly. (Tranquilo, sigue leyendo)

Luego añadiremos otras librerías para trabajar con bases de datos, gráficos, ... así cada una de ellas agrupa un tipo de funciones.

"Un espacio de nombres es un esquema lógico de nombres para tipos en el que un nombre de tipo simple, como MiTipo, aparece precedido por un nombre jerárquico separado por puntos. [...]"

Así es como lo definen en el eBook de .NET Framework de Microsoft. Pero mas claro... un Namespace es una forma de agrupar clases, funciones, tipos de datos, etc. que están relacionadas entre sí. Por ejemplo, entre los Namespaces que podemos encontrar en el .NET Framework encontramos uno con funciones relacionadas con Visual Basic: Microsoft.VisualBasic. Si te fijas, Microsoft y VisualBasic están separados por un punto, esto significa que Microsoft a su vez es un Namespace que contiene otros "espacios de nombres", tales como el mencionado VisualBasic, CSharp y Win32 con el cual podemos acceder a eventos o manipular el registro del sistema...

Para saber que es lo que contiene un Namespace, simplemente escribe el nombre con un punto y te mostrará una lista desplegable con los miembros que pertenecen a dicho espacio de nombres. Haz la prueba y en el código escribe la palabra "Microsoft." (Con el punto al final), verás que se despliega los posibles Namespaces disponibles y si seguimos y escribimos, o seleccionamos VisualBasic con un punto al final, veremos otra vez los Namespaces de esta otra clase llamada VisualBasic.

Pero de momento no te líes, simplemente que podemos utilizar como una especie de grupos de instrucciones y otros componentes añadiendo o utilizando "namespaces" a nuestros programas. De esta forma mantenemos los recursos de las aplicaciones en diferentes sitios reduciendo los conflictos.

Por regla general se deberían agrupar en un Namespace funciones o clases que estén relacionadas entre sí. De esta forma, será más fácil saber que estamos trabajando con funciones relacionadas entre sí. Pero el que distintos espacios de nombres pertenezcan a un mismo Namespace no significa que todos estén dentro de la misma librería o assembly. Un Namespace puede estar repartido en varios assemblies o librerías. Por otro lado, un assembly, (o ensamblado), puede contener varios Namespaces.

Hay espacios de nombres específicos por ejemplo para los gráficos y otros para trabajar con bases de datos, así los tenemos organizados de una forma mas cómoda para localizarlo y referirnos a ellos en el código.

Pero de esto no debemos preocuparnos, ya que el IDE de Visual Studio .NET se encarga de "saber" en que assembly está el Namespace que necesitamos.

Los Spacenames mas importantes, los de primer nivel y de los que luego "cuelgan" o pertenecen los demás son:

• System. Contiene clases fundamentales y clases base que definen los valores y tipos de datos de referencia, eventos y controladores de eventos, interfaces, atributos y excepciones de procesamiento comúnmente utilizados.
• Microsoft.VisualBasic. Contiene clases que admiten la compilación y generación de código mediante el lenguaje Basic .NET.

Otra vez te ruego tranquilidad y tiempo, a medida que avancemos en .NET irás juntando todos estos conceptos.

"Los ensamblados componen la unidad fundamental de implementación, control de versiones, reutilización, ámbito de activación y permisos de seguridad en una aplicación basada en .NET. Los ensamblados adoptan la forma de un archivo ejecutable (.exe) o un archivo de biblioteca de vínculos dinámicos (.dll), y constituyen unidades de creación de .NET Framework. Proporcionan a Common Language Runtime la información que necesita para estar al corriente de las implementaciones de tipos. Un ensamblado puede entenderse como una colección de tipos y recursos que forman una unidad lógica de funcionalidad y que se generan para trabajar conjuntamente"

Para que nos entendamos, podríamos decir que un assembly es una librería dinámica (DLL) o programa ejecutable en la cual pueden existir distintos espacios de nombres. Aunque esto es simplificar mucho, por ahora nos vale.

Un ensamblado o assembly puede estar formado por varios ficheros DLLs y EXEs, pero lo más importante es que todos los ensamblados contienen un manifiesto (o manifest), gracias al cual se evitan muchos de los quebraderos de cabeza a los que Windows nos tiene acostumbrados, al menos en lo referente a las distintas versiones de las librerías y ejecutables. Este manifiesto es una tabla de contenido del Assembly que lo identifica y dice su versión y otros datos. Esta información elimina lo que en otras versiones se llamaba "infierno de las DLL" por los enormes problemas de versiones y conflictos que generaban.

Por ejemplo, supongamos que tenemos una librería DLL que en su primera versión contenía X funciones. Al tiempo, se crea la segunda versión de dicha librería en la que se cambian algunas funciones y se añaden otras nuevas, para mejorar el rendimiento de las funciones contenidas en esa librería se usa otra DLL que es usada por algunas de las funciones contenidas en esa segunda versión. Esa otra librería puede ser una librería del sistema, la cual a su vez se actualiza con nueva funcionalidad y puede que dicha funcionalidad dependa a su vez de una tercera librería.

Resulta que instalamos un programa que usa las últimas versiones de todas estas librerías. Todo va bien, el programa funciona a las mil maravillas y nosotros estamos muy satisfechos de ese programa que no se cuelga ni una sola vez... Ahora llega a nuestras manos otra aplicación que necesitamos instalar y la instalamos, pero resulta que esa aplicación usa la primera versión de nuestra famosa librería. Si el programa de instalación está bien hecho, no ocurrirá nada malo, ya que al descubrir que tenemos una versión más reciente de la librería, deja la que ya está instalada. Probamos el programa de todo funciona bien. Probamos el maravilloso programa anterior y también funciona bien. ¿Cual es el problema? Por ahora ninguno, pero espera...

Después instalamos un programa que usa una de las librerías del sistema u otra que también usa nuestra "flamante" librería, pero ese programa se ha instalado de "mala manera", bien porque el programa de instalación sea malo o bien porque simplemente se ha instalado mal... como quiera que ha instalado una librería anterior a la que nuestros dos maravillosos ejecutables usan, se puede dar el caso de que ninguno de los dos programas funcionen correctamente... esto ocurrió cuando salió el Internet Explorer 4 y causó no pocos problemas... aunque también ha ocurrido con otros programas que no han tenido en cuenta a la hora de instalar que ya existe una versión más reciente de la librería. Por suerte, esto ya es menos común que hace unos años, sobre todo si los programas de instalación están creados con el Windows Installer o estamos usando el Windows 2000/XP.

Pero es que .NET mejora aún esa "imposibilidad" de meter la pata ya que cada assembly contiene un manifiesto en el cual se indica:

• Nombre y la versión del assembly
• Si este assembly depende de otros ensamblados, con lo cual se indica hasta la versión de dichos ensamblados
• Los tipos expuestos por el assembly (clases, etc.)
• Permisos de seguridad para los distintos tipos contenidos en el assembly.
• Datos del copyright, etc.

Nuevamente hay que comentar que no hay que preocuparse mucho de esto, ya que es el propio .NET el que se encarga de que todo funcione correctamente (al menos a priori)

La ventaja de los ensamblados es que "realmente" no necesitan de una instalación y un registro correcto en el registro del sistema de Windows, ya que es el "intérprete" de .NET el que se encarga de hacer las comprobaciones cuando tiene que hacerlas. Por tanto podríamos distribuir una aplicación sin necesidad de crear un programa de instalación. Pero, (¿por qué siempre hay un pero?), si la aplicación usa ensamblados compartidos, puede que sea necesario usar una instalación.

Los ensamblados compartidos se pueden usar por varias aplicaciones diferentes y deben estar "debidamente" instalados en el directorio asignado por el propio .NET Framework.

Ejemplo de ensamblados compartidos son los que definen las clases (tipos) usados por el propio .NET Framework.

Pues si, como hemos dicho antes el CLR, o el entorno de ejecución común admite por encima de él cualquier tipo de lenguaje. Actualmente esos son los aprobados:

• VB .NET
• C#
• C ++
• ASP.NET
• Jscript.NET

Pero hay otros muchos que están en camino y que podríamos utilizarlos con el mismo entorno y clases que los existentes:

• Cobol
• Pascal
• Perl
• Python
• SmallTalk
• ML
• ...