Technical FAQ

PostSharp inserts itself in the build process just after the C# or VB compiler. It disassembles the compiler output into an object model, transforms the code as required, the writes back the assembly (together with the rewritten PDB) to disk. Learn more here.

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.

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.

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.

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.

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.

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.

Please look at Requirements and Compatibility in the reference documentation.

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.

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.

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.

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 this method. If you want to step into the aspect instead, you can turn on the Step Into Aspects option. You're in control.

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 in mind, you can use your favourite unit test programs. For more, see Testing and Debugging Aspects in our documentation.

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