The Mixed Reality Forums here are no longer being used or maintained.
There are a few other places we would like to direct you to for support, both from Microsoft and from the community.
The first way we want to connect with you is our mixed reality developer program, which you can sign up for at https://aka.ms/IWantMR.
For technical questions, please use Stack Overflow, and tag your questions using either hololens or windows-mixed-reality.
If you want to join in discussions, please do so in the HoloDevelopers Slack, which you can join by going to https://aka.ms/holodevelopers, or in our Microsoft Tech Communities forums at https://techcommunity.microsoft.com/t5/mixed-reality/ct-p/MicrosoftMixedReality.
And always feel free to hit us up on Twitter @MxdRealityDev.
Deploying app to MR Portal is failing intermittently
I am using the latest MR Portal and latest windows insider preview build.
I am using the MR Portal in simulator mode.
About 50% of the time I can't seem to deploy my app to the MR Portal. After hitting F5 from visual studio, the app tries to launch, and looking at the debug log of VS I am seeing the following logs:
**---- start of debug log ----
OS 'Windows 10 (10.0.16241) 64bit'
PlayerConnection initialized from C:/dev/projects/hololens/MRInputTest/App/MRInputTest/bin/x86/Release/AppX/Data (debug = 0)
PlayerConnection initialized network socket : 0.0.0.0 55466
Multi-casting "[IP] 10.10.10.7 [Port] 55466 [Flags] 2 [Guid] 1203039561 [EditorId] 0 [Version] 1048832 [Id] MetroPlayerX86(heroes) [Debug] 0" to [225.0.0.222:54997]...
Started listening to [0.0.0.0:55466]
Player data archive not found at C:/dev/projects/hololens/MRInputTest/App/MRInputTest/bin/x86/Release/AppX/Data/data.unity3d, using local filesystem
GfxDevice: creating device client; threaded=1
Direct3D:
Version: Direct3D 11.0 [level 11.1] Renderer: NVIDIA GeForce GTX 1070 (ID=0x1be1) Vendor: NVIDIA VRAM: 3072 MB
Initialize engine version: 2017.2.0b3 (4c2ac554540c)
'MRInputTest.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\dev\projects\hololens\MRInputTest\App\MRInputTest\bin\x86\Release\AppX\UnityEngineProxy.dll'. Cannot find or open the PDB file.
'MRInputTest.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\dev\projects\hololens\MRInputTest\App\MRInputTest\bin\x86\Release\AppX\System.Linq.dll'. Symbols loaded.
'MRInputTest.exe' (CoreCLR: CoreCLR_UWP_Domain): Loaded 'C:\dev\projects\hololens\MRInputTest\App\MRInputTest\bin\x86\Release\AppX\System.Reflection.Extensions.dll'. Module was built without symbols.
-- end of the debug log---**
The app is not showing on the MR portal. I am seeing only black screen there even though I can see the boundary rectangle.
If I keep trying to deploy, eventually it will deploy fine, and usually when this happens I can see additional logs which looks like the following:
Setting up 2 worker threads for Enlighten.
Thread -> id: 491c -> priority: 1
Thread -> id: 12b0 -> priority: 1
This is when things are going fine.
I wonder if other devs are also experiencing similar issue, or this is just me.
Comments
I had the same thing happen to me. The thing that works best is if you don't auto-start it from Visual Studio. First, restart your computer. Next time you deploy, go to Build>Deploy Solution. Don't do the standard Debug>Start Without Debugging. Then, put on your Acer and enter into Mixed Reality. Launch your app from the list of all apps on the MR start menu.
Thanks for the feedback Sean (@mr0ng)!
I guess this is a known issue that impacts other devs too.
This happens about half of the time, it's really frustrating and slows down the dev time.
For my case, most of the time I do need to debug my app so I can see the debug traces of the code path. With debug mode, the output of Debug.Log will go to the VS's debug output. You will not get to see the log output if you are to deploy and run it from the device. It's good to hear the workaround you mentioned but again I need to debug the app to see the log traces.
When Unity 2017 beta finally fixes the 'c# project' property' during build, I will certainly be putting break points in the #codes and single stepping etc; this is all the crucial debugging stuff. So I really hope Microsoft will fix this problem soooon.