.XLL registering COM libraries into HKLM, not HKCU

Jul 19, 2013 at 3:13 PM
I have a question about Excel DNA. I have a .DNA file which, using ExcelDNAPack, creates a .XLL Excel Add-In. I have chosen for the DLLs to be packed into the XLL.

When we load the XLL (as an Add-In, not by running regsvr32), the DLLs are registered under HKLM. I thought the DLLs would be registered under HKCU so that multiple users could run our Excel app with entirely separate COM registrations (the app, ultimately, will run for many users on a Citrix box, so this is important).

Maybe there is a setting I can put in the .dna file which specifies where the COM components should be registered?


Jul 19, 2013 at 8:46 PM
Edited Jul 19, 2013 at 8:50 PM
Hi Philip,

I presume the registration you refer to is via the ComServer.DllRegisterServer() call.

Initially Excel-DNA only used the HKCU. But when running with a UAC-enabled context, but under an elevated token, the values written to HKCU is ignored by Windows, even though the registration writes succeed. This seems to be a hard case to detect.

So the current Excel-DNA approach is to first try to write to HKLM, and if that fails to write to HKCU.

I understand your situation makes this inconvenient - the different Citrix users might have the add-in in different locations, for example?

Given the current Excel-DNA approach, one option for you might be to ensure the users are not able to write to HKLM, and Excel-DNA will automatically fall back to HKCU. That might be reasonable in a shared environment.

Otherwise, I'd prefer to have some way to detect that the process is running under an elevated token. I might try this: http://stackoverflow.com/questions/1220213/detect-if-running-as-administrator-with-or-without-elevated-privileges.

Adding some kind of flag to the .dna file or to the call to ComServer.DllRegisterServer to restrict write attempts to HKLM would also be possible, though there isn't anything like that at the moment.