New in PostSharp 4.3 Preview: Improved Debugging Experience

by Gael Fraiteur on 18 Feb 2016

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.