类库主要的好处是它们将核心 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 来执行的图解概貌，请参看“执行可控制代码”示意图。）
** 6.NET ** ** 开发平台与 ** ** J2EE ** ** 的比较 ** ** **
作为彼此竞争的应用程序平台，微软 的 .NET 开发平台和 Sun 的 Java 2 Enterprise Edition （ J2EE ）（ Java 2 企业版）在意图和体系上极其相似，但在底层实现上却完全不同。
** 类似的目标 : **
.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 ）。
** 7. .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 <SPAN style="FONT-FAMILY: 宋体; mso-ascii-font-family: 'T