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).

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.
[MyLocationInterceptionAspect]
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.
[MyLocationInterceptionAspect]
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.
[DependencyProperty]
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:

[Cache]
[Log]
IEnumerable<int> MyEnumerator()
{
   yield return 1;
   yield return 2;
   yield return 3;
}

 

Summary

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!

-gael

As we continue to deliver on our mission of making .NET development more productive and enjoyable, it is exciting time for PostSharp team to announce PostSharp 6.3 RTM.  You can download it on our website and from nuget.org

We’ve highlighted some notable features in 6.3 RC announcement such as the support for Linux and macOS build agents as well as significant improvement of the responsiveness of PostSharp Tools for Visual Studio thanks to a full async redesign.

 

So, here is the summary of what’s new and great in this release:

 

• Support for Linux and macOS build agents – note that development is still only officially supported on Visual Studio for Windows

• Improved responsiveness of PostSharp Tools for Visual Studio – making PostSharp a well-behaved asynchronous extension

• Support for shared and multi-targeted projects - PostSharp Tools for Visual Studio now works properly with files that are shared between several projects, and with multi-targeted projects

• Support for per-monitor awareness of DPI – resulting in much smoother experience

• Solved aspect ordering issue on async methods – for instance, it is now possible to add a code contract to the return value of a cached async method

• Contracts: ability to customize the type of thrown exceptions - we now use a factory pattern to instantiate exceptions, so you can completely customize the exceptions thrown by standard contracts

 

For a detailed description of all new features, please read the release candidate announcement.

Summary

PostSharp 6.3 RTM is an exciting release with several major improvements: build on Linux and macOS, smoother UX with PostSharp Tools for Visual Studio, and intuitive use of aspects on async methods.

Don’t forget to download the new release and if you run into any issues please use Support to report any problem. We at PostSharp are always focused on high-quality stable releases and on helping you produce clean and reliable software that is easier to maintain. We do look forward to hearing your thoughts.

Happy PostSharping!

We're excited to announce the release of PostSharp 6.3 RC, available for download on our website and from nuget.org (make sure to enable the pre-release option). The most anticipated feature of this release is the support for Linux and macOS build agents. Additionally, we significantly improved the responsiveness of PostSharp Tools for Visual Studio thanks to a full async redesign.

Support for Linux and macOS

The wait is over! PostSharp has supported .NET Standard and .NET Core for a long time, but it still could only run on Windows-based build agents. Starting from PostSharp 6.3, we now support Linux and macOS build agents.

Note that development is still only officially supported on Visual Studio for Windows. Although you can probably live without the code editor extensions and additional tool windows provided by PostSharp Tools for Visual Studio, you would be missing the debugger integration. Without our Visual Studio plug-in, debugging a PostSharp-enhanced application can be confusing. If you don't mind, feel free to develop on Linux or macOS too.

Improved responsiveness of PostSharp Tools for Visual Studio

PostSharp is now a well-behaved asynchronous extension, so you should no longer experience UI freezes because of PostSharp. That was especially laborious because even a thing like getting a dependency from a service locator now needs to be asynchronous. We now stick to the letter of the new async orthodoxy and we must concede, it's for the best.

Support for shared and multi-targeted projects

PostSharp Tools for Visual Studio now works properly with files that are shared between several projects, and with multi-targeted projects. When editing a source file shared by several projects or targets, and if different aspects are used (e.g. using conditional compilation), the code adornments and tooltips now accurately reflect the aspects applied for the current project and/or target. The Aspect Explorer has been updated as well. Previously, PostSharp Tools for Visual Studio did not differentiate assemblies of the same name.

Support for per-monitor awareness of DPI

Several users were affected by a new option of Visual Studio 2019: support for per-monitor awareness of DPI. This option became enabled by default in VS 2019.3 and the number of affected users grew.

We're now happy to say that this issue is solved. We had to rewrite most of our old WinForms code to WPF and we took this opportunity to better respect color themes and icon sets. The result: a much smoother experience.

Solved aspect ordering issue on async methods

With PostSharp 6.3, we've done one more step to simplify the application of aspects to async methods. In the past, OnMethodBoundaryAspect had to be applied after MethodInterceptionAspect on all async methods. Starting from PostSharp 6.3, these aspects can be ordered freely... as long as OnMethodBoundaryAspect does not implement the OnYield and OnResume advices.

For instance, it is now possible to add a code contract to the return value of a cached async method:

[Cache]
[return: Required]
public async Task<string> GetCountryName( [Required] string countryCode )
{
    // ...
}

 

You may think it should have always been working this way and your intuition is correct – but we've had to put hundreds of hours of hard work to make this work intuitively.

Contracts: ability to customize the type of thrown exceptions

In previous versions, it was possible to customize the exception messages, but not the exception types itself. We now use a factory pattern to instantiate exceptions, so you can now completely customize the exceptions thrown by standard contracts. See Customizing Contract Exceptions for details.

Summary

PostSharp 6.3 is an exciting release with several major improvements: build on Linux and macOS, smoother UX with PostSharp Tools for Visual Studio, and intuitive use of aspects on async methods.

As always at PostSharp, we take the RC quality tag very seriously and consider this release as good as, if not better, than the current RTM, with the only reserve that it has not been largely used in the wild. Before we push the release to the stable channel of nuget.org, it's a good time to update your VS extension and NuGet packages, and report any problem via our support forum.