Hundreds of errors submitting Electron Windows 10 desktop app to Microsoft Store


#1

Has anybody tried to submit Electron Windows 10 desktop apps to the Microsoft Store but received 100’s of errors from their WACK certification tool e.g. dependent library errors like these?

Windows security features test

FAILED
Binary analyzer
Error Found: The binary analyzer test detected the following errors:
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\d3dcompiler_47.dll has failed the AppContainerCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\ffmpeg.dll has failed the AppContainerCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\libEGL.dll has failed the AppContainerCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\libGLESv2.dll has failed the AppContainerCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\node.dll has failed the AppContainerCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\website.exe has failed the AppContainerCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\xinput1_3.dll has failed the AppContainerCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\xinput1_3.dll has failed the DBCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\xinput1_3.dll has failed the ExecutableImportsCheck check.
File c:\program files\windowsapps\test.website_1.0.1.0_x86__gx9h620p3afrm\app\xinput1_3.dll has failed the NXCheck check.
Impact if not fixed: If the app doesn’t use the available Windows protections, it can increase the vulnerability of the customer’s computer to malware.
How to fix: Apply the required linker options - SAFESEH, DYNAMICBASE, NXCOMPAT, and APPCONTAINER - when you link the app. See links below for more information:
Fixing Binary Analyzer Errors

Supported API test

FAILED
Supported APIs
Error Found: The supported APIs test detected the following errors:
API SystemFunction036 in advapi32.dll is not supported for this application type. libEGL.dll calls this API.
API CreateFileW in kernel32.dll is not supported for this application type. libEGL.dll calls this API.
API ExitProcess in kernel32.dll is not supported for this application type. libEGL.dll calls this API.
API FreeEnvironmentStringsW in kernel32.dll is not supported for this application type. libEGL.dll calls this API.
API GetACP in kernel32.dll is not supported for this application type. libEGL.dll calls this API.
API GetConsoleCP in kernel32.dll is not supported for this application type. libEGL.dll calls this API.
API GetConsoleMode in kernel32.dll is not supported for this application type. libEGL.dll calls this API.

[snip]

API SetStdHandle in kernel32.dll is not supported for this application type. xinput1_3.dll calls this API.
API UnhandledExceptionFilter in kernel32.dll is not supported for this application type. xinput1_3.dll calls this API.
API VirtualAlloc in kernel32.dll is not supported for this application type. xinput1_3.dll calls this API.
API VirtualProtect in kernel32.dll is not supported for this application type. xinput1_3.dll calls this API.
API SetupDiDestroyDeviceInfoList in setupapi.dll is not supported for this application type. xinput1_3.dll calls this API.
API SetupDiEnumDeviceInterfaces in setupapi.dll is not supported for this application type. xinput1_3.dll calls this API.
API SetupDiGetClassDevsW in setupapi.dll is not supported for this application type. xinput1_3.dll calls this API.
API SetupDiGetDeviceInterfaceDetailW in setupapi.dll is not supported for this application type. xinput1_3.dll calls this API.
API RtlUnwind in ntdll.dll is not supported for this application type. xinput1_3.dll calls this API.
Impact if not fixed: Using an API that is not part of the Windows SDK for Windows Store apps violates the Windows Store certification requirements.
How to fix: Review the error messages to identify the API that is not part of the Windows SDK for Windows Store apps. Please note, apps that are built in a debug configuration or without .NET Native enabled (where applicable) can fail this test as these environments may pull in unsupported APIs. Retest your app in a release configuration, and with .NET Native enabled if applicable. See the link below for more information:
Alternatives to Windows APIs in Windows Store apps.


#2

Did you follow the guide
http://electron.atom.io/docs/tutorial/windows-store-guide/ ?


#3

Yes. We are using Node v5.11.1 but I think that should work.

The local sideload works perfectly, it’s only the WACK analysis that has these errors and the Window Store submission that get’s stuck right at the beginning in the pre-processing stage (I think WACK is rerun in the store submission so might all be the same issue).

I’m guessing the biggest issue is the second group of errors listing 1137 unsupported API calls. There is a WACK helper link that takes you to various pages describing how to port these API’s to the UWP API’s instead (https://msdn.microsoft.com/library/windows/apps/hh464945.aspx) but I’m not sure this is a reasonable option (at least a significant task) so it looks like I’ve missed something.

I think DesktopAppConverter is one way that electron-windows-store can process these unsupported API calls but DesktopAppConverter seems to require an installer (and there is no installer yet since this is still just a simple Electron wrap of a website).

To generate the AppX file, we just run electron-packager.cmd and then electron-windows-store…


#4

Here are some updates:

(1) DesktopAppConverter is not a solution for unsupported API’s.

(2) The unsupported API calls do not occur if Microsoft’s Node.js is used with the Chakra JavaScript engine. This is also UWP compliant which is required for a Windows Store submission. One workaround we found was to build this with Visual Studio 2015 Update 3 with the Chakra UWP extension i.e. not Electron. This workaround essentially replaces the Chromium libraries with those from Edge. So a question is can we use Electron to build in this Windows use case e.g. is it possible to configure the Electron build with different libraries on a per platform basis? Perhaps there are also other considerations I’ve missed?


#5

I used to work at Microsoft (and during that time I built this thing). Additional verification steps are more to ensure developers are committed and validated. Win32 applications (and all electronic applications) have full access to the system, which means that the usual Apex boundaries do not exist. 70-334 VCE

You can not create a wp / apx package that works c: format, but you can do it completely from the electron application, so the extra steps are there. Entry program should not be too difficult, however, Microsoft usually <3 developers. Microsoft 70-462 VCE