Search Unity

Official Poll: What's preventing you from switching to IL2CPP scripting backend on Windows Store?

Discussion in 'Windows' started by Tautvydas-Zilys, Dec 14, 2016.

?

What's preventing you from switching to IL2CPP scripting backend on Windows Store?

  1. Lack of Windows Runtime support

    25 vote(s)
    25.5%
  2. Plugins that I use for Windows Store don't work

    27 vote(s)
    27.6%
  3. Longer iteration times

    54 vote(s)
    55.1%
  4. No C# debugger

    35 vote(s)
    35.7%
  5. I had no idea IL2CPP was even an option

    2 vote(s)
    2.0%
  6. I don't target Windows Store

    11 vote(s)
    11.2%
  7. I already use IL2CPP when targeting Windows Store!

    10 vote(s)
    10.2%
  8. Other (please tell us about it in the thread!)

    16 vote(s)
    16.3%
Multiple votes are allowed.
  1. doctorpangloss

    doctorpangloss

    Joined:
    Feb 20, 2013
    Posts:
    183
    > Other (please tell us about it in the thread!)

    Because I develop my iOS + PC cross-platform game on a macOS device, and I can't build for IL2CPP on it.
     
  2. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    6,344
    You couldn't build with .NET scripting backend for UWP on macOS either. This is not a new restriction.
     
  3. Noemata

    Noemata

    Joined:
    Dec 14, 2018
    Posts:
    6
    On the surface, your observations are all valid Tautvydas. However, once you factor in technology churn into the mix, it's a bit harder to justify some of them. IL2CPP is not really an option anymore. By the time Unity games switch to Unity v 2018.3 + IL2CPP to a significant degree, adoption of 16299 will be a non-issue. Similarly, I see lots of folks hanging on to Windows 7 for dear life. Once Windows 7 support stops on January 2020, you'll be in the crazy grandpa category if you persist with it. Choices, like IL2CPP aren't options. Switch or die.

    I completely disagree with your assertion that .Net Standard 2.0 support for UWP is not useful. Having .Net Standard 2.0 will dramatically accelerate adoption of 16299 as it significantly improves the viability of UWP. Because .Net Standard 2.0 + is the future of .Net, not playing nice with it will result in marginalization.

    Because .Net and C# are now essentially severed from Windows, it's a safe bet to adopt the technology even more. However, ignoring where C# and .Net are headed and trying to coopt the standard will lead to a dead end. A good example of that is HPC#. It's very cool, but will result in a Unity Island for the folks that leverage it. I know that's the idea. I've seen this play before. Roslyn is super cool, and provides all the tooling needed to gracefully extend C#.

    Wouldn't it be better to coordinate with Microsoft on how to extend C# rather than leave Unity as the only place where HPC# works? Yes, you wind up with a captive development community. Such power plays sometimes work. In this case you'll have to worry about what Microsoft might come up with to crush its prospective future. They are in a position to crush folks that try to disparage or coopt C#. I also wonder who is going to do the Visual Studio integration for HPC# so it has things like intellisence. It won't be Microsoft, and I have to wonder how happy Microsoft will be with their current Unity integration investments once they realize what this drift from their standard will mean.

    Your most valid point relates to the requirements associated with porting .Net Native to other platforms. Because the .Net Native compiler consists of a series of stages given it's a C++ compiler under the hood, Unity could leverage the compiler architecture to do most of the heavy lifting. The C# .Net Native compiler handles all of Linq, and the various other painful IL translation transformations. The Visual Studio compiler already supports x86/x64 and AMR32/64 targets, which covers a lot of where Unity needs to go.

    .Net Native is 2-10x faster than IL2CPP, Coreclr is 2-5x faster than mono. There are thousands of PnP .Net Standard 2.0 compatible packages out there at the moment. UniRx will never match the real System.Reactive. Do you really think Unity could survive such a disparity were some other capable game engine to come along and fully embrace those advantages?

    Unity needs to stay out of the compiler business, and stick to what it's really good at, a wonderfully accessible and capable gaming development platform.
     
  4. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    6,344
    Majority of people using Windows are not developers, and have no idea what .NET standard 2.0 is. They don't really care about "viability of UWP".

    We support .NET Standard 2.0 through IL2CPP and Mono.

    .NET native doesn't use C++.

    *In select workloads. It was slower than IL2CPP when integrated in Unity because it lacks embedding API.

    And most of those work with IL2CPP.
     
  5. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    89
    I'm grateful for the active discussion on this topic. Some software vendors just refuse to communicate when vision or direction hits a roadblock ... or controversial topics are raised. Thank you Unity et all for the transparency and ongoing discussion.
     
  6. Noemata

    Noemata

    Joined:
    Dec 14, 2018
    Posts:
    6
    Perhaps some reading about .Net Native might be helpful: https://blogs.msdn.microsoft.com/do...r-and-runtime-in-visual-studio-2015-update-2/

    With respect to the .Net Native compiler, this quote from the above provides a useful summary.

    "With 1.3.1 this is now done using the same whole program inlining engine used for high performance C++ applications, enabling significant improvement for many scenarios."

    As cool as IL2CPP is in the short term, in the long term it won't keep up with the .Net Native compiler (doubtful Unity corp will beat Microsoft in the compiler game). I've done comparison benchmarks. They aren't pretty for IL2CPP. It's rarely faster than .Net Native, and often considerably behind. If you want to prove IL2CPP is faster, present how you are benchmarking.

    I can appreciate the integration issues being challenging and perhaps not even possible due to many factors including licensing considerations.

    The fact that Unity does not have an integrated Nuget package manager will create a form of firewall between it, and the wider .Net community.

    IL2CPP is cool. The .Net Native compiler is cooler. The real question is whether Unity will wind of detaching itself from where the rest of .Net is headed.
     
  7. varun_mani

    varun_mani

    Joined:
    Sep 18, 2018
    Posts:
    7
    @Tautvydas-Zilys, really appreciate this thread... Could you expand a little more on how I could achieve the above?

    1. When you say "change the generated project to C#" I am assuming you mean in the generated solution, I would manually create a new UWP c# project and try to mimic the same structure as a .net scripting backend generated c-sharp project correct? Is there a simpler way to ask Unity to build out a c# project with an IL2CPP backend?

    2. How do I ensure that GameAssembly.dll is included in the build? Since I am editing the solution generated by the IL2CPP build, I already see a UnityData SharedItems "project" in the solution with a GameAssembly.dll entry under references. Would that be enough? I've included a screenshot of the solution explorer

    [img=368x455]https://i.imgur.com/FO2Io2w.png[/img]
     
  8. varun_mani

    varun_mani

    Joined:
    Sep 18, 2018
    Posts:
    7
    Hit two more issues in trying to do the above...

    1. I think I am successfully able to build the project now, but on deploying, I keep hitting an exception right during the AppCallbacks constructor: System.IO.FileNotFoundException: 'The specified module could not be found. (Exception from HRESULT: 0x8007007E)'

    A quick web search seemed to point to an issue with loading a splash screen maybe? (https://answers.unity.com/questions/1187996/appcallbacks-constructor-throws-filenotfound-excep.html)

    So, I went back to Unity and tried to re-build the project into the same output folder (since Unity is only supposed to touch IL2CPPOutputProject and UnityData) but I got an error in UnityEditor: UnityException: Build path contains project built with .NET scripting backend, while current project is using IL2CPP scripting backend. Consider building your project into an empty directory.

    2. Does this mean that I will have to re-create the c-sharp UWP XAML project every single time I re-build from Unity?
     
  9. IndieFist

    IndieFist

    Joined:
    Jul 18, 2013
    Posts:
    307
    I cannot use Vungle.Ads with IL2CPP, only with NET.
    If Unity.Ads give us support in UWP we are happy to change ^^
     
  10. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    6,344
    I created an example project here: https://github.com/TautvydasZilys/unity-uwp-il2cpp-with-csharp-project-example
     
    varun_mani likes this.
  11. varun_mani

    varun_mani

    Joined:
    Sep 18, 2018
    Posts:
    7
    I am slowly making progress on this but am hitting a wall again. Since we can't access UnityEngine.dll anymore, how would "I expose my own API" to bridge between IL2CPP land and C# land? I'd like to keep as much as possible in Unity-land as possible but there are something things that need to be driven from outside of Unity (in C#) and somethings that Unity needs to drive in the XAML thread.

    Once again, thanks in advance for the help!
     
  12. varun_mani

    varun_mani

    Joined:
    Sep 18, 2018
    Posts:
    7
    ... Ideally, I would be able to write a C# script within Unity called CommsInterop or something like that... Build that script using Unity IL2CPP and then be able to code against it from the XAML layer in C#.
     
  13. varun_mani

    varun_mani

    Joined:
    Sep 18, 2018
    Posts:
    7
    Dug into the example project you provided a little bit more. I noticed you have a c++ class that is imported into Unity as a plugin with a
    __declspec(dllexport) void __stdcall AddActivatedEventArgs
    method in there.

    That then gets imported in the C# XAML project using
    Code (CSharp):
    1.  
    2. [DllImport("GameAssembly.dll")]
    3.         static extern void AddActivatedEventArgs(IActivatedEventArgs args);
    4.  

    I also noticed the
    Code (CSharp):
    1.  
    2. [DllImport("__Internal")]
    3.     extern static void SetupActivatedEventCallback(AppActivatedDelegate callback);
    4.  
    How would I achieve the same thing within a Unity C# script instead? i.e., how would I do a
    __declspec(dllexport) void __stdcall 
    within a Unity C# script? Or is the only way to get XAML C# code to call a Unity C# function to have it call a Unity CPP plugin which in turn calls a callback in a C# Unity script?
     
    Last edited: Feb 13, 2019
  14. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    6,344
    There is a way to achieve it. You need to create a C# interface in a .winmd file, implement it in your C# code, pass it to C++ code and then have the other C# side retrieve it.

    To do that, you first need to create a "Windows Runtime Component" project:

    upload_2019-2-13_14-16-9.png

    In there, define the interface with all the methods you want to be callable. Once you build it, put it in your Unity project. In your C# script, implement the interface. Then, pass the object that implements the interface to C++ code:

    Code (csharp):
    1. [DllImport("__Internal")] static extern void SetWinmdInterface(IMyInterfaceInWinmdFile instance);
    Code (csharp):
    1. static ComPtr<IInspectable> s_WinmdInterface;
    2. extern "C" void __stdcall SetWinmdInterface(IInspectable* instance)
    3. {
    4.     s_WinmdInterface = instance;
    5. }
    Then, from the other side C# code, you want to add a reference to this .winmd file in your .csproj and retrieve it from the C++ side:

    Code (csharp):
    1. [DllImport("GameAssembly.dll")] static extern IMyInterfaceInWinmdFile GetWinmdInterface();
    Code (csharp):
    1. extern "C" __declspec(dllexport) IInspectable* __stdcall GetWinmdInterface()
    2. {
    3.     IInspectable* instance = s_WinmdInterface.Get();
    4.     instance->AddRef();
    5.     return instance;
    6. }
    Then you can just call methods on that interface and you'll end up calling into the other C# side.
     
  15. varun_mani

    varun_mani

    Joined:
    Sep 18, 2018
    Posts:
    7
    Got it! I was afraid a WinRT component was the only path for this. But it makes sense :) Thanks so much for all the help @Tautvydas-Zilys!
     
  16. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    89
    @Tautvydas-Zilys and @JoshPeterson. Just an update for my usage scenario. You might remember that my project required a shared .NET runtime between UWP and Unity because my project started as UWP and Ishared domain objects and logic. At that time I used Unity for rendering only and for this reason I was essentially stuck on the .NET scripting backend.

    Today, with exception of a few bugs or quirks in IL2CPP that I'm still working through, I am now able to use switch over! It's a huge relief to me that I won't be prematurely stuck on a LTS release.

    Using the Noesis GUI Asset, I converted 90+ XAML screens and user controls from UWP to native Unity with pretty high fidelity. The upshot is that the title now support multiple platforms and my debugging experience is greatly simplified. The biggest challenge (beyond porting existing code) was the trial and error process of learning what .NET APIs are supported/unsupported in IL2CPP.
     
  17. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    3,880
    Thanks for the feedback!
     
  18. tvald

    tvald

    Joined:
    Jul 13, 2018
    Posts:
    10
    The biggest loss is Visual Studio's incredibly detailed CPU/GPU performance profiling and analysis. Hololens 2 is still a resource-constrained platform and we need deep visibility into our application behavior to optimize it properly. Unity's profiling isn't really useful for these complex situations, lacking core tools like:

    - CPU call tree: hot path expansion
    - CPU call tree: inverted / bottom-up view (or a function-based view)
    - GPU event timeline
    - GPU single frame analysis
     
  19. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    6,344
    IL2CPP doesn't prevent you from using any of those tools. They're still available, and usually the C++ counterparts are even better for performance analysis.
     
    tvald likes this.
  20. SteveLeigh-readify

    SteveLeigh-readify

    Joined:
    Feb 12, 2017
    Posts:
    3
    My problem with IL2CPP is the long build times. Everything else I can deal with - but waiting for that ol' progress bar is painful to the extreme.

    My primary use case is with Hololens - in the other targets, the editor experience is powerful enough that I don't have to build much.

    So to get me to love the state of the world, you would need to either
    1) Provide an option for "play" in the editor to give me a native-feeling experience (I'm talking World Anchors, up to date spatial mesh, stable holograms, (text-to-(speech)-to-text) - everything. Right now we get a shaky terrible looking half experience.
    2) Dramatically improve the build time.

    Option 1 is preferred.
     
    rsmeenk likes this.
  21. LocalJoost

    LocalJoost

    Joined:
    Dec 28, 2016
    Posts:
    3
    My primary use case is HoloLens and Windows Mixed Reality as well. If I now want to change code that can only run on a device, I need to rebuild the project from Unity. Single. Time. Even if I change as much as a comma. That takes time. I need to make a number of settings to make sure my code is even debuggable. The compilation and deployment of the C++ app takes much longer. Then I need to go back to my C# solution and attach that to the running app and THEN I can debug. I make a fix... rinse and repeat. When I go to production, I need to remember change back a number of settings because I don't want my app listening on debugger ports.

    More work, more time, more actions, more failure points. It feels a bit Apple-esque to me - not really caring about developer experience. The .NET backend was great for quick development turnarounds.

    So either make sure development/debugging with IL2CPP get dramatically faster/easier, or at least let it the .NET backend live, if only for development purposes.
     
    rsmeenk likes this.
  22. apavloff

    apavloff

    Joined:
    May 2, 2017
    Posts:
    3
    I can use Holographic Remoting to reduce iteration time. However, if I'm doing anything that requires calling into UWP or other native APIs, that doesn't work.

    Unity has also taken it upon themselves to create Yet Another .Net Runtime in IL2CPP, just as the main .Net runtime becomes more platform-agnostic than every before. I would hope that the IL2CPP code has a robust set of unit tests comparable or identical to the main corefx ones to ensure correct behavior.
     
  23. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    6,344
    We are working on making IL2CPP iteration faster. It should get better every release.

    IL2CPP has a lot of tests - tens of thousands that run on all platforms that IL2CPP supports. I'm not sure what kind of tests CoreFX tests, but we aim to make sure that every bit of functionality in IL2CPP is covered by a test. Calling into Windows Runtime APIs alone has around 7000 tests.
     
    stonstad likes this.
  24. SteveLeigh-readify

    SteveLeigh-readify

    Joined:
    Feb 12, 2017
    Posts:
    3
    > We are working on making IL2CPP iteration faster. It should get better every release.

    This is great, but I can't see it ever getting to the same level as VR development.

    Is there effort being put into improvement the editor/remoting experience for AR device deployments, so it gets access to all features bits of the target device?
     
  25. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    6,344
    What do you mean with "Same level as VR development"? I honestly believe we can make developing with IL2CPP on UWP just as fast as it was with .NET scripting backend on UWP. The "Executable Only" build feature in 2019.1 + Build & Run button + Script only builds already provides fast script iteration on local machine. It doesn't support deploying to HoloLens yet, though.
     
  26. SteveLeigh-readify

    SteveLeigh-readify

    Joined:
    Feb 12, 2017
    Posts:
    3
    Sorry for the delayed reply - I should have put a watch on this thread, I didn't notice.

    In that context, I meant the way we can just hit play in the editor, and have it instantly appear on our headset with no compilation. We won't get to that level of niceness, because there's a compilation step in the middle - hence preferring a full-featured in-editor experience.

    Even without the compilation step in the middle, going from Unity => .NET => IL2CPP is always going to be slower than Unity => .NET stop.

    Regarding the "script only" stuff, I've never had much use for this. Maybe I'm developing inefficiently, but generally when I'm going to device, it's because I'm tweaking materials, shaders, components and stuff - the scripts are easily tested in-editor and rarely need device-specific deployments. Visuals and performance on the other hand change BIG TIME with a real spatial mesh and an additive display
     
  27. DaTruAndi

    DaTruAndi

    Joined:
    Apr 14, 2017
    Posts:
    13
    My TL;DR Summary:
    Toolchain iteration times from code change to "debug on physical device" (like HoloLens) take longer - costing hundreds of dollars mid-term and thousands long term - per developer.
    Unity shouldn't allude to understand .NET better than everybody else - if there is a need for mechanisms like IL2CPP - contribute it to the .NET Foundation.

    Longer:
    I aired and shared my thoughts about IL2CPP multiple times, including at a high level event at Microsoft (the event was covered by NDA unfortunately).
    In my opinion, at this point in time it is a form of hubris to drive IL2CPP. That's provocative, I know.
    There is the .NET Foundation. If there is a need for a mechanism like IL2CPP it should not be a one-off approach by a single vendor like Unity, but the need to build something that cross-compiles to many platforms is a core need the .NET Foundation should be interested in. Same with all the stripping and what-not mechanisms in there.
    There should be no IL2CPP vs .NET Runtime - there should be only a .NET Runtime that can do something similar to IL2CPP - when both needed and desired.
    Especially during highly iterative experimentation times on device, the tool-chain adds costly minutes to each iteration, adding to hundreds of dollars of cost shortly, and thousands of dollars over the course of the year per developer.
    Something like IL2CPP is great for the final build "to native" when building the "shipable" executable, but not during dev time.
    In short again: don't try to allude that you understand .NET better than everybody else - contribute to .NET and don't do the one-off that is IL2CPP.
     
  28. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    89
    JoshPeterson likes this.