Xamarin.forms: Uwp Xamarin.Forms.Shell

目前仅为 Android 和 iOS 提供 Shell 支持。 我们正在不断评估有关潜在的未来 UWP 支持的反馈，并将在未来提供更多可用信息。

我通常为我的手机用户使用 iOS 和 Android，为我的平板电脑和桌面用户使用 UWP。 因此，拥有 UWP 支持对于保持 Windows 用户的参与度非常重要。

什么？？ MS真的是在抛弃自己的平台。 听到这令人难过！

没有关于何时提供 UWP 支持的任何可见性？ 还是已经做出了决定？

对 UWP 的 Shell 支持 - 请！

我还希望看到 UWP 对 Shell 的支持。

对于我的公司来说，UWP 非常重要，因为我们的客户将 Windows 平板电脑与一些 Android 手机结合使用来完成他们的工作。 如果缺少 UWP 支持，我们将无法迁移到 Shell。

同意 - UWP 兼容性允许我通过我的移动实现来烘焙 Windows 平板电脑功能。 如果没有它，我必须完全单独编码。 糟糕！ UWP 兼容性是必备的！

不知道有没有道理，因为我还没用过Shell。 但也许有一种方法可以将应用程序的所有其他元素（除了 Shell）用于 UWP 实现。 毕竟使用 TabbedPage 和 MasterDetailPage 会达到同样的效果，看起来。

我也会投票支持在 Shell 中使用 UWP 的能力。

请使用 UWP... 或者至少是我们可以依赖几年的 Microsoft UX API 的某种风格。 这种“我们稍后会通知您是否支持它”的方法只是卑鄙。

所以，是的，UWP 或其他任何东西都会支持它，但更重要的是：承诺我们何时会知道。

没有这种把握就不能搬到壳牌。

不仅 UWP，MacOS 也请。

不知道你有没有意识到，UWP 不仅是一个仍然被开发者广泛使用的平台，也是让基于 Android 和 iOS 的 XF 应用程序启动和运行的最快方式。 因为 - 相比之下 - 为 Android 和 Mac 世界提供的模拟器非常缓慢，容易出现问题，让我们不要谈论可怕的认证体验，或者仍然被迫拥有一台真正的 Mac，好吗？ 因此，即使它毕竟不能取代在真实事物上的开发，UWP 应用程序通过提供一种快速、简单和全面的方式来完成......事情......完成，从而提高了开发人员的工作效率。 然后：尽一切努力让您的应用程序在 iOS 和 Android 上启动并运行。

那么你会为 UWP 添加 shell 支持吗？

https://github.com/xamarin/Xamarin.Forms/pull/6015

同意@Mephisztoe，它确实是一个很好的生产力工具，当然，让该应用程序实际可用于 Windows 的选项也是一个不错的加分项 :)

请不要仅将 Xamarin.Forms 降级到移动平台。 我希望看到对 UWP 的持续支持，尤其是对 WPF 和 GTK# 的支持。

因此，基本上任何拥有 Xamarin Forms 中所有三个平台的跨平台应用程序的人现在都无法更新和使用这些功能。 如果 Xamarin Forms for UWP 的未来开发不会发生，为什么不从跨平台列表中删除 UWP？

不同的平台总是有不同的优先级。 毕竟，您说的是“所有三个平台”，而不是“所有七个平台”。

@GalaxiaGuy是对的，我确实说了所有三个平台，考虑到如果我说七个平台，我将组成虚构的平台。 根据 Xamarin.Forms 文档：

Xamarin.Forms
Xamarin.Forms 为 .NET 开发人员公开了一个完整的跨平台 UI 工具包。 在 Visual Studio 中使用 C# 构建完全原生的 Android、iOS 和通用 Windows 平台应用程序。

在自述文件上它说：

Xamarin.Forms 提供了一种完全在 C# 中为 iOS、Android、Windows 和 macOS 快速构建本机应用程序的方法。

这并不意味着它也不支持 GTK、WPF 和 Tizen。

我同意这些平台可能不如 UWP 重要，但有很多人认为 UWP 不如 iOS 和 Android 重要。

不过，我大体上同意这种观点，我不得不自己忽略较新的功能，因为它们不在 UWP 上。

仅供参考，除非我错误地阅读了发行说明，否则在 4.1 预览版中似乎有针对 Tizen 的ShellRenderer实现。 没有提到 UWP。

如果来自@dotMorten的拉取请求需要一段时间才能合并，也许有人可以采用该实现并将其移至由社区管理的单独“预发布”NuGet 包，直到/如果我们获得官方支持。 这样我们就可以在不使用 Xamarin.Forms 的完整预发布或自定义版本的情况下使用它。 如果我们没有得到官方支持，那么 repo 就已经设置好了，社区可以接管。

我很抱歉这没有加快速度。 我在与 master 同步时遇到了一些倒退，我已经完全被工作和家庭相关的事情淹没了，所以没有太多时间真正坐下来尝试解决它。 但是，我非常乐意为我的分支接受 PR。

我们还将在 UWP 上可用时立即使用该外壳。 我们有和上面一样的问题。 我们有平板电脑、手机和笔记本电脑，Android 和 Windows。 而且我们也认为最好的开发环境是UWP

这个问题是我放弃 XF 的主要原因之一。 对于我们的客户而言，台式机和移动设备具有相同的优先级。

我还能说什么，还没有说..

所以继续吧！
UWP 支持对 Microsoft 来说不是可选的——你真的需要被告知吗？

@papiermache请注意行为准则适用于该项目的所有交流、问题和评论

也将此视为对 MS Xamarin 对开发人员承诺的测试。 MS方面有人准备称重吗？

对不起，我会缓和进一步的想法……但我完全震惊地发现缺乏 UWP 支持——我从来没有想过 UWP 从一开始就不是一个包含的平台。 瑞克。

来自：杰里米通知@github.com
发送时间：2019 年 8 月 16 日下午 2:28
至：xamarin/Xamarin.Forms [email protected]
抄送：Rick Piovesan [email protected] ； 提及[email protected]
主题：回复：[xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

@papiermache https://github.com/papiermache请注意行为准则适用于本项目的所有通信、问题和评论

—
你收到这个是因为你被提到了。
回复此电子邮件直接，查看它在GitHub上https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 ，或静音线程https://github.com/通知/取消订阅身份验证/ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A 。

嗨@dotMorten ，你能提供任何更新吗？ 您是否仍打算尝试让 UPW+Shell 工作？ 理解这是一种善意和社区的行为:) 只是想知道，因为您的努力似乎最接近于让 Shell+UWP 工作。 微软似乎对 Xamarin 不再支持 Windows 的做法仍然感到十分困惑。 感谢所有其他的善良，但仍然感到困惑和沮丧。

对不起。 现在有点烧坏了，所以我没有重新审视这个。 我记得与最新的合并导致了很多回归，只是没有时间也没有精力让它恢复速度。 还确定了一些需要改变的事情，需要 XF 团队更广泛的支持，但除了“当然让我们研究一下”之外没有得到太多支持，然后就消失了。 一般来说，我从 XF 团队得到的支持和反馈只是鼓励，但缺乏跟进。 仍在等待对我所做工作的反馈，但在这一点上它可能已经过时了。 希望我很快就会有一些时间和精力重新投入其中。

这个问题目前在评论最多的前 10 个未决项目中，但它不在完成的路线图上。

@pauldipietro我们可以得到更新吗？ 在我看来，这是一个信号，即 UWP 支持不再是 XF 团队的优先事项。 如果这是真的，请告诉我们，以便我们制定计划。

谢谢

同意，我只想知道 XF 是否不包括 Windows 支持。 如果不行，我也想知道为什么不行？ 他们是否知道除 UWP 之外的“下一个”Windows UX 堆栈将是什么并且不想浪费周期？ 一些 Blazor/HTML 的东西会成为下一件吗？ 如果是这样，请让我（我们）知道，以便我可以过渡...也许到 uno 平台？

来自：Scott Kuhl通知@ github.com
发送时间：2019 年 8 月 22 日星期四下午 1:21:22
至：xamarin/Xamarin.Forms [email protected]
抄送：David Gerding [email protected] ； 评论[email protected]
主题：回复：[xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

这个问题目前在评论最多的前 10 个未决项目中，但它不在完成的路线图上。

@pauldipietro https://github.com/pauldipietro我们可以得到更新吗？ 在我看来，这是一个信号，即 UWP 支持不再是 XF 团队的优先事项。 如果这是真的，请告诉我们，以便我们制定计划。

谢谢

—
您收到此消息是因为您发表了评论。
回复此电子邮件直接，查看它在GitHub上https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 ，或静音线程https://github.com/通知/取消订阅身份验证/AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A 。

坦率地说，在我看来，最好的选择实际上是用 Uno Platform 替换 XF ......

Xamarin 已明确表示，他们的目标主要是移动设备（手机、平板电脑、手表），而不是台式机或笔记本电脑。

他们对自己支持和维护 UWP 没有兴趣，所以我不推荐给我的客户。

我想澄清我的需求：Xamarin Forms 不需要 _UWP_。 我需要 _some Windows target_ 用于 Xamarin Forms。 UWP 似乎是最可行的候选者。 如果我不得不猜测微软最终会转向桌面的 HTML 和 Blazor 客户端，因为它可能会给他们在后 Windows 世界中最广泛的 UX 影响。 这也可能更适合可组合的 shell（不是 xf shell）路径。 由于在 UX 的 Windows 方面没有任何连贯的路线图，我无法想象他们还会计划什么。

但需要明确的是，放弃 Windows 对 Xamarin 的支持而不用粗体字宣布“我们不会也不会做 WINDOWS”，至少是非常非常不友好的。 它听起来像“老微软”。

@davidortinau等人：请做更多的事情，而不是指出现在已经死了（参见@dotMorten的最新帖子）“XF Shell + Windows 的社区支持”。

我非常感谢 Xamarin 中所有新的和酷的东西。 但我需要对使用 Xamarin 的 Windows 目标的未来可行性（如果有的话）做出更诚实的回应。

需要改变并需要 XF 团队更广泛支持的几件事情

我知道其中一个与 WinUI 有关，我们希望将其作为此 PR 的依赖项
https://github.com/xamarin/Xamarin.Forms/pull/7214

该 PR 保持 16299 兼容性，并且根据我的测试，当它包含在 nuget 中并且不需要用户安装 WinUI 时效果很好。 我仍然需要在虚拟机中启动 16299 以确保，但我保持乐观。 我知道@dotMorten您曾表达过一些对引入 WinUI 的担忧，所以如果我完全忽略了这些，请告诉我 :-)

这是那个nuget。

Xamarin.Forms.4.3.0.1853.zip

如果其他人想为我们测试它，并让我们知道您是否有任何真正有用的问题。 我已经用基本的 UWP 模板对其进行了测试，它对我来说很好用，没有崩溃。

我目前看到的路径是

• get #7214 合并，以便我们处理 WinUI 依赖
• 重新调整 UWP Shell PR（我们已将其安排在未来的 sprint 中，因此我们要么在那时执行此操作，要么在其他人击败我们时执行此操作）
• Morten 已经让它与 Gastropods 一起工作，所以我们只想用更多的样本（主要是 Xaminals）来测试它，一旦它工作并且我们进行任何需要的代码清理更改，我们将合并

如果我在该路径上遗漏了任何内容，请告诉我，我们将尝试解决它，因此需要做的就是重新设置基准和针对 Xaminals 进行验证。

@PureWeen ，
我可以使用您提供的 Xamarin Nuget 运行 App132.zip。 应用程序似乎工作正常......假设它应该将带时间戳的元素添加到列表控件。 顶部的按钮和下拉刷新行为都添加了元素。

不确定我在寻找什么，但我感谢您的努力，并会尽我所能提供帮助。

戴夫 G

@PureWeen很
此外，WinUI 中的一些错误让我很头疼，但我最近注意到我记录的一些错误得到了修复，所以这一切都令人鼓舞。 一旦 7214 进入，请 Ping 我，我将尝试开始这项工作。
也很乐意帮助重新定位。 上次我这样做时，我完全搞砸了这个 PR :-)

@dotMorten听起来不错！！

我确实在 VS 2017 上测试了上面包含的应用程序，它对我有用，所以我认为我们在这方面没问题

不确定我在寻找什么，但我感谢您的努力，并会尽我所能提供帮助。

主要的事情是将 nuget 添加到您的主要 UWP 项目中，并确保它们似乎都可以编译并运行正常。

只是试图审查添加 WINUI 依赖项不会引起任何头痛:-)

我确实在 VS 2017 上测试了上面包含的应用程序

没有也将 WinUI 添加到项目负责人？ 这就是我发现的问题：如果人们要升级到依赖于 WinUI 的 XF 版本，如果不手动向 WinUI 添加依赖项，它将无法工作。 恕我直言，这是一个突破性的变化。 WinUI 可以更改他们的包，使其隐式工作，但它需要 VS2019，因为它依赖于 NuGet 5.0 功能（而且他们还没有进行此更改，因此它现在无法正常工作）。

这是我在 WinUI 中登录的问题： https :

我可能只是做一个快速 PR 来至少解决这个问题，这样 VS2019 用户就不必手动添加额外的依赖项。

只是补充一点，当我测试 app123 时，它使用的是 VS2019。

没有也将 WinUI 添加到项目负责人？

是的，我上面链接的项目我可以在 VS2017 中打开，它编译并运行良好。 我没有将 WinUI nuget 添加到 UWP 头，它仅表示为 nuspec 内部的依赖项

我真的不明白这是如何工作的。 有一个样式需要添加，一个额外的appx框架包需要随包一起安装，这一切都由.targets来完成。 您的机器上是否已经安装了框架包？

Visual Studio Magazine 特别报道了这个问题。 微软，是时候做出正式回应了。

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten我出去了几天，但我回来后会调查一下。 我还联系了 WinUI 团队进行审核

当我在 VS 2017 上测试时，这个目标可以很好地传递
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

这是一个更新的 nuget，可让您覆盖本地表单项目中的设置
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

在表单项目中，我们将其强制设为 true，这样人们就不会感到惊讶。

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeen这是在不显式添加这些行的情况下应该工作的部分（因为所有用户也必须更新他们的项目负责人）：

我认为你是说它确实有效，但只是确保我们在同一页面上。

可能您认为这是一个可以接受的重大更改，但我记得这最近发生在另一个依赖项中，并且让很多人望而却步，因为升级路径并不像选择一个新的 XF 版本那么干净。

回复：Xamarin Forms 需要桌面/笔记本电脑/平板电脑目标

对于我们这些在企业环境中构建移动应用程序的人来说，从与 Android/iOS 基础相同的基本代码库生成“类似工作”的桌面/笔记本电脑可执行文件的能力是必不可少的。 它不需要只是 Windows（基于浏览器的目标，例如 HTML/JS 也一样好），但我们的绝大多数用户都拥有 Windows 台式机/笔记本电脑 + iPhone/Android 手机，因此 Windows 可执行文件是大多数情况下都很好。

我们发现，当我们在组织内提供移动应用程序时，我们的大多数用户希望首先在他们的笔记本电脑/台式机上试用它 - 只有当他们发现它有用或适合他们的需求时，他们才会屈尊投入在他们的手机上。 此外，如果用户可以从桌面或设备输入数据或查询结果，则获得用户的支持（和反馈）效果会更好，具体取决于他们在特定时刻工作的位置。

Xamarin Forms 适用于这些场景，我们真的很想使用 Shell 和 CollectionView，但它们对我们来说是架子，直到它们可用于生成桌面/笔记本电脑类似的工作......

@dotMorten所以我没有看到异常的原因是我有 WinUI 作为对 nuget 的依赖，所以如果你将 XF 安装到 UWP 头上，那么 WinUI 就会出现并应用它的目标。

这确实使 XF 包本身必须安装到 UWP 头项目中才能工作。 我在上面的示例中测试了仅在 netstandard 项目上安装 XF 的情况，并且能够重新创建您的异常。

我们在这个问题上已经讨论了一点
https://github.com/xamarin/Xamarin.Forms/issues/4126

如果人们只将 XF 安装到共享库而不是 UWP 头项目中，这将是破坏性的。 所以我们需要稍微讨论一下，看看我们想对此做些什么

@pureween好的。 很高兴我们看到了同样的事情。 在您的讨论中需要考虑以下几点：

• 如果我在 WinUI 中的 PR 被合并，它只会影响 VS2017 用户（但是，如果团队同时使用两者并且只会影响某些用户，这可能会变得很奇怪）。
• 您可以在 Init() 期间检测到这一点并抛出一个错误，告诉用户确切地做什么，这样痛苦就没有那么严重了。
• 我在想，XF 有一个目标文件，如果尚未存在，该文件将依赖项添加到引用项目，但可以
  创造一种奇怪的开发体验。
• 一旦 WinUI 与平台分离，所有 UWP 项目将始终使用此依赖项（但到那时 VS2017 可能已经不支持了）。
  
  
  
  • 通过此更改，您将能够支持较低版本的 Win10，从而创造一个可以证明其合理性的附加值。
  
  
  • 没有人会注意到，因为根据你的团队，反正没有人真正使用 UWP 😜 j/k
  
  

另一种可能的方法：检测在初始化期间是否引用了 WinUI，但让应用程序运行。 任何依赖 WinUI 的渲染器都会抛出异常，因此它只会影响这些新功能的用户。 所以故事变成了“如果你想使用 Shell 或 PullToRefresh，你还必须添加对 WinUI 的引用（如果你使用的是 VS2017）”。

@dotMorten感谢您为将 Shell 引入 UWP 所做的一切努力！ 这是非常需要的，应该由核心 Xamarin 团队解决。

这是使用 CV 和 Shell 在 UWP 上运行的 Xaminals 的体验！！！

做得好！

很棒的工作。 一旦它出来，我们将把它包含在我们构建企业级应用程序的框架中

干得好，我会在我的应用程序的未来版本中尝试它；）

是的，Xamarin 做到了！ 我读到一个人说我们搬到了 Uno。 不！！！！ Xamarin 对我们来说很棒，为我们节省了很多时间去学习 swift + java。 让我们对团队有耐心并支持他们

被#6015 关闭

伟大的工作，感谢所有团队<3，我会转的💃

伟大的工作，非常感谢！

好吧，发生了一些奇怪的事情，我升级了我的项目以使用 4.3.0.947036，现在项目在调用 forms.init 时失败
'找不到 Windows 运行时类型 'Microsoft.UI.Xaml.Controls.XamlControlsResources

非常奇怪的是现在在 XamlTypeInfo.g.cs 中发现的代码量，在以前版本的 Xamarin 中我们只有 13 个条目，现在我们有超过 43 个。我在项目上安装了 Win.UI Nuget，但仍然如此没有帮助。 有任何想法吗

@abrantie1z -（虽然偏离主题，我想我会提到）Uno 和 Xamarin Forms 不再是相互排斥的选择 - 请参阅https://platform.uno/xamarin-forms/和https:/ /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx警告：我没有使用过 Uno，所以我不知道这种支持有多强大。 但是任何让更多人对浏览器中的 XF 感兴趣的东西都是一件好事。