無法訪問HKEY_CLASSES_ROOT的遠程DLL註冊

Question

我們有一個傳統的VB6應用程序，它在啓動時通過下拉最新文件並註冊COM組件來自行更新。這適用於在另一臺計算機上的COM +中註冊的本地（regsvr32）ActiveX COM組件和遠程（clireg32）ActiveX COM組件。

出於安全原因，新的要求阻止我們寫入HKEY_LOACL_MACHINE（H​​KLM），這在調用regsvr32和clireg32時顯然是默認情況下發生的。

我們想出了一種方法，使用RegOverridePredefKey Windows API方法在HKEY_CURRENT_USER \ Software \ Classes（HKCU）下注冊本地COM組件。這是通過將插入註冊表重定向到HKCU位置來實現的。然後，當COM組件被實例化時，窗口首先查找HKCU，然後在HKLM中查找組件信息。這取代了regsvr32正在做的事情。

我們現在遇到的問題是，當我們嘗試使用clireg32註冊VBR/TLB時，此註冊過程還向HKEY_LOACL_MACHINE添加註冊密鑰。

有沒有辦法將clireg32.exe重定向到註冊組件HKEY_CURRENT_USER？ 是否有任何其他方法可以讓我們在客戶端計算機上註冊這些COM +組件並使用有限的安全訪問權限？

我們現在唯一的解決方案是手動將註冊信息寫入註冊表，但這並不理想，並且是一個重大問題。

Answer 1

我在這裏看到幾個快樂的答案。使用12年前的技術需要安裝更新的應用程序的概念很奇怪，而且在現代機器上支持得不好。像無reg COM這樣的常見解決方案，我認爲與COM +不兼容。同樣很奇怪的是，bug修復風格更新需要重新註冊組件。你是否證實這實際上是必需的？

擴展到該主題，您實際上多久更換一次部署中的GUID？當鑰匙不經常改變時，自己負責登記而不是將它留給組件本身應該是可行的。可以像使用SysInternals的ProcMon實用程序捕獲註冊一樣簡單，編寫一個設置HKCU密鑰的.reg文件。

除此之外，您確實需要獲得不可寫的註冊表項權限。如果您無法從客戶那裏得到好處，那麼可以考慮要求安排更新的計劃任務。只要系統管理員允許，他們可以訪問。