[AOT] Explore Alternatives to MakeGenericType/MakeGenericMethod For Web UI

[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.

There are multiple uses of MakeGenericType() and MakeGenericMethod() throughout the Microsoft.AspNetCore.Components and Microsoft.JSInterop projects that make them unsafe for AOT scenarios. Initially it was believed that the warnings surrounding these would be suppressible since these projects are already trim-safe, but there are multiple places where we cannot guarantee the safety of the suppression.

During review of #45580, there was the suggestion of exploring a non-dynamic code fallback such as here. Further investigation found that the performance degradation would make this a poor approach when dealing with Blazor.

Describe the solution you'd like

The below uses of MakeGenericMethod() and MakeGenericType() need to either have an AOT-safe fallback or a refactor (e.g. source generation) which allows these type-generic methods to not require JIT compilation.

Microsoft.AspNetCore.Components

• PropertySetter()

Microsoft.JSInterop

• DotNetDispatcher.GetTaskByType()
• TaskGenericUtil.GetTaskResult()
• TaskGenericUtil.CreateResultSetter()
• DotNetObjectReferenceJsonConverterFactory.CreateConverter()

Additional context

Linked to #45578, the other part of Web UI's remaining work in #45473.

AOT analysis for these projects is already turned off by #45604.

[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]

We'll address this as part of #51598