Serialization issue on building product - "GetBool is not allowed...", "The serialization data format 'Nodes' is not supported

Issue #208 resolved
Former user created an issue

Hi There,

I'm using Odin, and after updating to the newest Unity 2017.2.0f3 I can no longer build a product on Windows 10. While I can debug, I can neither 'Build', nor 'Build & Run'.
I'm getting a lot of errors like the following:

[Error] GetBool is not allowed to be called during serialization, call it from Awake or Start instead. Called from MonoBehaviour 'Prefsmanager' on game object 'Menu and Settings'.
See ""Script Serialization"" page in the Unity Manual for further details.
UnityEditor.EditorPrefs:GetBool(String, Boolean)

and

[Error] The serialization data format 'Nodes' is not supported by this method. You must create your own reader.

which are all invariably traced back to Odin:

Stack example:

[Error] GetBool is not allowed to be called during serialization, call it from Awake or Start instead. Called from MonoBehaviour 'Prefsmanager' on game object 'Menu and Settings'.
See "Script Serialization" page in the Unity Manual for further details.
UnityEditor.EditorPrefs:GetBool(String, Boolean)
GlobalConfiguration.get_SendConsoleToVisualStudio()
ActiveConfiguration.get_SendConsoleToVisualStudio()
VisualStudioIntegration.OnLog()
Debug.LogError()
UnitySerializationUtility.DeserializeUnityObject()    C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Utilities/UnitySerializationUtility.cs:1221
UnitySerializationUtility.DeserializeUnityObject()    C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Utilities/UnitySerializationUtility.cs:1012
UnitySerializationUtility.DeserializeUnityObject()    C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Utilities/UnitySerializationUtility.cs:984
Sirenix.OdinInspector.SerializedMonoBehaviour.UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize()    C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Unity Integration/SerializedMonoBehaviour.cs:25
GUIUtility.ProcessEvent()

Any help urgently appreciated.

Kind regards,

ch

Comments (16)

  1. Tor Esa Vestergaard

    The first error about GetBool looks like an error in Unity's Visual Studio Integration. I have been unable to reproduce it in 2017.2.0f3 on Windows 10, but I can see by decompiling the Unity assemblies and looking at the classes indicated in the stacktrace, that they are calling EditorPrefs.GetBool when checking whether they should send log events to Visual Studio's console. This is illegal and bad and the Unity people who wrote that code should be ashamed of themselves. I'll make sure to send Unity an error report as soon as I figured out what the conditions are for reproducing it. (Any information you have regarding this would be welcome.)

    The second error, which causes the first to appear by the virtue of logging an error message, I cannot reproduce either despite much trying. You have a MonoBehaviour "Prefsmanager" on a GameObject called "Menu and Settings" - could you provide the code for Prefsmanager, please, so I can try to reproduce the error?

  2. Christian Franz

    Thank you for looking into this. Below please find the stack trace of the second example (I have roughly 90 similar in my build since the update). The one thing they all have in common is that all scripts affected are descendants from SerializedMonobehaviour.

    [Error] The serialization data format 'Nodes' is not supported by this method. You must create your own reader.
    UnitySerializationUtility.DeserializeUnityObject() C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Utilities/UnitySerializationUtility.cs:1221
    UnitySerializationUtility.DeserializeUnityObject() C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Utilities/UnitySerializationUtility.cs:1012
    UnitySerializationUtility.DeserializeUnityObject() C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Utilities/UnitySerializationUtility.cs:984
    Sirenix.OdinInspector.SerializedMonoBehaviour.UnityEngine.ISerializationCallbackReceiver.OnAfterDeserialize() C:/Sirenix/Sirenix Solution/Sirenix.Serialization/Unity Integration/SerializedMonoBehaviour.cs:25
    GUIUtility.ProcessEvent()

    Kind regards,
    -ch

  3. Tor Esa Vestergaard

    I'm afraid that doesn't help me at all. If this is something that happens globally across your project, yet I can't reproduce it at all despite the exact same setup, then the most convenient thing would be for me to have a look at your project in order to reproduce it. Is you sending me your project (at tor@sirenix.net) to help debug this a possibility? Also, which version of Odin are you on?

  4. Christian Franz

    I'm using 1.0.5.2 with Unity 2017.2.0f3 -- unfortunately, sharing the project is somewhat impractical at 12 GB size and a lot of proprietary code that I must not share with people outside the project.

    Kind regards,
    -ch

  5. Christian Franz

    I'll see if I can create a small project using only Odin to re-create the issue. Removing SerializedMonoBehaviour from the class tree has conclusively shown that this eliminates the issue.

    Please understand that we are under a deadline, and we now have made the decision to completely remove Odin from the project; rebuilding all dependent scripts is in progress, Therefore I don't know if I have the time to create a demo project; the issue is closed from our perspective.

    Thank you for taking the time to look into this and your quick response.

    -ch

  6. Tor Esa Vestergaard

    I'm very sorry to hear that you've been forced to make that decision, but I do understand. This isn't an error we've ever encountered anywhere else or had reported before.

    If you cannot put together a demo project, or do not feel that you have the time, then one thing you could do that would be very helpful would be to send me the file for one of your scenes or prefab assets that contains one of the SerializedMonoBehaviour scripts that are bugging. Just the file, with forced text serialization - not any of the scripts themselves. Looking at the raw serialized data might be very helpful in diagnosing the issue.

    If I had to guess what had happened, I would guess that this must be some sort of project upgrade issues that caused Unity to somehow - essentially - mess up Odin's serialization data. As far as I can tell, what has happened is that there is a conflict between the data that is stored, and the format that it is marked as being stored in. All the data is still there, but is stored in the wrong format. This indicates that the serialization data has been somehow broken in between Odin serializing and deserializing it, since that discrepancy was introduced.

  7. Christian Franz

    Since this issue surfaced after an Unity update, your thoughts seem plausible. All our affected scripts are based on a class with multiple descendants, and to implement easy serialization we changed that base class's class from MonoBehaviour to SerializedMonoBehaviour; any script we use in our project inherits from a lot more than just SMB (this also makes a simple demonstrator for you difficult). If the configured prefabs in the scenes then have serialization issues, this could result in the error I objerved; but IMHO this also sh/would have meant that the pre-configured prefabs also bug out during testing in Editor - which they did not; they only do that when building for Player. I'm not enough familiar with how Unity's build process works to tell the difference between building for Editor vs. Player (I'm somewhat new to Unity and more familiar with classic IDE like Eclipse or XCode), but there may be a hint there.

    Interestingly enough, though, the Mac OS version of the project, based on the Win master uploaded to the cloud, did compile and build for player without issues, Odin included. Update to 2017.2 included, Strange.

    Anyway, thank you so much for taking the time to shed some light on this issue.

    -ch

  8. Tor Esa Vestergaard

    I have hurriedly taken some time to put together an Odin build which will do its very best to recover from this sort of situation, attempting to figure out what format is actually stored in the bytes when the stated format is clearly invalid, and then deserialize from the guessed format. If you wouldn't mind giving it a try, can you please send me a mail at tor@sirenix.net, or provide me a mail here, and I will send you that build right away, so you can see if it resolves the issue for you.

    Even if it doesn't resolve the issue, the extra data it now logs in case things do go wrong, should shed some additional light on the issue.

  9. Bjarke Elias Clauson-Kaas ├śrrild

    This might be a long shot. But have you guys tried just closing visual studio before building? Maybe that would prevent Visual Studio Tools for Unity from during silly things?

    Also, maybe updating Visual Studio Tool for Unity via the Visual Studio installer might solve the issue?

  10. Alexandru Palade

    Already tried with VS closed and the problem is still there. I'm also on the latest version of VS Tools; in fact, I just reinstalled my machine last weekend so everything is at the latest version.

    I did just realize one thing that's particular about our setup. We're using the experimental .NET 4.6 script runtime. I can't easily revert the project to 3.5 but that's something you might want to try in order to reproduce. I expect you're not officially supporting this setup but maybe future-proofing is a good idea. :)

  11. yc960

    I am encountering this issue as well in unity 2017.3.1f1 with odin 1.0.6.0 where removing the use of serializedmonobehavior resolved the issue. Tried with VS closed but no avail. Also script runtime 4.6.

  12. Log in to comment