Where do development patterns fit into your world? Carl Franklin and Richard Campbell talk to Gael Fraiteur about the evolution of PostSharp into a library for implementing patterns. The combination of aspect-oriented programming and patterns is powerful - providing a means to implement a pattern while keeping it separate from your business code. Gael explores one particular family of patterns: multi-threading. PostSharp implements half a dozen different multi-threading strategies, so that you can apply the pattern as an aspect to your objects and make multi-threaded coding simpler and safer.
Listen to .NET Rocks Show 1269 and if you haven’t don’t it already, subscribe to the podcast and register to the fan club.
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 http://samples.postsharp.net/. Of course, we’re still hosting the source code on GitHub and you can download or clone all samples from https://github.com/postsharp/PostSharp.Samples.
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?
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:
- Step Over Aspects
- Clean Call Stack
- 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 Over 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. We called this feature Step Over Aspects.
Step-Over-Aspects is now enabled by default. To disable Step-Over-Aspects, go to the menu PostSharp / Options, then to the tab Debugging, and uncheck the feature.
To see Step-Over-Aspects in action, look at this video:
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. PostSharp becomes the first non-Microsoft library in my knowledge that specifically extends the debugger. I would really appreciate if you could try the new debugging experience. Is that working as expected? Do you still encounter some awkward experience?
P.S. This post is the second in a series dedicated to the new features of PostSharp 4.3:
- Command-Line Interface;
- Improved Debugging Experience.