Unlike per-developer licenses, per-usage licenses have no limitation on the number of users that can build the projects in the repository. Instead, they limit the number of lines of code you can enhance with PostSharp.
This topic contains the following sections:
A per-usage license can only be installed in a configuration file placed in the repository where your code is. See Deploying License Keys for instructions on how to do that.
If you already have a per-usage license, you can check the current status of how many enhanced lines of code are being reported for your subscription on the customer portal. Sign into the portal with a license key and you'll be able to see the usage data for the last 30 days.
If you're considering to use a per-usage license but don't know how many lines of code you need to purchase, you have two options:
Estimating from the total number of lines of code in a repo
The first option is to compute the total number of lines of code in your repository and then apply a corrective factor.
To estimate how many lines of code are there in your project as seen by our algorithm, you can run the tool found at https://www.postsharp.net/downloads/postsharp-6.6/v6.6.3/PostSharp.LinesOfCodeCounter-6.6.3-preview.zip (make sure to download the latest release) in your repository after building your binaries. The tool uses the same algorithm as the licensing code inside PostSharp.
The tool tells you the total number of lines of your project. Telemetry data shows that customers typically apply aspects to 10-20% of their code. If you're using PostSharp Logging, this correction factor can be 100%.
This should give you an idea of how many lines of code you will need to purchase. You can always start small and increase later, of course.
Measuring from PostSharp Trial or PostSharp Per-User
If you're already using or testing PostSharp, you can measure how many lines of code would be consumed if you had a per-user license.
To measure the number of lines of code that would be consumed from a per-usage subscription:
Install PostSharp Tools for Visual Studio.
In Visual Studio, go to Options / PostSharp / License.
Check the option Enable counting of enhanced lines of code.... Click Ok.
Rebuild all the solutions in which you would like to use PostSharp. You must do that within 24 hours after enabling the option.
In Visual Studio, go back to Options / PostSharp / License and click on the Generate per-usage report link.
The report will open in your web browser. It tells you how many lines of code to purchase for PostSharp Logging, PostSharp Ultimate if PostSharp Logging is also purchased, and PostSharp Ultimate if PostSharp Logging is not purchased.
When PostSharp checks for licenses, it first uses any per-developer licenses that are available, before considering per-usage licenses. When all requirements of a target type are gathered, we select the cheapest license(s) that cover all the requirements. This means that if e.g. both PostSharp Ultimate and PostSharp Logging licenses are present, and a target type requires PostSharp Logging plus some other PostSharp Ultimate feature, only the PostSharp Ultimate license is consumed because it covers PostSharp Logging as well. On the other hand, if only PostSharp Logging is required by the target type, only the PostSharp Logging license is consumed.
If your code uses a feature that is not covered by any per-developer or per-usage license, PostSharp will try to consume the free allowances for premium features offered by PostSharp Community. This means that if a per-usage license is found and it satisfies the requirements of an enhanced type, it is always consumed even though the free features provided by Community Edition have not been used up yet.
Per-usage licenses are always enforced using license audit. Usage data is gathered on all develoment devices and uploaded once per day to our license auditing service in the cloud. The data includes a hash of the repository name, a hash of all enhanced type names, and the number of lines of code in enhanced types, as well as the license key itself.
On our servers, we aggregate the data based on the type name hashes, so that if multiple people build the same code on different devices or build different solutions which share projects, each enhanced type would only consume the licenses once. If the same type hash is reported with different numbers of lines of code, we take the higher number. If the same type has is reported to be enhanced using different sets of subscriptions, all of them are consumed.
PostSharp uses a custom algorithm to count the number of lines in a given type for the purposes of per-usage licensing and to check for PostSharp Community limits. This algorithm has been selected for its high performance, high relevance, and low sensitivity to coding style. We do not pretend this is the best way to count lines of code (we believe there isn't one), but it's a reasonable choice for this purpose.
It's important to understand that the unit of counting is the enhanced type (class or struct). If you enhance a single method or other member of a type, PostSharp will consider that the whole type has been enhanced. This approach is a compromise of relevance and performance.
PostSharp uses the following rules to measure the number of lines of code in each type:
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, typically;
Therefore, we do not count lines of code for namespaces, generic parameters, or custom attributes.
When the code is built with optimizations (this usually happens in Release builds), the resulting IL code may be shorter. In such a case, the number of lines of code that PostSharp detects may differ from results based a non-optimized (Debug) build. Because of the algorithm keeping the highest number for each type during aggregation, we will probably take the Debug build into account.
Note that different versions of the C# compiler may emit a slightly different number of sequence points and affect our algorithm in a way that we cannot control.