Microsoft Logging Application Block, a part of Enterprise Library, is very popular in corporate environments. As all logging frameworks, the Logging Application Block provides an infrastructure for collecting and routing log entries, but falls short at generating them. If you want to log something, you have to write code that emits this log record. But there are situations where you just want to trace the execution of every method in some part of your application so that you can troubleshoot some issue. That typically requires a lot of boilerplate code.

This is why we designed PostSharp Diagnostics Toolkit, a tool that excels at generating the boilerplate needed to emit tracing information at a very low level of details. Today, we’re proud that the toolkit also supports Enterprise Library, besides NLog, Log4Net and System.Diagnostics.

Adding tracing to your application

Seriously, adding tracing to your application has never been so easy.

First, install PostSharp 3 CTP from Visual Studio Gallery or Visual Studio Extension Manager.

Then, in the Solution Explorer, right-click on the project and choose Add > PostSharp policy

You’ll get a list of project-level policies. Choose logging.

You’re then asked which types and methods should be logged.

Here you have a chance to specify which details need to be included. There are two default profiles: log everything, and log only on exceptions. Both default profiles will include parameter values by default. You can edit the profiles and create new ones as required.

Finally, you are asked to change the logging back-end.

After confirmation, PostSharp will download the required NuGet packages and will add a [Log] custom attribute to a new file named GlobalAspects.cs.

[assembly: Log(AttributeTargetMemberAttributes = MulticastAttributes.Public,
AttributeTargetTypeAttributes = MulticastAttributes.Public)]

Of course, you can use the full power of aspect multicasting to fine-tune the set of methods that you want to trace.

If you build and run the application, and if you have included a trace listener, you will see that all public methods of public types have been traced!


The Logging Application Block is a bit different from other logging frameworks in that there is no concept of “trace source”. Instead, there is a a concept of extensible log record and a concept of filters that can match any property of log records, including custom properties. This design makes Enterprise Library more flexible than other logging frameworks, but is at first sight less suitable for massive tracing because of the expense of building a log record object. Fortunately, intelligent code generation can make Enterprise Library as fast as other frameworks by sharing some read-only data structures and assuming that filters do not change when the application is executing (i.e., that a change requires an application restart).

Hierarchical categories

Another limitation, critical for automated tracing, is the lack of support for hierarchical categories. As a workaround, PostSharp will enlist each log record in several categories, one for each part of the type name and namespace.

Generated Code

For those who want to see what’s under the hood, the following snippet shows the code generated from a simple “Hello, world” method with full tracing enabled.

public static void Main(string[] args)
    if (<>z__LoggingImplementationDetails._3)
        object[] CS$0$0__args0 = new object[] { args };
        <>z__LoggingImplementationDetails.Write((TraceEventType) TraceEventType.Verbose,
"Entering: ConsoleApplication39.Program.Main({{{0}}})", CS$0$0__args0,
<>z__LoggingImplementationDetails._2.Categories); } try { Console.WriteLine("Hello, world."); if (<>z__LoggingImplementationDetails._3) { object[] CS$0$1__args1 = new object[] { args }; <>z__LoggingImplementationDetails.Write((TraceEventType) TraceEventType.Verbose,
"Leaving: ConsoleApplication39.Program.Main({{{0}}})", CS$0$1__args1,
<>z__LoggingImplementationDetails._2.Categories); } } catch (Exception) { if (<>z__LoggingImplementationDetails._5) { Exception CS$0$2__ex; object[] CS$0$3__args3 = new object[] { args, CS$0$2__ex }; <>z__LoggingImplementationDetails.Write((TraceEventType) TraceEventType.Warning,
"Exception in ConsoleApplication39.Program.Main({{{0}}}):\n{1}",
CS$0$3__args3, <>z__LoggingImplementationDetails._4.Categories); throw; } } }

As you can see, there is a lot of references to the class LoggingImplementationDetails. This class is generated by PostSharp. The static constructor configures prototype log entries and evaluates the filters. The Write method acts as a re-entrance guard, preventing infinite recursions typically induced by ToString when arguments get included in the logged text.

internal static class <>z__LoggingImplementationDetails
    // Fields
    public static readonly object[] _1 = new object[0];
    public static readonly LogEntry _2;
    public static readonly bool _3;
    public static readonly LogEntry _4;
    public static readonly bool _5;
    private static bool isLogging;

    // Methods
    static <>z__LoggingImplementationDetails()
        LogEntry CS$0$0__logEntry0 = new LogEntry();
        CS$0$0__logEntry0.set_Severity((TraceEventType) TraceEventType.Verbose);
        _2 = CS$0$0__logEntry0;
        _3 = Logger.ShouldLog(_2);
        LogEntry CS$0$1__logEntry1 = new LogEntry();
        CS$0$1__logEntry1.set_Severity((TraceEventType) TraceEventType.Warning);
        _4 = CS$0$1__logEntry1;
        _5 = Logger.ShouldLog(_4);

    public static void Write(TraceEventType severity, string messageFormat, 
object[] messageArgs, ICollection categories) { if (!isLogging) { isLogging = true; try { LogEntry CS$0$0__logEntry0 = new LogEntry(); CS$0$0__logEntry0.set_Severity(severity); CS$0$0__logEntry0.Message = string.Format(messageFormat, messageArgs); CS$0$0__logEntry0.Categories = categories; Logger.Write(CS$0$0__logEntry0); } finally { isLogging = false; } } } }

In theory, the JIT compiler could see that the tracing block code depends on the read-only static field whose value is false, and could completely avoid to generate the logging code, resulting in zero cost in case that a given trace category is disabled.


Perhaps the main feature that I regret is missing from the current version is support for the Tracer facility, which may be more appropriate for the low-level massive tracing we are trying to achieve. We will have to consider, in a next version, how we can make this concept fit with the current architecture of the PostSharp Diagnostics Toolkit.


Detailed tracing with Enterprise Library Logging Application Block is now easier than ever. In just a few clicks, you can add tracing to thousands of methods, with no impact or your source code and minimal impact on run-time performance.

Happy PostSharping!

A few days after Phil Haack described how to implement a null-checking aspect with PostSharp 2, it’s a good time to introduce a new feature of the refreshed PostSharp 3 CTP: validation of parameters, field, and properties.

First, you need to have PostSharp 3 CTP (3.0.5) installed.

To add a contract to to a parameter, just position the caret to the parameter name and select the relevant smart tag:

After you click on the action, PostSharp will download and install the relevant NuGet packages to your project, and add a [Required] custom attribute to the parameter. The same works for fields and properties.

It could not be easier. Of course, you can also introduce contracts without the user interface by installing the package PostSharp.Toolkit.Domain and adding the custom attribute yourself.

public void Foo( [Required] string bar ) 

(Make sure to allow pre-releases if you install the package manually.)

Ready-Made Contracts

The following contracts are available in the PostSharp.Toolkit.Contracts namespace, depending on the type of the field, property or parameter:

NotNull Requires a non-null value
NotEmpty Requires a non-null and non-empty string or collection
Required Requires a non-null object or a non-whitespace string
CreditCard Requires a valid credit card number
EmailAddress Requires a valid email address
Phone Requires a valid phone number
RegularExpression Requires a match of a regular expression
StringLength Requires a string of a given length
EnumDataType Requires a valid value for an enumeration (can be applied to strings and integers)
GreaterThan Requires a value greater than a threshold.
LessThan Requires a value less than a threshold.
Positive Requires a value greater or equal to 0.
StrictlyPositive Requires a value strictly greater than 0.
Range Requires a value within a range.

High Performance and Flexibility

Unlike previous validation aspects based on OnMethodBoundaryAspect, the new aspects result in compact and fast code, with almost no overhead compared to hand-written code.

Yet, they are based on an abstraction that you can extend to develop your own contracts: ILocationValidationAspect<T> is a new aspect primitive designed specifically for the task. It works transparently for fields, properties, and parameters.

If you want to create your own contract, you can derive a class from System.Attribute, or preferably PostSharp.Extensibility,MulticastAttribute (which supports inheritance, see below), and ILocationValidationAspect<T>, where T is the type of values to be validated, as many times as necessary. Note that the aspect does not know any standard type conversion (other than down-casting, which is not a conversion), so you will need a lot of these Ts, for instance for int, int?, long, long?, and so on if you want to target numbers.

Contract Inheritance

If you apply a contract to a parameter of an interface, abstract or virtual method, any the contract will be implemented in any derived method, for instance:

interface IFoo
   void Bar( [Required] string fooBar );

class Foo : IFoo
   public void Bar( string fooBar ) 
      // PostSharp will inject the [Required] contract at the top of this method body.

Note that inheritance is a feature of MulticastAttribute and not just contracts, so you can use it with just any aspect.


I already mentioned that the aspect does not support any type conversion, which could be annoying if you need to develop contracts that work on numbers.

Also note that the aspect is not yet able to validate output argument and return values. It is purely a precondition checker.

Finally, note that all contracts are opt-in. There is no “not-null by default”. It would be fairly easy to develop such a policy using an assembly-level IAspectProvider, but currently you have to do it yourself.


PostSharp 3 introduces a new aspect primitive that is optimized to validate fields, properties, and parameters with high run-time efficiency. The PostSharp Domain Toolkit contains a set of standard contracts that you can add to your code easily – just using the smart tags in Visual Studio.

Happy PostSharping!


The PostSharp team is excited to announce today the first public release of PostSharp 3, available for download on the Visual Studio Gallery and NuGet (make sure to allow prereleases).

This release marks an important turning point in the way we talk about PostSharp. During the last 8 years, we have successfully positioned PostSharp as the leading framework for aspect-oriented programming in Microsoft .NET. We provided an abstract construction kit and told customers they could build “whatever they wanted” with it. However, we became increasingly aware that the vast majority of our customers were all re-implementing the same aspects.

In addition to just providing a wonderful framework, we now offer more value to our customers by delivering ready-made implementations of the most common design patterns that hang over application development today:

  • Logging for System.Diagnostics, NLog, Log4Net (Enterprise Library coming soon);
  • Design patterns for safe multithreading;
  • INotifyPropertyChanged beyond the obvious;
  • Architectural validation;
  • Change tracking and undo/redo (coming soon);
  • Value validation: not null, regular expression, range, custom rules, … (coming soon);

Long-time PostSharpers know that we already started building on this vision nearly a year ago with our PostSharp Toolkits, published as free add-ons to PostSharp 2.1 Pro Edition. Although the toolkits have always been an important part of our vision for PostSharp 3, we wanted to nurture these projects jointly with our community and release them continuously. The incubation period is now over, and we are happy to announce that PostSharp toolkits will join our product line as first-class members.

With PostSharp 3, not only do we provide ready-made solutions to top problems, but we also make these solutions much more accessible than ever. With the new content-sensitive smart tags and wizards, you will be able to implement design patterns in a matter of minutes, without need to read extensive documentation.

So, beyond the new orientation, what’s new in PostSharp 3?

Smart tags and wizards in Visual Studio

The single most striking feature of PostSharp 3 is its deeper integration with Visual Studio.

For instance, move the caret to the name of a class or a method. Visual Studio will display a smart tag proposing actions that make sense in the current context: apply a threading model, add logging, implement INotifyPropertyChanged, …

A wizard-like user interface then collects all relevant settings and performs the required operations, such as installing a NuGet package and adding a custom attribute to your code.

Support for Visual Studio 2012

Visual Studio 2012 is now fully supported. Windows Store projects are supported too (see below). Visual Studio 2010 is still supported at an equal level of features, but support for Visual Studio 2008 has been discontinued.

First-Class Support for Windows Store Apps, Silverlight, and Windows Phone

Silverlight and Windows Phone (previously .NET Compact Framework) have been supported since PostSharp 1.5, but only a small subset of features was actually available for these platforms. This limitation was due to the inability of previous versions of PostSharp to execute, at build-time, code that was linked to exogenous platforms. Concretely, this affected features such as CompileTimeValidate, CompileTimeInitialize, IAspectProvider and MethodPointcut.

Thanks to some significant engineering effort, this limitation is now removed and all PostSharp features are now equally available on all supported platforms.

Support for Portable Class Libraries

Exogenous platforms are now supported through a single Portable Class Library that can target .NET 4.0, Silverlight 4, Windows Phone 7, and Windows Store 8. Therefore, it is now possible to create portable aspect libraries.

Note that a separate version of PostSharp.dll is still available for .NET 2.0. Unlike the portable version, this one supports serialization of aspects through the BinaryFormatter and provides backward compatibility not only with previous versions of .NET, but also with previous versions of PostSharp.

Because the BinaryFormatter is not portable, we had to develop our own portable serializer. Unlike other formatters readily available with the portable class library, and just as the BinaryFormatter, our implementation serializes the internal object structure (i.e. fields, and not public properties) and supports cyclic object graphs. To use the portable serializer, just use [PSerializable] instead of [Serialiable] and [PNonSerialized] instead of [NonSerialized]. This alone is already a pretty piece of software!

In order to provide support for portable class libraries, we had to do some breaking changes in PostSharp.dll. Specifically, the interface _Assembly is now replaced everywhere by the class Assembly. We had to use the interop interface _Assembly in previous versions of PostSharp because the class Assembly used to be sealed. Since _Assembly is not portable and Assembly is now portable and abstract, we decided to make this breaking change.

Practically, it means that PostSharp 3 won’t compile aspects linked to a previous version.

Unified Deployment Experience

As industry has evolved since PostSharp’s debuts in 2004, we decide to embrace Microsoft’s new vision of development tools deployment. PostSharp distribution is now clearly split into two parts: the compiler is now only distributed as a NuGet package and published on the NuGet Gallery, and the user interface is shipped as a VSIX package and published on the Visual Studio Gallery.

Feature Scavenging

It’s sometimes necessary to make difficult choices and discontinue support for scenarios that seem no longer central. That’s what we did with the following features:

  • Support for Mono as a build platform,
  • Support for Visual Studio 2005 and .NET 3.5 as a build platform (.NET 2.0 is still supported as a runtime platform),
  • Support for .NET Compact Framework (Windows Phone 7 is supported through the Portable Class Library),
  • Support for Silverlight 3 (Silverlight 4 is supported through the Portable Class Library),
  • Diagnostic build,
  • Diagnostic console,
  • Windows Installer distribution,
  • Zip package distribution.

Customers who rely on these features have the possibility to keep using PostSharp 2.1, which is still maintained. Also, note that the user interface of PostSharp 3 is compatible with the compiler of PostSharp 2.1, so side-by-side usage is possible.

Commercial customers who are severely affected by these deprecations are invited to contact us directly.

Continuous Delivery and Subscription-Based Maintenance

As of PostSharp 2.1 we officially switched to a continuous delivery process. We abandoned the distinction between “milestone releases” and “hotfixes” to assure that our customers will always have the latest build from the download page on our website, as well as on NuGet.

All paid PostSharp 3 licenses will come with subscription-based maintenance including 1 year of free updates, web-based technical support, phone support, remote assistance and issue escalation. Maintenance subscriptions are renewed annually with multi-year subscriptions available. Pricing for all PostSharp 3 editions will be announced shortly.

Conditions for Free Upgrade

Those who recently purchased PostSharp 2.1 without support subscription will be eligible for a free upgrade to PostSharp 3, with 6 months of free maintenance from the original date of purchase. This offer is valid only for customers who purchase PostSharp 2.1 within 6 months of the official PostSharp 3 release, scheduled for Q1 2013.

Current PostSharp 2.1 customers with support subscription can upgrade to PostSharp 3 and will receive an additional 6 months of maintenance to their subscription – at no cost.


Note that PostSharp is currently in pre-release quality. It comes with several minor issues and the following limitations:

  • All new APIs are still subject to change.
  • Support for obfuscation is not yet available for portable class library.


Starting today, you will hear much less about aspect-oriented programming from us and much more about patterns. Engineers need patterns because they have been proven to reduce complexity and PostSharp provides ready-made implementations of some of the most common patterns found in .NET applications. Furthermore, PostSharp helps you to build custom design patterns of your own, implement them automatically, and validate that they have been implemented properly. AOP remains at the heart of PostSharp as one of the enabling technologies, but now PostSharp adds even more value to software engineering.

Happy PostSharping!