Using long paths (>260) with .net 4.6.2 in Windows service

Question

I have some code that has begun to throw the exception: TooLongPathException. So I did some research and found out that .net 4.6.2 solves this problem. Great!

The code that fails is code that moves and copies folders to different folders. I would like to use .net 4.6.2 framework to enable this code to use longer paths so I do not need to code some workaround.

I have installed .net 4.6.2 framework on the machine. The machine runs Windows server 2008 R2 SP1. I have made the project target 4.6.2 framwork but still it throws this error.

I am not sure what I am missing here.

Has anyone used .net 4.6.2 for a similar thing that can point me as to what I need to do?

@user1666620 Probably from https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/ — GSerg, Nov 04 '16 at 12:36
Did you configure your app to use the fix 4.6.2 uses? https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/ - i am guessing not? — Darren Wainwright, Nov 04 '16 at 12:36
@GSerg thanks for the link. Instructions are contained in there. — user1666620, Nov 04 '16 at 12:36
Maybe you are really hitting the Windows limit? Then nothing will help you :) — Ilya Chernomordik, Nov 04 '16 at 12:38
@GSerg Exactly that blog and the MSDN blog here: https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/#bcl — Sigmundur, Nov 04 '16 at 12:49
@Darren My application project targets 4.6.2. Here is the app.config: — Sigmundur, Nov 04 '16 at 12:57
Even if your software finds a way to cope with long paths, make sure not to create situations that makes others trip. Creating long paths is not the solution but the problem. — TaW, Nov 04 '16 at 13:27
@TaW This is very isolated code and it is out of my hands to shorten the paths as the customer is the one creating the paths. This tends to be several nested folders with long path names and a very long file name at the end. — Sigmundur, Nov 04 '16 at 13:33
@Sigmundur sometimes you just have to bite the bullet and tell the customer that due to limitations in the technology (or better, to abide by the supported terms of use) they need to stop with the stupidly-long file paths. — user1666620, Nov 04 '16 at 13:37
@user1666620 Yes. But I do not want to do that and Microsoft has released a .net framework that specifically, and explicitly, targets this issue. Even if I would tell the customer to stop being stupid I would still like to get this working. It should be as simple as targeting framework 4.6.2. Can someone create a console app that targets framework 6.4.2 and try to create paths that are longer than 260 characters? — Sigmundur, Nov 04 '16 at 14:00
i have the same issue, i think that we need to set in the GPO "win32 long paths" to enabled. Unfortunatly this thing isnt in the GPO of Windows Server (2012 r2 in my case) to switch it on. So we have maybe to wait for Windows Server 2016 or something??? It worked fine on my Windows10 Developer machine. — grunge, Nov 16 '16 at 11:43

score 0 · Answer 1 · answered Nov 16 '16 at 15:16

After a zillion of Tests I can confirm that this works with .Net 4.6.2 on a Windows10, but fails on a Server 2012r2.

When i want to delete a long folder that i created with Windows10 on a share, the Server is failing to delete it. My workaround is the old fashioned Robocopy.

public static void DirectoryDeleteRobocopy(string a_strPath)
    {
        _log.Debug("DirectoryDeleteRobocopy called: " + a_strPath);
        string strTmpDir = System.Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);
        var emptyDirectory = new DirectoryInfo(strTmpDir + "\\TempEmptyDir_" + Guid.NewGuid());
        try
        {
            emptyDirectory.Create();
            using (var process = new Process())
            {
                process.StartInfo.FileName = "robocopy.exe";
                process.StartInfo.Arguments = "\"" + emptyDirectory.FullName + "\" \"" + a_strPath + "\" /e /purge";
                process.StartInfo.UseShellExecute = false;
                process.StartInfo.CreateNoWindow = true;
                process.Start();
                process.WaitForExit();
            }
            emptyDirectory.Delete();
            new DirectoryInfo(a_strPath).Attributes = FileAttributes.Normal;
            Directory.Delete(a_strPath);
        }
        catch (IOException) { }
    }

I think that Microsoft should make "Enable Win32 long paths" policy available to Server 2012 (and maybe even 2008) a soon as possible. Sorry, but right now this looks bad.

I appreciate the time you took to make the tests but I can not accept this as the accepted solution since this is just a work around. I have implemented a work around using a third party library called AlphaFS which has solved the problem for me and is problably a bit nicer than starting a seperate process but that is a subjective matter. The reason I have not written an answer to my own question is the same reason for why I will not pick your answer as the correct one. Thanks for the effort though. — Sigmundur, Nov 17 '16 at 14:07

Using long paths (>260) with .net 4.6.2 in Windows service

1 Answers1