help: how to integrate third party lib to my MFC Extension DLL.
-
lyjqhjcplusplus wrote:
Any suggestion will be highly appreciated.
I suggest you post the error information because "it failed" probably does not allow people to have a clue what the problem is. If you are looking for a higher level analysis, there is about a 99.9999999% chance you did something wrong.
led mike
Thanks. I just post detailed info in the thread above. I also think something I did was wrong, and would appreciate if anyone can guide me to identify it. Thanks Developer
-
Thanks Roger. The "ERR, hr" shows "The specified module could not be found." as you suggested. Below is the Output message: 'Wrapper.exe': Loaded 'C:\Data\Feb252008\New_Agent\EXT\DLL\Wrapper.exe', Symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\user32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_c8452471\mfc80ud.dll', Symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c\msvcr80d.dll', Symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\secur32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\oleaut32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\ole32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\imm32.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFCLOC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_91481303\mfc80ENU.dll', Binary was not built with debug information. 'Wrapper.exe': Loaded 'C:\Data\Feb252008\New_Agent\EXT\DLL\RemoteInventoryD.DLL', Symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\version.dll', No symbols loaded. 'Wrapper.exe': Loaded 'C:\WINDOWS\system32\netapi32.dll', No symbols loaded. 'Wrapper.exe': Unloaded 'C:\Data\Feb252008\New_Agent\EXT\DLL\EXT.DLL' 'Wrapper.exe': Unloaded 'C:\WINDOWS\system32\netapi32.dll' 'Wrapper.exe': Unloaded 'C:\WINDOWS\system32\version.dll' My guess is somehow, it unloaded DLL, as 'Wrapper.exe': Unloaded 'C:\Data\Feb252008\New_Agent\EXT\DLL\EXT.DLL'. If I took out the following line: FileHandle = ConvertFile( filename ) from EXT.DLL, Then everything is fine. @ERR, hr return S_OK and below is the Output: 'Wrapper.exe': Loaded 'C:\Data\Feb252008\New_Agent\EXT\DLL\Wrapper.exe', Symbol
If the error description says "The specified module could not be found.", what do you think could be the error? Your library could not be located when the system tried to find it. You may have neglected to copy the library to the directory where you start your application from, if you haven't tried to copy it to some system directory that is included in the DLL search. I suggest that you have a look at Dynamic-link Library Search Order[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
If the error description says "The specified module could not be found.", what do you think could be the error? Your library could not be located when the system tried to find it. You may have neglected to copy the library to the directory where you start your application from, if you haven't tried to copy it to some system directory that is included in the DLL search. I suggest that you have a look at Dynamic-link Library Search Order[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownAs I mentioned in previous email, it makes difference that when I make the 3rd party's method call. So my guess is that something cause the conflict. Otherwise, how to explain the behavior? If the library could not be located, then it should be consistent with or without making 3rd party's call. Am I on the right track?
-
As I mentioned in previous email, it makes difference that when I make the 3rd party's method call. So my guess is that something cause the conflict. Otherwise, how to explain the behavior? If the library could not be located, then it should be consistent with or without making 3rd party's call. Am I on the right track?
-
As I mentioned in previous email, it makes difference that when I make the 3rd party's method call. So my guess is that something cause the conflict. Otherwise, how to explain the behavior? If the library could not be located, then it should be consistent with or without making 3rd party's call. Am I on the right track?
You need to put in the reverse gear.... You have in fact a well-known error when it comes to dynamic link libraries: the file can not be found when your application is trying to load it. How exactly are you linking with your DLL? You are talking about a "Tool.lib" file which you have no use of unless you are doing implicit linking, i.e. the library is loaded when the application starts. But at the same time you're talking about
::LoadLibrary(), which is used when you're doing explicit linking, i.e. loading the DLL at runtime. This suggests that you've mixed the two ways. Are you somewhere calling::GetProcAddress()to get the address ofmyTool()? If you are not and the code builds successfully, you are using implicit linking and you can remove the call to::LoadLibrary(). The library will be loaded when you application starts and if the library cannot be found the application won't start. You need to read this[^]."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
lyjqhjcplusplus wrote:
Am I on the right track?
I don't know what your post means but you are not on the right track if you are disagreeing with Roger.
led mike
led mike wrote:
you are not on the right track if you are disagreeing with Roger
:laugh: How am I supposed to interpret that? I'm always right? ;)
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
lyjqhjcplusplus wrote:
Am I on the right track?
I don't know what your post means but you are not on the right track if you are disagreeing with Roger.
led mike
Well, I am not disagreeing with Roger. Instead, I am asking why the library can not be found? Roger suggest that the path was not included. But why making a third party call is causing such a difference?
-
Well, I am not disagreeing with Roger. Instead, I am asking why the library can not be found? Roger suggest that the path was not included. But why making a third party call is causing such a difference?
-
You need to put in the reverse gear.... You have in fact a well-known error when it comes to dynamic link libraries: the file can not be found when your application is trying to load it. How exactly are you linking with your DLL? You are talking about a "Tool.lib" file which you have no use of unless you are doing implicit linking, i.e. the library is loaded when the application starts. But at the same time you're talking about
::LoadLibrary(), which is used when you're doing explicit linking, i.e. loading the DLL at runtime. This suggests that you've mixed the two ways. Are you somewhere calling::GetProcAddress()to get the address ofmyTool()? If you are not and the code builds successfully, you are using implicit linking and you can remove the call to::LoadLibrary(). The library will be loaded when you application starts and if the library cannot be found the application won't start. You need to read this[^]."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownThanks Roger, Your comments are very helpful. To explain better, here is how I linked DLL. My application wrapper.exe, dynamically linked to library EXT.DLL, by calling LoadLibrary(). If this is it, everything works fine. Another 3rd party, provided a implicit linking library, tool.lib. so I modified code, regenerated EXT.DLL as below: 1) Link the tool.lib by modify the Project Configuration - Linker Input 2) Include the header file tool.h 3) Add one line in my EXT.DLL source code, which call the funtion exported in tool.lib. Everything else remains the same. But it is not loading EXT.DLL in my application wrapper.exe. I know it sounds complicated, but it is the problem that I am facing. Thank you in advance for your help.
-
Hi experts: I have a MFC Extension DLL module, say EXT.DLL, and I have Wrapper.exe which do LoadLibrary(TEXT("EXT.DLL")); So far everything is working. However, a couple days ago, I started to integrate a third party library, Tool.lib, which export a method called myTool(char *). My first step was, wrote a program, test.exe, which links Tool.lib, include Tool.h header file and call myTool(...) in test.exe, it works fine, I got what I want. Then I did the same thing to EXT.DLL, link the Tool.lib, include Too.h and call myTool(...). It compiled EXE.DLL successfully. However, it failed in Wrapper.exe at LoadLibrary(TEXT("EXT.DLL")); Any suggestion will be highly appreciated. Thanks Software Developer.
Hi, Copy Tool.lib to your current working directory and then try to run the application.
-
Hi, Copy Tool.lib to your current working directory and then try to run the application.
Hungry Developer wrote:
Copy Tool.lib to your current working directory
The .lib file is only used during the linking process if the DLL is implicitly linked to the application, which means that it won't make any difference where it's located once the application is built.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Thanks Roger, Your comments are very helpful. To explain better, here is how I linked DLL. My application wrapper.exe, dynamically linked to library EXT.DLL, by calling LoadLibrary(). If this is it, everything works fine. Another 3rd party, provided a implicit linking library, tool.lib. so I modified code, regenerated EXT.DLL as below: 1) Link the tool.lib by modify the Project Configuration - Linker Input 2) Include the header file tool.h 3) Add one line in my EXT.DLL source code, which call the funtion exported in tool.lib. Everything else remains the same. But it is not loading EXT.DLL in my application wrapper.exe. I know it sounds complicated, but it is the problem that I am facing. Thank you in advance for your help.
lyjqhjcplusplus wrote:
Another 3rd party, provided a implicit linking library, tool.lib. so I modified code, regenerated EXT.DLL as below: 1) Link the tool.lib by modify the Project Configuration - Linker Input 2) Include the header file tool.h 3) Add one line in my EXT.DLL source code, which call the funtion exported in tool.lib.
This is how I interpret what you've said so far: You are implicitly linking the "Tool" library with your "Ext" library, but it seems like you are explicitly linking your "Ext" library to your application. When you're trying to load your "Ext.dll" with
::LoadLibrary(), it fails to load since the "Tool.dll" cannot be found. Forget about the Tool.lib file, it's not used after the "Ext.dll" has been successfully built. You have to read the documentation I linked to earlier, otherwise it serves no point in trying to help you. If you would have bothered to read it, you should have solved this by now."It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown