It's been a few days since we released our new website. Although PostSharp 3 is still in preview, we've become confident enough in its quality to start selling licenses – with a 30% discount until we reach RTM. I wanted to quickly tell you about changes made to the PostSharp product lineup, including maintenance, pricing, and upgrade conditions.

New focus on design patterns

In the past years, we've successfully positioned PostSharp as the leading framework for Aspect-Oriented Programming in .NET. With time and customer feedback, we've realized that AOP was only an instrument serving automation and enforcement of design patterns. Unlike AOP, design patterns are readily understood and accepted by the majority. We published our view of Design Pattern Automation in a recent article on InfoQ.

PostSharp is now composed of the following members:

Note that Pattern Libraries were previously incubated as a satellite project of PostSharp 2.1, where they were named toolkits. They are now an integral and supported member of our product line.

We're very proud of our new website, reflects our new vision of PostSharp. There are plenty of tutorials for beginners and intermediate users, and more are coming.

What's New in PostSharp 3?

PostSharp 3 is not just about repackaging old ideas differently. We also added a lot of new features and support for the latest platforms:

  • First-class support for Silverlight, Windows Phone, and Windows Store. Not only did we add new platforms, but we also brought all features to most cousins of the .NET Framework. Best of all: these platforms are supported through a single Portable Class Library, so it's now possible to write truly portable aspects. A central component of this feature is the Portable Serializer, similar in function to the BinaryFormatter (just replace [Serializable] by [PSerializable]).
  • Pattern Libraries, providing ready-made implementation of some the most common patterns. Improvements over PostSharp 2.1 Toolkits include better management through logging profiles, logging to Enterprise Library, code contracts, and performance enhancements.
  • Smart tags in the code editor help you adding ready-made aspects to your application without coding – without even reading our Getting Started. Smart tags are completed with a comprehensive wizard interface coupled with NuGet and a code generator.
  • Support for Visual Studio 2012, including the dark theme.
  • Transparency to all obfuscators: PostSharp does not rely on any string references that may be broken during serialization.
  • Better differentiation of "reference assemblies" and "runtime assemblies".
  • New approach to licensing that will allow to install the license key to source control.
  • Streamlined deployment through NuGet and Visual Studio Gallery

New Maintenance Model

PostSharp 2 was ruled by a "major-version" maintenance model: all updates (minor versions and bug fixes) within a major version were available for free. We released important improvements as "bug fixes": for instance, support for .NET 4.5 was included into PostSharp 2.1 because PostSharp 3 was not ready. This maintenance model created a conflict of interest between us (we need to be paid for our work) and our customers (you can't wait for a new major version to get new necessary features). It was time to change.

PostSharp now comes with 1-year of maintenance subscription included that gives you access to free updates, bug fixes and premium support. Every license key includes the subscription end date, which is tested against the build date of PostSharp. Importantly, licenses are still perpetual: if you can use a given PostSharp build one day, you can use it forever (except with the trial license).

Please read our Licensing & Maintenance FAQ for details. Note that we have an updated License Agreement that reflects these changes. If you need to continue with the previous license agreement, please contact our sales team.

New Product Line

There are now three distinct editions available.
  1. PostSharp Express (formerly Starter Edition) – for getting started with simple custom design pattern automation. Free as in beer.
  2. PostSharp Professional – for automating custom design patterns (aspect framework) and logging (diagnostics pattern library). Price: 449$ or 329€ including maintenance subscription.
  3. PostSharp Ultimate – for automating custom design patterns (aspect framework) and enforcing design rules (architecture framework), includes all ready-made design pattern libraries. Price: 799$ or 589€ including maintenance subscription.
For more information, see the feature matrix of all editions. As you can see, we dropped the Personal License. On the other side, we're now offering free licenses to all freelancers and consultants, additionally to students, educational facilities, and influencers of all sorts. We're also offering a one-time 1000$ discount to all businesses enrolled in BizSpark.

Upgrade Conditions

We're giving 6 months of maintenance subscription for free to all customers:

  • Customers without support subscription fully-featured PostSharp Ultimate for free and get 6-months of maintenance starting from the original date of purchase. Practically, it means that this offer only applies to customers who have purchased PostSharp later than six month ago.
  • Customers with a current support subscription get PostSharp Ultimate for free and will receive an additional 6 months of maintenance, at no cost.
  • Other customers can benefit from our upgrade price (224$/164€ for PostSharp Professional or 399$/299€ for PostSharp Ultimate).

Technically, we consider PostSharp 3 mature enough for most situations. However, if you cannot afford taking risks right now (tight deadline, large team), we recommend to wait until RTM before doing the upgrade. The principle obstacle on the path to RTM is now the lack of documentation for new features and new deployment options.

Downgrade Conditions

We understand that some teams don't want to upgrade to PostSharp 3 now, and may need to acquire new PostSharp 2.1 licenses. When you acquire a PostSharp 3 commercial license, you become eligible for a free PostSharp 2.1 license. To request your license key, please contact our sales team. The offer does not apply to PostSharp Express.

Time-Limited Discount

For a limited time, we’re offering a special discount on PostSharp 3 purchases. From now until the RTM announcement, purchase any new PostSharp Professional or PostSharp Ultimate license and save 30% off your order by entering the discount code POSTSHARP3 during checkout. This offer also includes license upgrades and maintenance subscription renewals.

PostSharp 3 is going to change the way software engineers think about design patterns. Happy PostSharping!


Just a very short post to update you on the status on PostSharp 3. We spent the last 2 months stabilizing the new version, polishing new features without adding any new one, adding more tests, and running test suites on all supported platforms. The team is now quite satisfied with the quality, so we decided to move the quality label from Alpha to Beta. It means that we are code complete, that no important refactoring is planned, and that the only changes should be bug fixes and documentation. We have a few minor UI and UX bugs open, but there should be nothing serious.

The main task that separates us from the Release Candidate status is API and reference documentation. That’s what we are going to work on during the next couple of weeks. The API could still change during this process because documenting also works as an excellent review process.

If you are already using PostSharp 2.1, it is now a good time to try to upgrade to the next version and see if anything goes well. We don’t recommend you to “commit” the upgrade to your main development branch yet (and the PostSharp 3 does not come with a go-production license yet), but it would really help us to have feedback from the field. To upgrade to PostSharp 3, just use NuGet package manager at solution-level and add the pre-release PostSharp package to all projects.

We’re looking forward for your feedback.

Happy PostSharping!


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!