Deprecation of support for the .Net Scripting backend used by the Universal Windows Platform

Do you have instructions on how to use the managed debugger for IL2CPP? We are trying to use it with a UWP HoloLens build that was previously .NET and we are having trouble figuring out where the source files are and how to debug it.

 

Thank you!

 

I tried replicating what you do in the video but it seems to refuse to connect.My cursor spins for a second and then nothing.

I'm trying to build and run on a Hololens.

 

Basically echoing what Charlie said, when attempting to attach the debugger to the running build in the other Visual Studio window, the cursor simply spins for a few seconds and then never successfully attaches. There is no error provided, and the output window is blank so it isn't clear why it isn't attaching.

Also as discussed in other forum posts, there seems to be a significant slowdown in iterations building with IL2CPP vs. .NET. I've tried following https://docs.unity3d.com/Manual/IL2CPP-OptimizingBuildTimes.html and "Scripts Only Build" but as someone developing for the HoloLens for the past 2 years, I can say I don't think we would have been able to complete our projects on schedule with the significantly increased iteration time. It seems to take us about 10 minutes to go from build to HoloLens deployment, whereas before it was about 3 minutes. Also as you were debugging on the HoloLens, the Unity C# projects feature that allowed us to modify the code in that built project, which saved a tremendous amount of time and helped us debug and tweak our HoloLens apps quickly and efficiently. The new IL2CPP doesn't seem to support this, which I think is a major loss of iteration development that improved effeciency for HoloLens Development.

That adds up in daily development. My feedback would be that you really should consider maintaining .NET support unless you guys can figure out how to increase the build & deploy times and increase iteration time. We are upgrading now because of the deprecation but, begrudgingly :-/ at this point.

 

Thanks for the update. Can you possibly let us know when you have the HoloLens fix? Do you suspect it will be weeks/months? Would it be a 2018.2 patch? Thanks.

In regards to the project details and timings:

It is for an incremental build. We are using .NET 4x in the project. I tested by adding a new TestScript.cs to one of my game objects and made a build. Here are the timings:

Build from Unity to VS-> 2:12 seconds
Compilation Time from VS -> 2:57 seconds
Linker Time -> 77 seconds

Deploy time to HoloLens was another few minutes (I didn't have a chance to time it). Some of the deployment lag may be due to symbols, which I've since disabled, but it was still several minutes for deployment.

I am using an Alienware 15 R2 and the project and Unity are on my SSD.

 

Thanks for the swift responses and help. I did disable the anti-virus software.

I've been able to get the compile times down. Release I am at 110 seconds and Debug is curiously faster at 45 seconds. Still slower than the expected 15 seconds. Linker is still slow. I'm attaching the build log here.

Code (CSharp):

1. "C:\Users\shaddad\Documents\DI Work\Projects\AR IRAD\AR-IRAD\AR Project\Builds\Project IL2CPP\build\bin\Win32\Release\GameAssembly.map" "C:\Users\shaddad\Documents\DI Work\Projects\AR IRAD\AR-IRAD\AR Project\Builds\Project IL2CPP\build\bin\Win32\Release\SymbolMap"
2. 1>Cleaned up 249 object files.
3. 2>------ Build started: Project: Project, Configuration: Release Win32 ------
4. 2>App.cpp
5. 2>UnityGenerated.cpp
6. 2>c:\users\shaddad\documents\di work\projects\ar irad\ar-irad\ar Project\builds\Project il2cpp\Project\app.cpp(26): warning C4973: 'Windows::UI::ViewManagement::IApplicationView2::SuppressSystemOverlays::set': marked as deprecated
7. 2>c:\users\shaddad\documents\di work\projects\ar irad\ar-irad\ar Project\builds\Project il2cpp\Project\app.cpp(26): note: Message: 'Use the TryEnterFullScreen method and IsFullScreenMode property instead of SuppressSystemOverlays. For more info, see MSDN.'
8. 2>Generating code
9. 2>0 of 160 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
10. 2>  0 functions were new in current compilation
11. 2>  0 functions had inline decision re-evaluated but remain unchanged
12. 2>Finished generating code
13. 2>Project.vcxproj -> C:\Users\shaddad\Documents\DI Work\Projects\AR IRAD\AR-IRAD\AR Project\Builds\Project IL2CPP\build\bin\Win32\Release\Project.exe
14. 2>GENERATEPROJECTPRIFILE : warning PRI249: 0xdef00520 - Invalid qualifier: DLL-RESOURCES
15. 2>GENERATEPROJECTPRIFILE : warning PRI249: 0xdef00520 - Invalid qualifier: DLL-RESOURCES
16. 2>GENERATEPROJECTPRIFILE : warning PRI249: 0xdef00520 - Invalid qualifier: DLL-RESOURCES
17. 2>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2428,5): warning APPX0108: The certificate specified has expired. For more information about renewing certificates, see http://go.microsoft.com/fwlink/?LinkID=241478.
18. 2>Done building project "Project.vcxproj".
19. ========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
20.  

 

I could open a bug if you'd like but I cannot upload source code w/out permission, which likely would involve an NDA. Let me know if I should still open a bug report as well anyways.

 

+10 on this. In my experience with Unity development, being able to iterate on the C# external to the project without needing a full Unity build cycle is incredibly valuable.

The usual maximum productivity developer loop for Unity is just playing a scene inside the editor -- editing C# and building/running inside the editor is very quick for PC apps, thanks to the Mono runtime. There's no IL2CPP build cycle required inside the editor, and no switching to VS2017 to play your scene.

This doesn't work for UWP apps. My app uses UWP audio APIs that are inaccessible when running inside the editor.

Previously, I would just build the C# projects for my app, then do my UWP-specific edit/compile/run cycle inside of VS2017. No switching back to Unity required to iterate on my code.

But with this deprecation, now every change I make to Unity C# code that's run by UWP forces a full Unity project build and a VS2017 project rebuild. I have to use both tools for every code change.

I certainly appreciate that you are going to work hard on shortening this loop. However, there is only so much you can do, given that both Unity and VS2017 are now involved whereas previously it was only VS2017.

Are you also planning to deprecate the Mono runtime for Unity PC apps? If not, then is it conceivable that you could support the Mono runtime for UWP apps? The most productive possible outcome for UWP development would seem to be the same support for UWP apps that already exists for PC apps -- namely, the ability to make C# code changes and immediately play your scene in the editor, with full access to UWP APIs. (Essentially, providing the ability to run the Unity editor itself under UWP.) Is there any roadmap towards this goal?

(HoloLens-specific question: alternatively, is it possible to use HoloLens remoting to support playing Unity HoloLens apps directly from the editor to a HoloLens?)

In the meantime, I will probably factor my app in such a way that I can run it under Unity without the UWP functionality to optimize iterating on the Unity scripts, while moving as much C# as possible into separate DLLs that I can iterate on in VS2017 without IL2CPP rebuilds. That step is just fundamentally painful, given how far from C# source IL2CPP output is.

Thanks for your engagement with the community -- as problematic as this change is, it's good to see UWP getting focus from Unity.

Edit: I see elsewhere you had this useful advice:

Thanks for providing the technical background on why the feature was more fragile than it appeared. I definitely hope you are able to reach the point of changing as few IL2CPP output files as possible when making incremental changes to C# scripts, as that'll certainly accelerate this loop.

 

Amen. This a very stupid idea that will have a huge impact on developer productivity.

 

I agree that being able to export from unity with the C# projects is a huge help.

I am in the ID@XBOX program and the documentation for integrating Xbox live functionality into my game had me export the unity project into Visual studio then add in extra C# Xbox live projects so I could then use the various api calls.

There are C++ versions of these projects but I don't know C++. As such it would be a huge undertaking to get the xbox live stuff in if I could not export using the .net scripting back end.

 

Could you explain a little more how I would go about this? Would I simply add the external C# projects to the C# project while its still within unity? or add the external C# projects to the C++ project once the build from unity is complete?

 

Just following up, do you have any updates on getting managed IL2CPP debugging working with the HoloLens?

 

Thanks for the update, but see above posts. When we attempt to attach, our cursor spins for a few seconds and never actually attaches. No error is given. We've reproduced this on 2 machines here. Have you seen that, and if so what is the workaround for it? Thanks.

 

We can give that a shot to see if it works, but we can't really use preview software for active development, so we'd really like to get it working with the current released versions if possible.

Is managed debugging Il2CPP supported with Visual Studio 15.7.1 and VSTU 3.7.0.1? That is what I currently have installed. Any other ideas what could be causing it to fail to attach, or any logs we could view to get information as to why it fails?

 

Thank you for the reply, especially as you are on vacation!. I have copied the Dlls and WinMD files into my unity project ( I have tried them in both the plugins folder and another new folder I created) but I cant seem to reference them in my unity scripts. Is this because the files are only marked as WSAPlayer under the platform section? I vaguely remember using plugins before and I had to supply a PlaceHolder file which would then allow methods to be called from my scripts. Is this still a requirement? (I am using unity 5.6.3P2) I have looked for documentation but seeing conflicting results which appears to be down to which version of unity is in use.

 

Here is a video for using plugins to access the Win 10 API. https://channel9.msdn.com/Blogs/2p-...-features-with-Unity-games-in-your-own-plugin

Hope that helps.

 

Thanks for the write up. I have been following the advice in this thread and this video:

However, I am still running into a problem. When I try to attach the Unity debugger, the Hololens doesn't show up in the list of Unity instances. Only Unity itself shows up. Is there anything else that needs to be set up for the Hololens to show up in the list?
I don't have the Holographic Remote Player installed on the Hololens, which could be the issue, but I'd rather have that confirmed first.

I also have an additional question, since I can't find anyone talking about it. Since I don't always have the hardware available, can I attach the Unity Debugger to the Hololens emulator as well?

Thanks in advance.

 

Its good to hear there is now need for the placeholder. I had already got the #if ENABLE_WINMD_SUPPORT around the plugin calls. I'm not sure how to test that the code I am within this condition though (apologies if I am missing something very obvious). When I open my unity project this section is greyed out in visual studio - This happened in the past when I had some #If NETFX_CORE conditions. This code only became enabled when I exported the project as a C# UWP project and opened that in visual studio - I understand that this code could not be called when running in the editor so it is correctly greyed out. However, as the export to C# is not an option here how can I actually test the code going forward?

 

Perfect! this was exactly what I was looking for. Its a very elegant solution - Is there plans to update the official documentation with this information?

Thanks again
Matt

 

To chime in, I previously also had debugger issues with IL2CPP, but those seem to be ironed out using the latest Unity 2018.2.6 and Visual Studio 15.8.

However, IL2CPP with HoloLens is an absolutely dreadful experience. Not only are the build times extremely frustrating (yes, I read above that you plan on working on this), the biggest issue I have with IL2CPP is that it strips out code and plugin references as it pleases. Especially with code that is only used for serialization, these parts just crash constantly. Now this is not the biggest issue though, because as long as it concerns managed code, link.xml is your friend; the time you lose on debugging this nonsense, however....

My biggest issue is that when you use third party (or your own) plugins using DllImport, the required DLLs are not taken into account by IL2CPP and the only message you get is the following

Exception thrown at 0x76E73502 in XR.Hololens.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x022FE6D0.
Exception thrown at 0x76E73502 in XR.Hololens.exe: Microsoft C++ exception: Il2CppExceptionWrapper at memory location 0x022FE868.
DllNotFoundException: Unable to load DLL 'pdfrenderer': The specified module could not be found.

So my question is: how can I make sure that IL2CPP does copy my plugin assembly? It is in folder plugins/WSA/x86 and it is defined as UWP, Il2CPP (although I've tried all possible combinations of settings and none work).

Seriously Unity, rethink your deprecation strategy until a point that your tooling around IL2CPP is in a state where people can actually work with them. Because the "we need less time spent supporting the .net scripting backend" shifts time spent to Unity developers who have to deal with the agony of IL2CPP every single day.

 

The plugin we are using is PDF Renderer from the asset store. It hasn't been updated since April this year and we have used it on Hololens with .net scripting backend before. It's only because we started having issues in projects with Unity 2018.x to deploy to HoloLens with both the .net scripting backend and the TextMesh Pro package enabled from Package Manager that we felt we didn't have another choice than using IL2CPP.

Now first I'd like to thank you for pointing me in the right direction and secondly I'd like to apologize for the frustrated rant, because I have the following to report:
1) After throwing out the PDF Renderer package and replacing it with the directory from another project that we previously had successfully built for HoloLens, the PDF Renderer now works in both a .net scripting backend build and an IL2CPP build
2) It's not all rosebuds and moonshine, because in order to have a successful .net scripting build, I had to remove the 2018.2 TextMesh Pro package completely, and bring back an old version (TextMeshPro-1.0.55.2017.1.0b12). Otherwise the .net scripting project didn't want to build at all. It does seem that the newer TextMesh Pro packages have an issue with building for HoloLens using a .net scripting backend.
3) Apart from the fact that the IL2CPP version builds terribly slow and does have its quirks for removing constructors of classes that we mainly use for serialization, it does seem to run faster on HoloLens

Also, while it's good to hear that .net scripting backend will still be supported for 2 years in version 2018.4, I do want to point out that we won't be using it if IL2CPP delivers. This for us does mean that build times and in general build workflow needs to be optimized and ironed out, and preferably you guys should adopt a strategy like obfuscation tools implement, being that there is some visual UI that provides insights in the stripping process, as well as some .net attributes that allow decoration of classes/methods/properties/fields that should never be stripped at all, rather than having to fiddle with the link.xml. Just my 2 cents.

Long story short, thank you very much for your help.

 

Any chance of creating/supporting a CPP WinRT host component and C# XAML UWP Host Project?

For LOB apps using C++ on host project side is very rarely used and there's very few libraries that are support (on UWP side).

 

I have been trying to use Unity3D 2018.2.11f1 IL2CPP scripting with Visual Studio 2017 to build UWP images for Hololens. This worked cleanly in Unity3D 2017.4.12f1 but under 2018.2.11f1 I am getting errors of varying sorts consistently. Is IL2CPP scripting supported for UWP images for Hololens in 2018.2.11f1?

Thanks!

 

Ok looking at the error message, I get "the build tool for Visual Studio 2015 (v140) can not be found.

I am puzzled.

 

New thread created.

 

I recently switched to testing with the IL2CPP backend and am experiencing VS not being able to attach to a running HoloLens app, as the instance running on the HoloLens does not show up in the Attach Unity Debugger dialog. This is with Unity 2018.2.12f1, Visual Studio 15.8.7, Visual Studio Tools for Unity 3.8.0.7.

Just to make sure I'm doing it right:

0. Unity project settings: Scripting Runtime Version = .NET 4.x Equivalent, Scripting Backend = IL2CPP, Api Compatibility Level = .NET 4.x, Capabilities InternetClient, InternetClientServer, PrivateNetworkClientServer enabled.

1. Export from Unity with Development Build, Script Debugging and Wait for Managed Debugger checked

2. Open the exported VS solution in VS instance A (build mode Debug, x86). IP of the HoloLens set under Debugging -> Machine Name and Auth type set to Universal (Unencrypted Protocol)

3. Open VS instance B from Unity by double-clicking on a C# script. B is for managed debugging (build mode Debug, Any CPU)

4. Debug -> Start Debugging in instance A

5. When the "Debug - You can attach a managed debugger now if you want" dialog appears on the HoloLens use Debug -> Attach Unity Debugger in instance B. But no instance on the HoloLens is in the list (only the Unity Editor if it running)

 

Yes, the HoloLens has access to the network over wifi. I can also access the device portal on it from my laptop over wifi. Connecting the Unity profiler to the HoloLens works when I manually specify the IP address. Using the IP in the VS Debug -> Attach Unity Debugger does not work, but I guess the port changes each session?

In the profiler documentation I see the note on Unity and the HoloLens needing to be on the same network subnet. Is that also a requirement for attaching the VS managed debugger? They are on the same subnet anyway, but was just wondering if it was really needed for debugging.

 

Okay, so patching the source to show the debugger port and attaching by hand works. I wouldn't be surprised if multicasting isn't enabled/supported on our wifi network.