A script behaviour has a different serialization layout when loading...

Hi,

I cannot run my new C# scripts anymore on the phone. The old games do work but none of the new ones.
I get the following error message on phone screen in Development Build:

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

What does that mean?

The cube drops on the plane but the Gui Text does not update on the phone.

Updating Unity from 4.2.1 to 4.2.2 did not solve the problem.


Any ideas?

 

Try cleaning your directory with wp build, it worked for me

 

Cleaning the build directory did not work for me.:-x
Updating to Unity 4.3.0 did not help either.
Trying to repair Windows Phone SDK 8.0 failed ("Unable to locate package source ...downloads\packages\Windows_SDK\Win8SharedSDKTools.msi").
Propably something has corrupted during a Win8 crash.:neutral:

Uninstalling and reinstalling the WP SDK solved the problem.
One week lost time of my life and even Unity's bug report guys could not solve this.

 

Just FYI,

I had the same problem over a month ago.
It was never fixed, and I never found a solution.
I had to drop Windows Phone as a target for the app.

But I wish you luck, and I hope you can figure it out.

-Chilton

 

Here's my thread from 9/27. I think I posted about it in another thread earlier that day, or the day before.

http://forum.unity3d.com/threads/20...ipt-is-too-much-The-answer-might-surprise-you!

-Chilton

 

We also had this message (Read 44 bytes, expected 148 ) when attempting port to the Metro target.
After a lot of tracking/debugging I found that a component refered to a class B that was marked as [Serializable]. Class B inherits class A which was not marked as [Serializable]. Since A was not used in an array I dropped the tag, rebuild my assetbundles and all worked great.

To figure out which script was the problem, I dumpet all dependencies from my bundle. Sorted out all the scripts and added a constructor with a debug.log("myclass") in all the scripts. When the error occurred, the constructor had run just in front telling me what script was causing this.

Hope this helps others as I've spent quite some time on this now. And Unity, would it be so hard to just tell us the script in your error message?

 

I've logged a bug
Case : 580776

 

Hi Tautvyadas did you guys look at this suggestion? I logged the bug number above.

 

Thanks, we have upgraded the project to 4.3 now, and it seems it might be catching this same error, but rather at build-time instead of at player run-time.

I have attached a screenshot of the errors we receive. I would think these might be related. If more information such as the class or line of code responsible could be added in both places (in the player console debug) and the editor in 4.3+ at build-time, that would be lovely.



I have added this information to the case too.

 

Hi all.

In my case problem was that MonoBehaviour script was in Plugin folder.

 

Is there any more info on how to easily identify the offending class?

I have an asset from the asset store that works fine with iOS builds but is having this problem with Windows Store builds.

 

Hi Aurimas, Thanks for the info.

I've gone through all the #if lines (there were only 4) and changed them so that they only change a variable value and moved all the program logic outside the #if block using the new variable to control the flow.

But this has not helped. I'm still getting the error.

Is there any way to better identify the specific class that is causing this error?

In case this is a Unity issue, I've submitted a bug report. My case # is 630867.

 

I just discovered that if I don't select "Unity C# projects" in build settings I can deploy and run my project to my Surface RT without the serializatin error.

That's got to be a Unity bug, right?

 

I submitted a bug report last night. The case # is 630867. Thanks for looking into this.

 

Have you guys had a chance to look into this yet? Have you reproduced the issue on your end?

 

Thanks very much for looking into this.

I can confirm that restructuring my folder hierarchy has solved the issue.

 

Well, I might have spoken too soon.

The serialization issue is definitely resolved and the Windows Store Build of my test project runs fine on my dev PC via Visual Studio 2013 but when I deploy it to my Microsoft Surface RT, I get a new error in the developer console (see the attached screenshot).

I'm not sure if this is related to the bug you identified and/or if it's also something I can work around via the folder structure so I've submitted a new bug report. The case # is 632944.

 

Thanks, I will do that.

 

I got an email today saying that the fix for the serialization bug would be included in an upcoming patch release.

Thanks very much for that. Unity rocks!

Last night I tried to debug the "managedHandle" error to see if I could get any info from Visual Studio's output window.

I couldn't remember where I saved the project that I submitted with the bug report so I just recreated it from scratch.

But this time, the error did not reappear.

I noticed recently that I sometimes have to manually rebuild the entire solution when I switch platform targets (sometimes the app will crash on launch) so maybe the managedHandle error had to do with a bad partial recompile?

Anyway, if it comes up again I will be sure to check the VS output window for more info.

 

@Tautvydas Zilys
What would be the workaround in case you WANT to have serialized properties available only in editor?

for instance,

#if UNITY_EDITOR
public bool debuggingPath = false;
public bool debuggingPriority = false;
public PriorityType priorityToDebug;
#endif

I'd like to see those values in the inspector, and to have their state persist, but I do not wish to have them included into the build (for obvious reason). This is very common practice throughout my project, I would have assumed that unity will re-serialize all the data during the build phase.

 

Nope. I'm using 4.6.1

Interestingly this only popped up recently, before hand there wasn't an error in previous builds.

I'm targeting PC though, if that makes a difference.

On second thought, this was just an example. I was assuming this is where the problem is, loads of those throughout the project. I did update some plugins as well lately, so I can't be sure what exactly is causing this. (A better error message, with the class name would have been very helpful here)

 

@Tautvydas Zilys

Just checked this with 4.6.2, and I am still getting this error.

Can i get some hotpatch that prints out the class name?

 

After further investigation, i've found the issue.

that problem was actually a missing script, however, that error never showed up in the dev console of the build, only the "IFDEF" one.

 

I wrote a quick DLL to log what was causing the error. Had to dig around in a bit of Unity's internal stuff to find out how to get some logs as to what is happening. Here is the DLL, just inject it on the little Unity launch menu. Note: The DLL is x86 only as I didn't want to mess with x64 ASM. Dependencies: msvcrt120.

EDIT: The lines you'll be looking for in the log file, which is named ObjectLoadingLog.txt, look like this:

[DESERIALIZE] On MonoBehavior <someBehaviorName>. Got x bytes, expected >x bytes

 

I ran into this issue when building assetbundles with dependency in Unity 4.6.3 using the old BuildPipeline API.
Here's basicly what I've done: (follow the documentation http://docs.unity3d.com//Manual/managingassetdependencies.html)

Push Dependency
Build Shared Assets' Bundle
Push Dependency
foreach asset
Build Assetbundle
end
Pop Dependency
Pop Dependency

when building multiple assets in this way, the error "A script behaviour has a different serialization layout when loading" is shown as the bundle's asset been instantiated, and all the scripts on the GameObject are missing.
Turns out the building code is completely wrong, the correct one should be like this below:

Push Dependency
Build Shared Assets' Bundle
foreach asset
Push Dependency
Build Assetbundle
Pop Dependency
end
Pop Dependency

Building Assetbundle in this way will eliminate the problem

 

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