rejectRemoteRequests config switch on remoting channels

You can add rejectRemoteRequests=”true” on the server side tcp or http channels. With this set remoting will only allow connections from the loopback address and thus will reject cross machine calls. This is equivalent to setting bindTo=”″ or machineName=”localhost”. In v2.0 IPC channel would probably be a better choice for local machine x-process scenarios.


Reasoning for TypeFilterLevel in remoting

Most remoting users have seen one of the following exception messages during deserialization: Because of security restrictions, the type XXX cannot be accessedType XXX and the types derived from it (such as {YYY}) are not permitted to be deserialized at this security level Here is some explanation of why these security restrictions are in place for remoting: 1….


Clarification on OneWay messages in remoting

My post from last week talked about OneWay messages in remoting. I should have clarified that the async and one way behaviour occurs only when invoking a method marked with [OneWay] on a remoting proxy. Invoking the same method on a regular object will not have the desired effect. It will be called synchronously like any other…


Investigating memory leaks in remoting

There is a common misconception that using remoting leads to memory leaks. The fact is that the problems mostly lie in the server design more that in the use of remoting. There are two issues which often lead to server side leaks: 1. It could be related to [STAThread]. This attribute should never be used for a…



RemotingServices.Marshal allows you to publish an existing instance remotely. Both for server activated (wellknown) and client activated objects remoting controls when the object is instantiated and initialized. Using Marshal allows you to initialize the object before making it available remotely. The published object will still follow the same lifetime rules, meaning it will be disconnected…


OneWay messages in remoting

Remoting provides a way for fire-and-forget OneWay messages from client to the server. Just adding a [OneWay] attribute to a method of your remoted type would make the method invokation oneway. Something like: public class Remote : MarshalByRefObject{  public void RemoteMethod ()  {}   [OneWay]  public void RemoteOneWayMethod()  {}} When invoking a oneway method the client…


NLB and remoting

One issue with NLB and remoting is the fact that remoting clients cache sockets connections for performance reasons. The side effect of this is that in the NLB case subsequent calls from the same client go to the same server introducing server affinity. But separate clients should still work with NLB and should be routed…


Guidance for using Events and delegates in Remoting

Events and Delegates are supported in remoting. So x-appdomain and x-process delegates and eventing does work. The guidance is to not use them in cases where channels could be unreliable. In case where channels are unreliable (mostly the network in x-machine cases) its difficult to handle exceptions when events are being fired ( An unhandled exception…


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…



CallContext allows you to flow information with a “logical” call. With logical we mean the call doesnt necessarily have to happen on the same thread. Following constitute logical calls: 1. remoting calls made x-appdomain and x-process 2. Async delegate invokations which might execute on different thread. The callcontext is serialized for remoting calls and carried…