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

> 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.

 

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.

 

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.

 

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.

 

@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]

 

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?

 

I cannot use Vungle.Ads with IL2CPP, only with NET.
If Unity.Ads give us support in UWP we are happy to change ^^

 

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!

 

... 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#.

 

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?

 

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!

 

@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.

 

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

 

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.

 

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.

 

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.

 

> 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?

 

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

 

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.

 

@Tautvydas-Zilys @JoshPeterson I was able to convert my 70+ UWP/XAML controls to Noesis, successfully ending my dependency on the .NET scripting backend. In case this might help others... I write about it briefly here https://www.noesisengine.com/forums/viewtopic.php?f=12&t=1759

 

I think one of the merits of IL2CPP is that it is non-.NET.
Remember that most platforms do not adopt .NET. They give developers only C++ compiler.
It is unrealistic that Unity might force each platform to spend additional effort for .NET.
Nowadays the platforms which can execute .NET as .NET are only standalone and Windows Store. (Others are not or substantially not).
Imagine there should be "IL2CPP by .NET", could you believe that Apple accepts it?