(Case 1122461) Deserialization Problem of ScriptableObject containing Asset References

Error:

Code (CSharp):

1. A scripted object (probably SceneReference?) has a different serialization layout when loading. (Read 92 bytes but expected 164 bytes).
2. Did you #ifdef UNITY_EDITOR a section of your serialized properties in any of your scripts?

Code (CSharp):

1.     public class SceneReference : ScriptableObject
2.     {
3.         public AssetReference AssetReference;
4.         public string DisplayName;
5.         public string SceneName;
6.         public string Uuid;
7.     }

SceneReference has no #if but AssetReference has some.

That error message does not look helpful. The size of SceneReference should not change when the size of AssetReference changes. The only thing which comes to my mind is that the Addressable Asset System has problems with compression and that the asset is loaded compressed and then it tries to deserialize it without uncompressing it.

Edit: Should have noted: This only happens in a WebGL build and because that is IL2CPP based I'ved added a link.xml to include the whole assembly SceneReference resides in to avoid any Stripping.

 

Thanks for letting us know, I've added a ticket to our system.

 

@unity_bill I would like to provide some more helpful information if I find out why and how this happens. This issue is mightily strange and breaks our CI/CD as the builds made via CD all show this error and no addressable can be successfully deserialized. However on my local dev machine (same platform, same build target, same OS, same profile, both times clean player content then build player content) this does not happen.

Both machines are in the same network and use the same Cache Server (node.js based version running on the CI/CD machine). Of course both use the same Unity version.

I will try to go through the steps I do on my machine on the CI/CD machine by hand and try to find out why there is a different serialization layout but so far I have not the slightest clue (no code changes!)

 

Okay... it happens on both machines, not only the CI machine. Some builds work. Some don't.

 

Okay - two consecutive builds without a change on my side in between: One loads - one fails. I assume it is A) Cache related or B) related to files in the folder it builds the addressables into. That is the only thing I know that is different betwen two builds. Both were made with Clean Player Content > Build Player Content.

 

@unity_bill looks like this Case is actually related to Case 1117939. After failing several builds in a row I reimported scripts and assets manually and the next build worked.

 

@unity_bill as we got the mail, that the bug was reproduced but no fixed version yet. Is there any fixed in version known already? We are still heavily hindered by this in Unity 2018.3.12f1 which was just released.

 

@unity_bill Looking at Asset Reference and the forum post here I'd guess one of the problems is that we use AssetReferences inside of ScriptableObjects because of

\Library\PackageCache\com.unity.addressables@0.6.7-preview\Runtime\AssetReference.cs

Code (CSharp):

1. #if UNITY_EDITOR
2.         [FormerlySerializedAs("m_cachedAsset")]
3.         [SerializeField]
4.         Object m_CachedAsset;
5. #endif

and the other
Library\PackageCache\com.unity.postprocessing@2.1.4\PostProcessing\Runtime\PostProcessLayer.cs

Code (CSharp):

1. #if UNITY_EDITOR
2.         // UI states
3.         [SerializeField] bool m_ShowToolkit;
4.         [SerializeField] bool m_ShowCustomSorter;
5. #endif

(Although we do not use PostProcessLayer ourself in a ScriptableObject but I assume the PP package does itself)

Although this is not `Serializable` but `SerializeField`, I assume both affect the serialized binary layout.

 

yes, that is the problem, and it's fixed in the upcoming 0.7.x release.