第一章 .NET体系结构

　　　　　　　　　　　　　　　第1章  .NET体系结构

　　　　　　　　　　　　　　　　　　1.1 C#与.NET的关系
　　 我们不能孤立地使用C#语言，而必须和.NET Framework一起考虑。C#编译器专门用于.NET，这表示用C#编写的所有代码总是在.NET Framework中运行。对于C#语言来说，可以得出两个重要的结论：
● C#的结构和方法论反映了.NET基础方法论。
● 在许多情况下，C#的特定语言功能取决于.NET的功能，或依赖于.NET基类。
　　由于这种依赖性，在开始使用C#编程前，了解.NET的结构和方法论就非常重要了，这就是本章的目的。
本章首先介绍.NET如何处理所有的代码(包括C#)，了解在.NET编译和运行代码时通常会出现什么情况。对这些内容进行概述之后，就要详细阐述Microsoft中间语言(Microsoft Intermediate Language，MSIL或简称为IL)，所有编译好的代码都要使用这种语言。本章特别要介绍IL、通用类型系统(Common Type System，CTS)及公共语言规范(Common Language Specification，CLS)如何提供语言之间的互操作性。最后解释各种语言如何使用.NET，包括VB和C++。
　　之后，我们将介绍.NET的其他特性，包括程序集、命名空间和.NET基类。最后本章简要探讨一下C#开发人员可以创建的应用程序类型。
C#是一种相当新的编程语言，C#的重要性体现在以下两个方面：
● 它是专门为与Microsoft的.NET Framework一起使用而设计的。
● 它是一种基于现代面向对象设计方法的语言，在设计它时，Microsoft还吸取了其他类似语言的经验，这些语言是近20年来面向对象规则得到广泛应用后才开发出来的。
　　有一个很重要的问题要弄明白：C#就其本身而言只是一种语言，尽管它是用于生成面向.NET环境的代码，但它本身不是.NET的一部分。.NET支持的一些特性，C#并不支持。而C#语言支持的另一些特性，.NET却不支持(例如运算符重载)！
但是，因为C#语言是和.NET一起使用的，所以如果要使用C#高效地开发应用程序，理解Framework就非常重要，所以本章将介绍.NET的内涵。
 
　　　　　　　　　　　　　　　　　　1.2 公共语言运行库
 　　.NET Framework的核心是其运行库的执行环境，称为公共语言运行库(CLR)或.NET运行库。在CLR的控制下运行的代码常常称为托管代码(managed code)。
但是，在CLR执行开发的源代码之前，需要编译它们(在C#中或其他语言中)。在.NET中，编译分为两个阶段：
(1) 把源代码编译为Microsoft中间语言(IL)。
(2) CLR把IL编译为平台专用的代码。
　　这个两阶段的编译过程非常重要，因为Microsoft中间语言(托管代码)是提供.NET的许多优点的关键。下面看看其原因。
托管代码的优点
　　Microsoft中间语言与Java字节代码共享一种理念：它们都是一种低级语言，语法很简单(使用数字代码，而不是文本代码)，可以非常快速地转换为内部机器码。对于代码来说，这种精心设计的通用语法，有很重要的优点。
1. 平台无关性
　　首先，这意味着包含字节代码指令的同一文件可以放在任一平台中，运行时编译过程的最后阶段可以很容易完成，这样代码就可以运行在该特定的平台上。换言之，编译为中间语言就可以获得.NET平台无关性，这与编译为Java字节代码就会得到Java平台无关性是一样的。
注意.NET的平台无关性目前只是一种可能，因为在编写本书时，.NET只能用于Windows平台，但人们正在积极准备，使它可以用于其他平台(参见Mono项目，它用于创建.NET的开放源代码的实现，参见http://www.go-mono.com/)。
提高性能
        比Java字节代码的作用还要大。IL总是即时编译的(称为JIT编译)，而Java字节代码常常是解释性的，Java的一个缺点是，在运行应用程序时，把Java字节代码转换为内部可执行代码的过程会导致性能的损失(但在最近，Java在某些平台上能进行JIT编译)。

JIT编译器并不是把整个应用程序一次编译完(这样会有很长的启动时间)，而是只编译它调用的那部分代码(这是其名称由来)。代码编译过一次后，得到的内部可执行代码就存储起来，直到退出该应用程序为止，这样在下次运行这部分代码时，就不需要重新编译了。Microsoft认为这个过程要比一开始就编译整个应用程序代码的效率高得多，因为任何应用程序的大部分代码实际上并不是在每次运行过程中都执行。使用JIT编译器，从来都不会编译这种代码。

这解释了为什么托管IL代码的执行几乎和内部机器代码的执行速度一样快，但是并没有说明为什么Microsoft认为这会提高性能。其原因是编译过程的最后一部分是在运行时进行的，JIT编译器确切地知道程序运行在什么类型的处理器上，利用该处理器提供的任何特性或特定的机器代码指令来优化最后的可执行代码。

传统的编译器会优化代码，但它们的优化过程是独立于代码所运行的特定处理器的。这是因为传统的编译器是在发布软件之前编译为内部机器可执行的代码。即编译器不知道代码所运行的处理器类型，例如该处理器是x86兼容处理器或Alpha处理器，这超出了基本操作的范围。例如Visual Studio 6优化了一台一般的Pentium机器，所以它生成的代码就不能利用Pentium III处理器的硬件特性。相反，JIT编译器不仅可以进行Visual Studio 6所能完成的优化工作，还可以优化代码所运行的特定处理器。

3. 语言的互操作性
不仅支持平台无关性，还支持语言的互操作性。简言之，就是能将任何一种语言编译为中间代码，编译好的代码可以与从其他语言编译过来的代码进行交互操作。
那么除了C#之外，还有什么语言可以通过.NET进行交互操作呢？下面就简要讨论其他常见语言如何与.NET交互操作。

VB.NET

在升级到Visual Basic .NET时，经历了一番脱胎换骨的变化。Visual Basic是在最近的几年中演化的，其早期版本Visual Basic 6并不适合运行.NET程序。例如，它与COM的高度集成，且只把事件处理程序作为源代码显示给开发人员，大多数后台代码不能用作源代码。另外，它不支持继承，Visual Basic使用的标准数据类型也与.NET不兼容。

Visual Basic 6已经升级为Visual Basic .NET，对VB进行的改变非常大，完全可以把Visual Basic .NET当作是一种新语言。现有的VB6代码不能编译为VB.NET代码，把VB6程序转换为VB.NET时，需要对代码进行大量的改动，但大多数修改工作都可以由Visual Studio .NET(VS的升级版本，用于与.NET一起使用)自动完成。如果要把一个VB6项目读取到Visual Studio .NET中，Visual Studio .NET就会升级该项目，也就是说把VB6源代码重写为VB.NET源代码。虽然这意味着其中的工作已大大减轻，但用户仍需要检查新的VB.NET代码，以确保项目仍可正确工作，因为这种转换并不十分完美。

这种语言升级的一个副作用是不能再把VB.NET编译为内部可执行代码了。VB.NET只编译为中间语言，就像C#一样。如果需要继续使用VB6编写程序，就可以这么做，但生成的可执行代码会完全忽略.NET Framework，如果继续把Visual Studio作为开发环境，就需要安装Visual Studio 6。

Visual C++ .NET

有许多Microsoft对Windows的特定扩展。通过Visual C++ .NET，又加入了更多的扩展内容，来支持.NET Framework。现有的C++源代码会继续编译为内部可执行代码，不会有修改，但它会独立于.NET运行库运行。如果要让C++代码在.NET Framework中运行，就要在代码的开头添加下述命令：

#using

还要把标记/clr传递给编译器，编译器假定要编译托管代码，因此会生成中间语言，而不是内部机器码。C++的一个有趣的问题是在编译托管代码时，编译器可以生成包含内嵌本机可执行代码的IL。这表示在C++代码中可以把托管类型和非托管类型合并起来，因此托管C++ 代码：

class MyClass

{

定义了一个普通的C++类，而代码：

__gc class MyClass

{

生成了一个托管类，就好像使用C#或VB.NET编写类一样。实际上，托管C++比C#更优越的一点是可以在托管C++代码中调用非托管C++类，而不必采用COM交互功能。

如果在托管类型上试图使用.NET不支持的特性(例如，模板或类的多继承)，编译器就会出现一个错误。另外，在使用托管类时，还需要使用非标准的C++特性(例如上述代码中的__gc关键字)。

因为C++允许低级指针操作，C++编译器不能生成可以通过CLR内存类型安全测试的代码。如果CLR把代码标识为内存类型安全是非常重要的，就需要用其他一些语言编写源代码，例如C# 或VB.NET。

Visual J#

。在.NET Framework 1.1版本推出之前，用户必须下载相应的软件，才能使用J#。现在J#语言内置于.NET Framework中。因此，J#用户可以利用Visual Studio .NET的所有常见特性。Microsoft希望大多数J++用户认为他们在使用.NET时，将很容易使用J#。J#不使用Java运行库，而是使用与其他.NET兼容语言一样的基类库。这说明，与C#和VB.NET一样，可以使用J#创建ASP.NET Web应用程序、Windows窗体、XML Web服务和其他应用程序。

脚本语言

的推出，一般认为它们的重要性在降低。另一方面，JScript升级到JScript.NET。ASP.NET页面可以用JScript.NET编写，现在可以把JScript.NET当作一种编译语言来运行，而不是解释性的语言，也可以编写输入量比较大的JScript.NET代码。有了ASP.NET后，就没有必要在服务器端的Web页面上使用脚本语言了，但VBA仍用作Office文档和Visual Studio宏语言。

COM和COM+

从技术上讲，COM 和 COM+并不是面向.NET的技术，因为基于它们的组件不能编译为IL(但如果原来的COM组件是用C++编写的，使用托管C++，在某种程度上可以这么做)。但是，COM+仍然是一个重要的工具，因为其特性没有在.NET中完全实现。另外，COM组件仍可以使用——.NET组合了COM的互操作性，从而使托管代码可以调用COM组件，COM组件也可以调用托管代码(见第29章)。在大多数情况中，把新组件编写为.NET组件，其多数目的是为了比较方便，因为这样可以利用.NET基类和托管代码的其他优点。
 
1.3 中间语言
 中有非常重要的作用。C#开发人员应明白，C#代码在执行前要编译为中间语言(实际上，C#编译器仅编译为托管代码)，这是有意义的，现在应详细讨论一下IL的主要特征，因为面向.NET的所有语言在逻辑上都需要支持IL的主要特征。

下面就是中间语言的主要特征：

● 面向对象和使用接口

● 值类型和引用类型之间的巨大差别

● 强数据类型

● 使用异常来处理错误

● 使用特性(attribute)

下面详细讨论这些特征。

1.3.1  面向对象和接口的支持
.NET的语言无关性还有一些实际的限制。特别是中间语言在设计时就打算实现某些特殊的编程方法，这表示.NET语言必须与编程方法兼容，Microsoft为IL选择的特定道路是传统的面向对象的编程，带有类的单一继承性。

注意：

不熟悉面向对象功能概念的读者应参考附录A，获得更多的信息。附录A可以从www.wrox.com上下载。

除了传统的面向对象编程外，中间语言还引入了接口的概念，它们显示了在带有COM的Windows下的第一个实现方式。.NET接口与COM接口不同，它们不需要支持任何COM基础结构，例如，它们不是派生自IUnknown，也没有对应的GUID。但它们与COM接口共享下述理念：提供一个契约，实现给定接口的类必须提供该接口指定的方法和属性的实现方式。

面向对象和语言的互操作性
前面介绍了使用.NET意味着要编译为中间语言，即需要使用传统的面向对象的方法来编程。但这并不能提供语言的互操作性。毕竟，C++和Java都使用相同的面向对象的范型，但它们仍不是可交互操作的语言。下面需要详细探讨一下语言互操作性的概念。

首先，需要确定一下语言互操作性的含义。毕竟，COM允许以不同语言编写的组件一起工作，即可以调用彼此的方法。这就足够了吗？COM是一个二进制标准，允许组件实例化其他组件，调用它们的方法或属性，而无需考虑编写相关组件的语言。但为了实现这个功能，每个对象都必须通过COM运行库来实例化，通过接口来访问。根据关系组件的线程模型，不同线程上内存空间和运行组件之间要编组数据，这还可能造成很大的性能损失。在极端情况下，组件驻留在可执行文件中，而不是DLL文件中，还必须创建单独的过程来运行它们。重要的是组件要能与其他组件通信，但仅通过COM运行库进行通信。无论COM是用于允许使用不同语言的组件直接彼此通信，或者创建彼此的实例，系统都把COM作为中间件来处理。不仅如此，COM结构还不允许利用继承实现，即它丧失了面向对象编程的许多优势。

一个相关的问题是，在调试时，仍必须单独调试用不同语言编写的组件。这样就不可能在调试器上调试不同语言的代码了。语言互操作性的真正含义是用一种语言编写的类应能直接与用另一种语言编写的类通信。特别是：

● 用一种语言编写的类应能继承用另一种语言编写的类。

● 一个类应能包含另一个类的实例，而不管它们是使用什么语言编写的。

● 一个对象应能直接调用用其他语言编写的另一个对象的方法。

● 对象(或对象的引用)应能在方法之间传递。

● 在不同的语言之间调用方法时，应能在调试器中调试这些方法调用，即调试不同语言编写的源代码。

这是一个雄心勃勃的目标，但令人惊讶的是，.NET和中间语言已经实现了这个目标。在调试器上调试方法时，Visual Studio .NET IDE提供了这样的工具(不是CLR提供的)。

1.3.2  值类型和引用类型
与其他编程语言一样，中间语言提供了许多预定义的基本数据类型。它的一个特性是值类型和引用类型有明显的区别。对于值类型，变量直接保存其数据，而对于引用类型，变量仅保存地址，对应的数据可以在该地址中找到。

在C++中，引用类型类似于通过指针来访问变量，而在Visual Basic中，与引用类型最相似的是对象，VB6总是通过引用来访问对象。中间语言也有数据存储的规范：引用类型的实例总是存储在一个名为托管堆的内存区域中，值类型一般存储在堆栈中(但如果值类型在引用类型中声明为字段，它们就内联存储在堆中)。第3章讨论堆栈和堆，及其工作原理。

1.3.3  强数据类型
中间语言的一个重要方面是它基于强数据类型。所有的变量都清晰地标记为属于某个特定数据类型(在中间语言中没有Visual Basic和脚本语言识别的Variant数据类型)。特别是中间语言一般不允许对模糊的数据类型执行任何操作。

开发人员习惯于传递变量，而无需担心它们的类型。因为VB6会自动进行所需的类型转换。C++开发人员习惯于在不同类型之间转换指针类型。执行这类操作将大大提高性能，但破坏了类型的安全性。因此，这类操作只能在非常特殊的情况下进行，在某些编译为托管代码的语言中也仅支持非常特殊的情况。确实，指针(相对于引用)只能在标记了的C#代码块中使用，但在VB中不能使用(但一般在托管C++中允许使用)。在代码中使用指针会立即导致CLR提供的内存类型安全性检查失败。

注意，一些与.NET兼容的语言。例如VB.NET，在类型化方面上要求仍比较松，但这是可以的，因为编译器在后台确保在生成的IL上强制类型安全。

尽管强迫实现类型的安全性最初会降低性能，但在许多情况下，我们从.NET提供的、依赖于类型安全的服务中获得的好处更多。这些服务包括：

● 语言的互操作性

● 垃圾收集

● 安全性

● 应用程序域

下面学习讨论强数据类型化对于这些.NET特性非常重要的原因。

1. 语言互操作性中强数据类型的重要性
如果类派生其他类，或包含其他类的实例，它就需要知道其他类使用的所有数据类型，这就是强数据类型非常重要的原因。实际上，过去没有任何认同的系统指定这些信息，从而成为语言继承和交互操作的真正障碍。这类信息不只是在一个标准的可执行文件或DLL中出现。

假定VB.NET类中的一个方法被定义为返回一个整型——VB.NET可以使用的标准数据类型之一。但C#没有该名称的数据类型。显然，我们只能从该类中派生，再使用这个方法，如果编译器知道如何把VB.NET的整型类型映射为C#定义的某种已知类型，就可以在C#代码中使用返回的类型。这个问题在.NET中是如何解决的？

通用类型系统 (CTS)

中使用通用类型系统 (CTS)得到了解决。CTS定义了可以在中间语言中使用的预定义数据类型，所有用于.NET Framework的语言都可以生成最终基于这些类型的编译代码。

例如，VB.NET的整型实际上是一个32位有符号的整数，它实际映射为中间语言类型Int32。因此在中间语言代码中就指定这种数据类型。C#编译器可以使用这种类型，所以就不会有问题了。在源代码中，C#用关键字int来表示Int32，所以编译器就认为VB.NET方法返回一个int类型的值。

通用类型系统不仅指定了基本数据类型，还定义了一个内容丰富的类型层次结构，其中包含设计合理的位置，在这些位置上，代码允许定义它自己的类型。通用类型系统的层次结构反映了中间语言的单一继承的面向对象的方法，如图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 Types              接口
 Pointer Types                指针
 Self-describing Types        为垃圾收集器提供有用信息的数据类型(参见下一节)
 Arrays                       包含对象数组的类型
 Class Types                  可自我描述的类型，但不是数组
 Delegates                    用于把引用包含在方法中的类型
 User-definedReference Types  在源代码中定义，且保存为引用类型的数据类型。在C#中，它表示类
 Boxed Value Types            值类型，临时打包放在一个引用中，以便于存储在堆中
 
这里没有列出内置的值类型，因为将在第2章详细介绍它们。在C#中，编译器识别的每个预定义类型都映射为一个IL内置类型。这与VB.NET是一样的。

公共语言规范(CLS)

，CLS)和通用类型系统一起确保语言的互操作性。CLS是一个最低标准集，所有面向.NET的编译器都必须支持它。因为IL是一种内涵非常丰富的语言，大多数编译器的编写人员有可能把给定编译器的功能限制为只支持IL和CLS提供的一部分特性。只要编译器支持已在CLS中定义的内容，这就是很不错的。

提示：

编写的非CLS兼容代码应该是完全可以接受的，只是编写了这种代码后，就不能保证编译好的IL代码是完全支持语言的互操作性。

下面的一个例子是有关区分大小写字母的。IL是区分大小写的语言。使用这些语言的开发人员常常利用区分大小写所提供的灵活性来选择变量名。但VB.NET是不区分大小写的语言。CLS就要指定CLS兼容代码不使用任何只根据大小写来区分的名称。因此，VB.NET代码可以与CLS兼容代码一起使用。

这个例子说明了CLS的两种工作方式。首先是各个编译器的功能不必强大到支持.NET的所有功能，这将鼓励人们为其他面向.NET的编程语言开发编译器。第二，它提供如下保证：如果限制类只能使用CLS兼容的特性，就要保证用其他语言编写的代码可以使用这个类。

这种方法的优点是使用CLS兼容特性的限制只适用于公共和受保护的类成员和公共类。在类的私有实现方式中，可以编写非CLS代码，因为其他程序集(托管代码的单元，参见本章后面的内容)中的代码不能访问这部分代码。

这里不深入讨论CLS规范。在一般情况下，CLS对C#代码的影响不会太大，因为C#中的非CLS兼容特性非常少。

垃圾收集
中进行内存管理，特别是它可以恢复正在运行中的应用程序需要的内存。到目前为止，Windows平台已经使用了两种技术来释放进程向系统动态请求的内存：

● 完全以手工方式使应用程序代码完成这些工作

● 让对象维护引用计数。

让应用程序代码负责释放内存是低级、高性能的语言使用的技术，例如C++。这种技术很有效，且可以让资源在不需要时就释放(一般情况下)，但其最大的缺点是频繁出现错误。请求内存的代码还必须明确通知系统它什么时候不再需要该内存。但这是很容易被遗漏的，从而导致内存泄漏。

尽管现代的开发环境提供了帮助检测内存泄漏的工具，但它们很难跟踪错误，因为直到内存已大量泄漏从而使Windows拒绝为进程提供资源时，它们才会发挥作用。从这层意义上说，由于对内存的需求，会使整个计算机变得相当慢。

维护引用计数是COM对象采用的一种技术，其方法是每个COM组件都保留一个计数，记录客户机目前对它的引用数。当这个计数下降到0时，组件就会删除自己，并释放相应的内存和资源。它带来的问题是仍需要客户机通知组件它们已经完成了内存的使用。只要有一个客户机没有这么做，对象就仍驻留在内存中。在某些方面，这是比C++内存泄漏更为严重的问题，因为COM对象可能存在于它自己的进程中，从来不会被系统删除(在C++内存泄漏问题上，系统至少可以在进程中断时释放所有的内存)。

.NET运行库采用的方法是垃圾收集器，这是一个程序，其目的是清理内存，方法是所有动态请求的内存都分配到堆上(这对所有的语言都一样，但在.NET中，CLR维护它自己的托管堆，以供.NET应用程序使用)，当.NET检测到给定进程的托管堆已满，需要清理时，就调用垃圾收集器。垃圾收集器处理目前代码中的所有变量，检查对存储在托管堆上的对象的引用，确定哪些对象可以从代码中访问—— 即哪些对象有引用。没有引用的对象就不能再从代码中访问，因而被删除。Java就使用与此类似的垃圾收集器系统。

之所以在.NET中使用垃圾收集器，是因为中间语言已用来处理进程。其规则要求，第一，不能引用已有的对象，除非复制已有的引用。第二，中间语言是类型安全的语言。在这里，其含义是如果存在对对象的任何引用，该引用中就有足够的信息来确定对象的类型。

垃圾收集器机制不能和诸如非托管C++这样的语言一起使用，因为C++允许指针自由地转换数据类型。

垃圾收集器的一个重要方面是它是不确定的。换言之，不能保证什么时候会调用垃圾收集器：.NET运行库决定需要它时，就可以调用它(除非明确调用垃圾收集器)。但可以重写这个过程，在代码中调用垃圾收集器。

安全性
很好地补足了Windows提供的安全机制，因为它提供的安全机制是基于代码的安全性，而Windows仅提供了基于角色的安全性。

基于角色的安全性建立在运行进程的账户的身份基础上，换言之，就是谁拥有和运行进程。另一方面，基于代码的安全性建立在代码实际执行的任务和代码的可信程度上。由于中间语言提供了强大的类型安全性，所以CLR就可以在运行代码前检查它，以确定是否有需要的安全权限。.NET还提供了一种机制，可以在运行代码前指定代码需要什么安全权限。

基于代码的安全性非常重要，原因是它降低了运行怀疑其出处的代码的风险(例如代码是从Internet上下载来的)。即使代码运行在管理员账户下，也有可能使用基于代码的安全性，来确定这段代码是否仍不能执行管理员账户一般允许执行的某些类型的操作，例如读写环境变量、读写注册表或访问.NET反射特性。

安全问题详见本书后面的第14章。

应用程序域
中的一个重要技术改进，它用于减少运行应用程序的系统开销，这些应用程序需要与其他程序分离开来，但同时还需要彼此通信。典型的例子是Web服务器应用程序，它需要同时响应许多浏览器请求。因此，要有许多组件实例同时响应这些同时运行的请求。

在.NET没有开发出来前，可以让这些实例共享同一个进程，但此时一个运行的实例就有可能导致整个网站的崩溃；也可以把这些实例孤立在不同的进程中，但这样做会增加相关性能的系统开销。

到现在为止，孤立代码的惟一方式是通过进程来实现的。在运行一个新的应用程序时，它会在一个进程环境内运行。Windows通过地址空间把进程分隔开来。这样，每个进程有4GB的虚拟内存来存储其数据和可执行代码(4GB对应于32位系统，64位系统要用更多的内存)。Windows利用额外的间接方式把这些虚拟内存映射到物理内存或磁盘空间的一个特殊区域中，每个进程都会有不同的映射，虚拟地址空间块映射的物理内存之间不能有重叠，这种情况如图1-2所示。

 

图  1-2

在一般情况下，任何进程都只能通过指定虚拟内存中的一个地址来访问内存——即进程不能直接访问物理内存，因此一个进程不可能访问分配给另一个进程的内存。这样就可以确保任何执行出错的代码不会损害其地址空间以外的数据(注意在Windows 9x上，这些保护措施不像在NT/2000/XP/2003上那样强大，所以理论上存在应用程序因写入不对应的内存而导致Windows崩溃的可能性)。

进程不仅是运行代码的实例相互隔离的一种方式，在Windows NT/2000/XP/2003系统上，它们还可以构成分配了安全权限和许可的单元。每个进程都有自己的安全标识，明确地表示Windows允许该进程可以执行的操作。

进程对确保安全有很大的帮助，而它们的一大缺点是性能。许多进程常常在一起工作，因此需要相互通信。一个常见的例子是进程调用一个COM组件，而该COM组件是可执行的，因此需要在它自己的进程上运行。在COM中使用代理时也会发生类似的情况。因为进程不能共享任何内存，所以必须使用一个复杂的编组过程在进程之间复制数据。这对性能有非常大的影响。如果需要使组件一起工作，但不希望性能有损失，惟一的方法是使用基于DLL的组件，让所有的组件在同一个地址空间中运行—— 其相关的风险是执行出错的组件会影响其他组件。

应用程序域是分离组件的一种方式，它不会导致因在进程之间传送数据而产生性能问题。其方法是把任何一个进程分解到多个应用程序域中，每个应用程序域大致对应一个应用程序，执行的每个线程都运行在一个具体的应用程序域中，如图1-3所示。

 

图  1-3

如果不同的可执行文件都运行在同一个进程空间中，显然它们就能轻松地共享数据，因为理论上它们可以直接访问彼此的数据。虽然在理论上这是可以实现的，但是CLR会检查每个正在运行的应用程序的代码，以确保这些代码不偏离它自己的数据区域，保证不发生直接访问其他进程的数据的情况。这初看起来是不可能的，如何告诉程序要做什么工作，而又不真正运   行它？

实际上，这么做通常是可能的，因为中间语言拥有强大的类型安全功能。在大多数情况下，除非代码明确使用不安全的特性，例如指针，否则它使用的数据类型可以确保内存不会被错误地访问。例如，.NET数组类型执行边界检查，以禁止执行超出边界的数组操作。如果运行的应用程序的确需要与运行在不同应用程序域中的其他应用程序通信或共享数据，就必须调用.NET的远程服务。

被验证不能访问超出其应用程序域的数据(而不是通过明确的远程机制)的代码就是内存类型安全的代码，这种代码与运行在同一个进程中但应用程序域不同的类型安全代码一起运行是安全的。

1.3.4  通过异常处理错误
可以根据异常使用相同的机制处理错误情况，这与Java和C++是一样的。C++开发人员应注意到，由于IL有非常强大的类型系统，所以在IL中以C++的方式使用异常不会带来相关的性能问题。另外，.NET和C#也支持finally块，这是许多C++开发人员长久以来的愿望。

第11章会详细讨论异常。简要地说，代码的某些领域被看作是异常处理程序例程，每个例程都能处理某种特殊的错误情况(例如，找不到文件，或拒绝执行某些操作的许可)。这些条件可以定义得很宽或很窄。异常结构确保在发生错误情况时，执行进程立即跳到异常处理程序例程上，处理有问题的错误情况。

异常处理的结构还提供了一种方便的方式，当对象包含错误情况的准确信息时，该对象就可以传送给错误处理例程。这个对象包括给用户提供的相应信息和在代码的什么地方检测到错误的确切信息。

大多数异常处理结构，包括异常发生时的程序流控制，都是由高级语言处理的，例如C#、VB.NET和C++，任何中间语言命令都不支持它。例如，C#使用try{}、catch{}和 finally{}代码块来处理它，详见第11章。

.NET提供了一种基础结构，让面向.NET的编译器支持异常处理。特别是它提供了一组.NET类来表示异常，语言的互操作性则允许抛出被错误处理代码解释的异常对象，无论错误处理代码使用什么语言编写都是这样。语言的无关性没有体现在C++和Java的异常处理实现中，但在COM的错误处理机制中有一定限度的体现。COM的错误处理机制包括从方法中返回错误代码以及传递错误对象。在不同语言中，错误的处理是一致的，这是多语言开发的重要一环。

1.3.5  特性的使用
是使用C++编写COM组件的开发人员很熟悉的一个功能(使用Microsoft的COM接口定义语言(IDL))。特性最初是为了在程序中提供与某些项目相关的外部信息，以供编译器使用。

.NET支持特性，因此现在C++、C#和VB.NET也支持特性。但在.NET中，对特性的革新是建立了一个机制，通过该机制可以在源代码中定义自己的特性。这些用户定义的特性将和对应数据类型或方法的元数据放在一起，这对于文档说明书十分有用，它们和反射技术一起使用，以根据特性执行编程任务。另外，与.NET的语言无关性的基本原理一样，特性也可以在一种语言的源代码中定义，而被用另一种语言编写的代码读取。

本书的第10章详细介绍了特性。
 
1.4 程序集
（ 本章字数：5180 更新时间：2007-4-26 19:08:17 ）

 
 是包含编译好的、面向.NET Framework的代码的逻辑单元。本章不详细论述程序集，而在第13章中论述，下面概述其中的要点。

程序集是完全自我描述性的，也是一个逻辑单元而不是物理单元，它可以存储在多个文件中(动态程序集的确存储在内存中，而不是存储在文件中)。如果一个程序集存储在多个文件中，其中就会有一个包含入口点的主文件，该文件描述了程序集中的其他文件。

注意可执行代码和库代码使用相同的程序集结构。惟一的区别是可执行的程序集包含一个主程序入口点，而库程序集则不包含。

程序集的一个重要特性是它们包含的元数据描述了对应代码中定义的类型和方法。程序集也包含描述程序集本身的元数据，这种程序集元数据包含在一个称为程序集清单的区域中，可以检查程序集的版本及其完整性。

注意：

ildasm是一个基于Windows的实用程序，可以用于检查程序集的内容，包括程序集清单和元数据。第13章将介绍ildasm。

程序集包含程序的元数据，表示调用给定程序集中的代码的应用程序或其他程序集不需要指定注册表或其他数据源，以便确定如何使用该程序集。这与以前的COM有很大的不同，以前，组件的GUID和接口必须从注册表中获取，在某些情况下，方法和属性的详细信息也需要从类型库中读取。

把数据分散在3个以上的不同位置上，可能会出现信息不同步的情况，从而妨碍其他软件成功地使用该组件。有了程序集后，就不会发生这种情况，因为所有的元数据都与程序的可执行指令存储在一起。注意，即使程序集存储在几个文件中，数据也不会出现不同步的问题。这是因为包含程序集入口的文件也存储了其他文件的细节、散列和内容，如果一个文件被替换，或者被塞满，系统肯定会检测出来，并拒绝加载程序集。

程序集有两种类型：共享程序集和私有程序集。

1.4.1  私有程序集
 

系统可以保证，私有程序集不被其他软件使用，因为应用程序只能加载位于主执行文件所在文件夹或其子文件夹中的程序集。

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

因为私有程序集完全是自含式的，所以安装它的过程就很简单。只需把相应的文件放在文件系统的对应文件夹中即可(不需要注册表项)，这个过程称为“0影响(xcopy)安装”。

1.4.2  共享程序集
 

● 名称冲突，另一个公司的共享程序集执行的类型与自己的共享程序集同名。因为客户机代码理论上可以同时访问这些程序集，所以这是一个严重的问题。

● 程序集被同一个程序集的不同版本覆盖——新版本与某些已有的客户机代码不兼容。

这些问题的解决方法是把共享程序集放在文件系统的一个特定的子目录树中，称为全局程序集缓冲区(GAC)。与私有程序集不同，不能简单地把共享程序集复制到对应的文件夹中，而需要专门安装到缓冲区中，这个过程可以用许多.NET工具来完成，其中包含对程序集的检查、在程序集缓冲区中设置一个小的文件夹层次结构，以确保程序集的完整性。

为了避免名称冲突，共享程序集应根据私有密钥加密法指定一个名称(私有程序集只需要指定与其主文件名相同的名称即可)。该名称称为强名(strong name)，并保证其惟一性，它必须由要引用共享程序集的应用程序来引用。

与覆盖程序集相关的问题，可以通过在程序集清单中指定版本信息来解决，也可以通过同时安装来解决。

1.4.3  反射
章详细介绍了它们。该技术很有趣，因为它表示托管代码实际上可以检查其他托管代码，甚至检查它自己，以确定该代码的信息。它们常常用于获取特性的详细信息，也可以把反射用于其他目的，例如作为实例化类或调用方法的一种间接方式，如果把方法上的类名指定为字符串，就可以选择类来实例化方法，以便在运行时调用，而不是在编译时调用，例如根据用户的输入来调用(动态绑定)。

 
1.5 .NET Framework类
（ 本章字数：10538 更新时间：2007-4-26 19:08:17 ）

 
 至少从开发人员的角度来看，编写托管代码的最大好处是可以使用.NET基类库。

.NET基类是一个内容丰富的托管代码类集合，它可以完成以前要通过Windows API来完成的绝大多数任务。这些类派生于与中间语言相同的对象模型，也基于单一继承性。无论.NET基类是否合适，都可以实例化对象，也可以从它们派生自己的类。

.NET基类的一个优点是它们非常直观和易用。例如，要启动一个线程，可以调用Thread类的Start()方法。要禁用TextBox，应把TextBox对象的Enabled属性设置为false。Visual Basic和Java开发人员非常熟悉这种方式。它们的库都很容易使用，但对于C++开发人员来说这是极大的解脱，因为他们多年来一直在使用诸如GetDIBits()、RegisterWndClassEx()和IsEqualIID()这样的API函数，以及需要传递Windows句柄的函数。

另一方面，C++开发人员总是很容易访问整个Windows API，而Visual Basic 6和Java开发人员只能访问其语言所能访问的基本操作系统功能。.NET基类的新增内容就是把Visual Basic和Java库的易用性和Windows API函数的丰富功能结合起来。但Windows仍有许多功能不能通过基类来使用，而需要调用API函数。在日常的使用中，会发现基类非常丰富。如果需要调用API函数，.NET提供了所谓的“平台调用”，来确保对数据类型进行正确的转换，这样无论是使用C#、C++或VB.NET进行编码，该任务都不会比直接从已有的C++代码中调用函数更困难。

注意：

WinCV是一个基于Windows的实用程序，可以用于浏览基类库中的类、结构、接口和枚举。本书将在第12章介绍WinCV。

第3章主要介绍基类。完成了C#语言语法的概述后，本书的其余内容将主要说明如何在.NET基类库中使用各种类，即各种基类是如何工作的。.NET基类包括：

● IL提供的核心功能，例如，通用类型系统中的基本数据类型，详见第3章。

● Windows GUI支持和控件(第19章)

● Web窗体 (ASP.NET，第25-27章)

● 数据访问 (ADO.NET，第21-22章)

● 目录访问(第24章)

● 文件系统和注册表访问(第30章)

● 网络和Web浏览(第31章)

● .NET特性和反射(第10章)

● 访问Windows操作系统的各个方面(例如环境变量等，第14章)

● COM互操作性(第28和29章)

附带说一下，根据Microsoft源文件，大部分.NET基类实际上都是用C#编写的！

 
避免类名冲突的一种方式。例如，命名空间可以避免下述情况：定义一个类来表示一个顾客，称此类为Customer，同时其他人也在做相同的事(这有一个类似的场景——顾客有相当多的业务)。

命名空间不过是一组数据类型，但命名空间中所有数据类型的名称都会自动加上该命名空间的名字作为其前缀。命名空间还可以相互嵌套。例如，大多数用于一般目的的.NET基类位于命名空间System中，基类Array在这个命名空间中，所以其全名是System.Array。

.NET需要在命名空间中定义所有的类型，例如，可以把Customer类放在命名空间YourCompanyName中，则这个类的全名就是YourCompanyName.Customer。

注意：

如果没有显式提供命名空间，类型就添加到一个没有名称的全局命名空间中。

Microsoft建议在大多数情况下，都至少要提供两个嵌套的命名空间名，第一个是公司名，第二个是技术名称或软件包的名称，而类是其中的一个成员，例如YourCompanyName.Sales Services.Customer。在大多数情况下，这么做可以保证类的名称不会与其他组织编写的类名冲突。

第2章将详细介绍命名空间。

 
1.6 用C#创建.NET应用程序
（ 本章字数：22966 更新时间：2007-4-26 19:08:17 ）

 
 可以用于创建控制台应用程序：仅使用文本、运行在DOS窗口中的应用程序。在进行单元测试类库、创建Unix/Linux daemon进程时，就要使用控制台应用程序。但是，我们常常使用C#创建利用许多与.NET相关的技术的应用程序，下面简要论述可以用C#创建的不同类型的应用程序。

1.6.1  创建ASP.NET应用程序
ASP是用于创建带有动态内容的Web页面的一种Microsoft技术。ASP页面基本是一个嵌有服务器端VBScript或JavaScript代码块的HTML文件。当客户浏览器请求一个ASP页面时，Web服务器就会发送页面的HTML部分，并处理服务器端脚本。这些脚本通常会查询数据库的数据，在HTML中标记数据。ASP是客户建立基于浏览器的应用程序的一种便利方式。

也有缺点。首先，ASP页面有时显示得比较慢，因为服务器端代码是解释性的，而不是编译的。第二，ASP文件很难维护，因为它不是结构化的，服务器端的ASP代码和一般的HTML会混合在一起。第三，ASP有时开发起来会比较困难，因为它不支持错误处理和语法检查。特别是如果使用VBScript，并希望在页面中进行错误处理，就必须使用On Error Resume Next语句，通过Err.Number检查调用每个组件，以确保该调用正常进行。

ASP.NET是ASP的修订版本，它解决了ASP的许多问题。但ASP.NET页面并没有替代ASP，而是可以与原来的ASP应用程序在同一个服务器上同时并存。当然，也可以用C#编写ASP.NET。

后面的章节(第25-27章)会详细讨论ASP.NET，这里仅解释它的一些重要特性。

1. ASP.NET的特性
首先，也是最重要的是，ASP.NET页面是结构化的。这就是说，每个页面都是一个继承了.NET类System.Web.UI.Page的类，可以重写在Page对象的生存期中调用的一系列方法， (可以把这些事件看成是页面所特有的，对应于原ASP的global.asa文件中的OnApplication_Start 和OnSession_Start事件)。因为可以把一个页面的功能放在有明确含义的事件处理程序中，所以ASP.NET比较容易理解。

ASP.NET页面的另一个优点是可以在VS.NET中创建它们，在该环境下，可以创建ASP.NET页面使用的业务逻辑和数据访问组件。VS.NET项目组(也称为解决方案)包含了与应用程序相关的所有文件。而且，也可以在编辑器中调试传统的ASP页面，在以前使用Visual InterDev时，把InterDev和项目的Web服务器配置为支持调试常常是一个让人头痛的问题。

最清楚的是，ASP.NET的后台编码功能允许进一步采用结构化的方式。ASP.NET允许把页面的服务器端功能单独放在一个类中，把该类编译为DLL，并把该DLL放在HTML部分下面的一个目录中。放在页面顶部的后台编码指令将把该文件与其DLL关联起来。当浏览器请求该页面时，Web服务器就会在页面的后台DLL中引发类中的事件。

 最后ASP.NET在性能的提高上非常明显。传统的ASP页面是和每个页面请求一起进行解释，而Web服务器是在编译后高速缓存ASP.NET页面。这表示以后对ASP.NET页面的请求就比ASP页面的执行速度快得多。

ASP.NET还易于编写通过浏览器显示窗体的页面，这在内部网环境中会使用。传统的方式是基于窗体的应用程序提供一个功能丰富的用户界面，但较难维护，因为它们运行在非常多的不同机器上。因此，当用户界面是必不可少的，并可以为用户提供支持扩展时，人们就会依赖于基于窗体的应用程序。

但随着Internet Explorer 5的出现，而Navigator 6的性能乏善可陈时，基于窗体的应用程序的优点就非常突出了。IE 5对DHTML的健全的支持，允许程序员创建基于Web的应用程序，这些应用程序都能很好地对应于其客户端程序。当然，这种应用程序需要在IE上进行标准化，而不支持Navigator。在许多行业中，这种标准化现在是很常见的。

2. Web窗体
页面的结构，Visual Studio .NET提供了Web窗体。它们允许以创建VB6或 C++ Builder窗口的方式图形化地建立ASP.NET页面；换言之，就是把控件从工具箱拖放到窗体上，再考虑窗体的代码，为控件编写事件处理程序。在使用C#创建Web窗体时，就是创建一个继承于Page 基类的C#类，以及把这个类看做是后台编码的ASP.NET页面。当然不必使用C#创建Web窗体，而可以使用VB.NET或另一种.NET语言来创建。

过去，Web开发的困难使一些开发小组不愿意使用Web。为了成功地进行Web开发，必须了解非常多的不同技术，例如VBScript、ASP、DHTML、JavaScript等。把窗体概念应用于Web页面，Web窗体就可以使Web开发容易许多。

Web控件

窗体上的控件与ActiveX控件并不是同一种控件，它们是ASP.NET命名空间中的XML标记，当请求一个页面时，Web浏览器会动态地把它们转换为HTML和客户端脚本。Web服务器能以不同的方式显示相同的服务器端控件，产生一个对应于请求者特定Web浏览器的转换。这意味着现在很容易为Web页面编写相当复杂的用户界面，而不必担心如何确保页面运行在可用的任何浏览器上，因为Web窗体会完成这些任务。

可以使用C#或VB.NET扩展Web窗体工具箱。创建一个新服务器端控件，仅是执行.NET的System.Web.UI.WebControls.WebControl类而已。

3. XML Web服务
页面解决了World Wide Web上的大部分通信问题。有了XML，计算机就可以用一种独立于设备的格式，在Web上彼此通信。将来，计算机可以使用Web和XML交流信息，而不是专用的格式，例如EDI (Electronic Data Interchange)。XML Web服务是为面向Web的服务而设计的，即远程计算机彼此提供可以分析和重新格式化的动态信息，最后显示给用户。XML Web服务是计算机给Web上的其他计算机以XML格式显示信息的一种便利方式。

在技术上，.NET上的XML Web服务是给请求的客户返回XML而不是HTML的ASP.NET页面。这种页面有后台编码的DLL，它包含了派生自WebService类的类。VS.NET IDE提供的引擎简化了Web服务的开发。

公司选择使用XML Web服务主要有两个原因。第一是因为它们依赖于HTTP，而XML Web服务可以把现有的网络用作传输信息的媒介。第二是因为XML Web服务使用XML，该数据格式是自我描述的、非专用的、独立于平台的。

1.6.2  创建Windows窗体
和 .NET非常适合于Web开发，它们还为所谓的“胖客户端”应用程序提供了极好的支持，这种“胖客户端”应用程序必须安装在处理大多数操作的最终用户的机器上，这种支持来源于Windows窗体。

Windows窗体是VB6窗体的.NET版本，要设计一个图形化的窗口界面，只需把控件从工具箱拖放到Windows窗体上即可。要确定窗口的行为，应为该窗体的控件编写事件处理例程。Windows Form项目编译为.EXE，该EXE必须与.NET运行库一起安装在最终用户的计算机上。与其他.NET项目类型一样，VB.NET 和 C#都支持Windows Form项目。第7章将详细介绍Windows窗体。

Windows控件
Web窗体和Windows窗体的开发方式一样，但应为它们添加不同类型的控件。Web窗体使用Web控件，Windows窗体使用Windows控件。

Windows控件比较类似于ActiveX控件。在执行Windows控件后，它会编译为必须安装到客户机器上的DLL。实际上，.NET SDK提供了一个实用程序，为ActiveX控件创建包装器，以便把它们放在Windows窗体上。与Web控件一样，Windows控件的创建需要派生于特定的类System.Windows.Forms.Control。

1.6.3  Windows服务
 Windows服务(最初称为NT服务)是一个在Windows NT/2000/XP/2003 (但没有Windows 9x)后台运行的程序。当希望程序连续运行，响应事件，但没有用户的明确启动操作时，就应使用Windows服务。例如Web服务器上的World Wide Web服务，它们监听来自客户的Web 请求。

用C#编写服务是非常简单的。System.ServiceProcess命名空间中的.NET Framework基类可以处理许多与服务相关的样本任务，另外，Visual Studio .NET允许创建C# Windows Service项目，为基本Windows服务编写Framework C#源代码。第32章将详细介绍如何编写C# Windows服务。

 
1.7 C#在.NET企业体系结构中的作用
（ 本章字数：6863 更新时间：2007-4-26 19:08:17 ）

 
 C#要求在.NET运行库出现后，在几年内大多数客户机-—— 特别是大多数家用PC—— 就可以安装.NET了。而且，安装C#应用程序在方式上类似于安装.NET可重新分布的组件。因此，企业环境中会有许多C#应用程序。实际上，C#为希望建立健全的n层客户机/服务器应用程序的公司提供了一个绝佳的机会。

C#与ADO.NET合并后，就可以快速而经常地访问数据库了，例如SQL Server 和 Oracle数据库。返回的数据集很容易通过ADO.NET对象模型来处理，并自动显示为XML，一般通过办公室内部网来传输。

一旦为新项目建立了数据库模式，C#就会为执行一层数据访问对象提供一个极好的媒介，每个对象都能提供对不同的数据库表的插入、更新和删除访问。

因为这是第一个基于组件的C语言，所以C#非常适合于执行业务对象层。它为组件之间的通信封装了杂乱的信息，让开发人员把注意力集中在把数据访问对象组合在一起，在方法中精确地强制执行公司的业务规则。而且使用特性，C#业务对象可以配备方法级的安全检查、对象池和由COM+服务提供的JIT活动。而且，.NET附带的实用程序允许新的.NET业务对象与原来的COM组件交互。

要使用C#创建企业应用程序，可以为数据访问对象创建一个Class Library项目，为业务对象创建另一个Class Library项目。在开发时，可以使用Console项目测试类上的方法。喜欢编程的人可以建立能自动从批处理文件中执行的Console项目，测试工作代码是否中断。

注意，C# 和 .NET都会影响物理封装可重用类的方式。过去，许多开发人员把许多类放在一个物理组件中，因为这样安排会使部署容易得多；如果有版本冲突问题，就知道在何处进行检查。因为部署.NET企业组合仅是把文件复制到目录中，所以现在开发人员就可以把他们的类封装到逻辑性更高的离散组件中，而不会遇到DLL Hell。

最后但并非最不重要的是，用C#编写的ASP.NET页面构成了用户界面的绝妙媒介。ASP.NET页面是编译过的，所以执行得比较快。它们可以在VS.NET IDE中调试，所以更加健壮。它们支持所有的语言特性，例如早期绑定、继承和模块化，所以用C#编写的ASP.NET页面是很整洁的，很容易维护。

经验丰富的开发人员对大做广告的新技术和语言都持非常怀疑的态度，不愿意利用新平台，这仅仅是因为他们不愿意。如果读者是一位IT部门的企业开发人员，或者通过World Wide Web提供应用程序服务，即使一些比较奇异的特性如XML Web服务和服务器端控件不算在内，也可以确保C#和.NET至少提供了四个优点：

● 组件冲突将很少见，部署工作将更容易，因为同一组件的不同版本可以在同一台机器上并行运行，而不会发生冲突。

● ASP代码不再很难读懂。

● 可以在.NET基类中使用许多功能。

● 对于需要Windows窗体用户界面的应用程序来说，利用C#可以很容易编写这类应用 程序。

在某种程度上，以前Windows窗体并未受到重视，因为没有Web窗体和基于Internet的应用程序。但如果用户缺乏JavaScript、ASP或相关技术的专业知识，Windows窗体仍是方便而快速地创建用户界面的一种可行选择。记住管理好代码，使用户界面的逻辑与业务逻辑和数据访问代码分隔开来。这样才能在将来的某一刻把应用程序迁移到浏览器上。另外，Windows窗体还为家用应用程序和一些小公司长期保留了重要的用户界面。