Re: Remoting, AppDomains, and Exceptions

From: Daryl Smith (daryl.smith2_at_unisys.com)
Date: 10/26/04 

Date: Tue, 26 Oct 2004 09:53:08 -0700

> You would think the call to GetExceptionMethodString()
> would check if the _exceptionMethodString field is non-null and, if so,
> simply return it.
That was the exact same thought I had when I tracked down the code. Perhaps
this will be addressed in the 2.0 Framework.

> 1) Make the server assembly available to the main AppDomain (but I'm sure
> this not what you want).
> 2) Be sure to catch all exceptions coming from the second AppDomain and,
> instead of re-throwing them or sending them on as is (or as an
> InnerException), raise a new exception and copy the message over. Not
ideal,
> but should work.
Thanks for the ideas. I had come up with a similar list of alternatives,
and at this point, something along the lines of #2 seems to be my best
option.

Daryl

"Ken Kolda" <ken.kolda@elliemae-nospamplease.com> wrote in message
news:OHlP2Z3uEHA.944@TK2MSFTNGP11.phx.gbl...
> That's very strange -- looks like a bug in the implementation of the
> Exception class. You would think the call to GetExceptionMethodString()
> would check if the _exceptionMethodString field is non-null and, if so,
> simply return it. That would eliminate the problem you're having with the
> double serialization of the Exception.
>
> I can't think of an easy workaround other than the obvious ones:
>
> 1) Make the server assembly available to the main AppDomain (but I'm sure
> this not what you want).
> 2) Be sure to catch all exceptions coming from the second AppDomain and,
> instead of re-throwing them or sending them on as is (or as an
> InnerException), raise a new exception and copy the message over. Not
ideal,
> but should work.
>
> Ken
>
>
> "Daryl Smith" <daryl.smith2@unisys.com> wrote in message
> news:clk3ot$16l3$1@si05.rsvl.unisys.com...
> > I've encountered a problem with how the .NET Framework serializes
> exception
> > objects that is causing some grief for my remoting application that also
> > uses multiple AppDomains.
> >
> > In brief, the server side of my remoting application hosts a number of
> > independant assemblies which expose methods to the client. Each of
these
> > independant assemblies is loaded into its own AppDomain so that it is
> > isolated, and so that my server can unload it completely when the client
> > disconnects.
> >
> > The problem occurs when the code running in the loaded assembly throws
an
> > exception. I want to pass this exception through my server down to the
> > client. However, the client never receives the exception. Instead, it
> > receives a FileNotFoundException which indicates a problem with loading
an
> > Assembly. After considerable digging, I've discovered the problem is
the
> > TargetSite property of the Exception class and the way it is serialized.
> > (See http://www.dotnet247.com/247reference/System/Exception/__rotor).
> >
> > The Exception object has to pass through 2 serialization rounds. Once
> from
> > the AppDomain I create for the loaded assembly, and then once again from
> my
> > server process through remoting to the client. When the Exception class
> > serializes the TargetSite property, it serializes it to a string. When
it
> > attempts to rehydrate the TargetSite MethodInfo object after
> > deserialization, it needs access to the assembly in which the exception
> was
> > initially thrown. This fails since my server's main AppDomain is using
a
> > different codebase, and doesn't have access to the original assembly.
> >
> > I find it odd that the serialization for an Exception object requires
> access
> > to the assembly in which the exception initially occurred. It seems
like
> > this breaks the common "interface based remoting" approach. If the
client
> > tried to access the TargetSite property of an Exception thrown by the
> > server's private implementation of the remoted interface object, it
would
> > fail.
> >
> > Has anyone else run into this, and found a reasonable workaround?
> >
> >
> >
>
>

Relevant Pages

  • Re: Can RCW and CCW be used together?
    ... code that you show seems to be VB6 code, but the exception must be thrown ... component project reference to my client project and build. ... problem-domain specific assemblies and the assemblies for the RCW-Interop ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Cross-AppDomain call problems
    ... that I pass custom assemblies accross. ... An inner exception would not be it ... none of the types are leaking across the appdomain boundary. ... I have a simple interface assembly that defines all the types the two ...
    (microsoft.public.dotnet.framework)
  • Re: Cross-AppDomain call problems
    ... There must be something in one of the objects defined in the interface that ... An inner exception would not be it ... none of the types are leaking across the appdomain boundary. ... assembly (and possibly all the assemblies that it in turn references) to ...
    (microsoft.public.dotnet.framework)
  • UnhandledExceptionHandler delegate not working in remoting host
    ... But I'd like to catch any unhandled exceptions that occur in any of the actual assemblies being used by client applications. ... This exception is being raised - it's getting back to the client application - but my UnhandledException delegate isn't being called. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: EventLogPermission via caspol.exe
    ... I moved my code off UNC to local disk. ... Exception oInnerException, Boolean bLog) ... > web app and assemblies over UNC. ...
    (microsoft.public.dotnet.security)
Loading