aabramovich
aabramovich

Reputation: 209

C++ Linking and COM Registration issue

I've added a new library to my application (multiple projects-DLLs) - SQLite, to perform some in memory caching. There is just one library/project that is affected by this change - Lib1.

A build goes through fine. All libraries are built successfully and no errors are reported, including a couple of Com Objects.

If I try to register the com objects, I get the The DLL could not be loaded. Check to make sure all required application runtime files and other dependent DLLs are available in the component DLL's directory or the system path. message. But all the libs are at the same place. And all are in the path. A copy of this project builds and registers fine (without the few changes made for SqlLite ofcourse). Dependency walker reports no issues

Oddly, if I try to register the DLL of the com object (using regsvr32) it works fine. Also, I have another library, which is dependant on Lib1 (not on SqlLite) which also cannot be loaded.

Any ideas?

Thanks, A'z

Upvotes: 2

Views: 1525

Answers (4)

Jewel S
Jewel S

Reputation:

hmm... as Christian asks, how else are you attempting to register the objects if regsvr32.exe succeeds?

the rundll32.exe advice is also good. have you tried stepping through DllRegisterServer in a debugger to see precisely when it's failing? this sounds like a potential runtime failure if depends.exe isn't revealing anything.

btw, when i google for that exact error text i see: http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/402c1767-cf1d-42f0-aec9-e0169dbf1083/, but I assume you've probably already done this search and found it not helpful :)

Upvotes: 0

Cristian Adam
Cristian Adam

Reputation: 4834

You can use Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) set to filter process name regsvr32.exe in order to see all file and registry access.

Always use full path to your-com-dll when you issue regsvr32 commands, if you have the same dll somewhere else in path (for example c:\windows\system32) regsvr32 will use the other dll and not the one in your current directory.

Another trick would be to use "rundll32 your-com-dll,DllRegisterServer". In case of missing dlls it will tell which dll is missing instead of just saying that LoadLibrary failed.

Edit: What do you mean by "If I try to register the com objects"? How are you doing this? I'm asking because you say that regsvr32 on the dll which actually implements these com object works fine.

Upvotes: 1

aabramovich
aabramovich

Reputation: 209

And so, the plot thickens!!!!

I've actually narrowed down the to the line of code that causes this linking problem. In the modified library (LIB1) I've added a new class A1 which inherits from an existing class A. When I change an existing class B which used to inherit from A to now inherit from A1 - this is when the problem is caused. Class B is in a lib3.

I've verified that just when I change the inheritance, only then the problem occurs!!!

I've used file-mon on regsvr32 when loading successfully and when failing. I stuggle to find the difference! Tomorrow morning I'll try Process Monitor and see if it helps.

Still desperate for help, A'z

Upvotes: 0

1800 INFORMATION
1800 INFORMATION

Reputation: 135295

Use the dependency walker tool to figure out what other dlls the COM server relies on. Then check the executable paths that is set in Visual Studio (Tools -> Options -> Projects -> Directories (I think)). Note that VS does not use the system PATH environment variable - it uses what is set in the options page so if the path to the dependencies is not listed there, the registration would fail, even though if you used regsvr32 from the command line it would succeed.

Upvotes: 0

Related Questions