Our never-ending mission to spread the word about using PostSharp to produce cleaner code finds Gael and I in the good ole U.S. of A. for a week of presentations at user groups and businesses in Ohio and Michigan.

Joe Kunk first contacted us about the idea earlier this year and, together with the undying help of David Giard, we were able to build a tour that combines 4 user groups, 3 businesses, and 1 university over a 5 day stretch of interstate travel.

We sprinkled-in some customer visits for good measure, and added an extended layover at TechEd Europe on the way back to Prague and voilà: the perfect summer tour.

Gael has two presentations prepared for the tour:

  • Multithreading Beyond the Lock Keyword.” Dusting-off low-level synchronization primitives, Gael shows how to design programs that make better use of multiple cores. Because playing directly with low-level primitives can be overly complex, you’ll discover how large-scale multi-core software can be simplified using design patterns and how some these patterns can be ultimately simplified using aspect-oriented programming.
  • Intro to Aspect-Oriented Programming (AOP) with PostSharp.” Gael speaks about the problem with conventional programming, gives a gentle introduction to AOP with PostSharp, demonstrates how it works and why you should use it to eliminate scattered, tangled and coupled code from your codebases.

We’re excited to connect with user group leaders, members, and area businesses in Cleveland, Toledo, Detroit and Lansing. We look forward to learning about your current projects, the insight you provide about the solutions you’re looking for, and any feedback you can give about how you’re using PostSharp and our new toolkits.

Tour dates and locations include:


JUNE 18 Cleveland WPF User Group
JUNE 19 Oakland University
JUNE 20 Domino’s Pizza HQ
  Great Lakes Area .NET Users Group
JUNE 21 Michigan Health & Hospital Assoc.
  Consumers Energy
  Greater Lansing .NET User Group
JUNE 22 Sogeti
JUNE 26 & 27 TechEd Europe 2012


TechEd Europe promises to be one of the summer highlights, connecting us with new and old friends alike. Many thanks to Sara Faatz and the DevExpress team for their generosity. We’re very excited to get to know you and your team better. To our old friend Brady Gaster , who will be in Amsterdam to support the Azure team and participate in some breakout sessions, our apologies in advance to your liver.

If you find yourself in Ohio or Michigan next week, or attending TechEd Europe 2012 at the end of the month, please don’t hesitate to contact me to arrange a meet-up. Here’s to another wonderful summer!

Happy PostSharping!


p.s. – check out our Community page to find other opportunities to learn about PostSharp this summer.

If learning more about Aspect Oriented Programming is on your to-do list for 2012, we have some very good news for you.

We’ve teamed up with the good folks at Pluralsight to make it easier than ever for developers to get up to speed on developing with aspects. PostSharp users can sign-up to receive a free 30-day trial membership good towards one Pluralsight online course.

Start learning about Aspect Oriented Programming for .NET today >>

Pluralsight, “the leader in high-quality online training for hardcore developers,” has a huge library of online courses to choose from but, naturally, the course we recommend is Aspect Oriented Programming for .NET by PostSharp MVP and Pluralsight Author, Donald Belcham.

Donald is a senior software developer, independent contractor, author, and trainer based in Edmonton, Canada. He spoke about the topic of Aspect Oriented Programming at NDC and DevTeach Montreal earlier this year, and published the online course on Pluralsight in June.

The course is divided into four parts:

  • Introduction to AOP
  • AOP using Interceptors
  • AOP using IL Code Weaving
  • AOP beyond decorators

From Donald: “My course is perfect for developers who want to learn how to avoid code repetition by implementing AOP in .NET projects using IL Code Weaving frameworks like PostSharp, Interception frameworks like Castle Windsor, and even how to implement AOP without following the traditional decorator pattern.”

Apply for your free 30-day Pluralsight trial membership today and, upon approval, we’ll email you a unique login code plus a link to a special sign-in page for PostSharp users.

Start your free 30-day trial membership today >>


This is one of these unpopular but necessary decisions that every software publisher has to do now and then. It’s generally accepted that pulling off expensive but little-used features is a healthy decision because it frees resources that can be spent on more popular features. This is what we are doing with documentation and support of PostSharp SDK.

What is PostSharp SDK?

PostSharp is made of two principal components: PostSharp.dll and PostSharp.Sdk.dll.

PostSharp.dll is the high-level public API. It mostly contains interface definitions, abstract classes and custom attributes from which developers can derive their own aspects. This library is designed to be used by developers of business applications. It offers transformation primitives (such as: intercepting a method, wrapping a method, introducing an interface) that developers can add to their code.  PostSharp.dll leverages real aspect-oriented programming, a disciplined extension of object-oriented programming. Just as a normal compiler, the high-level API enforces syntactic rules, and you will get a reasonable error message if you violate them.

PostSharp.Sdk.dll is the opposite of PostSharp.dll. Its public API allows you to modify .NET assemblies at a very low level. You can do everything. The API does not enforce any programming discipline or syntactic rules. You can create invalid assemblies without even getting a warning. It requires you to learn the MSIL specification and to understand most of the 565 pages of the ECMA-335 specification. PostSharp.Sdk.dll is made of several components. The most low-level ones (code model, image reader, image writer) are also found in Mono Cecil and Microsoft CCI, although PostSharp SDK has its own implementation. PostSharp SDK also includes several middle-level components such as the project loader, the aspect infrastructure (which could allow you to use PostSharp SDK to develop an aspect weaver that has different syntax than PostSharp.dll), the aspect weaver (the implementation of the PostSharp.dll), the custom attribute multitasking components, and much more.

PostSharp SDK is more complex than you think

Contrarily to PostSharp itself, PostSharp SDK has a very steep, but misleading, learning curve. You get quite quickly the illusion that you “got” it, but the devil is in details. The 80-20 rules does not apply to PostSharp SDK: what applies is 95-5: 95% of time is spent in addressing 5% of cases. Think of MSIL programming as hiking in high mountains without a map. You always have the illusion that the top is near, but whenever you climb on what appeared to be top, you discover another, higher top. If you want to have an idea of the effort you’ll need to reach the goal, you need a map; ECMA-335 and the PostSharp SDK class reference will give you a fair overview of the complexity of your task.

So why do we have PostSharp SDK? First, for our own needs. From our own point of view, PostSharp SDK is the most important component of PostSharp. Secondly, because this API is useful to a tiny minority of ISVs with very specific needs (for instance: high focus on speed). They can afford to maintain MSIL skills because the effort is leveraged to thousands of customers. Third, because PostSharp SDK can be used to overcome missing features of PostSharp.dll. But this is where things can go wrong.

PostSharp SDK is undocumented and unsupported

There has been some criticism that PostSharp SDK is undocumented. This is not accurate: the class reference is quite complete and contains more than what’s obvious from the method signature. Many actually claim that PostSharp SDK has the best documentation of all MSIL rewriting tools.

What is true is there is no conceptual documentation. Let me be clear: the lack of conceptual of documentation is a feature, not a defect. The SDK will not be better documented. As any company, we have to allocate limited resources to a potentially unlimited number of features. It does not economically make sense to spend time in documenting a very complex API that is used by a dozen of customers.

The same holds for support. We cannot provide support on a highly complex and incompletely documented API. We cannot guide you through baby steps. PostSharp SDK is not supported. You use it at your own risks.

Nostra Culpa

On the support forum, you could often read answers that sounded like “this is not possible to do with PostSharp.dll but can be done with PostSharp.Sdk.dll”, followed by a disclaimer that PostSharp SDK is hard and you should maybe not try. This had led some customers to ask for more information for these specific cases, which I published on the blog. Mistake! These blog posts have been interpreted as an advertisement of and an invitation to use PostSharp SDK. I apologize for that. I will not advertise PostSharp SDK again. It will remain unsupported and undocumented. The harmful blog posts have been withdrawn.

PostSharp SDK still available

That said, PostSharp SDK is still available for use in the Professional Edition. We are only making it clearer that this feature is not officially supported, and must be used at own risk. I believe that it’s not a good idea to code directly MSIL instructions unless you can leverage the effort to thousands of customers (as we do), but you’re free to try. It’s just that you’re on your own.

I’m aware this decision will be unpopular, but I’m convinced it’s a necessary one to continue provide good support to the community.

Happy PostSharping !