Importing and Aliasing Namespaces

Not all namespaces should be imported at the global level. Although you have looked at the namespaces that are included at this level, it is much better to import namespaces only in the module where they will be used. Importing a namespace at the module level does not change setting the reference, but it does mean that you don’t add it into the list of imports on the project’s property page. As with variables used in a project, it is possible to define a namespace at the module level. The advantage of this is similar to the use of local variables in that it helps to prevent different namespaces from interfering with each other. As this section shows, it is possible for two different namespaces to contain classes or even child namespaces with the same name.

Importing Namespaces

The development environment and compiler need a way to prioritize the order in which namespaces should be checked when a class is referenced. It is always possible to unequivocally specify a class by stating its complete namespace path. This is referred to as fully qualifying your declaration. The following example fully qualifies a StringBuilder object:

  Dim sb As New System.Text.StringBuilder 

However, if every reference to every class needed its full namespace declaration, that would make Visual Basic 2005 and every other .NET language very difficult to program in. After all, who wants to type System.Collections.ArrayList each time an instance of the ArrayList class is wanted? If you review the global references, you’ll see the System.Collections namespace. Thus, you can just type ArrayList whenever you need an instance of this class, as the reference to the larger System.Collections namespace has already been made by the application.

In theory, another way to reference the StringBuilder class is to use Text.StringBuilder, but with all namespaces imported globally, there is a problem with this, caused by what is known as namespace crowding. Because there is a second namespace, System.Drawing, that has a child called Text, the compiler doesn’t have a clear location for the Text namespace and, therefore, cannot resolve the StringBuilder class. The solution to this problem is to ensure that only a single version of the Text child namespace is found locally. That way, the compiler will use this namespace regardless of the global availability of the System.Drawing.Text namespace.

Imports statements specify to the compiler those namespaces that the code will use:

  Imports Microsoft.Win32 Imports System Imports SysDraw = System.Drawing 

Once they are imported into the file, you are not required to fully qualify your object declarations in your code. For instance, if you imported the System.Data.SqlClient namespace into your file, you would then be able to create a SqlConnection object in the following manner:

  Dim conn As New SqlConnection 

Each of the preceding Imports statements illustrates a different facet of importing namespaces. The first namespace, Imports Microsoft.Win32, is not imported at the global level. Looking at the reference list, you may not see the Microsoft assembly referenced directly. However, opening the Object Browser reveals that this namespace is actually included as part of the System.dll.

As noted earlier, the StringBuilder references become ambiguous because both System.Text and System.Drawing.Text are valid namespaces at the global level. As a result, the compiler has no way to distinguish which Text child namespace is being referenced. Without any clear indication, the compiler flags Text.StringBuilder declarations in the command handler. However, using the Imports System declaration in the module tells the compiler that before checking namespaces imported at the global level, it should attempt to match incomplete references at the module level. Because the System namespace is declared at this level, if System.Drawing is not, then there is no ambiguity regarding which child namespace Text.StringBuilder belongs to.

This demonstrates how the compiler looks at each possible declaration:

• It first determines whether the item is a complete reference, such as System.Text.StringBuilder.

• If the declaration does not match a complete reference, then the compiler tries to determine whether the declaration is from a child namespace of one of the module-level imports.

• Finally, if a match has not been found, then the compiler looks at the global-level imports to determine whether the declaration can be associated with a namespace imported for the entire assembly.

While the preceding logical progression of moving from a full declaration through module- to global-level imports resolves the majority of issues, it does not handle all possibilities. Specifically, if you import System.Drawing at the module level, the namespace collision would return. This is where the third import statement becomes important - this import statement uses an alias.

Aliasing Namespaces

Aliasing has two benefits in .NET. First, aliasing allows a long namespace such as System.EnterpriseServices to be replaced with a shorthand name such as COMPlus. Second, it adds a way to prevent ambiguity among child namespaces at the module level.

As noted earlier, the System and System.Drawing namespaces both contain a child namespace of Text. Because you will be using a number of classes from the System.Drawing namespace, it follows that this namespace should be imported into the form’s module. However, were this namespace imported along with the System namespace, the compiler would once again find references to the Text child namespace ambiguous. By aliasing the System.Drawing namespace to SysDraw, the compiler knows that it should only check the System.Drawing namespace when a declaration begins with that alias. The result is that although multiple namespaces with the same child namespace are now available at the module level, the compiler knows that one (or more) of them should only be checked at this level when they are explicitly referenced.

Aliasing as defined here is done in the following fashion:

  Imports SysDraw = System.Drawing 

Referencing Namespaces in ASP.NET

Making a reference to a namespace in ASP.NET is quite similar to working with Windows Forms, but you have to take some simple, additional steps. From your ASP.NET solution, first make a reference to the assemblies from the References folder, just as you do with Windows Forms. Once there, import these namespaces at the top of the page file in order to avoid having to fully qualify the reference every time on that particular page.

For example, instead of using System.Collections.Generic for each instance of use, use the <%# Import %> page directive at the top of the ASP.NET page (if the page is constructed using the inline coding style) or use the Imports keyword at the top of the ASP.NET page’s code-behind file (just as you would with Windows Forms applications). The following shows how to perform this task when using inline coding for ASP.NET pages:

  <%# Import Namespace="System.Collections.Generic" %> 

Now that this reference is in place on the page, you can gain access to everything this namespace contains without the need to fully qualify the object you are accessing. Note that the Import keyword in the inline example is not missing an “s” at the end. When importing in this manner, it is Import (without the “s”) instead of Imports - as it is in the ASP.NET code-behind model and in Windows Forms.

In ASP.NET 1.0/1.1, if you used a particular namespace on each page of your application, you would need the Import statement on each and every page where that namespace was needed. ASP.NET 2.0 introduces the capability to use the web.config file to make a global reference so that you don’t need to make further references on the pages themselves, as shown in the following example:

  <pages>    <namespaces>       <add namespace="System.Drawing" />       <add namespace="Wrox.Books" />    </namespaces> </pages> 

In this example, using the <namespaces> element in the web.config file, references are made to the System.Drawing namespace and the Wrox.Books namespace. Because these references are now contained within the web.config file, there is no need to again reference them on any of the ASP.NET pages contained within this solution.