Starting from PostSharp 6.6, we’re giving our users the keys to a secret chamber that we’ve previously kept for ourselves: the realm of low-level MSIL development using PostSharp SDK, the layer on which high-level components such as PostSharp Aspect Framework are built.

Best of all: this is going to be free. We are launching a new edition called PostSharp Community that will surpass the old PostSharp Essentials in terms of free features. Not only will it give you access to the lowest layers of PostSharp SDK for free, but also to OnMethodBoundaryAspect, MethodInterceptionAspect and NotifyPropertyChanged for simple cases – and to Contracts.

Our commercial approach: high quality & high abstraction

Since PostSharp 2.0, our mission has been focused on two points: high quality, and aspect-oriented programming.

  • Our emphasis on high quality meant that we spent much effort on engineering (at the risk of over-engineering, sometimes), testing, backward compatibility, robustness, documentation, or continuous delivery. High quality came at a high cost and lower agility. High quality is a win-win: customers are more productive (our ultimate mission), and we can spend less time on support. The proof: we’ve always been able to keep our support time under 20 hours a week in average to support thousands of customers.
  • Our second mission, aspect-oriented programming, meant that we only required our users to have a standard knowledge of .NET. We designed our APIs in such a way that a developer would write correct code “by default” even without reading the documentation. We used abstractions that were similar to the ones most .NET developers were already exposed to, and we considered it our job to bridge the abstraction gap between human thought and MSIL. Since our ultimate vocation is to bridge the gap between human thought and C#, we found it counter-productive to cause even lower-level thinking. In a nutshell, PostSharp was not designed for hackers.

This strategy has been tremendously positive in the last years. Startups and corporates relied on PostSharp to reduce boilerplate, compress development costs and improve long-term maintainability. But it had a cost, too, and we had to reflect this cost in our price list.

Our community approach: lower friction & low abstraction

On the other side, the success of some open-source projects showed that there was a need in the community for a free and low-abstraction solution even at the cost of a lower level of support, testing, and documentation. With PostSharp 6.6, we would like to address this need by opening a community initiative to build add-ins based on PostSharp SDK, our platform for MSIL manipulation.

These community add-ins will be developed on GitHub under a MIT open-source license. They will not be subject to our commercial standards of quality and standard processes, therefore they will also cause less friction. The downside of this strategy is that we expect their quality to be lower than that of PostSharp itself, and therefore we will not provide commercial support for the community add-ins.

To make sure these add-ins are available for free for the community, we are providing free access to the lowest layers of PostSharp SDK. Access to this platform is provided AS IS, without support (even to commercial customers), and with a much lower documentation standard than our commercial products. That said, PostSharp has been publicly available since 2005, and PostSharp SDK is exactly the platform we’re relying on for the upper layers of our product, so we trust its reliability is very high.

PostSharp community add-ins

We have been already working on a couple add-ins. We’ve borrowed them from three sources:

  • adding our own add-ins, written from scratch;
  • releasing existing but internal works;
  • porting open-source add-ins developed for other MSIL stacks such as Fody.

You can find the work in progress at

What else is free in PostSharp Community?

Let’s face it, there were open-source alternatives for a few of the most basic but most useful features of PostSharp. We found it redundant to port these add-ins to PostSharp SDK where they’re already supported with top quality and documentation, so we included the following features for free in PostSharp Community:

Our objective is to make PostSharp your one-stop solution for assembly transformation. Since there are often incompatibilities between IL weavers, it’s better if you can have just one. And we want it to be PostSharp. You can use the free features forever, or you can upgrade to a commercial edition.

Additionally, with PostSharp Community you can use all premium features of PostSharp, but only on a limited project size. We’ll blog later about this possibility.

How to create a PostSharp add-in?

The best way to get started is to look at PostSharp.Community.HelloWorld.

Arguably, the documentation is still very basic, but you can find a few directions here and in the HelloWorld readme file, and you may want to look at the PostSharp SDK class reference.

If you plan to release your add-in as open-source, you’re welcome to join our Slack community channel and ask for help. Please note we don’t have the capacity to provide support to PostSharp SDK to all users and will focus our help on open-source contributors.


At PostSharp we’ve always focused on high-quality, high-abstraction and well-engineered and, let’s face it, high-priced solutions – but we’ve neglected the users who needed low-level access to assemblies, were more sensitive to financial costs, but less demanding in terms of quality.

With PostSharp 6.6, we’re introducing PostSharp Community, a free edition of PostSharp that gives access to community add-ins, simple features of PostSharp, as well as a limited usage of premium features. We’re also releasing 5 community add-ins under the MIT license. We’re grateful to the Fody open-source community for the possibility to port their add-ins to our platform.

Our focus on quality and engineering remains, but we’re opening the door to low-level and low-friction development.

You too can now create your own add-ins with PostSharp SDK, and choose to release them as open source, or keep them private. Your choice.


Happy PostSharping!


We are excited to announce the general availability of PostSharp 6.5 and give you a brief summary of new features and improvements. You can download PostSharp 6.5 from our website here.

With this release we made a significant improvements to build-time and design-time performance of PostSharp.

What is worth mentioning is that PostSharp 6.5 is LTS (Long Term Support) release, meaning that this release is supported for 5 years after the general availability date or one year after we publish the next LTS (the same policy as .NET Core LTS). Also PostSharp 6.5 marks an important milestone for us, as we can finally proudly say that .NET Core is now measured up to .NET Framework.


Here is the summary of all great improvements and features in PostSharp 6.5:

  • Support for Docker - we have successfully tested our product with all Docker images of .NET provided by Microsoft.
  • Build-Time performance enhancements: up to 2x faster - the startup time of PostSharp on .NET Core has decreased significantly and is now on par with the one on .NET Framework.
  • PostSharp Tools for Visual Studio performance improvements 
  • Support for IMemoryCache and the new Azure Service Bus API in Caching - we added suport for the modern Microsoft.Extensions.Caching.Memory.IMemoryCache interface on .NET Core and Microsoft.Azure.ServiceBus, the new API for Azure Service Bus.

We recommend checking out the RC announcement for more details.

Happy PostSharping!

We're happy to announce the release of PostSharp 6.5 RC, available for download on our website.

Most of our efforts with PostSharp 6.5 went into improving the build-time and design-time experience of PostSharp. We also now proudly and officially support Docker, after we have successfully tested our product with all Docker images of .NET Core provided by Microsoft.

This release contains the following improvements:

  • Performance enhancements
  • Installer improvements
  • Docker support
  • Platform updates


Performance enhancements

The startup time of PostSharp on .NET Core has decreased significantly.

The decrease is from 1,100 ms to 400 ms. That is a 2.5 times improvement. Building a lot of small projects should now be significantly faster. To achieve this improvement, we generate ReadyToRun images of PostSharp on the fly on each build machine. This feature can be disabled by setting the PostSharpReadyToRunDisabled MSBuild property to True.

Therefore we are glad to announce that PostSharp performance on .NET Core is now on a par with the one on .NET Framework!


Emitting errors and warnings is now significantly faster.

We removed an overhead of approximately another 400 ms on the first message and further improved the time to emit subsequent messages. The expensive part of emitting a message was to determine in which file and on which line the message should be anchored, and this is what we worked on.

Previously, on the first message, PostSharp loaded Roslyn to parse the source file and tried to locate the line and column of the offending code element. Loading Roslyn was a significant one-time overhead unless native images were present, and even then the cost of parsing was linear to the number of offending files - which could grow high if there was a lot of warnings. Now, we are using a Roslyn analyzer to export the location of all code elements (you will find a new pspdb file in your output directory). This analyzer resides in the Roslyn process itself and uses the already-parsed Roslyn code model, therefore it is very fast. This approach also allows us to find the source code of types with no method body at all, such as interfaces or enums, which previously we were not able to do. The new strategy causes a performance loss when there is no warning at all, but usage data shows that only a minority of projects would be negatively affected.

The analyzer can be disabled by setting the PostSharpRoslynAnalyzerDisabled property to True, but in this case errors and warnings will not be resolved to a source code location.


PostSharp Tools for Visual Studio is now even smoother.

PostSharp tools for VS is significantly better, since we continued to apply the async pattern everywhere. We also optimized memory usage so you should get a better experience with large solutions.


Installer improvements

The installer now lets you:

  • choose which instances of Visual Studio PostSharp should be installed into,
  • kill blocking processes, and
  • easily see the installation log in case of failure of VsixInstaller.exe. 


Docker support

We've tested PostSharp on Docker thoroughly and fixed a few issues with thin Windows images.


Platform updates

  • We added support for the modern Microsoft.Extensions.Caching.Memory.IMemoryCache interface of .NET Core and Microsoft.Azure.ServiceBus, the new API for Azure Service Bus.
  • Visual Studio 2017 RTM (15.0) is no longer supported. It is replaced by Visual Studio 2017 Update 1 (15.9, LTS).




In PostSharp 6.5 we focused on two areas: improving the build-time and design-time experience of PostSharp. 

We are happy to say that, in line with our previous announcements about support for .NET Core, PostSharp performance on .NET Core is now on a par with the one on .NET Framework.

As always, it is a good time to update your VS extension and NuGet packages, and report any problem via our support forum


Happy PostSharping!