At PostSharp we have a strong bias for building against communicating. Between PostSharp 4.2 RTM and now, we’ve already released four previews of PostSharp 4.3. Let’s have a look at the first feature that we almost completed: the command-line interface.

It is now possible to bypass NuGet and MSBuild integration and invoke PostSharp as an executable. This feature was supported up to PostSharp 2.1 and then removed in PostSharp 3. We are including it back because of popular demand.

Why to use the command-line interface?

PostSharp has been primarily designed as an extension to the C# and VB languages that automates the implementation or validation of patterns. Most patterns need to be present for the application to work. Think for instance of INotifyPropertyChanged.  It does not make sense to have a build of your application that does not implement INotifyPropertyChanged. Therefore, the best way to invoke PostSharp is to use the default MSBuild integration.

However, if you think of instrumentation aspects like logging, the situation is different. It is perfectly valid to add logging to an existing assembly. In this case, MSBuild is not the good option.

You can use the command-line interface in the following situations:

  1. When you have access to the source code of a project but you don’t want to add instrumentation into the normal C#/VB project file, but as a separate step.
  2. When you don’t have access to the source code of the assembly you want to instrument. (Legal disclaimer: in this case, make sure your license allows you to modify the assembly)

Example: instrumenting DotNetty

To demonstrate a typical use of the command-line, let’s take some random open-source project: DotNetty, a network stack used by the Azure platform. To keep the example simple, let’s add logging to the Echo.Client assembly.

Step 1. Download and extract the ZIP distribution

If you want to run PostSharp as a stand-alone executable, you will likely prefer to download the zip distribution of PostSharp instead of the NuGet packages. The zip distributions is one of the good things of PostSharp 2.1 that disappeared in PostSharp 3 and that we are bringing back. To download the zip distribution, go to, then download the file named PostSharp-<version>.zip and extract it to your local machine.

Step 2. Create a PostSharp project file

Create a file named postsharp.config (any file name will work) and add the following content:

<Project xmlns="">

<Property Name="Input" Value="Echo.Client.exe" />
<Property Name="Output" Value="Echo.Client2.exe" />
<Property Name="LoggingBackend" Value="Console" />

<LogAttribute xmlns="clr-namespace:PostSharp.Patterns.Diagnostics;assembly:PostSharp.Patterns.Diagnostics" />


Note that you can add any aspect to the assembly using this project file. For details, see our documentation.

Step 3. Invoke PostSharp

PostSharp executables are located under the tools folder. There are a lot of files in this directory, but you should focus on two: postsharp-net40-x64-native.exe and postsharp-net40-x86-native.exe. Use the first executable to transform x64 projects and the second to transform anything else.

Type the following command:

c:\PostSharp\tools\postsharp-net40-x86-native.exe postsharp.config

Step 4. Run the instrumented program

First, copy file Echo.Client.exe.config to Echo.Client2.exe.config so that the new executable will find its configuration.

Then execute Echo.Client2.exe and… enjoy the logging!


With PostSharp 4.3, we are bringing back a few good features of PostSharp 2.1 that disappeared in PostSharp 3: the zip distribution and the command-line executable.

You can use the command-line executable whenever you want to add instrumentation to an assembly without having to recompile it – whether or not you have its source code.

Is it useful for your scenario? How can we improve? Please let us know!

Happy PostSharping,


P.S. This post is the first in a series dedicated to the new features of PostSharp 4.3:

  1. Command-Line Interface;
  2. Improved Debugging Experience;
  3. Alternative to NuGet deployment.

Discover the new features and improvements of PostSharp 4.2 during the webinar with Gael Fraiteur, President & Chief Architect at PostSharp Technologies, and see how we dogfooded the new features in a real-world project of ours: PostSharp Tools for Visual Studio. Get ready to see some real code that runs inside your Visual Studio!

In this webinar, you will see:

  • How we dogfooded our threading models into PostSharp Tools for Visual Studio and what we did to make them more usable;
  • Amazing performance improvements in ready-made patterns;
  • Improvements in INotifyPropertyChanged;
  • Compute how many lines of code you save thanks to PostSharp with the brand new PostSharp Metrics feature.

Watch the recording and see the new features and improvements:

What's New in PostSharp 4.2 on Vimeo.


About the speaker, Gael Fraiteur

Gael Fraiteur

Gael has been passionately programming since childhood; building and selling his first commercial software at age 12. He is President and Chief Architect at PostSharp Technologies based in Prague, Czech Republic. Gael is a widely recognized expert in aspect-oriented programming and speaks at developer conferences in Europe and the United States.


Today we’re excited to announce the release of PostSharp 4.2, available for download on NuGet and Visual Studio Gallery .

This release comes more than 10 months after PostSharp 4.1, and during most of this time the team was focused on a single objective: to improve the quality, performance and usability of existing features. The result: thread-safe design patterns, NotifyPropertyChanged and VB support are now way better than before. PostSharp 4.2 also includes brand new features like code metrics and experimental support for ASP.NET v5.

Threading Models Made Usable

When we announced PostSharp 4.0 in October 2014, we were truly excited to bring a huge innovation to the .NET community and even to the OOP world. This innovation was the ability to write thread-safe code in a mainstream object-oriented language thanks to compiler-supported design patterns. It was not the first time that design patterns were used to achieve thread safety, but this time design patterns were not mere implementation guidelines that developers would benevolently follow: thanks to PostSharp 4.0, patterns are enforced and implemented by the compiler based on declarative indications given by the developer as custom attributes. PostSharp 4.0 gave design patterns a new dimension: the ability to be automatically implemented or verified by the machine, not only saving costly development time, but also avoiding defects.

Proud of our 4.0 release, we decided to dogfood it in a real-world project of us: our PostSharp Tools for Visual Studio, a medium-sized but fairly complex multithreaded codebase. Well, to be perfectly honest, we learned a lot during this project, and found so many issues that we decided that next time we would dogfood before our RTM release.

Today we’re proud to announce that our thread-safety design patterns have reached a new level of quality and usability, with the following improvements:

  • Huge run-time performance improvement. Much lower load on GC at runtime.

  • New ThreadSafetyPolicy attribute to emit warning when a class is not assigned to any threading model or when a static field is not of a thread-safe type. See Making a Whole Project or Solution Thread Safe for details.

  • Better support for async methods: for lock-based models, locks are being awaited asynchronously instead of synchronously.

  • In the actor model, methods with non-void return type are now allowed and their execution will be done in the actor context, but the calling thread will wait synchronously for the execution to complete. Void but non-async methods must now be annotated with [Dispatched] (until the next major version) to specify if execution must be synchronous or asynchronous.

  • New advisable class AdvisableHashSet<T> as a replacement for HashSet<T>.

  • New methods to the AdvisableCollection<T> class: AddRange(IEnumerable<T>) , InsertRange(Int32, IEnumerable<T>) , RemoveRange(Int32, Int32).

  • Support for immutable collections like ImmutableArray or ImmutableDictionary.

  • Support for type adapters to allow third-party classes (at least read-only ones) to work with the Aggregatable pattern. See TypeAdapter for details.

  • Ability to programmatically and automatically mark a field as child or reference without having to use a custom attribute in source code. See FieldRule for details.

Note that these improvements also apply to other consumers of the Aggregatable pattern, principally the undo/redo feature.

Visual Basic Supported, Now Seriously

Since PostSharp operates on MSIL code, VB has been supported from the first day. However, we had no specific test coverage for VB, some VB-specific language constructs were badly supported. Additionally, several features were not available in VB, including PostSharp Tools for Visual Studio and resolution of file/line location in error messages. We decided these were too many gaps and that we had to make a choice: either drop advertisement for VB support or do it properly. We chose the latter.

Starting with PostSharp 4.2, Visual Basic is fully supported at the same level as C#. And, yes, we now have tests written in VB.

Note that VB support in Visual Studio is available for VS 2015 only because it relies on the Roslyn infrastructure. There are periodically speculations in the community that “VB is dead”, but Roslyn gives it a second life. PostSharp 4.2 is the proof.

NotifyPropertyChanged Improvements

PostSharp 4.2 keeps up with C# 6.0 and specifically with the long-awaited, Elvis-nicknamed “?.” operator.

Previously, PostSharp’s implementation of INotifyPropertyChanged was already able to cope with property chains like "this.model.Address.City” . It now also supports chains that use the “?.” operator instead of “.”, for instance "this.model?.Address?.City”.

As a bonus, we now also support properties that depend on properties of variables that are set in conditional blocks (because this is what the Elvis operator does under the hood). For more information regarding this feature, see the PostSharp 4.2 RC announcement .

That’s not all. We also support INotifyPropertyChanging.

Oh, and we also did amazing performance improvements in this release. I mean terrific: we’re now 10x faster at runtime than with PostSharp 4.1.

Aspect Framework Improvements

Although the aspect framework was not our main focus in this release, we added the following features to support the previous improvements:

Code Saving Metrics

First we believed it would be a non-feature for developers and we did it for, hum, sales and marketing purposes. But the feedback we got is overwhelmingly positive.

Briefly said, PostSharp Tools for Visual Studio now tell you how many lines of hand-written code you have, and many lines of code you saved thanks to PostSharp. To see the metrics, build your project and go to the PostSharp / PostSharp Metrics menu item.

You can customize the amount of code considered save whenever one of your custom aspects is applied to a target declaration. For details, see Estimating Code Savings .

Experimental Support for ASP.NET v5

Even if ASP.NET v5 is still preview, we are already providing some experimental support for it. Given the high fragility of ASP.NET v5 public APIs, we are shipping the ASP.NET v5 connector in a separate open-source project named PostSharp.Dnx, hosted on GitHub. Please look at the project home page for instructions.

This experimental connector only supports the .NET Framework, i.e. neither CoreCLR nor Mono is supported.

Note that our plan is to merge PostSharp.Dnx into our main PostSharp package when ASP.NET v5 and the PostSharp connector will be more stable.

To make it possible to open-source the DNX connector, we had to publish a new NuGet package named PostSharp.Compiler.Client , which defines an API to invoke PostSharp. The MSBuild connector now also uses PostSharp.Compiler.Client.


PostSharp 4.2 significantly improves the performance and usability of the features introduced in PostSharp 4.0, namely the threading, aggregatable and undo/redo design patterns. It also brings first-class support for VB and makes our NotifyPropertyChanged aspect understand the new Elvis (?.) operator of C# 6.0.

At PostSharp, we’re more than ever focused on making .NET development more productive, more enjoyable and more reliable. The way we’re achieving this is to put the compiler at work and make it write the boilerplate code for you. To give you an idea of how many lines of boilerplate code you avoided thanks to PostSharp, we added a nice tool window in Visual Studio.

From now on, the team is working on PostSharp 4.3. Make sure you check our roadmap to see what’s coming next.

Happy PostSharping!