|
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+新的服務功能。
|
