Hello everyone!
I just started using the Managed C++ (Windows7/32 bit, Visual Studio 2012). My task was to rewrite a dll to make it dotNet-based, but still callable from my legacy C++/MFC application. In order to learn the technique, I created a simple sample project, which exports a single function.
The library code complies and builds. The problem is that when I am trying to step into it while debugging my MFC client, it does not do it... simply jumps over as if the dll does not have debugging info - but in fact it calls the library code because I
can see the traces in the output window.
Later on I succeeded in reaching my goal, but in a "indirect" way: despite both my projects: C++/MFC client application and Managed C++ DLL are built with a "Mixed" Debugger Type and have /ASSEMBLYDEBUG linker option
set, the only way to make the DLL code debuggable is to declare it a startup project, specify the executable as a parameter in the Configuration Command field, and run this way. As soon as I switch back to (what seems more natural, and what I got used to so
far) having an executable project declared a startup - boom! - it is impossible to set a breakpoint inside the DLL code. I built a small sample application (see
https://onedrive.live.com/redir?resid=AEEF48EEDC304E60!132&authkey=!ADRYzXWJWo6DRHk&ithint=file%2c.zip). All specific stuff has been removed from it so that it could be built anywhere. There are two pre-set breakpoints in the code: in the MSTestDlg.cpp
file (line 180) - before calling the DLL-provided Fit() function, and in the C1.cpp (line 109) - inside the DLL. Like I said before, as soon as the startup project is C1 (DLL) both breakpoints get hit. As soon as the MSTest (exe) project becomes startup
- only the first one - but the dll gets called as one can see from the traces left. What am I missing? Thank you in advance. Mike
Mike Faynberg