Benefits of Metalama over PostSharp

Higher runtime performance

In Metalama, aspects are inlined into your source code: aspects provide code templates that are expanded into your source code at compile time.

By contrast, in PostSharp, aspects were run-time objects that were invoked from your source code. To pass the execution context, such as the current instance and method arguments, from the source code to the aspect, PostSharp used heap-allocated objects such as MethodExecutionArgs. This implementation strategy caused a performance overhead, which is avoided in Metalama.

Thanks to the T# templating technology, it is much easier in Metalama to build high-performance aspects. It is also much easier to understand the performance characteristics of an aspect because the generated code is immediately readable by a human.

Broader platform support

Metalama is purely a compiler-based technology. It supports any platform that is compatible with .NET Standard 2.0.

PostSharp, by contrast, is a post-compiler. PostSharp is a .NET Framework or .NET Core process that loads the whole assembly generated by the compiler into the runtime and then executes aspects, representing the code model with the System.Reflection namespace.

This necessity for PostSharp to load assemblies into the CLR meant that it could not process projects incompatible with .NET Framework or .NET Core and with the processor of the compiler itself. This limitation does not exist in Metalama.

So, how does Metalama execute aspects, if it does not load the assembly into the compiler process? Metalama splits the user code into two subsets: the compile-time code and the run-time code. Metalama compiles the compile-time separately as an assembly targeting .NET Standard 2.0, and loads this assembly into the compiler process. The user code, which may be written for any platform, is never executed in the compiler process.

This new architecture makes Metalama future-proof: Metalama will support any platform that can be coded in C# because Metalama is essentially a compiler or an IDE plug-in, both of which are maintained by Microsoft.

Declarations introduced by aspects are visible from the source code

In Metalama, when an aspect introduces a declaration into a type, this new declaration can be used in your source code as if it were itself part of the source code. This is possible because Metalama runs within the compiler or the IDE.

In PostSharp, declarations introduced by aspects could not be used in your source code. The reason for that limitation is that PostSharp, as a post-compiler, runs after the compiler. Therefore, any change done by PostSharp is not visible from any upstream process, e.g. the compiler or the IDE.

Real-time feedback while editing code

With PostSharp, you had to build your projects to get the warnings and errors provided by the aspects or to update the data shown by PostSharp Tools by Visual Studio.

With Metalama, you get feedback within seconds because your projects are always verified in real-time by the IDE -- and Metalama integrates with the IDE.