Search Issue Tracker
By Design
Votes
0
Found in
2019.4
2019.4.18f1
2020.2
2021.1
2021.2
Issue ID
1309586
Regression
No
Unable to build different variable types on different Platforms
How to reproduce:
1. Open the attached "Android test.zip" Project
2. Try to build the Project on Android
3. Observe the Console
Expected Behavior: The build succeeds without errors
Actual Behavior: The build fails with an error
Reproducible with: 2019.4.19f1, 2020.2.3f1, 2021.1.0b3, 2020.2.0a2
Could not test with: .2018.4 due to assembly errors
Note:
- Build error: Type '[Assembly-CSharp]TestCode' has an extra field 'Health' of type 'System.Single' in the player and thus can't be serialized
UnityEngine.GUIUtility:ProcessEvent (int,intptr,bool&)
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Mono Windows Builds don't produce full log callstacks when generating logs
- AssetBundles fail to load when running in Built Players for Mobile Devices
- UI elements with text gets bigger and grey when Player window is moved to another screen with different resolution
- System name accepts multiline text but crops it on confirmation, duplicates input, and shrinks the field when empty
- UI element scale and position are wrong in project build when DRS is changed with HDR and Software Dynamic Resolution enabled
Resolution Note:
In your use case, in the editor the Property uses a different backing field for serialization and the intention is to access this data directly through a field at runtime to avoid extra check. This means that similarly to the Property you would need to initialize the value at runtime and would not need Serialization of the value. If the attribute [System.NonSerialized] is used against the field it will be present at runtime and accessible and will therefore not produce build errors as the serialization layout will be the same.
In attachment I have modified the code to demonstrate an initialization on Start. Another alternative would be to use ISerializationCallbackReceiver.OnAfterDeserialize to do this initialization at runtime. Unfortunately this will add a couple of bytes to your object at runtime. Though you would need to be cautious that those approach won't work if this code is called from a precompiled library.
Another alternative, is to make the property logic very minimal for runtime.