dll registration mistake

[menchar]

I've created DLL's in CVI for use with VB6.  The VB6 developers, not being particularly sophisticated (now there's an understatement) wrongly thried to register the DLL's by double-clicking on the .dll file and causing the Win32 registration server to attempt to register these non-registerable DLL's.   So now we have a mess.  The registration server of course can't un-register these because they're not set up to work as registered objects.

When they go to use the functions in the DLL's, they add the DLL's as references (I included a type library in the DLL's).

But, the DLL functions aren't directly accessible - they have to prepend the DLL name in front of the function name to get the call to compile.  So they wind up invoking the functions like this:

DLL Name.function name (params)  in one case, and even more bizarrely,

DLLName.DLLName.Function (parameters) in another.  If the DLL name isn't prepended to the function then at compile time an error pops up indicating that VB6 was expecting a variable or function name instead of a project name.

Does anyone know how we can get out of this nightmare?  I believe in the past I saw a developer go in and hack the registry to clear out the false "registration" but I'm not sure where he did it.

Thanks

[Makoto]

I think you have created a legacy function-based (non-COM) DLL by using CVI. Nobody can register/unregister the DLL using REGSVR32.EXE unless DllRegisterServer() and DllUnregisterServer() functions are being exported.

By importing (referencing) the embedded type library from VB6 environment, VB6 now has the syntax info of the DLL (instead of having DLL's VB declaration file).  But when runtime, the DLL must be placed in a directory where the PATH environment points, or the same directory as the compiled EXE. This is very big different point than COM DLL, which can be placed anywhere, because its full-path name is embedded in the registry.