|
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 Microsoft
//Corporation.All rights reserved.
#define __MTxSpm_LIBRARY_DEFINED__
#include "comsvcs.h"
Platform SDK所带的mtx.h文件其实就是COM Services头文件的包装文件。如果检查Visual C++项目的外部相关性（external dependencies），你会发现comsvcs.h包含在列表中而不是mtx.h。这个文件也是为什么要把Platform SDK的库和包含文件放置到Visual Studio安装的文件前面的原因之一，要确保组件选择了正确版本的头文件，比如mtx.h。
实际上你可以改变组件中的代码来不引用mtx.h:
#include <comsvcs.h>
这并不会影响到最终结果，在windows 2000中ASP组件可以注册成为COM+应用并由ASP页面访问。
还是那句话，迁移过来的组件在Windows 2000中拥有和NT4中一样的组件服务。但是，如果没有认真的考虑和广泛的修改，你并不能使用Windows 2000 COM+新的服务功能。
|
