Native Aot Support

[richard-einfinity]

Our Maui based solution is using Native Aot and reflection based serializarion is disabled for Aot projects.

I think this would mean exposing the serialization settings for the offline entities and / or providing a registration mechanism for providing JsonTypeInfo for the entities.

Happy to look into and propose possible solutions if it's not already on the radar.

[richard-einfinity]

So I've done a bit of digging and Serialization options are all internal. I think the crux of this is we need a way of setting the TypeInfoResolver on the SerializerOptions. So that the resolver can be passed from the project specific JsonSerializerContext sub class.

The options specified for the JsonSourceGenerationOptions need to match the current options constructed in the DatasyncSerializer class.

A JsonSerializable attribute will need to be added for each offline Entity to the JsonSerializerContext sub class it will need to include the Page class as well.

[JsonSerializable(typeof(Page<OfflineEntity1>))]
[JsonSerializable(typeof(Page<OfflineEntity2>))]
[JsonSourceGenerationOptions(PropertyNameCaseInsensitive = true, PropertyNamingPolicy = JsonKnownNamingPolicy.CamelCase,
    UseStringEnumConverter = true, WriteIndented = false, GenerationMode = JsonSourceGenerationMode.Metadata, AllowTrailingCommas = true,
    DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingDefault, Converters = [ 
        typeof(JsonStringEnumConverter), typeof(DateTimeConverter), typeof(DateTimeOffsetConverter), typeof(TimeOnlyConverter), typeof(MicrosoftSpatialGeoJsonConverter)])]
public partial class OfflineSerializerContext : JsonSerializerContext
{

}

I think my proposal would be to add a property to the OfflineOptions class for the serializer options and add a Method to the DatasyncOfflineOptionsBuilder for UseSerializerOptions. Then use the OfflineOptions property to set the JsonSerializerOptions on the base OfflineDbContext class.

Maybe default the settings to the currentsettings to avoid breaking changes.

[adrianhall]

Let me look at this more deeply on Friday (when I get a chance to work on this project). If it’s that simple, it should be easy to expose. However, what would be ideal is a project that “works when no Native AOT, but doesn’t work when Native AOT” is supplied as a cli able GitHub repository with instructions on how to adjust the project for Native AOT.

Basically, I’m not a MAUI expert, so I can do the minimum needed to get something working.

[richard-einfinity]

Hi @adrianhall unfortunately for Maui native Aot can't be disabled for iOS and catalyst https://learn.microsoft.com/en-us/dotnet/maui/macios/interpreter?view=net-maui-8.0

It's thrown up a few issues to say the least, even with efcore you have to use compiled models... which is a requirement for Aot. UseModel is a configuration option for the DbContextBuilder

The ef tools don't run against a Maui project so you need segregate projects to run the tools. Which you need to generate the compiled modules and migrations etc.

I'll document all the sticking points but I think at the moment it hasn't been an easy move from azure mobile apps. And this issue would block a release targeting iOS for anyone using Maui looking to migrate.

I'll update the sample project in my fork for reference

[richard-einfinity]

Hi @adrianhall just looking at this and mstest now supports testing with native Aot https://devblogs.microsoft.com/dotnet/testing-your-native-aot-dotnet-apps/

Will this support what your looking for in terms of a cli able application or were you thinking more of a console app that would work not Aot and then fail with Aot?

Cheers

Rich

[adrianhall]

Not sure right now :-)

I am thinking of working on the MAUI Todo app and turning on Native AOT. Not sure if that will work for Android, but if it does, it should be enough to show off the problem and I can go from there.

[adrianhall]

FWIW, I believe that this is relatively easy.

1. Set DatasyncSerializer to be public.
2. Set the JsonSerializerOptions to be public read.

That;s pretty much it. Then, in your code, you would do something like:

DatasyncSerializer.JsonSerializerOptions.<whatever your changes are>

It may also be worth my while to specify this in the EF Core extensions I have. Right now, I copy the reference to the JsonSerializerOptions from the DatasyncSerializer to the DbContext when it starts up; thus setting the DatasyncSerializer is the right thing to do.

If you want to test it, it’s a 2 line change to the library. I can put it in a branch for you to test (probably tonight - assuming I can get my desktop back online tonight - it fried its brain this week and I had to replace the SSD)

[richard-einfinity]

Will the crashlytics logs help? Also you can set a project property to emulate the Aot behaviour for the serializer it won't affect the DbContext though.

https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/source-generation?pivots=dotnet-8-0#disable-reflection-defaults

<PropertyGroup>
<JsonSerializerIsReflectionEnabledByDefault>false</JsonSerializerIsReflectionEnabledByDefault>
</PropertyGroup>

[richard-einfinity]

I feel your pain, spilt a can of Pepsi on my surface keyboard Monday evening... this week has been interesting.

[richard-einfinity]

Hi @adrianhall

I've updated the samples in a branch in my repository Updated Samples

It seems there is Native AoT and Native AoT. The async extensions for EF Core use MakeGenericMethod under the hood so they fail on native AoT with the console app. So this method fails.

/// <summary>
/// An asynchronous process for getting the last sequence ID used by the operations queue.
/// </summary>
/// <param name="cancellationToken">A <see cref="CancellationToken"/> to observe.</param>
/// <returns>The last sequence ID in use, <c>0L</c> by default.</returns>
internal Task<long> GetLastSequenceIdAsync(CancellationToken cancellationToken = default)
    => OperationsQueue.OrderByDescending(x => x.Sequence).Select(x => x.Sequence).FirstOrDefaultAsync(cancellationToken);

For Android there's a hard fail if reflection based serialization is enabled when syncing and if your not using a compiled model for the context. It doesn't seem to care about anything else.

For iOS it has the same hard fails as Android but complains about dynamic code generation in EFCore. Enabling the MTouchInterpreter seems to get over this.

The amendments in the samples and exposing the serializer options get passed the hard fails.