Shared Source CLI Essentials第一章第二部分

【 tulaoshi.com - ASP.NET 】

共享类型系统和中间语言 CLI中的类型在最低限度上是由字段和方法构成的，但是这些字段和方法自身又是如何定义的呢？CLI标准定义了一个与处理器无关的中间语言，用于描述程序，也定义了一个通用类型系统来为这种中间语言提供基本数据类型。这两个事物一起组成了一个抽象计算模型。标准使用一些规则来修饰这个抽象模型，这些规则描述了抽象模型如何才能转化成机器指令流和内存引用；这些转化过程的设计十分高效，能够识别和准确的描述许多不同编程语言的语义。中间语言，中间语言类型，以及转换的规则，组成了一个具有普遍意义的，用于描述程序的语言无关的方法。 CLI规范中定义的中间语言叫做通用中间语言（CIL）。它包含一个与任何现存的计算机硬件结构均无关的丰富的操作码集合，用于驱动一个易于理解的抽象堆栈机。同样的，通用类型系统（CTS）定义了一个包含标准的跨语言互操作性的类型的基本集合。为了充分实现这种语言无关的世界的好处，高级编译器需要理解CIL指令集和它所匹配的数据类型的集合。如果没有这个协议，那么不同的语言就必须选择不同的映射方式；例如，C#中的int类型的长度有多大？它和Visual Basic中的Integer类型有什么关系？它和C++中的long类型完全相同吗？通过将指令集和这些类型进行匹配，这些选择将变得相当简单，当然，关于具体应该使用哪个指令和类型的选择是由编译器决定的，但是，一个良好的规范的出现意味着使得这些选择变得相当地直接和简单。通过使用这种方法，结果代码可以和其它语言编写的代码和框架进行互操作，从而导致了更加高效的重用。第3章详细描述了CLI类型系统，而第5章描述了CIL，以及它是如何转换成本地指令的。 基于类型的可移植打包单元：装配件 CLI利用它的类型系统和抽象计算模型，实现了这样的理想：人们可以利用由不同人员在不同时间编写的软件组件，通过校验，装载这些组件，来使用它们一起创建应用程序。在CLI中，单独的组件可以打包到称为装配件的单元中，装配件可以在执行引擎中按需动态装载，既可以从本地磁盘中装载，也可以从网络上装载，甚至还可以在程序的控制下动态的创建。 装配件为CLI定义了组件模型的语义。类型不能存在于装配件的外部。反过来说，装配件是将类型装载到CLI中的唯一的机制。装配件又是由一个或多个模块（模块是驻留信息的打包子单元），以及一大块名为装配件清单的描述装配件的元数据组成的。虽然装配件也能由多个模块组成，不过一般一个装配件都只包含一个模块。 为了保证装配件不会在被编译和被装载的时候被篡改，每一个装配件通过一个秘钥对和整个装配件的一个哈希表来进行签名，这个签名可以被放在装配件清单中。这个签名被执行引擎所信任，并且可以保证装配件不会被篡改，以及有危险的装配件不会被装载。如果在运行时从装配件生成的哈希表和装配件清单中包含的哈希表不匹配，运行时会拒绝装载装配件，并且在潜在的危险代码有机会做任何事情之前抛出一个异常。在许多方面，装配件对于CLI的意义，就像共享库或DLL对于操作系统的意义一样：它们都是绑定和识别属于同一个部分的代码的方法。感谢CLI中建立的可靠的对元数据和符号的绑定方法，这使得每一个组件都可以在独立于它的邻居的情况下被装载，翻译以及执行，即使它们之间相互依赖，也不会互相干扰。这是至关紧要的，因为平台，应用程序，库，以及硬件都会随着时间的变化而改变。基于组件建立的解决方案应该在这些组件变化时继续正常工作。我们将在第3章和第4章讨论装配件。 组件隔离：应用程序域和远程调用 以使组件能够一起工作，并保护组件不受其它组件中的恶意代码或bug危害的方式装载各组件的能力，与在组件内部将代码组织在一起的能力一样重要。操作系统常常通过建立保护地址空间，以及提供连接保护地址空间和其它地址空间的通讯机制的方法来获得独立性；地址空间提供保护边界，而通讯机制为协作提供通道。在CLI中有相似的隔离执行代码的概念，它由应用程序域和对远程调用的支持组成。 程序集总是在一个应用程序域的上下文中被装载的，因此类型就被它们的应用程序域限制了范围，例如，程序集中定义的静态变量在应用程序域中分配空间和存储。如果同一个程序集在三个不同的域中被加载，会为这个程序集中类型的数据分配三个不同的拷贝。在本质上，应用程序域是”轻量级的地址空间”，对于在各个应用程序域之间传递数据，CLI执行和操作系统在不同的地址空间之间传递数据所执行的相同的限制。希望跨越域边界进行通讯的类型，必须使用特殊的通讯通道，并按照特定的规则来进行操作。 被称为远程调用的技术，可以用来在不同的物理计算机（计算机上可能运行不同的操作系统，具有不同的处理器）上运行的应用程序域之间进行通讯。就像经常一样，远程调用机制常常用于分隔位于同一个机器中同一个进程的域中的各组件。希望参与到远程调用中的组件要么必须是可序列化的，这样它们就能在域之间传递，要么必须继承自System.MarshalByRefObject类型，这样它们可以使用负担传递工作