Testing if your Desktop Bridge app is ready for distribution 

If you have read some of the posts that have been published on this blog about the Desktop Bridge, you’ll know that it’s an extremely powerful technology and, in most of the cases, you can get all the benefits of the new modern and deployment system provided by the app package model without having to do any code change in your existing desktop app.

However, there are still some scenarios that aren’t supported by the Desktop Bridge, because they go against the the goals of this technology, which are making desktop application safer to use for the user, cleaner to install / uninstall / update, etc. All the requirements that a desktop app must satisfy to be converted are reported in the following page of the documentation: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare However, let’s recap the most important ones.

Your application must run in user mode

An application acquired from the Store must always run in user mode, in order to allow every user to take advantage of it, even if they aren’t administrators of the app. Consequently, your desktop app can’t require elevation, neither at startup, neither during the regular usage, otherwise you will get an exception.

Your application requires a kernel driver or a Windows service

Like the usage of the app, also the installation process of an app package can’t require any special administrator privilege to the user. As such, if your desktop app requires a kernel driver or a Windows service to properly run, it must be installed upfront, but it can’t be deployed together with all the other files during the app package installation.

Your application or installer tries to modify registry keys which are part of the HKEY_LOCAL_MACHINE registry hive

This hive requires administrator rights to be accessed and, as such, an application or the app package deployment procedure can’t write registry keys in this area. If you need to perform this operation to add extensibility features to your app (like integrating with File Explorer context menus or associating a set of file extensions), you can leverage the special manifest extensions which are reserved to Desktop Bridge apps.

Your application writes data in the installation folder

We already covered this requirement in a specific blog post, where you’ll find all the details and alternative approaches. Long story short: since converted apps are installed inside an admin protected folder, you can only read data included in your installation folder, but you can’t write any file or folder, you need to leverage other techniques like using the AppData folder or the user libraries to do it.

Checking if the app is ready to be submitted

Many developers I have worked with, especially now that we have an easier way to generate app packages thanks to the WinJS project, are complaining or thinking that their converted desktop app, despite they have followed all the guidelines to perform a proper conversion, aren’t ready for the Store. The reason is that, after you have generated an app package using the Visual Studio wizard, the tool will offer you to run the WACK (Windows App Certification Kit), which is a kit that performs a set of automated tests that will check if your application is compliant with the Store.

In fact, all the technical tests that are listed are the same performed by the Dev Center during the submission process: as such, if your application passes all these tests, there’s a really good chance that your app will pass the certification without problems, unless you are violating any Store policy which isn’t related to the technical aspect (like using a third party monetization system or including pornography or too violent content or images).

However, the current version of the WACK doesn’t support converted apps through the Desktop Bridge, so your converted app will always fail the WACK test. The WACK is meant to test native Store apps (like UWP apps), so the report you will get will contain all sort of errors, from the fact that you’re using a restricted capability (runFullTrust) to the usage of native Windows DLLs which aren’t supported by the Universal Windows Platform. This is absolutely normal and, if it happens, it doesn’t mean that your app isn’t ready for prime time.

However, there’s a good news: as mentioned in a recent blog post which announced all the new Desktop Bridge related feature that are upcoming with the Windows 10 Creators Update, the new SDK that will be released for the new Windows 10 version will include a new version for the WACK that, instead, properly supports the Desktop Bridge and, if it will recognize that the tested app isn’t a pure Store app but a converted app, it will perform a specific set of tests, that will check if it’s compliant with the requirements we have mentioned at the beginning of this post.

What if I want to test my application now?

If you regularly follow this blog, you’ll probably know the answer: the last update of the Desktop App Converter (version 1.0.9.0) supports a new –Verify flag, which will run a set of specific Desktop Bridge tests (the same that will be executed by the WACK version that will be included in the Creators Update’s SDK) and it will generate a report that will tell you if your app is compliant or not. I won’t dig further to explain how to read this report, since I already explained it in the already mentioned blog post dedicated to the new release of the Desktop App Converter.

Wrapping up

If you want to make sure your app is ready to be released to the public (no matter if it’s the Store or inside an enterprise environment), you can leverage at the moment the new –Verify option that has been added in Desktop App Converter 1.0.9.0. However, things will change soon because the new Windows 10 SDK that will be released together with the Creators Update will contain an updated version of the WACK tool that will be able to properly identify a Desktop Bridge app and run the same set of tests. As such, for the moment, remember to not run the current WACK tool that is part of the Anniversary Update SDK (14393.795 is the latest version) on a Desktop Bridge app, because you will get all sort of errors which, however, are normal.

And if your goal is to submit your app on the Store and you have nominated it, don’t worry because you will have a second check in place: the AppConsult engineer that will work with you to test your app and to give you the required permissions to publish a converted app will perform the same checks on your behalf, so you’ll be the first to know if something isn’t working as expected.

Happy conversion!