To prevent the saying ‘go away … it worked on my machine’ we decided to deploy the first version of an application on the implementation model which will be used at a production stage. This application uses .NET remoting to communicate over boundary’s.
After setting up the remoting configuration the first call gave the following error:
System.Runtime.Serialization.SerializationException Because of security restrictions
This sounded weird because there were no extra implementations on security and at the end of course we were all administrators to get this thing to work. Still nothing ...
The types the application uses to communicatie between layers are classes with only props and the serializable attribute on it. These classes can be nested as an array structure. So maybe this is the problem, lets try to send a standard string a type within the current deployment. You did guess right .. it worked fine … With this information we can Google some more.
www.gotdotnet.com
www.cs.auckland.ac.nz
www.thecodeproject.com
It seems that the .NET framework uses 2 types of security for serialization of objects in .NET remoting. And of course the default security level (LOW) was not sufficient enough for the implemented classes. So the security lever has to set to HIGH. As described in the above links you can implement this with .config files or programmatically. The last one was implemented at the server because the usage of a standard framework (e-Platform) for .NET remoting. As follow:
BinaryClientFormatterSinkProvider clientProvider = null;
BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider();
serverProvider.TypeFilterLevel = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;
IDictionary props = new Hashtable();
props["port"] = 8102;
props["typeFilterLevel"] = TypeFilterLevel.Full;
TcpChannel _chan = new TcpChannel(props,clientProvider,serverProvider);
ChannelServices.RegisterChannel(_chan);
This eliminated the serialization security issue …