AOT Serialization


On AOT-compiled platforms, Unity's code stripping can remove classes that the serialization system needs, or fail to generate code for necessary variants of generic types. Therefore, Odin can create an assembly that directly references all the serialization functionality that is needed at runtime, to ensure that it will be avaible in the final AOT build. You can find options for this by going to Tools > Odin Inspector > Preferences > Serialization > AOT Generation.

We recommend that you enable Odin's AOT automation feature and also toggle it to run for all AOT platforms; this should let you stop worrying about AOT support, and just develop and build your game like you normally do. Odin will in this case take care of detecting that you're building for an AOT platform that will need pre-generated AOT support, do the scan, generate a DLL for the build, and clean up after itself when the build is done.

To manually handle creating the AOT support assembly, click Scan Project, and wait for the scan to complete. Essentially, during the scan, Odin loads and saves every relevant asset and scene in your entire project, and meanwhile it keeps track of which types are being saved by Odin's serialization system. From this information, it then creates a list of all types that it must support serializing in AOT builds. You can modify this list of types, adding to it or disabling support for types as you wish - when Odin scans, it will leave all of your custom modifications to the list of types alone. However, unless you know what you're doing, it is likely best to just use the base list of supported types that Odin generates itself from the scan.

Finally, to generate the assembly itself, press the "Generate DLL" button, and wait for Unity to reload. You should do this every time before you build. You must always ensure that your generated AOT dll is up to date before you make an AOT build, or serialization may fail in your build.

If you leave the generated .dll in your project after building, some versions of Unity may start throwing errors related to the generated .dll in the console on script reloads. This happens, for example, when you have generated a .dll that contains support for a custom type of yours, and you then change the name of that type, or delete it. This causes Unity to be unable to resolve the types that the .dll references, and therefore, it will throw errors. These error messages are harmless, but annoying. Therefore, you may want to establish a habit of deleting the generated .dll after you've made a build and are done with it.

You can read more about AOT Platforms and Unity on Unitys documentation here: docs.unity3d.com/Manual/ScriptingRestrictions.html