debugging a dll

[olhass]

---

@menchar wrote:

6 years later an NI still doesn't understand the issue 😉

---

true...

...these articles do not help me, i know what debugging a DLL means and how to switch and configure build settings/steps...

for better understanding of the problem here an example:

- i implicit link all used DLLs by adding the import libraries to the .prj (not by dynamic call of "LoadLib") because i want to have the symbol defines available before build (maybe this is the critical issue)

- let's assume that i have a low level DLL "submodule.dll" available as sm.lib and sm_dbg.lib

- this DLL is implemented in other DLLs "module_x.dll" which i also can compile as release with m_x.lib and as debug with m_x_dbg.lib where the m_x.lib uses the sm.lib and the m_x_dbg.lib uses the sm_dbg.lib, it is obiously possible to compile each (sub-)module this way

- now i develop an executeable or another dll that uses many "module_x.dlls" (m_1.lib ... m_200.lib)

- as i want to debug into all subprocesses/submodules i need to include each m_x_dbg.lib and exclude each m_x.lib

- every time i want to switch back to release a have to undo that, this is really annoying if the number of used LIBs exceeds 5-10

I can do the way mentioned in the articel with 32/64bit-libs and place the x_dbg.libs into a folder "dbg" (by build options), the libs are locally separated but when debugging the process CVI does not recognize that.

Perhaps there is a trick to use build steps / pre build actions / custom compiler settings / build options ($SOURCE or $MACRO names), e.g. in debug configuration to link all .libs with suffix "_dbg" or from the "dbg" folder?

Maybe also a not so efficient way is to create a "debuggung project" x_dbg.prj with all the m_x_dbg.libs linked and a "release project" x.prj with all the m_x.libs linked...

[menchar]

Good description of the problem.

I got annoyed switching back and forth with just 2 dll's 😉

If they fixed up CVI to allow configuration dependencies between projects they could make it do the switching for you.

There are more than a few subtle issues when creating and using DLL's in CVI.  When it's practical I'll go ahead and use static libraries and link them into multiple projects rather than fight all the DLL headaches - source level reuse at least, if not binary.  We once tried to come up with a scheme to be able to easily switch between a static library and an equivalent DLL using conditional compilation but it was cumbersome.

You can switch an entire solution (workspace) in Visual Studio between debug / release builds of multiple DLL's using a single control in the configuration manager.  But ... NI doesn't have the resources of micro$oft.

[olhass]

I do it now the way it is described in:

http://forums.ni.com/t5/LabWindows-CVI/Good-DLL-Habits-Debug-vs-Release/m-p/485081/highlight/true#M2...

So my pre-build action is to copy over either the .libs or the _dbg.libs from subdirectory "release" or "debug" to the projectdirectory when compiling in release or debug mode. Compiling will last a little bit longer, but i think it's the only practicable way...