I’m developing and maintaining a tween engine for Unity, DOTween, but some users recently encountered an issue with Windows 8 Phone/Store (while everything works perfectly on all other platforms). After some investigation, it seems that the reason is that a derived class fails to be cast to its base one.
Specifically, I have a
public class Vector3Plugin : ABSTweenPlugin<Vector3,Vector3,VectorOptions>
which, when cast to its base, for example like this:
Vector3Plugin plug = new Vector3Plugin();
return plug as ABSTweenPlugin<Vector3,Vector3,VectorOptions>;
returns null if inside a DLL, or throws an exception
if used directly inside some lose scripts.
This cast should totally be possible, and happens only for Windows 8 Phone/Store targets. Any chance of a workaround, or even better of a possible fix?
Just FYI, tried it on x86 Windows Phone emulator both from Unity 4.6.3 and Unity 5 RC3 - can’t reproduce issue. Looks like a bug which only reproduces on ARM device.
I’m a rather beginner C# programmer, so I’m not sure if this applies, but I found this StackOverflow discussion. It’s a bit different, as it’s a runtime issue in our case, and not a compiler one. But one of the answers suggests casting to object first and then to the desired type as a workaround, maybe this would help. I don’t yet own a WP device, so I can’t test it myself.
Interesting news, thanks to Rafal who’s helping me test various options to try and work around this issue. For now we were unsuccessful, but Rafal discovered an interesting things.
From VS:
Debug build works
Release build doesn’t and generates the known error Master build (which apparently should be the build to set for final production) works!
So in the meantime you can use master build. @Aurimas-Cernius , maybe this info can be useful to you?
I encountered the issue, as stated by Izitmee the Master build will work if executed or deployed from Visual Studio.
Unefortunately it will not work if the build is deployed by others means, which can lead to issues during app certification or worst once the app is live on the store.
I have an idea for a way to fix this issue (even if I hope Unity fixes it on their side too), since this seems to happen only with Unity’s “interchangeable” structs (Vector2/3/4, probably also Color/Color32), because they kind of break some rules of the C# language.
Note that @rafaellop 's test passed correctly when tweening integers, not when tweening a Unity Vector3, which is the real issue. We’re trying more tests now to find a workaround for that.
@Tautvydas-Zilys Thank youuuuu I believe the reason is the way the implicit Vector2/3/4 (as well as Color/Color32) interchangeable cast is implemented in the Unity Engine.
we asked Microsoft for help pinning this issue down, and they have found the root cause of it. It’s happening due to the combination of the way we handle assembly references and the way their tools compile managed assemblies to native code before deploying them to the phone (that’s why you saw differences according to how it was deployed).
This issue may affect generic types with generic arguments, that are defined in UnityEngine.dll and are value types (classes are not affected). So, Vector2/3/4, Color and Color32 (and several others) meet this requirement.
We are currently looking for workarounds we can give you. I’ll get back to this thread as soon as we find a solution.
In the meantime I created an alternative version of DOTween which works on WP8.1 too (and on all other platforms). It’s slightly slower (but just slightly) so I’ll scrap it as soon as you’ll have a viable alternative, but in the meantime I’m attaching it here. To make it work, I replaced Vector2/3/4, Color/Color32 and Quaternion (I actually thought Quaternion didn’t fall into the issue, but after additional tests apparently it did too) with custom struct implementations, which implicitly cast to Unity’s correct format only when applying the final values. That way, the “guilty” cast which couldn’t happen is now happening and everything works.