Corrupted EntitySchema created by NativeAOT class

[DruidOwl]

Discovered this while adding tests approving all the components and tags are registered for NativeAOT.
During test verification (case when some components are not registered) I've found that schema.ComponentTypeByType and schema.Components contains expected components while schema.ComponentTypes contains valid number but actually different types of components.

Traced the discrepancy till the line in EntitySchema ctor. It results in adding completely different type instead of passed.

Here the test, but it might not be working in a different environment. In that case try to reorder definitions of CompA..C.

    [Fact]
    public void Todo()
    {
        var aot = new NativeAOT();
        aot.RegisterComponent<CompC>();
        var schema = aot.CreateSchema();

        // Assert
        var expectedType = typeof(CompC);

        // Expected:
        Assert.Equal(expectedType, schema.ComponentTypeByType[expectedType].Type);
        Assert.Contains(expectedType, schema.Components.ToArray().Select(ct => ct?.Type));

        // Expected, but fails:
        Assert.Contains(expectedType, schema.ComponentTypes.Select(ct => ct.Type));

        // Not expected:
        // Assert.Contains(typeof(CompA), schema.ComponentTypes.Select(ct => ct.Type));
        // Assert.True(schema.ComponentTypes.HasAny(ComponentTypes.Get<CompA>()));
    }

    public struct CompA : IComponent;
    public struct CompB : IComponent;
    public struct CompC : IComponent;

[jegnzc]

Having the same issue.

[friflo]

Currently using NativeAOT() requires a native AOT build.
The detection of a native AOT build is made here.
https://github.com/friflo/Friflo.Engine.ECS/blob/main/src/ECS/Base/SchemaUtils.cs#L27

If using NativeAOT() in a CLR build (via a unit test) it result in the issue you mentioned.
Do you want to use NativeAOT() always in CLR builds?

[DruidOwl]

Could you explain please, what's then the purpose of returning EntitySchema from NativeAOT.CreateSchema()? It's already assigned to some statics so AOT trimmer should spare it. From the perspective of a user I expected the equal behavior in both worlds as long as no aot/trim warnings present.

It's also expected that techniques required to enable safe AOT are still working in CLR like System.Text.Json source-generated serializers.
Or should I add branching in my code to skip all Friflo.Engine.ECS.NativeAOT code when RuntimeFeature.IsDynamicCode.. is true?
Btw, Visual Studio during debug launches PublishAot=true apps in CLR but sets RuntimeFeature.IsDynamicCode.. to false.

Since the test does involve the use of reflection, how else can I guarantee that a descent size project targeted NativeAOT has all the components pre-registered without writing own source gen to feed NativeAOT class?

The current behavior is a bit confusing.

[friflo]

The NativeAOT class requires to register all component types manually.
Currently two options depending on RuntimeFeature.IsDynamicCode:

• Reflection (true) component types are registered by reflection
• AOT (false) component types must be registered manually.
  Both create an EntitySchema. Its an either or decision. It is fixed per process and cannot be changed.

I could add the possibility to enable use of AOT with an explicit setting.

[DruidOwl]

Sorry for the delayed answer!

Debugging was complicated by side effects.
When you want to see value of a ComponentTypes instance, debugger use proxy class ComponentTypesDebugView, which calls ComponentTypesEnumerator, which in turn statically retrieves EntityStoreBase.Static.EntitySchema.components, where .EntitySchema is a getter always calling SchemaUtils.RegisterSchemaTypes(), which in turn, yes, registers all the types based on reflection availability. Just by the attempt to see what's inside a ComponentTypes's BitSet, user forces the entire schema to be created.

My humble proposals so far:

• Switch from implicit way of generation schema (based on RuntimeFeature flags and other) to explicit, but there is no need for a separate manual boolean flag exposed to a user. Let's keep API simple.
• The very use of NativeAOT class, particularly calling aot.CreateSchema() is already an explicit user's opt-in towards manual components registration. After that call no reflection should be used internally to get types from assemblies. The schema is created and the user expects it to be used all around since then.
• When a schema is requested and statically cached for the first time (i. e. via EntityStoreBase.Static.EntitySchema = SchemaUtils.RegisterSchemaTypes()), then check:
  • if manual AOT-schema has already been created (aot.CreateSchema() has been called) then use it regardless of current runtime (CLR, AOT) and flags RuntimeFeature.IsDynamicCode...). User has opted in. It could be an internal flag in NativeAOT, the fact that NativeAOT.GetSchema() returns non-null value, etc.
  • if manual AOT-schema has not been created up to this moment, then check RuntimeFeature.IsDynamicCode... and other Unity-related flags (call SchemaUtils.RegisterComponentTypesByReflection(); it's logic remains intact):
    • if true, use the classic reflection-based logic to build EntitySchema, as is done in CLR now.
    • if false, throw an exception / log warning, because in this case reflection is limited AND AOT-schema is not created.

Thus, it will be clear to a library user when NativeAOT-setup is actually used and when it's not.
I don't see any obstacles preventing a manually created ("AOT") schema from working in CLR. The problem in the topic is caused by ComponentTypes class enumerator which internally forces a schema to be created (see debugging note above).

I may have overlooked some nuances that I am not aware of.

[studentutu]

@friflo can you provide status of this ticket? This seems to be the only issue preventing this plugin to be used in Unity projects (IL2Cpp/mobile)

[RouderSky]

@friflo How to manually register all component types?Do you have example code?I am using Unity 2021.3.30f1.

[friflo]

hi @RouderSky
Docs: https://friflo.gitbook.io/friflo.engine.ecs/project/package/native-aot
Tests: https://github.com/friflo/Friflo.Engine.ECS/tree/main/src/Tests-NativeAOT/ECS

[RouderSky]

hi @RouderSky Docs: https://friflo.gitbook.io/friflo.engine.ecs/project/package/native-aot Tests: https://github.com/friflo/Friflo.Engine.ECS/tree/main/src/Tests-NativeAOT/ECS

Can this also be done in Unity 2021.3.30f1 and friflo 3.4.2? @friflo