Last week we were honored to have our friends at IdeaBlade join us for a very special webinar, dealing with real world AOP usage. Ward Bell, V.P. of Technology at IdeaBlade, did an excellent job of demonstrating how Aspect-Oriented Programming and PostSharp helps creating clutter-free data access, using their flagship product, DevForce.

DevForce uses PostSharp to infuse “Code First” entity model classes - entities like Customer and Order – with rich behaviors that go way beyond property change notification. You write entities with simple getters and setters; after PostSharp, they support property validation, entity navigation, lazy loading, dirty tracking, and UI data binding.

Here is the recorded webinar and the slides for your viewing pleasure! You can download the source code for the demo application and the slides from the IdeaBlade Documentation site.



During the webinar you have asked us great questions, and, as promised, here are the answers to all of them:

Q: Does DevForce integrate with PostSharp?

A: Yes, DevForce Code First is built with PostSharp, so you don’t need a PostSharp to use it!

Q: Does any entity with a FirstName property get that clown verifier, or just Employee?

A: Just the Employee. As you can see, the type of the entity is passed into the custom verifier:

Q: Is it possible to step through the injected behaviors?

A: Yes, if you have the requisite symbol files (pdb files) loaded. It is rare to want to step through either the PostSharp or DevForce code itself, though. You’re usually debugging your own code, such as the “NoClownsVerifier”.

Q: Can you show some of the code in IdeaBlade.Aop?

A: Here is the definition for the two aspects provided by DevForce:

As you can see, it uses PostSharp’s abilities to introduce, or inject, behaviors at compile-time to the target classes, so it implements things like INotifyPropertyChanged for you in your entities automatically!

Please note that the specific behaviors we have injected may or may not be enabled when the entity is detached. For example, entity navigation properties require the EntityManager to locate the related entities in cache or query them from the database if necessary. Validation triggered by property setting requires an attached validation engine (our VerifierEngine) which is made available to the entity instance via its attached EntityManager. Accordingly, DevForce only enables these behaviors when the entity is attached. The capability has been injected, the code has been woven into the class, but the feature is turned off for detached entities.

Q: If you add your own properties to POCO class do you need to somehow tell PostSharp not to interfere with it?

A: The [Unmapped] attribute tells DevForce (and Entity Framework) that this property is NOT mapped to a column in the database and is not persisted. DevForce won’t activate the injected behaviors for such properties either (although we are considering an attribute that would tell DevForce to enable some of the behaviors for non-persistent properties in a future release).

Q: Can you provide you own base class for navigation property collections?

A: You can take over the behavior of any property, including navigation properties, via DevForce “property interceptors”, another feature that PostSharp weaves into your entity properties. Interceptors can be specified in the entity, in the base class, or in a separate property interceptor provider that DevForce will discover (we never require a base class in Code First).

Q: How do you mark a property to not have a specific aspect apply to it?

A: If this is a PostSharp question, the answer is “it’s up to how you implement your aspects.”

The DevForce aspects are applied at the class level but you can opt out at the property level with the [Unmapped] attribute. We only have two aspects (one for entities, one for complex objects) so I think what you’re asking is about opting out of one or more of the interfaces. DevForce lets you inject your own custom behavior into our interface implementations so you can do coarse grain or fine grained alterations of our implementations.

Q: How were the Employee.cs, Customer.cs and other table classes created?

A: I could have written them entirely by hand.  I found that boring so I used what we call our “Code Second” technique. I pointed the EF Designer at the database and asked it to generate code with our “Code First” T4 code generator. Then I threw away the EDMX and went to town, cleaning out anything I didn’t like in the generated entity classes. What you see is what I decided to keep.

Q: How do you convert an existing “Database First” to the code-first model?

A: You might try the Code Second technique that I described above.

Q: How is the raising change notification done on the FullName property in the Employee class?

A: I used DevForce property interception feature which is also woven into the properties via AOP. I added the following code at the bottom of the Employee class:

DevForce recognizes this as an Employee property interceptor for FirstName and LastName. The implementation raises PropertyChanged when either of those properties has finished setting its value.

We are considering the possibility of automating discovery of FullName’s dependence upon FirstName and LastName but that capability is not in this release.

Final words

We hope that you enjoyed this very special webinar! If you have any more questions about how to use PostSharp, please visit our Support Forums to have them answered. For more information about DevForce and IdeaBlade, please visit their website.

We thank Ward Bell and IdeaBlade for the wonderful presentation and the Q&A! See you all next time!

Until then,

Happy PostSharping!


Since its inception, PostSharp had always allowed making Aspect-Oriented Programming in .NET easy, allowing developers to produce cleaner code, encapsulating infrastructure code behind reusable modules.

We are pleased to announce today that we are making this even easier – with PostSharp Toolkits!

What are PostSharp Toolkits?

PostSharp Toolkits are a collection of ready-made solutions for adding common infrastructure code, such as logging, exception handling and performance monitoring to your application with no changes to your source code! Powered by PostSharp, the most complete AOP solution for .NET, the PostSharp Toolkits build upon the raw power of Aspect-Oriented Programming to seamlessly apply those solutions throughout your application.

Sounds interesting, how does it work?

We have great examples on how to add things like logging, tracing, and exception handling to your code. We’ve built upon this knowledge, and added things like XML-configuration, so no changes in the source code are required! Simply grab the toolkit from NuGet, and you’re all set!

What toolkits currently exist?

With the first release, we’re introducing the PostSharp Diagnostics Toolkit – an instrumentation toolkit that adds diagnostics features, such as logging, exception handling, performance counters and feature tracking to your application. The PostSharp Diagnostics Toolkit includes pluggable support for the leading logging frameworks, such as NLog. Support for additional frameworks is coming soon!

Note: As this is a work in progress, the PostSharp Diagnostics Toolkit currently only has logging support, with a very limited feature set. In the following releases, we will introduce additional configuration options, support for popular frameworks and other cool stuff!

The source code for the PostSharp Toolkits is available on GitHub, and we’re going to introduce new features based on your feedback in short release cycles.

Getting started

Here is how to add logging to your application without changing a single line of code:

Starting with a simple project:

  • Step 1: Add the PostSharp Diagnostics Toolkit from NuGet to the assembly you wish to instrument. It downloads PostSharp automatically as a dependency (please note that you need PostSharp 2.1 SP1 or higher for the PostSharp Toolkits).

  • Step 2: Rebuild your application

When you now run your application, this is what is printed in the output:

How did this happen?

The NuGet installation creates a .psproj file named after the current project in the source tree. This is an XML file, containing the configuration, which is processed by PostSharp during compilation.

The details about the XML configuration will be posted on GitHub. For now, just note that in the <Data> section there is a definition of LogAttribute. This is equivalent of placing the LogAttribute (part of the toolkit) on an assembly level in the source code, via:

[assembly: LogAttribute]

By default, it will be applied to all methods of the application. You can use the Filtering Properties to limit the multicasting. Please refer to the Online Documentation for details.

If we take a look at the compiled assembly in our favorite decompiler, we can see that the output lines were added directly in the method bodies, and no reference to PostSharp.dll is required!

What about writing the output to a file?

Glad you asked! The PostSharp Diagnostics Toolkit for NLog is exactly the solution for writing the output to NLog. Install it from NuGet, it will download all the required dependencies automatically. You will then need to configure NLog (either manually, or by downloading a NuGet package NLog.Configuration, which contains a sample configuration file for NLog). Then simply rebuild your application, and NLog will be automatically added to it!

Few notes:

The PostSharp Toolkits project is built using the PostSharp SDK. The PostSharp SDK is completely unsupported and undocumented, for the reasons detailed in this blog post. While the source code is available on GitHub, any questions pertaining to the PostSharp SDK will go unanswered.

The PostSharp Toolkits is an ongoing project, we are aiming at short (2-week) release cycles, bringing you more features based on your feedback!

Questions? Suggestions? Bugs?

Please visit our dedicated PostSharp Toolkits Support Forum to let us know what you think!

Happy PostSharping!


Boilerplate code. It’s all around us, polluting our business logic, and forcing us to write the same code over and over again. Join us on Thursday, January 26th, as our very own Igal Tabachnik shows you how to stay DRY (Don’t-Repeat-Yourself) by using aspect-oriented programming (AOP) and PostSharp to remove boilerplate code that’s duplicated in and across systems.

Attendees will learn:

  • Why the DRY principle matters
  • How AOP helps to remove boilerplate code
  • How to use PostSharp to produce cleaner code
  • Real-world AOP usage examples

Oh, and that’s not all – we’re giving away two PostSharp licenses to two lucky attendees!

So hurry up, sign up here: