As I look back at 2013, I am reminded of how much pain it sometimes takes to make a difference in the world, but how immense is the reward when what you believe in slowly comes true.

A year ago we were already 6 months late on the Microsoft release cycle. This year we added support for Visual Studio 2013 and .NET 4.5.1 the next day after the preview release and we soon caught up with the C# compiler.

A year ago, I almost lost faith in aspect-oriented programming. Today I strongly believe in a better, fundamentally simpler way to think about software. I believe a once-in-a-generation paradigm shift is coming. It will be an era in which developers will tell compilers what to do and not how to do it. In this vision, aspect-oriented programming plays a central goal in concert with static analysis and meta-programming. Today, we are proud as we contribute to the evolution of programming languages.

A year ago the company was in crisis. Today the team is solid and confident. This is why now my looking back is filled with gratitude and thanks for many.

I give thanks to our customers, those small teams of engineers who fight hard within their corporate bureaucracies to be allowed to use non-mainstream technologies.

I give thanks to our local team, who chose the shivers on the Santa Maria across unknown waters over the safety of cabotage in familiar territory.

I give special thanks to Marek Byszewski’s team for its crucial support during the storm, and to Art of Change’s Vlasta and Jana for their help in strengthening the team and our minds.

Last but not least, I give thanks to the Friends of PostSharp, those benevolent speakers who dedicated their free time to educate the community. Together, the Friends of PostSharp reached an audience of over 1,000 just this year.

We were looking for a way to express our gratitude and we thought there would be no better way than a donation to a charity on behalf of our community. We wanted to support a worthwhile cause that resonates with our industry. Thankfully, we were able to find a great one.

In the name of the Friends of PostSharp, we have donated $2,000 to the Czech Association Helping People with Autism (APLA).

Autism diagnoses have surged in the last few years and associations like APLA struggle to meet the demands of parents. Causes of the disease are still being debated. But beyond the usual jokes about socially-odd programmers, researchers have found signs that autism may indeed be more prevalent among children of those in highly intellectual and technical professions. Autism is a focal concern of industrialized societies and especially of high-tech professions.

Last for Matt, Donald, Dustin, Lance, Dror, Adam, Yan, Joe and Chad, thank you so much for your dedication and support.

We wish you all at least a few work-free days without PostSharp before the 2014 New Year.

Happy Christmas from all of us at PostSharp Technologies!


We’re excited to announce that PostSharp 3.1 RTM is now available for download from Visual Studio Gallery and NuGet.

Before we even mention the new features, we have good news for those who are just interested in a specific functionality in PostSharp such as logging or INotifyPropertyChanged:

PostSharp Pattern Libraries Available as Stand-Alone Purchases

It is now possible to purchase PostSharp Pattern Libraries separately so you don’t have to buy PostSharp Ultimate if you only need a small part of it. Please check the prices online and let us know if you have any questions.

What’s New in PostSharp 3.1

PostSharp 3.1 builds on the vision of PostSharp 3.0, but makes it more convenient to use. It also catches up with the C# compiler features, and adds more flexible licensing options. You can read more about the new features in the PostSharp 3.1 Preview Announcement. In short, PostSharp 3.1 brings you:

  • faster builds: PostSharp can now optionally install itself in GAC and generate native images. This decreases build time of a fraction of a second for each project: a substantial gain if you have a lot of projects.
  • support for async and iterator methods: when you applied an OnMethodBoundaryAspect to a method that was compiled into a state machine, whether an iterator or an async method, the code generated by PostSharp would not be very useful:  the aspect would just be applied to the method that implements the state machine. An OnException advise had no chance to get ever fired. Starting from PostSharp 3.1, OnMethodBoundaryAspect understands that is being applied to a state machine, and works as you would expect.
  • solution-level policies and improved configuration system: PostSharp 3.1 makes it easier to share configuration across several projects. For instance, you can now add aspects to all projects of a solution in just a few clicks.
  • locations (file/line) of errors and warnings: when previous versions of PostSharp had to report an error or a warning, it would include the name of the type and/or method causing the message, but was unable to determine the file and line number. You can now double-click on an error message in Visual Studio and you’ll get to the relevant location for the error message.
  • automatic indentation in logging: for better log readability, PostSharp Diagnostics Pattern Library now automatically indents log entries when entering and exiting methods.

All customers with an active maintenance subscription can upgrade to PostSharp 3.1 for free.

Happy PostSharping!


Many people wonder how many lines of code they really save thanks to PostSharp beyond the buzz and marketing promises. Thanks to data collected through our CEIP program, we are able to shed some light on this question.

When you opt-in for CEIP, we collect a few anonymous metrics for all projects you build. Two of these metrics are interesting here: the number of lines of code (we just count instructions, not declarations like fields, properties, type headers or method headers), and the number of aspect instances in your code.

We feed this data into a database that already has a few GBs. Let’s use R to analyze it.

First, we load the data. We filter out demo or test projects with fewer than 100 lines.

db <- odbcConnect("Feedback")
m <- sqlQuery( db, "SELECT InputLines, AspectsInstances 
FROM MetricSample s TABLESAMPLE ( 25 percent )
WHERE AspectsInstances > 0 and InputLines > 100")

We want to know how many aspects per line manual of code we have. The invert metric is easier to represent and interpret, so let’s compute it:

hist( m$InputLines / m$AspectsInstances, xlim=c(0,200), breaks=200000, col="lightblue"  )

Here is the result of this graph:

And here are the summary of this vector:

summary(m$InputLines / m$AspectsInstances)
# Min.  1st Qu.   Median     Mean  3rd Qu.     Max. 
# 0.0     12.6     43.8    626.8    199.0 357800.0 

What does it mean?

25% of PostSharp-enabled projects have an aspect every 13th line of code or less. 50% of these projects have an aspect every 44th line of code.

Suppose that each aspect avoids 4 lines of code. This is a pretty pessimistic estimate – an INotifyPropertyChanged aspect can save dozens of lines of code per instance. Also, PostSharp counts a line of code as any location where the debugger can stop, so it usually counts more than lines of text. So, with this ballpark estimate of how much a single aspect instances saves, we can say that:

  • 25% of projects would be 30% larger without PostSharp, i.e. PostSharp saves 23% of development costs.
  • For 50% of projects, the codebase increase without PostSharp would be 9% and the teams saves 8% with PostSharp.

Note that large projects are overrepresented in our sample because CEIP data are uploaded by many team members. However, this bias also reflects the higher economic importance of large projects.

Teams who use PostSharp the best get a 23% cost reduction.

This is pretty amazing in my eyes and I’m proud of us.

Happy PostSharping!