C#高级编程笔记--.Net体系结构

● 对这些内容进行概述之后，就要详细阐述Microsoft中间语言(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#是一种相当新的编程语言，C#的重要性体现在以下两个方面：

● 它是专门为与Microsoft的.NET Framework一起使用而设计的。(.NET Framework是一个功能非常丰富的平台，可开发、部署和执行分布式应用程序)。

● 它是一种基于现代面向对象设计方法的语言，在设计它时，Microsoft还吸取了其他类似语言的经验，这些语言是近20年来面向对象规则得到广泛应用后才开发出来的。

有一个很重要的问题要弄明白：C#就其本身而言只是一种语言，尽管它是用于生成面向.NET环境的代码，但它本身不是.NET的一部分。.NET支持的一些特性，C#并不支持。而C#语言支持的另一些特性，.NET却不支持(例如运算符重载)！

但是，因为C#语言是和.NET一起使用的，所以如果要使用C#高效地开发应用程序，理解Framework就非常重要。

1.2 公共语言运行库

.NET Framework的核心是其运行库的执行环境，称为公共语言运行库(CLR)或.NET运行库。通常将在CLR的控制下运行的代码称为托管代码(managed code)。

但是，在CLR执行编写好的源代码之前，需要编译它们(在C#中或其他语言中)。在.NET中，编译分为两个阶段：

(1) 把源代码编译为Microsoft中间语言(IL)。

(2) CLR把IL编译为平台专用的代码。

这个两阶段的编译过程非常重要，因为Microsoft中间语言(托管代码)是提供.NET的许多优点的关键。

Microsoft中间语言与Java字节代码共享一种理念：它们都是低级语言，语法很简单(使用数字代码，而不是文本代码)，可以非常快速地转换为内部机器码。对于代码来说，这种精心设计的通用语法有很重要的优点：平台无关性、提高性能和语言的互操作性。

1.2.1 平台无关性

首先，这意味着包含字节代码指令的同一文件可以放在任一平台中，运行时编译过程的最后阶段可以很容易完成，这样代码就可以运行在特定的平台上。换言之，编译为中间语言就可以获得.NET平台无关性，这与编译为Java字节代码就会得到Java平台无关性是一样的。

注意.NET的平台无关性目前只是一种可能，因为在编写本书时，.NET只能用于Windows平台，但人们正在积极准备，使它可以用于其他平台(参见Mono项目，它用于实现.NET的开放源代码，参见http://www.go-mono.com/)。

1.2.2 提高性能

前面把IL和Java做了比较，实际上，IL比Java字节代码的作用还要大。IL总是即时编译的(称为JIT编译)，而Java字节代码常常是解释性的，Java的一个缺点是，在运行应用程序时，把Java字节代码转换为内部可执行代码的过程会导致性能的损失(但在最近，Java在某些平台上能进行JIT编译)。

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

1.2.3 语言的互操作性

使用IL不仅支持平台无关性，还支持语言的互操作性。简而言之，就是能将任何一种语言编译为中间代码，编译好的代码可以与从其他语言编译过来的代码进行交互操作。

那么除了C#之外，还有什么语言可以通过.NET进行交互操作呢？下面就简要讨论其他常见语言如何与.NET交互操作。

1.Visual C++ 2008

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

#using <mscorlib.dll>

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

class MyClass

{

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

_ref class MyClass

{

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

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

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

1.3 中间语言

如前所述，Microsoft中间语言显然在.NET Framework中有非常重要的作用。C#开发人员应明白，C#代码在执行前要编译为中间语言(实际上，C#编译器仅编译为托管代码)，这是有意义的，现在应详细讨论一下IL的主要特征，因为面向.NET的所有语言在逻辑上都需要支持IL的主要特征。

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

● 面向对象和使用接口

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

● 强数据类型

● 使用异常来处理错误

● 使用特性(attribute)

下面详细讨论这些特征。

1.3.1 面向对象和接口的支持

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

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

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

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

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

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

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

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

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

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

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

1.3.2 相异值类型和引用类型

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

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

1.3.3 强数据类型

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

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

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

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

● 语言的互操作性

● 垃圾收集

● 安全性

● 应用程序域

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

1. 语言互操作性中强数据类型的重要性

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

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

(1) 通用类型系统(CTS)

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

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

通用类型系统不仅指定了基本数据类型，还定义了一个内容丰富的类型层次结构，其中包含设计合理的位置，在这些位置上，代码允许定义它自己的类型。通用类型系统的层次结构反映了中间语言的单一继承的面向对象方法。在C#中，编译器识别的每个预定义类型都映射为一个IL内置类型。

(2) 公共语言规范(CLS)

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

提示：

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

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

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

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

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

2. 垃圾收集

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

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

● 让对象维护引用计数。

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

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

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

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

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

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

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

3. 安全性

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

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

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

4. 应用程序域

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

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

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

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

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

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

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

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

图 1-3

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

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

1.3.4 通过异常处理错误

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

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

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

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

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

1.3.5 特性的使用

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

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

1.4 程序集

程序集(assembly)是包含编译好的、面向.NET Framework的代码的逻辑单元。下面概述其中的要点。

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

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

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

注意：

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

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

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

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

1.4.1 私有程序集

私有程序集是最简单的一种程序集类型。私有程序集一般附带在某个软件上，且只能用于该软件。附带私有程序集的常见情况是，以可执行文件或许多库的方式提供应用程序，这些库包含的代码只能用于该应用程序。

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

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

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

1.4.2 共享程序集

共享程序集是其他应用程序可以使用的公共库。因为其他软件可以访问共享程序集，所以需要采取一定的保护措施来防止以下风险：

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

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

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

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

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

1.4.3 反射

因为程序集存储了元数据，包括在程序集中定义的所有类型和这些类型的成员的细节，所以可以编程访问这些元数据。这个技术称为反射，第13章详细介绍了它们。该技术很有趣，因为它表示托管代码实际上可以检查其他托管代码，甚至检查它自己，以确定该代码的信息。它们常常用于获取特性的详细信息，也可以把反射用于其他目的，例如作为实例化类或调用方法的一种间接方式，如果把方法上的类名指定为字符串，就可以选择类来实例化方法，以便在运行时调用，而不是在编译时调用，例如根据用户的输入来调用(动态绑定)。

1.5 .NET Framework类

至少从开发人员的角度来看，编写托管代码的最大好处是可以使用.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++或Visual Basic 2008进行编码，该任务都不会比直接从已有的C++代码中调用函数更困难。

.NET 3.5基类包括：

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

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

● Web窗体(ASP.NET，第37和38章)

● 数据访问(ADO.NET，第26～30章)

● 目录访问(第46章)

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

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

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

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

● COM互操作性(第44和24章)

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

1.6 命名空间

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

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

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

注意：

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

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

1.7 用C#创建.NET应用程序

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

1.7.1 创建ASP.NET应用程序

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

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

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

1. ASP.NET的特性

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

ASP.NET页面的另一个优点是可以在Visual Studio 2008中创建它们，在该环境下，可以创建ASP.NET页面使用的业务逻辑和数据访问组件。Visual Studio 2008项目(也称为解决方案)包含了与应用程序相关的所有文件。而且，也可以在编辑器中调试传统的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还易于编写通过浏览器显示窗体的页面，这在内联网环境中会使用。传统的方式是基于窗体的应用程序提供一个功能丰富的用户界面，但较难维护，因为它们运行在非常多的不同机器上。因此，当用户界面是必不可少的，并可以为用户提供扩展支持时，人们就会依赖基于窗体的应用程序。

2. Web窗体

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

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

3. Web服务器控件

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

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

4. XML Web服务

目前，HTML页面解决了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类的类。Visual Studio 2008 IDE提供的引擎简化了Web服务的开发。

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

1.7.2 创建Windows窗体

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

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

1.7.3 使用Windows Presentation Foundation(WPF)

有一种最新的技术叫做Windows Presentation Foundation(WPF)。WPF在建立应用程序时使用XAML。XAML表示可扩展的应用程序标记语言(Extensible Application Markup Language)。这种在Microsoft环境下创建应用程序的新方式在2006年引入，是.NET Framework 3.0和3.5的一部分。要运行WPF应用程序，需要在客户机上安装.NET Framework 3.0或3.5。WPF应用程序可用于Windows Vista、Windows XP、Windows Server 2003和Windows Server 2008 (只有这些操作系统能安装.NET Framework 3.0或3.5)。

XAML是用于创建窗体的XML声明，它代表WPF应用程序的所有可视化部分和操作。虽然可以编程利用WPF应用程序，但WPF是迈向声明性编程的一步，而声明性编程是编程业的趋势。声明性编程是指，不是利用编译语言，如C#、VB或Java，通过编程来创建对象，而是通过XML类型的编程来声明所有的元素。

1.7.4 Windows控件

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

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

1.7.5 Windows服务

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

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

1.7.6 Windows Communication Foundation(WCF)

通过基于Microsoft的技术，可以采用许多方式将数据和服务从一处移动到另一处。例如，可以使用ASP.NET Web服务、.NET Remoting、Enterprise Services和用于初学者的MSMQ。应采用哪种技术？这要考虑具体要达到的目标，因为每种技术都适合于不同的场合。

因此，Microsoft把所有这些技术集成在一起，放在.NET Framework 3.0和3.5中。现在只有一种移动数据的方式—— Windows Communication Foundation(WCF)。WCF允许建立好服务后，只要修改配置文件，就可以用多种方式提供该服务(甚至在不同的协议下)。WCF是一种连接各种系统的强大的新方式。

1.8 C#在.NET企业体系结构中的作用

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

C#与ADO.NET合并后，就可以快速而经常地访问数据库了，例如SQL Server和Oracle数据库。返回的数据集很容易通过ADO.NET对象模型或LINQ来处理，并自动显示为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页面是编译过的，所以执行得比较快。它们可以在Visual Studio 2008 IDE中调试，所以更加健壮。它们支持所有的语言特性，例如早期绑定、继承和模块化，所以用C#编写的ASP.NET页面是很整洁的，很容易维护。

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

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

● ASP.NET代码不再难懂。

● 可以利用.NET基类中的许多功能。

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

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