PostSharp is a very power AOP framework. It changes the IL emitted from the compiler according to the aspects that it finds. The way PostSharp can be implemented ranges from very easy to very complex.

The demos in this series will look at a very simple scenario. PostSharp will be used to aspect the RunTest() method in the following code. The aspect used will output console messages surrounding the RunTest method.

There are many AOP frameworks around and they all use one of just a few techniques to inject code into join points. Oren has previously posted a list of these types of AOP techniques with their advantages and disadvantages. This list is copied below for reference:

I’ve been working with team build a fair bit over the last month. Yesterday I was bouncing through the MSDN documentation during my MSBuild travels and I came across a very handy build task. The BuildStep task allows you to create custom entries in the build report.

Take the following build target for example:

I love TFS, but there is one thing that grates me. Check ins with no changes are very frustrating. I’m reviewing a branch for a service and half the edit and merge changes don’t have changes. It’s not a big deal, but it would be good if the "noise" in the change sets wasn’t there.

I’m really looking forward to Code Camp this weekend (nerd camp my mother-in-law calls it). It should be a great weekend of sessions and networking. Hopefully I’ll get to catch up with friends and meet some great new people.

See you there!

I just saw the first episode in the latest season of the Gruen Transfer. The concept of the show is classic and the idea of “The pitch” is simply gold.

Watching this episode reminded me of a pitch from last year about selling the idea of invading New Zealand. My favourite was the advert that lost the competition, but I just have to link to it for posterity.

As I was writing and using my custom GhostDoc rules (here and here), I was thinking that it would be nice if GhostDoc was able to clear the existing documentation and then apply the DocumentThis command. I emailed Roland Weigelt about the feature idea not realising there is a forum for feature requests. He quickly replied saying that the feature is already there albeit undocumented. This is exactly what I was after.

If you open up the keyboard bindings and do a search for GhostDoc, you will find a RebuildDocumentation command.

I have assigned the RebuildDocumentation to a Ctrl+Shift+D, Ctrl+Shift+R combination and changed DocumentThis to Ctrl+Shift+D, Ctrl+Shift+D combination. Roland said to make sure that the new keyboard binding is only used in Text Editor (as highlighted above).

To follow up on my last post about documenting unit test methods with GhostDoc, a similar concept can be applied to documenting unit test classes.

Add a custom rule under the Classes section in the GhostDoc configuration dialog.

I have used the name “Matches unit test class” and identified type names that end with “Tests”. I have entered the summary documentation with the following value:

The $(TypeName.ShortNameAsSee)
class is used to test the <see cref=”$(TypeName.Words.Verbatim.ExceptLast)” /> class.$(End)

This produces much nicer documentation that the default documentation provided by Visual Studio.

GhostDoc is one of the coolest tools around for Visual Studio. Sometimes it needs a little help though and unit test methods are a classic example. The format of my unit test method names usually identifies the method name, parameter list, parameter value conditions, expected outcome and end in “Test”. The default rule that GhostDoc applies to this format is fairly ugly.

For example,

I’ve been on ADSL2+ for a few years now. Having a possible maximum speed of 24Gb is nice, but the actual floats between 5-7Gb being 3.5km from the exchange. That’s not great, but is fast enough for general net usage. Tonight however, surfing the net has been slow. Really really slow. So slow in fact, that www.speedtest.net tells me this.