Robert Bouillon
9/13/2004 9:31:00 PM
I'm using a local dll that believes itself to be remote, because it's a
context-bound object. It's still within my current application domain. In
other words, I'm already attached to it. I can only step into it, however,
if I set a breakpoint within the code of the remoted object.
Here's an illustration (Not real code, note tested):
01] class MyRemotedObject : ContextBoundObject
02] {
03] {...}
04] public void DoSomething()
05] {
06] throw new Exception("Something bad");
07] }
08] {...}
09]}
10]
11]MyRemotedObject m = new MyRemotedObject();
12]m.DoSomething();
When calling DoSomething, my code breaks at line 12, and I can't step deeper
into the call stack. VS is aware that it's a deeper call, though, because I
can view the procy call in the call stack window if I select "Show Non-User
Code". If I set a breakpoint within DoSomething though, I can step around in
it, I just can't view the values of the local members.
Can I get VSS to step into the ContextboundObject for me and break there
instead somehow?
--ROBERT
"Robert Bouillon" <djwhizzard@hotmail.com> wrote in message
news:eM4jY1FmEHA.2968@TK2MSFTNGP14.phx.gbl...
> I'm using a remoted object (Actually, it's just a context-bound object on
> the same machine, but same concept). When an exception is thrown, I can
only
> step into the last local call. I can't actually step into the remoted
> object's code where the exception was thrown. If I set a breakpoint,
> however, in the remoted object I will can step through it: I just can't
view
> the contents of the remoted object.
>
> So I have 2 questions:
>
> Is there a way I can enable VS .NET to capture, and break, at the remoted
> exception on the object server rather than the last location of the local
> call to the remoted object?
>
> I'm throwing a custom exception and throwing it from within my remoted
> object. On my client/host application, though, I'm actually receiving an
> "Object reference not set to an instance of an object" exception. The
stack
> trace shows my original, custom exception being thrown, though.
>
>