声明 broadFileSystemAccess 功能时文件 IO 操作不起作用
File IO operations not working when broadFileSystemAccess capability declared
我在应用程序开发过程中使用 "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 注：上面的观察API仅当最小版本也是17134（RS4）及更高版本时才会失败。当最低版本保持在 15063 和更低版本时，这些 API 的工作。
请帮忙解决以上问题
问题是 broadFileSystemAccess 功能仅适用于 UWP 中的新 Windows.Storage API。您正在使用的经典文件 IO API 不允许访问。
您可以在 docs 中验证这一点。这意味着您要么必须用使用新 APIs 的替代方案替换代码，要么将需要使用的文件复制到经典 APIs 可以访问的位置，例如 ApplicationData.Current.LocalFolder.
作为 .NET Standard 工作的一部分，.NET 处理代理文件路径的方式在 RS3 中发生了变化。在 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 来确保您可以持续访问该位置。
我想这里的结论是 .Net Standard 文件访问模型（System.IO 命名空间）对于 UWP 应用程序来说是完全错误的，并且绝对没有办法让它工作。我希望 broadFileSystemAccess 能够解决这个问题，不幸的是事实并非如此。希望这会很快得到解决。
我在应用程序开发过程中使用 "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 注：上面的观察API仅当最小版本也是17134（RS4）及更高版本时才会失败。当最低版本保持在 15063 和更低版本时，这些 API 的工作。
请帮忙解决以上问题
问题是 broadFileSystemAccess 功能仅适用于 UWP 中的新 Windows.Storage API。您正在使用的经典文件 IO API 不允许访问。
您可以在 docs 中验证这一点。这意味着您要么必须用使用新 APIs 的替代方案替换代码，要么将需要使用的文件复制到经典 APIs 可以访问的位置，例如 ApplicationData.Current.LocalFolder.
作为 .NET Standard 工作的一部分，.NET 处理代理文件路径的方式在 RS3 中发生了变化。在 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 来确保您可以持续访问该位置。
我想这里的结论是 .Net Standard 文件访问模型（System.IO 命名空间）对于 UWP 应用程序来说是完全错误的，并且绝对没有办法让它工作。我希望 broadFileSystemAccess 能够解决这个问题，不幸的是事实并非如此。希望这会很快得到解决。