Today we’re excited to announce the release of PostSharp 4.3 RTM, available for download on Visual Studio Gallery and NuGet.  PostSharp 4.3 addresses the most important concerns of current customers.  It focuses on improving the current experience without adding brand new features.

In a nutshell, PostSharp 4.3 brings you:

  • Improved build-time performance: up to 3x faster
  • Improved debugging experience
  • Alternative to NuGet-based deployment
  • Command-line tool
  • Improvements in the NotifyPropertyChanged aspect
  • Some licensing goodness for everybody.

You can watch the recording of the webinar What's New in PostSharp 4.3 that shows the updates of the new version.

Let’s look at these improvements one by one:

Improved build-time performance

PostSharp 4.3 is up to 3 times faster than PostSharp 4.2. The real figures will depend on the number and size of your projects, how many aspects are being used, and whether you enabled the solution-wide build optimizations. This option can be found under the PostSharp tab of the Solution properties in Visual Studio.

What is does is to try to build the whole solution in a single AppDomain (or as few as possible) so the overhead per project is much smaller.

Improved debugging experience

Debugging an application enhanced with aspects is now even easier thanks to the following improvements:

  • Full support for Just My Code.

  • During Step Into, aspect code is now stepped over by default.

  • The call stack no longer contains PostSharp implementation details by default.

To learn more about these features, see the blog post New in PostSharp 4.3 Preview: Improved Debugging Experience.

Alternative to NuGet-based deployment

Between versions 3.0 and 4.2, the PostSharp compiler and libraries were only distributed as NuGet packages. Let’s face it: some companies did not like this at all that we forced them to use NuGet. Starting from version 4.3, we are re-introducing the old good zip file, and integrate it better with PostSharp Tools for Visual Studio.

For more information, see the blog post New in PostSharp 4.3 Preview – An alternative to NuGet.

Command-line tool

Using PostSharp as a command-line tool is now a supported and documented scenario. It means you can now even instrument assemblies that you are not building yourself – whether or not you have its source code.

You can see how it works in the blog post New in PostSharp 4.3 Preview: Command-Line Interface.

Some licensing goodness for everybody

We hate licensing just as you do but we’ve working on it in PostSharp 4.3 and we’re glad to come with two major improvements:

  • You no longer need a license to build source code that you just checked out from Git or TFS but did not create/edit yourself.
  • The limitations of PostSharp Express for new users are now much simpler: you get everything of PostSharp Ultimate, but only if you add aspects to 10 classes per project.

Improvements in the NotifyPropertyChanged aspect

Due to popular demand, we’ve added support for Caliburn.Micro and MVVM Light.

We’ve also added an option to suppress false positives. To enable the option (which has some runtime overhead and is disabled by default), set the PreventFalsePositives option when constructing the NotifyPropertyChanged aspect:

[NotifyPropertyChanged(PreventFalsePositives = true)]


With PostSharp 4.3, we’ve been addressing the top concerns of existing customers. PostSharp users will spend less time waiting for the build and will be much more productive while debugging. Plus, there’s a ton of improvements to make the deployment and the licensing of PostSharp easier.

PostSharp 4.3 is fully backward compatible with PostSharp 4.2, so it’s safe to update today.

Happy PostSharping!



White Paper

Developers spend up to 20% of their time writing repetitive code that machines could generate more reliably. Download our new white paper 10 Reasons You MUST Consider Pattern-Aware Programming that explores the problem of duplicated source code that stems from manual implementation of patterns and reveals how to automate the boring side of programming and get a 19x ROI.

The document provides insight into:

  • why repetitive code is a major source of pain
  • what technologies for pattern automation exist today
  • why you should consider a pattern-aware compiler extension
  • what investment gains you should expect


The white paper was written for CTOs, software architects and senior developers in software-driven organizations—specifically in financial, insurance, healthcare, energy and IT industries that typically write a lot of repetitive code.



Additionally, we hosted a webinar that covers the white paper topics. Watch the recording and learn about the consequences of boilerplate code and how to eradicate it with pattern-aware programming. You can also download the slides.


About the speaker, Gael Fraiteur

Gael started programming as a kid and never stopped - building and selling his first commercial software at age 12. He is the Founder and CEO at PostSharp Technologies, a widely recognized expert in aspect-oriented programming and pattern-aware programming, and speaks at developer events in Europe and the United States.


We at PostSharp have always been in tension between being innovative and serving big development teams with a more conservative mindset. When we decided to fully embrace NuGet in May 2013 and deprecate our other deployment methods, we truly belonged to the believers. You know, this optimism whispering to you ear that the clouds will move away just before the party starts. Today, we acknowledge that we didn’t serve our enterprise customers well by trying to force them into NuGet, and want to provide an alternative. We’re bringing back our folder-based (zip) distribution, and are integrating it better with our Visual Studio tooling.

What’s still wrong with NuGet?

Clearly, the first version of NuGet was designed to make it easier to get started with new projects on the .NET platform. Get people create a prototype with the less possible friction, so they get addicted to the platform, and are then more likely to accept its limitations. There used to be a lot of criticism in the first years regarding the use of NuGet in the long term. Many limitations have been addressed in NuGet 3. But there are still a lot of good reasons why large teams are right to reject NuGet.

1. NuGet Versioning Hell

One of the main problems of NuGet is that packages are versioned at project-level. If you have several projects, each one can reference a different version of the same package, and it can be difficult to reconcile the conflicts. The problem was exacerbated by the fact that NuGet would select the latest version of a package by default when installed into a project, regardless of the version installed in other projects in the same solution.

Fortunately, the problem was partially solved with NuGet 3. You can now select versioning policies, and it became easier to consolidate versions in the same solution. That seems very reasonable, but this is still insufficient.

A large customer of us has more than 200 developers on the team, more than 100 projects spread over a dozen of solutions. How can you maintain versioning in this setup? Can you imagine the pain of the build manager? For sure, he does not like NuGet. And he probably didn’t like us neither, because we forced him to use NuGet. No longer.

2. Lack of Trust in NuGet Gallery

Another frequent criticism of NuGet in large teams is that it makes it too easy for anyone to pull a dependency. Taking a dependency on a third-party component is a serious decision. Somehow, NuGet makes it too easy to do the wrong thing.

It’s not really NuGet’s fault, it’s rather because of the public NuGet Gallery, which contains unverified packages. Some companies may want to block access to for good reasons. For these customers, we propose the curated package source

Using PostSharp without NuGet

As an alternative to NuGet, we’re re-introducing the folder-based distribution starting from PostSharp 4.3. The feature is hidden by default because we believe this is a minority use case.

To install PostSharp in a solution without using NuGet:

  1. In Visual Studio, go to PostSharp / Options / General / NuGet and check the option Always ask before using NuGet Package Manager.
  2. In the Solution Explorer, right-click on the project and then on Add PostSharp to project.
  3. In the wizard, select Install PostSharp into a new folder then select the installation folder of PostSharp.

As a result:

  • PostSharp compiler tools and libraries will be copied to the folder you specified.
  • A MySolution.pssln file will be created to store the location of the PostSharp folder, so that we don’t need to ask the next time you add PostSharp to a project of the same solution.
  • The project file (csproj) is modified to reference the copy of PostSharp installed in the specified folder.

Updating PostSharp without NuGet

Once you are using PostSharp in a solution (or set of solutions) without NuGet, it is very easy to update it. You just have to download the zip distribution from our web site (a file named and extract it to the installation folder. That’s all. Because the folder name does not include the version number, there is no need to go through all projects and change references. What a relief!


One size does not fit all. NuGet does not work for everybody. Now you can hate NuGet and still love PostSharp. There is no conflict. Starting from PostSharp 4.3, we give you an option to simply extract the product to a folder and reference it. No more versioning hell, no more update headache.

Happy PostSharping!


P.S. This post is the second 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.