Watching proxy objects in the debugger?

[Hani Atassi]

If the class is derived from ContextBoundObject or MarshalByRefObject, the debugger cannot view the members of the object remotly or even inside the same Application domain.

The debugger displays the following message in the watch window:
error: cannot evaluate field of a proxy object

Debug.WriteLine(proxyObj.Id) works fine but the Watch window doesn't work.

Is there anyway to let the debugger watch the members of the proxy object?

Thanks,

[[MSFT]]

Hello,

When you see the error "cannot evaluate field of a proxy object', it means
the object is not running in current process. For example, a
MarshalByRefObject object may be hosted in IIS. You need attach the debuger
to the particualr process.

Hope this help,

Luke
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Hani Atassi]

Thanks Luke,

I think you are right in the case my class in inherited from MarshalByRefObject, but my class is inherited from ContextBoundObject.

I did a console test application, and even inside the same application, I cannot watch the properties of the object.

Any help in this case?

Thanks,

[[MSFT]]

hello,

Is your ContextBoundObject object run in COM+? can you give some simple
code to tell me how you define the object and how your call it in the
console test application?

Thanks,

[Hani Atassi]

Hi Luke,

It's hosted inside NTService and exposed via .NET Remoting.
In my client I tried to attach the process of the NTService that hosts my object but that didn't help.
Also, as I told you, it won't even work inside the same application domain.. My very simple example was to create a console App and create a System.ContextBoundObject class in it like the following:

>>>> Main:
[STAThread]
static void Main(string[] args)
{
Class2 c = new Class2();
c.Id = 10;
Debug.WriteLine(c.Id); // This works. But watching c.Id didn't work.
}

>>>> My ContextBoundObject:

public class Class2 : System.ContextBoundObject
{
int _id = 0;

public int Id
{
get
{
return _id;
}
set
{
_id = value;
}
}
}

In my previous example, I didn't cross any application domains. Probably, I just crosed a context domain.

Regards,

[[MSFT]]

Hi Hani,

Is the breakpoints set in client code? The Server object is run in NT
Service process. If we debug the client code, we cannot get its detail
information.

For server side, if you register the server object with:

RemotingConfiguration.RegisterWellKnownServiceType

We don't have a reference to the object, so it also impossible to check the
object.

What I had used to debug such a remoting object:

1. I have three project in one solution: ServerObjectLibrary, a console
project which register the remoting server object, and a client project.
2. I set break points in ServerObjectLibrary and set console project as
startup project.
3. Start the console project in debug mode
4. Launch the client application out of vs.net to call the remoting object.

Hope this help,

[Hani Atassi]

Luke,

The problem is not debugging the code or stopping inside the service or the client.. i CANNOT watch member variables of any object derived from ContextBoundObject even inside the same application domain of the hosting service or from the clietn..

Even without using Remoting like the sample application I posted in my previous reply.. It's really annoying.. Take a look at the screen snapshot here: http://people.msoe.edu/~atassim/vs_watch_proplem.GIF
Class2 is created inside the same application of Main and even that I cannot watch its members..

I wonder if this is a bug...! I searched the whole net and couldn't find any solution for this... Any help?

Thanks,

[[MSFT]]

ContextBoundObject indeed has such a problem. The work around is as I
mentioned in previous message, set a break point in class library project
to get its internal values. The debugger window cannot retrieve its value.

[Hani Atassi]

Hi Luke,

> ContextBoundObject indeed has such a problem. The work around is as I
> mentioned in previous message, set a break point in class library project
> to get its internal values. The debugger window cannot retrieve its value.
>

So you mean is to break inside the remoting class it self inorder to watch the members. This could do it, but still annoying. And I found wierd behavior of watching member variables of a ContextBoundObject. I think they are evaluated as a pointer value instead of the value itself.. Look at the following two snapshots:

1- (_id) should equal 10 but it says that it's 77994744
http://people.msoe.edu/~atassim/vs_watch_proplem2.GIF

2- (Id) shows the correct value of 10
http://people.msoe.edu/~atassim/vs_watch_proplem3.GIF

Do you have anyidea if the ContextBoundObject problem is fixed in Visual Studio 2005?

Thanks,
Hani

[[MSFT]]

Hi Hani,

The behavior of ContextBoundObject ( sometimes indeed wierd from our view)
comes from its low level implement. I cannot guarantee this will be changed
in VS.NET 2005. There are still many things not settled in this version.

Luke

[[MSFT]]

Hi Hani,

Thank you for the reply. I think it is the best solution we can use so far.
Hope this can be improve in next version.

Luke