Exceptions and Remoting
Exceptions are serializable (ISerializable too). Exceptions are serialized from the server back the client. Thus if you see a client side exception with the following stack trace, there is a good chance you are actually seeing an exception which was thrown on the server:
[OutOfMemoryException: Exception of type System.OutOfMemoryException was thrown.] [TargetInvocationException: Exception has been thrown by the target of an invocation.]System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) |
Starting in v1.1 of the framework, for security reasons server exceptions dont propogate to the client by default, if the client isnt on the same machine as the server. Instead the client will see a generic exception of this form:
System.Runtime.Remoting.RemotingException: Server encountered an internal error. For more information, turn on customErrors in the server's .config file.
For the server to flow exceptions add the following to the server side config file
<configuration>
<system.runtime.remoting>
<customErrors mode="Off"/>
</system.runtime.remoting>
</configuration>
This is also settable programmatically in v2.0 of the framework.
If you need your own Exception to serialize correctly you need to make sure it implements a Deserialization Constructor of the following signature. If you dont you will see a runtime exception, unfortunately this issue cannot be detected at compile time:
protected Exception(SerializationInfo info, StreamingContext context)
It can simply call base(info, context); if there are no fields the derived exception needs to serialize.