I’m happy to announce we’ve just published PostSharp 6.1 RC, available for download on nuget.org (make sure to enable pre-release packages) and on our website .

This release focuses on two areas: we improved the debugging experience, and we took our logging API up to the expectations of a cloud-based, AI-enabled world.

Improved Debugging Experience

PostSharp 6.1 includes a major refactoring of our add-in to the Visual Studio debugger. This add-in makes sure the debugging experience (such as pressing F10 or F11) is natural when aspects are woven into hand-written code. We’ve been working on this feature for more than a year, and we’re excited to finally roll it out.

PostSharp 6.1 fixes most known issues in the debugging experience with a special focus on the debugging of async methods. In previous versions, debugging an aspected async method could be pretty challenging. It now behaves very smoothly.

This feature was a major engineering effort and it has disappointingly little visibility. If we’ve done our job properly, you will not notice any difference when debugging code with or without an aspect. We’re very proud of this achievement and happy it’s finally out.

Semantic Logging

In the past, the primary consumers of logs were human beings. Times are changing. More and more often, logs are stored in centralized and structured servers like Elasticsearch or Application Insights, and statistical processing becomes more important than human readability. And statistical processing, as you know, starts with bucketizing. You want to find the most frequent warning with its most frequent parameters. The problem is, how do you bucketize a human-readable string?

Structured logging is a long step in the right direction because it makes it easier to filter on parameters, but it still based on human-readable strings, and they are still difficult to bucketize.

Enter semantic logging. Contrarily to structured logs, semantic logs are not primarily designed to be read by humans. Each message has a name and a list of name-value pairs. That’s it. Unlike structured logs, it is extremely easy to bucketize semantic logs.

Semantic logging has been with .NET since 2014, although largely ignored. However, I believe that the current cloud & AI trends warrant a shift of mindset, and we’ve implemented support for that in PostSharp 6.1.

For more details, see Writing semantic messages for easy statistical processing in the online documentation.

Distributed Logging

As more and more customers are moving to microservices, distributed logging is becoming increasingly important every day. How to get a consistent trace for the processing of a request whose execution spans several machines? Several practices and specifications like OpenTracing or the HTTP Correlation Protocol are emerging, and logging frameworks need to evolve to support the new concepts.

PostSharp 6.1 brings two improvements for distributed logging:

  • Hierarchical Ids: we can generate ids that let you easily select all records of a distributed request with a wildcard query such as Properties.EventId: "|2ceff3ef47.a2.*", and sort them alphabetically for logical ordering. The generated ids comply to the Hierarchical Request-Id specification .
  • You can now attach properties to custom activities and custom log messages, and mark these properties as cross-process (this implements the Tag and Baggage concepts of OpenTracing).

For more details, see Implementing Logging for a Distributed System in the online documentation.

Sampled Logging

PostSharp Logging makes it so easy to add logging to your application that you can easily end up capturing gigabytes of data every minute. As it goes, most of this data won't ever be useful, but you still need to pay for storage and bandwidth. The ability to trace an application at a high level of detail is very useful, but it is important to be able to select when you want to log. This is especially relevant in web applications.

Starting from PostSharp 6.1, you can select which requests you want to log, and which ones you want to ignore.

For more details, see Choosing Which Requests to Log in the documentation.


In PostSharp 6.1, we focused on two areas: the debugging experience (especially async methods) and logging of distributed applications.

Other improvements include support for C# 7.3, filling gaps in .NET Standard support, and a few other features you will find in What's New in PostSharp 6.1 .

As always at PostSharp, when we say RC, we really mean it: complete tests and documentation, API freeze, backward compatibility, and most importantly, zero known important bugs. It is ready to be tested in your projects, and you can expect an RTM in April.

Happy PostSharping!


TL;DR If you use .NET Standard or .NET Core, you must now upgrade to PostSharp 5.1 even if it is not RTM.

We’re happy to announce that the first preview of PostSharp 5.1 is now ready for download on NuGet Gallery (make sure to enable the “include pre-release” option) and on our website.

PostSharp 5.1 will focus on providing support for .NET Standard 2.0 and .NET Core 2.0. Our objective is to port the PostSharp compiler itself to .NET Standard 2.0 so that we can compile .NET Standard and .NET Core applications natively, without cross-compilation. PostSharp 5.1 will still only support Windows as the only build platform.

PostSharp 5.1 comes after months of increasing instability of PostSharp 5.0. Initially, we tried to implement support for .NET Standard 2.0 and .NET Core 2.0 as bug fixes on the top of PostSharp 5.0, but it proved impossible to do without a significant refactoring of our type binding logic. We decided that, in respect to our .NET Framework users, we could not afford to destabilize PostSharp 5.0 any more, and therefore that any effort to support .NET Standard and .NET Core would go into a new version.

For the same reason, we will no longer solve bugs in .NET Standard 1.* and .NET Core 1.* in our PostSharp 5.0, but only in PostSharp 5.1.

PostSharp 5.0 was significantly destabilized by the release of .NET 4.7.1 and VS 15.5. We did not anticipate the breaking changes, as Microsoft seemed to be more careful with that in the past. At this moment, we realized we passed the breaking point of our type binding component and needed a complete refactoring to isolate us from what Microsoft may deem as implementation details.

We understand that several customers are not allowed to use pre-RTM releases of a product and our decision may push them in a difficult situation. We sincerely apologize. We’re going to push hard to move PostSharp 5.1 to RTM quality as soon as possible. Currently, we consider PostSharp 5.1 to be more stable than PostSharp 5.0, but it lacks testing in the field and customer feedback.

Happy PostSharping!


Today we’re excited to announce the release of PostSharp 4.2, available for download on NuGet and Visual Studio Gallery .

This release comes more than 10 months after PostSharp 4.1, and during most of this time the team was focused on a single objective: to improve the quality, performance and usability of existing features. The result: thread-safe design patterns, NotifyPropertyChanged and VB support are now way better than before. PostSharp 4.2 also includes brand new features like code metrics and experimental support for ASP.NET v5.

Threading Models Made Usable

When we announced PostSharp 4.0 in October 2014, we were truly excited to bring a huge innovation to the .NET community and even to the OOP world. This innovation was the ability to write thread-safe code in a mainstream object-oriented language thanks to compiler-supported design patterns. It was not the first time that design patterns were used to achieve thread safety, but this time design patterns were not mere implementation guidelines that developers would benevolently follow: thanks to PostSharp 4.0, patterns are enforced and implemented by the compiler based on declarative indications given by the developer as custom attributes. PostSharp 4.0 gave design patterns a new dimension: the ability to be automatically implemented or verified by the machine, not only saving costly development time, but also avoiding defects.

Proud of our 4.0 release, we decided to dogfood it in a real-world project of us: our PostSharp Tools for Visual Studio, a medium-sized but fairly complex multithreaded codebase. Well, to be perfectly honest, we learned a lot during this project, and found so many issues that we decided that next time we would dogfood before our RTM release.

Today we’re proud to announce that our thread-safety design patterns have reached a new level of quality and usability, with the following improvements:

  • Huge run-time performance improvement. Much lower load on GC at runtime.

  • New ThreadSafetyPolicy attribute to emit warning when a class is not assigned to any threading model or when a static field is not of a thread-safe type. See Making a Whole Project or Solution Thread Safe for details.

  • Better support for async methods: for lock-based models, locks are being awaited asynchronously instead of synchronously.

  • In the actor model, methods with non-void return type are now allowed and their execution will be done in the actor context, but the calling thread will wait synchronously for the execution to complete. Void but non-async methods must now be annotated with [Dispatched] (until the next major version) to specify if execution must be synchronous or asynchronous.

  • New advisable class AdvisableHashSet<T> as a replacement for HashSet<T>.

  • New methods to the AdvisableCollection<T> class: AddRange(IEnumerable<T>) , InsertRange(Int32, IEnumerable<T>) , RemoveRange(Int32, Int32).

  • Support for immutable collections like ImmutableArray or ImmutableDictionary.

  • Support for type adapters to allow third-party classes (at least read-only ones) to work with the Aggregatable pattern. See TypeAdapter for details.

  • Ability to programmatically and automatically mark a field as child or reference without having to use a custom attribute in source code. See FieldRule for details.

Note that these improvements also apply to other consumers of the Aggregatable pattern, principally the undo/redo feature.

Visual Basic Supported, Now Seriously

Since PostSharp operates on MSIL code, VB has been supported from the first day. However, we had no specific test coverage for VB, some VB-specific language constructs were badly supported. Additionally, several features were not available in VB, including PostSharp Tools for Visual Studio and resolution of file/line location in error messages. We decided these were too many gaps and that we had to make a choice: either drop advertisement for VB support or do it properly. We chose the latter.

Starting with PostSharp 4.2, Visual Basic is fully supported at the same level as C#. And, yes, we now have tests written in VB.

Note that VB support in Visual Studio is available for VS 2015 only because it relies on the Roslyn infrastructure. There are periodically speculations in the community that “VB is dead”, but Roslyn gives it a second life. PostSharp 4.2 is the proof.

NotifyPropertyChanged Improvements

PostSharp 4.2 keeps up with C# 6.0 and specifically with the long-awaited, Elvis-nicknamed “?.” operator.

Previously, PostSharp’s implementation of INotifyPropertyChanged was already able to cope with property chains like "this.model.Address.City” . It now also supports chains that use the “?.” operator instead of “.”, for instance "this.model?.Address?.City”.

As a bonus, we now also support properties that depend on properties of variables that are set in conditional blocks (because this is what the Elvis operator does under the hood). For more information regarding this feature, see the PostSharp 4.2 RC announcement .

That’s not all. We also support INotifyPropertyChanging.

Oh, and we also did amazing performance improvements in this release. I mean terrific: we’re now 10x faster at runtime than with PostSharp 4.1.

Aspect Framework Improvements

Although the aspect framework was not our main focus in this release, we added the following features to support the previous improvements:

Code Saving Metrics

First we believed it would be a non-feature for developers and we did it for, hum, sales and marketing purposes. But the feedback we got is overwhelmingly positive.

Briefly said, PostSharp Tools for Visual Studio now tell you how many lines of hand-written code you have, and many lines of code you saved thanks to PostSharp. To see the metrics, build your project and go to the PostSharp / PostSharp Metrics menu item.

You can customize the amount of code considered save whenever one of your custom aspects is applied to a target declaration. For details, see Estimating Code Savings .

Experimental Support for ASP.NET v5

Even if ASP.NET v5 is still preview, we are already providing some experimental support for it. Given the high fragility of ASP.NET v5 public APIs, we are shipping the ASP.NET v5 connector in a separate open-source project named PostSharp.Dnx, hosted on GitHub. Please look at the project home page for instructions.

This experimental connector only supports the .NET Framework, i.e. neither CoreCLR nor Mono is supported.

Note that our plan is to merge PostSharp.Dnx into our main PostSharp package when ASP.NET v5 and the PostSharp connector will be more stable.

To make it possible to open-source the DNX connector, we had to publish a new NuGet package named PostSharp.Compiler.Client , which defines an API to invoke PostSharp. The MSBuild connector now also uses PostSharp.Compiler.Client.


PostSharp 4.2 significantly improves the performance and usability of the features introduced in PostSharp 4.0, namely the threading, aggregatable and undo/redo design patterns. It also brings first-class support for VB and makes our NotifyPropertyChanged aspect understand the new Elvis (?.) operator of C# 6.0.

At PostSharp, we’re more than ever focused on making .NET development more productive, more enjoyable and more reliable. The way we’re achieving this is to put the compiler at work and make it write the boilerplate code for you. To give you an idea of how many lines of boilerplate code you avoided thanks to PostSharp, we added a nice tool window in Visual Studio.

From now on, the team is working on PostSharp 4.3. Make sure you check our roadmap to see what’s coming next.

Happy PostSharping!