简单的.ui怎么样？

这种区分是否也有助于非孤岛案例，还是会更令人困惑？

或者，如果这主要是为了在同一解决方案中帮助区分例如 WPF 和 WinUI Xaml，那么像.winui.xaml或.island.xaml这样的约定呢？ 这可能会使使用现有工具变得更容易。

这适用于 XAML Islands 场景还是无处不在？ 对于其他所有情况，除了造成混乱和迫使人们迁移（并且可能破坏许多工具（如旧版本的 VS）的向后兼容性）之外，我看不出这有什么价值。 像“whatever.winui.xaml”这样的约定可能破坏性较小，但我仍然认为它只在岛屿范围内有用，而不是在其他任何地方。

鉴于我不想将讨论范围缩小到 XAML 岛，因此更改标题。

我说继续使用 .xaml。 WinUi 的范围（和名称）可能会更改为包括窗口之外的其他平台（可能通过 UnoPlatform？）。 如果项目名称更改会怎样？

我更倾向于NO。 Microsoft 对产品和服务进行了太多重命名，有时会损害产品/服务或其用户（意见）。 这是另一个重命名。

这适用于 XAML Islands 场景还是无处不在？ 对于其他所有情况，除了造成混乱和迫使人们迁移（并且可能破坏许多工具（如旧版本的 VS）的向后兼容性）之外，我看不出这有什么价值。 像“whatever.winui.xaml”这样的约定可能破坏性较小，但我仍然认为它只在岛屿范围内有用，而不是在其他任何地方。

到处

我认为 XAML 应该保留.xaml ，但如果要出现新的东西来替代传统 XAML 或与传统 XAML 一起使用，那么.winui扩展名可能对此有用。 #804 :)

这个请求完全让我感到困惑......我不得不将这个问题阅读两次才能理解发生了什么......这将比不同的方言更加碎片化 xaml 生态系统......

瞬间失语了……

@liquidboy好吧，这至少是一个明确的反馈，支持不进行此更改 :) 感谢您发出您的声音。

我喜欢来自@jesbis的想法，也许我们可以添加一个*.islands.xaml来帮助更轻松地区分在 Islands 上下文中运行的 XAML 文件与不运行的 XAML 文件之间的区别。

好奇：是让.islands.xaml只适用于 Island 中的 XAML 文件，还是只是在任何地方都使用.winui.xaml作为整体扩展名会更好？ 我不确定这两个想法中我更喜欢哪一个。

我的投票是“.islands.xaml”或类似的模式是岛屿中推荐的（但不是严格强制执行的）模式，其他任何地方的 .xaml 文件仍然是 .xaml 文件。 这样我们就可以避免对不使用岛屿的人造成不必要的影响。

我最大的担忧来自所有的工具。 我对不同的扩展名没有任何问题，但这意味着依赖 .xaml 文件扩展名的每个工具都需要更新（我正在考虑 R#、 XamlStyler等）。 围绕 xaml 的工具支持已经感觉像是在苦苦挣扎，而且这看起来可能会使情况变得更糟。

我的 0.02 美元

也许问题标题应该更改为：
Xaml Islands 包含的 XAML 文件是否应该与 WinUI 3 项目具有不同的文件扩展名？

我强烈赞成将 .xaml 保留在其中。 也许您会使用 .ui.xaml 或 .xaml.ui，但技术很强大，并且可以提供帮助。 另一方面，不幸的是，在 wpf 性能陷阱、silverlight 和 windows phone 之后，xaml 受到了一些耻辱，因此更简洁的文件名可以帮助扭转局面。 我仍然喜欢 xaml，但我们不需要对技术名称产生更多混淆，除非它经过深思熟虑。

我认为将它简单地作为 .ui 是一个好主意，因为如果 winui 成为跨平台（就像许多 Windows 的东西一样），它将更适合。

这意味着它将成为未来的证明。

代码文件将具有 .ui.cs 扩展名，该扩展名易于解释且易于阅读。

.winui.xaml

所以这意味着我们将拥有 .winui.xaml.cs 文件？ 哎呀。。

使用 json 格式。 现在是 2020 年。

JSON 很苛刻，使用起来不太友好。

使用 json 格式。 现在是 2020 年。

JSON 格式是供计算机读取的，而不是供人类读取的。 它很难阅读，看起来也不好看。

我认为.winui会让初学者放弃。 因为我们会认为我们应该学习一门新的语言。 现在我们有了 WinForms、WPF、UWP、SL、ASP 和 ASP.NET Core。 我们应该花越来越多的时间来学习它，而不是继承。 我认为我们不应该总是制造新技术。

对不起，我和我的许多朋友都不喜欢学习新事物。 如果我们不期望成为少数，那我们应该使技术可以继承，可以重用和兼容。

在我看来，“哪个 XAML 是哪个”的更优雅的解决方案将取决于默认的 xmlns 命名空间，正如@grokys在此评论中所建议的那样： https ://github.com/AvaloniaUI/AvaloniaVS/issues/95#

我们没有使用 UWP 执行此操作，但也许我们可以为 WinUI 更改它。

在我看来，“哪个 XAML 是哪个”的更优雅的解决方案是依赖于默认的 xmlns 命名空间，正如@grokys在此评论中所建议的那样：AvaloniaUI /AvaloniaVS#95（评论）

我们没有使用 UWP 执行此操作，但也许我们可以为 WinUI 更改它。

您可以引入 Doctype 的等价物，就像 HTML 一样？

您可以引入 Doctype 的等价物，就像 HTML 一样？

也许，但我们不应该这样做。 默认命名空间应该是使每个不同平台区分开来的东西（毕竟它们是在代码隐藏中做的）

围绕 xaml 的工具支持已经感觉像是在苦苦挣扎，而且这看起来可能会使情况变得更糟。

@keboo这对我来说真的很重要，而且我正在努力让我们修复并做正确的事情。
我们所处的世界我们无法区分它们（对于岛屿场景），这是多年来工具如何发展的产物。 一切都是完全独立的，几乎不可能合理化不同方言之间的差异。 我想改变这一点，并开始使 XAML 解析和编译可以在所有 XAML 方言之间轻松共享，在此示例中，WinUI 和 WPF 使用相同的基本引擎。 该工具应该是默认命名空间所声明的插件，并且可以在需要时进行自定义。 在我看来，我们不应该需要更多的东西来使这个场景正常工作。 尽管这是一项巨大的努力，但对我来说，这是我们所有人都应该做的正确事情。

@stevenbrix该平台目前会理解 XAML 何时在 Island 情况下使用，但我读到这个问题的问题是开发人员告诉和理解如何在 WinUI 3.0 中使用 .xaml 文件的一种方式项目。

至于一般的 XAML 工具，它需要对 IMO 的设计时体验进行全面重做。 Expression Blend 是 XAML 设计和开发最后一次被认为是顶级的。

由于 XAML 的性质，它既是书面形式，也是可视形式。 Visual XAML 设计在将 Intellisense 带入高质量方面退居二线。 如果可以有一个健壮的、高性能的、易于原型化和完善的 XAML 设计体验 - 这可以重振社区。

一种插件方法，它不需要控件或工具包供应商做很多工作，同时仍然提供良好的设计时间、工具托盘、元素属性体验 - 可能非常有用。 随着 XAML 转向其他非传统形式因素，需要考虑设计工作流。 两个窗格视图（Neo 和 Duo）、非窗口托管 XAML 表面、Shell 集成、混合框架项目（xaml 岛、GDI 和 WinUI 混合）、Hololens Spatial 3D、旋转表面集线器等。

但也许声明性标记不再是处理它的理想方式。 或者也许应该在 XAML 内容和 XAML 样式之间有更多的分离？ 与 HTML 和 CSS 一样吗？

WinUI 感觉是一个很好的机会，不仅可以延续现状，还可以规划未来几十年。

不，我不明白这一点。 它不能解决任何问题。
如果有的话，它会给已经知道 xaml 扩展的编辑器带来问题。
我每天都使用 wpf、uwp 和表单 xaml，而且我从来没有因为扩展而感到困惑。

Xaml 的全部意义不是更容易工具吗？ 如果不依赖于文件扩展的古老概念，工具就不能解决这个问题吗？

我的意思是一般来说，如果 UI 框架没有任何变化，即它仍然是 XAML，请不要这样做。

如果它是一个全新的 UI 框架，那么我看不出有什么问题。

我也不知道您为什么要使用建议的islands.xaml来区分岛的 XAML 组件。 它会在工具方面做任何不同的事情，还是只是为了解决方案的可读性？

我的第一个想法是我绝对不喜欢这个想法。 但也许我没有看到它可以解决的真正问题，也许我不明白这一点。

如果其中有一个带有 xaml 的文件，我希望它是一个 .xaml 文件。 过去，我从来没有想过我希望 UWP .xaml 文件的名称与 WPF .xaml 文件不同。

接下来是文件扩展名中的框架名称似乎不是一个好主意，因为框架名称可能会更改，而 XAML 是 4ever XAML。

所以，我的意见是：一定要使用 .xaml。

但是带有 .xaml 文件扩展名的选项有哪些？
另一个 .islands.xaml 文件扩展名？ 这意味着文件扩展名不仅用于描述格式，还用于描述文件的内容。 嗯......但是这个的优点是你可以让它对开发人员来说是可选的。 如果他们想使用它，他们可以调用他们的文件 .islands.xaml 并且工具将使用不同的图标等来选择它。

另一个 default-namespace 也是一个有效的选项。 但这对于工具来说意味着它必须查看每个 .xaml 文件以找出它是什么类型的文件。 这也意味着 XAML 方言由于另一个根命名空间而再次出现了一些分歧。

但现在一个完全不同的想法：

如果我没记错的话，所有这些更改只会对 XAML Island 案例有帮助，在该案例中您可以在同一个解决方案中混合平台，对吧？ 因为如果您只使用 WinUI，您就会知道每个 XAML 文件都使用 WinUI。 我不确定 XAML Islands 是否会成为 WinUI 的主要场景。 过去引入 WPF 时，我们也有 WPF 和 WinForms 互操作，老实说，我很少看到开发人员在他们的 WinForms 应用程序中使用 WPF 控件。 相反，他们继续在 WInForms 中使用 WinForms，并使用 WPF 而不是 WinForms 开始了新项目。 也许 WinUI 3 也是如此，我认为会是这样。 XAML Islands 是一种现代化的好方法，但根据我的经验，开发人员只有在他们的 WPF/WinForms 应用程序中确实需要来自 WinUI 的控件时才会这样做。 如果没有，他们继续在旧堆栈上，并在新堆栈上启动新应用程序。 请注意，这不一定是事实，这只是我的经验。 :-)

这意味着我们正在讨论为可能不是平台主要场景的场景更改文件名。 我想这就是为什么我认为它不值得。 如果 WPF/UWP/Silverlight/Windows Phone 开发人员创建一个新的 WinUI 3 项目怎么办？ 他们会认为

为什么他们将 .xaml 文件扩展名更改为...？

请不要删除 .xaml 文件扩展名。

请不要去更改扩展名！

许多年前，我们开始在 Avalonia 中使用.paml扩展，但由于它引起的问题，最终又回到了.xaml ：IDE 中已经有了处理 XAML 的工具（无论多么笨拙，至少它是一些东西！）。

如果我们希望每个 XAML 方言都有自己的文件扩展名，那么每个想要使用 XAML 的项目都必须从头开始编写 100% 的工具 - 甚至需要重命名文件的工具之类的东西每次都要重写以重命名代码隐藏类等。

正如上面提到的@stevenbrix ，有一种非常好的方法可以判断文件正在使用哪种 XAML 方言，哪个是文件顶部的默认命名空间。 作为第一步，使工具尊重这一点。

然后开放 XAML 语言服务，提供与设计者交互的 API，每个人都可以受益；）

漂亮请;）

另一个不这样做的理由：UWP 已经在与采用问题作斗争。 将其重命名为另一种技术，而不是“它或多或少与 wpf 相同”。
WinUI 3.0 的重大更改已经存在更大的问题，这些更改将严重损害现有的 uwp 生态系统。 不要添加另一个不同的东西。
它仍然是 xaml，只是针对不同的 API 集，就像 c# 仍然是 c#，即使我将它用于不同的 UI 框架。 我可以使用的代码和 API 发生了变化，但它仍然是同一种语言。

我投反对票，我看不到任何好处，只是增加了混乱。

另一个不这样做的理由：UWP 已经在与采用问题作斗争。 将其重命名为另一种技术，而不是“它或多或少与 wpf 相同”。
WinUI 3.0 的重大更改已经存在更大的问题，这些更改将严重损害现有的 uwp 生态系统。 不要添加另一个不同的东西。
它仍然是 xaml，只是针对不同的 API 集，就像 c# 仍然是 c#，即使我将它用于不同的 UI 框架。 我可以使用的代码和 API 发生了变化，但它仍然是同一种语言。

@dotMorten Ha，我对 C# 有同样的想法。 如果我们将.xaml文件称为.winui ，我们应该将.cs文件称为.wincode以使其一致。 :-)

也许我仍然遗漏了一些东西，但对我来说它会引起更多的混乱，我看不到它的真正好处。

我的 2 美分，请坚持使用 _.xaml_。
请把事情统一起来，而不是把它们分开。

如果您想在 WPF 和 WinUI 之间共享小的 XAML 片段怎么办？ 我猜肯定有一些重叠，不是吗？ 它会使共享项目变得不那么有用......或者真的有很大的不同吗？ 如果它几乎是相同的类似 XAML，则保留相同的扩展名。 如果格式与过渡 XAML 大不相同，那么更改扩展名可能更容易接受。 那么真正的问题是格式与原始格式有多接近？

XAML 也用于 Xamarin，它不仅针对 Windows，而且针对 iOS、Android、macOS ......

将 .xaml 替换为 .winui 将导致 Xamarin 为 XAML 文件保留 .xaml（为什么要为 iOS 或 Android 使用 .winui？），而像 UWP/WPF 之类的 Windows 目标将移动到用于 XAML 文件的 .winui .

TL;DR一种文件格式/约定两个名称（Windows 为 .winui，Xamarin 为 .xaml），对我来说这很混乱。

扩展名应该是.xaml作为内容的语法它是 xaml，另一个扩展名只会造成混乱。
我投票给.winui.xaml之类的东西

留在“.xaml”，它的强大

不得不说，微软有病态命名的问题！

而这个真的是他们中的佼佼者。

不

如果您需要在同一个项目文件中包含 UWP XAML 和 WPF XAML，请改用新的Custom Tool 。

这样，该工具将检测 XAML 文件是使用 UWP XAML 还是 WPF XAML，并通过 msbuild 目标将它们发送到正确的编译器。

更好的办法是标准化 XAML 语言，这样我们就可以开发通用的编译器、二进制格式和框架库。

我就是这样做的！

既然你在问，不，不要这样做。

如果工具无法读取文件以查看差异，则 WORSE CASE 应该是“.winui.xaml”等的非必需约定。 再次关键是 NOT-REQUIRED 。 只是 xaml 扩展文件应该可以正常工作，但可能缺少一些增强的工具。

虽然我理解这背后的想法，但我认为这是一个糟糕的解决方案。
首先，WinUI 是框架商业名称，而不是文件格式。 如果有人决定版本 4 需要将名称更改为 UniversalUI 或其他名称怎么办？ 您将以不同于文件扩展名、不同于文件格式的框架名称结尾。 这可能是一场噩梦。

其次，它可能会破坏与现有工具和文档的兼容性。 未来的开发人员无法明确 WinUI 文件在内部是 xaml，因此他们不会将 xaml 文档视为相关文件。

第三，它将更多地分割微软产品中使用的 UI 语言。 我真的认为我们需要更多地达到 Xaml 的标准，因此产品并不那么重要。 Xamarin、Net Core、Windows 10 或 WPF 的 C# 相同，为什么 XAML 需要不同？

让人们安排他们的项目并组织代码，这样他们就不会感到困惑。

使用 json 格式。 现在是 2020 年。

@rickydatta即使在 2020 年，网络也使用 HTML 而不是 JSON 来定义用户界面。 HTML 和 XAML 等标记语言非常适合定义 UI 的原因有很多。 JSON 非常适合做一些事情，但 imo 不适用于定义 UI。 当您将 JSON 用于 UI 并尝试构建数据绑定、静态资源引用等功能时，您会发现它变得非常不可读。 但它在这里是题外话，所以让我们离开它。 如果您想要 JSON，请创建一个新问题，让我们看看社区对此有何反应。 :-)

我真的尽量避免在这里发表评论，因为大部分内容已经说过，但我已经让步了。对不起。 我很弱。

不要这样做。

如果你想做出改变，就需要有一套明确的利大于弊。

潜在的好处是什么？

• 对于拥有一些完全包含 WinUI 控件的 .xaml 文件和一些不包含的 .xaml 文件的人来说，这将避免可能的混淆。
• 帮助启用工具来确定如何处理 .xaml 文件可能不同的内容。

而已。
我已经重读了整篇文章三遍，我看不到这里列出的任何其他潜在好处。

潜在的不利因素是什么？

• 它会引入混乱。
  ——“这个新扩展是什么？” “打开它需要什么？” “和……有什么不同？” “他们为什么改变它？”
  -- 当混合现有的 UWP XAML 和 WinUI3 元素时，您对仅包含一些 WinUI 控件的文件使用什么扩展名？ 或者这个建议是否意味着这种能力将会消失？ （看，仅仅通过提出更改文件扩展名的建议，你已经引入了更多的混乱和 FUD。如果文件扩展名之类的东西可能仍然发生变化，也许我应该等待以任何身份查看 WinUI，直到它更稳定. 有好几个人叫我去研究 Flutter. 或许对我来说更美好的未来就在那儿。）
  -- 我对现有 WPF 应用程序中 Xaml Islands 的卖点之一的理解是，它意味着能够在使用 XAML 时重用现有技能和知识。 这种变化表明它不仅仅是 XAML，因此它是另一件必须学习的东西，也是采用的另一个潜在障碍。）

• 这是不必要的。
  -- 如果人们想在一个解决方案中分解文件，他们已经可以通过多种方式做到这一点：不同的项目； 不同的目录； 文件名的前缀或后缀； 使用多个/子扩展； 或在 VS 解决方案资源管理器中嵌套文件。 目前尚不清楚新扩展或强制每个人使用多个/子扩展如何比这些选项中的任何一个更好。
  -- [默认] 文件中的命名空间已经告诉工具正在使用 XAML 的哪种方言以及它应该可以做什么。 （在这方面可能存在一些其他未记录的问题，这意味着这是不可能的，但如果是这种情况，那么需要更多信息来说明为什么更改文件扩展名是解决该问题的最佳解决方案。）

• 它无视历史。
  -- 我以前使用的解决方案包含针对 WPF、Silverlight 和 Windows Phone 的项目。 他们都使用不同的 XAML 方言，但我从来没有对正在使用的语言或在文件中可以做什么感到困惑。 我使用过包含用于 UWP 和 Xamarin.Forms 的 XAML 的解决方案，但没有遇到在此问题背后的假设中预测的混淆。 我还与许多其他具有类似解决方案的开发人员交谈过，我从未听过其他人说使用不同的扩展会对他们有所帮助。
  -- 在我听到的所有关于 XAML 不同方言的批评中，基于文件命名的混淆从来都不是其中之一。
  -- 开发人员通常不喜欢你在没有充分理由的情况下告诉他们应该如何命名和构造文件和项目。 记录指导和推荐/建议的做法可能会更好，例如使用包含类似内容的文件的项目。
  -- 在文件上更广泛地使用多个扩展名的一个重要原因是文件资源管理器（或任何列出文件系统内容的东西——包括操作系统提供的选择器和对话框）在它们（配置为 - 这是默认值）隐藏已知的文件扩展名。 这会使MyClass.winui.xaml看起来像MyClass.winui ，这会导致关于文件是什么、来自哪里、为什么显示等问题和混淆。
  -- 添加多个/子扩展名会增加文件长度，从而增加遇到 MAXPATH 相关问题的机会。 也许有一天这不会成为问题，但我们还没有。 我不希望看到开发人员被迫给他们的文件（和类，因为两者通常保持同步）提供较少描述性的名称，因为该工具现在需要额外的六个字符作为扩展名。

• 它为工具开发人员创造了更多的工作。 （Microsoft 内部和外部。）
  -- 处理更多案件。
  -- 更多需要记录和测试的场景。
  - 更少的时间花在错误修复和新功能上。 由于当前的 XAML 工具被认为缺乏其他技术并且创建自定义工具的速度很慢，为什么要做任何使构建新工具变慢的事情呢？

• 它有可能开创一个非常糟糕的先例。
  -- 如果发生这种情况，为什么不适合用.wpf 、 .uwp 、 .xamarinforms等替换所有当前的 .xaml 文件？ 或者.xaml2006 , .xaml20009 , .xaml-uwp5如果底层命名空间，而不是它们的使用位置是关键问题？ 将有一个最小的潜在好处（在这种情况下），但它会被许多人视为 Microsoft 建议命名文件的方式。 （如果有人在看到这里的讨论时没有提出这样的建议，我不会感到惊讶。）
  - 我不知道（但很高兴得到纠正）任何 MS 提供的工具根据子扩展以不同的方式处理文件，但这样做可能会迫使 Visual Studio（和其他？，包括 Windows Shell？）需要能够处理这些场景。 然后，一旦有能力，我可以想象引入各种复杂但不必要的命名建议的诱惑，对一些开发人员来说太多了，导致我们其他人感到困惑。

总而言之，该提案会在有限的情况下带来混乱和更多的理论上的好处。 如果你这样做，我会放弃 Windows 开发。

感谢大家发出你的声音。 我们听到了！ 我们收集了足够多的反馈，因此我们可以肯定地说，更改 .xaml 扩展名是不可行的。

我们无意破坏生态系统或破坏第 3 方工具（而​​且有很多）。 我们同意 XAML 是语言，WinUI 3 是使用 XAML 的 UI 框架。 由于所有这些原因以及其他原因，继续使用 xaml 扩展是有意义的。

我们的团队仍然需要做一些功课并评估其他替代方案，我们应该稍后与社区协商。 例如：

1. 没做什么。 XAML Islands 的开发体验将是：不同项目中的 XAML 文件（也许这没什么大不了的）。 WInUI 3 将使用相同的命名空间，这并不重要，因为它将是项目中使用的唯一 XAML 语言。

2. 使用命名空间来区分基于 XAML 的 UI。 今天，WPF XAML 和 UWP XAML 使用相同的命名空间，也许 WinUI 3 应该使用不同的命名空间，就像 Xamarin Forms 正在做的那样（“http://xamarin.com/schemas/2014/forms”），所以编译器、工具和设计器可以区分文件。 另一方面，这将创造方言，尽管今天正在发生这种情况。 理论上，这将有助于开发人员从文档/博客中复制和粘贴 XAML 示例，尽管不幸的是，有很多示例不包含命名空间。

3. 做点什么，但只是为了岛屿。 无需区分所有 UI 框架。 我们可以使用约定。 例如，将来，带有 XAML Island 的 WPF 应用程序可以在特定文件夹（islands 文件夹？）中包含 XAML 文件。 这类似于 UWP 本地化 (Strings/en-US/Resources.resw)。

再次感谢您的反馈。 当我们有更多的想法成熟时，我会开启新的讨论。

为 island 文件包含一个 snippit 或 doctype 样式行，对于工具来说应该足够了。

如果喜欢.ui.xaml的想法，因为它是一个很好的折衷方案。 它仍然是一个有效的 XAML 扩展，还可以帮助选择正确的编辑器和图标。 它也比打开和解析数十/数百个 XAML 文件只是为了找到一个类型更有效。

@marb2000 WinUI 3 是一个使用 XAML 的 UI 框架

应该是：WinUI 3 是一个可以使用 XAML 的 UI 框架。 因为它不需要使用 XAML，也不需要对 XAML 语言的依赖。

我们同意 XAML 是语言

这很好，许多称为 XAML 的命名空间需要在 WinUI 中重命名：任何与 XAML 语言无关的东西。

对 UWP 的淡化是令人痛苦的见证。 现在，当您在频道 9 上搜索 UWP 内容时，您将获得 Xamarin 内容。 这是一个很明显的伎俩。 请停止尝试将 UWP 变形为其他东西！ 重新投资，加倍下注，让它发挥作用。 UWP 不需要课程修正，它需要 Xamarin 和 Office 团队加入。 微软内部政治正在扼杀 UWP。

@Noemata这是官方说明吗？