[AOT] Make BindConverter safe for AOT or mark as unsafe

[Nick-Stanton]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

BindConverter.cs has a ton of DynamicallyAccessedMembers.All annotations. It seems the class barely made the cut for trim safety, but definitely will not work in its current state for AOT.

Why not just mark those methods as requiring dynamic code and therefore unsafe for AOT?

Unfortunately, our forms input classes implement BindConverter.TryConvertTo<TValue>(), and to mark those as unsafe puts us in a jam since their implementation of BuildRenderTree() must have the same annotations as the version in base class ComponentBase.cs. Clearly, we can't take dynamic code annotations up the call chain unless we want large parts of Blazor to be marked as unsafe for AOT.

Why does BindConverter need so many DynamicallyAccessedMembers annotations?

The use of TypeDescriptor.GetConverter() (see here and here) seem to be the culprit and to my knowledge there will be no effort to remove any dynamic code annotations from there.

Describe the solution you'd like

I see a few different options here:

• Go ahead and mark everything BindConverter touches (and the subsequent warnings that bubble up the call chain) as unsafe for AOT. This would create an obstacle to Blazor being a useful framework for Native AOT solutions.
• Get BindConverter to a point where it works without the DynamicallyAccessedMembers.All annotations, which would require the removal of TypeDescriptor.GetConverter().
• Mark BindConverter as unsafe and create safe paths for classes that use BindConverter but also want to enable AOT by using an if-else block that checks for RuntimeFeature.IsDynamicCodeCompiled.

Additional context

CC @JamesNK @eerhardt for any advice, additional context, or cautionary tales surrounding this.

Part of effort tracked in #45473

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

Will be addressed as part of #51598