No message was deserialized prior to calling the DispatchChannelSink.

terence_ng99

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

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

sss 021y ago
You gotta use according Soap formatters if you want to use HTTP channels, maan... And binary for TCP. SoapServerFormatterSinkProvider serverProv = new SoapServerFormatterSinkProvider(); serverProv.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full; SoapClientFormatterSinkProvider clientProv = new SoapClientFormatterSinkProvider();
ArlenCode21y ago
I just ran into this same problem, and found a solution (I worry for my sanity, when I begin to understand .NET remoting error messages !!). Calls from client to server worked with no trouble, but the "No message was deserialized..." error occured going the other way. On the client, I was creating binary client _and_ server providers: ---- BinaryClientFormatterSinkProvider sinkProviderBinClient = new BinaryClientFormatterSinkProvider(); BinaryServerFormatterSinkProvider sinkProviderBinServer = new BinaryServerFormatterSinkProvider(); sinkProviderBinServer.TypeFilterLevel = TypeFilterLevel.Full; HttpChannel channel = new HttpChannel(dictChannelProperties,sinkProviderBinClient,sinkProviderBinServer); ---- However, on the server I was only creating the server provider: ---- BinaryServerFormatterSinkProvider sinkProviderBin = new BinaryServerFormatterSinkProvider(); sinkProviderBin.TypeFilterLevel = TypeFilterLevel.Full; HttpChannel channel = new HttpChannel(dictChannelProperties,null,sinkProviderTrebuchet); ---- What I _think_ was happening, is that, for HTTP, the client formatter being created automatically was a SOAP formatter, rather than a binary one. TCP, however, seems to create a binary formatter (I support both, and everything works fine for TCP). All I did was create the client binary formatter on the server and everything started working! : ---- BinaryServerFormatterSinkProvider sinkProviderBin = new BinaryServerFormatterSinkProvider(); sinkProviderBin.TypeFilterLevel = TypeFilterLevel.Full; BinaryClientFormatterSinkProvider sinkProviderBinClient = new BinaryClientFormatterSinkProvider(); HttpChannel channel = new HttpChannel(dictChannelProperties,sinkProviderBinClient,sinkProviderTrebuchet); ---- I don't know if this is the same problem you were having, but it seems likely. Obviously, the same could be done with a config file. I realize it has been a while since you posted the problem, so this may or may not be helpful to you, but I figure the more bits and pieces of remoting info out there, the better. Regards, Arlen Feldman, www.cowthulu.com