12.C#：解决方案、项目、程序集、命名空间区别

     我的理解：

     一个命名空间可能会根据开发部门或者里面的类型级别来分组，每一个分组被命名为一个程序集dll，这就是逻辑上的分组，比如按照开发部门来，那么某一个部门的程序集就需要引用到其他部门的程序集；

     而对于其中的某一个由某个部门开发的程序集（已经引用了其他部门的程序集），这个程序集就是一个大型项目，里面含有多个命名空间，每一个命名空间表示项目的一个层级，[比如按照开发层次来：命名空间A表示系统调用函数，命名空间B表示关于数据库的子函数，命名空间C表示消息类的函数，D表示帮助类的函数等等]。

     一个程序集源程序可以直接引用本程序集的其他命名空间，也可以直接引用其他程序集的命名空间，不过要在同一个解决方案下面打开所需要引用的其他程序集。

     总而言之，命名空间和程序集没有固定的界限，它们都有自己的作用，两者结合使用可以让功能层次清晰，结构合理，开发部署方便。

     下面是网上找的两篇博客，上面的理解也主要是来自下面的博客。

第一部分：

本文来自：http://blog.csdn.net/u010096526/article/details/46119033 

是不是有人也像我一样，弄不清他们几个的关系呢？

1、项目
      新建项目的同时，会自动建立此项目对应的解决方案名称，默认二者名称一样。
      在.Net下，一个项目可以表现为多种类型：控制台应用程序、类库、web应用程序等

2、解决方案

      解决方案其实是一个容器，其下边可以包含多个项目。 例如机房重构解决方案下边包含的7层（7个项目U/B/D）

3、程序集
      可以理解为dll。每个项目都有一个dll文件，这个dll中包含了这个项目中所用到的所有的方法程序。

      项目之间的引用调用，也是通过封装的dll实现。

4、命名空间
      类似于咱们的文件目录。引用命名空间的概念，其实是为了区分同名对象。我理解的命名空间其实就是姓名的“姓”，同名对象就是姓名的“名”。即使“名”一样，但因为“姓”不一样，也照样可以区分。虽然都为“teacher”，但有王teacher、张teacher。
      一般而言，命名空间尽量复杂，采用uri格式，例如some.some这样的层次嵌套。

命名空间和项目：二者一样吗？

      在项目里可以定义很多种不同的命名空间，但为了方便调用，尽量在同一个项目中，其命名空间是一样的。
      如果在该项目中添加一个文件夹，默认情况下，该文件夹的命名空间是“项目命名空间.文件夹名”。这样写其实不太方便整个项目被引用。

命名空间和程序集：

      在每个项目的properties中都可以设置。命名空间类似项目的存放路径；程序集其实就是该项目   程序的集合（项目名.dll）
4000
。
       啊啊啊，一堆文字的堆砌，就是没个图。自己改改底层框架的代码就知道了。

第二部分：

本文来自：http://www.cnblogs.com/hjtdlx/archive/2011/10/30/2229508.html

1.命名控件与程序集的区别。

      命名空间用于对类型进行逻辑分组。程序集则是程序的物理分组，对应于一个dll或exe文件。

2.为什么要使用两种方式分组？把逻辑分组作为物理分组不是更简单吗？

     逻辑分组主要针对开发人员，而物理分组主要针对安装和部署。

     除此之外，以下情况也需要使用两种方式分组，否则会很不方便。

     1）团队开发。一个公司分处不同的部门共同开发同一个命名控件的不同类型。那么不同的部门可以把他们开发的东西编译成各自的dll文件。使用时把几个dll一起引用即可。

      2）一个命名控件里包含的类型太多，而有大部分是用不上的。如果把一个命名空间编译成一个dll，则会降低运行效率。

      3）有时需要对一个命名空间内的类型区别对待。如果打算开发一个系列软件，该软件分普通版，专业版，高级版。越高的版本具有越高的权限（当中包含了一些高级的类），这是可以使用把高级的功能放到一个单独的dll来控制。

3.类型可以没有命名空间吗？

可以

4.Object类的名字到底是Object还是System.Object?

    可以说都是也可以说都不是。

    1）对于IL来说，确定一个类型是需要程序集+类型全名称的。比方调用Object的ToString()方法，其实是[MSCorLib.dll]System.Object::ToString()。因此CLR不知道命名空间的事情，它只知道调用MSCorLib.dll中的System.Object类。

    2)  对于C#来说，编译后会自动把命名空间加上点号让类型名变成全名称。但是，类名是不能出现点（.）符号的，以下代码在逻辑上是成立的，但是C#语法不允许。


class System.Object


{


}

    相当于


namespace Sysmtem


{


    class Object


    {


    }


}

    但是C#中命名空间是允许出现点符号的。


namespace Sysmtem.IO


{


    class Object


    {


    }


}

   完全等同于


namespace Sysmtem


{


    namespace IO


    {


        class Object


        {


        }


    }


}

第三部分：

本文来自：http://www.cnblogs.com/xionglee/articles/2390627.html

命名空间允许我们对相关的类型进行逻辑上的组织,这使得我们很方便的地定位一个类型：

举个简单的例子,我们实例化的一个队列,

如果不引入命名空间,则要这样写:

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文档中查找一个类型时，文档会明确的指出类型所属的命名空间，以及实现了该类型的程序集。

（用一个形象的比喻：一个类型，它有两个身份证，一个是命名空间，一个是程序集）