Curso de iniciación a la programación con Visual Basic .NET

Iniciado el 08/Sep/2001
Última revisión del 12/Oct/2001
Publicada el 12/Oct/2001
Autor: Guillermo 'guille' Som

Introducción:

Debido a que la nueva versión de Visual Basic no es sólo una mejora con respecto a las versiones anteriores, sino que cambia mucho, tanto como si de otro lenguaje de programación se tratara, creo que se merece que se explique de forma más o menos fácil de comprender para que cualquiera que se decida a elegirlo como su lenguaje de programación lo tenga, valga la redundancia, fácil.
Tan fácil como permitan las circunstancias, y además, (para que esto de estudiar no resulte algo tedioso), tan ameno como me sea posible, ya que las cosas se pueden explicar de muchas formas y, a pesar de parecer que peco de falta de modestia, estoy seguro que este curso de iniciación a la programación con Visual Basic .NET te va a resultar ameno y fácil de comprender... ¡seguro!
Pero no sólo vas a aprender a programar con VB.NET, sino que al estar "basado" en el .NET Framework, conocerás lo suficiente de este marco de desarrollo que podrás atreverte con otros lenguajes .NET, tales como c#, ya que al fin y al cabo, el corazón de los lenguajes .NET es el .NET Framework.

Para ir aclarando ideas, veamos algunos conceptos que habrá que tener claros desde el principio:
Visual Basic .NET usa una jerarquía de clases que están incluidas en el .NET Framework, por tanto conocer el .NET Framework nos ayudará a conocer al propio Visual Basic .NET, aunque también necesitarás conocer la forma de usar y de hacer del VB ya que, aunque en el fondo sea lo mismo, el aspecto sintáctico es diferente para cada uno de los lenguajes basados en .NET Framework, si no fuese así, ¡sólo existiría un solo lenguaje!

Me imagino que la primera pregunta a la que habría que responder es:

¿Qué es el .NET Framework?

Voy a intentar dar una respuesta que sea fácil de "asimilar", a ver si lo consigo...

Primer intento, lo que se dice en el eBook Microsoft .NET Framework, cuya versión en Castellano puedes conseguir usando este link: (este link está actualizado, al menos a fecha de hoy 10 de noviembre de 2002)

".NET Framework es un entorno para construir, instalar y ejecutar servicios Web y otras aplicaciones.
Se compone de tres partes principales: el Common Language Runtime, las clases Framework y ASP.NET"

Aunque dicho libro está basado en la Beta1 es válido para aclarar conceptos sobre lo que es el .NET Framework además de otros conceptos como el Common Language Runtime (CLR), Common Language Specification (CLS), Common Type System (CTS), Microsoft Intermediate Language (MSIL), los ensamblados o assemblies, así como sobre ASP.NET, conceptos que si bien no son imprescindibles para poder usar Visual Basic .NET, es conveniente leer un poco sobre ellos, para no estar totalmente perdidos cuando nos encontremos con esos conceptos...

Segundo intento, lo que dice la MSDN Library:

"El .NET Framework es un entorno multi-lenguaje para la construcción, distribución y ejecución de Servicios Webs y aplicaciones."
"El .NET Framework es una nueva plataforma diseñada para simplificar el desarrollo de aplicaciones en el entorno distribuido de Internet."
"El .NET Framework consta de dos componentes principales: el Common Language Runtime y la librería de clases .NET Framework."

Tercer intento, aclarando las cosas, para que se te "queden" grabadas:

El .NET Framework es el corazón de .NET, cualquier cosa que queramos hacer en cualquier lenguaje .NET debe pasar por el filtro cualquiera de las partes integrantes del .NET Framework.
El Common Lenguage Runtime (CLR) es una serie de librerías dinámicas (DLLs), también llamadas assemblies, que hacen las veces de las DLLs del API de Windows así como las librerías runtime de Visual Basic o C++. Como sabrás, y si no lo sabes ahora te lo cuento yo, cualquier ejecutable depende de una forma u otra de una serie de librerías, ya sea en tiempo de ejecución como a la hora de la compilación. Pues el CLR es eso, una serie de librerías usadas en tiempo de ejecución para que nuestros ejecutables o cualquiera basado en .NET puedan funcionar. Se acabó eso de que existan dos tipos de ejecutables: los que son autosuficientes y no dependen de librerías externas o los que necesitan de librerías en tiempo de ejecución para poder funcionar, tal es el caso de las versiones anteriores de Visual Basic.
Por otro lado, la librería de clases de .NET Framework proporcionan una jerarquía de clases orientadas a objeto disponibles para cualquiera de los lenguajes basados en .NET, incluido el Visual Basic. Esto quiere decir que a partir de ahora Visual Basic ya no será la "oveja negra" de los lenguajes de programación, sino que tendrá a su disposición todas las clases disponibles para el resto de los lenguajes basados en .NET, (o casi), con lo cual sólo nos diferenciará del resto de programadores en la forma de hacer las cosas: ¡más fáciles!
VB.NET ahora es totalmente un lenguaje orientado a objetos con herencia y todo. También permite crear Threads o hilos o tramas de ejecución y otras cosas que antes nos estaban vetadas. De todo esto veremos en esta serie de "entregas", espero que, aunque es un poco más complicado que el Visual Basic de "siempre", confío en que te sea fácil de asimilar. ¡A ver si lo consigo!

 

Sobre la versión de Visual Basic .NET:

A la hora de escribir estas líneas, la versión de Visual Basic .NET que hay disponible es la que se incluye en la Beta2 de Visual Studio .NET. Pero según dicen, la versión final tendrá pocos cambios con respecto a la Beta 2, así que, espero que todo lo que aquí explique sea válido para la versión definitiva de Visual Basic .NET.

 

Algunas aclaraciones preliminares:

Antes de empezar a ver el código, un par de aclaraciones, que aunque ahora puede ser que te suenen a chino, (si eres chino o conoces ese idioma, sólo decirte que es una frase hecha: "me suena a chino" es como decir: "no sé de que me estás hablando"), pronto serán tan usuales que acabarás por asimilarlas como si toda tu vida las hubieras estado usando... o casi...

Extensión de los ficheros de código.
En Visual Basic .NET a diferencia de lo que ocurría en las versiones anteriores de Visual Basic, sólo existe un tipo de fichero de código, el cual tiene la extensión .vb, en este tipo de fichero pueden coexistir distintos tipos de elementos, por ejemplo: un módulo de clase, un formulario, un módulo de código, un control, etc.; mientras que en las versiones anteriores de Visual Basic, cada uno de estos elementos tenían su propio tipo de fichero con su respectiva extensión. Si no sabes o no quieres saber de lo que ocurría en las versiones anteriores, me parece muy bien... pero esto sólo es para que lo sepas y no te sorprenda, si es que hay algo que aún puede sorprenderte, claro.

Tipos de ejecutables.
Con Visual Basic .NET puedes crear básicamente estos dos tipos de ejecutables:
de consola, no gráfico, al estilo del viejo MS-DOS, y
gráficos, como los que normalmente estamos acostumbrados a ver en Windows.
Existen otros tipos de aplicaciones que se pueden crear con Visual Basic .NET: aplicaciones ASP.NET, (realmente no es una aplicación o ejecutable, sino un compendio de distintos tipos de elementos...), servicios Web, servicios Windows, etc.

 

Nuestra primera aplicación con Visual Basic .NET.

Para ir calentando motores, creo que lo mejor es empezar creando una pequeña aplicación con VB.NET, después iremos aclarando los distintos conceptos usados... así te resultará menos complicado todo lo que tengo preparado para ti.

Inicia el Visual Studio .NET, por defecto te mostrará la "página de inicio" desde la cual pueden crearse nuevos proyectos o bien abrir alguno de los más recientemente abiertos. Pulsa en Nuevo proyecto

Te mostrará los diferentes tipos de proyectos que se pueden crear, en el panel izquierdo selecciona Proyectos de Visual Basic (Visual Basic Projects) y de los que muestra en el panel de la derecha, selecciona Console Application

Tendrás que especificar el directorio en el que se guardará el proyecto, así como el nombre del mismo, (creando un directorio con el nombre del proyecto indicado), deja el nombre que muestra por defecto, en la versión inglesa de Visual Studio .NET se llamará ConsoleApplication1. Pulsa en OK (Aceptar) y se creará el proyecto.

Por defecto te mostrará lo siguiente:

Es decir, creará un fichero llamado Module1.vb, (mostrado a la derecha en el Solution Explorer), con el código necesario para empezar a escribir. Fíjate que además del procedimiento Sub Main, el cual se usará como punto de entrada de nuestro ejecutable, también ha creado una "definición" llamada Module Module1 con su respectivo End Module, el cual indica dónde termina la definición del módulo. Esto es así, porque, como te dije hace un rato, en un mismo fichero .vb, pueden existir distintos tipos de elementos. Por ahora, dejémoslo así... ya habrá tiempo de complicarnos la vida...

Una aclaración: lo que estamos creando es una aplicación tipo consola, es decir, no se creará ninguna ventana gráfica, sino que el ejecutable que vamos a crear funciona desde una ventana de MS-DOS (o consola). Esto lo comprobaremos cuando ejecutemos el proyecto.

Lo que queremos, (o mejor dicho, lo que YO QUIERO), mostrar, es un mensaje que diga algo así como: Hola mundo .NET ¡que original! ¿verdad?, por tanto para mostrar un texto en la "consola", usaremos una función, método o instrucción, (como prefieras llamarla), que si bien no es nativa de Visual Basic .NET, la usaremos como si lo fuese... como veremos más tarde, TODO esto es posible gracias a los assemblies o a las clases incluidas en el .NET Framework. Por ahora simplemente confía en mi y escribe lo que te voy a decir.
La función en cuestión, (realmente todo lo que se usa en .NET son funciones), es Console.Write y se usa de la siguiente forma:
Console.Write("Hola mundo .NET"), es decir incluiremos dentro de paréntesis lo que queremos que se muestre en la consola, en este caso queremos mostrar un texto, el cual hay que incluirlo dentro de comillas dobles.
Escríbelo entre el Sub Main() y el End Sub. Comprueba que cuando escribas Console y el punto, se mostrarán las funciones que Console pone a nuestra disposición, así como una pequeña ayuda, en modo de ToolTip, aunque a esto, o a algo parecido, ya estarás acostumbrado si has usado alguna vez el Visual Basic 5/6.

Bien, ya tenemos todo lo que necesitamos. Ahora tendremos que indicarle al "Entorno Integrado" (IDE) que compile el proyecto y lo ejecute, y después de compilarse el proyecto, se deberá mostrar el texto en una ventana de DOS (o consola).
(Guille, ¿por qué me da la impresión de que no se va a mostrar nada? te gustaría preguntarme en este preciso momento)
Para salir de dudas, pulsa F5 (o a la flecha azul o botón con figura de PLAY de un reproductor)

Pregunta: ¿Que ha pasado?
Respuesta: Realmente se ha mostrado el mensaje en una ventana de consola...
(salvo que hayas cometido algún error, cosa que sólo habrá ocurrido si en lugar de estar leyendo, te has dedicado a hacer tus propias pruebas, así que... ¡HAZ EL FAVOR DE ATENDER EN CLASE! ¡ya tendrás tiempo de hacer tus propias pruebas!)
P: Entonces, ¿por qué no se ve?
R: Porque después de mostrarse se ha cerrado la ventana.
P: ¿Cómo podemos ver el mensaje?
R: Ejecutando el EXE desde una ventana de DOS (o consola)
Pero lo mejor sería hacer que el programa se pare hasta que pulsemos la tecla Intro. Para ello, añade la siguiente línea a continuación de la anterior:
Console.Read()
Pulsa de nuevo F5 y verás como esta vez si que se muestra el mensaje, además de que la ventana no se cierra hasta que pulses Intro.
Realmente puedes escribir lo que te de la gana y se irá mostrando en la ventana de consola, pero hasta que pulses Intro no dejará de mostrarse. (Tampoco iba a ser el primer ejemplo tan perfecto... ¡que te crees!).

Pues ésta es nuestra primera aplicación con el Visual Basic .NET.
Realmente tan inútil como poco práctica, pero... queda muy bien eso de saber que ya somos capaces de crear nuestros propios ejecutables. La verdad es que a estas alturas (o mejor dicho bajuras) del curso o tutorial no pretenderás hacer cosas más "sofisticadas", entre otras razones, porque se supone que no sabes nada de nada... ¿cómo? que si que sabes... que ya has trabajado antes con el Visual Basic... que incluso te has leído mi Curso Básico de VB... entonces... tendrás que esperar algunas entregas o unirte al grupo de estudiantes noveles (o principiantes o novatos o... como quieras llamarlos) y esperar a que los conceptos básicos estén aclarados, ya que este curso es un curso de iniciación y si los que lo siguen ya supieran tanto como tú, no sería un curso de iniciación... pues eso... (¡que borde (desagradable) eres algunas veces Guille!)

Olvidemos a los otros Guilles y sigamos...

Antes de continuar, vamos a conocer un poco sobre el entorno de desarrollo de Visual Studio .NET, (que es el que se usa 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 las librerías (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...

¿Te parece complicado? No te preocupes... ahora simplemente lee y pronto entenderás, pero por favor: ¡lee! no intentes pasar todo este "rollo" por alto, ya que si no te enteras de lo que te estoy contando, seguramente acabarás preguntándomelo por e-mail y la única respuesta que recibirás por mi parte es que te vuelvas a leer toda esta parrafada... gracias.

Por ejemplo, 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.

 

¿Que es un Namespace (o espacio de nombres)?

"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 que mencioné al principio.
Para que nos entendamos, un Namespace, (prefiero usar el nombre en inglés, ya que así es como aparecerá en el código), 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.

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, (viene bien esto de usar la traducción castellana e inglesa de una palabra, para no ser redundante), 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.
Pero de esto no debes preocuparte, ya que el IDE de Visual Studio .NET se encarga de "saber" en que assembly está el Namespace que necesitamos.

 

¿Que es un assembly (o ensamblado)?

"Un ensamblado es el bloque constructivo primario de una aplicación de .NET Framework. Se trata de una recopilación de funcionalidad que se construye, versiona e instala como una única unidad de implementación (como uno o más archivos). [...]"

Para que nos entendamos, podríamos decir que un assembly es una librería dinámica (DLL) 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, seguramente habrás oído hablar de las DLL Hell (o librerías del demonio) expresión que se usa cuando hay incompatibilidad de versiones entre varias librerías que están relacionadas entre si.
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 "supersatisfechos" de ese programa que no se cuelga ni una sola vez... (¿quién habrá hecho ese programa tan maravilloso?, sin comentarios...)
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 programilla de marras y 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 una caca 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 a más de uno nos trajo de cabeza, 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:
-el 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.
También se incluyen en los assemblies los datos del copyright, etc.

Nuevamente he de decirte que no debes preocuparte demasiado por esto, ya que es el propio .NET el que se encarga de que todo funciones a las mil maravillas, o al menos esa es la intención.

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.

Para terminar esta primera entrega introductoria al mundo .NET vamos a ver algunos conceptos que usaremos con bastante frecuencia en el resto de las entregas:

Nota:
Las palabras o conceptos están en la página del glosario.

 

Y hasta aquí hemos llegado en esta primera entrega del Curso de iniciación a la programación con Visual Basic .NET

Nos vemos.
Guillermo

Esta entrega ha sido escrita en varios periodos de tiempo, empezándose el día 8 de Septiembre y terminándose el 12 de Octubre de 2001, aunque no he estado todo ese mes y pico escribiendo, que tampoco ese eso.