.NET 3.5 不完全支持 XPATH 2.0 或 XSLT 2.0，这太糟糕了。有谁知道这两个是否会在未来的任何 .NET 版本中包含并完全支持？
【问题讨论】：
我认为他们不会很快添加对 XPath 2.0 或 XSLT 2.0 的支持。
但是，如果这些不是 BCL 的一部分，您应该不会感到难过，只要您有可用的 3rd 方实现：
Microsoft 以客户为导向。如果客户不想要，他们就不会成功。
2009-11-18：我联系了 XML 团队 here 并得到了回复：
虽然 XML 仍然是关键部分 在我们平台的未来发展中，我们有 决定不追求 XSLT 2.0 此时执行。如果有 是您正在尝试的特定 XSLT 任务 完成并且正在拥有 XSLT 1.0 的困难，请让 我们知道，我们会尽力提供帮助。
此列表现在维护在github.com/maxtoroq/dotnet-xml
【讨论】：
看到这个blog post
我们有几个原因 没有实现 XSLT 2.0 和 XPath 2.0
这需要大量的精力和资源 实施所有 3 项技术 （XQuery、XSLT 2.0 和 XPath 2.0）。我们的 指导原则是我们相信 创建 XML 查询的扩散 技术令人困惑 用户。我们宁愿再实施一个 我们推动人们学习的语言 比必须支持和解释三个 更多 XML 查询和转换 语言，除了 XPath 1.0 和 XSLT 1.0 中已经存在 .NET 框架。拥有我们的客户 和支持人们必须应对 3 复杂 XML 的复杂性 查询语言，其中两种是look 相似但行为完全不同 对于 XPath 2.0 和 XQuery 在我们看来并非如此 有益的。
【讨论】：
XslCompiledTransform 使用XPathNavigator 表示节点，而后者完全实现了XDM，因此您实际上可以将所有XPath2 功能（如运算符<< 和>>）作为自定义函数实现。
我的理解是，许多 Microsoft XML 资源从 XSLT 2.0 转移到 LINQ to XML，在我看来，这根本无法解决与 XSLT 相同的问题。
LINQ to XSD 应该增强 LINQ to XML（以及 XML Schema 的好处，语法不那么难看），但这是微软不久前在 CodePlex 上开源的，似乎没有社区支持。
此外，如果没有将 XSLT 2.0 编辑器和调试器集成到 Visual Studio 中，Microsoft 不太可能推出新的 XSLT 2.0 处理器，因此需要相当多的努力/时间来扭转他们的“不采用”决定。 [更新] 现在有一个XSLT 3.0 extension for Microsoft VSCode（由我自己管理），它与 Saxon 的 3.0 XSLT 处理器集成。
因此，我们选择了 Saxon.NET，它在标准合规方面享有无可挑剔的声誉，并为 .NET 提供了出色的可扩展性选项。
【讨论】：
Microsoft 没有计划在 .NET 中发布对 XPath/XSLT 2.0 的支持。
XQSharp 提供 XPath 2.0、XSLT 2.0 和 XQuery for .NET 的第 3 方实现。
[编辑：XQSharp 2.0 beta（带有 XSLT 2.0）已经发布]
【讨论】：
我不敢相信它们不会处于某个阶段，因为它们是 W3C 的核心技术。但是我找不到任何当前对这些的引用（只有很久以前发布的信息）。
在不久的将来，您应该看看Saxon，它支持您需要的 Xpath/XSLT 版本。
【讨论】：