Technical FAQ

PostSharp integrates itself into the build process immediately after the C# or VB compiler. It disassembles the compiler output into an object model, transforms the code as needed, then writes the assembly (along with the rewritten PDB) back to the disk. Learn more here.

MSIL is a highly stable and exceptionally well-specified ECMA standard with multiple open-source implementations. MSIL evolves much more slowly than the C# or VB language, allowing PostSharp to maintain its stability. Microsoft Code Contracts, Microsoft Code Analysis, and several other commercial tools also rely on MSIL rewriting.

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

Proxy-based AOP, facilitated by dependency injection and IoC containers, is a step in the right direction. However, the technology it depends on (dynamic proxies) imposes severe constraints on what can be accomplished. Essentially, you can only intercept interface or virtual methods. Consequently, the number of patterns you can implement using proxy-based AOP is quite limited.

Furthermore, proxy-based AOP compels you to dissect your application into components and interfaces of trivial granularity. As a result, you may find yourself modifying your architecture (with dependency injection) to gain a benefit that is inherent to the technology of dependency injection, but merely a side effect of it.

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

Refactoring tools enhance your productivity when writing code. Your code does not become simpler or more concise as a result of using a refactoring tool. It may be more readable because refactoring tools also possess excellent reformatting capabilities. However, the complexity of your code remains the same as if you were coding manually in, for instance, Notepad. Refactoring tools can be likened to a more sophisticated typewriter.

Conversely, PostSharp enables 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 akin to an advanced typewriter, PostSharp can be compared to a superior language.

For optimal productivity, we recommend using both PostSharp and a refactoring tool. It's like having a superior typewriter and a better language at the same time.

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

PostSharp does not confine you to a specific programming model. Unlike functional programming, which is predominantly popular in academic circles and certain industry niches, PostSharp adopts a pragmatic approach where thread safety is achieved through a combination of build-time and run-time verification. Because PostSharp does not aim to achieve 100% provable soundness at build time, it can focus on providing the maximum level of thread safety that is commercially viable in a business environment.

Please note that PostSharp’s standard of thread safety might be inadequate for operating system kernels, aeronautic/space software, real-time financial trading, or the control of nuclear power plants. However, such critical software typically costs an order of magnitude more than standard business applications.

PostSharp is faster than any alternative technology. However, using PostSharp does come with a runtime performance cost. When discussing the runtime performance of PostSharp, it is crucial to compare the cost of PostSharp's overhead to (1) the cost of the target code and (2) the cost of the behavior added by PostSharp, and then to weigh this cost against (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 applications (whether desktop, mobile, or server-side), but it would be prohibitive in the numeric backend of a scientific or financial application.

Yes, since PostSharp introduces additional steps into the compilation process, there is a performance cost. This is similar to, for example, custom tools run before the C# compiler is executed, such as the XAML compiler.

The extent of this cost largely depends on how extensively PostSharp transforms the original program, which in turn depends on how much PostSharp is utilized. For reference, PostSharp is generally a few times faster than FxCop, which is often run for every build in larger companies.

Please refer to Requirements and Compatibility in the reference documentation.

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

Yes. Deploying PostSharp to any build environment is straightforward because PostSharp is based on the widely-supported NuGet packaging technology. Furthermore, PostSharp does not enforce licensing during unattended builds, so there's no need 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, keeping it clean. PostSharp Tools for Visual Studio push this information directly into Visual Studio, ensuring you are always aware of these patterns.

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

Absolutely. Your debugging experience will not 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 activate the Step Into Aspects option. You're in control.

There's a misconception that aspects are difficult to test, but this is not the case. Testing aspects is simply a bit different. Just as you never test a method without passing arguments to it, you don't test aspects without applying them to some target code. The target code forms part of the context you're passing to the aspect. With this idea in mind, you can use your favorite unit test programs. For more information, see Testing and Debugging Aspects in our documentation.

You should test aspected code in the same way as normal code. There is no difference compared to code where aspects would be implemented manually.