If you regularly follow this blog, after reading the title of the post you may be thinking “Matteo is crazy, he has just published a post saying to not use WACK to test your Desktop Bridge apps and now he’s telling me to do the opposite?”. Well, in this case you haven’t read the post carefully If you remember, one of the key messages of the post was to not use the Windows App Certification Kit (WACK, from now on) included in the Windows 10 Anniversary Update SDK (14393), because it doesn’t support desktop apps converted with the Desktop Bridge, but only traditional Store apps, like the ones developed with the Universal Windows Platform. As such, if you would have tried to launch the tool, choose Validate Store app and you would have selected from the list a desktop app converted with the Bridge, you would have received multiple errors, because a desktop app does all sort of things that aren’t supported by a Universal Windows Platform app (like accessing to native Windows APIs, performing operations outside the sandbox, accessing to the system registry, etc.). However, in the same post I had also mentioned that WACK support for converted apps was coming with the Creators Update. Since now Windows 10 Creators Update is officially out (the rollout has started on 11th April, you can refer to the following blog post if you want to know how to get it immediately if you haven’t received it yet) and Visual Studio 2017 has been officially updated to include the Windows 10 Creators Update SDK (15063), now you can start using WACK to test if your converted app is compliant and ready for distribution.
Using the tool is very easy. Once you are sure that you have updated your machine with all the latest and greatest goodies from Microsoft (so you’re running Windows 10 Creators Update with Visual Studio 2017 and the Windows 10 15063 SDK), open the Start menu and start typing Windows App Cert Kit: in the screenshot below you can see the tool you should find and launch.
To make sure you have updated all the development tools on your machine and you’re using the right version, you can check the build number you will see at the top bar of the tool:
As you can see from the above image, you have to make sure that the build number of the Windows App Certification Kit is 10.0.15063.xxx (xxx is the minor build number but it isn’t important for our scenario, the only thing we need to care about is that the major build number should be 15063 and not 14393).
Once you have chosen the Validate Store App option, you will have two possibilities:
No matter which is the approach, you’re going to use, you will be presented with the set of tests that will be executed. You can immediately identify that the WACK is now able to properly recognize an app converted with the Desktop Bridge, because it will propose a set of tests different than the ones that are performed on full Universal Windows Platform apps. The below image shows, on the left, the tests that are executed on a Desktop Bridge app; on the right, instead, the ones that are proposed on a regular UWP app.
Once you press the Next button, the WACK will behave like the usual one that you may have already used against regular UWP apps. It will start to perform a set of tests and, out of the box, at the end of the process you’ll immediately know if your app has passed them or not.
The WACK will prompt you also to save a XML file on your hard disk, which is the one that will be opened when you click on the Click here to view the results link. The file is a detailed report of all the tests that have been performed and, in case of failures, it will explain in details what went wrong. For example, the following excerpt is coming from the report of an application that failed the App manifest resources tests :
In this specific case, the failure reason is that the manifest of the app is declaring, as visual assets, a set of images that don’t respect the required resolutions.
The XML produced by the WACK will give you an overall result, which will be displayed at the top of the report and it will tell you immediately if your app is compliant.
The WACK does a good job also in splitting the tests into two categories: the first ones under the overall result, in fact, are to be considered required . If any of them will result in a failure, your app isn’t compliant and you need to fix the reported issue before releasing your app (either on the Store or via an enterprise tool). At the end of the report, however, you will find also a section called Results for optional tests .
It’s recommended to do some investigations in order to make sure that you haven’t forgotten to do something in the proper way (like compiling your app in Debug mode) but, when it comes to Store onboarding, they won’t be considered as blockers: the Dev Center will accept anyway these packages and they won’t fail the certification (unless, of course, the tester will find problems that can’t be automatically detected by the tool, like a Store policy violation). For example, in this category falls the test called “Digitally signed file test” , which we already mentioned when we talked about the new – Verify parameter of the Desktop App Converter in another post on this blog. Since an app submitted on the Store is automatically signed with a certificate from the Dev Center, it will be accepted even if any of the executables or DLLs included in the package isn’t digitally signed.
In this post we’ve seen how to leverage the new Windows App Certification Kit included in the Creators Update SDK to check if our Desktop Bridge application is ready to be released from a technical point of view. It’s a great help, because it performs the same set of tests executed by the Dev Center during the ingestion process. As such, if our application is WACK compliant, we have higher chances to see it passing the certification process with success, unless we have done something which isn’t compliant with the Store policies (like forgetting to remove the auto-update feature or using a 3rd party monetization system). Additionally, the huge advantage of the new WACK is that it can be used with any application, even the ones that we have already converted and installed on our computer for testing. Before Creators Update, the only way to get a similar report was to use the – Verify option of the Desktop App Converter which, however, worked only in combination with this tool. As such, if our app was converted using a different approach (like Visual Studio 2017 or a 3rd party tool), we couldn’t leverage it to know if our app was compliant or not.
Happy conversion and, if you have a desktop app you would like to publish on the Store, don’t forget to nominate it using the official form !
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.