SerializationAbortException: AOT serializer was missing for type 'BetterEventEntry.OdinSerializedData' when running on iOS

[Leonardo Cavaletti]

I am using one of the community tools made with Odin featured on the site, BetterEvents (shoutout to the developer for this great tool, really an improvement compared to standards UnityEvents)

I have been using BetterEvents fine when developing on a PC and deploying to Android, however, when I test on iOS, my BetterEvents don't run correctly and I repeatedly get this error in the XCode log window:

No AOT serializer was pre-generated for the type 'BetterEventEntry.OdinSerializedData'. Please use Odin's AOT generation feature to generate an AOT dll before building, and ensure that 'BetterEventEntry.OdinSerializedData' is in the list of supported types after a scan. If it is not, please report an issue and add it to the list manually.
Stacktrace is not supported on this platform. 
(Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 48)

SerializationAbortException: AOT serializer was missing for type 'BetterEventEntry.OdinSerializedData'.
  at Sirenix.Serialization.Serializer.LogAOTError (System.Type type, System.ExecutionEngineException ex) [0x00000] in <00000000000000000000000000000000>:0 
  at Sirenix.Serialization.Serializer.Create (System.Type type) [0x00000] in <00000000000000000000000000000000>:0 
  at Sirenix.Serialization.Serializer.Get (System.Type type) [0x00000] in <00000000000000000000000000000000>:0 
  at Sirenix.Serialization.Serializer.Get[T] () [0x00000] in <00000000000000000000000000000000>:0 
  at Sirenix.Serialization.SerializationUtility.DeserializeValue[T] (Sirenix.Serialization.IDataReader reader, System.Collections.Generic.List`1[T] referencedUnityObjects) [0x00000] in <00000000000000000000000000000000>:0 
  at Sirenix.Serialization.SerializationUtility.DeserializeValue[T] (System.IO.Stream stream, Sirenix.Serialization.DataFormat format, System.Collections.Generic.List`1[T] referencedUnityObjects, Sirenix.Serialization.DeserializationContext context) [0x00000] in <00000000000000000000000000000000>:0 
  at Sirenix.Serialization.SerializationUtility.DeserializeValue[T] (System.Byte[] bytes, Sirenix.Serialization.DataFormat format, System.Collections.Generic.List`1[T] referencedUnityObjects, Sirenix.Serialization.DeserializationContext context) [0x00000] in <00000000000000000000000000000000>:0 
  at BetterEventEntry.OnAfterDeserialize () [0x00000] in <00000000000000000000000000000000>:0 

I have added that entry to Odin's AOT Generation preferences, but I am still getting the issue (enabling automatic AOT generation before build or manually generating the dlls doesn't make a difference - still broken):

Although I do realize this is not directly related to Odin (I opened an issue on the BetterEvents github page too), I was wondering whether there was something I was missing regarding the AOT generation options - sorry in advance if I am wasting anyone’s time and thanks again for the wonderful too that is ODIN!

Unity version is 2019.1.4f1

[Tor Esa Vestergaard]

You do not seem to have added the type properly - typing the “naive” type name does not work - you must provide the proper C# type name, which will, in this case, likely be “BetterEventEntry+OdinSerializedData”, since it is a nested class. (Starting in 2.1, typing the name as you have done there will in fact work, since everyone keeps going wrong and doing it that way. We had to use the new expression compiler to parse the name, to achieve support for it.)

It seems strange, however, that the automation does not work. Does the list not fill up properly with a bunch of types to support when you scan your project? If not, then how are you using BetterEvents, exactly? The scan only finds and supports serialized data in assets and scenes. If you are only using BetterEvents at runtime through the code API, without actually having data for it stored in an inspector anywhere, the scan will likely not work.

[Leonardo Cavaletti]

Ahh, thank you, adding the type with that syntax did the trick - it’s a small comfort to know that everyone got that wrong too…

I am as puzzled as you are as to whether the automation would not work. Scan doesn’t indeed pick up anything, and I am not doing anything fancy with BetterEvents, just using them the standard way - I’ve got a

public BetterEvent OnStartEvents
public BetterEvent OnEndEvents

in one of my scripts and that’s it - those are serialised just fine in the inspector. The only quirk I can think of is that that script inherits from a (stupidly simple) abstract class.

[Tor Esa Vestergaard]

I believe I have a suspicion, actually. I just had a look at BetterEvents, and the way they serialize themselves would not indicate to the scanner that the asset in question needs to be scanned. Just as a test, try making sure that every Unity object (MonoBehaviour, ScriptableObject, etc) you have that contains a BetterEvent somewhere implements the ISerializationCallbackReceiver interface. You don’t have to put anything into the interface methods, they can be left empty - but the interface should be there.

[Leonardo Cavaletti]

Sadly that didn’t seem to work as well, tried implementing the ISerializationCallbackReceiver interface as suggested but that type is still not picked up by the scan, nor the automatic generation before build.

[Arno Benizri]

Thanks, I was having this exact issue !

[Tor Esa Vestergaard]

@Arno Benizri Did any of the suggested solutions work for you?

[Arno Benizri]

@Tor Esa Vestergaard Absolutely, I never even looked at the preference settings of Sirenix because everything worked for me so far, then a coworker made major changes to the project and I had the same errors as the original poster. More precisely, I could build but when the app started, I had these errors in the logs.
So I opened the preferences to AOT Generation, checked the boxes Automated Before Build, Delete Dll After Builds, I set Automate For Platforms to Android since I’m developing on the Oculus Quest, then in Support Serialized Types, I added BetterEventEntry+OdinSerializedData like you suggested, and Voilà. It was pretty straightforward for me.

[Tor Esa Vestergaard]

Right, thank you. I think I'll actually mark this as resolved for now, as adding the type to the support list manually does work, after all.