Wednesday, November 29, 2006

vs.net cross language debugging

the attached image shows a solution with an unmanaged C++ wrapper (for a C++ .lib) and a C# application project.

whilst debugging, you can cross the language barrier and debug into both projects. in the attached screen, a breakpoint in C++ is being hit, but the application running is the C# app. cool hey!


- C++ breakpoint hit while debugging C# project

of course, this is all old news, the actual reason for this post is debugging issues with this sort of debugging.

the most common error is: "The breakpoint will not currently be hit. No symbols have been loaded for this document".

first steps from a newsgroup post:

1. Verify that you are in debug mode and not release mode.
2. Verify that the timestamp of the .pdb file is the same as the .dll or .exe that you're generating. If they are not, remove all of the binaries
and recompile your entire solution.
3. If the additional assemblies you are trying to debug are not part of your solution (i.e. other projects), go under the properties for the solution and be sure to include the "Debug Source Files" and "Debug Symbol Files" locations of the additional assemblies you're trying to debug.

despite all of this, when I started debugging, everything worked fine in the C# code, but the breakpoints in the CPP files show "No symbols have been loaded for this document." When I look at the modules, the status for the CPP DLL is "Symbols loaded." but there is an exclamation mark and the error "The module did not load at the default load address."

I was running in debug mode for both projects. I tried rebooting. I tried deleting all the debug files and rebuilding. and I also tried the steps in this help doc: How to: Debug in Mixed Mode.
this included adding /ASSEMBLYDEBUG to the native DLL project - I also tried w/out this statement.

I tried changing the debug build dir for the C++ project to be the debug dir of the C# project, but that didn't help.

it turned out that my issue was with my function import. I had the wrong entry point specified, so the code wasn't being called properly. why this problem manifested as it did, I don't know. I get the same behaviour as before (e.g. the breakpoints are still inactive at first), but when the debugger gets to the CPP files with breakpoints, they work.

the rest is from the article: How to: Debug in Mixed Mode

"The following procedures describe how to debug both managed and native code, also known as mixed-mode debugging. There are two scenarios for doing so, depending on whether the DLL or the application is written in native code:

The calling application that calls your DLL is written in native code. In this case your DLL is managed, and both managed and native debuggers must be enabled to debug both. You can check this in the Property Pages dialog box. How you do this depends on whether you start debugging from the DLL project or the calling application project.

The calling application that calls your DLL is written in managed code and your DLL is written in native code.

Note
The dialog boxes and menu commands you see might differ from those described in Help depending on your active settings or edition. To change your settings, choose Import and Export Settings on the Tools menu. For more information, see Visual Studio Settings.

To enable mixed-mode debugging in a native EXE calling a managed DLL
In Solution Explorer, select the project. On the View menu, click Property Pages. In the Property Pages dialog box, expand the Configuration Properties node, and then select Debugging. Set Debugger Type to Mixed or Auto.

To enable mixed-mode debugging in a managed EXE calling a native DLL
In Solution Explorer, select the project. On the View menu, click Property Pages. In the Properties Pages, click the Debug tab. Under the Enable Debuggers group, select the Enable unmanaged code debugging check box.

Note
For the debugger to attach to code written in C++, the code needs to emit DebuggableAttribute. You can add this to your code automatically by linking with the /ASSEMBLYDEBUG (Add DebuggableAttribute) linker option."

Monday, November 27, 2006

st john water polo

this weekend, I played in a water polo tournament in st john, new brunswick. I play for dalhousie university (in halifax, nova scotia); we were playing against teams from st john and tracadie.


- a nice offensive foul in the hole


- yes, it's a rough game :)

truly canadian road sign

this sign is in fredericton, new brunswick. it must be the most canadian sign on the planet.



- no left turn to tims

Wednesday, November 22, 2006

Fatal error cannot open LIBC

When migrating Visual Studio projects from VS 2003 to VS 2005, I encountered the error:
Fatal error cannot open "LIBC".

I thought I'd post the solution to make it easier for others to find.

To remove the error, navigate to Configuration Properties -> Linker -> Input. Then, add "libc" or "lib.lib" under Ignore specific library. In earlier versions of VS it was set to libc.lib.

I found the reference on this page about migration issues: Migrating to Visual Studio 2005

Wednesday, November 15, 2006

quick update

wow, how time flies. I haven't written anything here in ages. the reason for this is simple. I'm working hard on the augmented reality book for pragmatic, and I have also started on a new project that will be announced soon.