Object Oriented C# for ASP.NET Developers

Namespaces

For much of this article, we have worked with a class called Tree. Now, while Tree isn't an especially original name for a class, it fits the class perfectly. The problem is that the same name might fit another class just as well, and you'll have a naming conflict on your hands. Such conflicts aren't too serious when you get to write all your own classes; however, when you need to bring in a set of classes that someone else wrote for use in your program, things can get messy.

Consider, for example, what would happen if you'd designed all of the classes to handle the logic for a Web site that will track the sales of buttons for clothing. In such a case it would be natural to have a class called Button, but then your boss tells you he or she wants a nice, graphical user interface for the program. To your dismay, you find that the class built into the .NET Framework for creating buttons on user interfaces is called (you guessed it) Button. How can this conflict be resolved without having to go back through your code and change every reference to your Button class?

Namespaces to the rescue! C# provides namespaces as a way of grouping together classes according to their purpose, the company that wrote them, or whatever other criteria you like. As long as you ensure that your Button class is not in the same namespace as C#'s built-in Button class, you can use both classes in your program without any conflicts arising.

By default, classes you create reside in the default namespace, an unnamed namespace where all classes that are not assigned namespaces go. For most of your programs it is safe to leave your classes in the default namespace. All of the .NET Framework's built-in classes as well as most of the classes you will find available on the Internet and from other software vendors are grouped into namespaces, so you usually don't have to worry about your classes' names clashing with those of other classes in the default namespace.

You will want to group your classes into namespaces if you intend to reuse them in future projects (where new class names may clash with those you want to reuse), or if you want to distribute them for use by other developers (where their class names may clash with your own). To place your class in a namespace, you simply have to surround your class declaration with a namespace declaration. For example, classes that we develop at SitePoint.com are grouped in the Sitepoint namespace by adding the following to our C# files:

namespace SitePoint {            
 // Class declaration(s) go here            
}

If we were to place our Tree class inside the SitePoint namespace in this way, the class' full name would become SitePoint.Tree. You can also declare namespaces within namespaces to further organize your classes (e.g. SitePoint.Web.Tree).

As it turns out, the Button class built into the .NET Framework is actually in the System.Windows.Forms namespace, which also contains all of the other classes for creating basic graphical user interfaces in .NET. Thus, the fully qualified name of .NET's Button class is System.Windows.Forms.Button. To make use of this class without your program thinking that you're referring to your own Button class, you can use this full name instead. For example:

// Create a Windows Button            
System.Windows.Forms.Button b = new System.Windows.Forms.Button();

In fact, C# requires that you use the full name of any class that is not in the same namespace as the current class!

But what if your program doesn't have a Button class to clash with the one built into .NET? Spelling out the full class name every time means a lot of extra typing. To save yourself this annoyance, you can import the System.Windows.Forms namespace into the current namespace by putting a using line at the top of your C# file (just inside the namespace declaration(s), if any):

namespace SitePoint {            
 using System.Windows.Forms;            
 // Class declaration(s) go here            
}

Once its namespace is imported, you can use the class by its short name (Button) as if it were part of the same namespace as your class.

So if you put your Tree class into a namespace called SitePoint, any class not also declared to be in the SitePoint namespace that needed to use it would either have to call it SitePoint.Tree or import the SitePoint namespace.

For code in an ASP.NET page (.aspx file), the following namespaces are automatically imported:

• System
• System.Collections
• System.Collections.Specialized
• System.Configuration
• System.IO
• System.Text
• System.Text.RegularExpressions
• System.Web
• System.Web.Caching
• System.Web.Security
• System.Web.SessionState
• System.Web.UI
• System.Web.UI.HtmlControls
• System.Web.UI.WebControls

But if you wanted to access the newly-namespaced SitePoint.Tree class in your PlantTrees.aspx file, you'd either have to call it by its full name, or use an import directive.

Like a page directive, an import directive is a special tag that goes at the top of your file to provide special information about your ASP.NET page. Here's what the import directive to use the SitePoint namespace would look like:

<%@ Import namespace="SitePoint" %>