views:

1704

answers:

3

I am writing a Windows CE application in C# that references a native C++ DLL (that I am also coding) using the following method:

   [DllImport("CImg_IP_CE.dll")]
   public static unsafe extern void doBlur(byte* imgData, int sigma);

This actually works fine but I am unable to debug the DLL. When I check the debug modules that are loaded after running the EXE, CImg_IP_CE.dll is not one of them. Even after calling functions successfully from the DLL it still does not show up in the modules list.

Upon looking around, it seems that the LoadLibrary() function might work, but I cannot find any examples of using this in a C# Windows CE application. How would I do this or is there a better way to make sure the DLL loads up for debugging?

A: 

If you are able to call the function in the DLL without it throwing an application, you are most likely loading the DLL. You may need to make sure that unmaanged debugging is enabled in your project properties though.

http://stackoverflow.com/questions/765745/unable-to-set-breakpoints-in-c-dll-used-by-c-cli-called-from-c/765754#765754

heavyd
Strange... this seems like the ticket. Although on my debug tab of the project properties, I do not have a "Enable unmanaged code debugging" checkbox. Perhaps because this is a Windows CE project?
Ben McIntosh
+2  A: 

I found the answer through this post:

http://www.eggheadcafe.com/conversation.aspx?messageid=31762078&threadid=31762074

In summary, the same question was asked and the response was:

No, you can't step from managed code through a P/Invoke call into native code in the Smart Device debugger. You might be able to use Attach to Process to do the native debugging (with the native DLL project loaded into that instance of VS2005), or simply write debug information from the native DLL to a serial port or something. This really doesn't come up very often, though, where you actually need to step from one to the other.

Further along in the thread, someone figured out how to accomplish this:

A quick test shows that the easiest way to handle this is to 'run' your DLL. That is, set the debugging options to start the managed code EXE that will use your DLL and set your breakpoints in the DLL (all from the DLL project, of course). Naturally, when the EXE starts, your DLL won't be loaded, so you'll see the breakpoints as hollow circles with ! on them, but, when you call any of the native functions in your DLL, the DLL will be loaded (it's not loaded on startup), and the breakpoints will be set.

So strangely, when you run the C# program and make a call to the native DLL code, it still does not show as loaded in the debug modules window. However, if you set the DLL project as the startup project, and then set the Remote Executable as the EXE file in the Debugging options, now when you first call the DLL, it will load up in the debugger. Okay... whatever works!

Ben McIntosh
+1  A: 

Unfortunately, it seems that WinCE mixed mode debugging is not supported. That is, you can debug your process either as managed (so you can step through and set breakpoints in your C# code), or as native (so you can do the same for native code, including this DLL), but not both at the same time.

To run debugging in native mode on a C# project, you can do this: start application without debugging (Ctrl+F5 or Debug -> Start Without Debugging), then Debug -> Attach to Process, set "Transport" to "Smart Device", select the emulator from the "Qualifier" dropdown, click on "Select" button on the "Attach to" field, and check "Native". You will observe that it won't let you check both at the same time, but if you only need to debug the DLL, it may be sufficient...

Pavel Minaev