How to view native C++ data in mixed managed/native application

How to view native C++ data in mixed managed/native application

Post by Jahye » Sun, 11 Aug 2002 11:57:45



I'm debugging a managed app and want to look at some native data e.g. a
pointer value.  It seems that the de* uses the managed expression
evaluator even if I'm looking at a native C++ object.  Rather than resorting
to writing to the debug output stream, is there any way to use the native
expression evaluator in a managed program (that contains unmanaged code)?
 
 
 

How to view native C++ data in mixed managed/native application

Post by Min Kwan Park[MSFT » Tue, 13 Aug 2002 14:29:44


If you are debugging your mixed code in InterOp mode(Native + CLR), you may
have a way to do your work.
Based on your post, I think that your mixed code has native method and
managed method.
if so, when de* breaks, set the current stack frame with Native frame,
at this point, you use Native Expression Evaluator. so you can do Native
Expression evaluation.
I wish that it help you.

thanks
Min

--
This posting is provided "AS IS" with no warranties, and
confers no rights.

Quote:> I'm debugging a managed app and want to look at some native data e.g. a
> pointer value.  It seems that the de* uses the managed expression
> evaluator even if I'm looking at a native C++ object.  Rather than
resorting
> to writing to the debug output stream, is there any way to use the native
> expression evaluator in a managed program (that contains unmanaged code)?


 
 
 

1. Native C++ to managed COM+: DCOM or .NET remoting?

Hi,
As a beginner in using .NET and enterprise services I am faced with a basic
question:

What is the best way for a legacy unmanaged C++ application to acces remote
managed .NET COM+ components: is it DCOM or the new .NET remoting? To me it
seems that DCOM would be more appropriate for the following reasons:

1. It's the natural way for unmanaged code to access remote COM+
components - managed or unmanaged.
2. It doesn't require extra-programming effort on the client side: to supply
.NET remoting to the unmanaged client you have to provide a managed in-proc
COM component acting as a high-level "proxy" that the client would call
into.
3. It most likely introduces some extra-marshaling. Although I lack the
details my feeling is that a direct DCOM call into the remote component
would handle marshaling of arguments+return values more efficiently than a
call into a managed in-proc COM component followed by a .NET remoting call.

Can anybody contradict either of 1., 2., 3. or bring an argument for one way
or the other. What is the best way indeed?

Thanks a lot,

___
Gabriel Musatescu
McKesson Information Solutions

2. W2000 reboots the computer

3. Calling native C from managed C++

4. ATM 3.0 on NT4 does seem to run

5. Managed & Native Graphics

6. "Required Permissions cannot be acquired" Error

7. StringBuilder in native call to managed COM server

8. Can sendmail block based on connecting port? Unresolvable IP Address?

9. SQLXML Managed not .net native?

10. Debugging native DLL in VS.NET managed solution throws...

11. Using native buffers in managed code?

12. .NET advantages over native C++

13. communication between native c++ thread in dll and c#