What Is a Namespace?

Namespaces are a way of organizing the vast number of classes, structures, enumerations, delegates, and interfaces that the .NET Framework class library provides. Namespaces are a hierarchically structured index into a class library, which is available to all of the .NET languages, not only the Visual Basic 2005 language (with the exception of the new My namespace). The namespaces, or object references, are typically organized by function. For example, the System.IO namespace contains classes, structures, and interfaces for working with input/output streams and files. The classes in this namespace do not necessarily inherit from the same base classes (apart from Object, of course).

A namespace is a combination of a naming convention and an assembly, which organizes collections of objects and prevents ambiguity in object references. A namespace can be, and often is, implemented across several physical assemblies, but from the reference side it is the namespace that ties these assemblies together. A namespace consists of not only classes, but also other (child) namespaces. For example, IO is a child namespace of the System namespace.

Namespaces provide identification beyond the component name. With a namespace, it is possible to use a more meaningful title (for example, System) followed by a grouping (for example, Text) to group together a collection of classes that contain similar functions. For example, the System.Text namespace contains a powerful class called StringBuilder. To reference this class, you can use the fully qualified namespace reference of System.Text.StringBuilder, as shown here:

  Dim sb As New System.Text.StringBuilder() 

The structure of a namespace is not a reflection of the physical inheritance of classes that make up a namespace. For example, the System.Text namespace contains another child namespace called RegularExpressions. This namespace contains several classes, but they do not inherit or otherwise reference the classes that make up the System.Text namespace.

Figure 8-1 shows how the System namespace contains the Text child namespace, which also has a child namespace, called RegularExpressions. Both of these child namespaces, Text and Regular - Expressions, contain a number of objects in the inheritance model for these classes, as shown.

Figure 8-1

As you can see in Figure 8-1, while some of the classes in each namespace do inherit from each other, and while all of the classes eventually inherit from the generic Object, the classes in System.Text.RegularExpressions do not inherit from the classes in System.Text.

You may be wondering at this point what all the fuss is about. To emphasize the usefulness of namespaces, we can draw another good example from Figure 8-1. If you make a reference to System.Drawing .Imaging.Encoder in your application, then you are making a reference to a completely different Encoder class than the namespace shown in Figure 8-1 - System.Text.Encoder. Being able to clearly identify classes that have the same name though very different functions, and disambiguate them, is yet another advantage of namespaces.

If you are an experienced COM developer, you may note that unlike a ProgID, which is a one-level relationship between the project assembly and class, a single namespace can use child namespaces to extend the meaningful description of a class. The System namespace, imported by default as part of every project created with Visual Studio, contains not only the default Object class, but also many other classes that are used as the basis for every .NET language.

What if a class you need isn’t available in your project? The problem may be with the references in your project. For example, by default, the System.DirectoryServices namespace, used for getting programmatic access to the Active Directory objects, isn’t part of your project’s assembly. Using it requires adding a reference to the project assembly. The concept of referencing a namespace is very similar to the ability to reference a COM object in VB6.

In fact, with all this talk about referencing, it’s probably a good idea to look at an example of adding an additional namespace to a project. Before doing that, you need to know a little bit about how a namespace is actually implemented.

Namespaces are implemented within .NET assemblies. The System namespace is implemented in an assembly called System.dll provided with Visual Studio. By referencing this assembly, the project gains the ability to reference all of the child namespaces of System that happen to be implemented in this assembly. Using the preceding table, the project can import and use the System.Text namespace because its implementation is in the System.dll assembly. However, although it is listed, the project cannot import or use the System.Data namespace unless it references the assembly that implements this child of the System namespace, System.Data.dll.

Let’s create a sample project so you can examine the role that namespaces play within it. Using Visual Studio 2005, create a new Visual Basic 2005 Windows Application project called Namespace_Sampler.

The Microsoft.VisualBasic.Compatibility.VB6 library isn’t part of Visual Basic 2005 projects by default. To gain access to the classes that this namespace provides, you need to add it to your project. You can do this by using the Add Reference dialog box (available by right-clicking the Project name node within the Visual Studio Solution Explorer). The Add Reference dialog box has five tabs, each containing elements that can be referenced from your project:

• The first tab, with the title of .NET, contains .NET assemblies that can be found in the GAC. In addition to providing you with the name of the assembly, you can also get the version of the assembly and the version of the framework to which the assembly is compiled. The final data point found in this tab is the location of the assembly on the machine.

• The second tab, COM, contains all the available COM components. This tab provides the name of the component, the TypeLib version, and the path of the component.

• The third tab, Projects, contains any custom .NET assemblies from any of the various projects contained within your solution.

• The fourth tab, Browse, enables you to look for any component files (.dll, .tlb, .olb, .ocx, .exe, or .manifest) that are on the network.

• The last and fifth tab, Recent, lists the most recently made references for quick referencing capabilities.

The Add Reference dialog is shown in Figure 8-2.

Figure 8-2

The available .NET namespaces are listed by component name. This is the same as the namespace name. Within the dialog you can see a few columns that supply the namespace of the component, the version number of the component, the version of the .NET Framework for which the particular component is targeted, and the path location of the file. You can select a single namespace to make a reference to by clicking your mouse on the component that you are interested in. Holding down the Ctrl key and pressing the mouse button enables you to select multiple namespaces to reference.

To select a range of namespaces, first click on either the first or last component in the dialog that is contained in the range, and then complete the range selection by holding down the Shift key and using the mouse to select the other component in the range. Once you have selected all the components that you are interested in referencing, press the OK button.

The example in Figure 8-2 is importing some namespaces from the Microsoft.VisualBasic namespace, even though only one selection has been made. This implementation, while a bit surprising at first, is very powerful. First, it shows the extensibility of namespaces. This is due to the fact that the single Microsoft.VisualBasic.Compatibility.VB6 namespace is actually implemented in two separate assemblies. If you also make a reference to the Microsoft.VisualBasic.Compatibility namespace as well as the Microsoft.VisualBasic.Compatibility.Data namespace, you will see (through the Object Browser found in Visual Studio) that the Microsoft.VisualBasic.Compatibility.VB6 namespace is really found in both locations. This is shown in Figure 8-3.

Figure 8-3

Second, this implementation is powerful in that it enables you to include only the classes that you need - in this case, those that are related to the VB6 (Visual Basic 6) environment or to database tools, or both types. Note some interesting points about the Microsoft.VisualBasic namespace. First, this namespace gives you access to all the functions that VB6 developers have had for years. Microsoft has implemented these in the .NET Framework and made them available for your use within your .NET projects. Because these functions have been implemented in the .NET Framework, there is absolutely no performance hit for using them, but you will most likely find the functionality that they provide available to you in newer .NET namespaces. Contrary to what the name of the namespace suggests, this namespace is available for use by all of the .NET languages, which means that even a C# developer could use the Microsoft.VisualBasic namespace if desired.

Namespaces and References

Highlighting their importance to every project, references (including namespaces) are no longer hidden from view - available only after opening a dialog box as they were in VB6. As shown in the Solution Explorer window in Figure 8-4, every new project comes with a set of referenced namespaces. (If you don’t see the references listed in Solution Explorer, press the Show All Files button from the Solution Explorer menu.)

Figure 8-4

The list of default references varies based on the type of project. The example in Figure 8-4 shows the default references for a Windows Forms project in Visual Studio 2005. If the project type is an ASP.NET Web Application, the list of references changes appropriately - the reference to the System.Windows.Forms namespace assembly is replaced by a reference to System.Web. If the project type is an ASP.NET Web Service (not shown), then the System.Windows.Forms namespace is replaced by references to the System.Web and System.Web.Services namespaces.

In addition to making the namespaces available, references play a second important role in your project. One of the advantages of .NET is using services and components built on the common language runtime (CLR), which enables you to avoid DLL conflicts. The various problems that can occur related to DLL versioning, commonly referred to as DLL hell, involve two types of conflict.

The first situation occurs when you have a component that requires a minimum DLL version, and an older version of the same DLL causes your product to break. The alternative situation is when you require an older version of a DLL, and a new version is incompatible. In either case, the result is that a shared file, outside of your control, creates a systemwide dependency that impacts your software. As part of .NET, it is possible, but not required, to indicate that a DLL should be shipped as part of your project to avoid an external dependency.

To indicate that a referenced component should be included locally, you can select the reference in Solution Explorer and then examine the properties associated with that reference. One editable property is called Copy Local. You will see this property and its value in the Properties window within Visual Studio 2005. For those assemblies that are part of a Visual Studio 2005 installation, this value defaults to False. However, for custom references, this property defaults to True to indicate that the referenced DLL should be included as part of the assembly. Changing this property to True changes the path associated with the assembly. Instead of using the path to the referenced file’s location on the system, the project creates a subdirectory based on the reference name and places the files required for the implementation of the reference in this subdirectory, as shown in Figure 8-5.

Figure 8-5

The benefit of this is that even when another version of the DLL is later placed on the system, your project’s assembly will continue to function. However, this protection from a conflicting version comes at a price: Future updates to the namespace assembly to fix flaws will be in the system version but not in the private version that is part of your project’s assembly.

To resolve this, Microsoft’s solution is to place new versions in directories based on their version information. If you examine the path information for all of the Visual Studio 2005 references, you will see that it includes a version number. As new versions of these DLLs are released, they are installed in a separate directory. This method allows for an escape from DLL hell, by keeping new versions from stomping on old versions, and it enables old versions to be easily located for maintenance updates. For this reason, in many cases it is better to leave alone the default behavior of Visual Studio 2005, which is set to copy only locally custom components, until your organization implements a directory structure with version information similar to that of Microsoft.

The Visual Basic 2005 compiler will not allow you to add a reference to your assembly if the targeted implementation includes a reference that isn’t also referenced in your assembly. The good news is that the compiler will help. If, after adding a reference, that reference doesn’t appear in the IntelliSense list generated by Visual Studio 2005, go ahead and type the reference to a class from that reference. The compiler will flag it with one of its Microsoft Word−like spelling or grammar error underlines. Then, when you click the underlined text, the compiler will tell you which other assemblies need to be referenced in the project in order to use the class in question.

Common Namespaces

The generated list of references shown in Solution Explorer for the newly created Namespace_Sampler project includes most, but not all, of the namespaces that are part of your Windows Application project. For example, one namespace not displayed as a reference is Microsoft.VisualBasic and the accompanying Microsoft.VisualBasic.dll. Every Visual Basic 2005 project includes the namespace Microsoft.VisualBasic. This namespace is part of the Visual Studio project templates for Visual Basic 2005 and is, in short, what makes Visual Basic 2005 different from C# or any other .NET language. The implicit inclusion of this namespace is the reason why you can call IsDBNull and other methods of Visual Basic 2005 directly. The only difference in the default namespaces that are included with Visual Basic 2005 and C# Windows Application projects is that the former use Microsoft.VisualBasic and the latter use Microsoft.CSharp.

To see all of the namespaces that are imported automatically, such as the Microsoft.VisualBasic namespace, right-click the project name in Solution Explorer and select Properties from the context menu. This opens the project properties in the Visual Studio document window. Select the References tab from the left pane and you will see the reference Microsoft.VisualBasic at the top of the list (see Figure 8-6).

Figure 8-6

When looking at the project’s global list of imports in the text area at the bottom of the page, you can see that in addition to the Microsoft.VisualBasic namespace, the System.Collections and System.Diagnostics namespaces are also imported into the project. This is signified by the check marks next to the namespace. Unlike the other namespaces in the list, these namespaces are not listed as references in the text area directly above this. That is because the implementation of the System .Collections and System.Diagnostics namespaces is part of the referenced System.dll. Similarly to Microsoft.VisualBasic, importing these namespaces allows references to the associated classes, such that a fully qualified path is not required. Because these namespaces contain commonly used classes, it is worthwhile to always include them at the project level.

The following list briefly summarizes some of the namespaces commonly used in Visual Basic 2005 projects:

• System.Collections - Contains the classes that support various feature-rich object collections. Included automatically, it has classes for arrays, lists, dictionaries, queues, hash tables, and so on. As of .NET 2.0, this namespace also includes the capability to work with the new generics - a way to build type-safe collections as well as provide generic methods and classes.

• System.Data - This namespace contains the classes to support the core features of ADO.NET.

• System.Diagnostics - Included in all Visual Basic 2005 projects, this namespace includes the debugging classes. The Trace and Debug classes provide the primary capabilities, but the namespace contains dozens of classes to support debugging.

• System.Drawing - This namespace contains simple drawing classes to support Windows Application projects.

• System.EnterpriseServices- Not included automatically, the System.EnterpriseServices implementation must be referenced to make it available. This namespace contains the classes that interface .NET assemblies with COM+.

• System.IO - This namespace contains important classes that enable you to read and write to files as well as data streams.

• System.Text - This commonly used namespace enables you to work with text in a number of different ways, usually in regard to string manipulation. One of the more popular objects that this namespace offers is the StringBuilder object.

• System.Threading - This namespace contains the objects to work with and manipulate threads within your application.

• System.Web - This is the namespace that deals with one of the more exciting features of the .NET Framework, ASP.NET. This namespace provides the objects that deal with browser-server communications. Two main objects include HttpRequest, which deals with the request from the client to the server, and HttpResponse, which deals with the response from the server to the client.

• System.Web.Services - This is the main namespace you use when you are creating XML Web Services, one of the more powerful capabilities provided with the .NET Framework. This namespace offers the classes that deal with SOAP messages and the manipulation of these messages.

• System.Windows.Forms - The namespace that provides classes to create Windows Forms in Windows Application projects. This namespace contains the form elements.

Of course, to really make use of the classes and other objects in this list, you need more detailed information. In addition to resources such as Visual Studio 2005’s help files, the best source of information is the Object Browser. It is available directly in the Visual Studio 2005 IDE. You can find it by selecting View Object Browser if you are using Visual Studio 2005 or 2003, or View Other Windows Object Browser if you are using Visual Studio 2002. The Visual Studio 2005 Object Browser is shown in Figure 8-7.

Figure 8-7

The Object Browser displays each of the referenced assemblies and allows you to drill down into the various namespaces. Figure 8-7 illustrates how the System.dll implements a number of namespaces, including some that are part of the System namespace. By drilling down into a namespace, you can see some of the classes available. By further selecting a class, the browser shows not only the methods and properties associated with the selected class, but also a brief outline of what that class does.

Using the Object Browser is an excellent way to gain insight into which classes and interfaces are available via the different assemblies included in your project, and how they work. Clearly, the ability to actually see which classes are available and know how to use them is important in being able to work efficiently. Working effectively in the .NET CLR environment requires finding the right class for the task.