当声明了 broadFileSystemAccess 功能时，文件 IO 操作不起作用答案

【问题标题】：File IO operations not working when broadFileSystemAccess capability declared当声明了 broadFileSystemAccess 功能时，文件 IO 操作不起作用
【发布时间】：2019-04-02 04:26:04
【问题描述】：

我在应用开发过程中使用“broadFileSystemAccess”功能时遇到了一些奇怪的行为，即

我正在使用上述功能来访问整个文件系统和我的应用程序的最小和最大版本，我保持 ver 17134 (RS4)，尽管声明了以下 API，但仍然抛出拒绝访问异常broadFileSystemAccess 能力。

API 如下：

ZipFile.CreateFromDirectory - 来自 System.IO 命名空间

请参阅 https://github.com/siddhu10/Zipping.git 以获取上述 API 失败的示例。
DownloadFileAsync 来自 FluentFTP - 来自 nuget 的第 3 方库

请参阅 https://github.com/siddhu10/FileTransfer.git 以获取上述 API 失败的示例。

Imp Note:观察是上面API的失败只有当min ver也是17134（RS4）和更高版本时。当最低版本保持在 15063 及更低版本时，这些 API 的工作。

请帮助解决上述问题。

【问题讨论】：

标签： file-io uwp windows-10-universal

【解决方案1】：

作为 .NET Standard 工作的一部分，.NET 处理 RS3 中更改的代理文件路径的方式。在 RS3 之前，System.IO 类型会尝试在后台使用 WinRT API 来访问代理文件，只要用户授予应用访问权限，这些文件就可以工作。

从 RS3 开始，API 更改为仅使用原始 Win32 API（作为标准化工作的一部分）。现在有可以访问代理位置的 Win32 API，但由于一系列不幸的事件，这些不是 .NET 正在使用的 API。

只要你的 min-ver 小于 RS3，你就会得到旧的行为（但不是完整的 .NET Standard 2.0 支持）。

到目前为止，如果您的 min-ver 是 RS3 或更高版本，则访问代理位置的唯一方法是通过 WinRT API 或 Win32 FromApp API。而且由于broadFilesystemAccess 在RS4 中，恐怕你不能将它与System.IO API 一起使用。

如果您需要使用 .NET API，则需要将 minver 设置为 RS2 或更低，然后要求用户选择带有 FolderPicker 的文件夹。然后，您可以使用FutureAccessList 来确保您可以持续访问该位置。

【讨论】：

哇！不知道这个，谢谢你的详细解释！尽管我理解标准化是一件好事，但旧的行为似乎更有用一些。如果 UWP 将来允许 System.IO 考虑 broadFilesystemAccess，那就太好了。
当我选择从 RS4 开始的“broadFilesystemAccess”功能时，我想限制应用程序的安装，因此将 min ver 也保留为 17134。现在你能建议任何替代方案来实现 zip 创建和 FTP 下载操作（或）我将使用 min ver 作为 15063 及更低版本，在这种情况下建议如何限制从 RS3 及更低版本的安装？您能否建议我哪种方式可行以及如何实现？
但如果我使用“FolderPicker”而不是“broadFilesystemAccess”，FTP 库下载 api 需要一个字符串类型的路径，而不是存储文件夹或存储文件类型。如果我再次使用 StorageFolder 的 Path 属性，我会在访问直接路径时收到拒绝访问异常，并且我的下载 api 失败。如何解决这个问题？
我使用的 FTP 库是 FluentFTP，我可以看到他们的代码，它使用 System.IO 命名空间，所以我遇到了这样的异常。我想知道是否有任何仅使用 WinRT 兼容 API 的 FTP 库可用？
我不知道，抱歉。

【解决方案2】：

问题在于 broadFileSystemAccess 功能仅适用于 UWP 中的新 Windows.Storage API。您正在使用的经典 File IO API 不允许访问。

您可以在docs 中验证这一点。这意味着您要么必须用使用新 API 的替代代码替换代码，要么将需要使用的文件复制到经典 API 可访问的位置，例如 ApplicationData.Current.LocalFolder。

【讨论】：

但是同样的能力，它适用于最小版本 15063。为什么当我设置最小版本也是 17134 时它不是？
这很不寻常，因为根据文档，它应该到处都失败，特别是当你在你的机器上运行 17134 时，无论如何它都应该使用最新的 API......你能发布一些源代码？
或者更好——你能在 GitHub 上发布一些简单的应用程序来显示这种行为吗？我会在我的机器上验证它
我已经在上面的问题中为这两种情况添加了 github 链接。在这些样本中 min ver 设置为 17134 并且它确实失败了。但是您可以尝试将 min ver 更改为 15063 并且您可以看到它正在工作。请帮助解决方案
看我的回答。情况很复杂。除非我忘记了什么:)（远离 PC...）

【解决方案3】：

我想这里的结论是 .Net 标准文件访问模型（System.IO 命名空间）对于 UWP 应用程序来说完全被破坏了，并且绝对没有办法让它工作。我希望 broadFileSystemAccess 能解决这个问题，不幸的是事实并非如此。希望这将很快得到解决。

【讨论】：