.NET Framwork 1.0-3.0概述

.NET Framework 概念概述

.NET Framework 是支持生成和运行下一代应用程序和 XML Web Services 的内部 Windows 组件。.NET Framework 旨在实现下列目标：

• 提供一个一致的面向对象的编程环境，而无论对象代码是在本地存储和执行，还是在本地执行但在 Internet 上分布，或者是在远程执行的。

• 提供一个将软件部署和版本控制冲突最小化的代码执行环境。

• 提供一个可提高代码（包括由未知的或不完全受信任的第三方创建的代码）执行安全性的代码执行环境。

• 提供一个可消除脚本环境或解释环境的性能问题的代码执行环境。

• 使开发人员的经验在面对类型大不相同的应用程序（如基于 Windows 的应用程序和基于 Web 的应用程序）时保持一致。

• 按照工业标准生成所有通信，以确保基于 .NET Framework 的代码可与任何其他代码集成。

.NET Framework 具有两个主要组件：公共语言运行库和 .NET Framework 类库。公共语言运行库是 .NET Framework 的基础。您可以将运行库看作一个在执行时管理代码的代理，它提供内存管理、线程管理和远程处理等核心服务，并且还强制实施严格的类型安全以及可提高安全性和可靠性的其他形式的代码准确性。事实上，代码管理的概念是运行库的基本原则。以运行库为目标的代码称为托管代码，而不以运行库为目标的代码称为非托管代码。.NET Framework 的另一个主要组件是类库，它是一个综合性的面向对象的可重用类型集合，您可以使用它开发多种应用程序，这些应用程序包括传统的命令行或图形用户界面 (GUI) 应用程序，也包括基于 ASP.NET 所提供的最新创新的应用程序（如 Web 窗体和 XML Web Services）。

.NET Framework 可由非托管组件承载，这些组件将公共语言运行库加载到它们的进程中并启动托管代码的执行，从而创建一个可以同时利用托管和非托管功能的软件环境。.NET Framework 不但提供若干个运行库宿主，而且还支持第三方运行库宿主的开发。

例如，ASP.NET 承载运行库以为托管代码提供可伸缩的服务器端环境。ASP.NET 直接使用运行库以启用 ASP.NET 应用程序和 XML Web Services（本主题稍后将对这两者进行讨论）。

Internet Explorer 是承载运行库（以 MIME 类型扩展的形式）的非托管应用程序的一个示例。使用 Internet Explorer 承载运行库使您能够在 HTML 文档中嵌入托管组件或 Windows 窗体控件。以这种方式承载运行库使得托管移动代码（类似于 Microsoft® ActiveX® 控件）成为可能，不过它需要进行重大改进（如不完全受信任的执行和独立的文件存储），而这种改进只有托管代码才能提供。

下面的插图显示公共语言运行库和类库与应用程序之间以及与整个系统之间的关系。该插图还显示托管代码如何在更大的结构内运行。

.NET Framework 环境

 

下面的章节将更加详细地描述 .NET Framework 的主要组件和功能。

公共语言运行库的功能

公共语言运行库管理内存、线程执行、代码执行、代码安全验证、编译以及其他系统服务。这些功能是在公共语言运行库上运行的托管代码所固有的。

至于安全性，取决于包括托管组件的来源（如 Internet、企业网络或本地计算机）在内的一些因素，托管组件被赋予不同程度的信任。这意味着即使用在同一活动应用程序中，托管组件既可能能够执行文件访问操作、注册表访问操作或其他须小心使用的功能，也可能不能够执行这些功能。

运行库强制实施代码访问安全。例如，用户可以相信嵌入在网页中的可执行文件能够在屏幕上播放动画或唱歌，但不能访问他们的个人数据、文件系统或网络。这样，运行库的安全性功能就使通过 Internet 部署的合法软件能够具有特别丰富的功能。

运行库还通过实现称为通用类型系统 (CTS) 的严格类型验证和代码验证基础结构来加强代码可靠性。CTS 确保所有托管代码都是可以自我描述的。各种 Microsoft 和第三方语言编译器生成符合 CTS 的托管代码。这意味着托管代码可在严格实施类型保真和类型安全的同时使用其他托管类型和实例。

此外，运行库的托管环境还消除了许多常见的软件问题。例如，运行库自动处理对象布局并管理对对象的引用，在不再使用它们时将它们释放。这种自动内存管理解决了两个最常见的应用程序错误：内存泄漏和无效内存引用。

运行库还提高了开发人员的工作效率。例如，程序员可以用他们选择的开发语言编写应用程序，却仍能充分利用其他开发人员用其他语言编写的运行库、类库和组件。任何选择以运行库为目标的编译器供应商都可以这样做。以 .NET Framework 为目标的语言编译器使得用该语言编写的现有代码可以使用 .NET Framework 的功能，这大大减轻了现有应用程序的迁移过程的工作负担。

尽管运行库是为未来的软件设计的，但是它也支持现在和以前的软件。托管和非托管代码之间的互操作性使开发人员能够继续使用所需的 COM 组件和 DLL。

运行库旨在增强性能。尽管公共语言运行库提供许多标准运行库服务，但是它从不解释托管代码。一种称为实时 (JIT) 编译的功能使所有托管代码能够以它在其上执行的系统的本机语言运行。同时，内存管理器排除了出现零碎内存的可能性，并增大了内存引用区域以进一步提高性能。

最后，运行库可由高性能的服务器端应用程序（如 Microsoft® SQL Server™ 和 Internet 信息服务 (IIS)）承载。此基础结构使您在享受支持运行库宿主的行业最佳企业服务器的优越性能的同时，能够使用托管代码编写业务逻辑。

.NET Framework 类库

.NET Framework 类库是一个与公共语言运行库紧密集成的可重用的类型集合。该类库是面向对象的，并提供您自己的托管代码可从中导出功能的类型。这不但使 .NET Framework 类型易于使用，而且还减少了学习 .NET Framework 的新功能所需要的时间。此外，第三方组件可与 .NET Framework 中的类无缝集成。

例如，.NET Framework 集合类实现一组可用于开发您自己的集合类的接口。您的集合类将与 .NET Framework 中的类无缝地混合。

正如您对面向对象的类库所希望的那样，.NET Framework 类型使您能够完成一系列常见编程任务（包括诸如字符串管理、数据收集、数据库连接以及文件访问等任务）。除这些常见任务之外，类库还包括支持多种专用开发方案的类型。例如，可使用 .NET Framework 开发下列类型的应用程序和服务：

• 控制台应用程序。

• Windows GUI 应用程序（Windows 窗体）。

• ASP.NET 应用程序。

• XML Web Services。

• Windows 服务。

例如，Windows 窗体类是一组综合性的可重用的类型，它们大大简化了 Windows GUI 的开发。如果要编写 ASP.NET Web 窗体应用程序，可使用 Web 窗体类。

客户端应用程序开发

客户端应用程序在基于 Windows 的编程中最接近于传统风格的应用程序。这些是在桌面上显示窗口或窗体从而使用户能够执行任务的应用程序类型。客户端应用程序包括诸如字处理程序和电子表格等应用程序，还包括自定义的业务应用程序（如数据输入工具、报告工具等等）。客户端应用程序通常使用窗口、菜单、按钮和其他 GUI 元素，并且它们可能访问本地资源（如文件系统）和外围设备（如打印机）。

另一种客户端应用程序是作为网页通过 Internet 部署的传统 ActiveX 控件（现在被托管 Windows 窗体控件所替代）。此应用程序非常类似于其他客户端应用程序：它在本机执行，可以访问本地资源，并包含图形元素。

过去，开发人员结合使用 C/C++ 与 Microsoft 基础类 (MFC) 或应用程序快速开发 (RAD) 环境（如 Microsoft® Visual Basic®）来创建此类应用程序。.NET Framework 将这些现有产品的特点合并到了单个且一致的开发环境中，该环境大大简化了客户端应用程序的开发。

包含在 .NET Framework 中的 Windows 窗体类旨在用于 GUI 开发。您可以轻松创建具有适应多变的商业需求所需的灵活性的命令窗口、按钮、菜单、工具栏和其他屏幕元素。

例如，.NET Framework 提供简单的属性以调整与窗体相关联的可视属性。某些情况下，基础操作系统不支持直接更改这些属性，而在这些情况下，.NET Framework 将自动重新创建窗体。这是 .NET Framework 集成开发人员接口从而使编码更简单更一致的许多方法之一。

和 ActiveX 控件不同，Windows 窗体控件具有对用户计算机的不完全受信任的访问权限。这意味着二进制代码或在本机执行的代码可访问用户系统上的某些资源，例如 GUI 元素和访问受限制的文件，但这些代码不能访问或危害其他资源。由于具有代码访问安全性，许多曾经需要安装在用户系统上的应用程序现在可以通过 Web 部署。您的应用程序可以在像网页那样部署时实现本地应用程序的功能。

服务器应用程序开发

在托管领域中，服务器端应用程序是通过运行库宿主实现的。非托管应用程序承载公共语言运行库，后者使您的自定义托管代码可以控制服务器的行为。此模型在获得主服务器的性能和可伸缩性的同时提供给您公共语言运行库和类库的所有功能。

下面的插图显示在不同服务器环境中运行托管代码的基本网络架构。在应用程序逻辑通过托管代码执行时，服务器（如 IIS 和 SQL Server）可执行标准操作。

服务器端托管代码

 

ASP.NET 是使开发人员能够使用 .NET Framework 开发基于 Web 的应用程序的宿主环境。但是，ASP.NET 不止是一个运行库宿主；它是使用托管代码开发网站和通过 Internet 分布的对象的完整结构。Web 窗体和 XML Web Services 都将 IIS 和 ASP.NET 用作应用程序的发布机制，并且两者在 .NET Framework 中都具有支持类集合。

XML Web Services 作为基于 Web 的技术的重要发展，是类似于常见网站的分布式服务器端应用程序组件。但是，与基于 Web 的应用程序不同，XML Web Services 组件不具有 UI 并且不以浏览器（如 Internet Explorer 和 Netscape Navigator）为目标。XML Web Services 由旨在供其他应用程序使用的可重用的软件组件组成，所谓的其他应用程序包括：传统的客户端应用程序，基于 Web 的应用程序，甚至是其他 XML Web Services。因此，XML Web Services 技术正迅速地将应用程序开发和部署推向高度分布式 Internet 环境。

如果您使用过 ASP 技术的早期版本，很快就会注意到 ASP.NET 和 Web 窗体提供的改进。例如，您可以用支持 .NET Framework 的任何语言开发 Web 窗体页。此外，您的代码不再需要与 HTTP 文本共享同一个文件（尽管如果您愿意，代码还可以继续这样做）。Web 窗体页用本机语言执行，这是因为与所有其他托管应用程序一样，它们充分利用运行库。与此相对照，非托管 ASP 页始终被写成脚本并解释。ASP.NET 页比非托管 ASP 页更快、更实用并且更易于开发，这是因为它们像所有托管应用程序一样与运行库进行交互。

.NET Framework 还提供类和工具的集合来帮助开发和使用 XML Web Services 应用程序。XML Web Services 是基于 SOAP（一种远程过程调用协议）、XML（一种可扩展的数据格式）和 WSDL（Web 服务描述语言）这些标准生成的。基于这些标准生成 .NET Framework 的目的是为了提高与非 Microsoft 解决方案的互操作性。

例如，.NET Framework SDK 所包含的 Web 服务描述语言工具可以查询在 Web 上发布的 XML Web Services，分析它的 WSDL 描述，并产生 C# 或 Visual Basic 源代码，您的应用程序可以使用这些代码而成为 XML Web Services 的客户端。这些源代码可以创建从类库中的类派生的类，这些类使用 SOAP 和 XML 分析处理所有基础通信。虽然您可以使用类库来直接使用 XML Web Services，Web 服务描述语言工具和包含在 SDK 中的其他工具可以使您更加方便地用 .NET Framework 进行开发。

如果您开发和发布自己的 XML Web Services，.NET Framework 为您提供了一组符合所有基础通信标准（如 SOAP、WSDL 和 XML）的类。使用这些类使您能够将注意力集中在服务的逻辑上，而无需关注分布式软件开发所需要的通信基础结构。

最后，与托管环境中的 Web 窗体页相似，您的 XML Web Services 将使用 IIS 的可伸缩通信以本机语言的速度运行。

.NET Framework 1.1 新功能和增强的功能

本节描述以前独立安装而现在包括在 .NET Framework 1.1 版中的技术。另外还描述对现有技术所做的主要更改。

ASP.NET 移动控件

ASP.NET 移动控件（原为 Microsoft Mobile Internet Toolkit）扩展了 .NET Framework 和 Visual Studio，提供了对移动电话和个人数据助理 (PDA) 等移动（无线）设备的支持。.NET Framework 1.1 版将移动控件合并到 .NET Framework 和 Visual Studio 分发软件包中。

由于移动控件现在是 .NET Framework 的一部分，因此术语已经做了相应的更改以便与 .NET 文档中使用的约定相匹配，移动控件文档也已合并为更大的 .NET Framework 文档集。ASP.NET 移动控件替换了 Mobile Internet Toolkit 这个名称。

ASP.NET 移动控件扩展了 ASP.NET 服务器控件，以便适应呈现 Web 应用程序的移动设备。通过浏览器检测，移动控件能够适应各种个人设备的功能，从全功能的 PDA 浏览器到 5 行 × 20 字符的小型移动电话显示屏都能适应。这种自适应呈现功能可以处理很多单调的设备特定呈现决定，使您可以将注意力集中在 Web 应用程序逻辑上。

ADO.NET 的改动

ODBC .NET Framework 数据提供程序原来只用于 Web 下载，现在也随 .NET Framework 在命名空间 System.Data.Odbc 下提供。

注意

使用 .NET Framework 1.0 版的开发人员仍须从 http://www.microsoft.com/china/msdn/download/default.mspx 下载用于 ODBC 的 .NET Framework 数据提供程序（命名空间 = Microsoft.Data.Odbc）。

用于 Oracle 的 .NET Framework 数据提供程序现随 .NET Framework 在命名空间 System.Data.OracleClient 下提供。使用 .NET Framework 1.0 版的开发人员可以从 http://www.microsoft.com/china/msdn/download/default.mspx 下载用于 Oracle 的 .NET Framework 数据提供程序。

另外，ADO.NET 现在包括以下功能：

• DataReader 对象现在公开 HasRows 属性，可以确定是否无需调用 Read 就返回行。有关更多信息，请参见使用 DataReader 检索数据。

• Connection 对象现在具有 EnlistDistributedTransaction 方法，可以在分布式事务中启用手动登记。有关更多信息，请参见执行事务。

并行 (Side-by-Side) 执行

.NET Framework 1.1 版支持并行执行。并行执行是在同一台计算机上存储和执行应用程序或组件的多个版本的能力。这意味着在同一台计算机上可以同时有运行库的多个版本，并且可以有使用其中某个运行库版本的应用程序和组件的多个版本。另外，.NET Framework 或组件的其他版本的后续安装不会影响已安装的应用程序。有关更多信息，请参见并行 (Side-by-Side) 执行。

并行执行并不意味着托管应用程序与运行库或组件的其他版本兼容。相反，它意味着托管应用程序可以选择它执行时所使用的运行库和组件，而且运行库、应用程序和组件的多个版本可以在同一台计算机上共存。由您决定具体某个应用程序所使用的运行库和组件的版本。

.NET Framework 安全性的改动

在 1.0 和 1.1 版中，从运行库代码访问安全性系统接收不完全受信任代码的应用程序不能调用共享托管库，除非库编写器通过使用 AllowPartiallyTrustedCallersAttribute 属性特别允许它们调用。如果打算通过部分受信任的代码使用库，您需要知道有些库不能用于您的代码。在 1.1 版中，System.Web.dll、System.Web.Mobile.dll 和 System.Web.RegularExpressions.dll 都包含在具有 AllowPartiallyTrustedCallersAttribute 且可以通过部分受信任的代码调用的程序集列表中。有关更多信息，请参见通过部分受信任的代码使用库。

已经更改了默认安全策略，以便那些从 Internet 区域执行并被分配给“Internet 区域”代码组的应用程序现在能够接收与 Internet 权限集关联的权限。因此，来自 Internet 的应用程序现在接收了足够的权限，可以执行。而在 .NET Framework 1.0 Service Pack 1 和 Service Pack 2 中，此类应用程序接收的是与 Nothing 权限集关联的权限，因此不能执行。有关更多信息，请参见默认安全策略。

宿主环境中的 ASP.NET 安全性

现在，ASP.NET 在基于 Web 的应用程序中支持部分信任，能够更好地保证单个 Web 服务器上承载的多个应用程序的安全。尽管应用程序运行所使用的操作系统帐户对应用程序施加了安全限制，公共语言运行库的代码访问安全性系统仍然能够根据您指定的策略，为选定的应用程序强制额外的限制。可以在共享服务器环境中使用此功能隔离不同的应用程序，还可以在希望应用程序仅以最少的必要特权运行的独立服务器上使用此功能。

ASP.NET 提供了 <trust> 配置指令，帮助您为应用程序配置代码访问安全级别。如果部分受信任的 ASP.NET 应用程序要调用共享托管库，则这些库必须包含允许通过部分受信任的代码调用的 AllowPartiallyTrustedCallersAttribute 属性。有关更多信息，请参见通过部分受信任的代码使用库。

.NET Framework 中的 IPv6 支持

.NET Framework 1.1 版支持新出现的 Internet 协议（通常称为 IP 第 6 版或简写为 IPv6）。设计该协议的目的是为了大幅增加用于在 Internet 中标识通信终结点的地址空间，以与它的持续增长相适应。System.Net 命名空间、ASP.NET 和 XML Web services 均支持 IPv6。有关更多信息，请参见 Internet 协议版本 6。

.NET Framework 2.0 版中的新增功能

在 Microsoft .NET Framework 1.1 版的基础上，.NET Framework 2.0 版进行了扩展，不仅对现有的功能做了改进，还新增了一些功能，并对文档进行了增强。本节提供有关某些主要添加和修改的信息。

有关可能影响您的应用程序的重大更改的更多信息，请参见 Breaking Changes in the .NET Framework（.NET Framework 中的重大更改）。

64 位平台支持

新一代的 64 位计算机使人们能够创建比 32 位应用程序运行更快并且能够比 32 位应用程序更好地利用内存的应用程序。对 64 位应用程序的新支持使用户能够在 64 位计算机上生成托管代码库或方便地使用非托管代码库。有关更多信息，请参见 64 位应用程序。

访问控制列表支持

访问控制列表 (ACL) 用于授予或撤消对计算机上的资源的访问权限。.NET Framework 中已添加了允许托管代码创建和修改 ACL 的新类。I/O 类、注册表类和线程类中添加了使用 ACL 的新成员。

ADO.NET

ADO.NET 中的新功能包括对用户定义类型 (UDT)、异步数据库操作、XML 数据类型、大值类型和快照隔离的支持，以及对允许应用程序通过 SQL Server 2005 支持多活动结果集 (MARS) 的新属性的支持。有关 ADO.NET 的这些新功能以及其他 ADO.NET 新功能的更多信息，请参见 ADO.NET 中的新增功能。

ASP.NET

Microsoft .NET Framework 2.0 包含了对 ASP.NET 各个方面的重要增强。对于网页开发，新的控件使得向动态网页添加常用功能更加方便。新的数据控件使得无需编写代码即可在 ASP.NET 网页上显示和编辑数据成为可能。经过改善的代码隐藏模型使得开发 ASP.NET 页更容易也更可靠。缓存功能提供了用来缓存页的多种新方式，包括在 SQL Server 数据库的表上生成缓存依赖项的能力。

现在，您可以以多种方式自定义网站和网页。配置文件属性使 ASP.NET 能够自动跟踪单个用户的属性值。通过使用 Web 部件，您可以创建用户可在浏览器中自定义的页。您可以使用简单控件添加导航菜单。

对网站功能的改进使您可以更加方便快捷地创建专业网站。母版页使您可以为站点中的所有页创建一致的布局，而主题使您可以为控件和静态文本定义一致的外观。若要帮助保护您的站点，您可以预编译网站以从源文件（代码文件和 .aspx 页中的标记）生成可执行代码。然后，您可以将结果输出部署到成品服务器，结果输出不包含任何源信息。对 ASP.NET 的增强还包括可使网站开发人员、服务器管理员和托管人员更容易地进行网站管理的新的工具和类。

ASP.NET 适合于多种浏览器和设备。默认情况下，控件呈现符合 XHTML 1.1 标准的输出。您可以使用设备筛选针对不同的浏览器为相同的控件指定不同的属性值。

有关 ASP.NET 新增功能的更完整列表，请参见 ASP.NET 中的新增功能。

已验证身份的流

应用程序可使用新的 NegotiateStream 和 SslStream 类进行身份验证，并帮助保护在客户端和服务器之间传输的信息的安全。这些已验证身份的流类支持相互身份验证、数据加密和数据签名。NegotiateStream 类使用协商安全协议进行身份验证。SslStream 类使用安全套接字层 (SSL) 安全协议进行身份验证。

COM Interop 服务增强功能

类和工具中增加了四种支持与 COM 的互操作性的主要增强功能：

• 操作系统维护有限数量的句柄，这些句柄用来引用关键操作系统资源。新的 SafeHandle 和 CriticalHandle 类及其专用派生类提供了对操作系统句柄进行操作的安全可靠的方式。

• 对封送处理的改进使得与本机代码交互操作更加容易。对互操作封送拆收器的两种增强功能满足了最常见的两种用户要求：将本机函数指针包装到委托中的能力以及在结构内部封送固定大小的结构数组的能力。

• 对于常见调用类型，不同应用程序域中的应用程序之间的调用性能速度更快。

• 类型库导入程序 (Tlbimp.exe) 和类型库导出程序 (Tlbexp.exe) 的新开关消除了对注册表解析类型库引用的依赖性。此增强对于创建可靠的生成环境非常重要。

Console 类增补

Console 类的新成员使应用程序能够操作控制台窗口和屏幕缓冲区的大小；移动屏幕缓冲区的矩形区域（这对于执行平滑简单的动画很有用）；并在读取控制台输入时等待，直至按下某个键。其他新的类成员控制文本的前景色和背景色、光标的可见性和大小以及控制台警告声的频率和持续时间。

数据保护 API

新的数据保护 API (DPAPI) 包含四种方法可使应用程序无需调用平台调用即可加密密码、密钥、连接字符串等。您还可以在运行 Windows Server 2003 或更高版本操作系统的计算机上加密内存块。

调试器显示属性

现在，您可以控制当调试应用程序时 Visual Studio 显示类或成员的方式。调试器的显示属性功能使您能够标识要在调试器中显示的最有用的信息。

调试器编辑并继续支持

.NET Framework 2.0 重新引入了“编辑并继续”功能，该功能使在 Visual Studio 中调试应用程序的用户能够在以中断模式执行的同时更改源代码。在应用对源代码所做的编辑之后，用户可以继续执行代码并观察效果。而且，“编辑并继续”功能在 Visual Studio 所支持的任何编程语言中都可用。

检测网络连接更改

NetworkChange 类可使应用程序在网络接口（也称为网卡或适配器）的 Internet 协议 (IP) 地址发生更改时接收通知。更改接口地址的原因有多种，如网线断开、超出了无线局域网的范围或者硬件故障。NetworkChange 类通过在检测到地址更改时引发事件来提供地址更改通知。

分布式计算

在 System.Net 命名空间中，已添加了对 FTP 客户端请求、HTTP 资源缓存、自动代理发现以及网络流量和统计信息获取的支持。该命名空间现在包含一个 Web 服务器类 (HttpListener)，您可以用它来创建简单的 Web 服务器以响应 HTTP 请求。已对生成网络流量的类进行检测以输出用于应用程序调试和诊断的跟踪信息。System.Net.Sockets.Socket 和 System.Uri 类中添加了安全和性能增强。

在 System.Web.Services 命名空间中，添加了对 SOAP 1.2 和可空元素的支持。

在 System.Runtime.Remoting.Channels 命名空间中，添加了信道安全功能。TCP 信道现在支持身份验证和加密，以及多种用于更好地支持负载平衡的新功能。

EventLog 增强

现在您可以对 EventLog 消息、参数和类别使用自定义 DLL。

扩展的证书管理

.NET Framework 现在支持 X.509 证书存储区、证书链和证书扩展。此外，您可以使用 X.509 证书签名和验证 XML，而无需使用平台调用。还有对 PKCS7 签名和加密以及 CMS（Microsoft Windows 2000 和更高版本操作系统上可用的 PKCS7 标准的超集）的支持。PKCS7 是安全/多用途 Internet 邮件扩展 (S/MIME) 中用于签名和加密数据的基础格式。有关更多信息，请参见 X509Certificate2 类主题。

FTP 支持

应用程序现在可以使用 WebRequest、WebResponse 和 WebClient 类访问文件传输协议资源。

泛型和泛型集合

.NET Framework 2.0 引入了泛型以使您能够创建灵活的可重用代码。合称为泛型的语言功能充当模板，这些模板允许使用未指定的或泛型的类型参数（而不是使用具体的类型）来声明和定义类、结构、接口、方法和委托。使用泛型时，实际类型是在稍后指定的。多个命名空间（如 System Namespace 和 System.Collections.Generic）提供了泛型类和方法。新的 System.Collections.Generic 命名空间提供了对强类型集合的支持。System.Nullable<T> 是可选值的标准表示形式。有三种语言支持泛型：Visual Basic、C# 和 C++。

反射已得到扩展以允许泛型类型和方法的运行时检查和操作。System.Type 和 System.Reflection.MethodInfo 添加了新成员，包括标识泛型类型（例如 class Gen<T,U> {...}）的 IsGenericType、获取类型参数列表的 GetGenericArguments 以及创建特定类型（例如 new Gen<int, long>()）的 MakeGenericType。

全球化

五个新的全球化功能对于开发用于不同语言和区域性的应用程序提供了更广泛的支持。

• 对自定义区域性的支持使您能够根据需要定义和部署区域性相关的信息。此功能对于对现有区域性定义进行少量自定义以及创建 .NET Framework 中尚不存在的区域性定义非常有用。有关更多信息，请参见 CultureAndRegionInfoBuilder 属性。

• 编码和解码操作将 Unicode 字符与可传输到物理介质（如磁盘或通信线路）的字节流进行相互映射。如果映射操作无法完成，则可以使用 System.Text 命名空间中的多个类所支持的新的编码和解码回退功能来加以弥补。

• 实现 UTF-8 编码的 UTF8Encoding 类中的成员现在比以前的版本快几倍。UTF-8 是用来将 Unicode 字符转换为计算机上的字节的最常用编码。

• .NET Framework 现在支持 Unicode 联合会定义的最新规范化标准。该规范化过程将文本的字符表示形式转换为标准形式以便可以比较这些表示形式是否相等。

• GetCultureInfo 方法重载提供了 CultureInfo 只读对象的缓存版本。创建新的 CultureInfo 对象时使用该缓存版本可提高系统性能并减少内存使用量。

I/O 增强功能

已经对各种 I/O 类的可用性和功能进行了改进。用户现在可以更加容易地读写文本文件并获取有关驱动器的信息。

现在您可以使用 System.IO.Compression 命名空间中的类以 GZIP 压缩和解压缩标准读写数据，IETF RFC 1951 和 RFC 1952 规范描述了该标准，可在 IETF Request for Comments (RFC) search page（IETF 请求注释 (RFC) 搜索页）注意：搜索仅限于 RFC 编号上获得。

基于清单的激活

此功能提供了通过使用清单加载和激活应用程序的新支持。基于清单的激活对于支持 ClickOnce 应用程序至关重要。传统上，应用程序是通过对包含应用程序入口点的程序集的引用激活的。例如，从 Windows 外壳程序内单击应用程序的 .exe 文件将使外壳程序加载公共语言运行库 (CLR) 并调用该 .exe 文件的程序集内的已知入口点。

基于清单的激活模型使用应用程序清单而不是程序集来激活。清单完全描述应用程序、应用程序的依赖项、安全要求等。与基于程序集的激活模型相比，清单模型具有几个优点，特别是对于 Web 应用程序而言。例如，清单包含应用程序的安全要求，这使得用户能够决定在下载代码前是否允许应用程序执行。清单还包含有关应用程序依赖项的信息。

基于清单的激活由一组 API 提供，这些 API 允许托管主机激活由清单描述的应用程序和外接程序。这些 API 混合包含了新类以及对现有类的扩展。

此激活模型还调用称为“信任关系管理器”的实体，该实体执行以下任务：

1. 确定是否允许激活应用程序。此决定可通过提示用户、查询策略或任何其他认为适合于给定“信任关系管理器”的方式作出。

2. 设置在其中运行应用程序的安全上下文。通常，此步骤涉及在要运行应用程序的应用程序域上设置一个代码访问安全 (CAS) 策略树。

.NET Framework 远程处理

.NET Framework 远程处理现在支持 IPv6 地址以及泛型类型的交换。System.Runtime.Remoting.Channels.Tcp 命名空间中的类支持使用安全支持提供程序接口 (SSPI) 的身份验证和加密。新的 System.Runtime.Remoting.Channels.Ipc 命名空间中的类允许同一台计算机上的应用程序迅速通信而无需使用网络。最后，现在您可以配置连接缓存超时和方法重试次数，这可以提高网络负载平衡远程群集的性能。

获取有关本地计算机网络配置和使用情况的信息

通过使用 System.Net.NetworkInformation 命名空间中的类，应用程序可以访问 IP、IPv4、IPv6、TCP 和 UDP 网络流量的统计信息。应用程序还可以查看本地计算机网络适配器的地址和配置信息。这些信息类似于 Ipconfig.exe 命令行工具返回的信息。

Ping

Ping 类可使应用程序确定是否可通过网络访问远程计算机。此类提供类似于 Ping.exe 命令行工具的功能，并支持同步和异步调用。

从应用程序内部处理 HTTP 请求

您可以使用 HttpListener 类来创建响应 HTTP 请求的简单 Web 服务器。该 Web 服务器在 HttpListener 对象的生存期内是活动的，并以应用程序的权限在应用程序中运行。此类仅在运行 Windows XP Service Pack 2 或 Windows Server 2003 操作系统的计算机上可用。

缓存的编程空间

通过使用 System.Net.Cache 命名空间中的类，应用程序可以使用 WebRequest、WebResponse 和 WebClient 类控制所获取资源的缓存。您可以使用 .NET Framework 提供的预定义缓存策略或指定自定义缓存策略。可以为每个请求指定一个缓存策略，并为未指定缓存策略的请求定义默认缓存策略。

编程语言

四种 Microsoft 编程语言明确针对 .NET Framework。有关这些语言中的新增功能和增强的更多信息，请参见以下主题：

C# 2.0 中的新增功能

Visual J# 语言中的新增功能

Microsoft C/C++ 语言中的新增功能

Visual Basic 语言中的新增功能

Visual Basic 编译器和语言

Visual Basic 中的语言改进简化了源代码，并且启用了与使用高级功能的组件的交互。

编译器

Visual Basic 为所有项目引入了新的条件编译常数 VBC_VER。此版本的值为 VBC_VER 8.0。

Visual Basic 命令行编译器现在将默认命令行选项存储在 Vbc.rsp 文件中，该文件与命令行编译器 (Vbc.exe) 位于同一个目录中。您可以编辑 Vbc.rsp 以重新配置默认命令行选项。

有四个新的命令行编译器选项：

• /doc 选项根据代码中的注释生成 XML 文档文件。

• /noconfig 选项使编译器忽略 Vbc.rsp 文件。

• /codepage 选项指定在打开源文件时使用哪个代码页。

• /filealign 选项指定输出文件中的节大小。

• /nostdlib (Visual Basic) 选项使编译器不引用标准库。

有关更多信息，请参见 Visual Basic 编译器选项。

语言

在此版本的 Visual Basic 语言中有多个新元素：

• Continue 语句

• Operator 语句

• Using 语句

• IsFalse 运算符

• IsNot 运算符

• IsTrue 运算符

• SByte 数据类型

• UInteger 数据类型

• ULong 数据类型

• UShort 数据类型

• Global

• Of

• Narrowing

• Widening

• Partial (Visual Basic)

• Custom

安全性异常

System.Security.SecurityException 类已得到扩展以提供有利于调查安全性异常起因的附加数据。新属性提供了很多信息，包括发生异常的方法、第一个失败的权限、程序集的区域或 URL、失败的安全性操作以及引发异常的对调用堆栈的安全性操作，如 Deny 或 PermitOnly。

串行 I/O 设备支持

新的 SerialPort 类为应用程序提供了访问计算机串行端口以及与串行 I/O 设备进行通信的能力。

序列化

BinaryFormatter 和 SoapFormatter 类现在提供了版本容错序列化，这种序列化可使一种类型从另一个版本的序列化进行反序列化。有关更多详细信息，请参见版本容错序列化。

XML 序列化现在支持使用属性而不是字段来表示架构元素，支持泛型类型的序列化，并且支持使用 Nullable 结构来表示可空元素。IXmlSerializable 接口支持自定义架构生成。SchemaImporterExtension 可使您在架构导入期间更改架构来控制代理代码生成。例如，您可以在使用 Visual Studio 的“添加 Web 引用”功能或使用 Web 服务描述语言工具 (Wsdl.exe) 时更改生成的代理。

新的 XML 序列化程序生成器工具 (Sgen.exe) 可使您预编译 Web 服务客户端使用的代码以序列化传输的信息，这将大大缩短客户端启动时间。有关更多详细信息，请参见介绍 XML 序列化。

SMTP 支持

通过使用 System.Net.Mail 和 System.Net.Mime 命名空间中的类，应用程序可以将电子邮件发送给一个或多个收件人。邮件可用不同的可选视图发送并且可包含附件。同时支持抄送和密件抄送。

强类型资源支持

资源文件生成器 (Resgen.exe) 创建嵌入在可执行文件和附属程序集中的资源文件。Resgen.exe 为每个资源文件生成一个包装类，该类可使您方便地访问资源并防止资源名称的拼写错误。

线程改进

现在，您可以命名完全在托管代码中创建的进程间通信事件。Semaphore 类还支持专用资源计数。

跟踪数据筛选

.NET Framework 2.0 提供了跟踪和记录与 I/O、应用程序启动和关闭等有关的系统事件的类。然而，由于跟踪信息数量巨大而且类型多样，这使得用户难以分析这些数据。新的对跟踪数据筛选的支持使您能够指定要记录的信息的类型。

事务

新的 System.Transactions 命名空间包含的类可使应用程序参与由 Microsoft 分布式事务协调器 (MSDTC) 或本地事务管理器管理的事务。System.Transactions 命名空间提供基于 Transaction 类的显式编程模型和使用 TransactionScope 类的隐式编程模型，在后一种模型中，事务由该基础结构自动管理。此事务基础结构可以方便地与现有的 System.EnterpriseServices (COM+) 事务基础结构交互操作。System.Transactions 命名空间还提供用于实现资源管理器的类。资源管理器管理事务中使用的持久或可变数据，并与事务管理器协作为应用程序提供原子性和隔离性的保证。

Web 服务

Web 服务支持 SOAP 1.2 和 WS-I 基本概要 1.0，后者记录在“Web Services Interoperability Organization - Basic Profile Version 1.0（Web 服务互操作性组织 -- 基本概要 1.0 版）”中。

在使用定义共享类型的两个或更多 Web 服务时，为这些 Web 服务生成的客户端代理共享客户端上相应的类型。这使客户端可以在 Web 服务之间方便地传递共享类型的实例。

现在您可以使用基于事件的编程模式异步调用 Web 方法。

Windows 窗体相关的功能

ClickOnce 部署

ClickOnce 部署使您能够部署自行更新的 Windows 应用程序，这类应用程序可以像 Web 应用程序一样轻松地安装和运行。您可以部署 Windows 客户端和命令行应用程序。Visual Studio 中的“生成”和“项目”菜单上提供了新的“发布项目”命令。有关更多信息，请参见 ClickOnce 部署概述。

应用程序设置

Windows 窗体的应用程序设置使得在客户端上创建、存储和维护自定义应用程序和用户首选项变得容易进行。通过 Windows 窗体设置，您不仅可以存储应用程序数据（如数据库连接字符串），还可以存储特定于用户的数据（如工具栏位置和最近使用的列表）。有关更多信息，请参见应用程序设置概述。

新的数据绑定模型

因为 BindingSource 组件充当了绑定控件和目标数据源的中间源，所以简化了数据绑定的过程。它自动管理很多更难的绑定问题，例如货币、与数据有关的事件以及目标数据源更改。它还被设计为与其他和数据相关的 Windows 窗体控件交互操作，尤其是 BindingNavigator 和 DataGridView 控件。有关更多信息，请参见 BindingSource 组件。BindingSource 组件简化了将控件绑定到基础数据源的过程。它既充当导管，也充当其他控件所绑定到的数据源。

新的 Windows 窗体控件

DataGridView 控件提供了一种强大而灵活的方法，用来以表格的形式显示数据。它可以用来显示少量数据的只读视图，或可以缩放以显示非常大的数据集的可编辑视图。数据可以驻留在外部数据源中，也可以直接添加到控件。有关更多信息，请参见 DataGridView 控件概述（Windows 窗体）。

ToolStrip 控件是 Windows 窗体应用程序中可承载菜单、控件和用户控件的工具栏。ToolStrip 类及其关联类使您能够创建与 Microsoft Windows XP、Microsoft Office 和 Microsoft Internet Explorer 样式一致的工具栏和其他用户界面元素。您还可以使用这些类来自定义工具栏和用户界面元素。有关更多信息，请参见 ToolStrip 控件概述（Windows 窗体）。

MaskedTextBox 控件使用掩码定义来区分有效和无效的用户输入。有关更多信息，请参见 MaskedTextBox 控件（Windows 窗体）。

Windows 窗体 SoundPlayer 类使您能够轻松地在应用程序中包含声音。SoundPlayer 类可以播放来自资源或者来自通用命名约定 (UNC) 或 HTTP 位置的 .wav 格式的声音文件。此外，SoundPlayer 类使您能够异步加载或播放声音。有关更多信息，请参见 SoundPlayer 类。

可以将 Windows 窗体 SplitContainer 控件看作是一个复合体，它是由一个可移动的拆分条分隔的两个面板。当鼠标指针悬停在该拆分条上时，光标将相应地更改以显示该拆分条是可移动的。使用此控件可创建对于显示和浏览信息有效的、可调整大小的复杂用户界面。有关更多信息，请参见 SplitContainer 控件。

ListView 控件现在支持三种由 Windows XP 和 Windows Server 2003 系列提供的功能：平铺视图、分组和拖放项重新定位。

ListView、TreeView 和 ToolTip 控件现在支持类似于以前版本中的对 ComboBox、ListBox、MenuItem 和 TabControl 控件的所有者描述支持的所有者描述功能。

WebBrowser 控件使您可以在 Windows 窗体应用程序中承载网页。您可以使用 WebBrowser 控件在应用程序中提供基于 HTML 的集成用户帮助或 Internet Web 浏览功能。此外，您还可以使用 WebBrowser 控件将现有 Web 应用程序转换为将动态 HTML (DHTML) 代码与 Windows 窗体的用户界面功能无缝集成的客户端应用程序。有关更多信息，请参见 WebBrowser 控件概述。

FlowLayoutPanel 控件在水平或垂直流方向排列其内容。TableLayoutPanel 控件以网格方式排列其内容。因为在设计时和运行时都执行布局，所以当应用程序环境更改时，布局可以动态更改。有关更多信息，请参见 FlowLayoutPanel 控件概述和 TableLayoutPanel 控件概述。

BackgroundWorker 组件使您能够在后台执行可能花费很长时间执行的操作，例如图像下载和数据库事务。有关更多信息，请参见 BackgroundWorker 组件概述。

组件的异步模式是一种事件驱动的模型，它提供了多线程应用程序的优点，同时隐藏了多线程设计中固有的很多复杂问题。有关更多信息，请参见组件的异步模式。

XML 相关的功能

.NET Framework 2.0 提供了很多增强功能，包括新的 XSL 转换 (XSLT) 处理器；XmlReader、XmlWriter 和 XPathNavigator 类中的类型支持；以及 XPathNavigator 类中的新的编辑功能。此外，还有用于创建 XmlReader 和 XmlWriter 对象的新模型，以及很多性能改进。有关更多信息，请参见 System.Xml 中的新增功能。

C# 2.0新增功能

表1-2  C# 2.0新增功能

功能	描述
泛型	C# 2.0中添加了一些泛型类型。使开发人员能够实现程度很高的代码重用，获得更高的集合类性能。泛型类型只存在 arity 上的不同。也可以将参数强制为特定的类型。
迭代器	迭代器使得规定 foreach 循环将如何循环访问集合的内容变得更加容易。
分部类	分部类型定义允许将单个类（比如某个类）拆分为多个文件。Visual Studio 2005窗体设计器使用此功能将它生成的代码与用户代码分离。
可空类型	可空类型允许变量包含未定义的值。在使用数据库和其他可能包含未含有具体值的元素的数据结构时，可以使用可空类型。
匿名方法	可以将代码块作为参数来传递。在本应使用委托的任何地方，都可以使用代码块来取代，不需要定义新的方法。
命名空间别名限定符	命名空间别名限定符（：：）对访问命名空间成员提供了更多控制。global：：别名允许访问可能被代码中的实体隐藏的根命名空间。
静态类	若要声明那些包含不能实例化的静态方法的类，静态类就是一种安全而便利的方式。C# 1.2版要求将类构造函数定义为私有的，以防止类被实例化。
外部程序集别名	通过 extern 关键字的这种扩展用法引用包含在同一程序集中的同一组件的不同版本。
属性访问器可访问性	可以为属性的 get 和 set 访问器定义不同级别的可访问性。
委托中的协变和逆变	传递给委托的方法在返回类型和参数方面可以具有更大的灵活性。
声明、实例化和使用委托	方法组转换为声明委托提供了一种更简单的语法。
固定大小的缓冲区	在不安全的代码块中，可以声明包含嵌入数组的固定大小结构。
友元程序集	程序集可以提供对其他程序集的非公共类型的访问。
内联警告控制	#pragma 警告指令可用于禁用和启用某些编译器警告。
volatile	volatile 关键字应用于IntPtr和UIntPtr。

编译器的新增功能和更改内容如表1-3所示。

表1-3  编译器的新增功能和更改内容

功能	描述
/errorreport选项	可用于通过Internet向Microsoft报告内部编译器错误。
/incremental选项	已移除。
/keycontainer和/keyfile选项	支持指定加密密钥。
/langversion选项	可用于指定与特定语言版本的兼容性。
/linkresource选项	包含附加选项。
/moduleassemblyname选项	可以生成.netmodule文件并访问现有程序集中的非公共类型。
/pdb选项	指定.pdb文件的名称和位置。
/platform选项	可将Itanium系列(IPF)和x64结构作为目标平台。
#pragma warning	用于在代码中禁用或启用单个警告。

.NET Framework 3.0

适用于：

• .NET Framework 3.0（即以前的 WinFX）

• Windows 开发

摘要：3.0 版 Microsoft .NET Framework 采用了大量的最新技术，可以解决当今应用程序开发中的种种难题。

本页内容

描述 .NET Framework 3.0
应用 .NET Framework 3.0：设想
了解 .NET Framework 3.0：技术
获取 .NET Framework 3.0：不同选项
结论
更多参考资料

David Chappell

Chappell & Associates

2006 年 7 月

描述 .NET Framework 3.0

应用程序开发的目标始终如一，就是在最短时间内制作出最好的软件。然而，随着开发平台的性能越来越高，制作软件的壁垒也相应提高了。以 Windows 为例，原来的 Win32 接口已经融入到功能更强的 .NET Framework 中。2002 年发布的 Framework 1.0 和 2005 年发布的 Framework 2.0 为设计和编写 Windows 软件的开发人员提供了更好的工作环境，效率也更高。

.NET Framework 3.0（以前称为 WinFX）就是我们前进路上的下一个目标。建立在这一新版 Framework 上的应用程序可通过 Visual Studio 2005 创建，对大多数 Windows 开发人员来说，这样的应用程序将会更加熟悉。.NET Framework 3.0 是从 2.0 版本演化而来，并在原来的基础上添加了许多新的功能。.NET Framework 3.0 计划于 2006 年底发布，适用于 Windows Vista、Windows Server 2003 和 Windows XP。

本文对 .NET Framework 3.0 及其组件进行了整体描述，目的是让大家对这一新版本有一个清晰的了解，同时分析了采用的技术，并给出简要说明。

创建现代应用程序：主要挑战

今天，开发一款优秀的应用程序可不简单 - 您需要考虑众多的要求。传统的考虑因素，如访问数据、通过 Web 浏览器上网等固然重要，但这些已经显然不够了。下面列出了现代应用程序面临的一系列新挑战：

组织越来越倾向于从面向流程的角度看待他们的工作。由于大多数应用程序已经对业务流程实现了部分自动化，因此，在代码中明确流程中的这几个步骤就非常重要了。而要实现这一目标，最有效途径是使用工作流技术，这是一种需要支持基于工作流的应用程序的方法。

通常来讲，应用程序要与组织内外的其他应用程序进行通信。现代应用程序还必须适用于面向服务的架构 (SOA)，同时还要实现一些功能，作为其他软件可以访问的交互服务。要实现这些目标，就需要支持面向服务的应用程序。

对于使用应用程序的人员来说，通常还需要有传递识别信息的方法。目前定义和使用数字标识的技术各不相同，这也是造成网页仿冒等问题泛滥的原因。有鉴于此，现代应用程序及其使用者将会从一致的数字标识用户控件中受益。

对于现代用户界面，人们的要求也有了很大幅度的提高。要提供真正的业务价值往往需要处理不同类型的文档，使用二维或三维图形，播放视频等等，还要保证本地 Windows 客户端和 Web 浏览器能够兼容这些功能。要满足这些要求，需要不同的用户界面采用统一的方法。

一般说来，现在的应用程序需要应对以上部分或全部的挑战，因此，这些应用程序的开发平台应该采用一致、可行的方法来解决所有的相关问题。.NET Framework 3.0 就是专为解决这些 Windows 应用程序难题而设计。

应对挑战：.NET Framework 3.0 功能介绍

如图 1 所示，.NET Framework 3.0 版是在以前版本的基础上完善而成。事实上，3.0版本保留了 .NET Framework 2.0 的全部功能，因此，在以前版本基础上开发的应用程序仍然可以正常使用。.NET Framework 3.0 添加了四个新组件：Windows Workflow Foundation、Windows Communication Foundation、Windows CardSpace 和 Windows Presentation Foundation。本节将会概要介绍 .NET Framework 2.0 和上述四个新组件的功能。

图 1

.NET Framework 2.0：Windows 应用程序通用基础

尽管仍然可以通过 Win32 界面直接编写软件，而事实上却是，.NET Framework 已经成为编写新 Windows 应用程序的主流环境。如下所示为.NET Framework 最重要的组成部分：

• ASP.NET，支持可 Web 访问的应用程序的开发。

• ADO.NET，允许应用程序访问相关的其他类型数据。

• Windows Forms，支持建立 Windows 应用程序的图形用户界面 (GUI)。

• System.XML，使应用程序能够使用 XML 定义的数据，包括 XSLT 和 XPath。

Framework 的 2.0 版本在以前版本的基础上添加了几项实用功能，包括对开发 ASP.NET Web 应用程序的技术改进，支持在 64 位 Windows 上运行的 64 位应用程序，还增加了处理事务的新方法。虽然 .NET Framework 2.0 中的部分组件为 3.0 版本中新增组件所取代，但是 2.0 版本的技术仍然是新发布的 3.0 版本的基础，请见随后的详细介绍。

Windows Workflow Foundation：支持基于工作流的应用程序

工作流是一个简单思路：按照特定顺序执行的一系列步骤。您甚至可以认为每个应用程序都在执行工作流，因为每个应用程序都执行某些过程。但是，在使用 C#、Visual Basic 或其他编程语言等传统方法开发的应用程序中，这些过程都隐含在代码中。这样做没问题，但是这些过程被深深地嵌入程序逻辑中，使得其执行或更改愈加困难。

使用工作流技术执行过程逻辑可以有效地解决这一问题。采用工作流技术后，逻辑与普通代码就不会纠缠在一起，过程中的每一步骤都会明确定义，然后由工作流引擎执行。这样做的结果就是，过程执行清楚明确。

工作流引擎不是什么新概念，有些已经在 Windows 和其他系统中得到应用。Microsoft 已经在部分产品中嵌入了工作流引擎。但是，随着工作流日渐成为开发应用程序的主流方法，提供适用于 Windows 的单一工作流技术已经势在必行。这也正是 Windows Workflow Foundation（正式缩写是 WF ）的设计初衷。由于其提供了适用于 Windows 的通用工作流技术，WF 已成为所有基于工作流应用程序的统一创建基础。Microsoft 的 Microsoft Office 2007 系统、Windows SharePoint Services 等软件，以及许多其他公司的应用程序也会使用 WF。

但是，提供通用的工作流技术之路却是困难重重。举例来说，如何使用一种方法来满足不同工作流应用程序的各种要求？WF 给出的答案是，从全局视角来看待工作流。如图 2 所示，WF 工作流只是一组由 WF 引擎执行的活动。一个活动就是一个类，它可以包含工作流创建者认为有必要的任何工作。活动可以在不同的工作流中重复使用，因此，在针对新问题创建自动化的解决方案时，过程将会更加容易。

图 2

提供通用工作流技术面临另一个困难是，面向人员工作流和面向系统工作流的传统分歧。通常来说，工作人员使用的工作流应用程序需要有较高的灵活性，能够进行实时更改。而一般由系统，也就是由软件使用的工作流应用程序则相对更加静态，但要求尽可能高效。WF 综合考虑了这两种不同的使用情况，不仅包括面向人员的功能（如更改运行中工作流的功能），同时还支持更多面向系统的操作。

通过 WF 的 Windows 通用工作流技术，.NET Framework 3.0 为广大开发人员提供了一种非常有用的软件开发模式。随着面向流程的软件继续风行，工作流技术也会随之推广。

Windows Communication Foundation：支持面向服务的应用程序

无论是通过工作流还是其他方式开发，绝大多数应用程序都需要与其他应用程序进行通信。近几年来，应用程序间的通信技术发展迅速。在长达数十年的不统一之后，主要供应商之间最终达成了一致的应用程序通信协议。根据 SOAP 这一全球 Web 服务协议，基于 J2EE、.NET Framework 等不同技术平台开发的应用程序间的互操作性相比以前大为简化。它还会使面向服务的架构这一思想为更多的组织接受。

当然，现在的通信方式已经不少了。以 .NET Framework 2.0 为例，您可以选择以下几种通信方式：

• ASP.NET Web 服务，提供基于 SOAP 的交互通信。

• .NET Remoting，主要用于 .NET 应用程序之间的通信。

• Enterprise Services，支持可扩展的事务性应用程序。

• System.Messaging，通过 Microsoft Message Queuing (MSMQ) 支持队列消息。

• Web Services Enhancements (WSE)，它是 ASP.NET Web 服务的扩展，支持 WS-Security 等新规范。

这些技术都有其自身的价值，在实际应用中也有着各自的地位。可是，既然问题是一样的，为什么要采用好几种不同的解决方案呢？为什么不根据交互服务来建立一个单一的应用程序通信基础？

这正是 Windows Communication Foundation (WCF) 的设计初衷。有了 WCF，开发人员不必再像从前一样，处理每一类通信都要使用到不同的应用程序编程接口技术 － WCF （最初的代号为“Indigo”）以通用的 API 提供通用的方法。在 .NET Framework 3.0 环境下，大多数使用上述技术之一的应用程序将会代而使用 WCF。

WCF 通过 SOAP 提供强大的交互通信支持，这是现代计算机设备的基本要素。它还支持多项 WS-* 规范，如 WS-Security、WS-ReliableMessaging 和 WS-AtomicTransaction。WCF 不需要 SOAP，但是可能会使用其他方法，包括优化二进制协议、MSMQ 队列消息 和基于 REST 的简单通信。WCF 同样采取明确的面向服务方法来进行通信。WCF 不会在对象间进行透明通信，而是为通信各方提供略微不同的抽象服务。其结果之一就是放开了分布式对象系统间某些紧密的耦合关系，使得交互出错减少，并且更容易修改。

无论是在组织内部还是组织之间，应用程序通信都是现代软件的基本功能。.NET Framework 3.0 以其 WCF 面向服务方法解决了这一难题。

Windows CardSpace：一致的数字标识用户控件

请您想一下，人们在 Internet 上是如何表示各自身份的。多数情况下是将个人的数字标识作为一个简单的用户名。再加上密码之后，就可以使用这个标识访问电子邮件帐户、网上商店、网上银行和其他一些金融机构了。尽管这种方法很简单，现在也在普遍应用，但是用户名和密码方式有着无法回避的缺点。最重要的两项是：

要记住登录众多网站的不同用户名和密码，的确让人不胜其烦。为了减少这些麻烦，许多人在不同网站使用相同的用户名和密码，可这样又增加了安全风险。

用户名、密码和其他个人信息可能会被网页仿冒者窃取。网页仿冒者会发送欺骗性电子邮件，诱使受害者去登录一个假冒网站，比如一个与受害者银行极其相似的仿冒网站。而这个网站实际上是网页仿冒者控制的。一旦受害者输入自己的用户名和密码，网页仿冒者就会利用这些信息，在真网站冒充该用户，牟取不当利益。

要减少这些问题的危害性，我们需要采用新的方法来管理数字标识。Windows CardSpace（最初代号为“InfoCard”）是这种新方法中的重要组成部分。为帮助人们追踪自己的数字标识，CardSpace 用不同的信息卡来表示每个数字标识。如果网站接受 CardSpace 登录，那么用户在尝试登录这一网站时会看到 CardSpace 选择屏幕，如图 3 所示。您可以选择一张卡片，这就相当于选择了登录该网站的数字标识。不必再去费心记住数不清的用户名和密码，用户只要记住他们要使用的那张信息卡就可以了。不同的信息卡还包含其他信息，用户可以通过它控制登录网站时提交的信息。

图 3

信息卡表示的这些标识是由一个或多个标识提供者创建而成的。组织可以有自己的标识提供者，而不必依赖于简单的用户名和密码。每个标识提供者都会采用更加强大的加密机制，让用户来验证他们的标识。CardSpace 本身也包含一个自发行的标识提供者，可以在客户端计算机上运行。使用这一提供程序，用户可以创建自己的标识，且标识也不必依赖密码进行身份验证。网站接受这些自发行 CardSpace 标识，这样就不必再依赖常见的密码方法，自然会减少因密码而带来的诸多问题。

不用密码登录网站，网页仿冒者也就无密码可偷了！但是，如果网页仿冒者成功诱使受害者访问假冒网站的话，他们还是会窃取用户的其他信息，如敏感的医疗信息等。要杜绝这种情况，就要求用户自己能够区别假冒网站和真网站。为帮助用户识别网站，拥有网站的组织应获取“高度确认认证”。与现在的 SSL 简单认证不同，新的认证方式涉及到更多、更严格的流程，其中包括采用更严格的方式来证明申请该项认证的组织的身份。高度确认认证上还可以带有公司徽标和其他信息，帮助用户准确识别使用证书的网站是否合法。用户访问新网站时，CardSpace 会始终以标准屏幕显示该网站的证书信息。根据认证的接受程度，屏幕上会自动显示出对网站标识的确认程度。其目的是，强制用户明确界定网站是否可信，然后帮助他们作出正确选择。

Windows CardSpace 实际上是更大的标识元系统的一部分。标识元系统完全基于开放的公共协议，它定义了一种全新的方式，能够使不同的数字标识技术在各个不同的平台（包括 Windows 以外的操作系统）和应用程序（包括 Internet Explorer 以外的 Web 浏览器）上使用。CardSpace 采取通用的方法来选择标识和其他 Windows 信息，因而在元系统中扮演着重要角色。并且，由于解决了基本的标识问题，CardSpace 也已经成为 .NET Framework 3.0 的重要组成部分。

Windows Presentation Foundation：适用于不同用户界面的统一方法

对几乎所有的应用程序来说，用户界面都是重要的组成部分。现在，用户对这些界面的要求越来越高了。当然，我们仍然需要传统的菜单驱动式 GUI。但是除此之外，许多应用程序还需要能够播放视频、运行动画、采用二维或三维图形，以及调用不同的文档。无论是通过安装的桌面客户端还是通过 Web 浏览器来访问应用程序，上述功能都必须可以正常使用。

一直以来，Windows 上的这些用户界面功能都是以不同方式提供的。例如，开发人员可以使用 .NET Framework 中的 Windows Forms 来创建 Windows GUI，使用 HTML、Java 小程序或 JavaScript 代码创建 Web 浏览器界面，或是使用 Windows Media Player、Adobe 的 Flash Player 等软件播放视频，文档格式则以 Microsoft Word、Adobe PDF 或其他软件进行定义。很明显，开发人员面临着巨大的挑战：如何使用不同的技术，为不同的客户端创建一致的用户界面。这相当困难。

Windows Presentation Foundation (WPF)，最初代号为“Avalon”，就是为解决这一难题而设计。WPF 为所有的这些用户界面提供一致的技术基础，从而大幅简化了开发人员的工作。WPF 采用更为现代的方法，支持视频、动画、二维或三维图形以及各种类型的文档，从而可以让用户以全新的方式处理信息。此外，WPF 还为桌面客户端和浏览器客户端提供了通用基础，大大简化了二者的应用程序开发工作。

让我们以图 4 中的界面（其中包含了图像、现场图、三维视图等等）为例说明 WPF 的部分功能。过去，开发人员需要懂得各种技术才能进行工作；而现在通过这种更为一致的方法，开发人员可以轻松制作出类似示例中的用户界面。

图 4

另外一个长期困扰用户界面开发人员的问题是，如何创建高效界面需要的不同角色。软件开发人员需要编写相应的界面逻辑，但是，他们并不是定义界面感观的最佳人选。一般来说，人机交互领域的设计人员和专家更适合这一工作。但是在以前的技术（如 Windows Forms）背景下，这些问题完全由开发人员决定。开发人员和设计人员之间没有实现真正有效的协作。WPF 借助于可扩展应用程序标记语言 (XAML) 解决这一问题。XAML 是一种基于 XML 的语言，允许以声明方式指定用户界面 －而非代码。这就，开发工具就能够根据设计人员创建的可视化显示，更加容易地生成和使用界面规范。实际上，Microsoft 的一款新产品 Expression Interactive Designer 就是为此而设计。使用这一工具（其他的由第三方提供），设计人员可以创建界面外观，然后生成他们所创建界面的 XAML 定义。开发人员将这些定义导入 Visual Studio 之后，就可以着手构建界面所要求的逻辑了。

开发人员创建了直接在 Windows 上运行的安装版 WPF 应用程序后，就可以使用 WPF 提供的全部功能了。但是，若要创建在 Web 浏览器内部运行的客户端程序，开发人员应创建一个 XAML 浏览器应用程序，我们通常称之为 XBAP。与安装版 WPF 应用程序的基本原理相同，XBAP 允许在可下载的浏览器应用程序中表示与用户界面相同的样式。两种应用程序可以使用相同的代码，这也就意味着开发人员不再需要针对桌面和浏览器客户端的不同技术集。特别是按照此类丰富 Internet 应用程序的现状，在安全沙箱内运行从 Internet 下载的 XBAP，将会限制应用程序的功能。但是，安装版 WPF 应用程序中提供的大量用户界面功能子集也可用于 XBAP。

WPF 安装版应用程序和 XBAP 都可以利用 WPF 的现代图形支持，其中包括使用硬件加速、支持矢量图形以及其他更多功能。通过提供更强大的图形支持功能，WPF 使得一系列数据可视化选项成为可能，而这依靠 Windows Forms 或其他的早期技术是不可能实现的。WPF 还提供了 XML Paper Specification (XPS) 的基础，可定义查看、分发和打印固定格式文档的标准格式。

用户界面是现代应用程序中复杂而重要的组成部分。通过 WPF，.NET Framework 3.0 提供了一种比较完整和一致的解决方案，用于应对用户界面方面的难题。其目标是使构建用户界面的相关人员（包括开发人员和设计人员）能够更有效的进行工作。

应用 .NET Framework 3.0：设想

理解一组技术如何协同工作的最好方式，就是查看其使用方式的示例。现在假设，一款应用程序要求客户和代理提交保单。如果使用 .NET Framework 3.0 执行，则会有图 5 所示的工作流程。

图 5

图表左上角所显示的应用程序业务逻辑，是使用 WF 工作流得以实现的。处理保单是一项多步骤流程，包括根据组织的保险规则来评估此保单，或许要检查投保人的信用，甚至还要获得其上司的批准。工作流依靠所需要的其他软件，以活动方式实现流程中的每一个步骤。如果要访问存储数据，工作流中的活动可以使用 ADO.NET。

保险公司可以提供一个呼叫中心，使客户可以通过电话进行投保。呼叫中心员工使用的客户端软件显示在图表的右上角，是由安装版 WPF 应用程序实现的。客户端使用 WCF 与应用程序业务逻辑进行通信，采用的是经过 WCF-WCF 通信优化的二进制协议。如图所示，呼叫中心工作人员依靠 Windows CardSpace 来选择他们在登录该应用程序时将要使用的标识。

客户还可以通过网络进行投保，而保险代理商也可以通过网络提交保单。为便于网络操作，该应用程序使用 ASP.NET 与 Web 浏览器进行通信。如图表的左下角所示，客户通过 Internet Explorer 来访问该应用程序，他们可以使用普通的 HTML 界面，也可以使用 CardSpace 来选择自主设定的标识。第三方也可以为其他客户端操作系统和浏览器实现标识选择机制，使得标识元系统能够扩展至非 Windows 客户端和 Web 浏览器。

保险代理商通过 Internet 访问该应用程序时可能需要具有更多功能的界面。因此，他们应该使用 XBAP 而非简单的 HTML 界面。如图表底部中间位置所示，这些客户可以共享呼叫中心所用 WPF 桌面应用程序提供的大部分用户界面功能。由于两者构建在同一基础之上，因此应用程序开发人员可以在两种类型的客户端中重复使用相同的代码。对于其他类型的客户端来说，代理商可以使用 CardSpace 选择他们针对该应用程序所设定的标识。

最后，此应用程序有可能需要与其他应用程序之间进行互访。如果批准客户时要求信用审核，则最有可能通过调用外部服务实现。或者此应用程序会直接收到外部软件请求，提供这些外部应用程序可以调用的服务。在这些情况下，如图表右下角所示，该应用程序依靠 WCF 使用标准 Web 服务进行通信。无论这些应用程序构建于何种技术之上，WCF 对 SOAP 的支持都使得这些应用程序之间的交互变得轻而易举。

该方案说明了如何使用 .NET Framework 3.0 中最重要的组件来构建出色的应用程序。而此处所举的简单示例省略了相当多的选项，因此不能将其视为该系列技术所有功能的完整说明。相反，该示例只是提供一种思路，用于讲解如何使用 .NET Framework 3.0 的不同部分来解决实际的业务问题。

了解 .NET Framework 3.0：技术

更深入地研究 .NET Framework 3.0 的各项构成技术，对于真正了解 .NET Framework 3.0 的功能会很有帮助。本节分别为 .NET Framework 3.0 的五个部分提供了一个简明教程。有关各部分的更详细介绍，请参阅本文末尾的“更多参考资料”。

.NET Framework 2.0

图 6

.NET Framework 2.0 是目前 Windows 开发的基础，同时也是 .NET Framework 3.0 的基础。图 6 介绍了 Framework 的两个组成部分：公共语言运行库 (CLR) 和 .NET Framework 类库。.NET Framework 3.0 的一些组件，包括 WF、WCF 和 WPF，基本上都作为 .NET Framework 类库的扩展而执行。如前文所述，类库的许多部分仍然是开发人员所使用的重要部分，而其他部分则被包含到 .NET Framework 3.0 提供的新技术中。例如，ASP.NET 仍然是创建浏览器可访问的应用程序的基础，ADO.NET 仍然用来与存储数据配合使用。.NET Framework 3.0 开发人员使用 WPF 而非 Windows Forms 来创建本机 Windows GUI，但与 ASP.NET Web Services、.NET Remoting 或 Enterprise Services 相比，他们通常更喜欢 WCF。尽管存在这些变化，但也应该了解即使在 .NET Framework 3.0 世界中，早期版本的 Framework 仍然是开发人员所使用的核心部分，这一点非常重要。

Windows Workflow Foundation

由工作流驱动的、面向流程的设计，是 Windows 软件重要部分的正确开发方式。WF 的目的是让开发人员创建并执行这些基于工作流的应用程序。图 7 显示 WF 提供的用于进行该项工作的组件。

图 7

如前文所述，每个工作流都通过一定数量的活动创建。工作流和活动都属于类，所以两者均可由代码直接创建。WF 也提供了工作流设计器，这是一个用于构建工作流的 Visual Studio 托管图形工具。但是创建工作流后，其活动就可以从 WF 附带的基本活动程序库 (BAL) 或其他任何来源得到。

一旦定义了一个工作流，最终就会由 WF 运行时引擎来执行。该引擎所依赖的是一组运行时服务，用于保持工作流状态、跟踪工作流执行等。运行时服务、运行时引擎和工作流本身，所有这些都包含在某个主机进程中。该进程可以是任何 Windows 进程，从正在桌面上运行的简单的控制台或 WPF 应用程序，到可扩展的服务器进程。

要了解 WF，需要至少具有一点其组件的知识。以下部分将对各组件进行简述。

工作流

从本质上说，工作流就是一组活动。WF 对两种样式的工作流提供内置支持：

可以按定义的顺序执行活动的顺序工作流。类似于传统的流程图，顺序工作流中包含分支、循环和其他控制结构。但默认情况下，活动会按顺序依次执行。

可以实现传统有限状态机的状态机工作流。类似于任何的状态机，特定时间所执行的活动由当前状态和已收到的事件共同决定。

顺序选项可用于定义明确的工作流，例如完全基于软件的进程中的工作流。创建并理解这些工作流相对简单，而且一开始就让大多数开发人员觉得非常容易。当执行路径不太容易预测时，可以选择状态机工作流。一个典型的例子就是涉及与人进行交互的工作流，任何人在任何地方都可以取消该工作流。通过顺序工作流可应对该状况，但每个步骤都会成为一个分支：若工作流未取消，则应该执行；若已取消，则应该执行其他活动。使用状态机对这种行为建模会简单许多，因为取消工作流的请求恰恰是另一个可以在任何时间接收并处理的事件。

对状态机工作流的支持，是 WF 如何尝试为人和系统工作流提供支持的一个例子。另一个相关的例子是，WF 对更改正在运行的工作流的支持。人的要求千变万化，某个工作流的相关人员，在进程运行当中添加步骤、删除步骤或进行其他更改的行为并不罕见。为了以受控方式适应这种状况，WF 允许创建工作流的开发人员在执行工作流时指明是否要修改以及如何修改。

基本活动程序库

开发人员可以随意创建自定义活动。事实上，Microsoft 的目标是促进满含可重用活动的 WF 生态系统的开发。而且，从一个普通的基本活动集着手会让每个人都觉得更加容易。基本活动程序库 (BAL) 的作用就是提供这个普通集。

无论使用 BAL 中的哪些活动，工作流都不是必需的。而且，许多开发人员会发现 BAL 使他们的工作变得更简单，尤其是在开始的时候。BAL 中包含的活动如下：

• IfElse：根据是否满足某个条件，执行两个或更多可能路径中包含的活动。

• While：只要某个条件为真，就反复执行一个或多个活动。

• Sequence：以定义的顺序，一次执行一组活动。

• Parallel：并行执行两组或多组活动。

• Code：执行定义的代码块。

• Listen：等待一个特定事件，收到后再执行一个或多个活动。

• InvokeWebService：调用一个 Web 服务。

• state：表示工作流状态机中的一个状态。

• EventDriven：定义包含一个或多个活动的转换，该转换需处于特殊状态，并在收到特定事件后执行。

• Policy：允许使用 WF 提供的规则引擎定义并执行业务规则。

WF 采用了较一般的方式来使用活动，而并非为指定的工作流定义特定语言。BAL 提供了一种“语言”，但任何人都可以使用 WF 随意定义自己的语言。

Windows Workflow Foundation 工具：工作流设计器

使用工作流创建应用程序的一个优势是可以图形化地定义工作流。WF 的工作流设计器允许使用该功能，如图 8 所示。默认情况下，开发人员可将工具框中出现的 BAL 活动拖放到该工具的设计界面上，以创建工作流。

图 8

一些开发人员不喜欢图形设计器，他们更愿意编写代码。WF 也允许使用这种方法（并且有时需要该方法：一般是直接从代码构建的活动）。也可以将这两种方法结合使用，如同时使用工作流设计器和直接编码的方法创建工作流。其目的是让开发人员使用最有效率的方法。并且为实现更广泛的工具支持，也可以通过 XAML 语言表达工作流，这也是 WPF 所使用的语言。事实上，使用工作流设计器创建的工作流默认为是 XAML 定义的。

运行时引擎和运行时服务

如前文所述，WF 运行时引擎具有执行工作流中的活动的职责。作为执行该职责的一个部分，它依赖于一组运行时服务。WF 包含这些服务的标准实现，但是有能力的开发人员可以根据需要更换。这些服务支持几种不同的功能，其中有两种最值得注意：

• 持久性：因等待某个事件受到阻塞的工作流，可以使用该服务将其内存状态自动保存到磁盘。当事件发生时，该服务会自动重新加载工作流的状态并重新开始执行。这对于涉及到人员的工作流尤其有用，因为等待一个响应可能需要几个小时、几天或更长时间。

• 跟踪：工作流中的活动清楚地区分了其实现进程的执行。WF 的跟踪服务允许开发人员将工作流的执行信息自动写入数据库中。例如，开发人员希望跟踪工作流的起始时间、它的每个活动的起始时间和其他信息。

Windows Workflow Foundation 和其他 Microsoft 技术

引入新方法肯定会影响现有方法。.NET Framework 3.0 中的新技术也不例外，每项技术都会对 Microsoft 的其他技术产生影响。当使用 WF 时，对 Windows SharePoint Services、Microsoft Office 2007 系统和 BizTalk Server 的初始影响最大。

为了使开发人员更容易地创建文档合作和其他种类信息共享的工作流应用程序，3 版 的 Windows SharePoint Services 托管了 WF 运行时。Office SharePoint Server 2007 是 Office 2007 系统的组成部分，基于 WF 支持，构建于 Windows SharePoint Services 中。此外，添加该服务器后，就可以直接在 Office 2007 客户端应用程序中显示 InfoPath 窗体，而且可以在一些普通方案（如批准一个文档）中使用一组预定义的工作流。

任何熟悉 BizTalk Server 的人现在一定已经注意到了该产品的编排功能和 WF 提供功能之间的相似性。事实上，BizTalk Server 2006 发布后，将通过 WF 替换该产品现有的编排功能，并提供可帮助将现有编排服务迁移到 WF 工作流的工具。但有一点很重要，即应了解 WF 和 BizTalk Server 2006 解决的问题是截然不同的：

• WF 提供了一个通用框架，用于创建基于工作流的 Windows 应用程序。它可以被托管在任何进程中，使用任何种类的活动，并解决任何种类的业务问题，其中包括人员和系统工作流。

• BizTalk Server 是面向企业应用程序集成、企业对企业集成和管理业务流程的许可产品。它提供了大量用于连接不同系统和软件的适配器、用于实现诸如 RosettaNet 和 SWIFT 等标准的加速器以及对企业活动监控的支持。BizTalk Server 还提供了管理基础结构和工具，以及对增长的可扩展性的支持。

因为它是 Windows 标准的工作流技术，因此 WF 以后很可能会出现在其他 Microsoft 产品和技术中。无论 Microsoft 做出什么样的选择，在客户创建的大量应用程序中都肯定会出现 WF 的身影。

Windows Communication Foundation

面向服务的通信的变化，标志着在应用程序交互方式上的进步。WCF 专为支持面向服务的应用程序而设计，正好体现了这种进步。本节将介绍 WCF 最重要的方面，包括服务和客户端、通信选项以及对安全性、可靠通信和事务的支持。

服务和客户端

图 9

如图 9 所示，WCF 的基本思路很简单：服务提供了客户端可访问的接口。该接口可通过 Web 服务描述语言 (WSDL) 来定义，然后转成代码，也可以通过 C# 或 Visual Basic 等语言直接定义。对于一个提供保险应用程序服务的简单接口而言，若使用后一种方法，则代码如下所示：

[ServiceContract]interface IInsuranceApplication{ [OperationContract] int Submit(int policyType, string ApplicantName); [OperationContract] bool CheckStatus(int applicationNumber); [OperationContract] bool Cancel(int applicationNumber);}

C# 接口的定义用 ServiceContract 属性来标记。该属性表示 WCF 可在该接口中提供进行远程调用操作的方法。所提供的接口方法都标有 OperationContract 属性。在上述简单示例中，每个方法都标有该属性，因此都可以提供给远程调用者。但这并不是必需的，仅为接口的某些方法应用 OperationContract 是合法的。无论进行哪种选择，应用程序中必须有一个类实现该接口，从而为接口定义的方法提供实际代码。一旦完成，WCF 会自动将方法标记为 OperationContract，表示该服务的客户端可对其进行访问。

关于服务如何被实际提供给其客户端，图 10 给出了比较详细的介绍。客户端不直接访问接口，而是连接到特定的端点。服务可以提供多个端点，从而允许不同的客户端以不同方式进行访问。

图 10

如图所示，每个端点都具有以下三个属性：

• 合约，说明使用该端点可以调用的操作。该合约只需使用定义这些操作的接口名即可识别，此处是 IInsuranceApplication。

• 绑定，定义如何调用端点的操作。每个绑定都可定义数个方面，包括使用什么协议来调用操作、使用哪类安全性等。WCF 中包含许多预定义绑定，如此处显示的 BasicHttpBinding，这是最常见的例子，用户也可以定义自定义绑定。单个服务可以提供多个端点，所以可通过不同协议、使用不同安全性选项，同时访问不同种类的客户端。

• 地址，表示端点的位置。如图所示，位置是以 URL 表示的。

WCF 的基础很简单。与大多数通信技术一样，细节可以很复杂，因为具有许多选项，但是创建一般的 WCF 应用程序并不难。

通信选项

由不同类型的开发人员构建的不同种类的应用程序，需要以不同的方式进行通信。对大多数开发人员而言，最简单的方式是远程过程调用 (RPC)，它可以使客户端可以像调用本地操作那样调用远程操作。例如，假设是上文所示的接口，客户端可通过一般同步的方式调用任何操作，并耐心等待返回响应。该选项对开发人员而言很容易，在某些情况下是正确的选择。

但是，WCF 还提供了其他几个选项。如下所示：

• 调用没有响应的操作。该类通信标有属性 OneWay，对于发送事件或其他单向交互很有用。

• 基于消息的异步通信，直接发送和接收 XML 消息。

• 显式处理 SOAP 消息，包括直接在 SOAP 标头中插入元素。

WCF 还允许开发人员控制服务进行的各种本地形式。例如，使用 ServiceBehavior 属性，可用来设置服务是单线程还是多线程的、是否为每次调用创建新的服务实例以及其他选项。

安全性、可靠性和事务

基本通信，即系统间的数据移动功能，它非常有用，但却远远不够。大多数应用程序还需要其他功能。例如，大多数分布式应用程序需要某种安全性。从今天使用的不同方法和技术多样性看来，安全性的提供可能非常复杂。为了使开发人员在不必了解所有细节的情况下创建安全的分布式应用程序，WCF 主要依赖于安全性绑定。例如，上文所示的 BasicHttpBinding 可以配置为使用 HTTPS 而不是普通的 HTTP，其他绑定则提供了更多的安全性选项。例如，WsHttpBinding 支持 WS-Security，允许基于 SOAP 的交互验证、数据完整性和数据机密性。开发人员还可以创建自定义绑定，以提供其应用程序所需的相同的安全性服务。

对于许多应用程序而言，确保通信的可靠性也非常重要。传统的 Web 服务方法，即通过 HTTP 发送 SOAP，在某些情况下完全可以胜任，当使用 BasicHttpBinding 时会用到该方法。但在大多数情况下，这种广泛使用的方法显得力不从心。例如，经由一个或多个 SOAP 中间方传输的消息不能靠这种简单的方法实现端对端的可靠性。这些情况下，WCF 将执行 WS-ReliableMessaging。开发人员可以选择一个支持该选项的绑定，如 WsHttpBinding，从而传输交互可靠的消息。

在某些应用程序中，分布式事务也很重要。WCF 构建于 System.Transactions 之上，是 .NET Framework 2.0 的组成部分，允许创建事务性软件。方法可以使用 OperationBehavior 属性指示其所需事务并定义该事务的进行方式。WCF 依赖于 WS-AtomicTransaction 规范，允许分布式事务跨供应商边界进行交互。使用该多供应商协议定义的技术，WCF 应用程序可以参与涉及多项技术（包括 J2EE 及其他）的事务。

Windows Communication Foundation 和其他 Microsoft 技术

如前文所述，WCF 取代了一些用于创建分布式应用程序的早期 Microsoft 技术。大多数使用 ASP.NET Web Services、.NET Remoting、Enterprise Services、System.Messaging 或 WSE 构建的应用程序，将转而通过 WCF 进行构建。WCF 应用程序可以与 ASP.NET Web Services 应用程序交互，两者都支持标准 SOAP，也可与其他构建在 Enterprise Services、MSMQ 和 3.0 版的 WSE 上的应用程序交互。BizTalk Server 2006 也可以使用 WCF，而且未来版本的 BizTalk Server 会更直接地构建在 WCF 提供的架构上。

有一点非常重要，即使新的 .NET Framework 3.0 应用程序不常使用 WCF，但其取代的所有技术仍是该版 Framework 的组成部分，而且仍被照常支持。使用这些技术的早期版本构建的应用程序，还会继续正常运行；安装和使用 .NET Framework 3.0 不会破坏现有代码。

Windows CardSpace

无论是通过 Web 浏览器还是其他种类的客户端，用户通常会跨网络访问应用程序。这些应用程序通常需要用户以某种方式标识自己，因此结果肯定是人们必须定期获取并提供远程软件的标识信息。通过浏览器访问 Internet 应用程序，就是一个很常见的示例，内联网上的用户通常也会面临该问题。

如前文所述，现在多数人经常依赖用户名和密码进行数字识别，由此产生了诸多问题。Windows CardSpace 作为较大的标识元系统的组成部分，提供了解决这些问题的可选方法。若要更深入地了解 CardSpace 是如何实现的，应从了解标识元系统的基本概念入手。

Windows CardSpace 和标识元系统

当用户访问应用程序时，无论所使用的是 Web 浏览器还是应用程序特定的客户端，或者其他形式，一般都会提供某种数字标识。数字标识各种各样，但实际上都可由网路上的一个安全令牌表示。简单的安全令牌可能只是一个用户名，复杂的令牌则可能包含一个 X.509 证书或一个 XML 文档。无论通过何种方式，安全令牌都是目前网络上表示数字标识的典型机制。

我们可以美好地憧憬，总有一天所有人都会采用相同的安全令牌格式，但实际上各种方式仍将继续使用。现在我们会在钱包中携带各种标识卡，如驾驶执照、信用卡、航空公司常飞旅客积分卡等，与此类似，我们会始终使用由各种安全令牌表示的数字标识。没有单个标识系统可以提供通用的方案，所以多个安全令牌将始终是必需的。

然而，用户仍需要某种方式来一致地处理不同的数字标识。即使没有单个标识系统可以胜任，也可以创建一个标识系统的子系统，即标识元系统，从而以一致的方式使用各种数字标识。Microsoft 与其他公司通力协作，引领着定义该元系统的进程。该元系统基于开放的 Web 服务技术，如 WS-Security 和 WS-Trust 等，可定义数字标识的获取与使用方式，而无需考虑其所依赖的安全令牌类型。

发行、获取和使用数字标识的过程可以视作是获取三个不同角色的过程。这些角色如下：

• 用户：有时称为主体，用户是具有数字标识的实体。

• 标识提供者：标识提供者可以为用户提供数字标识。例如，对雇主分配给您的数字标识而言，标识提供者一般是诸如 Active Directory 的系统。对于您使用的 Amazon 数字标识而言，标识提供者将只对您有效，因为您可以定义自己的用户名和密码。不同标识提供者所创建的数字标识可以包含不同的信息，并提供不同的用户真实身份保证级别。

• 依赖方：依赖方是一个应用程序，以某种方式依赖于数字标识。依赖方将频繁使用标识（即该标识安全令牌中包含的信息）来验证用户，然后作出授权决定，如批准该用户访问某信息等。依赖方也会使用该标识获得信用卡号，来验证不同时间或出于不同目的而进行访问的同一用户。依赖方的典型示例包括 Internet 网站，如银行、网上商店和拍卖站点，以及其他通过 Web 服务接受请求的所有应用程序。

这三种实体在标识元系统中进行交互。图 11 说明了这种交互作用，以及 CardSpace 的适当位置。

图 11

用户通过 CardSpace 识别应用程序访问依赖方时，这一过程就会开始。要了解此依赖方将请求哪种类型的安全令牌，应用程序必须取得依赖方的策略（步骤 1）。以用于访问网站的浏览器为例（这可能是最常见的情况），站点策略的表达方式为 HTML，并作为网页的一部分发送回来。但是，对于通过 Web 服务访问的应用程序来说，应用程序将改为使用由 WS-MetadataExchange 定义的行业标准协议来向依赖方请求获取其策略。在这种情况下，该策略使用另一种行业标准 WS-SecurityPolicy 来表示。无论以何种方式获得策略信息，都会始终指明该依赖方将会接受的安全令牌类型，以及这些令牌中所必须包含的信息。

一旦 CardSpace 了解到依赖方需要的安全令牌类型后，会显示之前所示的标识屏幕。对该用户可用的每个数字标识在此屏幕上表示为一个信息卡。由外部依赖方发行的卡称之为受管卡，而由 CardSpace 自发行提供程序发行的卡称之为自发行卡。两种卡都在此屏幕上显示，用户可以任选其一。为了更加方便做出选择，屏幕会将所有不符合要求的信息卡显示为灰色，从而指示出能够满足依赖方要求的标识。然后，用户就可以从中任意选择一个作为要使用的数字标识（步骤 2）。

但是，卡中并不包含实际的安全令牌。相反，它含有的是用于查找特定标识提供者以及为该用户请求安全令牌所必需的信息。（实际上，所有信息卡最初都是由某些标识提供者创建的。）CardSpace 以用户所选信息卡中包含的内容向发行此卡的标识提供者请求安全令牌（步骤 3）。该请求是使用另一种行业标准协议 WS-Trust 发出的，并且用户使用 Kerberos（X.509 证书和数字签名）或另外一种机制来向标识提供者进行自我身份验证。令牌以加密形式返回，其中还包含了一个时间戳，以防止令牌被盗并于日后重新使用。

请求的安全令牌返回后会发送到依赖方（步骤 4）。依赖方使用令牌信息的方式有所不同。例如，如果令牌中包含一个 X.509 证书，并附带数字签名，则依赖方将有可能使用令牌来验证用户。但是，使用令牌验证或进行其他任何安全相关目的操作时没有任何要求。（实际上，术语“安全令牌”本身就是用词不当。）令牌中可以含有如用户年龄证明、购物网站享受优惠资格以及其他信息。身份验证是安全令牌一种重要但非唯一的使用目的。

需要十分注意的是，作为整体来讲，无论是 CardSpace 还是标识元系统都不了解用于安全令牌的格式或技术。元系统的目标是提供一致的方法来使用基于任何类型安全令牌的所有数字标识，而不仅仅是尝试为数字标识创建新的单一源或为安全令牌创建标准格式。通过提供元系统关键部分的 Windows 实现，CardSpace 在实现数字标识的常规方法过程中扮演着一个很重要的角色。

防止网页仿冒

标识提供者通常与用户不同，例如在标识由雇主分配时。但是在很多情况下，标识提供者即为用户自身。例如，如果没有使用 CardSpace，则访问许多网站都需要提供用户名和密码，而这两者都是由用户定义的。一旦用户创建标识之后，他们就可以将其用于提供用名和密码，然后可以查询银行余额、购买书籍或进行站点允许的其他任何操作。

但是如上所述，由于他们仍然依赖密码，所以这种自发行标识容易成为攻击者的目标，。为帮助减少此类攻击，CardSpace 提供了另外一种创建自发行标识的方法。该自发行标识提供者在用户的 Windows 系统上本地运行。自发行标识提供者创建的安全令牌不是依赖于用户名和密码，而是使用安全声明标记语言（SAML，一种 OASIS 定义的标准）进行定义。这些令牌依靠公钥技术而不是依靠密码来验证用户标识。如果依赖方接受他们，则他们就可以起到与传统用户名和密码相同的作用。好处是将不再存在网页仿冒者可以盗取的密码。减少密码的使用，再有如上所述高度保险认证提供更严格的网站标识证明，能够大幅降低网页仿冒所造成的危害。

Windows CardSpace 和其他 Microsoft 技术

CardSpace 涉及到数项其他 Microsoft 技术，其中包括：

• WCF：由于依赖 Web 服务标准，例如 WS-Security 和 WS-Trust，因此 CardSpace 使用 WCF 进行通信。实际上，WCF 应用程序的创建者只需指定一个特别绑定，就可以让该应用程序使用 CardSpace。

• Active Directory：虽然现在还无法实现，但 Active Directory 终将成为元系统中的一个标识提供者。

• Windows Live ID（以前称为 Passport）：正如 Active Directory 一样，Microsoft 业已宣布会将 Live ID 验证系统修改为一款标识提供者。请注意，不能使用 CardSpace 来代替 Live ID，因为这两者用于解决完全不同的问题。相反，正如其他任何标识提供者一样，Live ID 将成为标识元系统的一部分。

Microsoft 还提供其他标识相关技术，用以解决与 CardSpace 不同的问题。例如，Active Directory Federation Services (ADFS) 主要关注于组织之间的联合标识。这是一项重大的挑战，许多需要与其他组织合作的公司都面临着这一挑战。但是，此问题与 CardSpace 和标识元系统所解决的更广泛的问题完全不同。

Windows Presentation Foundation

基于工作流的逻辑、面向服务的通信和标识都是现代应用程序中的重要组成部分。但是，用户通常最关注的是他们所看到的：用户界面。WPF 的目的是为了解决现代应用程序中创建用户界面所遇到的挑战。WPF 提供了一系列相应功能来满足这些需求，如下所述。

Windows Presentation Foundation 功能

开发人员完全可以使用 C#、Visual Basic 或一些其他基于 CLR 的语言来自由构建 WPF 应用程序界面。但是，如前文所述，WPF 也允许使用基于 XML 的 XAML 来指定界面。XAML 中的元素和属性可直接映射到 WPF 提供的类和属性。例如，在下面的简单示例即使用 XAML 来定义按钮：

<Button Background="Red"> No</Button>

该示例创建了一个包含文本“No”的红色按钮。使用如下代码也可以达到完全相同的效果：

Button btn = new Button();btn.Background = Brushes.Red;btn.Content = "No";

无论如何定义，实际上所有 WPF 应用程序都遵循相同的基本模型。应用程序可继承 WPF 的标准应用程序对象，以提供基本方法、事件和属性。WPF 应用程序既可以拥有传统的对话框驱动界面，也可以拥有导航式界面，其功能更类似于一个浏览器应用程序。以后者样式构建的应用程序通常作为一组页面实现，每个页面中包含以 XAML 定义的用户界面和以代码定义的某些逻辑关系。为了将这些页面链接在一起，XAML 还提供了一个与 HTML 十分类似的超链接元素。应用程序每次显示一个页面，可使用户在这些页面之间前进或后退、维护历史记录列表以及其他功能等。尽管不需要，导航应用程序还是可以作为 XBAP 在 Web 浏览器内运行；开发人员也可以在安装版 WPF 应用程序中自由使用该界面样式。其目的是构建出融合浏览器界面与本地 Windows 界面最佳特点的软件。

无论其界面使用哪种样式，WPF 应用程序都可以通过面板进行基本布局。每个面板通常包含多个控件，这些由 WPF 提供的控件包括按钮、文本框、组合框、菜单以及其他对象。这些控件如何放置取决于所选择的面板类型。例如，Grid 允许将控件放在指定的网格上，而 Canvas 则允许开发人员将控件放在其界限范围内的任何位置。在 GUI 中，通常用户生成的事件由应用程序中的不同控件和其他类进行捕获和处理。还可以将样式和模板应用到控件组，这样就可以非常容易使应用程序具有一致的外观。

WPF 的支持范围远远超出了上述的基本用户界面功能，还包括：

• 文档：WPF 应用程序可以使用 XAML 的 FixedDocument 标记来显示 XPS 文档。也可以使用 FlowDocument 标记来显示流文档。流文档与传统的屏幕文档类似，能够让用户滚动浏览其内容。另外，开发人员通过设置此标记的不同属性，可以使文档更适应其环境。例如，文档可以每次显示一页，这样读者就不必上下滚动页面了。WPF 还能够根据显示文档的窗口大小来自动确定应该把文档拆分成多少列。其目的是尽量提高屏幕上文档的可读性。

• 图形：WPF 还支持创建二维和三维矢量图形。对于二维作业，WPF 可提供标准抽象，例如形状、画笔和绘图笔，同时还允许三维图形定义模型，以用于指定光线和摄像机位置信息。与早期技术（例如 Windows Forms 需要依赖于 GDI+ 才能绘制图形）不同的是，WPF 图形并不是使用开发人员所必须了解的单独一组概念来进行分区的。相反，用于图形的 XAML 元素能够与那些用户界面其他方面的元素自然组合。按钮可带有图形内容，文本和图形可以组合，以及其他更多功能。

• 图像：使用 XAML 的图像标记，WPF 应用程序可以显示不同格式的图形，包括 JPEG、GIF 以及其他格式。WPF 依靠 Windows Imaging Component (WIC) 为编解码器以及显示和存储图像的软件提供标准框架。在 WPF 中，通常图像元素可以与其他元素组合，能够让按钮显示图像而不是简单的文本标签。

• 媒体：WPF 应用程序可以使用 MediaElement 标记来显示不同格式的视频和音频，包括 WMV、AVI 和 MPEG。同样，此元素也可与其他 XAML 元素相组合，例如使三维立方体的所有侧面上都显示视频。

• 动画：WPF 提供动态显示绝大部分用户界面的内置支持。例如，放大和缩小圆圈、顺利地更改按钮大小。应用程序还可以定义包含时间线的情节提要，允许调整动画的发生顺序。

• 数据绑定：由于许多 WPF 应用程序都需要显示数据，因此提供将数据映射到用户界面元素的自动支持功能是很有帮助的。WPF 可为包含在对象和其他源中的信息提供此类数据绑定。WPF 数据绑定还允许在显示数据前对其进行排序和筛选。

Windows Presentation Foundation 的应用

WPF 提供大量的用户界面功能，使开发人员和设计人员可以创建出非常吸引人的用户界面。但是无论客户端应用程序看起来有多漂亮，如果存在部署问题的话，可能会使某些组织拒绝使用。如果推出的新版本客户端涉及到安装此应用程序的每台桌面电脑，则会导致高额的升级成本。现在，避免此问题的一个常用方法是创建基于浏览器的客户端，而不是本地 Windows 客户端。然而与浏览器相比，本地 Windows 客户端通常拥有更好、响应更及时的用户界面。为解决部署这些客户端时所面临的难题，就需要使用 ClickOnce 技术准备好安装版 WPF 应用程序。ClickOnce 技术第一次应用于 .NET Framework 2.0，可使 Internet Explorer 用户通过 Web 选择应用程序，然后将其自动安装在本地计算机上。安装之后，应用程序还能够在出现可用的新版本时进行自动更新。目的是将 Web 客户端的简单性和低成本部署与安装版 WPF 应用程序强大功能结合起来。

尤其是在使用 ClickOnce 进行部署时，安装版 WPF 应用程序在许多情况下都是很好的客户端选择。但即使其用户可以从 WPF 界面中获益，也存在不适用此类应用程序的情况。例如，回想一下上述的远程保险代理商，或者希望提供三维图形、视频以及其他 WPF 现代功能的网上商店。奢望此类应用程序用户通过安装本地 WPF 应用程序来访问网站通常是不切合实际的。更佳的解决方案是在用户的 Web 浏览器内提供 WPF 样式的界面。

XAML 浏览器应用程序 XBAP 即是针对这一问题而专门设计的。Internet Explorer 用户可以将 XBAP 直接下载到浏览器，而不必部署安装版 WPF 应用程序。此应用程序在 Internet Explorer 内运行，可以提供基于 WPF 的用户界面。但是从 Internet 网站下载和运行代码是一项危险的操作。为保护用户免遭恶意开发者的攻击，所有从 Internet 下载的 XBAP 都在部分信任沙箱中运行。基于 .NET Framework 提供的代码访问安全性，该沙箱会限制 XBAP 的操作。例如，从 Internet 下载的 XBAP 不能创建独立窗口或启动新窗口，不能显示由 XBAP 本身启动的保存对话框或访问隔离存储区以外的文件系统。尽管沙箱规定了种种限制，XBAP 仍然可以使用大部分的 WPF 功能，包括二维和三维图形、动画、屏幕文档、图像、视频等。

如前文所述，WPF 可使用 XAML 的 FlowDocument 元素让应用程序显示适合的文档。显然，基于显示方式而更改文档外观并不总是最好的解决方案。有时，固定格式文档（在屏幕上和打印出来的效果始终相同）会是更好的选择。WPF 的 XPS 文档可解决这一问题。使用 XAML 子集予以定义之后，可以在安装了 XPS 阅读器的任何系统上阅读 XPS 文档。此外还提供了一种新的 Windows 打印格式，能够以更高的保真度来打印复杂图形。为了更加一致地与不同类型的文档配合使用，XPS 文档和 Office 2007 文档都使用了 Microsoft 的“开放打包约定”，其中定义了存储文档内容、数字签名文档以及其他操作的常用方法。

Windows Presentation Foundation 工具

使用基本的文本编辑器就可以直接以代码和/或 WPF 来创建任何的 WPF 用户界面。但大多数人还是倾向于使用更好的工具，因此 Microsoft 提供了 Visual Studio 2005 的扩展，开发人员可以基于此来构建 WPF 应用程序。Visual Studio 的下一个版本（代号为“Orcas”）仍将为 Windows Presentation Foundation 提供更多的可视化设计器功能。使用该工具，开发人员能够以图形方式创建他们所希望的用户界面，然后用工具生成此界面的代码。

但是一般来讲，开发人员不是定义用户界面的最佳人选。设计人员通常更擅长此类工作，因为他们的工作就是与人交流。问题在于绝大多数设计人员并不编写代码，因而 Windows Presentation Foundation 可视化设计器（位于 Visual Studio 内）不是适用于该团队的有效工具。为了保证设计人员在 WPF 环境下的高效工作，Microsoft 推出了 Expression Interactive Designer。设计人员可以使用该工具来执行定义界面感观、指定动画等操作，然后将所创建内容生成 XAML 版本。开发人员将此 XAML 版本导入 Visual Studio 之后，就可以为事件处理等内容添加代码。由于 Visual Studio 和 Expression Interactive Designer 使用相同的生成系统，因此开发人员和设计人员可以使用其各自熟悉的工具反复处理一个项目。其目的是帮助来自设计与软件工程这两个不同学科的人员高效地协同工作。

Windows Presentation Foundation 和其他 Microsoft 技术

与其他 .NET Framework 3.0 组件一样，WPF 对现有 Microsoft 技术也有所影响。其中受到影响最大的有：

• Windows Forms：.NET Framework 最初用于创建 GUI 的方法，现在许多应用程序中都用到 Windows Forms。考虑到这一点，WPF 应用程序中允许托管 Windows Forms 控件，同时允许在 Windows Forms 应用程序中托管 WPF 控件。例如，Windows Forms 应用程序中可以托管能够提供三维数据可视化的 WPF 控件。虽然有一些限制，但是肯定可以同时使用这两种技术来构建应用程序。另请注意，现有 Windows Forms 应用程序仍可在 .NET Framework 3.0 环境中正常工作。

• Win32 和 Microsoft 基础类 (MFC)：与 Windows Forms 一样，可以在使用这些现有技术构建的现有 Win32 和 MFC 应用程序中托管 WPF 控件，反之亦然。但是其互操作性与 Windows Forms 相比有些复杂，原因是与 Windows Forms 的不同之处在于，基于 Win32 和基于 MFC 的应用程序并不是构建在 CLR 之上。因此，与 WPF 之间的互操作性还要求基于 CLR 的代码与本地 Win32 代码之间建立映射。

• Direct3D：是 API DirectX 系列的组成部分，其作用是使应用程序创建和显示三维图形。随着 .NET Framework 3.0 的面世，主流 Windows 应用程序都可以使用 WPF 中的三维功能，而不只局限于 Direct3D 提供的更专业方法。但一些需要较高性能的应用程序（例如三维游戏）仍将继续使用 Direct3D。实际上在后台，WPF 仍依靠 Direct3D 来完成所有的图形渲染工作。

• Windows Communication Foundation：如上所述，WPF 应用程序可以使用 WCF。但是，XBAP 通常无法使用 WCF，因为 WCF 需要完全信任才可正常运行。从 Internet 下载的每个 XBAP 都在部分信任沙箱中运行，这就禁止了 XBAP 访问 WCF。但是，XBAP 能够使用 ASP.NET Web 服务来调用可与 WCF 和其他 Web 服务实现交互的 SOAP。

• “WPF/E”：WPF 值得一提的另一个方面，尽管没有包含在 .NET Framework 3.0 之内。其代号为“WPF/E”，目的是在本身不支持 WPF 的系统中提供 WPF 样式界面支持。顾名思义，“E”表示该技术可用于任何地方，包括 Macintosh、小型设备以及其他系统。WPF/E 计划于推出 WPF 之后的某个时间发布，将提供全部 WPF 功能的一个子集，其中包括二维图形、动画和视频。

获取 .NET Framework 3.0：不同选项

对于要使用 .NET Framework 3.0 的应用程序，必须将此版本的 Framework 安装在运行该应用程序的计算机上。这对于 Windows Vista 来说是非常简单的：会在默认情况下安装 .NET Framework 3.0。也就是说，安装了 Windows Vista 的新计算机或升级到 Vista 的现有计算机都会自动安装 .NET Framework 3.0 应用程序。另外，.NET Framework 3.0 也可以在 Windows XP 和 Windows Server 2003 上运行。为使这两个系统的现有用户能够用到新的 .NET Framework 3.0 组件，Microsoft 提供该软件的免费下载版本。

结论

.NET Framework 3.0 是由 Windows 编程模型演变而来。它建立于 .NET Framework 2.0 的基础之上并加以扩展，目的是支持现代应用程序的构建。为此，该 3.0 版本采用了大量的最新技术，可以解决当今应用程序开发中的种种难题。通过在公共基础上建立这种多样性，Microsoft 致力于使软件的整体效果大于各个部分之和，从而让开发人员以更加一致的方式使用 .NET Framework 3.0 的不同部分来构建应用程序。

无论组织选择采用此新版本的哪些方面，其中所蕴含的技术必定会对 Windows 软件领域产生重大影响。对于该领域的所有人来说（无论是开发人员、设计人员或是决策者），现在是开始了解如何从 .NET Framework 3.0 获益的时候了。

版本兼容性

.NET Framework 对向后和向前兼容性的支持与版本相关。.NET Framework 只对使用 1.1 版创建的应用程序支持向后和向前兼容性。在使用 2.0 版创建的应用程序中，.NET Framework 不支持向前兼容性。在 .NET Framework 的上下文中，向后兼容性意味着使用 .NET Framework 的较早版本创建的应用程序可以在更高的版本上运行。相反，向前兼容性意味着使用 .NET Framework 的更高版本创建的应用程序可以在较早的版本上运行。

.NET Framework 提供高度的向后兼容性支持。例如，大多数使用 1.0 版创建的应用程序将在 1.1 版上运行，使用 1.1 版创建的应用程序将在 2.0 版上运行。只有对于 1.1 版，.NET Framework 还支持向前兼容性。但是，对于向前兼容性，可能需要修改应用程序以使应用程序按预期的方式运行。使用 2.0 版创建的应用程序将不在 .NET Framework 的早期版本上运行。对于向后和向前兼容性，对 .NET Framework 所做的可以提高安全性、正确性和功能性的更改也可能会引发兼容性问题。

有关可能影响您的应用程序的重大更改的更多信息，请参见 Breaking Changes in the .NET Framework（.NET Framework 中的重大更改）。


C# 3.0 新特性概览

    ·隐式类型本地变量

　　·匿名变量

　　·扩展方法

　　·对象和Collection初始化符

　　·Lambda表达式

　　·查询表达式

　　·表达式树

　　隐式类型本地变量

　　C# 3.0引进了一个新的关键字叫做"Var"。Var允许你声明一个新变量，它的类型是从用来初始化符变量的表达式里隐式的推断出来的。也就是说，如下的表达式是有效的格式：

var i = 1;

　　这一行使用了1来初始化符变量i。注意这里i被强类型到整型，它不是一个对象或者VB6的变量，也不带有其他对象或者变量的负载。
为了保证使用var关键字进行声明的变量的强类型特性，C#3.0要求你将赋值（初始化符）放到和声明（声明符）的同一行。同样，初始化符必须是一个表达式，不能是一个对象或者collection初始化符，也不能为null。如果多个声明符对同一个变量存在，那么它们必须在编译时被视作相同类型。

　　另一方面，隐式类型数组，可以使用一点不同的格式，如下所示：

var intArr = new[] {1,2,3,4} ;

　　上面一行的代码将声明intArr为int[].

　　var关键字允许你使用匿名类型的实例，因而这些实例就是静态类型的。所以，当你创建一个包含一组数据的对象的实例的时候，你不必要预先定义一个类可以同时支持这个结构和在一个静态类型变量里的数据。

　　匿名变量

　　C# 3.0使得你可以灵活的创建一个类的实例，而无需先写这个类的代码。所以你可以这样写代码：

new {hair="black", skin="green", teethCount=64}

　　上一行代码，通过new关键字的帮助，创建了有三个属性的类型：hair，skin和teethCount。这样C#编译器就会创建一个类如下：

class __Anonymous1
{
　private string _hair = "black";
　private string _skin = "green";
　private int _teeth = 64;
　public string hair {get { return _hair; } set { _hair = value; }}
　public string skin {get { return _skin; } set { _skin = value; }}
　public int teeth {get { return _teeth; } set { _teeth = value; }}
}

　　事实上，如果另外一个满足了相同的名称和类型顺序的匿名类型也被创建了，编译器也会聪明的只创建一个匿名类型来支持两个实例来使用。同样，因为实例都是一个类的简单实例，它们可以进行互换因为类型实际上是一样的。

　　现在你拥有了这个类，但是你还需要一些东西来支持以上的类的某个实例。这就是"var"关键字的作用。它让你拥有一个以上匿名变量的实例的一个静态类型实例。这里有一个简单好用的匿名类型的使用例子：

var frankenstein = new {hair="black", skin="green", teethCount=64}

　　扩展方法

　　扩展方法使你能够使用额外的静态方法来扩展各种类型。不过它们是非常有限的，也只能在实例方法不足够的情况下才作为候补使用。

　　扩展方法只能在静态类中被声明，并且以关键字"this"放在方法的第一个参数前来标识，如下就是一个有效的扩展方法的例子：

public static int ToInt32(this string s)
{
　return Convert.ToInt32(s) ;
}

　　如果一个包含以上方法的静态类被使用"using"关键字引进，ToInt32犯法将会出现在已有的类型中（虽然比现有的实例方法优先级低），你可以这样编译和执行代码：

string s = "1";
int i = s.ToInt32();

　　这使得你可以充分享用各种以有的内建的或者定义的类型的扩展特性，并且给它们加上新的方法。