Alternatives

You can search the web for hours and get totally confused looking for alternatives to PostSharp, or you can read this page. At SharpCrafters, we don't think PostSharp is the silver bullet. We put customer satisfaction first and want you to understand the pros and cons of competing technologies.

Containers (Dependency Injection)

Most dependency injection frameworks include some aspect-oriented features. While this support is suitable for simple technical requirements (such as tracing or exception handling) applying to application services, this approach will not scale to complex aspects, user interface objects, or domain objects.

Products: Spring.NET, Castle Windsor, Microsoft Unity.

• You may already be using a dependency-injection framework.
• Aspects can be configured after build.
• Some aspects (such as tracing or exception handling) may be provided by the framework.

• Very limited aspect-oriented features.
• Your objects must be instantiated using the container, so it is not suitable for user interface objects (and, most of the time, for domain objects).
• Does not work on static, non-public, and/or non-virtual methods, neither does it work on fields, properties, or events.
• No, or poor, Visual Studio tooling.

Functional Programming

Functional programming (through anonymous methods and lambda expressions) may be the answer to specific problems such as automatic retry of failed transactions.

• Standard C#. You do not need another dependency in your build or runtime code.
• Programmers are already familiar with the technology.
• In some cases, it results in the same number of lines of code as with AOP.

• You cannot automatically pass context from the caller to the aspect code; for instance, you can't use functional programming to implement tracing.
• You have to modify the code of every method to which you want to add the aspect. Real AOP can target many methods in a single piece of code and supports advanced matching and validation rules.
• Aspect composition is less convenient. If you have two aspects on the same methods, and later decide to invert the order of execution of aspects, you must edit every method.

Code Generation

AOP and code generation are two non-competing approaches to metaprogramming. While code generation focuses on producing new source code based on an input artifact of higher level of abstraction (such as a model), aspect-oriented programming excells at weaving (interlacing) source code of two natures - business and technical.

Products: CodeSmith

• It is easy to generate complex source code since all the developer manipulates is C# or Visual Basic.
• The resulting C#/VB code can be opened in Visual Studio and debugged, like any other source code.

• Unlike AOP, the input artifact of a code generator is typically an XML file, not the source code itself.
• The technology cannot inject new instructions into existing source code, or modify the behavior of existing source code in any way.

MSIL Transformation

As PostSharp's popularity grew, we have made multiple attempts to use direct MSIL transformations to add new behaviors to programs. Since PostSharp is itself based on PostSharp SDK, the most advanced assembly transformation platform available, there is nothing you could do with an alternative solution that you could not do with PostSharp.

Products: Mono.Cecil, Microsoft.CCI, CCISharp.

• Eliminates the runtime dependency to PostSharp.dll (note that you could achieve the same benefit by using PostSharp SDK).
• These frameworks are free of charge and backed by large companies.

• Requires an advanced knowledge of MSIL. Note that in MSIL it's quite easy to write a prototype, but it's much harder to write a transformation that works in every condition.
• You will permanently reinvent the wheel. MSIL transformation libraries are generally very low-level, they don't deliver the high-level features of the PostSharp SDK.
• Transformations implemented this way typically do not compose well when many are applied to the same method.
• No Visual Studio tooling.

Dynamic Languages

Most dynamic languages offer a meta-programming facility that lets you modify the structure and behavior of a program during its execution. You could use that meta- programming facility to modularize crosscutting concerns.

• Meta-programming for dynamic languages is easy, since these languages are designed for that purpose.

• You will need to switch to a dynamic language. This is not an easy choice.
• Meta-programming may be too powerful a tool for you; a more disciplined approach may be appropriate.
• No Visual Studio tooling.

Comparing AOP-enabling technologies

Where can you apply aspects?

	PostSharp MSIL transformation	Transparent Proxy Microsoft Unity	JIT-Emitted Proxy Spring.NET, Castle Windsor	JIT-Emitted Subclass Spring.NET, Castle Windsor
Methods implementing an interface	Yes	Yes	Yes	Yes
Virtual public methods	Yes	Only with MarshalByRefObject		Yes
Non-virtual public methods	Yes	Only with MarshalByRefObject		Yes
Virtual protected methods	Yes			Yes
All methods (including private, protected, static)	Yes
External methods (defined in a different assembly)	Yes
Constructors	Yes
Fields	Yes
Properties	Yes
Events	Yes

Other features

	PostSharp MSIL transformation	Transparent Proxy Microsoft Unity	JIT-Emitted Proxy Spring.NET, Castle Windsor	JIT-Emitted Subclass Spring.NET, Castle Windsor
Modify aspects after build		Yes	Yes	Yes
No impact on build time		Yes	Yes	Yes
Use plain old constructors instead of factory methods	Yes
Support for Silverlight & Compact Framework	Yes