在使用面向对象技术开发的现代软件系统中，经常拥有数百甚至上千个类，为了方便的管理这些类，面向对象技术引入了“命名空间(namespace)”的概念。
3.1 命名空间
命名空间可以看成是类的“容器”，它可以包含多个类，例如，以下代码创建了一个命名空间MyDLL,在其中放置了两个类——MyPublicClass和MyInnerClass:
namespace MyDLL
{
public class MyPublicClass
{
}
class MyInnerClass
{
}
}
如果要使用命名空间中的类，需要指明其命名空间。例如：
MyDLL.MyPublicClass obj=new MyDLL.MyPublicClass();
如果希望少写一点代码，可以在源代码文件开头使用using语句引用MyDLL命名空间：
using MyDLL;
在源代码文件中引用了特定的命名空间之后，就可以直接使用其中的类而不再需要指明其所属的命名空间。
下面对命名空间这一概念做更进一步的讨论。
.NET Framework使用命名空间来管理所有的类。如果把类比喻成书的话，则命名空间类似于放书的书架，书放在书架上，类放在命名空间里。
当我们去图书馆查找一本书时，需要指定这本书的编号，编号往往规定了书放在哪个书库的哪个书架上，通过逐渐缩小的范围：图书馆→书库→书架，最终可以在某个书架中找到这本书。
类似的，可以采用图书馆保存图书类似的方法来管理类，通过逐渐缩小的范围：最大的命名空间→子命名空间→孙命名空间→……，最终找到一个类。
所以，命名空间是可以嵌套的，请看以下示例代码：
namespace MyDLL
{
//...
namespace MyChildDLL
{
public class MyPublicChildClass
{
}
}
}
这时，外界可通过以下格式的声明来使用此类型：
MyDLL.MyChildDLL.MyPublicChildClass obj2=new MyDLL.MyChildDLL.MyPublicChildClass();
同样可以使用using语句缩短语句的长度。
3.2 类库
为了提高软件开发的效率，人们在整个软件开发过程中大量应用了软件工程的模块化原则，将可以在多个项目中使用的代码封装为可重用的软件模块，其余这些可复用的软件模块，再开发新项目就成为“重用已有模块，再开发部分新模块，最后将新旧模块组装起来”的过程。整个软件开发过程类似于现代工业的生产流水线，生产线上的每个环节都由特定的人员负责，整个生产线上的工作人员既分工明确又相互合作，大大的提高了生产效率。
在组件化开发大行其道的今天，人们通常将可以重用的软件模块称为“软件组件”。
在全面向对象的.NET软件平台之上，软件组件的表现形式为程序集(Assembly)，可以通过在Visual Studio中创建并编译一个类库项目得到一个程序集。
在Visual Studio的项目模板中，可以很方便的创建类库(Class Library)项目：
Visual Studio会自动在项目中添加一个名为Class1.cs的类文件，程序员可在此类文件中书写代码，或者添加新的类。一个类库项目中可以容纳的类数目没有限制，但只有声明为public的类可以被外界使用。
类库项目编译之后，会生成一个动态链接库(DLL:Dynamic Link Library)文件。这就是可以被重用的.NET软件组件——程序集。默认情况下，类库文件名就是项目名加上“.dll”后缀。
每个类库项目都拥有一个默认的命名空间，可以通过类库项目的属性窗口来指定。
需要仔细区分“类库项目”、“程序集”和“命名空间”这三个概念的区别：
（1）每个类库项目编译之后，将会生成一个程序集。
（2）类库项目中可以拥有多个类，这些类可属于不同的命名空间。
（3）不同的类库项目可以定义相同的命名空间。
根据上述三个特性，可以得到以下结论：
“命名空间”是一个逻辑上的概念，它的物理载体是“程序集”，具体体现为“DLL”(或EXE)文件。在Visual Studio中，可通过创建“类库”类型的项目生成程序集。
一个程序集可以有多个命名空间，而一个命名空间也可以分布于多个程序集。
一旦生成了一个程序集，在其他项目中就可以通过添加对这一程序集的引用而使用此程序集中的类。一个项目添加完对特定程序集的引用之后，就可以直接创建此程序集中的类了，当然要注意指明其命名空间。