声明broadFileSystemAccess功能时，文件IO操作不起作用

Question

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

我正在使用上述功能来访问整个文件系统，我的应用程序的最低和最高版本均保持为 ver 17134（RS4），并且在API下方，尽管声明了声明，但仍引发了访问被拒绝的异常broadFileSystemAccess功能。

下面列出了API：

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

  有关https://github.com/siddhu10/Zipping.git的示例示例，上述API失败。

来自FluentFTP的

• DownloadFileAsync-来自nuget的第三方库

  有关https://github.com/siddhu10/FileTransfer.git的示例示例，上述API失败。

Imp注意：：仅当最小版本也为17134（RS4）和更高版本时，观察结果才超过API的失败。这些API在最小版本保留为15063及更低版本时起作用。

请帮助解决以上问题。

Answer 1

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

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

只要您的分钟数小于RS3，您将获得较早的行为（但不完全支持.NET Standard 2.0）。

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

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

Answer 2

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

您可以在docs中进行验证。这意味着您将不得不用使用新API的替代代码替换代码，或将需要使用的文件复制到ApplicationData.Current.LocalFolder等经典API可以访问的位置。

Answer 3

我猜这里的结论是，对于UWP应用程序，.Net标准文件访问模型（System.IO命名空间）已完全损坏，并且绝对没有办法使其起作用。我希望broadFileSystemAccess可以解决此问题，不幸的是，情况并非如此。希望这个问题能尽快解决。