[RESOLVED] Register DLL's at runtime (to allow for late-binding)

[bobbo]

The first way to use DLL functions is to early bind, using Tools>References on the VBE menu. However, this prevents you from deploying your code (unless you manually set up each user).

The second way is late binding using the CreateObject command. The downside here (besides a minor performance hit) is that the DLL must be registered on the user's computer before calling the CreateObject command. Example:

'dsofile.dll found at: http://support.microsoft.com/kb/224351
Shell "regsvr32 /s """ + ThisWorkbook.Path + """\dsofile.dll""", vbHide
Set objFile = CreateObject("DSOFile.OleDocumentProperties")
objFile.Open "yourfile.xls", ReadOnly:=True
MsgBox objFile.SummaryProperties.Category
Shell "regsvr32 /s /u """ + ThisWorkbook.Path + """\dsofile.dll""", vbHide

Problem solved, right? Almost. In a locked-down corporate environment, users won't have admin rights and the DLL registration may fail. (This depends on the DLL: specifically, a non-admin can't write to the HKEY_LOCAL_MACHINE registry key.) The work-around is to "manually" register the file into the HKEY_CURRENT_USER key instead. For the dsofile.dll example, it looks like this:

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("WScript.Shell")
Set objEnv = objShell.Environment("Process")
strSourceFile = ThisWorkbook.Path & "\dsofile.dll"
strDllFile = objEnv("TEMP") & "\dsofile.dll"
If Not objFSO.FileExists(strDllFile) Then
    objFSO.CopyFile strSourceFile, strDllFile, False
End If
strRegFile = objEnv("TEMP") & "\dsofile.reg"
If objFSO.FileExists(strRegFile) Then
    objFSO.DeleteFile strRegFile
End If
Set objOpenRegFile = objFSO.OpenTextFile(strRegFile, 2, True)
objOpenRegFile.WriteLine ("Windows Registry Editor Version 5.00")
objOpenRegFile.WriteLine ("")
objOpenRegFile.WriteLine ("[HKEY_CURRENT_USER\SOFTWARE\Classes\DSOFile.OleDocumentProperties]")
objOpenRegFile.WriteLine ("@=""DSO OLE Document Properties Reader 2.1""")
objOpenRegFile.WriteLine ("")
objOpenRegFile.WriteLine ("[HKEY_CURRENT_USER\SOFTWARE\Classes\DSOFile.OleDocumentProperties\CLSID]")
objOpenRegFile.WriteLine ("@=""{58968145-CF05-4341-995F-2EE093F6ABA3}""")
objOpenRegFile.WriteLine ("")
objOpenRegFile.WriteLine ("[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{58968145-CF05-4341-995F-2EE093F6ABA3}]")
objOpenRegFile.WriteLine ("@=""DSOFile OleDocumentProperties""")
objOpenRegFile.WriteLine ("")
objOpenRegFile.WriteLine ("[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{58968145-CF05-4341-995F-2EE093F6ABA3}\InprocServer32]")
objOpenRegFile.WriteLine ("""ThreadingModel""=""Apartment""")
objOpenRegFile.WriteLine ("@=""" & Replace(strDllFile, "\", "\\") & """")
objOpenRegFile.WriteLine ("")
objOpenRegFile.WriteLine ("[HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{58968145-CF05-4341-995F-2EE093F6ABA3}\ProgID]")
objOpenRegFile.WriteLine ("@=""DSOFile.OleDocumentProperties""")
objOpenRegFile.WriteLine ("")
objOpenRegFile.Close
Shell "regedit /s """ + strRegFile, vbHide

'now continue with CreateObject as before
Set objFile = CreateObject("DSOFile.OleDocumentProperties")
objFile.Open "yourfile.xls", ReadOnly:=True
MsgBox objFile.SummaryProperties.Category

The trick is to know what to put in the .reg file: I did this by registering the dll on my system (logged in as an admin) and found what keys it used. Then I exported them, replaced HKEY_LOCAL_MACHINE with HKEY_CURRENT_USER, and saved this as my new .reg file.

The net result is you can simply put a copy of your DLL in the folder with your document, and your code works with zero client configuration. (One note: If you replace a DLL with a new one, it may break your "manual" registration. Be sure to review your code before deploying a new DLL.)

[Goldfingers]

Ji,

Why CreateObject looks only HKLM and not HKCU ?
I can write on HKCU but when i use createObject DLL is not recognised
Do you know why ?

Thans

[bobbo]

> Why CreateObject looks only HKLM and not HKCU ?

CreateObject just looks for the "DSOFile.OleDocumentProperties" object, no matter where it is in the Windows registry.

By default, dsofile.dll registers itself into HKLM. If you're an admin user, the first block of code will work for you. If you're not an admin, you have to use the second block of code, which forces the registration in HKCU instead.

> I can write on HKCU but when i use createObject DLL is not recognised
> Do you know why ?

If you have errors, open your registry editor and see if the keys (the "objOpenRegFile.WriteLine" statements) were created.

[Goldfingers]

Hi,

That means i cannot Register my one created DLL on HKCU and use createObject ?

Thx

[bobbo]

That means i cannot Register my one created DLL on HKCU and use createObject ?

If you're creating your own DLL, you can register it any where you want. In fact, I recommend you choose HKCU to allow non-admins to use it. CreateObject finds the association no matter where it is in the registry.

I can't help debug your DLL for you, but you could start by checking the CLSID in the registry to make sure the classes are set up correctly.

[Goldfingers]

Exactly the purpose of my need is to allow non-admins to use the DLL.

To write on HKCU, i use this "Set oExec = wShell.Exec("regedit /s " & sFileName)"

Why do i have information two times in the registry ? i mean in HKLM and in the HKCU

Do you thing that is why CreateObject() can't found my DLL ?

Regards

[bobbo]

I'm assuming we're still talking about dsofile.dll:

If you use regsvr32, it will register in HKLM.
If you use regedit /s with my script, it will register in HKCU.
It's registered in both places on my PC and works fine.

In the registry, check the path to dsofile.dll in the InprocServer32 key. The default key should have the format: C:\YourDirectory\dsofile.dll