Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

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

Discussion in 'Windows' started by Tautvydas-Zilys, Jul 9, 2018.

  1. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    As of Unity 2018.1, we have been supporting two scripting backends on the Universal Windows Platform (UWP): .NET, and IL2CPP. With the release of 2018.2, we are deprecating support for the .NET scripting backend. The goals for this deprecation are twofold.

    The first goal of this deprecation is to make it easier for you to port games to UWP. Much of the developer pain associated with porting games to UWP in the past has been due to differences in API surface area and differences between the .NET Native and the Mono and IL2CPP runtimes Unity uses on other platforms. This change will ultimately make it easier to port games to UWP going forward for most developers.

    The second reason for this deprecation is to make it easier for us to support you by fixing issues efficiently. Because the .NET scripting backend is completely different than the runtimes we use for all other Unity platforms, it has been challenging for us to maintain a consistent quality-level relative to the rest of Unity. This deprecation will ultimately enable us to spend less time maintaining the .NET scripting backend, and more time working on the features and issues that are most important to you.

    IL2CPP has the same .NET API surface as all other Unity platforms, and IL2CPP has had support for accessing WinRT types and APIs for some time now. So with the addition of the IL2CPP managed debugger in 2018.2, the developer experience on IL2CPP is now on a par with and superior to what the .NET scripting backend provides.

    IL2CPP has already been the default since 2017.2, , so we expect most will have no issues with this. However, if you have not yet tried using IL2CPP and you do experience any issues, please be sure to file them. We plan for full removal of .NET scripting backend support in 2019.1.

    Feel free to ask questions and discuss it in this thread.
     
  2. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    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.
     
  3. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
  4. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    Thank you!
     
  5. charlie-peter

    charlie-peter

    Joined:
    Dec 14, 2015
    Posts:
    9
    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.
     
  6. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    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.
     
    Dalton-Lima and mdroxas like this.
  7. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    We're looking at the connection issues with debugging - it was brought up to our attention yesterday. Strangely, it only seems to happen on HoloLens and not other UWP devices. Stay tuned - we'll definitely fix it.

    As for iteration times: is 10 minutes an incremental build time, or a clean build time? I would fully expect it to take 10 minutes to build for the first time, however, subsequent builds should be much, much faster. If they're not, I'd like to follow up to figure out what's going on there. One more thing to check is whether you're using .NET 4.x or .NET Standard 2.0 API compatibility level - the latter is smaller and should build much quicker.

    Lastly, iteration times is our number one focus post 2018.3. We're working on making IL2CPP emit less code, and on making our class libraries smaller.
     
    Dalton-Lima and charlie-peter like this.
  8. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    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.
     
  9. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    I first need to figure out what's failing. I aim to do it today if I can get my hands on a device. Hopefully it can be worked around without changes to the engine. But if we do end up having to fix it there, we'll definitely put it in 2018.2 patch.

    I assume you disabled your antivirus software as pointed out in that doc page? Windows Defender on my machine causes the builds to take 3 times longer...

    How many files got recompiled in that 2:57? Adding one script shouldn't result more than a few files being recompiled if you built on top of a previous build. I'd expect the compilation time to take at most 15 seconds.

    Also, can we get a bug report on the link times? I suspect we might be hitting an edge case somewhere. A repro project would help us evaluate that kind of things and potentially make it faster. If you do report a bug, please link to this post where I ask for it.

    Let's work together on this and make it faster!
     
  10. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    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.  
     
  11. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    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.
     
  12. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    It's not much we can do without source, as these incremental compilation times really depends on your code.

    We have improvements to linking times coming already. As you noticed, building debug is faster because the compiler doesn't spend time optimizing your code.
     
  13. RobJellinghaus

    RobJellinghaus

    Joined:
    Jul 10, 2017
    Posts:
    17
    +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.
     
    Last edited: Jul 16, 2018
    wellovate and jethrogillgren like this.
  14. LocalJoost

    LocalJoost

    Joined:
    Dec 28, 2016
    Posts:
    3
    Amen. This a very stupid idea that will have a huge impact on developer productivity.
     
  15. matt33315

    matt33315

    Joined:
    Mar 28, 2014
    Posts:
    94
    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.
     
  16. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    (I’m on vacation - my replies to all posts will be delayed)

    It’s not unfeasible, but we didn’t have any immediate plans of this. The biggest problem of Mono on UWP is that Mono currently does not support calling into COM and Windows Runtime APIs. That means all the C# code that calls into UWP specific APIs wouldn’t work on Mono. It took me 14 months of work to add this support into IL2CPP, so it’s definitely not something we can make happen quickly.
     
  17. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    You can use those APIs from your scripts in Unity in C# with IL2CPP. You don’t have to use C++.
     
  18. matt33315

    matt33315

    Joined:
    Mar 28, 2014
    Posts:
    94
    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?
     
  19. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    Just following up, do you have any updates on getting managed IL2CPP debugging working with the HoloLens?
     
  20. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    Managed debugging with IL2CPP and the Holoens does work in Unity 2018.2, but it is a bit slow, likely do to slower Wifi connections. We're working on improving that right now though.
     
  21. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    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.
     
  22. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    We have not seen that behavior. In our case, the attach succeeds, but breakpoints can take a while to load.

    There is a newer version of VSTU (version 3.8) which does less communication on on the network. I'd recommend giving it a try. You'll need to install the preview version of Visual Studio though to get it:

    https://visualstudio.microsoft.com/vs/preview/

    If you have a chance, please let me know if this improves the situation.
     
  23. shaddad

    shaddad

    Joined:
    Dec 1, 2016
    Posts:
    23
    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?
     
  24. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    6,920
    I agree. I'm hearing that VSTU 3.8 should be a released version soon.

    Yes, IL2CPP managed debugging is supported with Unity 2018.2 and these versions of VS and VSTU.

    I'm not sure why it is failing. We're going to do some more testing on our side to try to understand why. Unfortunately, we don't have any logging for this exposed, but hopefully we can reproduce it here.
     
  25. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    (Still on vacation, replies are still delayed)

    Put all the DLLs and WinMD files from the package into your Unity project, configure them to be compatible with UWP and then just use them from your c# scripts under “ENABLE_WINMD_SUPPORT” define.
     
  26. matt33315

    matt33315

    Joined:
    Mar 28, 2014
    Posts:
    94
    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.
     
  27. AiRobotMedia

    AiRobotMedia

    Joined:
    Jun 13, 2018
    Posts:
    61
  28. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    You don't need to use a placeholder, but remember to wrap code that calls into those plugins with #if ENABLE_WINMD_SUPPORT/#endif.
     
  29. Hefaistus

    Hefaistus

    Joined:
    Mar 4, 2015
    Posts:
    1
    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.
     
  30. matt33315

    matt33315

    Joined:
    Mar 28, 2014
    Posts:
    94
    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?
     
  31. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    See this post: https://forum.unity.com/threads/uwp-without-net-how-do-you-get-fast.538872/#post-3557795

    With that, the code will not be grayed out.
     
  32. matt33315

    matt33315

    Joined:
    Mar 28, 2014
    Posts:
    94
  33. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
  34. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    Hey, I just tested this today with the new VS update (15.8) and it seems to have started working. I was able to step through code and inspect variables. Could you give it a shot?
     
  35. 2Elemental

    2Elemental

    Joined:
    Jul 17, 2013
    Posts:
    12
    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.
     
    Dalton-Lima likes this.
  36. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    IL2CPP doesn't strip native plugins - I don't think that's the issue. Does this specific plugin work when using .NET scripting backend? The plugin should be copied automatically as long as it's configured to be compatible with UWP player in plugin importer. However, the plugin will fail to load if any of its dependencies are missing (same can be said for .NET scripting backend, though). Things to check:

    1. After you build/deploy the app, is pdfrenderer.dll is actually present on disk;
    2. Open it up in dependency walker and see whether it depends on any other DLLs that aren't present.

    If the native plugin works with .NET scripting backend but not IL2CPP, we'd like a bug report as that's definitely something we want to iron out. There are currently no known issues like that.

    .NET won't be removed until 2019.1, and it will be supported in 2018.4 LTS branch for 2 more years. If you really need it, you can still use it.
     
  37. 2Elemental

    2Elemental

    Joined:
    Jul 17, 2013
    Posts:
    12
    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.
     
    arufolo likes this.
  38. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
  39. mega-me

    mega-me

    Joined:
    Oct 26, 2017
    Posts:
    2
    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).
     
  40. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    ^ I replied to that on this thread. tldr: you can already do it. There are no changes that need to be made on Unity side to use it.
     
  41. DonRolph

    DonRolph

    Joined:
    Oct 3, 2016
    Posts:
    12
    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!
     
  42. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    Yes. What kind of errors are you getting? You should probably create a new thread for your issue.
     
  43. DonRolph

    DonRolph

    Joined:
    Oct 3, 2016
    Posts:
    12
    Ok looking at the error message, I get "the build tool for Visual Studio 2015 (v140) can not be found.

    I am puzzled.
     
  44. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    Please make a new thread and we'll discuss it there.
     
  45. DonRolph

    DonRolph

    Joined:
    Oct 3, 2016
    Posts:
    12
    New thread created.
     
    Last edited: Oct 11, 2018
  46. paulmelis

    paulmelis

    Joined:
    May 15, 2018
    Posts:
    9
    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)
     
  47. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    That sounds like right steps. Is your hololens app able to access the network in general (apart from the debugger)? Is the wifi that HoloLens is on reachable by your desktop computer? Are you able to connect Unity profiler to HoloLens?
     
  48. paulmelis

    paulmelis

    Joined:
    May 15, 2018
    Posts:
    9
    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.
     
  49. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,645
    Yes, they need to be. The device discovery mechanism for both profiler and debugger works the same way - if you cannot see the profiler connection, I'm not surprised you cannot see the debugger one either. It's likely that multicast packets are not being propagated on your network (perhaps your router is blocking them?).

    Anyway, can you try this? In generated Visual Studio solution, open file "debugger-agent.c", and find "mono_debugger_agent_parse_options" function. Stick this at the end before the closing brace:

    Code (csharp):
    1.     OutputDebugStringA("Starting il2cpp debugger: ");
    2.     OutputDebugStringA(agent_config.address);
    3.     OutputDebugStringA("\r\n");
    Now when you run your game, it should output (in Visual Studio "Output" window) which port it listens to for the debugger, and you could try connecting to it manually by inputting IP in Visual Studio.

    Also, you can playing with this: https://gist.github.com/jbevain/7bf8851752d7f0a829bdc3ce0175a50b
    It's the code that detects running game on your local network in Visual Studio. That might shed some light on why it's not showing up.
     
  50. paulmelis

    paulmelis

    Joined:
    May 15, 2018
    Posts:
    9
    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.