Q&A
Q: In your previous session, you used aspect boundaries to do something that could also be accomplished by method interception. What factors help to decide which way you should implement?
A: The OnMethodBoundaryAspect offers higher performance because only a part of the calling context needs to be passed to the aspect. This is especially true with the aspect optimizer feature, included in PostSharp Pro and Ultimate, when the aspect does not consume a lot of context, for instance a transaction scope aspect. The benefit is reduced however if the aspect consumes a lot of context, for instance all argument values. The MethodInterceptionAspect is more powerful: you can invoke the intercepted method on a different thread, for instance. But it is slower because the whole calling context needs to be stored to the heap and passed to the aspect.
Q: How can I disable a PostSharp aspect temporarily?
A: There are a number of ways to disable PostSharp from a specific project:
-
In Visual Studio, open the project properties dialog, select the right configuration, open the PostSharp tab page, and change the value of the Disable PostSharp option.
-
In Visual Studio, open the project properties dialog, select the right configuration, open the Build tab page, and add the conditional compilation symbol SkipPostSharp.
-
Define the MSBuild property SkipPostSharp=True, for instance using the command line msbuild /p:SkipPostSharp=True.
Q: Which Aspects are serialized?
A: Every aspect is serialized at compile time. You can find out more on aspect serialization in PostSharp documentation.
Q: Is there deserialization during run-time?
A: Yes, by using a decompiler you will see that PostSharp stores serialized aspects as resources, for instance the aspect I applied to the DoSomething method in the video, and an internal class does the work of deserializing the resources into an object.
Q: Why are you using the objects (internal classes) instead of writing the code directly in the corresponding methods? Wouldn't that be more performant?
A: This approach is named “aspect inlining”. It is more performant but more complex and less powerful (aspects code would need to be more limited).
Q: System.Diagnostics.Contracts also uses the post-compiler rewrite method to check state and assertions. Do PostSharp and Contracts work well together?
A: Yes, they work well together. PostSharp runs after Code Contracts.
Q: It’s evident that PostSharp is heavily dependent on using .NET's underlying support for discovering and calling methods using Reflection. Are there any significant trade-offs or compromises in using Reflection so heavily?
A: PostSharp does not rely on reflection to discover and call methods. The analysis is done completely at build time, and PostSharp generates code to call exactly the right methods. Reflection is only used if the aspects themselves use reflection. Even then, any use of reflection is optimized and cached.
Up next: Unit Testing & Thin Aspects
The benefits of unit testing are numerous. When aspects are involved, Matt believes keeping them "thin" is key to keeping your code easy to unit test. Join us this Thursday as he explores some of the implications of unit testing when a post-compiler tool is involved.
During this final episode in the AOP in .NET series, Matt will be joined by Gael Fraiteur, the creator of PostSharp, who has a differing opinion about the relevancy of "thin" aspects and will speak about a set of practices that can be used to create efficient tests of aspects.
SPECIAL OFFER:
The generous folks at Manning Publications are offering a 40% discount on Matt’s new book to all live webinar attendees. So, if you want to learn what difference AOP and PostSharp can make in your projects, and take advantage of Manning’s discount offer, be sure to join us for the last live webinar in this series.
Seats are limited and this head-to-head episode is sure to sell out so reserve your spot today.
-Britt