Whenever I build the windows 8.1 player from unity it goes through the entire process and then sits forever with a filled up progress bar and the message “Done”. The build dialog never goes away and never opens the build’s output folder and i cannot interact with unity in any way (including pressing the cancel button).
If i manually open the output VS solution i end up with a project that doesn’t build. When building a test project it didn’t even load the Assembly-Csharp-firstpass-metro and Assembly-Csharp-metro projects. When building my production project it had all 3 projects in the solution but the build fails because it can’t find “SerializationWeaver.exe”.
Has anyone else seen similar issues or is this likely something to do with my build environment?
do you know if this only happens in 5.4 for you? Could you download process explorer and check whether there aren’t any child processes of Unity.exe hanging?
I have not been able to install process explorer yet - i’ll have to work with our IT people on it because it fails to install.
However, I was able to determine the cause of the never-ending unity build. This was caused by our corporate Mcafee anti-virus scanner. Once i opened the “VirusScan Console” (windows key, then type “VirusScan Console”) and disabled “Access Protection” and “On-Access Protection” i was able to build the windows store player from unity and have that build fully complete.
Unfortunately the resulting VS Solution still will not successfully build the windows 8.1 app. I’ve include screenshots of the errors i get when building the VS Solution. The first image is from our team’s main project and the second is from an empty test project.
Thank you for your help that worked great! I’ve submitted a bug report on that just now.
While i have your attention i’ve got a couple more questions:
Now that i’ve fixed my compilation issue, when i build and run my production project the app loads the splash screen but instead of blinking the splash screen and then loading our main scene the app just stays on a black screen. I checked with an empty test project and that empty project starts up just fine. Additionally, i turn on the “show unity splash screen” build setting and that doesn’t even appear before the screen goes black. Any idea how to fix this?
How do i mark a bug as public? (i want a way to track the bugs ive reported since i haven’t gotten any email confirmations on my previous bugs - is this because i’ve had to manually active my unity install?)
the cpu is idling, memory usage is sitting at 88 mb (which is much lower than either my production project running b7 or an empty test project).
And to be clear this is a relatively new issue, since our project builds, runs and displays fine with unity 5.4.b7 i just get the black screen on beta 13 and 15 (i haven’t tested any other builds besides 7,13, and 15).
Could you paste Visual Studio output window contents? Additionally, could you try pausing execution in Visual Studio (debug → break) and pasting the callstacks you see there?
If this is a new issue, it would be great if you could submit a bug report about it with a repro project attach so we could look deeper into it and fix it.
When i initially debugged the app the call stack was completely empty - after i changed the debugger type from managed to mixed (managed and native). I got a lot more, namely this exception a 1 second into the app’s startup:
Exception thrown at 0x776C5B68 in Football.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x0628E9E0. HRESULT:0x80131534 The text associated with this error code could not be found.
WinRT information: System.TypeInitializationException: The type initializer for ‘WinRTBridge.WinRTBridge’ threw an exception. —> System.TypeInitializationException: The type initializer for ‘WinRTBridge.TypeInformation’ threw an exception. —> System.TypeLoadException: Derived method ‘EditNote’ in type ‘EdgeUI.UICreateDrillMenuStateFTBL’ from assembly ‘Assembly-CSharp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null’ cannot reduce access.
at UnityEngineInternal.BootstrapHelpers.FillTypeMaps0(Dictionary2 , List1
Stack trace:
[External Code]
If there is a handler for this exception, the program may be safely continued.
I looked into the method the exception referenced (EdgeUI.UICreateDrillMenuStateFTBL.EditNote()). The error looked like an public/private type error with inheritance, but i didn’t see what it could be since the referenced method and its base method are both protected.
This is most definitely a bug in Unity. Could you submit a bug report? I believe this will also happen if you strip all the assets from the project except scripts and DLLs - that would reduce your upload size significantly. We’d look into it asap.
I was able to isolate the bug and create a test project. One of my coworkers pointed out that the class referenced in the exception is a generic class and that seems to be the issue. (details at the end of the post)
I’ve uploaded a test project that recreates the bug. (additionally - i haven’t received any confirmation emails on the last couple bugs i’ve uploaded - you guys are getting them, right?)
Details on the bug:
If i have a generic class (parentscript) that is extended by a second class (childscript) and that second class (childscript) overrides one of the base class’s methods (parentscript’s methods). Building this for windows 8.1 will cause the app to have a black screen on startup or to throw an exception at startup if native (or mixed) debugging is enabled.
To see this for yourself - drag these 2 attached scripts into a project and add childscript to any gameobject in the scene. Then build the app for windows 8.1 - in the visual studio project make sure to change the debugger to “native” or “mixed” from “managed” then deploy the project.
