这篇文章很多地方借鉴了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相关应用
<P class=MsoNormal style="TEXT-I