Custom Matcher using Lambdas for NMock2

•November 20, 2011 • 4 Comments

I’m not a great fan of NMock2 but I’m currently stuck with it for one of the projects I’m working with and I find this code useful:

Custom Matcher

You can create your own custom matcher instead of using the various classes in the NMock2.Is static class by inheriting from Matcher in the NMock2 namespace and overriding the required methods.

Below is a matcher that expects an object of type <T> and matches it by using an anonymous delegate or lambda passed to the constructor. You can use this if you have requirements for matching the parameter that are a little more complex than the basic packaged functionality allows. The example I give here is checking to see a couple of the properties on the object passed in sum up to a given value. Yes, it’s highly contrived but I’m sure you get the point…

    public class MatchWithLambda<T>: Matcher{
        private Predicate<T> _matcher;
        private Action<T, TextWriter> _describer;
        private StringWriter _descriptionWriter = new StringWriter();
        public MatchWithLambda(
            Predicate<T> matcher,
            Action<T, TextWriter> describer = null){

            if (matcher == null){
                throw new ArgumentNullException("matcher");
            _describer = describer;
            _matcher = matcher;

        public override bool Matches(object o){
            if (o is T){
                if (null != _describer){
                    _describer((T) o, _descriptionWriter);
                return _matcher((T) o);

            return false;

        public override void DescribeTo(TextWriter writer){

To use this, pass in a lambda that contains the ‘match’ logic to the constructor of the MatchWithLambda matcher.

The parameter passed to the mock or stub when the test is run is passed in to the lambda you supply and complex logic can be applied to see if it matches your expectations. The thing passed in to your lambda (x in this example) is typed by the T generic parameter so you don’t need to cast anything.

public class TestClass{
    public string FirstString = "";
    public string SecondString = "";
    public int FirstInt;
    public int SecondInt;

public interface IMockableClass{
    void DoStuff(TestClass testClass);

public void TestPassesWhenMatchFound(){
    var testObj = new TestClass{FirstInt = 10, SecondInt = 20};

    Mockery mockery = new Mockery();
    var mocked = mockery.NewMock<IMockableClass>();
    //Check if DoStuff is passed a TestClass with
    //properties that sum to 30
        new MatchWithLambda<TestClass>(
            x => x.SecondInt + x.FirstInt == 30)



If you like, you can also pass in an action that will be used to describe why the parameter given did not match with your expectations. Again, you just pass it into the constructor.
An example of its use:

public void TestFailsBecauseSumOfPropertiesNotAsExpected(){
    var testObj =
        new TestClass{
                         FirstInt = 10,
                         SecondInt = 20,
                         FirstString = "Wibble"

    Mockery mockery = new Mockery();
    var mocked = mockery.NewMock<IMockableClass>();

        new MatchWithLambda<TestClass>(
            //Matcher function checks for properties summing to 40
            x => x.SecondInt + x.FirstInt == 40,
            //this lambda is called when a match fails
            //so that a description of the reason for
            //failure can be outputed
            (objectToMatch, describerWriter) =>
                    "Test thingy {0} didn't match as sum was {1}.",
                        objectToMatch.FirstInt + objectToMatch.SecondInt)))



You don’t need to pass a describer if you don’t want but it might help you to debug what went wrong in your test quickly if you do. The example of the failing match above, for instance, spits out this:

Hashtable constructor throwing an exception!

•March 23, 2011 • Leave a Comment

This has to be one of the weirdest bugs I’ve ever had to track down and fix. Check out this stack trace:

Yes, that’s right, a call to the default Hashtable constructor is throwing an ArgumentOutOfRangeException with a message of “Load factor needs to be between 0.1 and 1.0.”.  Where do you even begin with that one?

To make it particularly baffling this error just started occurring without the software being upgraded. The initial thoughts were a virus messing up the system, or a virus scanner causing issues. However there was no virus scanner operating (the machine is on a secure network and shouldn’t really need one…. yea, I know…) and there didn’t appear to be any virus. maybe the hardware had started to fail? A memory issue perhaps? But then it started happening elsewhere too. Upgrading the .Net runtime didn’t seem to help, and in fact some of the machines already had the latest runtime – which should have raised a flag actually, these machines are servers in a server room and run only our software. We don’t upgrade them without upgrading our software as well so some of these machines were being upgraded with the latest patches without us realising. To be fair our first response when we find an issue is “upgrade to the latest runtime and install all patches” so it is to be expected. The point is though, the runtime was upgraded but our software wasn’t. This shouldn’t be a problem but it was…

There is a bit of a clue to what is going on here – although we are calling the default constructor the framework is calling an overloaded constructor that takes 2 arguments, the first being an initial capacity and the second being a floating point value for the load factor for the hashtable (which has to do with the likelihood of there being collisions between unique hashes). That floating point is going to be important in a moment…

Checking with Reflector we can see that calling the default constructor calls the second constructor with a hardwired value of 1f:

Can’t see a problem there. Just to make sure I’m not barking mad, what does reflector say this constructor does?

public Hashtable(int capacity, float loadFactor)
  if (capacity < 0)
    throw new ArgumentOutOfRangeException("capacity", .....
  if ((loadFactor < 0.1f) || (loadFactor > 1f))
    throw new ArgumentOutOfRangeException("loadFactor", .......
 this.loadFactor = 0.72f * loadFactor;

Clearly, 1 is not greater than 1 – so what on earth is going on? It would seem the computer has forgotten how to do floating point maths…. This is the point where I have to mention that we are calling into a delphi dll in this project using P/Invoke. Delphi is well known for messing about with the floating point control register. A problem with one being greater than one you say? Delphi you say? hmm….

Time to break out the debugger of last resort and find out what’s going on. It’s WinDbg time.

I managed to get a reproduction at will by creating a thread that sat in a tight loop doing nothing other than new Hashtable(). After a couple of minutes this would cause the exception I was looking for so at least I didn’t have to rely on clients generating a dump file for me. I’m creating a dump file here instead of just attaching the windbg debugger because it’s simply easier. I can load the dump file whenever I like and don’t need to leave the system running in between debugging sessions.

First things first, what’s the exception exactly? Using !printexception I got this:

0:040> !printexception
Exception object: 22692da4
Exception type: System.ArgumentOutOfRangeException
Message: Load factor needs to be between 0.1 and 1.0.
StackTrace (generated):

HResult: 80131502

OK, that’s already known so nothing useful there then. What’s the stack trace for that thread got to say for itself?

0:040> !clrstack
OS Thread Id: 0x1ea8 (40)
2e4be7d4 7713b727 [HelperMethodFrame: 2e4be7d4]
2e4be878 6fa3993a System.Collections.Hashtable..ctor(Int32, Single)
2e4be89c 6f30165c System.Collections.Hashtable..ctor()
2e4be8a0 0040c128 Probel.Automation.EventStore.Impl.ModelObjectChangesCollection..ctor(…)
2e4be8c4 003c882e Probel.Automation.EventStore.RootImpl.Notify(…)
2e4bea3c 003c8217 Probel.Automation.EventStore.RootImpl.NotifyWriteComplete(…)
2e4bea70 003c7c46 Rescale.RescaleModel.EndWrite(…)
2e4beaf0 04c66d3d Rescale.Classic.ModelManager.EndWrite(…)
2e4bebbc 04c6692d Rescale.Classic.ReadWriteAccessor.Dispose()
2e4bec08 04c66872 Rescale.ReadWriteAccessor.Dispose()
2e4bec14 04bb7de7 Probel.Automation.EventStore.ClientFacing.ClientFacade.ExecuteWriteTransactionEx(…)
2e4bed34 04bb7ae4 Probel.Automation.EventStore.ClientFacing.ClientFacade.ExecuteWriteTransaction(Rescale.Priority, UInt32, UInt32, Probel.Automation.EventStore.ClientFacing.XaCallback, System.Object[])
2e4bed5c 04bef5bf Probel.Automation.EventStore.XmlExternalisation.XmlEventCopier.Paste(Probel.Automation.EventStore.ClientFacing.IClientFacade, Probel.Automation.Util.Oid, Probel.Automation.Util.Oid, Probel.Automation.Util.Oid, Probel.Automation.EventStore.XmlExternalisation.IPercentageComplete)
2e4beeb0 04beef56 Probel.Automation.EventStore.XmlExternalisation.XmlEventCopier.Paste(Probel.Automation.EventStore.ClientFacing.IClientFacade, Probel.Automation.Util.Oid, Probel.Automation.Util.Oid, Probel.Automation.EventStore.XmlExternalisation.IPercentageComplete)
2e4beed4 04beee80 Probel.Automation.MorpheusEditor.BackgroundLoader+PasteJob.Run()
2e4bef18 04beec7c Probel.Automation.MorpheusEditor.BackgroundLoader+ExecutableJob.ThreadProc()
2e4bef60 6f306e76 System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
2e4bef6c 6f3102ff System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
2e4bef84 6f306df4 System.Threading.ThreadHelper.ThreadStart()
2e4bf1ac 70841b4c [GCFrame: 2e4bf1ac]

The first thing about that stack trace that is instantly obvious is that this is not the stack trace of a thread creating Hashtables in a tight loop. So although there’s a thread creating potentially millions of hashtables a second, that’s not the thread that explodes. The second thing of interest is that there are a number of calls into Rescale code. That’s a wrapper around the delphi dll I was talking about so it looks like this exception may be happening on threads that are calling into delphi.

Out of interest I rewrote the code which caused the exception to occur repeatedly so as to create objects instead of hashtables and still got the issue. However, if I rewrote it to increment a variable instead the issue failed to arise so it looks like garbage collection may have something to do with it.

It’s obviously an issue with floating point maths so the first place to look would be the fpcw register. This is the register that controls how floating point operations are done by the FPU. Using ~*e .block{.printf “TID= %x\tfpcw=%x\n” ,@$tid, @fpcw}

however tells us that the fpcw is set to 27f on every thread. This is the value you would expect so that’s not the issue. That stumped me for a while but a bit of research into how floating point operations are done on an x86 architecture lead to me the SSE registers. These are ‘newer’ floating point registers that are not implemented on all processors. Actually they are by now since they started being put in around 1999 or so. The control register for the SSE registers is MXCSR. Lets find the value of that reg instead:

0:027> ~*e .block{.printf “TID= %x\tMXCSR=%x\n” ,@$tid, @mxcsr}

TID= 1b3c    MXCSR=1fa0
TID= 203c    MXCSR=1f80
TID= 1f14    MXCSR=1f80
TID= 924    MXCSR=1f80
TID= dac    MXCSR=1f80
TID= bbc    MXCSR=1f80
TID= 2258    MXCSR=1f80
TID= ad0    MXCSR=1f80
TID= db0    MXCSR=1f80
TID= ac8    MXCSR=1f80
TID= 225c    MXCSR=1fa0
TID= 21c0    MXCSR=1f80
TID= 920    MXCSR=1f80
TID= 1694    MXCSR=1f80
TID= 1f18    MXCSR=1f80
TID= 1810    MXCSR=1f80
TID= 107c    MXCSR=1f80
TID= 1cbc    MXCSR=1f80
TID= 2008    MXCSR=1f80
TID= 124c    MXCSR=1f80
TID= 10e4    MXCSR=1f80
TID= f00    MXCSR=1fa0
TID= 1730    MXCSR=1f80
TID= 220c    MXCSR=1f80
TID= 210c    MXCSR=1f80
TID= c44    MXCSR=1f80
TID= 10d4    MXCSR=1f80
TID= 1f44    MXCSR=1fa0
TID= 1310    MXCSR=1f80
TID= de0    MXCSR=1fa0
TID= cd8    MXCSR=1fa0
TID= 1708    MXCSR=1f80
TID= 185c    MXCSR=1fa0
TID= 1274    MXCSR=1f80
TID= 2198    MXCSR=1f80
TID= 20b4    MXCSR=1f80
TID= 20f8    MXCSR=1f80
TID= d04    MXCSR=1f80
TID= 1600    MXCSR=1f80
TID= 654    MXCSR=1f80
TID= 1ea8    MXCSR=1fa0
TID= 2034    MXCSR=1fa0
TID= 3f8    MXCSR=1f80

Now this is looking more interesting…

From the stacktrace we can see the thread Id for the thread that threw the exception is 1ea8. That thread has it’s MXCSR reg set to 1fa0 so this looks promising. Looking through the stack traces for all the threads showed a high correlation between threads with calls into the delphi dll in their stack and an incorrect MXCSR register. Unfortunately I was completely stumped as to what was setting the MXCSR reg. I even tried pushing and popping that register using assembler every time a delphi call was executed but that didn’t help. I’m guessing something in the delphi runtime sets and unsets that reqister but I can’t find it from disassembling the dll. Assembler isn’t my language of choice though so I was probably just missing the instruction. One of my colleagues suggested there might be an instruction for pushing and popping all registers so the MXCSR reg might not show up in the disassembly…

At this point I decided it was time to call microsoft and ask them if it was a problem with the framework or something we were doing. Thankfully our MSDN licences enable us to talk to their support people. They seemed to think it was a problem with delphi and not an issue for the dotnet runtime and suggested a number of options for trying to resolve the issue. The most obvious one, and the one we went with, was to only ever acccess the delphi dll from a dedicated (or number of dedicated) thread(s). This was a while ago now so I can’t remember if I used more than one thread for the rescale dll or not but we now execute all calls to the dll through a simple work queue. Push a work delegate onto the queue and it get processed as soon as possible in a separate thread that only ever deals with rescale. This resolved our problem. I’d still like to find out exactly what’s going on but I haven’t got the time to look into it any further. I’ve already spent far too long trying to resolve this.

It looks to me like microsoft were not originally using the sse registers in DotNet 2 but at some point decided that they were now ubiquitous enough to start using and added them to the JIT. We never had a problem with regular floating point values previously but for some reason the combination of Delphi and the DotNet runtime just don’t play nicely and one of them is not resetting the MXCSR register to what it should be when it is done with it. Thankfully that Delphi dll has now been replaced with a fully managed dll so this problem wont ever crop up again (I hope).

Debugging XAML Bindings

•March 2, 2011 • 1 Comment

First things first. Set up Visual Studio to emit binding information to the Output window.

Select Debug from the Application menu and choose “Options and Settings…”. Expand the Debugging node and select “Output Window”. Now in the right hand pane set the “Data Binding” value in WPF Trace Settings to at least Warning.

Now when the application is run up under the debugger binding information should be displayed in the Output window. If the Output window is not visible it can be opened by selecting View from the main menu and then selecting Output. If the binding information is still not being displayed then make sure the “Show Output From” dropdown has the correct value selected – you normally want “debug”.

If you’re still not getting enough information you can alter the trace level (in .Net 3.5 and above) in XAML by adding the System.Diagnostics  namespace to your XAML file:


and setting the trace level in the binding of interest like this:

    Color="{Binding Path=Color, 

If you’re still stumped you could always write a dummy IValueConverter that just returns the bound value. You can then set a breakpoint where the value is returned from the converter and check to see what’s going on:

public class DatabindingDebugConverter : IValueConverter {
  public object Convert(object value, Type targetType,
  object parameter, CultureInfo culture) {
    return value;

  public object ConvertBack(object value, Type targetType,
  object parameter, CultureInfo culture) {
    return value;

BadImageFormatException and Moq

•February 20, 2011 • Leave a Comment

I’m just trying out Moq at the moment and kept getting a BadImageFormatException when running my unit tests (NUnit) with resharper in VS2010. It turned out to be an issue with the new default build configurations when using VS2010.

I’m pretty sure everything used to be set to ‘Any CPU’ as default. For some stupid reason the default is now ‘x86′ (at least for a new .Net4 WPF project). The class library project I had created to put my unit tests in was configured by default to ‘Any CPU’ though.

I switched my debug build to build the WPF project as ‘Any CPU’ and Moq was happy.

Some basic Git commands

•February 18, 2011 • Leave a Comment

This is just a place for me to put all my commonly used Git commands so that I don’t have to go hunting on google every time. If  it’s of use to you then great – if I’m doing anything in a way that could be improved then please let me know. When it comes to Git I’m a newbie.

If you’re looking for THE place for information on using git may I humbly suggest this.

Configuring Git:

Set the default user identity for commits

git config --global "Russell Troywest"
git config --global

Set commit message editor to Notepad++

git config --global core.editor="'/cygdrive/c/Program Files (x86)/Notepad++/notepad++.exe' -multiInst
-notabbar -nosession -noPlugin"

My .gitignore file

To get a copy of an existing repository:

Switch to the directory you wish to use as the parent of the repository and execute

git clone <repository name>

To create a new repository:

Switch to the directory you wish to put under version control and initialise it with git init. Then add all the files you wish to put under git control, followed with a commit command. I normally put my .gitignore file in the directory to put under control and then just use add --all before commiting. Like this:

git init
git add --all
git commit

Create a remote “Origin” repository for collaboration:

Initialise a directory with a bare repository on the remote machine you wish to use as your “main” repository. Then switch to your local directory containing the git repository you wish to share. Add a remote branch to the local repository and then push the local branches you wish to share up to the remote.

On remote machine in directory that will hold repository:

git init --bare myproject.git

On the local machine that contains the git repository to share:

git remote add origin ssh://<remote repository dir>
git push origin master
git branch --set-upstream master origin/master

The first line creates a remote branch called origin with the url given. The second line pushes everything already in the master branch of the local repository to the origin/master branch and then pushes that up to the actual remote server (or at least I think that’s how it works). Remember, even remote branches are stored locally and are synced when you push/pull/fetch. I find it all horribly confusing so I just pretend the remote branches really are just remote. The third line tells git the local branch master is tracking the remote branch origin/master. This allows you to get extra information when using “git status” on the master branch. It will tell you if you’re a few commits ahead of remote etc.

Switch to a specific commit/tag

Use git log to find the commit you want to switch to and get the first few characters of the commit key. Like this:

In this case, if I wanted to switch to the commit that added a background image to the main window, I would use 6cc8e as the commit to switch to. I would then use

git checkout -b newBackground 6cc8e

to switch to a new branch called newBackground with it’s HEAD (current commit) set to 6cc8e. ie, you would be in a new branch with your working directory set to exactly how it was for that commit. You can then work on it and commit changes if you like as the changes will be committed to the new branch. If you wish to switch back to where you were you can just switch back to your master branch by using

git checkout master

If you want to use an existing branch but reset it to the commit you choose then use -B instead of -b. Instead of creating a new branch it will clear the state of the old branch and replace it with the commit you select.

Creating a Tag

To tag a commit with a name and a message you can use the command

git tag -m "<Message>" <tagname> <commit to tag>

In the previous example to do with checking out a specific commit I could have tagged that commit with something like

git tag -m "commit that updated background" newBackground 6cc8e

I could have then used newbackground in the checkout command instead of 6cc8e.

Altering the last commit

Add whatever you forgot to the index and then commit again using:

git commit --amend

This will add whatever you forgot to the previous commit. Don’t do this if you’ve already pushed your commit to a master repo.

My default .gitignore file for c#:


Who needs codebehind when you’ve got MVVM?

•February 14, 2011 • Leave a Comment

I’ve been working with WPF lately and have been rather enjoying it. The testability and cleanness of logic/gui separation when using MVVM really does make life easy. So I thought I’d set myself a  small challenge:

Can I write a fully functional game of tetris without a single line of code in the code behind files?

Everything will be done in a ViewModel and bound to the GUI in XAML. I don’t actually think this will be all that hard – it would be simple if I allowed myself a few lines of code in the codebehind (the sensible thing to do). But I’m interested to see if I can do it without a single line of extra code (I will need the Visual Studio generated code).

Obviously using MVVM for the sake of using it is missing the point a bit. MVVM is a great pattern that should be followed when it makes sense. Some of the things I’m going to do with this tetris game probably wont make a whole lot of sense as it would be far quicker and easier to just have a couple of lines of code in the code behind. Code behind isn’t always bad, just most of the time. Still, it’s an interesting experiment to see just how far the MVVM pattern can be stretched.

Basic Setup

I’m going to need some external frameworks to do this properly. Firstly I’m going to need a dependency injection framework. There are a pile out there but I’m settling on Ninject for this project as it’s lightweight, easy to use, and surprisingly fully featured for such a lightweight tool. They also have a cool website with ninjas…. (make sure you get the non-web version for this project)

Since this project is slightly larger than a hello world app I’m going to need a unit testing framework. For this I’m going to use NUnit, solely because that’s what I use at work. I might need a logging framework later, in which case I’ll probably add in log4Net.

With unit testing and dependency injection comes the need to use a mocking framework (unless you want to make life hard for yourself). If you’re not using MVVM, dependency injection, unit testing and a mocking framework for your WPF apps then you really should think about doing so. It makes your life so much easier and the learning curve is nowhere near as large as you might expect. For this project I think I’m going to use Moq as I’ve heard good things about it and have been meaning to try it for a while.

Source Control

Now I’m ready to start it’s time to put everything into version control. I’m loving Git at the moment so that’s what I’ll use. If you’re interested in looking at the source you can get it by pulling it down from my git repository:

If you’ve never used git before it’s easy – just install it on your PC (I used cygwin – really easy setup). Once it’s installed you will need to open the shell, navigate to the directory you wish to put the project in and then clone it like this:

git clone