UnityEngine.Keyframe is not serialized properly.

Issue #523 resolved
Joel Clark created an issue
  1. We're building our game for iOS & the game crashes on startup, with the error SerializationAbortException: AOT serializer was missing for type 'UnityEngine.Keyframe'. Keyframe wasn't automatically picked up by the AOT scan, so I manually added it: "UnityEngine.Keyframe, UnityEngine.CoreModule". But the issue still persists.

  2. I'm not sure. Our project is massive and we can't send it. I'm sorry for that :(

  3. N/A

  4. Unity 2019.1.0b6

  5. 2.0.16

  6. No.

  7. macOS Mojave, 10.14

Comments (13)

  1. Tor Esa Vestergaard
    • changed status to open

    Can you generate an AOT support dll using the button at the bottom of the AOT Generation preferences, and send me the resulting dll file?

  2. Tor Esa Vestergaard

    Hmm, that dll definitely contains support for the UnityEngine.Keyframe type. Have you enabled the AOT generation automation for builds? Are you sure the support dll is included in your iOS build?

  3. Joel Clark reporter

    I haven't turned on the AOT generation automation -- I've just been relying on manually updating it periodically. As far as I know, the dll is included in our iOS build. We've been using Odin on this project for a while, and the AOT has been working before. It's just stopped working now.

  4. Tor Esa Vestergaard

    Opening the dll with ILSpy and taking a look at the code it contains shows clear references to all needed classes for Keyframe serialization: Keyframe itself, KeyframeFormatter, ReflectionFormatter<Keyframe> (as a fallback) and ComplexTypeSerializer<Keyframe> - so I can only surmise that something else is going on, preventing this from getting into your final iOS build. Try enabling automation for a build (and make sure your target platform is in the list of automation platforms), and see if that makes a difference.

  5. Joel Clark reporter

    Everything is working when I build locally, so I'm starting to suspect it's an issue with our build pipeline somehow. I'll try enabling AOT build automation & see if that affects things.

    Two questions on that: Is there some sort of logging that I can look for in the Editor.log (after a build) to ensure that the automation is happening? And is there a way I can manually call the scan, so I can work it directly into the flow of our build pipeline?

  6. Joel Clark reporter

    Automating in the build didn't fix the issue. I'm still seeing the issue fixed when building locally, but not in our build pipeline.

    I've attached the part of the build log where the AOT generation is done. The only thing that looks odd is that it requests to update the APIs, and skips it.

    The only other thing odd that happens in the build is the following:

    Begin MonoManager ReloadAssembly
    Assembly 'Assets/Editor Default Resources/UMotionEditor/Plugins/Application/UMotionApplication.dll' will not be loaded due to errors:
    Unable to resolve reference 'Assembly-CSharp'. Is the assembly missing or incompatible with the current platform?
    Assembly 'Assets/Editor Default Resources/UMotionEditor/Plugins/Editor/UMotionEditor.dll' will not be loaded due to errors:
    Unable to resolve reference 'Assembly-CSharp'. Is the assembly missing or incompatible with the current platform?
    Unable to resolve reference 'Assembly-CSharp-Editor'. Is the assembly missing or incompatible with the current platform?
    Assembly 'Assets/Plugins/Sirenix/Assemblies/AOT/Sirenix.Serialization.AOTGenerated.dll' will not be loaded due to errors:
    Unable to resolve reference 'Main'. Is the assembly missing or incompatible with the current platform?

    Although that's at the very very start of the log, before the build is actually being run, and the AOTGenerated.dll gets created & refreshed later on.

  7. Tor Esa Vestergaard

    You can indeed invoke the automation API yourself during your build pipeline, and see if everything looks right. It sounds like it's refusing to load the dll, perhaps because of some type references the scan caught and generated support for, that are not allowed to be in the build (whatever this 'Main' reference is)? Regardless, look at the contents of the Odin script file called BuildAOTAutomation.cs - you can see which APIs it invokes. It runs a scan and gets a list of types to support, then it generates a support dll for those types, and finally after the build is done, it deletes the dll again.

  8. Joel Clark reporter

    Great. I'll look there & work that directly into our build pipeline.

    On this issue -- I did a full reload of the project hosted on our build machine, and this issue finally went away. I think you're right that it was refusing to reload the dll (still not sure why), but forcing it to completely rebuild the library folder solved it. It makes our builds a lot longer, but hey, I'll take it.

    Thanks for the support, even though it wasn't really a bug with the plugin!

  9. Joel Clark reporter

    I need to re-open this. The same issue cropped back up.

    Initially, our builds weren't doing a fresh, clean pull from Perforce. The fix I mentioned above was changing our builds to get everything fresh. I guessed that it had something to do with some cached information of some sort. There was also some odd messaging in the build log, and I mentioned that above as well. I had also switched to using the automation for our builds, and that seemed to be working for a while.

    Eventually, we starting getting a new AOT bug even with all of that setup. Posting that below. I switched off the automation & went back to manually building our dll before each build. That worked for a bit, and then the original Keyframe serialization issue cropped back up.

    Any ideas? Anything I can do to help you track this one down? We're near a deadline :/

  10. Log in to comment