I’m building 2 dlls, one with UNITY_EDITOR, and one without, as described here by @silentslack and @Baste:
All works fine in editor, but I’m getting this error in builds:
The list of [SerializeReference] objects being deserialized is from a more recent version of Unity. This is not supported and objects will be skipped.
The dlls are made with the same version of Unity that I’m making the build with, so I’m not sure what’s going on. Has anyone run across this problem before?
I haven’t run across this, but I know that references to scripts in dlls can have some issues. As an example, if you move MonoBehaviours from your assets folder to/from a dll, all instances of those scripts become “missing script” because the way files are referenced are different between the assets folder and dlls.
In particular, when you reference scripts in the assets folder, it’s written down as the guid of the script, while in dll’s it’s the guid of the dll + the fileID of the script inside the dll
So that might be what’s influencing this, but I’m not quite sure. From looking at your error, I’m guessing that you’ve got a [SerializeReference] list of objects (MonoBehaviours or ScriptableObjects) who’s type are defined in the dll.
so something like:
// This lives in the dll
public class MyScript : MonoBehaviour { }
// This (probably) does not
[SerializeReference] public List<MyScript> scripts:
And apparently that ends up not being able to load. I’d open whatever prefab/scene file serializes these, and look for the data from the [SerializedReferences]'s refID’s. They’re look like this for scripts in the asset folder:
- rid: 8741429000712749056
type: {class: MMF_CameraFieldOfView, ns: MoreMountains.Feedbacks, asm: MoreMountains.Feedbacks}
data:
Active: 0
So search for type: {class: and see what shows up. What I’m wondering is that maybe the name/path/guid of your dll’s maybe sneak in there and makes Unity mess up loading the file.
Alternatively, stop using dll’s and use a package instead? That’ll slow down compilation, but maybe in this case it’s worth it.
Third alternative is to define the data that’s to be serialized in it’s own dll that’s always included and you reference in both the main dll and the editor dll. Then that data only has one version and should be easy to reference.
Thanks for the ideas. I checked the scene file and it seems correct.
I’m using SerializeReference for polymorphic serialization of actions and UNITY_EDITOR for editor only serialized data. My understanding is that this officially works now, without the “different serialization layout” errors this used to generate. The docs were updated to say this works now. And it works fine as source code. I just can’t get it working in a dll.
I’m wondering if it’s a combination of things that Unity doesn’t handle well (a list of SerializeReference objects, in a managed plugin, with editor and standalone versions). I remember seeing an old bug with lists of SerializeReferences, maybe this is an edge case that wasn’t fixed. I think I’ll have to pull it apart to see which part is breaking…
Or maybe just use AssemblyDefinitions instead. My understanding is that after the first compile it should be as fast to compile as a dll?
That’s a good idea, it allows for having conditional code for every platform, including Editor-specific code without needing to build separate DLLs manually.
There’s a bit of post processing that can potentially happen on each Unity-compiled assembly, but that only needs to happen when the assembly needs to recompile. Other than that, it should be the same ballpark as the normal C# compiler producing an assembly.
Assemblies only get compiled as necessary (source files or other dependencies changing), so in the sense that the library isn’t getting recompiled, yeah, it would be as fast on script compilation when there aren’t changes. Your main issue at that point would be how damn long domain reload takes.