VB.NET Imports Statement Versus References

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. Were going to clear that up in this Quick Tip. Heres a brief summary of the whole story. Then well 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, its simply a coding convenience that allows shorter names to be used. Now lets look at an actual example. To illustrate this idea, were 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 doesnt 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 isnt a method in one of them.