I would suggest to give Moq a try, that will tell if it is a Castle
DynamicProxy problem or RhinoMocks problem.
BTW, I'm also a user of RM and trying to help :)
> Okay, what am I talking about!?
>
> Resolve<T> is a virtual member.
How sad is it that there is no online API doc for Unity and the P&P
team want me to download an msi install file! I hope no other patterns
this approach at least.
Anyway I downloaded a copy of Unity.dll from somewhere else and opened
it up in Reflector.
No! it is not virtual as you can always expect from P&P, again hope
you don't pattern this :)
The method is defined in the UnityContainerBase:
public T Resolve<T>()
{
return (T) this.Resolve(typeof(T));
}
and it finally calls
public abstract object Resolve(Type t, string name);
which you can stub if you use partial mock.
HTH
Virtual member and interface members are very different. I don't have
a link handy but there are a lot of talks you can google, or go direct
to C# language specification.
I understand your point and believe everything should just be virtual
like Java. While I do love property, delegate, event, lamba and etc in
.Net, IMHO, this virtual/non-virtual thing is just unnecessary
complication introduced by M$ to say, hey .Net has one more feature
then Java.
That being said, you should mock the interface, not the implementation.
I was getting bad image a lot at those days and hence my own compilation of RM.
Now it is your choice of keeping my version of RM (with many enhanced
feature that you (most likely) won't get it in future RM releases, or
get the RM source and compile one yourself with latest DynamicProxy2.