In my last two PostSharp blog posts, I looked at creating some custom attributes that you could use to get custom behavior out of PostSharp. Of course, I was implementing simple functionality and in fact, PostSharp had most of if not all of those features already built in.

Today, I want to dig in a little more to some of the built in power of PostSharp. To do this, I had to sign up for the 45 day evaluation license for PostSharp Ultimate. I had been putting that off to do as much “free stuff” as I could, but I really wanted to see what PostSharp could do, so I fired up the evaluation.

I created a very simple UI that looks like this:

When you click the buttons, I call a class that just sleeps for three seconds and returns to simulate some slow process.

public void LongRunningOperationBlocking()
{
    Thread.Sleep(3000);
    return;
}

I created code that will run this blocking process and then when the UI thread is free again, it displays a message box with whatever was in the textbox. Here is the UI in action. Note that I cannot select the text after clicking the button because the UI is locked up for 3 seconds.

However, with PostSharp, we can easily execute these long running methods on a background thread. As long as the method returns void, the context menu will reveal the “Execute method in the background” option like this:

After selecting that option, you get this wizard:

The sum total of the “visible” changes is that our other method got a new attribute, “[Background]”

[Background]
public void LongRunningOperationBackground()
{
    Thread.Sleep(3000);
    return;
}

But, the win is that now when I click the button, the UI returns immediately and we see the message box right away, even while the long running process is going.

That is a gigantic amount of threading code that we don’t have to write. It is only probably 4-6 lines per method, but you have to write the same thing over and over again for every method you want to have do work on a background thread. Of course, any time you can just cut out “boilerplate code”, you make your code not only easier to write, but easier to read and discern intent. And that is “A Good Thing™”!

As always, you can download the code for this series from my Github repository for it. The path to this post’s code is here.

Last time, I started off my PostSharp series by adding some logging coming in and out of a method. It was very easy to do and it was nice to have a single point of code that wasn’t copy-paste repeated all over the codebase. This time, I want to look at what it might take to check the parameters that come into the method.

As Matt Groves pointed out in the comments of my last post, Phil Haack created something called NullGuard to do the kind of thing that I’m endeavoring to do here. In addition, PostSharp themselves created the ability to do just this very thing with the release of PostSharp 3, but it is only available in the paid editions. You can see an explanation in detail here.

Smart people don’t roll their own code for things that are already “solved problems” (I ranted about this in a recent podcast). However, I’m going to tackle this simple problem a few different ways in order to demonstrate how you can create your own more complex rules with PostSharp.

I created a class called NoNullParamsAttribute.cs and its code is as follows

using PostSharp.Aspects;
using System;
using System.Text;

namespace IntroToAop2
{
    [Serializable] 
    public class NoNullParamsAttribute : OnMethodBoundaryAspect 
    {
        public override void OnEntry(MethodExecutionArgs args)
        {
            var messages = new StringBuilder();

            for (int i = 0; i < args.Arguments.Count; i++)
            {
                if (args.Arguments.GetArgument(i) == null)
                {
                    messages.AppendFormat("Parameter \"{0}\" cannot be null. ", args.Method.GetParameters()[i].Name);
                }
            }

            if (messages.Length > 0)
            {
                throw new ArgumentException(messages.ToString());
            }
        }
    }
}

Now, we can call that above one of our methods from last week like this

[NoNullParams]
public string ReverseString(string input)
{
    var inputArray = input.ToCharArray();
    Array.Reverse(inputArray);
    return new string(inputArray);
}

Now when I call it passing in null, I get an argument exception with the message ‘Parameter “input” cannot be null.’. I could obviously do the same check to make sure that it was not empty, or that all integers were greater than zero, and so on. Of course, the examples I mentioned earlier are much more sophisticated, however today we’ve seen how to iterate over method parameters, get their name, and examine them. Not too bad for a day’s work!

All of the code can be found on my GitHub repo for this series under IntroToAop2.