Why does my .NET Framework 4.8 app support long paths without a manifest on Windows Server 2016?

Question

I'm working on a .NET Framework 4.8 application deployed on Windows Server 2016. According to Microsoft's documentation, to enable long path support, one must set the LongPathsEnabled registry key and include the longPathAware element in the application's manifest. However, in my case, long paths (exceeding 260 characters) are functioning correctly without adding the longPathAware element to the manifest, the only thing I've done is setting the ​LongPathsEnabled registry value to 1.

Why is my .NET Framework 4.8 application supporting long file paths without the app manifest? I can't find anything on Microsoft's website to explain this behaviour, does anyone know where to look or why? I know that for .NET CORE applications, the app manifest is no longer needed, I'm just confused as to why this is also happening on .NET Framework 4.8 despite the official documentation stating otherwise.

What I've done:

• Set the LongPathsEnabled registry key to 1.​
• Did not create the application manifest.
• Utilized System.IO classes to handle file operations.​
• Confirmed that the application targets .NET Framework 4.8.​

Observed Behavior:

Despite not including the longPathAware element in the manifest, the .NET Framework 4.8 application handles long paths without throwing PathTooLongException.​

Questions:

1. Is there an explanation for why long path support is working without the manifest?​

2. Are there specific conditions or updates in .NET Framework 4.8 or Windows Server 2016 that allow this behavior?​

Any insights or experiences regarding this behavior would be greatly appreciated, thank you!

Answer 1

You need to confirm whether your long paths refer to C:\very-long-path or \\?\C:\very-long-path.

If longPathAware is not set in the manifest file, the former long path will still encounter errors in .net framework applications, but the PathTooLongException exception may not be thrown unless Switch.System.IO.BlockLongPaths=true is set^*. The latter long path only requires API support.

Also, please note that not all IO methods involve the long path problem, e.g. Path.GetFileName is just string manipulation.

* some tests without app.manifest and app.config

// throw DirectoryNotFoundException, the first level of directory created
Directory.CreateDirectory(@$"{new string('x', 128)}\{new string('y', 128)}\{new string('z', 128)}");

// throw PathTooLongException, no directory created
Directory.CreateDirectory($@"{new string('x', 200)}\{new string('y', 185)}");