.NET Core中Path.TryJoin优于Path.Combine的优点是什么? [英] What is the advantage of Path.TryJoin over Path.Combine in .NET Core?

问题描述

我刚刚开始使用.NET Core 2.1，并且发现

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.

除了利用新的C#之外，还有其他好处吗?

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

推荐答案

您可以找到被介绍的Path.Join背后的原理此处.恕我直言，这似乎是为了性能和一些较小的修正而简化交易，也找不到任何迹象表明Join创建了具有正确分隔符的跨平台有效路径，如Path.Combine那样，但从所有角度来说都是应该的.

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.

为了详细讨论，Path.Join解决的主要怪癖是最后一个有争议的论点，很多人不希望这样做(它虽然很小，但显然不是)在 C#或.NET页面中最糟糕的陷阱上的示例中可以看到.

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.

讨论中的总体思路是逐渐弃用Combine，而推荐使用Join.

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

还请注意，Path.Join已为此 PR 添加了字符串重载.

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

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