几年前，当我第一次开始移植 WPF 应用程序时，我感到沮丧。所以我当然理解你的心情。从那时起已经取得了一些进展，正如您所说，WinUI 团队真的在努力。

在我看来，存在一个我们无法解决的基本设计问题：WinRT 在技术上存在缺陷，因为它必须直接与 C++ 和 JavaScript 互操作（这里有一个示例，另一个）。它真的不能很好地处理许多高级概念，例如泛型。当然，这种架构还有一个很大的好处：现在所有的 Windows 都可以共享相同的 WinRT API。

WinRT 也是由 Sinofsky 领导的 Windows 团队完成的，我相信这意味着，是的，他们生活在自己的世界中，没有使用现有最终用户开发人员生态系统的经验。我们最终得到了一个“最小公分母”API，本地和托管开发人员都不喜欢使用它。这基本上是 Windows Phone 消亡的主要原因之一——开发人员无法轻松开发/移植应用程序。没有应用程序就没有客户。微软确实吸取了这个教训。

因此，我们失去了多年来已经习以为常的托管代码的一些好处。它似乎仍然是 WPF 的后退——我一直在发现错误和不完整的功能。我认为 #1830 在 WPF 时代永远不会发生。我们仍然必须以某种方式前进。

WinUI 3.0 显然是朝着正确方向迈出的一步，至少尝试在前端解决这个问题。不过，我更希望微软在发布新控件之前实施更强大的开发过程和更多的测试......我知道开发现在正在推动更改，稍后修复。虽然这可能适用于应用程序，但对于一旦设置好之后就很难更改它们的平台，这不是一个好的模式。（TreeView、NumberBox 等......在第一次发布时有很多问题，这些问题永远无法解决，更不用说 15 年前的规划阶段了）。

看到曾经最强大的 UI 平台 WPF 演变成这样，我很难过。但微软现在正在缓慢但肯定地听取反馈并解决问题。据了解，还有很多工作要做。

robloo 于 2020-01-17

👍7

你认为用户会很乐意做上面的事情吗？不，他们不会——事实上，79.8% 的人不这样做（我的 AppCenter 数据支持这一点）。留给我的要么是用户不使用我的应用程序，要么只是让我的应用程序看起来低于其他本机应用程序。

也许您没有考虑这样一个事实，即您的用户实际上会停下来思考：“等等，我真的要授予此应用访问我的整个驱动器的权限吗？” 对于不熟悉应用程序/开发人员/公司的人来说，这是一个红灯警告。

您将低保留率归咎于用户授予您的应用访问其整个驱动器所需的过程。也许您应该首先重新考虑您对 BroadFileSystemAccess 的“需求”，而只是让用户手动选择他们认为可以让您访问的文件夹。

仅供参考，如果我想试用一个应用程序，并且在安装后它就像“嘿，允许我访问任何地方的所有内容”，我也会运行。

当您请求 BroadSystemAccess 时，默认情况下您的应用程序没有该访问权限。

显然......您只是提出了一个请求，如果您的用户觉得这样做很舒服，他们实际上必须授予您访问权限。

kmgallahan 于 2020-01-17

👍3

此外，仅基于违反Microsoft 开源行为准则的不尊重标题，以及内容与 WinUI 无关，应该关闭此问题。 @jevansaks @jesbis

kmgallahan 于 2020-01-17

👎5 👍4

最后要补充的一件事。我认为 Rich Lander 在1 月 15 日的 .NET 社区站会（从 1:12:40 开始）说得最好。

@verelpode您

kmgallahan 于 2020-01-17

当您请求 BroadSystemAccess 时，默认情况下您的应用程序没有该访问权限。
显然......您只是提出了一个请求，如果您的用户觉得这样做很舒服，他们实际上必须授予您访问权限。

这不是问题：至少在 Android/iOS 上，当您的应用程序尝试访问 HDD 时，您会被问到这些问题，并且它不会像我们的情况那样被

jtorjo 于 2020-01-17

如果您提供文件选择器让用户选择他们想要授予您的应用访问权限的内容，您的应用就不会关闭。

相反，您想要这一切，抱怨用户必须采取的一个小的一次性额外步骤，并将您的保留率归咎于这一步。

kmgallahan 于 2020-01-17

👎2 👍1

此外，仅基于违反Microsoft 开源行为准则的不尊重标题，以及内容与 WinUI 无关，应该关闭此问题。 @jevansaks @jesbis

当我几乎要疯了的时候，要保持尊重真的很难。不是说 - 我之前已经说过了，没有地方可以写关于 WinRT 的内容。 如果我真的可以写作并且有人会倾听，我会很乐意使用不同的语气。以上所有的呼声都不应该存在——WinRT 应该足够成熟。还没有...

社区在哪里可以真正与 WinRT 团队交谈？有人在听吗？

jtorjo 于 2020-01-17

👍6

如果您提供文件选择器让用户选择他们想要授予您的应用访问权限的内容，您的应用就不会关闭。
相反，您想要这一切，抱怨用户必须采取的一个小的一次性额外步骤，并将您的保留率归咎于这一步。

我的应用程序允许用户编辑照片和视频，我希望用户可以轻松地根据自己的选择进行预览，而不是使用旧样式的文件选择器。所以是的，我可以访问所有硬盘非常重要。不，那些“图片”和“视频”虚拟文件夹是微软认为用户保存他们的照片和视频的地方。那不是现实。

jtorjo 于 2020-01-17

我之前说过，没有地方可以写关于 WinRT 的内容。

正如您的链接所示，您已经在 UWP 问答论坛上大肆谈论 WinRT，这是您被引导去的地方。

因此，通过在这里发帖，您似乎只是想要更多的受众，而不是真正完成任何事情（因为 WinUI 团队不在 WinRT 上工作）。

kmgallahan 于 2020-01-17

正如您的链接所示，您已经在 UWP 问答论坛上大肆谈论 WinRT，这是您被引导去的地方。

然而，我的任何问题都没有解决方案。在问答环节中，您提出问题并获得答案。但是你真的不能建议任何改变（不幸的是）。

jtorjo 于 2020-01-17

我的应用程序允许用户编辑照片和视频，我希望用户可以轻松地根据自己的选择进行预览，而不是使用旧样式的文件选择器。所以是的，我可以访问所有硬盘非常重要。

不，这不对。您的用户没有在驱动器上到处都是照片和视频，它们位于可能不是特殊文件夹的特定位置。

让用户选择这些文件夹一次，然后您始终可以通过FutureAccessList进行访问。不要让他们让你访问他们的所有文件，这样他们就不会逃跑了。

kmgallahan 于 2020-01-17

@kmgallahan当然，可以

我认为我们可以让这些类型的讨论保持专业性，因为我们知道它们源于沮丧和对开发生态系统成功的许多既得利益。

robloo 于 2020-01-17

👍3

当然，语气可以稍微回拨一下，但我们以前都感到沮丧。认为明显的问题没有得到解决更令人沮丧。

谢谢：）

jtorjo 于 2020-01-17

不，这不对。您的用户没有在驱动器上到处都是照片和视频，它们位于可能不是特殊文件夹的特定位置。
让用户选择这些文件夹一次，然后您始终可以通过FutureAccessList进行访问。不要让他们让你访问他们的所有文件，这样他们就不会逃跑了。

显然，他们不在那些特定的位置......

当然，我可以使用 FutureAccessList 并让用户记住他们保存照片/视频的位置，因为我们都知道我们保存所有照片/视频的位置，对吗？

而不是（我的应用程序所做的）很好地预览文件夹并向您显示您拥有照片/视频的文件夹。

jtorjo 于 2020-01-17

一些注意事项：

感谢@jtorjo花时间写下您的体验和反馈，以及您在问答页面上的时间。

正如@robloo和@kmgallahan提到的，其中大部分与

但是，我们也认识到，当涉及到 Windows 开发人员平台的不同领域时，问答网站和反馈中心的参与度可能会更好。我们确实正在积极尝试改进这一点，但我发现找到一个提供反馈的好地方并查看是否发生了任何事情令人沮丧。

例如，我们确实看到通过反馈中心提供的所有内容，但没有一种很好的方式来回应或继续讨论。因此，只要它保持建设性并且与 Windows 应用程序用户体验/开发相关，那么如果某个主题目前在其他地方不适合，我们可以在此处讨论一些一般平台反馈。

就其价值而言，这些主题也得到了内部的认真关注。 我们今天联系了一些 WinRT 专家，看看是否有关于这些领域的任何更新我们可以分享，因为您巧妙地总结了整个平台和工具的一些主要问题。

对于桌面应用程序开发：WinUI 3 是我们解耦 Windows 开发人员平台以消除这些互操作性障碍并使逐步采用 WinUI 和 UWP 变得更容易的重要组成部分。我们知道我们需要更好地启用具有现代 UX 的桌面应用程序，而不需要所有当前限制。我们有很多专家，包括 WPF 的一些主要创建者。

特别是，我们在 Xaml 孤岛和桌面应用程序的 WinUI 上花费了大量时间，我们期待下一步将发布预览版供人们在今年晚些时候试用。我们正在努力使反馈驱动更加透明且更加透明，随着我们将完整的 Xaml 平台（即 WinUI 3）之类的内容迁移到开源，这应该会变得更加容易。

如果人们对桌面计划的当前状态感兴趣，那么我们还可以在每月一次的社区电话会议中深入探讨更多细节 - 请随时在此处提出主题：

WinUI 社区电话会议（2020 年 1 月 22 日）#1857

jesbis 于 2020-01-18

👍9 🚀2

嗨@jesbis ，

感谢您查看我的问题！

正如@robloo和@kmgallahan提到的，其中大部分与

是的，真的很抱歉，我只是觉得我疯了。我在这里提到的事情很关键 - 我真的对此充满热情，因为我遇到了上述所有问题。他们都付出了巨大的代价，很多人甚至只是放弃了尝试。

但是，我们也认识到，当涉及到 Windows 开发人员平台的不同领域时，问答网站和反馈中心的参与度可能会更好。我们确实正在积极尝试改进这一点，但我发现找到一个提供反馈的好地方并查看是否发生了任何事情令人沮丧。

完全同意。作为旁注，我实际上试图在反馈中心报告 BroadSystemAccess，在提供了所有详细信息并在上面花费了大约 15 分钟之后，我最终以某种方式可能按下了一个相当于“返回”的热键 - 因此，我丢失了我所有的工作（没有撤消，没有文本被复制到剪贴板，什么都没有）。显然，我非常沮丧，只是放弃了。

就其价值而言，这些主题也得到了内部的认真关注。 我们今天联系了一些 WinRT 专家，看看是否有关于这些领域的任何更新我们可以分享，因为您巧妙地总结了整个平台和工具的一些主要问题。

凉爽的！

对于桌面应用程序开发：WinUI 3 是我们解耦 Windows 开发人员平台以消除这些互操作性障碍并使逐步采用 WinUI 和 UWP 变得更容易的重要组成部分。我们知道我们需要更好地启用具有现代 UX 的桌面应用程序，而不需要所有当前限制。我们有很多专家，包括 WPF 的一些主要创建者。

棒极了！我肯定更期待它。一旦完成，我很可能会更新我的应用程序，但在那之前我遇到了很多问题。

如果人们对桌面计划的当前状态感兴趣，那么我们还可以在每月一次的社区电话会议中深入探讨更多细节 - 请随时在此处提出主题：
WinUI 社区电话会议（2020 年 1 月 22 日）#1857

我可以推荐我在这里提到的 WinRT 主题吗？

再次感谢！

jtorjo 于 2020-01-18

例如，我们确实看到通过反馈中心提供的所有内容，但没有一种很好的方式来回应或继续讨论。因此，只要它保持建设性并且与应用程序开发相关，那么如果某个主题目前在其他地方不适合，我们可以在此处获取一些一般平台反馈。

@jesbis
这是个好消息！非常感谢 WinUI 团队展示了这种灵活性并试图减轻（感知到的）WinRT 反馈系统问题，即使他们不必这样做！

Felix-Dev 于 2020-01-18

🚀1

@kmgallahan

我认为 Rich Lander 在 1 月 15 日的 .NET 社区站会（从 1:12:40 开始）说得最好。

所以 Rich Lander 在那里说他更喜欢有一点侵略性但同时又很好的人。我认为社会上最大的问题之一是，许多人非常“礼貌”，以至于他们的行为变得极端化，在表面上表现出“礼貌”的同时，转变为不尊重和粗鲁。非常“有礼貌”的人说话间接和含糊不清，这使得他们的交流难以理解并且容易被误解。非常“有礼貌”的人是不尊重和粗鲁的，因为他们实际上是在说相当于：

“我相信你不能接受直接的真相，所以我会戴上厚厚的蓬松棉手套来对付你，用泡泡纸把你包起来，和你说话很客气，很间接，很含糊，因为如果我把你当作一个成熟的成年人，说出我的诚实意见，你会发火，爆炸和发疯。不处理直接的真相。”

那样的话，当所谓的“礼貌”到了极端（很多人都这样）的时候，就会显得不尊重和粗鲁，同时又显得很“礼貌”。换句话说，对礼貌和尊重的误解是社会上最大的问题之一。许多人没有意识到过度的礼貌是不尊重的，并导致项目失败等。这种虚假的礼貌问题导致世界上每一天每一小时每一秒的另一次沟通失败——它经常发生——和社会因为它而遭受很大的痛苦。

verelpode 于 2020-01-18

🚀1 👍1

@jtorjo
这是问题的根源：

诺基亚灾难性错误的重演

WinRT/UWP 不小心重蹈了诺基亚、黑莓、苹果等公司的覆辙。诺基亚故事：诺基亚是一个非常成功的巨头，但后来诺基亚意识到他们在智能手机技术方面已经落后了。为了解决这个问题，他们需要把实现他们现有系统的一系列改进版本放在首位。他们没有这样做，而是试图切换到一个新系统，但它杀死了他们。字面上杀死了他们——诺基亚移动被迫接受被微软收购。

那么你会期望微软会从诺基亚的错误中吸取教训，而不是重复同样的问题。不幸的是，微软确实重蹈了诺基亚的覆辙。 Microsoft 开始使用 WinRT/UWP，而不是生产新版本的 WPF 和 .NET Framework。猜猜发生了什么？与诺基亚相同的灾难性灾难：它杀死了他们。 Windows Mobile 已死，被微软高管取消。因此不幸的是，微软没有从诺基亚的灾难性错误中吸取教训。现在所有的智能手机都运行Android或Apple而不是WinRT / UWP，因此WinRT / UWP是灾难性的失败，导致微软完全失去了在数十亿美元的智能手机行业中的地位。 WinRT/UWP 给微软造成了数十亿美元的损失。

黑莓和诺基亚和微软犯了同样的错误。黑莓非常成功，但后来黑莓意识到他们在智能手机技术方面落后了。为了解决这个问题，他们需要把实现他们现有系统的一系列改进版本放在首位。他们没有这样做，而是尝试切换到新系统。黑莓最初使用黑莓操作系统，然后在2013年左右，他们切换到QNX系统。发生了什么？与 WinRT 和诺基亚相同。它杀死了他们。 2016 年，黑莓宣布将停止设计自己的手机。

过去，Apple 也曾发生过这种情况。苹果公司差点倒闭，幸而幸存下来。若干年后，苹果最终通过智能手机实现了强劲复苏。在灾难性的错误之后还活着是幸运的。

重大变化

微软声称他们无法继续 WPF 开发；由于发生重大变化，无法将 WPF 用于智能手机/平板电脑，但这是一种极度害怕发生重大变化的情况。是的，在破坏性变更方面非常小心是明智的，但如果采取极端措施，那么它就会扼杀项目和公司。现实情况是，其实可以引入重大更改。微软本可以发布支持智能手机/平板电脑/触摸屏的“WPF 5”，并宣布它包含重大更改，但没有开发人员被迫立即升级到它。预先存在的应用程序不会中断，因为它们会继续使用 WPF 4 运行，直到应用程序开发人员感到舒适并准备好切换到 WPF 5。因此，中断性更改不会导致混乱或失败。

它与包含重大更改的 NuGet 包的新版本的原理相同。当包的新版本发布时，您的应用程序不会突然中断。您的用户会继续使用您的应用并且不会遇到任何问题，因为您的应用会继续使用旧版本的包，直到您感觉舒适并准备好升级您的应用以使用最新版本的 NuGet 包。因此，可以引入重大更改。

对托管代码的立场逆转

微软表示托管代码提供了极好的优势，根据我使用托管和非托管代码的经验，这是绝对正确的。我的职业生涯始于编写非托管代码。后来我测试了 Microsoft 的声明，并切换到托管代码，我体验到了生产力和可靠性方面的出色改进。后来微软奇怪地颠倒了立场，在非托管代码的基础上，加上1993年的古老的组件对象模型（COM），过度使用Win16（也称为Win32），产生了WinRT。 WinRT 的基础是几十年来过时的技术：本机代码、COM 和 Win16 AKA Win32。大多数应用程序开发人员不愿意切换到 WinRT/UWP 也就不足为奇了。

Android 现在是市场领导者。微软可以向安卓学习。 Android 应用程序通常使用托管代码编写。虽然我不喜欢Java，更喜欢用C#，但不得不说Java比原生Win16和COM要好很多。

多名微软员工仍然继续说“本地”，好像这是一件好事。我的职业生涯始于“本土”，从多年的经验中我知道“本土”是一件坏事。大量的 Android 开发人员也知道原生是一件坏事，但太多的 UWP 工作人员说它好像很棒。用@jtorjo的话

我不得不一遍又一遍地重复这些话：WinRT/UWP 是一场灾难性的失败。我不得不不断重复这些话，因为 WinRT 团队“与现实脱节”，因为他们拒绝承认 WinRT/UWP 是一场灾难性的失败，微软不应该继续重复同样的错误WinRT 好像什么都没发生过一样。

例如，目前DataGrid是用现代托管代码编写的，但 WinUI 团队希望重写 DataGrid 以使用“本机”代码，并认为这是“升级”，而实际上它是降级和回归实践那已经过时了几十年。一般来说，WinRT/UWP 受到现代和过时软件工程实践之间的混淆的困扰。因此， @jtorjo使用 _"脱离现实"_ 可以被解释为不礼貌，但我相信这是一个准确的描述，即使它不是最好的词选择。

再举一个_“脱离现实”_的例子，看看WebView2 ——就像时光倒流回到我职业生涯的起点，几十年前，当我们使用过时的概念时例如HRESULT而不是现代异常处理。令人惊讶的是，WebView2 在 2020 年作为一个新项目发布，但仍然使用诸如HRESULT和LPCWSTR等古老技术。 WebView2 的设计与现代软件工程实践脱节。

verelpode 于 2020-01-18

🚀1

所以，按照 Rich Lander 所说的，我之前的留言表达了我对WinUI 团队的有礼貌，或者什么也不说。如果我不尊重团队，我会注销并忽略 WinUI：我根本不会费心写任何消息——我会认为 WinUI 是“无望的”和“失败的原因”，我不会在以下位置提供任何反馈全部。我提供详细反馈的事实表明我尊重团队。许多人不提供任何反馈——这是对团队的不尊重。认为团队如此绝望以至于不值得为他们写任何反馈是不尊重的。

如果你在法庭上，即使你讨厌他的胆量，你也会非常礼貌地对法官说“法官大人”。极端的礼貌是粗鲁。法官将“您的荣誉”解释为尊重，但实际上是不尊重。

verelpode 于 2020-01-18

Microsoft 开始使用 WinRT/UWP，而不是生产新版本的 WPF 和 .NET Framework。 ...

同意。我已经开发 UWP 好几个月了......有很多限制，但我已经尽力做到了“禅”，或多或少地继续前进。但我工作得越多，我就越意识到——限制实际上是 WinRT，而不是 UWP。

问题是，这就是我们所拥有的，显然，我们需要继续推进。在我看来，这应该是：

UWP 需要尽可能隐藏它使用 WinRT 和
WinRT 应努力消除尽可能多的（不需要的）限制
主要焦点应该是桌面，然后是其他平台（Hololens、xbox 等）

（ps事实上，对于一个文件，要获取它的属性，我需要调用一个异步函数，这仍然让我抽搐）

对托管代码的立场逆转

为什么我们需要在 WinRT 中处理 COM 确实超出了我的理解。似乎他们包装了一些旧的 DCOM 代码或其他东西，但这应该是对 WinRT 用户 100% 隐藏的。
我们需要了解 COM 的事实真的很糟糕。再一次，应该尽可能地对我这个图书馆的用户隐藏。

[稍后编辑] 现在想想，我们至少需要 COM 来处理 DirectX。尽管如此，它应该尽可能对图书馆用户隐藏。

多名微软员工仍然继续说“本地”，好像这是一件好事。

本机，在“编译为 .net 本机”的上下文中，我确实认为是一件好事，但是，我不喜欢它的局限性。我的项目无法编译为 .net 本机，因为它使用了我移植到 UWP 的另一个库，并使用了一些 API，强大的 Store 人员认为这是“不可接受的”。有问题的库是https://github.com/naudio/NAudio - 一个非常强大的库。仅出于这个原因，我只是说 - 我不会将我的应用程序发布到 MS 商店。

再举个_“脱离现实”_的例子，看看WebView2 ——就像穿越回到我职业生涯的起点

我不是 100% 肯定，但你可能是对的。我确实知道 WebView 据说是 Win32 控件的包装器，而且我知道一个奇怪的错误，当 WebView 位于另一个控件之上时，WebView 链接将不起作用。

jtorjo 于 2020-01-18

👍1

嗨@robloo ，

这么晚才回复很抱歉

几年前，当我第一次开始移植 WPF 应用程序时，我感到沮丧。所以我当然理解你的心情。从那时起已经取得了一些进展，正如您所说，WinUI 团队真的在努力。

是的，完全同意。早在 2016-2017 年，我什至不会接触 UWP。

在我看来，存在一个我们无法解决的基本设计问题：WinRT 在技术上有缺陷，因为它必须直接与 C++ 和 JavaScript 互操作（这里

至少可以说，这太可悲了……为什么我们要 JS 互操作性？

...是一个例子，另一个）。它真的不能很好地处理许多高级概念，例如泛型。当然，这种架构还有一个很大的好处：现在所有的 Windows 都可以共享相同的 WinRT API。

我讨厌 WinRT 的地方有很多 - 列表中还有什么？

我什至需要知道这一点的事实很糟糕。事实上，我需要创建这样 2 个小项目，而且都是反复试验，以了解我实际允许使用的内容。

因此，我们失去了多年来已经习以为常的托管代码的一些好处。它似乎仍然是 WPF 的后退——我一直在发现错误和不完整的功能。我认为 #1830 在 WPF 时代永远不会发生。我们仍然必须以某种方式前进。

是的，我们确实...

WinUI 3.0 显然是朝着正确方向迈出的一步，至少尝试在前端解决这个问题。不过，我更希望微软在发布新控件之前实施更强大的开发过程和更多的测试...... [...]

同意 100%。

看到曾经最强大的 UI 平台 WPF 演变成这样，我很难过。但微软现在正在缓慢但肯定地听取反馈并解决问题。据了解，还有很多工作要做。

是的，有明确真棒人正在监听MS。希望我们能扭转局面……

jtorjo 于 2020-01-18

查询文件 API 非常慢

显然，有人确实找到了解决方法。显然，花了这么长时间真的很难过 - 这不是我想要处理搜索文件的首选方式，但至少它确实有效。
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

所以，非常感谢@duke7553 ！

jtorjo 于 2020-01-19

@jtorjo 乐于助人！

duke7553 于 2020-01-19

👍1

我发现这个讨论非常有趣，实际上与 Windows UI 的未来非常相关。那是因为 WinUI 并非处于真空状态。除非它对于创建在 WinRT/UWP 以外的其他设备上运行的应用程序很有用，否则整个存储库的价值很小。 WinUI 3.0 来得不够快。

我们对 Windows 上的 UI 有一个愿景和路线图，但它位于堆栈的最顶部，并且对于该表面层下的内容没有愿景：
WinUI 好看吗？是的
您现在可以在 Windows 上制作现代、美观的应用程序吗（2020 年 1 月）？不
你能用 UWP 做一个好的应用程序吗？一定不行！

如果不解决房间里的大象问题，我们就无法真正向前迈进：前面提到过 WinRT 和 UWP 完全失败的事实，不仅在业务方面而且在技术方面都是如此。我个人是身在其中的。当我的应用程序失去焦点时，我无法弄清楚如何播放声音时，我停止了开发我的爱好项目。琐碎的。琐碎的事情必须像在 UWP 中一样困难吗？当琐碎的事情变得不可能困难时，你能称一个平台为伟大的吗？ WinUI 只是平台的一部分，不是吗？

房间里的另一头大象。如果有人问：我想制作一个新的 Windows 程序，最好的方法是什么？ JAN2020 没有直接的答案！如果您尝试将 UWP 放入答案中 - 您将度过一段不愉快的时光。（有没有一个评论、博客文章、YouTube 视频，其中有人说：我用 UWP 制作了一个很棒的应用程序并且我喜欢这个过程？我们都知道没有。没有人写关于用 UWP 制作应用程序的文章，它确实没有'在互联网上不存在）。 WPF？没有现代控件 - 死技术，不是一个好主意（但仍然比 UWP 好）。诚实的答案必须是：尝试电子，也许？ VSCode 就是用它制作的，所以你知道你可以用它制作一个好的应用程序。

您可以使用您喜欢的任何语言为 Windows 制作应用程序的想法只是一种逃避。在我们的情况下，您可以使用您想要的任何语言制作非常糟糕的 UWP 应用程序。 Bot 至少不是一种很好的方法。

之前在线程中提到的海军事情？完全同意。 Visual Studio - Juggernaut 本身 (UI) 是用托管代码 - WPF 制作的。它很棒，甚至很棒。尽管即使是 Microsoft 也无法使用这种所谓的超级本机代码制作出不错的应用程序。我每天都会看到 OneNote、天气甚至开始/搜索/任务栏出现意外行为。感觉很不稳定，有时注意力不集中。

这是一个丰富而重要的话题。与 WinUI 非常相关，遗憾的是没有更好的地方来谈论它。这些话题需要微软以开放的方式处理。

AndrewPawlowski 于 2020-01-19

👍6

我们对 Windows 上的 UI 有一个愿景和路线图，但它位于堆栈的最顶部，并且对于该表面层下的内容没有愿景：
WinUI 好看吗？是的

是的！

您现在可以在 Windows 上制作现代、美观的应用程序吗（2020 年 1 月）？不

我相信你可以——但这真的很难。琐碎的事情很难做到（我活生生地证明这是可能的，但你肯定需要钢铁般的神经）：

在 UI 方面，会有问题，但通常你会掌握它的窍门
在“任何其他”方面，情况非常暗淡。
由于 StorageFile/Folder API，在 UWP 上处理文件完全是地狱，说中间，我非常讨厌

如果不解决房间里的大象问题，我们就无法真正向前迈进：前面提到过 WinRT 和 UWP 完全失败的事实，不仅在业务方面而且在技术方面都是如此。我个人是身在其中的。当我的应用程序失去焦点时，我无法弄清楚如何播放声音时，我停止了开发我的爱好项目。琐碎的。做微不足道的事情必须和他们一样艰难

同意。确实，播放系统声音，在 WPF 中类似于SystemSounds.Beep.Play() ，它在 UWP 上不可用。

基本上，由于“巨大”的 WinRT 限制，UWP 上没有声音库，这基本上意味着 - 您不能从 win32 的 DLL 中导入任何函数。几乎每个像样的库都无法移植到 UWP。没有图书馆，没有应用程序。

在 UWP 上的“声音库”上，naudio 在 UWP 上已经尽力了。很明显，它掉了下来。我做了一个 fork，删除了很多 #ifdefs，现在它可以满足我的需要。我永远无法将我的应用程序发布到 MS Store，我也不想这样做。

在我看来，朝着正确方向迈出的最好一步是让 MS

最后，首先关注 Windows 桌面。停止追求一千个平台，如 Hololens、Xbox 等。当然，会有人想要为这些平台开发，但这个比例很小。
明智地删除所有限制 API - 这样人们实际上可以将库编译为 UWP
一旦你请求了 BroadSystemAccess，就给它，不要再过度保护了。
一旦您请求了 BroadSystemAccess，就允许 System.IO 通过所有 HDD
使其易于在 MS 商店外分发（+ 修复“新证书”问题）

房间里的另一头大象。如果有人问：我想制作一个新的 Windows 程序，最好的方法是什么？ JAN2020 没有直接的答案！如果您尝试将 UWP 放入答案中 - 您将度过一段不愉快的时光。（有没有一个评论、博客文章、YouTube 视频，其中有人说：我用 UWP 制作了一个很棒的应用程序并且我喜欢这个过程？我们都知道没有。没有人写关于用 UWP 制作应用程序的文章，它确实没有'在互联网上不存在）。 WPF？没有现代控制——

是的，我同意 - 在 UWP 上找到好的资源几乎为零。很多问题，你只需要自己解决和修复。

死技术，不是一个好主意（不过还是比 UWP 好）。诚实的答案必须是：尝试电子，也许？ VSCode 就是用它制作的，所以你知道你可以用它制作一个好的应用程序。

关于WPF我只有赞美之词。我已经开发了好几年了。虽然学习曲线非常陡峭，但一旦掌握了窍门，就会很棒！我确实发现了一些核心错误，我知道这些错误永远不会得到修复，但仅此而已。

我被迫转向 UWP，因为为了使我的应用程序足够快，我不得不使用 win2d。在 UI 方面，UWP 缺少一些东西（例如，在我开始移植时，没有为控件定义Cursor的本机方法），但总而言之，我总能找到解决方法.

之前在线程中提到的海军事情？完全同意。 Visual Studio - Juggernaut 本身 (UI) 是用托管代码 - WPF 制作的。它很棒，甚至很棒。虽然连微软都做不到

很明显，我敢打赌，你不能在我的一生中在 UWP 中创建 Visual Studio —— 我不是在谈论 UI，你可以匹配并超越 Visual Studio 的 UI，但其余的。 ...

这是一个丰富而重要的话题。与 WinUI 非常相关，遗憾的是没有更好的地方来谈论它。这些话题需要微软以开放的方式处理。

100%同意！

jtorjo 于 2020-01-19

👍5

您现在可以在 Windows 上制作现代、美观的应用程序吗（2020 年 1 月）？不
我相信你可以——但这真的很难。琐碎的事情很难做到（我活生生地证明这是可能的，但你肯定需要钢铁般的神经）：
在 UI 方面，会有问题，但通常你会掌握它的窍门
在“任何其他”方面，情况非常暗淡。
由于 StorageFile/Folder API，在 UWP 上处理文件完全是地狱，说中间，我非常讨厌

我们在这里就像被殴打的狗。为 Windows 桌面制作一个新的现代应用程序实际上太难了！难道不应该至少有一种出色的应用程序开发方式吗？当您在 Windows 上访问 Microsoft Store 并尝试滚动应用程序类别时，您将找不到任何使用 UWP 制作的不错的应用程序。顺便说一句，我无法自己检查，因为...

是的，女士们先生们，“现代”、“本地”应用程序。由于 Windows 现在实际上是免费的，因此货币化的主要来源不应该是系统上最可靠的应用程序，但我离题了。您实际上无需研究该应用程序即可了解它是用什么技术制作的。只需看一眼，您就可以判断它是否是使用 UWP 构建的。没有用 UWP 构建的严肃的商业项目，用它构建的是......你知道......

那是因为它太难了。 Window10是继互联网和Android之后最大的平台！！！但是没有人使用据称是为此目的而制作的工具为它制作应用程序！只是考虑一下。使用 UWP 为 3 个操作系统构建 Electron 应用程序比仅用于 Windows 更容易！

对我们这些被殴打的狗来说，只是想构建 Windows 桌面应用程序来要求优秀的工具，这可以吗？我毫无歉意地说是的！但我们所拥有的只是来自微软的无线电静默。谁想听听你的应用程序可以在 Holo Lens、Windows Phone 或 Xbox 上运行的童话故事？没有人。 5 年后，没有任何商业应用程序可以在 2 个为 UWP 承诺的平台上运行。（主要是因为这些平台不退出）。再想想！发生在我们身上的最好的事情是 WinUI 被移植回旧的 win32。

我喜欢 Windows 桌面，我学会了在 WinForms 和 WPF 上编写 C#。对于像我这样的菜鸟来说，这既简单又出色。今天，我对 WinUI 中那些多汁的控件垂涎三尺，但必须有人清楚地了解该平台的全局。我们需要关于实用技术领先地位的明确信息，而不是某些 MS 业务高管的市场抱负。

AndrewPawlowski 于 2020-01-19

🚀6

你好，
我对这次讨论有点晚了，但无论如何还是想发表我的拙见。
关于商业 UWP 应用程序：我想到的一个是 Adobe XD。这个是UWP，感觉非常成熟和完整。
我自己使用 UWP 的经验，作为 .Net 开发人员 13 年：当然，您可以使用它创建外观漂亮、性能良好的应用程序。但是……这不是一次美妙的经历。我们正在创建医疗应用程序，我们也遇到了这里和其他地方已经提到的许多事情：

令人难以置信的慢速文件 API
非常慢的“F5 时间”。因此，进入调试以构建/启动应用程序以尝试某些东西至少比 WPF 慢 10 倍。（在 Surface Book 2 上思考大约 2 分钟）
一般来说，受沙箱限制。
这些只是我头顶上的那些。最后，当 XamlIslands 发布时，我们选择在 WPF 窗口中托管我们完整的 UWP UI，在一切背后都有快速的 .net 核心。我认为没有多少人如此大规模地使用 XamlIsland（从我们创建的 github 问题/PR 得出结论）。然而，这项技术也有一些非常严重的局限性。举个例子，编译时间甚至更长。失去实时编辑 Xaml 的能力。为严肃的 WPF/XamlIsland/UWP 应用程序创建安装程序？好痛。等等...
所以总结起来，创建漂亮的 UWP 应用当然是可以做到的。但它是如此低效和缓慢。并且受到限制。
因此，与其他许多人一样，我们正在兴奋地等待 WinUI 3 的发布和成熟，能够拥有“UWP”前端和 .net 核心（或 .net 5 ;-)）后端而无需任何技巧。

jasonwurzel 于 2020-01-20

@jasonwurzel这些是一些非常好的观点
文件 API 很慢，但与此同时@duke7553在 #1465 中发布了一个解决方法（评论）
确实如此，但当时我们并不知道。多余的说，实现这种解决方法只是为了获得快速的文件 I/O 有点疯狂......
F5 时间确实减慢了速度，我认为可以使用一些改进
我很好奇您在尝试开发常规 UWP 应用程序而不是走 xaml 岛路线时遇到了哪些限制？我现在正在开发一些应用程序，我能够通过包含 Win32 进程来解决任何限制，但我明白这并不总是创建应用程序的理想方式。
我想最终这是我们遇到的障碍的总和，毫无疑问，其中一些可以通过外部流程解决。没有特定的顺序：
观察插入媒体的 CD 托盘/USB 端口
在本地 PC 的任何位置观察用户选择的目录，并让 App/Windows 在更新时记住访问权限
要求broadFileSystemAccess，得到异常，打开相应的Windows设置页面，用户检查App的切换，boom App无预警关闭，没有机会干预。
相同的域：让用户选择一个目录而不必打开 Windows 风格的 FolderPicker（不，我们不想以漂亮和流线型的方式设计我们的全屏应用程序，然后 Windows 对话框跳到用户的脸上）
鸡与蛋的问题：nuget 包的可用性/支持（更多人仍在使用 WPF，因此找到小问题的解决方案要快得多）
控制安装位置

jasonwurzel 于 2020-01-20

🚀2

@AndrewPawlowski我很惊讶你会说，当有很多既现代又好看的优秀 UWP 应用程序时，包括少数在 GitHub 上开源的应用程序。
仅仅因为您没有弄清楚如何做某事而放弃创建应用程序并不意味着平台失败了，这意味着您的应用程序失败了。如果您环顾四周，您会看到许多开发人员努力工作并创建了一些非常好的应用程序，包括在应用程序失去焦点时继续播放声音的应用程序。

我不是说这是不可能的，但这是非常非常困难的。而且我不是在谈论一个简单的“类似记事本”的应用程序，我在谈论一个非常复杂的应用程序，它处理 UI/视频编辑/声音编辑/加载/将大量内容保存到磁盘/（尝试但没有成功) 启动东西（请不要告诉我有关 fullTrust API 的信息）。我说的是 50-100K+ 行代码的应用程序。

那更难。

而且当应用程序失去焦点时您可以播放声音这一事实 - 没有人说您不能，但它应该比现在更容易。

你问是否有人喜欢开发 UWP 应用程序的过程，答案是有很多，最近几个月我收到了很多来自其他开发人员的请求，要求他们提供应用程序的帮助，该平台显然正在引起人们的兴趣。

我同意，这就是我真正着手将我的应用程序移植到 UWP 的原因。但这是一条非常坎坷的道路，现在仍然如此。

您还声称没有人撰写有关开发 UWP 应用程序的文章，我不得不说这是错误的， @rudyhuyn和 Martin Zikmund 只是编写有关 UWP 的开发人员的两个示例，但还有许多其他示例。

我完全同意，但将其与撰写有关 wpf 的人进行比较。这是一滴水。

只需做一个简单的 github 搜索 - “c# wpf”（3701 个结果）与“c# uwp”（337 个结果）。
我确定您是否会搜索相同的内容，并按“提交次数 > 500”（这意味着 - 用户坚持该项目）进行过滤 -> 您会找到一张 waaay 暗淡的图片。

这几乎表明您可以在 2020 年创建好看的应用程序以及现代 UWP 应用程序，并且您的许多陈述并不准确。

我不同意 - 为了能够开发一个 UWP复杂的应用程序并乐于这样做 -> 我们离那还有很长的路要走。

jtorjo 于 2020-01-20

我很好奇您在尝试开发常规 UWP 应用程序而不是走 xaml 岛路线时遇到了哪些限制？我现在正在开发一些应用程序，我能够通过包含 Win32 进程来解决任何限制，但我明白这并不总是创建应用程序的理想方式。

最后，我在 9 月份尝试使用 Xaml Islands 来使用 win2d - 没有一点效果。我尝试了一些 MS 的示例，但它们也不起作用。那时，我意识到我真的需要将我的应用程序移植到 UWP，否则这将永远无法工作。

至于最近的测试 - https://github.com/microsoft/Win2D/issues/731

jtorjo 于 2020-01-20

非常慢的“F5 时间”。因此，进入调试以构建/启动应用程序以尝试某些东西至少比 WPF 慢 10 倍。（在 Surface Book 2 上思考大约 2 分钟）

哦是的！我什至没有提到这一点，但是是的，它非常慢。我通过调整我编译的项目和我不编译的项目来解决它 - 并且取决于我正在处理的应用程序的哪个部分，这是体面的还是可怕的（并且体面，我的意思是，大约 10-15大多数时间是秒）

一般来说，受沙箱限制。

哦耶：）

jtorjo 于 2020-01-20

文件 API 很慢，但与此同时@duke7553在 #1465 中发布了一个解决方法（评论）

同意，但想想有人花了多长时间找到解决方法 - 显然存在，但深深地埋在文档中。而现在，可能很少有人意识到这一点（包括我自己）。

如果您进行谷歌搜索，您将找不到任何显示该解决方法的帖子，因此大多数开发人员可能需要几个月的时间才能意识到它。

jtorjo 于 2020-01-20

@jasonwurzel

因此，与其他许多人一样，我们正在兴奋地等待 WinUI 3 的发布和成熟，能够拥有“UWP”前端和 .net 核心（或 .net 5 ;-)）后端而无需任何技巧。

只是想指出 MS 说一旦 .NET 5 登陆，你就可以将它用于你的 UWP 项目就好了。不需要任何“技巧”或类似 .NET Core 3.x 的情况。这是 .NET 5 公告帖子： https :

Felix-Dev 于 2020-01-20

是的，这就是我所指的👍

jasonwurzel 于 2020-01-20

我认为_“完全脱离现实”_中的“完全”这个词是不公平和不准确的，但@jtorjo出于可以理解的原因感到非常沮丧。如果微软完全脱离现实，那么 WinUI 团队就不会致力于将 WinUI 与 UWP 分开。总的来说，WinUI 团队似乎比 UWP/WinRT 的其他部门更密切。我认为准确的描述是目前某些团队存在某种程度的脱节。

列列表 GUI 的意义

虽然 WinUI 团队可能是所有 UWP/WinRT 相关团队中表现最好的团队，但我认为 WinUI 的项目管理仍然存在一些错误。 带列的列表 GUI （例如DataGrid ）是每个客户每天都使用的基本主流功能（例如在 Windows 资源管理器和各种其他示例中，例如 Spotify 等）。自从 WinRT 启动以来，已经有8 年没有官方支持带列的列表 GUI 了！ 我觉得这种情况令人震惊。出于这个原因和其他原因，我说 UWP 今天仍然是一个 alpha 版本（它的功能还不完整，因此不是一个真正的测试版）。大多数应用程序开发人员从未认真对待 UWP，因此 Windows Mobile 最终被取消，这一点不足为奇。

WinUI 的DataGrid的官方版本已逾期 8 年。在 WinRT 1.0 发布的那一刻，DataGrid 就过期了，因为 Microsoft 不应该启动一个新系统（正如我在之前关于诺基亚等的消息中所解释的那样）。 8 年缺少基础知识，8 年逾期，现在 WinUI 团队希望通过将 DataGrid 降级到本机代码来浪费更多时间，从而使 DataGrid 更加逾期。由于多种原因，很难认真对待 UWP，也很难信任它。

C++/CX 最近被 C++/WinRT 取代

这是“与现实脱节”的另一个例子：
显然，软件需要以理智的方式编写（我的意思是术语“理智”，而不是诸如“你疯了”之类的侮辱）。 “理智”作为术语意味着您不应该使用晦涩复杂的黑魔法来完成简单直接的任务。
C++/CX 最近被 C++/WinRT 取代。 C++/WinRT 使用所谓的 _"curiously recurring template pattern"_ 通过静态调度进行函数调用。这是一个非常糟糕的设计，因为它不是一个理智的设计，因为它是一个使用晦涩复杂的黑魔法来完成简单直接任务的案例。此外，CLR/C#在几十年前就已经解决了这个问题，那么为什么WinRT团队仍然在几十年前已经解决的非常古老和原始的主题上浪费时间？为什么 WinRT 团队要重新发明轮子？

我浏览了 C++/WinRT 的新源代码，我对它的印象是它是一个非常低质量的软件，但 WinRT 团队认为它非常先进。因此，“脱离现实”是一个准确的描述。

UWP 文件系统仍为 alpha 版本

@jtorjo和其他人提到了 UWP 文件系统 API 的性能问题。性能低于将其描述为功能完整的测试版所需的水平。 UWP FS API 仍然是 alpha 版本的另一个原因是缺乏移动文件夹的能力。 25 年前，Windows 95 已经具备移动文件夹的能力，但 UWP 仍然缺少这种基本能力。在某些方面，Windows 95 比 UWP 更强大。从各方面来看，WPF 和 .NET Framework 仍然比 UWP 更强大。微软希望应用程序开发人员认真对待 UWP，但这是非常不合理的（或“与现实脱节”），因为微软从未将 UWP 从 alpha 阶段推进到 beta 阶段。

verelpode 于 2020-01-20

👍4

Windows 假设像“App Dev”这样的移动设备是一个蓬勃发展的市场，并且是现代的，因为它以安全性和电池寿命为核心。

由于市场力量，他们被赶出了移动市场。 Hololens 和 Xbox 等设备正试图取消对 Win32 的旧支持——让他们的开发变得更简单，以及更精简、更高效的操作系统代码库。

这些赌注并没有完全得到回报，但现代应用程序交付和安全模型的理想是值得称赞的目标。

因此，经过一番深思熟虑，Microsoft 决定将现代应用程序框架与 UI 框架分开。

WinUI 3.0 应该是两全其美，允许访问受益于语言投影、现代编码标准和移动熟悉的大多数现代 API。但也允许应用程序使用安全性较低但功能更强大的 Win32 和 .NET 运行时。

当然，依赖 Win32 访问，将限制它们将在哪些平台上运行——谁知道未来几年市场会走向何方。

我建议不要抱怨同样的旧理由和抱怨——这个社区被用来询问开发人员想要什么，而不是以不会推动项目前进的方式责备或咆哮。

mdtauk 于 2020-01-20

👍8

@mdtauk写道：

由于市场力量，他们被赶出了移动市场。

各种 UWP/WinRT 工作人员都非常愿意相信这个解释，以便更好地了解所发生的事情。我不相信这个解释。我认为 UWP 失败的原因是：

管理不善，以及
未能解决应用程序开发人员由于印象 UWP 尚未准备好并且仍未准备好迎接黄金时段而永久推迟其应用程序的 UWP 版本的问题，以及
过度使用非生产性的旧软件工程技术，以及
未能赢得广大应用开发者的信任，以及
使 UWP 看起来很愚蠢的事情，例如促进使用 JavaScript 而不是 Java，这意味着无法识别脚本语言与编程语言之间的区别。

可悲的是，考虑到管理不善是 UWP 失败的主要原因，具有讽刺意味的是，UWP 是用非托管代码编写的，因为“非托管”这个词实际上概括了失败的原因：源代码和项目管理的管理不善。

@jtorjo写道：

本机，在“编译为 .net 本机”的上下文中，我认为是一件好事

我同意。区别在于本机代码的自动生成与手动生成。当本机代码由编译器或工具自动生成时，通常是一件好事，而如果本机源代码是手动编写的源代码，则生产力、功能集和可靠性会受到很大影响。

如果您查看 WPF 开发的时间框架与 WinUI 开发的时间框架，那么 WPF 的开发速度要快得多（生产力要好得多），尽管事实上 WinUI 应该比 WPF 更容易/更快地开发，因为 WinUI 重用了许多相同的_已经_为 WPF 创建的概念。不幸的是，微软选择过度使用旧的软件工程技术，这与他们之前的立场相矛盾，破坏了他们自己的生产力，导致应用程序开发人员不断推迟 UWP 应用程序的开发。

现在可以做些什么来解决过去的错误？停止重复导致 UWP 失败的相同错误。不要继续，好像什么坏事都没有发生一样。我将在这里使用DataGrid作为示例：向DataGrid添加新功能而不是进一步延迟 DataGrid。不要通过进行无用的手动重写/转换为本机代码而使 DataGrid 逾期超过 8 年。

最终用户并不关心 DataGrid 是用托管代码还是非托管代码编写的，而且他们不知道这些术语的含义，因此更重要和明智的是将其与托管代码保持原样并改进DataGrid 的功能/特性。 UWP 中手动编写的原生代码数量已经是灾难性的，为什么还要编写更多的原生代码和基于 Win16/32 和 COM 的过时代码，从而使情况变得更糟？

我知道你不能只是扔掉所有过时的代码，但你可以停止让情况变得比现在更糟。意思是，停止编写更古老的本机代码。制定一项政策，从现在开始，所有新代码/项目都将使用现代软件工程技术编写。不要降级预先存在的托管代码，例如 DataGrid 等。

verelpode 于 2020-01-20

UWP 文件系统仍为 alpha 版本
@jtorjo和其他人提到了 UWP 文件系统 API 的性能问题。性能低于将其描述为功能完整的测试版所需的水平。 [...]

我之前提到过这一点，我将再次提到 - StorageFolder/StorageFile API 是我见过的最糟糕的 API 之一。我们已经进入了 21 世纪，我需要问“哦，拜托，我可以访问这个吗？那个？然后将它们添加到伟大的 FuturesAccessList 中吗？”

我需要异步请求基本属性，例如文件的大小？我不在乎这可能有什么理由，但它现在与现实脱节。

jtorjo 于 2020-01-20

这些赌注并没有完全得到回报，但现代应用程序交付和安全模型的理想是值得称赞的目标。

我完全同意...

[....] 当然，依赖 Win32 访问，将限制它们将在哪些平台上运行——谁知道未来几年市场会走向何方。 [...]

我完全同意，但是，对未来想太多也会很痛苦......
我的意思是 - 如果你从一开始就限制 Win32 访问，移植库将几乎是“不可行的”，所以你不会有现在，更不用说未来了。

通过允许我们也使用 Win32 代码，是的，我们可能无法移植到另一个（即将推出的）平台，但至少我们今天会有代码。明天，那将是另一天，当我们到达那里时，如果我们真的想要的话，我们会想办法移植我们的代码。

但我会做可以选择的事情，我会理解风险。

我建议不要抱怨同样的旧理由和抱怨——这个社区被用来询问开发人员想要什么，而不是以不会推动项目前进的方式责备或咆哮。

不确定这是针对我还是什么，我不是英语母语者。话虽如此，我绝对希望这个项目继续发展，但我确实认为解决一些阻止我们部署的问题很重要——今天。

jtorjo 于 2020-01-20

我建议不要抱怨同样的旧理由和抱怨——这个社区被用来询问开发人员想要什么，而不是以不会推动项目前进的方式责备或咆哮。
不确定这是针对我还是什么，我不是英语母语者。话虽如此，我绝对希望这个项目继续发展，但我确实认为解决一些阻止我们部署的问题很重要——今天。
我不是针对任何人，但讨论的标题有点消极，如果人们围绕着侮辱和指责，他们往往不会回应和解决合法的问题。

此外，现在我们知道 Win32/.NET 应用程序框架将随 WinUI 3.0 一起出现 - 仍然批评它们只是过去的 WinRT 没什么意义。 😁

mdtauk 于 2020-01-20

@jtorjo

我们已经进入了 21 世纪，我需要问“哦，拜托，我可以访问这个吗？那个？然后将它们添加到伟大的 FuturesAccessList 中吗？”

应用程序必须询问用户这一事实在我看来是朝着正确方向迈出的一步。与 Winforms 和 WPF 应用程序不同的是，该应用程序不能简单地扫描我的所有文件，而且我可以控制它可以访问哪些文件夹，这一事实在安全方面非常重要。如果您认为我们限制应用程序可以访问的资源来保护用户是不好的，那么我想这是您的看法，但我不希望每个应用程序都对我的文件做它想做的事情。

我需要异步请求基本属性，例如文件的大小？我不在乎这可能有什么理由，但它现在与现实脱节。

我想理由是它不应该阻塞 UI 线程，因为从 UX 角度可能发生的最糟糕的事情是应用程序不再响应，因为开发人员忘记了磁盘操作可能需要一些时间。使用 await 你可以解决这个问题，它会迫使你在某个时候解除对 UI 线程的阻塞。（至少我是这样理解异步等待的）。

正如@mdtauk正确指出的那样，讨论标题确实有点负面，而不是不断重复同样的老抱怨，这种讨论应该用来提出解决此类问题的想法。

我认为我们都应该牢记遵守 Microsoft 开源行为准则，保持专业讨论并尊重每个人，无论他们是否在场。

https://opensource.microsoft.com/codeofconduct/

chingucoding 于 2020-01-20

👍2

应用程序必须询问用户这一事实在我看来是朝着正确方向迈出的一步。与 Winforms 和 WPF 应用程序不同的是，该应用程序不能简单地扫描我的所有文件，而且我可以控制它可以访问哪些文件夹，这一事实在安全方面非常重要。如果您认为我们限制应用程序可以访问的资源来保护用户是不好的，那么我想这是您的看法，但我不希望每个应用程序都对我的文件做它想做的事情。

因此，与 WPF 应用程序相比，我们从一个巨大的劣势开始。这是一回事 - 另一件事是

我已经在安装时问过了。
即使用户可能不注意，Windows 也可以再次向用户显示“此应用程序想要访问您的文件”，并且用户可以说是/否。我完全可以接受。然而，这与正在发生的事情相去甚远。

我需要异步请求基本属性，例如文件的大小？我不在乎这可能有什么理由，但它现在与现实脱节。
我想理由是它不应该阻塞 UI 线程，因为从 UX 点可能发生的最糟糕的事情是应用程序不再响应，因为开发人员忘记了

文件大小应该是预取的（与上次访问日期/上次写入日期相同）——它非常重要，在您查询文件时应该预取。

正如@mdtauk正确指出的那样，讨论标题确实有点负面，而不是不断重复同样的老抱怨，这种讨论应该用来提出解决此类问题的想法。

我完全想解决这些问题，别无其他。

我认为我们都应该牢记遵守 Microsoft 开源行为准则，保持专业讨论并尊重每个人，无论他们是否在场。

如果我们真的有一个地方可以提出这些问题，并且 WinRT 可以在其他地方听取反馈，那么这个讨论就不会在这里发生。

jtorjo 于 2020-01-20

我不是针对任何人，但讨论的标题有点消极，如果人们围绕着侮辱和指责，他们往往不会回应和解决合法的问题。

我同意这有点消极，再一次，如果有其他地方可以提供有关 WinRT 问题的反馈，这种情况就不会发生。

此外，现在我们知道 Win32/.NET 应用程序框架将随 WinUI 3.0 一起出现 - 仍然批评它们只是过去的 WinRT 没什么意义。 😁

老实说，我真的希望是这样。我当然会等待这些问题得到解决，我个人也等不及那个非沙盒平台可用了。但在那之前，我仍在开发一个应用程序，并且仍然面临我首先概述的问题。

jtorjo 于 2020-01-20

因此，与 WPF 应用程序相比，我们从一个巨大的劣势开始。这是一回事 - 另一件事是

需要明确的是，在您看来，让用户选择拒绝应用程序访问所有文件是一个缺点吗？
我们作为开发人员必须为用户开发软件，而不是针对他们。在我看来，让用户无法选择您的应用程序看到的数据对用户来说是一个安全劣势。

我已经在安装时问过了。

您的意思是“broadFileSystemAccess”功能吗？在我看来，很少有应用程序有正当理由拥有此功能。（正如@kmgallahan已经指出的那样）
只需查看您每天使用的所有应用程序即可。有多少人需要一直访问所有文件？可能没有那么多，如果有的话。

正如您在最初的评论中所说：

你认为用户会很乐意做上面的事情吗？不，他们不会——事实上，79.8% 的人不这样做（我的 AppCenter 数据支持这一点）。

我认为用户不乐意这样做可能是有原因的（除了这是他们必须更改的安全设置这一事实之外）。

但是，我可能不知道需要访问所有文件的所有业务案例，所以如果有的话，我很高兴听到它们。归根结底，我们不是来打架的，而是为了丰富彼此的观点（希望如此）😅

编辑：

文件大小应该是预取的（与上次访问日期/上次写入日期相同）——它非常重要，在您查询文件时应该预取。

哦，对，是的，其中一些绝对应该预先获取。我同意这对我们开发人员来说有些不方便。

如果我们真的有一个地方可以提出这些问题，并且 WinRT 可以在其他地方听取反馈，那么这个讨论就不会在这里发生。

官方反馈中心是为此（我认为）但是是的，有时感觉有点反应迟钝。希望反馈中心改进。据我所知，随着时间的推移，他们已经对其进行了一些更改，所以我认为这也有望改变。

chingucoding 于 2020-01-20

@Felix-Dev

这是 .NET 5 公告帖子

感谢您链接到那个。我特别觉得这部分很有趣，我相信这是个好消息：

“Java 互操作性将在所有平台上可用。

在该网页末尾的评论中还有一些 Java 讨论，其中 Rich Lander 确认了双向互操作。我将此解读为微软正在回归现实的积极信号。我不喜欢 Java（我更喜欢 C#），但我承认 Java 互操作性非常有益，从一开始就应该成为 UWP/WinRT 的重点。如果 UWP/WinRT 将 Java 和 C#（托管代码）放在首位，而不是笨拙的旧本机代码（C++/CX、Win16/32、COM），如果 UWP 没有混淆 JavaScript 与 Java 的目的，那么 UWP 会吸引更多的应用程序开发人员，而 Windows Mobile 很可能在今天还活着。

不管喜欢与否，有必要清醒过来承认现实情况：市场领导者是 Android，它专注于 Java 应用程序开发。 Java 和 C# 表示托管代码。当微软改变其对托管代码的立场时，它犯了一个代价高昂的错误。

尽管我不是很喜欢 Java，但我很清楚 Android 的 Java 技术比 Microsoft 使用古老的 Win16 编程技术（例如 16 位与 32 位指针）开发 WebView2 的笨拙旧方式要好得多和HRESULT而不是现代异常处理等。WebView2 使用LPCWSTR并且L表示“长指针”，表示 32 位指针，而不是 16 位指针Win16 中的“短”指针。 W表示“宽字符”，表示 Unicode (UTF-16)，而不是 8 位 ASCII/ANSI 字符。相比之下，Android 对 Java 的使用远比微软的某些部门正在做的更专业、更现代、更值得信赖。

所以从积极的方面来说，听到微软将支持 Java 真的是个好消息（尽管我个人更喜欢 C# 而不是 Java）。一旦发布了可靠的 Java 互操作，Android 应用程序开发人员就会增加他们对 Windows 的兴趣。

verelpode 于 2020-01-20

此外，现在我们知道 Win32/.NET 应用程序框架将随 WinUI 3.0 一起出现 - 仍然批评它们只是过去的 WinRT 没什么意义。 😁

未来是光明的，我喜欢在 WinUI 中开发的东西。
过去是相当惨淡的，对于一个拥有 9 亿台设备的平台来说，UWP 的普及率很低是很难辩护的。编辑：过去是我们唯一可以学习的地方，所以讨论很重要。
我认为，现在是这个线程的重点，它没有被解决。如果有人想从今天开始开发一个需要 1-1.5 年才能开发的非平凡应用程序，可以给出哪些诚实的建议？我的答案是：尝试使用 WinUI，在 dotnet Core 中创建库，然后等待 WinUI3.0 出来真正开始创建您的应用程序。不要理会 UWP，因为无论如何你都想把它从你的应用程序中扔掉，你可能不想要不同的平台，因为 9 亿个平台已经足够大了。关于当下的问题并非微不足道，业务决策需要在今天做出。

没有说什么，但真正发生的是 UWP 和现代 UI 没有扩展到 win32，但实际上 UWP 正在重构出堆栈。当他们可以使用 dotnet standard 2 和 dotnet core 3 的强大功能以及所有可用的库时，为什么有人想要处理 UWP？

关于沙盒和 UWP 中引入的其他好主意：它们是好主意，但本可以更好地执行。我希望他们会回来，并且有可能 OPT-IN 进入沙箱或 OPT-IN 进入类似于 UWP 的状态管理。作为开发人员，我们希望为用户提供服务，但在 UWP 中，我们受到了平台需要包含的问题的威胁。

可以给出哪些诚实的建议？等待？

AndrewPawlowski 于 2020-01-20

😕1 👍1

@AndrewPawlowski如果您确定 UWP 和沙箱不适合您，我认为在 WinUI 3 登陆之前编写一个 MSIX 打包的 WPF 应用程序是一个不错的选择。您已经可以调用 Windows 10 专有 API，为用户提供现代安装/卸载体验，并且通常从 Windows 10 API 界面中选择您喜欢和不喜欢的内容（即您可以开始使用 Windows 10 Shell API）。与过去的 win32 方式相比，一些 WinRT API 使用起来真的很有趣，我认为某些场景甚至在 DesktopBridge 上做得最好，而不是纯 UWP。举个例子：注册一个应用程序以在登录时自动启动，请参阅此帖子以了解 UWP 与 DesktopBridge 行为的比较。在 DesktopBridge 的情况下，您最终仍然让用户控制，但在启用 start at log 时，用户不会经常被询问两次（首先是应用程序中的切换，然后是要求确认的系统提示）-在应用程序中。

不幸的是，与 UWP UI API 相比，WPF API 的许多部分现在确实显示出它们的年龄，因此您只需要再忍受几个月（至少）。许多可用的 WPF 工具包将缓解这一事实，但如果您真的想要 Windows 桌面应用程序的本机外观（以及现代 XAML 开发体验！），您真的将无法逃避 UWP UI API（和之后的 WinUI 3 API）。这意味着，即使您以后可以为 WinUI 重新使用一些 WPF UI 代码，我相信 UI 的现代化仍然是一个相当大的工作项目。

如果您不能等到 WinUI 3 发布并且 UWP 不适合您，这就是我目前为您看到的本机 Windows 应用程序开发的状态。

Felix-Dev 于 2020-01-20

👍1

@AndrewPawlowski

未来是光明的，我喜欢在 WinUI 中开发的东西。

同意

过去是相当惨淡的，对于一个拥有 9 亿台设备的平台来说，UWP 的普及率很低是很难辩护的。编辑：过去是我们唯一可以学习的地方，所以讨论很重要。
我认为，现在是这个线程的重点，它没有被解决。如果有人想从今天开始开发一个需要 1-1.5 年才能开发的非平凡应用程序，可以给出哪些诚实的建议？我的答案是：尝试使用 WinUI，在 dotnet Core 中创建库，然后等待 WinUI3.0 出来真正开始创建您的应用程序。不要理会 UWP，因为

我最初的想法是一样的，但我没有等待......

关于沙盒和 UWP 中引入的其他好主意：它们是好主意，但本可以更好地执行。

同意 100%

jtorjo 于 2020-01-20

但是，我可能不知道需要访问所有文件的所有业务案例，所以如果有的话，我很高兴听到它们。归根结底，我们不是来打架的，而是为了丰富彼此的观点（希望如此）😅

在任何您想要预览内容的地方，您都需要快速访问文件。就我而言，我想预览文件夹以直观地向用户显示照片/视频所在的位置，对于视频，我希望用户在选择视频之前预览视频。重点是：文件选择器提供了相当差的体验，我想丰富它。

官方反馈中心是为此（我认为）但是是的，有时感觉有点反应迟钝。希望反馈中心改进。据我所知，随着时间的推移，他们已经对其进行了一些更改，所以我认为这也有望改变（^∇^）

我个人不喜欢反馈中心——它太不具体了，还有其他问题。

jtorjo 于 2020-01-20

@jtorjo @chingucoding WinRT API 反馈中心可能很快会被 Microsoft Q&A 替换/配对，请查看此提交： https :

看到那里提到了 Chigusa： @chigy微软问答平台会成为非 WinUI WinRT API 的首选反馈平台吗？如果不是，它与反馈中心有什么关系（即在问答中提交错误/问题，反馈中心上的 API 请求，......）？

希望我们不会以三个不同的反馈平台结束 😆

Felix-Dev 于 2020-01-20

由于这是关于 UWP 的讨论，我可以提出一个功能请求：允许上下文菜单动词与文件资源管理器集成，而无需文件类型关联https://aka.ms/AA71n2t btw。 https://aka.ms/AA6rmrk （但它属于错误的类别 - 也许有人可以解决这个问题？）

功能请求的一个很好的来源是：
https://web.archive.org/web/20161221051552/https://wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
太糟糕了，这个用户声音的快照很旧（2016）。我记得有这样的东西：

调整 BroadFileSystemAccess 请求的行为，就像它在请求相机、位置、启动时启动应用程序时的行为一样......
汽车。打印（据我所知，目前仅支持物联网上的 POS）
使打印更具可配置性

mfe- 于 2020-01-20

@jtorjo

在任何您想要预览内容的地方，您都需要快速访问文件。就我而言，我想预览文件夹以直观地向用户显示照片/视频所在的位置，对于视频，我希望用户在选择视频之前预览视频。重点是：文件选择器提供了相当差的体验，我想丰富它。

我的猜测是，您首先让用户选择一个他想要使用您的应用程序的文件夹。毕竟，用户最了解他保存视频的位置。

否则你可能想看看：
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

但老实说，我不知道在这种情况下，broadFileSystemAccess 究竟会帮助你什么。您无法确定文件的确切位置（与用户不同）。但也许我没有完全正确理解你的应用程序的想法。

@Felix-Dev
感谢提供信息，不知道 WinRT 反馈可能会移动。

希望我们不会以三个不同的反馈平台结束 😆

哈哈，是的，希望不是！

chingucoding 于 2020-01-20

@jtorjo -- 您是否考虑过取消将您的应用程序从 WPF 移植到 UWP？您可以取消它并等待 WinUI 3 发布，然后您就不会被迫使用有问题的 UWP 文件系统 API、broadFileSystemAccess 等。同时，在您等待 WinUI 3 的同时，您可以继续通过继续开发应用程序的 WPF 版本，向用户提供应用程序的新版本。

在 WinRT 开始的 8 年中，我们实际上从未向用户提供任何 WinRT 或 UWP 应用程序。相反，我们为他们提供了许多继续使用我们软件的 WPF 版本的更新。我们的用户对此的抱怨为零，因为他们不关心 WPF、WinUI、UWP 等技术细节，而是关心应用程序的运行情况及其功能。我们的用户也没有对旧的 GUI 有任何抱怨，因为我们的 WPF 应用程序包括一堆 GUI 现代化。

@AndrewPawlowski说“使用 WinUI 进行实验”。是的，实验。多年来，我为 UWP 和 WinUI 编写了大量代码，但它们都是实验性、alpha 或 beta 代码。我从来没有达到过可以轻松地向用户发布任何 UWP 应用程序的地步。

WinUI 3 与 UWP 的分离是一个很大的帮助，但我认为这不是一个完整的解决方案。 WinUI 3 没有解决 WinUI 低生产力/开发速度缓慢的问题：WPF 的开发速度比 WinUI 快得多，尽管 WPF 比 WinUI 更难。

WinUI 团队表示，当 WinUI 3 开源时，速度会加快，也许会，但我个人不会为 WinUI 3 编写任何 C++/CX、C++/WinRT、Win16/32 或 COM 贡献。我几十年前，我的职业生涯是从 Win16/Win32 开始的，Win32 是一场噩梦，我无意恢复到如此陈旧且有问题的编程技术。多年来，我不断更新我的软件工程技能，并切换到 C# 和 .NET Framework，这是一个重大的改进和好处，我不会回到旧的 Win16/32 的噩梦天和大量手动编写的本机代码。

@AndrewPawlowski写道：

可以给出哪些诚实的建议？等待？

这真是一个很难回答的问题。一方面，是的，等待 WinUI 3，但另一方面，WinUI 3 并没有完全解决 8 年前由 WinRT 引发的大问题。 WinUI 3 是一个有用的部分解决方案。

verelpode 于 2020-01-20

来自 Ignite 的精彩视频： https :

我认为这里的很多讨论都质疑 WinRT 的目的。开发人员和用户仍然想知道一旦 WinUI 3 和 .NET 5.0 允许不同技术之间轻松互操作，它将扮演什么角色。更不用说，最终能够在沙盒与经典应用程序模型之间进行选择。

我认为编写新的 WinRT API 对微软来说更容易在内部完成，这解释了为什么他们之前多次声明大部分 API 层创新将在 WinRT 中完成。这意味着对于新的现代 Windows 应用程序，使用 WinRT 是有意义的，因为它将与新的外形因素带来的新体验进行最新和最好的集成。 WinRT 仅旨在成为在 Windows 上的 .NET 应用程序中点亮的一组特定通用 API。

话虽如此，我认为我们都同意，如果 UWP 桌面扩展包与现有的 Windows Shell 具有更好的集成能力，它将使通用应用程序更有价值。

谁知道呢，微软可能计划最终用 Windows 10X 等中较新的 Composable Shell (CShell) 替换 Windows Explorer Shell。Twitter 上的专家还发现了 Windows 中的一个新的 UDK（Undocked Development Kit），它可能允许将来可以更好地与这个新 shell 集成。

duke7553 于 2020-01-20

👍1

@AndrewPawlowski

您可能不想要不同的平台，因为 9 亿个平台已经足够大了。

虽然我明白你的意思，但你必须意识到 UWP 和 .NET 不再是这些相互排斥的东西，所以如果启动具有通用功能的应用程序是有意义的，那么应该投资于理解 WinRT 的部分内容。

我离题了。作为使用纯 UWP 应用程序模型构建 Windows 文件资源管理器竞争对手的人，WinUI 3 的速度不够快。在不久的将来，您将不必在使用通用功能和“9 亿用户”之间做出选择😀

duke7553 于 2020-01-20

@jtorjo我建议将标题更改为一个不那么负面的标题，因此更多的人会在这里提供输入。
也许是“为 WinRT 增加价值的机会”

duke7553 于 2020-01-20

@verelpode

@jtorjo -- 您是否考虑过取消将您的应用程序从 WPF 移植到 UWP？您可以取消它并等待 WinUI 3 发布，然后您就不会被迫使用有问题的 UWP 文件系统 API、broadFileSystemAccess 等。同时，在您等待 WinUI 3 的同时，您可以继续通过继续开发应用程序的 WPF 版本，向用户提供应用程序的新版本。

我想了很长时间——这就是我想做的。但我不能不这样做，因为我真的需要 win2d（或者更重要的是，一个很好的 Direct2D 包装器）。 ShapDX（Direct2D 的另一个包装器）看起来要复杂得多，所以我选择使用 win2d（即 UWP）。因此，将所有内容移植到 UWP。

jtorjo 于 2020-01-21

我的猜测是，您首先让用户选择一个他想要使用您的应用程序的文件夹。毕竟，用户最了解他保存视频的位置。

你真的真的把你的生命押在这个上面吗？我不会 - 很明显，如果您是高级用户，您可能会被疯狂地组织起来，并且知道每件事情的位置。除此以外....

然后，每当您（用户）以某种方式将照片/视频复制到新文件夹时，您都需要记住告诉我的应用程序也包含该文件夹...

并不是说“伟大的” FutureAccessList - 并没有真正指定 -> 如果我添加一个文件夹，我的应用程序是否可以访问它的所有子文件夹？

另外，如果我向 FutureAccessList 添加了一些东西，我是否需要从那里检索它，或者我可以使用 GetFolderFromPathAsync/GetFileFromPathAsync（是前者，我宁愿跳下悬崖）？

您是否知道，如果使用 FutureAccessList.AddOrReplace，并使用文件的路径作为标记，您会得到一个异常？多么周到......（描述中没有）

jtorjo 于 2020-01-21

WinUI 3 和 .NET Core 将是未来的一个选项 - 我认为这种组合在没有 UWP 沙箱的情况下与 WPF 的工作方式相同，但具有更新的 XAML 控件、可视层和简单的 WinRT API 访问。

mdtauk 于 2020-01-21

我的猜测是，您首先让用户选择一个他想要使用您的应用程序的文件夹。毕竟，用户最了解他保存视频的位置。

你真的真的把你的生命押在这个上面吗？我不会 - 很明显，如果您是高级用户，您可能会被疯狂地组织起来，并且知道每件事情的位置。除此以外....

那么如果用户不知道他的视频保存在哪里，你的应用应该怎么做？扫描系统中的所有文件，即使使用最快的软件也可能需要几个小时？至少对我来说，这似乎不是一次好的体验。毕竟，如果您的应用针对的是想要对视频做一些事情的用户，那么用户已经在某种程度上“有组织”了，他们知道他们知道他们在某处有视频。但同样，只是我的想法，并不真正了解您的应用程序和特定的业务案例。

然后，每当您（用户）以某种方式将照片/视频复制到新文件夹时，您都需要记住告诉我的应用程序也包含该文件夹...

我认为如果您有权访问父目录，您还可以访问未来的子文件夹（虽然我不是 100% 确定）。

您是否知道，如果使用 FutureAccessList.AddOrReplace，并使用文件的路径作为标记，您会得到一个异常？多么周到......（描述中没有）

这很奇怪，这是绝对应该记录的事情！

就我个人而言，我并不是真正喜欢请求“broadFileSystemAccess”的应用程序，因为它们中的很多都不需要它。也许在某些情况下它是有意义的（编写文件资源管理器等）但是很多需要访问某些文件夹的情况不应该继续说“请允许我访问所有文件”，因为您也可以要求特别是那个文件夹。

但也许我不知道足够的商业案例。如果有更多，我很乐意听到他们的声音！

chingucoding 于 2020-01-23

但也许我不知道足够的商业案例。如果有更多，我很乐意听到他们的声音！

工具和实用程序软件，例如（解）压缩工具。如果您想在当前文件所在的同一目录中提取压缩文件，并且当应用程序被 Windows 资源管理器上下文菜单调用时，您只能获得对所选文件的写访问权限。因此将无法创建新文件或目录（对于未压缩的文件）。
- 如果用户将文件拖到您的 uwp 应用程序中，您将无权写入这些文件！
  https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

mfe- 于 2020-01-23

就像一个（解）压缩工具。如果您想在当前文件所在的同一目录中提取压缩文件，并且当应用程序被 Windows 资源管理器上下文菜单调用时，您只能获得对所选文件的写访问权限。因此将无法创建新文件或目录（对于未压缩的文件）。

我认为当您右键单击单个文件时是否应该访问整个文件夹是很有争议的。虽然 tbh 我通常在压缩/解压缩时指定一个不同的文件夹，因为我通常只需要它们用于“交换”，即备份或下载/上传。所以对我来说几乎有必要指定文件的确切保存位置。但这可能是一个有效的用例，具体取决于用户的选择 😅

如果用户将文件拖到您的 uwp 应用程序中，您将无权写入这些文件！
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

好吧，对于用户和开发人员来说，这似乎有点过于复杂了。我原以为您至少可以获得对删除的文件的写访问权限。在我看来，这对开发人员来说只是一个不必要的限制。

尽管至少在我日常使用应用程序中，我只将文件放入 GitHub 评论中。对于其他情况，我只是双击或右键单击，但在某些情况下同意这不是很好。我想毕竟有一些情况可以访问所有文件。

chingucoding 于 2020-01-23

那么如果用户不知道他的视频保存在哪里，你的应用应该怎么做？扫描系统中的所有文件，即使使用最快的软件也可能需要几个小时？ ...

显然有很多可能性，其中之一是，当用户展开文件夹时，为他预览 - 这样他就可以轻松查看哪些文件夹有照片/视频，哪些没有。如果 Windows 允许我，我的应用程序实际上会做一件事

就我个人而言，我并不是真正喜欢请求“broadFileSystemAccess”的应用程序，因为它们中的很多都不需要它。

我无所谓。 WinRT 沙箱的文件系统保护模型与现实脱节。这是有人从伟大的“移动优先”口号中汲取的东西，它根本不适用于桌面。

事实上，沙盒文件/文件夹的一种更聪明的方法是让用户决定他想要保护哪些文件/文件夹 - 应该有一种非常简单的方法来做到这一点（例如，也许在文件资源管理器中，使用右键单击命令） .

这与默认情况下阻止所有内容形成对比，然后用户无意中错误地让您访问机密文件。

让我在这里坦率地说 -任何非平凡的应用程序都不是生活在真空中。

jtorjo 于 2020-01-24

显然有很多可能性，其中之一是，当用户展开文件夹时，为他预览 - 这样他就可以轻松查看哪些文件夹有照片/视频，哪些没有。如果 Windows 允许我，我的应用程序实际上会做一件事

是的，这是一种可能性。但是你什么时候要扫描文件夹？用户究竟可以在您的应用中展开哪些文件夹？

我无所谓。

你到底想在这里说什么？

事实上，沙盒文件/文件夹的一种更聪明的方法是让用户决定他想要保护哪些文件/文件夹 - 应该有一种非常简单的方法来做到这一点（例如，也许在文件资源管理器中，使用右键单击命令） . 用户将清楚地知道哪些文档/文件是机密的，并保护它们。

我认为整个访问保护不仅涉及“机密”文件，还涉及一般隐私，例如配置文件（通常隐藏在用户看不到的文件夹中）或仅涉及安装了哪些程序。这些是我不希望每个程序都能够访问的信息，尤其是您所说的“琐碎应用程序”。

还有一个现实世界的类比 - 想想 seifs。

是的，你可以把东西放在保险箱里。但这并不能改变您拥有公寓或家的钥匙这一事实。但是说每个程序都可以访问除保险箱中的所有内容就像说，您的公寓不需要门，因为您有一个可以存放贵重物品的保险箱。

这与默认情况下阻止所有内容形成对比，然后用户无意中错误地让您访问机密文件。

这种错误在两种情况下都可能发生，但我认为忘记锁定机密文件的可能性更大，而不是意外授予访问机密文件的权限。

让我在这里坦率地说 - 任何非平凡的应用程序都不会存在于真空中。它需要从某处（输入）获取数据并将其输出到某处。输入和输出通常是文件 - 您需要与其他应用程序等互操作。而 WinRT 只是让我无法设计一个漂亮的 UI 来提供给我的用户。

在这里说不可能是一种延伸，因为有很多很棒的 UWP 应用程序（尽管不幸的是不是很多）。

chingucoding 于 2020-01-25

是的，这是一种可能性。但是你什么时候要扫描文件夹？用户究竟可以在您的应用中展开哪些文件夹？

您熟悉 Windows 资源管理器的概念吗？你展开一个文件夹或驱动器——那是我开始扫描的时候

我认为整个访问保护不仅涉及“机密”文件，还涉及一般隐私，例如配置文件（通常隐藏在用户看不到的文件夹中）或仅涉及安装了哪些程序。这些是我不希望每个程序都能够访问的信息，尤其是您所说的“琐碎应用程序”。

如果应用程序将其文件保存在自己的“只有此应用程序可以访问它”文件夹中，则这不是问题。

这与默认情况下阻止所有内容形成对比，然后用户无意中错误地让您访问机密文件。
这种错误在两种情况下都可能发生，但我认为忘记锁定机密文件的可能性更大，而不是意外授予访问机密文件的权限。

我完全不同意-“机密”的全部意义应该让您想要锁定该文件。

在这里说不可能是一种延伸，因为有很多很棒的 UWP 应用程序（尽管不幸的是不是很多）。

你在这里自相矛盾。但是，让我们深入了解出色的 UWP 应用程序的庞大性：

注意“大量”喜欢，它应该告诉你有多少人在使用它。我想与苹果商店进行对比，但我不能，因为我没有苹果。但是让我们看看 Android - Facebook 有 70 多万条评论（相比之下在 Windows 上有 1353 条）。 Instagram 有超过 93 万条评论（这里有 1578 条评论）。而且我几乎可以肯定 Facebook 和 Instagram 实际上都是电子应用程序，而不是 UWP。

jtorjo 于 2020-01-25

您熟悉 Windows 资源管理器的概念吗？你展开一个文件夹或驱动器——那是我开始扫描的时候

因此，您正在构建类似于 Windows 资源管理器的内容，可以预览文件夹中的视频文件？

如果应用程序将其文件保存在自己的“只有此应用程序可以访问它”文件夹中，则这不是问题。

因此，一方面，应用程序通常应该可以访问所有文件，但另一方面，某些文件和文件夹将被用户锁定（因为他只有“机密”文件，而其他所有文件都是自动非机密的），而某些文件夹是被应用程序本身阻止？如果我想编写一个应用程序来处理由程序生成的文件怎么办？每个备份程序都会因为无法备份程序而失败吗？我不太确定这会如何解决，如果我在这里误解了你的想法，我很抱歉。

我完全不同意-“机密”的全部意义应该让您想要锁定该文件。

那么究竟什么是我不选择保密的呢？我不希望每个应用程序都能看到我的假期照片，但 Photoshop 应该能够看到它们。那么他们是否保密？或者这个机密的“标志”是一个程序列表，某些文件对于某些应用程序来说是不机密的？

你在这里自相矛盾。

是的，我的措辞在那里很垃圾。对于那个很抱歉。我想表明肯定存在很好的非“平凡”应用程序，它们运行良好。

注意“大量”喜欢，它应该告诉你有多少人在使用它。我想与苹果商店进行对比，但我不能，因为我没有苹果。但是让我们看看 Android - Facebook 有 70 多万条评论（相比之下在 Windows 上有 1353 条）。 Instagram 有超过 93 万条评论（这里有 1578 条评论）。而且我几乎可以肯定 Facebook 和 Instagram 实际上都是电子应用程序，而不是 UWP。

这不是 UWP 的问题，而是以下事实：

人们通常不倾向于写评论
iTunes 商店/Google Play 商店比 Microsoft 商店老得多
微软商店在用户中的反响不佳，开局不佳
大多数公司更喜欢开发网站而不是平台受限的应用程序

而且我几乎可以肯定 Facebook 和 Instagram 实际上都是电子应用程序，而不是 UWP。

很难判断它们是否是电子的，因为网站和应用程序看起来大不相同。基于对话框看起来几乎与默认对话框完全相同的事实，它们可能是 UWP 应用程序。

chingucoding 于 2020-01-26

因此，您正在构建类似于 Windows 资源管理器的内容，可以预览文件夹中的视频文件？

这是我的应用程序向导的一部分。

因此，一方面，应用程序通常应该可以访问所有文件，但另一方面，某些文件和文件夹将被用户锁定（因为他只有“机密”文件，而其他所有文件都是自动非机密的），而某些文件夹是被应用程序本身阻止？如果我想编写一个应用程序来处理由程序生成的文件怎么办？

我的想法与我们现在的想法相反。我并不是说它是完美的，远非如此——但任何事情都比现在发生的要好。因此，默认情况下，您可以访问所有非机密文件。如果您需要访问机密文件，则需要先询问。

那么究竟什么是我不选择保密的呢？我不希望每个应用程序都能看到我的假期照片，但 Photoshop 应该能够看到它们。那么他们是否保密？或者这个机密的“标志”是一个程序列表，某些文件对于某些应用程序来说是不机密的？

在我看来，这个“标志”会将文件或文件夹变成“拒绝访问”。如果你真的想访问它，你可以请求许可，用户可以选择给你或不给你（并且许可可以是 - 只是这一次，或永远）。

是的，我的措辞在那里很垃圾。对于那个很抱歉。我想表明肯定存在很好的非“平凡”应用程序，它们运行良好。

我不是说没有。我是说，与 WPF 相比，制作一个非常困难。
我是说我在浪费时间处理根本不应该存在的问题。

例如，有时，我得到一个异常（COM 异常，具体来说），而不是在失败点得到它，我实际上是在另一个线程中得到它，而且大多数时候，甚至堆栈跟踪是丢失。弄清楚发生了什么是非常非常痛苦的。

另一个问题是整个“让信息异步”的口头禅——我非常讨厌。我正在处理需要立即进行的渲染，但位图的加载是异步的。所以我不得不为此构建一个非常复杂的缓存机制。

让我们不要进入编译时间。最近有时在构建时，我得到一个“...dll 是在发布模式下构建的”（这基本上不可能，因为我正在构建调试）。解决方法是简单地清理所有解决方案并重建（这需要 1 分钟以上）。

是的，崩溃了。 VS 每运行 10-20 次就会崩溃一次，这让我很不解。

这些是我刚才想到的问题。还有无数。

这不是 UWP 的问题，而是以下事实：
人们通常不倾向于写评论
iTunes 商店/Google Play 商店比 Microsoft 商店老得多
微软商店在用户中的反响不佳，开局不佳
大多数公司更喜欢开发网站而不是平台受限的应用程序

好吧，我希望我能有一个苹果商店的比较——我很确定他们的顶级应用程序有数百万条评论。这个想法是 MS 商店从未流行过 - 因为人们只是放弃了 UWP/WinRT。如果我不需要 win2d，我至少会放弃 20 次。

想想看 - 作为 UWP 应用程序，我需要让 Windows 全屏显示。这简直太疯狂了。更愚蠢的是，这只适用于下一次运行。

我正在查看“抓取屏幕截图”API - 我只是放弃了它，它没用。我基本上想有一个很酷的方式来启动应用程序，基于当前屏幕（有点，过渡到我的应用程序）-> 这是不可能的，因为它需要用户交互（即，用户必须说 - 是的，我想允许抓取屏幕截图，这会破坏整个事情）

让我不要从剪贴板开始——它仅在您的应用程序处于前台时才有效。更有趣的是，微软认为“我们会在调试时让你随时访问剪贴板”，但在发布时，你会得到一个很好的“拒绝访问”异常。你知道我花了多少个小时才最终弄清楚这就是为什么我的应用程序无法在 Release 中启动（而在 Debug 中一切都只是花哨的）

名单还在继续——我想我可以写一本书。当然，UWP/WinRT 理论上很酷。但是当你开始使用时，哦，好吧..

很难判断它们是否是电子的，因为网站和应用程序看起来大不相同。基于对话框看起来几乎与默认对话框完全相同的事实，它们可能是 UWP 应用程序。

是的，我的观点是 - 人们放弃 UWP 应用程序 - 它带来的许多问题超过了好处。

jtorjo 于 2020-01-26

@jtorjo
（只是为了确保你知道它。）

让我不要从剪贴板开始——它仅在您的应用程序处于前台时才有效。

我在开发我的一个 UWP 应用程序期间遇到了相同（或类似）的问题，我必须将数据放在剪贴板上，最后我通过随附的 win32 完全信任进程（仅调用 Win32 的SetClipboardData ）解决了该问题。如果为您的 UWP 应用程序提供随附的 win32 完全信任进程的概念对您来说是新消息，那么您可以在这里很好地进行介绍（作者之前曾在 Microsoft 从事 UWP 工作）。

Felix-Dev 于 2020-01-26

@Felix-Dev

我在开发我的一个 UWP 应用程序期间遇到了相同（或类似）的问题，我必须将数据放在剪贴板上，最后我通过随附的 win32 完全信任进程（仅调用 Win32 的SetClipboardData ）解决了该问题。如果为您的 UWP 应用程序提供随附的 win32 完全信任进程的概念对您来说是新消息，那么您可以在这里很好地进行介绍（作者之前曾在 Microsoft 从事 UWP 工作）。

谢谢指点！我确实知道 win32 完全信任过程。我可能已经多次阅读这些文章 :) 我实际上曾多次考虑过拥有一个 win32 完全信任流程伴侣应用程序。我选择不这样做，因为增加了复杂性 - 我已经在努力生成在没有 MS 商店的情况下实际工作的设置工具包。我只是不想把它带入等式。

jtorjo 于 2020-01-26

因此，您正在构建类似于 Windows 资源管理器的内容，可以预览文件夹中的视频文件？

这是我的应用程序向导的一部分。

那种听起来像是带有额外步骤的文件浏览器(⊙ˍ⊙)

我的想法与我们现在的想法相反。我并不是说它是完美的，远非如此——但任何事情都比现在发生的要好。因此，默认情况下，您可以访问所有非机密文件。如果您需要访问机密文件，则需要先询问。

所以基本上，最终，您的应用程序可能会遇到与现在相同的问题，因为您永远不会知道文件是否机密。那些将所有内容都标记为机密的用户呢？因此，您刚刚创建了与现在相同的系统，但您可以访问更多变体。

例如，有时，我得到一个异常（COM 异常，具体来说），而不是在失败点得到它，我实际上是在另一个线程中得到它，而且大多数时候，甚至堆栈跟踪是丢失。弄清楚发生了什么是非常非常痛苦的。

如果你经常遇到这种情况，那就太烦人了。然而，对我来说，几乎所有发生在我身上的异常（例如在 XCG 中）都有一个 StackTrace 关联，有时甚至是有用的异常消息。所以我真的不能说什么，因为这对我来说从来都不是问题。

另一个问题是整个“让信息异步”的口头禅——我非常讨厌。我正在处理需要立即进行的渲染，但位图的加载是异步的。所以我不得不为此构建一个非常复杂的缓存机制。

有时 async 有点烦人，但是在大多数情况下，async 方法有理由成为 async，因为您不想在诸如网络或文件操作之类的操作上阻塞 UI。话虽如此，您可以使用以下方法同步运行异步方法：

```c#
// 将阻塞线程直到 MyAsyncMethod 完成
var myResult = MyAsyncMethod().Result;

// 这也将在方法完成执行时完成。
// 请注意，ConfigureAwait 可能会导致该方法在不同的上下文中被调用
var myResult2 = MyAsyncMethod().ConfigureAwait(false);
`` For ConfigureAwait` 可以看看下面的文章： https :

让我们不要进入编译时间。最近有时在构建时，我得到一个“...dll 是在发布模式下构建的”（这基本上不可能，因为我正在构建调试）。解决方法是简单地清理所有解决方案并重建（这需要 1 分钟以上）。

“...dll”内置于发布模式很奇怪。也许检查项目文件是否不连贯？关于编译时间，是的，这有点烦人，虽然 ~1 分钟还是可以的，WinUI 大约需要 5-10 分钟😅

是的，崩溃了。 VS 每运行 10-20 次就会崩溃一次，这让我很不解。

是的，这很烦人，虽然我不认为这真的依赖于 UWP，而只是一般的 Visual Studio（出于某种原因，它仍然是一个 32 位进程！）。

好吧，我希望我能有一个苹果商店的比较——我很确定他们的顶级应用程序有数百万条评论。这个想法是 MS 商店从未流行过 - 因为人们只是放弃了 UWP/WinRT。如果我不需要 win2d，我至少会放弃 20 次。

似乎您可以将 Win2D 与 WPF 一起使用： https :

想想看 - 作为 UWP 应用程序，我需要让 Windows 全屏显示。这简直太疯狂了。更愚蠢的是，这只适用于下一次运行。

即使在启动时，也可以让您的 UWP 应用程序处于全屏模式： https :
（虽然我还没有尝试过提交应用程序）

我正在查看“抓取屏幕截图”API - 我只是放弃了它，它没用。我基本上想有一个很酷的方式来启动应用程序，基于当前屏幕（有点，过渡到我的应用程序）-> 这是不可能的，因为它需要用户交互（即，用户必须说 - 是的，我想允许抓取屏幕截图，这会破坏整个事情）

大多数用户不希望应用程序在未经他们许可的情况下随意拍摄他们的屏幕。你可能没有问题，但我当然有，很多其他人也有。

让我不要从剪贴板开始——它仅在您的应用程序处于前台时才有效。更有趣的是，微软认为“我们会在调试时让你随时访问剪贴板”，但在发布时，你会得到一个很好的“拒绝访问”异常。你知道我花了多少个小时才最终弄清楚这就是为什么我的应用程序无法在 Release 中启动（而在 Debug 中一切都只是花哨的）

是的，您会遇到异常，但是文档中提到了您的应用程序在未聚焦时无法访问它的事实：

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

但是当用户不使用您的应用程序时，为什么您需要访问剪贴板？如果您在用户不使用您的应用程序时尝试设置剪贴板，当您干扰他的复制/粘贴时，用户会感到恼火。如果您在用户没有要求您的应用程序执行此操作时阅读剪贴板，那么您就是在监视他。除非这是你的目标（在这种情况下你绝对不应该使用 UWP），当你的应用程序不在焦点时（如果有的话），很少有理由读出剪贴板。

是的，我的观点是 - 人们放弃 UWP 应用程序 - 它带来的许多问题超过了好处。

也许吧，但也因为它更容易编写网站并将其打包到 Electron 中并将其发送到 Mac、Linux 和 Windows，而不是为所有平台编写单独的应用程序。

chingucoding 于 2020-01-26

那种听起来像是带有额外步骤的文件浏览器(⊙ˍ⊙)

它不是。离得很远。

所以基本上，最终，您的应用程序可能会遇到与现在相同的问题，因为您永远不会知道文件是否机密。那些将所有内容都标记为机密的用户呢？因此，您刚刚创建了与现在相同的系统，但您可以访问更多变体。

我并不是说我的解决方案是正确的。显然，我根本不想在沙箱中，我只是说当前的实现非常糟糕。

有时 async 有点烦人，但是在大多数情况下，async 方法有理由成为 async，因为您不想在诸如网络或文件操作之类的操作上阻塞 UI。话虽如此，您可以使用以下方法同步运行异步方法：

这是错误的。这只是假设我将始终从 UI 线程调用。我的意思是确定这对于简单的事情来说很好，但是我可以创建自己的线程，也可以创建自己的任务，并在那里做一些事情。

让一切都异步只会迫使我总是调用 await 并标记函数为异步。

[...] 对于ConfigureAwait您可以查看以下文章： https :

谢谢，这个我知道了。我遇到的另一个问题是完全按照您的建议加载位图（异步）。时不时地，我会遇到疯狂的等待时间，比如加载位图需要 5-6 秒。
我最终做了解决方法。

“...dll”内置于发布模式很奇怪。也许检查项目文件是否不连贯？关于编译时间，是的，这有点烦人，虽然 ~1 分钟还是可以的，WinUI 大约需要 5-10 分钟😅

是的，我什至不想考虑那个:) 我不确定你说的项目文件不连贯是什么意思。

是的，崩溃了。 VS 每运行 10-20 次就会崩溃一次，这让我很不解。
是的，这很烦人，虽然我不认为这真的依赖于 UWP，而只是一般的 Visual Studio（出于某种原因，它仍然是一个 32 位进程！）。

我确实相信它与 UWP 相关。在处理 WPF 时，这从未发生在我身上 - 我有 28 个项目，而且从未崩溃过。在 UWP 中，我有 15 个项目（我从 WPF 移植过来的），但它崩溃了。如果我查看事件查看器，会发现沙箱崩溃了——我记不太清楚了。

似乎您可以将 Win2D 与 WPF 一起使用： microsoft/Win2D#660

那是我的第一次尝试。这是一个完全不去的地方。我遇到了很多问题，我最终放弃了。处理 win2d 的代码相当复杂，所以我认为在 WPF 之上编写它比直接使用 UWP 需要更长的时间。

尽管我讨厌 UWP 设置，但我是对的。我永远无法让它正常工作。我假设你知道https://github.com/microsoft/Win2D/issues/731

想想看 - 作为 UWP 应用程序，我需要让 Windows 全屏显示。这简直太疯狂了。更愚蠢的是，这只适用于下一次运行。
即使在启动时，也可以让您的 UWP 应用程序处于全屏模式： https :

对不起，我的意思是“最大化” - 对不起。

是的，您会遇到异常，但是文档中提到了您的应用程序在未聚焦时无法访问它的事实：

问题是 - 我们在 Debug 和 Release 中有不同的行为。它应该是一致的。

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard
但是当用户不使用您的应用程序时，为什么您需要访问剪贴板？ [...]

有趣的是 - 我想在启动时将一些内容复制到剪贴板中。然而，这是在 MainPage 的构造函数中，所以显然，我还没有在前台。在 Debug 中运行良好，在 Release 中崩溃——我的意思是完全在启动时，不记录任何内容。

是的，我的观点是 - 人们放弃 UWP 应用程序 - 它带来的许多问题超过了好处。
也许吧，但也因为它更容易编写网站并将其打包到 Electron 中并将其发送到 Mac、Linux 和 Windows，而不是为所有平台编写单独的应用程序。

当谈到平台独立性时，这是一个全新的话题——我指的是人们在开发 UWP 应用程序时遇到的许多问题根本不应该存在。从 WPF 切换到 UWP 是一种非常糟糕的体验。

jtorjo 于 2020-01-26

@chingucoding

但是当用户不使用您的应用程序时，为什么您需要访问剪贴板？如果您在用户不使用您的应用程序时尝试设置剪贴板，当您干扰他的复制/粘贴时，用户会感到恼火。如果您在用户没有要求您的应用程序执行此操作时阅读剪贴板，那么您就是在监视他。除非这是你的目标（在这种情况下你绝对不应该使用 UWP），当你的应用程序不在焦点时（如果有的话），很少有理由读出剪贴板。

在我的情况下，我的应用程序会在应用程序正在监视的事件发生时不时显示通知。 Toast 通知可能包含用户想要进一步处理/在另一个上下文中使用的信息，因此我提供了一个 [复制到剪贴板] 操作按钮，它复制了一些显示的信息。由于通知可能随时到达并且应用程序很可能在此时处于后台，在这种情况下我必须使用 Win32 帮助程序。

在 UWP 沙箱之外使用 Win32 并不总是因为开发人员希望在用户不知道的情况下实现某些目标。因此，虽然一般来说沙箱为我们用户提供了价值，但无论如何您仍然必须作为开发人员来处理它，即使您不是不介意监视用户或无意要求的恶意开发人员在更改系统上的某些内容之前征得用户的同意。

您可以在您的应用程序旁边使用 Win32 完全信任进程这一事实表明 MS 意识到了这种困境，并且确实为我们的开发人员提供了使用 UWP 的工具，并且仍然能够在很大程度上享受 Win32 的自由。

Felix-Dev 于 2020-01-26

👍1

它不是。离得很远。

现在可以下载应用程序吗？如果是这样，我在哪里可以找到它？ 😅

显然，我根本不想在沙箱中，我只是说当前的实现非常糟糕。

我想，如果您不喜欢沙箱，那么切换到 WPF 替代方案可能是更好的选择，而不仅仅是尝试在 UWP 中开发您的应用程序，您已经明确表示，您认为这是“不可能的”或“非常困难”开发应用程序。我不认为 WPF 替代品与 Win2D 相比如此糟糕，这将证明你经历了所有的挣扎。但这只是我的观点。

此外，对于习惯于对文件没有限制的人来说，当前的实现是“糟糕的”。来自 Web 开发背景，我对此非常满意。我可以看到它们的位置，特别是因为 Web 也有限制，其目的是保护用户。

我不确定你说的项目文件不连贯是什么意思。

也许用于调试的项目文件是错误的，并且在发布时正在生成一些 dll，但我怀疑如果您只是让 Visual Studio 处理它会发生这种情况。

我确实相信它与 UWP 相关。在处理 WPF 时，这从未发生在我身上 - 我有 28 个项目，而且从未崩溃过。在 UWP 中，我有 15 个项目（我从 WPF 移植过来的），但它崩溃了。如果我查看事件查看器，会发现沙箱崩溃了——我记不太清楚了。

Visual Studio 的可靠性在很大程度上取决于我的项目规模。小型/中型 UWP/NetCore/NetFramework 始终工作正常。大型项目有时会导致 Visual Studio 无响应、挂起或直接崩溃。但这只是我的经验。

对不起，我的意思是“最大化” - 对不起。

在这种情况下，是的，更改只会在下次启动时应用，因为您在应用程序启动后为其设置了值。我不知道您所说的“我必须问 Windows”是什么意思。你是指你必须在代码中设置它吗？

还有一种方法可以设置首选大小，这应该会导致应用程序占用屏幕上的所有空间（类似于最大化），尽管它不如真正的最大化：
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

这是错误的。这只是假设我将始终从 UI 线程调用。我的意思是确定这对于简单的事情来说很好，但是我可以创建自己的线程，也可以创建自己的任务，并在那里做一些事情。

如果您已经在使用自己的线程，那么使用 await 对您来说应该不是问题。即使您使用单独的线程，事件处理程序也始终在 UI 线程中运行，因此如果您在那里进行大量计算，应用程序会变得无响应。

尽管我讨厌 UWP 设置，但我是对的。我永远无法让它正常工作。我假设你知道 microsoft/Win2D#731

我不知道，我以为是我从2018年开始提到的问题，现在应该会很好地解决。

问题是 - 我们在 Debug 和 Release 中有不同的行为。它应该是一致的。

嗯，这很奇怪。行为应该是一致的。

有趣的是 - 我想在启动时将一些内容复制到剪贴板中。

他们还在文档中提到了这个用例，你应该等待 CoreWindow.Activated 复制。当用户刚刚启动您的应用程序时，您为什么要将某些内容复制到剪贴板中？类似于@Felix-Dev 想要实现/实现的东西？

@Felix-Dev 感谢您的回复。我没有想过那个场景。在这种情况下，是的，您需要访问剪贴板，这肯定会改善用户的体验。我的猜测是，既然你敬酒“有重点”，这就会奏效。但我想事实并非如此。

因此，虽然一般来说沙箱为我们用户提供了价值，但无论如何您仍然必须作为开发人员来处理它，即使您不是不介意监视用户或无意要求的恶意开发人员在更改系统上的某些内容之前征得用户的同意。

是的，我们必须处理它，但是许多应用程序不受沙箱的限制，因此很难找到解决方法。还有一件事不要忘记，如果 UWP 不适合您，还有其他 2 个选项。

关于您的最后一点，是的，您可以使用 Win32 进程这一事实表明存在 UWP 限制您的情况。
也许这是手头最简单/最快的解决方法，或者它实际上是设计使然。

chingucoding 于 2020-01-26

它不是。离得很远。
现在可以下载应用程序吗？如果是这样，我在哪里可以找到它？ 😅

这里 -> https://photo-awe.com

我想，如果您不喜欢沙箱，那么切换到 WPF 替代方案可能是更好的选择，而不仅仅是尝试在 UWP 中开发您的应用程序，您已经明确表示，您认为这是“不可能的”或“非常困难”开发应用程序。我不认为 WPF 替代品与 Win2D 相比如此糟糕，这将证明你经历了所有的挣扎。但这只是我的观点。

这是一个 WPF 应用程序。然而，由于视频编辑的性质，我长期以来一直在速度方面达到 WPF 的极限（基本上，处理DrawingVisual ）。相信我，如果我有选择的话，我不会这样做。

此外，对于习惯于对文件没有限制的人来说，当前的实现是“糟糕的”。来自 Web 开发背景，我对此非常满意。我可以看到它们的位置，特别是因为 Web 也有限制，其目的是保护用户。

我可以发誓你来自网络背景:)

也许用于调试的项目文件是错误的，并且在发布时正在生成一些 dll，但我怀疑如果您只是让 Visual Studio 处理它会发生这种情况。

事实并非如此，但我确实仔细检查过 - 并非如此。

Visual Studio 的可靠性在很大程度上取决于我的项目规模。小型/中型 UWP/NetCore/NetFramework 始终工作正常。大型项目有时会导致 Visual Studio 无响应、挂起或直接崩溃。但这只是我的经验。

是的，我过去处理过这个问题。最新版本的 VS（2017、2019）似乎并非如此。无论如何，长话短说，这对我来说只是在 UWP 上发生的。这可能与我使用的是 win2d 的事实有关，我有一种非常复杂的野兽的感觉。

在这种情况下，是的，更改只会在下次启动时应用，因为您在应用程序启动后为其设置了值。我不知道您所说的“我必须问 Windows”是什么意思。你是指你必须在代码中设置它吗？

在 WPF 中，我只是将窗口大小设置为我想要的位置。在这里，您需要调用一个 API -> ApplicationView.PreferredLaunchViewSize - 正如文档所说，“它可以工作，除非系统直接管理窗口大小”。 - 是的，它只适用于下一个应用程序启动。

还有一种方法可以设置首选大小，这应该会导致应用程序占用屏幕上的所有空间（类似于最大化），尽管它不如真正的最大化：
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

我正在使用另一个代码，它实际上工作正常

var view = DisplayInformation.GetForCurrentView();
var resolution = new Size(view.ScreenWidthInRawPixels, view.ScreenHeightInRawPixels);
var scale = view.ResolutionScale == ResolutionScale.Invalid ? 1 : view.RawPixelsPerViewPixel;
var bounds = new Size(resolution.Width / scale, resolution.Height / scale);

ApplicationView.PreferredLaunchViewSize = new Size(bounds.Width, bounds.Height);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;

如果您已经在使用自己的线程，那么使用 await 对您来说应该不是问题。即使您使用单独的线程，事件处理程序也始终在 UI 线程中运行，因此如果您在那里进行大量计算，应用程序会变得无响应。

显然，事件处理程序在 UI 线程中运行。我已经有点习惯了，我确实不得不修改我的应用程序的相当多 - 只是向函数添加异步......仍然真正困扰我的是对我来说，似乎有很多 API 已经采用了这个极端情况下，只有 Async() 版本，这是没有意义的。

我不知道，我以为是我从2018年开始提到的问题，现在应该会很好地解决。

它没有 - 至少我上次检查过。

问题是 - 我们在 Debug 和 Release 中有不同的行为。它应该是一致的。
嗯，这很奇怪。行为应该是一致的。

是的，这才是真正让我生气的地方。很明显，在非 UWP 应用程序上使用剪贴板工作了很长时间，我认为我们不会有这些限制，所以是的，我没有读到必须等待 CoreWindow.Activated。话虽如此，必须了解所有这些细节是非常麻烦的。这就像我需要完全学习一门全新的语言。似乎每周我都会学到一些让我大吃一惊的事情，而不是一个无缝的过程。

他们还在文档中提到了这个用例，你应该等待 CoreWindow.Activated 复制。当用户刚刚启动您的应用程序时，您为什么要将某些内容复制到剪贴板中？类似于@Felix-Dev 想要实现/实现的东西？

那是我早期测试我的应用程序的时候，我只是想把它交给一位同事进行更多的内部测试。但是，他需要调整一些设置。设置保存在应用程序的本地文件夹中。这对每个用户来说都是不同的，所以我的看法是——让我保持这个简单并将其复制到剪贴板。然后，当他启动应用程序时，他将转到“此电脑”，粘贴位置，并在那里编辑设置文件（现在，我知道如何在资源管理器中简单地打开应用程序，但当时，我没有）。结果崩溃了，我调查和诅咒了几个小时。

jtorjo 于 2020-01-26

这里 -> https://photo-awe.com

谢谢！

这是一个 WPF 应用程序。但是，由于视频编辑的性质，我长期以来一直在速度方面达到 WPF 的极限（基本上是处理 DrawingVisual）。相信我，如果我有选择的话，我不会这样做。

没想到WPF比UWP有这么大的性能退步。

事实并非如此，但我确实仔细检查过 - 并非如此。

这很奇怪。我原以为会有什么问题。为什么 VS 在运行调试时会谈论发布 dll。

在 WPF 中，我只是将窗口大小设置为我想要的位置。在这里，您需要调用一个 API - ApplicationView.PreferredLaunchViewSize - 正如文档所说，“它可以工作，除非系统直接管理窗口大小”。

但是您使用的代码不也是用于设置窗口大小的 API 吗？

是的，它只适用于下一个应用程序启动。

当它被称为“PreferredLaunchViewSize”时并不奇怪😅
只是有点不方便，启动后无法设置它。

是的，我过去处理过这个问题。最新版本的 VS（2017、2019）似乎并非如此。无论如何，长话短说，这对我来说只是在 UWP 上发生的。

很高兴听到它不像早期版本的 VS 那样糟糕。

这可能与我使用的是 win2d 的事实有关，我有一种非常复杂的野兽的感觉。

我不太依赖设计器，因为模板绑定开始失败。你试过 Blend for Visual Studio 吗？这对设计师来说更可靠吗？

是的，这才是真正让我生气的地方。很明显，在非 UWP 应用程序上使用剪贴板工作了很长时间，我认为我们不会有这些限制，所以是的，我没有读到必须等待 CoreWindow.Activated。话虽如此，必须了解所有这些细节是非常麻烦的。这就像我需要完全学习一门全新的语言。似乎每周我都会学到一些让我大吃一惊的事情，而不是一个无缝的过程。

是的，我可以想象。从 WPF 到 UWP 的过渡指南可能会很好。如果这存在，那肯定会为新的 UWP 和前 WPF 开发人员节省大量时间。这不是第一次有过渡指南。已经有一个 Java to C# 指南，这对 Java 开发人员有很大帮助。

那是我早期测试我的应用程序的时候，我只是想把它交给一位同事进行更多的内部测试。但是，他需要调整一些设置。设置保存在应用程序的本地文件夹中。这对每个用户来说都是不同的，所以我的看法是——让我保持这个简单并将其复制到剪贴板。然后，当他启动应用程序时，他将转到“此电脑”，粘贴位置，并在那里编辑设置文件（现在，我知道如何在资源管理器中简单地打开应用程序，但当时，我没有）。结果崩溃了，我调查和诅咒了几个小时。

原来如此。如果不考虑打开文件夹，将文件夹路径复制到剪贴板是一种解决方案。出于测试目的，这是非常聪明的。

chingucoding 于 2020-01-26

没想到WPF比UWP有这么大的性能退步。

WPF 没有针对 DirectX 进行优化 - 当像素着色器和遮罩开始发挥作用时，它最终会变得非常缓慢。移植到 UWP/win2d 使应用程序速度提高了 3-4 倍。这是非常引人注目的。

这很奇怪。我原以为会有什么问题。为什么 VS 在运行调试时会谈论发布 dll。

是的，正是我的意思。

但是您使用的代码不也是用于设置窗口大小的 API 吗？

我的意思是，您使用 Preferred...Size，但不能保证它会发生。与使用 WPF 时一样，您可以保证在设置位置/大小时，它确实会发生。

当它被称为“PreferredLaunchViewSize”时并不奇怪😅
只是有点不方便，启动后无法设置它。

这太不方便了——这太不方便了。基本上，一旦我的应用程序启动，我就无法调整它的大小。是的，我希望我的应用程序具有不同的操作“模式”（例如基本/高级）-基于此，我希望占用更多或更少的空间-我做不到。您认为用户会同意“仅在重新启动后才会发生更改”吗？

我不太依赖设计器，因为模板绑定开始失败。你试过 Blend for Visual Studio 吗？这对设计师来说更可靠吗？

我应该更具体 - 编辑 xaml 时 VS 不会崩溃 - 启动应用程序时会崩溃；基本上，我假设它恰好在部署时发生，因为您只在（uwp）应用程序上看到大“x”大约 10 秒钟，然后我知道它挂了。此时我可以再等 45-60 秒，然后看到 VS 会崩溃，或者直接从任务管理器中关闭 VS。

是的，我可以想象。从 WPF 到 UWP 的过渡指南可能会很好。

是的，那会很有帮助。

原来如此。如果不考虑打开文件夹，将文件夹路径复制到剪贴板是一种解决方案。出于测试目的，这是非常聪明的。

谢谢 ;) 好吧，如果它真的有效的话，它会很聪明:)

jtorjo 于 2020-01-27

@chingucoding

有时 async 有点烦人，但是在大多数情况下，async 方法有理由成为 async，因为您不想在诸如网络或文件操作之类的操作上阻塞 UI。话虽如此，您可以使用以下方法同步运行您的异步方法

让我再给你一个我讨厌 async 的原因——这件事现在刚发生在我身上（基本上，这是一个用户的错误报告）。最初，我无法为我的生活弄清楚。

长话短说 - 单击按钮，我打开一个文件选择器。你猜对了，这是异步的。

因此，用户双击了它（两次点击之间有大约 100 毫秒的暂停）。当然，这打开了 2 个文件选择器。

现在，显然我可以解决这个问题，但是这永远不会发生，如果初始函数是同步的（当然，这在 WPF 中永远不会发生）。

jtorjo 于 2020-01-28

这太不方便了——这太不方便了。基本上，一旦我的应用程序启动，我就无法调整它的大小。是的，我希望我的应用程序具有不同的操作“模式”（例如基本/高级）-基于此，我希望占用更多或更少的空间-我做不到。您认为用户会同意“仅在重新启动后才会发生更改”吗？

“非常不方便”可能适用于需要强制执行某些大小的应用程序，但在大多数情况下，应用程序不需要自行调整大小。应用程序应该如何选择当前适合用户用例的大小？如果用户需要将其变小或变大，那么用户首先会注意到这一点。尤其是因为他最清楚其他打开的窗户在哪里，以及哪些空间可以不阻挡其他窗户的可见性。

如果您有基本和高级模式，如果应用程序在太小时肯定无法运行，您可以更改最小首选大小。但在我看来，如果程序开始调整自己的大小（幸运的是，到目前为止还没有程序这样做），这对我来说会非常恼火。

我做不到。您认为用户会同意“仅在重新启动后才会发生更改”吗？

如果调整大小那么重要，用户可以自己完成。但是，这种“仅在重新启动后才会发生更改”的情况并不少见，因此在我看来这是部分可以接受的。

因此，用户双击了它（两次点击之间有大约 100 毫秒的暂停）。当然，这打开了 2 个文件选择器。

为什么它打开文件选择器两次？事件处理程序是否触发了两次？这不是由异步引起的问题，而是由于事件处理程序没有阻止 UI 接收来自相应按钮的附加事件这一事实。

长话短说 - 单击按钮，我打开一个文件选择器。你猜对了，这是异步的。

是的，这是异步的，因为您不想在用户浏览驱动器并选择文件夹时阻塞整个线程。当用户完成选择文件/文件夹时，调用结束，您将获得所选文件。

在我看来，最好不要在此类操作上阻塞线程，因为您永远不知道它们实际需要多长时间。如果您因此而阻塞 UI 线程，只要打开文件选择器，您的应用就会变得无响应，IMO 不是一个好的 UX。

chingucoding 于 2020-02-03

首先让我恭敬地说：我们永远不会在任何事情上达成一致。

很明显，您是从 Web 的角度思考问题，而您根本看不到任何东西是“桌面”。我知道你的意思很好，但你只是在开发一些复杂的东西之前不会考虑“桌面”——当涉及到桌面时。我相信你没有。

“非常不方便”可能适用于需要强制执行某些大小的应用程序，但在大多数情况下，应用程序不需要自行调整大小。应用程序应该如何选择当前适合用户用例的大小？如果用户需要把它变小或变大，比用户

你是认真地问这个吗？应用程序不是应该帮助用户吗？然后如果用户对应用程序的大小不满意，他可以调整大小。但是该应用程序应该能够根据它应该完成的事情说这是我应该运行的大小。可以说，Photoshop - 总是更喜欢全屏运行，因为它有很多信息要显示给用户。

如果您有基本和高级模式，如果应用程序在太小时肯定无法运行，您可以更改最小首选大小。但在我看来，如果程序开始调整自己的大小（幸运的是，到目前为止还没有程序这样做），这对我来说会非常恼火。

如果他们这样做了，你甚至都没有考虑过。向导有时会以较小的尺寸运行，然后当向导完成时，应用程序可能会全屏显示。

我做不到。您认为用户会同意“仅在重新启动后才会发生更改”吗？
如果调整大小那么重要，用户可以自己完成。但是，这种“仅在重新启动后才会发生更改”的情况并不少见，因此在我看来这是部分可以接受的。

并且有一个糟糕的启动体验，因为我显示了一个看起来不错的窗口，只有特定大小 - 而 Windows 只是说“哦，但我会根据需要显示应用程序”。

为什么它打开文件选择器两次？事件处理程序是否触发了两次？这不是由异步引起的问题，而是由于事件处理程序没有阻止 UI 接收来自相应按钮的附加事件这一事实。

你诚实地这样做吗？向我展示代码如何在您有意识地执行此操作的地方进行剪切。

在我看来，最好不要在此类操作上阻塞线程，因为您永远不知道它们实际需要多长时间。如果您因此而阻塞 UI 线程，只要打开文件选择器，您的应用就会变得无响应，IMO 不是一个好的 UX。

WPF 如何处理这个问题？它正确处理它。 UI 不会阻塞，但应用程序会在该调用中阻塞 - 因此上述情况在 WPF 中永远不会发生

jtorjo 于 2020-02-03

👍2

首先让我恭敬地说：我们永远不会就任何事情达成一致。

如果这是你对这次讨论的看法，我很抱歉。

很明显，您是从 Web 的角度思考问题，而您根本看不到任何东西是“桌面”。我知道你的意思很好，但你只是在开发一些复杂的东西之前不会考虑“桌面”——当涉及到桌面时。我相信你没有。

我认为更准确的描述是：我来自开发人员无法访问任何内容的背景，而您来自开发人员可以访问每个操作系统资源的背景。

如果他们这样做了，你甚至都没有考虑过。向导有时会以较小的尺寸运行，然后当向导完成时，应用程序可能会全屏显示。

是的，向导以较小的尺寸运行，但大多数向导（包括 Visual Studio 2019 启动“向导”）会自行关闭，然后启动真正的程序。它们不会“变形”为实际应用程序。

值得注意的是，一些向导也不是新窗口，而只是弹出窗口，实际应用程序在后台。

并且有一个糟糕的启动体验，因为我显示了一个看起来不错的窗口，只有特定大小 - 而 Windows 只是说“哦，但我会根据需要显示应用程序”。

你让它看起来像 Windows 一直在忽略你的代码，而很明显它什么时候会忽略它（取自“PreferredLaunchViewSize”的文档）：

此属性仅在应用程序在非平板电脑模式的桌面设备上启动时有效。

所以它只适用于非平板电脑模式的桌面。但是在其他设备上实际请求大小是否有意义？您是否希望您的应用在 X-Box 或 Holo Lens 上运行，并且您是否针对此类设备进行了优化？如果没有，那么这个限制不应该那么困扰你。

你诚实地这样做吗？向我展示代码如何在您有意识地执行此操作的地方进行剪切。

不，我不是，我只是想指出一个事实，即您将与此无关的事情归咎于“异步”。如果用户单击按钮两次，则 clicked 事件将被触发两次。

WPF 如何处理这个问题？它正确处理它。 UI 不会阻塞，但应用程序会在该调用中阻塞 - 因此上述情况在 WPF 中永远不会发生

我相当肯定，如果您在 UI 线程中运行代码并且需要时间来完成，而不是在 WPF 中阻塞 UI 线程。

chingucoding 于 2020-02-03

👍2

您好，我是 Windows 操作系统团队的 Windows SDK 和 Windows 运行时基础架构的开发负责人。

这是一个很好的讨论，有很多细节和对话。几天前有人带来了这个对话，我很期待通读它，但我可能还需要几天时间才能读懂。不过，我会阅读整篇文章，并尝试给你一些更详细的答案或尽我所能跟进。

这可能不是解决 winrt 一般问题的最佳位置。您可以在 Microsoft 开发人员论坛中提出问题，或者专门针对 Windows 运行时问题，您可以在https://github.com/microsoft/xlang 中打开一个问题

再次感谢热烈的讨论。我很快会再次发布关于这个问题的帖子。

本·库恩
微软

BenJKuhn 于 2020-03-26

👍3 ❤1

嗨，本，

您好，我是 Windows 操作系统团队的 Windows SDK 和 Windows 运行时基础架构的开发负责人。
这是一个很好的讨论，有很多细节和对话。几天前有人带来了这个对话，我很期待通读它，但我可能还需要几天时间才能读懂。不过，我会阅读整篇文章，并尝试给你一些更详细的答案或尽我所能跟进。

太棒了 - 期待您的回复！

由于我是原始海报，如果您有任何问题/不清楚的地方，请告诉我，我会尽力澄清。

这可能不是解决 winrt 一般问题的最佳位置。您可以在 Microsoft 开发人员论坛中提出问题，或者专门针对 Windows 运行时问题，您可以在https://github.com/microsoft/xlang 中打开一个问题

同意这不是最好的地方，问题是人们不知道在哪里张贴。

如果你说我们应该发布到https://github.com/microsoft/xlang ，我肯定会从现在开始发布。

最好的事物，
约翰

jtorjo 于 2020-03-26

首先，让我指出一些我不打算解决的事情。

• 在线程底部附近有很多关于窗口、窗口位置等的精彩讨论。对于 WinUI 来说，这可能仍然有点题外话，但更接近家庭。我想让 WinUI 的人解析关于窗口位置、全屏等的反馈并帮助重定向。 @StephenLPeters ，你能帮忙解决这个问题吗？

• 我不会触及VS 反馈。有一个讨论 VS 质量和性能的健康论坛。尽管我已经注意到有关从 Visual Studio 开发 Windows 应用程序的故事变得更加复杂和混乱的讨论。

• WPF。我与 WPF 有爱恨交加的关系。它很有用，而且大多很好。当我阅读关于文件选择器上嵌套点击的评论时，它让我发笑。因为 WPF 中有一些让我非常头疼的怪癖。就像在 WPF 中拖动时一样，拖动消息有时会在嵌套消息中重复发送，因此您实际上是在模态拖动中进行模态拖动。你通常不会注意到。通常。但我还是喜欢WPF。 😉

其次， @verelpode ：这让我发笑。介意我坚持这个吗？
“我相信你处理不了直接的真相，所以我给你戴上厚厚的蓬松棉手套，用气泡膜包裹你”

好的，现在开始真正的话题。

WinRT vs. UWP vs. .NET – 一些背景

Windows 运行时实际上是将两件事合二为一，打包在另一件事中，并且确实被误解了。

在某种意义上，Windows 运行时类型系统实际上是 COM V2。这是从触发中断到调用 Win32 再到调用 COM API 的精神上的下一步。类型系统在某些方面在 COM 中的表现力稍差，但在大多数方面是一个实质性的超集。它最初旨在解决一个问题：我们如何让使用 .NET 或其他语言的开发人员更轻松地调用 WinRT API，而不必等待 VS 在 .NET 框架中制作漂亮的包装器。

然后是 API 库。我们在这里做了一些很棒的事情，也做了一些愚蠢的事情。我们可能对一些异步的东西有点忘乎所以。如果您使用 C++ /WinRT 进行编程，则可以显着缓解这种情况。如果您不在 UI 线程上，您只需获取结果，它就会阻塞并同步完成。 .NET 现在也可能使这更容易，但我现在编写的 .NET 代码较少，而且我对事物的当前状态不太确定。我们也做了一些没有按计划进行的其他事情。我不会一一列举。不过我们做了一些改进。

UWP 应用程序模型双脚跳入 winrt。这意味着我们可以编写一次操作系统 API，并让它们易于从基于 JS 的应用程序、.NET 应用程序和本机应用程序访问。这本身就是好事。去掉所有其他的 Win32 API 不太好。我们还有一些文档工作要做，但现在有更多经典的 Win32 API 可以在商店应用程序中使用。长话短说，我们创建了一个全新的应用程序平台，在新设备上的用户群很小，不允许您携带现有代码，也没有很多人出现。我们知道。这就是为什么我们要一点一点地修复它。我们也做对了很多，并且正在缓慢而稳定地朝着两全其美的方法努力。在大多数情况下，声明式安装系统是一件很棒的事情。

此线程还涉及 UWP 应用程序和桌面应用程序之间的代码可移植性。由于 UWP 模型差异很大，因此存在许多痛点。我们正在尽快解决这些问题。有些需要时间，或需要“主要休息”。例如，我们为 CRT DLL 使用不同的名称。我们整合了一个缓解措施，即 VC forwarders 包，但真正的解决方法是最终消除 CRT 未来版本中的区别，这本质上需要重命名文件和重大突破性更改。我们故意不经常这样做，因为它具有破坏性。

WinRT 本身正越来越多地将其工具开源，尽管不为人所知，但大多数 WinRT 可用于桌面应用程序。 XAML 是一个很大的差距。 XAML Islands 是朝着正确方向迈出的一步，但我对 WinUI 更加兴奋。

对特定 API 的反馈

对于其中的一些问题，如果这是您的问题，我会要求您提交反馈。我会帮助将问题推广给合适的团队。 Windows 中的不同团队各自负责他们自己的 API，如果您在反馈中心提交，它将最有效。这将反馈与真实的人和故事联系起来。它还允许您跟踪反馈。您可以通过添加其他人酌情提交的反馈来互相帮助。尝试选择一个合适的类别。如果不清楚，可以使用“开发者反馈”-> API 反馈

现代应用程序的文件系统 API 令人痛苦且出乎意料地缓慢

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
我们从客户和我们自己的构建应用程序的团队那里听到了这种反馈。我希望此时我可以分享更多。不幸的是，现在我只能说“我们知道”。

BroadSystemAccess API / 功能在实现时并不实用。

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
请提交反馈中心项目并将链接发送给我。我会亲自推广它并将其交给合适的所有者。 80% 的衰减率并不好。我也理解它对用户来说是一个危险信号。如果文件 API 足够快，听起来未来的访问列表至少会减轻一些痛苦，但可能不会像您现在拥有的那样“灵活”。但是，您处于岩石和坚硬的地方之间。为了让您现在的工作方式变得神奇，您需要用户让您看到一切。他们的密码电子表格、他们的邮件文件夹、他们的浏览器缓存等。你可能值得信赖，但你的应用程序应该让用户在交出他们的世界之前停下来思考他们对你的信任程度。

我知道关闭应用程序并重新启动的想法是一个尴尬的步骤。这似乎是至少应该在首次发布时解决的类型。请提交单独的反馈项目。同样的报价。我会推广和交付。

关于未来的访问列表是否可以访问子文件夹，我已经为该页面创建了一个文档问题。 https://github.com/MicrosoftDocs/windows-uwp/issues/2322。值得注意的是，由于文档页面在 github 上，您可以在文档上提交问题或提出对内容的更改。

将文件拖入应用程序不允许写访问：关于反馈中心的相同提议。请提交文件，我会相应地进行路由。

创建用于在 MS 商店外进行旁加载的应用程序

我在这里得到的结论是，这个问题大部分是一个文档问题，但它涉及另一个关键方面。由于我们的一些工具已转移到 github 项目和开源，文档也随之移动，这使得使用 Windows 文档作为所有内容的一站式服务变得更加困难。我将在内部就 .appinstaller 文件的具体问题提出这个问题，并与我们的内容团队更广泛地讨论如何更好地解决这个问题。

您还注意到需要通过服务器进行路由以进行调试的特定问题。您应该针对现有的 github 项目提出问题。

新证书发行和私人分发

这离我家更近一些（我更大的团队也处理应用程序安装的各个方面。我仍然很感激我可以解决的反馈中心问题。

WinRT 类型系统影响提供出色 API 和库的能力

无法重载类型名称是设计使然。在我们重新思考 javscript（Node / V8 怎么样？这会很有趣吗？）应用程序如何访问 WinRT API 之前，我们不会准备好重新审视这个问题。关于属性和 NaN 的另一个问题是在一个单独的问题中，有一些很好的讨论，所以我不会在这个回复中涉足它。

反馈中心应在放弃时提示，防止内容被误删

是的，我会 +1。请归档。在应用程序下的反馈中心中有一个类别用于...反馈中心。这太元了。

异步 API 仍然失控，对于不应该是异步的东西似乎很尴尬

是的。这仍然是内部争论的话题。在保姆和鼓励良好行为之间有一些很好的平衡，我们还没有完全达到。请继续提交有关您希望同步的特定 API 的反馈。

WinRT 上没有好的音频 API

我不是音频专家。随意在反馈中心提交文件，但我也将在这里拨打救命电话并进行一些询问。

剪贴板之痛

我必须从这里的 Mae Culpa 开始。我们的剪贴板访问模型是在 Win8 时代设计的，当时我们对用户进行了超级保护。我编码了大部分。有充分的理由保护剪贴板。用户将各种敏感数据放在剪贴板上，而可以覆盖剪贴板的应用程序也可能通过尝试利用可能具有更多访问权限的其他应用程序中的弱点来造成伤害。 Win32 剪贴板 API 还启用了一些可能被滥用的非常强大的行为。因此，剪贴板限制访问，除非您的应用程序处于前台或连接到调试器，并且稍微收紧了您可以放在剪贴板上的内容（除非您真的尝试，否则您永远不会注意到）。

也就是说，正在与之交互的通知似乎应该允许剪贴板访问。由于 Windows 和前景的计算方式，我认为这需要特殊处理，但似乎并不合理。请在 API 反馈下提交文件，我也会将该问题提交到错误数据库中。

包起来

我希望这会有所帮助。如果您将它们提交，我将跟踪线程并跟进上述问题。

出于对 WinUI 团队的尊重，他们手头上已经有很多东西了，请让这个线程结束，只关注这个线程中提出的 WinUI 和窗口方面。由于这个问题又长又曲折，将它们梳理成单独的、较小的问题可能会有所帮助。我将把这个开放几天，让你们所有人提交反馈并用链接发表评论，然后我会关闭这个线程。

如果您确实想深入研究 WinRT 类型系统的讨论，xlang 项目是一个不错的起点。对于特定的 Windows API 行为，反馈中心是更好的选择。它现在也有一个评论系统，所以希望这会有所帮助。

再次感谢您的精彩讨论和关于这么多主题的所有详细反馈。

本·库恩
微软

BenJKuhn 于 2020-03-27

❤6 👍6

如果您提供文件选择器让用户选择他们想要授予您的应用访问权限的内容，您的应用就不会关闭。

作为用户，我怎么强调都不过分。我不想让任何应用程序访问所有内容，但是如果您要求一个奇怪的位置_并且它有意义_我会授予访问权限。

sharpninja 于 2020-03-27

👍2

@BenJKuhn感谢您的详细回答。非常非常感谢！

• WPF。我与 WPF 有爱恨交加的关系。它很有用，而且大多很好。当我阅读关于文件选择器上嵌套点击的评论时，它让我发笑。因为 WPF 中有一些让我非常头疼的怪癖。就像在 WPF 中拖动时一样，拖动消息有时会在嵌套消息中重复发送，因此您实际上是在模态拖动中进行模态拖动。你通常不会注意到。通常。但我还是喜欢WPF。 😉

我完全同意。我不是 WPF 的倡导者，我很久以前就达到了 WPF 的极限。这就是我搬到 UWP 的原因。稳定性方面，WPF 似乎更稳定。

WinRT vs. UWP vs. .NET – 一些背景

然后是 API 库。我们在这里做了一些很棒的事情，也做了一些愚蠢的事情。我们可能对一些异步的东西有点忘乎所以。

你可以再说一遍：）

此线程中还涉及 UWP 应用程序和桌面应用程序之间的代码可移植性 [...] 但真正的修复将最终消除未来版本的 CRT 中的区别，这本质上需要重命名文件和重大突破性更改.

任何预计到达时间？ .Net 5？

现代应用程序的文件系统 API 令人痛苦且出乎意料地缓慢
https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
我们从客户和我们自己的构建应用程序的团队那里听到了这种反馈。我希望此时我可以分享更多。不幸的是，现在我只能说“我们知道”。

到目前为止，我有一个解决方法 - 远非理想，但现在我很好 - https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

BroadSystemAccess API / 功能在实现时并不实用。
https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
请提交反馈中心项目并将链接发送给我。我会亲自推广它并将其交给合适的所有者。 80% 的衰减率并不好。我明白

会的，我希望能在周末完成。

关于它对用户来说也是一个危险信号。如果文件 API 足够快，听起来未来的访问列表至少会减轻一些

是的，如果 StorageFile/Folder API 与 System.IO 一样快（或至少具有可比性），它会减轻它。这不是因为缺乏尝试 - 我已经完成了文档中概述的所有内容。

疼痛，但可能不像你现在那样“光滑”。但是，您处于岩石和坚硬的地方之间。为了让您现在的工作方式变得神奇，您需要用户让您看到一切。他们的密码电子表格、他们的邮件文件夹、他们的浏览器缓存等。你可能值得信赖，但你的应用程序应该让用户在交出他们的世界之前停下来思考他们对你的信任程度。

我完全理解这一切。我同意你的看法。我的痛点是所有这些的当前实现。我已经重写了大部分处理这个的 UI（几次）。

话虽如此，这里是我的改进想法：

“选择文件夹”可能会更有帮助 - 我可以指定我感兴趣的文件，它可以向用户突出显示包含它的文件夹
剪贴板 - 如果用户将一些文件/文件夹放入剪贴板，然后返回到我的应用程序，我应该可以自动访问这些（也许您可以添加“ClipboardFilesAndFolders”功能）
拖放文件/文件夹 - 这应该会自动让我访问这些文件（否则用户为什么要把它们放到我的应用程序中？）

我知道关闭应用程序并重新启动的想法是一个尴尬的步骤。这似乎是至少应该在首次发布时解决的类型。请提交单独的反馈项目。同样的报价。我会推广和交付。

知道了，谢谢 - 周末。

将文件拖入应用程序不允许写访问：关于反馈中心的相同提议。请提交文件，我会相应地进行路由。

是的，会做 - 将文件拖入应用程序的事情。我还没有真正尝试过：

它适用于文件和文件夹吗？
我可以访问 .Path 吗？
它是持久的（我认为不是）吗？
我是否需要挂在 StorageFile/Folder 上，或者稍后从 .Path 重新创建它会起作用（假设 2. 的答案是肯定的）？

创建用于在 MS 商店外进行旁加载的应用程序
我在这里得到的结论是，这个问题大部分是一个文档问题，但它涉及另一个关键方面。由于我们的一些工具已转移到 github 项目和开源，文档也随之移动，这使得使用 Windows 文档作为所有内容的一站式服务变得更加困难。我将在内部就 .appinstaller 文件的具体问题提出这个问题，并与我们的内容团队更广泛地讨论如何更好地解决这个问题。

是的，那会很棒！

就个人而言，我已经为我的应用程序找到了它。这让我无法做一些我想做的其他高级事情（例如，要启动一个 win32 应用程序，因为我担心整个 .appinstaller 文件需要如何更改）。

但是，对我来说，这应该是 Visual Studio“发布”过程的一部分。您应该为我创建一个 .appinstaller（因为正确获取所有这些依赖项名称绝非易事，而且对依赖项的任何更新 -> 我们又来了）。它还应该创建一个 readme.txt 文件，其中应该解释我需要上传到我的服务器的内容，并告诉我我不能在本地使用 .appinstaller，它需要从服务器下载（测试时)

您还注意到需要通过服务器进行路由以进行调试的特定问题。您应该针对现有的 github 项目提出问题。

我不记得那个问题是什么:)

反馈中心应在放弃时提示，防止内容被误删
是的，我会 +1。请归档。在应用程序下的反馈中心中有一个类别用于...反馈中心。这太元了。

对：）

异步 API 仍然失控，对于不应该是异步的东西似乎很尴尬
是的。这仍然是内部争论的话题。在保姆和鼓励良好行为之间有一些很好的平衡，我们还没有完全达到。请继续提交有关您希望同步的特定 API 的反馈。

呵呵，那是一个很长的清单；)

它从 StorageFolder/File 的基本属性开始； StorageFile.GetFileFromPathAsync（+ 与文件夹类似）。
加载缩略图 (StorageFile.GetThumbnailAsync
加载位图。这尤其痛苦，因为它被带到了其他库（例如 win2d）中，而且我已经达到了疯狂的阈值 - 例如，加载一个简单的位图（应该花费 <20 毫秒），持续 5 秒左右。显然，幕后有一些锁定，但没有人知道是什么/为什么/何时。是的，我的笔记本电脑是火箭。

我没有跟踪很多其他 API，对我的项目的快速搜索显示了 326 种用途——我已经把它减少了很多，因为我的很多事情都需要同步。

以上是我的主要头疼，从我的头顶开始。从现在开始，我将创建一个文档，并添加到其中 :)

WinRT 上没有好的音频 API
我不是音频专家。随意在反馈中心提交文件，但我也将在这里拨打救命电话并进行一些询问。

我不确定这是否/如何解决。最简单的事情就是放宽要求什么的，这样 naudio (https://github.com/naudio/NAudio) 可以正确地移植到 UWP。需要明确的是，它可以开箱即用地编译为 UWP，但它没有用，因为大多数有用的东西都被 #ifdef-ed 了。

明确地说，我不是在抱怨 UWP 上的声音 API - 这完全没问题，但我需要更多。即，解释声波等的能力（naudio 允许）。

我已经完成了一个 naudio 端口，在那里我几乎删除了所有 #ifdefs - 它可以工作，但我的应用程序永远不会进入 MS 商店 - 我对此很好。

剪贴板之痛

[...] 也就是说，正在与之交互的通知似乎应该允许剪贴板访问。由于 Windows 和前景的计算方式，我认为这需要特殊处理，但似乎并不合理。请在 API 反馈下提交文件，我也会将该问题提交到错误数据库中。

听起来不错，会做。

谢谢！

jtorjo 于 2020-03-27

@jtorjo您是否愿意在关于文件系统的反馈中心项目中包含问题 #1893（提案：文件系统访问：提供一种用户友好的方式来请求访问特定文件位置的权限）（如果您没有没有计划，我想你列出了上面的潜在问题）。恐怕我已经有一堆其他项目要归档，所以如果您在处理文件系统时能涵盖这个项目，那就太好了:)

当然，如果将它添加到反馈中心对您来说不方便，我仍然会提交它！

Felix-Dev 于 2020-03-27

@Felix-Dev 我会尽力的！将及时向大家发布！

jtorjo 于 2020-03-27

👍1

将文件拖入应用程序不允许写访问：关于反馈中心的相同提议。请提交文件，我会相应地进行路由。

是的，会做 - 将文件拖入应用程序的事情。

这实际上应该是关于从 shell 上下文菜单打开的注释。对困惑感到抱歉。

BenJKuhn 于 2020-03-27

@BenJKuhn鉴于此 Github 存储库是一个比反馈中心更好的讨论特定 WinRT 提案的地方（基于过去 12 个月在此存储库中多次表达的开发人员情绪）：是否可以只发布关于反馈中心的快速提案摘要，其中包含指向此存储库中更深入的提案的链接（目前，因为没有特定的 UWP 应用程序模型反馈平台，我知道开发人员社区对此有信心）？我已经看到提案通过其他社区意见得到进一步完善，因此 Microsoft 的特定团队可以直接链接到正在制定的提案。

Felix-Dev 于 2020-03-28

@Felix-Dev 对于具体的建议，老实说，我认为最好开始将它们提交到标记为“开发者平台 > API 反馈”的反馈中心。

查看最近在该过滤器下提交的反馈，似乎没有添加太多具体的反馈。我只看到在该过滤器下提交的 30 个项目（最多）。然而，工程师们最近对那里的反馈做出了回应。

我呼吁社区通过上面标记的反馈中心提交他们的 API 反馈，一旦提案变得更好，我们将开始看到它作为提交 API 反馈的选项蓬勃发展。

我认为@BenJKuhn会同意我的看法。

duke7553 于 2020-03-28

👍1

我才发现我的回复已经很长了，所以把这当作一个预警😅

@duke7553我们在这种情况下社区应该使用两个不同的平台来提供 UWP 平台反馈。特定的 API 请求，例如（请添加参数 x 到方法 y，或添加一个方法来执行 z）至少应该在反馈中心提交（尽管它们也应该发布在其他地方）。但是，比这更复杂的问题/建议（直到进入 UWP 的核心）平台绝对应该张贴在当前形式的反馈中心以外的其他地方。可以在反馈中心发布简短摘要，但对于其他任何事情，反馈中心现在都不是平台。阅读下面的更多细节，了解原因。

在目前的状态下，开发社区的许多活跃成员并没有根据他们在这个 repo 和 Twitter 等其他地方一次又一次表达的情绪来积极看待反馈中心。例如，这里挑出的问题是：

Windows 开发团队（认为）缺乏参与（我也刚刚查看了最近提交的 API 反馈，那里的许多问题截至目前显示为 0 条评论和 0 条官方回复，尤其是关于 2 个月和旧）。
社区对特定问题/提案的参与度很低（投票、评论）。
反馈中心的整体 UI/UX 真的很难与团队和社区进行反馈讨论。在这一点上，WinUI 团队的一些人表示他们也同意这里的社区。
最后，现在在 Github 上将支持媒体文件（如图像或 GIF）添加到提案中以帮助对其进行可视化要容易得多。提交问题时，我将直接从反馈中心获取此图像：

我之前没有使用反馈中心来归档开发平台的特定问题并立即查看它，看看社区如何接收问题（社区参与几乎为零！），Windows 开发团队及其整体结构，我不得不说这个单一的 WinUI 存储库基本上在各个方面都优于反馈中心（提案创建的难易度/社区参与度/MS 开发人员的可用性/...）。

老实说，它甚至不接近。

尤其是在社区参与方面。我再怎么强调社区在这个 repo 中的投入是多么的特别，并且大大推动和改进了这么多问题/提案。 如果仅在当前的反馈中心提交，那么所有这些伟大的社区意见都会消失。

关于开发团队对我在此处创建的 UWP 应用模型问题的回应，我只想说：在像这样的许多情况下，我得到了及时的反馈，并指出已在内部创建了一个工作项。我还能要求什么？与许多开发人员的情绪形成对比，他们认为如果提交到反馈中心，他们的问题将无处可去。我现在只需查看反馈中心就可以知道它们来自哪里。

@BenJKuhn
MS 的团队需要认真加强他们的 UWP 反馈平台，在我看到这些改进之前，只要 WinUI 团队允许，我将始终在这里使用这个 repo。反馈中心目前在许多 Windows 开发人员眼中处于最低点，一夜之间的帖子不会突然改变这种情况。这是一个开始，但要从根本上消除许多开发人员在谈论反馈中心（或其他 MS 特定的开发人员反馈平台，如之前关闭的 UWP 用户语音）时会得到的负面印象，还需要做更多工作。鉴于许多 UWP/Windows 开发人员在处理反馈中心或其他过去的反馈平台时遇到的许多令人失望的经历，我 - 在这件事上 - 坚信 Windows 开发和反馈团队需要首先加强而不是恳求开发人员返回（没有太多 - 如果有的话 - 可见的改进）。我承认这是一个相当严厉的观点，但如果你仔细看看这些年来开发人员在这个 repo 和许多其他反馈平台中给出的许多回应，你会很容易地看到开发社区中存在真正的挫败感。

我不想在这里太苛刻，因为双方都需要彼此来创建一个充满活力和富有成果的反馈平台，为 Microsoft 和开发人员社区提供高满意度。作为妥协，我在上面的帖子中一直建议在此 repo 中发布 UWP 问题，在那里可以与社区积极讨论这些问题，并发布一个简短的摘要，其中包含反馈中心中包含的 github 线程的链接。除了我上面列出的社区的所有优势之外，添加的链接还将让 Windows 开发团队了解该社区中存在的许多不同观点，甚至可以捕捉到许多可能永远不会被提交的小想法在反馈中心，但可以在此处的许多评论中找到。

我将以从反馈中心的开发人员平台 -> API 反馈部分截取的屏幕截图结束这篇文章：

PS：我将使用这篇文章再次真诚地感谢 WinUI 团队，他们同意开放他们的存储库来托管与 WinUI 完全无关的问题，而是旨在解决开发人员在 UWP 中看到的基本问题。谢谢你，WinUI 团队！

Felix-Dev 于 2020-03-29

👍2 😄1

@BenJKuhn

这是我创建的反馈中心问题

BroadSystemAccess API / 功能在实现时并不实用。 https://aka.ms/AA804aq

BroadSystemAccess API / 当用户允许广泛的系统访问时不应重新启动应用程序https://aka.ms/AA7zpe3

剪贴板应该一直工作。 https://aka.ms/AA804ce

文件系统访问：提供一种用户友好的方式来请求访问特定文件位置的权限https://aka.ms/AA804cp （对于 @Felix-Dev）

WinRT https://aka.ms/AA804d0上没有好的音频 API

异步 API 仍然失控，对于不应该是异步的东西似乎很尴尬https://aka.ms/AA804d3

我创造的其他东西

更多细节 - 应该允许更多字符https://aka.ms/AA7zws5

选择一个类别 - 让这更容易https://aka.ms/AA804cd

我不确定的事情

拖放文件/文件夹- 我没有亲自测试过。也就是说，我对拖放部分不感兴趣，这不是很难实现。我很好奇当用户在 UWP 控件上放置文件/文件夹时它是否真的有效。我有只读访问权限吗（这对我来说就足够了）？我可以将这些文件/文件夹添加到 FutureAccessList 吗？

我很好奇是否有人成功测试/使用过它，因为网上没有那么多信息。

反馈中心

反馈中心不是一种愉快的体验。一方面，我添加的问题暂时不会出现在“我的反馈”中 - 我需要关闭并重新启动应用程序。它不记得我上次的选择。我不能写太多文本，无法删除文件和/或剪贴板图像。所以我几乎完全同意@Felix-Dev - 真的很难理解在哪里发布问题（除了从现在开始将发布到 xlang）。

jtorjo 于 2020-03-29

👍2

@BenJKuhn以下是特定 Toast 通知问题的反馈中心链接，在用户与之交互时可以访问剪贴板： https :

Felix-Dev 于 2020-03-29

感谢大家的精彩讨论。我已将您提交给相应团队的每个平台问题路由。为了相应地设定期望，让我从求职中做一个类比：这有点像在招聘过程中通过筛选并直接进入面试。从这里开始，每个问题都掌握在合适的团队手中，以进行调查和确定优先级。

我感谢您为报告这些问题所做的努力，并将在团队审查它们时继续跟踪它们。我希望你们每个人都继续就遇到的问题与我们联系，我将尽我所能支持你们改进 Windows 上的应用程序开发人员体验。

谢谢，

本·库恩

BenJKuhn 于 2020-03-30

❤3 🚀1

@jtorjo你能分享你构建的 NAudio 的 UWP 端口的WACK报告吗？

这些数据将帮助我们评估需要放宽哪些限制，以便 NAudio 能够通过 Store 认证。

mikebattista 于 2020-03-31

@mikebattista我附上了 WACK。请仅考虑 naudio 问题。

显然，来自 log4net 的问题也很容易解决，即使我假设通过 fork log4net 并删除这些调用，我应该没问题。然而，他们出现很奇怪，因为我很确定我们从未真正被召唤过。反正...

FindFirstFileExFromApp - 这应该（并且实际上存在） - 它绝对不应该被标记。

您可以忽略 EnumChildWindows/EnumWindows - 我可以 #ifdef 将它们排除。

验证结果.zip

jtorjo 于 2020-04-01

谢谢！我们将评估支持的 API 故障。我已经联系了音频团队，征求他们对可能放宽此处的任何限制的意见。

mikebattista 于 2020-04-01

🚀1

@mikebattista很棒，谢谢！很期待这个：）

jtorjo 于 2020-04-01

@jtorjo关于拖放场景：

它适用于文件和文件夹吗？
它应该并且适用于许多应用程序和测试，如果您发现其他情况，请提交一个错误。
我可以访问 .Path 吗？
也许 - 如果有一个真实的文件系统路径来支持存储项目，那么是的。（像 shell 库这样的东西实际上没有真正的文件系统路径）
它是持久的（我认为不是）吗？
不，该应用程序可以通过将其添加到未来访问列表来使其持久化。
我是否需要挂在 StorageFile/Folder 上，或者稍后从 .Path 重新创建它会起作用（假设 2. 的答案是肯定的）？
您需要将其添加到未来访问列表或最近使用的列表中，否则您拥有的唯一访问权限是通过该对象实例，当您释放该实例时，访问权限将消失。

关于从任意位置添加视频文件 - 系统故意不允许任意访问，但是应用程序仍然可以处理放置在备用位置的文件的常见情况，并且用户尚未更新库以包含它们。索引器和存储感知服务都包含定期扫描驱动器以获取详细信息（文件大小等）的代码，并利用它们来定位照片和视频文件。应用程序可以使用StorageLibrary API来确定是否找到了库中没有的任何此类位置，如果是，则提示用户添加它们。（这让用户负责并允许常见的情况）没有任何东西会自动添加包含文件的所有位置，因为无法确定这是否是正确的做法。 [例如，我使用了许多 3D 模型构建和渲染工具，并且我不想在我的照片库中显示数以千计的纹理图像]

'FindFirstFileExFromApp - 这应该（并且实际上存在） - 它绝对不应该被标记。
完全同意所有 *FromApp API 都是为应用程序容器应用程序设计和使用的。因此，如果这些工具标记了其中任何一个，那就是我们需要解决的错误。

smaillet-ms 于 2020-04-02

@smaillet-ms 感谢您在此回复。是否正在努力提高 Windows.Storage API 的速度？我们已经等待答案很长时间了。我愿意签署保密协议，以便在我的应用场景中使用改进的 API。

我目前使用 FindFirstFile 的 FromApp 实现，但无法使用 FromApp API 获取项目缩略图。

这种为改进 Windows 运行时所做工作的保密程度与 Microsoft 工程师之前在线程中共享的内容形成鲜明对比。

Microsoft-ui-xaml: 讨论：为 WinRT 增加价值的机会

讨论：为 WinRT 增加价值的机会

查询文件 API 非常慢

广泛的系统访问 API

创建用于在 MS 商店外进行旁加载的应用程序

“新证书”问题

互操作性：零

最有用的评论

WinRT vs. UWP vs. .NET – 一些背景

对特定 API 的反馈

现代应用程序的文件系统 API 令人痛苦且出乎意料地缓慢

BroadSystemAccess API / 功能在实现时并不实用。

创建用于在 MS 商店外进行旁加载的应用程序

新证书发行和私人分发

WinRT 类型系统影响提供出色 API 和库的能力

反馈中心应在放弃时提示，防止内容被误删

异步 API 仍然失控，对于不应该是异步的东西似乎很尴尬

WinRT 上没有好的音频 API

剪贴板之痛

包起来

所有108条评论

诺基亚灾难性错误的重演

重大变化

对托管代码的立场逆转

列列表 GUI 的意义

C++/CX 最近被 C++/WinRT 取代

UWP 文件系统仍为 alpha 版本

让我在这里坦率地说 -任何非平凡的应用程序都不是生活在真空中。

WinRT vs. UWP vs. .NET – 一些背景

对特定 API 的反馈

现代应用程序的文件系统 API 令人痛苦且出乎意料地缓慢

BroadSystemAccess API / 功能在实现时并不实用。

创建用于在 MS 商店外进行旁加载的应用程序

新证书发行和私人分发

WinRT 类型系统影响提供出色 API 和库的能力

反馈中心应在放弃时提示，防止内容被误删

异步 API 仍然失控，对于不应该是异步的东西似乎很尴尬

WinRT 上没有好的音频 API

剪贴板之痛

包起来

WinRT vs. UWP vs. .NET – 一些背景

现代应用程序的文件系统 API 令人痛苦且出乎意料地缓慢

BroadSystemAccess API / 功能在实现时并不实用。

创建用于在 MS 商店外进行旁加载的应用程序

反馈中心应在放弃时提示，防止内容被误删

异步 API 仍然失控，对于不应该是异步的东西似乎很尴尬

WinRT 上没有好的音频 API

剪贴板之痛

这是我创建的反馈中心问题

我创造的其他东西

我不确定的事情

反馈中心

相关问题