It has been just 3 weeks since we've released PostSharp 6.3 RC with build-time support for Linux and MacOs. Today we're proud to announce the availability of PostSharp 6.4 RC.

Adding support for .NET Core 3.0 and C# 8.0 only 7 weeks after they have been released by Microsoft, PostSharp 6.4 shows our commitment to the new generation of .NET technologies.

Additionally, PostSharp 6.4 fills a few gaps in the aspect framework, including support for field or property initializers, and better support for iterators.

You can download PostSharp 6.4 from our website or from the NuGet gallery (make sure to enable the pre-release option).

Support for .NET Core 3.0 and .NET Standard 2.1

PostSharp now fully supports .NET Core 3.0 (including ASP.NET Core 3.0) and .NET Standard 2.1. We've also updated our package PostSharp.Patterns.Xaml to make sure it works with WPF on .NET Core 3.0.

That means that if you have a .NET Framework application that uses PostSharp, you can now start migrating to .NET Core.

Note that ReadyToRun is not fully supported yet. There are a few bugs whose fixing could be destabilizing and that will be addressed in the next release (6.5). We've also tested and fixed support for ReadyToRun between the RC and the release and we're glad to say it works like a charm.

Support for C# 8.0

Several new features of C# 8.0 affected PostSharp: default interface methods, nullable reference types, async streams, and read-only struct members. We have tested and fixed PostSharp for all these features.

Note that async streams are not yet idiomatically supported in PostSharp Aspect Framework, i.e. PostSharp will not be able to apply semantic advising to methods returning an async stream. PostSharp will treat them as plain methods returning an object. The caching aspect also does not support methods returning an async stream.

Support for field/property initializers (breaking change!)

In previous versions of PostSharp, a LocationInterceptionAspect could not properly intercept field and property initializers. That is, you could not react to the situation where the field or property was assigned on the same line as the declaration. Initializers were simply ignored.

This has been fixed in PostSharp 6.4, and this is a breaking change.

Initialization of static fields and properties is now intercepted by the LocationInterceptionAspect. OnSetValue(LocationInterceptionArgs) advice just as any other assignment:

// Intercepted by OnSetValue.
static int MyStaticProperty { get; set; } = 10;

However, initialization of instance fields cannot be intercepted because LocationInterceptionAspect expects the current object to be already initialized (and the this reference to be usable), which is not the case until the base constructor has been called. Therefore, we defined a new advice method OnInstanceLocationInitialized() that is being called as soon as the base constructor has completed.

// Handled by OnInstanceLocationInitialized.
int MyInstanceProperty { get; set; } = 10;

We have also fixed the [DependencyProperty] aspect so that it now accepts initializers. Note that DependencyProperty.DefaultMetadata.DefaultValue is not affected by the initializer value (that's because the default value in metadata needs to be a constant, while the initializer value can differ for each instance).

// Metadata.DefaultValue *not* set.
public int MyDependencyProperty1 { get; set; } = 10;

If you want to define the metadata default value, you have to define a property in the custom attribute, e.g. [DependencyProperty( DefaultValue = 10 )]:

// Metadata.DefaultValue set.
[DependencyProperty( DefaultValue = 10 )]
public int MyDependencyProperty2 { get; set; }

Free ordering of MethodBoundaryAspect and MethodInterceptionAspect on iterators

It is now possible to freely order an OnMethodBoundaryAspect before or after a MethodInterceptionAspect on iterator methods. That was the last limitation that applied on aspect ordering, except the one on async method when OnYield or OnResume are defined (which still make sense).

Previously, on iterator methods, aspects of type OnMethodBoundaryAspect had to be ordered after any MethodInterceptionAspect. It is also possible to apply an aspect semantically to a method returning an IEnumerable even if it is not an iterator.

Concretely, the following code now works, although it did not with previous versions of PostSharp:

IEnumerable<int> MyEnumerator()
   yield return 1;
   yield return 2;
   yield return 3;



With PostSharp 6.4, we demonstrate we're now again able to support mainstream desktop technologies of Microsoft within months after their general availability. As for each version, the RC milestone means that 6.4 release branch has reached the same maturity as the previous RTM branch, and that we're now waiting for more customer feedback before uploading it to the stable release channels. It's a good time to test it against your projects and report any problem to our support forum.

Happy PostSharping!



EDIT: Support for ReadyToRun was completed between the RC and the release.

This is to announce the availability of PostSharp 6.2 RTM. This release focuses on the support of Visual Studio 2019. You can download it from Visual Studio Marketplace and upgrade your NuGet packages. If you're using our caching aspect with Redis, you may also read our breaking changes documentation.

PostSharp 6.2 comes just 2 months after the release of PostSharp 6.1. This, for us, is in itself a significant achievement. The previous release took 9 months to complete, and the second previous 12 months. This was clearly too slow to react to decreasing predictability (and quality, unfortunately) of Microsoft developer product plans and previews. We changed our release management and git branching strategy to cope with this reality. We now merge features to a release branch only when they are fully stable, tested and documented. This is why we could swiftly react to Microsoft's decision not to release C# 8.0 and .NET Core 3.0 together with Visual Studio 2019, although we've had started to work on these features as well.

Our topmost objective is to maintain a very high quality of the stable release of our product. Our second priority is to keep the ability to release support for new framework versions quickly after they are released by Microsoft, without being hindered by the lack of maturity of other in-progress and in-preview features.

Therefore, you can now look forward for more frequent, smaller releases.

Happy PostSharping!




I’m happy to announce we’ve just published PostSharp 6.1 RC, available for download on (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!