外文参考文献译文及原文

本科毕业设计（论文）

外文参考文献译文及原文

学 院_____计算机学院______

专 业___计算机科学与技术___

年级班别____2009级（1）班__

学 号

学生姓名_______ ________

指导教师______ ________

2013 年 5 月

目 录

译文：

前言 ......................................................................................................................................... 1

第一章 微软.NET平台的介绍 .............................................................................................. 3

1.1 简介 ................................................................................................................................ 3

1.1.1 .NET平台简介 ................................................................................................ 3

1.1.2 微软的.NET和WINDOWS的基因................................................................. 4

1.1.3 微软 .NET体系结构 ..................................................................................... 4

1.1.4 .NET平台的特点 ............................................................................................ 4

1.1.5 多国语言的发展 ............................................................................................. 5

1.1.6 平台和处理器独立性 .................................................................................... 6

1.1.7 自动内存管理 ................................................................................................. 7

1.1.8 支持的版本 ...................................................................................................... 7

1.1.9 支持的开放标准 ............................................................................................. 8

1.1.10 配置简单 ........................................................................................................ 8

1.1.11 分布式体系结构 ........................................................................................... 9

1.1.12 与非托管代码的互用 .................................................................................. 9

原文：

Foreword ...................................................................................................................................... 11 Chapter1 Introduction of the Microsoft .NET Platform .................................. 13

1.1 Introduction ............................................................................................................ 13

1.1.1 Introduction of the .NET Platform ................................................ 13

1.1.2 Microsoft .NET and Windows DNA ......................................................... 15

1.1.3 Microsoft .NET Architecture Hierarchy ....................................... 15

1.1.4 Features of the .NET Platform ......................................................... 16

1.1.5 Multilanguage Development .................................................................. 17

1.1.6 Platform and Processor Independence ........................................... 18

1.1.7 Automatic Memory Management ............................................................. 19

1.1.8 Versioning Support .................................................................................. 20

1.1.9 Support for Open Standards ................................................................ 21

1.1.10 Easy Deployment ...................................................................................... 22

1.1.11 Distributed Architecture .................................................................. 23

1.1.12 Interoperability with Unmanaged Code ....................................... 23

译文：

前言

在电脑软件的历史上，很少有一种技术能够得到开发者和业界如此强烈的正面响应。全球已经有数百万的开发者下载了Microsoft的.NET软件开发工具包，已经出现了很多有关.NET平台及其相关技术和语言的教材、网站和新闻团体。

Microsoft在创建.NET上已经投入了数十亿美元进行了多年的研究。.NET是一种全面的策略，它由操作系统、数据库服务器、应用程序服务器和.NET运行时库组成，还包括运行于.NET平台之上的操纵语言。

很多人把.NET平台看作先前所说的Windows DNA的实际实现，也有人把它看作是改进先前技术和语言的结果。然而，这些仅仅说明了.NET是对Microsoft以前技术的重大改进。其实.NET平台是从头开始设计的，包括许多内在目标，如安全性、可升级性、可靠性、灵活性和互操作性。为了使.NET平台适合于企业和开发者，所有这些目标从一开始就被考虑到了。

NET平台呈现了Microsoft思想的重大转变。建立.NET平台时，Microsoft表现出对开放标准极大的支持，如XML、SOAP和UDDI，而不是建立自己的标准和技术。而且.NET平台的核心部分（Common Language Infrastructure, CLI）和C#规范都已提交给ECMA，并通过了标准化。

C#来源于C和C++，是一种简单的、现代的、面向对象和类型安全的编程语言，由Microsoft的Anders Hejlsberg专门为.NET平台开发的语言，继承了许多语言的特征，如C、C++和Java。C#是为了综合Visual Basic的简单和C++作为面向对象语言的功能强大的优点而写的，对于开发者来说，C#使企业应用程序的创建、调试和配置变得很容易。有人预言，C#将成为在.NET平台上开发应用程序最受欢迎的语言。

作为Visual Studio IDE的下一个版本，Visual Studio.NET也是.NET战略的关键组成部分。Visual Studio.NET IDE也已经被整合并装入了大量的新功能。位图编辑器、调试器、Web窗体设计器、Windows窗体设计器、Web服务设计器、XML编辑器、HTML编辑器、Web浏览器、服务器资源管理器和多语言支持，所有这些都被集成在IDE中。 C#.NET Web开发指导的重点不是教你C#语言的核心内容，而是提供代码实例来帮

助你使用.NET框架类库的功能。基础类库的.NET框架集合覆盖了大量API。尽管不可能在一本书中包含所有的特征，但是本书中包含了其中的关键思想、类库和.NET框架的API，希望本书能够帮助你容易地使用C#创建新的应用程序。

既然有这么多特征要学习和掌握，那就不要再等待了，咱们现在就开始吧！

第一章 微软.NET平台的介绍

1.1简介

Microsoft在创建.NET上已经投入了数十亿美元并进行了多年的研究，并且将极大可能考虑把它作为新兴的标准。许多微软的伙伴也宣布支持NET工具和部件——你可以浏览http://msdn.microsoft.com/vstudio/partners上的供应商表来查看。

.NET平台能提供强大的新服务，新的独立于处理器的二进制格式，新的管理语言，现有的语言扩展的管理语言，这样的例子不胜枚举。没有良好的操作背景是不可能有效地使用这些新工具的来运行你的应用程序。在这一章中，我们来看一看.NET平台的各个组成部分。我们不仅介绍他们的技术和概念，而且还要用专业术语去解释它们。这将使你对.NET平台的内部工作有一个深入的了解，并在接下来的章节中能有更多的收获。

1.1.1 .NET平台简介

.NET平台的所处的背景是:世界正在从个人电脑连接到一个服务器(比如互联网)中改变到一个地方的所有职能设备、电脑和服务协同工作中能为用户提供更丰富的体验。.NET平台是微软为软件开发人员给这种改变提供的解答。.NET平台到底有几个组成部分，每个人都会给你不同的答案。比如微软的商务对话和结构化查询语言以及.NET中的我的服务，它们中的第一个可见组件.NET通行证通常被视为.NET平台的有机组成部分。然而，对很多人来说，.NET框架是当.NET被提到时我们想象中的样子。它包括VS.NET，.NET公共语言库（CLR）和.NET基类库（BCL）。其他组件可能会要求特定的应用，但它们不是所有.NET应用程序的必要组成部分。

下面来看.NET的整体结构，它由这几个个主要部分组成： ■ .NET框架 一个全新的应用开发平台。 ■几个.NET产品 多重基于.NET框架的应用，包括新版本的并由可扩展标记语言（XML）在.NET平台上的集成交互和结构化查询语言（SQL）服务器。

■几种.NET服务 它是由微软为在.NET框架开发应用程序使用的。微软的Hailstorm实际上是一个囊括了微软品牌的最重要网站某些服务的计划。

■公共语言库 托管执行环境，处理内存分配，捕获错误，并与作业系统服务进行交

互。

■基类库 对组件的编程和应用程序接口（API）的广泛的收集。 ■两个最高发展目标 一个用于Web应用程序 （ASP.NET），另外一个用于普通的Windows应用程序（Windows 表格） 。

由.NET框架提供的好处包括：缩短开发周期（减少代码重用，减少编程意外，多种编程语言的支持），更简单的配置，由于整体式安全性而导致更少的数据类型相关的错误，由于垃圾回收器的存在而引起内存泄漏的减少，而且，具有一般的更具可扩展性、可靠性的应用程序。

1.1.2微软的.NET和WINDOWS的基因

.NET周围中的一些营销宣言听起来很熟悉：.NET平台被称为WINDOWS基因的下一代。不过，虽然视窗系统的基因确实提供了健壮的，可扩展的，分布式系统的基石，但是对一些人来说其本身并没有什么实质性。

Windows DNA的是一种技术规范，重点是对微软服务器产品的基础建设，利用多种技术和语言（ASP，HTML，JavaScript，MTS，COM等等），其中有相当多是与开发无关的。这些服务器和语言包括不同的API和系统，使互操作性达到最好。.NET与其有很大的不同：它不只是一个规范。在它的好的产品中，它包括语言所需要的工具和发展，使n层应用这些类型更容易，整齐地作为一个单一的连贯和全面的API封装。

1.1.3 微软 .NET体系结构

从本质上讲，根据公共语言规范，.NET语言编译的种类和微软中间语言（MSIL，或者只是IL）的输出是不同的。应用程序开发的主要类型是Web窗体，Web服务和Windows窗体应用程序。这些应用程序使用XML和简单对象访问协议（SOAP）进行通信，从而使得他们能在基类库中继承并能在公共语言中运行。 Visual Studio.NET不仅是为了发展需要.NET Framework应用程序，而且它还提供了可扩展的架构，从而使之成为发展.NET软件的理想选择。

1.1.4 .NET平台的特点

.NET平台的核心是在公共语言库，基类库，和公共语言规范中发现的。 .NET的基

类库用相同的方法揭露了公共语言库的功能，这样，Windows API允许你利用的Windows作业系统的特点的共同语言运行库的功能。而且，它也提供了许多更高级别的功能，促进代码重用。

这种架构提供了许多好处，至少一个很大的数目一致的API。通过书面形式向公共语言运行库和使用.NET基础类库，所有的应用服务是通过一个共同的面向对象编程模型提供。今天，一些操作系统的功能是通过调用DLL的访问使用基于C的API和其他设施，通过访问COM对象，从而使开发人员的工作更加简捷，使一切顺利。某些功能只提供给开发人员在低层次的语言工作，从而迫使他们设计决策。

这种新的编程模型大大简化了那些需要编写Windows DNA应用程序的工作或为了完成应用程序的几乎所有Win32和COM项目的工作难度。开发人员不再需要有一个对GUIDS、调用、释放、HRESULTS等等有着深入了解的Windows或COM的大师。.NET也不是隐藏在开发这些之中，在新的网络平台上，这些概念根本不存在的。

另一个为.NET开发人员带来极大的好处是其错误异常处理模型。为Windows开发平台软件始终意味着你会出现错误的地方，特别是在错误的方式会返回值。有些函数会返回错误的Win32代码，一些返回HRESULTS，还有的则比较例外，所有要求程序员编写错误处理代码的不同类型。 .NET中，所有的错误报告都会通过这个模型，从而大大简化了书写，阅读和维护代码。由于公共语言规范和通用类型系统，.NET也可以在跨模块和跨语言的界限工作

1.1.5 多国语言的发展

由于许多语言对.NET公共语言运行库有规范，现在更容易语言应用部分适应你的操作。以前，不同的编程语言互操作是允许的，如COM或CORBA，这样做是通过一个接口定义语言（IDL）的来实现的。.NET平台的语言，通过MSIL对彼此的使用加以整合。虽然它包含指示类似的汇编代码和移入和移出寄存器变量，它也包含了管理对象和调用它们的方法，操纵阵列，提高和捕获异常的说明。

Microsoft公共语言规范描述了其他开发工具，作者必须为他们的编译器输出IL代码，使它们能很好的融入.NET语言。微软目前针对.NET公共语言运行库的几个编译器提供了IL代码：C + +的托管扩展的C＃，JAVAScript和Visual Basic中。此外，微软和其他几家公司正在生产用于语言的编译器。这些编译器也针对.NET公共语言运行

库。目前支持为COBOL，Eiffel，Fortran语言，Perl，Python和Scheme。供应商还公布了其他不同的许多语言。这是一个当前供应商的列表：

http://msdn.microsoft.com/vstudio/partners/language/default.asp。

为什么你应该关心的IL详情？因为它为.NET管理着跨语言功能。由于IL整个翻译的开销的复杂性，无接口定义语言需要启用跨语言的元数据来处理。举例来说，一个对IL的定义，同样的对象可以不管是不是能捕获.NET语言。您的组件在C＃可以书面提出一个可以由Fortran采用资讯科技应用捕获的异常。而且关于不同的调用约定或数据类型，不必再担心无缝互操作性。

跨语言继承的另一个特点是可以使用IL。现在您可以创建源代码，而且无需再为新类中的基本成分编写其他的语言。例如，您可以创建一个C++的类，从Visual Basic中实现了一个派生类。.NET可以实现这一点，因为它定义和类型系统都提供了一个共同的.NET语言。

对应用开发的规范下，Windows DNA的巨大挑战之一是各种语言开发的应用程序时的调试。由于统一的Visual Studio.NET开发环境和IL都使用了.NET语言作为输出，跨语言调试就不会排斥汇编语言。 .NET公共语言运行库调试应用程序，完全支持跨语言的界限。运行库还提供了内置的堆叠设施，使其更容易找到漏洞和错误。

1.1.6 平台和处理器独立性

中间语言是与CPU无关的，它远高于大多数机器语言水平。.NET应用程序可以在任何平台上支持写、新建以及托管，这样就可以支持.NET公共语言运行库。由于.NET通用类型系统定义不论基本数据类型大小都可以使用.NET应用程序，而且这些应用程序可以在公共语言的环境中运行，所以任何硬件或操作系统都支持.NET平台。

虽然在写这篇文章的时候，.NET应用程序只能运行在Windows平台。但2001年6月27日，微软宣布，它已经与Corel达成协议，共同开发一个C＃编译器和.NET 框架基础结构组件，它们将共享源代码并执行FreeBSD版本的UNIX。这个测试版本目前预计将在2002年上半年的某个时候发布。

几个星期后，也就是在二零零一年七月十日微软给出了积极的信号。一个深蓝设计的.NET，这是一个为Linux用户界面设计的流行的Gnome计划的开源版本。你可以在www.go-mono.net找到该项目，称为MONO。该小组正在开发一个C＃语言的编译器，以

及.NET公共语言运行库，而且关于基类库的工作也开始了。在2001年年底该项目的发布了它的第一个可用单代码计划。

1.1.7 自动内存管理

提到内存泄漏问题，可能一个开发环境中并没有提供自动内存来管理开发，从而导致调试无数个小时。对那些想在这个工作中花费一些时间来降低棘手的代码的人来说，绕过资源管理应该是一种不错的方法。

从Visual Basic开发人员或有COM背景与未来技术的相关的人员的角度来说，这项技术在只有一个对象而且没有其他物体对其引用的时候会恢复内存，而且基本上它不再需要使用内存。虽然这在理论上听起来完善，但在实践中却有几个问题。最常见的是循环引用问题，即一个对象到另一个对象，它本身包含一个回到第一个对象的引用。当内存管理的对象不使用它们看起来时候的摸样时，这些对象将始终大于零。因此，除非它们是隐式解构，不然他们的内存可能永远不会被发现。

C或C++程序员的习惯是自己销毁对象，因为他们能管理其自有的内存。他们不信任任何人能利用管理资源并将之照顾好。然而，在.NET环境下，微软正在努力使软件开发更加容易。在本章后面的内容，我们涉及.NET如何进行已经经过严格的引用计数或手动内存管理方法改进的垃圾收集工作。

1.1.8 支持的版本

谁如果不理解 “DLL HELL”，那就是他尚未开发Windows（或至少支持）软件很长时间。对于外行，当客户使用您的应用程序相同的DLL之一安装了一个软件包时，你会发现自己就身在DLL HELL之中。但是，所有开发人员总是把每件事情都向后100％兼容，就像您的应用程序使用此DLL的版本1.0，新的1.1软件版本能兼容1.0版本的，对不对？当新的DLL使您的应用程序表现出一些奇怪的问题或者完全停止工作的时候，你要经过大量调查找出有问题的DLL是什么，并用新的版本替换您的软件版本。但是，如果现在他们的新软件不工作了，那么就是DLL HELL发挥作用了。当应用程序加载库时，许多开发人员仅需要采取安装每个DLL的应用程序需要的目录的方法。这虽然违背了共享库的目的，但它是一个解决问题的方法。

COM以前是这样的：你以前从来没有改变一个方法接口，你只是添加新的方法。不

幸的是，软件开发人员经常是玩弄主义者，留下一些“漏洞”的功能玩弄一些人。问题是，一旦在使用时产生了不良的客户端软件，那么改变一个组件的接口会被以前的所谓添加新的方法的行为影响。不过它也有解决方法，由于COM对象是被加载在注册表中的信息，所以只需替代该DLL或应用程序目录，那么这个问题便不会发生。

现在，.NET架构将应用程序组件分开，这样应用程序就能总是加载与它建立和测试相关的元件。如果应用程序安装运行后，应用程序应该始终运行。这是通过程序集和.NET的封装组件实现的。虽然目前的DLL和COM的对象包含了许多不同的版本信息，但是操作系统不会真正使用任何这些信息。程序集包含了.NET公共语言运行时使用的版本信息，以确保应用程序在加载它时建立使用组件。我们将在后面的章节涵盖了更多关于配件和版本如何工作的内容。

1.1.9 支持的开放标准

在今天的世界上，不是每个你可能工作的设备都是运行微软操作系统或使用英特尔处理器。为了实现开放的标准，.NET的建构是基于XML和SOAP的，它将使你可以通过Internet激活应用程序，而不论其背后依托标准的信息基础是什么设施。 SOAP将为不同的系统提供容易的交换信息的方法，而且更好的是，SOAP允许您调用远程系统的方法和返回结果。因为SOAP是一个类似于HTTP的简单的基于文本的协议，它可以轻易地穿过防火墙，不像DCOM或CORBA。

由.NET平台提供的其他标准包括通用描述，发现和集成（UDDI）以及它们的XML接口和Web服务描述语言（WSDL），它描述了一个应用程序代码做目录。通过许多基于开放标准.NET的基础并向ECMA（一个国际标准组织）提交对C＃和.NET公共语言基础结构的标准草案，微软希望籍由软件的未来版本看到其超出自己的领域。

1.1.10 配置简单

今天，基于Windows的应用程序的开发和安装达到了令人难以置信的困难。由于这一点，大多数公司对于用于开发他们的安装程序的第三方工具很不满意。通常需要在几个目录中安装大量的文件，设置各种注册表，安装所需的COM组件和建立快捷方式等等。完全卸载的应用程序几乎是不可能的，即使他们提供卸载功能，大多数仍会遗留很多字节以及碎片。随着Windows2000的发布，微软引入了一个新的安装引擎帮助解决这些问

题，但它仍然有可能是一个不正常的微软安装程序包。即使专门设计一种第三方软件，使得更容易开发一些工具，但要正确地在检索中安装一个应用仍然是一项艰巨的任务。 .NET设计队伍面对这个问题同样感到了的困惑，但.NET队伍计划将这些问题解决了。.NET组件中不引用注册表，由于元数据和引用的使用，组件描述是自发的。事实上，安装大部分.NET应用程序仅仅需要将他们的文件复制到一个目录，卸载应用程序将只是删除这些文件。

1.1.11 分布式体系结构

今天的分布式应用程序与未来的那些仍然有很大的不同。微软坚定地认为：他们十分看好分布式Web服务概念的公司。例如，现在，当用户与门户网站互动时，在他们看来是与一个远程服务器打交道。我们大多数人都知道，通常情况并非如此，至少在那些大规模的网站上不是这样的。其实是各种服务器和应用程序在后台运行，当访问几个远程站点的信息时，服务器结合自己的用户信息数据库，合并成一个集成产品，用户则浏览传递到浏览器上的信息。

由于这些类型的应用很有用，他们的开发和维护都非常的复杂。每条信息提供商已经开发不同的接口来访问他们的服务器上的数据和流程。这是非常低效的重复建设，并在大多数情况相当乏味，所以在许多活动已经形成了三个标准以简化流程：XML，SOAP和UDDI。正如我们前面讨论的，这些都是用来在.NET并都在竞争。但是，少为人知的是，这些都是IBM和Sun的倡议。

1.1.12 与非托管代码的互用

正如你可能已经猜到了，与非托管代码是不被.NET公共语言运行库管理的代码。但是，此代码仍然是由CLR运行时，它只是没有得到诸如通用类型系统和自动内存管理优势。您最终可能会在不同的情况使用不同的代码

■调用DLL函数 现在有许多函数都绑定了DLL。并不是每一个公司都要急于推出的.NET产品组件的版本，所以如果你需要接触他们，你会调用与非托管代码。

■使用COM组件 这应该是你调用DLL函数的相同原因。 ■从COM组件中调用.NET服务 虽然这听起来有点古怪，但它是可能的。一个COM客户端可以调用.NET组件，就好像这是一个COM服务器一样。

这里有一点关于COM互用问题的更多信息。微软并没有想迫使公司放弃现有的COM组件，特别是因为现在微软自己的产品很多是基于COM的.COM组件中的消息，这些消息是在.NET运行的时候，它的互操作层通过非法侵占来处理所有管理运行和COM组件系统之间翻译时传递的，就像与非托管代码一样。

在这其中的另一面，有公司出于对.COM技术的既得利益考虑，可能想使用.NET平台的一些零零碎碎的功能之后，然后才会采取坚持.COM客户端可以方便地通过COM 非法侵占层与.NET组件联系。

原文：

Foreword

Seldom in the history of computer software has any technology received such a positive response from developers and the industry, even while the technology is still in its nascent beta stage. The .NET Beta2 SDK from Microsoft has already been downloaded by millions of developers all over the world. Dozens of published books, Web sites and newsgroups devoted to the .NET platform, and relevant technical know-how.

Microsoft has invested billions of dollars and years of research in the creation of .NET. .NET is a comprehensive strategy, consisting of operating systems, database servers, application servers, and the .NET Runtime, as well as managed languages that operate over the .NET platform.

Some people think of the .NET platform as the practical implementation of the previously formulated Windows DNA. Others consider it as a response to developers’ ticklers of working with previous technologies and languages. Nevertheless, the common misunderstanding still exists, simply assuming that .NET is the mere improvement over previous Microsoft technologies. In fact, the .NET platform has started from scratch, with such goals as security, scalability, reliability, flexibility, and interoperability, thereby making the .NET accessible to platform enterprise.

The .NET platform displays a significant shift of Microsoft’s thinking. While building the .NET platform, Microsoft has shown strong support for open standards like XML, SOAP, and UDDI, rather than building its own proprietary standards and technologies. Even the core part of the .NET platform—the Common Language Infrastructure (CLI)—and the C# specifications have been placed before ECMA for standardization.

C#, developed by Anders Hejlsberg of Microsoft, is defined as a simple, modern, object-oriented, and type-safe programming language derived from C and C++, deriving from a number of languages like C, C++, and Java. Specifically written to offer the simplicity of Visual Basic and power of C++ as an object-oriented language, C# makes it easier for

developers to create, debug, and deploy enterprise applications. It has also been predicted that C# will become the favored language for developing applications on the .NET platform.

Visual Studio.NET, the next version of Visual Studio IDE, is also a key component of the .NET strategy. The Visual Studio.NET IDE has also been given a facelift and packed with a wide variety of new functionalities. A bitmap editor, debugger, Web Forms designer, Windows Forms designer, Web Services designer, XML editor, HTML editor, Web browser, Server Resources Explorer, and multi-language support have all been packed into one single IDE.

The focus of The C#.NET Web Developer’s Guide is not on teaching you the core C# language, but rather providing you with code examples that will help you leverage the functionalities of the .NET Framework Class Libraries. The .NET Framework collections of base classes cover many of the multiple APIs. Although impossible for one book to cover all the features, we have covered, in this book, the key concepts, libraries, and APIs of the .NET Framework, which can help create new applications using C#.

You have so many features to learn and master that we must get started now!!

Chapter1 Introduction of the Microsoft .NET Platform

1.1 Introduction

The .NET platform is the foundation upon which the next generation of software will be built. Microsoft has invested a lot of capital in its development and attempted to make it as the new standard. A list of Microsoft partners has also supported .NET tools and components. You can check http://msdn.microsoft.com/vstudio/partners for a current list of vendors who have .NET offerings.

The .NET platform is anything more than a mere new language, software development kit (SDK), or even an operating system. It offers powerful new services, a new processor-independent binary format, new managed languages, managed language extensions to existing languages, and so forth. Effectively using these new tools makes possible a firm background of the platform that will enhance your applications.

In this chapter, we take a look at the various components of the .NET platform. We not only introduce the concept and technology, but explain the terminology used to describe them as well. This will enable you to have a strong understanding of the internal workings of the .NET platform, thus reaping more benefits from the following chapters.

1.1.1 Introduction of the .NET Platform

The precept behind the .NET platform is the shift from one of PCs connected to servers through networks such as the Internet, to one where all manner of smart devices, computers, and services work together to provide a richer user experience. The .NET platform is Microsoft’s answer to the challenges this change will provide to software developers.

How many components the .NET platform have? Different people have different answers.

Servers such as BizTalk and SQL Server, as well as services such as .NET My Services and its first visible component, .NET Passport, are being described by some as integral parts of the .NET platform. Nonetheless, the .NET Framework, as far as many of us are concerned, can be anything that we can imagine when referring to .NET. It comprises Visual Studio.NET (VS.NET), the .NET Common Language Runtime (CLR), and the .NET Base Class Libraries (BCL). The other components may be required by specific applications, but they are not the necessary part of all .NET applications.

Looking at the overall architecture, .NET consists of three primary components:

■ The .NET Framework A completely new application development platform.

■ Several .NET products Various applications from Microsoft based on the .NET Framework, including new versions of Exchange and SQL Server, which are Extensible Markup Language (XML)–enabled and integrated into the .NET platform.

■ Several .NET services Provided by Microsoft for developing applications running under the .NET Framework. Microsoft’s Hailstorm project actually attempts to package some of the most crucial Web Services under the Microsoft brand name.

The .NET Framework itself can be divided into three parts:

■ The CLR A managed execution environment that handles memory allocation, error trapping, and interacting with the operating-system services.

■ The Base Class Library An extensive collection of programming components and application program interfaces (APIs).

■ Two top-level development targets One for Web applications (ASP.NET) and the other for regular Windows applications (Windows Forms)

The advantages offered by the .NET Framework include shorter development cycles (code reuse, fewer programming surprises, support for multiple programming languages), easier deployment, fewer data type-related bugs due to integral type safety, reduced memory leaks attributed to the garbage collector, and, in general more scalable, reliable applications.

1.1.2 Microsoft .NET and Windows DNA

If the propagation regarding .NET sounds familiar, there’s a good reason: The .NET platform is the next generation of Windows DNA. However, although Windows DNA offer some of the building blocks for creating robust, scalable, distributed systems, it generally had little substance in and of itself.

Windows DNA was a technical specification that focused on building software based on Microsoft server products, utilizing numerous technologies and languages (ASP, HTML, JavaScript, MTS, COM, and so on), many of which are quite unrelated from a developer’s point of view. The servers and languages involved all have varying APIs and type systems, making interoperability a challenge at best. Herein lies the big difference: .NET is much more than a specification. A product in its own right, it includes the tools and languages required to make developing these types of n-tiered applications easier, neatly packaged as a single coherent and comprehensive API.

1.1.3 Microsoft .NET Architecture Hierarchy

The compile of .NET families of languages are, in essence, different from the output of Microsoft Intermediate Language (MSIL, or just IL) rested on the Common Language Specification. The primary types of application development are Web Forms, Web Services, and Windows Forms applications. These applications communicate by way of using XML and Simple Object Access Protocol (SOAP), getting their functionality from the Base Class Library and running within the Common Language Runtime environment. Visual Studio .NET is not required in order to develop .NET Framework applications; but it does offer an extensible architecture that makes it an ideal choice for developing .NET software.

1.1.4 Features of the .NET Platform

The core of the .NET platform is founded on the Common Language Runtime, Base Class Library, and the Common Language Specification. The .NET Base Class Library exposes the features of the Common Language Runtime in much the same way that the Windows API allows you to utilize the features of the Windows operating system; however, it also provides many higher-level features that facilitate code reuse.

This architecture gives a great number of benefits, not the mere consistent API. By virtue of writing to the Common Language Runtime and using the .NET Base Class library, all application services are available in a common object-oriented programming model. Today some OS functions are accessed via DLL calls using the C-based API as well as other facilities are accessed via COM objects, making the developer do the necessary legwork to make everything work together smoothly. Some features are available only to developers working in low-level languages, forcing to design decisions.

This new programming model greatly simplifies the efforts that were required when writing Windows DNA applications, or for that matter, almost any Win32 and COM project. Developers need not to be a Windows or COM architecture guru with an in-depth understanding of GUIDs, I Unknown, AddRef, Release, HRESULTS, and so on. .NET doesn’t just hide these from the developer; in the new .NET platform, these concepts do not exist at all.

Another great benefit for .NET developers is its model for error handling via exceptions. Developing software for the Windows platform has always meant you were pulled into its own inconsistencies: particularly in the ways errors were returned. Some functions would return Win32 error codes, some return HRESULTS, and some raise exceptions, requiring the programmer to write different types of error-handling code. In .NET, all errors are reported in

the form of exceptions, therefore greatly simplifying writing, reading, and maintaining code. Due to the Common Language Specification and Common Type System, .NET exceptions transcend module and language boundaries as well.

1.1.5 Multilanguage Development

Because many languages target the .NET Common Language Runtime, it is now much easier to implement portions of your application using the language that’s best suited for it. Erstwhile methods, allowing such programming languages as COM or CORBA to interoperate, did so through the use of an Interface Definition Language (IDL). The .NET platform allows languages to be integrated with one another through the use of the MSIL. Although it contains instructions that appear similar to assembly code, such as pushing and popping values and moving variables in and out of registers, it also contains instructions for managing objects and invoking their methods, manipulating arrays, and raising and catching exceptions.

The Microsoft Common Language Specification describes what other development tool authors must do in order for their compilers to output IL code that will allow them to integrate well with other .NET languages. Microsoft currently provides several compilers that produce IL code targeting the .NET Common Language Runtime: C++ with managed extensions, C#, Jscript, and Visual Basic. In addition, several companies other than Microsoft are producing compilers for languages that also target the .NET Common Language Runtime. Currently having already supported for COBOL, Eiffel, Fortran, Perl, Python, Scheme, and many more have been announced by various vendors. For a current list check:

http://msdn.microsoft.com/vstudio/partners/language/default.asp.

Why should you care about the details of IL? Because this is how .NET manages many of its cross-language features. No Interface Definition Language is required to enable

cross-language functionality because IL metadata handles the entire translation overhead. For instance, with an exception object defined by IL, the same object can be caught regardless of the .NET language used. Your component written in C# can raise an exception that can be caught by the Fortran application using it. No more worries about different calling conventions or data types, just seamless interoperability.

Cross-language inheritance is another feature made possible by the use of IL. You can now create new classes based on components written in other languages, without needing the source code to the base component. For example, you can create a class in C++ that derives from a class implemented in Visual Basic. .NET can realize this because it defines and provides a type system common to all .NET languages.

One of the great challenges of developing applications under the Windows DNA specification was in debugging applications developed in a variety of languages. Because of both the unified development environment of Visual Studio.NET and the use of IL as the output of all .NET languages, cross-language debugging is possible without resorting to assembly language. The .NET Common Language Runtime fully supports debugging applications that cross language boundaries. The runtime also provides built-in stack-walking facilities, making it much easier to locate bugs and errors.

1.1.6 Platform and Processor Independence

The intermediate language is CPU-independent, and there is much higher level than most machine languages. Once being written and built, a managed .NET application can execute on any platform that supports the .NET Common Language Runtime. Because the .NET Common Type System defines the size of the base data types that are available to .NET applications, and applications run within the Common Language Runtime environment, the application developer is insulated from the specifics of any hardware or operating system that

supports the .NET platform.

Although at the time of this writing .NET applications run only on Windows platforms, Microsoft announced that it had reached an agreement with Corel to develop a shared-source implementation of a C# compiler and the .NET Framework infrastructure components for the FreeBSD version of UNIX on June 27th, 2001. This is currently expected to be available in a beta version sometime in the first half of 2002.

A few weeks later, on July 10, 2001 Microsoft gave the go-ahead to an open-source version of .NET being planned by Ximian, the developer the popular GNOME user interface for Linux. You can find the project, called Mono, at . The group is developing a C# language compiler, along with the .NET Common Language Runtime .Work has also begun on the Base Class Library. The release of the first usable Project Mono code is planned for the end of 2001.

1.1.7 Automatic Memory Management

The mere mention of a memory leak problem brings forth images of endless hours of debugging for developers who have come from a development environment that did not offer automatic memory management. Even for those fortunate enough to work with this in some form have likely spent some time trying to hunt down obscure bugs caused by tricky code that circumvented the resource management methodology.

Developers, specializing in Visual Basic or COM, are familiar with the reference counting technique. This technique recovers the memory used by an object when no other object has a reference to it, essentially when it is not needed any more. Although this is, to some extent, theoretically perfect, it has a few problems in practice. The most common matter is the circular reference for one object contains a reference to another object which itself

contains a reference back to the first object. When the memory manager looks for objects that are not in use, these objects will always have a reference count greater than zero, so unless they are implicitly deconstructed, their memory may never be recovered.

For a C or C++ programmer-accustomed to ensuring that objects are properly destroyed, essentially managing memory on their own-this sounds perfectly normal, and a good reason for not trusting anyone else to take care of managing resources. However, in the .NET environment, Microsoft is striving to make developing software easier. Later in this chapter, we cover a how .NET garbage collection works, and the improvements that have been made over strict reference counting or manual memory management approaches.

1.1.8 Versioning Support

Anyone who doesn’t understand the phrase ―DLL Hell‖ has not been developing (or at least supporting) software for Windows very long. For the uninitiated, you’ll find yourself in DLL Hell someday when a customer installs a software package that uses one of the same DLLs as your application. However, your application used version 1.0 of this DLL, and the new software replaces it with version 1.1.We developers all always make sure everything is 100% backwards-compatible, right? The new DLL makes your application exhibit some strange problem or perhaps just stop working altogether. After a lot of investigation, you figure out what the offending DLL is and have the customer replace the new one with the version that works with your software. Now their new software doesn’t work- welcome to DLL Hell. Many developers resort to simply installing every DLL their application requires in the application directory so that it will be found first when the application loads the libraries. This defeats the purpose of shared libraries, but it is one way around the problem.

COM was going to change this: one of its primary tenants was that you never changed the method interface you simply add new methods. Unfortunately, software developers are

frequently perfectionists, and leaving a ―broken‖ function alone just chafes some people. Problem is that changing a components interface once it’s in use can have adverse affects on the client software that expected the old behavior. Because COM objects are loaded using information in the Registry, simply placing the DLL or controlling in the application directory doesn’t work for this problem.

The .NET architecture now separates application components so that an application always loads the components with which it was built and tested. If the application runs after installation, then the application should always run. This is done with assemblies, which are .NET-packaged components. Although current DLLs and COM objects do contain version information, the OS does not use this information for any real purpose. Assemblies contain version information that the .NET Common Language Runtime uses to ensure that an application will load the components it was built with. We cover more of the specifics of how assemblies and versioning works later in the chapter.

1.1.9 Support for Open Standards

Currently, not every device you may want to work with is going to be running a Microsoft OS or using an Intel CPU. As for this point, the architects of .NET are relying on XML and its most visible descendant, SOAP, an emerging standard for sending messages across the Internet that activates programs or applications regardless of their underlying infrastructure. SOAP will provide the means for disparate systems to exchange information easily, but even more, SOAP allows you to invoke methods on remote systems and return the results immediately. Because SOAP is a simple text-based protocol similar to HTTP, it can easily pass through fire-walls, unlike DCOM or CORBA objects.

Other standards employed by the .NET platform include Universal Description, Discovery, and Integration (UDDI), a directory of companies and their XML interfaces and

the Web Services Description Language (WSDL), which describes what a piece of application code can do. By basing much of .NET on open standards and by submitting the proposed draft standards for C# and the .NET Common Language Infrastructure to ECMA, an international standards organization, Microsoft hopes to see its version of the future of software adopted beyond its own domain.

1.1.10 Easy Deployment

To date, developing installations for Windows-based applications can be incredibly difficult, to the point that most companies use third party tools for developing their installation programs, and even then it’s not pleasant. There are usually a large number of files to be installed in several directories, various Registry settings, installation of required COM components, and shortcuts that need to be created, and so on. Completely uninstalling an application is nearly impossible, most leave bits and pieces of themselves around even if they provide an uninstall feature. With the release of Windows 2000, Microsoft introduced a new installation engine that helps with some of these issues, but it is still possible that the author of a Microsoft Installer Package may fail to address every problems. Even with those third party tools specifically designed to make developing installation programs easier, it is still frequently a monumental task to correctly install a retrieval application.

The .NET design team might have recognized this problem, because .NET plans to do away with these issues for good. .NET components are not referenced in the Registry, thanks to the use of metadata and reflection, components are self describing. In fact, installing many .NET applications will require no more than copying their files to a directory, and uninstalling an application will be as easy as deleting those files.

1.1.11 Distributed Architecture

Today’s distributed applications are much different from those we would see in the future. Microsoft certainly believes that they are betting the company on the concept of distributed Web services. For example, when interacting with a portal site, it appears to seem that they are working with a remote server. Most know that it is normally not the case, at least for a site of any significant size. There are various servers and applications behind the scenes as well as accessing information on several remote sites, combining it with information from their user database and merging all into an integrated product delivered to the user via their browser.

As useful as these types of applications are, they are all very complex to develop and maintain. Each provider of information has developed different interfaces to access data and processes on their servers. This redundant development is grossly inefficient and for the most part fairly boring, so there has been a great deal of activity around three standards to streamline the process: XML, SOAP, and UDDI. As we discussed earlier, these are utilized in .NET and also in competing, less well known initiatives from IBM and Sun.

1.1.12 Interoperability with Unmanaged Code

As you can probably guess, unmanaged code is the code that is not managed by the .NET Common Language Runtime. However, this code can still run by the CLR, it just doesn’t get the advantages that it offers, such as the Common Type System and Automatic Memory Management. You will probably end up using unman-aged code in a couple of different situations:

■ Calling DLL functions There is a lot of functionality locked inside DLLs today. Not every company is going to rush to deliver a .NET component version of their products, so if you need to interface with them, you’ll be calling unmanaged code.

■ Using COM components This is likely to be for pretty much the same reasons you might be required to call DLL functions.

■ Calling .NET services from COM components Although this seems to be a little odd, it is possible. A COM client can be made to call a .NET component as though it was a COM server.

Here is little more information on the COM interoperability. Microsoft did not want to force companies to abandon their existing COM components largely because many of Microsoft’s own products are COM-based today. COM components interoperate with the .NET runtime through an interlope layer that handles all the work required when translating messages that pass back and forth between the managed runtime and the COM components operating as unmanaged code.

On the other hand, companies with a vested interest in COM technology might want to use a few bits and pieces from the .NET platform, sticking a toe in before taking the plunge. COM clients can easily interface with .NET components through the COM interlope layer.

REFERENCES:

Adrian Turtschi，DotThatCom.com，Jason Werry，Greg Hack，Joseph Albahari，Saurabh Nandu Technical Editor，Wei Meng Lee Series Editor