Declaración de importaciones de VB.NET versus referencias

El efecto real de la declaración de Importaciones en VB.NET es a menudo una fuente de confusión para las personas que aprenden el idioma. Y la interacción con las referencias de VB.NET crea aún más confusión. Vamos a aclarar eso en este Consejo rápido.

Aquí hay un breve resumen de toda la historia. Luego repasaremos los detalles.

Una referencia a un espacio de nombres VB.NET es un requisito y debe agregarse a un proyecto antes de poder utilizar los objetos en el espacio de nombres. (Se agrega automáticamente un conjunto de referencias para las diferentes plantillas en Visual Studio o VB.NET Express. Haga clic en "Mostrar todos los archivos" en el Explorador de soluciones para ver cuáles son). Pero la declaración de Importaciones no es un requisito. En cambio, es simplemente una conveniencia de codificación que permite usar nombres más cortos.

Ahora veamos un ejemplo real. Para ilustrar esta idea, vamos a utilizar el espacio de nombres System.Data, que proporciona tecnología de datos ADO.NET.

System.Data se agrega a las aplicaciones de Windows como referencia de forma predeterminada mediante la plantilla de aplicación de formularios Windows Forms de VB.NET.

Agregar un espacio de nombres en la colección de referencias

Agregar un nuevo espacio de nombres a la colección References en un proyecto hace que los objetos en ese espacio de nombres también estén disponibles para el proyecto. El efecto más visible de esto es que Visual Studio "Intellisense" lo ayudará a encontrar los objetos en cuadros de menú emergente.

Si intenta usar un objeto en su programa sin una Referencia, la línea de código genera un error.

La declaración de Importaciones, por otro lado, nunca se requiere. Lo único que hace es permitir que se resuelva el nombre sin estar completamente calificado. En otras palabras (énfasis agregado para mostrar las diferencias).

 Importaciones Datos de sistema

 Formulario de clase pública1

    Hereda System.Windows.Forms.Form

    Private Sub Form1_Load (… 

       Prueba tenue como OleDb.OleDbCommand

    End Sub

 Clase final 

y

 Importaciones System.Data.OleDb

 Formulario de clase pública1

    Hereda System.Windows.Forms.Form

    Private Sub Form1_Load (… 

       Prueba tenue como OleDbCommand

    End Sub

 Clase final 

son ambos equivalentes Pero…

 Importaciones Datos de sistema

 Formulario de clase pública1

    Hereda System.Windows.Forms.Form

    Private Sub Form1_Load (… 

       Prueba tenue como OleDbCommand

    End Sub

 Clase final 

da como resultado un error de sintaxis ("El tipo 'OleDbCommand' no está definido") debido al sistema de calificación del espacio de nombres Imports. Los datos no proporcionan suficiente información para encontrar el objeto OleDbCommand.

Aunque la calificación de los nombres en el código fuente de su programa se puede coordinar en cualquier nivel de la jerarquía 'aparente', aún debe elegir el espacio de nombres correcto para hacer referencia. Por ejemplo, .NET proporciona un espacio de nombres System.Web y una lista completa de otros que comienzan con System.Web ...

Nota

Hay dos archivos DLL completamente diferentes para las referencias. DEBE elegir el correcto porque WebService no es un método en uno de ellos.