.NET概观
2024-07-10 12:57:47
供稿：网友
这篇文章很多地方借鉴了david chappell的《understanding .net》和其他的一些网上的文章，但是也有一些我自己的文字。写这篇文章的本意是希望能用一些较少的文字能给读者对.net一个全面的、但是并不深入的印象。这里谨对《understanding.net》的作者david chappell及译者侯捷、荣耀还有其他的作者们表示感谢！
.net概观
微软.net的出现，可以说是一场地震。它将震撼windows环境下工作的任何人，同时也将在范围更广的世界里产生余震。微软一次性的带给我们那么大的变化，要我们适应它，短期来看，将使我们的日子更加难过，毕竟要学的东西太多！然而一段我们掌握了这套新工具和新技术，大多数windows开发人员将会发现，他们有能力在更短的时间内构建数更具威力、更有用的软件。
一． 什么是.net
.net是一个施用于一系列技术上的商标
微软将.net视为数字化未来的一个远景和平台。如果更具体更准确地看待这种创新，则是把.net视为一个商标，一个微软已经施行于数种不同技术上的商标。这些技术有些是全新的，提供新的服务和新的可能性，另一些则允许我们以最新的方式来创建我们今天已经知道的各类windows应用程序。当然，也有一些.net家族成员只不过是装饰着.net牌子的现有技术的新版本而已。
.net是软件成为一种服务的转移
.net在这个方面的意义是最被广泛接受和理解的。“软件就是服务”的历年最初是在
1997年左右由oracle的ceo larry ellison以及sun的ceo scott mcnealy在网络计算机的概念大行其道的时候提出的。不过oracle和sun并没有真正将这个概念变为现实，他们的视角更多的集中于资源集中化方面。不过，当初听到ellison和mcnealy这番见解的公司——当然包括microsoft，也认识到了这种见解说出了软件产业面临的一个巨大改变，.net则是microsoft对这种概念，这种变化作出的自己的反应。
.net是一个新的编程模型——也就是说是internet平台
micorsoft正在趋向于将.net看作一个系统。在表面下，它包含了两种不同的编程模型：一个是web服务编程模型，另一个是系统编程模型。
microsoft开始把.net系统编程模型作为.net整体的一个组成部分。计划最终以此代替现有的组件对象模型(component object model，com)以及windows应用程序编程接口(apis)，这个现在还没有最终正式定名的模型使用一系列新的基础类。
.net之中最重要的新技术首推web services。如其名称所示，web services提供了某些功能，让我们得以通过网络加以调用。大多数顶着.net商标的技术都可以在某种程度上直接支持web services。然而.net绝非仅仅是web services而已，微软置于.net商标伞下的技术包括：
.net framework：包括通用语言运行层（common language runtime,clr）和.net框架类库。clr是建造一系列新应用程序的标准基础，.net类库则为许多基于clr的应用程序提供一个新的标准开发环境。这个类库，包含的技术有：asp.net，最新一代的asp（active server pages）技术；ado.net，最新一代的ado（activex data objects）技术；以及对“构建和使用web services”的支持等等。微软还发行了一个.net framework精简版，名为.net compact framework，用于小型设备如个人数字助理（personal digital assistants，pdas）上。
visual studio.net：支持多种可使用.net framework的编程语言，包括visual basic；一个增强版的c++；一个基于.net的java替代语言j#，以及一个为.net framework量身打造的全新语言c#。
.net my services：一组服务，允许用户存储和访问位于互联网可达之服务器上的个人信息，例如日程表和地址簿等等。这些服务还提供诸如认证（autherntication）这样的通用功能，使客户能够证明自己的身份；也提供了一个“向不同设备上的客户发送消息”的方式。
.net enterprise servers：这是一系列软件服务器，包括、exchange server 2003、sharepoint server 2003、project server 2003、biztalk server2000，application center 2000、commerce server 2000、host integration server 2000、sql server 2000等等。除了几个叫2003的产品外，其他的很大程度上与这里说的.net技术没有什么关联，但是显而易见，在未来的版本当中，他们将全部基于.net技术构建，上面几个叫2003的版本已经证明了这一点。
二． .net的特点
1. 高效率开发
通过.net framework为我们提供的一个庞大而有结构清晰的类型，使得我们的编程变得异常轻松，还有自动垃圾回收机制等等一系列新的特性，可以让我们的程序员腾出更多的精力放在考虑如何实现客户所需要的业务逻辑上，而不是计算机的控制上为内存如何分派之类的事情头痛。甚至无论你是开发哪一种应用程序，无论是c/s、b/s、还是智能设备亦或是数据库编程，都可以使用你最熟悉的一种编程语言而不需要去学习诸如c++、asp、sql等等各不相同的多用语言。.net还带来了多种语言之间的无缝集成，例如一个系统同时可以采用多用编程语言来开发，vb.net编写的类可以方便的再用c#继承。这些都大幅了提高我们的开发效率。
2. 多平台特性
尽管不可否认，到目前为止.net应用程序还只能运行于windows平台上，但.net天生就为跨平台应用做好了准备，据我们所知，微软自己还有第三方开发商已经在为.net程序运行在unix、os2、linux等等系统上工作着（如开源项目mono）。我们还可以看到我们的.net应用程序将可以运行在pda甚至手机上。不久的将来，我们将可以只关心我们的应用程序将如何满足客户的需求而不用考虑基于何种平台来开发。
3. 无接触部署
借助于.net的反射特性，.net应用程序都可以精确的描述自身。这就使得无接触部署成为可能，.net应用程序无需在注册表中储存信息，只需简单的xcopy便可正确的在用户的机器上运行，这使得企业的部署成本将会大为降低。
4. 消除dll hell
同样是基于.net的反射特性，每一个应用程序将可以清楚地知道自己需要使用哪一个dll，同一个dll的不同版本可以彼此和平共处，从而彻底消除让我们头痛的dll hell。
5. 可信赖计算
长期以来，微软系统的安全性问题一直备受诟病。但终于，比尔盖茨决定改变这种现状。在.net中，这种安全性的考虑直接放到了代码级。通过一系列的技术，如代码访问安全(code access security)、基于角色的安全、强名称（strong name）、权限和权限集等等，最大限度地保证了系统的安全性。
三． .net framework体系结构
.net是分层的、模块化的，一及层次结构化的。.net framewok的每一层都是一个抽象层。其中，.net语言是顶层，也是最为抽象的一层。而公共语言运行库则位于底层，它是最不抽象、最靠近本地环境的一层。这一点很重要，因为公共语言运行库需要与操作环境紧密合作来管理.net应用程序。.net framework被分成了多个模块，每个模块都有它们各自特定的责任。最后由于高层只从底层请求服务，所以.net又是层次结构化的。
四． webservices(web服务)
要想透彻理解.net，就必须透彻理解web services，还必须领会刚刚列举出来的每一种.net技术的基本要素。
今天，web应用程序的典型访问方式为gui
近十年来，软件世界没有什么比interne和www带来的冲击更大。区区20年以前，还是大型机的时代。那时只有极少数人能够使用计算机，而且只能通过邻近的信息产业机构。个人电脑和图象化用户界面的出现却改变了一切，将计算机普及到了千家万户，并使它真正成为一种可以大工业生产的商品。企业界意识到，由个人电脑联结的网络和基于个人电脑的服务器可能改变他们的商务模式，而个人电脑对消费者来说也迅速地成为新兴的娱乐媒介。然后，因特网接踵而至。它革命性地改变了我们的交流方式，创造了丰富而新颖的信息和娱乐资源，并且在“商务”的前面加上了一个代表“电子”的字母“e”。今天，全球有将近三亿人口正在使用因特网。国际数据集团提供的资料显示，今年全球的网上交易金额将超过250亿美元。world wide web已经从根本上改变了我们访问信息、购物、找工作以及日常生活的方式。他通过具有图形界面（gui）的应用程序很人们直接互动而做到这一切。毫不夸张地说，以gui为主的应用程序，造就了web的今天。
然而，gui不是web的全部，web services代表了web的未来
以gui为主的应用程序可能就不再是下一阶段web的交通工具了。面对这些网络神话，我们仍然发现存在着巨大的改进空间。今天的因特网在很大程度上还在模仿旧式大型计算机的工作方式。尽管有充足的带宽资源，大量的信息还是被“锁”在了中央数据库里，并由“保安人员”看守。用户必须依靠网络服务器来完成所有的上网操作，这酷似老式的分时复用系统。网站好象一个个孤立的小岛，并不能按照用户的指令在它们之间进行有意义的交流。今天的网络似乎只能通过单个的网站向单个用户提供有限的服务 -- 因为大多数的网页只能呈现html格式的数据“图片”，而非信息本身。（对大多数网页来说，在现有技术条件下要两者兼顾是非常困难的。）非但如此，浏览器本身在很多方面都只是一个被美化了的“哑巴只读终端”-- 你可以轻易地浏览信息，但是很难进行编辑、分析和复制（实际上也就是知识工作者需要做的所有工作）。“个性化”只意味着重复地进入网站，并不断地将个人隐私泄露给你所访问的每一个网站。你必须适应科技，而不是科技反过来适应你的要求。我们希望我们能通过多种方式来获取信息，而不仅仅是浏览器。如果提供这些web服务的应用程序可以由外界通过编程来访问，那么外界就可以更容易且更有效率的使用这套重要的服务。用微软的话说，“一切都是服务”。这些网络服务的客户可以不再是坐在浏览器前面的人，而是运行在桌上电脑、移动电话或其他设备上的软件。客户软件可以通过多种方式来调用那些应用程序的远程操作，并使用xml（extensible markup language）传输信息。换句话说，这用应用程序可以用“web services方式”加以访问。
web services可被应用于很多方面
这种技术可应用于很多方面。它可用来让桌面客户或手持设备客户访问internet上的应用程序，利于预定系统；也可以用于b2b整合，通过internet连接不同企业组织的应用程序。web services甚至还可能用于企业应用整合，从而将企业组织“原本运行于专用网络上”的应用程序连接起来。所有这些案例中，web services技术都为型型色色的软件小模块提供了“标准胶水”。
xml web services是完全公开的，可以通过任何平台实现。.net my services 是xml web services的一个具体实现，通过xml web services的方式来传输数据，具体地说，就是通过以xml描述的soap消息来实现信息的交流，而soap消息可以通过http或者dime(direct internet message encapsulation，直接internet消息封装)协议来传递。xml web services的工作原理如图所示。结合microsoft .net passport用户身份认证系统，.net my services能够以用户为中心将应用程序和服务高效集成，并实现个体和组织的协作与信息共享。
web services以来的四种基础技术：
web services技术可以分解为四个独立领域，每一个领域都解决了问题的某个特定方面。
描述“经由网络发送的信息”：调用一个远程操作时，往往必须传入一些参数，并取回某些信息。如果使用web services，这些信息必须以xml描述。作为一种被普遍接受用以描述数据的现代通用语言，xml可以描述和交换不同种类的信息。
定义“web services能力”：必须存在某种机制，使web services供应者能够精确定义他所提供的services的技术细节，并且能够被服务的接受者所理解。这由web services描述语言（wsdl）完成。而wsdl自身也是采用xml来定义的。
访问web services：一旦定义好接口，客户必须使用某种协议调用该接口内的操作。这里并不存在什么专用协议，然而最重要的选择是soap（simple object access protocol）。soap提供一个办法，可以标识出“将调用那一个操作”：他以“采用xml定义完成的数据”传输操作的输入，并同样以“采用xml定义完成的数据”回传任意结果。
找出web services：对运用web services开发客户端程序的人员来说，必须存在某种方式，让他们知道可以获得什么样的服务，让他们知道web service提供了些什么？其接口看起来是什么模样？考虑到internet的存在，建立一个标准的registy用以存储和访问信息是很合理的。这正是uddi（universal description，discovery，and integration）技术所作的事情。使用uddi，web services供应者便可以用标准方式对他们所提供的东西广而告之，使客户得以获悉各家供应商提供了些什么服务，并让客户知道，为了开发客户端软件，他们需要了解些什么。
web services是通用的：any time，any where
以上每一种技术都是由成群的厂商和用户彼此协作而开发出来的。比如xml是world wide web协会（w3c）资助的一个大型团体开发出来的，wsdl主要由microsoft和ibm开发出来，soap原先由microsoft、ibm、userland software、developmentor，其他一些团体也扮演了一定的角色。uddi原先由microsoft、ibm和ariba开发，后来又有更多组织加入，共同努力。没有任何一个seb services技术源自单一厂商提供的解决方案。因此，奠基于xml、wsdl、soap和uddi之上的web services实质上可用于所有平台、所有语言和所有对象模型。再加上web services的无与伦比的穿越防火墙的能力，无论何时、无论何地、也无论你的系统是架构于windows、unix、mac或者linux甚至ppc、palm之上，只要有internet，您就能享受web services提供给您的服务。
应用web services
web services几乎可以用在任何场合。最显而易见的用途分为三类：
允许经由internet，以可编程方式访问应用程序：这样你就可以不必受限于浏览器了，你可以使用选择更有效率的方式来完成，通过一个适合客户端设备的界面，你可以表达你的意愿，并贯彻你的意愿。microsoft .net意味着简单化的整体服务；统一的信息浏览、编辑和授权；查看你的资料、工作和在线与离线媒体；一种整体的系统方案；随时随地的个性化；绝对的自由。例如，对于你个人信息的任何修改 -- 无论是通过个人电脑、便携设备还是灵通卡 -- 将即时和自动地通知到所有需要这些信息的地方。例如你可以随时随地通过你喜欢的方式来在网上预订机票，而不仅仅是访问航空公司的网站。
以这种方式访问web services，还引发另一种可能性：为何不让某些service为其供应者（公司）创造营收呢？正如奠基于浏览器之上的web应用程序支撑新式商业模型，从而带来internet大爆炸一样，web services也能为他们的供应者带来新的赚钱方式。虽然你的牙医不可能因为你做了一个预约就向你收费，但有些服务确实肯定要收费的。
b2b整合：web services的另一个重要应用是b2b整合，一般来说它也依赖于internet，将运行于不同企业组织中的软件连接起来。就目前来说，各个企业的软件在internet的海洋里还像是一个一个的信息孤岛，要连接起来还需要专门而特别的方法。其原因是多方面的，平台不同、软件不同、防火墙……等等这一些限制了彼此之间的连接，html虽然是通用而标准的，可是那只适合人看，想要交程序去理解网页中包含的信息，那是难上加难。而web services则提供了一个通用而标准的方式，使得这不再只是个美好的梦。可以想象，web services在企业协作比如供应链管理等等方面将发挥出它神奇的作用。
a2a整合：许多企业组织最困难的问题就是如何将现有应用程序连接在一起。不论规模如何，每家公司都有一些以不同语言在不同时间编写出来的软件，混合运行于不同系统上。将这些繁杂的应用程序联合为一个有用整体，已经是这些公司面临的巨大挑战之一，更别说为这个混合怪兽加上新程序了。而web services则为这个恼人的a2a整合问题提供了一个有效的解决方案，直截了当的说，web services为这个五花八门的环境提供了一盒不错的万能胶。
web services的未来一片光明
web services无疑是个好点子。他让许多厂商开放的services得以运行于跨越intranet和internet的所有平台上，并因此带来一种新的开放世界的方式。web services底层蕴含的技术——xml、wsdl、soap、uddi——都是相对较新的技术。尽管这些技术的资历并不深，但它们都被多家厂商支持，并且看起来都有可能在将来的分布式计算环境中发挥重要作用。奠基于浏览器之上的应用程序，造就了web璀璨的今天，而web services则可能成就出更美好的明天。并由此，将给我们带来一个全新的理念：一切都是服务。
五． common language runtime(通用语言运行层)
.net framework中的任何东西都依赖clr
通用语言运行层（clr，common language runtime）是.net framework之中任何东西的基础。要想透彻理解.net语言如c#和visual basic.net，你必须理解clr；要想透彻理解.net framework类库如asp.net和ado.net以及其他东西，你也必须理解clr。由于.net framework已经成为微软新软件的默认基础，所以任何打算在微软环境下工作的人，都应该努力把握clr。
clr定义了哪些东西
一般而言每一门语言都有自己的一套独特语法、一套控制结构、一道数据类型（data types），以及一套“class如何继承”的概念。语言设计这所作的决策，会受其目标应用程序（target applications）的影响，也就是说，“语言使用者可能拿这个语言来干什么”会影响语言当初的设计。当然，语言设计者也难免掺杂个人感情因素。
然而，对于一门现在编程语言应该提供些什么成分，大多数人都会达成共识。尽管与方面的意见会不同意，但语义方面大家有普遍的一致意见。于是，
clr定义了一套可被多种语言使用的通用语义集
clr还提供了其他通用服务：
garbage collection（垃圾回收），自动释放不再被引用的受控对象
metadata（元数据）标准格式。每一个类型的信息都存储在该类型编译后的代码里。这和com不同，不再有独立的类型库（type libraries），也不再需要idl。如今的interfaces和classess直接使用开发人员所采用的任何编程语言来定义，而后再被转换成metadata标准格式。
一个通用体制（common scheme），用以组织编译后的代码（称为装配件，assemblies）。装配件可以由一个或多个动态链接库(dynamic link libraries，dlls)和/或可执行文件（executables，exes）构成，并内含他所包含之classes的metadata。单一应用程序可使用来指一个或多个装配件的代码，因此，每一个装配件都可以明确描述他所依赖的其他装配件。
何谓受控代码（managed code）
建立于clr之上的软件，称为受控代码（managed code）,clr提供了好几样东西，用来创建和运行这种特殊代码。最基础的东西是一套可被clr-based语言所使用标准型别集（standard format for metadata），那是“以标准型别建造而成的软件”的相关信息。clr还提供受控代码的打包（packaging）技术和一个用以运行受控代码的运行期环境。
开发受控代码：通用型别系统（cts）
cts定义了核心语义，但没有定义语法。cts并不规定特定语法或关键字，只是定义了一套通用型别，他们可用于许多语言的语法上。每一种语言都可以自由定义他所希望的任何语法，但如果某个语言点基于clr之上，它将至少使用cts定义的一部分型别。
clr-based语言以不同的方式来显露cts types。cts定义的一整套types在clr中聚核心位置。奠基于crl之上的编程语言以一种语言相依方式来显露这些types。尽管一个clr-based语言创造者可以自由实现cts定义之types的任何子集，或甚至加入自己的types，但大多数clr-based语言还是广泛的采用了cts所定义的types。
cls：通用语言规范（common language specification）
cts定义了一套相当庞大也相当复杂的types，但并不是所有的这些types对所有语言都有意义。clr的一个关键目标就是允许开发人员以某种语言撰写代码，并以另一种语言调用这些代码。但是除非两种语言都以同样的方式支持相同的types，否则别想成功。然后如果让每一种语言都实现出每一种cts types，对语言涉及者来说也消受不起。
这个难题的一个折中解决方案就是cls。cls定义了一个庞大的cts子集，任何语言如果想和其他cls语言互通（互操作），就必须准从它。cls定义的是cts的一个子集，是“跨语言互操作性”成为可能。
编译受控代码（compiling managed code）
受控代码经过编译会生成msil（microsoft intermediate language，微软中间语言）和metadata（元数据）。无论受控代码一开始是由什么语言写的，编译器都会将受控代码中的所有types-class、structs、intergers、delegates机其他东西，统统装换成msil和metadata。
微软中间语言（microsoft intermediate language，msil）
msil和处理器原生指令集（processor’s native instruction set）很相似。不过并不存在用以运行这些指令的硬件，至少今天如此。msil代码总是在运行前先被编译为它将运行于其上的处理器的原生代码——不论哪一种处理器都如此。
事实上msil是clr的汇编语言。在上述描述中你可以发现：clr所定义的是一个stack-based抽象机（abstract machine），这意味着很多msil操作是依据这个stack来定义的。msil指令集紧密地和clr cts进行映射。
元数据（metadata）
metadata描述含于模块中的types的相关信息，包括：
type的名称
type的可见性，可为public或assembly
这个type继承自什么型别（如果有的话）
这个type所实现的任何interfaces（接口）
这个type所实现的任何methods
这个type所暴露的任何properties（属性）
这个type所暴露的任何events（事件）
此外还可以获得更多的详细信息。例如每一个method的描述，包括method的参数及其型别，以及返回值得型别。
由于么metadata总是存在，所以工具软件总是可以依赖他，例如visual studio.net便总是使用metadata向开发人员展示，她刚刚敲进去的那些class有哪些methods可用。
attributes（特性）
metadata还包括attributes（属性），存储metadata内的值，可被读取并可用于控制这些代码运行行为的方方面面。.net framework类库在很多方面都依赖于它，包括制定事务需求，指定那些methods应该开放为soap-called web services，以及描述安全需求等等。
组织受控代码：装配件（assembly）
装配件由一个或多个文件组成，这些文件构成了一个逻辑单元。每一个装配件都有一份清单，即装配件的metadata：manifest。清单包含于装配件的某个文件中，并且包含了装配件的信息，以及“组成装配件的文件”的信息。一个装配件可以是由一个或者多个文件组成(dlls, exes, html等等), 代表一组资源, 以及类型的定义和实现的集合. 一个配件也可以包含对其它配件的引用. 所有这些资源、类型和引用都在一manifest中描述。这个manifest也是配件的一部分，所以配件是一个自我描述的，不需要其它附加的部件对其描述! 配件的另一个重要特性是，它是.net环境下类型标识的一部分，也可以说是基本单位。因为，区分一个类型的标识就是包含这个类型的配件名字加上类型名本身。举个例子，配件a定义了类型t, 配件b也定义了同名类型t，但是.net把这两个类型认为是不同的类型。配件也是.net框架用于安全策略的基本单位，许多安全策略都是基于配件的。
装配件可以消除所谓的dll hell。所有的装配件都有一个简单的文本名称，但是也可以由一个“强名称（strong name）”,强名称将是独一无二的，clr利用强名称对装配件进行版本检查，施加强制的版本管理，从而有效地消除所谓的dll hell。如果想将装配件安装到gac（globle assembly cache，全局装配件缓存）中，就一定要有一个强名称。
即时编译（just-in-time compilation，jit）
开发人员编写的受控代码在被编译成msil之后，在运行时会被再编译为原生代码。有两种方式可以完成这个目标，一种是在运行期逐一编译methods的msil代码，另一种是在装配件被运行前整批的全部编译为原生代码。
将msil编译为原生代码的一个最常见的办法，就是先让clr装在装配件，然后在每个method第一次被调用时编译之。由于每个method都只在第一次被调用时才被编译，所以我们称之为即时编译（jit）。每一个methods在第一次调用被编译之后便会被缓存起来，这样后面再次调用的时候便无须再编译。
当一个method被编译时，同时也被检查型别安全，这个过程被称为验证（verification），检查范围包括method的msil和metadata，以确保代码没有做非法访问。待会将要讲到的“clr内建安全功能”即依赖这个验证过程，它也被用于检验受控代码行为的其他方面。
代码访问安全（code access security）
代码安全问题一直是一个令人头痛的问题，你不知道你安装的软件在你的电脑上做了些什么。尤其在internet无处不在的今天，更是可能给你带来巨大的安全危机。必须要有一种办法来限制代码——尤其是下载而来的代码——的活动范围。
“代码访问安全”机制可限制运行中的代码的行动范围。目前，控制“下载代码是否可运行”的windows典型解决方案是：问用户，但是.net代码安全机制并不依赖用户的知识。clr-based代码究竟能做些什么，有赖两种东西的交集：代码要求的“权限”是什么？代码运行时安全策略实际上授予的“权限”又是什么？为了标明它需要哪一种访问权限，装配件可以精确的指明需要运行环境给它什么样的权限。代码访问安全性使得clr可以根据装配件名称、发布商、从何而来等线索，限制特定装配件的行为能力。这种机制非常具有弹性，提供很多选项，可以满足广泛的要求。而且，在一个弥漫全球网络和移动代码的世界里，题共一种强制手段来限制代码的行为能力和范围，实在是不可或缺。
角色安全性（role-based security）
clr提供的角色安全性解决了代码访问安全性所不能解决的另一个问题，那就是如何去限制某些用户可以运行某些代码，而另一些用户则不能运行这些代码。clr允许为每一个method添加属性来指明允许运行这段代码的有哪些角色，之有用户所扮演的角色与之相匹配时，这段代码在被允许运行。
垃圾回收（garbage collection）
“垃圾回收”机制自动释放不再被使用的对像。对于每一个c++程序员来说，可能最头痛的就是内存泄露问题了，可能c++程序员认为，内存太重要了，所以不能由系统来自动管理。但在计算处理能力高速发展的今天，.net程序员认为，如何处理业务逻辑，建立随需应变的系统才是最重要的，既然如此，又何必不把内存交给系统来管理，自己好腾出精力来实现业务逻辑呢？
在.net framework应用程序执行过程中，managed heap起到了至关重要的作用。每一个reference type（例如每一个classes和每一个string）的实体都没分配于heap之上。一旦应用程序运行起来，heap内存会被塞满。为了创建新的实体，程序必须获得更多可用空间。这件事的处理过程称为“垃圾收集”。
垃圾回收器跟踪并回收托管内存中分配的对象，定期执行垃圾回收以回收分配给没有有效引用的对象的内存。当使用可用内存不能满足内存请求时，gc会自动进行。
在进行垃圾回收时，垃圾回收器回首先搜索内存中的托管对象，然后从托管代码中搜索被引用的对象并标记为有效，接着释放没有被标记为有效的对象并收回内存，最后整理内存将有效对象挪动到一起。这就是gc的四个步骤。
由上可见，gc是很影响性能的，所以一般说来这种事情况还是尽量少发生为好。
为了减少一些性能影响，.net的gc支持对象老化，或者说分代的概念，代是对象在内存中相对存现时期的度量单位，对象的代数或存现时期说明对象所属的代。目前.net的垃圾回收器支持三代。每进行一次gc,没有被回收的对象就自动提升一代。较近创建的对象属于较新的代，比在应用程序生命周期中较早创建的对象的代数低。最近代中的对象位于零代中。每一次gc的时候，都首先回收零代中的对象，只有在较低代数的对象回收完成后仍不能满足需求的情况下才回收较高代数的对象。
应用程序域（application domains）
应用程序域又是一个新的概念。我们知道，进程可以将“它所包含的应用程序”和“其他所有应用程序”隔离开来，从而使一个应用程序的崩溃不会影响到其他的。但这会影响性能，也使得进程间的通信变得很困难。
而应用程序域给我们提供了另外一种解决问题的办法，一个进程可以包含多个应用程序域，每个应用程序域内的应用程序彼此隔离，避免了“为每一个应用程序启动一个新进程”所带来的开销，之间的通信却又比进程间通信有效率的多。appdomain提供了进程的好处，而且没有进程带来的大开销。
app domains提供了一个适应于多种平台的一致环境。.net framework意图运行于windows和其他可能的操作系统上，而不同的操作系统有完全不同的进程模型（process models），尤其小型设备所使用的系统更是如此。让app domains定义自己的进程模型，有助于.net framework跨越所有平台，提供一个一致的环境。
六． .net语言
1. visual basic.net
在windows世界里，visual basic绝对是最流行的编程语言，visual basic.net为这个广泛使用的工具带来的翻天覆地的变化。vb.net建立于clr（通用语言运行层）之上，因此这个语言的大部分成分已经被clr有效界定了。实际上除了语法，你很难看得出如今的vb.net和当年的vb有什么相似之处了。从大的方面来讲，vb.net支持继承、委托（delegates）等新的特性，从小的方面来讲，vb.net数组的索引是从0开始了！
2. c++.net
c++.net其实应该说叫做带有受控扩充件（managed extensions）的c++。
c++是一门非常流行的语言，一门已被广泛使用超过10年的语言。“提供某种方式使c++能够和.net framework”是不可或缺的。然而同vb一样，c++的语义同clr的语义并非严格匹配。更糟的是，微软并不拥有c++，所以微软并不能像对visual basic动大手术那样也对c++来个脱胎换骨的修改。如果单方面修改这个语言使其和clr相配，会遭到严重的抗议，但如果不提供“让开发人员得以运用c++创建.net framework-based 应用程序”的方法，也会让很多开发人员不痛快，至少，比尔盖茨会很不痛快。
于是，微软选择开发一个相对于基本c++语言而言的扩充集。正式的名称是managed extensions for c++。
新的c++定义了几个新的关键字，他们均以两个下划线开头，其中最重要的有如下所示：
__gc：指出某个type受垃圾回收机制的管制，换句话说这个关键字意味着他所声明的types是个cts reference type。
__value：指出某个types不受垃圾回收机制的管制，换句话说它所声明的types是个cts value type。
__interface：用以定义一个cts interface type（接口型别）。
__box：将cts value type转换为reference type。
__unbox：将装箱的(boxed)cts value type转回其原来形式。
__delegate：用以定义一个cts delegate type（代理型别）。
基于以上的改变，managed c++有了这么一些特性：
managed c++代码和unmanaged c++代码可共存于同一个进程中。
managed c++允许完全访问clr特性。
c++是visual studio.net中唯一能直接编译为原生代码（native code）的语言。
c++语言不会寿终正寝，但它的作用将会收敛，可能还会收敛的相当厉害，作为一种“开发广泛应用程序的首选工具”的日子已经终结。
3. c#
c#是一种有着和c语法相似的面向对象语言
正如其名字所暗示的，c#是c语言家族中的一个新成员。c++从c衍化而来，严格的说，c++由于带着c的包袱从而并不是一个严格的面向对象的语言。而c#不同，c#十足的面向对象，也并不带来几近残酷的复杂度。对于拥有c++或者java背景的任何人来说，c#尤其平易近人。
c#和clr的标准化
微软已经将c#和cli（common language infrastucture，通用语言基础设施，clr的一个子集）提交国际标准化团体ecma，他们正朝着ecma标准之路迈进。随同c#一同被提交并期望获得标准化的还有：metadata（元数据）的语法和语义、msil(重命名后脚common intermediate language，cil，通用中介语言)，以及一部分.net framework类库。
sun曾经对java做过类似的事情，但在最后一刻退缩了。sun拒绝迈出这一步是因为不愿放弃对java的控制。从这一点上来说，c#的前景可能会值得期待一些。
interfaces（接口）
接口（interface）用来定义一种程序的协定。实现接口的类或者结构要与接口的定义严格一致。有了这个协定，就可以抛开编程语言的限制（理论上）。接口可以从多个基接口继承，而类或结构可以实现多个接口。接口可以包含方法、属性、事件和索引器。接口本身不提供它所定义的成员的实现。接口只指定实现该接口的类或接口必须提供的成员。
接口好比一种模版，这种模版定义了对象必须实现的方法，其目的就是让这些方法可以作为接口实例被引用。接口不能被实例化。类可以实现多个接口并且通过这些实现的接口被索引。接口变量只能索引实现该接口的类的实例。
属性
属性可以说是c#语言的一个创新。当然你也可以说不是。不是的原因是它背后的实现实际上还是两个函数--一个赋值函数（get），一个取值函数(set)，这从它生成的中间语言代码可以清晰地看到。是的原因是它的的确确在语言层面实现了面向对象编程一直以来对“属性”这一oo风格的类的特殊接口的诉求。理解属性的设计初衷是我们用好属性这一工具的根本。c#不提倡将域的保护级别设为public而使用户在类外任意操作--那样太不oo,或者具体点说太不安全！对所有有必要在类外可见的域，c#推荐采用属性来表达。属性不表示存储位置，这是属性和域的根本性的区别。
delegates（代理）、event（事件）
代理实现的是象c++等语言的指针功能，不同于函数指针，代理是一种面向对象、安全类型的。代理事派生于公共基类（system）的一种参考类型，方法被压入一个代理中，对于实例方法被称为实例的组成实体或关于实例的方法，而静态方法，被称为类的组成实体或类方法。代理的强大功能是它可以自动的匹配方法，而不管其类型。
基于其上的，c#还定义了一个完全oo的东西，event（事件），形象地说，事件是对象用来“发出通知”的成员。根据你的需要，你可以订阅某一个对象中的事件并响应该事件做出相应的处理。
七． .net framework类库(class library)
名字空间（namespace）
和com类库的平面化结构不同的是，.net 类库被组织为一套具有层次结构的名字空间。每个名字空间可以包含types如classes和interfaces，以及其他次级名字空间（sub-namespaces）。整个体系的root名为system，每一个.net framework应用程序都回用上system所含的一些types。其他名字空间所含的types也可能被许多开发人员经常使用。system是基础，但不是全部。
.net 类库的结构
八． 访问数据：ado.net
与数据打交道，如搜索、更新和处理等，使软件的基本任务。今天，大部分数据通常被存储于某种类型的数据库管理系统中（dbms）中，通常是关系型数据库（relational database）。开发人员需要某些机制，允许他们的应用程序访问这些信息。windows dna有一组名为activex数据对象（activex data objects,ado）的com classes，解决了这个问题。net framework中的结局方案时ado的激进更新版。
与 ado 的早期版本和其他数据访问组件相比，ado.net 提供了若干好处。这些好处分成以下几个类别：
互操作性
ado.net 应用程序可以利用 xml 的灵活性和广泛接受性。由于 xml 是用于在网络中传输数据集的格式，因此可以读取 xml 格式的任何组件都可以处理数据。实际上，接收组件根本不必是 ado.net 组件：传输组件可以只是将数据集传输给其目标，而不考虑接收组件的实现方式。目标组件可以是 visual studio 应用程序或无论用什么工具实现的其他任何应用程序。唯一的要求是接收组件能够读取 xml。作为一项工业标准，xml 正是在谨记这种互操作性的情况下设计的。
可维护性
在已部署系统的生存期中，适度的更改是可能的，但由于十分困难，所以很少尝试进行实质的结构更改。这是很遗憾的，因为在事件的自然过程中，这种实质上的更改会变得很有必要。例如，当已部署的应用程序越来越受用户欢迎时，增加的性能负荷可能需要进行结构更改。随着已部署的应用程序服务器上的性能负荷的增长，系统资源会变得不足，并且响应时间或吞吐量会受到影响。面对该问题，软件设计者可以选择将服务器的业务逻辑处理和用户界面处理划分到单独计算机上的单独层上。实际上，应用程序服务器层将替换为两层，缓解了系统资源缺乏。
该问题并不是要设计三层应用程序。相反，它是要在应用程序部署以后增加层数。如果原始应用程序使用数据集以 ado.net 实现，则该转换很容易进行。请记住，当用两层替换单个层时，将安排这两层交换信息。由于这些层可以通过 xml 格式的数据集传输数据，所以通讯相对较容易。
可编程性
visual studio 中的 ado.net 数据组件以不同方式封装数据访问功能，帮助您加快编程速度并减少犯错几率。例如，数据命令提取生成和执行 sql 语句或存储过程的任务。
强类型的数据集
由这些工具生成的 ado.net 数据类导致类型化数据集。这又使您可以通过已声明类型的编程访问数据。最后，已声明类型的数据集的代码更安全，原因在于它提供对类型的编译时检查。例如，假定 availablecredit 表达为货币值。如果程序员误向 availablecredit 分配了字符串值，则环境会在编译时向程序员报告该错误。当使用未声明类型的数据集时，程序员直到运行时才会知道该错误。
对于不连接的应用程序，ado.net 数据库提供的性能优于 ado 不连接的记录集。当使用 com 封送在层间传输不连接的记录集时，会因将记录集内的值转换为 com 可识别的数据类型而导致显著的处理开销。在 ado.net 中，这种数据类型转换则没有必要。
可伸缩性
因为 web 可以极大增加对数据的需求，所以可缩放性变得很关键。internet 应用程序具有无限的潜在用户供应。尽管应用程序可以很好地为十几个用户服务，但它可能不能向成百上千个（或几百万个）用户提供同样好的服务。使用数据库锁和数据库连接之类资源的应用程序不能很好地为大量用户服务，因为用户对这些有限资源的需求最终将超出其供应。
ado.net 通过鼓励程序员节省有限资源来实现可缩放性。由于所有 ado.net 应用程序都使用对数据的不连接访问，因此它不会在较长持续时间内保留数据库锁或活动数据库连接。
下一代的sql server：yukon
yukon是预定2005年供货的sql server的新一代版本。集成了.net framework 2.0。sql server "yukon"、.net 技术和 microsoft 开发者工具之间更深入的整合将提高开发人员产能和弹性，让开发人员得以：
建置并维护强固、安全、可扩充的数据库应用程序。开发人员将拥有一套适用于 transact-sql、xml 和 multidimensional expression (mdx) 的开发工具。与 visual studio® 开发环境的整合将提供更有效的实务和商业智能应用程序开发和侦错。sql server "yukon" 也将包含对 transact-sql 语言的强大改进。
从更多的开发弹性中获益。借着内嵌在数据库引擎的 common language runtime (clr)，开发人员将可以从多样化的熟悉语言中选择，用来开发数据库应用程序，包括 transact-sql、microsoft visual basic® .net、microsoft visual c#® .net 和 microsoft visual j#™ .net。此外，clr 整合将透过使用者定义的型别和函式，为开发人员提供更多的弹性。clr 也将提供机会，让使用协力厂商的程序代码能够快速开发数据库应用程序。
跨任一种平台、应用程序或装置以共享数据。对于诸如原生 xml 支持、使用者定义的数据型别和 xquery 的改进将让组织完美连接内部和外部系统。sql server "yukon" 将提供关系型和 xml 数据的原生支持，让企业得以最适合其需要的格式储存、管理和分析数据。对于现有和新出的开放标准，如超文字传输协议 (http)、xml、简单对象存取协议 (soap)、xquery 和 xml 结构描述定义 (xsd) 的支持，也将加速横跨已扩展之企业系统之间的通讯。
九． 开发windows相关应用
有些时候，browser-based应用程序似乎接管了这个世界。尽管开发人员曾经投入大量时间，彻底搞清楚windows gui是怎么回事，他们现在也为html和javascript细节留下了豆大的汗珠。对于现在软件来说，浏览器已经成了新的缺省界面。
但是windows guis依然不可小觑。浏览器虽然占据支配地位，但直接访问屏幕象素的应用程序，并没有消亡。.net framework设计者提供了一套崭新的classes，是clr-based应用程序能够构建windows guis。包含于system.windows.forms名字空间中的这套classes通常被称为windows forms。
1. 本地应用程序
典型的gui模型是一个form，带有负责响应事件的代码。windows forms遵循这种传统模型。每一个form都是form class的一个实体，而接受和派发事件的消息循环，由application class提供。form class的每一个实体都有一大套properties，用来控制form在屏幕上显示的外观。forms通常包含其他class，统称为windows forms控件（controls），他们一般用于展示某种输出，接受用户的某些输入，抑或兼而有之。空间也拥有properties，yon与定制其外观。forms和controls都可以相应events，并做出某种动作。
另一个相关的技术就是gdi+了
gdi+ 是 microsoft windows xp以及后续windows操作系统的子系统，同时又是.net提供的一种新的简单、快速的图形图象开发技术。顾名思义，gdi+ 是 gdi（windows 早期版本提供的图形设备接口）的后续版本。gdi+ 是一种应用程序编程接口 (api)，通过一套部署为托管代码的类来展现。这套类被称为 gdi+ 的“托管类接口”。
程序员可利用gdi+这样的图形设备接口在屏幕或打印机上显示信息，而不需要考虑特定显示设备的具体情况。应用程序的程序员调用gdi+类提供的方法，而这些方法又反过来调用特定的设备驱动程序。gdi+ 将应用程序与图形硬件隔离，而正是这种隔离允许开发人员创建设备无关的应用程序。
2. 智能客户端技术
smart client是什么
简而言之，smart client智能客户端就是这样一种一个可扩展的能集成不同应用的桌面应用程序：它可以无接触部署、即需即装、动态加载，xcopy即可运行而无须修改注册表，可以动态升级、自动更新，可以方便的经web运行而不用担心防火墙问题并可以方便的离线运用，方便的连接webservices的windows应用程序。
smart client的特点
动态加载，即需即装
应用程序的各个构件之间的相互调用并不采用直接引用的方式，而是采用动态加载，即需即装的方式，有效地降低了对系统资源的消耗。应用软件开发商可根据企业应用系统的公共接口进行开发，然后将应用组件发布在企业的服务器上，客户端应用程序将自动发现并加载该应用组件。
更松散的耦合
由于上面第一点所言构件之间的相互调用并不采用直接引用方式，这样系统实现的更松散的耦合，为应用程序升级更新提供了方便。
进一步的模块化
由于应用程序的松散耦合特性，使得系统的进一步模块化成为了可能，新功能、新特性的加入只需要开发出符合接口定义的新模块并添加连接即可。而无须修改重编译现有的程序。
零接触部署
安装时只要将一个主程序文件下载到本地，直接运行即可，无须改变注册表或共享的系统组件，其他应用组件将在第一次运行时自动下载。
网络加载应用程序组件
smart client的应用程序可以很方便的从网络服务器加载应用程序，而且因为程序及加载是从80端口实现，故无须考虑防火墙问题，这样为企业系统的集中管理提供了方便。
自动更新
只需将新版本的程序发布在服务器上，由客户端自动发现最新版本的程序和应用组件，并自动下载和更新。
在线与离线均可使用的应用程序
smart client应用程序尽管使用网络加载程序集，但一旦加载之后，程序集便被缓存到了本地。当用户至少启动了一次应用程序后，其装配就被下载和缓存到本地内存中了，所以用户就可以离线运行你的智能客户端了（通过转换浏览器到离线工作状态），假设应用程序不需要永久访问web services或一个共享的数据库就可以运行。
构建智能客户端的最大的好处就是可以离线使用。尽管业务之间的联系越来越紧密，但我们仍不能给企业应用程序提供始终连续的连接。离线式工作方式可以在你重新在线时，自动接收数据和应用程序更新，这种特征是人们很想得到的，但在.net前，这是很难实现的。同胖客户端一样，智能客户端给客户端分布大量的处理，这就为服务器免除了它在一个基于web的应用程序中需要承担的负荷。最后，智能客户端采取一种用户希望应用程序采取的工作方式——允许快速数据存取和管理，而不需要不必要的屏幕更新。
个性化用户界面
用户可根据喜好自行设置客户端应用程序，配置信息将被保存到服务器上。
与webservices的完美集成
smart client应用程序可以与webservices方便的集成应用，这样便可以轻松享受c/s应用程序的完美用户体验而不需担心防火墙等等的一系列问题。
smart client的优势
尽管有大量的广告，但瘦web解决方案并没必要成为所有企业应用程序的未来。不要丢弃用winforms来构建企业应用程序这种想法，因为企业应用需要集中的分布。下面的这张表格描述了smart client和其他解决方案之间的对比：
表 1 比较几者
通过将智能客户端的功能和web应用程序的功能进行比较，可以简化你的决策过程。
smart client的工作模型
图1. 智能客户端的工作模型
应用程序加载器用http从web服务器上的一个虚拟目录来访问和下载装配。下载后，装配被缓存起来，只有需要的时候才执行它们。
3. windows的未来：longhorn
2003年5月，微软公司在新奥尔良windows硬件开发人员论会上（winhec），进行了windows下一操作系统 longhorn的内部首映。微软公司在论会上介绍了longhorn操作系统的发展计划，并且认为longhorn是windows 95操作系统以来，继windows xp操作系统之后，功能最强大，性能最突出的桌面操作系统。
longhorn的关键技术：
应用程序编程模型“winfx”。对“.net framework”的编程模型的扩展，微软表示：“将大幅提高开发人员的开发效率和应用程序的安全性”。你甚至可以认为，.net framework将更名为winfx，成为longhorn主要api。
图形技术“avalon”。是用户界面、文档和用于显示多媒体的综合架构。
存储技术“winfs”。将强化检索、关联和使用信息的手段。根据特定需求而采用相应的应用程序数据结构。
通信技术“indigo”。对web服务提供支援，能够交换高安全性的信息，并能进行互连。
十． 开发web相关应用
经由web来访问软件已经是一件稀松平常的事情了。大多数新式企业应用程序至少提供浏览器界面的选项，甚至只提供浏览器界面。鉴于此，如果一个应用平台没有为构建web-based的软件提供一级支持，那简直注定要失败。事实上，通过web使用软件的方式也在不断变化之中，通过浏览器来和用户交流当然重要，但web services也闪亮登场了。web已经从单纯的眼球驱动的世界，扩张到也由应用程序驱动的世界。
asp.net是.net framework用于构建web相关应用的首要基础。作为.net framework类库的一个组成，它同时支持创建“浏览器应用”和“web services应用”，两者都依赖共通的基础设施。
1. 浏览器应用程序
从前的asp：意大利面条
asp.net的新性能：
代码分离
这个功能又叫做代码隐藏(code-behind)，将代码放在单独的文件中，你将不会再看到意大利面条似的代码了。
（类似）事件驱动模型
asp.net实现了类似事件驱动模型这样的机制，但由于http是一个无状态的协议，还只能称之为“类似”。
web controls
web controls使创建forms 和html controls.的工作将会变得简单易行。例如，在asp中典型的选择框/ select box里，你不得不创建一个循环以便让控制系统装入数据。但在asp.net里，你将会拥有一个"data-bound"，这意味着它会与数据源连接，并会自动装入数据。
语言支持
asp.net支持多种语言，它的缺省语言将是：visual basic而不是vbscript，这意味着我们可以摆脱vbscript的语言限制，我们的代码将是编译后运行的（而不是原来的解释执行）。
更好的代码控制
对于com对象不再需要再在服务器上注册的这个功能我们是非常喜爱的。但是通过这种过程简化，你再也不能够在你的服务器上运行 另外一个dll版本，并且代码相当保密，这意味着，如果没有正确的开发工具和源代码，很难改变代码。
更好的升级能力
此系统建成，本身有着一定的特性，以改进多处理器和串环境中的性能。例如，session state 能够通过单独的处理器来维持，在一个单独的机器上，甚至在数据库中允许交叉的服务器会话。
2. web services应用
asp.net中的web serivces应用程序依赖.asmx网页
就像迄今所描述的浏览器应用程序一样，服务器端的asp.net web services应用程序也依赖网页。这些网页所在的文件都有一个.asmx扩展名，其内不含任何的html，只是一些代码。这是因为服务器仅仅是被软件访问，而非被人访问，所以无需html，换句话说，服务器并不展示用户界面。
web method attribute用以将method开放为web services
为了将一个包含于.asmx文件内的method开放为一个web service，你唯一要做的事情就是在method的声明方面插入web method attribute，这样就可以了。一旦文件被建议，这个attribute将被存储在“为此而产生之装配件”的metadata中，就像所有其他特性一样。他向asp.net技术设施提供了一个信号：这个method应该可以被web service访问。
web service客户端依赖proxies(代理)
客户端为了使用web services，开发人员必须首先创建一个开放了相同method的proxy class。利用这个代理类的信息，客户端就知道该如何去调用并享受服务。
.net remoting
.net remoting 不属于asp.net的技术范畴，但提供了与web services相似的功能。
.net remoting与web services的比较：
都是采用了soap协议
.net remoting仅限用于通信双方都是.net平台的情况下，而web services致力于提供一个不同平台下应用软件不同的能力。
在通信双方都是.net平台的前提下，.net remoting提供了更高的性能。
十一． 基于smart device的开发
何为smart device
smart device的中文意思就是“智能设备”，泛指smart phone、pocket pc等使用了windows ce操作系统的移动的、嵌入式的或者具有人机交互功能的电子产品。pocket pc(以下简称ppc)想必大家已经都很熟悉了，现在国内已经有相当的用户群体。国际大厂如卡西欧、康柏等的产品早已进入中国市场，国内公司如联想也积极推出类似产品，争夺这片未来很有潜力的市场。
何为.net compact framework
微软为了实施.net战略，在一年前推出了面向windows平台的.net framework 1.0，我想这一点大家已经很熟悉了。在2003年4月份，微软又推出了windows server 2003和visual studio .net 2003。其中windows server 2003中更是集成了.net framework 1.1，而vs.net 2003中也增加了不少新鲜的开发模版。
.net compact framework的中文名称就是.net framework精简版。简单来说如果windows ce操作系统是嵌入式或移动电子设备上的windows，那么.net compact framework就是这些设备上的.net framework。实际上.net compact framework是.net framework针对嵌入式或移动电子设备的子集和补充。.net compact framework有两个主要组件：公共语言运行库和 .net compact framework类库。
公共语言运行库
公共语言运行库提供了管理 .net compact framework代码的执行环境。代码管理的形式可以是内存管理、线程管理、安全性管理、代码验证和编译以及其他系统服务。
运行时是为了增强性能而设计的。它使用实时 (jit) 编译的方法，使托管代码能够以运行应用程序的平台的本机语言运行。这样，您就可以创建适用于多种平台的应用程序，而不用再担心如何分别为每个平台重新编译或重新生成可执行程序了。
即使您的移动应用程序与托管代码一样都是用 visual basic .net 或 c# .net 编写的，仍然可以集成存储在动态链接库（dll，包括 windows ce api）外部的功能和子例程。.net compact framework提供的数据类型以及对结构的支持使您能够轻松地将 windows ce api 的功能集成到您的应用程序中。
.net compact framework类库
.net compact framework类库是与公共语言运行库紧密集成的可重复使用类的集合。您的应用程序将利用这些库来派生出所需的功能。就像其他面向对象的类库一样，.net compact framework类型可用于完成许多常见的编程任务，包括界面设计、利用 xml、数据库访问、线程管理和文件输入/输出等。
.net compact framework 是.net framework完全版的一个兼容子集
由于.net compact framework是.net framework完整版的一个兼容子集，这就意味着，您可以使用您熟悉的vb.net或者c#方便地为pocket pc开发应用程序，并且您不需要考虑该ppc的处理器是arm、mips还是其他的什么处理器，更妙的是，这应用程序在您的台式机上一样能很好的正常工作！
十二． office的扩展应用
将 office 用作业务解决方案平台
开发人员可以将 microsoft office 2003 应用程序用作创建自定义解决方案的平台。office 使开发人员可以利用一套丰富的预置功能。
将 microsoft office word 2003 或 microsoft office excel 2003 用作解决方案前端使开发人员可以利用熟悉的用户界面和强大的工具，例如拼写检查、多语言支持、更改跟踪和数据透视表。另一个优点是脱机使用解决方案的客户端部分，这与使用基于 web 的结构相比，更容易实现复杂的解决方案。
用于 microsoft office 系统的 visual studio 工具
用于 microsoft office 系统的 microsoft visual studio 工具可以帮助您创建解决方案，方法是使用 visual basic .net 和 visual c# 扩展 word 2003 文档和 excel 2003 工作簿。用于 office 的 visual studio 工具中包括新的 visual studio .net 项目，用于创建 word 文档、word 模板和 excel 工作簿的后端代码。这些项目包含：
对项目主要的主互操作程序集的引用
对所需系统组件的引用
项目初始化
使开发人员可以快速入门的安全设置
用于 microsoft office 系统的 visual studio 工具可以帮助您快速创建解决方案，它利用了每个应用程序的内置功能并提供以下优点：
word 和 excel 的后端托管代码
用于 office 的 visual studio 工具中包括 visual studio .net 项目，以帮助您在 visual studio .net 环境中用 visual basic 和 c# 编写 word 和 excel 的后端托管代码。您的代码对文档或工作簿中发生的事件进行响应。有关更多信息，请参见使用托管代码扩展的 office 解决方案的结构。
部署和维护
在部署使用托管代码扩展的 office 解决方案时，可以将编译代码和文档存储在共享位置以便于维护；也可以将程序集和文档的副本分发给每个用户以适应移动工作方式。
安全
使用由 microsoft .net framework 提供的安全功能实现安全。对于使用用于 microsoft office 系统的 visual studio 工具创建的程序集，默认策略是不允许任何程序集运行，这有助于保护用户不受病毒和其他恶意代码的攻击。在最终用户可以利用文档的托管代码扩展之前，管理员必须显式对程序集授予完全信任。
脱机访问
如果将程序集部署到可以用 web 地址（http:// 或 https://）访问的网络位置，可以使用 internet explorer 功能将该程序集缓存到本地计算机上。这使本地文档可以在未连接到网络时使用该程序集。如果将文档和程序集的本地副本同时部署到每个用户，就无须考虑网络连接问题了。
解决方案的典型结构
下面的关系图阐释了一个典型的解决方案结构。该关系图的上部显示从最终用户角度出发的运行时体验。
运行时涉及最终用户的步骤：
1．最终用户打开具有托管代码扩展（指向托管代码程序集的自定义属性）的文档或工作簿。
2．文档或工作簿从共享网络位置下载编译后的程序集。
3．程序集响应文档或工作簿中的事件。
该关系图的下部是从开发人员和（可选）设计人员角度出发的设计时体验。
设计时涉及开发人员和设计人员的步骤：
1．开发人员在 visual studio .net 中创建 microsoft office 2003 项目。该项目包括文档和在该文档后端运行的程序集。该文档可以是已存在的文档（多半是由设计人员创建的），或者也可以随项目创建一个新文档。
2．设计人员（创建该项目的开发人员或其他人）为最终用户创建该文档的最后外观。
由于开发人员主要在 visual studio .net 中工作，最终用户主要在 microsoft office 2003 中工作，因此可以用两种方式理解使用托管代码扩展的 office 解决方案。
开发人员的角度
最终用户的角度
开发人员使用 visual studio .net 编写 word 和 excel 可以访问的代码。
尽管开发人员似乎在创建一个运行 word 或 excel 的可执行文件,但实际的工作方式却不是这样的。文档与一个程序集相关联，并包含指向该程序集的指针。打开文档时，word 或 excel 定位该程序集并针对所有已处理的事件运行代码。
使用解决方案的人只须同打开任何其他 office 文件一样打开文档或工作簿（或从模板创建新文档）。
程序集在文档或工作簿中提供自定义功能，例如用当前数据自动填充它，或显示对话框以请求输入信息。该代码执行这些动作时，用户并不知道此文档与其他任何 office 文档有何不同。
十三． .net my services
基于xml web service的下一代计算模式已经为业界认同，作为产品线较长的软件厂商，microsoft已经在通向下一代的道路上领先了。继推出了xml web service的各种相关产品之后，microsoft最近又发布了自己的基于xml web service的平台，这就是microsoft my services。在过去很长一段时间里，my services曾以其开发代码hailstorm为人所关注。
信息沟通的挑战
虽然在过去的25年里，信息技术的非凡价值已经得到了用户的普遍认同，但至今仍远没有发展成熟，在很多方面有待加强和提高。各种设备和应用程序各自为政，并不考虑与周围世界的联系。
由此造成的后果是，每一种设备、每一种应用程序乃至每一个web站点都有自己的一套规则和使用方法，造成用户的困惑。例如，我们向pc中输入朋友的电话号码需要按照一定顺序敲击键盘，而向palm pilot、pocket pc或者移动电话中输入同样的电话号码所需的方法则完全不同。因此，我们不得不从最基本的字符输入法开始，学习使用每一种设备。
虽然我们为信息化的进步而骄傲，但我们并没有真正掌握身边的信息和设备，不难发现，我们的重要信息散落在技术空间的成百上千个角落里: 在某个pc的应用程序里、单位的某个服务器里、cookie里以及网站的用户跟踪表格里……移动电话中存储的电话号码并不为电子邮件程序所知，因为这2种技术无法了解对方的语言。
如果您搬家，改变了住址，您往往不得不在每一个web站点中更新您的送货地址，如果万一某次疏忽了，“方便的”internet会带给您一次不大不小的教训。您可能并不能拥有您的个人信息，它经常会被遗忘在某个internet孤岛上。各种应用、web站点以及服务的孤立特性使得各种技术很难有效地协同工作。如果您在网上订了机票，因为缺乏有效的沟通方式，web站点很难将您的行程自动同步到日程安排应用程序里，即使实现了，通讯的双方也不能保证客户是同一个人。
也许我们不得不承认，现在，我们实际上是在被动地去适应信息技术，在享受新技术的成果之前，我们首先要适应被强加的新规则。这种不便事实上限制了更有创造性的新技术和新产品的发展和应用。
初识.net my services
按照microsoft的定义，.net my services是一套以用户为中心的软件服务结构框架，是若干各种用途的xml web services的集合。microsoft .net my services能够简化将现有的各种孤立应用集成的工作。最大的变化在于，.net my services是面向用户的，而不是面向特定设备或应用的。它使用户能够真正控制自己的信息、保护私人数据，使得个性化服务更易实现。得益于microsoft .net技术，.net my services能够使各种设备、应用和服务有效地协同工作，而用户可以控制谁可以访问自己的信息，具有哪种层次的访问权限，以及有效期限等。
面向用户，或者说以用户为中心实际上是以用户数据为中心。因此，.net my services对用户数据的安全非常重视，通过microsoft .net passport来保证数据的安全、完整和私密性。在任何应用需要访问用户数据时，都需要用户进行确认。
以订机票为例，通过.net my services，在线旅行票务预订服务可以自动访问用户的个人意向信息和付款服务(经过用户的确认)，如果用户是进行商务旅行，则在线旅行票务预订服务还要经过.net my services的个体群属关系服务确定用户在公司的位置、从属关系，并根据公司的商务旅行政策进行匹配，使得航班级别与日程安排能够符合公司的有关规定。一旦选定了航班，旅行服务还能自动选择相应的日程安排服务，自动更新路线信息，并在航班延误时进行通知。通过.net my services，您还可以共享出日程安排，使接待方随时了解您的动向。而您的日程安排信息可以通过您的pc、其他人的pc、某台智能电话、pda以及任何智能信息设备来访问。
.net my services工作原理
.net my services实际上由3部分组成，即身份认证(.net passport)、消息传递(soap)以及数据描述(xml)。图2显示了应用程序使用.net my services访问用户数据的过程。
.net passport
.net passport是使用kerberos协议来完成身份认证的，windows 2000和windows xp都使用了kerberos协议。简单地说，kerberos通过集中存储的安全信息和分布式的“tickets”来实现用户身份认证。具体而言，.net my services通过如下步骤实现用户身份验证。
用户开启客户端应用程序或浏览器，打开登录界面，并输入用户名和口令。
登录动作引发客户端应用程序或网站向.net passport请求一个登录确认证明(即“ticket-granting-ticket”，tgt)。
.net passport验证用户口令，颁发tgt，确认登录已经成功。在满足一定安全约束条款的前提下，该tgt在一定时期内被缓存。
客户端应用程序或网站向.net passport(它这时所扮演的角色是kerberos中的“证明颁发服务器”)提交tgt，同时请求颁发一个“会话证明” (即session ticket)。
.net passport使用tgt来验证客户端的身份是否正确（即是否有效），确认后向相应的web service颁发会话证明。
客户端向所请求的web service提交会话证明，经确认后，客户端与web service的信息交换展开，所有数据都经由该会话证明加密从而确保安全。
soap
soap是基于xml的协议，一条soap消息由3部分组成。首先是信封(envelope)，用来描述消息的结构、内容以及处理方法。其次是一套规则，描述处理不同类型数据的方法。最后是关于原过程调用及其相应方式的约定。
通过soap，应用程序不仅能够实现数据共享，还能够调用远端应用对象的方法和属性，而不必了解对方的应用程序结构，也不需要特定的二进制代码、运行时库以及任何平台相关的条件。 .net my services通过soap协议来访问web service。
xml
.net my services的最底层是xml，一种基于sgml的文本形式的标记语言。xml具有可自描述，以数据为中心的优秀特性。关于xml的相关资料已经有很多，在此不多赘述。
十四． .net的开发工具(visual studio.net)
在2001年亚特兰大的tech ed 2001大会上，比尔·盖茨对热忱的开发人员介绍了microsoft最新的开发环境。不过，visual studio .net作为net平台的基石，不仅仅是一个开发环境。visual studio.net是用开发人员用于创建应用程序的技术构建的。
由于通用语言运行时（common language runtime），visual studio.net为c++、c#和vb程序员提供了通用的开发环境。jscript程序员在创建asp.net 和 web服务应用程序时将得到visual studio.net有限的支持。而xml开发人员将非常喜欢它对xml文档、xml大纲和xsl转换的强大支持。
实践
visual studio .net的设置很容易。安装程序将带你经过主要的3个步骤：更新系统组件，安装 .net框架，增加visual studio .net。如果喜欢完全安装，你还将得到c++及其类库和工具，c#和vb。你还将获得crystal reports、服务器组件及用于重新分布应用程序的工具。在环境调用时，将出现一个与浏览器类似的窗口，你会被带到开始页，此页包含了对在线资源、更新、新闻和下载等等内容的链接。下载链接特别有用，因为它将你直接带到microsoft的msdn区，在那里可以获得最新的软件工具包、源代码示例及参考实现。web主机链接带给你一个包含了支持asp.net的公司列表的网页。如同microsoft所说: “每个公司给你提供一个实验用测试场所”。另一个链接使你能够根据你目前的开发类型修改造型。例如，人员可以选择interdev造型，设置类似于visual studio 6的键盘和窗口布局，设置帮助文件过滤器——它只弹出与互联网开发相关的文档。 visual studio.net充分利用了屏幕空间。首先，可以在屏幕上打开多个窗口，然后通过跳格键快速在窗口间切换。还可在屏幕上固定窗口，或将它们泊位到屏幕任何一边，如属性窗口。当鼠标在泊位窗口滑过时，它立刻滑动到屏幕上。这就使得在导航窗口、工具条、属性检测器和编辑器间进行转换变得容易。环境是可配置的。从工具菜单中，可以为所有环境修改常规设置，并可以为每种语言设置选项。也就是说，如果你需要在vb和c#间进行转换，这种设置功能就很有用。另外除了控制visual studio.net的开启行为，你还可定制编辑器，设置字体和颜色，为工程和方案设置默认存储位置。开发环境的特性包括对调试器和造型进行了改进，出现了支持新部署模型的工具，提高了源代码控制等等。作为快速参考，附表总结了其中的主要特性。
编辑
visual studio为visual studio.net所支持的所有语言提供了一个统一的代码编辑器，而对每种语言又支持特定的特性。编辑器有了很大改进，如字提示、递增搜索、代码大纲、重叠文本、行号、分色显示和快捷键。编辑器还提供了许多特定于语言的特性，如它能在输入时完成原型和函数调用。
除了编程语言，编辑器还支持html文档、层叠样式表单，甚至xml的开发。事实上，xml文档中的关键字，如xml声明和属性，已经通过颜色高亮度显示。而且，编辑器提供了源视图和数据视图。在数据视图中，文档的结构在左侧窗口中显示出来。当在这种层次中选择一个xml元素时，窗口右部的表显示它的子元素，使你能够挖掘它的元素数据。然而，反常的是，并不是所有xml元素都能调入到数据视图中。具有不可预测结构的文档，在试图调入到数据视中时，编辑器将不知所措。
另一个令人愉快的是，visual studio .net使你能够根据文档实例创建xml大纲。默认情况下文档实例在文档源视图中打开。你可仍处于源视或转换到数据视图中，然后在视图中右击，从弹出的菜单中选择创建大纲。接着出现一个对话框，让你输入大纲文档的名称。一旦大纲创建了，对它的引用将插入到原始文档实例中。对于那些不愿从头编写xml大纲的人来说，visual studio.net使你能够跳过开头。
工程和解决方案
另一个方便的特性是解决方案。一个给定的方案涉及到多个工程。解决方案像独立的工程一样，在解决方案窗口中进行管理。因此，可以访问、创建、编辑和删除为解决方案定义的任何工程中的单个文件。
在设置独立工程时，vb、c#和c++程序员通常会发现此过程是很省力的。用vb在几分钟内可以创建一个asp.net应用程序。环境自动在本地web服务器上创建虚拟目录，增加aspx 和 global.asax文件、css样式表单、一些部件、查找文件及一个包含了工程配置信息的xml文档——web.config。你所做的只是在web浏览器中执行aspx文档以运行应用程序。
另一方面，jscript开发人员将面临困难，因为jscript没有完全与microsoft开发环境（mde）集成起来。这意味着必须手动设置虚拟目录，手工创建、管理许多文件。
语言变化
如同它所支持的平台一样，visual studio .net在编程方面也发生了大变化。由于vb与通用语言运行时的集成，vb程序员将感到巨大变化。你可能需要重新从头设计整个代码块。对于初学者来说，继承性和多态性意味着vb最终会成为真正的面向对象的程序语言。vb现在可以超越方法，重载方法调用。vb还引入了结构化异常处理，支持类似于com的接口和多线程。另外，很多语言成分被抛弃了，有一些被新属性、方法和函数所代替。
jscript也可以发现jscript发生了重大变化。由于编译语言的本质，所有jscript变量现在必须声明。还引入了数据类型。以前，jscript程序员创建没有与数据相关连的变量。然而，现在.net 应用程序特别要求为变量指定数据类型。这样做不会丢下jscript程序员，但数据类型的引入使jscript程序员遇到了以前没有遇到过的问题（如类型兼容性）。 jscript还引入了类、函数重载、对属性的获取和设置。增加的其他语言特性包括常量声明、枚举器和新的导入声明。它肯定不是上一代的脚本语言。
visual studio .net是特性非常丰富的开发环境，通用语言的支持能力使开发人员能在c++、vb和c#间自由转换。编辑器还支持xml文档、xml大纲、html和css的创建。调试器和profiler有所增强，新的工具支持部署、源代码控制和其他许多特性。当然，对可能的.net程序员还有很多重要变化。这就是为什么无法想象没有visual studio如何创建.net应用程序的原因。
十五． 结语
.net为开发者提供了更好、更有威力的环境
.net的初创，是微软向前迈出的一大步。通过提供一个开发windows应用程序的新基础，这家公司几乎是强迫开发人员开始攀登一个冗长的学习曲线。然而web services、.net framework、.net my services以及.net其他部分所带来的好处。这个崭新的开发环境更加现在，并且提供更多服务。一旦开发人员掌握了.net核心技术，他们的生产力将会大大提高；运用内建的web services支持，便可开发出全新类型的应用程序。最终，.net很可能达到终极目标：以最少的时间，开发出最好的软件。
为了获得更强大的威力，必须接受改变
但是，为了获得这些强大的威力，开发人员必须忍受的负面影响是：大幅度的变化。windows开发人员必须学习许多新语言特性（如果学习的是c#，那甚至是门全新语言）、一个（至少某部分）既大又新的标准类库，以及五花八门诸如web services等等的新概念。某些开发人员甚至会出现信心挫折，因为他们原有的很大一部分知识失去了作用。例如，除非你要和现有代码进行互动，否则com在..net framework之中派不上什么用场，因此，微软环境中的软件开发人员千辛万苦才学得的com细节知识，对于开发framework-based应用程序已经没有什么意义。随着.net framework的windows forms的引入，现有的gui技术变得价值不大。即使在数据访问方面，也有相当大的不同，因为ado已经被ado.net所取代。
然而，抱怨是没有任何意义的，对于希望在这个环境下工作的开发人员来说，唯一的选择是投入必要的时间，开始和.net进行一番搏斗，因为.net是在windows上开发应用程序的未来。
