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!


We regret to inform you that the upcoming Visual Studio 2017 Update 8 (15.8) will introduce a change that will break PostSharp NuGet packages with versions 5.0.0-5.0.52 and 6.0.0-6.0.17. The issue has been addressed in 5.0.53 and 6.0.18. 

The cause of the problem is our use of the developmentDependency  flag in our *.nuspec files. Our interpretation of the documentation was apparently incorrect from the beginning but the flag was not properly implemented by Visual Studio, and therefore everything worked perfectly. Now the team at Microsoft decided to implement the flag "properly" at the cost of breaking previous packages, including PostSharp. We discovered the issue while testing the preview of VS 15.8 and reported it to Microsoft but they decided to do the breaking change anyway.

The problem affects projects using the new CPS format with <PackageReference> instead of packages.config. The problem will occur when you will add a PostSharp package to your project. Existing projects that already have a reference to the packages are not affected.

If you are affected by the issue, you have two options:

  • Use PostSharp version 5.0.53 or 6.0.18 if you have an active support subscription or use PostSharp Essentials.
  • Otherwise, you can manually edit the NuGet packages you depend on by unzipping them, removing the developmentDependency flag from the nuspec file, and rezipping them.

This is not the first time that Microsoft does breaking changes and we understand this is the price to pay for the faster release pace we've enjoyed during the last months.

Happy PostSharping nevertheless!



EDIT: Fixed an incorrect information that only projects targeting .NET Core or .NET Standard are affected. Projects targeting .NET Framework may be affected too if they have been converted to PackageReference.

Today we're excited to announce the general availability of PostSharp 6.0. You can download PostSharp 6.0 from our web site, from Visual Studio Marketplace, or from the stable channel of NuGet.org.

While the list of new features seems modest, PostSharp 6.0 is actually the biggest refactoring since the 2.0 version released in July 2010. Most of the work went into supporting .NET Core 2.0 the right way, i.e. natively, without the dirty and increasingly unstable tricks we used in previous versions. This refactoring opens the road to running PostSharp on non-Windows platforms, but this will be for a future version.

We also aligned our versioning and support policies with the ones of Microsoft to cope with the faster release pace of the technologies we're building on (especially .NET Core and Visual Studio). PostSharp 6.0 is meant to replace PostSharp 5.0, so PostSharp 5.0 will stop being supported on September 9th, 2018. PostSharp 4.3 has been marked an LTS release and will be supported one year after the next LTS is released. Note that PostSharp 6.0 is not yet considered an LTS release.

New Platforms

Support for .NET Core 2.0-2.1 and .NET Standard 2.0 - PostSharp now runs natively under .NET Core 2.0 or later, which means that .NET Core projects are no longer cross-compiled from .NET Framework. Note that PostSharp 6.0 will still build only under Windows.

Support for Portable PDB - We now support portable PDB files as well as "embedded" portable PDBs. 

Support for C# 7.2 - The new in parameters and ref struct types are now properly handled. Note that the latest C# version (7.3) is not supported because it was released too shortly before our RC.

Support for CPS-based project systems in Visual Studio - The new project systems, which work with simpler project files and include built-in support for NuGet package references, are now properly supported.

New Features

Robust logging - A defect in the logging feature (whether in your code, in PostSharp, or in the logging framework) will not cause a failure of your application. By default, exceptions open the circuit breaker of the logging subsystem, therefore disabling logging for the rest of the application lifetime. See the documentation of this feature for details.

Flexible logging initialization - It is no longer necessary to initialize PostSharp.Patterns.Diagnostics before the first logged type is hit.

Cache locking - You can prevent concurrent executions of the same methods with the same arguments using the new cache locking facility. We provide an implementation for local (in-process) locking, and an open API to implement distributed locking. See the documentation for details.

Versioning hell solved - Different projects of a solution can now reference a different builds of PostSharp within the same major version, as long as "referencing" projects use a higher PostSharp version than "referenced" projects. We added a test battery to verify structural backward compatibility (compatibility of public APIs and serialization details).

GDPR compliance - We no longer: require your name and email address to register a trial or free license; use non-resettable device ids in our CEIP program; transfer data over unsecure HTTP; transfer personally-identifiable information when we open the web browser from Visual Studio or from our UI. (More work was done on our website to ensure GDPR compliance.)

Deprecated Platforms

Deprecation of support for Visual Studio 2012 - Please update to VS 2013 or later.

Deprecation of support for .NET Core SDK 1.1 - You can still build projects targeting .NET Core 1.1, but using .NET Core SDK 2.0 or later.


We're confident that the future of .NET resides in .NET Core and .NET Standard, and we're excited to say that with PostSharp 6.0 we've finally really caught up and we're ready to keep pace with Microsoft much better than before.

Happy PostSharping!


P.S. Oops, it seems the ducks started the release party without us.