Provide a centralized way to disable ExpressionValueProvider or fix DynamicCodeGeneration check

[dlbd]

ExpressionValueProvider does not work on iOS in AOT-only mode and throws exceptions like
System.AggregateException: Attempting to JIT compile method '(wrapper delegate-invoke) void <Module>:invoke_callvirt_void_Account_TimingEnum (COMPANY_NAME.Account,COMPANY_NAME.Enums.TimingEnum)' while running in aot-only mode. See https://docs.microsoft.com/xamarin/ios/internals/limitations for more information.

ReflectionValueProvider works. But, there is no easy way to switch the entire app from ExpressionValueProvider to ReflectionValueProvider. Currently as a workaround we are creating custom contract resolvers

public class CustomDefaultContractResolver : DefaultContractResolver
{
	protected override IValueProvider CreateMemberValueProvider(MemberInfo member)
	{
		return new ReflectionValueProvider(member);
	}
}
// same for CamelCasePropertyNamesContractResolver and others

and then using the custom contract resolvers in the app itself, SignalR, RestSharp and other libraries (which all require separate configuration).

Please do one of the following:

1. Provide a centralized way to disable ExpressionValueProvider, something like DefaultContractResolver.DisableExpressionValueProvider = true.
2. Enable the DynamicCodeGeneration check inside DefaultContractResolver.CreateMemberValueProvider (which is also supposed to detect that ExpressionValueProvider won't work) in netstandard2.0 and net6.0 builds of Newtonsoft.Json, and perhaps make JsonTypeReflector.DynamicCodeGeneration settable.

[sungam3r]

Most probably that an answer here is to switch to STJ as it was designed in AOT friendly way.

[JamesNK]

This might be fixed here? #2902

[dlbd]

Most probably that an answer here is to switch to STJ as it was designed in AOT friendly way.

The mobile app inherited a lot of code from an older WinForms application. Migrating everything to STJ (and making sure nothing else broke) would take some work.

This might be fixed here? #2902

It might be! I'll test after 13.0.4 is released.

[sungam3r]

13.0.4? #2902 was merged more than 2 years ago.

[dlbd]

13.0.4? #2902 was merged more than 2 years ago.

For me it shows that #2902 was merged on Sep 21, 2023

[sungam3r]

My bad.