感谢您听取社区反馈。 我对 WinUI 3.0 (Win32 + WinUI + C++) 感到非常兴奋。 这感觉就像我们一直在等待的框架！ RIP GDI 😉

(Win32 应用程序模型) + (WinUI 3.0 UI) + (.NET 或 C++ 语言)

所以这基本上是 UWP UI，但没有类似电话的生命周期和沙箱？ 这对于桌面应用程序来说似乎很有趣——我将对此进行试验。

感谢您的更新，希望随着 WinUI 3.0 的初始功能集被锁定，以及任何已提出的新控件或控件功能可能会进入 WinUI 3.0，将会有更多更新。

哦，关于WinUI 在桌面中如何工作的文档，与 UWP、WPF 和 Win32 不同，这对于预先解决即将出现的无数问题非常有用。

也许是一个很好的矩阵，其中包含框架和 API 的组合，以及我们在 Build 中获得的架构图！

你们太棒了，感谢一切！
xplat 部分让我很开心，尤其是 Uno 受到关注。

我们的重点仍然是 Windows 10 和 8.1，但我们听到反馈说你们中的一些人仍然有 Win7 的用户和客户，我们将随着时间的推移评估市场和选项。

假设 UI 框架的这种植入是在设计时考虑了可移植性，至少足以使其 UI 核心（渲染/输入）可以在任何支持 .NET Core 3+ 的 Windows 操作系统下运行。Windows 7 上会有什么限制？是？ 似乎人们在桌面上使用的大多数功能都可以使用，而对于特殊/特定平台的功能，则可能无法将它们作为核心 UI 系统的一部分，而是将它们保存在特定于平台的软件包中，例如（Win10、 Win8.1、Win7 Nugets 等）。

此外，如果有一个跨平台的 XAML，它在所有设备（Win32、Android、iOS 和 WASM）上都具有相同的外观和感觉，就像您可以使用 HTML（但遗憾的是 Xamarin）一样，我的公司几年前就会跃跃欲试。

也很高兴你们认为这是一场“马拉松（很棒的 Bungie 游戏）”。 XAML 空间中的碎片越少对每个人都越好，走很多捷径只会让你回到开始的地方;)

与 UWP、WPF 和 Win32 不同的有关桌面中的 WinUI 如何工作的文档将非常有用

我们正在研究它，并将随着它的发展分享更多！

假设 UI 框架的这种植入是在设计时考虑了可移植性，至少足以使其 UI 核心（渲染/输入）可以在任何支持 .NET Core 3+ 的 Windows 操作系统下运行。Windows 7 上会有什么限制？是？

@zezba9000 WinUI 不使用 .NET，并且您不一定必须将 .NET Core 与 WinUI 一起使用：它是一个基于 OS API 构建的本机框架，它依赖于 Win8/Win10 中不存在的新功能Win7 - 在某些情况下是核心功能，而不仅仅是更高级别的附加功能，如特定控件。

与 UWP、WPF 和 Win32 不同的有关桌面中的 WinUI 如何工作的文档将非常有用

我们正在研究它，并将随着它的发展分享更多！

假设 UI 框架的这种植入是在设计时考虑了可移植性，至少足以使其 UI 核心（渲染/输入）可以在任何支持 .NET Core 3+ 的 Windows 操作系统下运行。Windows 7 上会有什么限制？是？

@zezba9000 WinUI 不使用 .NET，并且您不一定必须将 .NET Core 与 WinUI 一起使用：它是一个基于 OS API 构建的本机框架，它依赖于 Win8/Win10 中不存在的新功能Win7 - 在某些情况下是核心功能，而不仅仅是更高级别的附加功能，如特定控件。

对于 Windows 7 兼容性 - 它需要一些第三方为 XAML 构建他们自己的兼容渲染器，以及需要的任何操作系统级 API 的某种替代 Shim。

现在不知道这是否可行——希望当 WinUI 位从操作系统中删除时，它们以某种方式放入开源项目，这将使其他平台能够提供某种兼容性组件。 想想带有自定义渲染器的 Xamarin、Uno 或 .Net Core。

它是一个基于 OS API 构建的本机框架，它依赖于 Win8/Win10 中 Win7 中不存在的新功能 - 在某些情况下是核心功能

在我看来，除了渲染和输入之外，什么构成了“核心功能”不会依赖于操作系统的细节。 在这些情况下，这将是任何人都可以扩展的抽象层。 在基础级别，理论上应该能够使用自定义软件渲染器渲染 UI，并在需要时使用带有虚拟光标的自定义 XInput 后​​端进行输入。 如果你能做到这种模块化，你几乎可以做任何事情，并且扩展平台支持变得非常容易（就像在游戏中所做的那样）。 你在这方面多花一点时间，在路上，一切都会少很多努力。 如果 WPF XAML 是按照这种方式设计的，那么它可能刚刚被采用并用于 UWP 应用程序中。 否则，技术债务将成为无休止的循环。

托盘图标支持等可以在“WinUI Windows 基本功能（Win7-Win10）”包中。 推送通知之类的东西可以在“WinUI Windows 扩展功能（Win8-Win10）”包中。

希望这是有道理的。

@mdtauk , @zezba9000这在理论上都是可能的，我们团队中有很多平台抽象专业知识。 与任何事情一样，它归结为成本、进度和预期收益😊

除了开发和测试成本（这会扩展到潜在的非显而易见的领域，例如确保一切都可以使用旧的辅助技术），我们还必须考虑长期的支持成本。

您是否希望在 2020 年以后在 Win7 上有新客户？ 反馈和明确的用例确实帮助我们确定优先级。

除了开发和测试成本（这会扩展到潜在的非显而易见的领域，例如确保一切都可以使用旧的辅助技术），我们还必须考虑长期的支持成本。

您是否希望在 2020 年以后在 Win7 上有新客户？ 反馈和明确的用例确实帮助我们确定优先级。

@jesbis我没有看到为 WinUI 3.0 增加对 Win7 的兼容性 - Linux、Android、iOS、iPadOS 和 MacOS 但是，可能有利于提供不依赖于本机 UI 框架的跨平台解决方案。

@mdtauk
@jesbis我没有看到为 WinUI 3.0 增加对 Win7 的兼容性 - Linux、Android、iOS、iPadOS 和 MacOS 但是，可能有利于提供跨平台解决方案。

同意这一点。 我只是添加了 web-assembly，对我来说它甚至比 Linux 更重要。

您是否希望在 2020 年以后在 Win7 上有新客户？ 反馈和明确的用例确实帮助我们确定优先级。

不，我的公司没有。 我在一个我看到 XAML 在所有迭代中挣扎的领域给出了更多的设计论点（从我的角度来看），但是我完全明白为什么 MS 不想在那里花时间。 但是，如果 WinUI 有足够的能力让其他人在需要时（我已经注意到这种情况经常发生）来完成这项工作，而不会像现在的 WPF 那样陷入 Windows 依赖项的兔子洞，那将会很酷。

要明确我的公司希望看到的是 Android 和 WASM 支持比 UNO（以及 3 年前）更正式一点。 我们制作管理软件来管理本地计算机和系统设置集合的状态，通常涉及对 Win32 API 的大量需求（UWP 永远不会为我们工作，但我们喜欢 UI，因为与 HTML 构建系统不同，编译时错误）和我们的客户 + 我们需要具有统一体验和感觉的 Win32 + Android + 浏览器 UI 体验。 HTML 只是一个很大的痛点，因为它增加了不必要的抽象和复杂性，否则我们的主要代码库是在 C# 中不需要存在的。

希望这对你来说是更好的反馈。

同样是的，与任何其他平台相比，WASM 是我们想要的最大目标。 到目前为止！！
因为它解决了我们的 Android / iOS / 移动问题以及门户网站的问题。

感谢您聆听反馈！

桌面 + WASM 将是黄金！

哇，谢谢你的呼喊，@jesbis！ 完全出乎意料，非常感谢和尊重。 👍

围绕 Windows 7 的讨论有点令人分心，因为工作量（更不用说成本）会导致 WinUI 3.0 的显着延迟。 Windows 7 将于 1 月停产，我们鼓励所有客户升级到 Windows 10。我的客户可能不会与其他人保持一致，但即使是 Windows 8.1 也不是我们感兴趣的平台。

对更新很满意。 WinUI 即将到来的目标看起来非常光明和有希望！ 甚至 Xplat 部分也是我没想到的，但非常受欢迎。 将期待使用 WinUI 的改进以及商店中的好东西。

感谢团队的透明度。

我想提一下业务线软件在帮助人们解决各种问题方面的重要性。

我使用 Lightswitch 工具工作了一段时间，并显着缩短了构建时间。 LOB 应用程序的快速应用程序开发非常有前途。 但由于美国的专利战非常重视，因此该产品被终止。

我们知道我们有 INotifyDataErrorInfo 用于下一次交付。 但是，如果 WinUI 具有用于未来交付（例如 3.x）的 RAD 资源，那就太好了。

谢谢团队，等不及你用铅笔写 webassembly 的那一天了。 它将使我度过一天、一年和十年，并将 MS 置于技术堆栈的顶端。 WinUI + Xamarin + WASM + .NET => 纯真棒！！

@jesbis感谢您的更新。 良好的工作团队：+1：。 了解它还为时过早，您认为我们什么时候会看到

您认为我们什么时候会看到 WinUI 3.0 里程碑的创建和针对它的问题？

@shaggygi好问题！ 我刚刚创建了它：

WinUI 3.0 里程碑

这是很棒的家伙！

快速提问：将 Windows.UI.Composition 移动到 Microsoft.UI.Composition，这更接近 2.2 还是 3.0？
在预期的时间范围内，当 3.0 可用时，这会是 2-3 个月或更长时间吗？

将来，当您谈论年份（如“年底”）时，请您清楚日历年和 [Microsoft] 财政年。
如果没有明确说明，很容易产生混淆，而且我知道有时这会导致人们相信事情会比预期提前 6 个月到来。

将 Windows.UI.Composition 移动到 Microsoft.UI.Composition，这更接近 2.2 还是 3.0？

@jtorjo这将是 3.0（至少）。 我们希望在 3.0 的第一个预览版中包含一个早期版本，但还不能 100% 保证。

将来，当您谈论年份（如“年底”）时，请您清楚日历年和 [Microsoft] 财政年。

@mrlacey谢谢，我会记住的！ 我们使用的所有日期通常都是日历时间。

@jesbis这有点可悲。 所以你是说我们有可能在 3.0 中没有 Microsoft.UI.Composition？

@jtorjo

我们希望在3.0的

通常有许多预览版本。 例如，.NET Core 3 在 Preview 6 上。

我们的计划是在 3.0 中包含组合 API。

不过，Xaml 框架部分在组合部分之前将是开源的。

@jesbis谢谢，听起来不错！

很棒的路线图，很棒的工作！

和这里的每个人一样，我喜欢它的透明度，我真的很期待 WinUI 3.0。 对我来说，WinUI 3.0 是自 2006 年推出 WPF 以来最令人兴奋的事情。

我还有运行 Windows 7 的客户，但我认为 Windows 10 支持是最重要的，我不会花费时间和资源来支持 Win7。 我工作的大多数公司都改用 10 了。而且我认为到 2020 年末，我所知道的唯一一家仍在使用 Windows 7 的公司可能是我的牙医。 如果他让我为他编写 Windows 应用程序，我会将他的 PC 迁移到 Windows 10。:-)

未来对 WASM 的支持将是惊人的。

昨天在一个会议上：

一个向@jesbis和我们在这里写作和参与的团队展示的小故事只是激动人心的冰山一角。 :-)

就在昨天，我在德国的一个开发者大会上与一些 .NET 开发者聊天，我向他们介绍了 WinUI 3.0，但他们并不知道。 我告诉他们路线图，他们说：

“哇，太神奇了”。

群里的一个女生问我：

“但你能不能把这一切都告诉我们？”

我看着她和其他人，然后我抓住机会在

await Task.Delay(3000);

在我说之前

“是的！你可以在 GitHub 上阅读这一切”。

感谢@jesbis和所有参与的人。 成为 Windows 开发人员的美好时光❤️

我希望第一方应用程序（如 Word？）可以使用 WinUI 的层，开发人员会很高兴看到，“嘿，WinUI 是可以运行业务的真实事物，而不是玩具”。
如果他们已经在使用它，请大声说出来。

用于 WPF、Win32 和 WinUI 桌面的亚克力。

哦，也许只在活动 Windows 策略上重新考虑亚克力。

是的，如果您有 1 个以上的显示器，它只会在一个窗口中呈现。 至少在多台显示器中它应该可以正常工作......

我在考虑在 UWP 应用程序中提供两组 UI 控件对开发体验的影响 - 当我们可以访问 WinUI 控件和旧版 UI 控件时，当在 C# 代码隐藏中时，IntelliSense 因为它总是需要我们正确地选择控件应该来自哪个命名空间，而不是使用Alt + Enter来添加using并继续。 有可能以某种方式避免这种情况吗？

一旦 WinUI3 面向开发人员推出，Windows 10 SDK 应考虑建议更改安装了受支持 SDK 的项目的命名空间。 尽量让人们远离操作系统的 namspaces。

用于 WPF、Win32 和 WinUI 桌面的亚克力。

我想看到的首先是MS成熟的XAML群岛足以让，作为一个例子，丙烯酸系标题栏，可用于非UWP项目的基础上WinUI他们的UI（见的最后一段这篇文章）。 @marb2000可能是问这个问题的人。

@MartinZikmund我们希望避免这种情况。 使用 WinUI 3 时，您应该只能访问包中的控件。 我们的想法是我们拥有您需要的一切，并进行最新和最大的更改。

@MartinZikmund
@卢卡斯海恩斯

一种解决方法应该是，您可以从构建中排除Windows.UI.Xaml.* WinMD 引用。 现在构建目标仅引用 Unified WinMD aka。 Windows.winmd ，在目标中添加一个选项来引用单个 WinMD，这样，我们可以根据我们正在构建的应用程序包含或排除引用。

是这样吗，那么就不需要更改命名空间，因为它的行为类似于 .NET dll它可以将程序集重定向到包内的本地版本，而不是系统提供的版本。

我知道该方法专门针对 .NET Framework，但对于 UAP，应该有针对此类场景的解决方案。 我知道msix/appx清单上有 FrameworkDependency。 也许我们可以使用它来为新的 WinUI 提供Windows.*命名空间而不是Microsoft.*命名空间。

在开发方面，我们升级应用程序的痛苦会更小，因为我们只更改引用而不是代码！

我宁愿根本不更改命名空间！

好处：

1. 不必来回更改代码。

2. 本地 WinUI 代码稳定后，您可以合并回 Windows 平台，以便系统应用程序和 LOB 应用程序可以在每个新的 Windows 版本中利用新的改进。

3. 一方面它是一个高度稳定的系统框架，具有高兼容性，如 .NET Framework。 另一方面，它就像 .NET Core，变化速度更快，具有两者的所有优点，但没有任何问题。

刚刚观看了 Steve Sanderson 在 Blazor +（非 html）UI 上的精彩演示，该 UI 包含在跨平台本机应用程序中。 视频播放约 52 分钟。 UWP、WinUI 和 c# 爱好者的必看之物。 我对 blazor 印象深刻！！！

https://youtu.be/uW-Kk7Qpv5U

在这些讨论中我忘记说的一件事，我认为很重要的是......
WinUI 3.0 本身有什么性能提升吗？ 是 XAML 渲染引擎刚刚解耦还是正在发生变化？ XAML 控件是否会主要使用 Composition，从而像 DirectUI 一样使用线程外和 dwm 驱动？

某些控件的性能和 RAM 使用情况可能会好得多，例如 ListView/GridView = ItemsControl。

您可以在 Windows 本身上看到这一点。 Windows 8 开始菜单 (DirectUI) 比 Windows 10 XAML 开始菜单更流畅。
尝试加载具有足够信息的 GridView，例如 Groove Albums 页面，但事情并不顺利。 这是 iOS 和 Android 表现得更好的地方，winforms、QT 也是如此。
（在我看来，WPF 甚至比 UWP XAML 还要糟糕）。

WinUI 3.0 本身有什么性能提升吗？ 是 XAML 渲染引擎刚刚解耦还是正在发生变化？ XAML 控件是否会主要使用 Composition，从而像 DirectUI 一样使用线程外和 dwm 驱动？

性能绝对是我们想要继续投资的东西，但我不希望 3.0 有任何改进。 最初的 3.0 努力主要集中在将 Xaml 解耦以作为 NuGet 包和开源发布。

WinUI 3.0（就像今天的 UWP Xaml）建立在合成层上，并通过 DWM 运行其大部分渲染和动画离线。

这是 iOS 和 Android 表现得更好的地方，winforms、QT 也是如此。
（在我看来，WPF 甚至比 UWP XAML 还要糟糕）。

在考虑这些场景时，通常会在性能与灵活性/丰富度之间进行权衡。 基于 Xaml 的平台（包括 UWP 和 WPF）往往为每个控件拥有更大、更丰富的 UI 对象树：这为更改任何控件的样式和 UX 提供了很大的灵活性，而其他一些平台往往具有更扁平的对象树不那么灵活，但有时可以更快地加载。

这种权衡绝对是我们考虑的事情，并将牢记于未来的潜在变化。 复杂 Xaml 控件模板的额外灵活性在很多时候不是必需的，因此我们可以简化控件以在您不需要额外灵活性的情况下更快地加载。

希望微软能提供一个新的基于WinUI 3.0的comctl32.dll和comdlg32.dll。

因为大多数 Win32 应用程序将具有现代 UI 体验，它将帮助开发人员使他们的应用程序适应现代 UI。

许多 Win32 开发人员需要适应多个 Windows 版本。 所以他们今天不能直接使用WinUI。 如果 Microsoft 能够提供一种方法来帮助他们减少应用程序 UI 现代化的工作量，那就太好了。

另外，我希望微软可以为使用 WinUI 的 C++ Win32 应用程序提供 XAML 设计器。

毛利健二

@MouriNaruto您今天可以使用FileOpenPicker （来自 Win32）。

@MouriNaruto您今天可以使用 FileOpenPicker（来自 Win32）。

我知道，但我希望所有现代通用控件和对话框都将带入 Win32。

@毛利火影忍者

从技术上讲是可能的。 但是 Windows 开发人员不仅要重新创建COMCTL和COMDLG实现的确切行为，还要重新创建代码库中存在的已知和未知错误。

兼容性是我们的敌人！

即使他们这样做了，到他们完成时，每个使用这些库的软件都有足够的时间迁移到 WinUI！ 具有讽刺意味的！！ 🤨🤣

@MarkIngramUK

仅供参考： FileOpenPicker不是本机 WinRT 对话框/控件。 它本质上是ExplorerFrame的包装，它本身是用DirectUI （由 ATG 团队开发并基于DirectX ）和COM编写的！

从技术上讲是可能的。 但是 Windows 开发人员不仅要重新创建 COMCTL 和 COMDLG 实现的确切行为，还要重新创建代码库中存在的已知和未知错误。
兼容性是我们的敌人！
即使他们这样做了，到他们完成时，每个使用这些库的软件都有足够的时间迁移到 WinUI！ 具有讽刺意味的！！ 🤨🤣

由于现实，我认为许多项目在没有它的情况下迁移到 WinUI 并不容易。

你说过“兼容性是我们的敌人！”。 是的，这也是我提出建议的原因之一。 具有讽刺意味的！！ 🤨🤣

即使 WPF 和 WinForms 必须选择使用新版本，我也会为通用对话框的 XAML WinUI 版本感到高兴。

WinUI 3 目标听起来非常令人兴奋，我很期待。 在使用 WinUI 3 的经典 Win32 应用程序的上下文中，我有一些关于分发/部署的问题

1. 是否每个应用程序都需要自带它的 WinUI 库，或者可以在应用程序之间共享，甚至可能通过 Windows 机制自动共享
2. 是否可以静态链接 WinUI？
3. 假设我必须重新分发它，WinUI 大概有多大（以 MB 为单位）？

是否每个应用程序都需要自带它的 WinUI 库，或者可以在应用程序之间共享，甚至可能通过 Windows 机制自动共享

我们计划主要通过 NuGet 分发 WinUI 3，它具有自动缓存和共享包的机制 - 此处提供更多信息：

https://docs.microsoft.com/nuget/what-is-nuget#what -else-does-nuget-do

https://docs.microsoft.com/nuget/consume-packages/managing-the-global-packages-and-cache-folders

是否可以静态链接 WinUI？

这不是我们目前正在计划的事情 - 你有没有想到这会带来好处的场景？

假设我必须重新分发它，WinUI 大概有多大（以 MB 为单位）？

我们仍在研究最终的依赖关系图会是什么样子，但对于 UI 部分，它可能类似于相关的现有 system32 dll 大小（10 兆字节）。

我们计划主要通过 NuGet 分发 WinUI 3，它具有自动缓存和共享包的机制

我认为 nuget 只是为了开发还是我错过了什么？ 据我所知，基于 nuget 的包必须由每个应用程序单独部署，不能共享。 这就是为什么共享 dotnet 核心运行时有专用安装程序的原因，否则考虑到 dotnet 核心包已经在 nuget 上，就没有必要了...

您不必为了共享 UI 框架包而安装任何开发工具或 SDK。 WPF 和 WinForms for .NET Core 遇到了同样的问题，并投资构建了一个共享包，这样人们就不必在最终用户机器上安装 SDK，一旦你到达那里，这对 WinUI 也可能是值得的（甚至可能让自己包含在 WindowsDesktop 包中）

特别是 VS 中已经有用于依赖于

对于 Microsoft Store 交付的应用，发布包内容也应在部署时自动共享。

对于通过其他方式部署的 win32 应用程序，在我们的待办事项列表中可以调查您提到的选项😊

是否可以静态链接 WinUI？

这不是我们目前正在计划的事情 - 你有没有想到这会带来好处的场景？

我想我需要澄清一下：是否可以在静态链接的 EXE（静态链接 VC-Runtime）中使用 WinUI？ 我认为这应该不是问题，因为 C++/WinRT 但我只是想确定......

假设我必须重新分发它，WinUI 大概有多大（以 MB 为单位）？

我们仍在研究最终的依赖关系图会是什么样子，但对于 UI 部分，它可能类似于相关的现有 system32 dll 大小（10 兆字节）。

感谢您的信息。

顺便说一句，对于如此庞大的事业来说，透明度很棒，我非常喜欢它。

我想我需要澄清一下：是否可以在静态链接的 EXE（静态链接 VC-Runtime）中使用 WinUI？ 我认为这应该不是问题，因为 C++/WinRT 但我只是想确定

这应该是可能的（理论上），但正如@jesbis所说，我们仍在研究未打包的应用程序将如何进入共享框架的故事。 我们可能需要一个 redist 安装程序，就像 .NET Core 的做法一样。

围绕 Windows 7 的讨论有点令人分心，因为工作量（更不用说成本）会导致 WinUI 3.0 的显着延迟。 Windows 7 将于 1 月停产，我们鼓励所有客户升级到 Windows 10。我的客户可能不会与其他人保持一致，但即使是 Windows 8.1 也不是我们感兴趣的平台。

你是对的。 但是我们无法控制我的客户，在中国有超过 60% 的系统是 win7。 而且我们不能放弃这个市场，所以不能使用任何不支持win7的技术。

数据来自百度，见https://tongji.baidu.com/data/os

但是我们无法控制我的客户，中国有超过 60% 的系统是 win7

TBH 如果你坚持使用 Win7，我会坚持使用 .NET Framework 4.8 + WPF。

但是我们无法控制我的客户，中国有超过 60% 的系统是 win7

TBH 如果你坚持使用 Win7，我会坚持使用 .NET Framework 4.8 + WPF。

但是Win7 Sp1可以安装.NET Framework 4.8，没有sp1的win7不能安装。

.NET Framework 系统要求 |

如果您甚至没有 SP1，那么您的生命周期就已经过去了 6 年。

对不带 Service Pack 的 Windows 7 RTM 的支持已于 2013 年 4 月 9 日结束。

https://support.microsoft.com/en-gb/help/13853/windows-lifecycle-fact-sheet

如果你想要 Windows 7 支持，你应该使用已经支持 Windows 7 的技术，而不是指望微软为你解决这个问题。

@MarkIngramUK并不是微软为我解决了这个问题，而是我无法支持我的客户在没有 sp1 的情况下使用 win7。 我无法控制我们的客户使用任何系统，但是那些使用win7而没有sp1的人会放弃我们的应用程序，这意味着我们失去了这个市场。 但是我的那些不使用新技术的竞争对手可以在没有 sp1 的情况下支持 win7，我的竞争对手将赢得这个市场。

可悲但真实，太多客户并不关心我们使用什么技术，但他们关心应用程序能否在他们的所有设备上运行良好。

这是我所在行业的现状，以上结论可能不适用于其他行业。

@lindexi就像我说的那样，您不能指望将新技术移植到已经

@lindexi我认为如果客户不想使用受支持的技术并且更喜欢过时的东西，那么他们就不能合理地期望拥有现代 UI。 这两个要求完全是相互排斥的......

@MarkIngramUK伤心。 我想当我可以使用今天的新技术时，这种新技术已经成为旧技术。

@lindexi这实际上与正在发生的事情相反。 你不能仅仅因为新技术没有被移植到一个古老的操作系统上就将它称为“旧技术”。 如果您想要 Win7（无 SP1）支持，请使用 WinForms 或 MFC 或其他东西。

@MartinZikmund你是对的。 其实我们的用户几乎没有懂电脑技术的，连win7和win10都分不清。 他们不在乎我们使用什么技术。

@jesbis我很想用 C++ 来体验新的 WinUI。 过去我尽我所能使用 UWP 和 C++/Cx，但除了 PhotoEditor 应用程序和一些示例之外，你总是在挠头并试图找到一些好的文档，例如将 XAML 与 Platform::Collections 和诸如此类的东西绑定那。 这是我在 Windows 上切换回 C# 进行 UWP 和 Qt 进行 C++ 开发的原因之一。 请多多爱C++。

在我的客户身上，我使用了带有 Windows 10 Media 的 USB 记忆棒 (PenDrive)，并且只需免费将其从 Windows 7 升级到最新的 Windows 10。 他们获得了现代操作系统的好处，包括防病毒、Windows 更新、Edge WebBrowser，并支持从 WinForms、WPF 等较旧的 GUI 技术到包括 UWP 及更高版本 (WinUI) 在内的较新的 GUI 技术。 此外，我没有关闭关机，而是将 Windows 设置为休眠，并教用户只需按下电源按钮即可开始使用 PC，并在使用完 PC 后按下电源按钮。
我还在网络上放了一个 ISO，以便轻松安装/升级机器。

而且他们的计算机上也预装了 Candy Crush！

观点

我认为 WPF 的控件实现可以合并到 WinUI 中以获得旧版本的 Windows 支持。 （例如，Windows 7。）但由于办公室政治，微软很难实现它，哈哈。

回复

@lindexi
我知道今天中国有很多过时的Windows版本用户。 但我认为今天有必要放弃 Windows NT 5.x 用户，我知道这很难。

@MartinZikmund

我认为如果客户不想使用受支持的技术并且更喜欢过时的东西，那么他们就不能合理地期望拥有现代 UI。 这两个要求完全是相互排斥的......

如果您不希望您的作品为少数人服务，那么现代 UI 和旧平台支持在中国都是必要的。 因此，我的一位朋友，一位中国开发人员，在没有安装任何更新的情况下将Blink 和 V8 移植到 Windows XP，许多开发人员使用它来实现他们的现代应用程序体验。 在中国，最低操作系统版本要求等于未安装任何更新的版本。 例如，如果您知道来自中国的应用程序的操作系统版本要求是Windows 7，则它告诉您可以在“Windows 7 RTM”或“6.1.7600.16385 (win7_rtm.090713-1255)”下使用该应用程序。 即使在 Android 世界中，今天仍有许多应用程序支持 Android 4.4。

这就是为什么大多数非中国开发商制作的应用程序在中国不能成为多数人的选择。

PS 我们可以使用最新的Visual Studio 2019 为 Windows XP RTM 构建应用程序，无需安装任何更新，使用最新的Windows 10 SDK 和最新的C++17 标准，或者现在尝试 C++20。 因为 VC-LTL(https://github.com/Chuyu-Team/VC-LTL) 和 YY-Thunks(https://github.com/Chuyu-Team/YY-Thunks)。

注意我自己

在我的大部分时间里，我使用最新的稳定 Windows 版本。 （我今天使用 10.0.18362。我使用 19H1 和 19H2。）但是我的 Win32 项目专为 Windows Vista RTM 设计，没有安装任何更新，我的 UWP 项目专为 Windows 10 版本 1703 设计，没有安装任何更新或更高版本，因为有条件RS2 中引入了 XAML 支持。 （我喜欢条件 XAML。为什么它在 Windows 10 Build 14393 上不存在？）

毛利健二

请，请考虑取消密封所有 WinUI 3.0 控件类！

根据我的理解，微软决定密封所有 UWP 控件类，因为 JavaScript（不知道继承）在与继承类一起使用时会导致问题。 现在 JS/HTML 已被弃用，新的​​ UI 框架不再需要仍然密封所有类。 取消锁定将使自定义 UWP 控件变得更加容易，就像在 WPF 中总是可能的一样。 在编写自定义虚拟化列表控件或面板时，拥有一个未密封的虚拟化基类来继承也会有很大帮助。 C#、C++/CX 或 C++/WinRT 都没有继承问题。 只有被称为 JS/HTML 的失败才迫使我们这样做。

所以请在创建 WinUI 3.0 时去掉这个不必要的限制。

@gisfromscratch感谢您的反馈！ 我们肯定希望支持 C++ 开发（特别是使用 C++/WinRT）。

什么会使使用 C++ 更容易？ 您是否尝试过C++/WinRT而不是 CX？

更多示例应用程序会有所帮助吗？

您提到很难找到有关绑定的文档：是否还有其他特定功能需要更好的文档？

请，请考虑取消密封所有 WinUI 3.0 控件类！

@lukasf这是我们可能会做的事情🙂 #780 中正在进行一些相关的讨论

@jesbis我必须更多地使用 C++/WinRT。 我只是按照照片编辑器 C++/WinRT 示例应用程序进行操作。 但是，当您深入阅读提供的链接（如

@gisfromscratch谢谢！ 我们在更新 WinUI 3 的文档时会牢记这一点。

如果有帮助，您提到的数据绑定页面还链接到一些单独的页面，专门关于使用 C++/WinRT 进行数据绑定，例如：

XAML 控件；

XAML 项控件；

该部分还有许多其他特定于 C++/WinRT 的主题。

感谢您的出色工作！ 很高兴看到Xaml Island从 WinUi 3.0 中删除。
顺便说一句：我只是想知道 WinUi 3.0 中语言投影的低级实现是否会与 WinRT 组件不同。 WinRT 组件的语言投影的实现在 .NET UWP 项目中似乎在编译时和运行时都有巨大的性能损失。 由于WinUi 3.0与UWP完全解耦，希望在语言互操作的实现上能有一些改进。

@zenjia XAML 岛不会从 WinUI 3 中删除。WinUI 3 将包含允许 WPF/WinForms/MFC 应用程序托管 WinUI 3 控件的 API。

我一直在努力跟上 WinUI 的进展。 我过去曾尝试用 C# 编写 UWP 应用程序，但发现这是一场艰苦的战斗。 但是我很想在winui 3.0之后再试一次。

我确实对 winui 路线图有疑问。 这里有四个。 抱歉，如果它们已在其他地方涵盖。 尽管进行了大量搜索，但我还没有找到答案……如果有更好的论坛可以询问这些类型的问题，请告诉我。

• 本机控件的 .net 包装器是否也将开源？ 不清楚这是负责 winui .Net方面的 github repro，考虑到我似乎找到的唯一 c# 代码是用于自动化测试。 我正在寻找 Microsoft.UI.Xaml.UIElement 之类的东西，但在任何地方都找不到该代码。

• 当我们发布 winui 3.0 时，UWP appmodel 和 win32 appmodel 会运行相同的 .Net Core 运行时吗？ 我从来没有弄清楚 UWP 应用程序使用什么版本的 .Net 核心。 我想这是 Windows 本身内置的东西，并且 Windows 10 SDK 允许 VS 2019 以 UWP 中可用的正确版本的 .Net 核心为目标。

• 关于 Xaml 岛的问题。 WPF 和 UWP 有可能共享同一个空域吗？ 我不希望像我们在 winforms 和 WPF 之间那样处理空域问题。 鉴于 WPF 和 UWP 都是基于 Direct-X 构建的，如果它们可以相互共享像素，那就太棒了。 例如，如果我在需要覆盖 UWP xaml 岛的功能区（在 WPF 中）上有一个后台菜单，如果这可以无缝发生就太好了。 看起来我不应该为了这样的事情跳过大量的篮球。 ...我记得在 WPF 的早期，他们试图为想要使用“WebBrowser”winforms 控件的客户端应用程序解决空域问题。 他们对 Web 浏览器的一项名为“WebBrowser.CompositionMode”的功能进行了试验，它应该允许 WebBrowser 与 WPF 配合使用。 ...但我认为该策略最终被放弃了。 也许 UWP 和 WPF 之间的互操作性可以如此无缝，以至于它们甚至可以相互共享像素（与 winform 和 WPF 不同）。 这样做的一个潜在优势是允许 WPF 增强 UWP 控件的功能。 例如，WPF 可以以类似于装饰器层的方式覆盖具有附加视觉效果的 xaml 岛。 这可能会在紧要关头变得方便。

• 某天有可能将带有 xaml 岛的 WPF 应用程序（比如 50% WPF 和 50% WINUI）本地编译为 ARM64 吗？ 使用 100% UWP 的应用程序可以定位 ARM，如果 WPF 依赖项不会迫使我们放弃我们的原生 ARM64 定位，那就太好了。 （另一种方法是在 x86 仿真中运行应用程序 - 但速度较慢并且限制了可以使用的可用内存）。

希望这些问题都与winui的路线图相关。 任何意见，将不胜感激。

本机控件的 .net 包装器是否也将开源？ 不清楚这是负责 winui .Net 方面的 github repro，考虑到我似乎找到的唯一 c# 代码是用于自动化测试。 我正在寻找 Microsoft.UI.Xaml.UIElement 之类的东西，但在任何地方都找不到该代码。

UIElement 不在 WinUI 2 中，因此它当前不在存储库中。 它将在尚未发布或开源的 WinUI 3 中，但我们正在努力！

您可以在通过 WinRT 投影公开给 .NET 的其他本机控件的存储库中查看示例，例如此处记录的 WinUI 2.2 控件。 它们大多不需要预先存在的每种语言的包装文件，这就是为什么您没有在 repo 中找到 .cs 文件的原因。

@marb2000可以最好地评论岛屿/桌面问题。

问： _WinUI 3 UWP 和桌面是否使用相同的 .NET 运行时？_
A：是的，这是计划。 UWP 和桌面将使用 .NET Core 3。托管 WinRT 库将使用 .NET Core 3 而不是 .NET Native。

问： _WPF 和 UWP 会共享同一个空域吗？_
答：虽然 WPF 和 WinUI（以及 XAML UWP）看起来很相似，但实际上并非如此。 WPF 使用 DirectX9，WinUI/XAML UWP 使用 Windows.UI.Composition 来满足 XAML 的合成、渲染和动画需求（除了 DirectX11 的现代版本）。 可悲的是，这导致互操作非常复杂。 你关于 WPF 装饰器的提议很有趣。 理论上，采用者可以创建一个弹出窗口，将 WinUI/XAML 内容置于 WPF 内容之上。 或者它可以通知 WPF 可视化树需要重新布局，但一切都基于 HWnds。
@dbeavon这是一个很好的提议，你能为此创建一个功能请求吗？

问： _带有 Xaml Islands 的 WPF 应用程序是否会编译为 ARM64？_
A:如果 .NET Core 3 for Windows 肯定支持 ARM64。 今天，它在 Windows 中支持 ARM32。 但是，在 Linux 中支持 ARM64。 我认为在 Windows 中支持 ARM64 也在 .NET Core 路线图上。 虽然是 AFAIN，但目前还没有日期。 @richlander ，有消息吗？

@marb2000

问：WPF 和 UWP 会共享同一个空域吗？

UWP 可以使用 Windows.UI.Composition 创建一个可以从 DirectX 位图获取渲染的层吗？ 然后 WPF 像 win2d 一样将窗口渲染到这一层。 也许它可以共享相同的空域。 但是很难让 WPF 渲染到图层。

@lindexi我想那可能是天堂：D

UWP 可以使用 Windows.UI.Composition 创建一个可以从 DirectX 位图获取渲染的层吗？

UWP Xaml 有多种方法可以在 Xaml 中渲染 DirectX 位图或交换链，并将它们与 Windows.UI.Composition 合成，以便它们共享相同的空域，包括SurfaceImageSource 、 VirtualSurfaceImageSource和SwapChainPanel - 此处提供更多信息：

https://docs.microsoft.com/windows/uwp/gaming/directx-and-xaml-interop

您还可以将 Windows.UI.Composition 视觉对象插入 UWP Xaml UI 树并向其绘制 DirectX 内容，例如使用ICompositorInterop 、 ICompositionDrawingSurfaceInterop和ICompositionGraphicsDeviceInterop如下所述：

https://docs.microsoft.com/windows/uwp/composition/composition-native-interop

这些方法应该与 WinUI 类似。

UWP 桌面应用程序将能够引用 WPF/WinForm DLL 并打开 WPF/WinFrom 窗口？ 这将使我能够逐渐迁移。

@marb2000——适用于 Windows ARM64 的 .NET Core 在我们的路线图上。 我现在正在为此制定一个计划。

使用WinUI 3.0，是否可以在其上编译win2d？
（因此，将其与 UWP 分离）
如果是这样，那就太棒了！

我们仍在研究 DirectX 集成的细节，但希望可以更新 Win2D 以使用 WinUI 基类而不是 UWP Xaml 基类。

手指交叉 :D

抱歉，如果这是题外话：关于 UWP 的错误报告 - 我是否在https://github.com/microsoft/microsoft-ui-xaml/或其他地方添加问题？

抱歉，如果这是题外话：关于 UWP 的错误报告 - 我是否在https://github.com/microsoft/microsoft-ui-xaml/或其他地方添加问题？

@jtorjo好问题！ 这个 repo 是提交任何相关问题的最佳地点：

• UWP UI 框架 API（例如 Windows.UI.Xaml）
• 流畅的设计
• 用户界面

通常， docs.microsoft.com上大多数文档页面的底部都应该有一个“发送有关此产品的反馈”链接，它会告诉您提供有关特定功能或 API 的反馈的最佳方式。

除了上述之外，对于 UWP 的大多数方面，将在反馈中心的开发人员平台类别下提交错误，该类别具有许多相关的子类别。

WinUI 3 会包含 UWP SemanticZoom 控件吗？ 我认为这是所有控件中最酷的控件。

@jesbis谢谢！ 刚刚发布了一个关于 System.IO 的讨论

即使微软没有放弃对 Office 的 Windows 7 支持，为什么 WinUI 3 会这样做？ 我的意思是，几乎所有严肃的软件都支持 Windows 7（Photoshop、Office、Visual Studio 2019、VSCode，...）如果 WinUI 不支持 Windows 7...

即使微软没有放弃对 Office 的 Windows 7 支持，为什么 WinUI 3 会这样做？ 我的意思是，几乎所有严肃的软件都支持 Windows 7（Photoshop、Office、Visual Studio 2019、VSCode，...）如果 WinUI 不支持 Windows 7...

Office 可能很快就会停止支持，因为 Microsoft 对 Windows 7 的支持很快就会结束。 但它建立在已经支持 Windows 7 的代码库上。

WinUI 是基于 Windows 10 构建的，因此需要向后移植到 Windows 7。随着操作系统进入生命周期结束，这样做的努力毫无意义，因此人们将不得不升级到 Windows 10。

问：WinUI 3 UWP 和 Desktop 会使用相同的 .NET 运行时吗？
A：是的，这是计划。 UWP 和桌面将使用 .NET Core 3。托管 WinRT 库将使用 .NET Core 3 而不是 .NET Native。
问：WPF 和 UWP 会共享同一个空域吗？
答：虽然 WPF 和 WinUI（以及 XAML UWP）看起来很相似，但实际上并非如此。 WPF 使用 DirectX9，WinUI/XAML UWP 使用 Windows.UI.Composition 来满足 XAML 的合成、渲染和动画需求（除了 DirectX11 的现代版本）。 可悲的是，这导致互操作非常复杂。 你关于 WPF 装饰器的提议很有趣。 理论上，采用者可以创建一个弹出窗口，将 WinUI/XAML 内容置于 WPF 内容之上。 或者它可以通知 WPF 可视化树需要重新布局，但一切都基于 HWnds。
@dbeavon这是一个很好的提议，你能为此创建一个功能请求吗？
问：带有 Xaml Islands 的 WPF 应用程序是否会编译为 ARM64？
A: 如果 .NET Core 3 for Windows 肯定支持 ARM64。 今天，它在 Windows 中支持 ARM32。 但是，在 Linux 中支持 ARM64。 我认为在 Windows 中支持 ARM64 也在 .NET Core 路线图上。 虽然是 AFAIN，但目前还没有日期。 @richlander ，有消息吗？

那么我们是否正在摆脱 UWP 沙箱？ 这又意味着当前形式的 UWP 也将消失，而我们所知道的 App Store 受保护的沙箱也会随之消失？

那么我们是否正在摆脱 UWP 沙箱？ 这又意味着当前形式的 UWP 也将消失，而我们所知道的 App Store 受保护的沙箱也会随之消失？

摆脱 UWP 沙箱会非常棒！

这绝对不意味着 UWP 会消失。 通用 Windows 平台是为所有 Windows 设备（PC、Xbox、HoloLens 等）进行本地构建的唯一方法，也是 Windows 集中其本地平台投资的地方。 RE：特别是沙盒：应用程序容器隔离继续为 UWP 和桌面应用程序的应用程序和用户提供许多重要的好处。

主要变化有：

• 我们正在扩大 UX 平台（即 WinUI）的范围，以便它也可以与桌面 (win32) 应用程序模型一起使用
• 我们正在将 WinUI 与 Windows 解耦，以便我们可以更频繁地更新它，使新功能向后兼容，并更轻松地将其开源

这意味着对于新应用程序，您将能够根据对您的应用程序有意义的内容在 UWP 和桌面应用程序模型之间进行选择，并且如果您有现有的桌面应用程序（例如 WPF、WinForms、MFC），那么您可以使用现代版本逐步更新它们使用 Xaml Islands 的 WinUI 功能。

那么我们是否正在摆脱 UWP 沙箱？ 这又意味着当前形式的 UWP 也将消失，而我们所知道的 App Store 受保护的沙箱也会随之消失？

UWP 将是构建 WinUI 3.0 应用程序的选项之一。 使用 UWP 将允许您的应用程序在 Xbox、Hololens 等上运行。

但是您也可以使用 WinUI 3.0 构建 Win32 应用程序并访问 UWP API - 但是您的应用程序可以运行的位置将受到更多限制。

@mdtauk @jesbis我完全支持 UWP，但此时：

1. 编译时间非常慢！ （几乎比 WPF 慢 6 倍 - 我使用的是目标版本 build 1809 - build 17783）
2. 我知道 StorageFolder 文件枚举 API 不是 UWP 的一部分，但这速度非常慢。 UWP 沙箱（至少在 Windows 桌面上）的伤害大于帮助。
3. 当然，异步编程很有趣，但在 UWP 中，当异常发生时，它会以某种方式被 UWP 代码吃掉，然后在调试器中中断，所有堆栈上下文都丢失了。 有时，我确实在抛出的异常本身中有堆栈上下文，但并非总是如此。
4. 分析 UWP 代码几乎是不可能的。 尝试执行时，事件 dotTrace 会立即中断。

（我花了一个多月才将代码从 WPF 移植到 UWP，因为我非常需要 win2d，所以我无法避免使用 UWP。）

@mdtauk @jesbis我完全支持 UWP，但此时：

1. 编译时间非常慢！ （几乎比 WPF 慢 6 倍 - 我使用的是目标版本 build 1809 - build 17783）
2. 我知道 StorageFolder 文件枚举 API 不是 UWP 的一部分，但这速度非常慢。 UWP 沙箱（至少在 Windows 桌面上）的伤害大于帮助。
3. 当然，异步编程很有趣，但在 UWP 中，当异常发生时，它会以某种方式被 UWP 代码吃掉，然后在调试器中中断，所有堆栈上下文都丢失了。 有时，我确实在抛出的异常本身中有堆栈上下文，但并非总是如此。
4. 分析 UWP 代码几乎是不可能的。 尝试执行时，事件 dotTrace 会立即中断。

（我花了一个多月才将代码从 WPF 移植到 UWP，因为我非常需要 win2d，所以我无法避免使用 UWP。）

将其发布在此线程 #1517 中会很有用，希望您可以将其包含在 SDK 团队成员的姓名中

@jtorjo

编译时间非常慢！ （差不多，比 WPF 慢 6 倍

你在使用 C++/WinRT 吗？ 如果是这样，您是否使用预编译的头文件？

@mdtauk刚刚发布在那里

@MarkIngramUK这是 c# 代码

结束 - 请将路线图和 alpha 反馈直接发送至：#1531

现在不知道这是否可行——希望当 WinUI 位从操作系统中删除时，它们以某种方式放入开源项目，这将使其他平台能够提供某种兼容性组件。 想想带有自定义渲染器的 Xamarin、Uno 或 .Net Core。

这真的在路线图上还是只是一个假设？

@mdtauk , @zezba9000这在理论上都是可能的，我们团队中有很多平台抽象专业知识。 与任何事情一样，它归结为成本、进度和预期收益😊

只是可能以一种使第三方能够使其在 Android 或 iOS 上运行的方式对其进行抽象，这将是巨大的。 我相信社区可以做到这一点。 我肯定会为此做出贡献。

@andreinitescu对不起，我的咆哮和抱怨，但只是我的想法：虽然我将使用 WinUI 3 来替换 Windows / Win32 的 WPF... 因为 Windows 上的 WinUI 仅使用 Windows 渲染 API 而不是不可知论者一，WinUI 似乎依赖于 3rd 方在其他平台上重新实现/碎片化 (ugg) WinUI（如 UNO 项目，这很酷，但它像 Mono 到 .NET 是一种不必要且浪费时间的碎片化，如果事情只是一开始就设计正确）。 而不是使用像 Skia 这样的便携式，或者创建一个 MS。 也不明白需要支持 1% 不会在 WinUI 中使用 C# 的人，使 C# 在某种意义上成为第二类目标，更重要的是使开发时间花费更长的时间。 就像 Android 为许多核心应用程序使用 Java + post-AOT 一样，Windows 也应该使用 C# + pre-AOT。 因为这样可以节省时间。 毕竟，70% 的使用 C++ 的错误都在使用释放的 ptr。

对于长期用例，公司中的团队之间缺乏沟通，当他们发布适用于移动平台（我计划使用）的 Android 操作系统风格并且更多人希望将其作为目标时，这将成为一个越来越大的问题使用 MS 工具......感觉它只是在某种程度上再次成为另一个类似 WinPhone7 的情况。 作为一个术语，Windows 不应再与 WinNT 内核如此紧密地联系在一起。 一个生态系统不仅仅是一个单一的平台或一个构建它的公司框架。

糟糕的是，MS 不能/不会做苹果在将近 20 年前从 OS9 迁移到 OSX 所做的事情。 在这种情况下，您可以通过迁移到 UNIX/LINUX 内核来摆脱创可贴，但在未来 5 到 10 年内，在操作系统中为遗留软件内置了一个模拟器/模拟器，而人们则将软件和开发工具迁移到本地运行。 （想想你会怎么想，但我可以做梦）