日期:2009-09-01  浏览次数:20772 次

Visual Basic 组件
    将原有的Visual Basic 项目文件拷贝到新的开发环境中,用VB打开使用MTS类库(Mts.dll)开发的项目。检查项目使用的参考库,会发现MTS类库已经被COM+ Services Type Library(comsvcs.dll)所代替了。


    当Microsoft Visual Basic创建新的COM Services组件的时候,它提供MTS所有的函数。要确保这些函数能够被移植到Windows 2000的组件正确的使用,Microsoft给COM Services组件分配了和旧的MTS组件完全一样的CLSID。

基于Visual Basic的组件从表面上看是通过类型库的说明来访问MTS的函数,但内部是通过CLSID来访问的。在Windows 2000中,基于Visual Basic的ASP组件访问同样的函数,但是它通过新的COM Services组件。

作为将组件移植到新系统的测试,将VB中的项目文件不做任何修改进行编译,你会发现不仅编译过程没有任何的问题,而且在Windows 2000中用ASP页访问组件的表现也和在NT中是一样的---当然,这还要看组件的功用以及他访问什么样的外部进程。举例说,某组件实现ObjectControl以利用JIT功能然后调用内建的ASP Response对象向客户端输出信息。

Figure 8Implementing ObjectControl


' the response object instance
Private m_oResponse As Response

'Implementation of ObjectControl interface
Implements ObjectControl

' ObjectControl Methods
Private Sub ObjectControl_Activate()
  Dim oContext As ObjectContext
  Set oContext = GetObjectContext()
  
  Set m_oResponse = oContext("Response")
End Sub

' for object pooling, required method
Function ObjectControl_CanBePooled() As Boolean
    ObjectControl_CanBePooled = False
End Function

' cleanup
Sub ObjectControl_Deactivate()

  Set m_oResponse = Nothing
End Sub

' use the Response object instance
Sub testResponse()

  m_oResponse.Write "Hello Windows 2000 World!"
  
End Sub



在IIS5.0中,将组件注册到Component Services并由ASP页面访问的结果与在NT4中将组件注册到MTS中的表现是一样的。注意,ASP页面调用testResponse方法,它将激发JIT调用ObjectControl Activate方法,创建Response对象输出“Hello World”信息。

在两个操作系统环境中访问组件不同的地方在于组件在Windows 2000中会较早的失效。Windows NT4中只有在页面完全退出作用域时才被释放;在Windows 2000中,组件在最后一个引用被释放时就释放了。因此,只要在ASP页面中将组件的实例设为Nothing(VBScript),VB的组件立刻就失效了。

当然,上面说的并不是ASP组件在Windows 2000和Windows NT中表现不同的唯一的地方。如果组件原来用作调用Windows NT特定的服务或执行某些操作,如输入/输出,Windows 2000在实现上可能会有些不同,也就是说可能需要重写相关的代码来适应新的系统。不过,如果ASP组件主要是使用某些技术(如ActiveX Data Object--ADO)访问数据库,这种情况受到的影响是最小的。

注意在Windows 2000中开发组件和Windows NT有一些不同,在Windows NT中用Visual Basic(Visual C++)开发注册到MTS的组件时,每次编译后要刷新组件一次。原因是,VB(VC)会在组件(DLL)生成后自动的注册一次。但是,Visual Basic创建的注册表实体会和MTS为这个组件创建的注册表实体冲突。在重编译后通过在MTS中刷新组件,会使MTS修复相关的错误。

在Windows 2000中,COM+和MTS并不是分割开来的,而被访问的组件通过Visual Basic或REGSVR32.EXE进行注册也是COM+所支持的。COM Services仍然保留了Refresh选项保持向后兼容性,但是已经不用在重编译后使用该选项。

谈到注册的问题,并不是非要重编译组件或者将它们添加到COM+的应用中才能用ASP访问,仍旧可以使用REGSVR32.EXE注册组件。使用REGSVR32.EXE注册组件或把组件添加到COM+应用中唯一不同的COM+考虑经配置的组件,而REGSVR32.EXE考虑未配置的组件。只要组件不使用事务处理和JIT功能,他仍旧会工作的很好,而不管是如何注册的。



Windows 2000中的Visual C++组件

    如果使用Visual C++开发ASP组件,Platform SDK安装程序会把SDK类库和头文件添加到开发环境中,如图9。如在Visual Basic中一样,ASP组件在Visual C++中重编译的过程不需要或只需要很少的改变,这包括任何使用ATL组件向导创建的ASP或MTS组件。



    在使用Visual C++ 6.0 ATL 向导创建ASP组件的时候,会使用ScriptingContext对象和OnStartPage 和OnEndPage事件处理程序,以例示ScriptingContext对象、创建ASP内建对象实例以及清除对象。Microsoft保留这些引用主要是为了保证向后兼容性,而使得这些组件可以工作在Windows 2000和IIS 5.0环境下,

尽管ScriptingContext依旧存在,但是不要再继续使用它们进行开发工作。作为替代,应当使用其它的ATL Object Wizard选项或者使用组件类库进行开发。请认真的考虑一下再将涉及ScriptingContext组件移植到Windows 2000中,在未来该对象将不再被支持。

在使用ATL Object Wizard创建MTS组件时,会把MTS类库和头文件加入到项目中。如下列代码会自动的添加到组件的头文件中。

#include <mtx.h>
在Windows 2000中MTS已经被COM+替代,MTS类库也被COM Service类库替代。那么,MTS组件是如何成功的编译并工作呢?

答案很简单,打开Platform SDK所附带的mtx.h文件就真相大白了:

  //  Copyright (C) 1995-1999 Mic