程序集和命名空间
1组件
CLR对组件代码的打包、部署和查找有自己的一套概念和技术。
这些概念和技术和COM、java和win32存在着本质上的区别。我们必须先弄清楚代码和元数据是如何打包的。
1.1 模块定义
CLR程序存在模块(module)中。一个CLR模块是一个字节流，通常作为一个文件存储在本地的文件系统中或者WEB服务器上。
CLR模块采用Windows NT的PE(Portable Exectuable)/COFF(Common Object File Format)可执行文件格式的扩展版。
当CLR编译器对C#、VB.NET等源程序编译后，产生MSIL（微软中间语言）和元数据。
元数据描述代码中的类型，包含每种类型成员的签名、代码引用的成员和运行库在执行时使用的其它数据。
MSIL和元数据包含在一个PE文件中，此文件基于并扩展过去用于可执行内容的已公布的Micorsoft PE和COFF。
CLR模块包含代码、元数据和资源。
模块代码：一般以公共中间语言的格式存放；
模块元数据：描述了模块中定义的类型，包含名字、继承关系、方法签名和依赖信息等。
模块的资源：静态的只读数据，例如，字符串、位图，以及其他没有被存储为可执行代码的部分。
CLR模块格式：
CLR模块格式输出选项:
选项/t:module产生“未加工的(raw)”模块，其文件扩展名默认为.netmodule。
这种格式的模块不能独立地部署，CLR也不能直接加载它们。
准确地说，开发人员必须在部署前，将这些“未加工的”模块和成型的组件(被称为程序集(Assembly))进行关联。
相比之下，用/t:library选项编译产生的模块，能够包含附加的元数据，允许开发人员将其作为独立代码进行部署。
选项/t:library编译产生的模块，其文件扩展名默认为.DLL。
“未加工的(raw)”模块没有程序集清单。“未加工的(raw)”模块也称作为能添加到其他程序集的模块。
1.2 程序集(Assembly)
为了部署CLR模块，开发人员首先必须将其归属于一个程序集(Assembly)中。程序集就是一个或多个模块的逻辑组合。
尽管程序集可能由多个模块组成，但是一个模块往往只属于一个程序集。假如出现两个程序集都引用同一个公共模块的情况，
CLR将这个公共模块视为两个不同的模块，即公共模块中的每个类型都有两个不同的拷贝。
在CLR中，程序集是部署的“原子”，被用来对CLR模块进行打包、加载、分发以及版本控制（物理的）。虽然程序集可能
包括多个模块以及辅助文件，但程序集本身被作为原子单元进行命名和版本化的。
程序集规定了组件中类型定义的作用域。CLR类型将它们的程序集名/类型名对作唯一标识。
*在VB.NET中，通过关键字DIM声明的方法默认为public,而字段默认为private。
程序集名字：
每个程序集的都采用四部分(four-part)名字，作为唯一标识符。这四部分名字由名称、文化、开发人员以及组件版本构成。
这些名字被存放于程序的清单中，以及引用它的所有程序集的程序集清单中。在加载时，CLR使用四部程序集名字找到正确的组件。
程序集的命名约定通常是基于命名空间前缀的。例如，.NET XML被部署在System.Xml程序集中，它包含的所有类型都使用System.Xml的
命名前缀。这仅仅是个约定，而不是规则。例如，类型System.Object存放在mscorlib的程序集中，而不是System的程序集中。
程序集名字的Name属性往往与程序集清单的底层文件名(不包含任何文件扩展明，尽管它们可能有用)相对应。当构建(Build)程序集时，
名字的这个部分是由编译器根据目标文件名自动选择的。
2 CLR类型
2.1 CLR类型
类型是CLR程序的生成快。开发人员在程序集的上下文中创建类型。当开发人员确定了把工程划分成一个或者多个程序集后，
他们的大部分时间就都花在考虑类型是如何工作的，以及类型直接是如何相互关联的。
CLR类型(CLR type)是命名的可重用抽象体。CLR类型的描述存放在CLR模块的元数据中，
该模块还包含使类型工作所需要的CIL或者本机代码。完全限定的CLR类型名包括三部分：程序集名字、可选的命名空间前缀和类型名称。
2.2 命名空间(namespace)
命名空间是一个逻辑的组织系统，开发人员在程序集开发上下文环境中使用命名空间来组织他们的类型系统。
这能帮助程序员在单个程序中使用两个或者多个同名的类型定义，只要它们分属不同的命名空间。这个命名空间前缀是一个字符串，
一般以开发人员的组织名（例如，Microsoft、MyCorp）开始；如果是.NET Framework的一部分，则以System开始。
3 小结
1)程序集用于组件的打包、部署、分发以及版本控制；命名空间前缀用于类型系统的逻辑划分。
2)程序集的名字由四部分组成，而其Name属性往往与程序集清单的底层文件名(不包含任何文件扩展明，尽管它们可能有用)相对应。
3)程序集的命名约定通常是基于命名空间前缀的，但这不是必须的。
4)如果要用到其它程序集中的类型，可以有两种方式：显式的和隐式的。通常我们都使用隐式的，这种方式不需要开发人员和程序集加载器进行显式的交互。只要在编译我们的程序集时，将需要的外部程序集使用/reference:<file>选项链接进来即可；如果使用显式的方式，开发人员可以使用System.Reflection.Assembly类的LoadFrom静态方法。
5)通常开发人员在自己的程序集上下文环境中时，主要打交道的是类型，以及类型的逻辑组织(namespace prefix)。
6)这里有两种主要的程序集种类，应用程序(.exe)和库(.dll)。
CLR对组件代码的打包、部署和查找有自己的一套概念和技术。
这些概念和技术和COM、java和win32存在着本质上的区别。我们必须先弄清楚代码和元数据是如何打包的。
1.1 模块定义
CLR程序存在模块(module)中。一个CLR模块是一个字节流，通常作为一个文件存储在本地的文件系统中或者WEB服务器上。
CLR模块采用Windows NT的PE(Portable Exectuable)/COFF(Common Object File Format)可执行文件格式的扩展版。
当CLR编译器对C#、VB.NET等源程序编译后，产生MSIL（微软中间语言）和元数据。
元数据描述代码中的类型，包含每种类型成员的签名、代码引用的成员和运行库在执行时使用的其它数据。
MSIL和元数据包含在一个PE文件中，此文件基于并扩展过去用于可执行内容的已公布的Micorsoft PE和COFF。
CLR模块包含代码、元数据和资源。
模块代码：一般以公共中间语言的格式存放；
模块元数据：描述了模块中定义的类型，包含名字、继承关系、方法签名和依赖信息等。
模块的资源：静态的只读数据，例如，字符串、位图，以及其他没有被存储为可执行代码的部分。
CLR模块格式：
| PE/COFF表头 | PE头 |
| COFF头 | |
| PE/COFF .text部分 | IMAGE_COR20_HEADER |
| 代码(CIL和/或本机机器码) | |
| 资源数据 | |
| 字符串/BLOB池 | |
| 元数据表 |
CLR模块格式输出选项:
| C#/VB.NET | C++ | 直接可加载？ | 从Shell中可直接运行？ | 可访问控制台？ |
| /t:exe | /CLR | 是 | 是 | 总是 |
| /t:winexe | /CLR /link /subsystem:windows | 是 | 是 | 从不 |
| /t:library | /CLR /LD | 是 | 否 | 依赖主机(Host-dependent) |
| /t:module | /CLR:NOASSEMBLY /LD | 否 | 否 | 依赖主机(Host-dependent) |
选项/t:module产生“未加工的(raw)”模块，其文件扩展名默认为.netmodule。
这种格式的模块不能独立地部署，CLR也不能直接加载它们。
准确地说，开发人员必须在部署前，将这些“未加工的”模块和成型的组件(被称为程序集(Assembly))进行关联。
相比之下，用/t:library选项编译产生的模块，能够包含附加的元数据，允许开发人员将其作为独立代码进行部署。
选项/t:library编译产生的模块，其文件扩展名默认为.DLL。
“未加工的(raw)”模块没有程序集清单。“未加工的(raw)”模块也称作为能添加到其他程序集的模块。
1.2 程序集(Assembly)
为了部署CLR模块，开发人员首先必须将其归属于一个程序集(Assembly)中。程序集就是一个或多个模块的逻辑组合。
尽管程序集可能由多个模块组成，但是一个模块往往只属于一个程序集。假如出现两个程序集都引用同一个公共模块的情况，
CLR将这个公共模块视为两个不同的模块，即公共模块中的每个类型都有两个不同的拷贝。
在CLR中，程序集是部署的“原子”，被用来对CLR模块进行打包、加载、分发以及版本控制（物理的）。虽然程序集可能
包括多个模块以及辅助文件，但程序集本身被作为原子单元进行命名和版本化的。
程序集规定了组件中类型定义的作用域。CLR类型将它们的程序集名/类型名对作唯一标识。
| C# | VB.NET | 意义 | |
| 类型 | Public | Public | 访问类型不受限制 |
| Internal | Friend | 类型只在程序集内部可访问 | |
| 成员 | Public | Public* | 访问成员不受限制 |
| Internal | Friend | 成员只在程序集内部可访问 | |
| Protected | Protected | 访问仅限于包含类或者包含类派生的子类型 | |
| Protected internal | Protected friend | 访问仅限于包含类以及包含类派生的子类型，或者当前程序集的其它类型。 | |
| Private | Private | 访问仅限于包含类型 |
*在VB.NET中，通过关键字DIM声明的方法默认为public,而字段默认为private。
程序集名字：
每个程序集的都采用四部分(four-part)名字，作为唯一标识符。这四部分名字由名称、文化、开发人员以及组件版本构成。
这些名字被存放于程序的清单中，以及引用它的所有程序集的程序集清单中。在加载时，CLR使用四部程序集名字找到正确的组件。
程序集的命名约定通常是基于命名空间前缀的。例如，.NET XML被部署在System.Xml程序集中，它包含的所有类型都使用System.Xml的
命名前缀。这仅仅是个约定，而不是规则。例如，类型System.Object存放在mscorlib的程序集中，而不是System的程序集中。
程序集名字的Name属性往往与程序集清单的底层文件名(不包含任何文件扩展明，尽管它们可能有用)相对应。当构建(Build)程序集时，
名字的这个部分是由编译器根据目标文件名自动选择的。
2 CLR类型
2.1 CLR类型
类型是CLR程序的生成快。开发人员在程序集的上下文中创建类型。当开发人员确定了把工程划分成一个或者多个程序集后，
他们的大部分时间就都花在考虑类型是如何工作的，以及类型直接是如何相互关联的。
CLR类型(CLR type)是命名的可重用抽象体。CLR类型的描述存放在CLR模块的元数据中，
该模块还包含使类型工作所需要的CIL或者本机代码。完全限定的CLR类型名包括三部分：程序集名字、可选的命名空间前缀和类型名称。
2.2 命名空间(namespace)
命名空间是一个逻辑的组织系统，开发人员在程序集开发上下文环境中使用命名空间来组织他们的类型系统。
这能帮助程序员在单个程序中使用两个或者多个同名的类型定义，只要它们分属不同的命名空间。这个命名空间前缀是一个字符串，
一般以开发人员的组织名（例如，Microsoft、MyCorp）开始；如果是.NET Framework的一部分，则以System开始。
3 小结
1)程序集用于组件的打包、部署、分发以及版本控制；命名空间前缀用于类型系统的逻辑划分。
2)程序集的名字由四部分组成，而其Name属性往往与程序集清单的底层文件名(不包含任何文件扩展明，尽管它们可能有用)相对应。
3)程序集的命名约定通常是基于命名空间前缀的，但这不是必须的。
4)如果要用到其它程序集中的类型，可以有两种方式：显式的和隐式的。通常我们都使用隐式的，这种方式不需要开发人员和程序集加载器进行显式的交互。只要在编译我们的程序集时，将需要的外部程序集使用/reference:<file>选项链接进来即可；如果使用显式的方式，开发人员可以使用System.Reflection.Assembly类的LoadFrom静态方法。
5)通常开发人员在自己的程序集上下文环境中时，主要打交道的是类型，以及类型的逻辑组织(namespace prefix)。
6)这里有两种主要的程序集种类，应用程序(.exe)和库(.dll)。