I was recently writing some code that was simulating a Client application calling into a Server application across a process boundary. That is, the Client and Server application were running in different processes. I was prototyping some code where the Client was invoking a member on a MarshalByRef object provided by the Server over a tcp channel. After I finally worked out the remoting code for the Client to call multiple Server processes, I decided it would be a great feature to also allow the server call into the client. A two way (i.e., two-way, both directions, cooperative) remoting channel.
After searching high and low for a remoting solution, the best alternative I could come up with was to have the server return an object back to the client that the server could then call on. Although this is one method, it wasn’t at all what I had in mind.
Note that I was not using .config files for my channel providers, etc… Most examples of config file usage show the property that ultimately solved my issue (see below). The following may not be the best solution for you, but since I ran into the issue and had a hard time determining the solution, I thought I would share my findings.
In the Backwards breaking changes from version 1.0 to 1.1 list I found my answer. Title – Secure Serialization in .Net Remoting. By setting typeFilterLevel = “full” I was good to go. You can set this
System.Collections.IDictionary props = new System.Collections.Hashtable();
props["name"] = "Client";
props["typeFilterLevel"] = "Full";
BinaryServerFormatterSinkProvider serverProvider = new BinaryServerFormatterSinkProvider();
serverProvider.TypeFilterLevel = TypeFilterLevel.Full;
Or via your App.exe.config setting
<channel ref="tcp" port="6123">
<formatter ref="binary" typeFilterLevel="Full" />
I hope this helps someone else out there. When dealing with remoting, may the force be with you ;-)