ERROR: PATH TOO LONG. Everyone who creates applications that deal with folders and paths eventually comes across this annoying error. And so did our team.

In our search for ways to prevent this error from happening again, we came across two possible solutions. We will gladly share them with you in this blog post.

Solution 1: Windows registry key + app.manifest

The first solution to enable long path support requires changes to the Windows registry key and the application manifest.

On docs.microsoft.com you can find a detailed article on “Maximum Path Length Limitation” and how to enable long paths with the Windows registry key and the application manifest.

Unfortunately, not every application has this support enabled. For such applications, like the FileStream constructor for instance, and for systems that don’t have a registry key, the below NuGet solution may help.

It’s also worth noting that not every Windows Server version has access to the registry key. As far as we can tell, only Windows Server 2016 and newer have access.

Solution 2: NuGet – AlphaFS.New (also supports .NetStandard)

If the first solution isn’t working for you, you might want to try using NuGet to enable long path support.

For this method to work, you should use AlphaFS. AlphaFS is a .NET library aiming to provide a more complete Win32 file system functionality to the .NET platform than the standard System.IO classes. It contains a wide array of commonly used System.IO classes (File, FileInfo, Directory, DirectoryInfo, Path, etc.), allowing you to simply replace the System.IO namespace with the one from NuGet.

Here’s an overview of some scenarios that can be covered with the NuGet solution:

System.Reflection.Assembly

// No long path support & locks the file
assembly = Assembly.LoadFile(filePath);

/*
 * Long path support & does not lock the file
 * In some very specific case DLLs loaded from bytes might not work properly.
 * The known example is the Microsoft.Exchange.WebServices DLL. 
 * This is a technical limitation and cannot be fixed. 
 */
assembly = Assembly.Load(File.ReadAllBytes(filePath));

System.IO.FileStream

// No long path support
using (System.IO.FileStream stream = new System.IO.FileStream(filePath, System.IO.FileMode.Open))
{



}

// Long path support
using (System.IO.FileStream fileStream = Alphaleonis.Win32.Filesystem.File.Open(filePath, System.IO.FileMode.Open))
{



}

Extra arguments like FileAccess & FileShare can be used in the same way for both options.

System.Xml.Linq

// No long path support
xdocument = XDocument.Load(filePath);


// Long path support - Read out the file contents 
string content = Alphaleonis.Win32.Filesystem.File.ReadAllText(filePath);
xdocument = XDocument.Parse(content);

// Long path support - Use the stream to load the XDocument
using (System.IO.FileStream fileStream = Alphaleonis.Win32.Filesystem.File.OpenRead(filePath))
{

    xdocument = XDocument.Load(fileStream)

}

Summary

We recommend that you try the “registry key + app.manifest” solution first because the NuGet solution has a small performance impact. However, if that solution doesn’t work for you, your best bet is to try the NuGet solution.

Do note that other NuGets or DLLs don’t necessarily have long path support enabled. In those scenarios, you should check whether there’s a “Stream object” you can pass on. (See “System.Xml.Linq. Long path support – Use the stream to load the XDocument”)