在 .NET Core 中，Path.TryJoin 与 Path.Combine 相比有什么优势? [英] What is the advantage of Path.TryJoin over Path.Combine in .NET Core?

问题描述

我刚开始使用 .NET Core 2.1，发现了 Path.TryJoin 和 Path.Join 方法.没有关于该方法的文档.

我运行了一些调用该方法的单元测试，它与 Path.Combine.

除了使用新的 C# 之外还有什么优势吗 Span 数据类型以最小化字符串操作执行?

解决方案

您可以找到引入 Path.Join 背后的基本原理 此处.恕我直言，它似乎是为了性能和一些小修复而交易简单性，也找不到任何迹象表明 Join 创建了具有正确分隔符的跨平台有效路径，例如 Path.Combine 确实如此，但所有帐户都是应该.

为了详细说明讨论，Path.Join 解决的主要怪癖是最后一个根深蒂固的论点，很多人不希望以它的方式工作(这看似次要但很明显不是)，正如在 C# 或 .NET 页面中最糟糕的问题上的示例中所见.>

讨论的总体思路是慢慢弃用 Combine 而支持 Join.

另请注意，使用此 Path.Join 添加了字符串重载>公关

I just started using .NET Core 2.1, and found the Path.TryJoin and Path.Join method. There is no documentation on the method.

I ran some unit tests calling the method, and it did nothing different than Path.Combine.

Is there any advantage to this other than utilizing the new C# Span<T> data type to minimize string manipulation execution?

解决方案

You can find the rationale behind the Path.Join being introduced here. IMHO it seems to be trading simplicity for performance and some minor fixes, also couldn't find any indication that Join creates cross-platform valid paths with the correct separators like Path.Combine does but by all accounts is should.

To elaborate on the discussion, the main quirk that Path.Join resolves is the last rooted argument which a lot of people don't expect to work the way it does (which seamed minor but clearly is not), as can be seen in the examples here on the the worst gotcha in C# or .NET page.

The general idea from the discussion is to slowly deprecate Combine in favor of Join.

Also note string overloads have been added for the Path.Join with this PR

这篇关于在 .NET Core 中，Path.TryJoin 与 Path.Combine 相比有什么优势?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！