PostSharp Blog

Intercepting Calls to Any Method with Metalama Interceptors

Thu, 29 Oct 2026 07:00:00 +0000

Metalama 2027.0 adds call-site interceptors. An override aspect modifies the called method itself, for every caller, and requires its source code. An interceptor modifies the call sites instead: an aspect or a fabric selects the calls to a method within a given scope, and Metalama rewrites them at build time to target the interceptor. The called method can therefore belong to any assembly: the .NET libraries, a NuGet package, or another team’s project. The interceptor is either a hand-written C# method or generated from a T# template for each signature.

A quick example: retrying calls to a third-party service

ShippingClient is a class of a vendor SDK. Its methods sometimes throw a TimeoutException, and the application calls them from many places:

public class ShipmentService
{
    private readonly ShippingClient _client = new();

    public decimal EstimateCost( string destination ) => this._client.GetQuote( destination );

    public Task<string> GetStatusAsync( string trackingNumber )
        => this._client.GetTrackingStatusAsync( trackingNumber );

    public string Ship( string destination ) => this._client.CreateShipment( destination );
}

The following project fabric retries the calls to the methods of ShippingClient whose name starts with Get:

internal class Fabric : ProjectFabric
{
    public override void AmendProject( IProjectAmender amender )
        => amender.InterceptMethods(
            calls => calls
                .Type( typeof(ShippingClient) )
                .AllMethods()
                .Where( m => m.Name.StartsWith( "Get" ) )
                .RedirectToSynthesizedMethod( nameof(this.Retry) )
                .WithArgs( new { maxAttempts = 3 } ) );

    [Template]
    public dynamic? Retry( [CompileTime] int maxAttempts )
    {
        for ( var attempt = 1;; attempt++ )
        {
            try
            {
                return meta.Proceed();
            }
            catch ( TimeoutException e ) when ( attempt < maxAttempts )
            {
                Console.WriteLine( $"Attempt {attempt} failed: {e.Message} Retrying." );
            }
        }
    }
}

Retry is a T# template: C# code in which meta.Proceed() stands for the original call. From this template, Metalama generates one interceptor per intercepted method:

internal static class MetalamaInterceptors
{
    internal static decimal ShippingClient_GetQuote_Interceptor( ShippingClient receiver, string destination )
    {
        for ( var attempt = 1;; attempt++ )
        {
            try
            {
                return receiver.GetQuote( destination );
            }
            catch ( TimeoutException e ) when ( attempt < 3 )
            {
                Console.WriteLine( $"Attempt {attempt} failed: {e.Message} Retrying." );
            }
        }
    }

    internal static async Task<string> ShippingClient_GetTrackingStatusAsync_Interceptor( ShippingClient receiver, string trackingNumber )
    {
        for ( var attempt = 1;; attempt++ )
        {
            try
            {
                return await receiver.GetTrackingStatusAsync( trackingNumber );
            }
            catch ( TimeoutException e ) when ( attempt < 3 )
            {
                Console.WriteLine( $"Attempt {attempt} failed: {e.Message} Retrying." );
            }
        }
    }
}

The source code of ShipmentService is unchanged; its calls to GetQuote and GetTrackingStatusAsync are routed to these methods. The compile-time parameter maxAttempts became the constant 3, and the interceptor of the async method awaits the call, so the retry covers the whole operation. CreateShipment is not intercepted, because retrying an operation that is not idempotent could create the shipment twice.

Compared with C# interceptors and Roslyn source generators

C# has its own interceptors: a method marked with [InterceptsLocation] replaces the call at one location in the source code, and a Roslyn source generator writes these methods. Metalama interceptors are unrelated to this feature, although both rewrite calls at build time.

Compared with C# interceptors, Metalama interceptors are:

Much simpler. No low-level Roslyn code generator is needed to walk syntax trees, query the semantic model and emit interceptors as C# text. Metalama locates the call sites and generates the interceptors, as in the retry example above.
No additional project. A source generator must live in its own project, referenced as an analyzer. The fabric and the interceptors can live in the same project as the business code.
Template-based. The interceptor is a T# template: C# that looks like the code it generates, with meta.Proceed() for the original call. One template covers every signature, including async and generic methods.
Able to intercept delegates. Method groups converted to delegates, such as items.Select( Normalize ), and event handlers can be intercepted, in addition to calls.

Each approach has its use cases:

Use case	Better tool
Retrying, timing or auditing the calls to an API	Metalama
Tracing calls temporarily, or only in some builds	Metalama
Adding test seams to legacy code, such as faking `Thread.Sleep` or the file system	Metalama
Moving PostSharp call-site interception to Metalama	Metalama
Generating optimized code from the arguments of each call, such as a lambda, a query or a SQL string, as Dapper.AOT and EF Core precompiled queries do	Roslyn source generator
A library that ships interceptors to its users without adding a dependency	Roslyn source generator

Features

Hand-written or template-based interceptors. Calls can be redirected to an existing static method, which can be debugged and unit-tested like any C# code, or to interceptors generated from a T# template, one for each intercepted signature.
Generic interceptors. A generic template covers methods of the same shape whose parameters have different types, such as SaveOrder( Order order ) and SaveCustomer( Customer customer ). Calls to generic methods, such as Serialize<T>( T value ), are handled either by one interceptor per type argument or by one shared generic interceptor.
Call-site context. An interceptor can receive the calling member, the calling object, a parameter of the calling method, and the caller information attributes ([CallerMemberName], [CallerFilePath], [CallerLineNumber]) resolved to the intercepted call.
Additional parameter values. WithArgs assigns values to the parameters of the interceptor that the intercepted method does not have: constants such as literals, enumeration values and types, or values computed for each call site. For templates, it also sets the compile-time parameters.
Async and iterator methods. The interceptor of an awaitable method is async and awaits the call; the interceptor of an async iterator is an async iterator.
Delegates and event handlers. Method groups converted to delegates and event subscriptions are intercepted along with calls, and can be filtered by kind of use.
Interface and virtual calls. Calls bound to overrides of the selected methods are intercepted, and calls bound to implementations of interface methods can be included.
Flexible scope. A registration applies to the target type of an aspect, a namespace, a project, the types that a query selects, some build configurations only, or every project that references a library.
Configurable placement. Interceptors are generated in a shared static class, in a class of your choice, or in the calling type, where they can access its private members and the protected methods of its base classes.

Redirecting calls to a hand-written method

The simplest interceptor is a hand-written static method. Being plain C#, it can be debugged and unit-tested like any other code.

The following method audits the deletion of files. The [ExcludeInterceptors] attribute prevents its own call to File.Delete from being intercepted, which would cause infinite recursion:

[ExcludeInterceptors]
public static class Audit
{
    public static void DeleteFile(
        string path,
        string category,
        [CallerMemberName] string caller = "",
        [CallerLineNumber] int line = 0 )
    {
        Console.WriteLine(
            $"[{category}] {caller} (line {line}) deletes {Path.GetFileName( path )}." );

        File.Delete( path );
    }
}

A project fabric redirects every call to File.Delete in the project to this method, and passes a constant value for category:

internal class Fabric : ProjectFabric
{
    public override void AmendProject( IProjectAmender amender )
    {
        var interceptor = typeof(Audit).AsINamedType()
            .Methods.OfName( nameof(Audit.DeleteFile) )
            .Single();

        amender.InterceptMethods(
            calls => calls
                .Type( typeof(File) )
                .Methods( nameof(File.Delete) )
                .RedirectToExistingMethod( interceptor )
                .WithArgs( new { category = "FileSystem" } ) );
    }
}

The calls in the business code are rewritten at build time:

public class ReportCleaner
{
    public void DeleteReport( string directory, string name )
        => Audit.DeleteFile( path: Path.Combine( directory, name + ".pdf" ), category: "FileSystem", caller: "DeleteReport", line: 10 );

    public void DeleteDraft( string directory, string name )
        => Audit.DeleteFile( path: Path.Combine( directory, name + ".draft" ), category: "FileSystem", caller: "DeleteDraft", line: 13 );
}

Each parameter of the interceptor is bound to a value of the call site. For instance methods, the first parameter receives the receiver of the call. The remaining parameters are matched by name rather than position. Parameters with a caller information attribute, such as [CallerMemberName], receive the location of the intercepted call.

Generating interceptors from a template

Beyond meta.Proceed(), templates can inspect the interception they implement through meta.Interception. For instance, the following line prints the name of the intercepted method:

Console.WriteLine( $"Calling {meta.Interception.Method.InterceptedMethod.Name}." );

By default, call sites that need the same code share one generated interceptor in an internal class named MetalamaInterceptors. A template that depends on the caller must declare it with WithGranularity: the Member granularity exposes the calling member, and the CallSite granularity the call site itself. A finer granularity generates more methods.

The location of the generated interceptor is also configurable. With PlaceInCallingType, it becomes a private method of the calling type, which does not need to be partial. The template can then access the private members of the caller, such as its logger:

public class LogPaymentCallsAttribute : TypeAspect
{
    public override void BuildAspect( IAspectBuilder<INamedType> builder )
        => builder.InterceptMethods(
            calls => calls
                .Type( typeof(PaymentGateway) )
                .AllMethods()
                .RedirectToSynthesizedMethod( nameof(this.LogCall) )
                .PlaceInCallingType() );

    [Template]
    public dynamic? LogCall()
    {
        meta.ThisType._log.WriteLine( $"Calling {meta.Interception.Method.InterceptedMethod.Name}." );

        return meta.Proceed();
    }
}

Applied to OrderService, the aspect generates this method inside the class, next to its _log field:

private static string PaymentGateway_Charge_Interceptor( decimal amount, string currency )
{
    _log.WriteLine( "Calling Charge." );
    return PaymentGateway.Charge( amount, currency );
}

Scoping interceptors

The scope of an interception is determined by where it is registered:

in an aspect, the calls written in the target type of the aspect;
in a namespace fabric, the calls written in its namespace;
in a project fabric, the calls written in the whole project, or in the types that a query selects.

A fabric can also register interceptors only in some builds. The following fabric does nothing unless the TRACE_CALLS symbol is defined:

if ( !amender.Project.PreprocessorSymbols.Contains( "TRACE_CALLS" ) )
{
    return;
}

For finer control, ForEachSite makes a decision for each call site. It can, for instance, pass a parameter of the calling method to the interceptor, or skip the call sites where that parameter does not exist.

Try it

Interceptors are available from Metalama 2027.0.4-preview, in the new Metalama.Extensions.Interceptors package, which works with a free Metalama Community license. This is a preview release and is not supported in production.

The documentation covers the feature in depth:

Interceptors for an overview and the full API.
When to Use Interceptors for their use cases, their limitations, and a comparison with other techniques.

See the Metalama 2027.0 release notes for the rest of the release. We welcome your feedback on GitHub.

Happy meta-programming with Metalama!

This article was first published on a https://postsharp.net/blog under the title Intercepting Calls to Any Method with Metalama Interceptors.

AI Coding Agent Support in PostSharp 2027.0

Wed, 28 Oct 2026 07:00:00 +0000

An AI coding agent in a PostSharp project works half blind. The source of a method shows none of the logging, caching or thread safety that PostSharp weaves into the assembly. When the agent writes an aspect, it rebuilds the API from memory, out of samples that span twenty years of PostSharp versions. And when the build fails, it is tempted to delete the aspect.

PostSharp 2027.0 gives the agent the facts: the real API, what the build actually did, and tests to check the result. Here is what we added:

PostSharp AI Plugin for Claude Code and Codex
CLI Commands to Introspect Aspects Without Visual Studio
Documentation of Every Build Message
Aspect Test Framework

PostSharp AI Plugin for Claude Code and Codex

The PostSharp plugin for Claude Code and OpenAI Codex gives the agent the documentation it needs to work with PostSharp. The plugin contains all the articles in Markdown format, the API reference of every namespace, two scripts that find an article or an API, and compilable source code of all examples. It also instructs the agent to look up the API before writing code, to build to verify, and to fix the cause of a build message instead of silencing it.

In Claude Code:

/plugin marketplace add https://github.com/postsharp/PostSharp.AI.Skills
/plugin install postsharp

Available now from the PostSharp.AI.Skills marketplace. See Configuring AI Coding Agents, which also covers Codex.

CLI Commands to Introspect Aspects Without Visual Studio

The postsharp introspect commands tell, from the files of the last build, which aspects apply to a declaration, what created them, and what they changed, in which order.

postsharp introspect show declaration Orders/Repository.cs:10

The output, abridged:

{
  "declaration": {
    "id": "M:App.Orders.Repository.Save(App.Customer)",
    "kind": "Method",
    "location": "Orders/Repository.cs:10:21",
    "project": "App",
    "targetFrameworks": [ "net10.0" ]
  },
  "aspectInstances": {
    "count": 1,
    "truncated": false,
    "items": [
      {
        "id": "f50384e0ebfe",
        "aspectClass": { "name": "Lib.LogAttribute", "shortName": "Log" },
        "predecessors": {
          "count": 1,
          "truncated": false,
          "items": [
            {
              "id": "0374f134812d",
              "kind": "Multicast",
              "isKindInferred": true,
              "declaration": { "id": "A:App", "kind": "Assembly" }
            }
          ]
        },
        "transformations": {
          "count": 1,
          "truncated": false,
          "items": [
            {
              "targetDeclaration": { "id": "M:App.Orders.Repository.Save(App.Customer)", "kind": "Method" },
              "description": "Wrapped by advice(s) OnEntry",
              "order": 2
            }
          ]
        },
        "linesOfCodeAvoided": 2
      }
    ]
  }
}

The agent learns that the Log aspect applies to Save because of a multicast attribute on the assembly, which the source of Save does not show.

We designed the commands for agents first:

JSON by default, with a stable schema. --format text is for people.
OData queries. list filters aspect classes, aspect instances, transformations and declarations with $filter expressions, such as --where "aspectClass/shortName eq 'Log'".
Output that fits in a context window. Lists are capped and summarized by namespace, and each truncated list gives the command that lists the rest.
batch runs several queries over one load of the projects, several times faster than separate calls.
Backward compatible. The commands read projects built with PostSharp 2023.0 to 2026.0, on Windows, Linux and macOS.

Available from 2027.0.7-preview, in the PostSharp.Tool global tool:

dotnet tool install -g PostSharp.Tool --prerelease

See Inspecting How Aspects Were Applied.

Documentation of Every Build Message

The new Errors and Warnings reference has one article per message code, such as PS0215, with its cause and how to fix it. An agent that reads the message and then its article fixes the code instead of silencing the message.

Available from 2027.0.5-preview.

Aspect Test Framework

The PostSharp.Testing.AspectTesting package, based on xunit.v3, is the framework we use to test PostSharp itself.

One file, one test. Each source file is compiled, woven in an assembly of its own, verified with ILVerify, and run.
Expected files. The test compares the output of the program and the messages of its build with files stored next to it, so a test can expect a build error.
Snapshots of the woven code. With @CompareTransformedCode, the framework decompiles the woven code to C# and compares it with a .t.cs file.

A test applies the aspect and calls the method:

public static class Calculator
{
    [Log]
    public static int Divide( int a, int b ) => a / b;
}

public static class Program
{
    public static void Main()
    {
        Calculator.Divide( 10, 2 );

        try
        {
            Calculator.Divide( 1, 0 );
        }
        catch ( DivideByZeroException )
        {
        }
    }
}

It passes when the program writes the expected output:

Entering Divide(10, 2).
Divide returned 5.
Entering Divide(1, 0).
Divide failed: Attempted to divide by zero.

Available from 2027.0.5-preview. See Testing Aspects with the Aspect Test Framework.

Try It

An agent writes boilerplate fast, but someone still reads every line it writes. An aspect keeps the pattern in one place, and the compiler applies it deterministically at every build, whoever wrote the code.

These features are in preview releases, which are not supported in production. See What’s New in PostSharp 2027.0 for the rest of the release, and tell us how your agent did on GitHub.

Happy meta-programming with PostSharp!

This article was first published on a https://postsharp.net/blog under the title AI Coding Agent Support in PostSharp 2027.0.

Moving PostSharp Aspects to Dependency Injection

Tue, 27 Oct 2026 07:00:00 +0000

PostSharp was designed when dependency injection was still young and the .NET Framework had no built-in container. .NET Core then built one in, around constructor injection, and constructor injection was what PostSharp aspects could not take part in. PostSharp 2027.0 changes that: an aspect can now ask for a service, and the class it enhances receives that service from its constructor, like any other dependency. You can move your legacy code to a DI-centric architecture and bring your aspects along.

Why aspects resisted dependency injection

Two properties of PostSharp aspects made them awkward to combine with a container:

They are instantiated at build time. The aspect object is created by the compiler, serialized into the assembly, and deserialized at run time. No container is involved, so no container can inject anything into it.
They usually have a static scope. Unless it implements IInstanceScopedAspect, an aspect instance is stored in a static field, even when it is applied to an instance method. It is shared by all the objects of the class.

So the usual pattern was a global service locator, resolved when the aspect is initialized at run time:

[PSerializable]
public sealed class AuditedAttribute : OnMethodBoundaryAspect
{
    private static IAuditLog auditLog;

    public override void RuntimeInitialize( MethodBase method )
    {
        auditLog = ServiceLocator.Current.GetInstance<IAuditLog>();
    }

    public override void OnSuccess( MethodExecutionArgs args )
    {
        auditLog.Write( "Executed " + args.Method.DeclaringType.Name + "." + args.Method.Name + "." );
    }
}

Caching was configured the same way, once for the whole process, at startup:

CachingServices.DefaultBackend = new MemoryCachingBackend();

This works, and it has run in production for years. It also has costs that grow once the rest of the application uses a container:

Hidden dependencies. OrderService needs an IAuditLog, but nothing in its constructor says so. You find out when the locator throws.
Initialization order. The locator must be ready before the first enhanced class is used, which rules out the entry point and makes startup fragile.
One global per process. Two tests, or two hosts in the same process, share the same audit log and the same cache. Scoped services, such as a per-request DbContext, are out of reach.

There was a second pattern, closer to dependency injection. An instance-scoped aspect introduced a property into the target class, copied an [Import] attribute onto it, and read it back with [ImportMember]:

[PSerializable]
public sealed class AuditedAttribute : OnMethodBoundaryAspect, IInstanceScopedAspect
{
    [IntroduceMember( Visibility = Visibility.Family, OverrideAction = MemberOverrideAction.Ignore )]
    [CopyCustomAttributes( typeof(ImportAttribute) )]
    [Import( typeof(IAuditLog) )]
    public IAuditLog AuditLog { get; set; }

    [ImportMember( "AuditLog", IsRequired = true )]
    public Property<IAuditLog> AuditLogProperty;

    public override void OnSuccess( MethodExecutionArgs args )
    {
        this.AuditLogProperty.Get().Write( "Executed " + args.Method.Name + "." );
    }

    // CreateInstance and RuntimeInitializeInstance omitted.
}

This worked with MEF and the other attribute-based frameworks of the time, which set the properties of an object after creating it. It does not work with Microsoft.Extensions.DependencyInjection or any other constructor-based container: they pass every dependency to the constructor and never look at properties, and an aspect had no way to add a parameter to a constructor.

Pulling dependencies from constructors

This is what PostSharp 2027.0 adds: aspects themselves can pull their dependencies from the constructor. An aspect requests a service by returning an ImportDependencyAdviceInstance from IAdviceProvider.ProvideAdvices. PostSharp then adds a parameter of the service type to the constructors of the target class, and the advices receive the service through an [ImportMember] parameter.

Here is the same Audited aspect, extended to request three services: a required IAuditLog, an optional IMetrics, and an INotifier that is resolved only when it is first used:

[PSerializable]
public sealed class AuditedAttribute : MethodLevelAspect, IAdviceProvider
{
    public IEnumerable<AdviceInstance> ProvideAdvices( object targetElement )
    {
        // Required: the constructor fails when the service is not available.
        yield return new ImportDependencyAdviceInstance( typeof(IAuditLog) );

        // Optional: the dependency can be null.
        yield return new ImportDependencyAdviceInstance( typeof(IMetrics) ) { IsRequired = false };

        // Lazy: the service is resolved when the advice first uses it.
        yield return new ImportDependencyAdviceInstance( typeof(INotifier) ) { IsLazy = true };
    }

    [OnMethodSuccessAdvice]
    public static void OnSuccess( [Declaration] MethodBase method,
                                  [ImportMember] IAuditLog auditLog,
                                  [ImportMember] IMetrics? metrics,
                                  [ImportMember] INotifier notifier )
    {
        string name = method.DeclaringType!.Name + "." + method.Name;

        auditLog.Write( "Executed " + name + "." );
        metrics?.Increment( name );
        notifier.Notify( name + " succeeded." );
    }
}

The advice is a static method with bound parameters, as described in our previous post on advice parameter binding. The aspect remains statically scoped: it holds no service. The services live in the object that the container created.

The class that uses the aspect declares only its own dependency:

public class OrderService
{
    private readonly IOrderRepository repository;

    public OrderService( IOrderRepository repository )
    {
        this.repository = repository;
    }

    [Audited]
    public void PlaceOrder( int orderId ) => this.repository.Save( orderId );
}

And the composition root registers the services as usual:

var services = new ServiceCollection();
services.AddSingleton<IAuditLog, ConsoleAuditLog>();
services.AddSingleton<IMetrics, ConsoleMetrics>();
services.AddSingleton<INotifier, ConsoleNotifier>();

// Microsoft.Extensions.DependencyInjection does not create Lazy<T> by itself.
services.AddTransient( provider => new Lazy<INotifier>( provider.GetRequiredService<INotifier> ) );

services.AddSingleton<IOrderRepository, OrderRepository>();
services.AddTransient<OrderService>();

serviceProvider.GetRequiredService<OrderService>() returns an OrderService with all four services. The notifier is created only when PlaceOrder succeeds for the first time.

What PostSharp generates

The container can pass the services because the build changed the constructors of OrderService. Here is the woven class, decompiled and cleaned up (we renamed the generated fields and removed the compiler attributes):

public class OrderService
{
    private readonly IOrderRepository repository;
    private readonly IAuditLog auditLog;
    private readonly IMetrics metrics;
    private readonly Lazy<INotifier> notifier;

    // The original constructor, now a forwarder.
    protected internal OrderService( IOrderRepository repository )
        : this( repository, null, null, null )
    {
    }

    // The enhanced constructor, the only public one.
    public OrderService( IOrderRepository repository,
                         IAuditLog auditLog,
                         IMetrics metrics = null,
                         Lazy<INotifier> lazy )
    {
        this.auditLog = auditLog ?? RunTimeServiceLocator.GetRequiredService<IAuditLog>();
        this.metrics = metrics ?? RunTimeServiceLocator.GetService<IMetrics>();
        this.notifier = lazy ?? new Lazy<INotifier>( RunTimeServiceLocator.GetRequiredService<INotifier> );
        this.repository = repository;
    }

    protected IAuditLog AuditLog => this.auditLog;

    protected IMetrics Metrics => this.metrics;

    protected INotifier Notifier => this.notifier.Value;

    public void PlaceOrder( int orderId )
    {
        this.repository.Save( orderId );
        AuditedAttribute.OnSuccess( /* the MethodBase of PlaceOrder */, this.AuditLog, this.Metrics, this.Notifier );
    }
}

The transformation follows a few rules:

One public constructor. The original constructor keeps its body, attributes and parameters in the enhanced constructor, which receives the services as extra parameters. The original signature becomes a protected internal forwarder, so the container sees one public constructor and has no ambiguity to resolve.
The fields are assigned first. The services are stored right after the call to the base constructor, before the body of your constructor runs, as C# would do for a field initialized from a parameter.
Your code wins. If the class already has a field, a property or a constructor parameter of exactly the service type, PostSharp uses it and adds nothing. This is how you give the class itself access to the same service.
Derived classes follow. The classes that derive from OrderService, in the same project or in another project that PostSharp processes, receive the dependencies of their base class, and their base(...) calls pass them. Derived classes can also read the services through the protected properties.
One field per service. When the aspect is applied to ten methods of the class, the class still gets one field and one constructor parameter per service type.

Migrate at your own pace

An application that has been in production for ten years does not move to a container in one commit. Some objects will come from the container long before the others stop using new. PostSharp supports both.

When the source code calls new OrderService( repository ), it calls the forwarder, which passes null for each service. The enhanced constructor then gets the service from RunTimeServiceLocator, a process-wide registry of service factories that PostSharp 2027.0 adds. Register the services there at startup, from your old composition code or from the new container:

RunTimeServiceLocator.RegisterService<IAuditLog>( () => new ConsoleAuditLog() );
RunTimeServiceLocator.RegisterService<INotifier>( () => new ConsoleNotifier() );

new OrderService( new OrderRepository() ).PlaceOrder( 3 );

A required service that nobody registered fails at construction with a message that says what to do:

No service of type MyApp.IAuditLog is registered in RunTimeServiceLocator. Register it with RunTimeServiceLocator.RegisterService, or pass it to the constructor.

An optional service that nobody registered stays null, which is why the advice above writes metrics?.Increment. A lazy service is resolved, and fails if needed, when the advice first uses it.

RunTimeServiceLocator is a bridge for the objects created with new, and it is deliberately limited: it has no scopes and does not dispose anything. As more of the application moves to the container, fewer objects need it.

Caching receives its cache from the container

PostSharp Caching is the first library of ours that uses this mechanism. Set UseDependencyInjection on [CacheConfiguration], on the assembly or on a class, and the classes with cached methods receive an ICachingService from their constructors:

[CacheConfiguration( UseDependencyInjection = true )]
public class ProductCatalog
{
    private readonly IProductRepository repository;

    public ProductCatalog( IProductRepository repository )
    {
        this.repository = repository;
    }

    [Cache( IgnoreThisParameter = true )]
    public Product GetProduct( int id ) => this.repository.Load( id );

    [InvalidateCache( nameof(GetProduct) )]
    public void RenameProduct( int id, string name ) => this.repository.Rename( id, name );
}

The cache, its backend and its profiles are now configured in the composition root, next to the services they depend on, such as the IMemoryCache of the container:

services.AddMemoryCache();
services.AddSingleton<CachingBackend>( provider => new MemoryCacheBackend( provider.GetRequiredService<IMemoryCache>() ) );
services.AddSingleton<ICachingService>( provider =>
{
    var cachingService = new CachingService( provider.GetRequiredService<CachingBackend>() );
    cachingService.Profiles.Default.AbsoluteExpiration = TimeSpan.FromMinutes( 10 );

    return cachingService;
} );

services.AddScoped<ProductCatalog>();

Each container now has its own cache, disposed with the container, so two tests in the same process no longer see each other’s cached items. A test can also replace ICachingService with its own implementation.

Static methods, and methods of structs, have no constructor to receive the service. They keep using CachingServices.DefaultService, the process-wide service that replaces DefaultBackend, and PostSharp reports the warning CAC011 so that you know which ones. Raise it to an error if every cached method must use the container.

Try it

Dependency injection is available from PostSharp 2027.0.6-preview. The documentation covers both halves of the feature:

Receiving Dependencies from the Constructors of the Target Class for your own aspects.
Using Caching with Dependency Injection for PostSharp Caching.

See What’s New in PostSharp 2027.0 for the rest of the release. Pick the aspect that holds your oldest service locator, convert it, and tell us how it went on GitHub.

Happy meta-programming with PostSharp!

This article was first published on a https://postsharp.net/blog under the title Moving PostSharp Aspects to Dependency Injection.

Your Aspects, Faster: Advice Parameter Binding in PostSharp 2027.0

Fri, 23 Oct 2026 07:00:00 +0000

Every OnEntry( MethodExecutionArgs args ) you have ever written pays three costs on every call: it allocates an object on the heap, it boxes the arguments and the return value into object, and it makes you cast them back. Our own Pattern Libraries stopped paying those costs a long time ago, because they use a mechanism we kept internal: advice parameter binding. With PostSharp 2027.0, this mechanism is public, documented and checked at build time.

What MethodExecutionArgs costs you

Here is a typical logging aspect written as a simple aspect. It logs the first argument, the return value, the exception and the duration of the method:

[PSerializable]
public sealed class LogAttribute : OnMethodBoundaryAspect
{
    public override void OnEntry( MethodExecutionArgs args )
    {
        Console.WriteLine( "Entering {0}({1}).", args.Method.Name, args.Arguments[0] );
        args.MethodExecutionTag = Stopwatch.StartNew();
    }

    public override void OnSuccess( MethodExecutionArgs args )
    {
        Console.WriteLine( "{0} returned {1}.", args.Method.Name, args.ReturnValue );
    }

    public override void OnException( MethodExecutionArgs args )
    {
        Console.WriteLine( "{0} failed: {1}", args.Method.Name, args.Exception.Message );
    }

    public override void OnExit( MethodExecutionArgs args )
    {
        var stopwatch = (Stopwatch) args.MethodExecutionTag;
        Console.WriteLine( "{0} took {1} ms.", args.Method.Name, stopwatch.ElapsedMilliseconds );
    }
}

It works, and it has worked for many years. But look at what it asks of the runtime:

One allocation per call. MethodExecutionArgs lives on the heap, and so does the Arguments collection.
Boxing. The Arguments collection stores the arguments with their own types, but exposes them as object, so reading an int through args.Arguments[0] boxes it. args.ReturnValue is an object too, so an int return value is boxed as well.
Casts. MethodExecutionTag is an object too, so the stopwatch must be cast back, and a wrong cast fails at run time.

On a method called a few times per request, nobody notices. On a hot path, the aspect becomes the most expensive part of the method.

The same aspect with bound parameters

With advice parameter binding, the aspect derives from MethodLevelAspect, and each advice method declares only the values it needs, as typed parameters. A binding attribute on each parameter says where the value comes from:

[PSerializable]
public sealed class LogAttribute : MethodLevelAspect
{
    [OnMethodEntryAdvice]
    public void OnEntry( [DeclarationName] string methodName,
                         [Argument( 0 )] object argument,
                         [State( StateScope.MethodInvocation )] out Stopwatch stopwatch )
    {
        Console.WriteLine( "Entering {0}({1}).", methodName, argument );
        stopwatch = Stopwatch.StartNew();
    }

    [OnMethodSuccessAdvice]
    public void OnSuccess<T>( [DeclarationName] string methodName, [ReturnValue] T returnValue )
    {
        Console.WriteLine( "{0} returned {1}.", methodName, returnValue );
    }

    [OnMethodExceptionAdvice]
    public void OnException( [DeclarationName] string methodName, [Exception] Exception exception )
    {
        Console.WriteLine( "{0} failed: {1}", methodName, exception.Message );
    }

    [OnMethodExitAdvice]
    public void OnExit( [DeclarationName] string methodName,
                        [State( StateScope.MethodInvocation )] Stopwatch stopwatch )
    {
        Console.WriteLine( "{0} took {1} ms.", methodName, stopwatch.ElapsedMilliseconds );
    }
}

The bindings in this example:

[DeclarationName] gives the name of the method. It is a constant, computed at build time, so there is no reflection call at run time.
[State] declares a typed variable shared by the advices for one execution of the method. The entry advice assigns it with out, and the exit advice reads it. There is no MethodExecutionTag and no cast.
[ReturnValue] on a generic parameter T receives the return value without boxing. PostSharp infers T for each target method.
[Argument( 0 )] reads the first argument. Here it is still boxed, because the parameter is object. Make the advice generic to avoid it, as shown below.
[Exception] gives the exception, typed as Exception.

The aspect is applied exactly as before, with [Log] on a method or with multicasting.

What PostSharp actually generates

Bound parameters are a build-time contract, so the woven code passes the values directly. Take a smaller profiling aspect, with an entry advice that starts a [State] stopwatch and an exit advice that prints the [DeclarationName] and the duration (see Aspect Development Concepts). PostSharp transforms the target method into code equivalent to this:

public void PlaceOrder( Order order )
{
    Stopwatch stopwatch;
    aspect.OnEntry( out stopwatch );
    try
    {
        // Method body.
    }
    finally
    {
        aspect.OnExit( "ProfileAspect.OrderService.PlaceOrder", stopwatch );
    }
}

The state is a local variable, the method name is a string literal, and the advices are plain method calls. Apart from the Stopwatch itself, the woven code allocates nothing.

Generic advices, inferred for each target

An advice method can be generic. PostSharp infers the type arguments separately for each target method, with rules similar to the type inference of the C# compiler, and then calls a different instantiation of the advice from each target.

Take the OnSuccess<T> advice above. On int Square( int value ), PostSharp calls OnSuccess<int>. On string Format( Order order ), it calls OnSuccess<string>. The same source method serves every signature, and an int stays an int all the way.

Inference also works through constructed types and constraints:

[OnMethodEntryAdvice]
public void OnEntry<T>( [DeclarationName] string methodName,
                        [Argument( 0 )] IEnumerable<T> items )
    where T : IComparable<T>
{
    Console.WriteLine( "{0} received {1} items, the first is {2}.",
                       methodName, items.Count(), items.FirstOrDefault() );
}

Applied to a method that takes a List<int>, this advice gets T = int: PostSharp matches IEnumerable<T> against the type of the argument, its base types and its interfaces, as C# would. The rules, in short:

No boxing. A value of a value type is passed as it is, and a ref, out or in parameter receives the location itself.
Common type. When several bound values give a type argument, it is the type to which all of them can be assigned. OnEntry<T>( [Argument( 0 )] T a, [Argument( 1 )] T b ) on M( string, object ) gives T = object.
Constructed types. T[], T?, IList<T> and the like are matched against the value’s type, its base types and its interfaces.
Constraints are checked. Including unmanaged, new() and constraints that refer to other type parameters.

When a type argument cannot be inferred for a target, or violates a constraint, the build fails with the error LA0220, which states the reason. Apply the advice above to a method that takes a List<object>, and you learn at build time that object does not implement IComparable<object>.

The type of a parameter can also use the type parameters of a generic aspect class. They are replaced by the type arguments of the aspect instance. See Generic advice methods for the complete rules.

Errors at build time, not in production

A simple aspect accepts any method, then fails at run time if it makes a wrong assumption, for instance by reading args.Arguments[0] on a method that has no parameters.

With bound parameters, PostSharp checks each advice against each target when it weaves the aspect. An advice that does not fit a target is a build error with a message code. Apply the LogAttribute above to a method without parameters, and [Argument( 0 )] causes the error LA0225: the target method has no parameter at this index. A parameter of the wrong type, a binding used in an advice that does not support it, or a type argument that cannot be inferred all have their own codes. PostSharp reports all the errors of an aspect in one build.

The complete list of build messages is in the reference.

Beyond the basics

The logging example uses five bindings. The Advice Parameter Reference lists them all. Among them:

Write access with ref and out. Replace an argument, set or replace the return value, or replace the exception.
[FlowBehavior] to return without executing the method, or to swallow an exception.
Async methods. [CurrentTask] gives the task that the caller observes, including for ValueTask methods, and [AsyncCallId] identifies one execution of the async method.
Interception. [Binding] gives an object that invokes the original method, field or property.
[This], [Declaration] and [DeclarationIdentifier] for the instance and the reflection object of the target.

Grouping also got simpler. [SelfPointcut] and the Master property are optional when the grouping of the advices is unambiguous, so an aspect that applies to a single method, field, property or event needs neither.

Should you modernize your aspects?

Not necessarily. Simple aspects remain fully supported, and you can keep the AdviceArgs signature in the following cases:

The aspect intercepts events, validates fields or parameters, or uses OnInvokeAsync. These advices do not accept bound parameters yet.
The aspect reads the value yielded by an iterator, which only MethodExecutionArgs.YieldValue gives.
The aspect is not on a performance-sensitive path, and you prefer the simpler programming model.

The other limitations are listed in the reference.

For the aspects that do run on hot paths, the conversion is mechanical. Change the base class to MethodLevelAspect or LocationLevelAspect, turn each override into an advice method with the matching attribute, replace each args member with a bound parameter, and build. PostSharp tells you what does not fit. The Modernizing Your Custom Aspects article gives the steps and a table that maps each member of MethodExecutionArgs, MethodInterceptionArgs and LocationInterceptionArgs to its binding.

Try it

Advice parameter binding is available from PostSharp 2027.0, which also adds support for .NET 11 and C# 15. See What’s New in PostSharp 2027.0 for the full list. Pick one aspect on your hottest path, convert it, and tell us how it went on GitHub.

Happy meta-programming with PostSharp!

This article was first published on a https://postsharp.net/blog under the title Your Aspects, Faster: Advice Parameter Binding in PostSharp 2027.0.

Security and Privacy Update for PostSharp and Metalama

Tue, 30 Jun 2026 19:00:01 +0000

Today we are shipping a coordinated security and privacy update across every supported branch of PostSharp and Metalama. It covers the build toolchain, the design time services, telemetry, and the Visual Studio Tools. It does not change the public API or how you write aspects, and none of it reaches your compiled application: every issue is in tooling that runs on developer and build machines, so the applications you have already built and shipped are not affected.

In short: All fixes are already shipped on every supported branch. The most serious issues (three High-severity advisories) require an attacker to already have a local account on your machine, so they mainly affect shared or multi-user build agents. Upgrade when convenient; prioritize it if you build on shared agents. Nothing else to do.

Scope and attack vectors

We published GitHub Security Advisories for the most severe findings, all rated High. They require the attacker to already have local access to the same machine, under a different user account, which mainly matters on shared or multi-user build agents.

PostSharp:
- Local code execution, information disclosure, and denial of service in the build toolchain on shared machines (GHSA-gpwg-4q4j-792q)
Metalama:
- Unsafe deserialization over the Visual Studio named pipe enables local code execution (GHSA-h26j-4vp7-x9w2)
- Local code execution via DLL planting in world-writable temp directories on Linux/macOS (GHSA-m6wq-39m7-9xpp)

We found and fixed other vulnerabilities that required the attacker to sit between your device and our postsharp.net or metalama.net servers as a man-in-the-middle. See the GitHub release notes in the What changed section below.

None of these vulnerabilities could be exploited by a remote attacker against a normal developer or CI setup.

One assumption is unchanged: like the .NET SDK itself, PostSharp and Metalama assume your source code and NuGet dependencies are trusted, and they execute that code at build time. This review hardened everything around that boundary, but it does not sandbox hostile source or malicious packages. Vetting what enters your build remains your job.

There is no known exploitation, and no customer needs to do anything beyond upgrading when convenient.

Why now, and not sooner

No attacker or customer reported these issues. We found and disclosed them ourselves, and published the advisories with the fixes already shipped on every supported branch.

Why now? Because the new generation of AI models makes it both possible and urgent. Auditing a 20-year-old living codebase used to mean weeks of work and skills we didn’t have in-house. It did not seem necessary for a niche tool that processes trusted local inputs without network access. However, with new AI tools, an in-depth security analysis takes a couple of hours, both for the publisher and the attacker. We used Claude Opus 4.8 for the review, reviewed every finding, supervised and refined the fixes, and tested them on real VMs before release. The whole pass still took weeks; without the model it would not have happened.

Run the analysis yourself

We believe that security stems from transparency. Ultimately, it does not matter who wrote the code you execute. What matters is the code itself.

Metalama is open source: clone it from GitHub and point your own tools at it. PostSharp’s source is available to enterprise customers at no additional charge under a source-available license, going back to version 1.0; see PostSharp Is Now Source Available.

If you run your own analysis, report any defects privately through GitHub Security Advisories (Metalama, PostSharp) and we will handle them the way we handled this review. Our security policy describes how we receive, prioritize, and disclose vulnerabilities.

What changed

Across all these releases, the work falls into a few themes:

Safer behavior on shared machines. Caches, temp files, and local servers now stay scoped to the current user, so one user cannot interfere with or read another’s build.
Telemetry hardened to minimize what leaves your machine. Crash reports now omit exception messages and data, and do a more thorough job scrubbing both secrets and confidential identifiers, such as a company name embedded in a namespace, so a stack trace can’t carry a token, a connection string, or your internal names off your machine. We rotate device IDs monthly and keep separate salts for our own diagnostics and our third-party analytics, so the two are much harder to correlate. For exactly what we collect and how to turn it off, see our privacy policy.
Removed features that collected data. We took out the in-product extras that came with a data cost: the Learning Hub tool window in Visual Studio, the Areas of Interest selection, and newsletter and email registration. We also removed the telemetry code for the long-defunct per-usage licensing model, which used to upload reversibly-hashed type names.
Defense in depth against our own servers. Some data comes from postsharp.net or metalama.net, such as the news feed and content feeds. We hardened the parsers and serializers that handle it, so a compromise of our servers could not turn that data into code execution on your machine.

The LTS and latest branches get the full set of changes. The two Metalama advisory fixes were also backported to the other supported versions, 2025.1.18 and 2026.0.25, without the broader privacy and telemetry rework. See the version status page for what is still serviced.

The per-release notes have the full technical detail:

PostSharp:
- 2026.0.13 (Current)
- 2024.0.23 (LTS)
Metalama:
- 2026.1.19 (Current)
- 2026.0.25 (Extended Support: advisory fixes only)
- 2025.1.18 (Extended Support: advisory fixes only)
Visual Studio Tools for PostSharp and Metalama:
- 2026.1.5

All packages are on NuGet.org, and the extension is on the Visual Studio Marketplace.

Updated policies

As part of this review we updated our privacy policy to describe exactly what we collect, and our security policy to reflect the current threat model and how to report a vulnerability.

How to upgrade

For most users this is a drop-in upgrade: bump the NuGet versions and update the extension. No API changes, nothing to reconfigure. Open-source and free-edition users can upgrade freely; for commercial editions, upgrading requires an active maintenance subscription. If you build on shared or multi-user agents, prioritize it.

What’s next

The next Metalama and PostSharp feature releases will focus on .NET 11 support, with work starting in late August.

Found an issue or have a feature request? Let us know on GitHub.

Happy meta-programming!

-gael

This article was first published on a https://postsharp.net/blog under the title Security and Privacy Update for PostSharp and Metalama.

Metalama 2026.1 Generally Available: First LTS Release, Complete C# 14 Support, and a Redesigned Redis Backend

Wed, 03 Jun 2026 07:00:01 +0000

Metalama 2026.1 is now generally available, and it’s our first long-term support (LTS) release. This is a consolidation release: we finished the C# 14 work we started in 2026.0, extended the advising API, redesigned the Redis caching backend, cut several third-party dependencies, and closed most of the bug backlog.

The packages are on NuGet.org, and the Visual Studio extension is on the Visual Studio Marketplace.

For the complete list of changes, see the release notes.

Complete C# 14 support in aspects

In 2026.0 we supported all C# 14 features in your own code but left a few gaps in aspects. Those gaps are now closed:

Introducing extension blocks. The new IntroduceExtensionBlock advice lets aspects add extension blocks to static classes. See Introducing types.
Contracts on extension-block receiver parameters. You can now add a contract to the receiver parameter of an extension block, and it propagates across the extension members.
Introducing user-defined compound assignment operators. Operators such as +=, -=, and *= can now be introduced through IntroduceMethod.
Run-time invoker interfaces for extension members.
Introducing parameters into partial constructors.

Two C# 14 constructs remain unsupported inside templates: null-conditional assignments (x?.P = v) and the field keyword. Rather than fail confusingly, Metalama now detects them and reports a clear diagnostic (LAMA0101).

Initialization advice

We’ve extended the initialization advice with two new initializer kinds and better support for records:

AfterLastInstanceConstructor injects code into a protected virtual OnConstructed method, so it runs once after the most-derived constructor completes.
AfterObjectInitializer runs after the constructor and any object initializer or with expression have completed. Metalama makes the target implement IInitializable and rewrites the call sites accordingly, so you can validate or compute derived state once every property has been set.
BeforeInstanceConstructor now works on positional records with primary constructors.
Constructor parameter introduction can now generate forwarding overloads, so you can add a parameter without breaking binary compatibility.

Dependency injection

IntroduceParameterAndPull now accepts a reuseExistingParameterOfCompatibleType argument. When a chained constructor already accepts a parameter of the same or a more specific type, the existing parameter is forwarded instead of duplicated. The default .NET DI adapter relies on this: an aspect that pulls an ILogger<T> no longer adds a second ILogger<T> parameter when the target constructor already has one. See Injecting dependencies into aspects.

Redesigned Redis caching backend

Metalama.Patterns.Caching.Backends.Redis received a major overhaul, porting the work we did for PostSharp 2025.1 (see Breaking Update of PostSharp Caching adapter for Redis in 2025.1):

New data schema. Reading a cache item is now a single, observationally-consistent operation, and cache keys are versioned.
Cluster support. Hash tags keep related keys on the same shard, and you can configure ReadCommandFlags and WriteCommandFlags for multi-node setups.
Retry and exception-handling policies. The new IRetryPolicy and IExceptionHandlingPolicy interfaces give you exponential backoff and centralized error handling.
Key compression. Keys longer than a configurable threshold (128 characters by default) are hashed automatically with XxHash64 or XxHash128.
Overload detection. The IsBackgroundTaskQueueOverloaded property lets you back off under pressure, and the dependency garbage collector pauses itself when the queue is saturated.

If you use the Redis backend, note that the schema change requires purging the cache (FLUSHDB) on upgrade. See the breaking changes below.

Fewer third-party dependencies

We reduced our dependency surface to improve supply-chain safety:

System.Text.Json replaces Newtonsoft.Json.
System.IO.Hashing replaces K4os.Hash (the xxHash implementation now comes from the .NET runtime).
Diff-tool integration moved to the optional Metalama.Extensions.DiffEngine package, and HTML test output moved to Metalama.Extensions.HtmlWriter (both used in aspect snapshot testing).
We no longer use MD5 for non-cryptographic hashing.

Performance improvements

This release improves both build-time and design-time performance. At build time, configuration files now use System.Text.Json source generators, polymorphic pattern matching in the code model was restructured to match on DeclarationKind or TypeKind, and the WPF temporary compilation phase (MarkupCompilePass1) runs a reduced pipeline that emits member signatures only and skips the linker step. At design time, the protocol between the analyzer and the design-time services moved from JSON to MessagePack.

Bug fixes

We fixed over 100 bugs in this release, spanning the template engine, linker, code model, design-time services, dependency injection, and diagnostics. Metalama 2026.1 is the first release ever to ship with (almost) zero known bugs.

Breaking changes

A few changes may affect existing code:

AddInitializer ordering now respects AspectOrderDirection.RunTime.
IntroduceParameter on a record primary constructor no longer materializes the parameter by default; opt in with materializeOnRecord.
IConstructor.InitializerKind returns Base (instead of None) for an implicit base() call.
IEvent.RaiseMethod returns null for non-raisable events. Use IEventInvoker.CanRaise.
The test base classes AspectTestClass, DefaultAspectTestClass, CurrentDirectoryAttribute, and CurrentProjectAttribute were removed.
For the Redis backend: the schema redesign requires a cache purge, ExceptionHandlingCachingBackendEnhancer was removed in favor of the ExceptionHandlingPolicy property, and TransactionMaxRetries and CacheCleanupOptions.Sequential are obsolete.

See the release notes for the full list.

What’s next

As our first LTS release, 2026.1 is the version to standardize on if you want stability. The next feature release is expected to be 2027.0, with support for .NET 11. Work will start in late August, and we don’t expect any larger work on Metalama in the meantime.

Found an issue or have a feature request? Let us know on GitHub.

Happy meta-programming!

-gael

This article was first published on a https://postsharp.net/blog under the title Metalama 2026.1 Generally Available: First LTS Release, Complete C# 14 Support, and a Redesigned Redis Backend.

PostSharp 2026.0 Generally Available: Support for .NET 10, C# 14 and Extension Blocks

Wed, 07 Jan 2026 07:00:00 +0000

Alongside Metalama 2026.0, we’re announcing the general availability of PostSharp 2026.0. This release brings full support for .NET 10 and C# 14, including proper handling of the new extension blocks syntax introduced in C# 14.

.NET 10 and C# 14

We’ve updated and tested PostSharp to fully support the .NET 10 SDK and C# 14 across all packages. You can now confidently use PostSharp with the latest .NET stack.

Extension Blocks Support

C# 14 introduces extension blocks as an alternative syntax for defining extension methods. This new language feature required careful consideration in PostSharp to ensure predictable behavior.

By default, multicast attributes now skip extension block members. This prevents aspects from being unintentionally applied to compiler-generated metadata associated with extension blocks.

For scenarios where you do want to target extension block members, we’ve added the AllowExtensionBlockMembers property to both MulticastAttribute and MulticastAttributeUsageAttribute. Setting this property to true enables your aspects to target extension block members explicitly.

Additionally, developers using IAspectProvider or IAdviceProvider interfaces can use the new ReflectionHelper.IsExtensionBlockMetadata utility method to identify compiler-generated metadata associated with extension blocks.

Updated Framework Baselines

We’ve raised the minimum supported frameworks to reflect the current .NET ecosystem:

.NET Standard 2.0 (minimum)
.NET Framework 4.7.0 (minimum)
.NET 6.0 (minimum for .NET Core-based projects)

All pre-2017 target frameworks and obsolete .NET Core versions that have lost mainstream support have been removed. Please consult the breaking changes documentation for complete migration guidance.

Conclusion

PostSharp 2026.0 continues our commitment to keeping PostSharp compatible with the latest .NET releases. While our new feature development is focused on Metalama, we remain dedicated to ensuring that PostSharp users can stay current with the evolving .NET platform.

Happy meta-programming with PostSharp!

This article was first published on a https://postsharp.net/blog under the title PostSharp 2026.0 Generally Available: Support for .NET 10, C# 14 and Extension Blocks.

Metalama 2026.0 Generally Available: Full Support for C# 14 and .NET 10

Mon, 05 Jan 2026 07:00:01 +0000

Metalama 2026.0 is now generally available! This major release brings full support for C# 14 (the most significant evolution of the C# language in years), along with .NET 10 SDK and Visual Studio 2026 compatibility. We’re also closing one of the last feature gaps with PostSharp: the ability to override event handler invocations. And you’re getting first-class support for tuple types.

Ready to try it? The packages are on NuGet.org, and the Visual Studio extension is available from the Visual Studio Marketplace.

For the complete list of changes, see the release notes. For even more detail, see the change notes for the releases 2026.0.11, 2026.0.10-rc, 2026.0.9-rc, 2026.0.8-rc, 2026.0.7-rc, 2026.0.6-rc, 2026.0.5-preview, 2026.0.4-preview, 2026.0.3-preview, 2026.0.2-preview, 2026.0.1-preview.

C# 14 support

C# 14 introduces several language features, and Metalama 2026.0 supports all of them in user code:

Extension blocks (see below)
Null-conditional assignments
field keyword in properties
Partial constructors and events
Compound assignment operators
Simple lambda parameters with modifiers

However, some features are not yet supported in aspects:

Null-conditional assignments in templates
The field keyword in templates
Generating run-time code for extension members via invoker interfaces
Adding contracts to the receiver parameter of extension blocks
Introducing new compound assignment operators
Introducing parameters into partial constructors
Introducing new extension blocks

Extension blocks

Extension blocks are the headline feature of C# 14, letting you extend any type with new members. Metalama supports them:

Extension blocks are modeled via the IExtensionBlock interface, which implements INamedType (TypeKind = Extension).
They appear under INamedType.ExtensionBlocks.
You can override extension members using the advising API or apply aspects via custom attributes.
You can introduce new members into existing extension blocks.
Introducing new extension blocks is not yet supported.

Here’s how to add logging to all extension methods in your project using a fabric:

public class Fabric : ProjectFabric
{
    public override void AmendProject( IProjectAmender amender )
    {
        amender
            .SelectTypes()
            .SelectMany( t => t.ExtensionBlocks )
            .SelectMany( e => e.Methods )
            .AddAspectIfEligible<LogAttribute>();
    }
}

Event handler overriding

You can now override event handler invocations, enabling patterns like “safe events” where each handler is isolated by exception handling. The OverrideInvoke method in OverrideEventAspect intercepts individual handler invocations.

Typical use cases:

Safe events (exception isolation)
Background or asynchronous event dispatch
Event invocation logging

Here’s an aspect that catches exceptions and removes faulty handlers:

public class SafeEventAttribute : OverrideEventAspect
{
    public override dynamic? OverrideInvoke( dynamic? handler )
    {
        try
        {
            return meta.Proceed();
        }
        catch ( Exception e )
        {
            Console.WriteLine( e );
            meta.Target.Event.Remove( handler );
            throw;
        }
    }
}

Apply it to any event:

public class Camera
{
    [SafeEvent]
    public event EventHandler? FocusChanged;

    private void OnFocusChanged()
    {
        this.FocusChanged?.Invoke( this, EventArgs.Empty );
    }
}

For details, see Overriding events.

First-class tuple support

Previously, Metalama treated tuples as plain INamedType objects, with no access to element names or types. The new ITupleType interface changes that, making scenarios like packing method arguments for interceptors much cleaner:

// Create a tuple type from method parameters.
var tupleType = TypeFactory.CreateTupleType( method.Parameters );

// Create a tuple instance.
var tupleExpression = tupleType.CreateCreateInstanceExpression( meta.Target.Parameters );

// Pass it to an observer.
_myObserver.OnMethodCalled( method.DeclaringType.FullName, method.Name, tupleExpression.Value );

Metrics enhancements

LinesOfCode metric: Three measurements (Logical, NonBlank, and Total).
Workspaces API: Now officially supports metrics consumption.

Visual Studio tooling improvements

We’ve refactored several background components of our VSIX. It’s now more stable, consumes less CPU, and better utilizes your cores.

Claude Code skill for AI-assisted development

We’re introducing a Claude Code skill that gives Anthropic’s AI assistant Metalama knowledge:

Conceptual documentation
API references
Sample code and pattern libraries

Whether you’re new to Metalama or tackling a complex scenario, Claude can now provide contextually relevant guidance for aspect development, templates, fabrics, and the code model.

The skill is available on the Metalama.AI.Skills marketplace. For setup instructions, see Configuring Claude Code.

Documentation updates

We’ve made these improvements:

New: Working with types
Improved: Writing T# templates
Updated: Injecting dependencies into aspects (now covers cross-project DI)
Updated: Overriding events
New: Consuming code metrics and Custom metrics
Enhanced API docs with integrated conceptual content

Breaking changes

.NET 6 SDK is no longer supported.
Several API and behavioral changes. See the release notes for details.

What’s next

With 2026.0 shipped, we’ll focus on extending C# 14 support in aspects.

Found an issue or have a feature request? Let us know on GitHub.

Happy meta-programming!

-gael

This article was first published on a https://postsharp.net/blog under the title Metalama 2026.0 Generally Available: Full Support for C# 14 and .NET 10.

Metalama November 2025 Update: Release Candidate for Metalama 2026.0

Sun, 30 Nov 2025 07:00:01 +0000

Metalama 2026.0 has reached Release Candidate status! All planned features are implemented, our test suite is green, and the release is stable enough for production evaluation. We’re now gathering community feedback ahead of our GA release on January 5th, 2026.

Ready to try it? The RC packages are available on NuGet.org, and the Visual Studio extension can be downloaded from the Metalama 2026.0 downloads page.

This article covers what we shipped this month. For the complete list of changes in Metalama 2026.0, see the release notes.

For the full list of fixes and enhancements, see the changelogs:

2026.0.4-preview (November 8).
2026.0.5-preview (November 12).
2026.0.6-rc (November 28).

C# 14 Extension Members

This month, we completed support for C# 14 extension blocks. You can now advise extension members and introduce members into existing extension blocks.

Extension blocks are the “extend everything” feature in C# 14. Here’s how Metalama models them:

Extension blocks use the IExtensionBlock interface, which implements INamedType (TypeKind = Extension) so you can discover members the usual Fields, Properties, Methods, … collections.
They appear under INamedType.ExtensionBlocks.
Extension methods and property accessors are also listed in INamedType.Methods as implicitly-implemented methods.
You can override extension members using the advising API or add aspects using custom attributes.
You can also add new extension members to existing extension blocks.
Introducing new extension blocks won’t be supported in 2026.0.

Other Improvements

Single-file applications. Metalama aspects now work in single-file dotnet run applications: arguably a niche scenario.

Toast notifications. Product briefs and news now appear via toast notifications on Windows. You can disable or configure this feature through the UI or CLI tool.

Visual Studio Tools improved stability and performance

During the last two weeks, we focused heavily on Visual Studio extension stability, and uncovered more issues than expected.

We owe you an apology. Most of these bugs were already present in the 2025.1 release, though some may have been introduced by a Visual Studio 17.x minor update (we don’t repeat our full manual test suite after each VS release, so we can’t be certain). We discovered them through exhaustive testing on clean virtual machines as part of our RC validation process.

This level of testing clearly wasn’t done properly for 2025.1. To ensure quality meets our standards, we chose to delay the release by one month, missing our target to reach GA before the Christmas break. It was the right call.

The good news: the Visual Studio extension is now significantly more stable, and we improved performance along the way. You can download it from the Metalama 2026.0 downloads page.

Known Issues

A couple of items to address before GA:

There’s a known issue (#149) with the apt package on Linux. We’re working on a fix.
The next RC will update to Roslyn 5.0.0 GA (#1212).

What’s Next

With full .NET 10 SDK and C# 14 support (except for by-design limitations documented in the release notes), and a significantly more stable Visual Studio extension, we’re on track for GA on January 5th, 2026.

If you haven’t tried the RC yet, now is the time. Test it with your projects and let us know what you find. Your feedback helps us ship a stable release.

Happy meta-programming!

-gael

This article was first published on a https://postsharp.net/blog under the title Metalama November 2025 Update: Release Candidate for Metalama 2026.0.

Metalama October 2025 Update: Full Steam Ahead Toward 2026.0

Thu, 30 Oct 2025 07:00:01 +0000

October is traditionally our busiest month. Microsoft ships the RCs of the .NET SDK, C# and Visual Studio, and we sprint to make Metalama ready. This year is no exception: we’ve made solid progress, and we’re confident we’ll be ready on time for the GA wave. Below is a recap of what we shipped and what’s coming.

Metalama 2025.2: skipped for simplicity

We’ve decided not to ship Metalama 2025.2 as a standalone release. All its features, including the ability to override event handler invocations, are already merged into Metalama 2026.0. Why? The only real benefit of releasing 2025.2 would be making event-invocation advising available a few weeks earlier, but supporting two versions in parallel would slow us down.

Metalama 2026.0: almost there

We are now almost code-complete with Metalama 2026.0, and have released several previews:

.NET 10 SDK and C# 14

We’re nearly done with support for the .NET 10 SDK and C# 14. Want to see where things stand? Check out these resources:

General status board highlighting the leftovers for the 2026.0 version.
C# 14 status board showing our progress with C# 14 features.

Out of scope for Metalama 2026.0:

Using null-conditional assignments in templates. #1109
Using the field keyword in templates. #1114
Introducing new extension blocks. #1159
~~Introducing extension members into existing extension blocks. #1160~~ UPDATE: implemented in 2026.0.4-preview.

Fun fact: we noticed that compiling our NopCommerce snapshot with C# 14 breaks LINQ-to-SQL because of implicit conversions of arrays to ReadOnlySpan. We’ve had to pin this solution to C# 13 to work around this issue.

Extension blocks

“Extend everything” is the headline feature of C# 14, and we’re making sure Metalama supports it out of the box, including overriding extension members. Here’s how we’re modeling extension blocks:

Extension blocks use the IExtensionBlock interface (TypeKind = Extension). It derives from INamedType, and adds two properties: ReceiverParameter and ReceiverType. Although extension blocks derive from INamedType, you can’t always treat them like regular ones. Yes, this technically bends the Liskov Substitution Principle, but splitting the hierarchy would make the API noisier for little practical benefit. For extension members (except classic extension methods), IMember.DeclaringType points to the IExtensionBlock.
Extension blocks show up under INamedType.ExtensionBlocks, not as nested types (INamedType.Types).
Extension methods and property accessors are listed in INamedType.Methods as implicitly-implemented methods. They exist in IL and are addressable in C#, but you can’t override them with Metalama.

This approach feels natural for C# developers and closely matches Roslyn’s model.

First-class support for named tuples

Previously, Metalama treated tuples as plain INamedType objects, without access to element types or names. This made scenarios like packing method arguments for interceptors (think caching) awkward and inefficient. Now, with the new ITupleType interface, you get direct access to element names and types. Create named tuples with TypeFactory.CreateTupleType, and instantiate them with ITupleType.CreateCreateInstanceExpression.

Our implementation even supports tuples with zero or one element. For two or more, you get the nice tuple syntax; for degenerate cases, Metalama falls back to ValueTuple.Create(...). When you use ITupleType, you don’t have to worry about these details yourself.

Example: Want to advise multiple methods and pass all arguments to an observer? Here’s how:

// Create the tuple type.
var tupleType = TypeFactory.CreateTupleType(method.Parameters);

// Create the tuple instance.
var tupleExpression = tupleType.CreateCreateInstanceExpression(meta.Target.Parameters);

// Invoke the interceptor.
_myObserver.OnMethodCalled(method.DeclaringType.FullName, method.Name, tupleExpression.Value);

Transformed code:

// Two or more arguments: tuple syntax
public IEnumerable<Hat> FindHats(decimal size, string category)
{
    _myObserver.OnMethodCalled("HatStore", "FindHats", (size, category));
    // ...
}

// One argument: ValueTuple.Create
public bool IsHatAvailable(long hatId)
{
    _myObserver.OnMethodCalled("HatStore", "IsHatAvailable", ValueTuple.Create(hatId));
    // ...
}

// Zero arguments
public bool IsStoreOpen()
{
    _myObserver.OnMethodCalled("HatStore", "IsStoreOpen", ValueTuple.Create());
    // ...
}

Breaking Change: INamedType.TypeKind now returns Tuple instead of NamedType for tuples.

Advising event invocations

Overriding event handler invocation logic, originally planned for 2025.2, is now part of 2026.0. For details, see the September 2025 Status Update.

Other improvements

Introducing user-defined checked operators.
Dependency injection: pull constructor parameters across projects.
API cleanup (some breaking changes, [Obsolete] warnings).

Metalama 2025.1: now supports Visual Studio 2026

Last month, we added limited .NET 10 SDK support to Metalama 2025.1. As of October 7, Visual Studio 2026 is also supported.

Just make sure to update both the NuGet packages and the VSIX extension.

Roadmap: finalizing 2026.0

We’re wrapping up the last features for full C# 14 support in Metalama 2026.0. Next up: stabilization, code cleanup, manual testing, and performance validation.

We’re aiming for a release candidate (RC) on November 7, barring any surprises during testing. The final GA release will follow soon after Microsoft ships the GA versions of the .NET SDK and related packages.

Conclusion

In October, we made good progress on Metalama 2026.0, whose main focus is to support the .NET 10 SDK, C# 14, and Visual Studio 2026. We’re almost code complete, and we’ll spend most of November stabilizing the release.

Happy meta-programming!

-gael

This article was first published on a https://postsharp.net/blog under the title Metalama October 2025 Update: Full Steam Ahead Toward 2026.0.