Debugging in a mixed development environment

  • Thread starter Thread starter baronics
  • Start date Start date
B

baronics

My Win CE 5.0 app is a combination of C# (using VS .NET 2003) and unmanaged
DLL's in C/C++ (using eMbedded VC 4.0).

I'm using Interop services to make the call from .NET to the unmanaged code.



Using VS.NET, how can I set a breakpoint in a function within one of the DLL's
and step into that code?



I have created a project within VS.NET for my unmanaged DLL and use a batch
file to do the 'make'. I set a breakpoint in my DLL source and when I run,
the breakpoint indicator turns into a question mark and complains:

"The breakpoint will not currently be hit. No symbols have been loaded for
this document."

When running under eVC using a test app, the debug info is available, so I
know it's there.



baronics.
 
No, you can't do that. The VS.NET debugger doesn't know enough about the
content of your eVC++ DLL to do the right things. You should separately
debug your DLL, in my scheme with a native code program and eVC++. When the
DLL is stable, debug the managed application using VS.NET. Alternatively,
you could write some logging code into the DLL and use that to debug what's
going on when it's called from managed code.

Paul T.
 
Thanks Paul.

I found in the PC environment using the full framework, I could set my
unmanaged dll as the startup project and point to my .NET exe as the start
command in the debug option page. This worked fine, but I can see there is
no equivalent in the WinCE environment.
 
No. I think that I tried this within eVC, too, unsuccessfully, but I'm not
sure about that. That would be the only possible way to make it work.

Paul T.
 
And, of course, the credit goes to Alex! I've never tried it, but it's got
to be better than message boxes or debug strings only...

Paul T.

Daniel Moth said:
There is always this crazy way:
http://www.opennetcf.org/Articles/pinvoke-debugging/pidebug.asp

Cheers
Daniel
--
http://www.danielmoth.com/Blog/


Paul G. Tobey said:
No. I think that I tried this within eVC, too, unsuccessfully, but I'm
not sure about that. That would be the only possible way to make it
work.

Paul T.

baronics said:
Thanks Paul.

I found in the PC environment using the full framework, I could set my
unmanaged dll as the startup project and point to my .NET exe as the
start command in the debug option page. This worked fine, but I can see
there is no equivalent in the WinCE environment.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message No, you can't do that. The VS.NET debugger doesn't know enough about
the content of your eVC++ DLL to do the right things. You should
separately debug your DLL, in my scheme with a native code program and
eVC++. When the DLL is stable, debug the managed application using
VS.NET. Alternatively, you could write some logging code into the DLL
and use that to debug what's going on when it's called from managed
code.

Paul T.

"baronics" <baronics at yahoo dot com> wrote in message
My Win CE 5.0 app is a combination of C# (using VS .NET 2003) and
unmanaged DLL's in C/C++ (using eMbedded VC 4.0).

I'm using Interop services to make the call from .NET to the unmanaged
code.



Using VS.NET, how can I set a breakpoint in a function within one of
the DLL's and step into that code?



I have created a project within VS.NET for my unmanaged DLL and use a
batch file to do the 'make'. I set a breakpoint in my DLL source and
when I run, the breakpoint indicator turns into a question mark and
complains:

"The breakpoint will not currently be hit. No symbols have been loaded
for this document."

When running under eVC using a test app, the debug info is available,
so I know it's there.



baronics.
Click to expand...
Click to expand...
Click to expand...
 
I haven't tried it either but of course credit goes to Mr Feinman; I though
the word "crazy" clearly indicated that :-)

Cheers
Daniel
--
http://www.danielmoth.com/Blog/


Paul G. Tobey said:
And, of course, the credit goes to Alex! I've never tried it, but it's
got to be better than message boxes or debug strings only...

Paul T.

Daniel Moth said:
There is always this crazy way:
http://www.opennetcf.org/Articles/pinvoke-debugging/pidebug.asp

Cheers
Daniel
--
http://www.danielmoth.com/Blog/


Paul G. Tobey said:
No. I think that I tried this within eVC, too, unsuccessfully, but I'm
not sure about that. That would be the only possible way to make it
work.

Paul T.

"baronics" <baronics at yahoo dot com> wrote in message
Thanks Paul.

I found in the PC environment using the full framework, I could set my
unmanaged dll as the startup project and point to my .NET exe as the
start command in the debug option page. This worked fine, but I can see
there is no equivalent in the WinCE environment.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT
com> wrote in message No, you can't do that. The VS.NET debugger doesn't know enough about
the content of your eVC++ DLL to do the right things. You should
separately debug your DLL, in my scheme with a native code program and
eVC++. When the DLL is stable, debug the managed application using
VS.NET. Alternatively, you could write some logging code into the DLL
and use that to debug what's going on when it's called from managed
code.

Paul T.

"baronics" <baronics at yahoo dot com> wrote in message
My Win CE 5.0 app is a combination of C# (using VS .NET 2003) and
unmanaged DLL's in C/C++ (using eMbedded VC 4.0).

I'm using Interop services to make the call from .NET to the
unmanaged code.



Using VS.NET, how can I set a breakpoint in a function within one of
the DLL's and step into that code?



I have created a project within VS.NET for my unmanaged DLL and use a
batch file to do the 'make'. I set a breakpoint in my DLL source and
when I run, the breakpoint indicator turns into a question mark and
complains:

"The breakpoint will not currently be hit. No symbols have been
loaded for this document."

When running under eVC using a test app, the debug info is available,
so I know it's there.



baronics.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top