This post is about the Rhino Tools project. It has been running for a long time now, over 5 years, and amassed quite a few projects in it.

I really like the codebase in the projects in Rhino Tools, but secondary aspects has been creeping in that made managing the project harder. In particular, putting all the projects in a single repository made it easy, far too easy. Projects had an easy time taking dependencies that they shouldn’t, and the entire build process was… complex, to say the least.

I have been somewhat unhappily tolerant of this so far because while it was annoying, it didn’t actively create problems for me so far. The problems started creeping when I wanted to move Rhino Tools to use NHibernate 2.1. That is when I realized that this is going to be a very painful process, since I have to take on the entire Rhino Tools set of projects in one go, instead of dealing with each of them independently. the fact that so many of the dependencies where in Rhino Commons, to which I have a profound dislike, helped increase my frustration.

There are other things that I find annoying now, Rhino Security is a general purpose library for NHibernate, but it makes a lot of assumptions about how it is going to use, which is wrong. Rhino ETL had a dependency on Rhino Commons because of three classes.

To resolve that, I decided to make a few other changes, taking dependencies is supposed to be a hard process, it is supposed to make you think.

I have been working on splitting the Rhino Tools projects to all its sub projects, so each of them is independent of all the others. That increase the effort of managing all of them as a unit, but decrease the effort of managing them independently.

The current goals are to:

• Make it simpler to treat each project independently
• Make it easier to deal with the management of each project (dependencies, build scripts)

There is a side line in which I am also learning to use Git, and there is a high likelihood that the separate Rhino Tools projects will move to github. Suversion’s patching & tracking capabilities annoyed me for the very last time about a week ago.

This is an alpha release only, because I don’t do anything with Silverlight.

Gunther Meyer ported Rhino Mocks to Silverlight, and now you can get the bits here.

This is the fix for the ExecutionEngineException that appeared in .Net 3.5 SP1, and was found by Rhino Mocks.

You can get it here: http://support.microsoft.com/?id=957541

This now works :-)

The challenge is still open, I intentionally stopped before completing the feature, and there is a failing test in the RecusriveMocks fixture that you can start from.

And just to give you an idea about what I am talking about, please run this and examine the results:

svn diff https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk -r 1682:1683

A really cool web view of them is here.

I have just committed a change to the way Rhino Mocks handles expectations for dynamic mocks and stubs.  Previously, the meaning of this statement was "expect Foo() to be called once and return 1 when it does":

Expect.Call( bar.Foo ).Return(1);

Now, the meaning of this is: "expect Foo() to be called one or more times, and return 1 when it does". This means that this will work:

Assert.AreEqual(1, bar.Foo);
Assert.AreEqual(1, bar.Foo);
Assert.AreEqual(1, bar.Foo);

Where as previously, using dynamic mocks, it would fail on the second assert, because the expectation that was setup was consumed. I think that this is a more natural way to behave, but this is a subtle breaking change.
You can get the old behavior by specifying .Repeat.Once().

Thoughts?

This post is derived from the Rhino Mocks 3.5 documentation.

Setting expectations for property set was always very simple, and slightly confusing with Rhino Mocks. Here is how you do it:

view.Username = "the user name";	

The problem is that it is hard to see that there is an expectation created here. So, with the generous help of Sebastian Jancke, we have a new syntax:

Expect.Call(view.Username).SetPropertyWithArguments("the user name");

This is much more explicit and easier to understand. We can also set expectation on the property set, without expecting a certain value using this syntax:

Expect.Call(view.Username).SetPropertyAndIgnoreArguments();

Okay, let us see if this approach works...

Here is a description of a feature that I would like to have in Rhino Mocks (modeled after a new feature in Type Mock). I don't consider this a complicated feature, and I would like to get more involvement from the community in building Rhino Mocks (see the list of all the people that helped get Rhino Mocks 3.5 out the door).

The feature is fluent mocks. The idea is that this code should work:

var mockService = MockRespository.GenerateMock<IMyService>();
Expect.Call( mockService.Identity.Name ).Return("foo");

Assert.AreEqual("foo", mockService.Identity.Name);

Where identity is an interface.

The best place to capture such semantics is in the RecordMockState.

Have fun, and send me the patch :-)

Today I decided that I had enough time to get bugs for the 3.5 RC, so I fixed all the remaining bugs, updated the Rhino Mocks 3.5 Documentation, and put the binaries out the site.

For this release, I actually have 4 binary packages. One for .NET 3.5 and one for .NET 2.0, but I have an additional criteria, with the castle assemblies merged (default) and with the castle assemblies included). The reason for having those two options is that people who want to extend Rhino Mocks directly can do it more easily. In general, I suggest using the merged version.

So, what do we actually have here (feature differences from 3.4)?

Features:

• Assert Act Arrange syntax for mocking
  • Including support for .NET 2.0
• Added a way to access the mocked method at runtime, using WhenCalled (similar to Do(), but without the pain of having to specify a special delegate).
• CreateMock() is deprecated and marked with the [Obsolete] attribute. Use StrictMock() instead.
• Support for mocking interface in C++ that mix native and managed types. (Note, may require that you install kb957541 to get around bug introduced to the framework on SP1).
  
• New event raising syntax:
  eventHolder.Raise(stub => stub.Blah += null, this, EventArgs.Empty);
• Better support for multi threaded replays.
  • Note that access to the mock object is now serialized.
• Support AssertWasCalled on parial mocks.

Patches:

• From Sebastian Jancke, adding support for SetPropertyAndIgnoreArguments() and SetPropertyWithArguments( o );
• From Yann Trevin, adding support for List.Element("MyKey", ...), so we are not limited to just integers.
• From David Tchepak, adding support for ctor arguments when creating a mock using static method.
• From Stefan Steinegger - much better support for creating inline constraints.
  

Improvements:

• Better handling of exception in raising events from mock objects
• Better error message when trying to set expectation on properties of a stub.
• Better error handling for AAA syntax abuse
• Will give better errors if you call Verify on a mock that is in record mode.
• Allowing to return to record mode without losing expectations.
• BackToRecord extension method.
• AAA syntax now works with Ordering
• Better error message if trying to use SetupResult on stubbed mock properties.
• Better error message when trying to mock null instance.

Bug fixes:

• Fixing an issue with mock objects that expose methods with output parameter of type System.IntPtr.
• Fixed an issue with merging, would cause issues if you are also using Castle Dynamic Proxy.
• Fixed various typos
• Fixed issue with mocking internal classes and interfaces.
• OutRef params was not copied when creating new expectation from an existing one.
• Fixing an issue with leaking expectationReplaced in mocks.

Okay, now that we are over the sensationalist headline, the actual problem is more complex than that. Let us assume that we have the following interface:

public interface IComplexGeneric<T>
{
	void GenericMethod<K>();
}

Up until .Net 3.5 SP1, Rhino Mocks was perfectly happy to deal with such an interface (well, not happy, exactly, that requires some hard core code). With .Net 3.5 SP1, this generate an Execution Engine Exception.

Fabian Schmied was kind enough to prove that select is broken here. This is the connect site issue, and I would appreciate it if you can vote for it.

The work around for this would mean that I will have to remove support for mocking F#, C++ and Spec# from Rhino Mocks, and I am reluctant to do so.

This is fixed,  you can get the fix here: http://support.microsoft.com/?id=957541