Frequently Asked Questions

Are you looking for the Purchasing & Licensing FAQ?


How does PostSharp affect runtime performance?

PostSharp is faster than any alternative technology. However, there is a run-time performance price associated with using PostSharp. When discussion run-time performance of PostSharp, it is necessary to compare the cost of PostSharp overhead to (1) the cost of the target code and (2) the cost of the behavior added by PostSharp, then to weight this cost with (3) the number of times per second that the method is invoked. You will find that the cost of PostSharp is negligible for typical enterprise application (whether desktop, mobile or server-side) but would be prohibitive in the numeric back-end of a scientific or financial application.

Will PostSharp affect my build time?

Yes, as PostSharp introduces additional steps into the compilation, there is a performance cost. This is the same for e.g. custom tools run before C# compiler is executed such as XAML compiler. How large this cost is, mostly depends on how extensively PostSharp transforms the original program which mostly depends on how much PostSharp is leveraged. For comparison, PostSharp is generally a few times faster than FxCop, which is frequently run for every build in larger companies.


Aren't much of PostSharp benefits possible with dependency injection (IoC containers)?

Dependency injection is like a tractor on the highway: it’s a great tool but often not the best one for that job.

Proxy-based AOP, which is made possible by dependency injection and IoC containers, make a step in the right direction. However, the technology it relies on (dynamic proxies) puts severe constraints on what can be done. Basically, you can only intercept interface or virtual methods. Therefore, the number of patterns you can implement using proxy-based AOP is very limited.

Additionally, proxy-based forces you to dissect your application into components and interfaces of meaningless granularity, so you will find yourself changing your architecture (with dependency injection) to get a benefit that is inherent to the technology of dependency injection, but just a side effect of it.

Finally, proxy-based AOP does not work on all platforms and is much less efficient than PostSharp at runtime.

How does PostSharp differs from refactoring tools like Resharper?

Refactoring tools increase your productivity when writing code. Your code is not simpler or more concise as a result of using a refactoring tool. It can be more readable because refactoring tools also have nice reformatting abilities. But the complexity of your code remains the same as if you were coding manually in, say, Notepad. Refactoring tools are like a more advanced typewriter.

However PostSharp allows you to implement features with fewer lines of code of lower intrinsic complexity. With PostSharp, you write code at a higher level of abstraction. If refactoring tools are like an advanced typewriter, PostSharp is more like a better language.

For optimal productivity, we recommend you use both PostSharp and a refactoring tool. It's like having a better typewriter and a better language altogether.

Messing with MSIL feels kind of “dirty”...

MSIL is a very stable and extremely well specified ECMA standard with several open-source implementations. MSIL evolves much more slowly than the C# or VB language, which allows PostSharp to remain so stable. Microsoft Code Contracts, Microsoft Code Analysis and several other commercial tools also work on MSIL rewriting.

I heard the only right way to have thread safety is to use purely functional languages...

Purely functional languages are thread-safe because they strictly follow the Immutable pattern. PostSharp also offers the Immutable pattern, along with 6 other threading models.

PostSharp does not force you into a specific programming model. Unlike functional programming, which is mainly popular in academic circles and in some specific industry niches, PostSharp follows a pragmatic approach where thread safety is achieved through a combination of build-time and run-time verification. Because PostSharp does not try to reach 100% provable soundness at build time, it can focus on providing the maximum thread safety commercially realistic in a business setting.

Note that PostSharp’s standard of thread safety would be insufficient for operating system kernels, aeronautic/space software, real-time financial trading or control of nuclear power plants, but these pieces of critical software typically cost an order of magnitude more than business applications.


Do I have to replace my existing compiler?

No. PostSharp is compatible with your existing Microsoft compiler, providing the tooling and user experience you’re used to, including light-bulb integration or errors and warnings displayed in the Visual Studio Error List.

Will it work with my build server?

Yes. Deploying PostSharp to any build environment is easy because PostSharp is based on the well-supported NuGet packaging technology. Additionally, PostSharp does not enforce licensing during unattended builds, so you don't have the hassle to install licenses on each build agent.

Debugging & Testing

I’ve tried such a tool in the past and it was difficult to understand my code. How is PostSharp different?

PostSharp comes with Visual Studio tooling that ensures you understand where and how patterns are used in your code. PostSharp applies patterns during compilation without affecting your source code in order to keep it clean. PostSharp Tools for Visual Studio push this information directly into Visual Studio so you are always aware of these patterns

PostSharp Explorer shows which patterns are used and how they affect the codebase. Pattern-aware syntax highlighting shows which code is enhanced by patterns. Pattern-aware tooltips shows which patterns are applied to the current code.

Can I still debug my code using Visual Studio debugger?

Definitively. Your debugging experience won't be affected by PostSharp. If you press F11 to step into a method with an aspect, the debugger will stop inside the aspect code. If you don't want this to happen, you can add the [DebuggerStepThrough] attribute to your aspect. You're in control.

How can I test my aspects?

People believe that aspects are difficult to test, but this is not true. Testing aspects is simply a bit different. Just like you never test a method without passing arguments to that method, you don't test aspects without applying them to some target code. The target code is a part of the context you're passing to the aspect. With that idea on mind, you can use your favourite unit test programs. For more, see Testing and Debugging Aspects in our documentation.

How can I test code that is enhanced by aspects?

You will test aspected code just as normal code. There is no difference compared to code where aspects would be implemented by hand.