Managing Namespaces in VB.Net

A namespace is a way to disambiguate one public interface from another. You can happily go through life not worrying about explicitly declaring namespaces in your VB.Net code because of VB.Net's automatic namespace creation. So you can create a project, give it a name, and start writing code. Beautiful and blissful.

Then one day, you wake up and the solution your team works on won't compile.

This will happen to you as a result of not managing your projects' namespaces properly. Eventually, you will need to understand what VB.Net is doing. And fix it.

A VB.Net project has a root namespace property, set by default to your project's name. For example, in a project named "VBNetLib," you have a class called "MyUsefulClass" that looks like this:

Public Class MyUsefulClass

Public Shared Sub DoesSomethingGood()

End Sub

End Class

You can access the DoesSomethingGood() method from another project like this:

VBNetLib.MyUsefulClass.DoSomethingUseful()

In the VBNetLib project, you'll see the Root Namespace property set to "VBNetLib." That is why you must call DoSomethingUseful as shown above, i.e., in the form namespace.class.method.

One day, let's suppose you read a C# book and notice every single class, without exception, has the namespace explicitly in the source code:

namespace CSNetLib

{

public class MyUsefulClass

{

public MyUsefulClass()

{

}

public static void DoesSomethingUseful()

{

}

}

}

You right-click on the C# project's properties and see a Default Namespace property, "CSNetLib." Since all those smart people are using C# nowadays, you decide to mimic this and modify your VB.Net class as follows:

Namespace VBNetLib

Public Class MyUsefulClass

Public Shared Sub DoesSomethingGood()

End Sub

End Class

End Namespace

Feeling much better, you compile the solution and see a build error: "'MyUsefulClass' is not a member of 'VBNetLib'. That is because you have just created a nested namespace, VBNetLib.VBNetLib, and the method can only be called this way:

VBNetLib.VBNetLib.MyUsefulClass.DoesSomethingUseful()

C# and VB.Net have similar looking project properties, but they are not equivalent. C# requires an explicit namespace in all source code, and a C# project's default namespace automatically adds this to new classes. VB.NET does not require an explicit namespace in source code, and a VB.Net project's root namespace is not used as a template for new source code but is instead a second way to specify a namespace in VB.Net projects. The other way is like C#: explicitly add a namespace declaration to your source code as shown above.

Many people recommend (and I will too -- note that some do not) that you set a VB.Net project's default namespace to blank (i.e., delete whatever is there) and instead explicitly declare (yes, manually type in) a project's namespace in all source code. This will make it easier to manage the scope of your classes and will make obvious how to access code in referenced assemblies. Spending time chasing down a nested namespace problem is not one of the joy's of VB.Net programming. Try to avoid ever encountering it.

[@more@]