Namespaces in VB.NET

What They Are and How to Use Them

man working on laptop
Klaus Vedfelt/Taxi/Getty Images

The most common way that VB.NET namespaces are used by most programmers is to tell the compiler which .NET Framework libraries are needed for a particular program. When you choose a "template" for your project (such as "Windows Forms Application") one of the things that you're choosing is the specific set of namespaces that will be automatically referenced in your project. This makes the code in those namespaces available to your program.

For example, some of the namespaces and the actual files they are in for a Windows Forms Application are shown below:

System --> in System.dll
System.Data --> in System.Data.dll
System.Deployment --> System.Deployment.dll
System.Drawing --> System.Drawing.dll
System.Windows.Forms --> System.Windows.Forms.dll

You can see (and change) the namespaces and references for your project in the project properties under the References tab. I have previously written about this side of namespaces in the article, References and Namespaces in VB.NET.

This way of thinking about namespaces makes them seem to be just the same thing as "code library" but that's only part of the idea. The real benefit of namespaces is organization.

Most of us won't get the chance to establish a new namespace hierarchy because it's generally only done once 'in the beginning' for a large and complicated code library. But, here, you'll learn how to interpret the namespaces that you will be asked to use in many organizations.

What Namespaces Do

Namespaces make it possible to organize the tens of thousands of .NET Framework objects and all the objects that VB programmers create in projects, too, so they don't clash.

For example, if you search .NET for a Color object, you find two. There is a Color object in both:

System.Drawing
System.Windows.Media

If you add an Imports statement for both namespaces (a reference may also be necessary in the project properties) ...

Imports System.Drawing
Imports System.Windows.Media

... then a statement like ...

Dim a As Color

... will be flagged as an error with the note, "Color is ambiguous" and .NET will point out that both namespaces contain an object with that name. This kind of error is called a "name collision."

This is the real reason for "namespaces" and it's also the way namespaces are used in other technologies (such as XML). Namespaces make it possible to use the same object name, such as Color, when the name fits and still keep things organized. You could define a Color object in your own code and keep it distinct from the ones in .NET (or the code of other programmers).

Namespace MyColor
   Public Class Color
      Sub Color()
         ' Do something
      End Sub
   End Class
End Namespace

You can also use the Color object somewhere else in your program like this:

Dim c As New MyColor.Color
c.Color()

Before getting into some of the other features, be aware that every project is contained in a namespace. VB.NET uses the name of your project (WindowsApplication1 for a standard forms application if you don't change it) as the default namespace.

To see this, create a new project (I used the name NSProj and check out the Object Browser tool:

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

The Object Browser shows your new project namespace (and the automatically defined objects in it) right along with the .NET Framework namespaces. This ability of VB.NET to make your objects equal to .NET objects is one of the keys to the power and flexibility. For example, this is why Intellisense will show your own objects as soon as you define them.

To kick it up a notch, let's define a new project (I named mine NewNSProj in the same solution (use File > Add > New Project ...) and code a new namespace in that project. And just to make it more fun, let's put the new namespace in a new module (I named it NewNSMod).

And since an object must be coded as a class, I also added a class block (named NewNSObj). Here's the code and Solution Explorer to show how it fits together:

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

Since your own code is 'just like Framework code', it's necessary to add a reference to NewNSMod in NSProj to use the object in the namespace, even though they're in the same solution. Once that's done, you can declare an object in NSProj based on the method in NewNSMod. You also need to "build" the project so an actual object exists to reference.

Dim o As New NewNSProj.AVBNS.NewNSMod.NewNSObj
o.AVBNSMethod()

That's quite a Dim statement though. We can shorten that by using an Imports statement with an alias.

Imports NS = NewNSProj.AVBNS.NewNSMod.NewNSObj
...
Dim o As New NS
o.AVBNSMethod()

Clicking the Run button displays the MsgBox from the AVBNS namespace, "Hey! It worked!"

When and Why to Use Namespaces

Everything so far has really just been syntax - the coding rules that you have to follow in using namespaces. But to really take advantage, you need two things:

  • A requirement for namespace organization in the first place. You need more than just a "Hello World" project before the organization of namespaces starts to pay off.
  • A plan to use them.

In general, Microsoft recommends that you organize your organization's code using a combination of your company name with the product name.

So, for example, if you're the Chief Software Architect for Dr. No's Nose Knows Plastic Surgery, then you might want to organize you namespaces like ...

DRNo
   Consulting
      ReadTheirWatchNChargeEm
      TellEmNuthin
   Surgery
      ElephantMan
      MyEyeLidsRGone

This is similar to .NET's organization ...

Object
   System
      Core
         IO
         Linq
      Data
         Odbc
         Sql

The multilevel namespaces are achieved by simply nesting the namespace blocks.

Namespace DRNo
   Namespace Surgery
      Namespace MyEyeLidsRGone
' VB Code
      End Namespace
   End Namespace
End Namespace

... or ...

Namespace DRNo.Surgery.MyEyeLidsRGone
' VB Code
End Namespace