If you’re developing ARX modules that need to be registered as a COM server, you’re faced with some decisions about how to register them. In the old days before anyone cared about user permissions, registration could be safely accomplished at runtime, even via AutoLISP. Unfortunately runtime COM server registration just doesn’t work reliably any more under limited user accounts, not to mention registry redirection on 64-bit platforms. There is only one reliable way to register COM servers, and that’s doing it at install time under elevated privileges.
A normal Windows application might accomplish install-time registration by calling RegSvr32 after the files are copied to the destination folder, but this doesn’t work with ObjectARX or BRX modules. The reason it doesn’t work is because ARX modules cannot be loaded outside the AutoCAD or Bricscad process. RegSvr32 will fail with errors like “The module <filename> failed to load” or the even less helpful “The specified module could not be found.” There are some kludgy ways to get RegSvr32 to work anyway, but the simplest and most reliable way to solve this problem is to forget RegSvr32 and just add the needed registry values manually into your installer script. It’s not difficult, though it might be time consuming initially if your server implements a lot of COM objects.
At a minimum, a COM server must register at least one COM class under HKCRCLSID. If the COM server needs to support OLE Automation (e.g. VBA, AutoLISP) it must register a type library in HKCRTypeLib. In most cases, this is all that is needed, however you may also need to register a “ProgID” in HKCR if a script or in-process module needs to be able to connect to the server via human-readable ProgID.
Most installation script software can import Windows registry script (.reg) files, so it’s often helpful (and more maintainable) to create a registry script file manually, then simply import the .reg file into the installation script. If you use Visual Studio deployment projects, this is the only way to batch import registry values into the installation script. I’ve provided a minimal template for a registry script that registers a single COM object and ProgID. The template uses special characters as placeholders for the actual values: $$ is the human readable ProgID name, ## is the COM object’s CLSID, ** is the filename of your ARX module, and %% is the type library GUID. The type library and object class version numbers should match your actual version numbers as well, and of course [TARGETDIR] is the installation target directory that will be resolved at install time.
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT$$.1]
@=”$$ Class”[HKEY_CLASSES_ROOT$$.1CLSID]
@=”{##}”[HKEY_CLASSES_ROOTCLSID{##}]
@=”$$ Class”[HKEY_CLASSES_ROOTCLSID{##}InprocServer32]
@=”[TARGETDIR]**.arx”
“ThreadingModel”=”Apartment”[HKEY_CLASSES_ROOTCLSID{##}ProgID]
@=”$$.1″[HKEY_CLASSES_ROOTCLSID{##}Programmable]
[HKEY_CLASSES_ROOTCLSID{##}TypeLib]
@=”{%%}”[HKEY_CLASSES_ROOTCLSID{##}VersionIndependentProgID]
@=”$$”[HKEY_CLASSES_ROOTTypeLib{%%}]
[HKEY_CLASSES_ROOTTypeLib{%%}1.0]
@=”$$ 1.0 Type Library”[HKEY_CLASSES_ROOTTypeLib{%%}1.0 ]
[HKEY_CLASSES_ROOTTypeLib{%%}1.0 win32]
@=”[TARGETDIR]**.arx”[HKEY_CLASSES_ROOTTypeLib{%%}1.0FLAGS]
@=”0″[HKEY_CLASSES_ROOTTypeLib{%%}1.0HELPDIR]
@=”[TARGETDIR]”
It’s really not that complicated for a single module. The work can be tedious to create all the values for multiple modules in scenarios where you support multiple AutoCAD and/or Bricscad versions or platforms, but these values typically don’t change over the life of the project, so it only needs to be done once. Once you have created the registry values manually, disable all other forms of COM server registration such as wizard-generated runtime registration or automatic “self-registration” at install time. A bonus side effect of the manual registration approach is that a normal uninstall reliably removes all traces of the COM server registration.
Great article! But when you say “unfortunately” with regards to COM registration under non-elevated context, that’s not a bad thing. It’s intentional and offers quite a bit of protection against malware attacks that XP couldn’t defend against. Also, if you are building an application to install on other computers you should package it using Wise or InstallShield, both of which provide tools for registering COM components and .NET assemblies, etc. Neither product is cheap, but they can save you a lot of work in the long run.