Before we start, let me state it clearly: we hate licensing just as you do. It’s a necessary evil – but still an evil. 

In PostSharp 6.6 we’re introducing Per-Repo Subscriptions, a pricing model where you are not charged per daily unique active user but per amount of source code in which you use PostSharp. 

With Per-Repo Subscriptions, we’re hoping to lower the barrier to entry for large teams that want to get started with PostSharp without paying a full license fee for all developers. 

The price of Per-Repo Subscriptions starts at $250 for PostSharp Ultimate or $50 for PostSharp Logging. 

What’s so bad about per-user licensing? 

Software development tools have traditionally been priced per user. If your team of 20 uses Visual Studio, you need to purchase 20 licenses. Per-user pricing is simple to explain and enforce. No wonder it has become the de-facto standard in the software development tools industry. It makes sense for an IDE because most developers open it every day. The ROI of Visual Studio would be much smaller for developers who open the IDE once per week, but this would not be a typical situation. 

However, not all software development tools have the same economics as an IDE. How do you price, say, a data grid control? Suppose you have 10 devs working on a project and you need one data grid. One developer adds the data grid to the app and spends one week integrating it in the codebase. After the initial developer merges the changes, the whole team will need to be able to build the code. With a per-user pricing model, all 10 developers need to be licensed – for a single instance of the control. This cost is clearly prohibitive. 

The caveats of per-user licensing explain many things in our industry: why UI component vendors try to sell large bundles instead of single controls, but also why customers turn to lower-quality open-source products.  

(Note for those interested in economics theory. The per-user pricing model does not lead to Pareto-efficient markets because the product price for the customer is not proportional to its utility. Both the buyer and the seller would have interest in doing more business together – the reason of the market inefficiency is not the product, but the pricing model itself.) 

Enter per-repo subscriptions 

So, how to make the cost of PostSharp more proportional to its usefulness? One of the most important metrics of utility of PostSharp is how much boilerplate code you avoid writing thanks to it. This metric cannot be estimated with enough precision to serve as a pricing basis, so it is not a good candidate. However, the amount of boilerplate code you save is proportional to the amount of hand-written code to which you apply aspects, and this metric can be reliably and precisely measured. 

That’s why we chose to base our new pricing model on the number of lines of code that you enhance with PostSharp. 

All developers would agree that counting lines of code is not the panacea. It is a metric, one that’s reasonably simple to measure and one that is proportional to the benefit you get from using PostSharp. It’s a compromise, and we hope that for many customers it’s a better one than counting unique daily active users. 

Because this new type of subscription is bound to a specific code base, we require the license key to be checked in your source code repository (in a file named postsharp.config). Anybody cloning and building that code would automatically use this subscription. This is why we call it the Per-Repo Subscription. 

How do we count lines of code? 

There is no industry standard about counting source lines of code (SLOC). Different tools would report very different results. What’s important is to only compare numbers given by the same algorithm. 

We chose a counting method that does not depend on code formatting and the amount of blank lines and comments. This method is very fast and precise enough. We count: 

  • one line for each declaration (i.e. for each class, struct, delegate, enum, property, property accessor, event, event accessor, method, field) 
  • one line for each debugger sequence point (i.e. each unique source code location where a breakpoint can be enabled), as emitted by the C# compiler, minus two for the opening and closing bracket 

We do not count lines of code for: namespaces, generic parameters, or custom attributes. 

The granularity level is the class or the struct. If you apply an aspect to a single method of a type, we will count all lines of this type. This, again, is a technical compromise of simplicity and performance, and we understand it may be considered as “unfair” in some situations.  

Aggregating lines of code in the cloud 

Since the license key of the subscription is stored in your source code repository, and since different developers may work on different subsets of the code base, how do we ensure that developers together do not exceed the number of SLOC? 

Short answer: we count on each device, upload anonymized metrics to the cloud, then aggregate per subscription. Daily. 

For each C# project, on each device, we compute the number of enhanced lines of code once per day. We create a file, for each project, mapping a non-reversible hash of the type name to the number of lines of code in this type. Then, each day and on each device, we aggregate yesterday’s files for all projects, and upload the aggregate to the cloud. The data ends up in Data Lake Analytics.  

If you are not online every day, it does not matter – but we do require an internet connection once per week for this licensing model. 

Then, once per day, we run a Data Lake Analytics job to aggregate data per subscription. We prepare detailed reports to be displayed in the customer portal, which looks like this: 


Additionally, the script exports summaries for our sales teams. When we notice that the consumption is higher than the entitlements, we will try to contact you and ask you to purchase more. 

We trust you by default. We will not break your build before we contact you. If you fail to increase the size of your subscription, we reserve the right to remotely deactivate your subscription. 

Per-Repo Subscriptions are Transferable 

Consultancies and bespoke development shops will appreciate this: once your project ends, you can transfer the licenses to your customer together with your source code. Seems logical since the license key is in the source repository, doesn’t it? A legal note: there’s an additional form that the three parties need to sign to make the transfer legally effective. 


Say you have a team of 100 developers and a code base of 1,000,000 lines of code (1,000 KSLOC): a large system with server, desktop and mobile apps.  

You’ve just discovered our [NotifyPropertyChanged] aspect and think you could reduce boilerplate on your MVVM classes. The per-user price for 100 devs would get you to a 5-digit price: a no-starter for your development director. You estimate that you will need to add 10 KLOC of MVVM code in the next months, so all you need to get started is a PostSharp Ultimate Per Repo license for 10 KSLOC. Since 1 KSLOC is given for free, your entry price is 9 x $250 = $2,250. This is just 22$ per developer! Now your development director wishes all publishers would propose our licensing model.  

After your first experience with PostSharp, you learn about other aspects such as caching or authentication, and you start adding them to your server-side code. As your usage of PostSharp increases, you increase the size of your subscription. Eventually, you may decide that switching to a per-user subscription is best for you. But from the beginning, you’ve enjoyed a maximal return on investment. 


Per-user licensing of software has severe caveats and at PostSharp we’ve decided to innovate once again and introduce Per-Repo Subscriptions, a pricing model bound to the amount of code to which you apply PostSharp.  

Per-Repo Subscriptions work by counting lines of code for each enhanced type on each developer workstation, uploading the data to the cloud once per day, and aggregating, and making them available on the customer portal. 

Thanks to Per-Repo Subscriptions, you can have a huge ROI from the first day. No need for a large upfront investment. 


Happy PostSharping! 


We’re happy to announce that PostSharp 6.6 is generally available today for download. Although it comes just 2 months after 6.5, it’s a huge release: we’ve been working on it since August 2019.  

The most visible part of it is a new logo and website, but it’s just the tip of the iceberg. Today, we’re also releasing a major upgrade of our business model and addressing the principal criticism we’ve heard from the community: our licensing and pricing policy

Until today, the only licensing option was to purchase a license for every team member, even before writing your first line of production code. That was a high barrier to entry for customers. Those who went over that barrier often achieved a very high return of investment – 25x is not unusual – but of course, most developers just would not take the risk.  

Our principal objective with this release is to make our adoption curve smoother. 

More free goodies 

First good news: we’re giving away more features for free in our new edition called PostSharp Community that replaces and surpasses PostSharp Essentials.  

Here is what you now get for free: 

  • Simple aspects (OnMethodBoundaryAspect and MethodInterceptionAspect)  
  • Architecture validation (build-time code validation) 
  • Contracts (preconditions, postconditions) 
  • [NotifyPropertyChanged] on auto-implemented properties 
  • Logging in developer mode 
  • Creation of low-level add-ins using PostSharp SDK 
  • Use of community add-ins (7 available at the time of writing) 
  • Apply any premium feature to a maximum of 1,000 lines of code. 

The following features are premium: 

  • Location-level aspects, event-level aspects, composite aspects 
  • Simple aspects applied semantically to async and iterator methods 
  • [NotifyPropertyChanged] with non-auto-implemented properties 
  • Caching, XAML commands and dependency properties, undo/redo, multi-threading 
  • Logging in production mode 

For more information, see PostSharp Community on our web site. 

Per-Repo Subscriptions 

Second good news: irrespective of the size of your team, you can use all PostSharp features for as little as $250 – or $50 if you just want logging.  

Besides Per-User subscriptions, we are introducing Per-Repo subscriptions where the price does not depend on the number of daily unique users, not even on the size of your repository. Instead, the price depends on the amount of code where you want to use PostSharp. 

So, if you liked PostSharp Community and now want to apply premium to more than 1,000 lines of code, you can now purchase a license by increments of 1,000 lines of code. Compare this to having to buy a license upfront for each team member. 

Also, this license is transferable, so if you’re a consultancy doing custom software, you can transfer the license to your customer along with the source code. 

For details about Per-Repo Subscriptions, see this blog post about why and how we're doing it. 

Per-User Lite Subscriptions 

For people who still want a per-user subscription but want to reduce their initial bill with PostSharp, we’re introducing Per-User Lite subscriptions: compared to standard Per-User Subscriptions, it comes with a 30% discount, but it does not contain a perpetual license. At the end of the year, you can choose to renew your Per-User Lite subscription, switch to a perpetual license, or stop using PostSharp. 

Community Add-Ins 

We have released the following add-ins under the open-source MIT license. They can be used for free with PostSharp Community: 


With PostSharp 6.6, we’re introducing a new free edition called PostSharp Community with a lot of unlimited free features and the possibility to apply premium features to 1,000 lines of code per app. For those who reach that limit, we’re introducing the Per-Repo Subscription, where the price depends on the number of lines of code that you enhance using PostSharp. 

Thanks to these new licensing options, you can jump on a 25x ROI immediately, with a minimal upfront investment, and increase your subscription size as your use of PostSharp increases. 


Happy PostSharping! 



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!