No message was deserialized prior to calling the DispatchChannelSink.

Question

I noticed that a few others also experienced the exception and message, “No message was deserialized prior to calling the DispatchChannelSink.” I never found any solutions posted as follow ups to their original enquiries so I wanted to get something “on the record.” However, I really never solved the problem but was able to get around it, at least for my situation. It all started a few days ago while working with the .Net Famework 1.1. Between my client application and server application I was trying to pass a delegate type for use as a callback and received a System.Security.SecurityException with the message, “Type System.DelegateSerializationHolder and the types derived from it (such as System.DelegateSerializationHolder) are not permitted to be deserialized at this security level.” With a little research if found that security enhancements in .Net 1.1 does not by default always permit serialization of certain types. (“Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed.” Reference: “.NET Remoting: Passing through the obstacles path from version 1.0 to 1.1” by Cohen Shwartz Oren, http://www.codeproject.com/csharp/PathRemotingArticle.asp) The result was that it is possible to set your channel's type-filter-level and your server-format-sink-provider's type-filter-level properties to TypeFilterLevel.Full. This permits the delegate type to be serialized and deserialized. I then received a System.ArgumentNullException with the message, “Additional information: No message was deserialized prior to calling the DispatchChannelSink.” The entire message follows: “A first chance exception of type 'System.ArgumentNullException' occurred in mscorlib.dll Additional information: No message was deserialized prior to calling the DispatchChannelSink. A first chance exception of type 'System.Runtime.Remoting.RemotingException' occurred in mscorlib.dll Additional information: System.ArgumentNullException: No message was deserialized prior to calling the DispatchChannelSink. Parameter name: requestMsg at System.Runtime.Remoting.Channels.DispatchChannelSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream) at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream) at System.Runtime.Remoting.Channels.Http.HttpServerTransportSink.ServiceRequest(Object state) at System.Runtime.Remoting.Channels.SocketHandler.ProcessRequestNow()” I found that one way around the problem (not the solution) was to switch from the HttpChannel to a TcpChannel. I literally changed two lines of code, the TcpChannel object creation and the URL on the client side and magnifique, it worked. Like I said, I never found the solution only a work-around. Fortunately, in my situation I can use a TCP connection. Of course it could be the way I was setting up the Http channel . . . who knows. Actually, If someone else was able to get their BinaryServerFormatterSinceProvider, HttpChannel, and RemoteConfiguration working with TypeFliterLeve.Full I would like to hear about it. Terence