Runtime: 将 System.Xaml 移植到 .NET Core

万岁！ 官方认可/承认！ 是的，我意识到这些词并不等同于“承诺”，但这绝对比我迄今为止看到的任何东西都要好。 @terrajobst你是我的英雄。 :心: :心: :心:

@cwensley和@SuperJMN ，在这里的每个人之间进行一些对话会很棒。 理想情况下（从我的角度来看）每个人最终都应该使用新 Xaml 库的一个端口/版本，并且没有不同的 Xaml 版本/方言。 这甚至有可能吗？ 如果没有，我可以接受，但我想看看我们是否可以。 :)

此外，我目前正在“工作休假（来自专横的客户 LOL）”，并且我有 3-4 个月的时间单独用于跨平台 Xaml。 如有必要，我可以在此期间全职工作并提供帮助。 一切为了事业（而且，我是一个把握好时机的机会主义者！）

如果 System.Xaml 开源了，我相信社区可以根据这个项目的需求和设计目标将它移植到 .net core，项目维护者只需要指导社区。 让我们利用 .net 社区的力量。

@Michael-DST，我同意拥有一种 xaml 方言很重要。 但是，它的实现可能完全不同。 对单个实现进行标准化确实取决于社区。

对于Portable.Xaml ，它是 Mono 出色的 System.Xaml（MIT 许可）实现的 PCL 259/136 端口，有许多错误修复。 这个想法是使用相同的 API 支持 MS 的 System.Xaml 所做的一切（包括读/写），但不一定限于此。

作为扩展功能的示例，Portable.Xaml 支持对列表中的项目使用类型转换器，其中 System.Xaml 使用 IList.Add(object)，您必须使用自定义集合来实现它以支持各种类型。

@cwensley我声称我对此一无所知......但是.NET Core 和 PCL 之间有什么区别？ 我以为他们是一样的？ 也就是说，我的理解是，如果您在某个 PCL 配置文件下进行设计，它将延续到 .NET Core ......这是不久前的事情（老实说，我正在等待 .NET Core 到 RTM/W），所以现在是刷新的好时机。 :P

我的理解/印象是 Portable.Xaml 确实是 Mono 的 System.Xaml 的一个端口，而 OmniXaml 是从头开始重写的，它在解析领域具有一些新的热点。 理想情况下（从我自己的角度来看）以某种方式合并两者会很棒，但我什至不确定这是否可行，甚至在两个基础之间是否可取。 在我看来（没有进行探索/分析），它基本上是将一个（Portable.Xaml）的成熟度与另一个（OmniXaml）的新热点相结合。

根据这篇文章，@Michael-DST PCL 259 确实与 .NET Core 兼容。 我已经将\lib\dotnet作为目标包含在 Portable.Xaml 的 nuget 包中，因此它_应该_可以按原样用于 .NET Core，尽管我尚未对其进行测试。

我没有时间研究 OmniXaml，但如果它确实是从头开始重写，那么合并这两个项目可能没有意义，因为我确信事情会完全不同。 如果 Portable.Xaml 大部分是完整的，我也不确定这样的好处。 不过我可能是错的 (;

:) 是的，我正在探索这里的选项，并且还要处理我对真正处于开源世界中的无知。 我确实讨厌让多个代码库做同样的事情的想法。 尤其是在 Xaml 社区规模较小的情况下，让它一开始就支离破碎会很糟糕（这不应该发生在_之后_为了自己的利益而变得过于成功吗？！哈哈）。 无论如何，很高兴听到@SuperJMN 对此的看法。 我知道他似乎对他的新修改非常坚定。 例如，使用MarkupExtensionContext 代替 IServiceProvider进行标记扩展，对于任何想要将现有代码移植到这个新世界的人来说，这将是一个突破性的变化。

澄清一下，所有 PCL 配置文件都与 .NET Core 兼容。 我们现在拥有的合约集和保理是 PCL 配置文件的演变。 这不适用于不能立即与 .NET Core 兼容的“旧式”可移植库（针对 mscorlib 等编译）。

@迈克尔-夏令时

@terrajobst你是我的英雄。 :心: :心: :心:

虽然我非常感谢您的热情，但我想明确表示任何人都可以提出这样的请求。 您不需要我们的任何赞助或确认即可提交问题，要求工作:-) 我只是自己提交以节省一些时间而不是超级跛脚（“随意提交错误”）:-)

LOL @terrajobst没关系，我的热情是半开玩笑半认真的...... MSFT 已经在这个问题上基本保持沉默近一年了，尽管有很多投票和广泛的对话。

所以，想想你做了什么，相当于在一个被单独监禁近一年的人的门下滑了一顿饭。 :stuck_out_tongue:

[编辑：在阅读了那个类比（并看到下面引用）之后，我不得不说这很糟糕，并且可能受到我当时正在阅读的一篇文章的影响——该死的新闻，你为什么要这样影响我？！ 一个更好/相关的人可能会在一年的油烟之后从天使轮中获得急需的现金注入。]

抄送： @Harikm86 ，System.Xaml 的所有者

我喜欢 XAML。 它是一种出色的声明性语言，适用于从 Silverlight（是的，我说过）到 Windows Workflow 再到现在的新通用应用平台的所有内容。 移植到 Core 将使移植其他依赖于 XAML 的技术成为可能。 我们需要这个！

很高兴听到您的支持@rschiefer！ 谢谢您的意见。 请确保您有其他您认识的 Xaml 开发人员加入此线程并在对话/指导方面提供帮助。

我也是 Silverlight 的粉丝，自 2011 年以来一直在追求它的下一个版本（无耻的插件：如果你想让 Visual Studio 团队知道你想看到下一个更智能的 Silverlight 形式，请投票并让他们在这里知道）。

我想花一点时间确保当我们说“Xaml”时，我们应该渴望在 .NET 4.x+（或“System.Xaml”）中找到的 Xaml 系统/功能集。 甚至 Silverlight 5 的 Xaml 也可以，真的。

（当然，也需要添加在 OmniXaml 中发现的新改进。）

只要它不是 UWP 中必须由实习生团队移植的“新”、混账版本，因为从那以后我们都一直在受苦（请参阅我在上面的帖子中提到的投票）。

我什至不敢称其为“Xaml”系统，因为它实际上是 XML，带有一些额外的令牌解析以求好运（它显然需要）。 有趣的事实：UWP 的 Xaml 系统最终在其构建过程中使用 System.Xaml 程序集。 嗯……#讽刺。

理想情况下，一旦此端口到位，UWP Xaml 系统将被完全弃用，并改用此端口。 然后，我们可以将令人尴尬的 Xaml 历史的那一章抛在脑后，让开发人员欢欣鼓舞。

以更新、更好的形式重新获得 Silverlight 也不错。 :) :) :)

@迈克尔-夏令时

所以，想想你做了什么，相当于在一个被单独监禁近一年的人的门下滑了一顿饭。 :stuck_out_tongue:

足够公平：微笑：

@迈克尔-夏令时

到目前为止，我实际上一直避免使用 UWP，因为我知道很多事情已经发生了变化，而且我忘记了 UWP 使用了它自己的 Xaml“版本”。 谢谢你提醒我。

我完全同意，应该移植 System.Xaml，然后我们可以修复 UWP 以使用真正的 Xaml。

我完全同意，应该移植 System.Xaml，然后我们可以修复 UWP 以使用真正的 Xaml。

抱歉@terrajobst ，我现在在@rschiefer 有了一个新英雄。 :smile: :smile: :smile:

谢谢大家的讨论。 这对我来说太酷了（但我很容易被打动！）。

@Michael-DST @rschiefer

@helmsb是的！ 哈哈！

FWIW，谷歌流行的网页材料设计技术（Angular.js），应用程序（Android）等也是开源的。 希望这个论点有助于说服老板和类似老板的实体。

@dsaf你是什么意思？

FWIW 我在今天发布的一篇题为“潮水正在转向 project.json 吗？”的文章中提到了这个问题？ ，看看 Xaml 如何成为从技术和 MSFT 业务/IP 角度描述 .NET 对象的首选机制。

大家好，那 Xamarin 交易怎么样，呵呵！ 有些事情告诉我，这个问题在接下来的几个月里会变得更加繁忙。 ：微笑：

不必要。 我们很有可能看到 UWP 的 Xaml 或 Xamarin 的 Xaml 风格成为一些跨平台库。 这可能意味着 System.Xaml 的移植或纯托管的 Xaml 实现都不会发生。

Xamarin 的 Xaml 系统虽然是封闭的/内部的，但远没有 System.Xaml 成熟。 代码本身相当脆弱（这是他们公认的担忧——实际上使用它是它被关闭/内部的原因之一）。 此外，它与 BindingObject 紧密耦合，如果您想要进行 POCO 序列化等，这是禁止的。

而且如上所述，UWP 的 Xaml 系统很糟糕。 除非有一些你知道我不知道的事情。 :stuck_out_tongue:

您能解释一下“纯托管 Xaml 实现”是什么意思吗？ FWIW，我在这里的期望不完全是 System.Xaml 的直接 1:1 端口，而是一个“新” System.Xaml（Microsoft.Xaml？）库，它从 System.Xaml、Xamarin.Core.Xaml、而且...好吧，我会说UWP的Xaml，但是... :wink:

我听说在内部，人们更喜欢 UWP 的 Xaml，而不是 WPF 等的 Xaml，尽管显然微软的不同团队可能有不同的意见。 毫无疑问，DotNet 的 Xaml 更强大、更灵活，但与任何带有这些描述符的东西一样，可能会带来一些缺点，这就是 UWP 如此缩减的原因。
通过非纯托管，我指的是关于 UWP 的 Xaml 的一件好事，因为它不是 DotNet 独有的。 因此，潜在的未来 Microsoft.Xaml 可能是具有托管外观的跨平台本机实现，因此它可以在 DotNet 之外使用。 （这也将排除它包含在 dotnet/corefx 中，除非这个未来的库被决定作为 CoreFX 的一个组件发布）

好吧，我很困惑。 当您说 .NET 时……您说的是 4.6，对吗？ 据我了解，这是针对 .NET Core Xaml 库的，它本质上是跨平台和 .NET (4.6) 独有的？ 当您说“不是 DotNet 独有的”时，您的意思是“DotNet 是否具有包容性”？ 双重否定。 :stuck_out_tongue: 这显然不是真的，因为你不能在 .NET 4.6 中使用 UWP Xaml（你也不想 :stuck_out_tongue:)。

请告诉我我在这里有什么问题。 此外，这里的一个好的目标是将 Xaml 作为 CoreFX 的一部分提供。 一些讨论已经围绕这个进行了一段时间。 - 果然，如果我没记错@RichiCoder1 ，你有投票权在那个线程中做到这一点......我想知道我以前在哪里看到过你的标签！ ：微笑：

而且我还想说，我也听说过内部倾向于 UWP 的 Xaml，但那是在围绕它的一些社区讨论开始之前在该线程之外（ ala Tim Heuer 的 Twitter 讨论）。 从那时起，针头肯定已经移动了。 至少，它更好！ 哈哈。 有些人错误地认为“Xaml 是为 UI 设计的”，而我们其他人则理解它是如何工作的。 :stuck_out_tongue:

当我说 DotNet 时，我指的是包括核心和框架的 DotNet。 而且我意识到你不能在 UWP 应用程序之外使用 UWP Xaml，我指的是在 C++ UWP 应用程序中使用它的能力。 因此，当我说它不是 DotNet 独有的时，我的意思是即将从 C++（或可能的其他语言）中使用它。 我想拥有 XAML 的团队不认真考虑 UI 之外的用例的原因是因为它不常见，或者在某些情况下，与 Microsoft 或合作伙伴积极诽谤。 不是我个人的意见，我很欣赏它的表现力和力量。

好的@RichiCoder1谢谢你的解释。 我想我现在_几乎_完全关注你了......当你说“框架”时，你的意思是 4.6？

在我看来，我认为内部团队认为在 UI 之外使用它并不常见的部分原因与开发人员的参与度低有关，正如我认为 Tim 的帖子所显示的那样。 我也对此感到内疚，因为直到大约一年前我才真正对参与 MSFT 感到高兴？ 事实上，Tim 的推文是关于我所做的投票，因为自 Windows 8.0 以来我个人/私下向所有人抱怨 Xaml 系统完全不同，不像它应该的那样。 当我听到关于 UWP (Windows 10) Xaml 基本相同的传言——在 3 年没有创新或改进之后——我就站出来了。 事后看来，它应该早得多。

可以肯定地说，这是一个重要的学习课程。 我现在（或者至少感觉像我）现在更多地融入了生态系统，并且感觉我被听到了。 事实上，我在四个多月前所做的一个非常重要的投票在本周早些时候被享有盛誉的 Visual Studio 团队标记为审核中。 说我的世界被震撼是轻描淡写的。 ：微笑：

通过框架，我用它来指代桌面.Net。 这似乎是区分核心和完整框架的流行方式。

我同意。 微软最近所有举措的好处之一是它几乎迫使开发人员更好地参与:)。

我自己对此非常兴奋！ 现在只是看看那会怎么样。 这可能意味着使用他们的共享项目将 Xamarin 工具放在一流的 UWP 应用程序之外，或者甚至可能意味着更高级别的东西。 只有时间（我猜，//构建）会告诉我们。

好的酷...谢谢你的信息。 :+1:

至于 //build... 确实如此。 :) 就个人而言，我希望看到一个完全基于 UWP 的新模型（松散地？），并利用新的 Xamarin 优势将其移动到 iOS/Droid。 更强大的 Xaml 模型也不会受到伤害。 毕竟，我想我们应该在 4 月 28 日之后保持安静。 :stuck_out_tongue:

我希望你们能做到！ :)

猜猜 UWP 的人会更容易采用不引入 .NET 代码的 XAML 实现（即使该代码是 .NET Core 的东西）。

就像一个独立的黑匣子（或仅取决于 UWP，但我们不希望那样，因为 UWP [尚未] 是非跨平台的，如果它是一个仍然会错过可以在 .NET/ 中运行的托管版本Silverlight [无法将您的应用程序锁定到仅 Win10 目标]）。

但我认为这或多或少是乌托邦，除非你为 XAML 的不同应用程序（用于 UWP UI、工作流、WPF/.NET、Silverlight 等）使用抽象层和可插入/驱动程序。 就像 DirectX 通过 HAL（硬件抽象层）看起来是一台机器一样，这也为 HEL（硬件仿真层 - 请参阅 http://www.developer.com/net/asp/article.php/968461/What 上的提及）打开了可能性-is-DirectX.htm)。 当然如果你不小心它也可能在性能方面打开地狱之门，但由于 DirectX 可以拉它，我想这样的架构还不错

+1 用于将 System.Xaml 移植到 .NET Core。
我希望将来能在所有平台上使用一种统一的 XAML 方言（.NET Xaml、UWP Xaml、Xamarin Xaml）。
它认为 System.Xaml 的 .NET Core 版本是实现这一目标的必要条件。

+1

为了避免大量通知警报，我们现在有一种新方法可以在 GitHub 上为个人评论 +1，以显示我们对当前主题的兴趣/反应：

哈哈@jasonwilliams200OK我不介意来自社区成员的大规模通知警报，他们表达了他们对强大的跨平台 System.Xaml 解决方案的基本兴趣。 :angel: 然而，也许其他话题我会分享你的痛苦/烦恼/沮丧。 ：眨眼：

无论如何，有效（和有价值）的观点。 我已经添加了我的 :+1: 原因。

@jasonwilliams200OK

感谢您大声疾呼！

FWIW，我刚刚邀请 Xamarin.Forms 团队在这里加入对话：
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

或者，如果有的话，让_这里_的每个人都知道_那里_的对话。 ：微笑：

在这篇文章的评论中得到了一些很好的讨论：
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

基本上 JSON 与 Xaml 用于 Visual Studio 似乎正在进行的新项目系统（万岁！）。 随时加入。:) 很高兴看到这又是另一个样子。

@Mike-EEE，也看看这个路线图： https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md。 新的 Roslyn 动力项目系统将是 .. 珍贵的。

哇...疯了，我现在才听到这个。 这一定是 Scott Hunter 在上述博客文章中提到的关于未来文章中即将发布的更多信息的内容。 很高兴看到。 罗斯林权力增长。 虽然，看到 Xaml 序列化项目定义的一些问题，我会感觉更舒服。 ：眨眼：

请参阅该 repo 的自述文件： https ://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system（以及 VS MSDN 博客的链接)，我们似乎可以使用 MEF 替换各种组件，这样就可以插入一个额外的序列化程序来解析用 XAML 编写的项目定义。 就个人而言，在描述项目属性和依赖项等问题时，我已经成长为更喜欢 JSON 而不是 XAML/XML，因为 JSON 噪音较小（嗯，YAML 比 JSON 噪音小，并且 lang 标准支持与 std-JSON 不同的注释，但在 dotnet 世界中，YAML 和其他具有缩进感知语法的语言尚未获得关注）

就个人而言，我已经成长为更喜欢 JSON 而不是 XAML/XML

安全！ 删除这个人！！！ 咳咳，我的意思是……：）

我完全赞成两全其美。 @SuperJMN和@Grokys可能会对此进行更多说明，但我相信 OmniXaml 正在努力使其不那么冗长和健谈。

我的 JSON 问题本身不是 JSON 本身，而是它的设计方法也是 .NET 配置的基础（我认为这是它的灵感），也就是说，对象的架构是“又一个工件”开发人员必须管理/维护并且_不是_类定义。 也就是说，在 Xaml 编程中（如您所知！），类定义_is_ 文档架构。 结果，这为文档的开发带来了非常自然的感觉，并且还有助于/协助工具。

更不用说开发人员的理智了。 :smile: 没有什么比不得不寻找一些晦涩的模式文档并弄清楚如何安装它并让最简单的智能感知工作更让我愤怒的了。

我对 JSON 的另一个问题再次不是 JSON 特定的，而是更多的网络思维方式，那就是命名约定。 .NET 配置也受此影响。 也就是说，您可能正在定义一个 POCO，例如：

public class MyPoco {
    public string Property {get; set;}
}

它的 JSON（或 app.config）看起来像（如果我错了，你可以教我这个！）：

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

在这里，Xaml 再次在类定义和它的序列化对应物之间保持一致，这就是我更喜欢它的原因。

我不得不说 .NET 配置是最差的，因为它的设计为每个配置实体产生了四个工件：

1. web/app.config 中的元素
2. 您必须以某种方式神奇地链接到 web/app.config 的 .xsd 文件（我从来没有让它工作！）
3. ConfigurationElement和/或ConfigurationSection元素从 app/web.config 获取值（并将不一致的 camelCase 映射到 PascalCase ——哦，太疯狂了！）
4. 最终从配置元素接入的 POCO。 （哇！）

我还没有充分研究 JSON 的项目设计，无法知道是否存在正在使用 .JSON 文档进行序列化的 POCO 对象，或者上面概述的无关映射是否也在发生。 如果你知道这个问题的答案，我很想听听。

在任何情况下，Xaml 都改进了这种设计，只需要两个工件：

1. 类文件 (.cs)
2. 数据文件 (.xaml)

最后，感谢自述文件的链接！ 我再次成为不做文件要求的事情的“那个人”。 ：笑：

如果有一个 POCO 对象正在使用 .JSON 文档进行序列化，或者上面概述的无关映射也正在发生。 如果你知道这个问题的答案，我很想听听。

我认为，如果您考虑 [DataContract] 和 [DataMember] 属性，那么 .NET 框架（在 BCL 级别）正在帮助 JSON 和其他数据序列化器。 但是，编译器没有原生/低级 JavaScript 对象文字 <-> C# POCO 转换支持，如 JSON 到 JavaScript（和许多其他语言）或 CSON 到 CoffeeScript。 然而，与具有所有 XPATH XQUERY XSLT 关系的 XML 不同，JSON 具有验证数据的模式概念，并且 JSON.net 像冠军一样支持它。

对于 C#6 及更高版本，请查看这些问题/建议https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ dictionary ，尤其是https://github.com/dotnet/roslyn/issues/6949并点击其中的链接。 有了新的C#6 字典初始化语法和这些提议，C# 似乎在语义上变得对 JSON 更友好。

我不得不说.NET 配置是最差的

同意，您也可以享受 ASP.NET 团队引入的“配置”和“IOption”模式作为即插即用包： https : //github.com/aspnet/Configuration，https ://docs.asp.net/

JSON 具有验证数据的模式概念，JSON.net 像冠军一样支持它。

听起来像是作为模式的类定义。 :) :) :)

似乎 C# 在语义上变得对 JSON 更友好。

哈哈，可以肯定的是，_any_ 对象已经是 JSON 友好的。 JSON 非常适合做它打算做的事情：以简洁、人类可读的方式注释对象定义。 毫无疑问，JSON.net 在实现这一目标方面做得很好。 当你开始描述_应用程序_时，我们开始进入这个对话开始的领域，嗯，因为没有更好的词而被卷入其中。 ：微笑：

最后，这里有两种情况（至少对我而言）：描述要在服务边界之间传输的对象（轻量级）和描述创建这些对象的应用程序（重要）。 我个人喜欢以各种可能的方式争取一致性，并尽量减少上下文切换。 只要我们保持我们的选项（ IOptions ? :laughing:) 开放并允许开发人员选择对他们最有意义的格式（并允许他们使用让他们感觉最高效的工具！ ) 那么我们都在这里获胜。 :+1:

与经典的 .NET WPF XAML 相比，UWP XAML 的功能更少。 我最怀念的功能之一是 TypeConverters。

我尝试按照此处的建议创建自己的 TypeConverter https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx （这篇文章适用于 WPF TypeConverters）

在 UWP 中，我得到了这个“在 XML 命名空间中使用：App2TypeConverters的未知类型‘汽车’”

        <ListBox>
            <local:car></local:car>
        </ListBox>

在 UWP 中添加自定义 TypeConverter 真的不可能吗？ 或者有解决方法吗？ 我在某处读到 XamlCompiler 正在使用内部 IServiceProvider 来注册 TypeConverter。 也许它可以以某种方式注册？
我也有兴趣了解有关 XAML 编译的背景的更多信息。 XAML 是否仍会生成为 BAML？ 我们能以某种方式挂钩 XAML 编译吗？
所以，请打开 System.Xaml。

Sooooooo... 这是否意味着 System.Xaml 终于要加入聚会了？？？ :smile: :smile: :smile:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

我要插嘴说：
a) 我真的很喜欢在 .Net Core 上运行的 XAML 和
b)如果发生这种情况，使用 UWP 风格是最有意义的，因为它已经被移植到其他架构（例如 Raspberry Pi 上的 IoT 推送）。

不过，如果可能的话，获得 WPF XAML 将是惊人的。

与 .NET 核心基本上是从头开始重建一样，基于过去十年的学习，我认为 XAML 也应该这样做。 WPF/Silverlight/WinRt-XAML 的演变已经彻底崩溃。 前进一步，后退两步（一个侧身）。 XAML、Expression Blend 等的承诺从未实现。

前几天，我听到 Scott Hunter 为 Dotnet Core 中没有跨平台 UI 辩护，他说“好吧，它们从来都不是很好。在 Windows 上，用户期望一个看起来像 Windows 的按钮，在 Mac 上是一个 Mac 按钮”。 好吧，我很抱歉 - 过去 5 年他在哪里？？？ 网络现在完全主导了 UI 设计，在网络上没有“标准按钮”之类的东西 - 但你猜怎么着？ 用户已经设法解决了。 该论点完全反对所有证据。 这些 Web UI 现在主导着地球上的商业。 但显然这对 Dotnet Core 来说还不够好。 为什么我们不能在不迎合任何[想象中的]“标准平台外观和感觉”愿望的情况下拥有一个跨平台 XAML？

我认为主要的技术障碍是如何将“XAML”（或任何下一代 UI 平台）与跨平台 3D API 接口 - 因为我们显然不能依赖 MacOS 等上的 Direct3D/Direct2D。但我认为这个问题已经被 Unity 等人解决了，他们设法实现了这个目标。

微软在开源 XAML 系列技术的问题上一直拖拖拉拉，人们不得不怀疑其中是否隐藏着比特币的秘密缓存或 microsoft.com 的私钥。

继续使用它 MSFT：开源 WPF/Silverlight/WinRT-XAML，让 UX 的下一个黄金时代开始。

听到你对 Scott Hunter 的评价真是太棒了，@JackUkleja。 你有源/链接吗？ 如果你说的是真的，那么除了你说的之外，这在几个方面显示了（令人惊讶的）无知：

1. 这正是 Xamarin.Forms 试图解决的问题。
2. 特定于平台（或模仿）的用户体验/交互/风格是一个可以而且应该由主题解决的问题。 这是 WPF 非常擅长的（尽管在您看来它可以而且应该改进）。
3. 最糟糕的是，这对成功创建 WPF（可以说是有史以来最伟大的演示框架）的人才库没有任何信心。 你是说他们不能再解决这个问题了？ 或者至少发挥 WPF 以跨平台方式取得如此成功的相同魔力？

好的用户体验就是好的用户体验。 正如您所指出的，网络清楚地证明了这一点。 本地应用程序用户肯定会适应其本地界面的某种外观和感觉，但这应该可以从主题中解决。

想象一下，能够在 Droid“皮肤”（完整的行为）中查看 iOS 设备上的应用程序，反之亦然。 这在 WPF 中是可能的，并且正是应该继续推进的那种想法。 也就是说，外观/感觉/体验不应该妨碍开发和设计应用程序。 你应该能够应用一个主题，然后哇，“它就可以了。” 不幸的是，这曾经/现在是 Xamarin.Forms 的一个批评者，因为虽然它确实考虑了不同的平台，但在确保每个目标平台上的一切都按预期工作时存在很多摩擦。

@Mike-EEE 我很确定 Scott Hunter 在这个 dotnet Rocks 插曲中说过这样的话： https ://www.dotnetrocks.com/?show=1291

回覆：

“成功创建 WPF 的人才库，可以说是有史以来最伟大的演示框架”

...我的理解是，大量的原始架构师，其中一些参与 WPF 的人离开了 MSFT，去了谷歌并参与了 Angular。 WPF 的许多想法都出现在 Angular 和相关框架（例如模板）中。 但无论你以何种方式分割这些 Web 框架，我认为你总会在后台闻到 HTML/CSS 的味道。 并非所有 UI 都基于文档/语义有意义，这就是 HTML 的本质，这就是为什么我认为世界仍然可以使用“XAML 核心”的原因。

[杰克...不要认为关于 google 和 WPF 架构师的数据是正确的]

@rrelyea这是我的理解，但我可能弄错了。 我可以发誓我读到了 WPF 团队中的一些人在 Angular 上工作。... Ian Ellison-Taylor等等？ （虽然看起来他现在回到 MSFT ......）

后台有 HTML/CSS 的味道

对统一的 HTML CSS 标准或这方面的任何类型的标准（C、C++、JavaScript）的一致性和趋同程度越高，这个世界就会越好。 相反，XAML 以其独特的功能，可以将自己呈现为 HTML+CSS 堆栈等的超集框架，或者简单地作为 ASPNET 的 Razor 的替代前端引擎： https ://github.com/aspnet/Razor/issues/78：电灯泡：

@jasonwilliams200OK FWIW/FYI 在JSIL中已经有一个 HTML/CSS“标准”端口 .NET 。 它的所有输出都 100% 兼容 HTML5，并且可以在任何现代浏览器中运行。 当然，这是我们应该追求的那种想法（并且应该是自 Silverlight 于 2011 年消亡以来的想法，但我离题了）。

也就是说，（我希望你的观点）理想/要求是 .NET 开发人员应该只需要处理 .NET/C#/F#/VB.NET 而不必接触 CSS/HTML/JS，就像如何Xamarin .NET 开发人员不必触及 iOS/Droid 的基础（无论它们是什么。:wink: ）。

@Mike-EEE，在超集语言（TypeScript 到 JavaScript 或 Less 到 CSS）中，我们可以在同一个文件中使用超集中的子语言代码，但不能反过来。 所以超集的概念有点超出了phonegap、cordova等的功能。 :)

哈哈是的@jasonwilliams200OK我只是想确保我们最终不会为我们的方法/策略制定一个特殊案例，即让.NET 回到浏览器中。 触摸 CSS/JS 应该与触摸二进制文件一样轻视。 :stuck_out_tongue:

例如，还有另一个项目Fayde使用 Xaml (yay)，但也依赖于 TypeScript (boo)。 这是不这样做的方式，因为您最终会得到两个不兼容的代码库——一个用于客户端代码的 TypeScript/JS，一个用于其他所有代码的 .NET——这在时间和资源上都非常昂贵。

ASPNET 的 Razor 的替代前端引擎

Razor 在我看来只是一个模板引擎。 实际上，在您提到的那个链接上，它说“......您可以从一长串前端模板引擎中进行选择以进行编码。”

我什至听到 MS 对 HTML 页面中的 Razor 等特殊的类似 C# 的语法发表了一些评论，支持使用自定义标签的框架

顺便说一句，还有 Bridge.net (http://bridge.net) 和其他 C# 到 Javascript 编译器，可以与 Fayde 等 XAML 解决方案结合使用

在 HTML5/JS/等上重新 XAML。 有一个有趣的项目Granular正在重新实现 WPF。 它使用 Saltarelle 编译为 JS。 一个活生生的例子是here 。

那个 Granular 非常棒，@ethanhs。 那是我不知道的。 由于它采用了相同的方法CSHTML5 、 JSIL 、 Bridge.net （ @birbilis提到），它遇到了同样的问题，即无法通过使用 PCL 在服务器和客户端之间共享代码，这确实是唯一可行的这些天这样做的方法。

确实，尽管该项目看起来很棒，但它几乎概括了自 Silverlight 消亡以来 .NET 开发人员不得不忍受的地狱景象。 它和大约十几个其他人在使 .NET 在浏览器中工作方面做了“一些”工作，但并不完全是具有 Silverlight 经验的人所期望的全部体验。

目前还没有一个单一的、孤立的统一解决方案导致开发人员忘记 Silverlight。 不过，我们越来越近了。 我希望，至少。 WebAssembly 看起来很有希望，但我已经有一段时间没有看到/听到任何重大进展了。 JSIL 驱动的端口/计划似乎有所放缓，自去年 10 月以来一直没有进行检查。

希望我们能在不久的将来在这里取得突破。 我很想在明年的 //build 上看到这样的声明。 :心: :+1:

这将是过去几年发生在 XAML 上的最好的事情之一。
在这里投票！

酷@bbougot。 还有另一票，_finally_ 得到了一些关注，经过近 15 个月的存在，这还不包括近 3 年没有认识到糟糕的 Xaml 系统开始（但我离题了！）：
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

（说真的，15 个月的时间才能对最明显的问题进行投票？UWP 团队在那边做什么？Visual Studio 或 .NET 团队什么时候会接管并纠正这艘船？？？它会做什么。 ..哎呀，没错，我跑题了……）

另外，别忘了给这个帖子点个赞。 它目前在 60 处做得很好，特别是考虑到这个问题是在我们拥有诸如 GitHub Reactions 之类的花哨设施之前就开始的。 ：微笑：

Xaml 是唯一有可能统一整个客户端生态系统的工具！
请摆脱DirectX，请拥抱OpenGL，！
UWP 可以在 PC、手机、网站上运行！
万岁 Xaml！

所以，这里有@terrajobst 、 @harikmenon和@karelz的民事问题（我看到你最近添加了一个标签，所以恭喜你，我要把你拉进去！）。 出于简单的好奇，我决定冒险一点，并在这个 repo 上查看高级（或者可能不是）GitHub 过滤。 认为有很多选票，而不是针对不同的问题。

这是我正在使用的 URL：
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

似乎这个问题目前有 82 个赞成票，如果我是正确的，列表中下一个最接近的项目是 17。这使得这个问题在这个 repo 中成为请求/投票最多的问题，对吗？

如果是这样，我很好奇这是否对您的优先事项和/或计划有任何影响。 显然，现在这似乎是一个_非常_受欢迎的问题/项目（再次，如果我理解正确的话），所以我认为可能会很高兴听到关于可能开始对话以取得进展的更新或签到这个问题有可能。

很高兴在这里获得任何观点/背景，和/或如果我对客户需求有完全误解。 它发生了。 😄

我们的 .NET Core 工程师非常关注 .NET Standard 2.0（也有很高的客户需求）——请在此处和此处查看详细信息。 在将 .NET Core 升级到最新标准后，我们​​将查看不在该列表中的其他库。

感谢您指出投票查询！

感谢您的回复@karelz！ 非常感激。 👍

👼 👼 👼 我会把这个留在这里，以防有人喜欢/转发。 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

从 .net 版本 3 开始，我一直在使用 xaml，我感觉到 Silverlight 的规模缩小，甚至它的死亡。 我是一个喜欢为了改进而改变的人，让事情变得更好、更有用。 但现在有了 UWP，我发现退步而不是前进。 不要介意所有感觉很棒的新功能，但是缺少像桌面应用程序那样的完整 xaml 支持。 我一直在尝试在 UWP 中制作一个新的应用程序，但我学到了我所学到的一切都再次改变的艰难方式，我在网上找不到太多支持，就像 xaml 库已经移动到的地方一样。 例如，框架下的装饰器不再存在， x:static 属性不起作用，您必须搜索几个小时才能找到示例或做什么。 没有显示从旧 xaml 到新 UWP 的链接...

@giworking很明显，MS 应该注意客户端开发！ 正如 Satya Nadella 所说，azule 是 MS 的核心和未来，推动 azule 最强大的能量是整个 .net 生态系统。 与java相比，客户端几乎是说服程序员和企业拥抱微软云的唯一武器（在中国，.net真的处于灾难状态，人们谈论java并反应，“什么是f k s t xamarin？”。 ....）。 所以，作为一个中国程序员，当我看到xamarin、uwp、typescript和cshtml5时，我知道可以将整个客户端统一到xaml+C#模式，但是为什么我们的MS朋友没有看到机会得到用if支持中国市场份额？

哇，这个问题现在已经超过 100 个赞了！ 非常感谢所有表示支持的人。 如果有人感兴趣，@ terrajobst有一篇非常（非常！ ）很棒的文章，其中包括他在评论中的巨大商标开发人员参与：
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

（说真的，每个发布基于公司的博客文章的 MSFT 员工都应该遵循 Landwerth 先生的领导，了解如何发布和跟进随后出现的不可避免的、无数的和无数的评论。他真的是这一切的佼佼者，看起来就像太多的 MSFT 作者一样，只是让他们的帖子变干，然后把问题搁置一旁，这当然是对待你的听众的一种糟糕的方式！）

无论如何，如果您还没有阅读，绝对值得一读，尤其是评论。 这让我想到了我现在发布的原因，因为_我很高兴看到评论中提到了这个问题以及将 System.Xaml 带入 .NET 标准/跨平台时代的热情/愿望_。 👍

154 票赞成……还在计数。 😎 下一个最高的问题是 25 ，供参考。 #squeakywheel

这需要完成。 加油！

我们有一个针对 WPF 的@ReactWindows应用程序，我们希望在该应用程序上使用 .NET Native 来显着改善我们数以万计的 Windows 7 用户的首次下载/安装体验。 我们还计划将 React Native 引入 Linux，并可能重用@ReactWindows共享代码，但目标是 Xamarin.Forms。

在 NETCore vNext 中提供 System.Xaml（以及 WindowsBase、PresentationCore 和 Xamarin.Forms 的其他类型/方法/程序集依赖项）对于此策略至关重要。 我们可以通过重新创作和重新定位现有程序集来解决这个缺陷，或者通过在 Mono 的 System.Xaml 中填充缺失的类型/方法并为 .NET Core 构建它，但我们更希望 Microsoft 加强并提供平台所必需的.. /cc @rozele @pre10der89

@matthargett祝你好运。 当我正在考虑将工作流引入 .net 核心时，我将这个问题打死了。 甚至还联系了 xaml 团队。 他们甚至对打开 System.Xaml 一点兴趣都没有。 我不明白为什么——那里肯定没有什么值得保护的。

可能会在4月底2.0发布后考虑。

伙计们，再一次，我们不需要 System.XAML 来将 WF 移植到netstandard1.x ... @dmetzgar已经有一个很好的工作，其中 WF 的核心工作。 主要缺失的部分是交易，我相信它最终会在netstandard2.x回来。

@dmetzgar port 的主要指导方针是不要将任何类型的设计语言绑定到核心并具有基本原语，以便人们可以随心所欲地序列化工作流程，然后在其之上创建设计师。

当然，这种方法将导致与当前基于 XAML 的工作流的非向后兼容性，但相信我，将任何东西移至 .Net Core是一个重大的突破性变化，因此人们需要了解这一点。

XAML 设计人员可以利用 OminiSharp，但同样，设计/序列化是 WF 核心之外的一部分。 它必须像 .Net Core 的其他一切一样纤薄。

我会说这个问题很明确，人们想将 WF 迁移到 .Net Core，我只是认为向 System.XAML 团队抱怨 OSS 它只是没有效率。 XAML 团队还有其他优先事项，它是 Windows/UWP/Xamarin 业务的核心，所以不要指望它这么快就获得 OSSed。 取而代之的是，我会要求@dmetzgar正式公开 .Net 基金会下的 WF 存储库，并指导社区启动并运行它，而不设置任何时间表或承诺完成netstandard2.x发布。 这将是一项由他的团队推动的持续工作，并且主要由显然想要帮助并成功的社区提供帮助。

看看奥尔良项目的发展速度有多快……这是微软研究院去年获得 OSS 的，它是 .Net Foundation 上最大和最活跃的存储库之一，它主要由社区努力推动（它仍然有一个MSFT 团队全职工作）。

无论如何，恕我直言，我认为我们需要停止骂人并开始做点什么。 很明显， @dmetzgar团队没有足够的带宽来解决这个问题，因为他们主要关心的是支持 WF 的主要用户，这些用户基本上是 Sharepoint 大型部署，没有任何计划使用 .net 核心。 所以它必须是一个社区驱动的（由@dmetzgar的团队监督）的努力。

伙计们，再一次，我们不需要 System.XAML 来将 WF 移植到 netstandard1.x...

@galvesribeiro这可能是真的，但这个问题是将 System.Xaml 移植到 .NET Core，其中它是迄今为止 .NET 团队征求反馈的存储库中请求最多的功能。 如果你不听你的反馈，那为什么要征求它呢？ 无论如何，WF 只是 System.Xaml 端口可以满足的场景之一。 如您所知（或应该！）System.Xaml 的功能远不止这些。

XAML 团队还有其他优先事项，它是 Windows/UWP/Xamarin 业务的核心，所以不要指望它这么快就获得 OSSed。

是的，这就是这里的问题，也是我们要求改变的。 :) 另外，我什至不确定这些天是否还有“Xaml 团队”，是吗？！ 确实感觉这项技术已被关闭，我们开始对其进行处理。

无论如何，恕我直言，我认为我们需要停止骂人并开始做点什么。

100% 同意。 FWIW， @SuperJMN刚刚发布了OmniXamlv2.0 ，因此可以利用一些社区的努力，而 MSFT 优先考虑他们围绕这个问题的精力和努力（顺便说一下，现在已经持续了大约 11 个月 - 并且还在继续）。

说到这一点，这里有一个很好的线程（也就是说，MSFT 在这方面不活跃），引用@terrajobst ：

需要明确的是，我并不是说 System.Xaml 不能或不应该是跨平台的。 我要说的是 System.Xaml 在 WPF 和 WF 之外不是很有用，而 NuGet 是该声明的合理代理指标。 当然，System.Xaml 可以在 UI 领域之外变得有意义，但这是次要的步骤。 我宁愿现在就使用我们的资源来使基础部分运作良好和完整。 此外，通过融合基础，移植更高级别的组件（例如 System.Xaml）也变得更加容易。

所以这不是一个非此即彼的陈述。 这是执行顺序的声明。

撇开关于 System.Xaml 在 WPF/WF 之外没有用处的非常不正确的说法不谈，这对我来说都是项目经理的声音，无意解决这个问题。 我的目的不是对这一声明提出批评，因为我完全支持 Immo 和他在这里所做的出色工作。 但是，我已经足够多地允许这种语言让我暂停并让我对这个问题采取观望（或者更确切地说“当我看到它时相信它”LOL！）的立场。

同时，我支持当前在 .NET Standard 2.0 中所做的努力，并期待它会产生什么结果。 也许它可能比预期的要好。 至少，听起来我们将能够为在 Windows 平台上运行的 .NET Core 项目回收 System.Xaml，这对我来说是一个足够好的开始。 👍

@Mike-EEE 首先我很抱歉......我虽然在回复这个https://github.com/dotnet/corefx/issues/2394 oO 这两个问题关联太多次，我感到困惑。

其次，我并不是说 XAML 只对 UI 有用。 我在 TFS 构建、WF 本身以及最近的 UI 上使用了这么多年。 有很多 DSL，例如 Azure ML，以及其他可以利用 XAML 的 DSL。

我的意思是我没有看到 XAML 这么快就移植到 .Net Core。 正如 Immo 所说，他们需要首先在当前平台上做对。 .Net Core 甚至还没有任何本机图像处理库。

有多种 XAML 实现，从功能齐全的 WPF 到弱 WPF，并且在 UWP 中缺少许多功能。 在这种东西得到OSS之前，它必须统一和稳定。 我不代表参与其中的团队发言。 我只是认为如果我必须优先考虑我的资源，我不会比他们做差异。

关于 WF，再次抱歉，但我之前的评论主要针对那些希望这个问题是 WF 移植到核心的原因没有那么快发生的人，这是不正确的。

这两个问题关联了太多次，以至于我感到困惑。

哈哈@galvesribeiro我不能告诉你（或者不敢承认）这也咬了我多少次。 不用担心。 无论如何，我都非常感谢您的意见！

FWIW，看起来@cwensley也继续在 @ Portable.Xaml上做得很好，最近他对 System.Xaml 的基于单声道的改编进行了性能改进，使其比原始版本更快。 似乎这可能是一个很好的起点，因为它可能最接近于所有风格/选项的原始 System.Xaml 体验。 只是我早上的咖啡因引起的两美分。

请将 System.Xaml 移植到 .NetCore

FWIW，这个问题有超过 200 票，现在是 202。下一个最高的问题是 dotnet/corefx#13526，在 47。嗯，是 47 ......在我投票之后现在是 48。 :)（去表达一些爱，这是个好主意。）#squeakywheel

感谢提醒@Mike-EEE ;-)。 设定期望：我们还没有准备好开始深入研究它——我个人希望到三月我们应该能够对我们的下一个官方步骤发表更多评论，即使它再次是“我们还没有计划” （免责声明：我试图传达我最好的个人猜测，请不要将其视为官方团队承诺！）。

当我们上次讨论这个问题时，突然出现的关键问题是确定 200 多张选票中的哪一张是真正仅关于 System.Xaml 与 WPF 的。 假设许多人不区分这两者。 任何建议如何最好地去做？ （例如，创建 2 个特定问题并要求人们投票支持 WPF 与“纯 Xaml，而不是 WPF”）

此外，获得 System.Xaml 方案的摘要列表以及一些优先级估计也会有所帮助（它们现在分散在长时间的讨论中）。 @Mike-EEE 你能帮我们整理一下吗？ （因为您似乎对该领域有浓厚的兴趣和深厚的知识）

毫无疑问， System.Xaml是人们想要的@karelz。 如果有人在这里考虑 WPF，恕我直言，这不是正确的地方。 还有许多其他利用 XAML 的框架，如 WF、TFS Build 等，它们仍在使用 System.Xaml，这将给我们很大的帮助。

@karelz非常感谢您在这里的回复。 感谢您抽出宝贵时间这样做。 正如@galvesribeiro 所提到的，System.Xaml 不仅仅是 UI，不幸的是，这似乎是许多 MSFT 错过的关键理解。 它是一个强大的序列化范例，使其超越任何其他序列化解决方案，尤其是在描述应用程序时，这是它最擅长的（毕竟，它的名字中的“A”）。 不幸的是，“应用程序”已与“用户界面”混为一谈，因此出现了摩擦。

忽略这方面是 UWP 的一个关键失败，也是没有人真正喜欢使用它的部分原因。 相反，Xamarin 似乎已经从其 Xaml 的风格中理解了这一关键方面，但它是内部的，而不是作为一流的、权威的产品应该是公开的（这几乎就是这个问题在此之后的内容）。

TBH， @cwensley在Portable.Xaml中的 System.Xaml 端口目前似乎是领先者。 他不仅移植了 Mono 的 System.Xaml（保持其整体熟悉的 API），而且添加了新功能，实际上将其性能提高到比 System.Xaml 更好。

在我看来，这个问题可以像与@cwensley一起工作一样简单，以使他所拥有的权威跨平台 Xaml 库能够继续使用。

除此之外，它变得棘手并且可能会增加您对这个问题的（可以理解的）复杂视图。 由于 System.Xaml 确实提供了一种表达力强且功能强大的语言来描述应用程序（同样，不仅仅是用户界面），它还在 Visual Studio（当然还有 Blend）中提供了一些很棒的工具支持。 因此，理想情况下，继续同样出色的体验并以某种方式以跨平台方式保持 Xaml 的设计器体验将是很棒的，但就个人而言，这是我们在这里讨论的令人敬畏的蛋糕上的一颗樱桃。 :)

此外，在这里重申一下，Xaml 的承诺（和交付）也是对设计人员和开发人员之间开发工作流程的改进。 我喜欢认为我们最终可以更进一步，改进开发和_devops_之间的过程。 也就是说，我希望看到 devops 在设计精美的应用程序配置编辑器（由 Xaml 提供支持）中工作以管理和维护已部署的应用程序的世界。

_这里的整个想法是降低应用程序开发从编码到部署的总体成本。 与漂亮的编辑和设计师一起工作（从资源的角度来看）比必须找到并雇用必须掌握代码（和/或脚本）才能使魔术发生的人更便宜。_

我与你分享这个作为一个愿景的观点，只是为了让你知道。 但是，我不确定您对听到这个有多大兴趣。 😉 所以，如果这只是一个“关闭这个问题并让你离开需要什么？” 我建议探索与温斯利先生合作的可能性，看看我们是否可以利用他迄今为止的出色工作（或者他是否愿意这样做）。 如果有一种方法可以解决这个问题，使其成为 .NET Core Wave 2 发布的权威跨平台 Xaml 包（大约 5 月左右？），那就更好了。 :)

谢谢你的信息，我肯定很感兴趣。 我也觉得我之前的问题没有按我的意愿提出，所以让我试着指出几点：

是的，我绝对对细节感兴趣。 我认为没有人在 MSFT 方面对 Xaml != WPF 提出异议。 我绝对没有尝试这样做。 我只知道我不完全理解的东西，我正在努力填补空白——即完全理解“纯 Xaml”场景的动机和需求。
（顺便说一句：我不太了解您的 devops 场景以及 Xaml 是如何成为唯一/最好的帮助的？或者它是如何在场景中实际使用的？）

我不是来试图解决这个问题的。 请！ 我什至没有想到这一点。 我在这里帮助社区总结问题，以便可以与合适的人讨论（在这种情况下考虑董事）。 是的，部分原因意味着我（和/或其他几个 MSFT）必须完全理解要代表它更高层的要求 - 因此是我的问题。

我承认，我是一个在看到这个问题之前没有区分 Xaml 和 WPF 的人的一个很好的例子。 从与 .NET 团队中的其他人的随机聊天中，许多人都知道 Xaml ！= WPF，但他们没有看到这里提出的纯 Xaml 的“巨大价值”——因此我对上述场景提出了问题。 这些场景将帮助我/我们更好地理解动机并更好地讲述/销售故事。 （我希望当没有明确的故事时，没有人会急于资助它，这并不奇怪 :) - 故事是资助的先决条件）
所以让我们想出电梯间距来推动它前进。

关于@cwensley的工作——很高兴听到可能有一些不那么昂贵的解决方案。 但同样，在我们跳入解决方案之前，首先了解背景和原因确实会有所帮助。 我希望这是有道理的。 （我并不是要轻视或任何其他事情 - 只是重复说，当理解和同意 WHY 时，更容易推进事情）

@galvesribeiro如果有人在这里考虑WPF，恕我直言，这不是正确的地方

我不相信所有 200 多名投票的人都真正了解 Xaml != WPF 到这些细节。 另外我想至少有几个人看一下 - 是的，让我们先获取 Xaml，然后请求 WPF 会更容易。 所以他们一直想到的场景是 WPF，而“纯 Xaml”只是迈向它的第一步。
也许我错了（尽管我至少不是 .NET 团队中唯一有这些疑问的人）......
另一个角度可能是将“纯 Xaml”分解为场景列表（WPF、上面的 devops，也许还有更多？），然后让人们投票给他们——其中哪一个对在这里投票的人真正重要？ 他们真正想要的是什么？
（这不是延迟策略，也不是任何邪恶的东西，我试图理解这里的“客户”。我希望这是有道理的——如果你有更好的建议如何获取这些数据，请说出来，我愿意接受其他方法)

编辑：像往常一样，如果您认为我没有以正确的方式解决问题，请这样说。 我正在尽我所能在这里提供帮助 - 带着最好的意图。 我不会有无所不知的错觉，或者认为我比其他人更聪明。

@karelz有一堆 UI 框架正在重新发明轮子并编写自己的标记语言，只是因为 XAML 不是跨平台的，即使他们根本不喜欢 WPF。 阿瓦洛尼亚是顶级之一。 当他们可以利用本机 XAML 时，他们会使用 Omnisharp。

Workflow Foundation 是 XAML 的大用户/客户， Port WF to .Net Core线程上的人们总是询问它。

所以是的，我同意你的观点，我们应该建立期望或绘制一个原始功能集，基于跨平台System.Xaml的预期以及所需的用途，例如 UI 和 WF。

@karelz

另外我想至少有几个人看一下 - 是的，让我们先获取 Xaml，然后请求 WPF 会更容易。 所以他们一直想到的场景是 WPF，而“纯 Xaml”只是迈向它的第一步。
也许我错了（尽管我至少不是 .NET 团队中唯一有这些疑问的人）......

那么……这有什么问题？ 类似 WPF 的跨平台解决方案可能是一件好事。 Xamarin 不能做跨平台桌面 GUI。

@jnm2还不错 - 但如果这是主要的（90%+）场景，我们应该计划两者都做。 在这种情况下，没有 WPF 的 Xaml 不会有帮助（至少没有多大帮助）。 并且它可能会产生（可能）WPF 已提交并将在不久之后出现的无效错觉。

将 WPF / GUI 引入 .NET Core 将是 .NET Core 迈出的一大步，它现在主要针对服务器场景和控制台应用程序。

@jnm2拥有 System.Xaml 将极大地帮助那些正在尝试将 WPF 之类的东西带到其他平台的人（比如我自己）（https://github.com/AvaloniaUI/Avalonia）。

@grokys这听起来像是一个合理的场景 - 你能详细说明一下吗？ 帮助有多大？ 没有它有什么挑战性？

我还将 Xaml 用于我的（非 WPF 之类的）跨平台桌面 UI 框架Eto.Forms 。 这就是为什么我一开始就创建了Portable.Xaml项目，并且到目前为止它对我和我的用户都运行良好。

我不反对帮助使其成为“权威的”跨平台 xaml 实现（正如@Mike-EEE 所说）。 但是，请记住，我只在业余时间从事此工作 (;

@karelz
不仅是 UI 框架，它还可以用于 XAML 到 HTML 等许多场景

@Kation你能分享更多细节你的意思吗？

顺便说一句：我开始在顶帖中总结场景 - 如果您的场景不存在，请描述它，一旦理解，我会在那里添加它。

@karelz
借助 Visual Studio 中强大的 XAML 编辑器，我们可以快速创建自定义组件内容。
然后，我认为我们可以在一些特殊场景下使用 XAML 生成 HTML 内容，甚至更多的 SVG 内容。
这是 .Net 4.5 的半成品 XAML 到 XML 框架。 https://github.com/Kation/WebPresentation

我不明白你为什么要从 XAML 生成 HTML 或 SVG。 XAML 在这里的价值是什么？
它有一个不错的 VS 编辑器的价值吗？ 还有 HTML 编辑器，为什么不直接使用呢？
还是我完全错过了重点？

@karelz
因为我想在一些项目中生成像WPF这样带有模板和样式的内容。

@karelz再次感谢您的对话。 我非常感谢它。

我不会有无所不知的错觉，或者认为我比其他人更聪明。

哦，我羡慕。 😉

所以他们一直想到的场景是 WPF，而“纯 Xaml”只是迈向它的第一步。

是的，这又是我提到的混淆。 Xaml 是一种序列化范式，纯粹而简单。 您可以在其中定义和描述一个应用程序——及其包含的组件。 首先，下面是 Xaml 中描述的 _console application_ 的示例：
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

您可以看到 Xaml 中描述的命令提供了有关通过使用控制台输入和输出向用户呈现的内容的说明。 这与 WPF 或“UI”无关（尽管从技术上讲，这是 CLI 意义上的 UI，但希望您能发现其中的区别）。 此外，您可以看到我在文件中使用了标记扩展和静态成员声明。 这是我在 JSON 或任何其他数据格式中没有看到的。 这确实是 IMO 的 Xaml 的强大功能。

作为“Pure Xaml”场景的另一个示例，这是我为新的与格式无关的 MSBuild 提议的文件：
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

（如果你上升一个级别，你可以看到做同样事情的其他格式，这恰好是 Xaml 版本）

这是处理器文件，它又是一组 ( System.Windows.Input.ICommand ) 命令，描述了在理论构建过程中采取的步骤。 同样，没有 WPF 或 UI，但您可以看到它确实向控制台发出了消息。

我想在这里指出的一个我之前提到的功能是我从这个文件中获得的 Visual Studio 中的内置工具：

在不做任何工作或定义任何外部架构的情况下，Visual Studio 只需“点亮”并提供属性编辑器，其中包含基于我正在使用的文件的类架构的下拉列表和其他设计器界面（这有望使 devops 场景更容易了解）。

除了处理器文件，这里是可用于发送到处理器的理论项目或输入文件：
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

在这里，我尝试使用 _markup extensions_ 提供版本（可能来自外部文件）并使用查询来提供收集到的文件以进行构建（请注意，也许您可​​能不想在最终构建系统，但我想证明它的可能性）。

顺便说一句，此示例代码是完全可操作的，因此您应该能够从该存储库中获取 SLN 并运行 Xaml 版本，结果应类似于以下内容：

（注意：在我的机器上工作，所以你的里程可能会有所不同。😄）

顺便说一句：我不太了解您的 devops 场景以及 Xaml 如何是唯一/最好的帮助？ 或者它是如何在场景中实际使用的？

是的，我争论是否要进入那个，因为我觉得我的帖子有点冗长。 希望现在上面的可视化设计器组件可以帮助说明我在这里所做的事情。

请知道并注意，对我来说，这是最终的结局，以及为什么我对这一切如此狂热。 _原因是它最终降低了应用程序在其生命周期内的总拥有成本。_

所以这里的核心是，我们在这里谈论的是基于 POCO 的开发，其中编辑和设计发生在应用程序过程中使用的 POCO 上。 正如我们所知，开发人员和设计人员将处理描述处理 UI 域的 POCO 元素的 Xaml 文件（如果您愿意，这里是“Xaml”的传统“WPF”）。

在我的世界里，我希望看到这个过程得到扩展，以便开发为 devops 提供 Xaml 文件，以用于管理/维护已部署到实时环境的应用程序。

您可以将其视为实时配置文件。 它们的加载方式必须得到解决，但最终结果将类似于您在上面的 Visual Studio 屏幕截图中看到的那样。 与其让最终（devops）用户被迫投入代码（或者更确切地说，让组织被迫雇用所需的昂贵人才/技能组），不如使用受限制的、经过验证的可视化编辑控件来配置和维护应用程序。

_这里的想法是，由于这样做需要付出努力（和技能），而不是需要了解和理解代码，因此在部署后维护应用程序的成本会大大降低。_

我没有提到的一个方面是这些控件实际上是可定制的。 Visual Studio 有一个（尽管已经老化）广泛的 API 来定义附加到这些 POCO 属性的可视化编辑器：
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

这一切现在都可以在 Visual Studio 中使用，无需任何额外的工作、开销或努力。 因此，这里的最终想法是创建一套功能强大的编辑器和设计师，不仅可以帮助开发过程，而且最终可以帮助开发运维过程。

同样，这一切都是有远见的，还没有任何实际的现实基础。 可以肯定的是，这并不完全是我的想法，而是受到模式和实践组及其基于 Windows 窗体的 Configuration Editor的启发。 我只是让这个傻瓜更进一步，并通过 Xaml 的强大功能来了解如何使用它。

如果您对此@karelz 有任何其他问题，请告诉我。 我再次欣赏对话。 它不仅提供了分享的机会，而且还提供了验证我的想法和信念的机会。 回到了解这一切的想法（是的，我有罪👼），我试着对事情保持开放的态度，并意识到我没有所有的答案。 这绝对是我不断努力做得更好的一个过程。 再次感谢！

@karelz - Avalonia 目前使用 OmniXaml 作为其 XAML 引擎，虽然这工作得很好，但仍然存在错误和缺失的功能。 与 Portable.Xaml 一样，OmniXaml 由一名志愿者维护，他并不总是有很多时间来处理它。

如果实际上您决定不打开 System.Xaml，那么发布您的测试套件可能是一个很好的折衷方案 - 至少这样我们可以确保 OmniXaml 和 Portable.Xaml 等第 3 方实现尽可能兼容。

我认为 .net 生态系统需要的是一种默认的人类可读的序列化格式——类似于 Javascript 世界中的 JSON。 这种格式应该使用 donet 数据类型，直接使用 POCOs 作为 schema。 然后该格式可用于描述 POCO 对象。 这些描述是强类型和静态类型的。 它可以是 UI 布局、运行时应用程序配置、项目/工作流描述，甚至可以是两个 .net 程序之间的通信。 甚至与其他生态系统（如 web/Javascript）的通信也是可能的，因为它们实现了这种格式。 但它应该围绕 .net 生态系统进行设计。 这就是 JSON/BOND/Protobuf/XML 不够的原因。

从历史上看，XAML 在某种程度上履行了职责。 现在的问题是，这个角色有多好。 如果它足够好，那么我认为 XAML 应该成为 netstandard，然后是 .net 实现。 但是，如果可能，还应考虑其他格式。 我想上周， http: //www.ammyui.com/ 出来了。 一种 UI 描述格式，侧重于简单性，但可转换为 XAML。 因为，XAML 不够简单。 我自己在 roslyn repodotnet/roslyn#16648 中提出了一种基于（对象、集合和索引）初始化程序的格式。 我的提议实际上取自 Entity 框架团队的@bricelam的这篇博文（然后稍作修改）。 他的帖子和我的提案线程都有一些例子。

我的观点是，.net 应该有一个默认格式，无论是 XAML 还是其他格式。

@grokys我确实想提到 OmniXaml，并已邀请@SuperJMN参加这里的对话，但他似乎不想参加。 不知道是设置还是什么（我也在 gitter 中进行了尝试——既然你和他一起工作，也许你可以把他拖到这里来获得更好的运气😄）。 当然，OmniXaml 也绝对欢迎参加这次对话。

@gulshan +💯 👏 👏！ 哈哈。 所有这一切令人困惑的部分原因是 Xaml 是一种 MSFT 格式和技术。 随着围绕它建立的所有投资和工具——无论是在 MSFT 还是在企业中，确实难以理解为什么在确保其连续性以便可以利用现有的努力和投资方面似乎存在差距。

也就是说，我喜欢我在 Ammy 身上看到的东西，并且我继续对此持开放态度。 或者尝试拥有一个。 👼

我认为重要的是重申为什么我们甚至会从数据文件开始，使用数据格式的主要价值是：

• 命令式语言不可知论。 使用这些文件不需要您了解编程语言。
• 设计师/工具友好。 _使用视觉设计师和/或为您的产品启用视觉设计师体验会降低TCO _。

也就是说，对我个人而言重要的是：

• 开发人员/设计师集成工作流程
• 手动编辑文件的视觉设计师体验。
  
  
  
  • PropertyGrid（属性窗口）具有如上所述的可扩展编辑器 API。
  
  
• 标记扩展
• 令人敬畏的蛋糕上的樱桃：能够在开发之外的场景中利用上述所有内容（上面的 devops 示例）。

如果满足所有这些，那么我愿意考虑“另一种 .NET 格式”，但显然我更愿意将 Xaml 维护和扩展为该格式。 毕竟，这是一项 MSFT 技术，因此也是知识产权。

@Mike-EEE 如果可以将格式反序列化为 POCO，则所有这些功能都应该正常工作，VS 中的属性窗口也会出现在非 XAML 场景中。 但我担心的一件事是，没有任何编辑器支持的可读性。 在某些情况下，您必须在远程服务器中编辑配置文件，而您只有 vim。 恕我直言，与 JSON 相比，XML（和 XAML）在这方面并不是那么好。

但是 XAML 有一些独特的东西（实际上是非 XML 特性），比如附加属性，它们很难用简单的序列化格式来模仿。

我会先投票给 WPF（这样我终于可以和 xamarin.froms 说再见了），然后是 xaml

VS 中的属性窗口也会出现在非 XAML 场景中

正确，但它不像 Xaml 那样几乎“点亮”，具有完全可自定义的编辑控件等。如果我在这里错了，请纠正我。 您不能简单地将光标放在这些格式的属性上并为枚举字段（例如）进行下拉呈现。 这种体验基本上是 WinForms 的下一个形式和版本，这也是它如此出色的部分原因（WinForms 仍然很受欢迎！）。

恕我直言，与 JSON 相比，XML（和 XAML）在这方面并不是那么好。

是的，我同意，Xaml 并不十分简洁，你会听到抱怨它有多冗长。 这就是 OmniXaml 通过围绕格式提供改进而大显身手的地方。 您还与其他格式（例如 TOML 和 YAML 等）竞争。

非 XML 功能），如附加属性...

和标记扩展。 😄 这些是其愿景的特征。

什么（我相信）你在这里@gulshan本质上是一个“数据AST（抽象语法树）”。 如果我们正在谈论认真改进 Xaml（或 .NET 数据格式），那么这就是要走的路。 它甚至可以由 Roslyn 提供动力。 事实上，我有一个用户投票支持这个想法（以及相应的博客文章）。 不幸的是它不是很受欢迎，因为它有点难以解释，哈哈。 本质上，您有一个可以写入任意数量格式的 AST（数据）树。 这样，开发人员（和工具）可以根据对他们最有意义（美学或其他方面）的任何格式来使用它。

所以我终于可以和 xamarin.froms 说再见了

在这方面与您达成一致@groege。 😎

@Mike-EEE 以前没有检查过您的数据 AST 提案。 是的，它在概念上类似于 .net 的默认序列化/对象表示法提议。 由于其抽象性，这个想法很难理解。 😄

关于 XAML，基于 .net 的强类型数据序列化格式将减少对许多 XAML 标记扩展的需求。 然而仍然会有一些，它们不能被某些表达式初始化（​​没有构造函数）。 我希望其中一些标记扩展功能是 C# 本身的一部分。

好吧，我还没有收到@karelz的回复，所以我只能假设他在得知您可以在 Xaml 中定义控制台应用程序后一直坐在他的显示器前：

（坏）笑话，如果您有任何其他问题，请告诉我。

此外，从 .NET 的本周开始，看起来.NET Core 中正在酝酿一个非常酷的引擎。 这篇文章的第一条评论说明了一切。 :)

@Mike-EEE 我知道我欠你一个答案（它在我的收件箱中被标记为重要并在浏览器中打开）。
到目前为止，我只能浏览回复（非常感谢大家提供的所有细节和见解！），但我没有时间自学 Xaml（正如你所指出的）并彻底阅读所有回复以成为能够回答......对不起，现在发生了太多的火灾和高调:(，我稍后会谈到它，我保证！

一切都好@karelz！ 非常感谢您在这里的努力和对话。

这是对开源 WPF 的投票，相比之下，所有其他版本的 XAML 都是垃圾。 认真的伙计们，完成这个循环，拥有一个适用于 unix 和 MacOS 的 .net core / XAML STORE 。

@Mike-EEE 非常抱歉，我仍然没有时间回到这个问题 :(

哦，伙计，别担心， @karelz我知道每个人现在都很忙。 我对这次谈话的欣赏胜过一切。 我想了很多。 很高兴看到它在那里并对其进行反思。 此外，到目前为止，我们已经为此等待了一年多……还有几个月左右的时间？ :)

他们应该开源 silverlight 5 .. 自从他们的 html5 移动，他们的 win8 移动/winrt ......现在 uwp & win10 和 xamarin ......常见！ 可悲的是，您迷失在好莱坞之类的拉拉土地上……

一个人怎么能从银光 5 到所有这些废话？ 如何？ 当您总是破坏汇编接口时，您怎么能说您尊重您的用户..您甚至重命名了自己的 nuget 包，并且没有自动在 nuget 中从旧包迁移到新包.. 就像您仍然无限地使用每个人Beta 测试人员，因为在创建想法和编码之前你太笨了，无法清楚地思考。

您需要消除对 xamarin 形式的 ios/android/uwp 项目的需求。认为支持多平台的方法比为每个平台都有一个项目要好得多。

现在把所有东西都放在一个 f 之下。 你擦屁股的框架（我推荐 wpf/silverlight 覆盖和 xaml 语言，但是如果你想把所有东西都带入 xamarin 但请你能在样式/模板上添加数据类型。像许多奇怪的遗漏，并确保你的 f.nucrapget 工作 A1一次..为什么我需要在所有依赖程序集中安装一个 nuget 包？与引用的 dll 相同..？你没有远见... niet none... capout ...一直卡在 ms 废话中..我本可以建立自己的f.世界级sdks ..

如果没有 MS 在我的路上倾倒粪便，我一天都无法度过.. 我正在认真考虑 scala-js 或者只是 swift.. 是时候离开家了！ 我受够了

好吧，他们花了将近两年的时间，但 UWP 终于为他们的 Xaml 模型指定了标记扩展：
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

另外值得注意的是，Noesis 上周推出了他们的 v2.0 产品，看起来相当令人印象深刻。 它的 Xaml 系统已经具有标记扩展功能（在 C++ 中，C# 正在开发中），并且没有用七年时间就达到规范。 现在独立开发者也可以免费使用。 一旦考虑到它对AmmyUI 的支持，我必须说，就 Xaml 模型进入 ATM 而言，这是我列表的顶部：

http://www.noesisengine.com/

嘿@karelz也许您可以对此发表评论。 但是您知道现在正在发生的 UWP Xaml“规范”是否与此问题有任何关联？ 如果没有，你知道它是否可以吗？ 这里的想法很疯狂，但如果可以得到帮助，以一个问题的价格解决两个问题可能会很好。 我也在 UWP 投票中留下了一条消息，但我想我也会在这里 ping 通。

@Mike-EEE UWP Xaml“规范”可能是由另一个组织（我认为在 Windows 中）驱动的——向他们询问有关用户语音的详细信息可能是最好的渠道。

是的，我害怕那个。 😛 我确实在那里收到了回复，但老实说，这对我来说没有多大意义。

据我所知，他们似乎将继续在他们的规范过程中采取闭门造车的方法。 这令人担忧，因为这似乎会导致与上次相同的结果，最终导致没有人愿意使用或采用的 API。

也许他们偷偷喜欢开发者抱怨他们的工作。 :)

在任何情况下，如果您正在阅读本文并且是透明、开源协作和开发的支持者，并且很高兴成为 asp/.NET Core 成功进入该领域的计划的一部分，请稍等片刻。到 WPDev UserVoice 并向他们发送一条便条，鼓励他们也这样做。 该链接在前面提到过，但对于那些从电子邮件中阅读此内容的人来说，这里再次提供：
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

我必须打电话给@birbilis ，并感谢他早先在那里所做的贡献。 任何人都可以在促进我们在这里使用的过程中提供任何额外的信任的话，我们将不胜感激。 👍

叹息...就像用户声音一样，您可以让人们为事物投票，最后即使它很受欢迎，也不要对此做任何事情！

更新：
https://github.com/microsoft/xaml-standard

我敢肯定@Mike-EEE 会对此感到非常高兴；P

这是一个伟大的举措。 感谢分享@RichiCoder1

不幸的是，它只是 UI。 XAML 的其他用法（如 Sharepoint 和 WF）可能已经过时了。

但是，是的，至少它将有助于在所有受支持的平台上标准化 XAML。

好动作！

希望他们将它分层

例如，除了非 UI 基础 XAML 层之外，我希望看到 XAML 3D 层

@galvesribeiro看起来有人创建了一个问题： https ://github.com/Microsoft/xaml-standard/issues/23 我会+1，没有理由不拆分最终标准。

我敢肯定@Mike-EEE 会对此感到非常高兴；P

哈哈，没错，@RichiCoder1！ 这一切都是错误的和破碎的，它应该在哪里，但这是一个开始。 ;） 谢谢你让我们知道。 👍

很高兴看到有人创建 https://github.com/Microsoft/xaml-standard/issues/23，这样我就不必这样做了。 ;) ;) ;)

请考虑在 XAML 标准中包含 WF（工作流基础）！！。

@Suriman请点赞！
https://github.com/Microsoft/xaml-standard/issues/23

所以我不想问——我这样做是为了成为一个优秀的回购/发行公民，但是这个问题还需要吗？ 我的意思是，那个 repo 已经记录了 50 多个问题，这些问题比这个问题更详细。 看起来它已经有了自己的生活！

有理由让这个问题在这里公开吗？ 除非我完全误解了某些东西（很有可能），否则我认为我们已经通过 Xaml 标准实现了这里的目标。 它是社区驱动的，一切对我个人来说都是最重要的。 :)

@Mike-EEE 这两个问题之间存在细微差别； 在我看来，一个是关于标准化 XAML 本身中可用的 API（严格来说是在 XAML 本身中），另一个是关于支持 XAML 作为类似于 System.Xaml 的 .NET 标准组件。

@lokitoth绝对愿意就此进行讨论，因为我仍在尝试了解所有新作品。 我想最好先建议观看@terrajobst的优秀且内容丰富的视频，该视频演示代码“正在使用”新的 .NET Standard2.0。 我个人并没有考虑这会如何影响 System.Xaml。 我的想法是它应该“正常工作”，但也许我开始认为我现在在这里弄错了（太好了，难以置信）。

老实说，在阅读了 Xaml Standard repo 中的一些线程之后，我有点为我之前的建议而自责（☕️咖啡让我这样做，我发誓！☕️）。 从外观上看，“Xaml 标准”最好命名为“MSFT UX/UI 标准”，因为这是该存储库中主要讨论的内容。 就目前而言，Xaml 作为一种强大的序列化技术根本没有被展示/展示/突出显示（除了在这里做出努力的少数勇敢的声音），这也导致了一些断开/混乱。

我个人并没有考虑这会如何影响 System.Xaml。

我们需要检查程序集以确定它的依赖关系树是否可在 .NET Standard 2.0 上下文中加载。 如果它是纯 .NET，它可能会工作（尽管有一组完整的编译时项，例如 BAML、嵌入式资源等，它们将被引入 .NET Core 的工具链）

从外观上看，“Xaml 标准”最好命名为“MSFT UX/UI 标准”，因为这是该存储库中主要讨论的内容。

我认为，这更多是因为它是在 UWP/Xamarin.Forms 的背景下宣布的，这意味着专注于这两个平台的开发人员——他们可能没有接触过“BigXaml”——是主要贡献者。 尽管您看到一些“带来所有 WPF XAML 方言”的问题已打开。

鉴于团队有很多清理工作要做，而且现在新问题的发生率相对于贡献的人数来说相当高，我会给它更多时间看看团队把它放在哪里。

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
我在 Xaml Standard 中创建了一个问题。
https://github.com/Microsoft/xaml-standard/issues/57

感谢@juepiezhongren 的提醒和对对话的贡献！

好吧@lokitoth ，我很高兴我们保持这个问题完好无损，因为它决定https://github.com/Microsoft/xaml-standard/issues/23不适合日光。

但是，我创建了一个新问题，我觉得它可以更好地描述手头的问题，在这里添加您的支持和/或贡献会很棒： https ://github.com/Microsoft/xaml-standard

澄清一下，您正在寻找的实际上是 _JavaScript_+HTML5+CSS3 生成的工件。 TypeScript 实际上是 JS 的转译器。 MSFT 没有制作 .NET 转译器来生成可在浏览器中有效执行的符合标准的 JS（如JSIL ），而是决定花费 C# 创建者的宝贵时间来制作能够有效并最终与之竞争的东西。

我会说不要让我开始这样做，但我认为我从未停止过。 😛

此外，另一点是CSHTML5非常接近您正在寻找的@weitzhandler ，但它不允许在客户端/服务器程序集（如 PCL 等）之间共享代码。 因此，您最终仍然需要维护两个独立的、不兼容的代码库，从而导致 .NET 和 JS（或 TypeScript 😉）之间存在相同的成本/业务问题，也就是说，在严格的 NodeJS 解决方案中不存在。

我的梦想是为带有点网核心的桌面应用程序使用 android xml ui 写作风格！ 对真的！！

任何将 XAML 移植到 .NET 核心的努力我都愿意自愿。

在我对CoreWf （网络标准 2.0 上的 WorkflowFoundation）的修改中，我看到 System.Xaml 或更兼容的 Portable.Xaml 实现可能需要允许从 Xaml 加载 DynamicActivity 。 我在 .net 框架上运行 CoreWf，使用 System.Xaml 加载基本的 DynamicActivity，但由于使用 Portable.Xaml 的 .net 核心上的解析状态无效，仍然失败。

一个问题是为什么 System.Xaml 的代码没有添加到 Mit 许可的参考源代码库中？ 是否存在许可、专利或其他问题？ 如果没有问题，将此代码添加到参考源将允许我们社区进行必要的移植以支持 CoreWf。 参考源存储库未提交 Microsoft 以支持 System.Xaml。 我应该在那里添加一个要求打开 System.Xaml 的问题吗？

如果 System.Xaml 没有打开，那么我们是否可以有一个文档（Xaml 规范除外）或以测试的形式提供支持，以描述为 WorkflowFoundation 解析和标记 Xaml 代码的正确步骤？

嘿 FWIW @karelz我在这里对 DevOps 场景提出了一些想法：
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

基于 Visual Studio Xaml 设计器中发生的一些很酷的事情：
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

以为我会在这里提到它，而我正在这样做。 👍 此外，这个线程已经过期了。 😆

@weitzhandler你需要更新，因为 mono-wasm 处于 alpha 状态，几乎是时候开始忘记 js 了。

@weitzhandler需要 2 或 3 年，但它不仅仅是一个完整的堆栈，它是 .net 的通用堆栈。

CoreRT 也在船上 - https://github.com/dotnet/corert/pull/4480 。 希望明年有一个生产就绪的 HTML+CSS+C# 组合。

提议的.net 兼容包包括System.Xaml可能状态并链接到此问题。

显然此问题已与兼容包 2.1 相关联？ 有人可以确认吗？ 我看到它已被标记为 netfx-compat-pack，但没有带有版本。 不过，我将接管迄今为止发生的任何事情。 😄

讨厌失望，但我想我在批量更新 comapt 包的问题时不小心将其标记为 2.1。 我已移至 Future 以反映提案中的可能状态。

@Mike-EEE 似乎 xamarin.wasm 即将到来。
https://github.com/mono/mono/pull/5924#issuecomment -343551464

感谢大佬们的更新。 感谢你为我着想。 :) @terrajobst这确实令人失望，但我感谢您抽出时间检查和更新。 我不确定您是否仍然订阅此线程。 👼

由于我们正在花时间无耻地插入项目（而且在我们得到官方 Xaml 修复之前还需要一段时间），所以我将花一点时间提及我在过去一年中一直在帮助解决ExtendedXmlSerializer v2 的问题，这是最近发布的。 它具有对标记扩展和附加属性的实验性支持（适用于 POCO，不需要DependencyObject ），以及protobuf样式的参数化序列化。

如果您在我们等待 System.Xaml 到达时正在寻找（或添加）类似 Xaml 的功能，请随时检查它、提供反馈或（更好）在 repo 中提交 PR。 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@danmosemsft将在 SDK 项目中支持 Workflow Foundation xaml 作为 3.0 桌面计划的一部分吗？

@lokki我不知道计划。 @terrajobst @karelz？

@danmosemsft
为什么没有“提供 UI 框架作为 .NET Core 的一部分”的问题？

这个问题没有具体讨论缺少 UI 框架，而且这里的人们似乎没有意识到这一点。
看到这个： https ://github.com/Microsoft/xaml-standard/issues/232

@weitzhandler这个问题现在对我来说更有意义了。 感谢您的澄清。

我可以看到将System.Xaml包含在 .NET 标准中很有用，尤其是与 XAML 标准一起使用。

如果我正确理解“桌面计划”，您应该能够使用过去可以使用的 .NET 库，只要您仅针对 Windows（不确定您的应用程序是否能够动态适应它的环境运行，如果主应用程序将无法执行它[例如，如果它找不到说 Windows 操作系统，则不会启动]，那么您可能可以通过制作多个调用平台特定内容的 .NET Core 程序集来做到这一点并根据应用程序检测到的运行平台按需加载它们）

@Birbilis还不够。 相同的 XAML 必须在所有平台上均等地呈现。

桌面计划不是关于 XAML，而是关于 .NET Core 不是最小公分母孤岛，而是允许应用程序可以针对特定平台（或者理想情况下也可以动态适应它们所运行的平台）并使最好地利用它们，进行特定于平台的集成等。人们可以在此功能之上构建基于功能的 API，这样就可以编写应用程序来查询特定功能的可用性。 也可以在此基础上构建抽象/兼容性 API，将 API 的作者有兴趣支持的每个平台挂钩到不同的实现中。

就目前而言，我认为Portable.Xaml现在与 System.Xaml 非常接近。 如果您发现任何问题，请提供反馈。

WPF 团队 (@dotnet/wpf-developers) 刚刚宣布为 .NET Core 3.0 开源 WPF。 作为其中的一部分，.NET Core 3.0 的预览版本现在包含 System.Xaml，相应的源代码可在 https://www.github.com/dotnet/wpf 获得。

顺便提一句