由于不受支持 API FindFirstFileEx（WACK 在本地传递），UWP 应用程序提交失败
UWP app submission failure due to unsupported API FindFirstFileEx (WACK passes locally)
我有一个 UWP 项目作为我的 Xamarin.Forms 解决方案的一部分。当 运行 在本地 Windows App Cert Kit 时，它顺利通过。
将我的应用程序提交到商店时，认证过程失败并出现以下错误：
Error Found:
The supported APIs test detected the following errors:
API FindFirstFileEx in api-ms-win-core-file-l1-2-0.dll is not supported for this application type. PInvoke.Kernel32.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.
我已验证我的应用程序在发布模式下运行，并已验证我的 UWP 构建设置：
我尝试联系 Microsoft 的聊天支持，但被重定向到进入事件报告，然后我被重定向到只能在论坛上寻求帮助或支付高级技术支持费用，所以我无法获得关于这是否是有效故障的任何更多信息。
根据在 FindFirstFileEx (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364419(v=vs.85).aspx) 上找到的文档，Windows 桌面、商店应用和 Windows Phone 似乎支持它。我的UWP应用是提交来支持Desktop和Mobile family的，似乎包含在这个功能支持的客户端中，所以不清楚是什么原因导致失败。
关于从这里到哪里去的任何想法？
我遇到了同样的问题。已提交认证反馈报告，等待微软部分回复...
2017 年 8 月 14 日更新：此问题现在应该已在应用商店中得到解决。如果您遇到此问题，请尝试重新提交您的应用。
WACK 扫描在应用商店中 运行 的方式以及它与 .NET Native 集成的方式存在问题。
对于某些背景，Windows 实际上并没有名为 FindFirstFileEx 的 API - 它不存在。 WACK 支持的 API 扫描的工作方式是它会查看您调用的所有 API 并验证以下情况之一是否为真：
- 这是一个 API 由你的包中的另一个 DLL 导出的
- 这是一个 API 在允许列表中明确提到的
在 kernel32.dll!FindFirstFileEx 的情况下，WACK 发现 kernel32.dll 在您的包中不存在，因此它必须检查允许列表。允许列表未提及 FindFirstFileEx，因为它不存在。 存在的是：
C:\Program Files (x86)\Windows Kits\App Certification Kit>findstr FindFirstFileEx SupportedAPIs-x64.xml
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="kernel32.dll"/>
<API Name="FindFirstFileExW" ModuleName="kernel32.dll"/>
请注意 FindFirstFileExA 和 FindFirstFileExW 有一堆条目，它们是实际存在的 API。每当您的应用程序尝试调用 FindFirstFileEx 时，它实际上是在调用其中一个。
对于C/C++开发者来说，预处理器实际上是将FindFirstFileEx替换为A或W版本based on the existence of the UNICODE macro.
对于 .NET 开发人员，JIT 运行time（或者，在 .NET Native 的情况下，编译器）会根据以下情况确定是调用 A 还是 W 版本DllImport attribute 的细节，例如 CharSet 和 ExactSpelling 属性的值。
这就是问题所在 - 目前，商店中的 WACK 运行正在 .NET 程序集 之前 编译器替换了无后缀版本带有正确的后缀版本。当您在开发机器上 运行 WACK 时，它会在 编译器进行替换后正确检查程序集 ，因此您看不到任何错误。
修复的第一部分（正在进行中）是将无后缀版本添加到允许列表。修复的第二部分是确保在 post 编译位上 WACK 运行s。
我遇到了同样的问题。我按照 Peter Torr 的建议打开了一个聊天会话（从开发中心）。
摘要如下：
我： 我的应用更新卡住了，因为你的认证系统有问题。看这里：
支持：我们已经意识到这个问题，并且正在努力解决这个问题。对于给您带来的不便，我们深表歉意
我： 好的，我知道你正在处理这个错误。但与此同时，您可以让我的应用通过，对吗？
支持：我们有一个临时解决方法。如果您愿意，我可以为您获取该信息？
...几分钟后...
支持： 好的，我需要你做的是重新提交你的包裹，但在证书部分的注释中包含这个号码 XXXXXXXXXXX。如果这不起作用并且您的应用程序再次未通过认证，请提交有关最新的未通过认证报告的反馈，并再次在此处插入号码。我已在您的帐户中注明以反映这一点
（实数替换为XXXXXXXXXXX）
更新一: 和@jkh一样，自动认证又失败了。所以我在认证反馈中发布了这个数字。
更新 2：不幸的是，"solution" 没有帮助。我现在已经给聊天支持人员写了一封电子邮件（聊天后我得到了他的地址）。我不太相信这有帮助。但是让我们看看...
更新3：我也提交了一个事件。 （这可以在您通常开始聊天会话的地方完成，但请使用下面的按钮 "Submit incident"。）
更新 4：事件提交的答案：
感谢您联系开发人员支持。我了解到由于 Window Store Policy 15.1 API 错误导致认证失败。在进一步审查后，我想让您知道这是一个已知问题，目前工程师正在努力修复。应该很快就会推出修复程序，请稍候。如果修复程序在星期一之前没有实施，我可以进一步调查这个问题，但由于这是一个全球性问题，我建议等待修复程序推出。当我听到与修复有关的消息时，我一定会联系您并请您重试以获得认证。
更新5：我重新提交了我的更新，现在正在等待结果。
更新 6: 又失败了...
更新 7：事件提交的回复：这仍然是一个持续存在的问题，我们已将您的问题上报给我们的内部团队进行进一步调查以尝试绕过这个错误给你。一旦收到更新，我一定会与您联系。
更新8：最终，重新提交后，认证过程花了两天（！），但现在我的更新在商店里了。哇，好厉害啊...
在几周前向 Microsoft 开票后，我的帐户终于获得了豁免，使我能够通过自动认证。
请勿重新提交。我被告知重新提交并提供有关该解决方案的认证报告反馈。重投几次后，收到邮件回复说我的提交已经手动通过了，但是每次重投都删除了这些提交，所以我的应用还是没有推送。
使用您从 Microsoft 支持收到的编号提交一次，包括在认证说明和认证报告反馈中，并在 Microsoft 开立票证，您的提交最终将获得通过。
我有一个 UWP 项目作为我的 Xamarin.Forms 解决方案的一部分。当 运行 在本地 Windows App Cert Kit 时，它顺利通过。
将我的应用程序提交到商店时，认证过程失败并出现以下错误：
Error Found:
The supported APIs test detected the following errors:
API FindFirstFileEx in api-ms-win-core-file-l1-2-0.dll is not supported for this application type. PInvoke.Kernel32.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.
我已验证我的应用程序在发布模式下运行，并已验证我的 UWP 构建设置：
我尝试联系 Microsoft 的聊天支持，但被重定向到进入事件报告，然后我被重定向到只能在论坛上寻求帮助或支付高级技术支持费用，所以我无法获得关于这是否是有效故障的任何更多信息。
根据在 FindFirstFileEx (https://msdn.microsoft.com/en-us/library/windows/desktop/aa364419(v=vs.85).aspx) 上找到的文档，Windows 桌面、商店应用和 Windows Phone 似乎支持它。我的UWP应用是提交来支持Desktop和Mobile family的，似乎包含在这个功能支持的客户端中，所以不清楚是什么原因导致失败。
关于从这里到哪里去的任何想法？
我遇到了同样的问题。已提交认证反馈报告，等待微软部分回复...
2017 年 8 月 14 日更新：此问题现在应该已在应用商店中得到解决。如果您遇到此问题，请尝试重新提交您的应用。
WACK 扫描在应用商店中 运行 的方式以及它与 .NET Native 集成的方式存在问题。
对于某些背景，Windows 实际上并没有名为 FindFirstFileEx 的 API - 它不存在。 WACK 支持的 API 扫描的工作方式是它会查看您调用的所有 API 并验证以下情况之一是否为真：
- 这是一个 API 由你的包中的另一个 DLL 导出的
- 这是一个 API 在允许列表中明确提到的
在 kernel32.dll!FindFirstFileEx 的情况下，WACK 发现 kernel32.dll 在您的包中不存在，因此它必须检查允许列表。允许列表未提及 FindFirstFileEx，因为它不存在。 存在的是：
C:\Program Files (x86)\Windows Kits\App Certification Kit>findstr FindFirstFileEx SupportedAPIs-x64.xml
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
<API Name="FindFirstFileExA" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-1-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-0.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-1.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-core-file-l1-2-2.dll"/>
<API Name="FindFirstFileExW" ModuleName="api-ms-win-downlevel-kernel32-l1-1-0.dll"/>
<API Name="FindFirstFileExA" ModuleName="kernel32.dll"/>
<API Name="FindFirstFileExW" ModuleName="kernel32.dll"/>
请注意 FindFirstFileExA 和 FindFirstFileExW 有一堆条目，它们是实际存在的 API。每当您的应用程序尝试调用 FindFirstFileEx 时，它实际上是在调用其中一个。
对于C/C++开发者来说，预处理器实际上是将FindFirstFileEx替换为A或W版本based on the existence of the UNICODE macro.
对于 .NET 开发人员，JIT 运行time（或者，在 .NET Native 的情况下，编译器）会根据以下情况确定是调用 A 还是 W 版本DllImport attribute 的细节，例如 CharSet 和 ExactSpelling 属性的值。
这就是问题所在 - 目前，商店中的 WACK 运行正在 .NET 程序集 之前 编译器替换了无后缀版本带有正确的后缀版本。当您在开发机器上 运行 WACK 时，它会在 编译器进行替换后正确检查程序集 ，因此您看不到任何错误。
修复的第一部分（正在进行中）是将无后缀版本添加到允许列表。修复的第二部分是确保在 post 编译位上 WACK 运行s。
我遇到了同样的问题。我按照 Peter Torr 的建议打开了一个聊天会话（从开发中心）。
摘要如下：
我： 我的应用更新卡住了，因为你的认证系统有问题。看这里：
支持：我们已经意识到这个问题，并且正在努力解决这个问题。对于给您带来的不便，我们深表歉意
我： 好的，我知道你正在处理这个错误。但与此同时，您可以让我的应用通过，对吗？
支持：我们有一个临时解决方法。如果您愿意，我可以为您获取该信息？
...几分钟后...
支持： 好的，我需要你做的是重新提交你的包裹，但在证书部分的注释中包含这个号码 XXXXXXXXXXX。如果这不起作用并且您的应用程序再次未通过认证，请提交有关最新的未通过认证报告的反馈，并再次在此处插入号码。我已在您的帐户中注明以反映这一点
（实数替换为XXXXXXXXXXX）
更新一: 和@jkh一样，自动认证又失败了。所以我在认证反馈中发布了这个数字。
更新 2：不幸的是，"solution" 没有帮助。我现在已经给聊天支持人员写了一封电子邮件（聊天后我得到了他的地址）。我不太相信这有帮助。但是让我们看看...
更新3：我也提交了一个事件。 （这可以在您通常开始聊天会话的地方完成，但请使用下面的按钮 "Submit incident"。）
更新 4：事件提交的答案：
感谢您联系开发人员支持。我了解到由于 Window Store Policy 15.1 API 错误导致认证失败。在进一步审查后，我想让您知道这是一个已知问题，目前工程师正在努力修复。应该很快就会推出修复程序，请稍候。如果修复程序在星期一之前没有实施，我可以进一步调查这个问题，但由于这是一个全球性问题，我建议等待修复程序推出。当我听到与修复有关的消息时，我一定会联系您并请您重试以获得认证。
更新5：我重新提交了我的更新，现在正在等待结果。
更新 6: 又失败了...
更新 7：事件提交的回复：这仍然是一个持续存在的问题，我们已将您的问题上报给我们的内部团队进行进一步调查以尝试绕过这个错误给你。一旦收到更新，我一定会与您联系。
更新8：最终，重新提交后，认证过程花了两天（！），但现在我的更新在商店里了。哇，好厉害啊...
在几周前向 Microsoft 开票后，我的帐户终于获得了豁免，使我能够通过自动认证。
请勿重新提交。我被告知重新提交并提供有关该解决方案的认证报告反馈。重投几次后，收到邮件回复说我的提交已经手动通过了，但是每次重投都删除了这些提交，所以我的应用还是没有推送。
使用您从 Microsoft 支持收到的编号提交一次，包括在认证说明和认证报告反馈中，并在 Microsoft 开立票证，您的提交最终将获得通过。