1

I have a VB6 DLL that's been working fine for many years and many versions. It is used from an Excel add-in.

To make it compatible with 64-bit Excel, I want to convert it to a VB6 ActiveX EXE. I did so, but now when I try to instantiate it from the client (same version of Excel; 2016), I get an error. This is the error the client returns:

Automation error

The specified module could not be found.

My understanding is that the ActiveX EXE should have been automatically registered when it was compiled, but I also tried registering it by double-clicking it to run it, and also by manually registering it with regserver. But I still get the same error.

In the client, here's the line I run to instantiate the VB6 ActiveX EXE; this is exactly the same as how it successfully instantiated it when it was a VB6 DLL:

Dim abc As Object

Set abc = CreateObject("ABC.cls_abc")

The class module's Instancing is set to MultiUse, and Persistable is set to NotPersistable.

I searched regedit for ABC.exe, and it was there.

Any suggestions?

UPDATE:

I tried changing the ActiveX EXE's project name and class name, and it worked.

I changed the project name from ABC to ABC64, and I changed the class name from cls_abc to cls_abc64.

Then from Excel I instantiated it like this:

Set abc = CreateObject("ABC64.cls_abc64")

I tried changing it back to ABC and cls_abc, and changing it back to an ActiveX DLL. I had deleted the DLL, so I compiled it again. Then I tried instantiating that from Excel with Set abc = CreateObject("ABC.cls_abc"), and that worked fine.

So the project works as an ActiveX EXE if I change the project name and class name, and it works as an ActiveX DLL with the old project name and class name, but doesn't work as an ActiveX EXE with the old project name and class name (I haven't tested changing only one or the other). Does this suggest I have a problem in the registry?

Martijn Pieters
  • 889,049
  • 245
  • 3,507
  • 2,997
Greg Lovern
  • 868
  • 2
  • 18
  • 30
  • You can run your DLL as an exe. https://support.microsoft.com/en-au/help/198891/how-to-run-a-dll-based-com-object-outside-the-sql-server-process – CatCat Sep 23 '18 at 23:08
  • CatCat, I looked at that, but it would mean going through another COM object. Also lots of registry hacks during setup. This is simpler and should run faster too. – Greg Lovern Sep 24 '18 at 01:36
  • Should run at the same speed as any other exe. – CatCat Sep 24 '18 at 07:51
  • 2
    Re the update - doesn't sound like you have a registry problem, per se. You did create conflicts by trying to use the same object names for different com objects. If you were to use the same object names (not recommended), it would probably work if you were to unregister the dll before you compiled or registered the exe. If you have not been compiling your dll with binary compatibility, then you probably need to unregister _all_ previous dlls you've compiled/registered, otherwise you might still have some dll registration info left in the registry. – MarkL Sep 24 '18 at 16:05
  • 1
    Did you unregister the original DLL before compiling the EXE? Possibly since you are using late binding it can figure out which class you really want to instantiate. If it is trying to use the ones from the DLL, and the DLL is now missing - it won't work. – StayOnTarget Sep 25 '18 at 11:34

0 Answers0