First published on MSDN on Aug 16, 2017
As you may already know, in order to publish a Desktop application to the Store the application must be in accordance with the policies of the Store. A great way to start this validation is through the Windows App Certification Kit (WACK) that is part of Windows SDK 10 .
If you never heard about the WACK tool please read the following post about how to install and use this great tool.
Starting after the official launch of Windows 10 S, now if you want to publish a Desktop Application packaged using Window Desktop Bridge to the Store your application must also be compliance with the new rules in order to be compatible with Windows 10 S.
To get more information about the Windows 10 S polices and how you can test if your application is compliant in Windows 10 S, please read the following article:
The purpose of this post is to update you about the new features available in the last version of WACK (10.0.15063.468). It is important to notice that, if you have installed the Windows 10 Creators Update SDK using the Visual Studio 2017 installer when it was released a few months ago, it does not get automatically updated, but you need to manually download and install it from https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk if you want to get version 15063.468.
The first new feature is the Package sanity test , that provides a set of tests for Desktop Bridge apps specific for Windows 10 S.
Here is an example of the output included in the Windows 10 S tests:
PASSED
FAILED
In this example, the WACK identified some violations related to launch a process or calling blocked executables. Observe that it is possible to have false positive, that is why is important to double-check the violations reported in this session.
Launching executable files is restricted on Windows 10 S systems. Apps that rely on this capability might not run correctly on Windows 10 S systems. The most common way to launch a process is through the usage of Process.Start or the native APIs like CreateProcessA , CreateProcessW or ShellExecuteW , which isn’t prohibited itself, as long as the process that is invoked is part of the same app package.
Launching a process starts to become a problem if it’s used to invoke external processes. It is important to notice that the usage of Process.Start() is not always prohibited on Window 10 S.
Example from the field:
In this case, using a debugger (WinDbg), it was possible to identify that the first violation is a false positive, as the ShellExecuteW was trying to open a website.
How to fix if it was a positive violation: Identify which of the flagged entries represent a call to launch an executable file that is not part of your app and remove those calls. If the flagged files are part of your application, you may ignore the warning.
To more details about launching processes which are part of the same package, please read this great article that talks about how the same app package can contain multiple executables and you can launch them using Process.Start():
https://blogs.msdn.microsoft.com/appconsult/2016/11/28/desktop-bridge-multiple-desktop-processes-a-single-uwp-container/
The Windows 10 S policies don’t allow to execute external processes even if the process is a Microsoft process like CMD.EXE, REG.EXE or REGEDIT.EXE.
Example from the field:
This violation is a false positive, and in this example, it was easy to identify that where it was only necessary to open the file and search for the REG word. In this case, the WACK identified the ® ; escape code used to represent the Copyright symbol as a potential problem.
The REG word was found in the following paragraph of the en.json file:
Another good update is that the latest WACK has fixed also the 1px offset bug.
In case some of you never saw that, from time to time WACK was reporting perfectly valid asset images (generated by the Visual Studio 2017 manifest editor) as incorrect due a wrong size for an offset of 1 pixel (example: the requested image size is 160x160, but WACK says that the provided image is 159x159, which was false).
FAILED App resources
I hope you liked this post.
As you may already know, in order to publish a Desktop application to the Store the application must be in accordance with the policies of the Store. A great way to start this validation is through the Windows App Certification Kit (WACK) that is part of Windows SDK 10 .
If you never heard about the WACK tool please read the following post about how to install and use this great tool.
Use WACK on Creators Update to check if your Desktop Bridge app is ready for distribution
Starting after the official launch of Windows 10 S, now if you want to publish a Desktop Application packaged using Window Desktop Bridge to the Store your application must also be compliance with the new rules in order to be compatible with Windows 10 S.
To get more information about the Windows 10 S polices and how you can test if your application is compliant in Windows 10 S, please read the following article:
Porting and testing your classic desktop applications on Windows 10 S with the Desktop Bridge .
The purpose of this post is to update you about the new features available in the last version of WACK (10.0.15063.468). It is important to notice that, if you have installed the Windows 10 Creators Update SDK using the Visual Studio 2017 installer when it was released a few months ago, it does not get automatically updated, but you need to manually download and install it from https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk if you want to get version 15063.468.
WACK New Feature: Windows 10 S Certification
The first new feature is the Package sanity test , that provides a set of tests for Desktop Bridge apps specific for Windows 10 S.
Here is an example of the output included in the Windows 10 S tests:
PASSED
Archive files usage
FAILED
Blocked executables
No additional information for Requirement: 25 Test: 88
File XXXX.dll contains a reference to a "Launch Process" related API System.Diagnostics.Process.Start.
File XXXX.dll contains a reference to a "Launch Process" related API System.Diagnostics.Process.Start.
File XXXX.dll contains a blocked executable reference to "REG".
In this example, the WACK identified some violations related to launch a process or calling blocked executables. Observe that it is possible to have false positive, that is why is important to double-check the violations reported in this session.
Let me provide two real examples from the field about potential false positive.
Launch Process Violation
Launching executable files is restricted on Windows 10 S systems. Apps that rely on this capability might not run correctly on Windows 10 S systems. The most common way to launch a process is through the usage of Process.Start or the native APIs like CreateProcessA , CreateProcessW or ShellExecuteW , which isn’t prohibited itself, as long as the process that is invoked is part of the same app package.
Launching a process starts to become a problem if it’s used to invoke external processes. It is important to notice that the usage of Process.Start() is not always prohibited on Window 10 S.
Example from the field:
File C:\Program Files\WindowsApps\XXXX.exe contains a reference to a "Launch Process" related API shell32.dll!ShellExecuteW
In this case, using a debugger (WinDbg), it was possible to identify that the first violation is a false positive, as the ShellExecuteW was trying to open a website.
# Call Stack
SHELL32!ShellExecuteW
0:000> dv /t /v
@rcx struct HWND__ * hwnd = 0x00000000`00000000
@rdx wchar_t * lpOp = 0x00007ff6`6c049018 "open"
@r8 wchar_t * lpFile = 0x0000022f`179a86c0 "http://www.bing.com"
@r9 wchar_t * lpArgs = 0x00000000`00000000 ""
00000060`08f1ae80 wchar_t * lpDir = 0x00007ff6`6c048efc "."
00000060`08f1ae88 int nShowCmd = 0n1
<unavailable> unsigned long fMask = <value unavailable>
00000060`08f1ae78 struct _SHELLEXECUTEINFOW sei = struct _SHELLEXECUTEINFOW
How to fix if it was a positive violation: Identify which of the flagged entries represent a call to launch an executable file that is not part of your app and remove those calls. If the flagged files are part of your application, you may ignore the warning.
To more details about launching processes which are part of the same package, please read this great article that talks about how the same app package can contain multiple executables and you can launch them using Process.Start():
https://blogs.msdn.microsoft.com/appconsult/2016/11/28/desktop-bridge-multiple-desktop-processes-a-single-uwp-container/
Blocked Executable
The Windows 10 S policies don’t allow to execute external processes even if the process is a Microsoft process like CMD.EXE, REG.EXE or REGEDIT.EXE.
Example from the field:
File en.json contains a blocked executable reference to "reg".
This violation is a false positive, and in this example, it was easy to identify that where it was only necessary to open the file and search for the REG word. In this case, the WACK identified the ® ; escape code used to represent the Copyright symbol as a potential problem.
The REG word was found in the following paragraph of the en.json file:
"My ApplicationBrand® Certified": "AppBrand® Certified"
WACK New Feature: Fixed the Assets Dimensions Bug
Another good update is that the latest WACK has fixed also the 1px offset bug.
In case some of you never saw that, from time to time WACK was reporting perfectly valid asset images (generated by the Visual Studio 2017 manifest editor) as incorrect due a wrong size for an offset of 1 pixel (example: the requested image size is 160x160, but WACK says that the provided image is 159x159, which was false).
App manifest resources tests
FAILED App resources
-
Error Found : The app resources validation test detected the following errors:
- Image reference "images\storelogo.png": The image "C:\WINDOWS\temp\appcert_XXXX\APPID\images\storelogo.scale-125.png" failed the size restrictions of 62 X 62.
- Image reference "images\Square150x150Logo.png": The image "C:\WINDOWS\temp\appcert_XXXX\APPID\images\Square150x150Logo.scale-125.png" failed the size restrictions of 187 X 187.
- Image reference "images\Wide310x150Logo.png": The image "C:\WINDOWS\temp\appcert_XXXX\APPID\images\Wide310x150Logo.scale-125.png" failed the size restrictions of 387 X 187.
-
Impact if not fixed: The app might not install if the strings or images declared in your app's manifest are incorrect. If the app does install with these errors, your app's logo or other images used by your app might not display correctly.
-
How to fix: Fix the problem indicated by the error message. See the link below for more information:
AppX Resource Validation
I hope you liked this post.
Updated Nov 22, 2022
Version 5.0
luisdem
Microsoft
Microsoft