C高级编程第6版演示教学.doc

《C高级编程第6版演示教学.doc》由会员分享，可在线阅读，更多相关《C高级编程第6版演示教学.doc（820页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第1章 .NET体系结构我们不能孤立地使用C#语言，而必须和.NET Framework一起考虑。C#编译器专门用于.NET，这表示用C#编写的所有代码总是在.NET Framework中运行。对于C#语言来说，可以得出两个重要的结论：(1) C#的结构和方法论反映了.NET基础方法论。(2) 在许多情况下，C#的特定语言功能取决于.NET的功能，或依赖于.NET基类。由于这种依赖性，在开始使用C#编程前，了解.NET的结构和方法论就非常重要了，这就是本章的目的。下面是本章的内容：本章首先了解在.NET编译和运行所有的代码(包括C#)时通常会出现什么情况。对这些内容进行概述之后，就要详细阐述M

2、icrosoft中间语言(Microsoft Intermediate Language，MSIL或简称为IL)，.NET上所有编译好的代码都要使用这种语言。本章特别要介绍IL、通用类型系统(Common Type System，CTS)及公共语言规范(Common Language Specification，CLS)如何提供.NET语言之间的互操作性。最后解释各种语言如何使用.NET，包括Visual Basic和C+。之后，我们将介绍.NET的其他特性，包括程序集、命名空间和.NET基类。最后本章简要探讨一下C#开发人员可以创建的应用程序类型。1.1 C#与.NET的关系C#是一种相当新

3、的编程语言，C#的重要性体现在以下两个方面： 它是专门为与Microsoft的.NET Framework一起使用而设计的。(.NET Framework是一个功能非常丰富的平台，可开发、部署和执行分布式应用程序)。 它是一种基于现代面向对象设计方法的语言，在设计它时，Microsoft还吸取了其他类似语言的经验，这些语言是近20年来面向对象规则得到广泛应用后才开发出来的。有一个很重要的问题要弄明白：C#就其本身而言只是一种语言，尽管它是用于生成面向.NET环境的代码，但它本身不是.NET的一部分。.NET支持的一些特性，C#并不支持。而C#语言支持的另一些特性，.NET却不支持(例如运算符重

4、载)！但是，因为C#语言是和.NET一起使用的，所以如果要使用C#高效地开发应用程序，理解Framework就非常重要，所以本章将介绍.NET的内涵。1.2 公共语言运行库.NET Framework的核心是其运行库的执行环境，称为公共语言运行库(CLR)或.NET运行库。通常将在CLR的控制下运行的代码称为托管代码(managed code)。但是，在CLR执行编写好的源代码之前，需要编译它们(在C#中或其他语言中)。在.NET中，编译分为两个阶段：(1) 把源代码编译为Microsoft中间语言(IL)。(2) CLR把IL编译为平台专用的代码。这个两阶段的编译过程非常重要，因为Micro

5、soft中间语言(托管代码)是提供.NET的许多优点的关键。Microsoft中间语言与Java字节代码共享一种理念：它们都是低级语言，语法很简单(使用数字代码，而不是文本代码)，可以非常快速地转换为内部机器码。对于代码来说，这种精心设计的通用语法有很重要的优点：平台无关性、提高性能和语言的互操作性。1.2.1 平台无关性首先，这意味着包含字节代码指令的同一文件可以放在任一平台中，运行时编译过程的最后阶段可以很容易完成，这样代码就可以运行在特定的平台上。换言之，编译为中间语言就可以获得.NET平台无关性，这与编译为Java字节代码就会得到Java平台无关性是一样的。注意.NET的平台无关性目前

6、只是一种可能，因为在编写本书时，.NET只能用于Windows平台，但人们正在积极准备，使它可以用于其他平台(参见Mono项目，它用于实现.NET的开放源代码，参见http:/www.go-1.2.2 提高性能前面把IL和Java做了比较，实际上，IL比Java字节代码的作用还要大。IL总是即时编译的(称为JIT编译)，而Java字节代码常常是解释性的，Java的一个缺点是，在运行应用程序时，把Java字节代码转换为内部可执行代码的过程会导致性能的损失(但在最近，Java在某些平台上能进行JIT编译)。JIT编译器并不是把整个应用程序一次编译完(这样会有很长的启动时间)，而是只编译它调用的那部

7、分代码(这是其名称由来)。代码编译过一次后，得到的内部可执行代码就存储起来，直到退出该应用程序为止，这样在下次运行这部分代码时，就不需要重新编译了。Microsoft认为这个过程要比一开始就编译整个应用程序代码的效率高得多，因为任何应用程序的大部分代码实际上并不是在每次运行过程中都执行。使用JIT编译器，从来都不会编译这种代码。这解释了为什么托管IL代码的执行几乎和内部机器代码的执行速度一样快，但是并没有说明为什么Microsoft认为这会提高性能。其原因是编译过程的最后一部分是在运行时进行的，JIT编译器确切地知道程序运行在什么类型的处理器上，可以利用该处理器提供的任何特性或特定的机器代码指

8、令来优化最后的可执行代码。传统的编译器会优化代码，但它们的优化过程是独立于代码所运行的特定处理器的。这是因为传统的编译器是在发布软件之前编译为内部机器可执行的代码。即编译器不知道代码所运行的处理器类型，例如该处理器是x86兼容处理器还是Alpha处理器，这超出了基本操作的范围。例如Visual Studio 6为一般的奔腾机器进行了优化，所以它生成的代码就不能利用奔腾 III处理器的硬件特性。相反，JIT编译器不仅可以进行Visual Studio 6所能完成的优化工作，还可以优化代码所运行的特定处理器。1.2.3 语言的互操作性使用IL不仅支持平台无关性，还支持语言的互操作性。简而言之，就是

9、能将任何一种语言编译为中间代码，编译好的代码可以与从其他语言编译过来的代码进行交互操作。那么除了C#之外，还有什么语言可以通过.NET进行交互操作呢？下面就简要讨论其他常见语言如何与.NET交互操作。1. Visual Basic 2008Visual Basic 6在升级到Visual Basic .NET 2002时，经历了一番脱胎换骨的变化，才集成到.NET Framework的第一版中。Visual Basic 语言对Visual Basic 6进行了很大的演化，也就是说，Visual Basic 6并不适合运行.NET程序。例如，它与COM的高度集成，且只把事件处理程序作为源代码显示

10、给开发人员，大多数后台代码不能用作源代码。另外，它不支持继承，Visual Basic使用的标准数据类型也与.NET不兼容。Visual Basic 6在2002年升级为Visual Basic .NET，对Visual Basic进行的改变非常大，完全可以把Visual Basic当作是一种新语言。现有的Visual Basic 6代码不能编译为Visual Basic 2008代码(或Visual Basic .NET 2002、2003和2005代码)，把Visual Basic 6程序转换为Visual Basic 2008时，需要对代码进行大量的改动，但大多数修改工作都可以由Visu

11、al Studio 2008(Visual Studio的升级版本，用于与.NET一起使用)自动完成。如果把Visual Basic 6项目读到Visual Studio 2008中，Visual Studio 2008就会升级该项目，也就是说把Visual Basic 6源代码重写为Visual Basic 2008源代码。虽然这意味着其中的工作已大大减轻，但用户仍需要检查新的Visual Basic 2008代码，以确保项目仍可正确工作，因为这种转换并不十分完美。这种语言升级的一个副作用是不能再把Visual Basic 2008编译为内部可执行代码了。Visual Basic 2008只

12、编译为中间语言，就像C#一样。如果需要继续使用Visual Basic 6编写程序，就可以这么做，但生成的可执行代码会完全忽略.NET Framework，如果继续把Visual Studio作为开发环境，就需要安装Visual Studio 6。2. Visual C+ 2008Visual C+ 6有许多Microsoft对Windows的特定扩展。通过Visual C+ .NET，又加入了更多的扩展内容，来支持.NET Framework。现有的C+源代码会继续编译为内部可执行代码，不会有修改，但它会独立于.NET运行库运行。如果让C+代码在.NET Framework中运行，就可以在代

13、码的开头添加下述命令：#using 还可以把标记/clr传递给编译器，这样编译器假定要编译托管代码，因此会生成中间语言，而不是内部机器码。C+的一个有趣的问题是在编译托管代码时，编译器可以生成包含内嵌本机可执行代码的IL。这表示在C+代码中可以把托管类型和非托管类型合并起来，因此托管C+代码：class MyClass定义了一个普通的C+类，而代码：_ref class MyClass生成了一个托管类，就好像使用C#或Visual Basic 2008编写类一样。实际上，托管C+比C#更优越的一点是可以在托管C+代码中调用非托管C+类，而不必采用COM交互功能。如果在托管类型上试图使用.NET

14、不支持的特性(例如，模板或类的多继承)，编译器就会出现一个错误。另外，在使用托管类时，还需要使用非标准的C+特性。因为C+允许低级指针操作，C+编译器不能生成可以通过CLR内存类型安全测试的代码。如果CLR把代码标识为内存类型安全是非常重要的，就需要用其他一些语言编写源代码，例如C# 或Visual Basic 2008。3. COM和COM+从技术上讲，COM 和 COM+并不是面向.NET的技术，因为基于它们的组件不能编译为IL(但如果原来的COM组件是用C+编写的，使用托管C+，在某种程度上可以这么做)。但是，COM+仍然是一个重要的工具，因为其特性没有在.NET中完全实现。另外，COM

15、组件仍可以使用-.NET集成了COM的互操作性，从而使托管代码可以调用COM组件，COM组件也可以调用托管代码(见第24章)。在一般情况下，把新组件编写为.NET组件，大多是为了方便，因为这样可以利用.NET基类和托管代码的其他优点。1.3 中间语言如前所述，Microsoft中间语言显然在.NET Framework中有非常重要的作用。C#开发人员应明白，C#代码在执行前要编译为中间语言(实际上，C#编译器仅编译为托管代码)，这是有意义的，现在应详细讨论一下IL的主要特征，因为面向.NET的所有语言在逻辑上都需要支持IL的主要特征。下面就是中间语言的主要特征： 面向对象和使用接口 值类型和引

16、用类型之间的巨大差别 强数据类型 使用异常来处理错误 使用特性(attribute)下面详细讨论这些特征。1.3.1 面向对象和接口的支持.NET的语言无关性还有一些实际的限制。中间语言在设计时就打算实现某些特殊的编程方法，这表示面向它的语言必须与编程方法兼容，Microsoft为IL选择的特定道路是传统的面向对象的编程，带有类的单一继承性。注意：不熟悉面向对象概念的读者应参考附录B，获得更多的信息。除了传统的面向对象编程外，中间语言还引入了接口的概念，它们显示了在带有COM的Windows下的第一个实现方式。.NET接口与COM接口不同，它们不需要支持任何COM基础结构，例如，它们不是派生自

17、IUnknown，也没有对应的GUID。但它们与COM接口共享下述理念：提供一个契约，实现给定接口的类必须提供该接口指定的方法和属性的实现方式。前面介绍了使用.NET意味着要编译为中间语言，即需要使用传统的面向对象的方法来编程。但这并不能提供语言的互操作性。毕竟，C+和Java都使用相同的面向对象的范型，但它们仍不是可交互操作的语言。下面需要详细探讨一下语言互操作性的概念。首先，需要确定一下语言互操作性的含义。毕竟，COM允许以不同语言编写的组件一起工作，即可以调用彼此的方法。这就足够了吗？COM是一个二进制标准，允许组件实例化其他组件，调用它们的方法或属性，而无须考虑编写相关组件的语言。但为

18、了实现这个功能，每个对象都必须通过COM运行库来实例化，通过接口来访问。根据相关组件的线程模型，不同线程上内存空间和运行组件之间要编组数据，这还可能造成很大的性能损失。在极端情况下，组件保存为可执行文件，而不是DLL文件，还必须创建单独的进程来运行它们。重要的是组件要能与其他组件通信，但仅通过COM运行库进行通信。无论COM是用于允许使用不同语言的组件直接彼此通信，或者创建彼此的实例，系统都把COM作为中间件来处理。不仅如此，COM结构还不允许利用继承实现，即它丧失了面向对象编程的许多优势。一个相关的问题是，在调试时，仍必须单独调试用不同语言编写的组件。这样就不可能在调试器上调试不同语言的代码

19、了。语言互操作性的真正含义是用一种语言编写的类应能直接与用另一种语言编写的类通信。特别是： 用一种语言编写的类应能继承用另一种语言编写的类。 一个类应能包含另一个类的实例，而不管它们是使用什么语言编写的。 一个对象应能直接调用用其他语言编写的另一个对象的方法。 对象(或对象的引用)应能在方法之间传递。 在不同的语言之间调用方法时，应能在调试器中调试这些方法调用，即调试不同语言编写的源代码。这是一个雄心勃勃的目标，但令人惊讶的是，.NET和中间语言已经实现了这个目标。在调试器上调试方法时，Visual Studio IDE提供了这样的工具(不是CLR提供的)。1.3.2 相异值类型和引用类型与其

20、他编程语言一样，中间语言提供了许多预定义的基本数据类型。它的一个特性是值类型和引用类型有明显的区别。对于值类型，变量直接保存其数据，而对于引用类型，变量仅保存地址，对应的数据可以在该地址中找到。在C+中，引用类型类似于通过指针来访问变量，而在Visual Basic中，与引用类型最相似的是对象，Visual Basic 6总是通过引用来访问对象。中间语言也有数据存储的规范：引用类型的实例总是存储在一个名为托管堆的内存区域中，值类型一般存储在堆栈中(但如果值类型在引用类型中声明为字段，它们就内联存储在堆中)。第2章C#基础讨论堆栈和堆，及其工作原理。1.3.3 强数据类型中间语言的一个重要方面是

21、它基于强数据类型。所有的变量都清晰地标记为属于某个特定数据类型(在中间语言中没有Visual Basic和脚本语言中的Variant数据类型)。特别是中间语言一般不允许对模糊的数据类型执行任何操作。例如，Visual Basic 6开发人员习惯于传递变量，而无需考虑它们的类型，因为Visual Basic 6会自动进行所需的类型转换。C+开发人员习惯于在不同类型之间转换指针类型。执行这类操作将大大提高性能，但破坏了类型的安全性。因此，这类操作只能在某些编译为托管代码的语言中的特殊情况下进行。确实，指针(相对于引用)只能在标记了的C#代码块中使用，但在Visual Basic中不能使用(但一般在

22、托管C+中允许使用)。在代码中使用指针会立即导致CLR提供的内存类型安全性检查失败。注意，一些与.NET兼容的语言，例如Visual Basic 2008，在类型化方面的要求仍比较松，但这是可以的，因为编译器在后台确保在生成的IL上强制类型安全。尽管强迫实现类型的安全性最初会降低性能，但在许多情况下，我们从.NET提供的、依赖于类型安全的服务中获得的好处更多。这些服务包括： 语言的互操作性 垃圾收集 安全性 应用程序域下面讨论强数据类型化对这些.NET特性非常重要的原因。1. 语言互操作性中强数据类型的重要性如果类派生自其他类，或包含其他类的实例，它就需要知道其他类使用的所有数据类型，这就是强

23、数据类型非常重要的原因。实际上，过去没有任何系统指定这些信息，从而成为语言继承和交互操作的真正障碍。这类信息不只是在一个标准的可执行文件或DLL中出现。假定将Visual Basic 2008类中的一个方法定义为返回一个Integer-Visual Basic 2008可以使用的标准数据类型之一。但C#没有该名称的数据类型。显然，我们只能从该类中派生，再使用这个方法，如果编译器知道如何把Visual Basic 2008的Integer类型映射为C#定义的某种已知类型，就可以在C#代码中使用返回的类型。这个问题在.NET中是如何解决的？(1) 通用类型系统(CTS)这个数据类型问题在.NET中

24、使用通用类型系统(CTS)得到了解决。CTS定义了可以在中间语言中使用的预定义数据类型，所有面向.NET Framework的语言都可以生成最终基于这些类型的编译代码。例如，Visual Basic 2008的Integer实际上是一个32位有符号的整数，它实际映射为中间语言类型Int32。因此在中间语言代码中就指定这种数据类型。C#编译器可以使用这种类型，所以就不会有问题了。在源代码中，C#用关键字int来表示Int32，所以编译器就认为Visual Basic 2008方法返回一个int类型的值。通用类型系统不仅指定了基本数据类型，还定义了一个内容丰富的类型层次结构，其中包含设计合理的位置

25、，在这些位置上，代码允许定义它自己的类型。通用类型系统的层次结构反映了中间语言的单一继承的面向对象方法，如图1-1所示。图 1-1这个树形结构中的类型说明如表1-1所示。表 1-1类 型含 义Type代表任何类型的基类Value Type代表任何值类型的基类Reference Types通过引用来访问，且存储在堆中的任何数据类型Built-in Value Types包含大多数标准基本类型，可以表示数字、Boolean值或字符Enumerations枚举值的集合User-defined Value Types在源代码中定义，且保存为值类型的数据类型。在C#中，它表示结构Interface Ty

26、pes接口Pointer Types指针 Self-describing Types为垃圾回收器提供信息的数据类型(参见下一节)Arrays包含对象数组的类型Class Types可自我描述的类型，但不是数组Delegates用于把引用包含在方法中的类型User-definedReference Types在源代码中定义，且保存为引用类型的数据类型。在C#中，它表示类Boxed Value Types值类型，临时打包放在一个引用中，以便于存储在堆中这里没有列出内置的所有值类型，因为第3章将详细介绍它们。在C#中，编译器识别的每个预定义类型都映射为一个IL内置类型。这与Visual Basic

27、2008是一样的。(2) 公共语言规范(CLS)公共语言规范(Common Language Specification，CLS)和通用类型系统一起确保语言的互操作性。CLS是一个最低标准集，所有面向.NET的编译器都必须支持它。因为IL是一种内涵非常丰富的语言，大多数编译器的编写人员有可能把给定编译器的功能限制为只支持IL和CLS提供的一部分特性。只要编译器支持已在CLS中定义的内容，这就是很不错的。提示：编写非CLS兼容代码是完全可以接受的，只是在编写了这种代码后，就不能保证编译好的IL代码完全支持语言的互操作性。下面的一个例子是有关区分大小写字母的。IL是区分大小写的语言。使用这些语言的

28、开发人员常常利用区分大小写所提供的灵活性来选择变量名。但Visual Basic 2008是不区分大小写的语言。CLS就要指定CLS兼容代码不使用任何只根据大小写来区分的名称。因此，Visual Basic 2008代码可以与CLS兼容代码一起使用。这个例子说明了CLS的两种工作方式。首先是各个编译器的功能不必强大到支持.NET的所有功能，这将鼓励人们为其他面向.NET的编程语言开发编译器。第二，它提供如下保证：如果限制类只能使用CLS兼容的特性，就要保证用其他兼容语言编写的代码可以使用这个类。这种方法的优点是使用CLS兼容特性的限制只适用于公共和受保护的类成员和公共类。在类的私有实现方式中，

29、可以编写非CLS代码，因为其他程序集(托管代码的单元，参见本章后面的内容)中的代码不能访问这部分代码。这里不深入讨论CLS规范。在一般情况下，CLS对C#代码的影响不会太大，因为C#中的非CLS兼容特性非常少。2. 垃圾收集垃圾收集器用来在.NET中进行内存管理，特别是它可以恢复正在运行中的应用程序需要的内存。到目前为止，Windows平台已经使用了两种技术来释放进程向系统动态请求的内存： 完全以手工方式使应用程序代码完成这些工作。 让对象维护引用计数。让应用程序代码负责释放内存是低级高性能的语言使用的技术，例如C+。这种技术很有效，且可以让资源在不需要时就释放(一般情况下)，但其最大的缺点是

30、频繁出现错误。请求内存的代码还必须显式通知系统它什么时候不再需要该内存。但这是很容易被遗漏的，从而导致内存泄漏。尽管现代的开发环境提供了帮助检测内存泄漏的工具，但它们很难跟踪错误，因为直到内存已大量泄漏从而使Windows拒绝为进程提供资源时，它们才会发挥作用。到那个时候，由于对内存的需求很大，会使整个计算机变得相当慢。维护引用计数是COM对象采用的一种技术，其方法是每个COM组件都保留一个计数，记录客户机目前对它的引用数。当这个计数下降到0时，组件就会删除自己，并释放相应的内存和资源。它带来的问题是仍需要客户机通知组件它们已经完成了内存的使用。只要有一个客户机没有这么做，对象就仍驻留在内存中

31、。在某些方面，这是比C+内存泄漏更为严重的问题，因为COM对象可能存在于它自己的进程中，从来不会被系统删除(在C+内存泄漏问题上，系统至少可以在进程中断时释放所有的内存)。.NET运行库采用的方法是垃圾收集器，这是一个程序，其目的是清理内存，方法是所有动态请求的内存都分配到堆上(所有的语言都是这样处理的，但在.NET中，CLR维护它自己的托管堆，以供.NET应用程序使用)，当.NET检测到给定进程的托管堆已满，需要清理时，就调用垃圾收集器。垃圾收集器处理目前代码中的所有变量，检查对存储在托管堆上的对象的引用，确定哪些对象可以从代码中访问- 即哪些对象有引用。没有引用的对象就不能再从代码中访问，

32、因而被删除。Java就使用与此类似的垃圾收集系统。之所以在.NET中使用垃圾收集器，是因为中间语言已用来处理进程。其规则要求，第一，不能引用已有的对象，除非复制已有的引用。第二，中间语言是类型安全的语言。在这里，其含义是如果存在对对象的任何引用，该引用中就有足够的信息来确定对象的类型。垃圾收集器机制不能和诸如非托管C+这样的语言一起使用，因为C+允许指针自由地转换数据类型。垃圾收集器的一个重要方面是它的不确定性。换言之，不能保证什么时候会调用垃圾收集器：.NET运行库决定需要它时，就可以调用它(除非明确调用垃圾收集器)。但可以重写这个过程，在代码中调用垃圾收集器。3. 安全性.NET很好地补足

33、了Windows提供的安全机制，因为它提供的安全机制是基于代码的安全性，而Windows仅提供了基于角色的安全性。基于角色的安全性建立在运行进程的账户的身份基础上，换而言之，就是谁拥有和运行进程。另一方面，基于代码的安全性建立在代码实际执行的任务和代码的可信程度上。由于中间语言提供了强大的类型安全性，所以CLR可以在运行代码前检查它，以确定是否有需要的安全权限。.NET还提供了一种机制，可以在运行代码前指定代码需要什么安全权限。基于代码的安全性非常重要，原因是它降低了运行来历不明的代码的风险(例如代码是从Internet上下载来的)。即使代码运行在管理员账户下，也有可能使用基于代码的安全性，来

34、确定这段代码是否仍不能执行管理员账户一般允许执行的某些类型的操作，例如读写环境变量、读写注册表或访问.NET反射特性。安全问题详见本书后面的第20章。4. 应用程序域应用程序域是.NET中的一个重要技术改进，它用于减少运行应用程序的系统开销，这些应用程序需要与其他程序分离开来，但仍需要彼此通信。典型的例子是Web服务器应用程序，它需要同时响应许多浏览器请求。因此，要有许多组件实例同时响应这些同时运行的请求。在.NET开发出来以前，可以让这些实例共享同一个进程，但此时一个运行的实例就有可能导致整个网站的崩溃；也可以把这些实例孤立在不同的进程中，但这样做会增加相关性能的系统开销。到现在为止，孤立代

35、码的唯一方式是通过进程来实现的。在运行一个新的应用程序时，它会在一个进程环境内运行。Windows通过地址空间把进程分隔开来。这样，每个进程有4GB的虚拟内存来存储其数据和可执行代码(4GB对应于32位系统，64位系统要用更多的内存)。Windows利用额外的间接方式把这些虚拟内存映射到物理内存或磁盘空间的一个特殊区域中，每个进程都会有不同的映射，虚拟地址空间块映射的物理内存之间不能有重叠，这种情况如图1-2所示。图 1-2 在一般情况下，任何进程都只能通过指定虚拟内存中的一个地址来访问内存-即进程不能直接访问物理内存，因此一个进程不可能访问分配给另一个进程的内存。这样就可以确保任何执行出错的

36、代码不会损害其地址空间以外的数据(注意在Windows 95/98上，这些保护措施不像在Windows NT/2000/XP/2003/Vista上那样强大，所以理论上存在应用程序因写入不对应的内存而导致Windows崩溃的可能性)。进程不仅是运行代码的实例相互隔离的一种方式，在Windows NT/2000/XP/2003/Vista系统上，它们还可以构成分配了安全权限和许可的单元。每个进程都有自己的安全标识，明确地表示Windows允许该进程可以执行的操作。进程对确保安全有很大的帮助，而它们的一大缺点是性能。许多进程常常在一起工作，因此需要相互通信。一个常见的例子是进程调用一个COM组件，

37、而该COM组件是可执行的，因此需要在它自己的进程上运行。在COM中使用代理时也会发生类似的情况。因为进程不能共享任何内存，所以必须使用一个复杂的编组过程在进程之间复制数据。这对性能有非常大的影响。如果需要使组件一起工作，但不希望性能有损失，唯一的方法是使用基于DLL的组件，让所有的组件在同一个地址空间中运行- 其风险是执行出错的组件会影响其他组件。应用程序域是分离组件的一种方式，它不会导致因在进程之间传送数据而产生的性能问题。其方法是把任何一个进程分解到多个应用程序域中，每个应用程序域大致对应一个应用程序，执行的每个线程都运行在一个具体的应用程序域中，如图1-3所示。如果不同的可执行文件都运行

38、在同一个进程空间中，显然它们就能轻松地共享数据，因为理论上它们可以直接访问彼此的数据。虽然在理论上这是可以实现的，但是CLR会检查每个正在运行的应用程序的代码，以确保这些代码不偏离它自己的数据区域，保证不发生直接访问其他进程的数据的情况。这初看起来是不可能的，如何告诉程序要做什么工作，而又不真正运行它？图 1-3实际上，这么做通常是可能的，因为中间语言拥有强大的类型安全功能。在大多数情况下，除非代码明确使用不安全的特性，例如指针，否则它使用的数据类型可以确保内存不会被错误地访问。例如，.NET数组类型执行边界检查，以禁止执行超出边界的数组操作。如果运行的应用程序的确需要与运行在不同应用程序域中

39、的其他应用程序通信或共享数据，就必须调用.NET的远程服务。被验证不能访问超出其应用程序域的数据(而不是通过明确的远程机制)的代码就是内存类型安全的代码，这种代码与运行在同一个进程中但应用程序域不同的类型安全代码一起运行是安全的。1.3.4 通过异常处理错误.NET Framework可以根据异常使用相同的机制处理错误情况，这与Java和C+是一样的。C+开发人员应注意到，由于IL有非常强大的类型系统，所以在IL中以C+的方式使用异常不会带来相关的性能问题。另外，.NET和C#也支持finally块，这是许多C+开发人员长久以来的愿望。第14章会详细讨论异常。简要地说，代码的某些领域被看作是异

40、常处理程序例程，每个例程都能处理某种特殊的错误情况(例如，找不到文件，或拒绝执行某些操作的许可)。这些条件可以定义得很宽或很窄。异常结构确保在发生错误情况时，执行进程立即跳到最合适的异常处理程序例程上，处理错误情况。异常处理的结构还提供了一种方便的方式，当对象包含错误情况的准确信息时，该对象就可以传送给错误处理例程。这个对象包括给用户提供的相应信息和在代码的什么地方检测到错误的确切信息。大多数异常处理结构，包括异常发生时的程序流控制，都是由高级语言处理的，例如C#、Visual Basic 2008和C+，任何中间语言中的命令都不支持它。例如，C#使用try、catch和 finally代码块

41、来处理它，详见第14章。.NET提供了一种基础结构，让面向.NET的编译器支持异常处理。特别是它提供了一组.NET类来表示异常，语言的互操作性则允许异常处理代码处理被抛出的异常对象，无论异常处理代码使用什么语言编写，都是这样。语言的无关性没有体现在C+和Java的异常处理中，但在COM的错误处理机制中有一定限度的体现。COM的错误处理机制包括从方法中返回错误代码以及传递错误对象。在不同的语言中，异常的处理是一致的，这是多语言开发的重要一环。1.3.5 特性的使用特性(attribute)是使用C+编写COM组件的开发人员很熟悉的一个功能(在Microsoft的COM接口定义语言(Interfa

42、ce Definition Language，IDL)中使用特性)。特性最初是为了在程序中提供与某些项相关的额外信息，以供编译器使用。.NET支持特性，因此现在C+、C#和Visual Basic 2008也支持特性。但在.NET中，对特性的革新是建立了一个机制，通过该机制可以在源代码中定义自己的特性。这些用户定义的特性将和对应数据类型或方法的元数据放在一起，这对于文档说明书十分有用，它们和反射技术一起使用，以根据特性执行编程任务。另外，与.NET的语言无关性的基本原理一样，特性也可以在一种语言的源代码中定义，而被用另一种语言编写的代码读取。本书的第13章详细介绍了特性。1.4 程序集程序集(

43、assembly)是包含编译好的、面向.NET Framework的代码的逻辑单元。本章不详细论述程序集，而在第17章中论述，下面概述其中的要点。程序集是完全自我描述性的，也是一个逻辑单元而不是物理单元，它可以存储在多个文件中(动态程序集的确存储在内存中，而不是存储在文件中)。如果一个程序集存储在多个文件中，其中就会有一个包含入口点的主文件，该文件描述了程序集中的其他文件。注意可执行代码和库代码使用相同的程序集结构。唯一的区别是可执行的程序集包含一个主程序入口点，而库程序集不包含。程序集的一个重要特性是它们包含的元数据描述了对应代码中定义的类型和方法。程序集也包含描述程序集本身的元数据，这种程

44、序集元数据包含在一个称为程序集清单的区域中，可以检查程序集的版本及其完整性。注意：ildasm是一个基于Windows的实用程序，可以用于检查程序集的内容，包括程序集清单和元数据。第17章将介绍ildasm。程序集包含程序的元数据，表示调用给定程序集中的代码的应用程序或其他程序集不需要指定注册表或其他数据源，以确定如何使用该程序集。这与以前的COM有很大的区别，以前，组件的GUID和接口必须从注册表中获取，在某些情况下，方法和属性的详细信息也需要从类型库中读取。把数据分散在3个以上的不同位置上，可能会出现信息不同步的情况，从而妨碍其他软件成功地使用该组件。有了程序集后，就不会发生这种情况，因为

45、所有的元数据都与程序的可执行指令存储在一起。注意，即使程序集存储在几个文件中，数据也不会出现不同步的问题。这是因为包含程序集入口的文件也存储了其他文件的细节、散列和内容，如果一个文件被替换，或者被塞满，系统肯定会检测出来，并拒绝加载程序集。程序集有两种类型：共享程序集和私有程序集。1.4.1 私有程序集私有程序集是最简单的一种程序集类型。私有程序集一般附带在某个软件上，且只能用于该软件。附带私有程序集的常见情况是，以可执行文件或许多库的方式提供应用程序，这些库包含的代码只能用于该应用程序。系统可以保证私有程序集不被其他软件使用，因为应用程序只能加载位于主执行文件所在文件夹或其子文件夹中的程序集

46、。用户一般会希望把商用软件安装在它自己的目录下，这样软件包没有覆盖、修改或加载另一个软件包的私有程序集的风险。私有程序集只能用于自己的软件包，这样，用户对什么软件使用它们就有了更多的控制。因此，不需要采取安全措施，因为这没有其他商用软件用某个新版本的程序集覆盖原来的私有程序集的风险(但软件是专门执行怀有恶意的损害性操作的情况除外)。名称也不会有冲突。如果私有程序集中的类正巧与另一个人的私有程序集中的类同名，是不会有问题的，因为给定的应用程序只能使用私有程序集的名称。因为私有程序集完全是自含式的，所以安装它的过程就很简单。只需把相应的文件放在文件系统的对应文件夹中即可(不需要注册表项)，这个过程

47、称为0影响(xcopy)安装。1.4.2 共享程序集共享程序集是其他应用程序可以使用的公共库。因为其他软件可以访问共享程序集，所以需要采取一定的保护措施来防止以下风险： 名称冲突，另一个公司的共享程序集执行的类型与自己的共享程序集中的类型同名。因为客户机代码理论上可以同时访问这些程序集，所以这是一个严重的问题。 程序集被同一个程序集的不同版本覆盖- 新版本与某些已有的客户机代码不兼容。这些问题的解决方法是把共享程序集放在文件系统的一个特定的子目录树中，称为全局程序集高速缓存(GAC)。与私有程序集不同，不能简单地把共享程序集复制到对应的文件夹中，而需要专门安装到高速缓存中，这个过程可以用许多.

48、NET工具来完成，其中包含对程序集的检查、在程序集高速缓存中设置一个小的文件夹层次结构，以确保程序集的完整性。为了避免名称冲突，共享程序集应根据私钥加密法指定一个名称(私有程序集只需要指定与其主文件名相同的名称即可)。该名称称为强名(strong name)，并保证其唯一性，它必须由要引用共享程序集的应用程序来引用。与覆盖程序集相关的问题，可以通过在程序集清单中指定版本信息来解决，也可以通过同时安装来解决。1.4.3 反射因为程序集存储了元数据，包括在程序集中定义的所有类型和这些类型的成员的细节，所以可以编程访问这些元数据。这个技术称为反射，第13章详细介绍了它们。该技术很有趣，因为它表示托管代码实际上可以检查其他托管代码，甚至检查它自己，以确定该