1、C#高级编程（第 6 版）2008 最新版第 1 章 .NET 体系结构我们不能孤立地使用 C#语言，而必须和 .NET Framework 一起考虑。C# 编译器专门用于.NET，这表示用 C#编写的所有代码总是在 .NET Framework 中运行。对于 C#语言来说，可以得出两个重要的结论：(1) C#的结构和方法论反映了.NET 基础方法论。(2) 在许多情况下，C# 的特定语言功能取决于.NET 的功能，或依赖于.NET 基类。由于这种依赖性，在开始使用 C#编程前，了解.NET 的结构和方法论就非常重要了，这就是本章的目的。下面是本章的内容： 本章首先了解在.NET 编译和运行所
2、有的代码(包括 C#)时通常会出现什么情况。 对这些内容进行概述之后，就要详细阐述 Microsoft 中间语言(Microsoft Intermediate Language，MSIL 或简称为 IL)，.NET 上所有编译好的代码都要使用这种语言。本章特别要介绍 IL、通用类型系统(Common Type System，CTS)及公共语言规范(Common Language Specification， CLS)如何提供 .NET 语言之间的互操作性。最后解释各种语言如何使用.NET，包括Visual Basic 和 C+。 之后，我们将介绍.NET 的其他特性，包括程序集、命名空间和.N
3、ET 基类。 最后本章简要探讨一下 C#开发人员可以创建的应用程序类型。1.1 C#与.NET 的关系C#是一种相当新的编程语言，C# 的重要性体现在以下两个方面： 它是专门为与 Microsoft 的 .NET Framework 一起使用而设计的。(.NET Framework 是一个功能非常丰富的平台，可开发、部署和执行分布式应用程序) 。 它是一种基于现代面向对象设计方法的语言，在设计它时，Microsoft 还吸取了其他类似语言的经验，这些语言是近 20 年来面向对象规则得到广泛应用后才开发出来的。有一个很重要的问题要弄明白：C#就其本身而言只是一种语言，尽管它是用于生成面向.NET
4、 环境的代码，但它本身不是.NET 的一部分。.NET 支持的一些特性，C#并不支持。而 C#语言支持的另一些特性，.NET 却不支持( 例如运算符重载) ！但是，因为 C#语言是和.NET 一起使用的，所以如果要使用 C#高效地开发应用程序，理解Framework 就非常重要，所以本章将介绍 .NET 的内涵。1.2 公共语言运行库.NET Framework 的核心是其运行库的执行环境，称为公共语言运行库(CLR)或.NET 运行库。通常将在 CLR 的控制下运行的代码称为托管代码(managed code)。但是，在 CLR 执行编写好的源代码之前，需要编译它们(在 C#中或其他语言中)
5、。在.NET 中，编译分为两个阶段：(1) 把源代码编译为 Microsoft 中间语言(IL)。(2) CLR 把 IL 编译为平台专用的代码。这个两阶段的编译过程非常重要，因为 Microsoft 中间语言(托管代码) 是提供.NET 的许多优点的关键。Microsoft 中间语言与 Java 字节代码共享一种理念：它们都是低级语言，语法很简单 (使用数字代码，而不是文本代码)，可以非常快速地转换为内部机器码。对于代码来说，这种精心设计的通用语法有很重要的优点：平台无关性、提高性能和语言的互操作性。1.2.1 平台无关性首先，这意味着包含字节代码指令的同一文件可以放在任一平台中，运行时编译
6、过程的最后阶段可以很容易完成，这样代码就可以运行在特定的平台上。换言之，编译为中间语言就可以获得.NET 平台无关性，这与编译为 Java 字节代码就会得到 Java 平台无关性是一样的。注意.NET 的平台无关性目前只是一种可能，因为在编写本书时，.NET 只能用于 Windows 平台，但人们正在积极准备，使它可以用于其他平台(参见 Mono 项目，它用于实现.NET 的开放源代码，参见 http:/www.go- 提高性能前面把 IL 和 Java 做了比较，实际上，IL 比 Java 字节代码的作用还要大。IL 总是即时编译的( 称为 JIT 编译 )，而 Java 字节代码常常是解释
7、性的，Java 的一个缺点是，在运行应用程序时，把 Java字节代码转换为内部可执行代码的过程会导致性能的损失( 但在最近，Java 在某些平台上能进行 JIT编译) 。JIT 编译器并不是把整个应用程序一次编译完( 这样会有很长的启动时间 )，而是只编译它调用的那部分代码(这是其名称由来 )。代码编译过一次后，得到的内部可执行代码就存储起来，直到退出该应用程序为止，这样在下次运行这部分代码时，就不需要重新编译了。Microsoft 认为这个过程要比一开始就编译整个应用程序代码的效率高得多，因为任何应用程序的大部分代码实际上并不是在每次运行过程中都执行。使用 JIT 编译器，从来都不会编译这种
8、代码。这解释了为什么托管 IL 代码的执行几乎和内部机器代码的执行速度一样快，但是并没有说明为什么 Microsoft 认为这会提高性能。其原因是编译过程的最后一部分是在运行时进行的，JIT 编译器确切地知道程序运行在什么类型的处理器上，可以利用该处理器提供的任何特性或特定的机器代码指令来优化最后的可执行代码。传统的编译器会优化代码，但它们的优化过程是独立于代码所运行的特定处理器的。这是因为传统的编译器是在发布软件之前编译为内部机器可执行的代码。即编译器不知道代码所运行的处理器类型，例如该处理器是 x86 兼容处理器还是 Alpha 处理器，这超出了基本操作的范围。例如Visual Studi
9、o 6 为一般的奔腾机器进行了优化，所以它生成的代码就不能利用奔腾 III 处理器的硬件特性。相反，JIT 编译器不仅可以进行 Visual Studio 6 所能完成的优化工作，还可以优化代码所运行的特定处理器。1.2.3 语言的互操作性使用 IL 不仅支持平台无关性，还支持语言的互操作性。简而言之，就是能将任何一种语言编译为中间代码，编译好的代码可以与从其他语言编译过来的代码进行交互操作。那么除了 C#之外，还有什么语言可以通过 .NET 进行交互操作呢？下面就简要讨论其他常见语言如何与.NET 交互操作。1. Visual Basic 2008Visual Basic 6 在升级到 Vi
10、sual Basic .NET 2002 时，经历了一番脱胎换骨的变化，才集成到.NET Framework 的第一版中。Visual Basic 语言对 Visual Basic 6 进行了很大的演化，也就是说，Visual Basic 6 并不适合运行.NET 程序。例如，它与 COM 的高度集成，且只把事件处理程序作为源代码显示给开发人员，大多数后台代码不能用作源代码。另外，它不支持继承，Visual Basic 使用的标准数据类型也与.NET 不兼容。Visual Basic 6 在 2002 年升级为 Visual Basic .NET，对 Visual Basic 进行的改变非常大
11、，完全可以把 Visual Basic 当作是一种新语言。现有的 Visual Basic 6 代码不能编译为 Visual Basic 2008 代码(或 Visual Basic .NET 2002、2003 和 2005 代码) ，把 Visual Basic 6 程序转换为 Visual Basic 2008 时，需要对代码进行大量的改动，但大多数修改工作都可以由 Visual Studio 2008(Visual Studio 的升级版本，用于与.NET 一起使用) 自动完成。如果把 Visual Basic 6 项目读到 Visual Studio 2008 中，Visual St
12、udio 2008 就会升级该项目，也就是说把 Visual Basic 6 源代码重写为 Visual Basic 2008 源代码。虽然这意味着其中的工作已大大减轻，但用户仍需要检查新的 Visual Basic 2008 代码，以确保项目仍可正确工作，因为这种转换并不十分完美。这种语言升级的一个副作用是不能再把 Visual Basic 2008 编译为内部可执行代码了。Visual Basic 2008 只编译为中间语言，就像 C#一样。如果需要继续使用 Visual Basic 6 编写程序，就可以这么做，但生成的可执行代码会完全忽略.NET Framework，如果继续把 Visu
13、al Studio 作为开发环境，就需要安装 Visual Studio 6。2. Visual C+ 2008Visual C+ 6 有许多 Microsoft 对 Windows 的特定扩展。通过 Visual C+ .NET，又加入了更多的扩展内容，来支持.NET Framework。现有的 C+源代码会继续编译为内部可执行代码，不会有修改，但它会独立于.NET 运行库运行。如果让 C+代码在 .NET Framework 中运行，就可以在代码的开头添加下述命令：#using 还可以把标记/clr 传递给编译器，这样编译器假定要编译托管代码，因此会生成中间语言，而不是内部机器码。C+的一
14、个有趣的问题是在编译托管代码时，编译器可以生成包含内嵌本机可执行代码的 IL。这表示在 C+代码中可以把托管类型和非托管类型合并起来，因此托管 C+代码：class MyClass定义了一个普通的 C+类，而代码：_ref class MyClass生成了一个托管类，就好像使用 C#或 Visual Basic 2008 编写类一样。实际上，托管 C+比 C#更优越的一点是可以在托管 C+代码中调用非托管 C+类，而不必采用 COM 交互功能。如果在托管类型上试图使用.NET 不支持的特性(例如，模板或类的多继承 )，编译器就会出现一个错误。另外，在使用托管类时，还需要使用非标准的 C+特性。
15、因为 C+允许低级指针操作，C+编译器不能生成可以通过 CLR 内存类型安全测试的代码。如果 CLR 把代码标识为内存类型安全是非常重要的，就需要用其他一些语言编写源代码，例如 C# 或Visual Basic 2008。3. COM 和 COM+从技术上讲，COM 和 COM+并不是面向.NET 的技术，因为基于它们的组件不能编译为 IL(但如果原来的 COM 组件是用 C+编写的，使用托管 C+，在某种程度上可以这么做)。但是，COM+仍然是一个重要的工具，因为其特性没有在.NET 中完全实现。另外，COM 组件仍可以使用-.NET集成了 COM 的互操作性，从而使托管代码可以调用 COM
16、 组件，COM 组件也可以调用托管代码(见第 24 章) 。在一般情况下，把新组件编写为 .NET 组件，大多是为了方便，因为这样可以利用 .NET 基类和托管代码的其他优点。1.3 中间语言如前所述，Microsoft 中间语言显然在.NET Framework 中有非常重要的作用。C#开发人员应明白，C#代码在执行前要编译为中间语言(实际上，C#编译器仅编译为托管代码)，这是有意义的，现在应详细讨论一下 IL 的主要特征，因为面向.NET 的所有语言在逻辑上都需要支持 IL 的主要特征。下面就是中间语言的主要特征： 面向对象和使用接口 值类型和引用类型之间的巨大差别 强数据类型 使用异常来
17、处理错误 使用特性(attribute)下面详细讨论这些特征。1.3.1 面向对象和接口的支持.NET 的语言无关性还有一些实际的限制。中间语言在设计时就打算实现某些特殊的编程方法，这表示面向它的语言必须与编程方法兼容，Microsoft 为 IL 选择的特定道路是传统的面向对象的编程，带有类的单一继承性。注意：不熟悉面向对象概念的读者应参考附录 B，获得更多的信息。除了传统的面向对象编程外，中间语言还引入了接口的概念，它们显示了在带有 COM 的Windows 下的第一个实现方式。 .NET 接口与 COM 接口不同，它们不需要支持任何 COM 基础结构，例如，它们不是派生自 IUnknow
18、n，也没有对应的 GUID。但它们与 COM 接口共享下述理念：提供一个契约，实现给定接口的类必须提供该接口指定的方法和属性的实现方式。前面介绍了使用.NET 意味着要编译为中间语言，即需要使用传统的面向对象的方法来编程。但这并不能提供语言的互操作性。毕竟，C+和 Java 都使用相同的面向对象的范型，但它们仍不是可交互操作的语言。下面需要详细探讨一下语言互操作性的概念。首先，需要确定一下语言互操作性的含义。毕竟，COM 允许以不同语言编写的组件一起工作，即可以调用彼此的方法。这就足够了吗？COM 是一个二进制标准，允许组件实例化其他组件，调用它们的方法或属性，而无须考虑编写相关组件的语言。但
19、为了实现这个功能，每个对象都必须通过COM 运行库来实例化，通过接口来访问。根据相关组件的线程模型，不同线程上内存空间和运行组件之间要编组数据，这还可能造成很大的性能损失。在极端情况下，组件保存为可执行文件，而不是 DLL 文件，还必须创建单独的进程来运行它们。重要的是组件要能与其他组件通信，但仅通过COM 运行库进行通信。无论 COM 是用于允许使用不同语言的组件直接彼此通信，或者创建彼此的实例，系统都把 COM 作为中间件来处理。不仅如此，COM 结构还不允许利用继承实现，即它丧失了面向对象编程的许多优势。一个相关的问题是，在调试时，仍必须单独调试用不同语言编写的组件。这样就不可能在调试器
20、上调试不同语言的代码了。语言互操作性的真正含义是用一种语言编写的类应能直接与用另一种语言编写的类通信。特别是： 用一种语言编写的类应能继承用另一种语言编写的类。 一个类应能包含另一个类的实例，而不管它们是使用什么语言编写的。 一个对象应能直接调用用其他语言编写的另一个对象的方法。 对象(或对象的引用 )应能在方法之间传递。 在不同的语言之间调用方法时，应能在调试器中调试这些方法调用，即调试不同语言编写的源代码。这是一个雄心勃勃的目标，但令人惊讶的是，.NET 和中间语言已经实现了这个目标。在调试器上调试方法时，Visual Studio IDE 提供了这样的工具( 不是 CLR 提供的)。1.
21、3.2 相异值类型和引用类型与其他编程语言一样，中间语言提供了许多预定义的基本数据类型。它的一个特性是值类型和引用类型有明显的区别。对于值类型，变量直接保存其数据，而对于引用类型，变量仅保存地址，对应的数据可以在该地址中找到。在 C+中，引用类型类似于通过指针来访问变量，而在 Visual Basic 中，与引用类型最相似的是对象，Visual Basic 6 总是通过引用来访问对象。中间语言也有数据存储的规范：引用类型的实例总是存储在一个名为“托管堆“ 的内存区域中，值类型一般存储在堆栈中(但如果值类型在引用类型中声明为字段，它们就内联存储在堆中)。第 2 章“C# 基础“讨论堆栈和堆，及其
22、工作原理。1.3.3 强数据类型中间语言的一个重要方面是它基于强数据类型。所有的变量都清晰地标记为属于某个特定数据类型( 在中间语言中没有 Visual Basic 和脚本语言中的 Variant 数据类型)。特别是中间语言一般不允许对模糊的数据类型执行任何操作。例如，Visual Basic 6 开发人员习惯于传递变量，而无需考虑它们的类型，因为 Visual Basic 6 会自动进行所需的类型转换。C+开发人员习惯于在不同类型之间转换指针类型。执行这类操作将大大提高性能，但破坏了类型的安全性。因此，这类操作只能在某些编译为托管代码的语言中的特殊情况下进行。确实，指针(相对于引用 )只能在
23、标记了的 C#代码块中使用，但在 Visual Basic 中不能使用(但一般在托管 C+中允许使用) 。在代码中使用指针会立即导致 CLR 提供的内存类型安全性检查失败。注意，一些与.NET 兼容的语言，例如 Visual Basic 2008，在类型化方面的要求仍比较松，但这是可以的，因为编译器在后台确保在生成的 IL 上强制类型安全。尽管强迫实现类型的安全性最初会降低性能，但在许多情况下，我们从.NET 提供的、依赖于类型安全的服务中获得的好处更多。这些服务包括： 语言的互操作性 垃圾收集 安全性 应用程序域下面讨论强数据类型化对这些.NET 特性非常重要的原因。1. 语言互操作性中强数
24、据类型的重要性如果类派生自其他类，或包含其他类的实例，它就需要知道其他类使用的所有数据类型，这就是强数据类型非常重要的原因。实际上，过去没有任何系统指定这些信息，从而成为语言继承和交互操作的真正障碍。这类信息不只是在一个标准的可执行文件或 DLL 中出现。假定将 Visual Basic 2008 类中的一个方法定义为返回一个 Integer-Visual Basic 2008 可以使用的标准数据类型之一。但 C#没有该名称的数据类型。显然，我们只能从该类中派生，再使用这个方法，如果编译器知道如何把 Visual Basic 2008 的 Integer 类型映射为 C#定义的某种已知类型，就
25、可以在C#代码中使用返回的类型。这个问题在.NET 中是如何解决的？(1) 通用类型系统(CTS)这个数据类型问题在.NET 中使用通用类型系统(CTS)得到了解决。CTS 定义了可以在中间语言中使用的预定义数据类型，所有面向.NET Framework 的语言都可以生成最终基于这些类型的编译代码。例如，Visual Basic 2008 的 Integer 实际上是一个 32 位有符号的整数，它实际映射为中间语言类型 Int32。因此在中间语言代码中就指定这种数据类型。C# 编译器可以使用这种类型，所以就不会有问题了。在源代码中，C#用关键字 int 来表示 Int32，所以编译器就认为 V
26、isual Basic 2008 方法返回一个 int 类型的值。通用类型系统不仅指定了基本数据类型，还定义了一个内容丰富的类型层次结构，其中包含设计合理的位置，在这些位置上，代码允许定义它自己的类型。通用类型系统的层次结构反映了中间语言的单一继承的面向对象方法，如图 1-1 所示。图 1-1这个树形结构中的类型说明如表 1-1 所示。表 1-1类 型 含 义Type 代表任何类型的基类Value Type 代表任何值类型的基类Reference Types 通过引用来访问，且存储在堆中的任何数据类型Built-in Value Types 包含大多数标准基本类型，可以表示数字、Boolean
27、 值或字符Enumerations 枚举值的集合User-defined Value Types在源代码中定义，且保存为值类型的数据类型。在 C#中，它表示结构Interface Types 接口Pointer Types 指针 Self-describing Types 为垃圾回收器提供信息的数据类型(参见下一节)Arrays 包含对象数组的类型Class Types 可自我描述的类型，但不是数组Delegates 用于把引用包含在方法中的类型User-definedReference Types在源代码中定义，且保存为引用类型的数据类型。在C#中，它表示类Boxed Value Types
28、 值类型，临时打包放在一个引用中，以便于存储在堆中这里没有列出内置的所有值类型，因为第 3 章将详细介绍它们。在 C#中，编译器识别的每个预定义类型都映射为一个 IL 内置类型。这与 Visual Basic 2008 是一样的。(2) 公共语言规范(CLS)公共语言规范(Common Language Specification，CLS) 和通用类型系统一起确保语言的互操作性。CLS 是一个最低标准集，所有面向.NET 的编译器都必须支持它。因为 IL 是一种内涵非常丰富的语言，大多数编译器的编写人员有可能把给定编译器的功能限制为只支持 IL 和 CLS 提供的一部分特性。只要编译器支持已在
29、 CLS 中定义的内容，这就是很不错的。提示：编写非 CLS 兼容代码是完全可以接受的，只是在编写了这种代码后，就不能保证编译好的 IL代码完全支持语言的互操作性。下面的一个例子是有关区分大小写字母的。IL 是区分大小写的语言。使用这些语言的开发人员常常利用区分大小写所提供的灵活性来选择变量名。但 Visual Basic 2008 是不区分大小写的语言。CLS 就要指定 CLS 兼容代码不使用任何只根据大小写来区分的名称。因此，Visual Basic 2008 代码可以与 CLS 兼容代码一起使用。这个例子说明了 CLS 的两种工作方式。首先是各个编译器的功能不必强大到支持 .NET 的所
30、有功能，这将鼓励人们为其他面向.NET 的编程语言开发编译器。第二，它提供如下保证：如果限制类只能使用 CLS 兼容的特性，就要保证用其他兼容语言编写的代码可以使用这个类。这种方法的优点是使用 CLS 兼容特性的限制只适用于公共和受保护的类成员和公共类。在类的私有实现方式中，可以编写非 CLS 代码，因为其他程序集 (托管代码的单元，参见本章后面的内容)中的代码不能访问这部分代码。这里不深入讨论 CLS 规范。在一般情况下，CLS 对 C#代码的影响不会太大，因为 C#中的非CLS 兼容特性非常少。2. 垃圾收集垃圾收集器用来在.NET 中进行内存管理，特别是它可以恢复正在运行中的应用程序需要
31、的内存。到目前为止，Windows 平台已经使用了两种技术来释放进程向系统动态请求的内存： 完全以手工方式使应用程序代码完成这些工作。 让对象维护引用计数。让应用程序代码负责释放内存是低级高性能的语言使用的技术，例如 C+。这种技术很有效，且可以让资源在不需要时就释放(一般情况下) ，但其最大的缺点是频繁出现错误。请求内存的代码还必须显式通知系统它什么时候不再需要该内存。但这是很容易被遗漏的，从而导致内存泄漏。尽管现代的开发环境提供了帮助检测内存泄漏的工具，但它们很难跟踪错误，因为直到内存已大量泄漏从而使 Windows 拒绝为进程提供资源时，它们才会发挥作用。到那个时候，由于对内存的需求很大
32、，会使整个计算机变得相当慢。维护引用计数是 COM 对象采用的一种技术，其方法是每个 COM 组件都保留一个计数，记录客户机目前对它的引用数。当这个计数下降到 0 时，组件就会删除自己，并释放相应的内存和资源。它带来的问题是仍需要客户机通知组件它们已经完成了内存的使用。只要有一个客户机没有这么做，对象就仍驻留在内存中。在某些方面，这是比 C+内存泄漏更为严重的问题，因为 COM 对象可能存在于它自己的进程中，从来不会被系统删除(在 C+内存泄漏问题上，系统至少可以在进程中断时释放所有的内存)。.NET 运行库采用的方法是垃圾收集器，这是一个程序，其目的是清理内存，方法是所有动态请求的内存都分配
33、到堆上(所有的语言都是这样处理的，但在.NET 中，CLR 维护它自己的托管堆，以供.NET 应用程序使用) ，当.NET 检测到给定进程的托管堆已满，需要清理时，就调用垃圾收集器。垃圾收集器处理目前代码中的所有变量，检查对存储在托管堆上的对象的引用，确定哪些对象可以从代码中访问- 即哪些对象有引用。没有引用的对象就不能再从代码中访问，因而被删除。Java 就使用与此类似的垃圾收集系统。之所以在.NET 中使用垃圾收集器，是因为中间语言已用来处理进程。其规则要求，第一，不能引用已有的对象，除非复制已有的引用。第二，中间语言是类型安全的语言。在这里，其含义是如果存在对对象的任何引用，该引用中就有
34、足够的信息来确定对象的类型。垃圾收集器机制不能和诸如非托管 C+这样的语言一起使用，因为 C+允许指针自由地转换数据类型。垃圾收集器的一个重要方面是它的不确定性。换言之，不能保证什么时候会调用垃圾收集器：.NET 运行库决定需要它时，就可以调用它(除非明确调用垃圾收集器 )。但可以重写这个过程，在代码中调用垃圾收集器。3. 安全性.NET 很好地补足了 Windows 提供的安全机制，因为它提供的安全机制是基于代码的安全性，而 Windows 仅提供了基于角色的安全性。基于角色的安全性建立在运行进程的账户的身份基础上，换而言之，就是谁拥有和运行进程。另一方面，基于代码的安全性建立在代码实际执行
35、的任务和代码的可信程度上。由于中间语言提供了强大的类型安全性，所以 CLR 可以在运行代码前检查它，以确定是否有需要的安全权限。 .NET还提供了一种机制，可以在运行代码前指定代码需要什么安全权限。基于代码的安全性非常重要，原因是它降低了运行来历不明的代码的风险(例如代码是从 Internet上下载来的)。即使代码运行在管理员账户下，也有可能使用基于代码的安全性，来确定这段代码是否仍不能执行管理员账户一般允许执行的某些类型的操作，例如读写环境变量、读写注册表或访问.NET 反射特性。安全问题详见本书后面的第 20 章。4. 应用程序域应用程序域是.NET 中的一个重要技术改进，它用于减少运行应
36、用程序的系统开销，这些应用程序需要与其他程序分离开来，但仍需要彼此通信。典型的例子是 Web 服务器应用程序，它需要同时响应许多浏览器请求。因此，要有许多组件实例同时响应这些同时运行的请求。在.NET 开发出来以前，可以让这些实例共享同一个进程，但此时一个运行的实例就有可能导致整个网站的崩溃；也可以把这些实例孤立在不同的进程中，但这样做会增加相关性能的系统开销。到现在为止，孤立代码的唯一方式是通过进程来实现的。在运行一个新的应用程序时，它会在一个进程环境内运行。Windows 通过地址空间把进程分隔开来。这样，每个进程有 4GB 的虚拟内存来存储其数据和可执行代码(4GB 对应于 32 位系统
37、，64 位系统要用更多的内存) 。Windows 利用额外的间接方式把这些虚拟内存映射到物理内存或磁盘空间的一个特殊区域中，每个进程都会有不同的映射，虚拟地址空间块映射的物理内存之间不能有重叠，这种情况如图 1-2 所示。图 1-2 在一般情况下，任何进程都只能通过指定虚拟内存中的一个地址来访问内存-即进程不能直接访问物理内存，因此一个进程不可能访问分配给另一个进程的内存。这样就可以确保任何执行出错的代码不会损害其地址空间以外的数据(注意在 Windows 95/98 上，这些保护措施不像在 Windows NT/2000/XP/2003/Vista 上那样强大，所以理论上存在应用程序因写入不
38、对应的内存而导致 Windows崩溃的可能性)。进程不仅是运行代码的实例相互隔离的一种方式，在 Windows NT/2000/XP/2003/Vista 系统上，它们还可以构成分配了安全权限和许可的单元。每个进程都有自己的安全标识，明确地表示Windows 允许该进程可以执行的操作。进程对确保安全有很大的帮助，而它们的一大缺点是性能。许多进程常常在一起工作，因此需要相互通信。一个常见的例子是进程调用一个 COM 组件，而该 COM 组件是可执行的，因此需要在它自己的进程上运行。在 COM 中使用代理时也会发生类似的情况。因为进程不能共享任何内存，所以必须使用一个复杂的编组过程在进程之间复制数
39、据。这对性能有非常大的影响。如果需要使组件一起工作，但不希望性能有损失，唯一的方法是使用基于 DLL 的组件，让所有的组件在同一个地址空间中运行- 其风险是执行出错的组件会影响其他组件。应用程序域是分离组件的一种方式，它不会导致因在进程之间传送数据而产生的性能问题。其方法是把任何一个进程分解到多个应用程序域中，每个应用程序域大致对应一个应用程序，执行的每个线程都运行在一个具体的应用程序域中，如图 1-3 所示。如果不同的可执行文件都运行在同一个进程空间中，显然它们就能轻松地共享数据，因为理论上它们可以直接访问彼此的数据。虽然在理论上这是可以实现的，但是 CLR 会检查每个正在运行的应用程序的代
40、码，以确保这些代码不偏离它自己的数据区域，保证不发生直接访问其他进程的数据的情况。这初看起来是不可能的，如何告诉程序要做什么工作，而又不真正运行它？图 1-3实际上，这么做通常是可能的，因为中间语言拥有强大的类型安全功能。在大多数情况下，除非代码明确使用不安全的特性，例如指针，否则它使用的数据类型可以确保内存不会被错误地访问。例如，.NET 数组类型执行边界检查，以禁止执行超出边界的数组操作。如果运行的应用程序的确需要与运行在不同应用程序域中的其他应用程序通信或共享数据，就必须调用.NET 的远程服务。被验证不能访问超出其应用程序域的数据(而不是通过明确的远程机制) 的代码就是内存类型安全的代
41、码，这种代码与运行在同一个进程中但应用程序域不同的类型安全代码一起运行是安全的。1.3.4 通过异常处理错误.NET Framework 可以根据异常使用相同的机制处理错误情况，这与 Java 和 C+是一样的。C+开发人员应注意到，由于 IL 有非常强大的类型系统，所以在 IL 中以 C+的方式使用异常不会带来相关的性能问题。另外，.NET 和 C#也支持 finally 块，这是许多 C+开发人员长久以来的愿望。第 14 章会详细讨论异常。简要地说，代码的某些领域被看作是异常处理程序例程，每个例程都能处理某种特殊的错误情况( 例如，找不到文件，或拒绝执行某些操作的许可) 。这些条件可以定义
42、得很宽或很窄。异常结构确保在发生错误情况时，执行进程立即跳到最合适的异常处理程序例程上，处理错误情况。异常处理的结构还提供了一种方便的方式，当对象包含错误情况的准确信息时，该对象就可以传送给错误处理例程。这个对象包括给用户提供的相应信息和在代码的什么地方检测到错误的确切信息。大多数异常处理结构，包括异常发生时的程序流控制，都是由高级语言处理的，例如C#、Visual Basic 2008 和 C+，任何中间语言中的命令都不支持它。例如，C#使用 try、catch和 finally代码块来处理它，详见第 14 章。.NET 提供了一种基础结构，让面向.NET 的编译器支持异常处理。特别是它提供
43、了一组.NET 类来表示异常，语言的互操作性则允许异常处理代码处理被抛出的异常对象，无论异常处理代码使用什么语言编写，都是这样。语言的无关性没有体现在 C+和 Java 的异常处理中，但在 COM 的错误处理机制中有一定限度的体现。COM 的错误处理机制包括从方法中返回错误代码以及传递错误对象。在不同的语言中，异常的处理是一致的，这是多语言开发的重要一环。1.3.5 特性的使用特性(attribute)是使用 C+编写 COM 组件的开发人员很熟悉的一个功能(在 Microsoft 的 COM 接口定义语言(Interface Definition Language，IDL)中使用特性)。特性
44、最初是为了在程序中提供与某些项相关的额外信息，以供编译器使用。.NET 支持特性，因此现在 C+、C# 和 Visual Basic 2008 也支持特性。但在.NET 中，对特性的革新是建立了一个机制，通过该机制可以在源代码中定义自己的特性。这些用户定义的特性将和对应数据类型或方法的元数据放在一起，这对于文档说明书十分有用，它们和反射技术一起使用，以根据特性执行编程任务。另外，与.NET 的语言无关性的基本原理一样，特性也可以在一种语言的源代码中定义，而被用另一种语言编写的代码读取。本书的第 13 章详细介绍了特性。1.4 程序集程序集(assembly)是包含编译好的、面向.NET Fra
45、mework 的代码的逻辑单元。本章不详细论述程序集，而在第 17 章中论述，下面概述其中的要点。程序集是完全自我描述性的，也是一个逻辑单元而不是物理单元，它可以存储在多个文件中(动态程序集的确存储在内存中，而不是存储在文件中)。如果一个程序集存储在多个文件中，其中就会有一个包含入口点的主文件，该文件描述了程序集中的其他文件。注意可执行代码和库代码使用相同的程序集结构。唯一的区别是可执行的程序集包含一个主程序入口点，而库程序集不包含。程序集的一个重要特性是它们包含的元数据描述了对应代码中定义的类型和方法。程序集也包含描述程序集本身的元数据，这种程序集元数据包含在一个称为“程序集清单“ 的区域中
46、，可以检查程序集的版本及其完整性。注意：ildasm 是一个基于 Windows 的实用程序，可以用于检查程序集的内容，包括程序集清单和元数据。第 17 章将介绍 ildasm。程序集包含程序的元数据，表示调用给定程序集中的代码的应用程序或其他程序集不需要指定注册表或其他数据源，以确定如何使用该程序集。这与以前的 COM 有很大的区别，以前，组件的GUID 和接口必须从注册表中获取，在某些情况下，方法和属性的详细信息也需要从类型库中读取。把数据分散在 3 个以上的不同位置上，可能会出现信息不同步的情况，从而妨碍其他软件成功地使用该组件。有了程序集后，就不会发生这种情况，因为所有的元数据都与程序
47、的可执行指令存储在一起。注意，即使程序集存储在几个文件中，数据也不会出现不同步的问题。这是因为包含程序集入口的文件也存储了其他文件的细节、散列和内容，如果一个文件被替换，或者被塞满，系统肯定会检测出来，并拒绝加载程序集。程序集有两种类型：共享程序集和私有程序集。1.4.1 私有程序集私有程序集是最简单的一种程序集类型。私有程序集一般附带在某个软件上，且只能用于该软件。附带私有程序集的常见情况是，以可执行文件或许多库的方式提供应用程序，这些库包含的代码只能用于该应用程序。系统可以保证私有程序集不被其他软件使用，因为应用程序只能加载位于主执行文件所在文件夹或其子文件夹中的程序集。用户一般会希望把商
48、用软件安装在它自己的目录下，这样软件包没有覆盖、修改或加载另一个软件包的私有程序集的风险。私有程序集只能用于自己的软件包，这样，用户对什么软件使用它们就有了更多的控制。因此，不需要采取安全措施，因为这没有其他商用软件用某个新版本的程序集覆盖原来的私有程序集的风险( 但软件是专门执行怀有恶意的损害性操作的情况除外) 。名称也不会有冲突。如果私有程序集中的类正巧与另一个人的私有程序集中的类同名，是不会有问题的，因为给定的应用程序只能使用私有程序集的名称。因为私有程序集完全是自含式的，所以安装它的过程就很简单。只需把相应的文件放在文件系统的对应文件夹中即可(不需要注册表项 )，这个过程称为 “0 影
49、响(xcopy)安装“。1.4.2 共享程序集共享程序集是其他应用程序可以使用的公共库。因为其他软件可以访问共享程序集，所以需要采取一定的保护措施来防止以下风险： 名称冲突，另一个公司的共享程序集执行的类型与自己的共享程序集中的类型同名。因为客户机代码理论上可以同时访问这些程序集，所以这是一个严重的问题。 程序集被同一个程序集的不同版本覆盖- 新版本与某些已有的客户机代码不兼容。这些问题的解决方法是把共享程序集放在文件系统的一个特定的子目录树中，称为全局程序集高速缓存(GAC)。与私有程序集不同，不能简单地把共享程序集复制到对应的文件夹中，而需要专门安装到高速缓存中，这个过程可以用许多.NET 工具来完成，其中包含对程序集的检查、在程序集高速缓存中设置一个小的文件夹层次结构，以确保程序集的完整性。为了避免名称冲突，共享程序集应根据私钥加密法指定一个名称(私有程序集只需要指定与其主文件名相同的名称即可)。该名称称为强名 (strong name)，并保证其唯一性，它必须由要引用共享程序集的应用程序来引用。与覆盖程序集相关的问题，可以通过在程序集清单中指定版本信息来解决，也可以通过同时安装来解决。1.4.
