A script behaviour has a different serialization layout...

Problem Summary

When running a development Windows build I’m seeing these errors:

![A script behaviour has a different serialization layout when loading. (Read 32 bytes but expected 56 bytes)
Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?][1]

There are 4 serializable classes inside files where the main class does have the #if UNITY_EDITOR platform dep. compilation flags, but they are in this format:

#if UNITY_EDITOR
....editor imports here...
#endif

[Serializable]
public class MySerializedClassOne(){ }

[Serializable]
public class MySerializedClassOne(){ }

#if UNITY_EDITOR
public class MyEditorOnlyClass(){ }
#endif

All threads that my GoogleFu yielded were either super old (2012-2014) with solutions that didn’t work, or were simply completely unanswered (all the ones in the past year).

Constraints

I saw in threads about these errors (from 2012) that found marking things as [NonSerialized] fixed the problem. Thing is, these classes hold prefab references and various level design settings for our automated maze generation Editor tools (see this devblog if you’re curious about wtf I’m talking about). Point is, these need to be serialized, otherwise they are not useful Editor tools.

Attempted Fixes

  1. I found that I actually could eliminate some of these errors by removing scripts from the Scene that did not need to exist in the runtime version of the game. For example Alan Zucconi’s ColorBlindFilter was throwing one of these errors and isn’t needed at runtime, so I simply deleted all Components from the Scene and presto that one error went away. So I figured if I did this for every single editor script we’d be gucci. So…I wrote runtime versions of some scripts that were needed at runtime, then I wrote more editor tools to automatically “prepare for publishing” which simply RemoveComponent()'s all the editor scripts that has anything to do with serialization. This eliminates a few more errors, but I still see a cascade of errors that guess SubtileScript and PillarScript “probably” are the cause (neither script have any [Serializable] tags and are marked for editor only with the PDC flags and [ExecuteInEditMode]).
  2. One curious thing I noticed (this might help myself or someone else figure out the cause of the problem) is that Zucconi’s script (which threw the same error as our scripts) has no serialization or #if UNITY_EDITOR flags whatsoever - I did add the PDC flag myself though.
  3. I made doubly sure absolutely no [Serializable] tags were inside of an #if UNITY_EDITOR flag across every single one of our scripts (not just the scripts that the console is saying “probably” are the cause).
  4. Moved the 4 serializable classes to a separate file just to make check if the #if UNITY_EDITOR even being in the same file was the issue. No such luck.

Questions

  • Any ideas on what I can try?

  • Could this be a Unity bug? In one of the super old 2012 threads this was in fact a bug with how C# development builds were created that Unity later fixed.

  • These errors don’t appear to actually impact the game itself, either in development or non-development builds. Everything works fine and there doesn’t appear to be a performance impact, so is it possible we could just ignore these if no solution is found? Or is that a really bad idea?

Your post is pretty long so it’s possible I missed something, but I wanted to speak to this point:

I made doubly sure absolutely no [Serializable] tags were inside of an #if UNITY_EDITOR flag across every single one of our scripts

So what matters here is whether there are any serialized fields inside #if UNITY_EDITOR blocks, not necessarily whether any serializable types are defined inside them. So, for example, this will cause the problem:

using UnityEngine;

public class NewBehaviourScript : MonoBehaviour
{
    #if UNITY_EDITOR
    public string someStringOnlyUsedAtEditTime;
    #endif
}

In this case, someStringOnlyUsedAtEditTime unfortunately needs to be part of the run-time serialization layout, even if you never use it. The fix is to just remove the #if UNITY_EDITOR guard for these cases.

My own solution to this error was fixing a mismatched class-name / script-name. I had a scriptable object class named State, but I’d named the file AIState. There were five instances of the scriptable object in my project, corresponding to five “serialization layout” error messages that appeared on load in the build (note that the errors only appeared in the build, not in play mode). Renaming my scriptable object class to AIState solved the problem.

You might also find that the class in question in an assembly which isn’t present in standalone build for your target platform (ie. test or editor only assemblies). This can be either because it’s in an editor folder or, if you’re using assembly definition files, that it’s in an assembly which has been marked as editor only or as a test assembly. That seems to also lead to this error at runtime.

An error saying the type was missing would be way more helpful than the one saying it’s the wrong size. It took me ages to work out what was going on when I hit this!

I ripped all those out of my source code and still get the error.

I had a similar problem, due to the fact that the scripts were located in the folder with the Assembly Definition, in which the required target platform was not specified

I encountered this error when I was referencing SOs in the inspector. Moving those SOs into resources and switching to Resources.Load() (rather than using the public inspector var) fixed the problem for me.

Sometimes this might be due to some compilation issue.

For me, the project worked well in the editor, but it didn’t work as a build. So I took development-build and it showed me the errors similar to the image posted in this question. All the working scripts were specified as missing in the dev-build. Also, most of the assets are specified as having a different serialization layout.

I tried to use Reimport All and it solved the issue. Hope it might help someone facing a similar issue as mine.

I used had a scriptable object class inside of a file with a different name then the class name.

After placing the class in it’s own file everything started to work fine on android :slight_smile:

My friend was having this problem when we were trying to play multiplayer. It turned out that Norton was deleting their lib.burst.generated.dll file for some reason. We just had to put the game files in an exception folder that Norton couldn’t touch and that did the trick!,One of my friends was having this error when we were trying to play multiplayer. It turned out that Norton was deleting their lib.burst.generated.dll file for some reason. We just had to put the game files in an exception folder that Norton couldn’t touch and that did the trick!