RequiresUnreferencedCode and RequiresDynamicCode annotations seem too broadly applied

[Cheesebaron]

In #3977 the project was marked with these two annotations in a lot of places:

[RequiresDynamicCode("The method uses reflection and will not work in AOT environments.")]
[RequiresUnreferencedCode("The method uses reflection and will not work in AOT environments.")]

• RequiresUnreferencedCode means that you are accessing other assemblies
• RequiresDynamicCode means that you are generating code at runtime

What is the reason for marking so much of the code in the ReactiveUI project with these annotations? Is it external dependencies such as Splat Locator that loads types from Assemblies that require unreferenced code?

On many classes these annotations are applied on the full class. Rather than, using DynamicallyAccessedMembers annotations on types where reflection is actually used.

[glennawatson]

Thanks for raising this — you’ve raised a really valid point around the nuance between using reflection and being unsafe for AOT or trimming. We completely agree that not all reflection is inherently unsafe, and that [RequiresUnreferencedCode] and [RequiresDynamicCode] should ideally be targeted and meaningful.

That said, the current state of ReactiveUI’s codebase makes that very difficult to do without a massive amount of granular work and ongoing maintenance. A lot of these annotations are applied at the class or method level because reflection (often through things like Activator.CreateInstance, MethodInfo.Invoke, or type scanning from Splat) is used indirectly or deep in the call tree. These effects trickle up — and it’s not always feasible to isolate them to a single method or member.

We’ve taken a conservative approach, following Microsoft's guidance to err on the side of caution when annotating libraries for trimming and AOT compatibility. Microsoft themselves often tag whole libraries or classes with these attributes when reflection is used in a way that the trimmer or native AOT compiler cannot reliably analyze. A few useful references from Microsoft:

• .NET Trimming documentation
• RequiresUnreferencedCodeAttribute usage guide
• Discussion on AOT compatibility and reflection in Microsoft.Extensions

"If you're unsure whether reflection usage is safe for trimming, you should assume it's unsafe."
— Microsoft Trimming Options Guide

We’re aware that Microsoft.Extensions.DependencyInjection uses reflection as well — but that team has deeply annotated it with DynamicallyAccessedMembers and other fine-grained hints, which we simply don’t have the capacity to maintain in ReactiveUI at the moment.

---

❗ Resolution

At this time, we are going to close this issue as "won’t fix". While we absolutely want ReactiveUI to be AOT-friendly long-term, the current annotations reflect a practical and conservative interim solution. We're open to PRs that help isolate and refine unsafe areas more precisely using DynamicallyAccessedMembers where applicable, and will revisit our strategy in future major versions.

Thanks again for the thoughtful feedback — we really appreciate it.