The last few lessons have been covering a lot of details involving classes because they’re so integral to the .NET Framework. In fact, just about everything you do in .NET involves a class in some way. The .NET Framework Class Library itself is really just a collection of classes with pre-built functionality that you can utilize in your projects. This library was built – by Microsoft – to make your job easier, and so that you don’t have to “re-invent the wheel” when creating software. The aim of this lesson is to help you understand how the .NET Framework Class Library was put together and how you can get the most out of it. This should help you better understand how the pre-built code is organized and how to access code that’s not part of your project by default. Much of this hinges on a deeply related coding topic that you have been seeing on the periphery throughout these lessons and that is the topic of namespaces along with the using directive.
Step 1: Understanding How Namespaces and Using Directives Relate
To understand how namespaces work, let’s briefly look back at the concepts of scope and locality. Consider having two different properties in your code that, logically, should have identical names. This is not possible when those properties are declared in the same scope (the class, in this case). However, it is perfectly possible to share the same name if these properties were in separate classes:
The compiler easily distinguishes between these properties because they each belong to very different scopes. By the same token, a namespace is yet another scope that simply acts as a container for a group of classes. So if you have two classes with the same name, it is forbidden if they are both part of the same scope since the compiler has no way of distinguishing between them:
However, if each of these classes belong in different namespaces, they belong within different scopes entirely:
Step 2: Referencing With and Without Using Directives
It becomes more obvious how the compiler can tell these classes apart when you reference them using their “full names,” that include the namespace they respectively belong to:
The CS_ASP_040 namespace here is color-coded different from the other namespace because it is being used within the current namespace:
We don’t have to reference the namespace “full name” for the first Car object as the compiler intuits that we are referring to the Car class from within the current namespace “CS_ASP_040”. However, the SomeOtherGroupOfClasses.Car object is different because it’s referencing a class from an outside namespace. In this case, you have to either reference the namespace on each line of code that utilizes this class, or as a shorthand you can add this outside namespace to the current one through a using directive:
Step 3: Resolving Class Name Ambiguities
Under normal circumstances this would adequately solve the problem of avoiding typing out the “full name” of the Class, but in this particular example we still have two Car classes without a way for the compiler to distinguish between them. In the example below, we know that car2 is supposed to be of the type found in SomeOtherGroupOfClasses, but the compiler will think it’s referring to the type found in the current CS_ASP_040 namespace even with the using directive:
If this is confusing, think about the concept of first and last names in the real world. If you were told, "Bob likes coffee", you’d probably have a difficult time understanding which Bob was being referred to. However, if you were told that "Robert Tharon Tabor likes coffee", you’d likely be able to distinguish that Bob from the other Bobs you know. In a similar manner, scope gives context to shared names, such as the example with "Make" given above. If you were told to modify the Make property, but it was given no context, you wouldn’t know which property to act on. In the same way, the compiler needs context to distinguish between shared names.
Step 4: Using Namespaces to Import Code Libraries
It’s important to note that while a namespace can just be seen as a way of grouping classes into different areas in your codebase, the biggest benefit of a namespace is to be able to import into your project (and make reference to) a library of code that is outside of it. We saw this
earlier when we wanted to access the StringBuilder class that originates from the System.Text namespace:
If we didn’t include the using directive to this namespace, we would have had to use the full name for this reference, making a less clean looking result:
It should be fairly clear that the System.Text namespace contains within it a collection of classes – one of which is the StringBuilder class. You can see, with Intellisense, all of the constituent classes within
Step 5: Visual Studio Defaults to Importing Common Namespaces
You will typically only want to import libraries that you intend to use. However, projects that are based on a template (such as the ASP.NET projects we have been working with) will anticipate common libraries that are useful – or in some cases necessary – by adding them ahead of time as using directives within each file that references them:
Step 6: Understanding Nested Namespaces
Another aspect of namespaces is that they can be nested within each other. In the example above, the Text namespace is nested within the System namespace. You can create nested classes just as you would expect:
And then you can reference them using the dot accessor in the way that you would expect:
Because classes can share the same name – but belong to a different namespace – be careful to ensure when researching a class that it is from the namespace you intend on using. When in doubt, enter the "full name" of the class including its namespace in the search engine.