AOT Jit Compile Workaround

[inforithmics]

This Pull request is a workaround for this Xamarin iOS AOT Bug.

xamarin/xamarin-macios#12545

There are two Fixes

1. This catches the exception and sets the Fast Mapper to null and outputs a Trace so that it can be seen in a released Version.

if (fastColumnSetters[i] != null) {
	try {
		fastColumnSetters[i].Invoke (obj, stmt, i);
	}
#pragma warning disable CS0618 // Type or member is obsolete
	catch (ExecutionEngineException) {
#pragma warning restore CS0618 // Type or member is obsolete
                 // Column setter has AOT Problem so don't use it.
                 fastColumnSetters[i] = null;
                 Trace.WriteLine($"FastMapper AOT Jit Exception on Type {map.MappedType.FullName} Column {cols[i].Name}");
	}
}

2. A Method where Fast Column Setters can be set to workround the iOS AOT Bug and still have the same-better Performance

SQLiteConnection.RegisterFastColumnSetter(
            typeof(CacheDto), 
            nameof(CacheDto.Date), 
            (obj, stmt, index) => { ((CacheDto)obj).Date = new DateTime(SQLite3.ColumnInt64(stmt, index)); });

[ElteHupkes]

As a tangentially related remark, I'm using a similar exception catching mechanism in a different internal library, but I'm a bit worried by ExecutionEngineException being marked as Obsolete. What are the odds of a new runtime version suddenly deciding it'll throw a different kind of exception, instantly breaking everything that relies on this?

[inforithmics]

The real workaround would be to use RegisterFastColumnSetter (I have written a SourceGenerator that Generates the code for it).

[pver]

@praeclarum is there any chance this will be merged at some point? Using the latest sqlite-net with release builds for Xamarin.iOS is basically broken at the moment (which is a pity seeing the library is mentioned on https://learn.microsoft.com/en-us/xamarin/ios/data-cloud/data/using-sqlite-orm and the readme.md mentioning Xamarin.iOS as the initial target platform 😊 )

This PR seems like a reasonable fallback for iOS for now. And iOS library users wanting to benefit from the possible performance gains can still provide their own setter via RegisterFastColumnSetter (which could be manually written or generated like @inforithmics suggests). And even without custom fast column setters on iOS, no performance gain is also still better than not being able to use the current version at all 😉

[inforithmics]

Is there some Interest in this Pull Request. If there is some Interest I would update this pull request with a SourceGenerator that Generates the Code for Using the FastColumn Setters

[Dokug]

I would be interested to see this updated and merged, yes

[0ut0fRange]

Is there any chance we will see this Pull Request being updated?
Even if it won't get merged, having this solution in here would allow everyone to copy the code and fixing this issue this way.