PostSharp 6.4 is out and there are many features and improvements that we are excited about. You can download it from our website or from the NuGet gallery.

Staying true to our promises to enhance a developer’s experience by eradicating boilerplate and allowing for more clarity, PostSharp now fully supports .NET Core 3.0, .NET Standard 2.1, C# 8.0 and more. 

What does that mean exactly? 

  1. If you have a .NET Framework application that uses PostSharp, you can now start migrating to .NET Core.
  2. PostSharp has been tested and fixed for all new features of C# 8.0. 

So, if there was a time to get excited, it is now :)  

 

Here is the summary of all great features in PostSharp 6.4:

  • Support for .NET Core 3.0 and .NET Standard 2.1 – yes, we've said it already. We've also updated our package PostSharp.Patterns.Xaml to make sure it works with WPF on .NET Core 3.0.
  • Support for C# 8.0 – default interface methods, nullable reference types and read-only struct members – all fixed and tested in PostSharp 6.4. Go on and try it :) 
  • Support for field/property initializers (breaking change!) – initialization of static fields and properties is now intercepted by the LocationInterceptionAspect.
  • 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.

For detailed description, go back and read the RC announcement

Summary

We are happy to stay on the path of delivering superb support for modern .NET desktop and server-side development to all PostSharp users and allowing them to develop more reliable applications. We have proven that we do keep up the pace with the new generation of .NET technologies and we are planning on continuing that way. 

Don’t forget to download the new release and enjoy all the new features and improvements. We will be happy to hear your feedback.

P.S. If you run into any issues, do let us know via Support.

Happy PostSharping!

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.

Summary

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!

-gael

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!

-gael