基于COM组件的网站建设论文.doc

江苏大学学士学位论文

摘要

本文从ASP技术与COM组件技术出发，详细论述了如何进行组件线程类型选择、接口设计、物理定位开发与实现，以及如何在ASP应用中创建和执行具有特定功能的COM组件，以实现其调用功能，使得应用程序更易于定制，更为灵活。同时本文还论述了在设计与实现COM组件调用的过程中，其安全性与作用域的选择。最后本文介绍了如何在MCU远程控制中用ASP调用COM组件，实现能被远程客户访问的应用。

关键词：ASP，COM组件，MCU

Abstract

This paper will set out from ASP technology and COM package technology , expound the fact in detail how to choose the package thread type , interface design , physics make a reservation and develop and realize, how to establish and carry out in ASP is used and package of COM with specific function, in order to realize transfering the function of COM package , make the application program easier to customize, more flexible. Having also described it during the process of design and realize COM package to transfering at the same time, the choices of its security and function land. How this text has been introduced to transfer COM package long-rangly with ASP while controlling in MCU finally, realize the application that can be visited by the long-range visitors.

Keywords：ASP， COM， MCU

目 录
第1章 绪论 1
第2章 基础知识介绍 3
2.1 ASP介绍 3
2.1.1 ASP的由来 3
2.1.2 ASP与HTML的区别 3
2.1.3 如何运行ASP 3
2.1.4 ASP的对象 3
2.2 COM组件介绍 4
2.2.1 COM组件的概念及其特点 4
2.2.2 组件的规划原则 6
2.3 COM组件与ASP之间关系 6
第3章 ASP调用COM组件 8
3.1 安装注册COM组件 8
3.2 理解组件的相关性 9
3.2.1 检查源代码 10
3.2.2 Dumpbin工具 10
3.2.3 Depends工具 11
3.3 绑定支持 12
3.3.1 后期绑定和前期绑定 12
3.3.2 IDispatch 12
3.4 COM组件的安全性 13
3.4.1 In-Process组件 14
3.4.2 Out-Process组件 14
3.5 激活程序 16
3.5.1 类型转换 16
3.5.2 易变性 18
3.6 保存COM对象 18
3.6.1 页面范围 18
3.6.2 会话范围 19
3.6.3 应用程序范围 19
3.7 COM组件的设计与实现 20
3.7.1 COM组件的基本设计思路 20
3.7.2 接口设计 20
3.7.3 组件定位 20
3.7.4 建立组件 21
3.7.5 组件测试 21
3.8 MCU远程控制ASP中COM组件的调用 21
3.8.1 Server对象 21
3.8.2 Server对象调用COM组件 21
第4章 系统实现过程 23
第5章 结论 27
附录 28
参考文献 38
致谢 39

不要删除行尾的分节符，此行不会被打印
- IV -
千万不要删除行尾的分节符，此行不会被打印。在目录上点右键“更新域”，然后“更新整个目录”。打印前，不要忘记把上面“Abstract”这一行后加一空行
- V -
第1章 绪论
目前，在开发功能强大、性能优良的网络应用过程中，应用系统的体系结构成为其设计的关键环节。它决定了应用系统的各个部分如何进行交互，同时也决定了每个部分实现的功能。分布式体系利用多台机器的资源及多进程空间，把应用程序分成更易管理的任务组，这些任务组能在各种不同的结构下进行部署。而ASP技术使得建立更大、更具有扩展功能的分布式网络应用变得简单。所有ASP内置的对象都是COM对象，当用到这些对象时，就调用了COM对象的方法和属性。因此，以分布式体系结构，结合ASP与COM技术实现基于Internet的应用是当前系统设计的最佳选择。以此方法可以实现具有扩展功能的、交互式的、基于Internet的应用，使其具有高性能与多用户，便于系统重复使用、扩充和管理。
分布式应用程序最初分为客户端/服务器两层应用程序。但随着业务的复杂化与相关性的加强，三层和Ｎ层应用程序随之出现。三层和Ｎ层应用组件是其关键技术，每层的组件都执行一个特定类型的处理。三层应用程序包含用户服务(表现)层、业务服务层和数据服务层，组件使用公共接口封装。三层结构和传统的二层客户端/服务器结构的主要区别就是在三层体系内，业务逻辑从用户界面和数据源中分离出来。把应用程序划分成独立的层或部分，能减小整个应用程序的复杂性，一个层的改动对其他层影响最小，并且使应用程序能够跟得上业务发展的需要。COM是一种组件开发技术，即组件对象模型(component object model)，它实际上是二进制层上兼容的软件开发方法的规范。COM定义了组件互操作性的标准，即组件相互之间交互的能力。组件不需要用指定的语言编写，只需指定组件之间及其与操作系统之间如何通信。这就意味着，为COM编写的组件可以重复使用，因此，可以在很大程度上忽略不同编程语言、应用环境之间的差别，它为各层服务于不同环境的多层分布式应用提供了实现方法。而ASP(ActiveX server page)技术是三层分布式体系结构的典型应用，其体系结构如图1.1所示。它直接建立于Web服务器中，并且作为Web服务器的一个应用服务器运行，支持多用户、多线程，允许创建能被各种浏览器使用的服务器端应用程序。对于客户，只能看到可被各种浏览器识别的标准HTML，并且根据不同的客户需求，它能动态生成。这在过去需要编写复杂的CGI程序，而ASP应用简化了此过程，使创建三层分布式网络应用成为举手之劳。同时，ASP可以承载许多COM对象。由于COM对象的环境无关性，其使用非常简单，不需要任何特殊的语法就可以在代码中直接调用。可以说，没有COM，ASP就不会这么容易扩充，　使用也不会如此简单，或许它根本不会存在。ASP技术充分应用了软件复用技术、分布式应用构造技术，使各个应用功能模块化，完全实现了用户的信息共享，并能建造功能强大的Internet应用。

图1.1 ASP应用体系结构
使用 ASP 技术，不仅可以借助 ASP本身开发Web 应用的优势，而且由于ASP对COM组件的支持，因而可以借助组件技术的强大优势，而后者对UUHDB系统尤为重要。这是因为异构数据库的联合使用是一个极为复杂的应用，并且随着信息技术的发展，不断会有新的情况出现，组件化的应用开发将使异构数据库的集成变得简单、灵活，更具动态性。因此，开发大量的CON组件完成UUHDB系统应用处理是主要工作。图1.2表示了使用ASP技术的Web数据库应用系统框架。

图1.2 ASP数据库应用系统结构

第2章 基础知识介绍
2.1 ASP介绍
2.1.1 ASP的由来
ASP是Active Server Pages的缩写，即是"活动服务器页面"，它是Microso在Windows开发的动态网页描述语言，因为它号称可以让服务器的网页动起来，故以Active Server Pages命名。ASP文件是以。asp为扩展名的，它的特殊之处在于所有可以在Html文件中使用的标记语言多可以用于ASP文件中，而且ASP文件通过标记对把 VB Script 或 Java Script脚本语言的程序嵌入文档中，当服务器遇到这对标志时，便将其视为程序来进行解释执行，然后将执行的结果传送到客户机上供用户浏览，并且用户无法看见ASP的源文件，因此ASP也被称为服务器端脚本文件。
2.1.2 ASP与HTML的区别
对于浏览器来说，ASP和HTML几乎是没有区别的，仅仅是后缀为.asp和.htm的区别，当我们在客户端提出ASP的申请后，服务器将之间的内容解释成HTML语言并传送到客户端的浏览器上，我们的浏览器接受的只是HTML格式的文件，因此它适用于任何浏览器，不管是IE还是Netscape。
2.1.3 如何运行ASP
怎样才能运行ASP呢?很简单，您只要在您的计算机上安装IIS(Internet Information Server)或PWS(Personal Web Server)，并把您存放ASP文件的目录属性设为"执行"即可，当您浏览ASP文件时，在浏览器中输入URL(HTTP://……)就可以看到ASP执行的结果了。
2.1.4 ASP的对象
ASP本身具有的内建(built-in)对象主要有五个(如表2.1所示)：
表2.1 ASP的5个内建对象
对象
用途
server
用于提供服务器的各种有关信息
request
用于读取客户机上浏览器提交的信息
response
用于向客户机上的浏览器传输信息
application
用于记录各个不同网页之间的共同信息
session
用于记录各个不同的客户机的连接者的信息

除了以上的对象外，我们还可以使用ActiveX对象。与ASP的内建对象不同的是使用ActiveX对象通常要先建立具体的对象才能被使用。例如，我们要建立一个对象，其对象名假设为dx，并且此对象是属于"ADODB对象库"(在文件中对应于一个.DLL或.EXE文件)中的"Connection对象类型"。这里我们使用了Set语句和内建对象"Server"的"CreateObject函数"来建立此对象dx:
Set
Dx=Server.Create Object(“ADODB.Connection”)

通过执行上面的语句，我们便建立了一个ActiveX对象dx。
说了这么多，那么ASP到底能做些什么呢?往下看就知道了:
(1) 可以在您的主页中根据不同的用户对象显示不同的信息(这点利用动态HTML也可以做到)。
(2) 可以在您的主页中创建一个计数器。
(3) 可以把HTML的FOTM 中提交的信息存储在数据库中。
(4) 可以让用户使用服务器中的数据库(如利用关键字查询数据库等)。(5) 可以在您的主页中创建留言本。
(6) 可以创建聊天室、搜索引擎、电子购物等等。
ASP主要有五个内建(built-in)对象:Server、Request、Response、Applicatio和Session。现在我们通过举例来对它们进行讲解。首先是最常使用的Response对象。
ASP在软件技术上有如下特点:
(1)解释执行，无需编译和连接，ASP脚本集成于HTML中，容易生成。
(2)设计简单。常规的文本编辑器就可以进行页面设计。对专业人员，最好用Microsoft的ASP专用开发工具Visual InterDev。
(3)与浏览器无关。可以解释HTML的浏览器均可以浏览ASP设计的主页。ASP脚本在服务器端运行，浏览器无法查看ASP源程序。
(4)兼容性好。ASP支持几乎所有的脚本语言，如VBScript，JavaScript和Perl，编写的ASP文件只需用ASP特殊标记〈%和%〉把脚本括起来，ASP就可以解释执行这些脚本。
(5)面向对象。在ASP脚本中可以方便地引用系统组成和ASP内置组件，还能通过定制ActiveXServer组件来扩充ASP脚本功能。
(6)保护源程序。ASP脚本在服务器上运行，用户在浏览器上看到的只是ASP执行结果所生成的常规的HTML代码，这样就保护了程序员的知识产权。
(7)隔离进程。IIS允许Web应用程序以隔离方式在服务器上运行，隔离的应用程序运行在分配给它的特定的存储空间内，其他应用程序不能访问这块空间。这样可以防止因为某一应用程序的崩溃而影响其他应用程序。不过采用隔离进程会影响服务器的性能。
(8)安全。ASP运行在IIS之中，利用Windows NT的安全机制可以对ASP文件进行访问限制。
2.2 COM组件介绍
2.2.1 COM组件的概念及其特点
COM(Component Object Model)，即组件对象模型，是关于如何建立组件和如何通过组件建立应用程序的一个规范。四年前，Microsoft就已经开始开发COMLE ，其目的是使Microsoft的各种软件产品更加灵活，更具有动态性并且更易于定制。目前Microsoft几乎所有的应用都使用了COM。Microsoft的ActiveX技术就是基于COM而建立起来的。COM是一个说明如何建立可动态交替更新的组件的规范，它提供了为保证能够互操作，客户和组件应遵循的标准。该标准对于组件架构的重要性同其他任何一个具有可交替更新部分的系统是一样的。
COM组件是以Win32动态链接库（DLL）或可执行文件（EXE）的形式发布的可执行代码组合的。遵循COM规范编写的组件将能够满足对组件架构的所有要求。
COM组件是动态链接的，COM使用DLL将组件动态链接起来。为满足这些要求，组件还必须具有封装性。
实现COM组件的封装是很容易的，这是因为它们能够满足下面的一些限制条件：
(1) COM组件是完全与语言无关的。任何过程性语言，从Ada到C到Java到Modula-3到Oberon到Pascal均可用来开发组件，并且可以修改任何一种语言使它能够使用组件，如Smalltalk及Visual Basic等。实际上，我们有办法编写出能够被宏语言使用的组件。
(2) COM组件可以以二进制的形式发布。
(3) COM组件可以在不妨碍老顾客的情况下被升级。
(4) COM组件可以透明的在网络上被重新分配位置。对远程机器上的组件同对本地机器上的组件的处理方式没有什么区别。
COM组件按照一种标准的方式来宣布它们的存在。使用COM的发布方案，客户可以动态的找到它所需要的组件。
COM组件是一种给其他应用提供面向对象的API或服务的极好方法。对于可用于快速构造应用的，与语言无关的组件库的建立，COM组件也是不在话下。
COM并不是一种计算机语言。将COM同某种计算机语言相提并论是没有意义的。例如比较C++和COM谁优谁劣就没有什么意义，因为COM和C++ 各自有着不同的用途。COM所说明的是如何编写组件，但具体选用什么语言来编写则完全是自由的。
将COM同DLL相比或相提并论也是不合适的。实际上COM利用DLL来给组件提供动态链接的能力。对于可用DLL解决的任意问题都可以用COM组件更好的加以解决。
COM也并不是象Win32 API那样的一个函数集。它并没有提供类似于Move Windows这样的服务。相反，COM更主要的是一种编写能够按面向对象API形式提供服务的组件的方法。COM也并不是类似于Microsoft基本类库（MFC）这样的C++类库。COM给开发人员提供的是一种开发与语言无关的组件库的方法，但COM本身并没有提供任何实现。
COM当然并不仅仅是一套规范——它也确实需要一些具体的实现。COM具有一个被称作是COM库的API，它提供的是对所有客户及组件都非常有用的组件管理服务。当在非Windows系统下开发COM风格的组件时，要实现此API中的大多数函数并不是一件太难的事情。COM库可以保证对所有组件，大多数重要的操作都可以按相同的方式完成。同时，COM库也可以节省开发人员花在他们自己组件及客户的实现上的时间。COM库中的大多数代码均可以支持分布式或网络化的组件。Windows系统上分布式COM（DCOM）的实现提供了一些同网络上其他组件通信所需的代码。这不但可以节省开发人员花在网络编程上的时间，而且可以使他们无须了解网络编程的细节知识。
COM最值得称道的地方是我们可以将其作为一种编写程序的方法。例如，可以在任何操作系统上使用任何编程语言按COM风格进行编程。为编写类COM组件，开发人员并不需要任何在Windows系统上实现的COM代码。COM充分体现了组件编程的概念。同结构化编程及面向对象的编程方法一样，COM也是一种组织软件的方法。好的软件概念在COM规范中得到了充分的体现。
COM借助于如下一些手段保证这些组件可以充分利用动态链接所带来的各种好处：
(1)提供了一个所有组件都应遵守的标准。
(2)允许使用组件的饿多个不同版本，而且这一点对于客户而言几乎是透明的。
(3)使得可以按相同的方式来处理类似的组件。
(4)支持对远程组件的透明链接。
2.2.2 组件的规划原则
创建自己的COM组件之前，首先必须从功能方面弄清楚组件的应用需求。一般来说，COM组件的规划应遵循以下原则:((1)用户对于数据库的访问请求应通过COM组件来实现。将访问权限授予COM组件，可有效保证访问数据库的安全性;把对每个用户的连接变成和COM组件的连接，以避免数据库资源的浪费和系统崩溃的危险。(2)组件粒度不宜过大，争取每一个COM组件实现某一个或一类相似的应用内容，而不必追求其功能的过分庞大。保证每个组件对象完成的逻辑功能相对单一，有助于重用机制的发挥和调节DNA的适应性。(3)COM组件与用户的接口应尽量简单、友好。COM组件如果是可视的，则只能有一个可视化界面。2。2　组件接口设计的考虑组件的接口在整个应用系统中起决定性的作用。一般接口应具有较高的通用性，以提高整个应用系统的复用能力，同时还要兼顾简单和实用性。如果我们需要定制一个组件访问特定的数据库并将结果返回给客户，若只是为该系统设计，可以将库名、表名、SQL语句全部封装在组件内部，这样组件的接口十分简单，但组件本身的重用性很小;若将库名、表名等作为组件的接口，组件的重用性大大提高了，但接口复杂了，不利于组件的拆换。建议的做法是如果希望系统有再次开发或移植的潜力，可以将库表名作为接口。否则将访库权限交给用户，既不利于数据库的安全性，也会给应用程序带来很大的负担。组件的内部实现细节不能反映到接口中，接口同内部实现细节的隔离程度越高，组件或应用发生变化对接口的影响将越小。
2.3 COM组件与ASP之间关系
在现今的3层体系结构中，业务逻辑单元是以COM组件的形式在中间层执行的，大大减少了服务器端运行的ASP脚本。但这并不意味着ASP将失去其原有的光彩。我们不仅可以通过编写ASP脚本动态生成的HTML，ASP还可以作为“粘合剂”将各个COM组件“粘合”在一起，并负责应用系统和COM组件间参数的传递。Active XDLL形式的COM组件在Web环境下应用时，通过ASP脚本的调用而显现自身的价值，把经过测试的COM组件集成到动态Web的ASP页面脚本中，并进行系统测试。在集成过程中，先通过Visual InterDev建立Web站点，连接服务器并在Web服务器的根目录下建立站点主页，然后交替使用Visual InterDev和FrontPage工具编写ASP脚本。最后在FrontPage Explorer下利用其提供的Publish功能将其导入IIS服务器，从而使客户能用前端的浏览器，从服务器上下载这些应用程序。下图表示了ASP和COM组件的关系：

图2.1 ASP和COM组件的关系

第3章 ASP调用COM组件

3.1 安装注册COM组件
要作为脚本的一部分使用一个COM组件，必须首先保证COM组件已经在WEB服务器的计算机操作系统上注册。当一个组件注册时，在WINDOWS注册表中建立一个项目，用来通知系统在何处可以找到对应于组件名称的代码。如果未注册，则在企图组件时，IIS将返回一条错误。
考虑如下脚本:
<%
Option Explicit
Dim obj
Set obj=Server.CreateObject(“StarTrek.TransporterControl”)
If not(obj.BeamUp(“Spock”)) then
Response.write “He’s shown up with a beard!”
Else
Response.write “Spock transported successfully。”
End if
%>
如果将这一代码输入到计算机中并试着运行它，则将得到错误。
这正是ASP通知我们的方式:”在这一系统中没有你试图使用的组件，或者有这一组件但是未注册-----这使我无法找到它。”
对于存在的每一个COM组件，均有一个唯一标识该组件的128位的数字。这一数字称为Globally Unique Identifier(GUID)， 因为代表一个组件的这一数字，从时间和空间上保证了该组件的唯一性，肯定与标识其他每一个COM组件的数字不同。
典型的GUID如下所示:
4abf2131-27c8-00bd-79fc-11bb114e8441
第一个设计COM的开发人员可能决定让我们承担每次需要实例化一个给定COM组件时输入这一代码的重任。在这种情况下，创建ASP常用的对象如下所示:
Set obj=_Server.CreateObject(“4a4abf2131-27c8-00bd-79fc11bb114e8441”)
常识告诉我们，这一方法对一般的程序员将是很困难的。开发人员仅仅为了使用一个简单的对象，不仅需要记住神秘而很长的字符串，而且很小的输入错误均导致其应用程序的运行完全失败。
因此COM包括可以根据开发人员为其选择的更短和更自然的名字，查找与各种组件相关联的GUID的程序。这样在上面的例子中开发人员试图实例化一个StarTrek.TransporterControl组件，事件的流程如下;
(1)ASP解释创建StarTrek.TransporterControl对象的请求。
(2)IIS请求COM实例化一个StarTrek.TransporterControl类的实例。
(3)COM在WINDOWS注册表中搜索该类的一个项。
(4)如果找到一个项，则得到该类的GUID;否则返回一条错误。
(5)COM使用该GUID在注册表中搜索该类的文件名和代码所在位置。
(6)如果找到一个项，则从该文件建立该对象;否则返回一条错误。
(7)如果该文件包括一个适当的COM对象，则将新的实例传送回IIS;否则产生一条错误。
(8)IIS传送新对象实例的一个句柄给ASP。
初学ASP的开发人员可能认为只要将一个给定的DLL，OCX或EXE文件拷到Web服务器，即可允许其在服务器上的脚本使用这些文件所包括的任何组件了。这种想法是错误的。如果我们检查上述步骤，将看到在一台机器上有了所需的文件仅仅足以满足第7步的要求。但是为了到达第7步，COM必须首先通过第(3)步到第(6)步。正是这些步骤导致实例化失败，除非我们首先注册了COM组件。
如果我们正在使用这种开发环境建立组件，则也可以直接从Visual Basic 在系统中注册COM组件。当编译ActiveX DLL和ActiveX EXE工程时， Visual Basic将自动注册这些工程中的COM组件。所以从Visual Basic中注册组件时我们必须做的全部工作是成功地完成便宜。
在Visual Basic中编译一个 ActiveX DLL和ActiveX EXE工程的步骤如下:
(1)启动Visual Basic。
(2)打开包含希望注册的组件的Project或Project Group。
(3)如果打开的是一个Project Group，则从Project Navigator中选择包括组件的特殊Project。
(4)打开File菜单。
(5)选择Make。
(6)为EXE或DLL文件选择一个适当的位置。
(7)为EXE和DLL文件选择一个适当的名字。
按照这些步骤创建的DLL或EXE文件，然后注册其中的组件。访问组件所使用的名字与所选择的文件名无关，相反访问组件所使用的名字是该工程的名字和跟在其后面这一工程中的类的名字。所以对于组件StarTrek.TransporterControl，我们可以推断出StarTrek是在Visual Basic下编译的ActiveX DLL和ActiveX EXE工程的名字，TransporterControl是该工程中一个类的名字。

3.2 理解组件的相关性
当今软件的设计很少有这样的情况，即一段代码的存在和作用完全独立于其他有的软件。许多应用程序几乎完全以多个独立的组件的松散关系而存在，使用DCOM的分布式功能将其自身粘合在一起形成一个有用的整体。大多数非分布式应用程序的特性是至少有一个中央式的可执行文件，而无论有多少个库可能支持它。
ASP开发人员常常认为DLL和OCX文件是自包含的，并且没有其自己的相关性。因此他们常常将这种文件从起开发环境拷贝到结果Web服务器，并假设只要在目标系统上正确地注册之后即可使用，然而情况并非如此。
DLL和OCX文件的组件的设计目标是运行在加载这些组件到内存中的那些可执行程序的处理空间内。除此之外，组件与独立的可执行程序是完全一样的。组件也完全可以请求加载到内存中的其他组件，为其提供所需要的功能。
如果我们将一个组件移动到另一个计算机上并已经注册，而没有同时将其所依赖的所有组件也移动过来并注册，则将出现错误。此时Active Server Page产生一条非常含糊的声明。
3.2.1 检查源代码
为了正确地将一个组件从一个系统移动到另一个系统，必须保证移动随之该组件本身所依赖的所有组件。如果我们是必须移动的那个组件的开发人员，则这一过程可能相对简单一些。我们可以从检查源代码开始，查看已经引用的组件有哪些。
例如在Visual Basic下，我们的定制组件所需要的许多组件均将列表显示在References对话框中，如图3.1所示。

图3.1 Visual Basic References对话框

对话框顶部的列表中显示了许多在我们的创建中可以使用的系统中的组件，带有选择标记的组件是我们的应用程序当前正在使用的组件。当我们高亮显示列表中的项时，包含这些组件的物理文件的确切路径显示在对话框的底部。这些信息对于收集与我们的组件一起发布所需要的所以文件很有用。
References对话框所关注的是DLL和EXE文件中的组件，而Components对话框则更注重于在OCX文件中找到的控件。这些控件是可见的ActiveX控件，一般可以直接放置在表单用来与最终用户交互。
与References对话框类似，带有选择标记的组件是我们当前工程中实际使用的组件。
3.2.2 Dumpbin工具
当需要在自己的Active Server Page中使用一个组件，而又没有该组件的源代码时将出现什么情况？由于用于COM应用程序的第三方组件的越来越丰富，出现这种情况的可能性越来越大。很少有这样的情况，即购买一些组件仅仅用于一个单一的很小的功能，并且在购买时不带有任何源代码或文档形式的资料。
当出现这种情况时，最好的方法是使用其自己的定制安装程序安装所购买的组件。在购买组件时一般提供这些安装程序，并且通常命名为SETUP.EXE。这一名字的另外一些变形是INSTALL.EXE，WINSTALL.EXE和SETUP32.EXE等。
安装程序一般知道其组件所依赖的文件，当没有这些程序时，我们必须求助于其他工具，尽量找出这些相关性。这些工具中最古老，最简单和最确定的是Dumpbin，在Windows Platform SDK和Visual C++的CD中均带有该工具。
Dumpbin的使用非常简单：
(1)在本地驱动器中定位DUMBIN.EXE。
(2)定位包含我们希望确定其相关性的组件的物理文件。
(3)输出如下命令：
Dumpin/imports<filename>
(4)检查所产生的输出短语”Section contains the following imports…”。其中所标记的每一部分，均应该包含一个我们的组件执行所需要的DLL文件的列表。
3.2.3 Depends工具
我们可能认为，使用一个诸如 Dumpbin这样的工具后，遗漏相关性的日子将彻底过去。不幸的是，虽然Dumpbin工具已经很好，但仍然可能出现缺少Active Server Page所使用的组件是完整相关性信息的情况。为了了解为什么会出现这种情况，必须首先了解静态与动态连接组件之间的区别。
一个静态连接组件是在编译时连接到我们自己组件中的，静态连接的优点是这些种类的文件总出现在Dumpbin的输出结果中。这种连接的缺点是其将使我们的组件对内存的需求急剧增加，因为这些组件总是随着我们自己的组件，所以在我们自己的组件的生命周期一开始即加载。
动态连接组件提供了更大的灵活性，因为在我们的组件特别请求这些组件之前，这些组件并没有加载到内存中。这样就大大降低了我们的组件对内存的要求，因为并不是所以所依赖的组件均需要同时处于内存中。这种连接的缺点是动态加载的组件并不包含在Dumpbin的输出结果中。
因此Microsoft建立了另外一个称为Depends的工具，Depends是一个GUI应用程序，包含在Microsoft Platform SDK和Visual Studio中。Depends的使用与 Dumpbin有一些不同，如下步骤说明了 Depends工具的使用方法:
(1)本地硬盘上定位DEPENDS.EXE。
(2)执行该程序。
(3)从File菜单中选择Open。
(4)从Profile菜单中选择Start Profiling。
(5)在Program Arguments下输入启动使用我们组件的软件命令所需要的内容。
(6)为该组件选择正确的Starting Directory。
(7)单击OK。
(8)以可以想到的各种方式使用应用程序，以保证每一个操作可以请求一个所调用的动态组件。
(9)在使用组件时注意在窗口底部所产生的事件列表。
如果有关于遗漏组件的错误消息弹出，则记录要使我们的组件正确运行所必须安装的这些动态文件。
3.3 绑定支持
对于所有Microsoft的COM技术，基本的要求是每一个遵守COM规则的对象均要实现一个称为IUnKnown的接口。仅仅使用IUnKnown接口中的方法，客户应用程序即可发现关于一个COM组件提供的方法所需要的所有信息，这些方法所使用的参数，以及所返回的数据类型。
然而访问IUnKnown的特性要求应用程序支持许多低级指针操作，这些操作一般与C++这样的语言有关，Active Server Page自身不能实现这种操作。COM规范还规定组件可以有选择地提供对另一个称为IDispstch的接口的支持，该接口可以提供同类型的运行时搜索方法和其参数的功能。
3.3.1 后期绑定和前期绑定
通过IUnKnown接口能够访问COM组件的应用程序，可以使用所谓的前期绑定。在前期绑定机制下，变量所包含的对象的特定类型可以在编写脚本时申明。这种情况下允许开发环境在程序编译时检查，确保：
·所声明的对象的类型已经在将要使用它的系统中注册。
·应用程序中的代码不明显将不适当的对象类型赋予该变量。
与此相反，后期绑定组件在运行之前对于编译器来说是完全未知的，这是因为用来包含这种组件的变量并没有声明为任何特定类型。由于Active Server Page只支持Variant，这是一种非指定的数据类型，所以ASP应用程序不能直接使用前期绑定方式，而只能使用后期绑定方式。
试图在其应用程序中使用前期绑定机制的Active Server Page开发人员，可以编写与如下代码类似的代码：
<%
Option Explicit
Dim obj as Startrek.TransporterControl
Set obj=new StarTrek.TransporterControl
If not(obj.BeamUp(“Spock”)) then
Response.write “He’s shown up with a beard!”
Else
Response.write “Spock transported successfully.”
End if
%>
不幸的是，Active Server Page不直接支持IUnKnown接口，所以上述脚本从头到尾均充满着错误。其部分原因是由于不支持IUnKnown接口，所以ASP将不可能正确地限制变量可以使用的对象类型。
这一脚本中所包含的另一个错误是代码行中使用了new关键字，该关键字将对象设置为指向其对象的一个新实例。在Visual Basic下，关键字new仅使用于通过IUnKnown提供前期绑定的组件。Active Server Page不提供这种支持，所以所有的新对象均必须使用Server对象的CreateObject方法实例化。
3.3.2 IDispatch
由于不能使用IUnKnown接口，所以在我们的开发环境中只能后期绑定我们的组件，即在我们的代码中没有办法限制编译时指定给给定变量的对象类型。Active Server Page也是如此，它既不支持IUnKnown，也不能在首次使用之前编译脚本。
对ASP不支持IUnKnown和前期绑定这一问题的解决方案通常是使IDispat接口和其后期绑定功能。使用这种技术重新编写后，上述脚本样例可能如下所示：
<%
Option Explicit
Dim obj
Set obj=Server.CreateObject(“StarTrek.TransporterControl”)
If not(obj.BeamUp(“Spock”)) then
Response.write “He’s shown up with a beard!”
Else
Response.write “Spock transported successful.”
End if
%>
碰巧的是并非所有COM组件均支持IDispatch接口，有些COM组件仅仅提供IUnKnown接口，所以也只能在可以使用事先绑定的开发环境中使用。如果试图仅仅使用Server对象的CreateObject方法，则从Active Server Page下有许多因素可以产生这一错误消息。如果可以访问该组件的技术支持或文档，可以从这些地方或资料中查找答案；否则如果可以进入Visual Basic开发环境，可以自己执行一个简单的测试。
为了在Visual Basic环境下测试一个组件，确定其是否支持IDispatch接口，首先试着使用前期绑定声明并实例化该对象：
Dim z as