When developers first discover PostSharp and decide to give it a try, one of the most frequent feedback we hear is the lack of samples that they could just download, compile and study. After years of ignoring the problem and focusing on building (look, we don’t have a single full-time marketing person in the company!), we’ve finally decided to give it the priority it deserves.

GitHub seemed to be the right way to share the source code, but let’s face it: GitHub’s source code browser could be better. The formatting is nice and colorful but GitHub does not link references to declarations and documentation.

So we looked at another solution to complete the gaps in GitHub code browser, and this thing immediately came to our mind: the Roslyn-powered .NET Reference Source Browser which has been open-sourced. That seemed the perfect solution, but some features would potentially drag the reader’s attention away from PostSharp to implementation details of the .NET Framework, which was not our objective here. So we commented out a few lines of code in the sample browser and linked the samples source code to our documentation instead of to the .NET Framework source code. We also added support for Markdown.

Today, we’re proud to release the best sample code browser in industry! Try it by yourself on Of course, we’re still hosting the source code on GitHub and you can download or clone all samples from

What do you think? Do you agree we have the best sample code browser in industry? If not, which sample browser do you prefer and why?

Happy PostSharping!


One of the most frequently questions asked by people who just learned about PostSharp is how the debugging experience is affected. Our usual answer was that debugging experience was unaffected, and indeed the debugger worked as usually. On some occasions we had some bugs, which we fixed when we discovered them. But in general, it worked as expected.

However, debugging experience is so critical that we wanted to improve it even more in PostSharp 4.3. That’s why we are proud to announce three features:

  1. Step Into Aspects
  2. Clean Call Stack
  3. Just My Code

Note that in the current preview, these features are only available in Visual Studio 2015. It will be backported to Visual Studio 2013 but not 2012.

Step Into Aspects

Suppose you have a method Foo and an aspect Bar applied to it. What should happen when the caret is on an instruction calling Foo and you do F11-Step-Into?

With previous versions of PostSharp, you would step into the aspect Bar. If you continue stepping, you would eventually get into Foo. This is the normal way the debugger works and nobody was surprised about that. However, this is annoying in the majority of cases. Most of the time, what you actually want is to get immediately into Foo. You want to step over the aspect and step directly into the target method. This is exactly what we implemented. 

By default, the debugger will not skip the aspect and step only into the business logic. To debug the aspect logic, go to the menu PostSharp / Options, then to the tab Debugging, and check the Step Into Aspects option.

To see this in action, look at this video:

(UPDATE: the video was recorded with a preview build of PostSharp 4.3 where the feature was named Step Over Aspects)

Demo: Step Over Aspects from PostSharp on Vimeo.

Clean Call Stack

Let’s face it: PostSharp could create ugly call stacks. If your method was intercepted by two aspects, you could easily have four additional stack frames with weird names. This reflected the reality of which MSIL code was executed, but most of the time, this was not useful.

Starting with PostSharp 4.3, we will clean the call stack by default. See by yourself.


Just My Code

Finally, we realized (although the problem has never been reported by customers) that Just My Code did not play nicely with PostSharp. I intentionally put the responsibility on Just My Code here and not on PostSharp. When Just My Code is enabled, it will automatically step over any non-user-code method, even if this method invokes a user-code method. In many situations, this leads to strange behaviors. For instance, when a non-user-code Foo method invokes a delegate bound to a user-code method Bar, the method Bar will never be stepped into. The same happens with PostSharp’s interception aspects like LocationInterceptionAspect and MethodInterceptionAspect: you just could not step into methods that had interception aspects if Just My Code was enabled.

We implemented a brutal workaround to this, and now Just My Code just works as you would expect.


PostSharp 4.3 makes the debugging experience much better. I would really appreciate if you could try the new debugging experience. Is that working as expected? Do you still encounter some awkward experience?

Happy PostSharping!



P.S. This post is the second in a series dedicated to the new features of PostSharp 4.3:

  1. Command-Line Interface;
  2. Improved Debugging Experience;
  3. Alternative to NuGet deployment.

At PostSharp we have a strong bias for building against communicating. Between PostSharp 4.2 RTM and now, we’ve already released four previews of PostSharp 4.3. Let’s have a look at the first feature that we almost completed: the command-line interface.

It is now possible to bypass NuGet and MSBuild integration and invoke PostSharp as an executable. This feature was supported up to PostSharp 2.1 and then removed in PostSharp 3. We are including it back because of popular demand.

Why to use the command-line interface?

PostSharp has been primarily designed as an extension to the C# and VB languages that automates the implementation or validation of patterns. Most patterns need to be present for the application to work. Think for instance of INotifyPropertyChanged.  It does not make sense to have a build of your application that does not implement INotifyPropertyChanged. Therefore, the best way to invoke PostSharp is to use the default MSBuild integration.

However, if you think of instrumentation aspects like logging, the situation is different. It is perfectly valid to add logging to an existing assembly. In this case, MSBuild is not the good option.

You can use the command-line interface in the following situations:

  1. When you have access to the source code of a project but you don’t want to add instrumentation into the normal C#/VB project file, but as a separate step.
  2. When you don’t have access to the source code of the assembly you want to instrument. (Legal disclaimer: in this case, make sure your license allows you to modify the assembly)

Example: instrumenting DotNetty

To demonstrate a typical use of the command-line, let’s take some random open-source project: DotNetty, a network stack used by the Azure platform. To keep the example simple, let’s add logging to the Echo.Client assembly.

Step 1. Download and extract the ZIP distribution

If you want to run PostSharp as a stand-alone executable, you will likely prefer to download the zip distribution of PostSharp instead of the NuGet packages. The zip distributions is one of the good things of PostSharp 2.1 that disappeared in PostSharp 3 and that we are bringing back. To download the zip distribution, go to, then download the file named PostSharp-<version>.zip and extract it to your local machine.

Step 2. Create a PostSharp project file

Create a file named postsharp.config (any file name will work) and add the following content:

<Project xmlns="">

<Property Name="Input" Value="Echo.Client.exe" />
<Property Name="Output" Value="Echo.Client2.exe" />
<Property Name="LoggingBackend" Value="Console" />

<LogAttribute xmlns="clr-namespace:PostSharp.Patterns.Diagnostics;assembly:PostSharp.Patterns.Diagnostics" />


Note that you can add any aspect to the assembly using this project file. For details, see our documentation.

Step 3. Invoke PostSharp

PostSharp executables are located under the tools folder. There are a lot of files in this directory, but you should focus on two: postsharp-net40-x64-native.exe and postsharp-net40-x86-native.exe. Use the first executable to transform x64 projects and the second to transform anything else.

Type the following command:

c:\PostSharp\tools\postsharp-net40-x86-native.exe postsharp.config

Step 4. Run the instrumented program

First, copy file Echo.Client.exe.config to Echo.Client2.exe.config so that the new executable will find its configuration.

Then execute Echo.Client2.exe and… enjoy the logging!


With PostSharp 4.3, we are bringing back a few good features of PostSharp 2.1 that disappeared in PostSharp 3: the zip distribution and the command-line executable.

You can use the command-line executable whenever you want to add instrumentation to an assembly without having to recompile it – whether or not you have its source code.

Is it useful for your scenario? How can we improve? Please let us know!

Happy PostSharping,


P.S. This post is the first in a series dedicated to the new features of PostSharp 4.3:

  1. Command-Line Interface;
  2. Improved Debugging Experience;
  3. Alternative to NuGet deployment.