這是一個非常重要的選擇,盲目應用它不是一個好主意。
COM有一個非常強大的DLL Hell問題。註冊COM服務器默認情況下具有機器範圍,這是由服務器註冊寫入HKLM註冊表配置單元中的註冊表引起的。當您更改服務器的實現並且使用服務器的客戶端程序不在計算機上重新編譯和升級時,會發生非常糟糕的情況。請記住,您只能直接控制服務器的版本,通常很少有關於確保客戶端程序更新的信息。
發生的一件很好的事情是,當你遵循COM約定,並給予coclass和接口一個不同的{guid}。客戶端程序將無法找到適當的接口,並在運行時因REGDB_E_CLASSNOTREG或E_NOINTERFACE運行時錯誤而失敗。用戶通常可以弄清楚什麼地方出了問題,當然不會讓他感到非常高興,但有些可能性他會採取自己的糾正措施並刪除更新。
可能發生的非常糟糕的一種非常糟糕的事情是,COM客戶端不會失敗定位coclass和接口,但是調用失敗。可能是完全錯誤的功能,可能是參數不再兼容。這種失敗完全是無法想象的,用戶無法找出問題所在。你會得到一個「它不起作用,幫助我!」電話。
.NET對於允許程序集的不同版本在機器上並排生活非常有力。 GAC是它們的存儲位置,[AssemblyVersion]屬性是關鍵。因此,重新編譯爲使用新版本的客戶端程序將自動使用新版本的COM服務器。未重新編譯的程序將繼續在舊版服務器上正常運行。 GAC提供他們所需的版本。
GAC對於.NET類庫也很有用,但由於大多數.NET庫部署在與使用它們的EXE相同的目錄中,因此大多數.NET庫都可以使用。自從註冊爲機器全局以來,不存在[ComVisible] .NET庫的情況。通過使用清單,有反對措施,但這取決於客戶端程序,而不是服務器。再次在你的控制之外。如果客戶端程序是一個廣泛使用的程序,如Office應用程序或Internet Explorer,通常非常不切實際。
因此部署你的COM服務器到GAC是非常重要的,你真的想利用DLL Hell的反制措施,並有一定的信心,更新服務器不會造成大問題。
想要使用/ codebase的唯一時間是在開發和測試服務器時。在這種情況下,您當然不會擔心DLL地獄,您總是使用最新版本,不想因爲需要將其放入GAC而感到不適。容易忘記,這是你永遠不會回來的一小時生活。
我同意,我們做同樣的事情 –
謝謝+1。你知道,如果你可以在COM類可見的.NET類中有重載的構造函數嗎? – w0051977
Com可見類必須始終具有無參數構造函數。您可以根據需要創建任意數量的參數化構造函數,但不能從VB6調用它們。提示:使用工廠方法來創建你的Net類。這些工廠方法可以調用一個參數化的構造函數。您甚至可以通過拋出異常來防止使用無參數構造函數 – Dabblernl