HoloLens .APPX Built with 2018.4.3f1 Fails Store Submission?

If I take Unity 2018.4.3f1 and do the following;

  • New 3D Project
  • Change the Build Settings to specify Device of HoloLens, x86, D3D build, Target SDK 18362, Min SDK 10240, Build Configuration: Release
  • Switch platform to UWP
  • Change the XR Settings to “Virtual Reality Supported” which (on my system) brings in the “Windows Mixed Reality SDK” from package “Windows Mixed Reality 1.0.12”
  • Build the UWP project
  • Make an APPX for Store Submission from the generated C++ Project, requesting to include the pieces for the Master configuration for x86 only.

And then I find that if I run the “Windows Application Certification Kit” (WACK) or submit the .APPX to the Windows Store then I seem to get a report which fails the .APPX in both the;

  • “Supported API Test”
  • “Package Sanity Test”

sections and this looks to be because of the presence of 3 64-bit DLLs;

  • HolographicAppRemoting.dll
  • PerceptionDevice.dll
  • UnityRemotingWMR.dll

I can see these 3 DLLs in my UWP folder and they all appear to be 64-bit DLLs (from dumpbin) but I’m not sure why they are there as I do not have holographic remoting switched on (as far as I know!).

I also see these 3 DLLs listed in the file Unity Data.vcxitems with each one set to have a DeploymentContent value of true.

I find that if I toggle that value to false for each of the 3 DLLs and then remake my APPX then it passes the WACK test.

Is this a bug in 2018.4.3f1 or the WMR package 1.0.12 or am I just not setting a switch somewhere?

1 Like

I have the same problem.
It is very weird, because I made downgrade to version UNITY and WMR SDK that published windows store my last app. However, Now appears fail in the submission
The version was UNITY 2018.3.12f1 and Mixed Reality Toolkit 2.0.0-Beta2.
Please, somebody help us!!

Man, “Windows Mixed Reality 1.0.8” with UNITY 2018.3.12f1 , it works!!

Can you file a new bug on this please, we will take a look. We have had a bit of churn recently in the holographic DLL’s

@JasonCostanza Is there any update on the status of this issue? It's very annoying having to manually edit the Unity Data.vcxitems after every build. Currently using 2018.4.8

@delphinius81 Yes that sounds incredibly obnoxious. I will look into this soon as I can and update here with some info. If you want, file a new bug and post the number here that way we all have a common tracking item and you can follow the progress in public issue tracker :slight_smile:

Joining in with 2018.4.12f1 and MRTK mrtk_development branch (from today), but our project is a little too big to create a repo.

Ran into this yesterday as well.

The fix is obnoxious, and requires modifying config files generated by unity

Check if you’re running the latest 18.4 editor and also the most updated Windows Mixed Reality package. I just ran a test using latest 18.4 and package and did not fail my WACK test for remoting DLLs.

Which pacakge version are you guys running when seeing failures?

What is the “Windows Mixed Reality package”? Package for Unity, VS, Windows itself?

What is the "Windows Mixed Reality package"? Package for Unity, VS, Windows itself?

Unity package. Under Window menu > Package Manager.


Ahaaaa… did not even know that existed. Since I actually have to update, I’m just assuming that it’ll work, for now :wink:

I have the latest package, which is what updates the remoting DLLs.

That said I do not have the latest 2018.4, as there is a grave serialization bug that breaks my workflow.

I’ll try updating anyway to see if I pass the certification.

Concerning the bug, the original issue states it not happening with 2018.4.8f1. We are on 2018.4.12f1, so it should be save to upgrade to that version.