Namespaces and Assemblies in C#.NET

Whether you realize it at first, every piece of code in .NET exists inside a .NET type (typically aclass). In turn, every type exists inside a namespace. The figure below shows this arrangement for your own code and the DateTime class. Keep in mind that this is an extreme simplification— the System namespace alone is stocked with several hundred classes. This diagram is designed only to show you the layers of organization.

Namespaces can organize all the different types in the class library. Without namespaces, these types would all be grouped into a single long and messy list. This sort of organization is practical for a small set of information, but it would be impractical for the thousands of types included with .NET.

To continue your exploration after you’ve finished this article, you’ll need to turn to the Visual Studio Help reference, which painstakingly documents the properties, methods, and events of every class in every namespace.

If you have Visual Studio installed, you can view the Visual Studio Help by selecting Start >> Programs >> Microsoft Visual Studio 2008 >> Microsoft Visual Studio 2008 Documentation (the exact path depends on the version of Visual Studio you’ve installed).

You can find class reference information on the Contents tab, grouped by namespace, under the .NET Development >> .NET Framework SDK >> .NET Framework >> .NET Framework Class Library node.

Using Namespaces

Often when you write ASP.NET code, you’ll just use the namespace that Visual Studio creates automatically. If, however, you want to organize your code into multiple namespaces, you can define the namespace using a simple block structure, as shown here:

namespace MyCompany
{
    namespace MyApp
    {
        public class Product
        {
            // Code goes here.
        }
    }
}

In the preceding example, the Product class is in the namespace MyCompany.MyApp. Code inside this namespace can access the Product class by name. Code outside it needs to use the fully qualified name, as in MyCompany.MyApp.Product. This ensures that you can use the components from various third-party developers without worrying about a name collision.

If those developers follow the recommended naming standards, their classes will always be in a namespace that uses the name of their company and software product. The fully qualified name of a class will then almost certainly be unique.

Namespaces don’t take an accessibility keyword and can be nested as many layers deep as you need. Nesting is purely cosmetic—for example, in the previous example, no special relationship exists between the MyCompany namespace and the MyApp namespace. In fact, you could create the namespace MyCompany.MyApp without using nesting at all using this syntax:

namespace MyCompany.MyApp
{
    public class Product
    {
        // Code goes here.
    }
}

You can declare the same namespace in various code files. In fact, more than one project can even use the same namespace. Namespaces are really nothing more than a convenient, logical container that helps you organize your classes.

Importing Namespaces

Having to type long, fully qualified names is certain to tire your fingers and create overly verbose code. To tighten code up, it’s standard practice to import the namespaces you want to use. When you import a namespace, you don’t need to type the fully qualified name. Instead, you can use the types in that namespace as though they were defined locally. To import a namespace, you use the using statement. These statements must appear as the first lines in your code file, outside of any namespaces or block structures:

using MyCompany.MyApp;

Consider the situation without importing a namespace:

MyCompany.MyApp.Product salesProduct = new MyCompany.MyApp.Product();

It’s much more manageable when you import the MyCompany.MyApp namespace. Once you do, you can use this syntax instead:

Product salesProduct = new Product();

Importing namespaces is really just a convenience. It has no effect on the performance of your application. In fact, whether you use namespace imports, the compiled IL code will look the same. That’s because the language compiler will translate your relative class references into fully qualified class names when it generates an EXE or a DLL file.

Streamlined Object Creation

Even if you choose not to import a namespace, you can compress any statement that declares an object variable and instantiates it. The trick is to use the var keyword you learned about in one of the previous articles. For example, you can replace this statement:

MyCompany.MyApp.Product salesProduct = new MyCompany.MyApp.Product();

with this:

var salesProduct = new MyCompany.MyApp.Product();

This works because the compiler can determine the correct data type for the salesProduct variable based on the object you’re creating with the new keyword. Best of all, this statement is just as readable as the non-var approach, because it’s still clear what type of object you’re creating. Of course, this technique won’t work if the compiler can’t determine the type of object you want. For that reason, neither of these statements is allowed:

var salesProductInvalid1;
var salesProductInvalid2 = null;

Furthermore, the var trick is limited to local variables. You can’t use it when declaring the member variables of a class.

Assemblies

You might wonder what gives you the ability to use the class library namespaces in a .NET program. Are they hardwired directly into the language? The truth is that all .NET classes are contained in assemblies. Assemblies are the physical files that contain compiled code. Typically, assembly files have the extension .exe if they are stand-alone applications or .dll if they’re reusable components.

The .dll extension is also used for code that needs to be executed (or hosted) by another type of program. When your web application is compiled, it’s turned into a DLL file, because your code doesn’t represent a stand-alone application. Instead, the ASP.NET engine executes it when a web request is received.

A strict relationship doesn’t exist between assemblies and namespaces. An assembly can contain multiple namespaces. Conversely, more than one assembly file can contain classes in the same namespace. Technically, namespaces are a logical way to group classes. Assemblies, however, are a physical package for distributing code.

The .NET classes are actually contained in a number of assemblies. For example, the basic types in the System namespace come from the mscorlib.dll assembly. Many ASP.NET types are found in the System.Web.dll assembly. In addition, you might want to use other, third-party assemblies. Often, assemblies and namespaces have the same names. For example, you’ll find the namespace System.Web in the assembly file System.Web.dll. However, this is a convenience, not a requirement.

When compiling an application, you need to tell the language compiler what assemblies the application uses. By default, a wide range of .NET assemblies is automatically made available to ASP.NET applications. If you need to use additional assemblies, you need to define them in a configuration file for your website. Visual Studio makes this process seamless, letting you add assembly references to the configuration file using the Website >> Add Reference command.