PostSharp Blog

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.

Metalama Status Update, September 2025

Wed, 01 Oct 2025 07:00:01 +0000

Welcome to Metalama’s September 2025 status update. After a relaxed summer, we’re back in full swing, delivering .NET 10 SDK support for Metalama and closing a key gap versus PostSharp: the ability to override event handler invocations.

Our first community contributor

Let me start with the announcement that brings me the greatest joy.

This past summer, Metalama received its first contribution from the open-source community. Giuseppe Marazzi submitted two PRs fixing two small and hard-to-find bugs.

A warm thanks to Giuseppe!

While Metalama may look like a complex codebase at first glance, Giuseppe’s contribution proves that anyone can make a meaningful impact. Don’t let the technical depth intimidate you: every contribution counts, however small. Our contributor’s guide shows you where to start.

.NET SDK 10 readiness

As autumn arrives, Microsoft is finalizing the new .NET stack, and, like all .NET extenders, we’re working hard to make sure you can use the new features as soon as possible.

We’ve split the work into two releases:

Metalama 2025.1 received quick fixes to keep working with the .NET 10 SDK, with limitations;
Metalama 2026.0 will be built natively for the .NET 10 SDK.

Metalama 2025.1: limited .NET SDK 10 support

With the .NET SDK 10 already in RC, we didn’t want you to wait for full integration, so we made small changes to ensure compatibility with the new .NET SDK.

This build is Metalama 2025.1.14, released this week. From our platform integration matrix tests, most .NET workloads are working.

Keep in mind that Metalama 2025.1 is still based on Roslyn 4.14, while the .NET SDK 10 includes Roslyn 5.0. This has some implications:

Analyzers and source generators compiled against Roslyn 5.0 will not work. When possible, we replace them with an older Roslyn 4.14 version. This often works, but not always.
Specifically, Blazor projects (all flavors) are not supported yet because of an incompatibility in their source generators.
You cannot use C# 14 features in your Metalama projects.

Metalama 2026.0 in progress

The goal of Metalama 2026.0 is to bring full native support for the .NET 10 SDK and C# 14: native, not hacks.

C# 14 brings a lot of new features, and we won’t support all of them in every scenario in November, when the new .NET is expected to become generally available. Our primary goal with Metalama 2026.0 is to let you safely use any new C# feature in your runtime code, but not necessarily in aspect templates. Support for new language features in templates may come in later versions. This aligns with our design philosophy: Metalama should be able to compile any valid C# code, but it’s okay to limit features available in aspects.

We’re using GitHub to track our progress. You can use this meta-issue or this dashboard to check the status.

We plan to have an RC ready in November, when Microsoft is expected to release the new stack.

If you’re eager for a preview, look for one next week. Or, if you’re more patient, compile the develop/2026.0 branch of Metalama and Metalama.Compiler repos (merged from Roslyn tag NET-SDK-10.0.100-preview.7.25380.108 as of today).

Visual Studio 2026 readiness

We ran some initial tests of our Metalama Tools for Visual Studio with Visual Studio 2026. They failed, subtly but miserably.

It seems those incompatibilities can be addressed with fairly small bug fixes. If that proves to be true, we’ll update our tooling 2025.1 to support Visual Studio 2026, and there will be no need to wait for Metalama 2026.0.

Metalama 2025.2 RC: Event invocation overrides

We have just released the first (and hopefully final) RC of Metalama 2025.2.

Since the beginning, Metalama has allowed overriding the add and remove accessors of events, which were arguably of limited utility. This version adds the ability to override the invocation of event handlers. The OverrideInvoke method of the OverrideEventAspect class lets you intercept the invocation of an individual event handler.

Typical use cases are:

safe events (exception handling)
background/asynchronous events
event invocation logging

Let’s illustrate this with an example. This aspect catches exceptions in event handlers; if any exception is caught, it removes it from the event invocation list.

public class SafeEventAttribute : OverrideEventAspect
{
    // If there are many event handlers, this method will be called several times.
    public override dynamic? OverrideInvoke( dynamic? handler )
    {
        try
        {
            return meta.Proceed();
        }
        catch ( Exception e )
        {
            Console.WriteLine( e );

            // First time shame on you, second time shame on me.
            meta.Target.Event.Remove( handler );
            throw;
        }
    }
}

We can now add this to any event:

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

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

As you might expect, it took us a while to implement. It’s far from simple.

Here’s how Metalama transforms your code:

public class Camera
{
    // The field backing the event.
    private event EventHandler? _focusChanged;

    // A broker sitting between the event API and the backing field.
    private volatile ActionEventBroker<EventHandler?, (object?, EventArgs)>? _focusChangedBroker;

    // Binds the broker to the event implementation and the advice.
    private static readonly ActionEventBrokerCallbacks<EventHandler?, (object?, EventArgs)> FocusChangedBrokerCallbacks_0 = new (
        static (handler, me, args) => ((Camera)me).FocusChanged_Invoke_SafeEvent(handler, args),
        static b => (sender, e) => b.Invoke((sender, e)),
        static (handler, me) => ((Camera)me).FocusChanged_SafeEvent += handler,
        static (handler, me) => ((Camera)me).FocusChanged_SafeEvent -= handler );



    // The public event with the new implementation.
    [SafeEvent]
    public event EventHandler? FocusChanged
    {
        add
        {
            ActionEventBroker<EventHandler?, (object?, EventArgs)>.EnsureInitialized(ref this._focusChangedBroker, this, FocusChangedBrokerCallbacks_0);
            this._focusChangedBroker.AddHandler(value);
        }

        remove
        {
            this._focusChangedBroker?.RemoveHandler(value);
        }
    }

    // The original event implementation.
    private event EventHandler? FocusChanged_SafeEvent
    {
        add
        {
            this._focusChanged += value;
        }

        remove
        {
            this._focusChanged -= value;
        }
    }

    // Your advice intercepting the handler invocation.
    private void FocusChanged_Invoke_SafeEvent(EventHandler? handler, (object? sender, EventArgs e) args)
    {
        try
        {
            handler.Invoke(args.sender, args.e);
            return;
        }
        catch (Exception e)
        {
            Console.WriteLine(e);
            _focusChanged -= handler;
            return;
        }
    }

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

It’s a bit lengthy, but aside from a touch of syntactic sugar, the event broker is the most reliable pattern, because we can’t predict or analyze how an event is raised. This approach is oblivious to the event’s implementation and to how it gets raised.

You can find more details on this documentation page.

Subscribe to our briefs to receive updates about ongoing work on Metalama 2026.0 before the next monthly update.

Dockerization of our build infrastructure

As a side note, the entire Metalama build infrastructure now runs on Docker, requiring only lean build agents.

That means you can build Metalama in the exact environment we use.

All you need is a Windows 11 or Windows Server 2025 machine with Docker installed and Windows containers enabled, then run:

.\DockerBuild.ps1 build

Summary

On the feature side, the OverrideEventAspect.OverrideInvoke advice closes one of Metalama’s remaining gaps with PostSharp. On the platform front, we’ve released the first bits of .NET 10 support and we expect to deliver more soon. In terms of infrastructure, Dockerizing our build workflow makes Metalama easy to reproduce across agents and helps reduce the cost and complexity of our setup.

Happy meta-programming with Metalama!

This article was first published on a https://postsharp.net/blog under the title Metalama Status Update, September 2025.

Security Notice: Data Leak Affecting a Limited Number of Accounts

Sun, 07 Sep 2025 23:00:01 +0000

We regret to inform you of a data leak that occurred on the PostSharp Customer Portal between Wednesday, September 3rd, and Tuesday, September 9th.

Who is affected?

A total of 38 customer accounts were impacted. If your account was affected, you will:

Receive a personal notification email within the next 24 hours.
Notice that you can no longer sign in to the portal using your license keys.

What data was leaked?

Only the content of the https://www.postsharp.net/account page of the portal was exposed, including:

Company name and billing address (or customer name and address for natural persons)
All subscription dates, number of users, licensed products, and support level
All license keys for PostSharp and Metalama

What was not leaked?

Contact lists or email addresses
Prices, invoices, or quotes
Support tickets
Source code (never uploaded to our servers)

Who accessed the data?

At most, one other PostSharp customer may have received your data in error.

How did this happen?

A caching error occurred in the daily job that sends subscription renewal notifications, causing account data to be sent to the wrong recipient. The first customer of the batch received all emails.

Timeline of events

Wed 9/3, 11:00 AM – First incorrect email sent.
Mon 9/8, 8:00 PM – Data leak reported by the receiving customer.
Tue 9/9, 2:00 PM – Report read and incident confirmed.
Tue 9/9, 4:30 PM – Credentials invalidated and issue remediated.

How we fixed it?

All past magic URLs were invalidated by rotating the salt for each affected account.
License keys exposed in the leak were disabled for authentication to the portal.
The caching bug was fixed.

Do you need to take action?

No action is required. Your license keys will continue to work normally with PostSharp and Metalama products.
If you prefer, we can issue new license keys on request, to ensure that any leaked key cannot be used by another party.

How to log in now?

If your license keys no longer work for portal login:

Use email authentication (one-time PIN or magic link) for one of your account contacts.
If you do not know your contact, please write to hello@postsharp.net from your work email.

We take full responsibility for this incident and sincerely apologize for the error. We are committed to ensuring it does not happen again.

This article was first published on a https://postsharp.net/blog under the title Security Notice: Data Leak Affecting a Limited Number of Accounts.

Breaking Update of PostSharp Caching adapter for Redis in 2025.1

Mon, 01 Sep 2025 23:00:01 +0000

We have released a refactored version of PostSharp.Patterns.Caching.Backends.Redis in PostSharp 2025.1 to address a reliability issue that could surface in multi-node Redis deployments (master/replica or cluster) when cache dependencies are enabled under sustained load. The fix required a redesign of the internal data schema, which is why this is a breaking change (one-time cache purge). Outside of that purge, the upgrade is straightforward and brings measurable gains in performance, consistency, and resilience.

Impact at a glance:

If you run multi-node Redis with dependencies, the update removes a potential failure mode.
You only need a one-time cache purge, and you’ll still benefit from performance and diagnostics improvements.
There is no risk of user data loss; only old cached entries stay in the database until purged.
No impact for the other backends.

Who is affected?

Affected by the bug:
- Applications that use PostSharp.Patterns.Caching.Backends.Redis with support for dependencies in a Redis master/replica or cluster setup.
Affected by the refactoring:
- All applications that use PostSharp.Patterns.Caching.Backends.Redis, with or without support for dependencies, are affected by the redesign of the data schema. You must purge the cache after the update, and there is no other impact. All versions prior to 2025.1.7 are affected.

Customers using Metalama.Patterns.Caching.Backends.Redis are affected by this issue too, and the solution has not yet been ported to Metalama. Please contact us if it matters to you.

What was wrong?

The previous design of the RedisCachingBackend relied on a retry loop in GetItem operations to retrieve a consistent snapshot of the cache item, which includes both the cache value and its dependencies, stored in separate Redis keys. Under heavy load in a master/replica setup, this loop could exhaust its iterations and fail.

The consistent snapshot of value and dependencies was required because recursive dependencies (when a cached method calls another already cached method) were flattened in the SetItem operation, so the RemoveItem and InvalidateItem operations did not need to operate recursively. This was a poor design choice.

The previous component was only tested in a single-node Redis topology. We believe the root cause was a lack of testing in multi-node topologies under high load.

How was this fixed?

We redesigned the data schema so GetItem never needs to iterate:

Dependencies are no longer flattened. The RemoveItem and InvalidateItem operations now work recursively.
Cache keys (a single logical cache item requires several Redis keys) are now versioned, so we don’t need loops to ensure read consistency.

What else has been improved?

Since a major refactoring was required to implement the new data schema, we went the extra mile and made the component more resilient in high-load production environments:

Performance improvements due to the new design of the Redis data schema that is always observationally consistent for read operations.
Key compression (hashing). Enable this feature by assigning the CachingServices.DefaultKeyBuilder property.
More resilient thanks to new behaviors controlled by the following properties on the RedisCachingBackendConfiguration object:
- Exception handling: RedisCachingBackendConfiguration.ExceptionHandlingPolicy.
- Retry policies: RedisCachingBackendConfiguration.BackgroundRecoveryRetryPolicy, RedisCachingBackendConfiguration.BackgroundTasksRetryPolicy, RedisCachingBackendConfiguration.TransactionRetryPolicy.
- Concurrency control: BackgroundTasksMaxConcurrency and InvalidationMaxConcurrency.
- Node selection: ReadCommandFlags and WriteCommandFlags, defaulting to PreferReplica and PreferMaster, respectively.
Support for sharding clusters, with keys containing taghashes. Tested on a 3+3 cluster.
Support for dependencies with a very large number of dependent cache items.
GC process:
- Detection of overloads and automatic temporary disabling.
- Periodic background cleanups to handle situations that were not detected by processing keyspace notifications in real time.
Keys contain the PostSharp Caching schema version for safe updates.
Fixed bugs with sliding expiration.
Improved documentation.

What changes are breaking?

The data schema has changed, so you must purge the old version’s cache; otherwise it will contain permanently unreachable data (garbage) forever.
The CacheValue.Dependencies and CacheItem.Dependencies properties now contain first-level dependencies rather than all recursive dependencies. These objects are largely implementation details and do not surface to the aspect-oriented API of PostSharp Caching.

How to update?

Update all PostSharp packages to 2025.1.8 and deploy your application.
Purge the cache using Redis’s FLUSHDB command after your old application has been undeployed.

If you ignore this post and only update the package, the Redis database will contain the data of the old version forever, since the dependency-management keys are set to never expire.

For details about the refactored PostSharp Caching for Redis, see our documentation.

Conclusion

PostSharp Caching for Redis now runs on a more robust, versioned schema that removes a reliability edge case and improves performance and consistency across single-node, replicated, and sharded clusters when dependency support is enabled. The component has been overhauled for better observability and resilience. The only required action is a one-time cache purge after upgrading to 2025.1.8 or later.

If you rely on the Metalama Redis backend, let us know so we can prioritize porting the same improvements.

Thanks to customers who surfaced the scenario early—enjoy the improved backend.

This article was first published on a https://postsharp.net/blog under the title Breaking Update of PostSharp Caching adapter for Redis in 2025.1.