Re: Remoting, AppDomains, and Exceptions

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Ken Kolda (ken.kolda_at_elliemae-nospamplease.com)
Date: 10/26/04 

Date: Tue, 26 Oct 2004 09:10:32 -0700

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: Tactics for Debugging Custom Components with CodeDom Serialized State
    ... >I am not sure if you used the CodeDOM serialization correct, and if CodeDOM serialization is the correct solution for serializing your objects. ... They appear in the Task List window below the design surface as "Build Errors". ... considers the two assemblies to be different, ... >When the exception throws out, in the debugger call stack window, we can get the list of exception call stack. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Weird XML serialization problem
    ... I am experiencing a *very* frustrating problem with XML serialization. ... Everything works - all of my assemblies that reference ... Exception Information ...
    (microsoft.public.dotnet.framework)
  • 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)
  • Re: Remoting, AppDomains, and Exceptions
    ... > 2) Be sure to catch all exceptions coming from the second AppDomain and, ... > InnerException), raise a new exception and copy the message over. ... >> independant assemblies which expose methods to the client. ...
    (microsoft.public.dotnet.framework.remoting)