We have been internally discussing about reasons people are still using the .NET scripting backend. It is no secret that we’re planning to drop .NET scripting backend support eventually, and make Windows Store an IL2CPP-only platform. The timeline for that, however, is a different discussion, and we’d like you to help us figure that one out. This is not something that will be done in 5.6, 5.7 or even 5.8 - and before we do it, we must make sure that we accommodate the needs of the developers and ideally have everyone switched to IL2CPP by that time. The answers to this poll will allow us to prioritize our IL2CPP work items.
So, can you tell us what is preventing you from switching to IL2CPP scripting backend on Windows Store?
Hi,
We use IL2CPP if properly supported by the target platform but we are not targeting Windows Store on our builds. Probably add this as an option to the poll?
[EDIT] Poll*, not pool (silly me).
I personally only use Windows Store at the moment for testing my asset so I test both .net and il2cpp. For me though, the debugger is a biggie, though most of my debugging has already been done im the editor. I’d also love to see some performance metrics between an il2cpp build and a .net build that has been run through .net native.
The C++ code it generates is a real problem for us. Not being able to debug scripts from the Unity side in the context of our Windows Store app is a real sticking point.
Do you mind elaborating? Did you ever try debugging generated C++ code? Is the problem the fact that it is hard to understand which portion of C++ code got generated from your C# code? Have you given Unity 5.6 beta a try where we introduced original source code annotations for generated C++ code? If so, does that help?
We haven’t attempted debugging with C++, but have inspected the output. In our tests, it was hard to find and recognize the generated C++ and where it fits in for complex components.
In general, developing in C# and then doing runtime debugging with C++ will certainly be a hindrance. Developers will need to know C++ well enough to understand the language conventions, and if there is a bug we’re working on fixing, the iteration time between C#/C++ will certainly be a productivity hit.
We have not looked at Unity 5.6… the source code annotations sound like they will help some. We have some work planned to look at it in the coming few weeks.
I must have missed that: Since when is ILCPP considered stable for Windows Store?
Last time I checked, it was experimental and half of the extensions we use didn’t support it.
What are the pros and cons?
Is there stuff not gonna work?
Only pro of ILCPP is better performance?
We aim to have all plugins and extensions be compatible with IL2CPP in 5.6.
It’s ‘stable’, and people are shipping games using it, but until 5.6 it was still missing some features - namely Windows Runtime support, so some plugins wouldn’t work.
Pros:
Identical .NET API compared to other unity platforms - you no longer have to rewrite your code to work on Windows Store;
In some cases significantly better performance;
IL2CPP uses the same serialization backend as all other Unity platforms, which eliminates certain long standing Windows Store bugs (like the one where we cannot scan static fields for UnityEngine.Object references and thus they will get unloaded when nothing else is referencing them), and enables some features previously unsupported on Windows Store (for instance, type trees for Asset Bundles, which makes you able to build them in one unity version and not have to rebuild them every time you update the editor).
Cons:
No C# debugger;
Longer build times (we’re working on this one).
IL2CPP is an AOT compiled platform, so obvious things like System.Reflection.Emit do not work. Up until 5.6, many plugins that were made especially for .NET scripting backend wouldn’t work either - you’d have to use the plugin variant that worked on the standalone player instead.
Thanks for the detailed info!
We use IL2CPP for iOS and Android, so I guess the System.Refleciton.Emit won’t be an issue anyway.
We are now just upgrading to 5.5, it’ll take a while until we use 5.6.
We have to evaluate 5.6 soon, since lightmapping completly changes, so I guess when we do that, we can also give IL2CPP a shot … the API unification sounds promissing.
On the other hand, does that actually mean I cannot access native code from unity script anymore?
E.g. this util function:
That should almost work just fine in 5.6 with IL2CPP - you’ll just have to change “NETFX_CORE” define to “ENABLE_WINMD_SUPPORT”. As I said before, we aim to make IL2CPP compatible with code you used with .NET scripting backend.
NETFX_CORE define used to mean two things: that your C# scripts were compiled against .NET Core 5 class libraries, and that you could reference “.winmd” files from scripts. With IL2CPP in 5.6, you can target full .NET 4.6 desktop class libraries. .NET 4.6 for desktop is almost entirely a superset of .NET Core 5, but it has minor differences - so we decided to not define NETFX_CORE instead introduce a new define that means that you can reference “.winmd” files from C# scripts. We also have new defines for different API compatibility level player setting on all platforms on Mono and IL2CPP scripting backend - NET_2_0, NET_2_0_SUBSET and NET_4_6.
The minor differences I mentioned is the lack of these types in .NET 4.6 profile that used to work on .NET scripting backends:
IL2CPP with zip plugin I use crashes the player on x86 only. I believe the bug has been submitted but I am not sure how long it will take to be fixed, if fixed at all.
It doesn’t work with Windows Store IAP.
We could submit our game to the Windows Store and works fine, sadly we can’t implement IAP because doesn’t work with IL2CPP.
