VB.NET Imports Statement Versus References

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 ADO.NET data technology.

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

Adding a Namespace in the References Collection

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.

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

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 of 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 ...

Note

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.