Well, it seems like Rhino Mocks has a new daddy . In particular, Mike Meisinger has kindly agreed to take the project as the project lead.

You can discuss all about this in the mailing list for Rhino Mocks, or hear more about Mike’s plans, visit his blog.

I was asked to comment on the current state of Rhino Mocks. The current codebase is located here: https://github.com/hibernating-rhinos/rhino-mocks

The last commit was 2 years ago. And I am no longer actively / passively monitoring the mailing list.

From my perspective, Rhino Mocks is done. Done in the sense that I don’t have any interest in extending it, done in the sense that I don’t really use mocking any longer.

If there is anyone in the community that wants to steps in and take charge as the Rhino Mocks project leader, I would love that. Failing that, the code it there, it works quite nicely, but that is all I am going to be doing with this for the time being and the foreseeable future.

This is a public service announcement, mostly meant to be caught in Google, to be frank.

The new homepage for Rhino Mocks is: http://hibernatingrhinos.com/open-source/rhino-mocks

There have been some changes, and it seems that it is hard to track them. Here are where you can find the master repositories for the rhino tools projects:

• Rhino Commons - https://github.com/lorenzomelato/rhino-commons
• Rhino Service Bus- https://github.com/hibernating-rhinos/rhino-esb
• Rhino Licensing - https://github.com/hibernating-rhinos/rhino-licensing
• Rhino ETL - https://github.com/hibernating-rhinos/rhino-etl
• Rhino Security - https://github.com/hibernating-rhinos/rhino-security
• Rhino Persistent Hash Table - https://github.com/hibernating-rhinos/rhino-pht
• Rhino Distributed Hash Table - https://github.com/hibernating-rhinos/rhino-dht
• Rhino DSL - https://github.com/hibernating-rhinos/rhino-dsl
• Rhino Mocks - https://github.com/hibernating-rhinos/rhino-mocks
• Rhino Queues - https://github.com/hibernating-rhinos/rhino-queues

Well, it is official now, Rhino Mocks have a new home, and it is on github.

We had a chance to try several common development scenarios with it, accepting patches & commits from other people, and so far I can tell you that I am very impressed with the Git style workflow.

However, I know that many people aren’t comfortable with Git yet, so I decided to setup things to make things easier for everyone.

You can now access the output of Rhino Mocks CI process here:

http://builds.hibernatingrhinos.com/builds/Rhino-Mocks

A while ago I was contacted by a friend who asked me if I am offering a commercial version of Rhino Mocks.

That is not a mistake, he was working in a place where the use of Open Source Software was not allowed, and decided that the simplest way to use the tool was to go through the normal route, buy it.

I wholeheartedly support this decision. :-)

Considering how hard it is to make some organizations use Open Source projects, and how used those same organizations to buying software, it is probably the right decision. It make things much simpler, and you are actually supporting OSS along the way.

At any rate, if you find yourself in the same position, you can just go and buy Rhino Mocks.

The retail version and the OSS version are… well, look at the title, then figure it out.

It was brought up in the mailing list that we should have a more structured way of managing the ideas for Rhino Mocks 4.0, I agree, and the forum is here:

http://nhprof.uservoice.com/pages/28152-rhino-mocks-4-0

Well, now that Rhino Mocks 3.6 is out of the way, we need to think about what the next version will look like.

Initially, I thought to match Rhino Mocks 4.0 to the .NET 4.0 release and support mocking dynamic variables, but while this is still on the planning board, I think that it is much more important to stop and take a look at where Rhino Mocks is now and where we would like it to be.

I started Rhino Mocks about 5 years ago, and the codebase has stood well in the test of time. There aren’t any nasty places and we can keep releasing new features with no major issues.

However, 5 years ago the community perception of mocking was different than what it is now. Rhino Mocks hasn’t really changed significantly since it 1.1 days, for that matter, you can take a code base using Rhino Mocks for .Net 1.1 and move it to Rhino Mocks 3.6 with no issues.

But one of the most frequent complaints that I have heard is that Rhino Mocks API has became too complex over the years, there are too many options and knobs that you can turn. I know that my own style of interaction testing has changed as well.

The current plan for Rhino Mocks 4.0 is that we will break backward compatibility in a big way. That means that we are going to drastically simplify everything in the framework.

We are still discussing this in the mailing list, but currently it looks like we will go with the following route:

• Kill the dynamic, strict, partial and stub terminology. No one cares. It is a fake.
• Remove the record / playback API. The AAA method is much simpler.
• Simplify mocking options, aiming at moving as much as possible from expectation style to assert style.
• Keep as much of the current capabilities as we can. That means that if Rhino Mocks was able to support a scenario, it should still support it for the 4.0 version, hopefully in a simpler fashion.

The end result is putting Rhino Mocks on an API diet. I am looking for help in doing this, both in terms of suggested syntax and in terms of actual patches.

You are welcome to contribute…

This release is mostly to put out all the patches & fixes that went into Rhino Mocks since the 3.5 release, almost a year ago.

The changes from the previous version are:

• Dynamic mocks and stubs will now assume that a call is match by any number of expectation.
• Recursive mocks (with help from webpaul)
• Fixing an issue with ArgManager in multi threaded scenarios (patch from Stefan Steinegger)
• Fixing problem with IgnoreArguments() after Do() erasing the Do()
• Fixing an issue with SetPropertyWithArgument improperly using LastCall.
• Allowing Rhino Mocks to raise events on VB6 dlls.
• Adding support for AssertWasCalled for getters (patch from robin clowers)
• Adding remoting mocks as static methods (patch from Peter Mounce)
• Adding a way to access the method from MethodInvocation
• Fixing an issue with recursive return types when making a call to record an event more than once.
• Various spelling & grammar issues (patch from Peter van der Woude)
• Fixing an issue with stubbing MarshalByReferenceObjects
• Better integration with Pex
• Making LambdaConstraint work better with polymorphic args
• Better feature parity for AAA with Record & Playback: Partials, Multis, and Stricts
• Fixing an issue with stubbing properties of generic interfaces implemented twice using different generic parameters (Alexander Groß)

As usual, the download is here.

James Kovacks introduced psake ( a power shell based build system )over a year ago, and at the time, I gave it a glance and decided that it was interesting, but not worth further investigation.

This weekend, as I was restructuring my Rhino Tools project, I realized that I need to touch the build system as well. The Rhino Tools build system has been through several projects, and was originally ported from Hibernate. It is NAnt based, complex, and can do just about everything that you want expect be easily understandable.

It became clear to me very quickly that it ain’t going to be easy to change the way it works, nor would it be easy to modify that to reflect the new structure. There are other issues with complex build systems, they tend to create zones of “there be dragons”, where only the initiated go, and even they go with trepidation. I decided to take advantage of the changes that I am already making to get a simpler build system.

I had a couple of options open to me: Rake and Bake.

Bake seemed natural, until I remember that no one touched it in a year or two. Beside, I can only stretch NIH so far :-). And while I know that people rave about rake, I did not want to introduce a Ruby dependency on my build system. I know that it was an annoyance when I had to build Fluent NHibernate.

One thing that I knew that I am not willing to go back to was editing XML, so I started looking at other build systems, ending up running into PSake.

There are a few interesting things that reading about it brought to mind. First, NAnt doesn’t cut it anymore. It can’t build WPF applications nor handle multi targeting well. Second, I am already managing the compilation part of the build using MSBuild, thanks to Visual Studio.

That leave the build system with executing msbuild, setting up directories, executing tests, running post build tools, etc.

PSake handles those well, since the execution environment is the command line. The syntax is nice, just enough to specify tasks and dependencies, but everything else is just pure command line. The following is Rhino Mocks build script, using PSake:

properties { 
  $base_dir  = resolve-path .
  $lib_dir = "$base_dir\SharedLibs"
  $build_dir = "$base_dir\build" 
  $buildartifacts_dir = "$build_dir\" 
  $sln_file = "$base_dir\Rhino.Mocks-vs2008.sln" 
  $version = "3.6.0.0"
  $tools_dir = "$base_dir\Tools"
  $release_dir = "$base_dir\Release"
} 

task default -depends Release

task Clean { 
  remove-item -force -recurse $buildartifacts_dir -ErrorAction SilentlyContinue 
  remove-item -force -recurse $release_dir -ErrorAction SilentlyContinue 
} 

task Init -depends Clean { 
    . .\psake_ext.ps1
    Generate-Assembly-Info `
        -file "$base_dir\Rhino.Mocks\Properties\AssemblyInfo.cs" `
        -title "Rhino Mocks $version" `
        -description "Mocking Framework for .NET" `
        -company "Hibernating Rhinos" `
        -product "Rhino Mocks $version" `
        -version $version `
        -copyright "Hibernating Rhinos & Ayende Rahien 2004 - 2009"
        
    Generate-Assembly-Info `
        -file "$base_dir\Rhino.Mocks.Tests\Properties\AssemblyInfo.cs" `
        -title "Rhino Mocks Tests $version" `
        -description "Mocking Framework for .NET" `
        -company "Hibernating Rhinos" `
        -product "Rhino Mocks Tests $version" `
        -version $version `
        -clsCompliant "false" `
        -copyright "Hibernating Rhinos & Ayende Rahien 2004 - 2009"
        
    Generate-Assembly-Info `
        -file "$base_dir\Rhino.Mocks.Tests.Model\Properties\AssemblyInfo.cs" `
        -title "Rhino Mocks Tests Model $version" `
        -description "Mocking Framework for .NET" `
        -company "Hibernating Rhinos" `
        -product "Rhino Mocks Tests Model $version" `
        -version $version `
        -clsCompliant "false" `
        -copyright "Hibernating Rhinos & Ayende Rahien 2004 - 2009"
        
    new-item $release_dir -itemType directory 
    new-item $buildartifacts_dir -itemType directory 
    cp $tools_dir\MbUnit\*.* $build_dir
} 

task Compile -depends Init { 
  exec msbuild "/p:OutDir=""$buildartifacts_dir "" $sln_file"
} 

task Test -depends Compile {
  $old = pwd
  cd $build_dir
  exec ".\MbUnit.Cons.exe" "$build_dir\Rhino.Mocks.Tests.dll"
  cd $old        
}

task Merge {
    $old = pwd
    cd $build_dir
    
    Remove-Item Rhino.Mocks.Partial.dll -ErrorAction SilentlyContinue 
    Rename-Item $build_dir\Rhino.Mocks.dll Rhino.Mocks.Partial.dll
    
    & $tools_dir\ILMerge.exe Rhino.Mocks.Partial.dll `
        Castle.DynamicProxy2.dll `
        Castle.Core.dll `
        /out:Rhino.Mocks.dll `
        /t:library `
        "/keyfile:$base_dir\ayende-open-source.snk" `
        "/internalize:$base_dir\ilmerge.exclude"
    if ($lastExitCode -ne 0) {
        throw "Error: Failed to merge assemblies!"
    }
    cd $old
}

task Release -depends Test, Merge {
    & $tools_dir\zip.exe -9 -A -j `
        $release_dir\Rhino.Mocks.zip `
        $build_dir\Rhino.Mocks.dll `
        $build_dir\Rhino.Mocks.xml `
        license.txt `
        acknowledgements.txt
    if ($lastExitCode -ne 0) {
        throw "Error: Failed to execute ZIP command"
    }
}

It is about 50 lines, all told, with a lot of spaces and is quite readable.

This handles the same tasks as the old set of scripts did, and it does this without undue complexity. I like it.