命名空间允许我们对相关的类型进行逻辑上的组织,这使得我们很方便的地定位一个类型：
举个简单的例子,我们实例化的一个队列,
如果不引入命名空间,则要这样写:
System.Collections.Queue q=new System.Collections.Queue();
那引入命名空间呢? 则只要这样写:
Using System.Collections;//引入命名空间
Queue q=new Queue();
对于编辑来说,命名空间仅仅是在类型名称前加了一些由点号隔开的符号而已.这使得一个类型的名称更长,从而也更具惟一性.如果两个相同的类在同一个命名空间则会冲突,如果不同的命名空间有相同的类型,也会产生二义性,就像windows中的目录一样,同一目录不能有同名文件,不同目录则可以.如果你非要用,可以用全称(System.Collections.Queue),也可以using sysQueue= System.Collections.Queue;
注意,C#的using指示符会指示编译器试着在类型名上添加不同的前缀,直到找到一个匹配为止,刚才已经讲了,命名空间只是逻辑上,真正的类型在程序集里,当查找一个类型的定义时,编译器必须被告知到哪些程序集中进行查找,编译器将扫描它知道的所有程序集来查找类型的定义.一旦编译器找到了正确的程序,程序集信息和类型信息会被添加到生成托管模块的元数据中,C#编译器默认情况下会自动在MSCorLib.dll程序集中进行查找.而MSCorLib.dll包含了所有FCL中定义的核心类型.例如Object,String等。
命名空间和程序集的关系：
1. 从属于一个命名空间的各个类型可能在不同的程序集中实现。例如:system.IO.FileStream类型是在MSCorlib.dll 程序集中实现的，而System.IO.FileSystemWatcher类型是在System.dll 程序集中实现的。事实上， .Net framework 甚至根本没有发布一个System.IO.dll程序集。(一个程序集内可能有多个命名空间，同一个命名空间可能存在于不同的程序集中.)
2. 在一个程序集中，也可能包含不同命名空间中的类型。例如，System.Int32和System.Text.StringBuilder类型都在MSCorLib.dll程序集中。
3. 在.net framework SDk文档中查找一个类型时，文档会明确的指出类型所属的命名空间，以及实现了该类型的程序集。
（用一个形象的比喻：一个类型，它有两个身份证，一个是命名空间，一个是程序集）