So today I updated my Rhino Mocks library to the newest version and bam, all my tests broke.

The errors were all on lines where I was doing things like:

Expect.Call(viewMock.ViewState).Return(viewState).Repeat.Any()

The error was:

Overload resolution failed because no accessible 'Expect' accepts this number of arguments.  

I found a few others having the same problem

http://groups.google.com/group/RhinoMocks/browse_thread/thread/ebdfc26579f25da1

http://groups.google.com.ag/group/rhinomocks/browse_thread/thread/a85251a7ad2fae70

… but no real mention of why this was happening.

I found pretty quickly that if I fully qualified things, it would work.  For example, this works:

Rhino.Mocks.Expect.Call(viewMock.ViewState).Return(viewState).Repeat.Any()

But I was already importing Rhino.Mocks so why the problem?

As it is, the error is that the compiler is trying to call an extension method named “Expect”.  This method extends the class Rhino.Mocks.RhinoMocks and is defined in Rhino.Mocks.RhinoMocksExtensions.  The “Expect” that I actually want is a class defined in Rhino.Mocks that has a static/shared method “Call”.

So why is the extension method of RhinoMocks getting picked up?  I think it’s a combination of 2 different things that are happening here.  The first issue (I think) is that VB.Net does not support a static class.  Extension methods are defined in static classes in C# and in modules in VB.Net.  A module is kinda like a static class, except for a big difference: you don’t have to qualify the methods in a module by using the module name.

In other words if you have this in VB.Net

Module MyMod
    Public Sub DoSomething()
    End Sub
End Module

Class NotReallyStatic
    Public Shared Sub DoThis()
    End Sub
End Class

The way you would call the 2 methods is:

'*** Call DoSomething on the module
DoSomething()

'*** Call DoThis on NotReallyStatic
NotReallyStatic.DoThis()

So because VB treates the Static Class RhinoMockExtensions as a Module all the extension methods become in scope without any qualification, so you end up with a name collision on Expects.

The seconde issue is that the Expects extension method in Rhino Mocks is extending generic classes (e.g. T) where T is any class.  If the extension was happening on any concrete class, I don’t think we’d see this issue, but because it is ANY class, the VB compiler this it could apply anywhere inside any of your classes.  And remember, even if you DO require some concrete class for the extension,

Here’s an example of this.

Let’s say your extension methods are defined like this:

Public Module SomeClassExtensions
     <Runtime.CompilerServices.Extension()> _
     Public Sub ExtensionMethod(Of T As Class)(ByVal o As T, ByVal str As String)
         Console.WriteLine("")
     End Sub

     <Runtime.CompilerServices.Extension()> _
     Public Sub ExtensionMethodString(ByVal o As String, ByVal str As String)
         Console.WriteLine("")
     End Sub
 End Module

Note that the first uses a generic class and then second extends String.

Using these extension methods, basically ANYWHERE in your code (in VB) you could do the following:

'*** works
 Call ExtensionMethod("foo")
 Dim s As String
 s.ExtensionMethodString("foo")

 '*** won't work
 Call ExtensionMethodString("foo")

 '*** also works!
 Call ExtensionMethodString("foo", "bar")

You can see that we are able to call the generic extension method direct as if it were an instance method in whatever class we are currently working because (I think) the compiler is treating Me (or this in C#) as T, and the method is in scope because it is defined in a Module and not a Static Class as it would be in C#. 

We can’t directly call ExtensionMethodString because the class I am currently in does not inherit from String.  But, you’ll see at the end, because of the whole “Module vs Static Class” scope thing, we can still call the ExtensionMethodString directly but we have to pass in a string for the first parameter, which is supposed to be the parameter that tells the compiler what type of class to extend.

So the rule here is, if you have a Class Name (or really anything) and Extension Method Name that have the same name and are in the same namespace, you can run into this problem in VB.Net, and those problems get even worse if you are extending a generic class.

As I mentioned, you can get around this by fully qualifying your calls to Expect.Call, or you could change the way you do your expectations,  but if you are writing out these types of tests and don’t want to have to fully qualify everything, then you can use an import alias like this:

Imports DoExpect = Rhino.Mocks.Expect

Then you just change your “Expect.Call” to “DoExpect.Call” and all should work!

I think this could be fixed in Rhino Mocks quite simply.  I believe all that would need to happen is that RhinoMocksExtensions would just need to move to a different namespace, like Rhino.Mocks.Extensions.  I don’t think this change would even require additional changes to the Rhino Mocks codebase, but I’m not 100% sure on that.