In October 2007, I added Remoting proxy support to Ayende Rahien's Rhino Mocks library. This allows Rhino Mocks to mock any type derived from
Control. This feature is available starting from Rhino Mocks 3.3.
While I was working in Bloomberg, we used a "ProxyMock" extension to the NMock library. This extension was written by my friend Levy Haskell. ProxyMock could mock any
MarshalByRefObject by using .NET Remoting mechanisms. The current status of ProxyMock is not clear to me. As far as I know, it has been a part of the NMock code base at some point, but it never made it to a public release of NMock.
After I left Bloomberg, I could no longer use ProxyMock. My friends in Finetix introduced me to Rhino Mocks by Ayende Rahien. I instantly fell in love with that library, but I missed the ability to mock
From time to time, I ran into difficult situations with my tests. Let's say, I have a view with an Infragistics grid in it. The Infragistics grid fires an event each time a grid row receives new data. Subscribers may intercept this event and change the row appearance based on the new data, e.g., change its background color. The view class passes the row initialization event to the presenter, and the presenter tells the view which background color to use.
UltraGridRow GridRow; DataRow DataRow;
delegate void InitializeRowHandler(object sender,
event InitializeRowHandler RowInitialized;
void SetBackgroundColor( UltraGridRow gridRow, Color color );
_view.RowInitialized += OnRowInitialized;
void OnRowInitialized( object sender, InitializeRowEventArgs args )
The presenter is not really interested in the guts of the
UltraGridRow. In this particular example, the grid row is completely opaque for the presenter. From the other hand, the presenter needs to have a grid row object. Otherwise, it would not be able to tell the view which row to color.
When I write a test for this code, I need to come up with a grid row object, pass it to the presenter, and make sure the row initialized is the row colored.
public class PresenterTest
public void Setup()
_mocks = new MockRepository();
public void ColorRowOnInit()
IView view = _mocks.CreateMock<IView>();
view.RowInitialized += null;
IEventRaiser rowInitialized =
UltraGridRow fakeGridRow = what goes here?
DataRow dataRow = some sample data;
RowInitializedEventArgs args =
new RowInitializedEventArgs(fakeGridRow, dataRow);
view.SetBackgroundColor( fakeGridRow, Color.Red );
Presenter = new Presenter(view);
The problem is, I cannot easily create an
UltraGridRow object: it does not have public constructors. In order to get a bona-fide
UltraGridRow, I will have to create a real Infragistics grid control, properly set it up, and give it a real data source with at least one data row. Too much trouble for a little test.
I cannot mock an
UltraGridRow either. It is not an interface, it's a real class. Rhino Mocks mocks real classes by dynamically creating derived classes with overridden virtual functions. If I cannot create an
UltraGridRow, creating an object of a derived type is also going to be a problem.
Remoting to the Rescue
UltraGridRow, like many other graphical widgets, ultimately derives from
MarshalByRefObject. It means, I can throw some Remoting at it. Here is how a typical remote object works:
There is no real object on the client side. A special entity called "transparent proxy" takes its place. Transparent proxy is a very peculiar object. Given any type
T that derives from
MarshalByRefObject, the .NET framework can construct a "fake" instance of that type out of thin air, bypassing any constructors and initializers. Obviously, this cannot be done in regular C# (or even IL). Transparent proxies are created by the "magic" method
RemotingServices.CreateTransparentProxy(). This method is marked
extern, and is implemented in unmanaged code. It is also internal. Mere mortals call this method indirectly via
Since a transparent proxy has no "meat", it cannot do any real work. It forwards all method calls to the real proxy object by calling the
RealProject.Invoke() method. The real proxy is supposed to package input parameters, transfer them over the wire, receive a return message, process the results, and convert them either to a return value or to an exception.
RealProxy class from the
System.Runtime.Remoting.Proxies namespace is a base class for all real proxies. The
RealProxy class is abstract. The actual .NET Remoting proxy is
System.Runtime.Remoting.Proxies.RemotingProxy. However, we are free to create our own real proxies that do any other kind of marshalling.
If you read a description of a transparent proxy, it looks like it was specifically invented to create mocks. It can construct a fake object out of thin air and forward all the calls to a special interceptor - the real proxy.
The only problem was to create such an interceptor. In the end of July 2007, I asked Ayende whether he would be interested in such an interceptor, and he said yes. In October 2007, I finally got the time to actually write it. Ayende and I went over a couple of iterations, and voila - Rhino Mocks 3.3 has the ability to mock
Rhino Mocks internally uses an interception framework from the Castle project. The framework defines the
IInvocation interface to represent a single method call, and the
IInterceptor interface to represent a call interceptor. Castle does not define what specifically the interceptor should do with the calls. Rhino Mocks defines the
RhinoInterceptor class that handles mock expectations and replay.
I needed to write an adapter that would forward calls from a .NET Remoting proxy to an
IInterceptor. This proved to be relatively straightforward, but there were some tricky pitfalls along the path. You can see the source code in the Rhino Mocks SVN repository.
One must keep in mind that absolutely all method calls are forwarded to the real proxy. This includes things like
Equals(). If you want to put the proxy in a container (and Rhino Mocks does want that), these methods cannot be left out. They must be handled on the proxy level, and they must be handled correctly.
Communicating with the Real Proxy
Another tricky problem was to retrieve information about the real proxy when you have only an instance of the transparent proxy. In particular, I needed to extract an
IMockedObject reference held by the Rhino Mocks real proxy.
IMockedObject is an internal Rhino Mocks class used for housekeeping.
The problem is: a transparent proxy can be of any type (as long as it derives from
MarshalByRefObject), so all I can rely on are the methods of the
Object class. There are not many to choose from:
public class Object
public virtual bool Equals(object obj);
public virtual int GetHashCode();
public Type GetType();
public virtual string ToString();
Out of these,
ToString() don't look very interesting, because:
- they don't take any parameters, and
- they return some fixed type.
I would not be able to retrieve an
IMockedObject reference through any of these three methods. This leaves us with
Equals() can take an object of any type, and, if necessary, it can even modify that object to store return data. So, I can use
Equals() as a two-way communication mechanism that can tell the real proxy what I want and get the data back. Of course, this is not what
Equals() was invented for. Normally,
Equals() is not supposed to modify its argument. Ayende called this technique "an evil hack". However, this was the only feasible way to extract data from the real proxy.
I even added some object oriented flavor to that evil hack - something along the lines of the Visitor pattern. I defined a special interface:
void Process(RemotingProxy proxy);
The real proxy's
Equals() handle checks whether the object passed is of type
IRemotingProxyOperation, and if yes, calls its
Process() method, passing the proxy as the argument:
private bool HandleEquals(IMethodMessage mcm)
object another = mcm.Args;
if (another == null) return false;
if (another <is IRemotingProxyOperation)
return ReferenceEquals(GetTransparentProxy(), another);
This allows to add new proxy processing operations without modifying the proxy code. Currently, only two operations are defined: checking whether a particular object is a transparent proxy for the Rhino Mocks Remoting proxy, and retrieving the
IMockedObject reference (RemotingMockGenerator.cs).
public static bool IsRemotingProxy(object obj)
if (obj == null) return false;
RemotingProxyDetector detector = new RemotingProxyDetector();
public static IMockedObject GetMockedObjectFromProxy(object proxy)
if (proxy == null) return null;
RemotingProxyMockedObjectGetter getter = new RemotingProxyMockedObjectGetter();
Using the Remoting Proxy
You don't need to do anything special to use the Remoting proxy. This is why this paragraph is so short. The
CreateMock<T>() method automatically detects the kind of type you are trying to mock, and uses the Remoting proxy if the type is a
MockRepository mocks = new MockRepository();
UltraGridRow row = mocks.CreateMock<UltraGridRow>();
Adding Remoting proxies to Rhino Mocks extends the set of types it can mock. Many "difficult" types derive from
MarshalByRefObject. In particular,
System.Windows.Forms.Control and all derived classes are marshaled by reference, and thus can be mocked using Remoting proxies. Most Infragistics types (in the Windows Forms flavor of Infragistics) are also marshaled by references, and also can be mocked.
Some people say that this shifts Rhino Mocks in the direction of TypeMock, and this is a bad thing. That might be the case in theory, but in practice, Remoting mocks allow me to unit test things I could not unit test before. So, it must be a good thing, at least in some cases.
Besides, working on this project was a lot of fun, and I learnt a lot about the internals of Rhino Mocks, Reflection on generic types, etc. I hope you will enjoy the end result of this project no less than I enjoyed working on it.
- Last updated: December 17, 2007.