Archive for the ‘c#’ Tag

Behaviour driven development on user interfaces with Automation peer

Testing user interfaces is usually a pain in the butt. No matter how cool your UI is, it will often boil down to a brain-cell killing process clicking the same buttons over and over again. Thanks to the Geek Gods of .Net though, there are ways to automate this, and it’s not even that tough to do.

In this post, we’re going to use Automation peers to expose a button to a unit test, and have the test start the application, click the button, and confirm that the button does what it’s meant to do. We’re going to use MbUnit to write the test, and NBehave to make the tests nice and clear.

Continue reading


Validating attribute usage with PostSharp Aspects

This post expands on my previous article on PostSharp. If you haven’t already, read it here

Most of January has flown by with just one post, effectively shooting down my resolution to blog more often. In my defence, I have to state that I’ve just moved on to newer pastures, with all the re-settling in that involves.

Apart from that, I also spent a few hours twiddling with the Jasema sources, so I do have something to post about at least. 🙂

The .net attribute architecture supports an Attribute Usage definition, which is itself an attribute that can be applied to attributes. AttributeUsageAttribute determines whether said attribute can be applied to fields, methods, classes, assemblies, or any combination thereof. This allows you to identify, at compilation time, whether the attributes you have specified are used correctly, which is great.

There are situations, however, where you might want to enforce some more detailed constraints on an attribute; for example, you might want to make sure that it is only used by classes that implement a given interface, or check what parameters have been defined for it.

It is possible to implement this as a runtime check within the attribute itself, however this is not always a very elegant solution. If you check the constraints every time the attribute is invoked in some way, you’re incurring a performance hit, however slight. If one considers that PostSharp aspects may be called every time data changes in a given field, or every time a method (or even any method in an assembly is called), this may add up to quite a bit, depending on what sort of checking you’re doing.

By making this sort of check at run time, you’re also depriving yourself of compile time checking. Even if you have unit tests in place to make sure you catch incorrect behaviour. it can still take time to run the suite; wouldn’t it be a lot nicer if the compiler could be instructed to raise an error when an attribute is given the wrong parameters, or is used with the wrong sort of class?

While PostSharp aspects don’t allow you to give such instructions to the compiler, they do allow you to do something that’s so similar that the difference, to someone like me, is purely academic (so, flame me). These aspects define an OnCompileValidate method, which can be overridden in your custom aspects.

The PostSharp compile-time weaver calls these methods while weaving your aspects into the code, so you can place your validation there; this gives you the advantage of having checks run once only (hence, without impact on executing code). Consider the source below:

public override bool CompileTimeValidate(System.Reflection.MethodBase method) 
    if (string.IsNullOrEmpty(fieldName)) 
        throw new InvalidOperationException( 
                "ListContentChangeRecorderAttribute requires the name of a field which implements IList. Failed on {0}.{1}", 

    MemberInfo[] matchingFields = method.DeclaringType 
            BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Static, 

    if (matchingFields.Length < 1) 
        throw new InvalidOperationException( 
                "ListContentChangeRecorderAttribute could not find field {0}.{1}", 

    // Determine whether the type that defines the field implements the requested interface. 
    if (!AttributeHelper.ImplementsInterface(((FieldInfo)matchingFields[0]).FieldType, typeof(IList))) 
        throw new NotSupportedException(string.Format( 
            "{0}.{1} does not implement IList.", 

    return base.CompileTimeValidate(method); 

This code, from the custom attributes controlling undo/redo functionality in Jasema v2 (coming soon), runs a few checks on the arguments provided for the attribute at construction: first, it makes sure that the field name argument is not empty, and that the field specified there is an actual existing field in the class which declares the method decorated with this attribute. Finally, using some helper code, it makes sure that the field implements IList, a requirement imposed on it by the logic of the aspect. This sort of checking would take some performance away from the application if it was to run repeatedly, but in this way, it only ever needs to run once – since attribute arguments must be constants, you can safely assume they won’t change after compilation.

Note that although CompileTimeValidate returns a bool type, I’m throwing an exception rather than returning false if the check decides there is something wrong. This is a matter of personal preference. The default behaviour for the weaver appears to be a silent failure; that is, if an aspect fails its validation check by returning false, it is simply omitted. Since I used aspects for a specific reason, I’d much rather have them ring all sorts of bells and raise all sorts of alarms if something is wrong, rather than failing silently and leaving you to scratch your head wondering why your masterfully crafted, world conquering AOP application is not doing what you thought it was supposed to do.

Mind you, the silent failure behaviour was probably introduced to allow the use of PostSharp‘s multicast aspect functionality (like applying an aspect to all methods in an assembly starting with an “F”). This would have been rather unwieldy if it broke the build every time it encountered a situation it didn’t quite support.

So in my case here, for example, I can’t multicast this aspect, but that’s perfectly ok by me because I only intend to use it explicitly. If you think you need to have an attribute capable of multicasting safely, then simply have it return false on failure. You may also be able to get the best of both worlds by making sure that all the classes that can support your attribute have a similar name pattern, but personally that’s where I start going glassy eyed and start drifting off into massively-overlong-classname induced nightmares.

AOP using PostSharp LAOS

Recently, I came across PostSharp, an excellent open source framework for .net. Among the great set of toys which it brings along is LAOS, an Aspect Oriented Programming solution which works very neatly.

Aspect oriented programming is quite a tricky subject to explain in short, so I won’t. While it’s an oversimplification, for the purposes of this post, we will just say that it is a technique where you intercept the control flow as it passes from one block to another, and attach non-default behaviour at these points.

PostSharp provides a mechanism which lets you define attributes to specify this behaviour; you can then decorate an assembly, class, method or field with these attributes. The specific methods you overload will then be triggered accordingly.

As an example, we’re going to add a logger to a method. Yes, it’s pretty boring – 99.99% of the AOP discussions on the web use this scenario as an example. However, I just want to demonstrate how to use these attributes, so no need to rock the boat yet. (If you’re feeling adventurous, visit Manageability for a couple of ideas on what else you can do with AOP).

Let’s say that we want to write a log message every time that an exception is thrown from a method. Since we’re going to use this attribute to handle something that has to do with a method, we’re going to use the OnMethodBoundaryAspect attribute as a base. Among others, this attribute exposes an OnException method, which is just what we need:


Like all interception methods exposed by OnMethodBoundaryAspect, OnException accepts a MethodExecutionEventArgs parameter. This gives us access to a lot of useful fields, among others, the name of the method being executed before interception (and all its reflected details), any parameters that were passed to the method, and the full details of the exception. This is especially handy when trying to re-create an exception.

Note the value being set in eventArgs.FlowBehavior. FlowBehavior.Continue tells the application to digest the exception and go on. Not, I must say, the smartest thing to do in all cases; in fact, I’d be dead set against finishing such an intercept this way in most cases. It’s been set that way for the purposes of the example application, where I want and expect an exception to be thrown half-way.

One other possible value of FlowBehaviour which I would like to mention briefly is the Return value. This makes the intercept digest the exception in the same way as Continue, but also allows us to set the MethodExecutionEventArgs.ReturnValue property. In this way, we can return a default value after an exception.

To actually make our new attribute DO something, we have to apply it to a method. We have a number of ways we can do this. If we want, we can specifically apply the attribute to a method (the parameter in the attribute is a constructor parameter for the attribute – refer to the source code attached):


We can also apply an attribute to all methods in a class:


Even more neatly, we can specify an expression that identifies a selection of methods within a class. For example,


The named property tells the attribute that it should apply to all methods and fields in the decorated class where the name starts with “MyLogged”.

Yet another option is to specify the attribute at an assembly level… but if you plan to do that, you really should move on to the actual PostSharp documentation 😛

The source code extends some more methods from the OnMethodBoundaryAspect attribute. You will need to install PostSharp to build the code.

kick it on

C# 3.0 – Linq queries and Implicit Types

Finally played a bit with Linq today. About time, a lot of people will say, and rightly so. Just dipping my toes right now: wrote a short console application to list all current processes running more than 5 threads (no real use – just playing).

The whole thing was pleasantly intuitive, and the script is shown in its entirety below:

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Diagnostics; 
using System.IO;  

namespace MyFirstLinq 
    class Program 
        static void Main(string[] args) 
            Process[] processes = Process.GetProcesses();  

            var query = 
                from process in processes 
                    process.Threads.Count > 5 
                orderby process.Threads.Count descending 
                select new { process.ProcessName, process.Threads.Count };  

            foreach (var result in query) 
                Console.WriteLine("{0} ({1} threads)", 


While writing this, I also had a look at the implicit type declaration (the var keyword in the code) – already ran into this while talking to Marlon the C# Monk a few days ago (thanks again for taking the time to explain stuff – helps loads!). This form of declaration looks extremely handy – you get the benefits of strongly typed return values, without the hassle of having to write several small classes that are unlikely to be used anywhere else, ever (Annoying, but has my vote for the lesser of two evils – using object arrays for return values is messy).

According to MSDN, implicit types can only be used within the method scope. This makes sense, since if you’re going to start passing them around, you will probably need to declare a proper class for their values anyway.

Writing a Custom Appender for log4net

On most of my projects, I use log4net (a habit I carried over from Java really) to maintain traces and logs. I find it preferable to using the trace mechanism, and it certainly beats Console.Write as a technique. One of the best things about it is that you can configure appenders to write to pretty much anything. The appenders that come bundled with log4net cover most of the stuff you’d actually want to log to – the event logs, console, a database, file system, and so on. However, sometimes you may need something a little more specific.

In my case, I needed to have one of my projects log issues directly into the issue tracking system we use here. Said tracking system exposes a web service to do just that, so I set about writing an appender that would consume this service. I’m not going to go into the details of how to connect to this specific system, but hopefully this short post will illustrate how incredibly easy it is to write a custom appender.

The best place to start off is by extending log4net.Appender.AppenderSkeleton. This will provide 99% of the functionality needed to make an appender work. Depending on your specific needs, you might find something even closer to your target to work from, but this was fine for me.

AppenderSkeleton provides two abstract overloads of the Append method. This is what the framework calls to let the appender know there is something to log. All I needed was to convert the log message that is passed to this method to a string. To keep things simple and configurable, we can use the following:

string logMessage = RenderLoggingEvent(loggingEvent);

The RenderLoggingEvent method uses the Layout provider specified in the appender configuration. This allows us to keep our appender configuration consistent with any other logger out there, with no extra effort (a subject very close to my heart. The lack of extra effort that is, not consistency).

Once the message has been prepared, we can fire it off as we would with any web service call. However, calling a web service may itself raise an exception. Logging errors should be transparent to the rest of the application, so we don’t want the exception to be thrown back to us. Instead, we can trap it and pass it to the logger’s error handler:

// Send the log message to the web service.
catch (Exception e)
    ErrorHandler.Error("An error occurred while connecting to the logging service.", e);

The error handler is, once again, determined by the configuration and would be responsible for deciding what to do with the exception. For simplicity’s sake, I only defined a handler for the generic exception type here, but it might help if you add appropriate handlers if you intend to use such code.

The example provided in the downloadable code is rather simple – the logging service it connects to only accepts one parameter. In reality, you would probably need to specify a number of properties, including authentication settings and so forth. Luckily, log4net makes it easy to keep everything configurable. Any public property defined in the appender class can be set up in the configuration file as follows:

   type="GeminiAppender.GeminiAppender, GeminiAppender">
   <ServiceURL value="https://****.****.***/webservices/gemini.asmx" />
   <AccessCode value="********" />
   <ApplicationId value="**" />
   <ReporterId value="**" /> 
   <threshold value="ERROR" />
   <layout type="log4net.Layout.PatternLayout">
    <!-- Pattern to output the caller's file name and line number -->
    <conversionPattern value="%5level - %message%newline" />

The underlined elements are properties defined in the appender class. Note that the dll containing the appender must be in the binaries folder (not necessarily referenced directly, but it must be present).

The sample code can be downloaded here. Note that there is an issue with the test (Attempted to access unloaded AppDomain) – this seems to be something to do with the messed up way I set up cassini; it only appears if the test ran correctly, which is highly annoying. Updates and further information will be posted as soon as I figure out why it’s doing this.

kick it on