Microsoft-ui-xaml: 👩‍💻📞 WinUI 社区电话会议（2020 年 2 月 19 日）

我有一个关于 Windows 10X 开发的问题。 为了开发它，我需要模拟器，什么时候支持 AMD 处理器（嵌套虚拟化）？ 我们可以指望 Windows 10 2003 版本吗？

更多与WinUI相关，基于#1958，Live Tiles的未来是什么？

AMD Ryzen 支持阻止我运行模拟器，所以任何关于何时纠正的消息都会很高兴听到。

@jp-weber @mdtauk

这是官方措辞（https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools）：

目前不支持 AMD 处理器。 在模拟器中运行 Windows 10X 需要嵌套虚拟化，Windows 尚不支持在 AMD 处理器上执行此操作。 敬请关注！

如果您想了解更多信息，您应该联系[email protected]。 我怀疑 WinUI 是询问模拟器特定问题的正确团队。

谢谢@Felix-Dev - 没错，文档是获取 10X 模拟器最新状态的最佳位置，而该电子邮件地址是其他 10X 问题的最佳联系方式，这些问题并非特定于 WinUI。

很公平，必须等到微软准备好谈论它。

看看 Windows 10X，Win32 应用程序在 VEIL 容器中运行。 WinUI 3.0 非 UWP 应用呢？

它们是否会像原生 UWP 应用程序一样运行 10 倍？

@mdtauk由于 WinUI 桌面应用程序不是本机 UWP 应用程序，我认为它们不会在 UWP 容器中运行。 我相信它们将在提到的 Win32 容器中运行，因为它们将拥有（所有）Win32 应用程序的功能。

我也很想知道未来 WinUI 应用程序隔离的计划是什么。 从企业的角度来看，我们需要隔离/沙盒和功能控制（而不是用户选择加入）。 所以，把它作为 Miguel 的一个话题。

@mdtauk由于 WinUI 桌面应用程序不是本机 UWP 应用程序，我认为它们不会在 UWP 容器中运行。 我相信它们将在提到的 Win32 容器中运行，因为它们将拥有（所有）Win32 应用程序的功能。

这有点令人失望。 Win32 应用程序似乎表现出不同的窗口行为，并且当它们在前台时会使屏幕变暗。 因此，切换的行为也不同。

使用 Xaml UI，希望 WinUI 桌面应用程序至少在表面上对用户来说是两全其美的场景

@mdtauk由于当前发布给我们的 10X 模拟器映像还很早，我很确定您注意到的问题/行为（我在我的测试中也是这样做的）将在发布之前得到解决/更改（即我也有 Win32 应用程序，它只是现在无法加载）。

也就是说，我很高兴在 10X 上的 WinUI 桌面应用程序容器上得到纠正。 我目前的想法是基于到目前为止我们所了解的 WinUI 桌面（Win32 应用程序模型）、10X 演示How Windows 10X runs UWP and Win32 apps和桌面桥测试应用程序。 不幸的是，我的 XAML Island 测试应用程序当前无法在模拟器上加载（卡在App Launch Initialized阶段），所以我无法检查他们将使用哪个容器。 如果它不是 Win32 容器，我会感到惊讶，因为它们仍然是 Win32 应用程序。 所有这些都让我相信 WinUI 桌面应用程序将以 10 倍的速度在 Win32 容器中运行。

问团队当然是个好问题！

@Felix-Dev 根据您提到的同一视频（Windows 10X 如何运行 UWP 和 Win32 应用程序）在 20:18 分钟表示不支持混合应用程序（Win32/UWP）（还？），我的理解是一个应用程序使用 XAML Island 是一个混合应用程序。

Q1) SwapchainPanel 什么时候可以在 WinUI 中使用？ 这对于我和许多其他人所做的工作来说绝对是必不可少的。

Q2) 由于 SharpDX 的创建者不再支持它，微软是否会加强并提供 SharpDX 和 WinUI 硬件渲染表面之间的兼容性？ MS 是否甚至看到了在没有 SharpDX 的情况下使用 C# 进行硬件渲染的故事？ 我不关心 Unity，我的意思是不受限制的、自由形式的图形开发，用 C# 制作我们自己的图形工具、引擎和非 Unity 游戏。 而且我也不是指 Win2d，我需要完整的硬件渲染功能 (DirectX)。

Q3) 当鼠标移动到屏幕的顶部和底部边缘时，应用程序无法关闭 TaskBar 和 TitleBar 弹出窗口。 对于许多游戏（可能还有一些应用程序）来说，这是一个交易破坏者，它们在自己的 UI 中利用屏幕边缘来处理诸如相机平移或弹出窗口之类的事情。 何时修复（这可能是 Windows 问题，但需要由 API 驱动，因此与 WinUI 相关）。

Q4) 当我们想要绕过 Xaml 并直接渲染到窗口绑定的 Swapchain 时，我们可以让 WinUI 包含 CoreWindow (IFrameworkView) 应用程序模型吗？

这听起来可能有点奇怪，要求 WinUI 提供非 Xaml 表面。 但我认为 CoreWindow 与 XamlWindow（在 UWP 中称为 Window）在同一个库中，也与 UWP 分离以使其在 .net 5 中可用。假设 .net 5 将能够针对非 uwp 以及 uwp。 目前在 UWP 之外没有现代 C++ 应用程序模型 - 游戏开发人员必须使用旧的 c 代码 (Win32) 来编写游戏或图形应用程序的应用程序层。 .net core 中也没有现代桌面应用程序模型。 UWP 的 CoreWindow 解决方案有效且使用舒适。 它只需要存在于 UWP 之外（对于 C++/非 uwp 和 .net 5）。 从 UWP 中提取 CoreWindow 的另一个好处是，它提供了一种将代码从 UWP 直接移植到 .net 5（以及 C++，如果它获得非 uwp 现代应用程序模型）的方法。

游戏开发者不能使用 UWP，直到窗口行为改变并且分发故事被整理出来。 已经很长时间了，看起来微软甚至不明白这个问题。 所以我们必须尝试将这些 API 拉到 UWP 之外。 如果 UWP 已修复，我们就不需要了。

以及来自第1215 期的进一步评论

如果您将 Win32 Window 替换为用于非包含/非 Xaml 方案的 CoreWindow，并且还向 .Net 5 Non-UWP 提供 CoreWindow，那么我们可以在 Windows 之间为非 Xaml 工作提供统一的应用程序/窗口模型。 这比永远坚持 Win32 或构建新的应用程序模型更有意义。

为什么我们要重写应用层只是因为我们想在包含和非包含执行之间切换（例如在 UWP 和 Win32 之间）——这是当今游戏开发者面临的一个典型问题，他们无法提交到 UWP，因为他们需要Win32发行自由。 所以他们被迫使用 HWnd 或 .Net Framework 应用程序模型。 如果 UWP 应用程序/窗口模型可用于非 uwp 包含的应用程序，没问题，我们可以为应用程序层编写相同的代码，并从相同的代码库为 MS Store 和其他商店编译。

@leoniDEV这其中的大部分内容仍然是猜测“混合应用程序”的确切含义。 例如，请参阅此 twitter 线程，其中据说 XAML Island 应用程序不属于该类别（Matteo Pagani 在 Microsoft 作为Windows AppConsult Engineer ）。 UWP 社区的一位 MS 员工表示，对运行 Win32 完全信任进程的 UWP 应用的支持将不会在第一天得到支持，但计划稍后添加。

@Gavin-Williams WinUI 将有两种风格：WinUI UWP 和 WinUI Desktop。 使用 WinUI UWP，您将能够创建完整的 UWP 应用程序，这些应用程序将在 Windows 10X 上的 UWP 容器中运行。 然后是 WinUI 桌面，它使 Win32 应用程序也可以完全访问 UWP UI API（XAML、组合、输入... - 不包括像CoreWindow这样的一些 API）。 这些类型的应用程序不必处理 UWP 沙箱或 UWP 的其他设计限制。 但是，由于它们不是 UWP 应用程序，因此您的 WinUI 桌面应用程序将无法针对 UWP 应用程序可以定位的广泛的 Windows 10 设备类别。
请参阅下面从WinUI 路线图中截取的图像，以获得一个很好的概述：

WinUI 完全是用 C++ 编写的，因此可以在非托管应用程序上下文中使用。

正如我上面强调的，我写的I believe they will run in the mentioned Win32 container纯粹是基于我目前对 WinUI Desktop、10X 视频和我在 10X 上运行的桌面桥测试应用程序的理解。 我没有内幕消息。 WinUI 团队肯定会让我们知道 WinUI 桌面应用程序和使用的 10X 容器的计划是什么，我很高兴在这里得到纠正，并被告知是的，WinUI 桌面应用程序将在 UWP 容器中以 10X 运行。

我想了解更多关于在使用 WinUI / Microsoft UI 构建应用程序时可能能够使用其他编程语言（例如 Java、Python、JavaScript 等）的想法。

我知道有一个名为 Xlang (cross-lang) 的项目——它本质上看起来像是 .NET 应该是的，一个更好的 COM。

这与 WinUI 有何关系？

xlang 本质上是 Windows 运行时 (WinRT) 的跨平台开源版本，尽管它不会完全兼容。 WinRT的目的就是你说的，语言之间的互操作性，它是基于COM的。 WinUI 的 API 建立在 WinRT 之上，这就是它支持 C++ 和 C# 的方式。 还有其他语言对 WinRT 提供不同级别的支持，包括Python 、 Rust （这是我个人研究过的一种）和JavaScript ，但据我所知，它们（还）都没有支持 WinUI - 支持 WinUI 特别困难因为它的 Composition 和 XAML API 严重依赖于称为可组合类型（本质上是实现继承的一种形式）的类型系统功能，其他 WinRT 和 UWP API 不使用该功能，并且很难映射到其他语言的类型系统。
C++/WinRT 的创建者 Kenny Kerr 现在正在研究一个新的 Rust WinRT 投影。

实际上，我最近一直在思考 Rust 如何最好地支持可组合类型（以及 WinUI）。 这当然是可能的，但我不确定我能让开发人员感受到它有多自然。 基本上，如果有人投入工作来创建投影，任何语言都应该能够支持 WinRT，但是根据语言的设计，有时很难以某种方式将 WinRT 类型系统构造映射到语言的类型系统那感觉很自然。

xlang 在我看来已经死了。 C++/WinRT 并没有真正完成——它留下了错误和一个非常奇怪的使用故事，使得它对普通开发人员来说是不受欢迎的。 为了让 C++/WinRT 能够工作，我挣扎了很多很多小时，但未能完成我在 30 分钟内使用 C++/CX 所做的事情。 从长远来看，C++/CX 更容易使用。 如果微软希望这些跨语言工具可供普通乔使用，他们需要让一个团队来解决这个问题，而不是让肯尼·克尔一个人来完成所有的工作。 他有一些很棒的想法。 但是这些工具需要广泛的吸引力，我认为他需要帮助才能使这些产品成熟并成为它们的全部。

目前 UWP 及其后继者 WinUI 尚未准备好用于 LOB 应用程序

我们面临着几个问题

• 表现不佳。 例如 WinUI 依赖属性比https://github.com/microsoft/microsoft-ui-xaml/issues/1633慢 50 倍。
• 编译性能差。 比wpf慢几倍
• 网络原生
• 发布之间有很多重大更改。
• 沙盒和权限模型
• 与 wpf 相比，3d 派对供应商的定制能力有限

你认为 WinUI 能克服这个限制，成为未来 10 年的下一个 LOB 就绪框架吗？ 或者是时候使用电子 blazor 应用程序了）

我对 WinUI 的当前状态有几个问题。

与 C++/CX 工具和整体开发人员体验相比，C++/WinRT 仍然是非常差的开发人员体验。 如果我们希望处理用 C++ 编写的 WinUI 组件，那么对 C++/CX 工具的能力至少有 1:1 的覆盖率是可以预期的。

如果与仅使用 C++/CX 相比，我的生产力受到影响，那么标准 C++17 对我来说毫无用处，并且编写 UWP 组件或基于 XAML 的 UI 需要两倍的时间。

这引出了我的第二个问题，必须在 UWP/WinUI 上处理 C++ 的主要原因是因为微软已经放弃了任何类型的 DirectX 绑定到 .NET 语言。 那么 WinUI 是否会像替换一样提供对 XNA 或 WPF 3D 场景图的支持？ 显然，我们在这里只能听到无线电静默，并且被迫参与 MonoGame 等社区项目或 Unity 等成熟引擎。

Win2D 何时最终成为 WinUI 的一部分？ 目前它看起来处于维护模式，未来不确定。

目前，继续销售 UWP 梦想变得非常困难，因为我的肥皂盒周围的听众数量不断减少。

Windows 10X UI 元素何时会进入桌面 Windows 10？

@carmellob 2022-2025？

编辑：MS 可能会删除此内容，因为它提出了产品交付时间表，但该时间表不存在，因此具有误导性；)

@Felix-Dev “WinUI 桌面 .. 将使 Win32 应用程序能够完全访问 UWP UI API .. 不包括像 CoreWindow 这样的一些 API。

排除CoreWindow？ OMG - 这是应该从 UWP 中撤出的第一个也是最重要的 API。 它是提供基本窗口功能的最基本的 API。 它需要在 UWP 容器内外通用。 在它被推出之前，我们无法为应用程序层提供一个通用的代码库，并且我们被困在 C++ 中的遗留 Win32 c 代码或任何 .net 核心将为 C# 提供（又是另一个 Window 类？）。

请 Microsoft - 就像您在 UWP 内外都提供 XamlWindow 一样，也请在 UWP 内外提供 CoreWindow。

关于电话会议：你为什么离开 Teams？ YouTube 在最后一个上运行得不太好。

@加文-威廉姆斯

来自https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216：

我们的方法是 WinUI 3 在 UWP 中运行时将使用 CoreWindow，而在桌面 (Win32) 中运行时将使用 Win32 Window(HWind)。

UWP 应用程序中的 WinUI 3 将能够使用 AppWindow API。 对于桌面，将需要推出类似的东西。 我们仍在设计这个，所以到目前为止我没有更多细节。

该团队还表示，它正在寻求为 WinUI 桌面提供CoreApplicationViewTitleBar.ExtendViewIntoTitleBar 等API，以便我们能够两全其美。 Win32 窗口设计的全部功能（即无标题栏/100% 自定义标题栏、应用程序窗口< 要求的最小尺寸、无任务栏按钮等）和新的现代 UWP 自定义 API。 （对于 UWP，我们可能需要等待 AppWindow V2 具有接近当前 Win32 窗口功能的窗口功能。）

@jesbis关于 WinUI 桌面的问题：在问题https://github.com/microsoft/microsoft-ui-xaml/issues/1939 中，有人指出 toast 通知激活不适用于 MSIX 打包桌面应用程序（至少）文档中提到的 1909 年：

对于桌面桥应用程序，只需像 UWP 应用程序一样发送 toast 通知。 当用户单击您的 toast 时，您的应用程序将使用您在 toast 中指定的启动参数在命令行中启动。

虽然我必须等待，看看提到的修复程序是否会被反向移植到桌面桥接应用程序的受影响操作系统版本，但我的问题是：WinUI 桌面应用程序是否会提供上面引用的开箱即用的 Toast 激活功能（因此无需使用一个 COM 激活器）在所有针对 WinUI 的 Windows 10 版本上？ （或任何类似的吐司激活概念。）

@Felix-Dev 从文档看来，XAML Island 并没有严格暗示混合应用程序，如果我理解，您可以直接从 Win32 应用程序调用 UWP XAML 托管 API，但会丢失一些功能，例如使用自定义控件正确的文档（以及文档中的注释）：

使用 XAML 岛在 WPF 应用程序中托管标准 UWP 控件

所需组件

您的应用程序的项目和源代码。 面向 .NET Framework 或 .NET Core 3 的应用程序支持使用 WindowsXamlHost 控件托管标准的第一方 UWP 控件。

定义从 XamlApplication 派生的根应用程序类的 UWP 应用项目。 您的 WPF 或 Windows 窗体项目必须有权访问 Windows 社区工具包提供的 Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication 类的实例。 此对象充当根元数据提供程序，用于为应用程序当前目录中的程序集中的自定义 UWP XAML 类型加载元数据。

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

为了让 C++/WinRT 能够工作，我挣扎了很多很多小时，但未能完成我在 30 分钟内用 C++/CX 所做的事情

如果我们希望处理用 C++ 编写的 WinUI 组件，那么对 C++/CX 工具的能力至少有 1:1 的覆盖率是可以预期的。

@Gavin-Williams，@ pjmlp您是否在cppwinrt 存储库中为您发现的问题打开了问题？ 或者它们是特定于 WinUI 的问题，您可以在这个 repo 中打开问题吗？ 我们正在积极致力于 C++/WinRT 支持，因此很高兴听到有关不适合您的任何细节的任何详细信息。 我们自己也在使用它 - 新的 WinUI 功能都在 C++/WinRT 中，我们的应用程序也在使用它（例如计算器）。

关于电话会议：你为什么离开 Teams？ YouTube 在最后一个上运行得不太好。

如果您的意思是音频问题：我们认为我们上个月的电缆坏了，希望明天会更好。 大多数人似乎更容易访问 YouTube，而且 Channel9 工作室的音频和视频比我们用于 Teams 的会议室要好得多。

RE：CoreWindow、win32 支持、容器 - 我们将在明天的社区电话会议中与@marb2000讨论我们当前的方向 :)

到目前为止，我们还将尝试解决其他问题（例如，SwapChainPanel 时间线、Win2D/DirectX、岛屿等的当前状态）——感谢迄今为止的评论和问题！

@jesbis感谢您回复我们。

没有问题可以解决，因为 C++/WinRT 的开发方法完全落后于 C++/CX 提供的生产力。

使用 C++/CX，我最初认为 Microsoft 终于以正确的方式销售 Visual C++，25 年后，Visual C++ 已经开始使用 C++ Builder 的 RAD 体验。

相反，C++/WinRT 给我的是回到 ATL/WTL 时代，在那里我必须编写 MIDL 样板，尽管 MIDL 3.0 在某种程度上比原始 MIDL 更好，但必须手动编写 C++/CX 处理的 UWP 绑定样板我。

并不是说 C++/CX 是完美的，它处理事件处理程序的方式仍然不如 C#/VB.NET 或 C++ Builder。

UWP 无论如何都与 Windows 相关联，因此拥有纯 C++ 绑定并不是让我接受 C++/Winrt 的东西，而是能够执行与 C# 或 VB.NET 完全相同的操作，而无需处理仍然感觉像的代码ATL/WTL。

如前所述，我只忙于 C++，因为将 DirectX 公开为一组 UWP 运行时组件的呼吁一直被忽略。

所以我不觉得在 cppwinrt 上打开问题会像 C++/CX 一样简单地提高在 Blend 和 Visual Studio 中使用 C++/Winrt 的能力，理想情况下像 C# 和 VB.NET 一样简单，因为我希望 cppwinrt 团队改变问题进入 Visual Studio 团队，传统上（MFC/ATL/WTL）C++ 工具团队从不关心提供与 .NET 语言相同的高级工具，即使其他公司能够使用 C++（Qt，内河航运）。

@pjmlp感谢您提供详细信息 - 我正在与一些人核对，看看是否有更多关于 C++/WinRT 工具的信息要分享，尽管到明天我可能不会有好的答案。 我们专注于 C++/WinRT 的新开发，但我们确实在我们的路线图上有它，希望有用于 WinUI 3 的 C++/CX 模板，如果有帮助的话。

我也很想知道未来 WinUI 应用程序隔离的计划是什么。 从企业的角度来看，我们需要隔离/沙盒和功能控制（而不是用户选择加入）。 所以，把它作为 Miguel 的一个话题。

@infoequipt你能详细说明隔离是什么意思吗？ 例如像AppContainer支持？

目前 UWP 及其后继者 WinUI 尚未准备好用于 LOB 应用程序

• 发布之间有很多重大更改。

@Xarlot哪些重大更改给您带来了问题？ 对于 UWP API，我们尝试在每个版本中保持高度的兼容性。

@Gavin-Williams 关于SharpDX已被弃用，您可能需要查看Vortice.Windows ，这是一个很好的选择。 @Aminator目前正在他自己的完全 UWP/C#/XAML DX12 游戏引擎和编辑器DX12GameEngine 。
希望这适合您的应用程序需求！ 😄

关于电话会议的问题，我有一个小细节，但在我们进行时：我们是否可以使用切换到 WinUI 3 来修复一些可被视为“重大更改”的旧 UI 小错误，例如StackPanel将Spacing属性错误地应用于折叠的项目？

IE。 如果您在StackPanel有一些折叠的项目，它仍然会应用它们之间的间距，如果您有一些可以以编程方式显示/隐藏的项目，它会迫使您回退到项目之间的手动填充/边距。 我已经修复了 Windows 社区工具包 ( #2838 ) 中WrapPanel的 PR 中的这个特定错误，显然StackPanel中的这种行为是其他一些 MS 工程师认可的已知问题以及。 🤔

继续伟大的工作！ 🚀

@leoniDEV感谢您指出这一点。 看看明天能不能得到一些明确的答案吧🙂

@jesbis还有两个关于 WinUI 桌面的问题（相互关联）：

1. WinUI 桌面应用程序是否具有多实例（Win32 标准）和单实例（UWP 标准）之间的内置切换？ 现在，如果我们希望 Win32 应用程序成为单实例，我们必须自己实现此行为。 这可能不仅需要应用程序锁（如互斥锁来检查实例是否已在运行），还需要 Win32 API（如SendMessage）将操作从第二个应用程序实例传递到主应用程序实例（请参阅问题 2）。 如果我们可以选择为 WinUI 桌面应用程序提供 UWP 应用程序的单实例行为，那就太好了。

1. WinUI 桌面应用程序能否使用UWP Jumplist API？ 目前，桌面桥接应用程序无法有效使用它们，因为该应用程序似乎无法激活（有关问题的简要概述，请参阅 Windows 终端问题 https://github.com/microsoft/terminal/issues/576）。 我希望为 WinUI 桌面应用程序提供此 API 的完全支持，因为它们比 Win32/WPF API 更易于使用。 例如，可以使用ms-appx:///或ms-appdata:/// URI 方案轻松设置跳转列表任务图标，而不必创建包含图像的 .exe 或 .dll，然后设置该二进制文件的路径以及特定图标的文件偏移量。

   文档总结了 UWP Jumplist API 的优点：

   或者，改用 UWP Windows.UI.StartScreen.JumpList API，它允许您使用与包相关的 ms-resource URI 方案（也是语言、DPI 和高对比度感知）来引用字符串和图像资产。

UWP 应用程序的单实例行为也可能使使用跳转列表变得更加容易。 如果您有一个跳转列表任务应该在当前运行的应用程序实例上运行，在 WPF/Win32 中，将启动第二个应用程序实例，然后需要使用，例如， SendMessage Win32 API 来发送请求的操作到主应用程序实例。 在 UWP 上使用单实例行为，正在运行的应用程序可以轻松获取调用的跳转任务。 无需在 Win32 情况下进行所有额外工作。

@pjmlp如果你还没有看过它，另一件你可能会感兴趣的事情是 Kenny Kerr 和 Scott Jones 在上次 Build 会议上的这次会议，特别是最后大约 11 分钟，他们讨论了绑定的一些原型改进和一些 C++添加反射和元类支持的技术规范可以完全删除当前的 IDL 和元数据代码生成要求：

https://youtu.be/X41j_gzSwOY?t=2659

如果我们有时间，那么我们也可以在明天的电话会议中讨论这个问题。

谢谢@jesbis ，我知道那次谈话。 据我所知，未来还很遥远。

现在看起来我更有可能将我现有的 DirectX 代码移植到诸如@Sergio0694指出的 Vortice 库之类的东西，

我确实钦佩你的努力，但从战壕来看，在 Silverlight、XNA、WinRT、UAP、UWP、WinUI、.NET Framework、WCF、EF6 之后，最终我们厌倦了继续重写。

WinUI 在各个方面都应该比 WPF 好，如果我们因为某些原因被迫使用 C++，那么它的工具应该与 .NET 开发人员喜欢的水平相同，实际上值得超越 WPF 或制作一个避免企业想要使用 Electron 风格的应用程序。

正如@Sergio0694已经问过的那样，WinUi 3.0 是否不仅可以用于切换命名空间，还可以包含其他破坏性更改，这些更改是修复错误应用空间等错误所需的？

如果是这样，是否有机会将NavigationView.IsBackButtonVisible属性重命名为BackButtonVisibility因为名称和类型目前并未真正对齐（IsBackButtonVisible 是 NavigationViewBackButtonVisible 枚举，而不是 bool）。 这也在这里讨论

@chingucoding我记得团队说过，对于 WinUI 3.0 本身，破坏性更改应该最小化，以便尽可能简单地将现有 (UWP) 应用程序移植到它。 我怀疑这些更改如果获得批准，将在后续的 WinUI 3.x/4/5/.... 版本中实施。

问：WinUI 3.x 是否支持AcrylicBrush和HostBackdrop ？ 目前已知它在 alpha 中已损坏，但我很好奇它是否在发布前修复的路线图上。

问：WinUI 桌面是否会让桌面应用程序开发人员_最终_使用AcrylicBrush和HostBackdrop ？ 我们之前将组合属性WCA_ACCENT_POLICY与ACCENT_ENABLE_ACRYLICBLURBEHIND但微软在 19H1+ 中严重破坏了这一点，我们的应用程序从那以后一直在受苦。 （它也影响了 Emoji Picker 之类的东西，但微软为这些组件提供服务以使用非丙烯酸方法。）

关于 WebView2：
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

“开发者预览版可用于 Windows 10、Windows 8.1、Windows 8 和 Windows 7 上的 Win32 C++。未来，我们计划支持 .NET 上的 WebView2 和 XAML。”

我的问题是.. 是否计划适用于 Win8.1、8 和 7 的 WebView2 SDK 的 .NET 版本？
我担心 .NET 上的 parhaps WebView2 仅通过 WinUI3 支持。 据我了解，WinUI3 WinForms 应用程序支持仅适用于基于 .NET Core 且仅适用于 Win10。
让我解释一下我的情况。我的客户端有许多使用 IE BrowserControl 的 WinForm 桌面应用程序。 但是 IE 已经过时，并且希望迁移到现代浏览器。 而且，这些应用程序应该支持 Win7、8、8.1。 （不要因为旧的操作系统支持而责怪我）

如果可能的话：

• WinUI 3.0 预览版中的 Win32 ETA

• 如果源代码还没有准备好共享，也许可以发布一些我们可以下载和玩的运行的 UI 元素的已经编译的演示 exe，向同事炫耀会很酷。

• WinUI 3.0 是否支持像 WPF/Silverlight 那样的自定义着色器效果？ 如果没有，是否有任何想法稍后添加它们？ WinUI 使用的渲染层甚至能够做到这一点吗？

@leoniDEV我继续创建了一个 XAML Island 项目，正如您突出显示的那样（因此没有单独的 UWP 项目）。 它包含一个 UWP 收件箱控件（一个按钮）并且在 10X 上运行良好。 容器故事并不奇怪……它按预期在 Win32 容器中运行。

因此，至少现在似乎还没有完全支持使用单独的 UWP 项目的 XAML 岛应用程序。

我正在考虑对传统 WPF 应用程序进行 v-next。 我可能可以使用 .NET Core WPF，但我真的很想使用 WinUI。 我遇到了像 Prism 这样仍然源自 Windows.UI.Xaml（而不是 Microsoft.UI.Xaml）的库的问题。 感觉这些类型的问题是基础性的。 是否有针对 WinUI 的可靠 PnP 指南，还是为时过早？

是否可以请 shell 团队或收件箱应用程序团队的某个人讨论为什么 Windows 10x 上的开始菜单和文件资源管理器是基于 Web 的而不是使用 WinUI？

我所需要的只是从我们当前的 UWP 应用（带桌面扩展）到 WinUI 桌面应用（不带桌面扩展）的无缝移植体验。 这可能吗？ 在这种情况下有哪些陷阱？

如果这被证明是困难的，将来是否有可能改进 UWP（对于在桌面上运行的应用程序）以始终在后台运行应用程序并允许它们通过 P/Invoke 调用所有 win32 API 并允许加载 dll其他 dll 没有 LoadPackagedLibrary（但有 LoadLibrary）。

当第一批 Windows 10X 设备启动时，WinUI 3.0 准备启动的可能性有多大？ 我对跳入 Windows 开发世界很感兴趣，我正在尝试确定此时哪种方法最有意义。

感谢大家的提问和观看，如果你能做到！ 录音在同一链接上直播。

有很多我们没有解决的问题 - 我会尝试总结它们并尽快在此处发布一些回复。

优秀的表演者，感谢您提出我的问题和 Miguel 的介绍。

我将添加一些我留下的问题，希望它们能得到解决。

1. 传统的 Win32 应用程序在 WM_PAINT 中绘制到屏幕上。 XAML 应用程序是保留模式。 我们在屏幕上绘制了太多东西来创建单个对象/控件。 是否还会有一个 WM_PAINT 等效项允许我使用更现代的 API 绘制到窗口？ Win2D 或其他一些即时模式 API？

2. 可访问性在 Win32（COM API）与 WPF（自动化对等）中的处理方式不同。 如果我编写一个 Win32 + WinUI 应用程序，我是否能够更轻松地增加或控制辅助功能树？ 还是我会坚持使用旧的 COM API？ 我如何将我的自定义绘制内容与辅助功能树中的辅助控件混合在一起？

3. 今天，我们通过在打印机 DC 中绘图来打印。 Win32+WinUI有新的打印吗？

4. 我仍然对 HWND、CoreWindow 和 WinUI 的任何后续内容之间的关系感到困惑。 HWND 是否仍然存在，或者我们是否会用其他东西替换 CreateWindow 调用？ 我认为是这样......但如果是这种情况，我认为对于我们必须将其移交给外部组件（例如父 HWND）的情况，仍然必须有一个底层 HWND。

5. 在 Win32+WinUI 应用程序中使用 WebView2 是否会遇到我们在嵌入式 IE 控件中遇到的空域问题？

开始追上一些问题：

WinUI 只是 UWP 开发而是更现代的规范吗？ 我看到有关 WinUI 的对话，但我不确定他们是在谈论 UWP 开发、UWP 开发中的特定库还是完全不同的东西

WinUI 是专门的 UI 层，不包括 UWP 应用平台的其他方面，例如用于暂停/恢复的应用模型、后台任务等。

对于 UWP 应用，它可以专门替换Windows.UI.Xaml 、 Windows.UI.Composition和Windows.UI.Input 。

WinUI 应用程序是否具有在多实例（Win32 标准）和单实例（UWP 标准）之间的内置切换？

@Felix-Dev 我们还没有探索过为 win32 应用程序提供更好的单实例支持的想法 - 如果您有建议，请随时在此 repo 中为它打开一个问题！

WinUI 3.x 是否支持带有 HostBackdrop 的 AcrylicBrush？ 目前已知它在 alpha 中已损坏，但我很好奇它是否在发布前修复的路线图上。 WinUI Desktop 能否让桌面应用开发者最终将 AcrylicBrush 与 HostBackdrop 结合使用？

@riverar不幸的是，这不在 WinUI 3.0 RTM 的计划中。 在与操作系统分离的 UI 平台中支持这一点存在挑战，但我们计划在 3.0 之后重新审视这一点。

关于WebView2：我的问题是..是否计划推出适用于Win8.1、8和7的.NET版本的WebView2 SDK？
我担心 .NET 上的 parhaps WebView2 仅通过 WinUI3 支持。

@pnp0a03 WinUI Xaml 控件仅在 WinUI 3 中受支持，但有适用于 Windows 7、8 和 8.1 的核心 WebView 2 SDK 的开发者预览版，适用于 win32 应用程序：

https://docs.microsoft.com/microsoft-edge/hosting/webview2

我遇到了像 Prism 这样仍然源自 Windows.UI.Xaml（而不是 Microsoft.UI.Xaml）的库的问题。 感觉这些类型的问题是基础性的。 是否有针对 WinUI 的可靠 PnP 指南，还是为时过早？

@GraniteStateHacker我认为这有点太早了 - WinUI 3 仍然太新，无法获得太多的生态系统支持（它只是在 alpha 中）但@hassanuz正在启动一个工作流来调查库兼容性/迁移选项。

WinUI 仅适用于商店应用程序吗？

不 - 您可以通过多种方式使用它，例如：

• 使用 Xaml Islands 将其包含在现有的 win32 应用程序（WPF、WinForms、MFC 等）中
• 构建一个 MSIX 安装程序并根据需要进行部署
• 创建一个未打包的应用程序并通过 xcopy 或其他方式分发它（WinUI 3 尚不支持，但计划用于 RTM）

当第一批 Windows 10X 设备启动时，WinUI 3.0 准备启动的可能性有多大？ 我对跳入 Windows 开发世界很感兴趣，我正在尝试确定此时哪种方法最有意义。

@dwalleck WinUI 3 已经发布了 alpha 版本，并且应该在Build会议时间范围内提供更多功能的预览，并且都针对 2020 年末。如果您从 UWP Xaml 和/或 WinUI 开始，那么您应该走上 10 倍开发的良好道路.

传统的 Win32 应用程序在 WM_PAINT 中绘制到屏幕上。 XAML 应用程序是保留模式。 我们在屏幕上绘制了太多东西来创建单个对象/控件。 是否还会有一个 WM_PAINT 等效项允许我使用更现代的 API 绘制到窗口？ Win2D 或其他一些即时模式 API？

@jschroedl Xaml 元素树和画笔是保留模式，但您可以使用多个选项中的一个或多个来包含轻量级渲染原语：

• 合成层视觉效果
• 组合层形状，可以绘制非常高性能的保留几何图形 - 也用于 WinUI AnimatedVisualPlayer控件之类的东西，它可以播放 Lottie 形状/动画
• DirectX 使用SwapChainPanel、SurfaceImageSource 或 VirtualSurfaceImageSource与 Xaml 互操作（取决于您想要交换链还是虚拟化/非虚拟化画笔模型）
• Win2D，它为您抽象了上述 DirectX 互操作（使用 Direct2D、DirectWrite）并提供了一个 .NET API

可访问性在 Win32（COM API）与 WPF（自动化对等）中的处理方式不同。 如果我编写一个 Win32 + WinUI 应用程序，我是否能够更轻松地增加或控制辅助功能树？ 还是我会坚持使用旧的 COM API？ 我如何将我的自定义绘制内容与辅助功能树中的辅助控件混合在一起？

好问题！ 分页@marb2000以确保涵盖此内容并提供最新更新。 一般来说，WinUI Xaml 树应该使用 AutomationPeers，但我不确定这是否会将任何新功能扩展到非 WinUI win32 内容。

今天，我们通过在打印机 DC 中绘图来打印。 Win32+WinUI有新的打印吗？

WinUI 内容的主要打印功能应通过 WinRT PrintDocument API 的 WinUI 版本实现。

我仍然对 HWND、CoreWindow 和 WinUI 的任何后续内容之间的关系感到困惑。 HWND 是否仍然存在，或者我们是否会用其他东西替换 CreateWindow 调用？ 我假设是这样......但如果是这种情况，我认为对于我们必须将其交给外部组件（例如父 HWND）的情况，仍然必须有一个底层 HWND

WinUI 不会取代 hwnds，但目标是通过提供 Xaml API 来抽象出它们在常见用例中的使用 - 有点类似于 WPF 的工作方式。 Xaml API 确实仍将使用 hwnds/CoreWindows 作为底层实现细节，我们可能会使用“后门”/“escape-hatch”API 在需要时直接访问 hwnd。 我们应该在几周内有一份提案草案，这将使这一点更加清晰。

@jesbis谢谢你的回答，但不幸的是我的担忧没有得到解决。
目前，WebView2 SDK Win32 "C++" (preview) 版本已从本站发布。 它支持 Win7、8 和 8.1。
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
我的问题是关于 .NET 版本。 目前，.NET 版本仅支持 WinUI 3，但是，如您所知，我们无法在 Win7、8 和 8.1 上使用 WinUI 3（对吗？）。
因此，我已将我的问题发布如下。

我的问题是.. 是否计划适用于 Win8.1、8 和 7 的 WebView2 SDK 的 .NET 版本？

@jesbis感谢您回答我的问题，尽管这让人感到沮丧。

试图在这里有建设性。

因此，微软在 C++/WinRT 工具方面所能提供的最好的东西是指出一些悬而未决的建议，如果有的话，幸运的话可能会落在 ISO 之间的某个位置。 然后等待 Visual Studio 团队最终在它们之上重建 C++/CX，这使得它从现在开始大约 6 年。

如果我想要出色的 C++ UI 工具，WinUI 绝对不是，而是 Qt 或 C++ Builder，具有平台可移植性的额外好处。

所以在看完演示后，仍然带着 XNA（用 DirectXTK 用 C++ 重写）、WinRT 8.0、WinRT UAP 8.1、UWP W10、C++ Direct2D 而不是 System 的伤疤。 绘图（直到 Win2D 出现，现在停滞不前），WinUI 绝对是我将搁置的东西。

展望未来，我会建议我的客户在使用 .NET 时使用 WPF，在使用 C++ 时使用 Qt，或者在 Web 技术可行的情况下专注于 PWA。

如果 UWP 在桌面市场上销售不断失败，WinUI 3.0 路线图不会激发人们对再次重启即将到来的任何信心。

从某种意义上说，我想指出的是，自从 Windows 8 发布以来，在我们失败了很多次之后，微软管理层应该考虑如何向我们推销采用 WinUI 的想法。

@pjmlp一般的 C++/WinRT 反馈可能最好针对 cppwinrt 存储库。 ISO 标准更新需要时间，但我希望它比你提到的时间框架短——反射支持是重中之重，他们上周刚刚在布拉格的 C++ 会议上讨论了它。

仍在开发中的 DirectXTK 已得到定期更新。

在 Xaml 框架 API 方面，WinUI 是前进的道路，并且具有相当完整的兼容性沿袭 Windows 8 - 我们花了很多时间试图保持高度的兼容性🙂 有一些变化（由于外壳集成， VS 项目结构等），但在大多数情况下，您可以将 Windows 8 Xaml 移植到当前的 Windows 10 应用程序，重新编译它并在最新的内部版本上运行它，它会起作用。

WinUI 的一些高级优势将包括消除 UWP WinRT API 和 win32 API 之间的障碍、支持 .NET 5、启用对新功能的立即下层支持、无需进行许多条件操作系统版本检查、启用 OSS 贡献和使用 Xaml 岛启用对现有 win32 应用程序的增量更新。

@pnp0a03也在努力将 .NET 元素推向市场。 我无法给出具体日期，但我们知道对此的需求并正在制定细节。

@jschroedl我们想消除空域问题，我们正在努力制定一个渲染计划来帮助我们实现这一目标。

@jesbis如前所述，我不相信抱怨 cppwinrt 会做任何事情，我宁愿抱怨不采用 C++/WinRT，除非对于我无法避免的用例，特别是因为路线图是采用甚至可能不被接受的功能国际标准化组织。

关于 DirectXTK，我给出了另一个例子，说明微软如何通过放弃 XNA 并提供 DirectXTK 作为“替代品”，迫使我们将 C# 代码重写为 C++，使用功能较弱的工具。

幸运的是，开源社区设法提出了 MonoGame，并完成了微软拒绝使用 XNA 进行的工作。

我在演示期间和这里的一些评论中看到了，C++ 是多么伟大和有趣，WinDev（自从 Longhorn 接手以来又一次）如何保持先销售 C++，然后再销售 .NET。

如果我想要出色的 C++ 工具，Qt 和 C++ Builder 是我的首选环境，而不是 Visual C++。

你真的应该要求管理层让你的团队看看今天在竞争中什么是可能的，而不是期望一些元类和反思的想法会被 ISO 接受。

我们不仅要处理不会从 .NET Framework 转移到 .NET Core 的 API 和第三方库，我们还必须处理从 WPF/UWP 到 WinUI 的所有迁移问题以及“只需编写它在 C++/WinRT 中，很酷，而且在几年内会更好”的心态。

微软管理层真的必须考虑清楚，如何将这个重写版本卖给烧毁的 .NET 开发人员，否则我们不会离开已经完成他们工作的堆栈。

@pjmlp说到 DirectX，我正在空闲时间积极开发一个可移植且不可知的 C# 图形、音频和输入框架，它将能够在 WinUI 视图中运行 D3D12/11 等......等等。

与 XNA 之类的渲染方法相比，它支持更现代、更注重性能的渲染方法。 它还没有准备好使用，但是很多人都想要，包括我自己……所以我正在制作它。 D3D12 和 Vulkan 将是第一个支持的目标。 您还可以使用 C# 而非 HLSL 或 GLSL 等编写着色器。

当它准备好使用时，我会分享更多，但因为这是一个框架，而不是一些庞大的 SDK 或游戏引擎，它将非常便携和轻量级，但功能强大且易于使用。 非常适合在 WinUI、WPF 或某些本机 C# Win32 或 WinRT 应用程序中呈现 3D 内容。

https://github.com/reignstudios/Orbital-Framework

@zezba9000谢谢你提供的信息，你做了很多令人印象深刻的事情，荣誉！

我想在 DirectX 的托管支持方面，我们只能依靠像您这样的社区努力，在击败托管 DirectX 和 XNA 之后，C++ MS 人群接管了 DirectX 开发工作。

至少这些项目中的任何一个都可以算作我的倡导，作为营销向其他人展示它不需要像 WinDev 喜欢推动的那样只是“C++ 或高速公路”。 在这里，他们可以学习 OpenGL ES/Metal 与 Swift，或 OpenGL ES/Vulkan 与 Java/Kotlin。 显然，使用托管语言进行 3D 编程并不是移动平台赢得 Windows 的问题（遗憾的是，WP 是一种很棒的体验）。

祝你好运，用 C# 编写着色器看起来很吸引人，而且我不知道 CS2X。

@pjmlp Ya CS2X 部分将允许在 C# 中编写不可知的 GPU 着色器（这很酷，因为您将能够在理论上对您的着色器进行单元测试）。 对于可以使用 C# 子集的目标，CS2X 允许我/其他人使用非常轻量级的运行时将当前 .NET 运行时支持的平台之外的平台作为目标，因为 CS2X 可以将 C# 子集编译为 C89 运行时......并且因为轨道框架可以针对 CS2X => C89 运行时，它反过来也可以针对这些平台。

大项目，但它是我关心的，我致力于实现它。

是否可以在 WinUI 2.4 中使用 HwndHost
我试过预发行版，但没有用。
WinUI3 是否也可以使用所有这些新计划的窗口（XAML 窗口）和应用程序（XAML 应用程序），如果是的话，我们可以期待第一次预览时看到它。
实际上，如果它可以在 WinUI3 中实现，此功能是否会添加到 WinUI 2 新版本中，或者 WinUI 2 将仅适用于 Uwp 应用程序。
例如现在，我们有 WPF 应用程序，它通过 HwndHost 使用大量 C++ 代码，并且因为我们计划将所有内容都移至 WinUI，所以这部分对于我们决定使用 WinUI 或其他东西非常关键。 甚至 WinUI 2 对我们来说也很好看，XAML 部分很容易转移，Composition Api 工作得很好，Uwp Community Toolkit 工作得很好，只是我们不能使用 HwndHost 和 c++ Win32 代码。 那么，WinUI3 何时会解决这个问题？ 我也很喜欢 x:Bind 但这甚至有可能发布 WinUI3。

@zezba9000

说到 DirectX，我在空闲时间积极开发可移植且不可知的 C# 图形、音频和输入框架，该框架将能够在 WinUI 视图中运行 D3D12/11 等......等等。

祝你好运！ 这是一个疯狂的工作量！

是否可以在 WinUI 2.4 中使用 HwndHost
我试过预发行版，但没有用。
WinUI3 是否也可以使用所有这些新计划的窗口（XAML 窗口）和应用程序（XAML 应用程序），如果是的话，我们可以期待第一次预览时看到它。
实际上，如果它可以在 WinUI3 中实现，此功能是否会添加到 WinUI 2 新版本中，或者 WinUI 2 将仅适用于 Uwp 应用程序。
例如现在，我们有 WPF 应用程序，它通过 HwndHost 使用大量 C++ 代码，并且因为我们计划将所有内容都移至 WinUI，所以这部分对于我们决定使用 WinUI 或其他东西非常关键。

在 WinUI XAML 中托管 user32/comctl 或 WPF UI 的方法存在一个问题： https :

好像要到3.0以后才会制作，如果制作的话。

我把这个贴到#1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833但我会复制
它也在这里：现在我们有 WPF 应用程序，它通过使用大量 C++ 代码
HwndHost 控制。 我们计划将 Wpf 应用程序移至 WinUI 并移至 Xaml
效果很好，没有问题，但是 HwndHost 呢，这会是
可以使用 WinUI3。 在我们的例子中，我们正在与
DirectShow 通过 HwndHost 和现在在 WinUI 2 中，这不是
可能的。 在 WinUI3 中使用 HwndHost 的实际日期是什么？ 也是
这个新的 Xaml 窗口和应用程序就像最迟在二月份讨论的那样
WinUI 社区电话，是否有帮助？

埃尔多姆，2 月 23 日 de 2020 a la(s) 13:42, Max Strini (
通知@github.com）escribió：

是否可以在 WinUI 2.4 中使用 HwndHost
我试过预发行版，但没有用。
有了所有这些新计划，WinUI3 是否也将成为可能
窗口（XAML 窗口）和应用程序（XAML 应用程序），如果是，当
我们可以期待第一个预览看到这一点。
实际上，如果在 WinUI3 中可以实现此功能
被添加到 WinUI 2 新版本中，否则 WinUI 2 将只适用于 Uwp 应用程序。
例如现在，我们有 WPF 应用程序，它通过使用大量 C++ 代码
HwndHost，并且因为我们计划将所有内容都移至 WinUI，所以这部分
对我们决定使用 WinUI 或其他东西非常关键。

在内部托管 user32/comctl 或 WPF UI 的方法存在问题
WinUI XAML：#1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

好像要到3.0以后才会制作，如果制作的话。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWXW6L043VMWSQWQL020OEMT200400000000000000000000000000000000400000000000000000Mvvwwwxwxaml3
或取消订阅
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
.

——
马里奥·兰契奇
软件工程师
微软认证专家

上周非常好的 WinUI 社区电话会议！ 内容非常有趣且详细/技术性足以提供很多见解。 路线图/开发状态更新对于 WinUI 的消费者和我们自己的开发路线图也非常有价值。 期待下次来电！

关于 WinUI 3 中的 HwndHost。
HwndHost 允许在 WPF 内托管 Win32 内容。 不幸的是，WinUI 3.0 中没有计划支持这一点，包括 WinUI 3.0 Desktop 或 WinUI Islands。 关于@mariorancic01描述的场景，您是否评估了 UWP MediaPlayer API 而不是 DirectShow？

好吧 Uwp 相机看起来更好，但不确定我们是否可以在我们的场景中使用它。
我们使用相机作为 DirectShow 的虚拟相机，我们需要它显示
视频，以获取照片的相机流以及 PjSip 中的
同时，在我们可以使用 DirectShow 完成之前。 我们可以使用这个 Uwp
带有 PjSip 的媒体播放器。

El mié.，2 月 26 日 de 2020 a la(s) 23:47, Miguel Ramos (
通知@github.com）escribió：

关于 WinUI 3 中的 HwndHost。
HwndHost 允许在 WPF 内托管 Win32 内容。 不幸的是有
WinUI 3.0 中没有计划支持此功能，包括 WinUI 3.0 Desktop 或
WinUI 群岛。 关于场景@mariorancic01
https://github.com/mariorancic01描述的，你评价过UWP吗
MediaPlayer API 代替 DirectShow？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW6ZLDNHPM52HS4DFVREXG43VMVBWJKLODNV95G43VMVBW6ZLODNC50000000000000100000000000000000000000000000000000000000000000000000000000不同
或取消订阅
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
.

——
马里奥·兰契奇
软件工程师
微软认证专家

我对 Windows Store for Business 有疑问，这看起来非常酷，对 LOB 应用程序非常有用，但我读到这可能会被放弃。 任何人都可以谈谈有关此的计划。

@marionrancic01这并不是真正必要的，因为您现在可以通过 MSIX 打包分发 UWP 应用程序。

悲伤，就像@mariorancic01一样，我也发现适用于企业的 Windows 应用商店很有用 😞

@leoniDEV我真的很好奇为什么你需要 Windows Store for Business，当你可以简单地发布为 msix 时，正如@kmgallahan所说

@kmgallahan @jtorjo我想他们正在寻找的是拥有一个私有应用程序目录。 MSIX 不提供，我相信？ 除非您建立一个网站，在其中列出您公司提供的 MSIX，或者使用某些管理工具将内容部署给您的用户？
以类似的方式，旧的 MSI 安装程序也不提供发现应用程序的方法。

发布到 Windows 应用商店不是在公园里散步 - 它比您想象的要复杂。 首先，您需要等待来自 MS 的证书 - 您将用于发布的证书（我现在不记得确切的步骤）。 然后，您需要确保您的应用没有违反任何商店要求。 然后，您所做的任何更新可能需要数天才能被接受（或者可能被拒绝），并且您将依赖商店的算法让人们找到您的应用程序。

但是如果你自己部署，设置起来会有点困难（我会知道），但是一旦完成，就很容易了。 但是，是的，您将负责向全世界展示您的应用。

作为在 Microsoft Store 上拥有多个应用程序（包括商业应用商店）的人，我可以告诉您，在过去几个月中，向 Microsoft Store 发布应用程序变得更好了。 定期更新的认证有时会在几个小时内完成。 商店指南也很容易满足。
另一方面，干扰独立的 msix 可能很复杂。 与商店为您签署软件包不同，如果您在商店外分发您的应用程序，则需要自行签名。

@jtorjo您不需要任何证书。

需要明确的是，商店存在问题，开发人员仪表板确实会不时关闭，但我上面的观点是，拥有商业应用程序商店非常方便。

作为在 Microsoft Store 上拥有多个应用程序（包括商业应用商店）的人，我可以告诉您，在过去几个月中，向 Microsoft Store 发布应用程序变得更好了。 定期更新的认证有时会在几个小时内完成。 商店指南也很容易满足。

@yaichenbaum知道这绝对是件好事。 当我出版时（大约两年前），它更难。 是的，您确实需要自己签名——事实上，您购买了一个证书，并将其作为“发布”过程的一部分进行签名。 所以一旦你设置了它，你就可以忘记它。

@riverar当我发布时（