The .NET framework has a significant limitation when it comes to accessing files. All the classes, methods and properties in the System.IO namespace that manipulates file and folder names are limited to so-called system-defined maximum lengths. From the .NET documentation:
The specified path, file name, or both exceed the system-defined maximum length. For example, on Windows-based platforms, paths must be less than 248 characters, and file names must be less than 260 characters.
This limitation does not cause problems in most situations. But on Windows systems, if there is a need to access a files whose name or path is longer than the .NET limit, a %System.IO.PathTooLongException% will be thrown.
To counter this, Xceed FileSystem implements the WindowsDiskFile and WindowsDiskFolder classes. The classes work in the exact same way as DiskFile and DiskFolder but internally, they do not use the .NET framework to access the file or folder they represent. Instead, they make direct, native calls to the Windows API. For example, to open a file for reading, WindowsDiskFile will call the CreateFile() function of the Windows API. The path limit under Windows is much larger than the .NET framework. It stands at 32,767 characters.
The WindowsDiskFile and WindowsDiskFolder classes are located in the Xceed.FileSystem.Windows assembly. To use the classes, the Xceed.FileSystem.Windows.dll file needs to be added as a reference in your application project.
Because the functionality requires calling Windows directly, using the Xceed.FileSystem.Windows assembly requires the "full trust" permission level and will only work on Windows systems.
The Xceed.FileSystem.Windows assembly is entirely optional. No Xceed assembly directly references it so existing application will continue to behave as they did before.
The WindowsDiskFile and WindowsDiskFolder classes are located in the Xceed.FileSystem.Windows namespace. The namespace must be added to your code.
A path is considered long when it more than 248 characters in length. A file name is considered long when it is more than 260 characters in length.
Usage of WindowsDiskFile and WindowsDiskFolder is not restricted to long paths, you can use the classes on normal paths as you would with DiskFile and DiskFolder.
Because both set of classes derive from AbstractFile/AbstractFolder, they can be used together so that WindowsDiskFile/WindowsDiskFolder are only used in specific cases where access to a long file or folder is needed.
A classic problem situation is dealing with zip archives. Zip archives can contain items with long names. Unzipping such an item into a DiskFolder would make the .NET framework throw a %System.IO.PathTooLongException%. By unzipping into a WindowsDiskFolder, items with long names will be unzipped into WindowsDiskFile objects that can handle the name.
Another classic problem is zipping from a disk that contains files with long names or a folder structure that amounts to a long path. Using DiskFolder, an exception is thrown when an item that cannot be handled is encountered. Using WindowsDiskFile and WindowsDiskFolder objects as sources, the files can be handled properly.
If you have existing code which use DiskFile and DiskFolder that you do not wish to modify but would like to benefit from long path support, you can instruct DiskFile and DiskFolder to automatically use WindowsDiskFile and WindowsDiskFolder internally. This way, they will support long paths the same way.
The feature is enabled by a global property DiskFile.DefaultIOHandler. It will affect all DiskFile and DiskFolder objects that will be created after the property is set. Existing objects will continue to behave the same. To avoid confusion, it is advisable to set the property before you start creating DiskFile and DiskFolder objects.