Unleash your code with PostSharp

Currently, I have some spare time and wanted to play around with geeky stuff. The guys from sharpcrafters.com provided me a evaluation version of their tool PostSharp. PostSharp is a framework for aspect oriented programming in .NET. In short, aspect oriented programming helps you to remove unnecessary boiler plate code such as logging, transaction handling, exception handling and many more. The boiler plate code I’m talking about is also called cross-cutting concern because it cuts through your whole application. If you want to know more about aspect oriented programming I suggest you follow the links provided in this article. But now let’s dive into PostSharp.

PostSharp comes with a simple installer which installs PostSharp HQ on your machine. Everything is then setup to start using PostSharp. PostSharp HQ is essentially nothing more than a simple browser window which provides you information about your license status and links to documentation and tutorials. When you start VS2010 the first time after the PostSharp installation, a new information area is placed beside your toolbox. The information area provides you with a check list and tutorials which allow you to dive into the features and possibilities of PostSharp.

The basics of PostSharp are really simple. I’m not going to cover the stuff of PostSharp which is already in the tutorials but I’ll provide a detailed list of tutorials at the end of this post.

PostSharp itself is really user friendly. They are trying to provide a maximum amount of information possible at compile time. For example if you forget to mark your aspects as serializable you receive a compile error which points you to the cause of the problem. It is even possible to extend this message based information system with your own compile errors or warnings (look for MessageSource and Message.Write in the documentation).

Another powerful feature is the provided Visual Studio plugin. The plugin visualizes aspects and code which is influenced by aspects. On every recompile new information is available. For example the aspect browser shows aspects which are part of the solution and the affected code for each aspect (first screenshot). The code editor integration of the plugin shows nicely all aspects directly in the editor window. It is even possible to directly jump to the disassembled code with your favorite disassembler (for example ILSpy, DotPeek…).

All the rest should be covered in detail in the tutorials below. Happy PostSharping!

Hints from my side

  • If you are using ReSharper I suggest you add some templates to your solution settings which help you write aspects (for example the template should include the serializable attribute)
  • Always keep in mind that the application of attributes is undeterministic so there is no guarantee of execution order (PostSharp will also let you know that in the warnings)
  • The order of execution can influence the operational behavior of an aspect!
  • When possible try to avoid using the AttributePriority to modify the priority when aspects are applied. This can quickly become a huge mess.
  • Read the tutorials about aspect scoping multiple times
  • If you are using FxCop there is a section in the documentation about FxCop compatibility with PostSharp (haven’t tried it out yet)

Aspect Oriented Programming

PostSharp Tutorials

About the author

Daniel Marbach


  • Thank you for blobbing about PostSharp.

    Let me add some technical precision reguarding the undeterministic aspect priority. You mentioned the use of AttributePriority, but this does not affect the order of execution of aspects at runtime, but rather the order in which the include/exclude selection rules are applied to match aspects to code.

    Ordering of several aspects on a single method is quite well organized and documented here: http://doc.sharpcrafters.com/postsharp-2.1/Content.aspx/PostSharp-2.1.chm/html/30402cd7-58ab-49ac-8f5c-65f510174daf.htm. Basically, the developer of the aspect has to express dependencies so that the users of the aspect don’t have to care — and don’t create a mess.

    Compatibility with FxCop should not be a problem. Actually, code analysis must run on the input of PostSharp, not on its output. If you’re using FxCop as a part of Visual Studio, you don’t have to worry about anything. If you’re using it as a separate tool, you have to remember and implement this simple rule in your build scripts.

By Daniel Marbach

Recent Posts