Registering a mock/stub with Windsor

I have some code that uses Castle Windsor to retrieve instances this helps to manage dependencies that I don’t have to worry about, the side effect of this is that when performing unit tests against the code that needs to get an instance from Windsor I want to provide a way to inject a mock/stub object is can be accomplished with the following:


To help reduce the amount of code in my test setups I usually have this method in my Unit Testing base class

protected void RegisterDependencyAgainst(TInterface instance)

Which is then called like this:

// in setup method
mockFoo = MockRepository.CreateMock();

Getting to grips with NHibernate: Stored Procedures Redux

Update: Due to popular demand I have included using stored procedures for insert/update/delete

I hope this post saves someone the amount of time it took me to try and run a stored procedure using NHibernate.

Selecting from a Stored Procedure

Create Stored Procedure

The first step is to create your stored procedure, if we take a basic example:

	@LastName VARCHAR(255) = NULL,
	@FirstName VARCHAR(255) = NULL

	FROM Staff s
	WHERE (s.LastName LIKE @LastName OR @LastName IS NULL)
	AND (s.FirstName LIKE @FirstName OR @FirstName IS NULL)
	ORDER BY FirstName, LastName



Create a named query

In order for NHibernate to be able to run the stored procedure, we need to create a named query, in our hbm file:

	exec SearchStaff :LastName, :FirstName

In this example because the stored procedure is actually returning a staff object I set the return to the Staff class, if I was only returning something like an integer value I could use the following:

    exec StaffCount :LastName, :FirstName

The name does not need to be the same name as the stored procedure.

Create the NHibernate code

// session set here

IQuery searchQuery = session.GetNamedQuery("StaffSearching")

if (!string.IsNullOrEmpty(LastName))
	searchQuery.SetString("LastName", LastName);
    searchQuery.SetString("LastName", null);

if (!string.IsNullOrEmpty(FirstName))
    searchQuery.SetString("FirstName", FirstName);
    searchQuery.SetString("FirstName", null);

IList foundStaff = searchQuery.List();

Notice that the stored procedure can deal with or without filtering, so if the fields have not been set we can simply set them to a null value and NHibernate will pass the parameters as a NULL which is what we want.It’s worth noting that the above is quite a simple example and that for the above I would not use a stored procedure and instead just use NHibernates own querying objects. The case were I used a stored procedure was for a paging routine for SQL server 2000.

Using Stored Procedure for Insert, Update & Delete

Create Stored Procedures

	@LastName VARCHAR(255),
	@FirstName VARCHAR(255),
             @EmailAddress VARCHAR(512)
             INSERT INTO Staff

Note: SET NOCOUNT is not set for these stored procedures

I’m not going to include the SQL for the update and delete stored procedures as I don’t think it adds any value, and is the easy part.

Update NHibernate XML Mapping

We need to tell NHibernate the SQL we want to execute for our insert/update/delete, we do this inside the class element:


    EXEC InsertStaff ?,?,?
    EXEC UpdateStaff ?,?,?,?
    EXEC DeleteStaff ?


  • The last parameter will be the id for the update.
  • The ordering of the parameters is determined by NHibernate, so the best way to find out the ordering would be to view the generated SQL, bit pants but hay ho.

Your code will remain the same, so no changes needed there.

Rounding with decimal.Round()

The decimal.Round() method has 4 different overloads:

  1. Accepts just decimal value and rounds it to an integer.
  2. Accepts a decimal value plus an int which is used to round to a certain amount of decimal places.
  3. Accepts a decimal value and an enum that specifies how the rounding should be performed.
  4. Accepts a decimal value, an int which is used to determine the number of decimal places to round to and also an enum that specifies how the rounding should be performed.

The last overload is the one I want to explain as this is where the need to know different strategies for rounding come in.

The first 2 overloads use a strategy of rounding called ‘to even’ or ‘bankers rounding’.

To Even

With this type of rounding strategy the decimal value will be rounded to the appropriate number of decimals and if the proceeding value is a 5 and there are trailing zeroes the preceding value will be rounded to the nearest even number, this essentially means that it could be rounded up or rounded down

e.g. if we had this value 2.345 and we wanted to round the 2 decimal places we would get 2.34 however if we had 2.355 and wanted to perform the same rounding we would get 2.36. Also given the rule about applying it when there are only trailing zeroes if we had 2.34501 unlike the other result we would in fact get 2.35 due to the non trailing zeroes.

The reason this rounding is known as bankers rounding is because it is used a lot in financial calculations to more evenly distribute the rounding results instead of the bias you get with the ‘away from zero’ strategy.

Away from zero

This is the strategy I remember being taught at school and is a simpler strategy that basically means that if your rounding and the proceeding value is a 5 then the preceding value gets rounded away from zero.

e.g. if we had this value 2.345 and we wanted to round the 2 decimal places we would get 2.35 and if we had 2.355 and wanted to perform the same rounding we would get 2.36.

Specifying the rounding strategy

As pointed out before the default is to perform ‘to even’ you can however use the 3rd & 4th overloads to pass in an enum called MidpointRounding this contains 2 values:

  • ToEven
  • AwayFromZero

Further Information

Multiple instances of same windows service

There are times were you want to be able install multiple instances of the same windows service onto the same server (i.e. to support different environments but you have limited servers at your diposal) this poses a problem, you are probably aware windows will not allow more than 1 windows service to be installed with the same service name and when you create a windows service project and an installer you assign the service name at design time.

We need is someway to assign the service name at runtime, well after some extensive googling around I found a way of achieving this, the ProjectInstaller has 2 methods you can override Install and Uninstall which enables us to make changes to the service installer at the at runtime 🙂 Yeah that’s great however how do we assign the service name?! Fear not! at our disposal is the Context class that happens to have a Parameters dictionary so we can now capture custom command arguments passed to installutil.exe, enough yapping time for some code:

public override void Install(System.Collections.IDictionary stateSaver)

public override void Uninstall(System.Collections.IDictionary savedState)

private void RetrieveServiceName()
	var serviceName = Context.Parameters["servicename"];
	if (!string.IsNullOrEmpty(serviceName))
		this.SomeService.ServiceName = serviceName;
		this.SomeService.DisplayName = serviceName;

In this instance I have made the servicename argument optional in which case it will use the default assigned at design time, you could enforce it in your version.

We can now use this like this:

installutil /servicename=”My Service [SysTest]” d:\pathToMyService\Service.exe

and for uninstall:

installutil /u /servicename=”My Service [SysTest]” d:\pathToMyService\Service.exe

Note for the uninstall you need to supply the servicename so windows how to resolve the service to uninstall

One thing that suprises me is how hidden this implementation is, most results bring up people wanting the same functionality and being told it ain’t possible and articles that suggest messing with config files this to me seems to be a much simpler and nicer way to achieve multiple instances.

Enforcing Conventions

In my last post I demonstrated adding AOP to cut down on cross cutting code, and at the end mentioned that it would be nice to enforce a convention throughout the system, the example being each public method in the task layer being decorated with a certain attribute.

I was unsure about how to do this until recently seeing a post by Ayende in it he references an article by Glenn Block whereby both of them came up with a unit test called PrismShouldNotReferenceUnity in the test they use reflection to check that there are indeed no references from the Prism assembly to the Unity assembly.

This is a great idea! You now have a repeatable test that can be run to make sure the conventions for your system are met, so armed with this technique I created the following test:

public void task_class_methods_should_be_marked_with_wrap_exception_attributes()
        Assembly asm = Assembly.LoadFrom( "MCromwell.StaffIntranet.Task.dll" );
        var wrapExceptionType = asm.GetType( "MCromwell.StaffIntranet.Task.Infrastructure.WrapExceptionWithAttribute" );

        foreach (Type current in asm.GetTypes())
            if (current.FullName.StartsWith( "MCromwell.StaffIntranet.Task.Tasks." ) && (!current.IsInterface) && (!current.IsAbstract))
                foreach (var method in current.GetMethods())
                    if ((method.IsPublic) && (method.DeclaringType.Name != "Object"))
                        if (method.GetCustomAttributes(wrapExceptionType, false).Length <= 0)
                            Assert.Fail("no wrap exception attribute found on type '{0}', method '{1}'", current.FullName,method.Name);
    catch (ReflectionTypeLoadException rex)
        foreach (var current in rex.LoaderExceptions)
    catch (Exception ex)

In here you can see by leveraging reflection I can browse all the public methods for my task layer classes and make sure they do indeed have a WrapExceptionWithAttribute the other cool thing is that by doing it this way I can freely add new classes and they will need to comply with the conventions set out or the testing will fail, cool eh!

One thing to point out is that if you start increasing the number of conventions and want a better way to control and report on, you probably want to look into something like FXCop or NDepend’s CQL.

Adding AOP to Staff Intranet

Because I’m a stickler for good code I put exception handling into my task layer and wrap any exception that may be raised from the data access layer into an appropriate exception for the task layer and also log the exception, because of this I end up having lots of unit test code that looks similar to make sure I’m enforcing this rule:

public void Should_log_exception_if_exception_is_raised_when_deleting_session()
    Guid id = Guid.Empty;
    IAdministrationRepository mockRepository = CreateMock();

    IServiceResolver mockResolver = CreateMock();
    ILog mockLog = CreateMock();
    Exception mockException = new Exception( "mock ex" );

    using (Record)
                   .Return(new LoginSession(id));

    using (PlayBack)
            IAuthenticationTask sut = createSUT(mockRepository);
        catch { }

And to fulfill this I then end up with cross cutting code to meet the test behaviour:

    //... work here
catch (Exception thrownException)
    throw new ProblemSavingStaffMemberException(thrownException);

To try and cut down on this cross cutting code and to keep the tasks more lean I did some investigation into some AOP strategies.

My first reaction was… I’m using Castle Windsor so can I utilize it’s built in AOP capabilities after changing some code and adding an interceptor I quickly found out this won’t be possible as it doesn’t support out or ref parameters and due to some of my task layer method using out parameters to pass back a notification object this choice was gone!

Next up I had a look at PostSharp the difference between them being that PostSharp adds code in after compilation whereas Windsor dynamically creates proxies at runtime. After looking at some examples I had an idea as to how to implement it so after installing PostSharp I created my object that will inject itself into other objects:

public class TaskExceptionHandlerAttribute : OnMethodBoundaryAspect
    public override void OnException(MethodExecutionEventArgs eventArgs)
        Exception thrownException = eventArgs.Exception;
        WrapExceptionWithAttribute wrapExceptionAttribute = RetrieveWrappingExceptionAttribute(eventArgs.Method);
        if (wrapExceptionAttribute != null)
            Type exceptionToWrapWith = wrapExceptionAttribute.WrapExceptionType;
            Exception exceptionToThrow = (Exception)Activator.CreateInstance(exceptionToWrapWith, thrownException);
            if (exceptionToThrow != null)
                throw exceptionToThrow;
        throw new TaskLayerException(thrownException);

    private static WrapExceptionWithAttribute RetrieveWrappingExceptionAttribute(MethodBase method)
        WrapExceptionWithAttribute wrapExceptionAttribute =
        return wrapExceptionAttribute;

    private static void LogException(Exception thrownException)
        ILog log = IoC.Resolve();

In order to not have to place this object as an attribute on all the different task classes I can use the assembly attribute and give it a target using a name plus a wildcard:

[assembly: TaskExceptionHandler(AttributeTargetTypes="MCromwell.StaffIntranet.Task.Tasks.*")]

And that’s it my methods are now injected with the PostSharp code after compilation to handle exceptions and at which point it will call my custom code very cool!

One thing you may have noticed is the use of another attribute that can be decorated on the task methods WrapExceptionWithAttribute this attribute takes a Type in it’s constructor this Type is the exception that should wrap the thrown exception ideally we would like this attribute to be placed on all public task class methods so that we raise applicable exceptions depending on the task be performed although how do we enforce this convention?…

In my next post I will be demonstrating a technique that allows to enforce these types of conventions we want for our systems.

Reduce repetitive code writing

Start using the built in code snippets included with VS2005/VS2008 (Lucky users with R# disregard!) I have found them invaluable for saving time writing boiler plate test fixtures and test cases, instead of having to write out:

 [TextFixture] public class When_() 

I can simply type testfixture plus tab, below is the xml for the example above:

        Code snippet for a textfixture class
        Mike Cromwell
                 Class name

Most of it is self explanatory, the SnippetType can be one of the following:

  • Expansion – The snippet can be added were the cursor is
  • WithSurrounds – The snippet will surround any selected code
  • Refactoring – The snippet can only be applied during a C# refactoring

To enable them in the intellisense for VS you can locate the My Snippets folder or by adding a new snippet location via the Snippets Manager under Tools. Once you have the location you simply need to create a new text file and give a .snippet extension, you can then add in the XML using the schema shown above, when you go back to VS you should see the snippet listed using the Shortcut value.

The msdn site has more details on the snippet schema reference