C++ Windows Store app validation fails

If  you’ve recently run the Windows App Cert Kit for your C++ Windows Store app, you might have encountered these or similar failures of the Supported API test:

You’ve ensured you’re not building in Debug mode. The error persists. And you could swear, a few days ago, everything was fine.

Clearly, msvc dlls are not the type of code you would have written yourself. So what to do about this?

Luckily, the friendly folks over at the MSDN forums have isolated the issue, verifying that it can (temporarily) be resolved by uninstalling the recent Windows update KB2976978. This is the officially recommended workaround by Microsoft for the time being, as well.

Note that the above errors won’t cause your app to fail submission.

I’ll update this post as soon as there’s anything new!

Unity3D Windows Store – Part 2: Windows App Cert Kit

In the first part of this series, we’ve talked about how to build and run a Unity3D game targeting the Windows Store platform. We succeeded in building the Unity player, building the resulting Visual Studio solution for the Windows Store game, and running the app on our local machine along with all of our fancy Unity plugins.

Today, we’ll take a look at the limitations of .NET for Windows Store apps and how to pass the Windows App Cert Kit tests with our game.

Supported APIs Test

The Windows App Cert Kit (WACK) has been shipped by Microsoft to enable you to run all of the tests on your app that you are required to pass for being listed in the Windows Store. The kit can be launched for your app right after you’ve ever run it from Visual Studio on your local machine.

The most usual, annoying and complex issues we’ll be facing are the supported API tests. Microsoft prohibits calling certain APIs from your game in order to increase general security and stability of all apps in the store. Most of the violating calls are related to File I/O and reflection.

File I/O

File I/O issues can be solved by defining a new compilation symbol and adapting your project and solution configurations (see part 1). We’ve defined a new symbol windows_store and wrapped all I/O-related code, which was part of our framework but used for Unity editor extensions only, anyway.

Reflection

The more complicated issues are related to reflection. In the Slash Games Framework, we’re following a heavily data-driven approach for configuring and running our games: Almost all entity data, such as hitpoints, damage or speed, is stored in XML files. Whenever a game entity is created, we’re instantiating and attaching the required components (i.e. HealthComponent, AttackComponent) via reflection. Thus, just replacing or wrapping all reflection code with ifdefs clearly wasn’t an option.

Luckily, our reflection code entirely resides in a dedicated library called Slash.Reflection.dll. The few classes of this library were the only ones that we needed to modify. Our most difficult problem was how to access all loaded types in our Windows Store app. As there’s no AppDomain for this target platform, AppDomain.CurrentDomain.GetAssemblies isn’t available, and thus there’s no framework method that allows reflecting all loaded types. However, we’re not the first ones facing that problem, and there’s an acceptable workaround that has been posted on Stack Overflow.

We created a convenience method GetLoadedTypes and provided two  implementations for the different target platforms. As the approach for Windows Store apps requires you to reference other libraries (i.e. .NETCore, Windows), we were forced to create a new project Slash.Reflection.WindowsStore and put our new reflection code in that project. Giving both libraries compiled from Slash.Reflection and Slash.Reflection.WindowsStore the same name, Unity automatically picks the right one for your target platform. This will come in handy later, when we’re implementing Windows Store-specific features such as the snap view or suspending the app.

Performance Test

Then, the performance test was the last one to fail:

Performance launch: The Native Image Generator failed

The Windows App Certification Kit generates native images for all the managed assemblies of your app package. There’s a manual out around at the Microsoft support pages, helping you to identify the file that’s failing, getting information about the failure and how to pass the test.

In our case, the combination of package name, executable file name, and user name was too long: The generator stores the native images in a user directory, which has a long path name because of the fixed parts that it includes. As all of our package and executable names were already very short (i.e. Slash.Reflection), we opted out of automatic native image generation by  including a file named nongen.txt in our app package at the cost of a minor performance hit in our game.

Exporting the App Package

Now that our game was passing all tests, we exported the app package just as explained on the official Unity website. More detailed information about the process of deploying Windows Store apps can be found at the MSDN, but for now, the steps provided by the Unity documentation were enough.

If you aren’t running a Windows 8 build server, you can easily put the exported package in your SkyDrive, access it on your ARM device and install the game by running the Powershell script Add-AppDevPackage.ps1.

Microsoft recommends running WACK  on your device as well, in order to check whether you pass required maximum load times, for example. The Windows App Certification Kit for Windows RT is available at the official MSDN website. Running the kit for our game on the mobile device immediately passed all tests.

In the last part of this series, we’ll talk about how to include Windows Store-specific features, such as live tiles, contracts or toast notifications in our Unity game.

As usual, feel free to share your thoughts or ask any questions in the comments below!

Next: Unity3D Windows Store – Part 3: Reflections