[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.dotnet.framework.remoting

Remoting, AppDomains, and Exceptions

Daryl Smith

10/25/2004 11:55:00 PM

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/Excepti...).

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?
2 Answers

Ken Kolda

10/26/2004 4:11:00 PM

0

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/Excepti...).
>
> 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?
>
>
>

Daryl Smith

10/26/2004 4:53:00 PM

0

> 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/Excepti...).
> >
> > 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?
> >
> >
> >
>
>