Fix incorrect NativeAOT warnings

[dabbinavo]

Issue and discussion references

• [Bug]: Excessive IL2026 warnings #4018
• What is the recommended approach for resolving these two warnings? #4210
• Using ReactiveUI with Native AOT #4215

What kind of change does this PR introduce?

The Pull-Request tries to eliminate incorrect generation of NativeAOT and Trimming warnings for some frequently used ReactiveUI methods (like WhenAnyValue)

What is the current behavior?

Lots of incorrect IL2026 and IL3050 warnings when using ReactiveUI with NativeAOT or Trimming enabled in an project.

What is the new behavior?

Less incorrect of these warnings.

What might this PR break?

This PR shouldn't break anything as pretty all changes just fix incorrect annotations or add new compiler hints in order to let the trimmer work correctly.

Please check if the PR fulfills these requirements

• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:
State of the Pull Request Draft:

• Fix incorrect warnings for WhenAnyValue on non WinUI Platforms

  • Only for WinUI an additional implementation for ICreatesObservableForProperty is registered which needs RequiresUnreferencedCode

• New API: AOT-friendly void Reflection.ThrowIfMethodsNotOverloaded(string callingTypeName, Type targetType, params string[] methodsToCheck) method

  • Previous method is now unused, but also kept in codebase as it is available via public API

• Fix incorrect warnings for ReactiveCommand.Create...

[glennawatson]

Request a discussion before opening a PR since you can only tell if the warning is invalid the AOT test app. Closing for the moment just to avoid you wasting your time unnecessarily

[dabbinavo]

I am happy to hear that now there will be a focus on NativeAOT support for ReactiveUI.
The roadmap described in #4243 of course is the best of all possibilities and i can't wait having the library in that state.

I want to mention that my last known information was this one from #4018:

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.

This PR neither had the goal to make ReactiveUI fully AOT compatible nor to fix all incorrect warnings. My goal simply was to resolve the warnings for the most frequently used methods so consumers like me do not have to annotate the own codebase with thousands of UnconditionalSuppress annotations. In order to be able to use the recent version of ReactiveUI, I hoped that I can contribute something that can be used in short-term in order to not need to wait until ReactiveUI is rewritten from scratch to provide bullet-proof AOT-support.

I already suspected that I may be missing a correct way to identify invalid warnings. Because of this, I asked for help in the linked discussion.

But again - I am very pleased that you will make ReactiveUI to a library with AOT implemented from scratch including source generators. So good 🎉

And thank you for clarifying this in order to prevent waste of time. As this would have been my first contribution to ReactiveUI, I invested already a few hours in order to get everything running and being able to provide a PR draft.

[glennawatson]

No Problem, definitely my fault. I did mean to respond to your earlier query at the time but got side tracked, We are normally very open to any contribution from the community, just very tough when you get a PR that doesn't quite fit with our plans (and to be honest removing the excessive warnings is a very worthy one), you don't want to put people off contributing to the project since we can definitely use all the help we can get also.

[glennawatson]

Been thinking about it, as a stop gap measure might be worthwhile if we just do the warning removal.

[glennawatson]

I might reopen a separate branch and just attribute the fixes to you (do co-author-by), might be easier since I been actively working on all this. Will use the majority of the work you been using.

[dabbinavo]

Nice to hear that 👍
I opened the PR as draft as there were some questions open that i wanted to clarify.
Two most important:

• What setup to use in order to safely identify if an NativeAOT annotation really can be removed?
• Is ICreatesObservableForProperty still working with WinUI, even if only the src/ReactiveUI.Maui/WinUI/DependencyObjectObservableForProperty.cs implementation is not registered? I mean, is that class existing only for performance reasons for WinUI and it is ensured that one of the other registrations always kicks in and works?
• Why are the 'string propertyName' overloads (https://github.com/dabbinavo/ReactiveUI/blob/fix%2Fnativeaot/src%2FReactiveUI%2FVariadicTemplates.cs#L48-L62) commented as AOT friendly? From my understanding these methods are never AOT friendly as they need to create an Expression under the hood?!

If the specific implementation for WinUI is optional, it might be possible to make WhenAnyValue & Co. completely NativeAot safe.

GitHub

ReactiveUI/src/ReactiveUI/VariadicTemplates.cs at fix/nativeaot · dabbinavo/ReactiveUI

An advanced, composable, functional reactive model-view-viewmodel framework for all .NET platforms that is inspired by functional reactive programming. ReactiveUI allows you to abstract mutable st...

[glennawatson]

Step one is reactiveui/splat#1461 which removes a lot of the down stream warnings.