无法将帮助文件作为 Windows 10 通用应用程序打开答案

【问题标题】：Can't open help file as Windows 10 Universal application无法将帮助文件作为 Windows 10 通用应用程序打开
【发布时间】：2017-09-17 21:56:27
【问题描述】：

我刚刚使用Desktop Bridge 打包了三个MFC 应用程序以上传到Windows 应用商店。

它们都工作正常，但由于某种原因其中一个无法打开帮助文件。（帮助在其他两个应用程序中运行良好。）

当从 Visual Studio 运行或双击可执行文件时，问题应用程序运行良好。但是从测试 AppX 包安装后访问帮助会给我以下错误。

无法启动帮助。

我可以使用任务管理器找到已安装的应用程序位置，并确认它确实包含我的帮助文件。此外，我添加了代码以在启动时显示帮助文件的路径，它显示了正确的帮助路径！但无论我做什么，我的应用程序都无法提供帮助。

有谁知道作为 Windows 10 应用程序安装的受限权限是否会以某种方式限制对帮助文件的访问？或者任何人都可以建议如何通过上面完全无用的错误消息来提示它为什么失败？

【问题讨论】：

文件在哪里，您是如何尝试打开/启动它的？
帮助文件与可执行文件位于同一文件夹中。我的应用程序类中有一个命令处理程序，它委托给 CWinApp::OnHelp。
尝试将当前工作目录设置为该路径。如果它试图从当前工作目录打开文件，那么它将无法在转换后的应用程序中运行，因为该路径指向其他地方。
我修改了代码以打开一个显示 m_pszHelpFilePath 值的消息框。我验证它具有正确的值。也就是说，它反映了找到帮助文件的实际路径。让我觉得它找到了帮助文件，但无法加载它。如果只有错误消息能提供更多信息。
实际打开帮助文件的进程是什么？请记住，只有在您的应用包上下文中运行的进程才能访问您应用的安装目录。

标签： mfc windows-10-universal chm desktop-bridge

【解决方案1】：

您收到此错误是因为包含您的帮助内容的 .chm 文件位于您的应用程序安装文件夹中。在现代 Windows 应用模型中，该文件夹被锁定，因此只有属于您的应用包的进程才能访问它。然而，使用 MFC 框架，被调用的帮助查看器不是包的一部分 - 因此它无法访问 .chm 文件。

解决方案是让您的应用在运行时（例如在启动后立即）在可访问的位置（例如 %TEMP%）制作 .chm 文件的副本，并更新 m_pszHelpFilePath 以指向该位置。现在帮助查看器进程应该可以成功加载帮助了。

【讨论】：

感谢您与我一起解决这个问题。但我仍然认为问题没有解决。首先，正如我在我的 OP 中提到的，我有三个这样的程序。另外两个帮助工作正常。其次，帮助在新的应用程序模型中不起作用是难以接受的。 Windows HtmlHelp() API 应该可以工作！除了我的一个应用程序之外，其他所有应用程序都可以。
MFC 模型是在 25 年前发明的，那时软件是在盒子里购买的，每个人都是管理员，互联网和安全性都不是问题。这导致了当今存在的许多问题：DLL 地狱、注册表腐烂、安全和隐私问题，仅举几例。从那个时代迁移应用程序时，我们需要应用新模型中的规则，在某些情况下，这需要您进行一些代码更改，就像在这种情况下一样。我很乐意了解为什么您的其他应用程序中的帮助无需更改即可工作。商店里已经有这些了，我可以看看吗？
Windows 也很旧。并且 Windows API 需要工作以保持 Windows 的可行性。而且我认为帮助仍然很重要（尽管微软似乎没有那么重要）。我的其他应用程序尚未在商店中发布，并且在发布时不会免费。我确实有一位 Microsoft 联系人一直在帮助我使用 Desktop Bridge。我认为他会进一步考虑这一点。我很想让其他人看看，但我可能需要在 Stackoverflow 上分享不适合的信息和位。
告诉您的 Microsoft 联系人与我联系，我们可以离线跟进。我是桌面桥的项目经理。 Windows 中当然会继续支持帮助，但应用程序使用它的方式需要遵守现代应用程序模型的规则。这可能需要更改应用代码。我们一直在我们的文档/演示文稿中说，在桌面桥上移动的应用程序可能必须进行兼容的代码更改以符合应用程序模型。
哦，您是 Desktop Bridge 的项目经理？我在意大利与 Matteo 合作。我会跟他提这件事。感谢您在这方面的帮助。