如何避免System.IO.PathTooLongException？

我们经常遇到这个问题......

例:

如果我有一个文件,我想将它复制到另一个目录或UNC共享,如果路径的长度超过248(如果我没有记错),那么它会抛出PathTooLongException.这个问题有解决方法吗？

PS:是否有任何注册表设置将此路径设置为更长的字符集？

1> Mark Hurd..：

---

正如Jeremy Kuhne的博客中所描述的,.NET Framework 4.6.2MAX_PATH在可能的情况下消除了限制,而没有破坏向后兼容性.

---

您的说法并不完全正确。新的.NET框架不会删除限制...但是它们确实提供了一种消除限制的受支持方法。默认情况下，仅使用最新框架不会将其删除。您必须在Windows中启用长路径支持（通过更改注册表或更改组策略）。然后，您必须将适当的代码添加到应用程序中的App.config文件中，以使应用程序支持长路径。Jeremy Kuhne博客的链接提供了有关这些内容的更多详细信息。我非常感谢您的回答，因为它为我指出了解决方案。

2> Elshan..：

---

试试这个:Delimon.Win32.I O Library(V4.0) 这个Libarary是在.NET Framework 4.0上编写的

Delimon.Win32.IO取代了System.IO的基本文件功能,并支持最多32,767个字符的文件和文件夹名称.

https://gallery.technet.microsoft.com/DelimonWin32IO-Library-V40-7ff6b16c

此库是专门为克服.NET Framework限制使用长路径和文件名而编写的.使用此库,您可以以编程方式浏览,访问,写入,删除等System.IO namespace.Library无法访问的文件和文件夹.

用法

首先将Delimon.Win32.IO.dll的引用添加到您的项目中(浏览到Delimon.Win32.IO.dll文件)

在您的代码文件中添加"使用Delimon.Win32.IO"

使用普通的文件和目录对象,就像使用System.IO一样

---

这是一个很棒的图书馆,感谢分享.你应该把它放在NuGet上.

---

这个库很棒,但是为什么Microsoft不为文件系统实际可以处理的任何东西提供原生支持？

3> ShuggyCoUk..：

---

BCL团队已对此进行了深入讨论,请参阅博客文章

本质上,没有办法在.Net代码中执行此操作并坚持使用BCL.太多的函数依赖于能够规范化路径名(它会立即触发使用期望遵循MAX_PATH的函数).

你可以包装所有支持"\\？\"语法的win32函数,这些函数你可以实现一套长路径感知功能,但这很麻烦.

由于大量工具(包括explorer [1])无法处理长路径名称,因此除非您对与生成的文件系统的所有交互都通过您的库(或者有限数量的工具)感到高兴,否则不宜走这条路线.像robocopy一样处理它

为了满足您的特定需求,我将调查直接使用robocopy是否足以执行此任务.

[1] Vista有一些方法可以通过引擎盖下的一些花哨重命名来缓解这个问题,但这最好是脆弱的)