.Net开发平台(转自MS光盘)(0分)

这几天，论坛中关注C#的大富翁越来越多了，真是高兴。刚才整理硬盘，看到一些好文章。
贴来让大家看看。
.Net开发平台
Michael Cherry, Greg De Michi Uie
执行总结
.Net开发平台的发布标志着近十年来微软开发平台第一个重大的转变。这个开发平台包括一个用于加载和运行应用程序的新的软件基础结构（.NET Framework和ASP.NET），一个新的开发环境（Visual Studio .NET），以及支持该结构的编程语言。
微软希望随着这个新平台的发布，评论不再将这个平台作为朦胧的软件，而且开发者也将发现该平台使得Windows上Web应用程序（尤其是Web Service）的开发更为容易。这样或许会使更多的开发者拥护公司的操作系统和服务器产品，并将他们从与Java平台的竞争中吸引过来。
微软的客户可以将该平台用作应用程序的更可靠、更安全和更统一的标准，而微软的合伙伙伴则可以通过帮助为该平台创建早期的胜利来加强与公司的联系。不过，无论是客户还是合伙厂商都应该意识到，新的平台要求他们从根本上掌握新的应用程序编程接口和编程语言，而且它能将他们锁定在微软的操作系统和服务器产品上。

.NET开发平台
本期内容
简介
微软为什么需要一个新的开发平台
机会与风险
Web Services：是什么和为什么
.NET Framework Core
CLR捕捉Bug，使编程更轻松
类库统一Windows API
支持Web Services
使平台一致
ECMA标准和Windows Lock-In
.NET开发平台工具
.NET开发平台语言
选择.NET语言的经验规则
.NET开发平台与J2EE的比较
Visual Studio .NET
ASP .NET
ASP .NET在哪些方面补充了.NET开发平台
ASP .NET的益处
向 ASP .NET进发
益处评价
软件可获得性
资源

简介
微软发布了.NET开发平台，这是自1993年7月随着Windows NT3.0出现的Win32 API后微软软件开发平台的第一次大升级。比起Win16来，Win32提供了更多功能强大的API，但没有对工具和技术进行引人注目的改变。与之不同的是，.NET开发平台在开发者用以创造应用程序的工具和技术上做了根本的改变。
.NET开发平台使得开发者创建运行在Internet Information Server (IIS）（互联网信息服务器）Web服务器上的Web应用程序更为容易，它也使创建稳定、可靠而又安全的Windows桌面应用程序更为容易。.NET开发平台包括以下内容：
•.NET Framework（架构），包括：Common Language Runtime（CLR）（通用语言运行环境），这是用于运行和加载应用程序的软件组件；新的类库，分级组织了开发者可以在他们的应用程序中用来显示图形用户界面、访问数据库和文件以及在Web上通信的代码集。
•.NET开发者工具，包括：Visual Studio .NET Integrated Development Environment （IDE）（Visual Studio .NET集成开发环境），用来开发和测试应用程序；.NET编程语言（例如Visual Basic .NET和新的Visual C#），用来创建运行在CLR下并且使用类库的应用程序。
•ASP .NET，一个取代以前的Active Server Pages （ASP）的特殊类库，用来创建动态的Web内容和Web服务器应用程序，这些都将采用诸如HTML、XML和Simple Object Access Protocol（SOAP）（简单对象访问协议）等Internet协议和数据格式。
（有关该平台组件的概貌，请参看“.NET开发平台”示意图。）
微软为什么需要一个新的开发平台。
微软希望能够藉此平台保留住它庞大的Windows开发用户的基础，否则由于Java向开发者所做的硬件与操作系统（OSs）无关性的承诺，这些用户群可能会转向其它的平台。开发者本身不会给微软（或任何其他针对此事的公司）带来很多收益。不过，Windows程序员是公司内对微软产品（例如Windows本身）的极大的支持力量，而商用软件的开发者形成了向客户发售微软产品的重要渠道。如果微软可以让开发者在新的.NET开发平台下写应用程序的话，那么就会有更多的公司购买Windows Server和.NET Enterprise Server （.NET企业服务器），包括SQL Sever 、Exchange 、Share Point、Commerce Server以及BizTalk等。
微软尤其推重.NET开发平台用于开发一种新型的应用程序：Web Services, 或者和Web上其他应用程序交换XML格式数据的服务器应用程序。（有关Web Services的概貌，请参看“Web Services：是什么与为什么”。）微软认为Web Services（为此公司已注册了名为“XML Web Services”的商标）是公司将现有的、孤立的应用程序集成到更大的商务（以及B2B）系统中的一种成本低而效用高的方法。微软希望Web Services成为吸引程序员在新的平台和产品上开发的“必有”的应用程序类型，正如带有图形用户界面的桌面应用程序吸引程序员在早期版本的Windows上进行开发那样。微软本身也计划使用该平台开发它自己的公共Web Services（称作.NET My Services），它将给Internet上的客户提供数据存储以及其他的功能。
（有关微软关于自己商务的长期计划以及该计划中.NET开发平台、 Web Services和.NET My Services的作用的概貌，请参看2001年7月的研究报告“Understanding .NET”（“理解.NET”。）
.NET开发平台

.NET开发平台是一组用于建立Web服务器应用程序和Windows桌面应用程序的软件组件，用该平台创建的应用程序在Common Language Runtime（CLR）（通用语言运行环境）（底层）的控制下运行。CLR是一个软件引擎，用来加载应用程序，确认它们可以没有错误地执行，进行相应的安全许可验证，执行应用程序，然后在运行完成后将它们清除。类库集提供了使应用程序可以读写XML数据、在Internet上通信、访问数据库等的代码。所有的类库都建立在一个基础的类库之上，它提供管理使用最为频繁的数据类型（例如数值或文本字符串）的功能，以及诸如文件输入/输出等底层功能。
Web服务器应用程序通常依赖于ASP.NET，一个处理Web请求的服务器端的库。ASP.NET又依赖一个用于发送和接收SOAP信息的Web Services库，以及一个用于以浏览器接收用户输入并动态地生成Web页面以示响应的Web用户接口（UI）（有时称作Web 表单）。Windows桌面应用程序通过使用Win表单库（也称作Windows 表单）可以显示一个图形UI。
最后，Visual Studio .NET提供了一个用于在该平台上创建应用程序的图形Integrated Development Ewironment（IDE）（集成开发环境）。程序员可以使用一种或多种.NET编程语言，来编写他们的代码，例如微软自己的Visual Basic .NET（VB.NET），Visual C++, Visual C#和JScrjpt .NET等。大量其它的.NET编程语言可以从第三方厂商获得。
机会与风险
新的.NET开发平台给合伙厂商和客户带来了新的机会与风险。
对于合伙厂商而言，新的平台意味着建立或加强与微软之间的关系的一次机会。微软需要早期的胜利来为该平台提供动力，那些能够提供这样的机会的合伙厂商就有可能建立和培育与微软间的坚实的共进关系。例如，Monster.com将开始使用各种.NET技术(例如Visual Studis.NET和.NET Framwork等）来发送它的四种重要的Web Services：Job seeker Notification（求职者公告），Job Posting（职位公布），Job Searching（职位搜索），以及Resume Posting （简历公布）。这优点类似于Visio的方法，它采用对象链接与嵌入和COM技术建立了与微软的伙伴关系，并且最终被微软购并。
不过，新的平台对于现在的合伙厂商也是一种风险，因为它将重新布置游戏领域，迫使先前与之关系紧密的或从中受惠的合伙厂商在新平台上重新起步，这样就给了其他公司加入的机会。更为重要的是，该平台建立的合作方机会根据价格分配，因为微软将为那些全盘采纳它的平台而摒弃其他公司产品的合作方保持最大的回报。Visio确立了完全使用Windows的目标，这使它可能已经丧失了与其他厂商建立关系，以便将它的产品卖给喜欢其他的OS的客户的机会。
新的平台将使公司的IT部门受益，它使程序员可以在短时间内即可创建更为安全可靠、扩展性更强的应用程序。不过实际上，这要等到.NET Framework可以使用以后，目前IT部门还必须将Framework 分配到多个桌面上，因为微软还没有将Framework加载到它任何一个操作系统上，包括最近的Windows XP。
.NET开发平台实际上不会改变低层代码的开发（例如设备驱动程序，定位多个OS（操作系统）的应用程序，或者用于PC或游戏机的游戏程序），所以它对商用软件程序员的影响有限。不过，它将为Windows应用程序，基于Web的应用程序以及Web Services（对于公司程序员而言这是一个分水岭般的事件），提供一个单一、细致的设计平台。对于公司来说，面临的风险就是.NET开发平台将把它们锁定Windows OS和.NET Enterprise Servers（.NET企业服务器）上。
这篇报告深入讨论了.NET开发平台，并且讨论了其关键组件，包括：拥有自己的CLR和类库的.NET Framework，新的工具和语言，以及ASP .NET等。报告还分析了.NET平台可能产生的问题与提供的好处。
Web Services：是什么与为什么
Web Services是一个软件组件，它通过将消息以XML格式进行编码，并将消息通过标准的Internet协议（例如Hypertext Transfer Prorocol (HTTP）（超文本传输协议））发送出去来与其它的应用程序进行通信。一个Web Services类似于这样一个Web站点：没有用户接口，向应用程序而非用户提供服务。Web Services不从浏览器获得请求并返回相应的Web页面，而是从应用程序接收XML格式的请求消息，执行任务，然后向应用程序返回XML格式的响应消息。
IBM和微软一致提倡将SOAP作为一种用于Web services的消息标准。一条SOAP消息如同一封信，由一个基于XML格式的“信封”和载有消息数据的“正文”两部分组成，“信封”部分包含一个指明消息接收者地址的头部和一系列投递选项（例如加密信息）。
（微软喜欢将此编程模型称作“XML Web Services”——采用“XML”意在强调其开放性。——但是这个基于一套World Wide Web Consortium （W3C）协议标准的模型，业界习惯上简单称其为“Web Services”。）
微软和IBM等其他供应商提倡将Web Services作为用于Internet上的互连应用程序通信的程序设计模型。这些公司相信通过Internet相互连接的应用程序，将增强与它们的合作供应商和客户协同工作的商务能力。通过在一个现有的公司应用程序的顶层创建一个Web Services层，各个组织可以允许外部系统通过Internet（或企业Intranet）调用应用程序的功能，但却不必修改应用程序本身。例如，有几家公司正在创建Web Services，来充当驻留在主机内的订单一入口应用程序的前端，这允许客户的订货系统通过Internet提交订单。作为公司内整合由各个部门独立开发的应用程序，以降低伴随公司合并与购并而来的IT整合费用的方法，将Web Services放在现有应用程序的顶层相当重要。
微软也希望使用Web Services进入服务供应商领域，通过Internet向付费客户提供必要的服务。计划中的服务首要的是.NET My Services，一套由微软管理的数据存储Web Services，包括由单个用户输入的个人信息，例如信用卡号和日历安排。桌面和Web服务器应用程序，如果获得了用户的许可，将通过Web Services协议从那些Internet上的数据库中取回信息。

.NET Framework核心
所有在.NET开发平台上创建的应用程序运行都需要运行两个核心块：
Common Language Runtime（CLR）（通用语言运行环境），这是一个软件引擎，用来加载应用程序，确认它们可以没有错误地运行，进行相应的安全许可验证，执行应用程序，然后在完成后将它们清除。
.NET Framework类库，向程序员提供所需用来编写在CLR的控制下运行的代码的软件组件。它们按照单一有序的分级组织提供了一个庞大的功能集——从文件系统到对XML功能的网络访问的每一样功能。
Web服务器应用程序也可以使用ASP .NET，这个类库将在做详细解释。桌面应用程序不需要ASP .NET。
CLR描述Bug，使编程更轻松
CLR有两个主要的目标：
•提高应用程序的稳定性和安全性
•减少应用程序开发者所必须写的冗长而又易出错的底层代码的容量
这两个目标类似于诸如Sun和IBM等厂商试图用Unix和主机上的Java平台去解决的问题。为了解决Windows上的这些问题，CLR对加载和执行应用程序的编程模型做了根本的改变。
CLR如何工作
一个应用程序是作为称作汇编的文件或文件集进入CLR的。这个汇编包是Microsoft Intermediate Languagl (MSIL）代码，CLR将其翻译成可执行的本机代码。由于可以对从MSIL到本机代码的应用程序翻译的控制，使得CLR可以管理应用程序的执行并且防止各种问题的发生，因此也就有了术语可控制代码。
除了MSIL代码，汇编还包含有详细描述了MSIL代码正确执行所需的各种相关数据类型的元数据。最后，汇编还包括一个清单——一个列出了汇编中所有文件和软件组件的文档，该文档还指出CLR在哪里可以找到具有应用程序运行所需组件的其它汇编。
为了加载一个应用程序，CLR使用汇编的清单来确定应用程序所需的汇编的正确版本。然后CLR检查应用程序的全部汇编——即，MSIL代码本身与描述它的元数据——从而确认代码是“类型安全”的，这表明它只执行对恰当数据类型的恰当的操作（也就是说，它不会允许开发者使用一个整数作为一个函数指针），而且它只访问经过授权可以访问的内存位置。
接下来CLR加载应用程序的汇编中的MSIL，并且在此过程中，收集有关汇编的“证据”，例如：
•它是从哪里下载或安装的
•它需要执行什么功能（也就是说，它是否需要写文件或发E-mail）
•什么用户试图运行它
•
汇编是否拥有来自信任的开发者的数字签名，以及进行数字签名后汇编是否有改动。
执行控制代码
Common Language Runtime (CLR）（通用语言运行环境）组件（以灰色显示）加载并运行应用程序。
（1）Class Loader（类加载器）将应用程序的汇编加载到内存中。汇编包括Microsoft Intermediate Language[MSIL]代码、描述应用程序的汇编中的软件组件的元数据，以及其他应用程序所需的组件。
接下来，Class Loader使用应用程序汇编的元数据，试图加载任何应用程序所需的组件的支持汇编。例如，它可能加载包含一个桌面应用程序所需的图形用户接口（GUI）控制的汇编。Class Loader 使用Versioning Polily（版本政策）（由应用程序的开发者或者系统管理员指定）采确定加载它所支持的哪些版本汇编。例如，一个Versioning Policy可能要求只能使用特定版本的GUI组件，即使有更多最近的版本可以利用。这消除了组件版本问题，这样的问题在过去十分普遍地存在于Windows应用程序中。
（2）一旦应用程序和受支持的汇编加载后，Verifier就得检查它的内容以确保它是类型安全的（type-safe），并且确定对于应用程序适当的安全许可。这是加强安全过程的第一步。
（3）本机编译器将MSIL转换为可控制的本机代码，这是处理器相关代码，它知道如何与CLR提供的服务，例如碎片整理（声明内存不再为应用程序所用）或CLR安全系统（将增强应用程序的安全许可），进行行交互。
这些证据构成了.NET Framework中的安全要素，使得CLR可以判断是否运行应用程序，以及运行时需要具有什么许可。
接下来，CLR将MSIL代码翻译成处理器可以执行的本机代码。（微软将此称为“可控制的本机代码”，以与“不可控制的本机代码”相区分，后者是用C++这样较老的语言写的，CLR对其没有控制。）一项称为Just-in-Time（JIT）编译的能力使得CLR能将翻译过程延迟至真正需要它时，这样就使CLR避免翻译不常用的代码。（关于这个过程的图解说明，请参看 “执行可控制代码”示意图。）
最后，CLR监控着翻译代码的运行，并且定期清空应用程序释放的内存（使用一个称作“碎片整理”的进程）。

CLR的好处
CLR通过下列方法增强了应用程序的可靠性：
它减少了不同版本组件间的冲突。CLR可以帮助避免在一台机器上安装相冲突的软件组件时发生的问题——现在的Windows应用程序如果试图加载不正确版本组件时可能失败。当CRL加载一个应用程序时，它使用元数据和汇编清单来确保它加载了所有组件的正确版本。例如如果应用程序需要访问数据库，CLR就使用清单中的信息来寻找并加载版本正确的数据访问组件。系统也允许并列安装多个版本的组件。
它减少了由于通常的编程错误所带来的bug和安全漏洞的数量。CLR监控代码以确保它不会有通常的编程错误，这些错误可能导致程序执行不正确的功能，例如试图使用一个整数作为函数指针，强行将数值型数据存放到分配给文本数据的位置，或者是载入数据时覆盖代码（由于缓冲溢出）。减少来自这些通常的编程错误的bug意味着应用程序不但运行得更可靠，而且攻击者有机可乘的漏洞和弱点也更少。
增强的安全性能使恶性代码的运行更为困难。因为CLR可以理解每个应用程序的代码的身份和来源，所以它可以决定应用程序是否被允许执行特定的任务（例如读写本地存储器或者发送E-mail）。这给现在的安全模型增加了另外一层保护，在现在的安全模型中应用程序在运行它的用户帐号的安全背景下运行（例如，管理员机器上所有的应用程序都用管理员级的许可在运行）。
内存泄漏更少。如果内存和组件分配给一个应用程序使用，但却得不到释放，这样就会导致系统超出内存运行，要么会冲击系统，要么就需重新启动、释放内存。CLR的内存管理和碎片整理可大大降低这种问题发生的可能性。
组装函数（Plumbing functions）减少了bug，同时也节约了开发者的时间。最后，CLR提供了许多与内存和对象管理、数据编组，以及线程（thread）相关的低级的，或组装函数。这不仅通过降低bug的发生可能性而建立了更好的可靠度，而且还使得程序员能将精力集中于用于他们特定的应用程序的“行业”代码上，而不必重新实现标准的Windows函数。
从Windows的过渡
最后，CLR执行的一项非常重要的功能是在可控制代码和不可控制代码（即脱离CLR运行的传统的Windows代码）间起中介作用。特别地，它使开发者可以将新的.NET代码与现存的Windows库和COM组件结合起来，并将一个应用程序逐渐地从老平台迁移到新平台上来。（请参看“混合可控制代码与不可控制代码”示意图）。
不过，需要指出的是，不可控制代码脱离CLR的控制而运行，因此有可能冲击应用程序，泄露内存，或者通过缓冲溢出打开安全漏洞。一个.NET应用程序只是和它的最弱环节——它的不可控制代码一样强壮。
类库统一Windows API
.NET Framework类库提供了几乎所有应用程序都需要的公共代码。和在Windows和它的SDK中发送的代码库一样，类库使得开发者能将精力集中于编写他们的应用程序所独有的代码，而不必一再重复编写类似读写文件这样经常使用的功能的代码。
类库还解决了当前的Windows代码库中存在的一个问题：当微软将向Windows绑缚新功能时，API和SDK之间就会出现混乱。（各种“版本”中的Java库试图解决非Windows OS 上类似的、甚或更严重的问题，即：来自各种不同的厂商，用于诸如文件输入/输出和消息收发等基本功能的使人困惑的API。）
类库做什么
所有的可控制代码都组织在称为类的（这就是类库的来源）逻辑组中，这些类按照称作域名空间的分级制度排列。
.NET Framenork类库在域名空间“System”之下。为了方便查找开发者所需要的类，该域名空间按照功能区的分级制度进行排列。（有关.NET类库的图解概貌，请参看“.NET类库域名空间”示意图。）
例如，System中有System. Data，它包含用于ADO .NET数据访问API的类。System.Data本身包括一组称作System.Data.Oledb的类，它用来支持访问数据库以及其他拥有Windows OLE DB .NET数据供应器的数据源。System .Data还包括System .Data .SQLclient，它支持对SQL Server的访问。
一些System类提供的功能以前可以通过Windows API或者特定语言的功能获得，但其他类则是全新的，例如System .Reflection，它使可控制代码能够获得来自汇编的信息，例如它的元数据。
开发者可以通过扩展类库中的类来定义自己的类，还可以定义全局唯一的专用域名空间，以使他们的类不会和微软或其他任何组织的类相冲突。
类库的好处
类库主要的好处是它们将核心Win32 API的最常用的功能和外挂SDK的功能封装到了一个统一的包中。采用清晰而有条理的方式对类库进行了分组和描述，这样开发者能更容易地找到他们的应用程序所需的大多数功能。
相反，在过去几年中，新功能要么被“绑缚”到Win32 API上，要由通过独立的API（例如用于图形的Directx，或者用于XML和SOAP的不同的SDK）来提供。对它们唯一能做的逻辑分组就是按照字母顺序进行排序。结果，使用Win32 API和各种SDK经常使人晕头转向，而开发者必须判断几个类似的API中哪一个最适合他们特定的要求。

支持Web Services
CLR和类库的结合使得与以前只是在Windows上相比，开发Web Services更为容易。
首先，CLR为运行服务器应用程序，包括Web Services，提供了一个更可靠的基础。服务器应用程序通常比桌面应用程序要有更高的可用性和安全性的要求，因此它们尤其将从CLR捕捉错误和阻止恶性代码的功能中受益。此外，服务器应用程序通常需要长时间不间断地运行，因此也将从CLR的碎片整理功能中受益。碎片整理功能可以限制内存泄露，否则长时间运行的应用程序可能会耗尽所有可用的内存。
混合可控制代码和不可控制代码

Common Language Runtime（CLR）（通用语言运行环境）的协作功能允许开发者将可控制代码与COM组件中现有的不可控制代码（以及Win32动态连接库（DLL）中的代码）混合起来。
当一可控制代码组件调用一COM组件（顶层）时，CLR就生成一个运行环境可调用包装（runtime callable wrapper）(RCW）。RCW充当不可控制的COM组件的代理（或中介）的角色。RCW处理可控制组件和COM组件之间所有的交互，包括（但不限于）以下内容：
•在CLR和COM环境间翻译和传递数据
•当可控制代码组件被CLR碎片整理进程重新声明时，释放包装的 COM组件的内存和其他资源。
•将来自COM错误返回代码（HRESULT值）的错误翻译成CLR错误（称作异常）。
当COM组件调用用可控制代码（底层）写的 .NET组件时，CLR又生成了一个称作COM 可调用包装（CCW）的包。和RCW类似，CCW也在不可控制的COM代码和可控制代码之间充当代理或中介的角色。CCW还实现了COM组件所需功能的标准设置，这样可控制代码组件看起来就像标准的COM组件一样。
CCW处理不可控制的COM对象和可控制的.NET组件之间的所有支互，包括（但不限于）以下内容。
•在两种环境间移动和翻译数据
•当COM组件被释放时，由CLR释放用于最后的碎片整理的可控制代码。
•将CLR异常翻译为COM返回代码。
其次，类库提供了开发者创建Web Services或使用Web Services的应用程序所需的全部代码。特别地，它们提供了在应用程序数据和XML间进行翻译转换的代码，以及通过Internet协议收发SOAP消息的代码。这样开发者就可将更多的精力放在他们自己的应用程序的逻辑上，而尽量不去考虑如何实现网络协议或读写XML数据这样的细节上。
统一平台
CLR和类库还联合解决了微软当前平台存在的一个重要问题：所有的编程语言并非是均衡创建的。 微软的每种编程语言都有自己的run-time基础结构（例如，Visual Basic [VB] runtime的多个潜在冲突的版本）和软件库（例如Microsoft C++基础类）。这就要求微软维护这些库以及相关的诸如debugger和wizard等工具。一个组织通常不得不将一个项目分割开来，其中一些让C++程序员编写，另外一些则让VB程序员来写。任一种程序员的短缺都会影响进度。
.NET Framework采用以下两种方法来解决语言的划分问题。
标准化数据类型。首先，.NET Framework为最常用的数据类型（例如整数、实数、文本字符）提供了标准的内部描述和运算，并提供了将这些类型向所有的.NET语言和CLR扩展的机制。设立这种标准化数据类型和可扩展模型（全称为.NET Framework Common Type System (CTS)），消除了每种语言用它自己唯一且不兼容的方法实现数据类型的必要。
标准化应用程序格式。其次，.NET Framework实现了一个标准的应用程序格式——拥有自己的MSIL、元数据和清单的汇编。所有.NET语言的编译器都生成这种格式。通过从元数据中提取有关MSIL的信息，编译器、调试器和协议器等工具可以分析处理任何一种源程序设计语言的数据。
标准化的数据类型和应用程序格式使开发者可以创建用任一种理解其中的数据类型和格式的程序设计语言工作的类库，这样的类库包含所有微软的.NET编程语言以及众多的第三方厂商语言。特别地，.NET Framework类库仅使用CTS数据类型，并分配以标准的应用程序格式。结果，这些类库能被使用任何一种.NET编程语言的应用程序所使用。
（请参看“开发可控制代码”示意图。）
CLR和类库相结合为微软提供了一个单一的运行平台，它支持运行所有的编程语言，并且可以用一组公共的开发工具来实现它。微软已经发布了一个该平台和它所使用的语言的规范。（请参看“ECMA标准和Windows Lock-In。）此外，类库向所有的.NET编程语言提供了大致相同的基本功能组，这样就使程序员可以用任一种他们最拿手的语言来工作。

.NET类库域名空间

.NET开发平台提供的API 被组织安排到了一组带有逻辑名的分级域名空间中。（本示意图显示了几个比较重要的类。）这和Win32 API形成了尖锐对比，Win32 API只是一个简单的功能名的长列表，顶多可以按字母排序。有了分级制度以后开发者就可以更加快捷地定位所需的功能，而且添加新的API也不会与已有的发生冲突。
类建立在基础类（底层）之上，基础类具有下述能力：文本处理（System.Text）网络访问（System .NET），以及存储列表和其他数据集（System .Collections）等。
基础类之上是更复杂的类，例如数据访问（System .Data），它包括ADD.NET和XML处理（System .XML）。
顶层是用户接口库。Windows 表单和Drawing库（分别是System.Win表单和System .Drawing）提供了封装后的Windows用户接口，包括GDI+和DirectX .System。Web包含用于建立包括Web Services类和Web 表单用户接口类的ASP.NET应用程序的类库。
开发可控制代码

开发者通过将他们自己的应用程序源代码和来自.NET类库的代码相结合，创建了可控制代码。这些类库可能包括.NET开发平台包含的类库（例如ADO.NET和Windows 表单），以及来自第三方的类库。
接下来.NET编译器将此代码从人可读的格式翻译成Microsoft Intermediate Language （MSIL）。不管采用何种语言，所有的.NET开发平台编译器均生成MSIL结果。
除了MSIL，.NET编译器还产生元数据，它描述了弥补代码的组件。Common Language Runtime (CLR）（通用语言运行环境）使用这种元数据来增强安全性，并确保获得它所需的任何组件的正确版本（减少组件冲突，或者“DLL Hell”）。
Visual Studio .NET和其他工具自动将MSIL代码封装到CLR中使用的汇编中。几个MSIL文件可以被组合成一个单一的汇编。（有关一个汇编如何由CLR来执行的图解概貌，请参看“执行可控制代码”示意图。）
ECMA标准和Windows Lock-In
经过使.NET Framework或为应用程序开发的标准的努力之后，微软向欧洲计算机制造商协会（ECMA），一个国际标准化组织，提交了C#语言和基于.NET Framework 的Common Language Infrastructure（CLI）（通用语言基础结构）的规范。原则上讲，这些规范能让开发者在.NET开发平台上写出可以运行在任何操作系统和硬件上的应用程序。不过，对这些规范的更深入的分析揭示出在可预见的将来这将把大部分.NET开发限制到Windows上。
2001年10月，ECMA批准了ECMA-344号标准——C#语言规范。这个ECMA标准规定了有关的形式，并且建立了使用C#编程语言写的程序的解释机制。它还规定了其他一些内容：
•C#语言的语法和约束
•C#程序的语义——它们如何工作
•由C#的一致实现所带来的约束和限制
同样是在2001年10月，ECMA发布了ECMA-335号标准，它定义了CLI。CLI是这样一个run-time环境，它使得用高级语言（例如C#）写的应用程序可以在不同的操作系统和硬件上运行，却不需要开发者考虑每种环境的独特特征再重写应用程序。CLI定义了以下内容：
•用于应用程序的文件格式
•在应用程序中使用的数据类型的公共设置
•应用程序元数据的可扩展格式
•用于应用程序代码的基于MSIL的中介语言
•类似于.NET Framework基础类的基础类库
2001年，ECMA，微软和Corel宣布，它们将协同工作，使用这些标准创建一个C#和用于FreeBSD的工具，并且按照微软的Shared Source Code（共享源代码）许可提供这个工具。 Ximian, 一个Linux的GNOME环境的开放源代码开发商，也已宣布它将使用同样的ECMA规范来实现Linux上的.NET Framework。
尽管有这些承诺，是否会有产品从此规范衍生出来，仍不清楚。
对于类库的有限支持
提交给ECMA用于标准化的信息包括反映.NET Framework部件（包括Common Type System（CTS）（公共类型系统），它为CLI和类似于Common Language Runtime（CLR）的虚拟执行环境定义的公共数据类型（例如整数和字符串））的要素。原则上讲，开发者可以创建一个可移植的应用程序，它可以在任何拥有ECMA兼容开发平台的操作系统和硬件上运行。例如，开发者可以在.NET开发平台上创建一个应用程序，它无需修改就可在使用Corel的CLI 工具的Free BSD上运行。
但是，应用程序的可移植性实际上由ECMA类跨环境的变换有多清楚来决定：如果开发者使用.NET Framework在Windows上写了一个程序，是不是所有微软的类库中的功能在遵守ECMA 规范的Free BSD工具中都可利用。
ECMA 规范描述了一组基础类库，包括映射到.NET Framework的System、system.NET、System.Reflection（它使程序可以获得可控制代码的元数据描述）的类和System.XML类。不过，规范看起来没有任何反映Windows或者Web Services的内容。类似地，ECMA 规范不包括任何和ADO.NET数据访问库类似的东西，所以根据此规范写的应用程序没有办法和数据库一起工作。
授权仍不确定
最后，还有授权问题。ECMA不考虑知识产权（例如专利，由诸如微软这样提出标准的公司掌握着）。它只要求知识产权所有者向希望实现ECMA标准的任何厂商提供某种授权。这样，尽管ECMA标准确保任何希望实现非Windows版.NET的厂商不会被“毫无理由”地被拒绝给予授权，但授权非常麻烦，以至于大大地限制了发布。
直至微软关于授权的政策更为和缓（现在的Shared Source Program仅限于学术使用），.NET Framework都不会有一个可行的交叉平台未来。需要全部.NET Framework的应用程序或许也需要Windows。

.NET开发平台工具
和先前从Win16到Win32 API的平台转换不同，从Win32到.NET开发平台的转换既有对已有语言和工具的修改，还引入了全新的语言。结果，决定使用.NET开发平台的组织，不仅必须改变它们的平台战略，而且还必须考虑它们的语言和工具战略。
.NET开发平台语言
将有三种新版的微软编程语言支持CLR和类库：Visual Basic.NET, Visual C++，以及Jscript.NET。它们还将结合两种新语言：Visual C#和Visual J#。Visual J#使visual J++开发者可以使用类似的语言创建可控制代码。
微软经常指出，.NET开发平台和诸如Java等其他编程环境之间的最大的差别在于，.NET开发平台支持多种编程语言。（有关.NET开发平台与Java之间差别的更多信息，语参看边框内容 （“.NET开发平台与J2EE的比较”。）由于.NET开发平台支持不同的语言，具有不同技巧的程序员就可以使用他们最擅长的语言来创建组件，而这些组件可以平滑地协作。但这也带来一个问题——开发和项目经理如何选择他们的应用程序所用的语言。
Microsof的每一种支持CIR和类库的语言都有着不同的实现和历史，做选择时需要加以考虑。（为获得选择.NET开发语言的快速指南，请参看边框内容“选择.NET语言的经验规则”。）
Visual Basic .NET
这种新的语言拥有与现有的Visual Basic（VB）类似的语法，设计它的目的是为了让使用VB的开发者能过渡到.NET。不过，和以前的VB版本不同的是，Visual Basic.NET使用CLR和类库取代了类似的VB组件和插件。VB.NET还有新的、高级的功能，例如对多线程和结构化异常处理的支持。尽管如“onerror goto”型的错误处理的语言习惯的去除是一项受欢迎的改变——这会使应用程序更加健壮，但却意味着现在的VB程序员不能加载并运行他们以前的应用程序。
事实上，VB.NET与以前的VB版本相比有很大的改变，不能向后兼容。微软正在开发一个工具，用于将VB源代码迁移成VB.NET代码，但是这个过程不能全部自动完成。开发者必须手工检查迁移后的代码，重写某些部分，并仔细测试结果。
不过，开发者不必一次迁移所有代码：幸赖CLR的协作功能，VB.NET可以调用VB代码，反之亦然。这就允许开发者逐渐递增地迁移应用程序——例如，一个VB.NET应用程序可以合并一些已有的VB模块。
由于迁移不能马上完成，微软答应它将继续支持现在的VB语言（6.0版），至少到VB .NET的第三版发布，根据VB发布的惯常速度，那大概要等到五、六年之后。
两个VB的变种根本不能迁移到.NET开发平台上：一种是Visual Basis Scripting Edition（VBScript）（Visual Basic脚本描述版本），用于管理脚本、Active Server Pages (ASP）（活动服务器页）与动态Web内容的脚本描述语言；另一种是Visual Basic for Applications (VBA），用于定制诸如Office等应用程序的脚本描述语言。VBScript已经包容在VB.NET中，而VBA则将继续作为Office中的宏程序设计语言发挥作用。
微软说在向.NET开发平台迁移时，过去使用VB的开发者应使用VB.NET而非C#。这只是一个初步分析的结论，具体情况还需考虑开发者使用的VB功能的广泛程度：
选择.NET语言的经验规则
•当前的程序员有哪些技巧，以及雇佣新程序员有多容易？
•正在开发的组件是用于单一的终端用户应用程序，还是在不同的情况下被其他程序员重用的基础组件？
•应用程序需要从头编写新代码，还是可能只需修改和改写已有的代码？
•可以使用第三方（non-Windows）语言和工具吗？
下面的经验规则可以帮助开发者选择.NET开发平台语言：
•大多数VB程序是继续使用VB（VB .NET）或许将受益很多。
•对于那些已经熟悉VB的更高级的功能的VB开发者，需要关注一下C#，作为另一种工具。
•已经熟悉Java或J++的开发者将发现C#最适合他们的技巧。
•正在将已有的本机代码改写为.NET代码的C++开发者应使用Managed Extensions to C++。那些继续开发本机应用程序的C++开发者应继续使用现有的C++语言。
•正在开发新的应用程序和代码基础的C++开发者需要在C#和Managed Extensions to C++中做出选择。大多数情形中，这些开发者将发现使用C#的收益非常符合学习曲线。
•对脚本描述Web页非常感兴趣，并且使用Jscript完成过这种工作的，应转向JScript.NET。
•使用过J++以及喜欢Java语法的开发者应考虑J#。
•对于多数一般的VB程序员，大多数的语言改变相当直接。如果VB开发者的主要经验是使用已有的VB组件，那么他们应当使用VB.NET进行新应用程序的开发，而不能转到使用C#上去。像C#这样的更为严格的面向对象语言的附加的复杂性与任何获得的小的收益都不成比例。
•高级的VB程序员——例如，那些广泛使用诸如“Win32 Declare”这类对底层OS进行直接调用的功能的开发者——则另当别论。使用VB.NET，他们现在能发挥自己的本领创建应用程序底层的组件，例如那些供其他VB程序员使用的组件。不过，因为他们要设计供团队内其他成员使用的组件（即使团队的其他人继续使用VB.NET），这些组件开发者也应考虑切换到C#对于组件开发的好处。

Visual C++
Visual C++，这个现有的用于编写低层代码和Windows程序的程序设计语言，还将继续存在，但是它将被修改更新以支持.NET开发平台。
特别地， Visual C++将获得新的关键字和数据类型（称为Managed Extensions to Visual C++），它使程序员可以创建可控制代码。不过，这些扩展是可以选择的；.NET Framework 所带的Visual C++版本完全向后兼容它的前身：Visual C++6.0，开发者可用它写不可控制代码。
这使C++在.NET领域中具有一个独特的位置。所有其他的微软语言需要向.NET开发平台进行完全的转换——例如，无法使用VB.NET创建一个运行在老的VB runtime上的VB风格组件，也无法直接将一个C# 应用程序编译为 本机 Intel指令。不过Visual C++仍有本机编译器。结合CLR将新的可控制代码与已有的不可控制代码相连的本领，这些都意味着C++开发者可以继续使用同他们过去一直在用的完全相同的语言和环境。
.NET开发平台与J2EE的比较
作为彼此竞争的应用程序平台，微软 的.NET开发平台和Sun 的Java 2 Enterprise Edition（J2EE）（Java 2企业版）在意图和体系上极其相似，但在底层实现上却完全不同。目前，看上去无论是.NET还是J2EE开发平台都不会轻易地占优势，这意味着几乎任何开发软件的人某些情况下都不得不在二者之中做出选择。
类似的目标
.NET开发平台和J2EE在精神实质上具有类似的目标：
采用更易于重用别人创建的代码组件的程序设计模型，通过向开发者提供已有的组件，消除了重写底层例程的必要，从而提高开发者的开发效率。
通过消除或减少对C这样的开发语言的易出错结构的使用，以及使用强迫对所有代码组件间的交互点作清晰定义的编程模型（这隔离了错误的影响，并且使错误跟踪更为容易），增强了软件的可靠性。
通过对应用程序可以或不可以做什么（例如它们是否可以读/写磁盘）加以控制，并且在运行时采用数字签名以确认代码是由信任的实体编写的且尚未被改变，来提高安全性。
通过在代码自身内嵌入组件描述（包括版本信息）来简化安装和卸载。这免除了让开发者在安装时“注册”他们的代码的思想——这是以前安装复杂和不稳定的一个主要原因—— 从而使需要时，没有或很少有用户或者管理员的干预，应用程序软件即可自动安装成为可能。在.NET开发平台的情形中，它还允许同一组件的不同版本共存于一个系统，彼此间互不干涉，也不与其他应用程序相干涉。
类似的体系结构
由于目标类似，.NET和J2EE两个开发平台也有着类似的体系结构。相应的体系结构特征如下：
虚拟机：设计它用来检查、加载和执行在一个牢牢受控的“沙箱”（sandbox）中的程序。通过在程序代码可以做和不可以做什么之间设置严格的边界，这个沙箱减少了由恶性代码（例如病毒）和信任代码偶然的行为造成的危险。为了启用这个沙箱体系结构，所有的程序都被从原始代码编译成了与处理器无关的中介语言——Microsoft Intermediate Language（MSIL）或Java位码。然后在称作Just-in-Time（JIT）编译器的参与下，这些中介代码单元被翻译成了针对特定CPU类型和操作系统的本机代码。这个虚拟机还向程序提供了诸如内存管理等基础服务。.NET的虚拟机称作Common Language Runtime（CLR），J2EE使用Java Virtual Machine（JVM）(Java虚拟机）。
类库：向应用程序开发者提供预先写好的功能，包括：编码服务（例如字符串操作和事务处理），网络服务（协议处理），系统管理服务（安全许可和组件合并），服务器服务（为Web页服务，连结E-mail），以及连结外部源（例如数据库系统和数据流）的服务。
定制的编程语言：建立在C和C++基础之上，包括诸如强类型化和能提高开发者开发效率并降低bug出现的可能性等改进。不过，只要有编译器能将初始的源代码翻译成为虚拟机能够理解的中介代码，就没有必要用这些语言（C# for .NET或者Java for J2EE）来写程序。CLR现在支持C#、Visual Basic、 Jscript、 COBLOL、 Fortran、 Haskell以及Python（由的三方开发的带有许多其他语言的工具）；JVM支持Java、COBOL、ADA以及Prolog等。
用于运行在Web服务器上的动态Web页的开发环境：这让开发者使用相同的平台既可创建桌面应用程序，又可创建基于Web的应用程序，.NET使用ASP..NET，而J2EE使用Java Server Pages（JSP）。
即使有了Managed Extensions，使用Visual C++编写可控制代码仍然比较困难，并容易出错，由于.NET开发平台数据类型和C++的之间的差异，这意味着开发者首先使用Visual C++，正如现在所用的那样，编写诸如低层设备驱动程序这样的不可控制代码，然后使用Managed Extensions来让这些代码能够与某些其他来源的可控制代码协作，或与它们合并。
JScript.NET
JScript.NET是微软的JavaScript （或ECMA Script）脚本描述语言的更新版，它与Java 和Visual J#（参看下文）都不同。与VB.NET 对VB的突破相比，JScript.NET对当前JScript语言（通常用于客户端浏览器脚本描述）的根本性突破比较少，这是因为JScript已经支持和CLR所提供的相类似的数据类型和特征。尽管如此，JScript.NET并非全部后向兼容，微软也还没有宣布任何计划来支持源代码向更新版语言的移植。
对于那些现在使用JScript，并且想要利用自己已有的知识发挥CLR和类库优势的Web开发者，JScript非常有吸引力。
Visual C#
介于使用Visual C++创建可控制代码的困难，微软 创造了一种类似的语言，称作Visual C#，专门用于编写可控制代码。
C#是微软唯一一种从一开始设计就专门针对CLR的语言，微软本身已经使用C#来创建诸如类库和ASP.NET等子系统中的可控制代码。事实上，虽然支持多种语言是CLR的主要设计目标，也不妨认为C#和CLR被有效地设计在一起，并且每一个的设计都会影响另一个。这是不是意味着所有的程序员都应该使用C#？当然不是。
尽管C#比C++更为简单，它仍深深植根于“C”语言家族。这意味着它继承了VB这样的语言所没有的特征。例如，C#语言大小写敏感，而VB则大小写不敏感。C#要求开发者明确地转换数据类型，而VB则进行了某些缺省的转换。C#包括对能够更直接访问底层.NET开发平台基础结构的不可控制代码的支持，例如，C#开发者可以使用指针类型指令访问缓冲内存并检查该缓冲。
微软明智地决定不在VB.NET中使用这些能力，因为这样做将使VB语言更为复杂化，却只不过对于较少的高级VB程序员有益。
简而言之，C#更能吸引现在用Visual C++ 或Java工作的程序员，对于开发组件的高级VB程序员，并且他们需要一门使用CLR和类库的易于学习的语言，C#也有吸引力。
Visual J#.NET
这是一种新语言，它给程序员提供了从现有的Visual J++ Java环境向新的.NET开发环境迁移的途径。
Visual J# .NET是Visual Studio的一个外接式附件，它使程序员能够使用Java语法写应用程序，但最终的应用程序使用.NET Framework 类库和CLR而非Sun的Java 2 API和Java Visual Machine（JVM）（Java虚拟机）。Visual J#.NET还提供工具用以导入和转换J++应用程序，程序然后能在CLR下运行，并且通过CLR和COM协同工作性的功能来访问J++库（例如Windows Foundation Classes（Windows基本类库））。Visual J# .NET没有使用任何Sun Java技术，因此不能轻易地将应用程序移植到Sun兼容Java上。
.NET开发平台和J2EE的比较（续）
既然.NET Framework和J2EE提供非常相似的体系结构和性能，做出选用任何一种平台（或者从一种向另一种转换）的决定需要经理人员考虑技术领域以外的事情，组织应该考虑以下三个主要领域的内容：
成熟度与最近的技术。尽管较多建立在J2EE上的应用程序正在涌现，但Java平台的核心部件——JVM和“标准版”类库——已经在丰富的真是世界情境中使用过，大量致命的bug已由Sun或者第三方发现并修正。此外，开发者已经用充足的时间去学习它，并且有广泛的工具和应用程序去支持它。这些因素或能会导致更平滑、更可预知的开发过程。
同时，因为.NET相对较新，它拥有Java所缺乏的改进，例如，ASP.NET使开发者可以用比Java开发者在J2EE平台上更少的代码来实现Web Services。
开发者的可用性。许多组织现在都有在职的VB程序员。尽管VB.NET有一些大的改变，但是重新培训这些VB开发者要比从头培训新的Java程序员更为简单，花费相对更少。
工具集的可用性。作为全部.NET工作的一部分，微软也已做了对Studio生产线的重大改动。Visual Studio已拥有非常强大的开发者队伍，微软希望采用以下方法使.NET更有吸引力。Sun没有创建开发者工具的历史。Sun 的主要的Java工具是Fort for Java以及第三方供应的附加工具，例如IBM的Visual Age for Java。
可移植性和协作性。Java的交叉平台可移植性获得了很好的评价，使它在大规模混合式服务器环境上大获成功（尽管写给J2EE的代码比只是写给JVM的代码的移植性要差）。
另一方面，.NET可控制代码，只能在各种不同的Windows 平台间进行移植。与在 Windows上运行时Java所能提供的相比，.NET CLR提供了.NET代码与写给已有Windows平台的代码间更紧密的协作性。此外，.NET重点放在Windows上不像看起来那么有限。Windows2000及其后的版本都将在服务器和桌面上支持.NET，而Windows CE与它的衍生品将在各种可移植的设备上支持.NET，包括掌上电脑、智能电话与TV机顶盒。另一方面，微软目前还不允许.NET Framework向其他平台（例如Unix）的移植，除了遵守已经宣布的授权，由欧洲计算机制造者协会（ECMA）标准化了的.NET Framework部分。（有关这些标准更多的信息，请参看“ECMA标准和Windows Lock-In”。）
对于那些已使用Visual J++工作过，并且熟悉Java语法，但又不想转换到.NET开发平台的程序员，Visual J# .NET非常有吸引力。
Visual J# .NET是在Visual Studio.NET之外的一个独立的开发计划，最新版是一个测试版，它还不能与Visual Studio .NET的最终版本相兼容。
Visual Studio .NET
2002年2月，微软发布了Visual Studio.NET（VS.NET）的最终版本，这是微软极力推荐的创建.NET应用程序的软件开发工具集。VS.NET第一次让开发者仔细体会了微软在语言上进行的革命性的改变，同时也解决了许多过去困扰开发者使用微软工具创建应用程序的问题。随着它在调试方面的改进，以及它将开发者所需的工具紧密集成到一个单一的环境上去，VS.NET将大大影响Web应用程序的开发。
由于将新的工具、向导、功能和开发途径等都封装到一个熟悉的拖放环境中，需要相当的学习研究才能掌握VS.NET所有的优点，但是它应该服从引导微软现有的开发者客户进入.NET世界这样一个目的。
SDK与IDE
微软提供了一个免费的.NET Framework SDK，它包括CLR、类库、ASP.NET和用于C#与VB语言的编译器，使用这个SDK，开发者可以使用任何编辑器写代码，然后从命令行界面访问编译器和其他工具。
尽管如此，大多数开发者更喜欢在VS.NET图形集成开发环境（IDE）中工作。VS.NET提供了图形化工具，从而更容易查找代码组件、跟踪任务、编辑和编译代码、指导调试，以及组织开发工作等。
VS .NET是微软促使开发者决心转移到.NET开发平台上来的主要工具，为了实现这个目标，微软已为它补充了新的功能。这些新功能可以根据让.NET开发者的生活更轻松的意义进行分类：一些意味着增加了创建.NET应用程序的乐趣，一些意味着舒缓痛苦，还有一些意味着延缓必然的转变。
增加乐趣
最贴近开发者心声的方法是对于他们的编程任务给出更多的信息和控制，同时又没有让他们的生活复杂化。VS.NET大大增加了开发者随手可得的信息和控制的水平。
主要的增强包括以下内容：
更多的开发者工具。VS.NET与以往的Visual Studio版本相比有更加丰富的功能，包括近30种内建的工具条，用于处理各种项目元素，例如数据库、XML 图、设计工具、HTML格式工具、图像编辑器、布局工具、文本编辑器、样式表以及报告生成器等。仅Windows 表单设计者工具箱就有超过40条标准控制。
新的Server Explorer窗格使开发者可以浏览已连接的服务器（包括Inter.net服务器）上他们所需的任何资源，例如SQL Server数据库。这样就可以更加容易查找和集成信息队列、日志、数据库、分布式组件以及服务等。（请参看“Visual Studio.NET Server Explore”。）
增强的剪贴板区允许开发者建立个人的代码片断库，这些片断可以拖放到代码中。
集成语言。以前，Visual Studio中的每种语言都有略微不同的IDE。现在，所有被支持的.NET语言共享相同的开发、调试以及部署的IDE，这大大提高了解决应用程序开发问题的灵活性。开发者尤其欢迎从任一客户端代码向任一服务器端代码的迅速步进，当处理分布式组件时这十分重要。集成的调试环境使得来自任何.NET语言的错误可以在其他的语言中加以捕捉和报告，并且支持跨越项目、服务器、语言、进程甚至储存的程序的应用程序的调试。
Visual Studio.NET Server Explorer
Visual Studio.NET Server Explorer允许开发者定位查找由不同的服务器提供的可编程的service然后将这些service拖放到他们的应用程序中，通过Server Explorer可以获得的service包括XML Web Services、 SQL表格、Views和储存的程序、消息队列、性能计数器，以及事件日志等。
可扩充的IDE。在对第三方工具的支持上，VS.NET远远超出了以前任何版本的Visual Studio。过去，诸如Rational这样的工具和语言供应商都只有有限的挂钩，可以用来在Visual Studio之上进行开发。有了VS.NET，这些供应商拥有和微软自己一样多的挂钩来创建自己的语言产品。一些供应商，例如Fujitsu，正在使用VS.NET IDE进行以CLR为目标的 COBOL和Fortran的设计。
强大的Web生产能力。以前，开发者只能在Web页中嵌入VB Script或JScript。现在，Web页可以用VS.NET中的任一种语言来生成。IDE也提供了从Web 表单控件中创造Web页的拖放式 GUI，它是完全动态的，易于编码，能自动处理状态问题，根据浏览器兼容能力生成纯HTML，并且将用户界面问题与编码问题相分离。
只需简单地将一个外部的Web Services拖到设计页面上，就可将它与项目连接起来。创建Web Services只需向代码中添加标签属性。可以使用增强的HTML和脚本编辑器。对于许多Web创建者来说，这是一方乐土。
过去，采用一个称作Visual InterDev的工具进行Web开发。随着Visual 的发布，Visual InterDev不再作为一个独立产品存在，但所有的功能都集成到了VS.NET中。
完全集成的数据处理。XML和数据库集成，通过和数据源相连结合起来，大大简化了对来自不同种类的数据源的联合数据（例如将来自一Oracle数据库的雇员数据合并到基于XML的销售成绩列表中）的处理。
全部代码公开。以前，支持某些控件的代码被隐藏起来，开发者很难发现并修改。现在，所有控件发出的代码，包括格式化代码，都可以显示出来，这样便于高级开发者修改表单和控制件的缺省行为，并且在应用程序的外观上给予它们更紧凑的控制。（为了保留大多数VB用户经验，VS.NET IDE使用大纲功能来隐藏代码，直到开发者想要浏览它。）
舒缓痛苦
切换到.NET开发平台潜在的痛苦主要有两个来源：新语言需要的改变程度，以及使某些功能发挥作用的组装代码的数量。微软 试图（用成功的惊喜程度）通过使用向导（现在称作Designers）与突出熟悉的拖放编程方法来舒缓这些变动带来的痛苦。特殊的痛苦缓和手段包括以下内容：
简化复杂的任务，新的可视化Designers可以帮助开发者为建立数据库、查询、数据连接、Web Services、HTML、XML以及SQL服务器上的备用程序创建必要的支持代码。开发者可以从工具箱中将一个可视化元素拖到代码设计窗格中，而对于该项功能的冗长的支持代码将自动生成。接下来开发者可以编辑这些支持代码。
可浏览的复杂度。在基于Web领域中，组件和组件类型越多，模板越复杂，对应的项目也就越复杂。IDE通过将老的Project窗格分成一个Solution窗格和一个Class View窗格，降低了这种复杂度。Solution窗格显示了作为一个更大的“方案”的部件的所有项目的全产文件和目录。Class View 窗格映射出了一个项目中所有正在使用的类。Server Explorer也可以帮助管理复杂的服务器环境。
自动化的组件组装。为了提高应用程序的可扩展性和可靠性，大规模的应用程序通常分成几个逻辑层，它的多个拷见可以在服务器的相关组（称为服务器田）上运行。当 .NET组件在服务器田上运行时，它们使用特殊的、共有的资源Services（称作COM+ Component Services（不要与COM组件对象模型相混淆，它只用作COM+的部分）），来处理所涉及的许多复杂问题。
这些组件需要大量组装代码，但在大多数情形中，代码可以由拖放Component Designer自动生成。这对于n-tier目标为服务器田的开发者是一个好消息。
增强组件管理。IDE中的新工具还可以减轻部署和监控服务器田中的分布式组件的痛苦。所有的.NET对象都是Windows Management Interface（WMI）客户端对象，自动配备进行性能监测。
动态帮助。新的Dynamic Help功能使得IDE能够识别每种语言的语法和大多数系统性错误代码，并且动态给出关于当前编码活动和光标位置的帮助主题到表，这项辅助功能通过详细的说明和代码示例随手可得，可以帮助开发者理解.NET环境的新要求——尽管它将占用开发者计算机上大量的资源。
自动化的XML界面。那些试图建立基于新标准的XML界面的开发者面临着令人畏缩的大量细节：文件布局和数据图表必须小心翼翼地汇集起来，并进行校核和测试。
VS.NET通过自动生成用于使用或创建Web Services和数据连接的界面，减轻了这项负担。它包括用于读/写XML和创建并校核来自数据源的XML图表等增强工具。既然XML是.NET组件通信的标准语言，这项功能对于开发者部署组件应用程序尤为重要。
延缓必然的转变
在被告知.NET中所涉及的改变的程度和努力的范围后，许多开发者都想尽可能延迟向.NET的转变。微软通过支持COM和.NET组件之间的协作功能进行了可能是和缓的迁移。在VS.NET中工作的开发者可以参考来自他们的项目中的老的COM风格组件。
下列特征将有助于开发者延缓必然的转变：
自动创建包装。通过将COM组件包进称作运行环境可调用包装（RCW）特殊的代码层中，COM组件可以合并到.NET环境中。类似地，.NET组件可以被包到— COM可调用包装（RCW）中，并被合并到主要是基于COM的应用程序中。VS.NET IDE拥有创建所有在运行时CLR需要它生成包装的组装工具，这使COM和.NET更易于共存于相同的应用程序中。（有关此互操作性的更多信息，请参看“混合可控制代码和不可控制代码”）
必要时绕过.NET。即使在VS.NET中使用，Visual C++也能生成不使用CLR而直接在Windows上运行的不可控制代码模块。这样，开发者可以使用VS.NET创建应用程序，例如设备驱动程序，它可能需要不受.NET开发平台的限制而运行。
ASP.NET
微软的ASP.NET对Active Server Page（ASP）进行了很大的改变，不仅使开发者更易于创建动态Web内容，还使他们更易于创建复杂而可靠的Web应用程序，例如Web Services。ASP.NET 是微软的. NET开发平台的关键的一部分。为了微软 .NET战略的成功，必须吸引开发者采用. NET开发平台，包括ASP .NET。尽管ASP .NET beta版测试者报告了它的大量好处，开发者的不得不克服从ASP转到ASP.NET在编辑模型和语言支持上的差异问题。
ASP. NET的主要目标是降低Web应用程度开发的门槛，它采用与降低使用Visual Basic（VB）进行Windows编程难度大致相同的方法实现了这个目标：通过设计——“事件－驱动”编程模型，在此模型中开发者向一表单中填加控件，然后编写代码处理与这些空间相关的事件（例如，数据进入文本框或者单击鼠标）。由于允许开发者在由.NET Frame类库显示的XML支持上开发，这也使他们更易于创建以XML格式交换数据的Service。
ASP.NET在哪些方面补充了.NET开发平台
ASP.NET是.NET开发平台的一个部件，用来开发驻留在微软的Internet Information Server（ILS）上并且使用诸如HTTP和SOAP等Internet协议的Web应用程序。ASP.NET使两种类型的Web应用程序的开发和部署更为容易。
•Web 表单应用程序，包括用于动态内容的从脚本生成的Web页和向一个客户（例如浏览器）显示UI或表单的Web页两种。
•Web Services，用于显示其他应用程序和“智能”客户端的功能，使应用程序可以交换信息。
两种Web应用程序体现了超出传统应用程序的一个主要的优点：它们使用基于Internet的协议使信息可以轻易地穿过组织边界（和防火墙）移动，如同在一个组织内移动一样。
微软以前试图使用ASP（1996年作为IIS3.0的扩展功能首先引入）来降低Web应用程序开发的门槛。ASP支持VBScript和JScript，以及一些可用于Web应用程序开发的简单对象，例如Request对象，允许开发者从客户端获得数据；Response 对象则向客户端发送数据。与以前的IIS API（例如Common Gateway Interface（CGI）（通用网关接口）和Internet Server Application Programming Interface（ISAP）（Internet服务器应用程序编程接口））相比，ASP更易用于Web应用程序开发。使用ASP，一个有HTML和脚本使用经验的程序员可以轻松地开发动态Web内容。
尽管如此，介于其有限的对象模型，有限的脚本描述语言能力，有限的用于端到端应用程序调试的工具，以及对于外部XML工具和分析程序进行API级调用的要求，开发一个功能强大且稳定的Web 表单仍然十分困难。
通过在.NET开发平台中嵌入ASP.NET，微软将CLR和类库的益处提供给了开发者。ASP.NET使用CLR 来编译代码，管理执行，创造了运行更快、表现更好的Web应用程序。此外，ASP.NET使用类库让开发者更易于将XML格式数据合并到Web应用程序中，添加处理异常的代码，创建UI元素，并提供其他的编程功能。
（有关ASP.NET和.NET开发平台的组件的图形描述，请参看“ASP.NET体系结构”示意图。）
ASP.NET的好处
ASP.NET在三个领域提供了超越ASP的改进：编程模型，状态管理，以及从.NET开发平台继承过来的好处。
ASP.NET体系结构

ASP.NET使开发者能够创建在Internet Information Server（IIS）和.NET开发平台上运行的Web应用程序。ASP.NET通过Internet Server Application Programming Interfaces（ISAPI）与IIS通信，Active Server Pages（ASP）同样。事实上，ASP和ASP.NET可以共存于同样的IIS服务器上：IIS将对于ASP页面的请求（带有.asp扩展名）指向ASP，将对于ASP.NET页面的请求（带有.aspx或.asmx扩展名）指向ASP.NET。
ASP.NET本身有一个cache，通过提供cache内的经常使用的页面来提高性能。ASP.NET还包括一个跟踪用户会话的状态管理Service。在ASP中，开发者通常不得不创建自己的cache和状态管理Services来扩大ASP所提供的。
.NET Framework Core开发平台支持ASP.NET页面中的代码。特别地，Common Language Runtime（CLR）编译和管理页面中代码的执行。类库提供了一个用于接收请求和生成响应的统一类集（例如Web 表单类和XML类）。
事件—驱动编程模型
事件—驱动编程允许开发者创建一旦特定事件发生时就执行的代码。例如，在ASP.NET的情形中，当加载、卸载或单击页面上的控件时，一段特定的代码将执行。ASP使用线性代码处理模型，每条ASP代码线都掺杂了静态HTML，并且按照在ASP文件中出现的顺序加以处理。
事件—驱动编程使ASP.NET编程更接近于Windows编程。这样做的好处是开发者只需编写响应事件的代码，并且他们可以将事件—驱动编程的知识从Windows桌面应用程序扩展到Web应用程序上来。
事件—驱动编程的另一个优点是它可以使处理数据的代码与向用户显示数据的代码相分离。例如，ASP.NET允许开发者使用一种称作“代码隐藏”的机制将Web应用程序逻辑（通常用VB.NET或C#开发）从表示层（通常采用HTML格式）中分离出来。通过将逻辑与表示相分离，ASP.NET允许多个页面使用相同的代码，从而使维护更容易。开发者不再需要为了修改一个编程逻辑问题而浏览HTML表示，Web设计者也不必通读所有代码来修正一个页面的HTML错误，（参看“ASP.NET代码隐藏”示意图）。
更好的状态管理
ASP.NET给Web应用程序状态带来丰富的好处。状态管理涉及到跟踪每个人的会话数据，这是由用户在与Web站点发生交互时生成的独特的数据。例如，用户购物车内当前的产品信息，或者用户目前是否登录到了该站点上。
ASP.NET解决了和状态管理有关的两个问题。第一个，如果Web服务器有问题，状态信息经常丢失；第二个，驻留在一个服务器组或者Web田上的Web站点上的状态信息难于管理。
和ASP一样，状态信息存在于ASP.NET正在其中运行的程序中。尽管这种方法提供了最好的性能，但也最缺少稳定性和可扩展性。如果服务器重启，保存的状态信息就会丢失，而进程中的状态管理不能提供给驻留在多个服务器的Web应用程序。
和ASP不同的是，ASP.NET还可以使用一个用于进程外状态管理的Windows Service（ASPState）。尽管这比进程中状态管理稍慢，但是即使ASP.NET进程被重启，信息仍能保存下来，而且它也可以支持跨越Web田中多个服务器上的Web应用程序。
另一个状态管理的选择是让ASP.NET将状态信息保存在SQL Server上。这种方式确保状态信息能幸免于Web服务器上的问题，并且允许一个SQL Server（大站点上的SQL Server簇）保存驻留在—Web田中的几个服务器上的Web应用程序的状态信息。
从.NET Framework中受益
ASP.NET使开发者用.NET Framework类库创建带有UI的Web页面更为容易。.NET Framework类库提供诸如文本和列表框，以及各种按钮等控件，开发者可以通过将标签（例如〈asp: Button〉）插入到他们的动态Web页面中来使用这些控件，或者也可以使用Visual Studio.NET的图形页面编辑器来添加控件。ASP.NET提供以下几种类型的控件：
•现有HTML控件的服务器端版本，例如代表〈input type=submit〉的按钮（HTML Button）控件。现有的用于表单 的HTML与ASP.NET HTML控件之间的主要差别是“runat=server”属性，它表示代码在服务器上运行，而控件显示在客户端。
ASP.NET代码隐藏

ASP.NET使事件处理代码“隐藏”在表示代码之后，或者说从中分离出来。和Visual Basic（VB）将VB-based Windows应用程序表单从与之交互的代码中分离开来完全一样，ASP.NET Web 表单将用户接口（UI）编程分为商务逻辑和内容表示两部分。
与由Web 表单页面生成的事件发生交互的逻辑或程序代码被称作“代码隐藏”页面。扩展名.aspx.vb或者.aspx.cs表明页面是否包含Visual Basic.NET或C#代码。这些代码隐藏页面被编译成Dynamic Link Libraries（DLLS）（动态链接库），这项技术得益于ASP.NET性能的提高。
表示文件或Web表单页面是一个混装静态HTML和ASP.NET服务器控件的容器。
当用户请求一个页面时，ASP.NET显示Web 表单。当用户选择一个控件（例如，单击submit（提交）按钮）时，页面将被激活的控件的信息返回给ASP.NET，ASP.NET执行代码中相关的事件句柄。
ASP.NET性能

微软和beta版测试者们都说ASP.NET的性能胜过ASP的性能，但是评测的基准很难说明，就像美国环保局提供的汽车里程评估——“实际里程可能不同”。
尽管如此，在2001年10月的Professional Developers Conference（PDC）（专业开发者会议）期间，微软还是提供了初步的性能数据。客户们不得不决定如何推断符合他们应用程序需求的基准数据。
数据是基于Doculab的Nile的基准，它常常用于评估应用程序服务器的相关性能。实现ASP.NET的Nile基准需要4,000条C#代码，用来生成一个ad-hoc搜索的混合，创建新客户，管理购物车，以及处理定单等。保持硬件配置不变，通过对应用程序和数据库服务器的测试，得出如下结果：附加测试表明用VB.NET编写代码和用C#编写代码区别不大。
&amp;#8226;Web 表单控件，这是服务器端控件，一些是HTML控件，另外一些则是新增的更为复杂的控件，例如文本框（<asp:TextBox>、列表框、日历和数据网格等。这些控件比HTML控件更易于使用，因为诸如容量这样的属性在所有控件中均使用一致的方式设置。
&amp;#8226;确认控件，这是一种链接到HTML控件和Web 表单输入控件（例如文本框）的控件。确认控件能够通过比较、检查输入范围或应用一个定制的确认代码来确认用户的输入。
所有这些控件都减少了开发者不得不编写的代码的数量，开发者只需把控件定位在一个页面中，初始化控件的性能和方法，然后编写代码来响应控件可能产生的事件，这种事件是用户某些行为（如单击按钮）的结果。这些控件还支持数据绑定，这使开发者很容易将从数据库取回的特定信息与指定给控制值关联起来。
相比之下，ASP仅仅提供了6个基本控件。尽管ActiveX控件能够由ASP使用，但这通常会削弱Web应用程序的稳定性。
另外，.NET开发平台的类库不仅使Web应用程序受益，同样也有益于任何Windows应用程序，这些助益如下：
减少了异常处理的编码。异常处理类使开发者可以很容易地添加代码处理公共编程问题，例如被0除，内存溢出，或是找不到文件等错误。
减少了用于数据交换的编码。通过使用类库，ASP.NET开发者可以方便地读写XML数据流。ASP.NET还可使用ADO.NET，一套新的扩展的Active Data Objects（ADO）（活动数据对象），来管理指向数据库中的数据的连接，并且处理数据。
改进的性能。ASP.NET性能大大优于ASP，这主要是因为以CLR为目标的代码是编译执行，而用于ASP的脚本语言则是解释执行。当代码第一次使用时，要被编译，起始页面加栽可能会慢些，但在随后的页面请求中，该页面将从动态输出缓存中的已编译过的代码中读出。当识别到缓存页面的控件事件或查询字符串的变化时，ASP.NET甚至能够专门缓存。甚至ASP.NET测试版看来也比ASP要快好多。（微软提供的比较，参看“ASP.NET性能”。）
增加的语言支持。ASP.NET允许开发者使用CLR支持的任何语言，包括VB.NET和C#。ASP仅仅支持VBScript与Jscript这样的解释型脚本描述语言。
改进的调试支持。基于ASP.NET的 Web应用程序的开发者既可以使用包含在.NET Framework SDK中的调试器，也可使用集成在Visual Studio中的调试器。除了允许开发者逐步检查代码，设置断点外， ASP.NET还支持跟踪，它允许开发者跟踪一个应用程序的执行，然后观察跟踪结果。要排除ASP 页面的故障，开发者不得不散布带有自定义的“Response.Write”声明的代码，来显示应用程序中特定点的变量值。调试完后，必须将这些代码行清除或者注释掉，以便应用程序作为产品运行时，不会输出调试信息。可以轻松地设置跟踪开或关，并且既可同单独的Web页面也可同大范围的Web应用程序一起工作。

向ASP.NET进发
ASP 和ASP.NET之间的差异导致ASP页面不可能在ASP.NET上运行。然而，一个单一的IIS服务器能同时驻留 ASP应用程序 和基于ASP.NET的 Web应用程序。
想利用ASP.NET的开发者有几种选择：
&amp;#8226;保留现有的ASP应用程序不动，在ASP.NET上开发新的应用程序。因为ASP和ASP.NET可以共存，也就不必迫切地将现有的应用程序转换到ASP.NET上，但是知道ASP.NET的重大优势，开发者也许不会再想开发任何新的ASP应用程序。
&amp;#8226;将ASP.NET特征添加到现有的ASP Web应用程序上。从原理上讲，开发者能够建立带有ASP和 ASP.NET混合页面的应用程序，这使应用程序可以逐渐迁移到ASP.NET上。然而，状态管理还不能在ASP和ASP.NET之间分开，如果状态信息必须由ASP和ASP.NET页面共享，这就使得这种方法不切实际。
&amp;#8226;把现有的ASP Web应用程序转换到ASP.NET。这需要开发者将现有的基于脚本的代码转换到VB.NET或C#，从ADO转换到ADO.NET，并且将事件驱动代码添加到应用程序之中。仔细检查现有的应用程序，确定有多少脚本代码嵌入在页面之中，并且考察ASP.NET的新的优势，如服务器端控件和事件模型，将说明这种方法是否有意义。
&amp;#8226;使用现有的页面作为校验的规范，充分利用ASP.NET功能的优势，重建页面的表示和逻辑，改写现有的ASP Web应用程序，使之用于ASP.NET。这种方法花费的工夫可能最多，但是在应用程序的稳定性和性能方面可能会达到最好的效果。
益处评价
.NET开发平台的发布给微软的客户及其合作厂商带来一个基本的问题：和目前的Windows平台或Java相比，我们应当把多少开发和市场的经费投入到新的平台中？在做决策时，组织应当考虑到以下需求：
可靠性和安全性。和Windows或者Java中的任何一个相比，.NET开发平台提供了更好的应用程序可靠性和安全性，这尤其要归功于Common Language Runtime（CLR），及其基本编码错误（如缓冲区溢出）的防止，和管理员定义版本政策和安全限制的增强。然而，一个应用仅仅同它最弱的环节一样强壮：具有不可控制代码的.NET应用程序 仅与那些代码具有相同的可靠性和安全性。Java有一个用以调用本机代码的机制，Java Native Interface（JNI）（Java本机接口），但是现有的代码必须加以修改采允许其被调用。
开发成本。.NET开发平台在开发Web应用程序（尤其是Web服务）时明显优于现在的Windows版本，它甚至有着远远超越Java的优势，这得益于Visual Studio.NET复杂的图形编辑器和向导。
类库和CLR还向采用所有.NET编程语言的应用程序提供了单纯一致的目标，它应当简化培训程序员和编写维护代码的工作。多种编程语言的支持还使.NET开发平台具有一个强于Java的优点，因为熟悉旧的Windows语言，例如Visual Basic的开发者，无需再从头学习.NET中相同的内容。.NET开发平台还给主要投资于Windows代码的组织提供了一种方法，使它们可以在新的.NET开发平台中重用不可控制代码，这样这些组织就可以逐渐地迁移到新平台上来。
然而，.NET与现在的Windows平台差异甚多，因此许多组织不得不在编程语言和库方面培训开发者，并且必须重新访问和重新编写现有的Windows源代码，以便运行它时完全受控于CLR下。
性能。尽管在.NET开发平台和Java平台之间进行有效的性能比较非常困难，因为体系结构、设计及平台等各种差异太多，但基准显示，.NET是可比的，而且ASP和ASP.NET之间的测试强有力地表明：在Windows平台上，ASP.NET胜过了ASP。事实上，ASP.NET的性能几乎可以与速度最快的基于Windows的Web API相媲美。然而，比起直接把Windows APIS作为目标，.NET开发平台还带来了一些不可避免的性能冲撞，为了增加可靠性和安全性，沟通不可控制代码和可控制代码之间的鸿沟，以及把中间代码翻译成本机代码。这使该平台对于性能敏感应用程序（例如游戏和低层的网络业务）的吸引力较弱。
单独厂商因素。和Java，.NET开发平台由单个厂商微软开发并实现，这样使得顾客购买平台更为简便，而微软和合作商对平台的支持也更方便。然而，.NET开发平台只能在Windows上运行，因此组织进行平台转换必须保证在解决企业问题（例如安全问题和可靠性问题）时Windows将保持其性价比优势。最近微软产品的授权成本的增加以及及安全漏洞的不断发现暗示这可能不是完全有把握的一赌。
总而言之，转到还是离开.NET开发平台的决策必须由每个组织自己来做，而且在同一个组织内不同的开发项目组间也可能有所不同。新平台对于创建新的服务器端Web应用程序（尤其是重用现有的COM代码的Web Service和Web应用程序）的公司意义最大。.NET对于已经使用了第三方软件厂商产品的组织，特别是使用Windows桌面应用程序和必须在Unix环境和主机操作系统上运行的封装服务器应用程序（如SAP的ERP产品）的组织，没有太大的意义。这些软件厂商或许会看好.NET Web Service的前景，但是他们几乎看不到将应用程序迁移到.NET开发平台上的好处，这些应用程序的.NET版的出现，还要经过一个漫长的等待。
软件可获得性
.NET Framework SDK可以从以下网址下栽得到：
msdn.microsoft.com/downloads/default.asp?url=/downloads/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml&amp;frame=true。
.NET Framework包含在Visual Studio.NET中。
MSDN订购者可以从msdn.Microsoft.com/visualj/jsharp/beta.asp下载Visual Studio.NET。
Visual Basic.NET、Visual C++和Visual C#包含在.NET Framework（编译器）中，自然也驻留在Visual Studio.NET中。
Visual J#.NET Beta 1可从msdn.Microsoft.com/visualj/jsharp/beta.asp下载，从这还可获得进一步的信息。
ASP.NET包含在.NET Framework中， ASP.NET 1.0版可从www.asp.net/download.aspx下载。
资源
.NET Framework系统需求
要获得.NET Framework的系统需求的清单，请看：
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconnetframeworksystemrequirements.asp?frame=true
若要对微软的.NET的前景有一个全面的概要认识，包括.NET对微软、合作伙伴及客户意味着什么，参看2001年7月的研究报告“理解.NET”。
要获得关于.NET开发平台的开发人员信息，请看：msdn.Microsoft.com/net/。
要获得其他有用的.NET链接和信息，请看：www.devx.com/dotnet/resources和www.gotdotnet.com。
.NET Framework
有关.NET Framework的信息，请看：msdn.Microsoft.com/netframework/。
有关.NET Framework最具权威性的文档在.NET Framework SDK中。

语言
MSDN有一个Visual Studio.NET的论文选集，放在msdn.Microsoft.com/vstudio/中。
要获得有关Common Language Infrastructure（通用语言基础结构）的信息，请看：www.ecma.ch/ecma1/MEMENTO/tc39.htm。
有关创建一个Common Language Infrastructure for Linux工具的项目的信息，请看：www.go-mono.com/。
ASP.NET
要想获得有关ASP.NET的信息，请看：www.asp.net，www.gotdotnet.com，以及msdn.Microsoft.com/library/default.asp?url=/nhp/Default.asp?contented=28000440。
与Java的比较
微软和Sun给开发者的主页分别是：msdn.Microsoft.com/net/和java.sun.com/j2ee/tutorial/。
.NET和J2EE应用程度开发环境之间很好的技术比较可从以下网址获得：www.sdmagazine.com/articles/2001/0103/0103a/0103a.htm。
C#和Java编程语言上粗略比较可从New England Java Users Group站点得到，网址为：www.nejug.org/2001/feb01.htm。

文章不错。
没有断行，看得好难受。
建议大富翁输出文本时自动判断是否该断行，并加入换行回车。

先顶牢,在慢慢看