Namespaces in VB.NET

man working on laptop
Klaus Vedfelt/Taxi/Getty Images

The most common way 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:

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.

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:


If you add an Imports statement for both namespaces (a reference may also be necessary for 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

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 (we used the name NSProj and check out the Object Browser tool):

  1. Click Here to display the illustration
  2. 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 (We named ours 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 (we named it NewNSMod). And since an object must be coded as a class, we also added a class block (named NewNSObj). Here's the code and Solution Explorer to show how it fits together:

  1. Click Here to display the illustration
  2. 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

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

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 your namespaces like ...


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


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


Namespace DRNo.Surgery.MyEyeLidsRGone
' VB Code
End Namespace
mla apa chicago
Your Citation
Mabbutt, Dan. "Namespaces in VB.NET." ThoughtCo, Aug. 27, 2020, Mabbutt, Dan. (2020, August 27). Namespaces in VB.NET. Retrieved from Mabbutt, Dan. "Namespaces in VB.NET." ThoughtCo. (accessed March 22, 2023).