• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 284
  • Last Modified:

Debug Setting for DLL is not enough for Debug version of DLL to run?

Hello experts,

I am writing a DLL on a VC 7.1. I have compiled the project using the debug settings. In the debug setting, I renamed the output DLL to say MyDLL_Debug.DLL and the debug lib to say MyLib_Debug.lib. In the release versions, I left the names without _Debug.
When I link my exe with this dll, and I am in debug mode, I use debug version of the lib. Shouln't that tell the exe to use the debug version of my dll? I though so, but it seems I am wrong. Even though I am linking against the debug version of the lib, it appears that I link to release version of the DLL. Actually, it links to the DLL that has the same name as a project. If that name is for debug dll, then it will link with that debug dll. Otherwise, it seems to link with release. I though that by generating a debug lib, the lib will let the exe know what DLL name to call. But, it will NOT link to anything that does not match the project name of the DLL.

Any thoughts?

Thanks,
Mactep
0
mactep13
Asked:
mactep13
  • 5
  • 4
1 Solution
 
rcarlanCommented:
The LIB file corresponding to a DLL stores internally the DLL's filename. At runtime, the EXE that has linked to the dynamic LIB will load the DLL having the corresponding filename. If you rename the DLL after the build process has finished, your EXE will not load it. If your EXE finds in the search path a DLL with the same name as the one stored in the LIB it will load it (whether it's debug or release), if not you'll get an ugly message box from the O/S.

You have two options:

1. Generate the DLL directly with the desired name - i.e. instead of renaming it to MyDLL_Debug.DLL after the build has finished. You can do this from the Project Properties | Linker | General | Output file.

2. Load the DLL manually in your EXE (i.e. LoadLibrary).

Radu
0
 
nonubikCommented:
> Even though I am linking against the debug version of the lib, it appears that I link to release version of the DLL.
Check your exe with depends.exe to see what dll is he liking against with.
Maybe in the Debug folder you have both dlls, the original and the renamed one. Try a Rebuild on your debug version of the project.
0
 
mactep13Author Commented:
I do not rename the DLL after the build. I have set the name in the project settings.
The dll is placed in the DLL folder outside of the project. Yes, there is a Release version of the DLL in that folder as well, however, the names are different.
Using LoadLibrary is inconvinient. It would be easier to link to it statically.
What else can be wrong?
0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
mactep13Author Commented:
Well, after a few head scratches, I have figured out that if the *.def file has the LIBRARY "DLLName", that's the name the *.exp file will have as a /OUT: directive and that is the name of the DLL that exe will use. OK, so that's simple enough, but How do I tell the def file to use "MyDLL_Debug" when in debug and "MyDLL" when in release mode. Standard #ifdefs do not work on def files.

Any thoughts?

Thanks,
Mactep
0
 
rcarlanCommented:
I didn't realise you had a .DEF file in your DLL project. Unless you export things manually through the DEF (e.g. use aliases or numerals), you don't really need it. Just remove it from the project, delete (or rename) the file, re-build your DLL and everything should be fine.

If you really do need/want a DEF in your DLL project, you can create two copies of it (debug and release), with different names (or in different locations) and use different module names in them (matching your DLL file name). Then, you can configure the debug build to use one DEF and the release build to use the other. The downside is that you will have to maintain two DEF files.

Radu
0
 
mactep13Author Commented:
Agreed.
However, I strictly remember reading somewhere in MSDN that the def file is needed for the .exp and .lib to be created. I don't remember which version of the compiler this was with, it was a while ago. Granted, my def file is as naked as the women in my fantasies, but it does have one directive --> LIBRARY "MyDLLName"
If what you're saying is true, then how will the export file know what the name of my library is? Perhaps some linker switches??? I already indicated the name of the lib and DLL in the settings. I suppose that will do?

I'll give it a try in the morning.
Mactep
0
 
rcarlanCommented:
I have DEF-less DLLs and they link and work without problems. The VS linker documentation states that the presence of a DEF will force a .LIB and .EXP to be generated even if there are no exports in the output file (i.e. in the DLL). It doesn't explicitly say what happens if there is no DEF, but I assume that LIB and EXP get generated if there are exports - i.e. __declspec(dllexport)), otherwise not. I certainly get a LIB and EXP for my DLLs even without a DEF.

I assume that in the absence of a DEF the linker uses the DLL output filename as a module name. The VC linker switch for specifying the DLL output filename is /OUT. You can also override the LIB filename with /IMPLIB, though if you specify the /OUT switch, the default LIB name is probably suitable (based on the DLL name with the .lib extension). You can also specify the output filename from the compiler: /Fe

Radu
0
 
mactep13Author Commented:
I am using an MFC extension DLL, hence I only have AFX_EXT_CLASS macros. I do believe they translate into declspec down the road. I assume there should be no problem here with AFX_EXT_XLASS and no def file?

Thanks,

Mactep
0
 
rcarlanCommented:
Mactep,

AFX_EXT_CLASS resolves to __declspec(dllexport) in an MFC extension DLL and to __declspec(dllimport) in an MFC executable.
This is probably enough for your purposes, and it should definitely enable you to ditch the DEF.

However, in larger projects, where you have DLLs linking to DLLs, the AFX_EXT_CLASS may prove to be limiting. At that point you may decide to roll your own import/export macros (one per DLL).

Radu
0
 
mactep13Author Commented:
Radu,

Thanks for all your help.
I didnot realize this is that simple. It's been bugging me for quite some time.

Thanks again,

Mactep
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now