Namespaces in VB.NET


By Dan Mabbutt

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 this article will tell you how to interpret (and … Hey! … maybe even criticize) the namespaces that you will be asked to use in many organizations.

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!”

So far, we have talked about how to use namespaces. On the next page, we’ll talk about when and why.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s