这些是我对您在问题内容中提出的问题的初步想法。

我从设计和用户的角度出发，只有一点点开发经验，当时对 Silverlight/Windows Phone 7 开发非常感兴趣，现在感觉有点受不了。

您最感兴趣的模板是什么？

我认为在索取模板想法列表之前，需要对每个框架中最大和最常用的应用程序进行某种审核，因此 WPF、UWP、WinForms、MFC 等。

检查这些应用程序的“轮廓”并找出常见的用户体验场景。

在我的头顶上，有：

• 主菜单（所有框架）
• MDI（单个窗口中的多个文档）（主要是 MFC）
• 选项卡和数据网格（WPF、WinForms、MFC）
• 功能区（Win32 应用程序 Office、3ds max、绘画、写字板、文件资源管理器等）
• 系统托盘实用程序（MFC、WinForms）
• 浏览器
• 向导（WPF、MFC）
• 复杂的 MDI 应用程序（Adobe 软件、Visual Studio）
• 媒体播放器
• 数据可视化 LoB（WPF 和 Web）
• 社交应用（React Native、PWA - Skype、Facebook、Twitter）

所有或部分这些都可以从 WinRT/UWP 系统与通知/操作中心的集成中受益。

所有这些新项目模板都应避开内置的 Windows.Xaml 命名空间、WPF 控件主题和 WinForms 视觉样式，转而采用与 FabricWeb/Fluent 控件设计相匹配的新模板和视觉样式。

对于使用现有 WPF 和 WinForms 应用程序的开发人员来说，还应该有一种简单的方法来添加 WinUI 3.0 依赖项，从而通过简单的 using 语句或清单条目为他们提供新的控件设计

XAML 岛

随着 Xaml 岛变得更容易实现 - 替换旧的 webview 控件、颜色选择器、基于 XAML 的对话框可能就像添加新...并选择一个对话框或现有 C# 和 C++ 代码可以调用的标准控件一样简单，以及他们有自己的代码隐藏。

现代应用程序和页面模板，如 Xbox Next 应用程序、NavigationView、Master/Details、Hubs、Modern Ribbon、NavigationViewTop 和 Pivot——都可以用于所有 Windows 演示平台——带有 XAML 岛和示例内容。

目前在 UWP XAML 中无法实现的任何这些场景都应该带有控件和模板，以使这些更容易。

如果 Visual Studio 或其他工具自动为您更新命名空间会有所帮助吗？

当有人使用当前的 Windows 10 SDK 在最新版本的 Visual Studio 上打开他们的项目时，应该会问这个问题。 按下按钮，它将替换名称空间并使用，或者如果它不是它熟悉的控件，则标记它们。

在新项目中，它应该是默认值，并且 nuget 包与 Windows SDK 的未来版本一起安装。

在 WinUI 3 中使用 UWP 组件的首选解决方案是什么？

与自动更新答案一样，默认情况下新页面和项目应包含它，并询问是否要自动移动到 WinUI | 的消息。 添加 ToDo 注释以更新命名空间| 不要移动到 WinUI 。

您最希望将 WinUI 3.0 用于哪些应用程序？

作为用户，我希望所有在 Windows 上运行的应用程序共享一个通用的 UI 和 UX，无论使用什么框架。

我希望安装应用程序时不会弄乱注册表并留下垃圾。 （所以百年）

我希望所有应用程序都可以从商店内安装，或者从 Centennial 类型的安装程序安装。 为每个应用程序虚拟化 System 和 Windows 文件夹。

使用 Fluent UI 现代化 C++ MFC 应用程序？

Acrylic 应该可用于 WPF、WinForms 和 MFC 应用程序，并通过 WinUI 3.0 依赖项或清单包含在默认的新模板中。 CommonControls 和窗口样式应该使用 Acrylic 和扩展的标题栏（可以覆盖以返回到当前默认值）

Microsoft 的 Win32 非 UWP 应用程序都需要使用 WinUI 3.0 重新编译，因此它们都使用 Acrylic 窗口框架、主菜单、ThemeShadows、上下文菜单、文本字段、进度条等。

然后现有的应用程序需要一个简单的解决方案来插入 WinUI 3.0+，然后更新所有控件的外观 - 或者一次有选择地应用一个对话框的能力，直到更新整个 UI。

回复：命名空间，我希望它们仅根据目标进行更改，即使它需要条件命名空间。

以下是我的回答：

创建新应用

您最感兴趣的模板是什么？

• 我很想首先看到 c++/winRT win32+xaml 和 .net core+xaml，第二个是 UWP 模板，打包的 win32 应用程序不应该作为模板出现，因为当前的应用程序包模板应该像它们已经用当前win32/.Net 应用程序。
• 另外，我很想看到像“新 XAML 窗口”这样的项目模板，带有样板代码，以在现有的 win32 或 .net 核心应用程序应用程序中显示它（例如：制作现有的系统托盘应用程序 à la Docker Desktop，能够显示一个新的顶级 Xaml 窗口）

将 WinUI 3.0 添加到现有的 Win32 应用程序

• 非向后兼容性是我从未在实际项目中使用 xaml 岛的确切原因（尽管将其用于个人项目的乐趣）。 将 UI 框架与 Windows API 解耦是 WinUI 3.0 路线图宣布的最伟大的事情之一（以及非打包/非 uwp 目标应用程序可以利用它的能力）

将现有的 UWP Xaml 应用更新到 WinUI 3.0

这听起来可能很苛刻，但我觉得 UWP xaml 应用程序是一个利基市场（由于 Windows Phone 的下降，没有更多的吸引力将 UWP 作为目标平台），即使工具/互操作会很好，我不不认为它应该是 WinUI 3.0 的主要焦点。
因此，命名空间更新工具（实际上可能是使用全局查找和替换完成）和混合 UWP xaml 和 WinUI xaml 对我来说并不重要。

另外，只想提一下，这是一个非常受欢迎的举措，在 Github 上开源整个 UI 框架真是太棒了！ 非常感谢你这样做！

首先，这是一个伟大的举措！ 不幸的是，我不能忽视这样一个事实，我对微软处理他们平台上最后几个开发人员的方式感到有点受伤。 目前我只将 UWP 用于面向消费者的应用程序，因为：

1. WPF 比 WinUI 成熟得多（验证、现有控件等），因此 WPF 更适合企业
2. UWP 非常适合多种设备类别（移动、平板电脑、台式机等），这就是消费者所在的位置

很高兴看到 WinUI 可以解决第 1 点，这让我对 WinUI 的进展充满热情。 不幸的是，2 不再适用（不再有很酷的设备，只有台式机）。 令人惊奇的是，当这些东西发布时（从现在起最早 1 年？），开发人员在那个阶段需要什么。

我认为消费者的东西不再是等式的一部分，这艘船已经以裁员“战略”航行。 因此，它唯一可能对企业应用程序有益。

总的来说，我对从 WPF 到 WinUI 的良好迁移策略更感兴趣，以尝试将我们庞大的 WPF 代码库迁移到 Windows 10。必须更新面向消费者的应用程序（当前为 UWP）的缺点是它们高度依赖关于外部组件开发人员（例如 win 工具包等）。 我认为没有可行的选择来更新这些了，因为大多数开发人员（我知道）对消费者/Windows 客户端开发失去了兴趣。

问题的答案

创建新应用

您最感兴趣的模板是什么？

我很想在这里看到 .net core / xaml / C#，因为我认为这是最常用的语言组合。 但也许这里有一个迁移模板会更好（尽量让每个人都尽快加入，时间越长，就越痛苦）。

将 WinUI 3.0 添加到现有的 Win32 应用程序

我认为这非常好，我们会经常使用它（但实际上，这至少还需要一年时间，因为企业客户仍在使用 Windows 7，即使 MS 支持结束，公司也将使用 Windows 7）。 然后我们就可以慢慢将WPF迁移到WinUI 3了。

您是否知道 Xaml Islands 用于使桌面应用程序现代化？

是的，但是太多的客户现在（或曾经）使用 Windows 7，因此它不是企业开发人员的选择。 对于消费者而言，您无论如何都可以使用 UWP。

Windows 10 上扩展的向后兼容性是否会使 Xaml Islands 对您更有用？

这是一个良好的开端，因为当这些东西发布时，它可以在企业中所有受支持的 Windows 10 版本上运行。

将现有的 UWP Xaml 应用更新到 WinUI 3.0

MS 的消费者应用程序已经结束，这一切都是因为 MS 所做的选择，没有更多的空间。 我会跳过整个选项并忘记它。 很难过，因为我在 UWP 应用程序中投入了数千小时，但我认为我们需要尽快让这种死亡变得不那么痛苦。

整个承诺的故事始终是最新的，支持所有设备。 我想我们都知道那个承诺是怎么回事。

如果 Visual Studio 或其他工具自动为您更新命名空间会有所帮助吗？

如果它只是命名空间，搜索/替换也应该可以解决问题。

现有 UWP Xaml 组件与 WinUI 3.0 应用程序之间的完全兼容性对您来说有多重要？

不再重要，我愿意承担数千小时开发的损失，反正没有用户。

您是否创建或使用了无法与应用代码一起轻松重新编译和更新的 UWP Xaml 控件库或 WinRT 组件？

不。

在 WinUI 3 中使用 UWP 组件的首选解决方案是什么？

UWP 岛（某种托管组件）

一般的

您如何看待上述和路线图中概述的整体 3.0 计划？ 它能让您将 WinUI 用于新的和现有的 Windows 应用程序吗？

它可能需要一些成熟，但我认为自己在 1 到 2 年内将这些东西用于企业开发。 根据迁移的难易程度，我们将选择 WinUI 或 web（取决于 Windows 本身如何“进化”）。

您最希望将 WinUI 3.0 用于哪些应用程序？ 创建一个新的 Win32 应用程序并使用 MSIX 将其打包？ 向 WPF 应用程序添加新视图？ 使用 Fluent UI 现代化 C++ MFC 应用程序？

可能只是向 WPF 应用程序添加新视图并慢慢开始迁移。

我非常喜欢这个路线图。 UWP 需要摆脱束缚，这是实现这一目标的好方法。

将现有的 UWP Xaml 应用更新到 WinUI 3.0

这对我的雇主来说非常重要。 我们在商店中有一个复杂的 UWP 桌面应用程序。 我们现在需要桌面桥来访问 .NET Native 不支持的 win32 API。

我想

• 直接访问所有 win32 API；
• 使用普通的老式 win32 执行模型。 我对一些类似桌面桥的沙箱（例如注册表的虚拟化）很好；
• 将我们的应用程序放入商店（msix），就像现在一样；
• 仍然使用 WNS（推送通知）；
• 从 UWP 到一些新的 Xaml 桌面应用程序类型的轻松更新体验。 我不介意做一些体力劳动。 也许我更喜欢这里好的文档而不是工具。

现有 UWP Xaml 组件与 WinUI 3.0 应用程序之间的完全兼容性对您来说有多重要？

现有的样式应该仍然有效。 我可以忍受一些细微的视觉变化。 但不是随着行为的改变。

您是否创建或使用了无法与应用代码一起轻松重新编译和更新的 UWP Xaml 控件库或 WinRT 组件？

不。

在 WinUI 3 中使用 UWP 组件的首选解决方案是什么？

如果它们不能被重新编译（第三方）：类似 Xaml Islands 的方法。 否则应该可以轻松地将它们移植到 WinUI 3。

一般的

您最希望将 WinUI 3.0 用于哪些应用程序？ 创建一个新的 Win32 应用程序并使用 MSIX 将其打包？ 向 WPF 应用程序添加新视图？ 使用 Fluent UI 现代化 C++ MFC 应用程序？

• 桌面 win32 应用程序，与 MSIX 一起打包。
• Uno 跨平台应用程序 ;)

请不要为 _INotifyDataErrorInfo_ 之类的东西引入新的命名空间 - 它应该用于通常是跨平台的视图模型并且不应该依赖于 WinUI。 应该定义其他类似的东西所在的位置（即 _INotifyPropertyChanged_ 或 _INotifyCollectionChanged）_

我只想知道最终目标是否是创建一个跨平台的 UI 堆栈。 理解它可能无法完全理解我们如何到达那里。 但是，如果这是意图......在这项工作开始时最好在没有Win参考的情况下进行品牌化。 如果你这样做了，从长远来看，它会减少头痛。

标记为XamlUI或类似标签会更好吗？ Microsoft.UI.* 命名空间很好，只需标记存储库，例如

感谢您伸出援手。 期待这个空间会发生什么 :smile:

对我来说，所有的技术细节都不那么重要。
UWP、WPF 或任何仅适用于 Windows 的框架，尽管很棒，但只要它不能在每个平台（至少是 Windows、Droid、iOS 和 Web）上运行，并且与任何屏幕尺寸。

TBH 在上次 Build 中让我失望，因为我发现 MS 没有让 UWP 或 XAML 跨平台的计划。 除了演讲外， Uno没有得到任何官方认可。 更令人沮丧，我会说是伤害，是发现 MS 非常喜欢 React Native 和 HTML/JS 驱动的框架（WinJS），而忽略了负责任的 .NET 堆栈开发人员。
我希望看到 MS 正式创建一个像 Uno 这样的跨平台 UI 堆栈，并提供正确的工具、模板和集成支持。

顺便说一句，自从 XF 被 MS 收购以来，我一直在与 XF 合作，并希望它有一个替代方案，原因如下： 没有网络支持，b。 非常偏向于移动设备，不喜欢台式机 c. 与 WPF/UWP 控制库 d 相比，它的库层次结构让人感觉很草率。 未使用 MS XAML。
这是我在 Microsoft Developer Community 上发布的功能请求： .NET UI Standard 。

谢谢大家！

我们需要一个也可以在 Web（程序集）上运行的 XAML UI。 至少是 UWP 的一个子集。
为什么不拥抱 UNO 平台并使用 SkiaSharp 进行 Web 渲染？
可能是Silverlight 6 ， WinUI的 Web

快速回复问题

您最感兴趣的模板是什么？

.NET 核心 SDK 样式的项目，或一些简化的 MSVC 项目格式。
旧项目文件太复杂，无法手动编辑，新旧项目系统之间存在大量交互问题。 对于全新的项目，我们应该彻底放弃旧的项目系统。

您是否知道 Xaml Islands 用于使桌面应用程序现代化？

不。我正在使用完整的数据模型更改来重写我的应用程序，因此没有渐进式迁移。

Windows 10 上扩展的向后兼容性是否会使 Xaml Islands 对您更有用？

Windows 7 上还有很多用户，Xaml Islands 也帮不上忙。

现有 UWP Xaml 组件与 WinUI 3.0 应用程序之间的完全兼容性对您来说有多重要？

不。我的所有组件都是自己编写的，或者来自 MUX 和 WCTK，因此我可以执行快速的手动迁移。

如果 Visual Studio 或其他工具自动为您更新命名空间会有所帮助吗？

没有那么多，因为我的项目不大（现在大约 20 页和大约 10 个自定义控件）。

在 WinUI 3 中使用 UWP 组件的首选解决方案是什么？

我希望有一个随操作系统一起提供的版本，以允许创建非常小的工具并以 KBs 形式发送。 该工具根本无法在较低的操作系统上运行，因为假定的用户可以立即与我联系（例如，通过一些聊天软件）。

您最希望将 WinUI 3.0 用于哪些应用程序？ 创建一个新的 Win32 应用程序并使用 MSIX 将其打包？ 向 WPF 应用程序添加新视图？ 使用 Fluent UI 现代化 C++ MFC 应用程序？

创建一个新的仅限 Windows 10 的应用程序并在没有商店的情况下发货。
可信签名对于个人开发者来说是昂贵的，并且上传到商店不适用于特定于域的应用程序，而不是长期应用程序。

我个人对 UI 平台的看法

Xaml 工具链

xaml 语言在某种程度上并不严重，我面临着许多问题，例如“我应该如何表示这一点”。 WPF xaml 和 UWP xaml 并不完全兼容，所以我需要记住它们的区别。 Xaml 与 .NET 功能不完全兼容，所以我有时需要在我的模型中编写一些丑陋的技巧，以及一个帮助类。

使用x:Bind ，事情变得更糟。 简单的场景很容易使用，但是做一些不仅仅是属性访问的事情就很复杂了。 例如，它不支持方法重载，因此我必须编译以检查为该绑定表达式选择了哪个重载。 我什至不能做一个简单的切换，或者“当某些属性为假时可见”转换，并且需要一个辅助方法。 文档对这些详细的场景没有说，所以我认为应该有一个xaml-language-design讨论的立场，让xaml像C#一样成为一种认真设计的语言。

xaml 编辑器也很难使用。 设计师尝试执行一些代码来显示实际效果是合理的，但文本编辑器应该只知道元数据。 在源代码视图中打开 xaml 文件很慢，因为它正在激活设计器，并为完全可以运行的 xaml 抛出一些交互异常，例如NullReferenceException和Cannot convert __ComObject to some type 。 它通过构建的库触及ProjectReference ，即使对依赖库中的非public-api区域进行简单的编辑也会导致复杂的错误，通常是数据模型的实现。 所以我认为应该有一个元数据和源代码感知，完全 Roslyn 集成的 xaml 编译器。

更好的窗口模型

信息完整、状态完整的应用程序通常使用多窗口模型而不是导航模型。 目前在 UWP 中，使用ApplicationView创建新窗口很痛苦，因为存在线程问题。 新的AppWindow共享 UI 线程，我不确定它的 UI 性能。

将来某个时候在WinUI 中重写Visual Studio 可以证明它是一个成熟的UI 系统。

数据绑定接口

我们已经厌倦了创建实现INotifyPropertyChanged 。 我已经编写了一个自定义 MSBuild 任务来将 xml 转换为扩展的属性访问器，但是当我想在属性更改时在 setter 中执行一些自定义操作时，它没有帮助。

还有线程问题。 我的数据完全来自后台网络服务器，因此await上下文捕获无法帮助我。 在 WPF 和Binding ，它原样是因为Binding解决了线程本身。 当更改为x:Bind ，我必须在事件引发器中解决它，因为x:Bind只是在调用线程上操作。 当我有多个应用程序视图接触相同的数据时，情况变得更糟，这意味着没有可用的全局 UI 调度程序，唯一的解决方案是在事件注册时捕获SynchronizationContext.Current 。 对于集合， ItemsSource也不是线程安全的，需要相同的解决方法。

肯定应该有一个工具链来解决可变可绑定模型的建模、线程和扩展问题。 可绑定集合的通用内置解决方案应该为“更改任何子项的指定属性”提供一种机制。

IObservableVector<T>是一个伪泛型类型，只能使用object ， INotifyCollectionChanged是非泛型。 仅仅为像ObservableCollection<T>这样的内置集合实现它是不够的，特别是对于复杂的、面向ISupportIncrementalLoading / IItemsRangeInfo的场景。 平台应提供具有最佳实践的默认抽象实现，允许用户仅实现抽象数据填充方法。

@shaggygi @weitzhandler @TonyHenrique

如果 UWP/XamlUI3.0 有一个跨平台的未来，从 Windows 渲染器中抽象出 XAML 语法，Windows 运行时的其余部分将是一种处理它的方法。

如果项目可以有几乎插件的心态，那么可能会有一个 Android 或 iOS/AppKit Renderer，以及一个 Android/iOS AppKit Shim 将 ART API 传递到 C# 和 VB，以及现有的 C++、C 语言支持。
Xamarin 可以在这里提供帮助。

Microsoft 不需要成为那些 alt 平台渲染器的工作人员。

但是现在专注于 Windows... WinUI 3.0 可以包含 Fabric Web / React Native / WPF / WinForms / MFC。 PWA 也将成为应用程序开发的一等公民，因此对于不是直接为 Windows/.NET/UWP 制作的应用程序，也有跨平台的故事。

现在需要的是为 C#/.NET/UWP 开发人员提供一个故事，将他们的应用程序和投资带到更广泛的平台领域。

我的 2 美分：我是 Xamarin.Forms 开发人员，并且（与许多其他人一样）很想看到所有 XAML 方言合并为一种适用于任何地方（包括移动领域）的方言。 不知道结果会如何，但这至少是我对此事的希望。

可能是 WinUI 3.0 以后的版本 - 但是有太多的 WPF 应用程序，无法期望它们全部重新编写和翻译所有 XAML。 新的 WPF 项目可以使用更现代的 WinRT XAML 方言。 您可以将 DocType 的等效项引入 XAML，以便不同的方言可以共存于同一个项目中。

当然说起来容易做起来难。

@mdtauk我认为一旦 Xaml 平台真正开源，我们就会更清楚地了解它依赖于堆栈底部的什么（我们已经知道主要的特定于平台的依赖项是 DirectX11、Direct2D 和 Windows Media Foundation，但谁知道在那里使用了 Windows SDK 的哪一部分），以及它是如何分层的（以便我们可以对任何移植的可行性有一个实际的感觉）。
此外，我们还没有看到将在何种许可下分发源代码。 我不确定是否已经决定。

Android 使用 Vulkan，我认为支持 OpenGL
iOS 和 macOS 使用 Metal

至于媒体编解码器，可以使用基于原生 C 的 API 来替代。

@simonferquel在重构和签入代码时会变得更加清晰。并且可能需要一些 iOS 和 Android 专家来领导这些工作。

我认为当 winui 是控件集合时，更改命名空间是一种合理的方法。 但是，现在它基本上取代了平台，我认为这已经没有道理了。 这对于 WPF/Winforms 已经以相同的方式工作，其中代码可以从 .net Framework 移动到 .net core，而无需更改代码中的命名空间。 启用后，平台应该能够自动加载必要 dll 的 winui 版本。 通过这种方式，可以保留源代码和二进制兼容性（我已经成功地在 .net 核心应用程序中使用了 .net 框架库）。

只想说谢谢大家到目前为止的评论！ WinUI 团队正在仔细查看所有响应和要点。
一旦我们组织了我们的想法，我们也可能会拆分一些重点问题来讨论出现的特定问题（例如与现有 UWP 框架和组件的兼容性）。

我只想对 MS 说声谢谢，感谢您更多地倾听并为 .net 开发人员提供了很棒的工具，但在构建会议之后，我不禁对 UWP Xaml 的未来感到失望。
阅读此博客和网络上的许多文章，您会感觉到 UWP 正在变成专门的“企业”，甚至这也是有争议的，因为许多企业变得越来越不依赖操作系统，允许员工使用例如 MacBook Pro。

让我明确一点，我在本机 UWP 和 Xamarin Forms（Android、iOS）上投入了大量资金，我喜欢这个平台，但是在 MS 宣布对 React 的本机支持之后，我即将跳槽。

我知道我必须让我的 UWP 应用程序在桌面上与平台无关，因此我希望我可以创建一个“混合应用程序”，以我当前的 uwp 应用程序为外壳，并通过在混合中使用 React 来合并越来越多的 Web 前端技术. 像我理解的提议的“Sets”功能现在由于 Edge 中更高的优先级而被延迟，对于我当前的解决方案来说是理想的，因为它通过在“窗口/边缘标签”。 这种“混合”方法将使我能够慢慢地将网络技术融入到我当前的平台中，同时也可以在“浏览器”中为“原生应用”提供一个选项卡。 （从消费者的角度来看）如果“原生 uwp 应用程序”在桌面上长期失败，这也为我提供了一个逃生口。

上述想法的原因是 UWP 没有为我提供逃生舱口，因为如果很快没有跨平台功能，它很容易成为下一个 Silverlight 受害者。 MS 正在对冲他们的赌注，确保他们不会在 PWA 趋势中失败，或者他们的手正在转向 Windows 上的 React 原生支持。 问题是我打赌希望此时 UWP/c#/.net 会有一条“路径”进入浏览器或跨平台，并且我可以将大部分投资重用于这些平台。

我记得当那里的每个开发人员都大喊购买 Xamarin 时，MS 花了很长时间才做到这一点。 我认为大多数熟悉 Web Assembly 的开发人员都知道，最近他们设法在 Web Assembly 中运行了“完整版”的 Windows Server，他们会说购买 Uno 平台并通过大量投资使其变得庞大。 如果完整的操作系统可以在 Web 程序集上运行，MS 应该为每个 .net 开发人员提供跨平台功能的迁移路径，以保护他们现有的投资。

你可能会说 Blazor 就在那里，但坦率地说，在我在新平台上投入更多时间之前，我宁愿学习 React，或者你可能会说我们 MS 对所有这些的资源有限。 当然，当你为 Github 支付 75 亿美元时，一切都变得相对。

我认为，MS 必须了解现有 UWP/Win32 投资的跨平台功能迁移路径失败所造成的声誉损害。 跨平台功能应该是 .NET 5 的同义词，但事实并非如此。 我不确定在这种情况下跨平台的婴儿步骤是否适合 MS，相信我，我一直是 xaml/.net/c# 的忠实粉丝

您最感兴趣的模板是什么？

您是指项目模板还是项目模板？

如果 Visual Studio 或其他工具自动为您更新命名空间会有所帮助吗？

这只是搜索和替换（价值较低）还是将更新依赖项合并到新版本（更有价值但不确定如何判断）

回复：新功能的向后兼容性

向后兼容创意者更新 (15063) 是一个固定的参考点，还是未来的计划是支持当前版本和之前的 X 个版本？

这对于任何创建扩展或拥有想要公开共享的控件或功能的人来说意味着什么？ 他们是否也需要支持这种级别的向后兼容性？ 甚至到 Windows 8.1？

回复：迁移命名空间

是否可以分阶段迁移现有的 UWP（我正在考虑页面），还是需要一次更新整个应用程序？ 如果一次性完成整个应用程序，则会降低采用速度。

迁移 WPF 应用程序怎么样？ - 使用 XAML 岛的迁移策略是否可以使用 WinUI 2.x 或 3.x？ 两者可以在同一个应用程序中使用吗？

是的，将这个问题分成多个、更集中的问题将有助于更清晰地捕捉想法并避免切线。

请用适当的名称替换UWP 的所有实例，因为不清楚您指的是什么。

@mrlacey ：

您是指项目模板还是项目模板？

项目或库模板也很有趣！ 到目前为止，回复中有一些关于提供额外样板和启动代码的要点，这些是我们可以考虑随着时间的推移添加的其他内容，例如Windows Template Studio 。

这只是搜索和替换（价值较低）还是将更新依赖项合并到新版本（更有价值但不确定如何判断）

好问题 - 什么样的依赖更新会使其更有价值？ 例如，寻找新的兼容 NuGet 包版本？

向后兼容创意者更新 (15063) 是一个固定的参考点，还是未来的计划是支持当前版本和之前的 X 个版本？

我们设想支持版本范围会根据使用情况随时间变化。 我们可能会继续查看使用数据并支持市场上最活跃的 Windows 10 版本，而不是仅限于特定数量的版本。

这对于任何创建扩展或拥有想要公开共享的控件或功能的人来说意味着什么？ 他们是否也需要支持这种级别的向后兼容性？ 甚至到 Windows 8.1？

我们目前不打算对自定义控件强加任何额外要求或“认证”。 版本控制取决于你。 2019 年 5 月更新、WinUI 3.0 和未来版本的 WinUI 的整体版本故事绝对是我们希望尽快深入探讨的主题。

是否可以分阶段迁移现有的 UWP（我正在考虑页面），还是需要一次更新整个应用程序？ 如果一次性完成整个应用程序，则会降低采用速度。

很好的问题 - 感谢您注意到这一点。 这也是我们希望尽快深入探讨的话题。

请用适当的名称替换 UWP 的所有实例，因为不清楚您指的是什么。

@riverar ：是否有

我们使用术语“ UWP Xaml ”来指代作为 Windows 10 和 UWP SDK 的一部分提供的 Xaml 平台，以便将其与其他基于 Xaml 的平台（例如 WPF）区分开来。

我们还提到“ UWP 应用模型”（打包和安装、数据和状态管理、运行时生命周期等），与 Win32 应用模型不同。

即使在 Windows 桌面上，用户也会花费大量时间浏览 Web。
我认为我们需要一种方法来开发体面的 Web 应用程序，使用（的子集） UWP vNext XAML + .NET (C#/F#/VB.NET)

我用WPF+ClickOnce开发了很多年，然后开始看UWP。 我喜欢 UWP，但它（或下一个版本）需要能够运行独立的 EXE、更好的 Window API（如果我们愿意，甚至可以制作自定义的 Winamp Window 样式应用程序）、更多的打印 API、与 C dll 的轻松互操作，OCX，至少有一部分组件应该在 Web 上运行。

当我看到 UNO 时，我想：微软可以收购这家公司，并与 UWP 和 Xamarin 的团队一起加入这些开发人员。 如果下一个版本的 UWP 成为 Azure 的东西，在 Web、Windows、移动和物联网上运行，我会很高兴。 IMO 甚至可以在 UWP vNext 中编写 Azure 门户。

微软可以做到。 你用 Silverlight 做到了，你用了 WPF，你用了 UWP，你用了 Xamarin。 现在是最终的 GUI XAML 框架的时候了。 而且，在我看来，必须支持 Web，至少是功能的一个子集。

_INotifyDataErrorInfo_

请不要为 _INotifyDataErrorInfo_ 之类的东西引入新的命名空间 - 它应该用于通常是跨平台的视图模型并且不应该依赖于 WinUI。 应该定义其他类似的东西所在的位置（即 _INotifyPropertyChanged_ 或 _INotifyCollectionChanged）_

关于这个话题。 Windows.UI.Xaml.Interop 已经有 INotifyCollectionChanged 接口，Windows.UI.Xaml.Data 有 INotifyPropertyChanged。 这两个将移至 Microsoft 命名空间。 也许 System.Runtime.WindowsRuntime 程序集可以做一些从 WinUI 到 .Net 的映射

如果尚未添加，我唯一想添加的是，我 100% 支持 MSIX/Appx 包模型，并且 Win10 在修复 Windows 生命周期内安装和删除的问题方面做得非常出色。 但是，由于 AppContainer 沙箱中提供的可用 API 选择的奇怪子集，我一直在努力构建“UWP”应用程序。 作为 C++ 开发人员，这令人沮丧，并且每年看到您进一步打开沙箱以允许完整的 Win32 API 集已是一种解脱。

因此，如果 WinUI 3.0 允许我构建一个可以访问 100% Win32 堆栈的应用程序，那么这将是黄金！ 我现在已经尝试使用 XamlIslands，这是一个很棒的逃生舱口，但它对我来说很不稳定，在它真正跨过终点线之前还有一些工作要做。

获得让我构建 Win32 应用程序的项目模板，而不会被塞在 AppContainer 进程中，并让我访问您使用 UI 所做的所有改进，那么 WinUI 3 将非常适合我。

@eklipse2k8仍然需要一个权限系统来访问用户的文件和设备，即使在轻松的沙箱中也是如此。 另外我认为应该有一些规则可以保留在用户空间中并避免提升到管理员和内核访问权限 - 没有某种官方测试和代码签名要求。

你好微软，

我不知道这篇文章会对字体渲染、 ClearType 、 DirectWrite和 Windows UI 的未来产生多大的影响，但我是少数对字体渲染子系统有严重不满的人之一视窗。

互联网上几乎到处都有人们对Windows UI 和字体呈现喜欢字体平滑，你会发现其他人绝对讨厌它。

我不是在这里讨论一个是否比另一个更好。 我也不是在这里讨论注册表黑客、“字体调整器”或如何调整操作系统设置以使字体看起来更好。 相信我，我已经做到了； 甚至研究编写内核模式驱动程序来修补内核模式下的 DirectWrite 函数。

我来这里是因为我有一种非常常见的眼科疾病，称为

超出手臂距离，我需要戴矫正镜片。 :eyeglasses: 我相信我们都知道，台式电脑屏幕的距离大约是手臂的距离。 因此问题来了。

• 看起来光滑的字体对我来说看起来很模糊。
• 带有锐边（对齐像素）的字体对我来说看起来更清晰。

当字体与像素对齐时，锐利的边缘是向我的大脑发出的视觉信号，表明我的视野清晰且聚焦。 然而，当我遇到字体平滑的文本时，这种视觉信号会欺骗我的大脑，让我认为

作为一个花费大量时间编写代码和查看文本的开发人员，这令人沮丧和痛苦。 这是我仍在运行Windows 7而不是Windows 10 的主要原因。 几乎所有 Windows 10 主 Metro UI 都在各处使用字体平滑。

为了说明这个字体平滑问题，让我们看看Windows 7上的services.msc MMC 管理单元：

您是否看到任何看起来失焦的模糊文本？ 这里。 让我们放大一点...

天哪，我感觉就像我在自动立体图中用斗鸡眼看文字一样。

事实证明，在这种特定情况下，通过挖掘该窗口的控件层次结构，MMC 管理单元承载了一个 Internet Explorer DHTML/ActiveX 控件，该控件在“选择一个项目以查看其描述”面板中呈现模糊文本。 清晰（对齐像素）、“帮助”菜单和服务列表是用普通的 USER32 和 GDI32 原语呈现的。

这个小例子突出了 Windows 中字体渲染的最大问题之一。 事实证明，IE8 将尊重禁用 ClearType 和字体平滑的全局操作系统设置。 但是，如果您安装 IE9 或更高版本，IE9+ 将很乐意忽略任何和所有禁用字体平滑的努力。 IE9+ 只是不在乎并强制所有用户使用字体平滑文本查看网站（和 ActiveX 控件中）上的文本。

对于像我这样的用户来说，问题变得更糟，因为随着时间的推移，Windows 8 和 Windows 10、Metro Apps、WPF 和 UWP 的诞生都采取了与 IE9+ 相同的方法。 所有这些底层的 UI 技术都忽略了在我们的机器上应该遵守的全局操作系统范围的设置

我知道我不是唯一一个遇到这个问题的人。

不久前，谷歌浏览器在v31 版本中做了同样的事情，并尝试遵循 IE9+ 方法并将所有字体渲染切换到DirectWrite，忽略全局系统范围的设置。 这一变化让互联网风靡一时。 请参阅Chromium 问题 319429 。 最后，经过多次咬牙切齿后，谷歌改变了方向并纠正了Chrome 37中那些有近视视力障碍的用户的问题，现在尊重禁用字体平滑的操作系统范围的设置。

由于强大的力量和市场力量，微软输掉了浏览器战争，现在正在采用 Chromium 渲染引擎，但我屏住呼吸，Edge 团队将尊重禁用的字体平滑设置。

我在这里只是为了提倡微软需要一个需要尊重的全局设置，对于操作系统上的所有应用程序，跨所有 UI 堆栈，对于那些有视力问题的人。

作为友好的提醒，这通常是 Windows UI 的可访问性问题，而不是视觉偏好之一。

根据世界范围内近视的患病率，可以估计当前世界人口的22%以上，即15亿人是近视的。 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

谢谢，
布赖恩

:walking_man: :walking_woman:失踪人员 - 走在洛杉矶

这意味着完整的 Xaml 框架将在 GitHub 上开发并作为NuGet包带外发布。

NuGet 很棒，但支持vcpkg （和CMake ）也会受到赞赏（对于我们这些拥有大型现有跨平台库的人）。

您最感兴趣的模板是什么？

按优先顺序：
Win32 + Xaml 桌面 + WinUI
Win32 + Xaml 岛 + WinUI
UWP + WinUI

您是否知道 Xaml Islands 用于使桌面应用程序现代化？Windows 10 上扩展的向后兼容性是否会使 Xaml Islands 对您更有用？

是的，Xaml Islands 很有趣，但是由于我们针对的是消费者而非企业客户，扩展的向后兼容性并不是一个交易破坏者 - 大多数客户都相当乐意更新他们的操作系统（并给出了基于新 WinUI 实施更改的时间尺度Xaml，将其锁定到 1903 年可能意味着它已经推出一年了）。

WinUI 中 Xaml、组合和输入 API 的根命名空间将不同于 Windows UWP SDK 根命名空间：

如果 Visual Studio 或其他工具自动为您更新命名空间会有所帮助吗？

这不会影响我，因为我们没有 UWP 应用程序（目前使用 WPF 进行直销，使用 WPF + Desktop Bridge 进行商店），但更改命名空间是一次性的，即使在最大的代码库中， Windows::UI::Xaml的全局查找和替换并没有那么令人生畏（我们都在使用版本控制，对吧......？）。

发布 WinUI 3.0 的最快途径是不支持混合：

这对我来说很好，它们应该被视为单独的不兼容库。 您可以针对 UWP Xaml 或 WinUI Xaml。 如上所述，一次性转换不应该那么困难。

但是，我们最大的担忧之一是兼容性问题和可能为现有 UWP 应用和组件库创建的工作，尤其是在您创作或使用 UWP Xaml 控件库时。
例如，现有版本的Windows 社区工具包将无法在 WinUI 3.0 应用程序中使用，因此工具包和使用它的任何应用程序都需要在使用 WinUI 3.0 之前进行更新。

微软需要选择一种技术并坚持下去。 多年来，我们一直承诺提供最新最好的桌面 UI 框架（Win32、ATL、WTL、MFC、WinForms、WPF、UWP Xaml 和现在的 WinUI Xaml）。 虽然选择很好，但它会导致功能和开发人员知识的碎片化。 在 Windows 中实现一项功能的一个会话/一个网页/一个 stackoverflow 答案要容易得多，而不是 7 个不同的答案，具体取决于技术。 如果 WinUI Xaml 是未来，则需要更新社区工具包以利用它。

现有 UWP Xaml 组件与 WinUI 3.0 应用程序之间的完全兼容性对您来说有多重要？

我一直在推迟使用 UWP Xaml 做任何事情，因为该功能不存在（与 Win32 / WPF 相比），并且我认为在这方面我并不孤单。 因此，完全兼容性不是问题。

您是否创建或使用了无法与应用代码一起轻松重新编译和更新的 UWP Xaml 控件库或 WinRT 组件？

不。

在 WinUI 3 中使用 UWP Xaml 组件的首选解决方案是什么？

不适用

1. 您如何看待上述和路线图中概述的整体 3.0 计划？ 它能让您将 WinUI 用于新的和现有的 Windows 应用程序吗？

路线图中没有提到Xaml Desktop 。 这是否属于 WinUI 的职权范围？
我之前在 //Build/ 上向人们提到过这一点，但之前不采用 UWP Xaml 的原因是不可能制作使用现有 C++ 库的应用程序。 例如，当用户使用FileOpenPicker选择文件时，结果将作为IStorageFile传递，并且无法将其传递给现有的第 3 方库以打开（例如libpng 、 libjpeg等）。 这就是我们必须坚持使用 WPF 的原因，所以如果Xaml Desktop或Win32 + Xaml Islands允许我们在没有这些限制的情况下生活，那么是的，它将使我们能够将 WinUI 用于新应用程序。

1. 您最希望将 WinUI 3.0 用于哪些应用程序？ 创建一个新的 Win32 应用程序并使用MSIX将其

使用 WinUI 创建一个新的 Win32 应用程序（并使用 MSIX 打包）。

如果您有任何问题，请告诉我，我很乐意进一步讨论。

实际上希望有办法从 WPF/WinForms 调用 Compact Overlay。
我们只需要一个管理员权限系统，例如 Android 中的“绘制其他应用程序权限”。

希望这个应用程序模型 + 包装（UWP + AppX，Win32 + MSIX）允许（沙盒内的完全抽象）

Windows 不是应该是最先进和无限的可能性，具有最好的安全性吗？
为了安全起见，没有残缺的功能。

感谢您向社区开放，以征求有关路线图的意见。

现有 UWP Xaml 组件与 WinUI 3.0 应用程序之间的完全兼容性对您来说有多重要？

说到这一点，我们现在有相当多的 UWP 应用程序用于企业客户端，我希望迁移路径不会那么困难。 如果有重大变化 如果有一个类似于.Net Framework到.Net Core的迁移工具，它会生成我们的迁移路径的兼容性，这应该报告任何可能需要更改的内容（例如，可能会被弃用或行为不同的 API）以及在可能的情况下自动更改命名空间的选项。 这样，UWP 到 WInUI 的迁移路径对于我们企业开发人员来说就不会那么不稳定。

您是否知道 Xaml Islands 用于使桌面应用程序现代化？
Windows 10 上扩展的向后兼容性是否会使 Xaml Islands 对您更有用？

是的，但这并不是什么大问题，因为我们所有新开发的桌面应用程序都在通过 API 后端使用 UWP 通信，而且我们的大多数客户已经在运行 Windows10。

您如何看待上述和路线图中概述的整体 3.0 计划？ 它能让您将 WinUI 用于新的和现有的 Windows 应用程序吗？

桌面团队已经对 WinUI 3 的消息感到兴奋，但如上所述，如果路径不是那么顺利，他们害怕将我们所有的 UWP 应用程序迁移到它。

至于一般的 XAML，因为整个 XAML UI 框架将与 Windows 分离，正如其他人所说的那样，因此可以更换渲染器。 这将开辟在其他平台上运行 WinUI XAML 的可能性，这是当今人们选择坚持使用的堆栈的一个巨大决定因素，正如 Electron 和 JS 框架的流行所证明的那样专门为每个平台开发本机代码库的人力。

还要补充一点，从 WinUI 3 开始，XAML 方言也应该有所改进，可能会引入一个版本命名空间/Doctype 来指定正在使用哪个版本的 XAML，以便保持对旧应用程序的向后兼容性。 要使 XAML 不那么冗长或将一些样板文件分块，还有很多工作要做，例如必须编写INotifyPropertyChanged并为其提供支持的私有设置器，而不仅仅是一个简单的属性属性，例如NotifyPropertyChangedAttribute并让构建步骤注入实现以避免运行时开销或DependencyProperties用于自定义控件以简化组件的制作。 也许还可以对 Razor 团队的一些好的部分进行一些改进。

这些请求可能可行，也可能不可行，但我喜欢 XAML 并希望它继续改进，所以我将说明我和我们团队中的一些人在为他们开发时遇到的一些痛点（但仍然可用）。

@mdtauk我不反对文件安全，但底层内核应该阻止你在你没有授权的地方写作，而不是使用一套全新的 API 并放弃 win32 文件 API。 另外，我知道这已经离题了，但是 StorageFile/StorageFolder api 是可怕的替代品，甚至不考虑文件安全性。 它们很慢，而且您总是通过运行时文件代理进行代理。 此外，沙盒应用程序需要特殊的 MS 批准权限才能写入用户的文档文件夹，这绝不应该成为限制。 举个例子，AppContainer 的文件故事是多么糟糕，除了在用户隐藏的 LocalData 文件夹中，不可能在任何地方创建一个 sqlite 数据库。 对于用户想要创建、保存和打开文件并另存为 yadda yadda 的桌面系统，这给软件开发人员带来了负担，他们需要重新培训用户如何管理用户的内容。

就管理员访问权限而言，2018 年 10 月的版本添加了“allowsElevation”作为权利，这是有道理的。 如果用户需要对某些功能集进行广泛的系统级别访问，则应用程序可以允许用户以管理员身份运行。 我们并非都在构建可爱的小照片编辑器和流程图应用程序。

@MarkIngramUK感谢您的评论，仅作澄清。 在 //Build 2019 的 Sneak Peek 中提出的 Xaml 桌面概念已重命名为 WinUI 桌面。 这个新的 Visual Studio 项目将使用 Win32 应用程序模型，以 WinUI 作为表示框架，它可以是本机的或托管的（使用 .NET Core 3）。

谢谢@marb2000 - 这是在 WinUI 3.0 时间范围内吗？

WinUI Desktop 的@marb2000 ，您的意思是带有 Xaml Islands 的 Win32 应用程序？ 这是在哪个构建会话中显示的？

WinUI 团队应该注意 WinUI 3.0 重命名的一件事：如果您重命名在 .NET 中投影的任何类型，那么投影将不起作用（我们不打算添加更多，因为它不是一个可维护的可扩展系统）。 这是我们项目的类型列表： https :

对与这些类型不同的类型的任何更改都需要用户将他们的对象包装在实现新接口的新对象中，或者将他们的数据复制到新类型中。 特别是， INotifyPropertyChanged和INotifyCollectionChanged类型对 XAML 岛和提供下游支持很感兴趣。

INotifyDataErrorInfo

请不要为 INotifyDataErrorInfo 之类的东西引入新的命名空间 - 它应该用于通常是跨平台的视图模型并且不应该依赖于 WinUI。 应该定义其他类似的东西所在的位置（即 INotifyPropertyChanged 或 INotifyCollectionChanged）

关于这个话题。 Windows.UI.Xaml.Interop 已经有 INotifyCollectionChanged 接口，Windows.UI.Xaml.Data 有 INotifyPropertyChanged。 这两个将移至 Microsoft 命名空间。 也许 System.Runtime.WindowsRuntime 程序集可以做一些从 WinUI 到 .Net 的映射

感谢您的回复，但如果 .NET Standard 已经在 System.ComponentModel 中拥有它，为什么您需要在 Microsoft 命名空间中使用它？ https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@meir-pletinsky。 NET 只是一种可用于使用 UWP XAML 制作应用程序的框架。 他们希望开发人员可以使用文本字段验证，无论他们使用什么框架

@mdtauk不，WinUI 桌面（以前称为 Xaml 桌面）允许您直接在 Win32 中使用 Xaml，而无需使用岛。

@marb2000如果应用程序打包项目允许您使用 Win32 窗口构建 AppX 并以与 UWP 项目相同的简单方式包含 WinRT 组件，那就太好了。 如果不手动编辑 vcxproj 文件，例如添加资源和 cppwinrt 编译器从包含的 WinRT 组件生成标头，有很多事情将无法工作。

另一个对这个新UI很重要的项目是Simon Cropp 的 _PropertyChanged.Fody_ ，它允许自动实现 INotifyPropertyChanged（我尝试过 C#/F#）。 见https://github.com/Fody/PropertyChanged

它允许像这样的简单代码：

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

我们可以用来绑定到 UI。

我希望在 WinUI 3.0 中看到的一件事：目前，当从 csproj、vbproj 或 vcxproj 文件引用时，UWP XAML 编译器 ( genxbf.dll ) 只能由 MSBuild 直接调用。 这是因为没有可用于调用此功能的命令行工具。 这让我觉得这是一个非常奇怪的决定，因为 Windows 10 SDK 下载中没有其他内容需要 Visual Studio。 （WDK 附加组件还包括 Visual Studio 目标，但这些目标都调用可独立于 VS 使用的命令行工具。）我非常感谢添加例如XbfCompiler.exe和XbfCodeGen.exe到 SDK 的 bin 目录。 （前一个 EXE 将 XAML 文件编译为 XBF 文件，后者将生成从代码中引用 XAML 类型所需的代码隐藏文件。）这主要在使用 CMake 或其他非 Visual 的 C++ 项目中有用Studio 构建工具，但如果需要，也可用于 C# 和 VB.NET 项目。 谢谢！

@MarkIngramUK你知道我可以在哪里了解更多关于 WinUI 桌面的信息吗？ 这些 Build 2019 课程无法在线观看。 听起来像应该在这个 repo 中链接到的重要信息

@mdtauk在所谓的 Sneak Peek 中提到了这一点，它仅适用于 Build 参与者。 Afaik 没有录音。 我也不在那里，但有一张幻灯片 - 也许是最好的幻灯片 :-) - 可在 Twitter 上找到： https :

@mdtauk WinUI 3 路线图包含最新的信息和图表，这些信息和图表比 Build

3.0路线图对于以下策略似乎非常合理：允许任何 Windows 客户端应用程序使用 XAML 和“现代”WinUI 控件。

然而，如果考虑到当今市场的现实，这种策略似乎是短视的：对于许多应用程序开发而言，Android 和 iOS 是主要目标，而 Windows 是一个很好的选择。 对于 .NET 开发人员，Xamarin 为您提供了不错的 Android 和 iOS 支持，但他们的 Windows 支持低于标准。 因此，对于本机移动/桌面应用程序，Win UI 3.0 不会为 .NET 开发人员简化跨平台开发。

我真正希望看到的是一种具有真正普遍愿望的前进 XAML 方言。 我应该能够使用 XAML 编写一个 .NET 应用程序，并让该应用程序在 Windows、iOS 和 Android 上运行。 该应用程序应该在每个平台上都是一流的，并且可以根据需要访问本机元素。 如前所述，Xamarin 是一个好的开始，但它的 XAML 方言非常不同，它对 Windows 的支持很差，而且您所做的工作都没有帮助。

所以，tldr，很高兴您继续为 Windows 提供现代 UI 平台。 很好，您可以更轻松地从不同类型的应用程序中使用。 不好的是你不渴望跨平台支持。

（可选）禁用或选择退出旧版移动应用程序生命周期行为，例如挂起 + 逻辑删除。

现实情况是，UWP 是一个桌面环境，至少对于游戏而言，用户可能经常最小化应用程序，这通常会导致应用程序暂停/墓碑化。 这是一种不和谐的体验，与任何 win32 桌面应用程序或游戏都截然不同。 请求延期延期（可能仍会到期）不足以无缝处理此问题。

虽然此生命周期对某些应用程序很方便，但对其他应用程序有害。 理想情况下，桌面应用程序或游戏应该能够声明允许应用程序选择退出挂起+墓碑生命周期模型的功能，这将防止它在最小化时最终被挂起。

@natemonster

每个： https :

在桌面设备上，使用 ExtendedExecutionReason.Unspecified 创建的扩展执行会话具有电池感知时间限制。 如果设备连接到墙上电源，则扩展执行时间段的长度没有限制。 如果设备使用电池供电，则延长的执行时间段可以在后台运行长达十分钟。

平板电脑或笔记本电脑用户可以获得相同的长时间运行行为 - 以电池寿命为代价 - 当在应用设置的电池使用中选择允许应用运行后台任务选项时。

@TonyHenrique当您提到Fody时，这是因为您想建立对它的认识，还是说它应该内置到 WinUI 中？

项目或库模板也很有趣！ 到目前为止，答复中有一些关于提供额外样板和入门代码的重要观点，这些是我们可以考虑随着时间的推移添加的其他内容，例如 Windows 模板工作室。

@Jesbis我是 Windows Template Studio 的核心贡献者，我正在关注 WinUI 路线图，以了解我们未来的工作以及我们如何引入对 WPF 的支持。 ;)

什么样的依赖更新会使其更有价值？ 例如，寻找新的兼容 NuGet 包版本？

能够检测 NuGet 更新会更有用，但进行更新还有其他潜在的兼容性问题。 我会将检测新版本和自动转换列为低优先级。 有太多的考虑，它本身就是一个大项目，我宁愿看到时间在平台上投入，而不是像这样的工具。

@mrlacey我提到一种更好的方法来避免 _INotifyPropertyChanged_ 样板代码。 对于 Reactive 对象的这个概念，如果有一个 MS 支持的解决方案，它会在某些属性更改时自动引发事件，这将是一件好事。
它适用于 C# 类，甚至适用于 F# Records（但有一些困难）。
所以在 WinUI 路线图上也应该有这个。

注意：如果我们也可以使用 F# 记录来定义我们的数据实体，然后直接绑定到 XAML UI，那就太好了。 如果我们可以毫无问题地使用 F# Records + Fody + DataBinding，那就太酷了。

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

对于来自 C# 的人来说，这会更熟悉。
另一种方法是 Elmish 方式。 我认为两者都很有趣，并且可以得到支持。

@tonyhenrique / @mrlacey我认为

而且我认为这实际上是模型的 .NET (IL) 实现细节，实际上与 WinUI 没有任何关系（尽管它可以侦听更改事件）。 我的建议是将它们分开。 例如，我使用 Catel，它有自己的 Fody 编织机，以确保所有东西都正确编织。

我真正希望看到的是一种具有真正普遍愿望的前进 XAML 方言。 我应该能够使用 XAML 编写一个 .NET 应用程序，并让该应用程序在 Windows、iOS 和 Android 上运行。 该应用程序应该在每个平台上都是一流的，并且可以根据需要访问本机元素。

有一个长期的建议朝着这个方向发展： .NET 5 的跨平台 UX - 原标题Cross platform UX for .NET Core 3.0 。 社区对它的压倒性支持是显而易见的，我们可以希望 MSFT 会意识到这是开发任何在 .NET 上工作的 UI 框架的最佳方向。 几乎没有理由为不同的平台组保留单独的代码库，并根据 .NET 支持的不同 UX 框架强行创建单独的开发人员技能集。

通过为所有平台创建单一用户体验，我们消除了框架开发中的所有低效率，并降低了开发人员采用的障碍。

@mfeingol / @4creators ，我会满足

该应用程序在每个平台上都应该是真正一流的

在 Windows 上开始...

现在是 2019 年，我想要一个快速、原生的 UI，而且我不想认真考虑使用CreateWindowExW 、GDI 等来制作用户界面。

现在WinUI3.0及以上版本的代码与Windows 10解耦了，未来有没有计划让WinUI在Linux和Mac上运行？

@jesbis Touch 交互会保留在 WinUI 3.0 中吗？

感谢您的澄清，我认为 3.0 的工作方式是在 WinUI 中包含 Xaml Islands，而不是使用社区工具包。

随着它成为 XAML 和 Win32，它变得更有意义，尤其是在 Windows 核心操作系统用 XAML 重写它的外壳时。

据我所知，这个丰富的 Win32 API 访问是在 C 和 C++ 中的 C# 中的任何东西都依赖于 .NET（现在都是 .NET Core）。

也许应该有一种安全且简单的方法来访问这些 Win32 API，以及用于显示应用程序 UI 的更多入口点？

• WinUI 3 应用程序的系统托盘 XAML 弹出按钮

• Hololens/Xbox/Surface Hub/IoT 等的简单选择器 UI

• 更新了 XAML 可自定义的通用文件对话框和文件夹选择器

• 对 Win32 API 的简单 C# .NET 访问

• 所有 XAML 元素的紧凑设置，匹配 Win32 和 WPF 控件大小（这将有助于框架舒适地坐在一起）

• 使用 WinUI 时匹配控件样式/字体/重音画笔/亚克力

• 明确定义哪些设备需要 WinRT/Mobile 生命周期

• Xbox Next 控件样式内置用于 Windows 上的 Xbox 应用程序开发和测试

• 默认支持存储和单个exe/MSI/APPX打包下载，NO INSTALLERS，默认百年型文件系统虚拟化

• WinForms WinUI 3.0 - 简单的 UI，只能访问 MFC、鼠标和键盘

• WPF WinUI 3.0 - 密集 UI、3D 渲染、DPI 感知、模拟触摸和基本墨水支持

• Xaml WinUI 3.0 - 全触控、MR、游戏手柄、墨迹书写、语音、鼠标、键盘。 密集而简单的用户界面。 新的窗口支持。 MR 3D 渲染。 可选的托管生命周期或桌面生命周期。 世界上最好的外壳和重新设计的收件箱应用程序的默认设置，带有 Win32 版本的收件箱应用程序，如记事本、charmap、油漆、文件资源管理器 - 开源并可从商店获得。

WinUI 3.0 中会保留触控交互吗？

@r7dev是的，计划是保持相同级别的触摸支持。

F# 在 WinUI 3.0 路线图中被忽略。 微软再次无视其产品之一。

Win32 API 思考

我还想到了 win32 也一直存在的原因。 我认为有一种假设是因为遗留项目，但实际上比这更深。 Win32 ABI 非常容易与您选择的语言、nodejs、python、rust、go、ruby、c#、c++ 等连接。例如，如果我的核心项目是 rust，并且我想生成一个窗口为了管理输出，作为 Rust 开发人员，访问 win32 API 集并使用相同语言构建前端是非常强大的。

在 OS X 上，要访问 AppKit，您只需要桥接 objc_msgSend C API 并获得对整个 obj-c 基础架构的访问权限。 上面所有这些语言都很好地弥合了这一点，并且可以轻松地用您选择的语言编写并产生令人信服的东西。

因此，如果您想让 WinUI 3.x 成为访问低延迟、低内存、高质量 Win32 UI 的真正途径，您需要考虑其他语言维护人员可以轻松地利用基础设施。

用户界面一致性

如果您真的打算将 UI 与系统分离，那么 UI 与每次操作系统升级保持一致的计划是什么？ 当 Apple 对 AppKit 或 iOS 中的阴影和渐变进行调整时，依赖于系统框架的应用程序会继承所有这些调整并保持一致。 这也将使您难以添加系统范围的体验，因为 3 年前锁定到 UI 基础架构的应用程序可能无法在某些新系统服务上正常运行，因此随着时间的推移，它们将具有另一个兼容性层。

总会有一些功能需要选择加入，我可以认为暗模式是如果应用程序不是为它设计的，那么提供它作为一个选项真的没有意义，但仍然有对随时间变化的系统组件的调整。

二进制大小

在我们的项目中交付所有这些 UI.dll 的计划故事是什么？ 这些东西会是 40mb 的运行时需要随我们的项目一起提供吗？ 如果一个项目被放弃会发生什么，他们是否会因为使用旧的 UI 框架而开始显得过时？

C++ 的好处之一是它的库开销最小，具体取决于代码库。 当然，如果从现在开始的每个应用程序都需要 WinUI 3.x，那将是 40mb x 应用程序数量。

二进制大小

WinUI 已经是一个依赖项，就像 .NET 一样。 它已经是一个系统范围的库。 :)
您没有重复的 dll，也不会拥有它。
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@eklipse2k8

“我还想到了 win32 也一直存在的原因。我认为有一种假设是因为遗留项目，但实际上比这更深。Win32 ABI 非常容易与您选择的语言联系起来, nodejs, python, rust, go, ruby​​, c#, c++, etc. 等等 如果我的核心项目是rust，我想生成一个窗口来管理输出，作为一个rust开发者，超级强大访问 win32 API 集并以相同的语言构建前端。”

这是一个混合包，虽然为新语言实现 WinRT 支持是一个巨大的障碍，一旦你这样做，你最终会自动生成对任何新 API 的类型化绑定。 我最近一直在研究一个连接 Win32 和 WinRT 的 Rust 项目（在 Win32 窗口中使用 Composition API），尽管我不得不笨拙地处理剩余的部分，但 Win32 部分总体上肯定更痛苦缺少对某些 WinRT 功能（如类继承）的 Rust 支持。 （现在可以在 Win32 中使用 Composition 确实有帮助，因为它允许逐步改进对此功能的支持，而不必一次处理整个应用程序模型）

可能最大的问题是低级 WinRT ABI 详细信息的文档有点杂乱无章，世界/社区对它们的了解或认识很少，但我希望这种情况会随着 xlang 项目得到改善。

您对哪些模板最感兴趣？

目前我更喜欢从一个空白应用程序（通用 Windows）项目开始。 我也喜欢带有预配置框架的模板，但只有当我想快速尝试一些东西时。 UWP 的“主菜单”模板和 MDI 模板也不错（因为这些模板也适用于 WinForms）

您是否知道 Xaml Islands 用于使桌面应用程序现代化？
Windows 10 上扩展的向后兼容性是否会使 Xaml Islands 对您更有用

是的，我知道 Xaml 岛。 如果可以，我会尽量坚持使用纯 WPF 或纯 UWP 应用。 我当时不需要这样的功能。

如果 Visual Studio 或其他工具自动为您更新命名空间会有所帮助吗？

是的，确定它是否可靠！ 我很惊讶许多评论不喜欢这样一个好的功能。 此功能还可以检查 WinUI 3.0 的更新是否可行，采用 XAML 代码，调整命名空间并安装所需的 WinUI nuget。

现有 UWP Xaml 组件与 WinUI 3.0 应用程序之间的完全兼容性对您来说有多重要？

我希望仅更改控件的命名空间以与 WinUI 3.0 一起工作。 我不想花太多时间升级到 WinUI 3.0

您是否创建或使用了无法与应用代码一起轻松重新编译和更新的 UWP Xaml 控件库或 WinRT 组件？

我正在使用第三方 UWP Xaml 控件库（如 Windows 社区工具包，https://github.com/kakone/VLC.MediaElement ）。 我想我可以自己将 Dockpanel 等第三方库中的简单控件升级到 WinUI 3.0。

在 WinUI 3 中使用 UWP Xaml 组件的首选解决方案是什么？

• 在 Visual Studio for UWP 中创建“Blank App with WinUI 3.0”项目模板。 WinUI 3.0 依赖项将作为 nuget 安装（就像在 WinUI 2.0 中一样）。

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] 。 只要我获得所有基本控件，我绝对会更喜欢这样的解决方案。 我希望来自 Windows.UI 的所有类在 Microsoft.UI 命名空间中都有一个等效的类。

WinUI 3.0 中的主要主题是关于控件和 Windows 10 兼容性的，如果我是对的，可以通过 XAML 岛从 UWP 和 WPF 或 WinForms 使用它们。 UWP XAML 标记是否有可能获得某种附加功能？

• 缺少样式触发器
• 样式`BasedOn={StaticResource {x:Type TextBlock}} 缺失
• 使用 DataTypes 定义的 DataTemplates 不会像在 WPF 中那样自动应用（仅通过 Key）
• 为什么每秒Windows.UI.Xaml.Controls控件（TextBlock、Border、...）都被声明为密封的？！ 请不要在带有 UWP 的 WinUI 3.0 中执行此操作。
• WPF 奇偶校验的标记扩展
• 这已经提到了，但我要再提一次。 令人遗憾的是，UWP 没有使用 System.ComponentModel.IDataErrorInfo。 这样我就无法与 UWP 解决方案共享我的模型项目。
• ReportControl（用于企业应用程序）

我真的很期待 WinUI 3.0 及其向后兼容性！

在 WinUI 3.0 路线图中忽略 F#

UWP XAML 标记是否有可能获得某种附加功能？

@Happypig375 ，@mfe-：

路线图仅涵盖初始 3.0 版本，对于初始版本，我们主要关注现有功能的奇偶校验和向后兼容性，以及少量新功能。

如果您认为其他新功能（如更好的 F# 支持或新标记功能）很重要，那么请打开新功能请求，以便我们可以单独跟踪它们！

为什么每隔一个 Windows.UI.Xaml.Controls 控件（TextBlock、Border、...）就被声明为密封的？！ 请不要在带有 UWP 的 WinUI 3.0 中执行此操作。

开封控件实际上是我们希望包含在 3.0 中的少数新功能之一😊

当涉及到语言时，混合和匹配会很整洁（如果在打包之前将所有内容都编译下来应该没问题）

F# 用于一些后端逻辑 - C# 用于数据绑定和 UI 代码 - C++ 用于控件和一些低端 Win32 挂钩，甚至用于启动 WinForms 对话框。

所有代码语言都是平等的，可互换的，WinUI 3.0 处理所有 UI

那是xlang😉

那是xlang😉

@MarkIngramUK嗯，我认为它是语言之间的桥梁，它抽象了每种语言，而不是在单个项目中允许来自多种语言的代码文件。

我有点难以理解 xlang 的目的 - 掩盖了 repo 中发生的更新（但仍然在我的观察列表中）

xlang 在编译前还是编译后工作？ 它是可以投影的自己的抽象语言，还是只是位于现有代码文件之间？

是的，您不能在一个项目中混合使用多种语言。 它是一座桥梁，但对于这些目的仍然有用。

@MarkIngramUK我想如果它的代码可以编译然后包含在内。

能够使用 C# 访问本机 Win32 功能会很好，而无需 PInvokes 和其他 .NET 技巧

@jesbis老实说，我对这个项目的跨平台方面更感兴趣......

我认为一开始，你们应该将其重命名为更通用的名称，而不是严格地重命名为“Windows”。

我知道最初的实现应该严格专注于 Win32 并支持 UWP/Xamarin 应用程序和 Windows，但只是 OSS 并从一开始就将其称为“仅限 Windows”的框架，绝对不会像 UWP 一样受到太多关注没有，其他平台的开发人员永远不会对它感兴趣。

如果 .Net 5 的目标是“One .Net Everywhere”，这基本上是自 .Net 1.0 以来每个人一直期望的，那么“Anything but Win UI”框架的基础应该开始跨平台。

谷歌 Flutter 就是一个很好的例子，说明如何使它正确。 Flutter 还处于早期阶段，但由于其核心（又名 Flutter 引擎）是 100% 跨平台的，并且在任何地方（包括 IoT、Win、OSX，现在甚至是 Web！）都可以使用，因此获得了很多关注。

那只是我的2c。 我很想回到 Xaml 上工作，但如果它与 UWP 保持在同一条线上，恐怕它不会得到正确的牵引力，并且将是重新编写 WPF 的另一种尝试，最终需要再次尝试未来等等。

请不要让我生气，也不要将我的评论视为不好的批评。 我只是希望 .Net 世界上 UI 的努力能够得到类似 Flutter、.Net Core 3.0/.Net 5 甚至 Blazor 的东西。

作为记录，由于 .Net World 上缺乏选项，我开始了一个项目，以完全在 C# 和 .Net Core 上重写/移植 Flutter 引擎......

顺便说一句， CoreUI是个好名字...

感谢 Jake Helfert 的建议 😄

💃

顺便说一句， CoreUI是个好名字...

感谢 Jake Helfert 的建议 😄

💃

CoreUI 可能会与 .NET Core 混淆

WinUI 非常专注于 Windows，但其中的 XAML 框架可以获得 Metal（iOS 和 macOS）或 Vulkan（Android）的渲染器 - 而 FabricWeb 可能是处理其他平台的 PWA/ChromeOS 方式。

如果团队选择引入演示平台，Xland 或 Xamarin 可以处理跨平台应用程序的运行时。

关于从收件箱 UWP UI 迁移到 WinUI 3.0，我将引用@dotMorten最近的一篇博

有趣的底部说明：UWP 发生的事情并不是它被扼杀了：微软正在转向将最好的部分带到我们需要的地方。 这实际上发生在之前，但不幸的是它没有被用作执行枢轴的机会。 还记得银光吗？ 猜猜 .NET Core 的跨平台 CLR 从何而来。 许多 Silverlight 的代码也最终出现在 UWP 中。 如果他们只是转过头说“是的，我们同意 Silverlight 在消费者备用品中没有意义，但它在企业领域蓬勃发展，所以让我们以此为基础，我们将把它发展成 .NET Core 和 Windows 应用商店”。 不幸的是，这并没有那么顺利，而且很多人仍然患有 PTSD，并且对 Microsoft 所做的似乎正在扼杀任何技术的任何事情持谨慎态度。

我真的认为重要的是要记住，在没有为开发人员和代码库提供良好前进道路的情况下，被视为杀死或重置现有框架不仅会影响现有框架的开发人员 - 它会给未来的努力蒙上阴影，因为每个人都想知道为什么新事物不会只是遭遇同样的命运。 这并不是对任何特定提议的迁移方法的评论，而是对关于迁移无关紧要的评论的回应，因为没有多少人在使用现有的收件箱 UI 框架。 这不是唯一的考虑！

@weitzhandler WinUI 3.0 将各种 Win32、.NET Core 和 UWP 框架与单个 XAML 框架相结合，并与 WPF、WinForms 和 MFC++ 进行互操作

Windows 上的 XAML 呈现为 Direct X。

如果您想将相同的 XAML 与 .NET Core 结合使用，并使其在其他平台上运行。 您需要为这些平台编写新的渲染器。 iOS 和 macOS 使用 Metal 作为它们的 Direct X 等价物。 Android 使用 Vulkan。 不知道 Linux 如何处理渲染，我猜它只是 Open GL。

微软不想自己这样做，因为这对他们来说没有意义。 但是 WinUI 3.0 将是开源的 - 所以其他人可以选择尝试跨平台

@mdtauk

感谢您澄清这一点。 Flutter 可能是我的未来。

这只是我的理解，可能有误。

据说 Flutter 将来会获得 Windows 支持。 Windows 也将支持 React Native。 此外，如果您投资于 Web HTML 和 Javascript 世界，还有 PWA。

对我来说，如果他们还考虑允许它的至少一个基本子集运行跨平台（macOS、iOS、Android），包括 Web，并且还提供更好的 F# 支持和项目模板（包括XAML 双向绑定到 F# 记录，也是一种更实用的 Elmish 方式）

XAML 需要与环境无关，就像 HTML不需要像 HTML 应用程序那样为最基本的工具应用程序占用 100mb+。 这意味着一个 XAML 框架是用纯 C/C++ 或 C# 编写的，并且可以在 WASM、Win32、UWP、iOS、Android、macOS、Linux 等平台上托管，在移植时只需最少的努力。 您需要一个不可知的渲染后端，就像游戏引擎开始时使用的那样。

如果这个专注于 UWP 的 XAML 解决了我的公司或我个人多年来使用 XAML 遇到的任何问题，那就没有了……这就是可移植性。 TBH MS 正在处理 UI 完全错误的问题，并且它不会很快（它浪费了很多人的大量宝贵时间）。 这个 UWP XAML 黑客对我展示它的人来说并不好......这很可悲，因为它只是意味着永无止境地反对采用 XAML，在这一点上我没有更多的论点。

我认为保存 XAML 的唯一方法是：

• 为 .NET Core 和 C/C++ 创建一个新的不可知/可移植框架基础。
• 创建一个任何人都可以通过拉取请求扩展的不可知渲染抽象层。
• 就像 HTML 一样，XAML 将重点放在单窗口应用程序的概念上（就像在游戏中所做的那样）但允许为多窗口等扩展桌面功能（这允许应用程序在几乎任何上下文中运行，就像游戏 UI 一样）

简单地说，有两个条件必须合二为一，才能排除 XAML 适应。

1 MS 需要支持 XAML 项目，否则人们担心它会失败。

2 它需要是跨平台的，否则每个人都会被疯狂臃肿的 HTML 运行时所困扰。

无论如何，这是我的两分钱，如果 WinUI 3.0 设计正确，也许可以移植。 在这一点上，虽然不知道什么感觉。

这里有一些关于跨平台的评论，我不太确定 WinUI 是否需要跨平台才能成功。 无论如何，它在 Mac 或 Linux 上都不能很好地工作，因为它的不同之处在于它在这两个平台上都感觉不到原生。 这个项目由一个团队拥有，该团队对 Windows 内部的工作方式有丰富的知识，如果他们离开并弄清楚如何使某些东西在 Mac 或 Linux 上也能在相同程度上真正运行良好，这会分散他们的注意力。

还有... Fluent 在 Mac 上会感觉笨重，看看 iTunes，Apple 不得不将他们的整个 UI 系统移植到 Windows，这绝对感觉不合适。 字体渲染不同，动画曲线和阴影以及颜色选择在 Win10 中感觉很不合适。 我的意思是，它很好并且可以使用，但我更喜欢 Spotify，它不会尝试模拟任何桌面 UI，只是在引擎盖下使用 Web 浏览器。 在 Mac 上，在充满圆角且没有显示效果的桌面上看到带有方形组件的显示聚光灯会产生如此强烈的冲突。

不，我认为这个项目应该专注于为想要/需要构建 Windows 软件的开发人员提供一流的方式来制作原生 Windows 软件。 将跨平台的问题留给 Electron/Typescript 团队解决。

这里有一些关于跨平台的评论，我不太确定 WinUI 是否需要跨平台才能成功。 无论如何，它在 Mac 或 Linux 上都不能很好地工作，因为它的不同之处在于它在这两个平台上都感觉不到原生。 这个项目由一个团队拥有，该团队对 Windows 内部的工作方式有丰富的知识，如果他们离开并弄清楚如何使某些东西在 Mac 或 Linux 上也能在相同程度上真正运行良好，这会分散他们的注意力。
还有... Fluent 在 Mac 上会感觉笨重，看看 iTunes，Apple 不得不将他们的整个 UI 系统移植到 Windows，这绝对感觉不合适。 字体渲染不同，动画曲线和阴影以及颜色选择在 Win10 中感觉很不合适。 我的意思是，它很好并且可以使用，但我更喜欢 Spotify，它不会尝试模拟任何桌面 UI，只是在引擎盖下使用 Web 浏览器。 在 Mac 上，在充满圆角且没有显示效果的桌面上看到带有方形组件的显示聚光灯会产生如此强烈的冲突。
不，我认为这个项目应该专注于为想要/需要构建 Windows 软件的开发人员提供一流的方式来制作原生 Windows 软件。 将跨平台的问题留给 Electron/Typescript 团队解决。

我认为没有人真的想要在其他平台上进行完整的 Fluent 设计，而只是能够最大化平台之间的通用代码。

这是 Microsoft 设计团队已经解决的问题。 Fluent 网站明确表示“设计和构建原生 iOS 且仍具有独特的 Fluent 的自定义应用程序”。 Fluent 文档显示应该使用本机控件样式。
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

应该避免的是，必须为每个平台设计和维护完全独立的 UI。 这并不意味着它需要在表面上看起来完全相同，而是应该共享一个通用的布局，并且 UI 设计人员应该能够尽可能多地重用。 实际样式不需要（也不应该）与 Windows 10 系统样式匹配。

本质上，我们需要的是一种让 Windows 应用程序在其他平台上运行的简单方法，而无需重新制作整个 UI——而不是将 Fluent 设计带到其他平台。 这将使人们能够首先为 Windows 编写代码，然后将他们的应用程序带到其他平台，而无需进行大量工作。

@KyleNanakdewa好吧，如果他们开源它，让一些 Xaml 粉丝离开并创建底层平台位。 我认为它在架构上可能足够复杂，并且充分利用了 Win32，我怀疑移植将是一项艰巨的任务。

我认为这个项目应该专注于提供一流的方式来制作原生 Windows 软件

如果 Microsoft 还没有拥有一个现有的跨平台 XAML 工具包，而该工具包恰好提供了与 WinUI 截然不同的 XAML 方言，那么这个论点可能会令人信服。

此外，如果您投资于 Web HTML 和 Javascript 世界，还有 PWA。

是的……“那个世界”正在迅速取代我们对原生 OS/Store/Hosted 开发的了解。 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

考虑“那个世界”存在于带有 HTML5 渲染器的_所有_现代设备上：

• 苹果有 14 亿
• 拥有 25 亿的 Droid
• Windows 10 8 亿

您会注意到 Windows 现在拥有最小的市场份额，这意味着任何专门针对此平台的产品都将进入最小的市场。 这样做只会降低应用程序的最大潜在市场覆盖范围，进而降低其最大潜在收入上限。

将此与 Flutter 进行比较，后者的 _one_ 代码库覆盖上述市场的_所有_，以及上述市场

虽然我非常喜欢这里的开源、协作和征求社区反馈的努力，但我还没有从这些讨论中看到任何东西（我也很喜欢 😁）向我发出任何信心的信号，即这里的努力将是与 Flutter 之类的软件（顺便说一句，它也为 PWA 做准备）相比，它具有竞争力——因此是可盈利的。

在即将成为官方 NET CORE 3（2019 年 9 月）和最终版本的任何数据驱动的现代桌面体验中，图表控制都是必不可少的。 NET 5（2020 年 11 月）

我认为提供的 Networkview 开源控件是一个有效的用例，说明如何使用 Xaml 将 WPF 移植到 Win UI 控件。 这个移植的 Win UI 将成为其他人将其他稍微复杂的 WPF 控件移植到 Win UI 的良好公会。

我们看到了 2 合 1 用例，其中我们的应用程序需要在未来的 Windows 核心操作系统中支持平板电脑模式。 我们怀疑 .NET Core 3 中的 Winform 将无济于事..另一个强有力的理由说明为什么 Win UI 图控件不仅仅是 PoC 的练习，而是应该成为与 Grid 控件向前移动类似的 FIRST 类中的 win ui 核心控件的一部分..

如果您认为其他新功能（如更好的 F# 支持或新标记功能）很重要，那么请打开新功能请求，以便我们可以单独跟踪它们！

似乎@migueldeicaza正在自己处理事情： https :

我想回应@eklipse2k8关于跨平台的想法。 在制作一个跨平台的 UI 库时，你总是不得不做出妥协。 WinUI 不应妥协 - 它需要成为 Win32 UI 的现代替代品（我不想再调用CreateWindowExW ！）并且它需要展示您可以在 Windows 上执行的操作。 macOS 或 Android 上的 WinUI 将始终提供永远无法与本机体验相匹配的体验。 我们编写跨平台应用程序，并在每个平台上编写原生 UI。 这样客户就可以在他们选择的平台上获得最佳体验。 如果人们想要一个跨平台的解决方案，那很好，他们应该为此目的寻找另一个库——也许是一个在 Windows 平台上包装 WinUI 的库。

而关于PWA，这些并不代表完全使用Windows UI系统，推荐专注于“单窗口应用程序”会立即排除任何专业软件（游戏除外）。 已经有针对 PWA 和跨平台的解决方案——我们不需要另一个解决方案。

强制性 XKCD：
https://xkcd.com/927/

@MarkIngramUK我认为跨平台的讨论更多是关于能够编码到 .NET 和 XAML 以声明 UI - 然后让该应用程序在 Android、iOS、macOS、Linux 上运行？！ - 无需更改背后的代码或放弃 XAML。

现在，如果这些其他平台有 XAML 渲染器——它们如何解释 XAML 可能就像 Xamarin Forms，它移交给本机 UI 平台——或者只是基本上绘制到显卡缓冲区并在屏幕上绘制像素——保持大部分相同的控件样式。

WinUI 3.0 应该仍然是一个专注于 Windows 的项目，以将各种 API 和 ABI 与基于现代 XAML 的 UI 平台统一起来。 但这并不意味着 Xamarin 或个人不能接受渲染代码并为其他平台制作版本。

真正需要的（在高层次上）是确保包含将 XAML 呈现到 Windows 中的屏幕的代码，以便其他呈现器可以介入跨平台场景。

WinRT/UWP/XAML 将需要进行一些重构以将它们从 Windows 10 操作系统中解脱出来 - 因此，要记住如何进行重构以允许未来扩展。 跨平台是否成为现实。

@MarkIngramUK我同意@mdtauk

我们应该没有理由不能使用 xaml 来描述包括 React 在内的其他库中的 UI 组件。 如果您查看像http://www.cshtml5.com这样的项目，他们会使用可转换为 html 的 xaml。
我也不认为有人暗示最终目标是让 UI 在其他平台上看起来相同，但我个人想要的是 UI 方面的东西，我可以用它来利用我对 UWP 的现有投资

重点就是这个。 如果我向企业客户提出建议，并展示一个很棒的 UWP 应用程序，它在各方面都很棒。 如果该企业客户有 1 个使用例如 MacBook Pro 的用户，那么我会立即遇到问题，因为即使他们运行，企业客户也宁愿使用在任何地方都可用的东西（最低分母 => 网站）而不是我的“本机应用程序”在 Windows 10 上。

所以可访问性是关键。 MS 仍然期望我们在 2019 年投资“原生应用程序”而没有任何跨平台功能的路线图，这一事实很疯狂。

从企业角度来看，任何新项目都可能遵循上述可访问性逻辑，因此所有新项目都将偏向于 Web 和所有这些，因为没有包含 XAML/UWP 跨平台功能的路线图

那么我们快进 2-3 年，没有公司对 UWP/win32 的新投资，而您正坐在另一个没人关心的“银光”旁边。

MS 甚至可以告诉我 XAML 明天将被弃用，而“新”UI 库例如是 React。 只要 c# 可以粘在这个新库上，那么我就会减少损失，转储 XAML 并拥抱这个新的跨平台 UI 库。 至少我的投资具有耐久性并且可以长期使用。

由于没有就跨平台 UI 功能的这个特定问题提供清晰的信息，MS 正在为其“本机堆栈”创造不确定性，因此大多数企业宁愿用木腿度过难关，也不愿拥抱未知。

而关于PWA，这些并不代表完全使用Windows UI系统

很公平，我同意。 我对 PWA 的主要观点是证明它的市场份额使任何单个特定市场相形见绌，因为​​它是所有市场的总和。

也就是说，我想我这里的部分混乱是命名空间来反映Microsoft.* ，实际上听起来它仍然应该是Windows.* （甚至Microsoft.Windows.* ） .

已经有针对 PWA 和跨平台的解决方案——我们不需要另一个解决方案。

不幸的是，.NET 开发并非如此，这是围绕此公告和后续讨论的混乱和跨平台焦虑的一部分。

因此，最大限度地扩大市场覆盖范围和应用程序开发人员的潜在收入，同时降低构建应用程序所需的成本。

有时性能和用户体验细节会产生很大的不同。 Skype 以牺牲性能为代价使用 Electron 框架最大化了市场范围，结果是商业灾难。

关于跨平台 (xplat) 解决方案。
Xplat 解决方案是对多个原生底层系统的抽象。 我对 WinUI 的理解是它将成为 Windows 的本机系统。

如果 WinUI 也是 xplat，它会如何整合 Windows 独有的东西？ 这不会阻止它做新的和创新的事情吗？ 或者这是否意味着微软也需要将任何新的或区别于 Windows 的东西移植到其他平台上？ 那些因为其他底层操作系统无法支持而无法移植的东西怎么办——它们不应该添加到 Windows 中吗？

如果您使用本机 Windows 技术构建某些东西，那么可以合理地假设 Microsoft 将在一段时间内支持它，并在未来提供一条通往更新的基于 Windows 的系统的途径。 （承认 SilverLight 是一个例外。）我认为假设如果您使用本机 Windows 技术构建某些东西然后想要在竞争的操作系统上运行它那么由 Microsoft/Windows 来简化这件事是不合理的。 如果您使用 Swift 为 iPad 构建了一个应用程序，并希望将其引入 Windows 桌面，您是否希望 Apple 改变 iOS 开发以使其变得简单？

如果您喜欢或喜欢使用本机 Windows 技术，那就太好了。 您不能做的是将您在选择这些技术时做出的业务决策推迟给其他人。 所有技术选择都会产生后果，没有人知道未来几年可能需要什么，或者您的客户可能会要求什么。 要求专门为 Windows 开发的软件也能够在其他地方运行，可能会给人一种印象，即其目的是避免做出可能在未来任何时候产生负面影响的技术决策。 基于技术的本质和变化的速度，我觉得这不太现实。

也就是说，如果您想构建一个 xplat 解决方案（并且有很多人这样做并有理由这样做）因为您现在想要针对多个操作系统，或者将来可能想要，那么这是一个合理且可以理解的设想。
为此，微软有 Xamarin。 或者，如果您更喜欢使用 XAML 更像 UWP 的东西，那就是 Uno。 （还有很多其他选择。）
如果像我一样，你想看到 Xamarin 对构建 Windows 应用程序有更好的本机支持，我认为让 WinUI 尝试做多种事情不是答案。

WinUI 不仅仅是 XAML 和特定控件。 它包括有关这些控件和使用它们构建的应用程序如何与底层操作系统集成的详细信息。
如果 WinUI 计划的重点是使 Windows 上的 Windows 开发成为最好的，那么这就是拥有创新和良好未来支持的一个很好的例子。 它还可能增加人们希望继续使用 Windows 的机会，因此它获得多个 xplat 解决方案的坚实支持变得很重要。

关于跨平台 (xplat) 解决方案。
Xplat 解决方案是对多个原生底层系统的抽象。 我对 WinUI 的理解是它将成为 Windows 的本机系统。

对不起，但我没有那种感觉......

看看 Flutter……它有一个核心引擎，可以在它支持的任何平台上渲染任何东西。

最重要的是，它具有使用引擎管理层在 Dart 上完全实现的组件，并以像素保真度表示（绘制/渲染）您想要使用的平台和设计语言，例如 Material.io 和 Apple 的 Cupertino。

所以，恕我直言，这将是制作跨平台产品的最佳方法，同时代表底层平台功能。

我认为假设如果您使用本机 Windows 技术构建某些东西然后想在竞争的操作系统上运行它然后由 Microsoft/Windows 来简化这件事是不合理的

是的...我认为其他人在这里提出的观点是，这些天这似乎有点落后/聋哑，尤其是在启动新应用程序的情况下。 当 Windows 应用程序只占市场的一小部分时，为什么有人要构建原生 Windows 应用程序？ 这不是善用资本。

如果是为了维护旧的 Windows 应用程序或专门制作一个 Windows 应用程序，那么是的，我同意所有这些，这是有道理的。 然而，由于似乎发生了重大变化并涉及进一步投资，因此与使用 Flutter 相比，这样做的价值主张尚未得到解释。

这正是我要说的...

例如，Win10（WPF 和 UWP）以及 OSX 上桌面的 Flutter 嵌入器即将推出。

它们 100% 由 flutter 运行时管理，但它们仅使用（例如）WPF/UWP 来获取窗口管理和Graphics指针。 其余的都由引擎管理......

我们已经将 Flutter 引擎自己移植到嵌入式 ARM 设备上，我不得不说这是一次很棒的体验。 为什么？ 因为它天生是可移植的，并且通过让“嵌入器”处理平台特定的基元（如 GPU、软件渲染、输入管理等）的实现细节，可以在任何地方运行......

这就是为什么我说通过WinUI获得的UWP: The empire strikes back不会长期有效。

MSFT 必须具有跨平台、开放和可移植的功能。 就像他们对 .Net Core、Blazor 等所做的那样......重新发明 UWP/XAML 不会去任何地方。

我相信 XAML 如果在用于“描述”（或像某些人所说的那样声明）UI 的意义上正确使用，则具有很好的潜力。 “引擎”从中构建渲染树，然后将渲染命令分派到底层平台。

就像 MSFT 最近将 Chromium 作为 Edge 的核心所做的那样，我相信 WinUI（或它变成的任何名称）可以利用 Skia，因为它具有 GL、DX、Vulkan、软件渲染、FB 等的后端......刚开始你有很大的潜力在以后添加其他平台......

@加尔维斯贝罗，

看看 Flutter……它有一个核心引擎，可以在它支持的任何平台上渲染任何东西。

最重要的是，它具有使用引擎管理层在 Dart 上完全实现的组件，并以像素保真度表示（绘制/渲染）您想要使用的平台和设计语言，例如 Material.io 和 Apple 的 Cupertino。

太好了，一旦 Apple 发布 macOS 更新，并且 UI 更新（可能按钮圆角半径更改，或背景渐变更改等），您的 Flutter 应用程序就不会更新并继续看起来像以前的操作系统 - 与本机不同控制这将免费获得好处。

@MarkIngramUK这是团队支持更新的工作。

就像 Xamarin 团队从 0+1 天开始提供更新一样，这个团队也可以这样做。 谷歌团队也这样做了......

通过使用“本机”控件，您将再次回到 Xamarin 世界，如果您只是这样做，包装器（又名渲染）...

我们不是在讨论 C# 与本机控件的绑定（就像 Xamarin 所做的那样）......我们正在谈论一个完整的 UI 框架，就像你在 Flutter 中所做的那样......

作为记录，没有人为任何平台使用“默认”主题。 他们都在每个平台的设计语言之上创建了自己独特的用户体验。

如果您如此担心总是看起来像本机组件，那么您的应用程序可能永远不会像它们看起来那样拥有良好的受众......嗯......

我相信我们在这里谈论的是两个不同的项目。 WinUI 需要成为 Win32 的替代品。 人们要求一个跨平台的解决方案，这是合理的，但我认为不应该是这个项目。

此外，Flutter 允许您在所有平台上使用“主题”。 因此，您可以在 Win10 PC 上运行 Cupertino。 一个重要的例子是材料设计。 它是一种设计语言，而不是一组控件。 它可以在任何地方使用......碰巧某些平台（如Android）具有实现它的本机控件......

@MarkIngramUK

我只是在澄清为什么 WinUI 不应该只是 Win32 的替代品，仅此而已。

如果是这样，那么我很确定它会在可预见的未来像 UWP 一样下降......

我同意@MarkIngramUK WinUI 本身应该专注于为 Windows 提供统一的 UI，无论您是否使用 C#、WinRT API、Win32 ABI、C++、F#、VB、.NET Core。

WinUI 3.0 涉及将 XAML 的所有代码和呈现从 Windows 操作系统中提取出来，并使其成为一个独立于操作系统更新周期的框架，并使其开源。

它如何被提升和重新包装仍然悬而未决。 只有微软内部的人才知道他们将如何做到这一点。 为了支持未来对 XAML 的跨平台支持，我只希望对将来如何实现它进行一些思考，因为他们正在从 Windows 中解脱出来。

.NET Core 已经在其他平台上可用。 所以这就是已经可以转移的 C# 代码。 它现在只是 XAML 和 UI 和控件，它们需要一条通往 iOS/macOS/Android/Linux（以及未来可能出现的任何东西）的路径

可能超出 WinUI 3.0 的范围，但绝对与此项目和工作有关。

@jesbis @terrajobst @jevansaks

Microsoft 计划将 UI 框架引入 .NET Core 以在桌面、移动设备（Droid、iOS）和 Web 上呈现什么？
关于这一点的不确定性已经持续了很长时间。

@weitzhandler ，他们已经有了一个路线图，有以下段落：

用于 Web 和跨平台框​​架的本机 Windows 目标
WinUI 3 针对库和框架进行了更好的优化，
例如，我们计划将新的高性能 C++ React Native Windows 实现基于 WinUI 3。

注意强调的部分，“建立在”。 正如我在上面所说的那样，没有理由不能首先使用 Windows，其他库构建在它之上。

好吧...

/me keep working on FluSharp

这是合理的，但我认为不应该是这个项目。

外面很渴@MarkIngramUK ，请原谅我们的预测。 😅

与以下段落

不多说。 它没有揭示 MS 制作 C# 和 .NET 开发 xplat 的明确意图。 如果你想便携，可能会说 HTML JS 和 CSS shi{ 比 C# 更适合你。

目前，Xamarin 和 Xamarin Forms 是微软在 Windows 之外进行 C# 和 .NET Core 开发的故事。

React Native for Windows 即将用于 Javascript 代码和 Native UI（将使用 WinUI 3.0 XAML）

目前微软还没有宣布将 WinUI 3.0 的 XAML 引入其他平台的计划。

WinUI 该项目试图在一个现代 XAML 呈现框架下统一 Win32、WPF、MFC、UWP、.NET Core 开发框架。

我认为在那之后，应该努力寻找呈现为 WinUI 3.0 编写的 XAML 的方法 - 在 macOS、iOS、Android 等平台上 - 但这目前还没有列入议程。

一旦 WinUI 3.0 在这里开始工作，它将是开源的，如果有足够的需求，这将使未来的跨平台工作成为可能。 最终使这些跨平台路径可用的可能不是微软，而是开源社区。

有没有计划让 F#，.NET 的红发继子成为一等公民？ 然后人们想知道为什么绝大多数 .NET 开发人员不会用 10 英尺长的杆子接触 F#。

目前，Xamarin 和 Xamarin Forms 是微软在 Windows 之外进行 C# 和 .NET Core 开发的故事。

是的，Xamarin.Forms 正在被移植到 macOS、GTK、UWP 和 WPF，并且在工作中到处都有材料设计，这使它成为事实上的 .NET UI 框架，但它是如此缓慢和错误，我想知道微软在想什么关于它的开发人员。 看看问题清单就知道了！ 一旦开始认真的开发，错误就会被左右击中。 我希望在 WinUI 中我们最终可以有更好的开发体验。

回复：F#

如果您认为其他新功能（如更好的 F# 支持或新标记功能）很重要，那么请打开一个新功能请求，以便我们可以单独跟踪它们！

是的，F# 总是被单独跟踪并再次被忽略。 看看 UWP 和 .NET Native - 两者都没有考虑 F#，整个社区都必须弄清楚一切。 🙄 4 年后，.NET Native 仍然不支持 F#。

对于F#建议/问题，我创建了一个专门的问题：
https://github.com/microsoft/microsoft-ui-xaml/issues/740

请随时直接在那里进行 F# 讨论。

我们绝对不会忽视关于它的反馈——有一个专门的问题只是帮助我们组织和跟踪它。
该团队正在讨论如何将其纳入 3.0 及更高版本的路线图，并将根据任何进展更新新问题。

RE：跨平台用户界面：

感谢大家到目前为止提出的观点，以及对 .NET 和 Xaml 的热情。
我只想再说一遍，我们正在密切倾听所有反馈，随着我们的进步，我们将分享我们的想法和更新。

只是重申当前的路线图和提出的一些要点：

WinUI 是 Windows 的本机 UI 平台（包括本机应用程序，而不仅仅是 .NET），对于最初的 3.0 版本，我们主要专注于使其独立于操作系统，并努力使其为更快发布的开源开发做好准备循环。 我们希望确保该范围足够可行，以便我们在今年进行预览。

我们目前的其他短期目标之一是使 WinUI 能够作为其他平台在 Windows 上使用的本机目标：例如，我们也在努力确保react-native-windows - 一种高性能的 C++ React Native 实现对于 Windows -使用 WinUI ，并且 WinUI 控件可用于在 React Native 应用程序中创建本机 UI 视图。

我会非常诚实。 我有一个我在 2006 年在 WinForms 上编写的本机 Windows 桌面应用程序，我今天仍在网上销售。

我不打算将此应用程序迁移到 WPF、UWP 或使用任何专有的 Windows UI 技术。 我不在乎 Windows 演示看起来多么引人注目。 如果我决定再次开发这个应用程序，下一个主要版本将是某种可以在 MacOS、Linux 和 Windows 上运行的跨平台实现。

目前，这可能看起来像 Blazor + .NET Core + Electron。

我认为@Mike-EEE 提出了一些很好的观点。 使我能够利用我的 C# 技能来接触最多受众的 UX/平台是我更可能选择的技术。

微软应该专注于授权开发人员利用他们现有的技能来通过他们的应用程序覆盖更多的受众。 我认为这是一个成功的策略，并将让微软保持在游戏中。

墙上的文字是操作系统软件正变得更像是一种商品。 也就是说，人们可以选择他们想要的任何操作系统并获得他们想要使用的应用程序。 我认为随着时间的推移，随着世界软件供应商继续关注跨平台，这一点将变得更加明显。

在经济学中，商品是具有完全或实质性可替代性的经济商品或服务：也就是说，市场将商品的实例视为等价或几乎等价，而不管是谁生产的。 https://en.wikipedia.org/wiki/Commodity

微软必须做出决定，它是否想成为开发工具故事的一部分？ 或者，微软是否投资了数百万美元到一个新的仅适用于 Windows 的 UX 堆栈中，它最终会加入越来越少人使用的 UX 堆栈的墓地？

这个项目由一个团队拥有，该团队对 Windows 内部的工作方式有丰富的知识，如果他们离开并弄清楚如何使某些东西在 Mac 或 Linux 上也能在相同程度上真正运行良好，这会分散他们的注意力。

这是一个很难确定的位置。 但时代变了。 今天的世界与 1995 年的世界大不相同。在我看来，有几个选择：

你可以雇佣更多的人来扩展 Windows 以外的知识。

或者，利用该团队的知识在 Windows 内构建 UX 管道，增强跨平台 UI 应用程序框架的兼容性，以便在 Windows 上更好地运行。

就像 WSL 在 Windows 上运行 Linux 所做的那样。

• 利用团队的知识使 GTK 运行速度提高 200 倍。
• 利用团队的知识使 QT 应用程序的运行速度提高 200 倍。
• 利用团队的知识使 Electron 应用程序的渲染速度比任何其他操作系统都快。

有很多工作可以做来增强 Windows 跨平台 UX 兼容性故事。 但是投资一个全新的 UX 堆栈并希望我们都切换（没有任何跨平台故事）是一个相当大的赌注。 你必须打破这种习惯，只为 Windows 创建新的 UX 框架。

只有我的两分钱。 ：钱袋子：

:horse_racing: :cowboy_hat_face: Lil Nas X - Old Town Road (Official Movie) ft. Billy Ray Cyrus

@bchavez

你必须打破这种习惯，只为 Windows 创建新的 UX 框架。

- 不仅。 甚至打破 Windows 自身内部 XAML 可移植性的习惯。 WPF、Siliverlight、UWP 都在他们自己的分支上......这种事情正在推动越来越多的人远离我个人希望在未来继续使用的 Windows 开发工具。 来自 Windows 开发工具的更多反击意味着 C# 的相关性越来越少，对我来说，当我开始研究它时，我关心的是什么。

RE：跨平台用户界面：

... WinUI 是 Windows 的本机 UI 平台（_包括本机应用程序_，不仅仅是 .NET），对于最初的 3.0 版本，我们主要专注于使其独立于操作系统并努力使其为开源做好准备以更快的发布周期进行开发。 我们希望确保该范围足够可行，以便我们在今年进行预览。

添加 +1 以更新与 WinUI 3.0 一起运行的 WinForms、MFC、WPF 控件的视觉外观，以更好地匹配 Fluent/FabricWeb 控件样式。

肯定有不同的控件大小（任何不是 WinRT XAML 的东西都应该将它们的指标与 UWP 控件的 Compact 版本相匹配），但具有连贯一致的抛光外观。

将 WinUI 3.0 依赖项添加到 WinForms 中并更改控件。

WinUI 3.0 WPF 应用程序检测并使用 Fluent.Light.xaml 或 Fluent.Dark.xaml 控件主题。

@weitzhandler我理解你的心情。 我希望永远不必接触 javaScript 和类似的东西来做这个跨平台的 GUI。 我什至不喜欢考虑使用电子、角度、飞镖、颤振来开始一个项目。
我希望我们能很快在 .NET 5 中找到一个解决方案，这将带来 Universal XAML 的梦想。 Microsoft XAML 可以胜出、Web、移动、桌面和物联网。
对于许多用例，Silverlight 几乎做到了。

你必须打破这种习惯，只为 Windows 创建新的 UX 框架。

如果我们必须等待（在所有平台上不可避免地受到损害）跨平台支持，WinUI 3.0 将永远不会发布。 WinUI 应该是 Windows 上最底层的 UI 框架，如果你想要跨平台能力，就在它之上构建（或者使用 React Native、Xamarin 等）。

你必须打破这种习惯，只为 Windows 创建新的 UX 框架。

我想澄清一下，我们并不是要尝试使用 WinUI 3.0 创建新的 UI 框架。

我们最初的目标是：

• 通过将现有的现代本机技术（Windows 10 Xaml UI 和合成器）与操作系统解耦并使它们能够跨现有应用程序模型（win32 和 UWP）、语言、其他框架（通过孤岛）和 Windows 版本工作，消除使用现有现代本机技术（Windows 10 Xaml UI 和合成器）的障碍

• 将我们的工程流程更新为开源

如果我们必须等待（在所有平台上不可避免地受到损害）跨平台支持，WinUI 3.0 将永远不会发布。

伙计......如果你真的相信这一点，你的意思是像 Flutter 这样成功的框架不起作用......

我也不喜欢 Dart，但他们确实发布了一个漂亮的下降产品，它正在发展并且非常快速地获得牵引力。

我很沮丧 WinUI 将只成为 Windows 的东西......

.Net 需要一个 UI 框架来匹配 .Net Core 跨平台功能的强大功能，就像我们刚刚通过 Blazor（客户端和服务器端）获得的 Web 一样。

我认为目前，我们仍然需要依靠社区驱动的努力。

我了解你的团队正在尝试做什么@jesbis ...只是我们中的许多人厌倦了在 .Net/C++/UWP/MFC/Windows 上看到 UI 是一个 _silo_ed 的东西，它只能在 Windows 上运行，而全世界（除 Apple 和 OSX 之外的其他公司）正以相反的方式为开发人员提供越来越好的跨平台解决方案。 就像你提到的 React 和 Rect-Native（为了记录我也不喜欢，只是提到它们正在发展）。

所以我们现在所拥有的只是社区驱动的计划，如 Avalonia 甚至 Uno 和其他框架（如我提到的 FluSharp），由于显而易见的原因，它们发展非常缓慢......

我的建议是，与其将 XAML 和合成器从 Windows 代码库中提取出来并使其成为仅限 Windows 的版本，不如获取它并进行适当的抽象，以便它可以在多个平台上工作。 就像我们使用 .Net Core 一样，它最初仅适用于 Windows，但社区驱动的努力使其在 Linux、OSX 甚至 ARM 设备上运行得非常快......

（在所有平台上不可避免地受到影响）跨平台支持

我真的不认为这会是一个问题，因为跨平台设计一直是 UWP 的 XAML UI 和流畅设计的一个关键方面。 肯定有一些控件在 Windows 版本之间的视觉设计不同 - 这是无缝处理的，您可以获得与设备操作系统匹配的本机 UI。

例如，控件中内置的 Acrylic 和 Reveal、Pivo​​ts 和 NavigationViews 上的强调色 - 这些东西不会出现在 Creator's Update 中，但会出现在 FCU 和更新版本中。 需要零更改。

显然，在完全不同的操作系统上渲染 UI 的幕后复杂性要高得多，但就实际设计 UI 而言，我认为不需要考虑任何新的考虑因素。使用 UWP 和 WinUI。

我认为最大的担忧是真正的长期计划是什么。 根据@jesbis 的回复，他们现在似乎只关注短期，长期计划仍在讨论中。

这是可以理解的，这样一个项目的范围是巨大的。 如果不是短期计划，而是最终计划，我完全可以理解。 透明度在这里很重要，很明显没有人愿意支持一个没有明确未来的平台。

很明显，微软作为一个整体专注于跨平台——我们在 Fluent Design（现在有 iOS、Android 和 Web 的示例）中看到了这一点，在其他平台上有大量的微软制造的应用程序——所以共享 UI 是真的只是一个很大的缺失环节。 这就是为什么没有看到它发生会如此令人失望 - 我认为很多人喜欢 MS 制造的通用应用程序平台的想法，但如果我们没有它的完整解决方案。

关键是...与 material.io 和 Cupertino 一样，我们可以（如果 Google 还没有这样做，我并不感到惊讶！）在 Flutter 上使用流利的设计语言的“主题”...

这就是我的观点，当我说一个真正的跨平台 UI 框架不会关心这一点并且会像 Flutter 那样工作时......我看不出我们在这方面有什么妥协......

@weitzhandler我也不喜欢本机应用程序的 HTML。 否则我会在 React 中使用 Electron 😄

我只是在这里没有激情，而只是理性。

我真的很期待 WinUI 3.0，我会立即将它用于新的 C++/WinRT Windows 桌面项目。 我希望 3.0 之后的下一个主要版本将引入一个可移植的运行时来托管 WinUI 应用程序（如 Flutter 运行时）。 对于大量 LOB 应用程序和类似 Photoshop 的应用程序，每个平台上的 GUI 可以相同，但关键是性能和源代码重用。 而且我还认为 xlang 项目是一个好主意，并有望在未来带来一些好消息。

我建议这里的用户在 BUILD 2019 之后花点时间听 Scott Hunter 关于 Win UI、Xamarin Form、UNO 和 Web Assembly 如何结合在一起的演讲。

.NET Core 3 及更高版本与 Scott Hunter @.NET Rock

Xamarin Forms (XAML) 和 UNO (XAML) 都是为了跨平台而创建的。 在 UNO 的情况下（除了 iOS、Android、XAML for Web 通过 Web Assembly）。

UWP 是在没有超越 Microsoft 生态系统（例如 Web、Android、iOS）的情况下创建的。 由于 UWP 的采用缓慢，所有令人印象深刻的 Fluent 设计工作几乎没有被占用

正如@Mike-EE 指出的那样，droid 和 iOS 有 2~ 和 1.5~ 十亿，而 Win10 有 9 亿。 其中大多数开发人员仍然不愿意从 WinForm 和 WPF 跳到 UWP。

为什么？ 该UWP控制，从商业和微软，是不完整的!!!!! 与 WinForm 和 WPF 中的那些相比。 微软没有努力帮助这种转变。 XAML岛不会解决这个问题只要微软有盲点的什么失踪的WinForm和WPF开发人员需要过渡到UWP。

由于缺少这些 UWP 控件，现在正在投入大量精力将 Win UI 引入 React Native for Web。 ？？？？？？ 我们需要这些缺失的 UWP 的 Win UI 控件，以便我们可以游说从 WinForm 和 WPF 过渡到 UWP 。

一种这样的控制是图表控制。 所有数据密集型业务应用程序都需要 UWP 的图表控制。

==> 我理解解耦 UWP UI 的必要性。 这只有将 Fluent Design 品牌推广到其他平台（例如 iOS、Android、Web）才有意义。
==> 请专注于提供更好的 3D 模型控制和图表控制（2D/3D）

只有当 ALL BCL from（mono 与 Windows 的原生合并，用于 Web Assembly 等）时，停留并等待 NET5 才有意义，因为我看到了 HOLOLENS 创意 3D UI 的未来。

为此，我们需要用于 UWP 和3D 模型控件的2d/3D 图表控件，它们不仅应该显示模型，还应允许开发人员访问骨架/顶点动画。

@jesbis我敦促您将更多人投入到 UWP 的 Win UI 的这些 USP（独特卖点）中。

@weitzhandler

创建此问题是为了讨论WinUI 3.0 路线图。

@jesbis发表了澄清声明：

WinUI 是 Windows 的本机 UI 平台（包括本机应用程序，而不仅仅是 .NET），对于最初的 3.0 版本，我们主要专注于使其独立于操作系统，并努力使其为更快发布的开源开发做好准备循环。 我们希望确保该范围足够可行，以便我们在今年进行预览。

你的前两条评论是切中要害的。

以下六个是非生产性和贬义的组合，您几乎违反了Microsoft 开放源代码行为准则。

这应该仍然是与 Microsoft 的富有成效的专业对话。

// 我不是为了整天听某个人发泄而关注这次谈话。

我认为这里有一些很棒的评论，尽管似乎可能有两个单独的讨论。 我会保持简短，因为之前已经说过大部分内容。

跨平台和网络

.NET Core 很棒。 我们最终可以使用出色的工具和出色的语言来定位每个平台和接触点。
唯一缺少的是除了 Blazor 之外的 UI 堆栈（尽管 HTML / CSS 很糟糕）。 为了获得最大的可比性，最好有一个框架允许桌面开发人员使用相同的技能、工具和语言（Xaml 和 C#）迁移到 Web 及其他平台。 Tbh，Silverlight 在那里做了一件很棒的事情——它刚刚奏效）。 我不确定 WinUI 是否需要成为那个框架，但请在内部提出这个问题。 Flutter 基本上适用于 .NET 开发人员，并且以 Web 为目标将是最大的优势。

不确定 Xamarin 是否可以成为该平台，但如果是，请确保 Xaml 在 WinUI 和 Xamarin 之间尽可能保持一致。

用户界面

这需要发生。 应该有一个通用的 Xaml 堆栈来在 Windows 平台上创建可能的最佳体验。 理想情况下，应该填补 WPF 在控件和功能方面的缺失。

HoloLens 及其他

随着 Lite 的出现，以及新的超级激动人心的外形因素，例如 HoloLens，人们可能会争辩说 UWP 在 UI 方面还没有准备好。 是的，我们可以在 HoloLens 上运行它们，这很好，但我想看到一种方法来真正优化 3D 应用程序，而无需使用完整的 Unity。

WinUI 远远领先于 Xamarin。 但微软团队只是推出了 Xamarin 4.0...
我个人更喜欢 Xamarin，因为它是跨平台的最低面额，未来 SaaS 的本机应用程序数量会增加。

除了 Xamarin，还有一些替代方案。
1) 为什么不拥抱 UNO 平台并使用 SkiaSharp 进行 Web 渲染？
2) @zezba9000你需要一个像游戏引擎一样的不可知渲染后端。 其实我也挺认同的......

也许微软更推WinUI，因为与其他跨平台解决方案不同，里面有非开源代码跟踪：Xamarin，UNO，可能有UNIX库......

不管怎样，愿原力与你同在。
PS：Github 赞助商来自微软，所以请赞助一些著名的 Mac/Linux 开发人员为 WPF/Winforms 的跨平台分支。

@jkoritzinsky ，WinUI 团队应该注意 WinUI 3.0 重命名的一件事：如果您重命名在 .NET 中投影的任何类型，那么投影将不起作用（我们不打算添加更多因为它不是一个可维护的可扩展系统）。 这是我们项目的类型列表： https :

对与这些类型不同的类型的任何更改都需要用户将他们的对象包装在实现新接口的新对象中，或者将他们的数据复制到新类型中。 特别是， INotifyPropertyChanged和INotifyCollectionChanged类型对 XAML 岛和提供下游支持很感兴趣。

我同意并且很高兴你提出这个问题，尽管我想补充一点，我认为这些预测有点不幸。 我们没有计划可能应该是的每个 API（考虑 System.IO API），所以我们应该要么解决这个问题，要么换个方式思考。 想到的一件事是不要向不同命名空间中的 .NET 类型添加相似但不同的类型。 相反，我们应该让我们的 C++ 开发人员也可以使用 System.ComponentModel.INotifyDataErrorInfo。 这是我们使用 C++/CLI 所做的，但这不需要为纯 C++ 应用程序加载 CLR。 我不知道这是否会更令人困惑，但感觉就像我们在 API 层泄露了 .NET 和 WinRT 技术的基本和底层差异，这让事情变得不连贯。

@meir-pletinsky。 NET 只是一种可用于使用 UWP XAML 制作应用程序的框架。 他们希望开发人员可以使用文本字段验证，无论他们使用什么框架

这在金钱上是正确的，我们确实有我们关心的 C++ 开发人员。 尽管就像我上面提到的那样，我希望我们不要为了实现这一点而在 .NET 社区中造成混乱。

@mdtauk不，WinUI 桌面（以前称为 Xaml 桌面）允许您直接在 Win32 中使用 Xaml，而无需使用岛。

我认为@meir-pletinsky 指的是 .NET/C++，除非我遗漏了什么？

@MarkIngramUK我相信我们在这里谈论的是两个不同的项目。 WinUI 需要成为 Win32 的替代品。 人们要求一个跨平台的解决方案，这是合理的，但我认为它不应该是_this_ 项目。

是的，我完全同意！ 对我来说，WinUI 是关于为 Windows 定义最现代、最高效的、最好的 UI。 Xamarin 应该是来自 Microsoft 的跨平台故事，并且应该发展到 WinUI 之上。

@mdtauk

添加 +1 以更新与 WinUI 3.0 一起运行的 WinForms、MFC、WPF 控件的视觉外观，以更好地匹配 Fluent/FabricWeb 控件样式。

肯定有不同的控件大小（任何不是 WinRT XAML 的东西都应该将它们的指标与 UWP 控件的 Compact 版本相匹配），但具有连贯一致的抛光外观。

将 WinUI 3.0 依赖项添加到 WinForms 中并更改控件。

WinUI 3.0 WPF 应用程序检测并使用 Fluent.Light.xaml 或 Fluent.Dark.xaml 控件主题。

我真的不想看到微软在这些框架上投入时间和资源，让它们看起来像原生的 Windows 10 应用程序。 这就是为什么会有 WinUI 3.0。 您想要 WPF/WinForms 应用程序中的 Windows 10 外观吗？ 使用 WinUI 3.0。
MS 应该更倾向于将他们的资源投入到缩小 UWP/WinUI 和他们的 Win32 对应物之间的现有（和阻止）差距上，而不是重新访问他们的旧框架。 特别是考虑到 WinUI 旨在成为 Windows 的 _the_ 演示框架......

我想澄清一下 WinUI 和微软在 UI/UX 上的意图：

1. WinUI 是否会替换以下所有内容（假设？）：Win32、ATL、MFC、WinForms、Silverlight（我知道）、WPF、UWP 和/或 XAML 岛？ 我认识到这些技术将继续存在，并且将继续无限期地得到支持； 我只是想清楚地了解，这就是微软所说的“前进的道路”，并且（例如）我们应该像考虑 Win32 或 MFC 一样考虑 WinForms 和 WPF。

2. WinUI 是否源自 UWP？ （或者，两者的相似程度如何？）与 UWP、XAML 岛或 WPF 相比，WinUI 的相似（或不同）程度如何？

作为一名专业的 C# 和 C++ 开发人员，我开始使用 WinForms，然后转向 WPF，然后又回到 WinForms，因为我可以在 WinForms 中为商业目的设计 UI/UX，速度大约是在 WPF 中的两倍。 WPF 提供了更多的灵活性、性能和更好的外观——但是一旦有人通过设计器触摸界面而不是手动编辑 XAML，就会发生 XAML 修改，这很糟糕。 在某些情况下，我认为 WinForms（使用设计器）比手动构建类似的 XAML 表单或控件快几个数量级。

就我个人而言，我希望有一个在 Microsoft 的产品中可用且完全相同的 UI。 一个可以由 Win32 或 .NET 以类似方式利用的框架意味着所有 Microsoft 开发人员都可以使用一致的、外观现代的应用程序，并且还意味着可以在针对单一技术的会话中解决常见问题和问题——例如，在询问有关控件的问题时，对于 Win32 开发人员或 .NET 开发人员来说，答案将是相同的（如果不是几乎相同的话）。 这将使学习“WinUI”对任何给定开发人员的任一堆栈都有用，并且无论您在何处开发，都将使在线访问信息（StackOverflow 等）更有价值。 虽然我不使用 Xamarin，但如果 Xamarin 也能跟上这些脚步（作为 WinUI 的扩展？），那么上面的说法不仅适用于 Windows 开发者，也适用于面向 Android、iOS 等的开发者。

将 WinUI 用于哪些类型的应用程序我会很兴奋？

如果我对 WinUI 的理解是正确的，它是“前进的方向”，替换 Win32、MFC、Forms、WPF 等，并且相同的框架可用于本机或 .NET 开发，那么我将热切地替换组合在我支持的所有_ 应用程序中。 现代、一致的用户界面，无论平台或堆栈如何工作（和行为）都相同？ 这不是我们都想要的吗？ 我认为没有人想记住如何在 WinForms 或 WPF 中以完全独立的方式处理事件的同时，如何同时使用 CreateWindowEx() 和运行消息循环来调度 Win32 中的事件。 是时候来点“现代”了。 我真的希望这就是 WinUI (3.0)。

操作系统兼容性和下层支持

我认为 WinUI 专注于将组合与操作系统分离是很棒的，但是有大量客户甚至还没有使用 Windows 10。 我知道这是一个痛点，我们都希望我们的目标受众运行最新版本，但这是我们所有人每天都面临的真正问题。 关于让 WinUI 可用于 1703 之后的旧平台（我认为这是当前目标最老的平台）的讨论有哪些？

使 WinUI 可静态链接或可嵌入（如 .NET Core/5）是一种选择吗？ 我们将不得不以 Windows 8.1、Windows 8、Windows 7 甚至 Windows PE 为目标。 我们如何使用具有这些要求的 WinUI？

@希德尔：

WinUI 是否源自 UWP？ （或者，两者的相似程度如何？）与 UWP、XAML 岛或 WPF 相比，WinUI 的相似（或不同）程度如何？

从某种意义上说，WinUI 3.0 将是 Windows 10/UWP 的 UI 平台组件的下一个版本，包括 Xaml 平台、组合和输入。 它来自那个代码库。

除了路线图中提到的内容之外，它应该与 Windows 10/UWP Xaml 平台 API 非常相似：即不同的根命名空间，更好地支持与其他技术的混合和匹配（例如使用 win32 应用程序模型而不是 UWP），以及一些新的附加功能。

WinUI 是否会替换以下所有内容（假设？）：Win32、ATL、MFC、WinForms、Silverlight（我知道）、WPF、UWP 和/或 XAML 岛？ 我认识到这些技术将继续存在，并且将继续无限期地得到支持； 我只是想清楚地了解，这就是微软所说的“前进的道路”，并且（例如）我们应该像考虑 Win32 或 MFC 一样考虑 WinForms 和 WPF。

WinUI 是我们主要针对 Windows 上的本机应用程序 UI 进行的主要积极开发和进展。 这也是 Windows 本身和本机 Microsoft 应用程序和设备所使用的。

Xaml 岛将成为 WinUI 的一部分，并使您能够使用 WinUI 在现有应用程序（例如 WPF、WinForms）中创建新视图。

关于让 WinUI 可用于 1703 之后的旧平台（我认为这是当前目标最老的平台）的讨论有哪些？
使 WinUI 可静态链接或可嵌入（如 .NET Core/5）是一种选择吗？ 我们将不得不以 Windows 8.1、Windows 8、Windows 7 甚至 Windows PE 为目标。 我们如何使用具有这些要求的 WinUI？

感谢您分享这方面的反馈。 对于 3.0，我们专注于路线图中的平台（1703+，对 8.1 有一些支持）。 我们绝对理解开发人员也有其他版本的客户，这是我们计划在未来进行评估的内容。

太棒了——听起来 WinUI 是“前进的方向”，鉴于对它的这种理解，说我很兴奋是轻描淡写。

特别是，我认为 XAML Islands 将允许开发人员将 WinUI 扩展到旧技术（如 WPF 和 WinForms）中，这真是太棒了。 在处理/扩展旧的（er）项目时，这是一个很好的“前进”桥梁。

太棒了——听起来 WinUI 是“前进的方向”，鉴于对它的这种理解，说我很兴奋是轻描淡写。

特别是，我认为 XAML Islands 将允许开发人员将 WinUI 扩展到旧技术（如 WPF 和 WinForms）中，这真是太棒了。 在处理/扩展旧的（er）项目时，这是一个很好的“前进”桥梁。

我想考虑是否创建了包含 WinUI 3.0 的 WinForms、MFC 或 WPF 项目——它们可以只呈现 XAML 页面/内容/窗口，而不必在 Form/WPF 窗口/HWND 窗口中使用 XAML 岛。

仅使用纯 XAML 或使用孤岛将 XAML 放入框架提供的表面的能力 - 将真正使 WinUI 3.0 成为“统一的 UI 来统治它们”

将真正使 WinUI 3.0 成为“统治所有人的一个 UI”

...在 Windows 上。 😉

从某种意义上说，WinUI 3.0 将是 Windows 10/UWP 的 UI 平台组件的下一个版本，包括 Xaml 平台、组合和输入。 它来自那个代码库。

关于这一点， @jesbis ，我想知道您是否可以谈谈 WPF 和 UWP 之间的集成方式。 特别是，我们多年来一直在 UWP 中要求使用诸如标记扩展之类的概念，但收效甚微。

当然，进行了尝试，但尽管花费了整整两年的时间来开发，但仍远未实现 WPF 。

此外，WPF 标记中提供的大量服务仍有待在 UWP 中使用和实现。 这里是否努力确保新的基于 UWP 的 WinUI 3.0 标记与 WPF 完全保真？ 抱歉，如果在某处对此进行了解释，但我还没有解析消息以查看它（并欢迎任何资源来纠正/补充我的理解）。

将真正使 WinUI 3.0 成为“统治所有人的一个 UI”

...在 Windows 上。 😉

至少对于 WinUI 3.0 的发布窗口。 我希望这可能是将 XAML 渲染引入其他平台的过程的开始......

我想知道您是否可以谈谈 WPF 和 UWP 之间的集成将如何进行。 特别是，我们多年来一直在 UWP 中要求使用诸如标记扩展之类的概念，但收效甚微。 [...] 是否努力确保新的基于 UWP 的 WinUI 3.0 标记与 WPF 完全保真？

@Mike-EEE 对 WPF 的完全保真并不是 3.0 的目标。 但是，我们正在跟踪一些工作项目以随着时间的推移缩小差距（例如#741标记扩展改进 - 请务必查看并发表评论是否满足您的需求！）并继续将 WinUI 扩展到 WPF 之外（例如# 686 3D 模型支持）。

如果您希望/需要在 WinUI 中使用 WPF 中的其他特定功能，请随时为它们打开新的功能提案问题，或在最近的“应该在 WinRT XAML 中的 WPF 功能”问题#719 中发表评论。 我们没有无限的资源，但我们肯定会尝试在我们的规划中考虑社区的意见。 一旦一切都是开源的，任何人都有机会帮助贡献功能。

这是令人鼓舞的， @jesbis谢谢你的分享。 我已经更新了 UserVoice 上的相关投票，以将订阅者指向该问题。

我想我最关心的是，如果完全的 WPF 保真度不是一个目标，而在 WPF 中使用 WinUI _is_ 一个目标，那么您将遇到采用 WPF 的摩擦，因为它具有卓越的（和原始的）Xaml 模型。

也就是说，将 WinUI3.0 合并到 WPF 中似乎没有明显的价值主张，就像 Xaml Islands 没有明显的价值主张一样。 归根结底，您似乎试图将回归/劣质/欠发达的 Xaml 模型引入既定的和优越的 Xaml 模型中，这根本没有任何意义。

对于 WinForms、MFC 等中的用例，是的，这种方法对 WinUI3.0 有意义。 但是，使用 WPF，它具有卓越的演示模型和开发人员/设计人员范式，这是 MSFT 或外部供应商的任何其他计划都无法比拟的。

@Mike-EEE 基于Scott Hunter 的谈话，在我看来，这可能是错误的，“一个 BCL 统治他们”的目标比“一个 UI 统治他们”的优先级更高。

通过使用具有 AoC 的通用 BCL 替换 Web 中的 MONO 底层 Xamarin Forms XAML 和 UNO XAML，Web 组件中基于 Xamarin Forms XAML 的应用程序、Web 上的 Uno XAML 都将受益于速度性能。

鉴于来自其他技术（例如 flutter、react 等）的激烈竞争，这种速度性能对于关心自己职业生涯未来的人来说至关重要，因为他们投资于跨平台的 C#。

希望在通往.NET5 = 一个通用 BCL 的旅程中，XAML 标准化在此过程中部分或全部得到关注，但不是 .NET5 的主要目标。

除了 XAML 标准化需求之外，另一个优先事项是通过流畅的设计将 Microsoft 品牌推广到所有平台（移动、桌面和 Web）。 [从技术上讲，通过Win UI 3.0解耦，我们一次又一次地被要求聚焦WinUI 3.0路线图的目的]

最后，在 .NET5 发布时，Win UI 起源的 UWP 有多少实际上在这个 ONE BCL 中发挥了作用，以在 2020 年 11 月发布 .NET5 时将它们全部统治，在我看来，这也不是一个高优先级目标。

从营销的角度来看，不幸的是，没有转化为我们深切关注的技术，微软通过流畅的设计品牌推广无处不在，而且推广这种设计的应用程序。

这就是我如何看待微软由于缺乏移动业务而“赶上市场份额”的长期战略。

这很明显，但我认为 Hololens 2 及以后的版本有更大的潜力。 为此，我们需要确保带有 WinUI 3.0 的 UWP 应用程序带有 3D 图表控件和高级 3D 模型查看器。

抱歉各位，我一直在推动这个，因为我想利用我在最好的技术上的有限时间。 :-)

关于WinUI 3.0过渡期

我建议 Microsoft 直接与 Windows Community Toolkit 维护者合作（其中一些为 MS 工作），以便：

1. 测试以查看在将工具包重新定位到 WinUI 3.0（包括示例应用程序）时是否存在任何不可预见的障碍。
2. 通过 Visual Studio 或“另一个工具”测试自动命名空间重命名，看看它进行得有多顺利。
3. 公开报告该过程的进展情况（博客文章/GitHub 问题/任何你喜欢的）。
4. 提供关于 WinUI 3.0 的复制+粘贴文本块以及项目维护者可以附加到他们的 GitHub/Nuget/其他自述文件的转换，或者至少提供一个包含有关它的简明信息的 URL。 这将有助于让这些项目的任何用户快速了解 WinUI 3.0，并解释他们需要做什么才能完成转换。
5. 概述项目/库维护者可以选择采用的建议转换过程和时间表。

关于最后一项，这应该包括以下建议：

• 创建一个新的主要版本号，指示它将与 WinUI 3.0 应用程序（例如 WCT v6.0）一起使用。
• （？）创建一个分支以包含将支持尚未更新到 WinUI 3.0 的项目的遗留代码。
• 提供一段时间（例如 3/6/12 个月），在此期间将提供对遗留项目的支持（即从主分支合并错误修复等）。 这可能具有特定日期以“同步”跨社区项目/图书馆的支持期。

最后，我觉得如果你需要支持 Windows 10 版本 1507 和 1607 LTSB，确定可以做什么是很重要的。 这些是仅有的 2 个受支持的 W10 版本，并且在发布时 WinUI 3.0 将不兼容。

最初我打算建议使用 Windows 10 计算器测试这个过程，因为它是一个生产质量的开源应用程序。 但是，我随后意识到该应用程序需要在 1507 和 1607 LTSB 上再运行 6-7 年。 显然会有一些围绕支持这些类型的应用程序的争论，尤其是在涉及较小的社区项目时。 如果他们真的需要这种支持，那么应该提供一个明确的长期战略如何这样做。

关于 WinUI 4.0/3.x/vNext

正如此处的评论所示，社区对于 WinUI 的未来版本有很长的愿望清单。 我们应该通过公开记录一些更长期的计划来真正利用这里建立的势头和热情。

由于这些项目中的大多数都超出了 v3.0 的范围，我觉得应该尽早创建一个新问题来开始收集关于 WinUI 4.0/3.x/vNext 的社区反馈。 如果有的话，这将有助于确定 WinUI 团队正在考虑的工作类型，以及超出 WinUI 范围和/或其他 MS 团队的责任的工作。

最后一点的一个例子 - 我真的很想看到这些东西：

• .NET Core 3.0 对 UWP 项目的支持（.NET 团队的责任，据我所知）
• Visual Studio 应用中心完全支持 Windows 应用程序（UWP 和 Win32）（显然不是 WinUI 团队负责的）
• 更具体的 Fluent Design 指南，类似于您在 Material Design 文档中可以找到的内容（同样，独立团队的责任）
• 在内置 W10 应用程序中使用 WinUI 3.0 和 Fluent 设计（单独的团队和其中一些应用程序需要支持 LTSB 版本）

通过识别这些超出范围的项目，我们可以将社区重定向到适当的反馈点，和/或以其他方式解释这些领域的情况。

除此之外，范围内的愿望清单可以开始汇集，社区可以开始展示他们对未来他们最想要从 WinUI 中获得的东西的支持。

如果 F# 对 C# 有同等支持，例如具有与 C# 相同的项目模板，那就太好了。

我希望 WinUI (UWP vNext) 有一个像 WPF 那样合适的Window对象，包括 Top、Left、Width、Height、StartupPosition、IsTopMost、AllowTransparency 和 Show() / ShowDialog() 方法。

（_我不确定这个窗口如何在小屏幕设备上工作（或被允许），比如手机和物联网_）

@TonyHenrique在 1903 年为 UWP 提供了一个新的窗口 API，但它远未完成。

正在重新审视 WinUI 3.0 范围内 XAML 的呈现。

我觉得与 WPF 的渲染相比有所下降的是：

• 文本不使用 ClearType，而是支持灰度抗锯齿；
• 边界笔画等缺乏像素精度；

我可以理解何时 Windows Phone 7 和 Windows Phone 8 必须共享一个渲染系统 - 屏幕技术的类型和渲染速度正在推动更高的性能。 但是随着 WinUI 首先转向桌面和更大的显示器 - 也许是时候将这些品质恢复到 XAML 渲染引擎。

如果像 Hololens 和 Xbox 之类的东西需要特殊考虑，为什么不提供一种性能模式，可以在那些需要渲染的设备上像现在一样在平台级别打开？

f# 模板呢？

除非它在面向 .NET Framework 4.5 或更高版本的标准 Windows 窗体和 WPF 项目模板中开箱即用，否则我们不能采用 WinUI 库。

只需要最新的 Windows 10 版本和/或 UWP 应用程序是采用 Fluent 设计的关键。

我建议 Microsoft 直接与 Windows Community Toolkit 维护者合作（其中一些为 MS 工作）

@kmgallahan
很棒的建议！ 这绝对在计划中。 我们的团队经常与 Windows Community Toolkit 维护者密切合作，这是我们希望用作测试项目的东西之一。

正在重新审视 WinUI 3.0 范围内 XAML 的呈现。

@mdtauk
任何渲染更改都可能超出 3.0 的范围，但请为它打开一个问题，以便我们可以重新审视后续版本的想法。 一个重要的焦点肯定是通用性能，正如您所注意到的，这导致了 Windows 8+ 中的一些渲染变化。 性能模式切换是一个有趣的想法。

f# 模板呢？

@edgarsanchez , @khashroomahdi
看起来我们对 F# 很感兴趣！ 我们很想知道更多关于你为什么想要 F# 的信息：请随时在 F# 问题中评论你为什么想要它以及你会用它做什么：#740

除非它在面向 .NET Framework 4.5 或更高版本的标准 Windows 窗体和 WPF 项目模板中开箱即用，否则我们不能采用 WinUI 库。

@jozefizso
你看过Xaml Islands吗？ 此功能允许您在 WPF 和 Windows 窗体应用程序中使用 WinRT Xaml，以便您可以开始使用现代 Xaml 视图/页面增强它们：
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

我们计划让 WinUI 3.0 包含孤岛并向后兼容 Creators Update 和更新版本，这至少是 Windows 的最后 5 个版本。

Xaml Islands 使用 WinUI 3.0 开发 Creators Update 和更新版本能否满足您的需求？

任何渲染更改都可能超出 3.0 的范围，但请为它打开一个问题，以便我们可以重新审视后续版本的想法。 一个重要的焦点肯定是通用性能，正如您所注意到的，这导致了 Windows 8+ 中的一些渲染变化。 性能模式切换是一个有趣的想法。

完成#768

XAML Islands 需要 Windows 10 版本 1903， Windows Community Toolkit库要求项目为 UWP。 那是不行的。

XAML Islands 需要 Windows 10 版本 1903， Windows Community Toolkit库要求项目为 UWP。 那是不行的。

WinUI 3.0 不会在 Windows 7/8/8.1 上运行 - 但这些操作系统很快就会结束。 您现在仍然可以使用 WPF 和 WinForms。 这是在您的用户迁移到 Windows 10 时使用的

在这种情况下，项目将是适用于 Windows 10 的 UWP，因此支持 WPF/WinForms 毫无意义。 这只是在循环并分散开发人员工具。

@jozefizso更准确地说，UWP 正在改变以使其更像 WPF 和 WinForms，并且 XAML UI 越来越接近 WPF 和 WinForms 平台。

带有现代 XAML UI 的 UWP 应用突破了限制性沙箱，并且能够连接到 WPF 和 WinForms 平台。

我是这样理解的。

XAML 岛需要 Windows 10 版本 1903

在这种情况下，项目将是适用于 Windows 10 的 UWP

在 WinUI 3.0 中，我们计划在 1703 及更高版本（更早）上提供岛屿。

我们还致力于使 WinUI 可用于 Win32 应用程序模型而不是 UWP（非正式地称为“WinUI 桌面”），因此它不一定必须是 UWP 应用程序。

我们还致力于使 WinUI 可用于 Win32 应用程序模型而不是 UWP（非正式地称为“WinUI 桌面”），因此它不一定必须是 UWP 应用程序。

这是我最兴奋的事情。 具有可用 Windows 完整 API 的本机应用程序，无论是 Win32 还是 Windows 运行时，都能够通过 Xaml 拥有高性能 UI。

我们还致力于使 WinUI 可用于 Win32 应用程序模型而不是 UWP（非正式地称为“WinUI 桌面”），因此它不一定必须是 UWP 应用程序。

这是我最兴奋的事情。 具有可用 Windows 完整 API 的本机应用程序，无论是 Win32 还是 Windows 运行时，都能够通过 Xaml 拥有高性能 UI。

使用 WinForms 应用程序，保留代码隐藏，但将表单替换为 XAML 窗口，并可以访问所有画笔和 XAML 控件。

WPF 仅使用 WinUI XAML 会稍微复杂一些 - 但至少 WPF 控件的样式可以与 WinUI 控件相匹配

1. 命名空间应该被重命名。 “Xaml”不合适，因为 Xaml 指的是标记语言，它被错误地用作本机 UWP 组件的营销语言（经常更改）。 “Xaml”应替换为“WinUI”。 即使在这个线程中，您也可以看到造成了多少混乱，其中通常不清楚“Xaml”是指 .xaml 语言还是 ui 组件。
2. 就这使 WPF 和 UWP 靠得更近的情况而言，这很好。 它们每个都具有另一个不具备的功能，因此拥有将两者结合起来的“Windows UI”是有意义的。 可能会有一些重复的功能，但这也可以是 WPF -> UWP 的过渡路径。
3. 与 windows 版本解耦是有道理的，但假设一个相对更新的 Win10 也是可以的，因为当这项工作完成时，Win7 将远远超过 EOL。

Xaml 是 UI 框架的名称。 因此 Windows.UI.Xaml...

Xaml 是 UI 框架的名称

Xaml 是 WPF 中的一项技术，它使开发人员不仅能够强大地描述和构建其应用程序中的演示场景，还能够描述和构建应用程序本身。 也就是说，您可以描述 UI 元素_以及 POCOs_。 如果是 .NET，则可以使用 Xaml 对其进行丰富的描述并将其加载到应用程序上下文中。

以免我们忘记（听起来我们已经忘记）Xaml 代表扩展应用程序标记语言，这意味着它是一种标记语言，使您能够优雅有效地描述 .NET _application_ 组件。 虽然它主要用于描述用户界面元素，但在实践中并没有被降级或限制。

我个人最终使用 Xaml 来描述我的整个应用程序配置，删除和替换 App.config —— 是的，甚至是 Web.config —— 复杂性，除非那些绝对需要它的外部 API。

Xaml _not_ UI。 它们完全是两个完全不同的概念，但不幸的是，多年来在 UWP 下被混为一谈。 我很乐意看到“Xaml”一词从这些努力中解脱出来，但我不太有信心会考虑这些措施，更不用说采取了。

@charlesroddie我有点同意命名真的很随意。 只是切线，如果您曾经检查过源自 WUXaml 命名空间的事物的堆栈跟踪，它实际上在命名空间 DirectUI 内部。 如果当时有人在场，我很想知道 Win8 的故事，因为我想会有一个不同的故事。 DirectComp 用于合成图层，DirectManipulation 用于平滑滚动和橡皮筋，然后 Direct2D/DirectWrite 作为矢量图形引擎，DirectUI 位于顶部以将它们整合在一起。 然后出于某种原因，其中一些被反向移植到 Win7，只有 Xaml 位通过 WinRT 系统公开，而所有其他 API 都保留为神秘的 com 接口，带有奇怪的工厂和模式，您需要查看示例说明如何调用。

实际上，现在我仔细想想，如果就像 WUComposition 通过 WinRT 公开 DirectComp 和 DirectManipulation（或者是重写）一样，Direct2D/DirectWrite 在这里也有一个正式的家就好了。 如果您正在寻找它，它们都可以协同工作以启用各种级别的逃生舱口和保真接触点。 Win2D 真的是半成品，也不是一个好的 API。

我相信 Windows.UI.Composition 是对 DirectComposition 的重写。 API 相似但不相同。

不要再假设所有显示器都是 sRGB。
将所有旧版应用程序的颜色视为 sRGB，并在合成过程中为每个显示器进行转换。

这可能有点题外话，但假设您已经有一个用 C++ 编写的大型 Win32 应用程序，您希望对 UI 系统进行现代化改造，因此您可能希望使用具有最小依赖性的 WinUI 或 Comp，例如仅使用 Comp而没有in-框控件集，甚至没有 XAML 。

不过现在已经可以了，我们不需要等待 WinUI 3.0。

感谢大家对命名的反馈。 如前所述，我们今天确实在“Xaml 平台”和“Xaml 语言” （具有自己不同的规范/方言）之间存在区别，这可能会让人感到困惑。 我认为不会进行重大的品牌重塑，但我们肯定会讨论命名和命名空间。

在没有 XAML 的 C++ Win32 应用程序中使用 Windows.UI.Composition 对现有应用程序（如 Photoshop）进行现代化改造。 他们已经有了一个 UI 架构。

这可能有点题外话，但假设您已经有一个用 C++ 编写的大型 Win32 应用程序，您希望对 UI 系统进行现代化改造，因此您可能希望使用具有最小依赖性的 WinUI 或 Comp，例如只使用 Comp 而没有 in-框控件集，甚至没有 XAML。

感谢您对此的反馈 - 我认为这最终应该可以通过 WinUI 3 实现，类似于使用 Windows.UI.Composition 的“无框架”应用程序，您今天已经可以做到了。 在确定如何构建 WinUI NuGet 包和依赖项时，我们将牢记这一点。

不要再假设所有显示器都是 sRGB。
将所有旧版应用程序的颜色视为 sRGB，并在合成过程中为每个显示器进行转换。

@reli-msft 你能打开一个单独的问题来跟踪吗？

@jesbis 👉 # 67

苹果今天宣布了 SwiftUI...

如果要为Xaml Direct提供 Visual Studio 模板，让开发人员能够选择使用代码而不是 XAML 和代码隐藏来制作应用程序，那又如何呢？

我认为不会进行重大的品牌重塑，但我们肯定会讨论命名和命名空间。

谢谢@jesbis我很感激你如此参与这个

你是对的：有 1) 用户界面平台和 2) 语言/标记/描述机制。 在我的批评性评论中，我会说我从来没有对（第一个）用户界面平台给予足够的信任，因为我知道 Windows 团队在这方面做了很多出色的工作。 就我个人而言，这从来都不是问题。 这是引起我（和其他人）愤怒和惊愕的第二个领域，我们在这些年来出现的 UserVoice 问题中看到了这一点。

所有这一切都表明我至少会要求（乞求，甚至😅）进一步考虑品牌推广工作，以更好地对这两个领域进行分类。 我认为“Xaml Direct”是这里混淆的顶峰，正如它的名字暗示“标记语言”——它的名字就对了！ - 但在实际使用中没有任何类似的东西。 我会提供非常令人困惑和误导，以及品牌的边缘滥用。

说到 Xaml Direct， @mdtauk ：

如果要为 Xaml Direct 提供 Visual Studio 模板，让开发人员能够选择使用代码而不是 XAML 和代码隐藏来制作应用程序，那又如何呢？

就像CSharpForMarkup一样？

我建议使用一个比 Xaml Direct 更好、更贴切的名称。 当然，_any_ 名称将是。 😉

说到 Xaml Direct， @mdtauk ：

如果要为 Xaml Direct 提供 Visual Studio 模板，让开发人员能够选择使用代码而不是 XAML 和代码隐藏来制作应用程序，那又如何呢？

就像CSharpForMarkup一样？

我建议使用一个比 Xaml Direct 更好、更贴切的名称。 当然，_any_ 名称将是。 😉

@Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

它是为中间件设计的，可以从代码中编写 XAML UI，但是如果有模板来使用它而不是 XAML 文件呢？ 只是一个想法放在那里......

@mdtauk是的！ SwiftUI 有点像 Xaml，但在代码中完成。 我真的很喜欢 React 的代码中的一切想法。 打破你的设计文件然后链接某种代码隐藏有点老派，我发现它很难维护。

一位朋友刚刚提到他们需要 SwiftUI 布局引擎才能与 iPad Pro 的 120hz 显示器配合使用。 所以这就是他们一直关注的。 真的很迷人。

我提出了一个新问题 #804，其中关于 SwiftUI 启发的更改的讨论可以转到@eklipse2k8

请不要忘记为 Visual Basic 添加模板。😀

让 WPF 来构建 _on_ WinUI 3 的下层！

@reli-msft 你想从更新 WPF 中获得什么好处？

如果您希望在 WinUI 中看到您依赖的特定 WPF 功能，那么我们很乐意在“应该在 WinRT [WinUI] 中使用的 WPF 功能”主题中听到更多信息： https :

关闭支持新的固定问题 #888

真的很期待这个。 将解决许多与版本相关的问题。

@weitzhandler [ 2019年

对我来说，所有的技术细节都不那么重要。
UWP、WPF 或任何仅适用于 Windows 的框架，尽管很棒，但只要它不能在每个平台（至少是 Windows、Droid、iOS 和 Web）上运行，并且与任何屏幕尺寸。

总的来说，根据 WinUI 和 XAML，我希望看到以下方面的改进，其中一些我觉得很烦人，而且会减慢我的工作速度。

• 更多内置转换器应该有大量转换器，其中一些甚至应该用作标记扩展以减少冗长。 这还应该包括否定简单的算术动作、对象到布尔转换器（语义值为假，即空字符串、空集合、隐藏可见性等。每个上下文）。
• 与上面相同，但有行为。 绑定和事件/动作之间应该有一个简单的端口。 如果这是内置的，并且开发人员不会怀疑使用哪个未经测试的 NuGet，那将会容易得多。
• WPF 中缺少的所有内容，例如某些绑定类型、标记扩展、通用视图等。

谢谢！

更多内置转换器

由于巴贝奇的分析引擎和图灵的通用计算理论，一台计算机可以运行任何计算机可以运行的任何程序。 你想回到那个时代，我们必须为你想做的每一个计算创建一台新计算机。

应该毫不客气地甩掉整个转换器业务。

对象到布尔转换器

布尔值是布尔值。 其他对象不是布尔值。 并且没有从对象到布尔值的自然转换。 类型在 .Net 中很重要，进一步的无类型系统不应该暴露给用户。

是的，现有的无类型系统（如绑定）也应该被转储。

应该毫不客气地甩掉整个转换器业务。

我的意思是你有什么选择？
我对转换器的痛点只是你必须自己重新编写它们/从 NuGet 中选择，而且它们非常冗长。 除了它们不灵活之外，不允许使用算术或否定等表达式。

布尔值是布尔值。 其他对象不是布尔值。

你是对的，但是当涉及到 UI 时，这并不重要。
您想根据对象的常规状态显示/隐藏内容。 并非所有东西都应该有专门的可见性属性。

现有的无类型系统（如绑定）也应该被转储。

嗯？ 其实我觉得它有优势。 V 和 VM 之间的松耦合可能很好。

现有的无类型系统（如绑定）也应该被转储。

V 和 VM 之间的松耦合可能很好。

也许对于小型项目，但松散耦合的抽象比字面上关闭编译器帮助更好。 如果您曾经不得不维护一个包含数十到数百个视图的大型应用程序，并且想要重构可能在多个站点中使用的某些内容，那么不让编译器验证绑定路径的正确性会大大降低开发人员的体验。 我们的语言中有类型系统是有原因的，如果没有工具来帮助程序员，大型项目实际上是无法维护的，目前 UI 语言落后很多。

编译绑定对此有很大帮助。

@weitzhandler我的意思是你的选择是什么？
...不是所有东西都应该有一个专门的可见性属性。
嗯？ 我实际上认为 [bindings] 有优势。 V 和 VM 之间的松耦合可能很好。

在一个好的反应式框架中，您可以定义可观察变量（在代码中），如name:Mutable<string> ，然后将它们映射到let visibility = name.map(fun s -> s <> "") ，然后将它们绑定到使用visibility.bind someView.set_IsVisible或name.bind(fun s -> someView.IsVisible <- s <> "")查看属性

我使用https://github.com/ReedCopsey/Gjallarhorn，但周围有各种反应式框架。

请注意： 1. 一切都是键入的，与绑定不同。 2. 事物（函数、属性、视图）被称为对象，而不是通过传递字符串名称， 3. 函数只是函数，比转换器笨重得多， 4. 绑定样板，需要额外给出简单的对象属性“绑定属性”等，可以删除。

视图仍然可以用 Xaml 编写，特别是如果它们是简单的大部分静态布局，具有无处不在的魔术字符串的缺点，但具有设计人员提供实时视图的优点。 更好的是拥有提供实时视图的代码。 很有可能有翻译。

说到反应式框架，请查看Chain Reactive并告诉我是否应该将其开源。

嗨，ms team 可以解决uservoice上的所有错误/功能吗？
如果是这样，那将是一大进步，比 WinUI 3.0 还多。

@hupo376787我认为你的

但问题是微软和开发者可以参与的windows开发平台没有公开讨论的地方，微软相关组没有维护任何反馈机制，没有更新或回应，这是一个问题多年的用户声音。

@charlesroddie是的，似乎放弃了用户声音。 我会将我的声音发送到反馈中心。 也许女士会忽略它们，但我会做好我的工作。

UserVoice 本月将完全停用。

对于特定的产品，GitHub repos（比如这个）是反馈的最佳场所，因为相关的工程团队正在积极使用它们。

对于与特定存储库产品无关的反馈，请使用反馈中心。 有一个“开发人员平台”类别，其中包含专门用于 API 和开发人员工具反馈的各种子类别。

我知道 UserVoice 目前有很多历史和以前的反馈（我们仍然会跟踪），但 GitHub 和反馈中心都为我们的工程团队和工作项目跟踪提供了比 UserVoice 更直接的途径，所以希望这应该是积极的变化。 我们正在更新各种支持和反馈链接。

我们确实看到了来自任一渠道的所有内容，并且非常感谢反馈和错误报告！

@jesbis好的，明白了。

对于WinForms，在使用新的WinUI项目模板时，属性窗口是否还能正常工作并能够设置WinUI控件的属性？ 我可以整天编写 HTML 代码没问题（通常是 Asp.net MVC），但是当有如此多的控件设置可用时，过去 20 年来我一直喜欢使用属性窗口。

@Dean-NC 我猜你问的是 XAML 设计器，没有 WinFoms/Windows 窗体，对吧？ 如果是这样，是的，当您在 XAML 设计器上选择一个项目时，属性面板仍然适用于 WinUI 控件。

@marb2000我想我天真地认为 WinUI 3 会将新控件带到 WinForms，因为它几乎是无缝的，并且我可以拥有一个包含旧版控件和 WinUI 控件的表单，并且属性窗口可以工作适用于旧版和 WinUI 控件。

我阅读了上面的整个帖子，我一直很兴奋地关注这个（作为 WinForms 开发人员），但我想我误解了这将如何工作的高级工作流程（同样，从 WinForms 的角度来看） ）。

我一直在说 WinForms 在未来几年仍然是一个很棒的东西，但它最大的弱点是它的基本控件看起来过时（文本框不允许填充，所以它看起来很瘦，小的单选按钮和复选框按钮， 等等。）。 只是 Win 10 控件（文本框、单选框、复选框）的非常基础的知识将大大有助于为 WinForms 带来新的活力。
是否有一些文章，或者您是否介意简要描述一个新的 WinForms 项目的工作流程，该项目想要同时使用旧控件和新控件？
谢谢。

@marb2000我想我天真地认为 WinUI 3 会将新控件带到 WinForms，因为它几乎是无缝的，并且我可以拥有一个包含旧版控件和 WinUI 控件的表单，并且属性窗口可以工作适用于旧版和 WinUI 控件。

我阅读了上面的整个帖子，我一直很兴奋地关注这个（作为 WinForms 开发人员），但我想我误解了这将如何工作的高级工作流程（同样，从 WinForms 的角度来看） ）。

我一直在说 WinForms 在未来几年仍然是一个很棒的东西，但它最大的弱点是它的基本控件看起来过时（文本框不允许填充，所以它看起来很瘦，小的单选按钮和复选框按钮， 等等。）。 只是 Win 10 控件（文本框、单选框、复选框）的非常基础的知识将大大有助于为 WinForms 带来新的活力。
是否有一些文章，或者您是否介意简要描述一个新的 WinForms 项目的工作流程，该项目想要同时使用旧控件和新控件？
谢谢。

更有可能的是，您将能够使用您的应用程序项目、添加 WinUI 窗口和页面，并使用现代 XAML UI 完全或一点一点地替换您的 UI。

还有用于将 XAML 插入现有 Winforms 和 WPF UI 的 XAML 岛

您的 Blazor 团队应该与 Uno 合作，以将其某些托管模型包含在 Uno（特别是服务器端）中，和/或获得可被 Blazor 使用的 Uno UI（以及 WinUI 3）渲染/视觉层....和/或 Blazor 的 Xaml 岛？

我在这里感觉有点不舒服，因为大部分反馈来自主要在 xaml 领域工作的开发人员。 他们通常似乎正在寻找他们已经拥有的更好的版本。 这可能对现有用户有好处，但我不知道它是否会吸引许多迄今为止回避 UWP 的开发人员。

我的团队只开发了 1 个 UWP 应用。 我们不会再开发了。

无法克服的障碍是缺乏内置的表格报告编写器。 我们已经尝试了市场上所有声称支持 UWP 的 3rd 方报告编写器。 不幸的是，它们都不适用于 UWP。 他们的 UWP 产品通常是对 WPF/WinForms 变体的快速破解，无法正常工作。

我们在 UWP 产品中使用 Stimulsoft 报告。 这是非常有问题的，他们告诉我们他们不会修复这些错误，因为他们的 UWP 使用率很低。

我看到你在列表上有数据可视化。 但是仍然有数百万个战舰灰色应用程序存在的原因是许多企业不太关心内部应用程序的视觉效果。 他们想要带有小计的数字列。

因此，如果 WinUI 旨在最终吸引数据开发人员的表单，那么我们需要一个内置的表格报告编写器。

我希望这不会冒犯视觉人士:-)

我完全同意。 如果没有可以轻松与应用程序集成的报告系统，我们如何开发现代业务应用程序？ 这是一个巨大的峡谷，将阻止开发人员移动。

业务用户需要能够与表格数据进行交互，然后将其打印或导出为其他格式。 他们还需要能够创建发票、报价单、报表和其他工具文档。

据我了解，企业/企业仍然是 Windows 的最大消费者。 为什么不为 UWP 开发对 Windows 生态系统如此重要的东西？

感谢@VagueGit和@Elmarcotoro的反馈！ 企业控制现在对我们来说是一个缺口。 但是您的时机很好，我们正在收集有关 DataGrid 控件设计的反馈。 请在此处阅读并提供反馈：#1500。

同样，除了方形表格数据控件，我们还需要一个开源的 UWP 图形控件来创造性地以民主的方式通过图表控件共享复杂的关系

对于报表系统，我认为 Telerik UI 是目前最好的选择。 中国有句谚语：“有人专攻某些职业，有人专攻其他职业”。 Telerik、DevExpress 或其他人擅长报告。

对于各种控制的缺失，我们不应该责怪这个团队，而是整个MS的策略。 从 Satya 开始放弃手机，他们更喜欢 ios 和 android，导致老板喜欢他们。 整个 UWP 生态系统变得越来越弱。

目前，推特上有一个名为“UWP已死”的争论，我认为MS应该澄清这一点并声明他们的uwp之路。

目前，推特上有一个名为“UWP已死”的争论，我认为MS应该澄清这一点并声明他们的uwp之路。

您刚刚在路线图主题上发布了该内容...

@jevansaks感谢您提供有关 Datagrid 控件的信息。 这不涉及打印报告和分页、导出等问题。 这些是需要处理的现实生活业务场景，而不是某些按钮是否动画（尽可能好和酷）。

@hupo376787
“对于报告系统，我认为 Telerik UI 是目前最好的选择。”

据我所知，Dev Express 是目前唯一提供完整堆栈来创建和查看 UWP 报告的工具，而且它们的定价似乎偏高。 包括 Telerik 在内的所有其他工具都存在工具缺陷，这意味着无法创建 UWP 报告。 我愿意（希望）对此进行纠正。

对于报表系统，我认为 Telerik UI 是目前最好的选择。 中国有句谚语：“有人专攻某些职业，有人专攻其他职业”。 Telerik、DevExpress 或其他人擅长报告。

@hupo376787在暗示发布不正确之前，请格外小心地检查您的事实。 Telerik Reporting有一个 WPF 和 WinForms 的报表设计器，但没有 UWP。

DevExpress也有 WinForms 和 WPF 的报表设计器，但没有 UWP

因此，请先检查您的事实，然后再将自己犯下错误，该错误将被永久保存并广泛传播。 嘿，这听起来可能有一天会成为一句古老的谚语 😉

@hupo376787在暗示发布不正确之前，请格外小心地检查您的事实。 Telerik Reporting有一个 WPF 和 WinForms 的报表设计器，但没有 UWP。

DevExpress也有 WinForms 和 WPF 的报表设计器，但没有 UWP

因此，请先检查您的事实，然后再将自己犯下错误，该错误将被永久保存并广泛传播。 嘿，这听起来可能有一天会成为一句古老的谚语 😉

好吧，我想我们对报告有不同的理解。 我的意思是https://www.telerik.com/universal-windows-platform-ui和https://www.devexpress.com/products/net/controls/win10apps/。

我错了，Dev Express 不提供 UWP 报告。 似乎没有第三方工具开发人员这样做！ 我通过他们的聊天联系了 Dev express，询问他们是否有为 UWP 提供报告的路线图。
他们说，
“XtraReports Suite 使用 System.Drawing 程序集提供的功能，阻止我们为通用窗口应用程序实现相同工具集的原因是该程序集在那里不可用（https://stackoverflow.com/questions /31545389/windows-universal-app-with-system-drawing-and-possible-alternative）。所以，我们还没有在这方面制定我们未来的计划。”

@jevansaks ，Microsoft UI 团队与这些第三方工具提供商之间似乎缺乏沟通。 我们很乐意使用第三方工具，但看起来 UWP 平台使这些公司很难将他们为其他平台拥有的工具集成到 UWP 中。

他们让我联系他们的[email protected] ，了解我们的报告要求，这可能有助于 Win UI 3.0 团队与他们联系，看看他们是否可以帮助他们实施。 如果没有适当的报告工具，我不知道您将如何在通用平台上获得业务开发人员。

https://www.devexpress.com/subscriptions/reporting/

报告：仅从 WinForms 的角度来看，我同时使用了 Telerik 和 DevExpress（甚至是它们的最新版本），虽然 Telerik 很好，但我认为 DevExpress 不仅具有更好的整体设计器和体验，而且具有更多微妙的功能允许我做比 Telerik 更复杂的布局。 我认为DevExpress渲染技术更先进。

Win UI 3.0 团队与他们取得联系，看看他们是否可以帮助他们实施，这可能会有所帮助。

感谢您的来电。 我们也会联系他们。

感谢您的来电。 我们也会联系他们。

可能值得与他们所有人交谈并了解积木是什么？ Telerik、Grapecity、DevExpress 等。

感谢您的来电。 我们也会联系他们。

可能值得与他们所有人交谈并了解积木是什么？ Telerik、Grapecity、DevExpress 等。

当然，这就是我们的计划。

我们与大多数为 Windows 构建的开发人员略有不同。 我们主要开发自助服务终端应用程序（旨在由计算机所有者以外的用户运行的应用程序，通常是全屏的，无法访问更广泛的系统）。 这些应用程序通常是根据客户的特定要求构建的，无意通过商店或同类产品分发它们。

由于应用程序全屏运行，因此保持其他 Windows 应用程序的外观和感觉的内置控件的价值非常有限； 相反，他们往往对每个客户都有很高的品牌知名度。 我们仍然需要标准 Windows 应用程序中的许多常见_行为_和控件，但我们通常会对每个控件模板进行大量自定义，或者至少覆盖它们的核心样式。 很长一段时间以来，我们构建了许多应用程序作为 WinForms 后端，其中包含用于 UI 的嵌入式 Flash 前端。

从广义上讲，我们编写的几乎每个应用程序都将某种基于 Web 的后端与某些硬件（例如打印机、条形码扫描仪、磁条阅读器、RFID 扫描仪、相机、卡支付硬件、自动售货机式现金支付）集成在一起组件等），而且这些组件中的绝大多数在历史上都是随 Win32 SDK 而不是 UWP 的。

由于这两个原因，我们的大多数历史应用程序都是 WinForms 应用程序，而我们的大多数现代应用程序都是 WPF 应用程序。 我们已经构建了一些 UWP 应用程序（主要受益于 Windows 非常好的分配访问/信息亭模式功能），但与 WPF 相比，它们通常很难处理，而且我们通常无法获得兼容的硬件 SDK .

不过，我们对 XAML 岛非常感兴趣，它允许我们使用现代 UI 编写与 Win32 兼容的应用程序（尽管 UWP 相对于 WPF 的优势对我们来说并不总是很明显，特别是如果我们不使用标准控件或 Microsoft 特定的Fluent 等效果）。

要回答您的具体问题：

您最感兴趣的模板是什么？

带有 .NET Core 的 C#、带有 WinUI 3.0 的 Win32 覆盖会很好。

您是否知道 Xaml Islands 用于使桌面应用程序现代化？

是的，当我使用它们时，我对它们相对满意，尽管我们不太可能使用 _single_ 控件，而是为整个自定义 UI 做出决定。

我知道它的主要原因是因为我们将获得对 Win32 应用程序的Lottie支持。

Windows 10 上扩展的向后兼容性是否会使 Xaml Islands 对您更有用？

并不真地; 我们几乎总是控制目标 PC，并可以确保我们始终获得最新的兼容版本。

如果 Visual Studio 或其他工具自动为您更新命名空间会有所帮助吗？

是的。

现有 UWP Xaml 组件与 WinUI 3.0 应用程序之间的完全兼容性对您来说有多重要？

非常少。 我们会遇到的主要兼容性问题是更改用于样式化核心元素的 StaticResource 键。

您是否创建或使用了无法与应用代码一起轻松重新编译和更新的 UWP Xaml 控件库或 WinRT 组件？

是的，我们过去使用过 Syncfusion UWP 控件库。

在 WinUI 3 中使用 UWP Xaml 组件的首选解决方案是什么？

首选的解决方案是在 WinUI 本身中提供更多的标准控件，而不是依赖外部资源（例如文档查看器），但我希望这些外部组件库在更新其库方面通常会比我们切换到的更先进WinUI 3 无论如何。

您如何看待上述和路线图中概述的整体 3.0 计划？ 它能让您将 WinUI 用于新的和现有的 Windows 应用程序吗？

我很高兴看到 UWP 控件更清楚地与 UWP 应用程序和安全模型分离，因为硬件兼容性原因，这些模型历来将我们拒之门外，尤其是因为 WinUI 是在开放式设计和开发的。

有了关于 Microsoft 如何推荐我们构建应用程序 UI 的明确指导，我希望我们所有的应用程序最终都会使用 WinUI 前端，无论我们可以支持哪个后端。

您最希望将 WinUI 3.0 用于哪些应用程序？ 创建一个新的 Win32 应用程序并使用 MSIX 将其打包？ 向 WPF 应用程序添加新视图？ 使用 Fluent UI 现代化 C++ MFC 应用程序？

主要是关于在我的旧应用程序中访问更积极维护的控件库，使用更好、更明显的文档（甚至访问标准控件的底层代码）使我更容易确定何时可以调整标准控件当我需要滚动我自己的用户控件时。 例如，在最近一个内置 WPF 的应用程序中，我有几个日期选择器； 让该控件很好地用于触摸，以及自定义大小、字体、弹出图标等非常烦人。 鉴于上面的路线图，我倾向于在未来将 WinUI 用于此类应用程序的 _default_，因为：

1. 我可以合理地保证，有一个至少适度触摸友好的原生日期选择器控件
2. 我可以检查该控件的本机/开箱即用模板等，以轻松查看我需要覆盖的内容以使其与客户外观的设计证明相匹配（作为一个粗略的代表性示例，我可能想要找出独立于输入文本的 TextBox 控件标题的类型（字体大小、粗细、系列）的最简洁方式；标准 HeaderTemplate 是否使用了我可以重新定义的神奇静态资源，还是需要覆盖模板本身？如果我确实覆盖了模板，那么默认模板的标记是什么样的；它是否执行/支持我没有考虑过的任何事情？）。

我看到这已经关闭，但是我们的用户提出了几个问题，我认为值得提出。 它们是处理大量数据的用户的生产力改进。

文本框：
如果用户需要编辑文本框，他们首先必须单击文本框以显示清除按钮，然后单击清除按钮以清除文本框。 在处理大量数据时，这是非常低效的。 如果当用户单击或选项卡进入 TextBox 时，文本可以突出显示以准备写入，那将会很好。

网格视图/列表视图：
Gridview 和 ListView 似乎不允许用户有效地 Tab 浏览集合。
ListView 确实允许 Tab 移动到同一行上的控件，但它不会 Tab 到下一行控件。 相反，ListView 失去焦点并且 Tab 移动到可视化树中的下一个控件。

这是我们的用户提出的两个非常烦人的问题。

@Elmarcotoro

我建议您为您提到的每项改进创建一个新问题。 WinUI 团队随后将进行分类以确定他们是否需要在实施之前发布 WinUI 3。

这个问题的存在主要是为了收集关于帖子顶部的 2 个“一般问题”的反馈。

支持 WinUI 中原生的 Blazor 托管模型。 这将允许 Blazor 控件直接在客户端/服务器 Web 中使用，或直接在 WinUI 中使用。 Blazor 路线图在不使用 WebView 控件的情况下具有此未来概念。 通过这种方式，控件的 UI 以本机方式运行，而代码的 .Net Standard 部分也以本机方式运行。

支持 WinUI 中原生的 Blazor 托管模型

在 Blazor 方面讨论，FWIW：
https://github.com/dotnet/aspnetcore/issues/11082

当然，这就是我们的计划。

@jevansaks也很

我希望托盘菜单/图标菜单与 WinUI 3.0 具有更好的一致性。 每个 App 都有不同的间距，Win32 应用程序不会始终遵循字体渲染/间距/主题。 请解决这个问题！

由于缺乏任何窗口管理可能性，桌面中的 WinUi 对我来说完全没用：显示/隐藏窗口、窗口位置、窗口大小、停靠/取消停靠...

@alexandrevk它仍然是一个预览。 你看到窗口 API 设计了吗？ https://github.com/microsoft/ProjectReunion/issues/157

感谢@dotMorten链接到窗口公告帖子！

@alexandrevk - 我们正在为 Reunion 整合 API，这将允许您使用 WinUI 内容从 Win32 和 UWP 以及在您的窗口中使用其他框架/交换链内容时执行这些类型的窗口操作。 这些窗口功能中的一些可能会被抽象到 WinUI 窗口类中，以便于访问，但这还需要进一步的研究。 窗口区域的功能规格在管道中，请继续关注。

仅作为个人用户（即：非公司/公司）和 C++ 严格地说，即使我只是一个孤独的声音在虚空中大喊大叫，我觉得有必要说，只要这些新的 UI 系统中的任何一个是与 UWP 和他们构建的那个可怕的打包系统相关联，那么恐怕无论你做什么，它都会永远处于黑暗之中。 （从 WinRT 经验来看，还没有尝试过 WinUI，但对我来说它看起来几乎一样）。
当然必须知道几乎没有人真正使用 UWP 应用程序吗？ （实际上被大多数 afaik 讨厌）所以如果它被称为“本地”，那么为什么它不是真正的“本地”，即：一些#includes，链接一两个 .lib 并在标准 c++ 中构建您的应用程序。
当跨平台无关紧要时不得不求助于Qt之类的东西，只是为了避免第1000次包装win32是公平的。
无论如何只是我的 2 美分，来自每天使用该语言的人，但可能没有地方在这里发表评论。

@nl-n 你应该很高兴知道 WinUI 的一大亮点是它不需要作为 UWP 应用程序运行。 事实上，自预览版 2 以来，这已经成为可能。
_目前_它确实需要打包为 msix，但 msix 实际上是分发（和更新）应用程序的一种相当不错的方式。

@dotMorten这是一大问题：需要通过商店进行侧加载/安装。 我不知道有一个人在安装 Windows 之前（或之后）不禁用/剥离商店，那么我们应该如何分发它们？。
我知道这有点花言巧语，但它适用于这一点。 我应该能够压缩构建目录并分发它（或安装程序，如果有保证）。
然后是兼容性问题，很多人仍然拒绝安装W10，所以也是......
然而，很高兴听到 3.0 的发展方向，尽管我讨厌 xaml，但这将是一个受欢迎的补充。
也许我们也可以在不需要在 VS 中安装整个 50gb UWP 工作负载的情况下获得它？ 🙏（夸大我知道，但仍然）

在本主题开头附近引用@MarkIngramUK ：

现在是 2019 年，我想要一个快速、原生的 UI，而且我不想认真考虑使用CreateWindowExW 、GDI 等来制作用户界面。

这（很有趣）我现在真的必须做，是的，这听起来很痛苦:)

@nl-n 谁说了这家店的事？ MSIX 与从 MSI 安装并没有什么不同。 它只是一个应用程序安装程序。 双击它进行安装。 不需要商店。 也保证 100% 干净卸载（而不是 MSI，这会造成巨大的混乱）

我不认识一个不禁用/剥离商店的人

不过这并不常见。

我们应该如何分配它们

首先需要告知用户不要禁用商店）

我应该能够压缩构建目录并分发它

MSIX 可以在没有商店的情况下安装。 使用最新的 Windows 版本，用户不需要为此启用任何东西。 当然，如果之前使用受信任的证书对包进行了签名。 但是，是的，如果用户从 PC 中删除了商店，那么他也可以从中删除 MSIX/APPX AppInstaller。 在那种情况下，他们可能不想要应用程序的所有可变性。

很多人仍然拒绝安装 W10，

这是他们的选择。 纳夫说。

VS 中的整个 50GB UWP 工作负载

单个 SDK 大约 3GB。 不需要从 10240 开始每一本都下载。

@nl-n 谁说了这家店的事？ MSIX 与从 MSI 安装并没有什么不同。 它只是一个应用程序安装程序。 双击它进行安装。 不需要商店。 也保证 100% 干净卸载（而不是 MSI，这会造成巨大的混乱）

那是来自visual studio给你的描述，“通过微软商店进行侧载/安装”，我在msix上找到的唯一其他信息来自msdn，它基本上说：msix包是沙盒/虚拟化的“appx”应用程序，对于直接使用 winapi 的任何东西来说，这几乎是一个杀手。 而且他们需要签名才能安装？...

我想它也可能只是交叉线，太多不同的术语，而且我对 UWP 了解不多。

不过这并不常见。

比你想象的更常见，而且有理由😄

无论如何，我无意出轨，所以现在我会回去写我的 CreateWindowExW 东西🤣