Creating Your Own Namespaces

Every assembly created in .NET is part of some root namespace. By default assemblies are assigned a namespace that matches the project name. In .NET it is possible to change this default behavior. Just as Microsoft has packaged the system-level and CLR classes using well-defined names, you can create your own namespaces. Of course, it is also possible to create projects that match existing namespaces and extend those namespaces, but that is typically a poor programming practice.

Namespaces can be created at one of two levels in Visual Basic. Similar to C# it is possible to explicitly assign a namespace within a source file using the Namespace keyword. However, Visual Basic provides a second way of defining your custom namespace. By default one of your project properties is the root namespace for your application in Visual Basic. This root namespace will be applied to all classes that don't explicitly define a namespace. You can review your project's default namespace by accessing the project properties. This is done through the assembly's project pages, reached by right-clicking the solution name in the Solution Explorer window and working off the first tab (Application) within the Properties page that opens in the document window, as shown in Figure 2.11.

Figure 2.11 Application settings in project properties

The next step is optional, but, depending on whether you want to create a class at the top level or at a child level, you can add a Namespace command to your code. There is a trick to being able to create top-level namespaces or multiple namespaces within the modules that make up an assembly. Instead of replacing the default namespace with another name, you can delete the default namespace and define the namespaces only in the modules, using the Namespace command.

The Namespace command is accompanied by an End Namespace command. This End Namespace command must be placed after the End Class tag for any classes that will be part of the namespace. The following code demonstrates the structure used to create a MyMetaNamespace namespace, which contains a single class:

Namespace MyMetaNamespace
    Class MyClass1
       ' Code
    End Class
End Namespace

You can then utilize the MyClass1 object simply by referencing its namespace, MyMetaNamespace.MyClass1. It is also possible to have multiple namespaces in a single file, as shown here:

Namespace MyMetaNamespace1
    Class MyClass1
       ' Code
    End Class
 End Namespace
Namespace MyMetaNamespace2
   Class MyClass2
      ' Code
    End Class
 End Namespace

Using this kind of structure, if you want to utilize MyClass1, then you access it through the namespace MyMetaNamespace.MyClass1. This does not give you access to MyMetaNamespace2 and the objects that it offers; instead, you have to make a separate reference to MyMetaNamespace2.MyClass2. Note typically it is best practice to place each class into a separate file; similarly, having multiple namespaces in a single file is not considered best practice.

The Namespace command can also be nested. Using nested Namespace commands is how child namespaces are defined. The same rules apply — each Namespace must be paired with an End Namespace and must fully encompass all of the classes that are part of that namespace. In the following example, the MyMetaNamespace has a child namespace called MyMetaNamespace.MyChildNamespace:

Namespace MyMetaNamespace
    Class MyClass1
       ' Code
    End Class
    Namespace MyChildNamespace
       Class MyClass2
          ' Code
       End Class
    End Namespace
End Namespace

This is another point to be aware of when you make references to other namespaces within your own custom namespaces. Consider the following example:

Imports System
Imports System.Data
Imports System.Data.SqlClient
Imports System.IO
Namespace MyMetaNamespace1
    Class MyClass1
       ' Code
    End Class
End Namespace
Namespace MyMetaNamespace2
   Class MyClass2
      ' Code
   End Class
End Namespace

In this example, a number of different namespaces are referenced in the file. The four namespaces referenced at the top of the code listing—the System, System.Data, and System.Data.SqlClient namespace references—are available to every namespace developed in the file. This is because these three references are sitting outside of any particular namespace declarations. However, the same is not true for the System.IO namespace reference. Because this reference is made within the MyMetaNamespace2 namespace, it is unavailable to any other namespace in the file.

Sometimes when you are working with custom namespaces, you might find that you have locked yourself out of accessing a particular branch of a namespace, purely due to naming conflicts. Visual Basic includes the Global keyword, which can be used as the outermost root class available in the .NET Framework class library. Figure 2.12 shows a diagram of how the class structure looks with the Global keyword.

Figure 2.12 Visual Basic's Global keyword's namespace hierarchy

This means that you can make specifications such as:

Global.System.String

or

Global.Wrox.System.Titles