The using Directive

The using Directive

It is possible to import types from one namespace into the enclosing namespace scope. As a result, it would not be necessary for the programmer to fully qualify a type. To achieve this, the C# programmer includes a using directive, generally at the top of the file. For example, in Listing 4.6, Console is not prefixed with System. Instead, it includes the using directive, using System, at the top of the listing.

Listing 4.6. using Directive Example

    // The using directive imports all types from the     // specified namespace into the enclosing scopein     // this case, the entire file.     using System;                                   class HelloWorld     {       static void Main()       {            // No need to qualify Console with System            // because of the using directive above.                      Console.WriteLine("Hello, my name is Inigo Montoya");               }     } 

The results of Listing 4.6 appear in Output 4.2.

Output 4.2.

 Hello, my name is Inigo Montoya 

A using directive like using System does not enable the omission of System from a method within a more specific namespace. If code accessed a type within System.Text, for example, you would have to either include an additional using directive for System.Text, or fully qualify the type. The using directive does not import any nested namespaces. Nested namespaces, identified by the period in the namespace, need to be imported explicitly.

Language Contrast: JavaWildcards in import Directive

Java allows for importing namespaces using a wildcard such as:

import javax.swing.*;

In contrast, C# does not support a wildcard using directive, and instead requires each namespace to be imported explicitly.

Language Contrast: Visual Basic .NETProject Scope Imports Directive

Unlike C#, Visual Basic .NET supports the ability to specify the using directive equivalent, Imports, for an entire project, rather than just for a specific file. In other words, Visual Basic .NET provides a command-line means of the using directive that will span an entire compilation.

Typically, prevalent use of types within a particular namespace results in a using directive for that namespace, instead of fully qualifying all types within the namespace. Following this tendency, virtually all files include the using System directive at the top. Throughout the remainder of this book, code listings will often omit the using System directive. Other namespace directives will be included explicitly, however.

One interesting effect of the using System directive is that the string data type can be identified with varying case: String or string. The former version relies on the using System directive and the latter uses the string keyword. Both are valid C# references to the System.String data type, and the resulting CIL code is unaffected by which version is chosen.[1]

[1] I prefer the string keyword, but whichever representation a programmer selects, ideally code within a project should be consistent.

Advanced Topic: Nested using Declaratives

Not only can you have using declaratives at the top of a file, but you also can include them at the top of a namespace declaration. For example, if a new namespace, Awl.Michaelis.EssentialCSharp, were declared, it would be possible to add a using declarative at the top of the namespace declaration (see Listing 4.7).

Listing 4.7. Specifying the using Directive inside a Namespace Declaration

 namespace Awl.Michaelis.EssentialCSharp {   using System;                                                     class HelloWorld   {     static void Main()     {         // No need to qualify Console with System         // because of the using directive above.        Console.WriteLine("Hello, my name is Inigo Montoya");           }   } } 

The results of Listing 4.7 appear in Output 4.3.

Output 4.3.

 Hello, my name is Inigo Montoya 

The difference between placing the using declarative at the top of a file rather than at the top of a namespace declaration is that the declarative is active only within the namespace declaration. If the code includes a new namespace declaration above or below the Awl.Michaelis.EssentialCSharp declaration, then the using System directive within a different namespace would not be active. Code seldom is written this way, especially given the standard practice of a single type declaration per file.


The using directive also has a provision for aliasing a namespace or type. An alias is an alternate name that you can use within the scope to which the using directive applies. The two most common reasons for aliasing are to disambiguate two types that have the same name and to abbreviate a long name. In Listing 4.8, for example, the CountDownTimer alias is declared as a means of referring to the type System.Timers.Timer. Simply adding a using System.Timers directive will not sufficiently enable the code to avoid fully qualifying the Timer type. The reason is that System.Threading also includes a type called Timer, and therefore, just using Timer within the code will be ambiguous.

Listing 4.8. Declaring a Type Alias

     using System;     using System.Threading;                                      using CountDownTimer = System.Timers.Timer;                  class HelloWorld     {        static void Main()        {           CountDownTimer timer;                                         // ...        }     } 

Listing 4.8 uses an entirely new name, CountDownTimer, as the alias. It is possible, however, to specify the alias as Timer, as shown in Listing 4.9.

Listing 4.9. Declaring a Type Alias with the Same Name

 using System; using System.Threading;   // Declare alias Timer to refer to System.Timers.Timer to                              // avoid code ambiguity with System.Threading.Timer                                    using Timer = System.Timers.Timer;                                     class HelloWorld {   static void Main()   {       Timer timer;                                                            // ...   } } 

Because of the alias directive, "Timer" is not an ambiguous reference. Furthermore, to refer to the System.Threading.Timer type, you will have to either qualify the type or define a different alias.

Essential C# 2.0
Essential C# 2.0
ISBN: 0321150775
EAN: 2147483647
Year: 2007
Pages: 185 © 2008-2017.
If you may any questions please contact us: