这个答案基于:https://stackoverflow.com/a/1703799/184528。与我的代码不同的是，我们只递归许多删除子目录和文件时，需要调用目录。第一次尝试删除失败(这可能是因为windows资源管理器查看目录)。

    public static void DeleteDirectory(string dir, bool secondAttempt = false)
    {
        // If this is a second try, we are going to manually 
        // delete the files and sub-directories. 
        if (secondAttempt)
        {
            // Interrupt the current thread to allow Explorer time to release a directory handle
            Thread.Sleep(0);

            // Delete any files in the directory 
            foreach (var f in Directory.GetFiles(dir, "*.*", SearchOption.TopDirectoryOnly))
                File.Delete(f);

            // Try manually recursing and deleting sub-directories 
            foreach (var d in Directory.GetDirectories(dir))
                DeleteDirectory(d);

            // Now we try to delete the current directory
            Directory.Delete(dir, false);
            return;
        }

        try
        {
            // First attempt: use the standard MSDN approach.
            // This will throw an exception a directory is open in explorer
            Directory.Delete(dir, true);
        }
        catch (IOException)
        {
            // Try again to delete the directory manually recursing. 
            DeleteDirectory(dir, true);
        }
        catch (UnauthorizedAccessException)
        {
            // Try again to delete the directory manually recursing. 
            DeleteDirectory(dir, true);
        } 
    }

在Windows上，当目录(或任何子目录)中的文件路径长度大于260个符号时，就会出现此问题。

在这种情况下，您需要删除\\\\?\C:\mydir而不是C:\mydir。 大约260个符号的限制，你可以在这里阅读。

我在特尔斐也遇到过同样的问题。最终的结果是我自己的应用程序锁定了我想要删除的目录。不知何故，当我写入目录(一些临时文件)时，目录被锁定了。

问题在于，在删除它之前，我对它的父目录做了一个简单的更改。

在Windows资源管理器中选择路径或子文件夹似乎足以阻止目录的一次执行。Delete(path, true)，抛出如上所述的IOException和死亡，而不是引导Windows资源管理器到父文件夹并按预期进行。

不删除文件的递归目录删除当然是意外的。我的解决办法是:

public class IOUtils
{
    public static void DeleteDirectory(string directory)
    {
        Directory.GetFiles(directory, "*", SearchOption.AllDirectories).ForEach(File.Delete);
        Directory.Delete(directory, true);
    }
}

我经历过这样做有帮助的案例，但一般来说，Directory。Delete在递归删除时删除目录中的文件，如msdn中所述。

作为Windows资源管理器的用户，我偶尔也会遇到这种不正常的行为:有时我无法删除文件夹(它认为荒谬的消息是“拒绝访问”)，但当我向下钻取并删除较低的项目时，我也可以删除上面的项目。所以我猜上面的代码处理的是操作系统异常——而不是基类库问题。

在继续之前，检查一下你能控制的以下原因:

该文件夹是否设置为您的进程的当前目录?如果是，请先将其更改为其他内容。 您是否从该文件夹中打开了文件(或加载了DLL) ?(并且忘记关闭/卸载它)

否则，请检查以下不在你控制范围内的合理原因:

该文件夹中有标记为只读的文件。 您没有删除其中一些文件的权限。 文件或子文件夹在资源管理器或其他应用程序中打开。

如果是上述任何一个问题，在尝试改进删除代码之前，您应该了解为什么会发生这种情况。你的应用程序是否应该删除只读或不可访问的文件?是谁给它们做的标记，为什么?

一旦排除了上述原因，仍然存在虚假失败的可能性。如果任何人持有任何被删除的文件或文件夹的句柄，删除将失败，并且有人可能会枚举文件夹或读取其文件的原因有很多:

搜索索引器 要 备份软件

处理虚假失败的一般方法是尝试多次，在尝试之间暂停。显然，您不希望一直尝试下去，因此应该在一定次数的尝试后放弃，并抛出异常或忽略错误。是这样的:

private static void DeleteRecursivelyWithMagicDust(string destinationDir) {
    const int magicDust = 10;
    for (var gnomes = 1; gnomes <= magicDust; gnomes++) {
        try {
            Directory.Delete(destinationDir, true);
        } catch (DirectoryNotFoundException) {
            return;  // good!
        } catch (IOException) { // System.IO.IOException: The directory is not empty
            System.Diagnostics.Debug.WriteLine("Gnomes prevent deletion of {0}! Applying magic dust, attempt #{1}.", destinationDir, gnomes);

            // see http://stackoverflow.com/questions/329355/cannot-delete-directory-with-directory-deletepath-true for more magic
            Thread.Sleep(50);
            continue;
        }
        return;
    }
    // depending on your use case, consider throwing an exception here
}

在我看来，像这样的帮助器应该用于所有的删除，因为虚假的失败总是可能的。然而，你应该根据你的用例调整这些代码，而不是盲目地复制它。

我的应用程序生成的内部数据文件夹，位于%LocalAppData%下，所以我的分析如下:

The folder is controlled solely by my application, and the user has no valid reason to go and mark things as read-only or inaccessible inside that folder, so I don't try to handle that case. There's no valuable user-created stuff in there, so there's no risk of forcefully deleting something by mistake. Being an internal data folder, I don't expect it to be open in explorer, at least I don't feel the need to specifically handle the case (i.e. I'm fine handling that case via support). If all attempts fail, I choose to ignore the error. Worst case, the app fails to unpack some newer resources, crashes and prompts the user to contact support, which is acceptable to me as long as it does not happen often. Or, if the app does not crash, it will leave some old data behind, which again is acceptable to me. I choose to limit retries to 500ms (50 * 10). This is an arbitrary threshold which works in practice; I wanted the threshold to be short enough so that users wouldn't kill the app, thinking that it has stopped responding. On the other hand, half a second is plenty of time for the offender to finish processing my folder. Judging from other SO answers which sometimes find even Sleep(0) to be acceptable, very few users will ever experience more than a single retry. I retry every 50ms, which is another arbitrary number. I feel that if a file is being processed (indexed, checked) when I try to delete it, 50ms is about the right time to expect the processing to be completed in my case. Also, 50ms is small enough to not result in a noticeable slowdown; again, Sleep(0) seems to be enough in many cases, so we don't want to delay too much. The code retries on any IO exceptions. I don't normally expect any exceptions accessing %LocalAppData%, so I chose simplicity and accepted the risk of a 500ms delay in case a legitimate exception happens. I also didn't want to figure out a way to detect the exact exception that I want to retry on.