The VB.NET Imports Statement

Imports and References in VB.NET are often confused.

Businessman with hands on chin at workstation
Thomas Barwick/Stone/Getty Images

The actual effect of the Imports statement in VB.NET is often a source of confusion for people learning the language. And the interaction with VB.NET References makes for even more confusion. We're going to clear that up in this Quick Tip.

Here's a brief summary of the whole story. Then we'll go over the details.

A Reference to a VB.NET namespace is a requirement and must be added to a project before the objects in the namespace can be used.

(A set of references is automatically added for the different templates in Visual Studio or VB.NET Express. Click "Show All Files" in Solution Explorer to see what they are.) But the Imports statement is not a requirement. Instead, it's simply a coding convenience that allows shorter names to be used.

Now let's look at an actual example. To illustrate this idea, we're going to use the System.Data namespace - which provides the ADO.NET data technology.

System.Data is added to Windows applications as a Reference by default using the VB.NET Windows Forms Application template.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

Adding a new namespace to the References collection in a project makes the objects in that namespace available to the project as well. The most visible effect of this is that the Visual Studio "Intellisense" will help you find the objects in popup menu boxes.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

If you attempt to use an object in your program without a Reference, the line of code generates an error.

--------​
Click Here to display the illustration
Click the Back button on your browser to return
--------

The Imports statement, on the other hand, is never required. The only thing it does is allow the name to be resolved without being fully qualified. In other words (emphasis added to show the differences) ...

 Imports System.Data
 Public Class Form1
    Inherits System.Windows.Forms.Form
    Private Sub Form1_Load( ...
       Dim Test As OleDb.OleDbCommand
    End Sub
 End Class 

and

 Imports System.Data.OleDb
 Public Class Form1
    Inherits System.Windows.Forms.Form
    Private Sub Form1_Load( ...
       Dim Test As OleDbCommand
    End Sub
 End Class 

are both equivalent. But ...

 Imports System.Data
 Public Class Form1
    Inherits System.Windows.Forms.Form
    Private Sub Form1_Load( ...
       Dim Test As OleDbCommand
    End Sub
 End Class 

results in a syntax error ("Type 'OleDbCommand' is not defined") because the Imports namespace qualification System.Data doesn't provide enough information to find the object OleDbCommand.

Although the qualification of names in your program source code can be coordinated at any level in the 'apparent' hierarchy, you still have to pick the right namespace to reference. For example, .NET provides a System.Web namespace and a whole list of others starting with System.Web ...

--------​
Click Here to display the illustration
Click the Back button on your browser to return
--------

Note that there are two entirely different DLL files for the references. You DO have to pick the right one because WebService isn't a method in one of them.

--------
Click Here to display the illustration
Click the Back button on your browser to return
--------

Format
mla apa chicago
Your Citation
Mabbutt, Dan. "The VB.NET Imports Statement." ThoughtCo, Jun. 9, 2017, thoughtco.com/the-vbnet-imports-statement-3424234. Mabbutt, Dan. (2017, June 9). The VB.NET Imports Statement. Retrieved from https://www.thoughtco.com/the-vbnet-imports-statement-3424234 Mabbutt, Dan. "The VB.NET Imports Statement." ThoughtCo. https://www.thoughtco.com/the-vbnet-imports-statement-3424234 (accessed December 12, 2017).