We have many classes published in a remoting channel as singlecalls. The application resides into a windows service. They are being used in the following scenarios:
- From the same application domain
- From another application domain using CrossAppDomain remoting channel
- From a remote client through the network using a tcp channel
As some of these classes are used in the three cases we have some common code to do operations with them, something like:
using(IRemoteObject remoteObject= (IRemoteObject)
RemotingHelper.GetObject(typeof(IRemoteObject)))
{
remoteObject.DoStuff();
}
The RemotingHelper already knows how to create the objects depending on the scenario. It is a modification of the Ingo Rammer's one.
All the remote object interfaces inherit from IDisposable, and all remote objects inherit from MarshalByRefObject.
So, in the case of using this code in the first two cases, the code behaves correctly, but when used through real remoting the remote object is created twice and disposed twice.
This happens because the Dispose() call, the one being made by the using statement, is managed as a new remote call, but the remoting infraestructure already called to the dispose of the object automatically, because that's how it behaves for SingleCall objects: each call creates a new instance and disposes it automatically.
Is there any configuration value to avoid these repeated (redundant) calls?
Edit: I already knew why this happened. In the case of a remote SingleCall IDisposable object the remoting channel automatically calls to Dispose after the Method returns, the second call is done by the proxy generated at client side, causing a instantiation of a new object at server side, just for calling the Dispose method.
This second call is the one I want to avoid because it is unneeded.