[Breaking change]: Unintentional UnsafeAccessor support for non-open generics is altered in .NET 9.

[AaronRobinsonMSFT]

Description

In .NET 8, we introduced the UnsafeAccessor API. This permitted access to non-visible members of types (a.k.a., "fast private reflection") - see [API Proposal]: Zero-overhead member access with suppressed visibility checks · Issue #81741 · dotnet/runtime (github.com). The initial design supported generics, but we didn't add support in .NET 8 due to time constraints. However, in CoreCLR and native AOT, some very narrow and not officially supported scenarios did work. These scenarios weren't intentionally blocked, but should have been.

In .NET 9, official support was added with dotnet/runtime#99468.

Version

.NET 9 Preview 6

Previous behavior

A naive signature look-up on types was implemented, which caused use of generic types to be valid in some cases. For example, the below should have been deemed invalid:

[UnsafeAccessor(UnsafeAccessorKind.Method, Name = ".ctor")]
extern static void CtorAsMethod(List<int> c);

New behavior

The fully supported and documented way to consume generic types is to ensure type parameters match type parameters and method parameters match method parameters. This is because the runtime performs a strict metadata signature match. Examples and remarks can be found here.

class Accessor<T>
{
    [UnsafeAccessor(UnsafeAccessorKind.Method, Name = ".ctor")]
    public extern static void CtorAsMethod(List<T> c);
}

Type of breaking change

• Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
• Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
• Behavioral change: Existing binaries might behave differently at run time.

Reason for change

The reasoning for the change is that the previous behavior was not intended to be supported in the official release. It was, early in development, a possibly supported scenario, but was later deferred until .NET 9 for complexity issues encountered. The official documentation did not mention generics nor provide any examples using generics.

Recommended action

Users are encouraged to examine the updated documentation for the UnsafeAccessorAttribute API. Support for this scenario in .NET 8 is considered unintentional and uses deemed an error.

Feature area

Core .NET libraries

Affected APIs

System.Runtime.CompilerServices.UnsafeAccessorAttribute

---

Associated WorkItem - 286111