On Monday, September 2, version 4.0.19 of my first HoloLens Store app, AMS HoloATC, became available in the Microsoft Store. This version has been completely rebuilt using the Mixed Reality Toolkit 2, and includes some HoloLens 2-only functionality: you can actually touch the airplanes now, and using gaze tracking, it will show you a picture of the actual aircraft, if available.
You may also like: Fantastic Buttons and Where to Find Them — in the MR Toolkit
Hoops to Jump
As you might recall from earlier posts, things have changed quite a bit when it comes to actually deploying apps on HoloLens. Now, we will need compiling and submitting a Unity-generated C++ solution to the store. Although the process looks very much like we used to do for Unity apps running on the .NET backend, there are three things you might run into:
- Your WACK test will most likely fail
- If you have submitted your app as a bundle before, make sure you submit it as a bundle again. A Unity generated C++ solution does not have this as a default setting
- If you create (like me) an app that is supposed to run on Desktop (in immersive headsets), HoloLens 1 and HoloLens 2 you may find out your app cannot be downloaded by a HoloLens 1 anymore — or the HoloLens 2 emulator, for what matters
Fixing the WACK Fail
Before you actually submit an app to the Store, you do the Windows Application Certification test first to prevent embarrassing easy-to-prevent fails, right. (Right?). And if you do so, you will see it fail. It will spout quite some errors at you.
- The Windows security features test will complain about:
HolographicAppRemoting.dllhas failed the
PerceptionDevice.dllhas failed the
UnityRemotingWMR.dllhas failed the
- The Supported API test will list 10 errors concerning
UnityRemotingWMRcalling unsupported APIs
- The Debug configuration test will tell you Unity RemotingWMR is only built-in debug mode
- And if you try to build for x86 or ARM, the Package sanity test will tell you
UnityRemotingWMR.dllare only available for x64.
The solution is a bit weird but can be found in this Unity forum post and involves manually hacking the “Unity Data.vcxitems” file that is inside your store projects. Open in it in a text editor, and search for “
HolographicAppRemoting“. This will show this piece of XML:
<None Include="$(MSBuildThisFileDirectory)HolographicAppRemoting.dll"> <DeploymentContent>true</DeploymentContent> <ExcludeFromResourceIndex>true</ExcludeFromResourceIndex> </None>
Now, simply change the value “true” inside the
DeploymentContent to “false”:
Repeat this for
UnityRemotingWMR. Rebuild your app, generated packages again, and presto: your WACK test will pass. That is literally all that’s needed to get rid of this multitude of errors.
Bundling Your App
I don’t know exactly what changed, but all my HoloLens apps that I created with previous Unity versions were uploaded as bundles. To be honest, I never did pay much attention to it. But the default setting of the generated C++ setting is this:
This generates an appx per platform (in my case three: one for x64, one for x86 and one for ARM for, in the same order, WMR immersive headsets, HoloLens 1 and HoloLens 2). If you try to upload those files as updates to an app that was previously submitted as a bundle, you will be greeted with:
And this can simply be fixed by changing the setting “Generate app bundle” from “If needed” to “Always:”
Make Your App (Still) Downloadable for HoloLens 1
To be honest, 4.0.19 was not the first HoloLens 2 enabled version I submitted. That was 4.0.17. It got certified — as one of the first if not the very first indie HoloLens 2 app. I was very happy about this — for about 25 seconds. And then I got a very unpleasant surprise: I could not download it anymore on a HoloLens 1. Sure enough, you could find it in the store, but the “Install” button was greyed out (well, light blue in stead of dark blue, but in any case un-operational). Curiously enough, a HoloLens that had it already installed did get the updated version though.
The reason for this behavior can be found down in this post in the Unity forums. Basically, Unity dropped support for anything lower than DirectX 10, and this is listed now in the app’s store manifest. Unfortunately, when the Store on the HoloLens 1 (and the HoloLens 2 emulator, incidentally) checks for DirectX 10, the device apparently reports “don’t have that” and the Store consequently blocks download.
Now, I think this will be fixed shortly, but in the meantime, here’s a workaround for if you need do to a submission right now:
First, open the Package.AppManifest.xml file in a text editor. Find these lines:
<TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.16299.0" MaxVersionTested="10.0.18362.0" /> <TargetDeviceFamily Name="Windows.Holographic" MinVersion="10.0.16299.0" MaxVersionTested="10.0.18362.0" /
Comment out the second line. Then proceed to build a bundle, but for x64 only.
Go back to Package.AppManifest.xml, uncomment the first line, and re-activate the second. Now, find the StoreManifest.xml file — open it in a text editor. It should look like this:
<?xml version="1.0" encoding="utf-8"?> <StoreManifest xmlns="http://schemas.microsoft.com/appx/2015/StoreManifest"> <Dependencies> <DirectXDependency Name="D3D11_HWFL_10_0" /> </Dependencies> </StoreManifest>
Simply remove the line <DirectXDependency Name=”D3D11_HWFL_10_0″ />.
Now, build a package for x86 and ARM. I am not sure if this is essential, but I made sure the x86/ARM bundle was had a one release number one point higher than the x64.
Now, proceed to upload both bundles into submission and set checkboxes as needed. In my store submissions, it looks like this:
Now, as you can see, version 4.0.17 still contains all platforms, but that is not necessary. But because the 4.0.19 has a higher version number, it will be offered first to HoloLens 1 and 2.
Anyway, now your app, once certified, should be downloadable for all devices. On x64, the DirectX 10 check will be still in place; for other devices, it’s disabled.
It’s early days for HoloLens 2 (I built my app without having direct access to it) but I think it’s pretty cool to have an app armed and ready for it. It takes some fiddling around with XML files to get it right, but I am sure things will be better soon and these workarounds won’t be necessary anymore.
Enjoy building the next generation Mixed Reality apps!