Re: Mobile 5 - Debugging Managed C#/Unmanaged C++ Code

Tech-Archive recommends: Fix windows errors by optimizing your registry

You can go one further too. You can set the startup EXE to be VIsual Studio
itself, then load up your managed project there and it gives you the ability
to (alomost) step from managed to native by setting breakpoints at the entry
of your native DLL. A step in the managed instance in Studio across the
P/Invoke call then transfers to the native instance of Studio. That's the
best I've been able to achieve (and it's slow since you have to fire up
studio every time you hit Run).


--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com



"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:OEoVuIWfIHA.2000@xxxxxxxxxxxxxxxxxxxxxxx
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.
Works fine for me, anyway.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:O75snxVfIHA.2000@xxxxxxxxxxxxxxxxxxxxxxx
Do you have the DLL project loaded when you do this? You could drop a
DebugBreak() call in your DLL and see if that will trigger the debugger.

The easiest thing is to debug native code from a native code user and
then you have tested code against which you don't have to debug much; all
bugs, at that point, should be in the real, managed user of the DLL.

Paul T.

<john.e.otten@xxxxxxxxx> wrote in message
news:4a652f24-99f4-4015-b8d3-3dcbf6c976d6@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Paul,
Thanks for your reply.

I did look into Attach to Process to access the DLL code during
debugging. However, the threads that I spawned in the DLL do not
appear in the Thread list on the IDE, so I don't know how I can get a
handle into the code in the DLL. Setting breakpoints in the DLL code
does not work - the IDE states that because the DLL symbols are not
loaded it can't set a breakpoint (I am using a debug version of the
DLL, but perhaps because of the nature of the managed/unmanaged code
it can't tell that the DLL is actually loaded?).

We are less concerned with stepping from the managed to the unmanaged
code than we are being able to step through the unmanaged code
itself. Most of the heavy duty processing will be performed in the
unmanaged code, so we just want to be sure we can get into it during
debugging.

Any other thoughts?

John

On Mar 3, 12:12 pm, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
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.

Paul T.

<john.e.ot...@xxxxxxxxx> wrote in message

news:ecbcb079-b7e8-48d8-81da-9d67757ad571@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



Hi,

We are working on an application that is targeting a PDA that runs
Windows Mobile 5.0. Our development environment is Visual Studio 2005
with the appropriate plugins.

Currently, the GUI is being built with C# managed code using the VS
2005 GUI builder. The main processing of the code is planned to be
contained in a static DLL written with unmanaged C++. We will use
PInvoke calls to access data in the DLL for display/interaction on the
GUI. We decided upon this as it does not appear that we can use
managed C++ in the Windows Mobile 5 platform, and the only way to use
C
++ for the GUI in the Mobile environment is to use the Windows API
calls (which means development would take longer, and perhaps be less
robust).

I wrote some simple functions on the C++ side to verify that the
concept would work with the current version of the GUI, and it did.
However, now that we are trying to do full up development we realize
that we will need to use the debugger on the unmanaged C++ side.

I poked around on the internet and found some references that state
you should set your debugging state to "Both" in the C++ unmanaged
project so that debugging would work with both managed and unmanaged
code. However, that option does not appear in our DLL project -
instead only "Smart Device Native Debugger" appears as a choice.
Also, the MSDN pages discuss an option in the C# project settings
under the debug tab that allows you to "Enable unmanaged code
debugging." That checkbox does not appear in our C# project either.

My concern is that such settings (like some others) do not exist in
the Windows Mobile paradigm. If they do exist, how can I access
them? If they do not exist, does anyone have any suggestions on how
to proceed?

We do not have any experience programming in C# (hence the desire for
a C++ unmanaged DLL) and although we would like to learn, we do have
to keep our project deadline in mind. If it is the most expedient way
to do it, we can possibly bite the bullet (but I'll have to find some
way to appease the project manager for the additional time it may
take).

My only other thought is (assuming that the settings do not exist in
the Mobile environment) that we attempt to do the managed/unmanaged
development outside of the Mobile environment and then port it to
Windows Mobile 5 after it is completed. This is not a very attractive
solution either. Has anyone done anything similar to this?

Any comments or suggestions would be greatly appreciated!

Thanks,
John- Hide quoted text -

- Show quoted text -






.

Relevant Pages

  • Re: Mobile 5 - Debugging Managed C#/Unmanaged C++ Code
    ... 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, ... managed C++ in the Windows Mobile 5 platform, and the only way to use C ... way to appease the project manager for the additional time it may ...
    (microsoft.public.windowsce.app.development)
  • Re: Mobile 5 - Debugging Managed C#/Unmanaged C++ Code
    ... of your native DLL. ... set the debugging options to start the managed code EXE that ... managed C++ in the Windows Mobile 5 platform, and the only way to use ... way to appease the project manager for the additional time it may ...
    (microsoft.public.windowsce.app.development)
  • Re: Mobile 5 - Debugging Managed C#/Unmanaged C++ Code
    ... of your native DLL. ... set the debugging options to start the managed code EXE ... managed C++ in the Windows Mobile 5 platform, ... way to appease the project manager for the additional time it may ...
    (microsoft.public.windowsce.app.development)
  • Re: Memory Management
    ... include the memory manager after any files that declare malloc etc. I'm not ... I have tried to export the operators from a DLL, ... I'm still using the CRT's malloc and free to allocate memory. ...
    (microsoft.public.vc.language)
  • Re: Mobile 5 - Debugging Managed C#/Unmanaged C++ Code
    ... If it comes in as an int*, I *think* (I'd have to fire up a native session ... of your native DLL. ... set the debugging options to start the managed code EXE ... way to appease the project manager for the additional time it may ...
    (microsoft.public.windowsce.app.development)