可能是一件遥不可及的事情，但 Blend 需要彻底改革并且需要一个以设计为中心的工作流程。

XAML 设计器需要健壮和强大。

一些可视化页面/窗口分层结构的方法，对于提升的控件尤其重要。

在页面外可视化 UI 元素的方法，例如单个控件/模板。

为 CoreOS、“Surface Phone”、Surface Hub、Xbox、HoloLens 进行的显示控制定制，所有这些都在设计器中。

XAML 的组合设计器与 WinForms、WPF、MFC 以及 WinUI 桌面将使用的所有其他框架混合。

导入和导出 XAML 的好方法，因此设计人员可以在与主应用程序隔离的 Blend 中工作，然后将它们交给开发团队以引入应用程序。

更好的系统资源可视化和列表，以及提取那些可以采用轻风格覆盖默认值的全局资源的好方法，并且设计表面实时反映这些变化。

使用涉及 WinForms、MFC 等的应用程序测试不同 DPI 缩放的更好方法。

新控件模板、自定义主题资源字典、集成 Fluent 主题编辑器、支持应用程序组合的模板（Win32 MFC 与 Xaml UI 等）。

shell 集成点的模板，如文件选择器、任务托盘弹出窗口。

这些只是一些想法......

我的想法如下：

1. MSIX 一切都很好，但我仍然使用旧的 MSI 来安装更复杂的应用程序，这些应用程序需要 MSIX 不支持的功能。 我也对使用 MSIX 持怀疑态度，因为所需的 Authenticode 证书非常昂贵。 （我可以使用自签名证书轻松签署我的代码，我相信它与我从公司购买的证书一样安全，但是 Windows 不会加载它。Windows 会很乐意接受自签名 MSI 文件，但是.) 只要我可以从基于 MSI 的应用程序中使用 WinUI 3，我就很高兴。
2. 一个更好的 XAML 设计器将不胜感激，但我不需要将 WinUI XAML 和 WinForms/WPF 设计器集成在一起而增加的复杂性。 我完全可以在 VS 中的不同选项卡之间进行翻转。
3. 正如我之前所评论的，将 XBF 编译器与 C# 和 Visual Basic 项目系统分离将非常有用。 （如果发布了 XBF 编译器源代码或足以重新创建它的文档，那就更好了，但我不知道这种情况发生的可能性有多大。）
4. 在 C++ 项目系统中更好地支持 C++/WinRT 和 MIDL 3。 目前，对使用 C++/WinRT 的项目支持是脆弱和笨重的。 （例如，如果您更改 IDL 文件中的命名空间——如果您想在命名空间中使用项目名称中的一个点，这通常是必需的，因为模板会自动将这些转换为下划线——您的项目将无法编译，并根据我的经验解决问题需要将*.h和*.cpp文件移到一边，从头开始重新生成它们，复制代码，然后卸载和编辑 vcxproj 文件以修复嵌套。）尽管我想使用比 vcxproj 更现代、更灵活的东西，但由于 XBF 编译器对它的硬依赖，我不能这样做。

如果还有什么问题，我一定会在这里发布。 谢谢！

1. 我在这里想知道的是...好吧，我是否需要使用像 < winui:Listview或 < controls:listview或开发人员决定的任何名称的名称空间前缀？ 我认为如果可能的话，使用与现在相同的体验会好得多，只是前缀是好的，而且很棒，仅用于几个控件。 但是当你开始到处使用时，这会让 XAML 阅读成为一场噩梦，而且非常。
   使用命名空间前缀没有意义，因为无法使用 Windows.UI.Xaml.Controls 并且 WinUI 将是默认选择。

2. 现在我什至不使用 XAML 设计器。 我真的在设置中禁用了。 XAML 设计器很慢，需要更好的支持。 它适用于 WPF，但不适用于 UWP，特别是如果您想做响应式设计、处理页面、显示数据等。
   这可能是对遥远未来的反馈，但我认为这是一个很好的反馈。 WPF 设计器要快得多。
   这是因为沙箱还是什么？

3. 进行迁移的工具会很有趣。 特别是因为它可能与更新的 WinUI 3.0 控件（如 ScrollViewer）存在一些兼容性问题。 因此，如果有一个工具，它至少需要在这些更新/重写的控件上显示可能的警告。

1. 我们需要强大的 xaml 代码编辑器与设计器分离的 IntelliSense。
   大多数时候我只是像 C# 一样编写 xaml 代码。 目前，代码编辑器缓慢且脆弱，在我之前的评论中解释
2. x:Bind设计数据支持可能非常困难，因为我正在函数绑定中编写复杂的帮助程序。 但是如果 xaml 内置函数可以替换一些帮助程序，事情会更好。
3. 我想为我的应用程序提供更多免费的包装模型组合。 可能偏离主题，但我找不到任何地方可以向应用程序模型团队反馈。

TL;DR 我想要一个支持任意实例共存的应用程序模型。 即使是相同的版本也可以使用不同的数据/选项集运行，例如 Visual Studio hives。 目前唯一的解决方案似乎是 xcopy。

谁能告诉我如何折叠这个？

首先，我也在使用我每天都在开发的应用程序（并且大部分时间都在使用>>调试）。 因此，让开发构建与稳定构建共存对我有很大帮助。 目前我必须增加版本号，打包调试msix，更新安装包版本进行调试。
在不同的调试阶段，我需要不同的功能。 对于复杂的现实世界数据，我希望调试实例与稳定实例共享数据。 对于任意的虚假数据，我想要隔离。 这在理论上是通过使用文件夹选择器访问数据来解决的，但很遗憾 UWP 中的 SQLite 不支持它，而且据我所知，没有其他嵌入式 ACID 引擎。

哦，还有另一件事。 如果可以对 vcxproj 如何要求使用 packages.config 用于 NuGet 包引用做些什么，我真的会非常感激。 WinUI 作为 NuGet 包分发，C++/WinRT 和其他关键组件也是如此。 我真的不喜欢使用packages.config。 PackageReference 效率更高（如果您将 vcxproj 移动到不同的目录，它不会导致构建损坏）。 当从 vcxproj 使用时，它确实可以工作，只要在适当的时间运行恢复目标。 （这是因为 vcxproj 目标间接导入了非 SDK C# 项目的 PackageReference 恢复机制。）我编写了一组目标，当 PackageReference 项集更改时，这些目标会自动运行恢复目标，因为 VS 不会这样做本身（还）。 不幸的是，NuGet 系统对此一无所知，因此当我添加 C++/WinRT 文件模板时，它会尝试添加一个 packages.config 文件。 这会导致各种破坏，导致抛出异常和损坏的项目文件。 我不确定如何最好地解决此问题，但如果至少可以在 WinUI 3 发布之前对其进行查看，我将不胜感激。 谢谢！

如果 WinUI 支持新项目 sdk - Microsoft.NET.Sdk或MSBuild.Sdk.Extras ，那就太好了。
旧式 csproj 文件很难维护。 并且我们不能将多个TargetFrameworks与它一起使用，这对于迁移到 WinUI 可能很有用。

为什么不支持 F#？

是否应在此处讨论 Azure DevOps 和 Visual Studio App Center 功能？

像@vitorgrs一样，我更喜欢没有命名空间前缀的本机控件，它给代码添加了“噪音”。 它有助于查看哪些是本机控件，哪些是 3rd 方。

当然，迁移工具会很好。 如果它与大型 3rd 方提供商（Telerik、DevExpress 等）合作，那将是一件大事。

模板

是否有兴趣/需要将以前版本的 UWP XAML 模板保留在 VS 新项目流程中？

在我看来，没有必要保留模板。 但会不会是 UWP 有一个不在 WinUI 中的控件？ 如果可能发生这种情况，那么这可能是构建传统 UWP 应用程序并在所需控件存在时将其迁移到 WinUI 的正当理由。 那么可能需要模板。

如果您已经构建了一个应用程序并且您无法再使用最新的 Visual Studio 版本创建它，那么开发人员可能也会感到困惑。

但就我个人而言，我没有兴趣保留模板

我们如何帮助您在 Visual Studio 中的模板和组件方面提高效率或取得成功？

对我来说，这对 UWP 来说看起来很棒。 现在我想看到同样的 Win32。 :)

本演练是否有帮助，您是否希望在场景形成时看到更多这样的内容？

当然是。 这个演练非常有助于了解未来可能和应该是什么样子。 我想看到更多这样的东西。

移民

如果我们提供一个自动执行步骤 1-3 的迁移工具，会有好处吗？

确实。 也许一个小的 Visual Studio 扩展将是这次迁移的一个很好的选择。 我还可以想到像“WinUI 兼容性分析器”这样的东西，它输出可以迁移的内容和不可以迁移的内容。 类似于 .NET 可移植性分析器的东西。

您在本机 Windows 10 控制集之外使用了哪些库？

通常 Telerik DataGrid 和社区工具包

我们可以通过哪些方式协助我们目前没有考虑的迁移？

如果你在 Visual Studio 中打开一个版本低于你安装的 Win SDK 的 UWP 应用，Visual Studio 会为你迁移它。 也许您也应该为 WinUI 迁移考虑类似的事情。 我不确定，但要记住这一点。 尤其是当 Visual Studio 不再拥有普通的 UWP 模板时，开发人员可能会因为拥有无法使用模板创建的应用程序而感到困惑。

其他

就像其他评论中已经提到的那样，我认为是时候切换到 SDK 样式的 .csproj 文件了。

将 winui 3.0 模板添加到 windows 模板工作室。

桌面应用程序中的 WinUI

桌面中的 WinUI 将允许开发人员在桌面应用程序模型上使用 Windows UI 库。 @marb2000将在未来几周内

作为 .net 开发者，这是我最感兴趣的部分。

模板

• 是否有兴趣/需要将以前版本的 UWP XAML 模板保留在 VS 新项目流程中？

取决于模板的数量。 如果数量较少（例如，每种语言只有“空白应用程序（通用 Windows）”，那么在 c# 的情况下为 1），则噪声较低并且可以支持。 但是如果涉及的模板比较多，那么就不要默认包含它们，而是添加一个可选的VS安装组件来添加它们。

• 我们如何帮助您在 Visual Studio 中的模板和组件方面提高效率或取得成功？

保留一个没有脚手架的真正空白模板（更适合教程）。 看看asp.net core正在做什么，他们在新的项目体验中做了很多改变。 基本上，您选择一个通用模板“App (UWP WinUI)”，然后第二个屏幕（特定于您的应用程序模型）允许您从不同的模板中进行选择。 使用此步骤还可以选择最低和目标平台版本（因此无需额外步骤）。 例如，您可以添加一个选项来直接创建应用程序打包项目。

也为项目之间的工具箱中的组件提供良好的支持。 新控件应立即显示在工具箱中，按项目分组。 也许支持设计器图标以帮助区分它们。

• 本演练是否有帮助，您是否希望在场景形成时看到更多这样的内容？

是的

语言支持

• 如果我们提供一个自动执行步骤 1-3 的迁移工具，会有好处吗？

一份好的文档（一页有清晰的步骤）就足够了。 如果一切都可以在 VS 内完成而无需手动编辑 csproj，我建议只添加一个描述步骤的文档页面。

如果您决定（我希望您会这样做）切换到新的 csproj 格式，那么肯定需要迁移工具，因为迁移需要编辑 csproj 文件。

包装

MSIX 是适用于所有应用程序的现代打包方法。 对于 Win32 中的 WinUI，我们应该支持 ClickOnce 吗？ 我们还应该支持哪些其他包装方法？ 尤其是Win32下的WinUI

比较clickonce和msix部署的区别：

1. 应用安装程序功能在较旧的 Windows 版本上无法提供相同的体验
2. MSIX 需要有效的签名包（内部或公共）。 Clickonce 支持自签名包。
3. 包模型有一些限制，主要是由隔离环境引起的（例如没有本地应用数据访问，没有提升操作）。

对我来说，最烦人的问题是 2。我们通常有 clickonce 应用程序，这些应用程序在内部部署在未注册域的计算机上。 因此，对于这些类型的应用程序，它需要我们使用有效的公共签名证书对包进行签名。

很难预测这两个框架之间的所有差异，因为 Appx 打包格式通常只针对面向商店的应用程序进行广告，当我们看到限制时，我们并不总是知道它们是否也适用于 Web 分发格式。

• 设计师经验

性能，性能，性能，以及对具有大量项目的大型解决方案的支持。

Windows 10 SDK 的 WinUI 版本和 WinUI Xaml 设计器是否会开源？

我们能否发布对设计时工作流程和体验的请求？

SDK 是否会遵循与 WinUI 的 nuget 版本类似的发布节奏？

一些额外的痛苦：
改善托管-非托管混合调试体验。
当前，当非托管代码中发生异常时， COMException会显示在托管调试站点中。 如果调用堆栈跨越托管/非托管边界超过 1 次，情况可能会更糟。
与WPF相比，托管调用栈始终可用，抛出的异常带有一个有助于调试的字符串。
我知道非托管世界和 COM 模型不像托管那样方便。 但至少，当框架抛出异常（错误的 HResult）时，我需要必要的信息来定位开源存储库中

我们严重依赖 ClickOnce，因此短期内支持会很好。 我们愿意迁移到 MSIX，但在提供类似功能之后。

至于模板，最好有一个为 NavigationView 和导航提供样板 UI 和代码的模板。

谢谢

我们严重依赖 ClickOnce，因此短期内支持会很好。 我们愿意迁移到 MSIX，但在提供类似功能之后。

至于模板，最好有一个为 NavigationView 和导航提供样板 UI 和代码的模板。

谢谢

最常见的应用程序“外壳”结构和模式 - 应作为模板提供，以便开发人员可以快速启动和运行。 Microsoft 的第一方应用程序应该成为这些布局的典范，并在行为、一致性和遵守 Fluent Design 和 WinUI 的 UI 设计规范方面充当最佳实践。

@shaggygi @mdtauk
对于“最常见的应用程序“外壳”结构和模式”和“至于模板，最好有一个为 NavigationView 和导航提供样板 UI 和代码的模板。” 有由 Microsoft 和社区共同维护和开发的Windows Template Studio 。 引用它的介绍：

Windows Template Studio (WTS) 是 Visual Studio 2017 和 2019 扩展，它使用基于向导的体验加速新通用 Windows 平台 (UWP) 应用的创建。 生成的 UWP 项目是格式良好、可读的代码，在实施经过验证的模式和最佳实践的同时，合并了最新的 Windows 10 功能。

@Felix-Dev 除了 UWP 之外，最终还会有 WPF 模板吗？

@shaggygi可能此线程：虽然目前似乎没有任何保证，但显然正在探索为 WPF 项目提供专门模板的想法。 如链接线程中所述，在 Build 2019 上举办了一个名为“Windows Template Studio - WPF 版”的非公开预览会议。

我们正在使用 C++/WinRT。 我们目前不使用 xaml 设计器或绑定。 但是我们将在运行时创建控件并可能通过 UWP xaml 为它们设置样式。 我们还需要对话框和带有 xaml 岛的无模式子窗口，包括停靠/浮动窗口等。

我曾尝试为我的 C++ 应用程序编写 XAML，但男孩的经历很痛苦。

我不得不添加许多未记录的项目属性和其他一些技巧以正确生成所有内容并正确打包。

例如：

• 在创建一个项目来存储我的 XAML 页面时，我必须添加<_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp>和<_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> ，这两个项目属性完全没有记录，只能通过检查新终端的源代码才能找到。
• 我有一个神秘的“无法创建新视图，因为主窗口尚未创建”，直到我创建并使用了一个 App 类，在 VS 中没有办法，除了创建一个普通页面并进入VS 中的 XAML 文件并将其更改为应用程序定义，然后调整 MIDL、源代码和 XAML 文件。
• 我添加了Microsoft.Toolkit.Win32.UI.XamlApplication NuGet 包来创建我的应用程序类，并且在我还添加了Microsoft.VCRTForwarders之前无法加载它，我在检查终端的源代码时再次发现了这一点，没有任何关于任何包的迹象。
• 在我在 .waproj 文件中添加了一些东西之前，PRI 并没有合并成一个，所以它找不到我的 XAML 资源。
• 在我添加<DisableEmbeddedXbf>false</DisableEmbeddedXbf>之前，XBF 无法正常工作，这令人惊讶地禁用了嵌入式 XBF 而不是启用它。 我遇到的唯一错误是 XAML 解析错误，但没有任何内容表明 XBF 文件不起作用。
• 我的应用程序清单中的maxVersionTested完全被忽略，直到我将其全部更改为小写，即使说明告诉使用驼峰式大小写版本： https :

此外，C++/WinRT 也令人头疼：

• 每次我运行增量构建时，我的自定义类都有一个[msg]redefinition [context]: MyClass阻止我构建并且直到我运行干净的构建才消失，由于 C++/WinRT 标头需要很长时间。 这个问题不知何故神奇地在中途消失了。
• 现在，当我运行干净的构建时，我收到有关缺少标头的错误。 第二次点击构建按钮让它再次工作。
• 由于来自 C++/WinRT 的不良代码生成，我不得不编写自己的AppT<>类。 终端应用程序和 XAML 岛示例执行相同的操作，就好像这是用户需要做的事情，而不是解决根本问题。
• 在我进行干净的构建之前，更改 MIDL 文件中的任何内容都会导致构建错误。

即便如此，即使将activatableClass内容添加到我的应用程序清单中，它仍然无法在未打包的情况下工作（关于无法找到 XAML 资源的问题，例如当我没有合并 PRI 时），这很重要为我的应用程序提供支持。

移民

步骤 1-3 的自动化绝对有帮助，特别是因为重命名数百个文件的命名空间非常耗时且容易出错。 最重要的是，compat 分析器会很好，就像 .net 框架 > .net 核心分析器一样，它会创建一份关于当前代码库兼容性的报告，并记录所有可能需要的更改。

工装

正如其他人已经说过的那样，功能更丰富的编辑器会很好。 工作中的大部分时间 XAML 都是手工完成的，并且主要使用设计器作为应用程序外观的粗略框架的指南。 智能感知和智能重构将是非常有帮助的，生活质量的东西一样CTRL + R + R重命名的东西（如依赖项属性，甚至标签），例如尤其是当你往往有大量的自定义UserControls ，也GoTo 实现和参考。 Roslyn 分析器支持也非常好。

扩展命名空间改进。 如果以某种方式可以在不向默认命名空间添加新的XmlnsDefinition的情况下更轻松地实现非前缀自定义控件，那将会很好，它会整理标记 imo 并且仅在发现不明确的控件时才需要前缀，就像类是如何工作的，这也与 GoTo 实现很好地结合在一起。 通常，控件的名称以及将鼠标悬停在其上以显示完整命名空间就足以知道它来自哪里，除非需要，否则通常不会在 C# 代码中使用命名空间别名。

主要是在工具方面，如果它的行为像 C# 编辑器那样使重构不那么脆弱或麻烦并且更容易导航标记，那就太好了。 除此之外，对于 XAML 语言本身来说，减少冗长也是一个很好的例子，如讨论的 #62 和 #279 的样式。

扩展命名空间改进。 如果在不向默认命名空间添加新的XmlnsDefinition的情况下可以更轻松地实现非前缀自定义控件，那就太好了，它会整理标记 imo 并且只在发现不明确的控件时才需要前缀，就像类是如何工作的，这也与 GoTo 实现很好地结合在一起。 通常，控件的名称以及将鼠标悬停在其上以显示完整命名空间就足以知道它来自哪里，除非需要，否则通常不会在 C# 代码中使用命名空间别名。

我认为 WinUI 3.0 版本的 Page 控件将不需要为这些控件使用前缀。 我想这将是一个 SDK 级别的事情。

使用 WinUI 时是否可以不更改命名空间？

一种解决方法应该是，您可以从构建中排除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，变化速度更快，具有两者的所有优点，但没有任何问题。

我认为没有必要提供移植工具。 这是一次性更改，使用 Find&Replace 相当容易，并且实例数量将相当低。

还遇到了更多问题：

• 在将资源添加到App类后，我的 XAML 无法找到它，直到我添加了它，再次从终端应用程序中找到，并且对它的真正作用知之甚少：
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• 构建将完全随机中断，并出现类似于cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication的错误，再次获得项目构建的唯一方法是进行干净的构建
• 我无法通过直接将主exe的vcxproj设置为启动项目来运行应用程序，我必须手动启动bin\x64\Debug\AppX未打包的appx输出，然后从VS内部注入调试器，或设置应用程序包作为启动过程。

Windows 桌面上的相关内容

长时间的 WinForms，WPF 开发人员，这里有一些 UWP 经验。 这是我的 2 美分：

移民

• 将现有 UWP 应用程序迁移到 WinUI 的工具是必须的。
• 在现有应用程序中将 WinForms 或 WPF 控件转换为 WinUI 控件的工具将非常棒。 通过转换控件，我的意思是将容器中的引用更改为单个控件。
• 将 Xamarin Forms 迁移到 WinUI 以允许将移动应用程序向后移植到 Windows 的工具。

工装

• 当前的 XAML 编辑器很糟糕！ 它需要使用普通的文本编辑器画布，并提供 Roslyn 功能以应用于 XAML 对象模型以获得更好的智能感知和重构。
• 在 Visual Studio 成为 64 位之前，XAML 编辑器需要是一个独立的 64 位幕后应用程序。 在使用大量 XAML 时，我经常不得不重新启动 VS 2017 和 VS 2019 以停止内存不足错误。

模板

• 我们需要这些项目模板

  • 导航视图 WinUI
  • 导航视图 WPF
  • 功能区 WinUI
  • 功能区 WPF
  • 功能区 WinForms

• 我们需要这些页面/窗口模板

  • 媒体控制器页面
  • 浏览器页面
  • 对话窗口
  • 无边框窗口
  • 浮动窗口

• 我们需要控制模板

  • 封装数据网格视图
  • 封装的子数据视图

最后两个将共同创建简单的主从窗口。

所有这些模板和页面等都已经在 Windows Template Studio 项目中完成了，为什么不遵循相同的路线而不是重新创建所有这些呢？

SDK 样式项目文件
我希望看到的最重要的一点之一 - 正如许多其他人也提到的 - 是对 UWP 和“桌面 XAML”应用程序的新 SDK 样式项目文件格式的支持。

UWP 和桌面 XAML 应用模型之间的迁移
如果我们开始构建“桌面 XAML”应用程序，它离 UWP 应用程序还有多远？ 如果我们意识到我们仍然处于 UWP 沙箱的限制范围内，那么稍后将其转换为 UWP 应用程序会很简单吗？ 或者，如果我们开始构建 UWP 应用程序并意识到我们需要更多应用程序，那么将它变成“桌面 XAML”应用程序会容易吗？

我有模板工作室支持。

我有模板工作室支持。

Template Studio 是否支持 XAML C++ 项目？

Template Studio 正在做什么，应该是 WinUI SDK IMO 的一部分

Template Studio 正在做什么，应该是 WinUI SDK IMO 的一部分

应该是Visual Studio IDE IMO 的一部分！ 😎

伙计们，重点是 windows 模板工作室正在为 UWP 项目创建做一个多合一的东西，所以请记住，如果缺少像 xaml c++ 支持这样的东西，我们应该考虑将它添加到 windows 模板工作室，我认为它会更快，更多如果 uwp 项目中的所有新创新都保留在一个项目中，则效率更高。

让有一些方法可以直接使用 WinUI 3 堆栈的下层，而无需 XAML 甚至 MVVM。 这对于现有的大型 C++ 软件特别有用，这些软件已经在其代码库中具有某种 MV 架构。 他们只是想要比 HWND + GDI 更好的东西。

并且，请让人们认为WinUI 3 不是玩具，它真的可以支持严肃的软件。

@be5invis我完全同意。 目前唯一的解决方案是 XamlDirect，但它更针对中间件开发人员。

您已经可以使用 Xaml Islands 手动构建内容。 只需让 DesktopWindowXamlSource 工作并附加到窗口，然后在代码中创建和排列/布局控件。

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

@MarkIngramUK他们可能需要更“完整”的东西，比如用 WinUI 函数替换CreateWindow 。

出于设计考虑，我非常希望未来的 WinUI WPF 模板能够像当前的 UWP 应用程序一样支持将页面内容扩展到标题栏。 现在，使用现有的 XAML 岛解决方案，我们只是在 WPF/WinForms 窗口内托管控件而不是现代视图。

@LucasHaines我们计划在 WinUI 3.0 中支持的语言列表：C#、C++/WinRT、Visual Basic。 我们正在探索对 F# 的支持。

这表明您做错了，不仅对于 F#，而且对于所有 .Net 语言。 您首先要考虑模板和 .xaml 文件，这就像在未完成结构的情况下建造房屋并安装地毯和窗帘一样。

您应该能够将 WinUI 作为 Nuget 包安装到任何 .Net Standard 2.0/.Net Core 3.0/.Net 5 项目中。 然后您可以访问内部定义的所有类。 然后，您可以从 WinUI 项目（可能仅限 C#）引用此类项目。 这允许使用任何 .Net 语言创建 WinUI 视图。 了解 Xamarin.Forms 如何做到这一点。

这些类已可用于 F#（因为它们是 Windows 运行时组件，可用于所有 .NET 语言）

您将能够手动创建布局。 您甚至可以通过 Python 使用 Py/WinRT 来处理所有 WinUI 问题。

@sylveon具体是什么课程？ 我会感兴趣...

他们都。 WinUI 的公共 API 只是 Windows 运行时组件。

@LucasHaines我们计划在 WinUI 3.0 中支持的语言列表：C#、C++/WinRT、Visual Basic。 我们正在探索对 F# 的支持。

这表明您做错了，不仅对于 F#，而且对于所有 .Net 语言。 您首先要考虑模板和 .xaml 文件，这就像在未完成结构的情况下建造房屋并安装地毯和窗帘一样。

您应该能够将 WinUI 作为 Nuget 包安装到任何 .Net Standard 2.0/.Net Core 3.0/.Net 5 项目中。 然后您可以访问内部定义的所有类。 然后，您可以从 WinUI 项目（可能仅限 C#）引用此类项目。 这允许使用任何 .Net 语言创建 WinUI 视图。 了解 Xamarin.Forms 如何做到这一点。

这个话题/问题是关于工具的。 是的，这些库可以从任何能够使用它们的语言中直接引用，但是工具和语言支持之间的定义很模糊。
以 Xamarin.Forms 为例。 这只为 C# 提供工具，在较小程度上为 F# 提供工具。 可以使用 VB.Net 和 Xamarin.Forms 构建应用程序，但它不受_官方支持_，因为没有工具并且只有有限的文档可以这样做。

此外，由于 WinUI 是特定于 Windows 的，因此不能在任何.Net Standard 2.0/.Net Core 3.0/.Net 5 项目中引用。
对于某些场景，还需要项目/编译器/打包级别的支持。

v2.2 版本的伟大工作团队。 我们是否有机会获得有关 v3.0 状态的简要更新？

我多次看到这一点，但没有明确的方向。 由于 WinUI 3.0 现在将拥有所有控件，因此必须删除引用 WinUI 库控件的命名空间要求。 这使 XAML 变得非常混乱，极大地阻碍了迁移，并破坏了与 UNO 平台和 Avalonia 等事物的简单兼容性。

请从 XAML 中删除xmlns:mux="using:Microsoft.UI.Xaml.Controls"的需要。 我明白背后的代码仍然需要改变。 在项目中的某个地方也可能有一个配置。

请从 XAML 中删除xmlns:mux="using:Microsoft.UI.Xaml.Controls"的需要。

XAML _markup_ 中不需要它，但仍需要更改代码隐藏中的命名空间。

如果你想使用 Windows 控件（如果它们没有从操作系统中删除） - 你应该在 XAML 中声明命名空间

如果你想使用 Windows 控件（如果它们没有从操作系统中删除） - 你应该在 XAML 中声明命名空间

使用 WinUI 3.0 这不是一个场景——您不能将操作系统控件与 WinUI 3.0 控件混合和匹配。 现在只适用于 WinUI 2.x，因为这些控件是操作系统的附加组件（我们有很多尴尬的情况，我们在两个地方都提供了类型，如 NavigationView 和 TreeView 导致歧义）。

如果你想使用 Windows 控件（如果它们没有从操作系统中删除） - 你应该在 XAML 中声明命名空间

使用 WinUI 3.0 这不是一个场景——您不能将操作系统控件与 WinUI 3.0 控件混合和匹配。 现在只适用于 WinUI 2.x，因为这些控件是操作系统的附加组件（我们有很多尴尬的情况，我们在两个地方都提供了类型，如 NavigationView 和 TreeView 导致歧义）。

很高兴听到。 将使从操作系统中弃用它变得更容易。 我希望设置应用程序、外壳和操作系统的其他部分也将迁移到 WinUI 3.0。

并希望将管理员工具、写字板等移植到 XAML 上，尽可能多地重用相同的代码！

@jevansaks好的，明白了，感谢您的反馈！

@mdtauk无需在 XAML 中区分“操作系统”旧控件和新的“WinUI 3.0”平台控件。 一切都在向 WinUI 3.0 转移，正如您所知，操作系统控件不再有功能更新。 在 WinUI 3.0 之后，如果开发人员仍然希望针对旧控件，他们应该使用较旧的 SDK 和 Visual Studio 版本进行开发。 由于前面所述的原因，保持从 XAML 引用两个 Microsoft/Windows UI 控件库的能力只是一个障碍。 此外，随着 WinUI 开发的解耦，最终可以切换到“允许”这样的更改的可持续路径——这甚至不是中断。

编辑：回复前忘了刷新，现在大部分都是多余的。

@robloo我很高兴这将真正取代以前版本的 UWP Xaml。 我也希望操作系统可以为 Inbox Apps 和 Shell 迁移到它。

我还希望有大量的开发人员视频详细介绍迁移到 WinUI 3.0 的过程 - 以及如何使用与 Win32 应用程序相同的生命周期来使用 WinUI 3.0。 没有更多的补水，更好的方法来保存页面状态和导航等。

提供一些示例可能会有所帮助（取决于哪些应用程序计划迁移到 WinUI 3.0），例如将写字板和代码迁移到 WinUI 中内置的新用户界面 - 以及采用 Groove Music 之类的收件箱应用程序并将其迁移到 WinUI 3.0

对于 WinUI 3，应用程序功能在设计语言中的放置需要保持一定的一致性。

在这方面，应用程序设置。

在哪里可以找到应用程序设置？ 我是否单击右上角的齿轮？ 左下角？ 我是否点击右上角的个人资料头像并点击设置？ 我点击左上角吗？ 左下方？ 我要转到“编辑”>“首选项”吗？

真的取决于你是否使用 NavigationView ...

来自：shaheedmalik [email protected]
发送时间：2019 年 9 月 12 日星期四下午 3:48:12
至：microsoft/microsoft-ui-xaml [email protected]
抄送：犀利忍者[email protected] ； 评论[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] WinUI 3.0 开发人员体验和工具 - 需要输入 (#1045)

对于 WinUI 3，应用程序功能在设计语言中的放置需要保持一定的一致性。

在这方面，应用程序设置。

在哪里可以找到应用程序设置？ 我是否单击右上角的齿轮？ 左下角？ 我是否点击右上角的个人资料头像并点击设置？ 我点击左上角吗？ 左下方？ 我要转到“编辑”>“首选项”吗？

—
您收到此消息是因为您发表了评论。
回复此电子邮件直接，查看它在GitHub上https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 ，或静音线程的https：// github上。 com/notifications/unsubscribe-auth/AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ 。

我们如何帮助您在 Visual Studio 中的模板和组件方面提高效率或取得成功？

在 Visual Studio 中使 WinUI/XAML 岛与 C++/WinRT 一起工作不应该花费大量的努力和未记录的项目配置属性。

这一点再怎么强调也不为过，但对我来说最重要的是 WinUI 不仅仅可以渲染到 Windows。

当我看到 Surface Duo 时，我想知道现在微软正在发布一款 Android 驱动的设备，跨平台开发故事会是什么。 Xamarin.Forms 没有削减它的原因有很多。 是时候 Microsoft 完全采用跨平台工具包（如 UNO 平台，但已完成且稳定），我们都知道多年来一直以各种形式要求使用该工具包。 我希望微软有一些计划没有告诉这里的开发人员。

Satya 说：“我们不想只建立体验和一种设备，而是要跨越我们生活中的所有设备。” 如果您希望开发人员像 Panos 所希望的那样参加这次旅行，这是最好的方式。 否则，您会要求开发人员编写两个单独的 UI 来跨越 Surface Duo 和其他家庭成员之间的“体验”。 我认为这对一个“家庭”设备中的开发人员来说不是一个公平的要求。

在每个平台上呈现不同，也就是“原生外观”。

我不明白这个。 请不要，我希望 Fluent Design 做的最后一件事是造成更多的不一致而不是更少。

编辑：原始评论已删除

Satya 说：“我们不想只建立体验和一种设备，而是要跨越我们生活中的所有设备。” 如果您希望开发人员像 Panos 所希望的那样参加这次旅行，这是最好的方式。 否则，您会要求开发人员编写两个单独的 UI 来跨越 Surface Duo 和其他家庭成员之间的“体验”。 我认为这对一个“家庭”设备中的开发人员来说不是一个公平的要求。

这正是我对 Duo 是 Android 感到沮丧的原因。

模板需要开源，以消除其中出现的任何问题区域。

何时将 WinUI 与 WPF 结合使用，以及何时使用以下代码创建新控件：
c# public class MyControl : UserControl { ... }
它将使用 WinUI.UserControl 还是 WPF.UserControl？
我们是否有需要选择以及如何处理呢？

有趣的是，如果要统一 XAML 工具，我们是否有能力创建某种共享的 xaml 文件？
就像是：

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

它应该是某种具有特殊根命名空间的共享方言吗？ （如 Visual Studio 中的共享项目）。 它可能看起来像条件​​ xaml。

它将使用 WinUI.UserControl 还是 WPF.UserControl？
我们是否有需要选择以及如何处理呢？

这应该在您定义的 XAML 中自动发生

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

这告诉编译器它是 UWP。

public class MyControl : UserControl { ... }

这实际上是不正确的。 你应该这样声明

public partial class MyControl { }

不需要继承，因为它由 .g.cs 文件处理，该文件指定了继承以及正在使用的框架。

关于模板，如果不仅仅是一个 Hello World 模板，我会更高兴。 我的意思是微软应该备份一些与客户端应用程序一起工作所需的外围识别框架

@weitzhandler我也很想看到这个！！

C# 和 Cpp/WinRT 项目的 SDK 样式项目也应该是必须的

我认为应该有适用于所有常见 Win32 和 Inbox 应用程序模式的模板。 我脑海中的一个简短列表：

• 丝带
• 主菜单
• 选项卡式文档界面
• 导航视图
• 命令/工具栏
• 顶部导航视图
• 中心/画廊（我知道这有点过时）
• Treeview/MasterDetails（文件浏览器、RegEdit、管理应用程序）

但也应该有通用对话框、页面、设置页面等的项目模板。

我们如何帮助您在 Visual Studio 中的模板和组件方面提高效率或取得成功？

使用 VSCode/Visual Studio 的 C++ 扩展。 我还希望将 VS Code 视为受支持的编辑器，并提供与 Visual Studio 类似的体验。 WinUI 应该是 OSS，VS Code 也是，所以我认为这是可行的。

Template10 和 Windows Template Studio 等工具是缺乏基本功能的迹象。 有了 WinUI3，这些工具的功能就应该到位。 我敢打赌，很多开发人员都在一遍又一遍地做这个基本的脚手架……它应该是框架的一部分。 不需要额外的工具。 也许您甚至应该关闭 MVVM 脚手架，以便在您希望没有的情况下处理那些罕见的情况。

在使用 ASPNET Core 后，我缺少依赖注入。 此功能在 ASPNET Core 中本机存在。 它只是有效，无需您做任何额外的事情。 如果您愿意，您可以轻松添加或修改服务。 但是对于今天的UWP，那么就需要自己搭建或者使用WTS之类的东西来上手，但还是感觉后面是粘上去的。 具有适当本机依赖项注入的 WinUI3 会很有帮助。

我不认为模板系统的存在表明缺乏基本功能，我认为它突出了将这些模板系统组合在一起的支持社区的质量。

Template10 和 Windows Template Studio 等工具是缺乏基本功能的迹象。

我认为这样的事情是对基本功能的扩展。 当然，这样的事情可以在内部进行，但更多的是由核心团队维护和支持。 随着核心团队做得更多，往往意味着他们分散得更细，所以一切都需要更长的时间。 如果 Msft 觉得他们有预算将这样的事情带入主团队，我很乐意与某人谈谈；)

关于简化样式和控件模板的一些想法，例如更容易为内置样式和控件添加自定义行为。 这里的完美示例是Button样式，当我们需要覆盖整个控件模板以更改悬停颜色或使用边框半径时。 直接设置其中一些，例如css ，将防止创建数公里的 XAML 代码

@AntiPasha你听说过轻量级造型吗？ 有了它，您可以轻松更改悬停颜色，而无需重新创建整个样式：

更改按钮的悬停颜色将是：

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

17763 SDK 中还添加了Control.CornerRadius属性，WinUI 团队还引入了可覆盖的资源，以便轻松添加应用程序或页面范围的自定义，而无需重新设置控件样式： https :

有趣的是，如果要统一 XAML 工具，我们是否有能力创建某种共享的 xaml 文件？
就像是：

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

它应该是某种具有特殊根命名空间的共享方言吗？ （如 Visual Studio 中的共享项目）。 它可能看起来像条件​​ xaml。

@Tirraon这是一个非常有趣的例子，但我认为当我们谈论统一工具时，最好从平台将像今天一样存在的心态开始，我们不会试图创建另一个 Xaml 标准相等的。

我们可以使用默认命名空间来区分 xaml 文件属于哪个“顶级”平台，例如，我们可以为每个 XAML 平台使用以下默认命名空间（这些大多是假设的，因此对它们持保留态度😄）：

wpf： xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp： xmlns="http://github.com/microsoft/microsoft-ui-xaml"
阿瓦隆尼亚： xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
联合国： xmlns="https://github.com/unoplatform/uno"
xamarin.forms： xmlns="https://github.com/xamarin/Xamarin.Forms"

因此，要使用 Xaml Islands 将 WinUI 与 WPF 混合使用，您的标记如下所示：

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

你怎么认为？

@stevenbrix
在您的 UWP 示例中，它将呈现两个按钮，不是吗？
我的意思是，例如，当 xmlns=".../xaml/presentation" 是顶级命名空间并且 UserControl wutg StackPanel 在 uwp 和 wpf 中都可用时，那么第二个 Button 是否也可以在两个平台上使用？

当我们谈论统一工具时，最好从平台将像今天一样存在的心态开始

是的，我完全同意。

在您的 UWP 示例中，它将呈现两个按钮，不是吗？
我的意思是，例如，当 xmlns=".../xaml/presentation" 是顶级命名空间并且 UserControl wutg StackPanel 在 uwp 和 wpf 中都可用时，那么第二个 Button 是否也可以在两个平台上使用？

@Tirraon ，我给出的示例纯粹是针对 WPF 应用程序，该应用程序使用 Xaml Islands 逐步更新其应用程序。 它不适用于 WPF 和 WinUI 应用程序之间使用的“标准”标记，这有意义吗？

目前，想要使用 Xaml Islands 的应用程序作者必须为每个岛创建用户控件。 然后，他们通过 WPF 标记中的字符串引用类型，而不是在 WPF 标记中自然嵌入 WinUI 元素。

我现在正在使用手机，但是一旦我靠近我的电脑，我就可以在我提议的前后得到更具体的信息。

@stevenbrix
哦，现在我知道了，谢谢。

@stevenbrix
哦，现在我知道了，谢谢。

@Tirraon很棒！ 很高兴我们在同一页上☺️

抱歉，如果我的想法似乎来自左派，我们一直在早期讨论如何潜在地统一工具，目标是改进 Xaml 岛场景。 你认为这样的事情有价值吗？

FWIW，我绝对认为像你提出的那样的东西是有价值的。 但我正在努力专注于我们可以在 WinUI3/.NET5 时间框架内完成的事情。

弄清楚如何将 WinUI Xaml 呈现到某个管道，该管道将输出转换为本机画布并从本机消息系统接收输入。 像 WinUi.Adapters.DirectX、WinUI.Adapters.WASM、WinUi.Adapters.X、WinUi.Adapters.Android。

在 Launch 时不需要实现所有适配器，只需要支持 Windows 10 所需的那些。

来自：Steven Kirbach通知@github.com
发送时间：2019 年 11 月 7 日，星期四 9:13:46
至：microsoft/microsoft-ui-xaml [email protected]
抄送：犀利忍者[email protected] ； 评论[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] WinUI 3.0 开发人员体验和工具 - 需要输入 (#1045)

@stevenbrix https://github.com/stevenbrix
哦，现在我知道了，谢谢。

@Tirraon https://github.com/Tirraon很棒！ 很高兴我们在同一页上☺️

抱歉，如果我的想法似乎来自左派，我们一直在早期讨论如何潜在地统一工具，目标是改进 Xaml 岛场景。 你认为这样的事情有价值吗？

FWIW，我绝对认为像你提出的那样的东西是有价值的。 但我正在努力专注于我们可以在 WinUI3/.NET5 时间框架内完成的事情。

—
您收到此消息是因为您发表了评论。
回复此电子邮件直接，查看它在GitHub上https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 ，或退订https://github.com/通知/取消订阅认证/AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ 。

是的，目前 XAML 岛场景很糟糕

@sharpninja
你应该看看Uno
https://platform.uno/
它还将为每个平台支持 WinUI 3.0
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
我对 Xaml Islands 并没有真正的经验，通常使用普通的 UWP。 但我绝对需要仔细看看它。
我的提议与 Xaml Islands 本身无关，但总体上与 WinUI 更相关，因为它可以在多个平台上运行。

我的提议与 Xaml Islands 本身无关，但总体上与 WinUI 更相关，因为它可以在多个平台上运行。

@Tirraon ，是的，我完全明白，并且绝对喜欢你的头脑🙌

我已经与@jeromelaban和公司简短地谈过你的提议，而且肯定有兴趣。 目前还没有具体的计划或承诺，因为我们仍处于讨论的早期阶段。 这种输入很棒，可以帮助我们更好地了解它为客户带来的价值 😄

我所说的 XAML 岛场景是指 C++ 场景。 有关我遇到的问题列表，请参阅此线程中我以前的消息。

是的，目前 XAML 岛场景很糟糕

我所说的 XAML 岛场景是指 C++ 场景。 有关我遇到的问题列表，请参阅此线程中我以前的消息。

@sylveon我看到你的评论（下面的链接），是的，这听起来很糟糕。 很抱歉您遇到了这种情况，我相信我们会做得更好。
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

你所经历的很多痛苦都与声音项目系统相关，我知道这是很多人关注的事情（尽管我相当超然）。 你见过这个视频的那几个团队成员对XAML的工具做？ 该链接应在 @michael-hawker 和@marb2000开始进入新的 Xaml 岛体验时开始 YouTube 视频。 我们肯定关心 C++，但我不知道到目前为止我们是否只解决了 .NET 体验，或者 C++ 是否也有改进。 他们可能会对此发表更多评论。

有很多事情可以使 Xaml Island 的体验变得轻松和自然。 我所指的方面是，目前，您在 WPF 中包含 UWP 岛内容的方式是这样的（来自上面的视频）：

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

我认为我们可以做得更好，并提供如下内容：

  <Grid>
   <uwp:SamplePage />
  </Grid>

@stevenbrix

我已经与@jeromelaban和公司简短地谈过你的提议，而且肯定有兴趣。 目前还没有具体的计划或承诺，因为我们仍处于讨论的早期阶段。 这种输入很棒，可以帮助我们更好地了解它为客户带来的价值

有这么多，这么多的兴趣！ （此对话随处可见）如果 WinUI post 3.0 转向跨平台实现，您将获得大量开发人员支持。 看看#1461的讨论就知道了。 在短期内，使用 Uno 平台技术将 XAML/C# 转换为 HTML/WASM 以让 UWP 应用程序在所有平台上运行将是惊人的。 从长远来看，我担心在 Electron 或浏览器中运行对性能的影响，并且有更高效架构的空间。

最重要的是，我知道目前每个人都在忙于 WinUI 3.0。 但是，当公司完成了，如果我们连@jeromelaban，@ marb2000，@jevansaks等人找出最好的方法，使UWP到处呈现将是巨大的。 对于未来的电话会议，这也将是一个非常有趣的社区讨论。

WinUi 是导致 Neo 和 Duo 幸存的唯一合理途径

来自：robloo [email protected]
发送时间：2019 年 11 月 7 日星期四 12:00:07 PM
至：microsoft/microsoft-ui-xaml [email protected]
抄送：犀利忍者[email protected] ； 提及[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] WinUI 3.0 开发人员体验和工具 - 需要输入 (#1045)

@stevenbrix https://github.com/stevenbrix

我已经与 @jeromelaban https://github.com/jeromelaban和公司就您提出的建议进行了简短的交谈，并且肯定有兴趣。 目前还没有具体的计划或承诺，因为我们仍处于讨论的早期阶段。 这种输入很棒，可以帮助我们更好地了解它为客户带来的价值

有这么多，这么多的兴趣！ （此对话随处可见）如果 WinUI post 3.0 转向跨平台实现，您将获得大量开发人员支持。 看看关于 #1461 https://github.com/microsoft/microsoft-ui-xaml/issues/1461的讨论。 在短期内，使用 Uno 平台技术将 XAML/C# 转换为 HTML/WASM 以让 UWP 应用程序在所有平台上运行将是惊人的。 从长远来看，我担心在 Electron 或浏览器中运行对性能的影响，并且有更高效架构的空间。

最重要的是，我知道目前每个人都在忙于 WinUI 3.0。 但是当它完成时，如果我们将 @jeromelaban https://github.com/jeromelaban 、@marb2000 https://github.com/marb2000 、@jevansaks https://github.com/jevansaks和其他人连接到找出使 UWP 随处呈现的最佳方法。 对于未来的电话会议，这也将是一个非常有趣的社区讨论。

—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 ，或退订https://github.com/通知/取消订阅身份验证/AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ 。

WinUi 是导致 Neo 和 Duo 幸存的唯一合理途径

我倾向于同意，但从在 Android 和 Surface Duo 上运行的 Windows 应用程序获得相同的用户界面。 开发人员的干预最少 - 这就是圣杯。

如果 WinUI 有机会成为主要的开发平台，并让 Windows 有机会在长期内避免成为其他平台应用程序的容器。 （对于已建立的大型应用程序，并不总是坏事，但对于 LoB 和下一个大型应用程序......）

我正在创建自己的面向应用程序的语言，并希望支持将 WinUI 与 XAML 和我的代码隐藏语言一起使用。 如果该工具能够为一种语言提供为 XAML 提供代码生成的能力，那就太好了。 如果 XAML 代码生成器将 IL 构建为可以使用任何语言完成的分部类，那就更好了。 这意味着代码生成器将输出可编译的 IL 程序集。

我正在创建自己的面向应用程序的语言，并希望支持将 WinUI 与 XAML 和我的代码隐藏语言一起使用。 如果该工具能够为一种语言提供为 XAML 提供代码生成的能力，那就太好了。 如果 XAML 代码生成器将 IL 构建为可以使用任何语言完成的分部类，那就更好了。 这意味着代码生成器将输出可编译的 IL 程序集。

有 XAML Direct，但目前 C# 和 C++ 支持它。
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

这不是我的意思。 我的意思是代码生成工具的输出是 IL，而不是 C# 或 C++。 这样我的编译器就可以将 XAML 转换为 IL，然后继承该类。

@sharpninja如果它还可以生成 LLVM 字节码而不仅仅是 C++ 代码，那也将是有益的。

这样我们就可以将它与 MIDL 和 XLang 结合起来生成 COM 库和 WinMD 文件，以便在所有 XLang 支持的场景中使用。

带着我的 C++ 帽子，我希望看到关于 C++ 的 WinUI 工具，微软最终会赶上 C++ Builder 自 90 年代中期以来一直在做的事情。

为基于 C++ 的开发提供实际的 RAD 工具。

C++/CLI 失败了，尽管在表单中有一些解决方法。

C++/CX 似乎就是这样，但它仍然需要比 C++ Builder 能够做到的更多的努力。

现在 C++/WinRT 可能是标准的 C++17，但桌面开发人员的整体体验感觉像是降级，随着必须手动编写的样板增加，额外关心 COM 类型如何超越 ABI 边界以及缺乏设计器支持。

所以我暂时还在使用 C++/CX，因为我觉得没有处理 MIDL 编译器所需的所有样板，以及 COM ABI 支持。

另一方面，带着我的 .NET 帽子，我希望看到像 DirectX 这样的仅限 C++ 的库最终作为 WinUI 组件公开，有些人喜欢 Blend，并记住 F# 据说也是来自 Microsoft 的 .NET 语言。

我在尝试切换到 WinUI 时遇到了很多困难。 目前有许多第一和第三方库都没有使用 WinUI，并且对它们的依赖会出现问题。 例如，行为 SDK。

这是我在 UWP Community Discord 中谈论 StatusBar 时的一个想法..

在 Visual Studio 中，让工具箱包含 UWP 中缺少的 WPF 控件条目，并在选择这些条目时显示一个弹出窗口，说明如何模拟传统控件。

这个想法来自于希望简化来自 WPF（或其他框架）的人们的过渡的愿望，他们希望看到某些控件，而找不到这些控件会发现它是一种不和谐的体验。 怎么知道 CommandBar 可以像 StatusBar 一样使用？ 我认为我们需要让人们尽可能简单地迁移到 WinUI。 这可能有助于填补一些空白，而无需实际开发所有缺失的控件。

编辑：
为了完整起见，这里是我所说的关于状态栏的其他内容。

回复：StatusBar - 我是从尝试 UWP 的传统框架用户的角度思考的 - 并且看到它没有 StatusBar - 仍然是许多应用程序的主要内容。 是的，CommandBar 甚至可能更好。 但是人们不知道 CommandBar 是什么，或者可能会猜测它是别的东西。 上面有人甚至建议我添加一个网格，将其放在底部，使其高一排并添加各种控件来显示内容。 因此，即使现有的 Xaml 设计人员似乎也不了解 CommandBar。 不管怎样，也许你是对的，也许 CommandBar 更好，但 Paul Thurrot 没有在他的 UWP 记事本应用程序中使用它，他使用了网格。 因此，似乎 CommandBar 没有被传达为 StatusBar 的替代品。 临时（或新）开发人员仍在寻找 StatusBar 而没有找到它。 我知道 Paul Thurrot 不是开发人员，但您明白我的意思。

如果代码片段也通过正常用例注入到 xaml 中，那就太好了。

来自：Gavin-Williams [email protected]
发送：2020 年 2 月 18 日，星期二 7:05:39 PM
至：microsoft/microsoft-ui-xaml [email protected]
抄送：犀利忍者[email protected] ； 提及[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] WinUI 3.0 开发人员体验和工具 - 需要输入 (#1045)

这是我在 UWP Community Discord 中谈论 StatusBar 时的一个想法..

在 Visual Studio 中，让工具箱包含 UWP 中缺少的 WPF 控件条目，并在选择这些条目时显示一个弹出窗口，说明如何模拟传统控件。

这个想法来自于希望简化来自 WPF（或其他框架）的人们的过渡的愿望，他们希望看到某些控件，而找不到这些控件会发现它是一种不和谐的体验。 怎么知道 CommandBar 可以像 StatusBar 一样使用？ 我认为我们需要让人们尽可能简单地迁移到 WinUI。 这可能有助于填补一些空白，而无需实际开发所有缺失的控件。

—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 ，或退订https://github.com/通知/取消订阅身份验证/AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ 。

开发者故事应该包括一种比较列表。

Win32 应用程序固有的概念，因此状态栏、工具栏、菜单、抓手、选项卡等在一个列表中，而 WinUI 等效项在另一个列表中。

页面本身包括来自两者的代码示例，以展示如何将现有应用的 UI 移至 WinUI。

未解决的问题
如果我们提供一个自动执行步骤 1-3 的迁移工具，会有好处吗？

是的。 我支持 1 个“旧版”Windows 窗体应用程序（旧版意味着没有重新编写的预算）和 2 或 3 个旧版 WPF 应用程序。 WinForms 应用程序可能会搁浅，但帮助将 WPF 应用程序快速移植到 WinUI 3 的工具会很棒！

MSIX 是适用于所有应用程序的现代打包方法。 对于 Win32 中的 WinUI，我们应该支持 ClickOnce 吗？ 我们还应该支持哪些其他包装方法？ 尤其是Win32下的WinUI

我们目前使用 ClickOnce 将应用程序发布到我们用户的桌面。 仍然需要某种自动更新模型。

@杰夫施万特

这些步骤是关于将使用早期版本 (1-2) 的 WinUI 项目转换为版本 3。

以自动化方式将 WPF 应用程序转换为 WinUI 应用程序并不是特别可行（无需大量工作，但即便如此，它也极易出错）。

我希望这是发布此请求的正确线程。

Rust 现在迫切需要一个合适的 UI 框架。 如果 WinUI 将来可以通过原生 SDK 和一些工具支持 Rust，那就太好了。

我希望这是发布此请求的正确线程。

Rust 现在迫切需要一个合适的 UI 框架。 如果 WinUI 将来可以通过原生 SDK 和一些工具支持 Rust，那就太好了。

好消息，Rust/WinRT 正在开发中，这将使 Rust 应用程序能够使用 WinRT API，如 WinUI！ 看看https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

@jevansaks嘿，感谢您的回复！ 是的，我知道 Kenny 在 Rust/WinRT 上工作，但我想知道 WinRT 是否是 WinUI 将支持的唯一 API 层？ 我不确定这如何与桌面应用程序的 WinRT API 使用仅在 Windows 10 1903 中可用这一事实相吻合，而 WinUI 旨在支持旧版本的 Windows 10。

Rust/WinRT（如 C++/WinRT）应该一直适用于 Windows 7。WinRT 本身一直适用于桌面/win32 应用程序。 只有某些 API 具有存储/uwp/打包要求（而不是整个 WinRT）。 只要 WinUI 没有这些要求，您就可以在任何受支持的平台上通过 C++/WinRT 和 Rust/WinRT 从桌面应用程序使用 WinUI。

WinUI 桌面应用程序应该支持动态磁贴和磁贴更新 - 使用简单的示例和 SDK 工具可以比今天的 UWP 应用程序更容易创建磁贴。

我不确定这如何与桌面应用程序的 WinRT API 使用仅在 Windows 10 1903 中可用的事实相符

WinUI 桌面现在是为 WinUI 3.0 设计的，这应该使普通的 Win32 应用程序能够使用 WinUI 下层（当前计划下降到 1803）。

Windows UI 应该至少支持主要的 MVVM 框架——MVVM Light、Prism 和 Caliburn。 不幸的是，您记录的问题与更改 INotifyPropertyChanged 和 INotifyCollectionChanged 破坏 ObservableCollection肯定会破坏 MVVM Light，也可能会破坏其他两个框架。 以为你应该知道。

不幸的是，您记录的有关 INotifyPropertyChanged 和 INotifyCollectionChanged 的​​更改破坏 ObservableCollection 的问题肯定会破坏 MVVM Light，并且可能还会破坏其他两个框架。 以为你应该知道。

谢谢@terrycox！ 我们知道，这将由 WinUI 3.0 RTM 解决，最好在此之前的预览版本中解决 ;)

@terrycox Windows UI 应该至少支持主要的 MVVM 框架——MVVM Light、Prism 和 Caliburn。 ...您记录在案的问题

是的，它应该修复记录在案的问题，但不需要 .Net UI 库（包括 WinUI）来支持 MVVM 框架。 它只需要支持代表 UI 元素的对象。 .Net MVVM 或反应式框架是一种基于表示数据的对象生成和更改表示 UI 的 .Net 对象的方法。 双方都不需要知道对方。 任何框架都可以与任何 UI 库结合使用。

但是不需要 .Net UI 库（包括 WinUI）来支持 MVVM 框架。

但是 UIElements 知道的事件和接口之类的东西是必要的，这就是破坏的原因。

来自：Charles Roddie [email protected]
发送： 2020 年 3 月 25 日，星期三 2:28:46 PM
至：microsoft/microsoft-ui-xaml [email protected]
抄送：犀利忍者[email protected] ； 提及[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] WinUI 3.0 开发人员体验和工具 - 需要输入 (#1045)

@terrycox https://github.com/terrycox Windows UI 应该至少支持主要的 MVVM 框架——MVVM Light、Prism 和 Caliburn。 ...您记录在案的问题

是的，它应该修复记录在案的问题，但不需要 .Net UI 库（包括 WinUI）来支持 MVVM 框架。 它只需要支持代表 UI 元素的对象。 .Net MVVM 或反应式框架是一种基于表示数据的对象生成和更改表示 UI 的 .Net 对象的方法。 双方都不需要知道对方。 任何框架都可以与任何 UI 库结合使用。

—
你收到这个是因为你被提到了。
直接回复本邮件，在 GitHub 上查看https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 ，或者退订https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ 。

Dotnet cli 工具应与a一起使用。 网络核心sdk。
dotnet new 和 dotnet build 等命令应该就够了，没有安装 Visual Studio 的硬依赖。 请，全面加入.Net Core时代！

• 如果 xaml 设计器速度快就好了。 当前的 XAML 设计器很慢并且总是抛出一些错误，说发生了一些异常并且它不会工作。 请更正并提供强大的设计师。

• 目前 uwp 没有任何可以检测锁定屏幕的 API。 如果我们提供了可以检测锁屏并给出布尔值作为返回值的 API，那就太好了。 我们还应该能够在锁定或解锁后显示一些动画和徽章。
  -现有的锁屏 API

• 我的问题解释了

沿着@JensNordenbro的评论，这是否有可能仅适用于 Vs Code？

我希望看到一个应用程序模板，该模板使用引用 .NET 5 商店主机应用程序的 WinUI 3.0 UI 创建 .NET 5 应用程序。 这将允许减少 .NET 5.0 的冗余安装

在 WinUI 桌面应用程序中，如何从 muxc.Window.ThisPtr 到 hWnd 再到本机 Win32 窗口？

我刚刚尝试了适用于桌面的 WinUI 3 Preview 1 的 2020 年 5 月新模板，因为我喜欢这个想法。

但我有一个问题。 随着 WinUI 成为 Windows 上的本机 UI 平台，我对它实际上也成为 Windows 10 的一部分缺乏沟通感到惊讶？

我生成的 Hello World 应用程序大约有 120 MB 大。 当然，空间很便宜，但我在这里没有对自己的依赖。 其中，WinUI 占用了大量空间，大约与包含的 .NET 5 本身一样多。 这仅适用于 x64 构建。 将 x86 包含在多平台包中并将其大小加倍。 添加一些其他依赖项，我们可能很容易看到要打包分发的 300 MB 应用程序。

为什么 WinUI 3 不只是 .NET 5 的 Windows 版本的一部分？ 它是 .NET Core 模块化工作的一部分吗？ 但如果没有，它的位置在哪里？ 真的在每个应用程序的文件夹中？ 作为官方的 Windows 10 用户界面......？

或者它将来会成为 Windows 10 的一部分吗？ 如果 WinUI 更像是一个系统库，并且 .NET 5 将在稍后开始随 Windows 一起提供，那么我们将转而关注相对较小的应用程序。 但希望这至少是 Windows 10X 的故事，也许以后 Windows 10 non-X 也是如此？ 不包括这两个库以及 Windows 10 SDK C#/WinRT 桥 DLL，应用程序大小会下降到 1-5 MB。

@ryandemopoulos在 Discord 上表示 WinUI 将作为框架包交付，因此使用 Store 或 MSIX 进行分发的应用程序将不必携带自己的 WinUI 版本，因为它们都将共享相同的 WinUI 副本。

使 WinUI 成为 Windows 本身的一部分将破坏 WinUI 与操作系统分离的意义。

“可靠可用，而不是应用程序的大小”是问题。 我希望 .NET 5 的分发方式类似。

@lmcdougald我邀请您在.NET Core 安装程序中打开一个问题，并请求 .NET 5 也使用框架打包进行服务。

@jonasnordlund还有另一个讨论 #2500，我们正在讨论 WinRT 运行时部署。 也许你会在那里找到一些答案。 :)

@marb2000我已经打开了一个问题，但老实说我很困惑。 这对于提供 Windows 10X 的任何应用程序来说不是必不可少的吗？

这是几个功能的汇编，其中一些不是直接的 WinUI，但它们的缺乏直接影响任何 .NET 客户端开发的体验 - 包括 UWP 客户端，尤其是 LoB 应用程序客户端。

• 对我来说，首要任务是培养 Uno 平台。 对我来说，这就是使 UWP 相关的原因，如果没有 Uno，我会在 XF 或其他技术上妥协。 （https://github.com/microsoft/microsoft-ui-xaml/issues/2024）
• 要从 ViewModel 使用的抽象客户端身份管理 API (https://github.com/microsoft/ProjectReunion/issues/31)
• 完整的数据注释支持、验证和 UI 标题、字符串长度、必填属性、只读字段、水印等（https://bit.ly/3gcMJ3a）
• 改进 OData，使其成为过去 RIA 服务的合适替代品。 例如：支持属性生成、接口实现、泛型类型、XML 文档（https://github.com/OData/odata.net/issues/1746）
• 引入 WPF 中所有缺失的功能
• x:Bind还应该具有Binding所有功能，例如范围或嵌套绑定（https://github.com/microsoft/microsoft-ui-xaml/issues/2237）
• 热重启 (https://github.com/microsoft/ProjectReunion/issues/44)
• 不仅仅是简单的 Hello World 模板。 像这样的适应用户登录，MVVM，路由，x-plat项目（如Uno-Platform）等。换句话说，请给WTS更多的权力。
• XAML WYSIWYG-editor layout features like in WinForms，例如停靠，间距等 - 这似乎完成了！ ❤

感谢您的编译@weitzhandler ，非常方便。

WinUI 团队与 Uno 产品团队（非微软）、Xamarin Forms/MAUI 团队和 React Native 有着很好的关系。 我们积极与他们合作，并祝愿他们未来成功。

关于缺少的 WPF 功能，您能列出您最喜欢的功能吗？ 缩小 WPF 和 WinUI 之间的差距是我们的目标之一。 不过，这将需要几个版本。

Apropos 更复杂的模板。 Window Template Studio有这个使命。

我提出了一个问题，试图收集与 WPF 相比缺少 WinUI 的区域 #719 @weitzhandler @marb2000

Apropos 更复杂的模板。 Window Template Studio 有这个使命。

@marb2000我们可以将 Window Template Studio 带入我们的 VSIX 吗？ 或者反之亦然？ 只是使用 Window Template Studio 作为运送所有 WinUI3（和 Project Reunion）模板的工具吗？

Apropos 更复杂的模板。 Window Template Studio 有这个使命。

@marb2000我们可以将 Window Template Studio 带入我们的 VSIX 吗？ 或者反之亦然？ 只是使用 Window Template Studio 作为运送所有 WinUI3（和 Project Reunion）模板的工具吗？

👀 @crutkas @sibille

我建议花一些时间使用 C++ Builder (VCL/FMX) 和 Qt Creator/Design studio，了解 C++ 和现代工具的可能性。

理想情况下，WinUI 将提供与这些产品类似的工具，这些工具今天已经为用 C++ 编写的跨平台 GUI 提供了。

我关心的是 .NET 开发经验，以及我被迫使用 C++ 的用例的类似经验，无论出于何种原因，我们都无法使用。

C++ Builder 和 QtCreator 实现了这样的体验，如果 .NET 开发人员在面临不得不花几天时间编写 C++/WinRT 代码时感到宾至如归，那将是受欢迎的。

为什么要针对 .NET 开发人员？ C++ XAML 体验很糟糕，无论您是 C++ 还是 .NET 开发人员都无所谓。

我相信，如果他们开辟道路以在桌面、Web（边缘）、移动和物联网上运行相同的 XAML，那将会很棒。

我们什么时候才能在没有 C#、Xaml 或设计器的 C++ 项目中使用 WinUI 3？
还有关于WinUI 3的c++核心开源日期的消息吗？

编辑：我想我的第一个问题得到了答案，看起来 WinUI 3.0 Preview 1 中有一个 c++ WinUI 3 项目模板：

安装 .vsix 扩展后，您可以通过搜索“WinUI”并选择可用的 C# 或 C++ 模板之一来创建新的 WinUI 3.0 项目。

我希望 WinUI 改进的用例是为前线 IT 支持人员制作基于 GUI 的小型工具，这些工具通常是用 PowerShell 编写的。 能够在 Visual Studio Code 中制作这些类型的工具会很棒。 即使是基于 C# 的 VSCode 开发选项也将是一个很好的步骤。 对于这种情况，成熟的 Visual Studio 感觉相当沉重和复杂。

目前，企业环境正在使用以下工具：

• https://poshgui.com/ （基于 Web 的 XAML 向导）
• Sapien PowerShell Studio 2020 （专有）
• Admin Script Editor (ASE) （现已废弃的项目）

此处描述了其他常用的“将 Visual Studio 用于 XAML”模式：

• 为 PowerShell 脚本创建一个简单的图形界面
• 如何为您的脚本构建 PowerShell GUI

我的问题是在他 5 月份提出的@mqudsi问题的背景下，但没有人回答。

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

由于这是一个桌面应用程序，我们不能使用 ICoreWindowInterop，我尝试了诸如new HandleRef(this, ThisPtr)之类的随机赃物，其中“this”的类型为 Microsoft.UI.Xaml.Window，但一直看到无效窗口句柄的 errno。 一旦我最终获得了那个 hwnd，我就可以尝试使用更多的 COM 来改变窗口样式并与其他人分享，这样他们就不会感受到我现在所做的痛苦:)。

对于任何感兴趣的人，这是我用来获取主窗口的 hWnd 的快速方法，以便我可以使其无边界。 WindowStyle = None 的 WPF 等效项的完整解决方案在这里。

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

目前，当您的 WinUI 处于桌面进程时，似乎没有一种容易找到/记录的方式来获取 hWnd，这就是我转向我使用的方法的原因。 似乎工作得很好。

我认为 UWP 和通用 Windows 作为术语可能应该消失。 这些术语带有一些不幸的包袱，导致开发人员回避。

也许我们可以用 WinUI (Win64) 替换模板 WinUI (Universal Windows)？ 然后可以选择桌面还是商店？

Win64 令人困惑 - 这意味着 Win32 API 仅支持 32 位，相反，UWP 仅支持 64 位，两者都是错误的。

Win32 名称本身已经让很多初学者感到困惑，我们不需要 Win64 来让事情变得更糟。

@VagueGit我学到的是，选择正确的名字和制作故事是更复杂的事情之一。 我们（微软）应该提供正确的产品（和故事）来帮助你取得成功，而不是更换一个名字。 UWP 作为 Win32 是一个众所周知的术语，因此我们应该继续使用它们。

这是我们的方法（非常简化）：

WinUI 可用于针对不同设备的两种“类型”应用程序：

• 您的应用程序针对具有大量输入和外形因素的大量设备。 然后使用 UWP。 UWP 就是为此而创建的； 因此，您必须满足包装模型、存储、应用程序模型、安全容器等要求。
• 您的应用程序仅面向桌面，并且需要对操作系统的完全访问权限。 使用 Win32 或桌面（这是 Visual Studio 调用 WPF、WinForms、MFC、应用程序的方式）。

UWP 应用中的WinUI 和桌面应用中的 WinUI （或 UWP WinUI 应用或桌面 WinUI 应用）更符合项目模板的目标。

@marb2000命名事情很难，同意。 但不幸的是，有些名字是有毒的，应该被抛在后面。 这就是为什么不时对产品进行更名的原因。 UWP 是其中之一，但这只是我的观点......以及我与之交谈的每个人。 但是你去了。

我们有一个要迁移到 WinUI 的 UWP 应用。 我们不使用 Win32 api，我们只针对桌面，我们不想使用商店。 这怎么合得来？

@marb2000命名事情很难，同意。 但不幸的是，有些名字是有毒的，应该被抛在后面。 这就是为什么不时对产品进行更名的原因。 UWP 是其中之一，但这只是我的观点......以及我与之交谈的每个人。 但是你去了。

我们有一个要迁移到 WinUI 的 UWP 应用。 我们不使用 Win32 api，我们只针对桌面，我们不想使用商店。 这怎么合得来？

该应用程序究竟是为谁准备的？

作为一个特意使用UWP应用程序的消费者，如果应用程序不在商店里，我可能不会去接触它，更不用说看到它了。

别担心@shaheedmalik我们不会要求你碰它:-)。 我们编写业务应用程序。 Win32 和 UWP。 我们有一个 UWP 应用程序，它已经在商店中存在了几年，但在商店中看不到。 我们拥有可追溯到 30 年前的成熟商业客户群。 他们对我们的 UWP 应用感到满意，但对商店体验不满意，因此我们将其移出商店。

所以我们知道 Win64 商业应用程序有市场，我们相信我们是少数提供商业客户愿意付费的 Win64 应用程序的商业开发者之一。 我知道这个线程上有一些开发人员走通用 Windows/多平台路线，但他们非常罕见。 根据我的经验，大多数业务开发人员都针对特定的外形尺寸。

那么从一个在UWP上投入巨资并且在UWP上取得商业成功的开发公司的角度来说，也许WinUI（桌面）和WinUI（商店）的模板？ 您只需关注技术媒体即可了解 UWP 被视为开发平台的糟糕程度。

@VagueGit
“我们有一个 UWP 应用，我们想迁移到 WinUI。我们不使用 Win32 api，我们只针对桌面，我们不想使用商店。这如何适合？”

那么您是否想将 UWP 迁移到 WinUI 3 并部署到应用商店之外？ 一个天真的问题：您是否尝试过 MSIX 的侧载？ 除了商店阻止您使用 UWP 之外，还有其他原因吗？

@VagueGit
“所以我们知道 Win64 商业应用程序有市场。”

一个问题，Win64代表了很多东西。 例如，应用程序为 x64 编译。 Win64 对您意味着什么？

@marb2000 UWP 对业务报告的支持很差。 我们认为品牌重塑可能有助于启动报告编写器等第三方工具的开发。 我们玩过侧加载，但直到 20H1 才可行，因为默认情况下没有启用侧加载。

我们认为 Win64 是 Windows 的前进方向。 Micro$ 过去曾试图将 Win32 定位为传统，但没有成功，现在又回到了那个位置。 但最终 Win32 必须消失，根据我们的判断（我自己说的是经过 30 年的 Win32 开发）。 我们设法克服了 UWP 的大部分限制，以提供公司将购买的商业应用程序。 我们担心，如果不进行品牌重塑，UWP 的另一次迭代将具有有限的吸引力。

正如@marb2000的混淆所显示的那样，Win64 一词已经（不好）使用了。 我之前也指出过。

我同意可能需要更名，但 Win64 是一种糟糕的方式。 在没有正式的东西之前，你应该使用 UWP 这个词来让每个人都理解。

@sylveon UWP 被大家理解为失败。 我们喜欢它，但很少有人喜欢。 这就是为什么品牌重塑很重要的原因。 您如何看待 WinUI (Deskop) 或 WinUI (Store) 作为项目模板？

WinUI (Store) 并不好，因为您还可以在商店中发布 Win32 应用程序，或者在商店外发布 UWP 应用程序。 然而，WinUI（桌面）很好。

@sylveon WinUI (Store) 不排除针对商店的其他项目。 这只是意味着您希望从支持通过商店发布的一组功能开始。

这足以让初学者感到困惑。

这并不意味着针对此线程中的任何特定人员，而是针对桌面应用程序开发人员/公司所有者的我自己的观点。

我从来没有被什么东西命名过。 我只关心它具有哪些功能以及它的支持程度。

我认为也有很多开发人员（包括我在内）在我们这里提到 MAUI 之类的术语时会变得兴奋，但当我们意识到它仍然是相同的代码库时，他们会立即失望。 品牌重塑表明“嘿，看，我们正在构建这个全新的东西，它从一个与阻止您访问 xyz 的代码库完全不同的代码库开始”。 我喜欢看到的是一大堆功能改变了，这些功能抵消了我或其他任何人的挣扎。

平台就像任何产品或品牌一样随着时间的推移而发展。 我在已经存在了几十年的品牌和名称中找到了安慰，因为它自动暗示了 LTS。 虽然我确实意识到名称更改有时是必要的，但它们也提醒开发人员放弃（Silverlight）。 有很多汽车模型多年来一直受到问题的困扰，但最终成为人们喜爱和受人尊敬的品牌。 即使你不喜欢以前的经历，也有很多熟悉的东西要说，因为你知道会发生什么。 只要问题解决了，这才是最重要的。

我认为至少有两个受众需要考虑； 开发人员和最终产品用户。 作为开发人员/企业主，如果我有一个客户需要应用程序，并且他们对底层技术名称感到厌烦，那么我的工作就是让他们相信该名称所代表的产品已经成熟以及他们在过去已更新。 另一方面，如果我说“看看有一个名为 WinUI 或 MAUI 的新东西”并且他们已经拥有我们为他们开发的 WPF、UWP 或 Xamarin 产品，他们的可预见的反应是“哦，太好了，现在我们的应用程序是用 2,3 或 4 种不同的技术编写的”。 这就是我必须出售它们的地方。 考虑到所有客户都是不同的，无论您保留名称还是更改名称，我都会遇到阻力。

最后（对我而言）重要的是我们拥有编写具有 LTS 的吸引人的、功能丰富的应用程序所需的工具。 当我看到产品达到最后期限时，我会很兴奋，当产品发布时我会阅读新功能和问题解决列表。 自 2016 年以来，我一直喜欢 NetCore/Net5（更名 LOL）。（顺便说一句，在我说服他们迁移到 NetCore 一年后，试图告诉我的客户 .Net5 是我们计划的目标也不容易！）

现在，我只想快进到可以用 XAML 方言编写桌面应用程序并获得与 UWP/WinUI 提供的相同渲染性能（没有 UWP 沙箱）的点。 出于这个原因，由于 9 月预览的下降，我将开始试驾 Avalonia。 在通过 SkiaSharp 听说渲染性能时，我喜欢 WPF 的相似之处。

几年后，当 UI 开发的选项稳定下来时，这将是令人兴奋的。 他们可以随意命名项目模板，这不会改变我对缺乏功能的看法。

我很感激你们。

我明白 jtbrower 在他的电子邮件中所说的话。 他和我们一样的公司是少数成功走上 xaml 道路的公司之一。 我们不需要相信这些好处。

但尽管它可能很好，但 xaml 对 Micro$ 来说是一场灾难。 绝大多数开发人员要么继续使用 WinForms，要么完全转向 Web 开发。 自 UWP 以来，开发人员的外流恶化了。

要使 xaml 技术可持续，Micro$ 必须赢得数百万他们未能加入的开发人员。 对于那些开发人员、工具供应商和技术媒体来说，UWP 是一个死胡同。 UWP 的另一个迭代不会赢得他们的青睐。

@VagueGit但开发人员很想知道重命名的产品是一样的。 他们知道 MAUI 是重命名的 Xamarin Forms。 事实上，他们似乎说 MAUI 是一个被盗的名字。 我认为您无法通过更名来激励典型的开发人员。 我们都想要功能，不是吗？ 您是否更愿意看到 UWP 允许多个 Windows，或者允许完全信任？ 如果他们两者都做，我们都可以针对 UWP，并可能保留商店应用程序的沙箱。 我只是在大声梦想什么会让我兴奋起来！ 特征！！

绝对同意你 jtbrower。 我也很感谢你对我的帮助，我希望其他人批评他们的想法。 但是如何向开发人员和工具供应商表明存在两种不同的 UWP，即应用商店和桌面？

所以无论如何，那些想要沿着 UWP 路径继续走下去的人可以从 UWP Store 模板开始，但是那些想要 64 位桌面，而不是沙盒和完全信任的人……那不是 UWP 吗？

UWP 在市场上被视为瘫痪。 当 Micro$ 退出在 UWP 中构建自己的应用程序时，除了我们这些顽固分子之外，所有人都放弃了 UWP。

开发市场不会关注 UWP 的发展。 64 位桌面，没有沙盒和完全信任，不仅仅是更名； 这是一个不同的范式。 但如果它仍然被称为 UWP，那些注销 UWP 的人将不会注意到它。

@VagueGit我很高兴你在 UWP 上取得了成功。 命名很困难，而且我们称其为“通用 Windows 平台”并且绝大多数 Windows 开发人员并不真正站得住脚这一事实使它，嗯，不是很“通用”。 Project Reunion 的准确总结就是解决这个问题，并使所有 Windows 开发人员真正可以访问 UWP 的各个方面。

我同意 UWP 有一个坏名字，如果你在搜索引擎中输入短语“UWP is”，Bing 或 Google 会给你的第一个自动建议是“UWP is dead”。 但是，我确实认为@marb2000是正确的，我们应该继续使用这个名字，尽管它背负着包袱。

话虽这么说...

今天，桌面项目的许多方面将能够使用我们过去定义为“UWP”的不同部分：

1. UI 堆栈（又名 WinUI3）
2. MSIX 包装
3. 捷运资源

一旦 CoreApplication 被取消，那么 UWP 和桌面之间的唯一区别将真正是您为应用程序选择的沙箱模型以及您能够定位的设备。

我们已经讨论了对项目模板进行修改，并拥有更准确地描述这一点的类似向导的体验。

@JeanRoca是负责这

我喜欢 WinUI 桌面模板的想法。 比 Win32 更合适，更具前瞻性。 这是我们将开始使用的模板，而 Win32 建议使用 32 位约束。 WinUI Desktop 有望在媒体和开发人员中获得一些关注。

当 UWP 应用在商店外发布时，包是 .appinstaller。 如果我们将该应用程序升级到 Win UI Desktop，安装程序包将从 appinstaller 更改为 msix。

假设我们保持应用程序包中的详细信息相同并适当地提高版本，Windows 会识别这是同一应用程序的新版本并保留本地数据，还是将其安装为不同的应用程序？

根据我的理解，WinUI 3.0 永远不会从 .NET Framework <= 4.8 使用。 因此，如果我们谈论 WinUI，我们要么谈论 .NET Native 或 .NET 3.1/5+（或另一组绑定）。

关于如何进一步推进/询问 .NET 5（或者我猜现在是 6）的框架打包的任何建议？ 我打开了一个问题，但没有得到任何回应。 在应用程序中捆绑 .NET 5 是不可能的。

@stevenbrix

一旦 CoreApplication 被取消，那么 UWP 和桌面之间的唯一区别将真正是您为应用程序选择的沙箱模型以及您能够定位的设备。

不幸的是，另一个很大的不同是 .NET 开发人员被迫为像 DirectX 这样的 API 使用 C++，尽管他们是基于 COM 的，但他们的团队显然拒绝使它们与 UWP 兼容。

在这个过程中，回到使用类似记事本的良好体验手动编写 MIDL 并复制文件的生产力时代，显然 Windows 团队不能放弃像开发经验一样的 ATL，而是为 C++ 工作流提供类似 NET 的体验。 C++/CX 与 C++ Builder 太接近了，所以它必须以 ISO 的名义被杀死，幸运的是我们可能会在 C++23 和 2025 年在 VS 中获得它们。

我怀疑到那时有人会关心 UWP，除非有适当的开发经验来清除所有这些错误行为。

同样向我们抛出 GitHub 问题的还有关于向哪个团队提供反馈的问题，这是一种很快就会失去兴趣的方法。 我只是碰巧太在意了。

无法修改 DirectX API 以实现 WinRT 兼容性，因为这对现有使用者来说将是一个重大的 API 中断，而这种情况是不可能发生的。

有多个可用于 DirectX 的托管包装器，例如TerraFX （原始 1:1 绑定）或Vortice （更像 C# 风格的 API 包装器）。

至于CX，它必须消失。 特定于编译器的语言扩展很糟糕并且不受欢迎。 它严重阻碍了代码的可移植性，在 C++ 标准支持方面往往落后，并且需要从现有库进行完全垂直集成。 替代方案 WRL 非常难以使用且过于冗长。 因此，很多人（包括 DX 部门）不想编写 WinRT API 也就不足为奇了。

C++/WinRT 是一个更好的解决方案，不幸的是它不得不带回 IDL（但目前是必要的邪恶）。 C++ 团队在标准支持方面做得比以前好得多，所以如果我们在 C++23 最终确定之前真正获得元类也就不足为奇了，这应该会从根本上改善开发人员的用户体验。

@西尔文

Windows 开发社区无视任何来自 Redmond 的东西，并以此作为生产力下降的理由，请不要感到惊讶。

CX 也发生了同样的情况……它基本上没有使用，因为 C++ 开发人员不喜欢专有语言扩展。

假设我们保持应用程序包中的详细信息相同并适当地提高版本，Windows 会识别这是同一应用程序的新版本并保留本地数据，还是将其安装为不同的应用程序？

@VagueGit ，这是一个很好的问题。 归根结底，安装 UWP 和桌面应用程序的技术是相同的。 我觉得答案是肯定的？ 我认为在最近的 SDK 中，甚至 UWP 应用程序都有 .msix 扩展名（我可能错了，所以不要引用我的话）。 我确定您可以在本地尝试一下并找出答案？ @adambraden仅供参考。

关于如何进一步推进/询问 .NET 5（或者我猜现在是 6）的框架打包的任何建议？ 我打开了一个问题，但没有得到任何回应。 在应用程序中捆绑 .NET 5 是不可能的。

@lmcdougald我想我知道您指的是哪个问题（但我找不到）。 会有一个，但我想它会在 .net6 时间范围内。 每个人都知道这是需要做的事情。

在这个过程中，回到使用类似记事本的良好体验手动编写 MIDL 并复制文件的生产力时代，显然 Windows 团队不能放弃像开发经验一样的 ATL，而是为 C++ 工作流提供类似 NET 的体验。 C++/CX 与 C++ Builder 太接近了，所以它必须以 ISO 的名义被杀死，幸运的是我们可能会在 C++23 和 2025 年在 VS 中获得它们。

同样向我们抛出 GitHub 问题的还有关于向哪个团队提供反馈的问题，这是一种很快就会失去兴趣的方法。 我只是碰巧太在意了。

@pjmlp我很欣赏你的诚实和热情。 我完全同意当前的 C++ 体验低于标准。 我们已经做了很多事情来使 C++ 体验更像 .NET，但正如@sylveon提到的那样，它们是有代价的。 我们最终决定，如果我们想花费工程上的努力使 C++ 变得更好，我们应该将其投入到推动 C++ 标准中。 不幸的是，元类是一个出路，我们正在讨论在此期间改进体验的方法，因为我同意你的看法，我们不能等那么久。

感谢您的回复——我对“每个人都知道这是需要做的事情”感到满意，我将忍受膨胀的二进制文件一年左右。

@stevenbrix和@VagueGit - 你应该仍然可以为你的 msix 包使用 appinstaller 文件。 appinstaller 文件只不过是一个 json 文件，为您的包提供 uri。 既然您提到了企业场景，您可以为内部位置适当地自定义应用程序安装程序 uri，或者使它们对于外部访问也不同——所有这些都依赖于您的 CDN。 关于版本控制 - 如果包标识相同，则对于打包的应用程序是，然后安装新版本将可以访问现有的应用程序数据。

@stevenbrix @VagueGit我会回复我目前在向导方面的信息，比如经验。 我对这个角色还很陌生，所以请随意接受我所说的一切。 话虽如此，我的团队目前正在推动Windows Template Studio的努力。 此应用程序目前允许您使用我们的向导中的现有模板创建新的 WPF 或 UWP 应用程序，其中包含您想要的页面和框架。

此应用程序未来的目标和当前计划是统一和改进所有用户的开发体验。 我们目前正在使用 WinUI 3 为桌面应用程序开发模板。您可以在此处找到跟踪问题。 我们也在讨论为 UWP 做同样的事情，以便我们的用户可以在时机成熟时轻松迁移他们的项目。 我们仍然不知道这将如何运作，但我们的目标是尽可能地统一和简化体验。 希望有帮助！

CX 也发生了同样的情况……它基本上没有使用，因为 C++ 开发人员不喜欢专有语言扩展。

他们喜欢在 clang、GCC、Intel 上使用它们。 xlCC、PGI、CUDA、C++ Builder 和来自嵌入式平台的过多。

显然 CX 被杀死是因为政治不能接受来自 Microsoft 的 C++ RAD 环境，而是让我们所有人都用类似记事本的体验来做 MDIL/ATL。

无论编译器如何，我都会不惜一切代价避免它们。 特别是当所述专有扩展本身是一种完全不同的语言时。

无论编译器如何，我都会不惜一切代价避免它们。 特别是当所述专有扩展本身是一种完全不同的语言时。

那么为什么要针对像 WinUI 这样的专有 UI 进行编码，而是使用像 X Windows 这样的开放标准呢？

... 好像可以在 Windows 上使用一样。 我避免使用编译器扩展，因为我想使用多目标编译器（Clang 和 MSVC）进行标准合规性验证，并希望使用更新的 C++ 标准。

我的代码使用 C++20。 许多语言扩展缺乏 C++17 支持或很晚才得到支持。 这种情况会在 C++20 中重复（或者更糟，因为 C++20 比 17 有更多的新东西）。 例如，你不能混合使用 C++20 ( /std:c++latest ) 和 CX ( /ZW )，你会得到一个编译器错误，说这两个开关不兼容。

直到今年 NVCC 才支持设备端 C++17。 不好看。

我不想把自己置于一个角落，我使用的语言扩展不能用于较新的标准，但我还需要一个新的标准功能。

由于上述原因，我避免使用它们。 如果我们将 WinUI C++ 开发人员体验回归到语言扩展，我将转向替代 GUI 框架。

@sylveon你完全可移植的用于 WinUI 的 C++20 在 Windows 之外是完全没用的，去享受没有扩展的 Qt 吧。

因为 C++ 桌面用户没有其他值得使用的东西。

感谢您确认无意义的政治是杀死 CX 的原因。

建议彼此友好相处。 我不能评论技术 c++ 参数，也不会判断谁是对的。
关键是像go have fun with X这样的短语并没有在这里营造友好和协作的氛围。 @stevenbrix和其他人请在需要时介入。

谢谢@hansmbakker ☺️

@pjmm和@sylveon我很欣赏热情和诚实的谈话，有像你这样关心的客户真是太好了。

这两点都非常有效，我认为世界足够大，你们俩都是对的。

@pjmlp我们对 C++ 的当前体验并不满意，并且确实认识到我们需要在 C++ 元类之前做一些事情。 我们已经有关于自由IDL-C ++ / WinRT中，并@kennykerr一些讨论和@ Scottj1s做了构建谈论它。 我们遇到的大多数问题都与与 WinUI 的集成有关，因为我们的编译器需要元数据。 我们想重新审视这个工作流程，看看我们是否可以有一个有凝聚力的故事来改善整体开发人员体验。 与带回 C++/Cx 不同的是，一个无 idl 版本的 c++/winrt 会让你感兴趣吗？

只是为了设定预期，我预计 2020 年不会有太大进展。

我对 IDL 免费 C++/WinRT 非常感兴趣。

IDE 体验也不是最好的。 例如，我们无法像使用 C# 那样从 XAML 编辑器创建事件回调（创建新回调下拉菜单什么也不做）。 从 XAML 编辑器导航到定义也不起作用。

它的其他问题是我在这个 repo 中填写的各种 XAML 编译器错误，这使我需要其他支持的语言不需要的解决方法。

@stevenbrix ，我想将我的声音添加到无 IDL 的 C++/WinRT（当然不希望看到返回到 C++/CX）。 我们编写跨平台软件，并使用 MSVC 和 LLVM（包括在 Windows 上）进行编译，因此符合标准的 C++ 对我们来说非常重要。

@stevenbrix ,

@pjmlp我们对 C++ 的当前体验并不满意，并且确实认识到我们需要在 C++ 元类之前做一些事情。 我们已经有关于自由IDL-C ++ / WinRT中，并@kennykerr一些讨论和@ Scottj1s做了构建谈论它。 我们遇到的大多数问题都与与 WinUI 的集成有关，因为我们的编译器需要元数据。 我们想重新审视这个工作流程，看看我们是否可以有一个有凝聚力的故事来改善整体开发人员体验。 与带回 C++/Cx 不同的是，一个无 idl 版本的 c++/winrt 会让你感兴趣吗？

只是为了设定预期，我预计 2020 年不会有太大进展。

这只是表明 C++/WinRT 的整个想法一开始是多么糟糕，在不考虑我们的生产力下降的情况下将其降低到我们身上。

从长远来看，Windows 开发人员的经验可以追溯到 Windows 3.0，现在 C++ 主要与基于 .NET 的应用程序一起使用，而不是单独使用。

Borland 工具是我的面包和黄油，直到由于旧时 Windows 开发人员已知的各种原因，前进的道路最终是迁移到 Microsoft 编译器。

鉴于 Visual C++ 缺乏与 Forms 和 AOT 编译的集成，Visual C++ 从来都不是 C++ Builder，即使是 C++/CLI。

C++/CX 似乎微软终于得到了它，我们将在 25 年后获得与使用 Delphi/C++ Builder 相同的生产力工作流。

取而代之的是，我们在政治上采取了杀死 C++/CX 的举措，而不考虑我们的生产力，向 ISO C++ 和 WG 21 挥舞着对缺失功能的责任，就好像 Visual C++ 团队从我们身上拿走的一切都将是WG 21 接受。

即使必要的特性最终会被 ISO C++ 采用，它会是 2023 年、2026 年，......？ 然后就是 Windows 开发人员何时可以真正使用这些功能，看看模块支持就知道了。 自从 Windows 8 于 2012 年发布以来，我们花了大约无数年的时间才能与 C++/CX 为我们提供的东西相提并论。

因此，考虑到到 2020 年我们不会看到任何改进，我们已经在这里谈论了 9 年，所以请原谅我是否倾向于对所有这些的管理方式感到有点生气，以及我们遇到的其他问题处理 UWP 失败、Reunion、.NET 生态系统重启，而我们被要求像 2000 年那样编写代码，具有基本的 MIDL 记事本经验和无穷无尽的模板汤（如 ATL）。

所以是的，要么是 IDL 免费的 C++/WinRT 版本，要么至少是具有完整 Intellisense/Intelicode 支持且无需手动复制文件的 IDL 体验。 但是，这不会从 C++ 代码本身中消除类似 ATL 的体验。

从 .NET/C++ 开发的角​​度来看，我不关心微软框架过去的时间旅行，而是如果更认真地对待 C++ RAD 的观点，它会是什么样子，不幸的是 C++/ WinRT 的故事已经得到了管理，现在一切都随着 UWP 的倒退而发生，我想知道“开发人员、开发人员、开发人员”去了哪里。

很抱歉，如果它仍然感觉有点生气，但这就是当我需要从 .NET 进入 C++ 时我对我的生产力下降的感觉，以大多数 C++ 编译器无论如何都不会这样做的 ISO 纯度的名义。

C++ 仍然非常重要。 许多应用程序是用原始 C++ 编写的，没有运行任何托管代码。 事实上，整个 UWP 运行时和 XAML/WinUI 框架都是原生 C++。 用 C++ 编写的 UWP 应用（幸好）不涉及托管语言。

我认为，如果您觉得有必要在 .NET 中使用 C++，您应该问问自己为什么并尝试直接在 .NET 中解决这些问题。 表现？ 使用 span 类型、stackalloc 和 vector 内部函数。 DirectX、本机 API 还是 COM？ 使用像 TerraFX 这样的绑定。 与仅 C++ 的库交互？ 在 .NET 中重新实现您需要的内容。

.NET 没有 C++ 更好，C++ 没有 .NET 更好。

我认为 cppwinrt 中的模板并没有那么糟糕。 最让我烦恼的是代码生成的需要以及它产生的可怕的编译时间。

@sylveon Easy，由于 Windows 团队拒绝将 API 作为 UWP 提供，并且没有第三方绑定不算数，并不是每个人都有幸拥有一个可以放手的法律部门，而不考虑许可证和未来的支持问题。

Borland（现在的 Embarcadero）和 Qt 公司已经展示了如何做到这一点，由微软决定他们希望保持平台的相关性。

尝试看看在 macOS、iOS、Android、ChromeOS GUI 中使用 ISO C++ 会走多远。

反正停在这里也没有意义。

@pjmlp我们拥有具有数百万行 ISO C++ 的跨平台应用程序，它们在 iOS/macOS/Windows 上运行良好。 当您关心性能和/或电池寿命时，C++ 是唯一可以使用的语言。 C++ 扩展对我们没有好处，因为我们使用多个编译器（显然它们没有实现彼此的扩展）。
我们以前使用过 C++/CLI，这太痛苦了。 类成员只允许原始 C++ 指针等限制使得存储智能指针变得困难。 编译时间长（单个字符更改需要5分钟的MD Merge时间）。
C++ 包括 require wrapping 以更改 pragma 托管/非托管
与 C++ 相比，C++/CLI 的编译器是一个不同的版本（我在构建时被告知 C++/CLI 编译器不支持晚于 C++17，这是一个问题，当包含来自使用 C++ 的库的头文件时20 个特征）。
我想说的是，不要有多个相互竞争的努力。 坚持标准并与之合作。 微软是 C++ 委员会的成员，他们帮助推动标准向前发展，这应该是重点，而不是专有的，锁定在扩展中。

我们可以有一个xaml 编译器，比如xaml.exe 来编译xaml 文件，类似于midl.exe、cl.exe 或link.exe？ 为 winui 应用程序构建自动管道将非常有用。

有时，我们不想使用 Visual Studio 来进行开发，也许可以使用我们想要的任何编辑器，但要保持构建管道分离。 winui 应用程序 xaml 似乎是一个特殊的部分，似乎还没有命令行工具来编译它。

这对于 cmake 等场景是必需的： https :

我们可以有一个xaml 编译器，比如xaml.exe 来编译xaml 文件，类似于midl.exe、cl.exe 或link.exe？ 为 winui 应用程序构建自动管道将非常有用。

@sammi是否 #1433 总结了一个合理的解决方案来满足您的需求？

我们可以有一个xaml 编译器，比如xaml.exe 来编译xaml 文件，类似于midl.exe、cl.exe 或link.exe？ 为 winui 应用程序构建自动管道将非常有用。

@sammi是否 #1433 总结了一个合理的解决方案来满足您的需求？

@jtbrower ，这正是我正在寻找的功能，谢谢！

当然这是一个预览版，这意味着我不应该期望太多，但是 WinUI 3 预览版 2 对我来说很失望。

我最大的需求是在 XAML 设计领域。 XAML 设计器根本不起作用这一事实让我感到非常吃惊，到目前为止，我还没有找到有关何时起作用的明确信息。

是的，我同意 Visual Studio 中当前的 XAML 设计器非常慢，并且当实时更改不应该破坏它的内容时它会中断。 例如，将Height="*"更改"Auto"或 100。（错误窗口会吐出大约 10 个错误——大量闪烁，您必须重建项目）

明确地说——我并没有真正使用设计师来设计——我只是想知道我的布局是否看起来像我在完成构建过程之前所设想的那样。 如果更简单，如果设计器只是“仅查看”，并且它在我调整 XAML 时更新（没有崩溃），那对我来说没问题，因为我不使用 GUI 来更改 XAML ......或者很少使用. 实际上， WindowsCommunityToolkit对 XAML 源所做的让用户更改源并实时查看输出的功能对我来说已经足够了。

尽管如此，WinUI 有一个好主意——将所有这些“简单”的东西从操作系统中分离出来，让开发人员的工作发展得更快，我们可以将依赖项与应用程序捆绑在一起，以避免必须升级 10 亿台设备所以他们可以运行我们新的伟大的东西。

我希望 Project Reunion 最终也能将 GUI 与应用程序容器完全分离。 没有沙箱/边界的类似 UWP 的 UX 将是向前迈出的一大步。

但是我们什么时候可以有一个可以再次工作的 XAML 设计器......拜托？

我认为热重载基本上不赞成 XAML 设计器的“仅查看”目的。

但我们在这里谈论的是 WinUI 工具。 热重载和实时可视化树也不适用于 WinUI。

我对 View Only 设计师的意思是“如果我们可以将其放入即将发布的预览版中，我可以接受”

我可能是错的（如果我错了请告诉我），但现在，在 WinUI 中查看您的 UI 的唯一方法是构建和运行它。

但我们在这里谈论的是 WinUI 工具。 热重载和实时可视化树也不适用于 WinUI。

我对 View Only 设计师的意思是“如果我们可以将其放入即将发布的预览版中，我可以接受”

我可能是错的（如果我错了请告诉我），但现在，在 WinUI 中查看您的 UI 的唯一方法是构建和运行它。

嘿@ericleigh007你有机会看看我们最新发布的 WinUI 3 Preview 3 吗？ 我们最近添加了许多工具改进，例如 IntelliSense、Hot Reload、Live Visual Tree 和 Live Property Explorer。 您可以查看发行说明，这里并获得最新的预览这里。 我对你的想法很感兴趣，所以请随时与我们联系！

@JeanRoca不幸的是，赶上 C++/CX 开发经验并不是这些工具改进之一。 当提议的 C++ 工具感觉就像回到 2000 年，在记事本中编写 IDL 文件（没有任何编辑器支持）并手动复制文件时，不要期望开发人员对 WinUI 有太多的喜爱。

它让我尽可能多地留在 .NET 中，或者尽管警告要使用 C++/WinRT，但仍然继续使用 C++/CX。

感谢更新; 今天将尝试，并将报告。 🤞

从邮件发送https://go.microsoft.com/fwlink/?LinkId=550986 for Windows 10

来自：JeanRoca [email protected]
发送时间：2020 年 11 月 18 日，星期三 4:41 AM
至：microsoft/microsoft-ui-xaml [email protected]
抄送：Eric [email protected] ； 提及[email protected]
主题：回复：[microsoft/microsoft-ui-xaml] WinUI 3.0 开发人员体验和工具 - 需要输入 (#1045)

但我们在这里谈论的是 WinUI 工具。 热重载和实时可视化树也不适用于 WinUI。

我对 View Only 设计师的意思是“如果我们可以将其放入即将发布的预览版中，我可以接受”

我可能是错的（如果我错了请告诉我），但现在，在 WinUI 中查看您的 UI 的唯一方法是构建和运行它。

嘿@ ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637412713160082691%7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jha7IQJyg%2BKEZKwKvAkSUIZFGZD有机会查看最新版本吗？ 我们最近添加了许多工具改进，例如 IntelliSense、Hot Reload、Live Visual Tree 和 Live Property Explorer。 您可以在此处查看发行说明https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160082691％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE％3D＆保留= 0 ，并在这里获得最新的预览https://eur05.safelinks.protection.outlook.com/?url=https% 3A％2F％2Fdocs.microsoft.com％2Fen-我们％2Fwindows％2Fapps％2Fwinui％2Fwinui3％2F＆数据= 04％7C01％7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160092685％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = VF2s7jilqpksevP6Fx7mXW1QCNJN2％ 2BK5yWOndg3rKoc%3D&reserved=0 。 我对你的想法很感兴趣，所以请随时与我们联系！

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729402012＆数据= 04％7C01％7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160092685％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = R1S2JpfBSzsNKJBAH5％2Fgme8Bq％2FjHbzB9FySk1KnZKbk％3D＆保留= 0 ，或取消订阅的https：//eur05.safelinks.protection.outlook的.com /？URL = HTTPS％3A％2F％2Fgithub.com％2Fnotifications％2Funsubscribe-AUTH％2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ＆数据= 04％7C01％7C％7Cae66199f9c044a728fb108d88b7c470d％7C84df9e7fe9f640afb435aaaaaaaaaaaa％7C1％7C0％7C637412713160102680％7CUnknown％7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0％3D％7C1000＆SDATA = 0H6IpND3YX1s6oyXy％ 2FCXNAMN9n8fvSPdWks%2FfmXT0Bc%3D&reserved=0 。

- 目前没有适用于 winui3 c++（桌面）的所见即所得编辑器/方法，对吗？

微软也在设法疏远 C++/CX 用户？ 这整件事根本没有好转。 任何采用微软几年前为 UWP 推出的技术的人，无论是 .net 还是 c++，现在都在没有微软支持的情况下陷入困境。

看起来 WinUI 3 只适合用 WPF 编写的桌面应用程序——但他们很快就会意识到 UWP 没有 WPF 的所有功能，而且 WinUI 的功能仍然较少。 每个人都会感到沮丧，这是启动 WinUI 3 的糟糕地方。

@robloo作为曾经提倡 UWP 的人，他们失去了我，直到他们解决了这个烂摊子，我才知道是 WPF 和 Win32。

C++/WinRT 是一项政治举措，我们被告知只能接受并等待 ISO C++ 最终提供反射和元类支持，以便 Visual Studio 团队复制 C++/CX 体验。

如前所述，即使编辑 IDL 文件也与使用原始记事本没有什么不同。

我们在 .NET 中不得不忍受 Microsoft 没有向我们提供所有 UWP 组件，在某种程度上可以通过 C++/CX 提供类似 C++/CLI 的体验。 现在有了 C++/WinRT，我们又回到了 ATL。

然后通过阅读 Reunion 问题讨论和更新路线图，很明显他们需要几年时间来纠正路线。

WPF 和 Win32 可能已经过时了，但它们已经存在并且可以正常工作，而且不会再次重写和丢失功能。

- 目前没有适用于 winui3 c++（桌面）的所见即所得编辑器/方法，对吗？

XAML 设计器有点工作，但它并不是真正为所见即所得编辑而设计的。 热重载（现在可以在预览版 3 中使用）效果更好。

实时视觉树和实时道具视图在预览中效果很好 3. 设计师计划何时可用？

还注意到桌面（WPF）（不是 UWP）设计器曾经在 2.4（或其他）中工作，但现在我的测试没有看到它再次工作？ 我是否遗漏了设计师当前的状态？

对不起，我参加聚会迟到了。 @wjk用他的第一点把它

1. MSIX 一切都很好，但我仍然使用旧的 MSI 来安装更复杂的应用程序，这些应用程序需要 MSIX 不支持的功能。 我也对使用 MSIX 持怀疑态度，因为所需的 Authenticode 证书非常昂贵。

我真的很欣赏 MSIX 的魅力，但这个证书签名授权对我来说是一个交易破坏者。 我需要一个合适的 SCM 友好的安装程序向导，我可以用它来创建经典的桌面安装程序体验。 为什么不采用 MSIX 中的改进并在没有 Microsoft Store 和认证要求的情况下创建新版本的 MSI 安装程序，以获得更现代的开发体验？ 也许这就是当前路线图中列出的“支持非 MSIX 部署”功能的含义？ 如果是这样，我想我一直在等待 3.x，除非出现奇迹，这使它成为更早的版本。 期待这一点，因为 VS 安装程序项目已经过时了，而且对源代码控制一点也不友好。 😓

@Chiramisu我同意这种观点，但我也很困惑——侧载体验 + AppInstaller 不够怎么办？

@Chiramisu你试过WiX吗？ 我将它用于我所有基于 MSI 的安装程序，它运行得非常非常好。 还有一个Visual Studio 扩展，因此您可以拥有自动执行各种编译命令的 WiX 项目。

@robloo作为曾经提倡 UWP 的人，他们失去了我，直到他们解决了这个烂摊子，我才知道是 WPF 和 Win32。

C++/WinRT 是一项政治举措，我们被告知只能接受并等待 ISO C++ 最终提供反射和元类支持，以便 Visual Studio 团队复制 C++/CX 体验。

如前所述，即使编辑 IDL 文件也与使用原始记事本没有什么不同。

我们在 .NET 中不得不忍受 Microsoft 没有向我们提供所有 UWP 组件，在某种程度上可以通过 C++/CX 提供类似 C++/CLI 的体验。 现在有了 C++/WinRT，我们又回到了 ATL。

然后通过阅读 Reunion 问题讨论和更新路线图，很明显他们需要几年时间来纠正路线。

WPF 和 Win32 可能已经过时了，但它们已经存在并且可以正常工作，而且不会再次重写和丢失功能。

为了让我跟上，你能告诉我你在谈论什么 IDL 编辑 C++/WinRT 吗？ 从我所看到的 co_await 和其他 C++ 17 语法来看，C++/CX 的复杂性似乎大大增加了。

多发性硬化症？ 难道除非有人围绕它创建一些非常好的包装器，否则基于 C++ 17 功能的 C++/WinRT 是不是太复杂并且与当前的设计太不同了？ 难道 C++/CX 不能保持足够长的时间来为 C++ 17 创建一些“优秀的包装器”，以使 C++/WinRT 使用和迁移相当简单？

（现在有人要链接到一篇展示这是如何完成的文章，我会觉得很愚蠢）

@lmcdougald我还没试过。 应该注意的是，我的特定项目仍在 .NET Framework 3.5 上。 我知道我知道。 我还没有被允许更新它，所以我坚持安装程序技术将与这个古老的框架一起使用。 😖

@wjk我过去曾研究过，但不，我还没有尝试过。 尽管考虑到上述情况，但它似乎是唯一适用于我现有项目的技术。 您是否曾将其用于基于旧框架的 WinForms 应用程序？ 不幸的是，我是一个孤独的开发人员，所以我不得不对我如何度过我的时间持极端的偏见，并且没有自由去试验新技术。

亲切地

@Chiramisu是的，WiX 适用于旧版本的 .NET Framework，是的，它也适用于 winforms 应用程序。 由于它创建原始 MSI 文件，WiX 可以安装任何编程语言的任何东西。 在学习方面，我会从基础教程开始。 我还想指出如何检测 .NET 是否已安装，以及如何使用 WiX 对文件运行 NGEN ，因为您在应用程序中使用了这些技术。 Visual Studio 扩展还附带了许多项目模板，以便为您提供正确的框架代码以供添加。 （注意：不要使用 Bootstrapper 模板，因为这是一个更高级的主题。）希望这会有所帮助！

@Chiramisu我对你正在寻找的东西感到很困惑——在我看来，你正在为当前项目而不是 WinUI 3.0 项目寻找打包工具。

值得注意的是，.NET Framework 3.5 可以打包到 MSIX 中。 您可以使用 VS 2019 中的 Package Project 为现有应用程序构建 MSIX 包，然后在某种程度上无缝地经历漫长的过渡，但需要做很多工作：

WinUI 3.0 永远不会正式支持 .NET 3.5，并且可能永远不会支持任何版本的 .NET Framework。 我将通过升级到 .NET 4.6（或理想情况下更高，4.8 是理想的）来开始您的现代化，而无需更改您现有的打包项目。 如果一切顺利，我将开始将功能转换为 .NET Standard 共享库，您可以从更新的 .NET 4.6+ 应用程序中引用该共享库。

.NET 4.6 应用程序稳定并经过测试后，您可以将其作为 MSIX 打包项目的自动更新进行交换。 在 .NET Standard 步骤之后，您可以创建一个项目负责人，该项目负责人使用与 .NET Core 3.1（或 5，但我觉得 LTS 状态可能对您的组织意义重大）几乎相同的代码。 再次测试，然后将 MSIX 切换为使用此版本。

此时从 WinForms 切换到 WinUI 是学习 WinUI 并重新实现界面的问题。 再次，创建一个新的项目头，实现 + 引用 .NET Standard 库，测试，然后切换包以使用此版本。

这就是我如何进行现代化而不在任何给定点创建大相径庭的项目。 我会优先设置 MSIX 打包和 .NET 4.6 + .NET Standard 步骤，因为这些将为您带来更多的帮助工具和与现代 .NET 开发周期的联系。 考虑到 .NET 3.5 的生命周期是 .NET 3.5 的 1/10，在短期内匆忙切换到 .NET 5 听起来对您的组织来说是个坏主意。

为了让我跟上，你能告诉我你在谈论什么 IDL 编辑 C++/WinRT 吗？ 从我所看到的 co_await 和其他 C++ 17 语法来看，C++/CX 的复杂性似乎大大增加了。

多发性硬化症？ 难道除非有人围绕它创建一些非常好的包装器，否则基于 C++ 17 功能的 C++/WinRT 是不是太复杂并且与当前的设计太不同了？ 难道 C++/CX 不能保持足够长的时间来为 C++ 17 创建一些“优秀的包装器”，以使 C++/WinRT 使用和迁移相当简单？

（现在有人要链接到一篇展示这是如何完成的文章，我会觉得很愚蠢）

因为普通的 C++ 没有能力提取制作 .winmd 文件所需的类型元数据，所以您必须在 .hpp 和 .cpp 之上的 .idl 文件中编写 WinRT 类。

co_await比到处写.then([=](Foo^ thing) { })简单得多，它与 C# 的await语法非常相似。

这是来自默认运行时组件项目的示例 (idl + hpp + cpp)：

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

这是一个小的 co_await 示例：

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

你好呀，

我们正在阅读您的反馈并记录痛点。

@ericleigh007 XAML Designer 退出是因为在收集客户反馈后，顶级客户的痛点在于改进开发人员的内部循环。 Hot Reload 和 Live Visual Tree 位居榜首。 应用程序内工具栏是另一个无法制作预览版 3 的最重要的东西。 我们需要更新功能路线图思想。 根据当前的工程计划，它在 3.0 RTM 之外，所以它是 3.0 之后的。

@pjmlp我同情你对 C++/WinRT 的描述以及添加 IDL 的需要。 C++/CX 在这方面要好得多。 改进 C++/WinRT 体验是我们需要解决的另一个主题。 Live Visual Tree 和 Hot Reload 等工具适用于 C# 和 C++，但有一些特定的东西只影响 C++，需要分开处理。 根据当前的工程计划，解决 IDL 问题不在 3.0 RTM 之内。

@robloo ，我们不迎合用 WPF 编写的桌面应用程序。 C++/WinRT 是 WinUI 生态系统中的第一个公民。 这是我们用来编写 WinUI 的东西，所以我们正在对我们合适的工具和语言进行测试。

@Chiramisu让我解释一下“支持非 MSIX 部署”是什么意思。 今天，您需要使用 MSIX 安装和运行桌面 WinUI 3 应用程序。 此功能旨在消除这种需求。 要运行桌面 WinUI 3 应用程序，您只需要在 .EXE 上加倍，仅此而已。 要安装您的应用程序，您只需执行一个 xcopy（无需签署任何内容）。 基本上，您将能够使用其他打包和安装系统，如 WiX。

@marb2000感谢您承认这个问题。 我和许多其他 Windows 开发人员不明白的是，为什么您（如在 WinDev 管理中）认为使用劣质工具将 C++/WinRT 强加给我们是个好主意，即使回到 MFC 感觉更好，至少我们是'不要手动复制文件。

现在我专注于 ASP.NET、WFP 和 Win32，继续关注 UWP 的东西，希望微软最终意识到我们厌倦了重写应用程序和被拖累手动配置，就像在 UAP => UWP 中一样转换，.NET Framework 到 .NET Core，或者是 C++/CX => C++/WinRT。

这更像是一种反馈，作为 Windows 开发社区的一位发声成员，自 Windows 8 推出以来，对不断的重写感到有点失望。

@pjmlp我不知道你为什么批评 C++/WinRT，它只是 Windows API 的（符合标准的）C++ 包装器。 无需工具（和 IDL 文件等）即可使用 C++/WinRT 编写应用程序。

@pjmlp我不知道你为什么批评 C++/WinRT，它只是 Windows API 的（符合标准的）C++ 包装器。 无需工具（和 IDL 文件等）即可使用 C++/WinRT 编写应用程序。

这正是问题所在，零工具支持与 Visual Studio 中 C++/CX 的开发体验。

没有对 IDL 文件的编辑支持，甚至没有语法高亮，更不用说智能感知了。 然后有人被告知手动复制或合并生成的翻译单元！

这就像过去做 ATL 一样。

我不关心 ISO C++ 兼容性，无论如何 UWP 只是 Windows 并且没有任何没有语言扩展的 C++ 编译器。

除了作为 WRL 唯一用户的 WinDev 人员之外，我看不出任何人都可以将其视为进步。

@pjmlp ,

我不关心 ISO C++ 兼容性，无论如何 UWP 只是 Windows 并且没有任何没有语言扩展的 C++ 编译器。

对于我们这些编写大型 C++ 跨平台应用程序的人来说，符合标准是一件大事。 C++/CX 的限制很糟糕（没有不是原始指针的成员变量，帽子！（ ^ ）等）。 我们目前有一个庞大的 C++/CLI 互操作库，痛点不胜枚举。

没有对 IDL 文件的编辑支持，甚至没有语法高亮，更不用说智能感知了。 然后有人被告知手动复制或合并生成的翻译单元！

同样，您将 C++/WinRT 和工具混为一谈。 他们是两个不同的东西。 C++/WinRT 是围绕 WinRT API 的 C++ 包装器。 IDL 用于代码生成，是的，我同意它很糟糕，它太糟糕了，我不使用它。

我编写了一个仅限 Windows 的应用程序，但我仍然关心标准合规性，因为它允许我在 MSVC 失败的情况下使用不同的编译器。

@MarkIngramUK

同样，您将 C++/WinRT 和工具混为一谈。 他们是两个不同的东西。 C++/WinRT 是围绕 WinRT API 的 C++ 包装器。 IDL 用于代码生成，是的，我同意它很糟糕，它太糟糕了，我不使用它。

自 MS-DOS 3.3 以来，我一直在为 Microsoft 平台编码，在 1992 年使用 Turbo C++ 1.0 将 C++ 添加到我的工具箱中，在 C++ 开发方面使用了大部分 Borland 和 Microsoft 产品。 不需要任何关于 C++/WinRT 是什么的讲座。

绝对不是，它与 C++ Builder 和 Qt（使用 Qt Designer）开发人员的经验相匹配，C++/CX 显示了 25 年后最终赶上的承诺。

但显然这里的大多数人只想要带有 ATL 3.0 的 Visual C++ 6.0，而我们其他人应该坚持使用 .NET 5、WPF 和 Win32 桌面体验，因为我们是少数不值得考虑的，否则 C++/WinRT 永远不会有被推到原来的样子。

老实说，C++/WinRT 现在已经快 4 年了，微软甚至无法提供语法高亮和智能感知的支持？

我们中的一些人在 Notepad++（语法高亮）中制作的东西，真的吗？

它肯定显示了优先级在哪里，并且 WinUI 不会以这种方式获得采用，自 Windows 8 以来重写太多了。

@pjmlp ，你又在谈论错误的事情。 C++/WinRT 只是 C++，所以它确实有语法高亮显示并且它确实有智能感知支持。 就像您拥有的任何其他 C++ 代码一样。

IDE 集成可能会更好，就像您提到的 IDL 语法高亮显示以及诸如建议在 IDL 中的 .hpp 和 .cpp 中创建默认实现之类的东西（例如当前在标题中没有定义的函数如何用绿色波浪线提示您创建一个），但回到 C++/CX 是 IMO 的净降级。 将我在 C++/CX 中使用的所有库和共享代码集成起来需要太多的努力，并迫使我将我的项目从 C++20 降级到 C++17（我不想放弃，20给了我太多好东西）。

当程序只想使用 WinRT 类而不是编写它们时，C++/WinRT 也比 C++/CX 的侵入性小得多。

Qt 和 C++ Builder 在大多数符合标准的 C++ 中获得了他们的经验（注意 Qt 有一些类似于 IDL 的东西，称为 Qt MOC）。 如果这些可以，那么 VS 也可以。 它只需要 DevDiv 中某人的更多爱。

正如您之前提到的@sylveon ，我们可以使用其他编译器自由构建（我们目前使用 MSVC 和 Clang/LLVM 构建）。 使用 C++/CX 或其他 MS 扩展，这是不可能的。

@MarkIngramUK和@sylveon

我已经完成了这个线程，很明显，像我这样的反馈对于改进 WinUI 开发人员体验和工具是不受欢迎的。

享受符合标准的 C++/WinRT 的乐趣。

你能编辑这个来修正“没有餐饮”的错字吗..我认为这应该是“现在......”

@pjmlp我想我完全明白你的意思。

大约一年前，我放弃了将我的 UWP C++/CX 代码移植到 C++/WinRT 的想法。 移植的动机是能够使用 Clang 编译我的 UWP 应用程序，因为 MSVC++ 包含一个我在 18 个月前报告的错误，但他们似乎根本没有兴趣修复。

但是，后来发现 Visual Studio 不支持使用 Clang 构建 UWP 应用程序。 太好了，所以 C++/WinRT 的“仅 ISO C++”优势就消失了。 此外，通过 C++/WinRT 移植 C++/CX 代码库就像穿越 20 年前一样。

我基本上已经放弃将我们的 Android/iOS 应用程序移植到 Windows 上。 对于我们这样的小商店来说，除了针对 Android/iOS 进行开发之外，还要处理 Windows 应用程序开发的 clusterfuck，这根本不可行。

@MarkIngramUK似乎您根本没有意识到工具非常重要。 不是每个人都有资源来弥补他/她自己缺乏适当的工具。

现在，在我的咆哮之后，这是我的输入：

支持在 C++/CX 中使用 WinUI 3。 一旦 C++/WinRT 的工具对于没有资源来构建自己的工具的公司来说是可以接受的，那么切换到 C++/WinRT 可能就可以了。 现在肯定不是。

@pjmlp我想我完全明白你的意思。

大约一年前，我放弃了将我的 UWP C++/CX 代码移植到 C++/WinRT 的想法。 移植的动机是能够使用 Clang 编译我的 UWP 应用程序，因为 MSVC++ 包含一个我在 18 个月前报告的错误，但他们似乎根本没有兴趣修复。

但是，后来发现 Visual Studio 不支持使用 Clang 构建 UWP 应用程序。 太好了，所以 C++/WinRT 的“仅 ISO C++”优势就消失了。 此外，通过 C++/WinRT 移植 C++/CX 代码库就像穿越 20 年前一样。

我基本上已经放弃将我们的 Android/iOS 应用程序移植到 Windows 上。 对于我们这样的小商店来说，除了针对 Android/iOS 进行开发之外，还要处理 Windows 应用程序开发的 clusterfuck，这根本不可行。

@MarkIngramUK似乎您根本没有意识到工具非常重要。 不是每个人都有资源来弥补他/她自己缺乏适当的工具。

现在，在我的咆哮之后，这是我的输入：

支持在 C++/CX 中使用 WinUI 3。 一旦 C++/WinRT 的工具对于没有资源来构建自己的工具的公司来说是可以接受的，那么切换到 C++/WinRT 可能就可以了。 现在肯定不是。

出于好奇，18 个月前报告的错误是什么？ 你有任何地方的链接吗？

嗨，米格尔，
___编辑以修复从 Outlook for Android 回复后的糟糕状态___

我有一个想法，可以让您明确预览和发布的目标，因为您说 Winrt 平台是您用来开发 WINUI 的平台。

拿这篇文章来说，如果 IDL 编写和手动复制 if 文件并修改它以匹配您在工具中工作的状态，它会指出一堆

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

如果不是在这里，也许我们可以在其他地方讨论。

顺便说一句，你让我相信 XAML 设计器，尤其是使用像 XAML 工作室这样的工具。 （如果它也能够加载一些代码，这样它就可以成功加载使用IValueConverter XAML ...

正如我在之前的文章中提到的，C++/WinRT 本身的 C++17 标准合规性在大多数情况下没有动力将 C++/CX 代码库迁移到 C++/WinRT，因为您被迫使用 Microsoft 的 Visual C++ 编译器进行编译反正。 如果您可以切换出会完全改变的编译器。

但是 Visual Studio 不支持切换 Windows 运行时组件的编译器。 为什么不支持这对我来说是个谜，特别是因为它支持此博客文章中概述的桌面应用程序。 对于 Windows 运行时组件，确实应该扩展 Clang 支持。

我们正在使用 Clang 为 Android 和 iOS 编译我们的代码库。 能够使用 Clang 为 Windows 编译我们的代码库实际上是从 C++/CX 迁移的一个非常好的理由。 Visual Studio 功能请求已经存在，但到目前为止，Visual Studio 团队还没有做任何事情。

你符合 C++ 标准，你在 Visual Studio 中为桌面应用程序提供 Clang 支持。 因此，请执行最后一步，并通过为 Windows 运行时组件提供 Clang 支持来提供从 C++/CX 迁移的真正原因。

标准合规性对消费者很有用 - 正如您提到的，生产者坚持使用 MSVC。 有一种方法可以通过将属性CLToolExe设置为.vcxproj文件中的 clang-cl 路径来“强制”clang-cl（实际上 LLVM 工具集已经这样做了）。 我不确定它在 UWP 项目中的效果如何，但值得一试。

一旦 XAML 和 C++/WinRT 生成器工具在桌面项目中解锁，对我来说也将不再是一个问题。

@ackh我有一个 UWP 项目要在 Clang 11 下构建：

这是我所做的：

• 卸载项目，并在<Project>下添加以下指令作为第一个指令

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• 用<AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions>替换<AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• 用<PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>替换<PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• 在它的正下方，添加<ModuleOutputFile />
• 重新加载项目
• 建造

然而，它有几个陷阱：

• 关于未使用参数的一些警告支持：您可以通过更改/删除未使用的参数来解决这些问题。
• 出于某种原因，Clang 以 32 位形式发出 64 位目标文件，可能只需要将-m32到 CLI tho。
• 由于 Clang 尚未完全实现协程，因此您将无法使用它们。
• 每次运行应用程序时，VS 都会执行完整的单线程重建，而不是增量和/或并行重建。

我建议在https://github.com/microsoft/ProjectReunion上打开一个问题来引起注意。

@sylveon 非常感谢您发布这些说明。 我会在某个时候尝试一下，但仍然希望 Visual Studio 会在某个时候支持它开箱即用。