Déclaration VB.NET Imports par rapport aux références

L'effet réel de l'instruction Imports dans VB.NET est souvent une source de confusion pour les personnes apprenant la langue. Et l'interaction avec les références VB.NET crée encore plus de confusion. Nous allons clarifier cela dans ce petit conseil.

Voici un bref résumé de toute l'histoire. Ensuite, nous passerons en revue les détails.

Une référence à un espace de noms VB.NET est une exigence et doit être ajoutée à un projet avant que les objets de l'espace de noms puissent être utilisés. (Un ensemble de références est automatiquement ajouté pour les différents modèles dans Visual Studio ou VB.NET Express. Cliquez sur "Afficher tous les fichiers" dans l'Explorateur de solutions pour voir ce qu'ils sont.) Mais l'instruction Imports n'est pas obligatoire. Au lieu de cela, c'est simplement une commodité de codage qui permet d'utiliser des noms plus courts.

Voyons maintenant un exemple réel. Pour illustrer cette idée, nous allons utiliser l'espace de noms System.Data - qui fournit la technologie de données ADO.NET.

System.Data est ajouté aux applications Windows comme référence par défaut à l'aide du modèle d'application Windows Forms VB.NET.

Ajout d'un espace de noms dans la collection de références

L'ajout d'un nouvel espace de noms à la collection Références dans un projet met également les objets de cet espace de noms à la disposition du projet. L'effet le plus visible est que Visual Studio "Intellisense" vous aidera à trouver les objets dans les boîtes de menu contextuelles.

Si vous essayez d'utiliser un objet dans votre programme sans référence, la ligne de code génère une erreur.

La déclaration d'importation, en revanche, n'est jamais requise. La seule chose qu'il fait est de permettre la résolution du nom sans être pleinement qualifié. En d'autres termes (accent mis pour montrer les différences).

 Importations System.Data

 Formule de classe publique1

    Hérite de System.Windows.Forms.Form

    Sous-formulaire privé1_Load (… 

       Dim Test As OleDb.OleDbCommand

    End Sub

 Fin de classe 

et

 Importations System.Data.OleDb

 Formule de classe publique1

    Hérite de System.Windows.Forms.Form

    Sous-formulaire privé1_Load (… 

       Dim Test As OleDbCommand

    End Sub

 Fin de classe 

sont tous deux équivalents. Mais…

 Importations System.Data

 Formule de classe publique1

    Hérite de System.Windows.Forms.Form

    Sous-formulaire privé1_Load (… 

       Dim Test As OleDbCommand

    End Sub

 Fin de classe 

entraîne une erreur de syntaxe ("Le type 'OleDbCommand' n'est pas défini") en raison de la qualification de l'espace de noms Imports System.Data ne fournit pas suffisamment d'informations pour trouver l'objet OleDbCommand.

Bien que la qualification des noms dans le code source de votre programme puisse être coordonnée à n'importe quel niveau de la hiérarchie «apparente», vous devez toujours choisir le bon espace de noms à référencer. Par exemple, .NET fournit un espace de noms System.Web et toute une liste d'autres commençant par System.Web…

Remarque

Il existe deux fichiers DLL entièrement différents pour les références. Vous devez choisir la bonne parce que WebService n'est pas une méthode dans l'une d'elles.