The problem is that they don’t contain ANY clue as to what is wrong and where.
I cant deduct what is the problem, i really need help.
Recursive Serialization is not supported. You can't dereference a PPtr while loading. (Constructors of C# classes may not load objects either. See stacktrace.)
UnityEditor.HostView:OnGUI()
Error building Player: Recursive Serialization is not supported. You can't dereference a PPtr while loading. (Constructors of C# classes may not load objects either. See stacktrace.)
UnityEditor.BuildPlayerWindow+BuildMethodException: Build failed with errors.
at UnityEditor.BuildPlayerWindow+DefaultBuildMethods.BuildPlayer (BuildPlayerOptions options) [0x001b9] in C:\buildslave\unity\build\Editor\Mono\BuildPlayerWindowBuildMethods.cs:162
at UnityEditor.BuildPlayerWindow.CallBuildMethods (Boolean askForBuildLocation, BuildOptions defaultBuildOptions) [0x00050] in C:\buildslave\unity\build\Editor\Mono\BuildPlayerWindowBuildMethods.cs:83
UnityEditor.HostView:OnGUI()
Do you have ScriptableObjects or MonoBehaviours that are trying to instantiate others in their constructor? The error isn’t clear without any context and not seeing the code, but it looks to me like that’s what it’s referring to. If there’s a bigger stack trace that would be helpful as well.
Ok I found the problem.
The problem was some scriptable objects with recursive serialization (very handy for having some “directories”).
Before Unity 2017 it was just a harmless warning saying the max serialization depth is 7, now it’s a nonsense error that only appear when building.
I’ll go ahead and throw out what worked for me since this is the top result when searching google.
Basically I had serializable class that had a reference to another serializable that had a reference to the original serializable class (so class 1 refed class 2 which refed 1) creating recursive serialization. Either rework that code to remove the circular reference or roll back to a previous version of Unity that doesn’t prevent you from building if you have this error.
The problem is not in the serialization itself, it’s understandable why it happens, and how to prevent it.
The problem is that the ERROR message doesn’t give you any insights on WHERE the error is, if you have massive codebase you will spend a lot of time hunting for it without a clue where to look at.
Same problem here, but when upgrading from 2018.3.3 (if i remember correctly), to 2018.3.8. it broke so many things…
I created a new project and i started importing my old project piece by piece through packages. I imported all the scripts and there were minor issues I already solved. This recursivity issue arised when i imported everything ok, and lastly I imported the prefabs.
Now I have to look at each one of them searching for the bug. Perhaps importing them one by one. Anyone knows a better alternative?
I’ve got the same issue. Is there a way to tell unity not to worry about the property ([??ignore] type directive). I have an external class library that copy in to the unity project that has such circular references. You can use directives like [XmlIgnore] outside of unity, but I’m not sure if these work in unity serialisation?
If you use [RuntimeInitializeOnLoad] or (editor) [InitializeOnLoad], this also happens if you call Resources.Load from within methods with this attribute, so you cannot load unityobjects from within any method with these attributes or their call stacks, even if you have no depth or references in your serialized (Unity.Object) objects, which makes this message super confusing and frustrating.
I had this error for the past two weeks (2019.3b9), and only figured this out when I commented out the attributes.
Just had this problem here (unity 2019.4.25) today. Seems like it was a serialization loop in a class I had, which had a backlink to its parent class, which was also serializable… Making that backlink a [NonSerialized] field seems to have fixed it.
I have to say though… this is by no means clear in any way from the error message… the serialization limit appears only as a warning, and the build time error has zero information about where it comes from.
Thanks for posting your solutions, hopefully mine will be of use to someone else in the future.
I have circular serialization in my project, but it’s in the form of arrays of length 0 or 1: ClassA has a field ClassB[ ] and ClassB has a field ClassA[ ], and at some depth the length of the array is 0, which breaks the loop. I still get this error, but it still lets me build the game and it functions completely normally. Should I be worried?
I built the app and had it running fine. I had some errors which I was debugging, viewing the log. I added a couple of print statements in my code, clicked to build+run, and I got these build errors.
I’ve just tried ‘Build’ from inside VS which worked. Then tried ‘Build’ from Unity which worked and I have run the .exe okay. Tried Build+Run and got a build failure.
Finally tried Build only again, got the two errors, but the build was successful.
Solved. I returned to an old version from a few days ago where the work had mostly been finding the source of issues, and the fixes were easy to reimplement. I’m using a database asset, GameDataEditor, and assigned its keys to an array of strings for local use:
I was surprised to see the allocation at the definition with the method call “spc_DataCache.GetAlienKeys()” worked - there were no VS errors or compile errors, so I left it there and it ran fine in the editor. It’s only when it came to building, this generated the build errors with inconsistency - “Build” generated two errors but built and ran. “Build and Run” generated errors and failed.
There was actually a clue in the second, less generic, error which pointed me to StarSystem_Controller, but I wasn’t directly using get_persistentDataPath directly and didn’t find the error with a conventional search. I also had forgotten I had made this change since the last working build as there were no editor or runtime errors. The error was further misleading though as it said this reference to ‘get_persistentDataPath’ should be made in Awake() or Start(). It’s fine to have it called anywhere in code; just not in field definitions!
In conclusion, this error is likely caused by assigning in your definitions a call that refers to get_persistentDataPath. Check the error that mentions the script and check its fields.
Also, be wary of copy/pasting stuff in the editor as shortcuts; it may accept something that’s unbuildable!
I had the problem too, but I wasn’t aware of any recursive errors. I use Rider as ide and went to Build → Clean Solution. After that it was fixed. I’m not exactly sure what it does, I think something like it removes unused icludes.
