У меня была такая же проблема под Delphi. В результате мое собственное приложение блокировало каталог, который я хотел удалить. Каким-то образом каталог был заблокирован, когда я писал в него (некоторые временные файлы).

Уловка 22 заключалась в том, что я сделал простой сменить каталог для его родительского элемента перед его удалением.

Возможно ли, что у вас есть состояние гонки, когда другой поток или процесс добавляет файлы в каталог:

Последовательность будет такой:

Процесс удаления A:

1. Очистить каталог
2. Удалите (теперь пустой) каталог.

Если кто-то еще добавит файл между 1 и 2, то, возможно, 2 вызовет указанное исключение?

Каталог или файл в нем заблокированы и не могут быть удалены. Найдите виновника, который его блокирует, и посмотрите, сможете ли вы его устранить.

Примечание редактора: Хотя этот ответ содержит некоторую полезную информацию, на самом деле он неверен относительно работы Directory.Delete. Пожалуйста, прочтите комментарии к этому ответу и другие ответы на этот вопрос.

Я сталкивался с этой проблемой раньше.

Корень проблемы в том, что эта функция не удаляет файлы, находящиеся в структуре каталогов. Итак, что вам нужно сделать, это создать функцию, которая удаляет все файлы в структуре каталогов, а затем все каталоги перед удалением самого каталога. Я знаю, что это противоречит второму параметру, но это гораздо более безопасный подход. Кроме того, вы, вероятно, захотите удалить атрибуты доступа ТОЛЬКО ДЛЯ ЧТЕНИЯ из файлов прямо перед их удалением. В противном случае это вызовет исключение.

Просто вставьте этот код в свой проект.

public static void DeleteDirectory(string target_dir)
{
    string[] files = Directory.GetFiles(target_dir);
    string[] dirs = Directory.GetDirectories(target_dir);

    foreach (string file in files)
    {
        File.SetAttributes(file, FileAttributes.Normal);
        File.Delete(file);
    }

    foreach (string dir in dirs)
    {
        DeleteDirectory(dir);
    }

    Directory.Delete(target_dir, false);
}

Кроме того, я лично добавляю ограничение на области машины, которые разрешено удалять, потому что вы хотите, чтобы кто-то вызвал эту функцию на C:\WINDOWS (%WinDir%) или C:\.

Если текущий каталог вашего приложения (или любого другого приложения) - это тот, который вы пытаетесь удалить, это не будет ошибкой нарушения прав доступа, но каталог не будет пустым. Убедитесь, что это не ваше собственное приложение, изменив текущий каталог; также убедитесь, что каталог не открыт в какой-либо другой программе (например, Word, excel, Total Commander и т. д.). Большинство программ будут переходить в каталог с последним открытым файлом, что могло бы вызвать это.

У меня были эти странные проблемы с разрешениями при удалении каталогов профиля пользователя (в C: \ Documents and Settings), несмотря на то, что я мог сделать это в оболочке Explorer.

File.SetAttributes(target_dir, FileAttributes.Normal);
Directory.Delete(target_dir, false);

Для меня не имеет смысла, что делает с каталогом «файловая» операция, но я знаю, что она работает, и мне этого достаточно!

Если вы пытаетесь рекурсивно удалить каталог a и каталог a\b открыт в проводнике, b будет удален, но вы получите сообщение об ошибке «каталог не пуст» для a, даже если он пуст, когда вы пойдете и посмотрите. Текущий каталог любого приложения (включая проводник) сохраняет дескриптор каталога. Когда вы вызываете Directory.Delete(true), он удаляет снизу вверх: b, затем a. Если b открыт в проводнике, проводник обнаружит удаление b, сменит каталог вверх cd .. и очистит открытые дескрипторы. Поскольку файловая система работает асинхронно, операция Directory.Delete завершается ошибкой из-за конфликтов с проводником.

Неполное решение

Первоначально я опубликовал следующее решение с идеей прерывания текущего потока, чтобы дать обозревателю время освободить дескриптор каталога.

// incomplete!
try
{
    Directory.Delete(path, true);
}
catch (IOException)
{
    Thread.Sleep(0);
    Directory.Delete(path, true);
}

Но это работает, только если открытый каталог является дочерним немедленный каталога, который вы удаляете. Если a\b\c\d открыт в проводнике и вы используете его на a, этот метод не сработает после удаления d и c.

Несколько лучшее решение

Этот метод будет обрабатывать удаление глубокой структуры каталогов, даже если один из каталогов нижнего уровня открыт в проводнике.

/// <summary>
/// Depth-first recursive delete, with handling for descendant 
/// directories open in Windows Explorer.
/// </summary>
public static void DeleteDirectory(string path)
{
    foreach (string directory in Directory.GetDirectories(path))
    {
        DeleteDirectory(directory);
    }

    try
    {
        Directory.Delete(path, true);
    }
    catch (IOException) 
    {
        Directory.Delete(path, true);
    }
    catch (UnauthorizedAccessException)
    {
        Directory.Delete(path, true);
    }
}

Несмотря на дополнительную работу по рекурсии, нам, по-прежнему, приходится обрабатывать UnauthorizedAccessException, которые могут возникнуть в процессе. Неясно, прокладывает ли первая попытка удаления путь второй, успешной, или это просто временная задержка, вызванная выбросом / перехватом исключения, которое позволяет файловой системе наверстать упущенное.

Вы можете уменьшить количество генерируемых и перехватываемых исключений в типичных условиях, добавив Thread.Sleep(0) в начало блока try. Кроме того, существует риск того, что при большой загрузке системы вы можете выполнить обе попытки Directory.Delete и потерпеть неудачу. Считайте это решение отправной точкой для более надежного рекурсивного удаления.

Общий ответ

Это решение затрагивает только особенности взаимодействия с проводником Windows. Если вам нужна надежная операция удаления, помните, что что угодно (сканер вирусов, что угодно) может иметь открытый дескриптор того, что вы пытаетесь удалить, в любое время. Так что вам придется повторить попытку позже. Сколько позже и сколько раз вы будете пытаться, зависит от того, насколько важно удалить объект. Как MSDN указывает,

Robust file iteration code must take into account many complexities of the file system.

Это невинное заявление, снабженное лишь ссылкой на справочную документацию NTFS, должно заставить вас всколыхнуться.

(Редактировать: Много. Изначально у этого ответа было только первое неполное решение.)

Похоже, что наличия пути или подпапки, выбранной в проводнике Windows, достаточно, чтобы заблокировать однократное выполнение Directory.Delete (path, true), выбросить исключение IOException, как описано выше, и умереть вместо того, чтобы загружать проводник Windows в родительскую папку и действовать как ожидал.

в случае сетевых файлов Directory.DeleteHelper (recursive: = true) может вызвать исключение IOException, вызванное задержкой удаления файла.

У меня сегодня была эта проблема. Это произошло потому, что у меня был проводник Windows, открытый для каталога, который пытался удалить, что привело к сбою рекурсивного вызова и, следовательно, к IOException. Убедитесь, что в каталоге нет открытых дескрипторов.

Кроме того, MSDN ясно дает понять, что вам не нужно писать собственное возражение: http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

Я потратил несколько часов, чтобы решить эту проблему и другие исключения с удалением каталога. Это мое решение

 public static void DeleteDirectory(string target_dir)
    {
        DeleteDirectoryFiles(target_dir);
        while (Directory.Exists(target_dir))
        {
            lock (_lock)
            {
                DeleteDirectoryDirs(target_dir);
            }
        }
    }

    private static void DeleteDirectoryDirs(string target_dir)
    {
        System.Threading.Thread.Sleep(100);

        if (Directory.Exists(target_dir))
        {

            string[] dirs = Directory.GetDirectories(target_dir);

            if (dirs.Length == 0)
                Directory.Delete(target_dir, false);
            else
                foreach (string dir in dirs)
                    DeleteDirectoryDirs(dir);
        }
    }

    private static void DeleteDirectoryFiles(string target_dir)
    {
        string[] files = Directory.GetFiles(target_dir);
        string[] dirs = Directory.GetDirectories(target_dir);

        foreach (string file in files)
        {
            File.SetAttributes(file, FileAttributes.Normal);
            File.Delete(file);
        }

        foreach (string dir in dirs)
        {
            DeleteDirectoryFiles(dir);
        }
    }

Этот код имеет небольшую задержку, которая для моего приложения не важна. Но будьте осторожны, задержка может быть проблемой для вас, если у вас много подкаталогов внутри каталога, который вы хотите удалить.

Я думаю, что есть файл, открытый каким-то потоком, о котором вы не знаете. У меня была такая же проблема, и я решил ее, закрыв все потоки, которые указывали на каталог, который я хотел удалить.

Я удивлен, что никто не подумал об этом простом нерекурсивном методе, который может удалять каталоги, содержащие файлы только для чтения, без необходимости изменять атрибут только для чтения каждого из них.

Process.Start("cmd.exe", "/c " + @"rmdir /s/q C:\Test\TestDirectoryContainingReadOnlyFiles"); 

(Немного измените, чтобы не запускать окно cmd на мгновение, которое доступно во всем Интернете)

Прежде чем двигаться дальше, проверьте следующие причины, которые находятся под вашим контролем:

• Папка установлена ​​в качестве текущего каталога вашего процесса? Если да, сначала измените его на что-нибудь другое.
• Вы открыли файл (или загрузили 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%, поэтому мой анализ выглядит следующим образом:

1. Папка контролируется исключительно моим приложением, и у пользователя нет веской причины идти и отмечать вещи как доступные только для чтения или недоступные внутри этой папки, поэтому я не пытаюсь обрабатывать этот случай.

2. Там нет ценных вещей, созданных пользователями, поэтому нет риска насильственно удалить что-то по ошибке.

3. Поскольку это внутренняя папка данных, я не ожидаю, что она будет открыта в проводнике, по крайней мере, я не чувствую необходимости специально обрабатывать этот случай (т.е. я прекрасно справляюсь с этим случаем через службу поддержки).

4. Если все попытки терпят неудачу, я предпочитаю игнорировать ошибку. В худшем случае приложение не может распаковать некоторые новые ресурсы, вылетает и предлагает пользователю обратиться в службу поддержки, что приемлемо для меня, если это случается нечасто. Или, если приложение не выйдет из строя, оно оставит некоторые старые данные, что снова приемлемо для меня.

5. Я предпочитаю ограничить количество повторных попыток до 500 мс (50 * 10). Это произвольный порог, который работает на практике; Я хотел, чтобы порог был достаточно коротким, чтобы пользователи не убивали приложение, думая, что оно перестало отвечать. С другой стороны, полсекунды - это достаточно времени, чтобы злоумышленник закончил обработку моей папки. Судя по другим ответам SO, которые иногда считают приемлемым даже Sleep(0), очень немногие пользователи когда-либо испытают более одной попытки.

6. Я повторяю каждые 50 мсек, это еще одно произвольное число. Я чувствую, что если файл обрабатывается (индексируется, проверяется), когда я пытаюсь его удалить, 50 мс - это как раз подходящее время для ожидания завершения обработки в моем случае. Кроме того, 50 мс - это достаточно мало, чтобы не вызвать заметного замедления; опять же, Sleep(0) кажется достаточно во многих случаях, поэтому мы не хотим слишком долго откладывать.

7. Код повторяет попытку при любых исключениях ввода-вывода. Обычно я не ожидаю каких-либо исключений при доступе к% LocalAppData%, поэтому я выбрал простоту и принял риск задержки 500 мс в случае возникновения законного исключения. Я также не хотел выяснять способ обнаружения точного исключения, которое я хочу повторить.

Рекурсивное удаление каталога, которое не приводит к удалению файлов, безусловно, является неожиданным. Мое исправление для этого:

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 Explorer: иногда я не могу удалить папку (он думает, что бессмысленным сообщением является «доступ запрещен»), но когда я углубляюсь и удаляю нижние элементы, я могу удалить верхние. предметы тоже. Итак, я предполагаю, что приведенный выше код имеет дело с аномалией ОС, а не с проблемой библиотеки базового класса.

У меня была такая же проблема с Windows Workflow Foundation на сервере сборки с TFS2012. Внутренне рабочий процесс называется Directory.Delete () с рекурсивным флагом, установленным в значение true. В нашем случае это похоже на сеть.

Мы удаляли двоичную папку размещения на сетевом ресурсе перед повторным созданием и повторным заполнением ее последними двоичными файлами. Любая другая сборка выйдет из строя. При открытии папки размещения после неудачной сборки папка была пустой, что указывает на то, что все аспекты вызова Directory.Delete () были успешными, за исключением удаления фактического каталога.

Проблема, по-видимому, вызвана асинхронным характером сетевых файловых обменов. Сервер сборки сказал файловому серверу удалить все файлы, и файловый сервер сообщил об этом, даже если он не был полностью завершен. Затем сервер сборки запросил удаление каталога, и файловый сервер отклонил запрос, поскольку он еще не полностью завершил удаление файлов.

В нашем случае два возможных решения:

• Создайте рекурсивное удаление в нашем собственном коде с задержками и проверками между каждым шагом
• Повторите попытку до X раз после исключения IOException с задержкой перед повторной попыткой

Последний метод быстр и грязен, но, похоже, помогает.

Это из-за FileChangesNotifications.

Это происходит, начиная с ASP.NET 2.0. Когда вы удаляете какую-либо папку в приложении, это перезапускается. Вы можете убедиться в этом сами, используя Мониторинг работоспособности ASP.NET.

Просто добавьте этот код в свой web.config / configuration / system.web:

<healthMonitoring enabled = "true">
  <rules>
    <add name = "MyAppLogEvents" eventName = "Application Lifetime Events" provider = "EventLogProvider" profile = "Critical"/>
  </rules>
</healthMonitoring>

После этого проверьте Windows Log -> Application. Что происходит:

Когда вы удаляете папку, если есть какая-либо подпапка, Delete(path, true) сначала удаляет подпапку. FileChangesMonitor достаточно знать об удалении и закрыть ваше приложение. Между тем ваш основной каталог еще не удален. Это событие из журнала:

Delete() не завершил свою работу, и поскольку приложение закрывается, возникает исключение:

Когда вы нет вложенных папок в удаляемой папке, Delete () просто удаляет все файлы и эту папку, приложение тоже перезапускается, но вы не бывает исключений, потому что перезапуск приложения ничего не прерывает. Но все равно вы теряете все внутрипроцессные сеансы, приложение не отвечает на запросы при перезапуске и т. д.

Что теперь?

Есть некоторые обходные пути и настройки для отключения этого поведения, Directory Junction, Отключение FCN с помощью реестра, Остановка FileChangesMonitor с помощью Reflection (поскольку нет открытого метода), но все они кажутся неправильными, потому что FCN существует не просто так. Он ищет структура вашего приложения, который не является структура ваших данных. Короткий ответ: поместите папки, которые вы хотите удалить, за пределами вашего приложения. FileChangesMonitor не будет получать уведомления, и ваше приложение не будет перезапускаться каждый раз. Вы не получите исключений. Чтобы сделать их видимыми из Интернета, есть два способа:

1. Сделайте контроллер, который обрабатывает входящие вызовы, а затем возвращает файлы, читая их из папки вне приложения (вне wwwroot).

2. Если ваш проект большой и производительность важнее всего, настройте отдельный небольшой и быстрый веб-сервер для обслуживания статического контента. Таким образом, вы оставите IIS его конкретную работу. Это может быть тот же компьютер (mongoose для Windows) или другой компьютер (nginx для Linux). Хорошая новость в том, что вам не нужно платить дополнительную лицензию Microsoft для установки сервера статического содержимого в Linux.

Надеюсь это поможет.

Ни один из приведенных выше ответов не помог мне. Похоже, что использование DirectoryInfo в целевом каталоге моим собственным приложением заставляло его оставаться заблокированным.

Похоже, принудительная сборка мусора решила проблему, но не сразу. Несколько попыток удалить где необходимо.

Обратите внимание на Directory.Exists, так как он может исчезнуть после исключения. Я не знаю, почему удаление для меня было отложено (Windows 7 SP1)

        for (int attempts = 0; attempts < 10; attempts++)
        {
            try
            {
                if (Directory.Exists(folder))
                {
                    Directory.Delete(folder, true);
                }
                return;
            }
            catch (IOException e)
            {
                GC.Collect();
                Thread.Sleep(1000);
            }
        }

        throw new Exception("Failed to remove folder.");

Вы можете воспроизвести ошибку, запустив:

Directory.CreateDirectory(@"C:\Temp\a\b\c\");
Process.Start(@"C:\Temp\a\b\c\");
Thread.Sleep(1000);
Directory.Delete(@"C:\Temp\a\b\c");
Directory.Delete(@"C:\Temp\a\b");
Directory.Delete(@"C:\Temp\a");

При попытке удалить каталог 'b' выдается исключение IOException «Каталог не пуст». Это глупо, ведь мы только что удалили каталог «c».

Насколько я понимаю, объяснение состоит в том, что каталог «c» помечен как удаленный. Но удаление еще не выполнено в системе. Система получила ответ, что задание выполнено, хотя фактически оно все еще обрабатывается. Система, вероятно, дождется, когда файловый проводник сфокусируется на родительском каталоге, чтобы зафиксировать удаление.

Если вы посмотрите исходный код функции удаления (http://referencesource.microsoft.com/#mscorlib/system/io/directory.cs), вы увидите, что она использует встроенную функцию Win32Native.RemoveDirectory. Это поведение «не ждать» отмечено здесь:

The RemoveDirectory function marks a directory for deletion on close. Therefore, the directory is not removed until the last handle to the directory is closed.

(http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488(v=vs.85).aspx)

Сон и повтор - вот решение. См. Раствор рясла.

Эта ошибка возникает, если какой-либо файл или каталог считается используемым. Это ошибочная ошибка. Проверьте, открыты ли у вас окна проводника или окна командной строки для любого каталога в дереве или программы, использующей файл в этом дереве.

Как упоминалось выше, «принятое» решение не работает в точках повторной обработки - но люди все еще отмечают его (???). Есть гораздо более короткое решение, которое должным образом воспроизводит функциональность:

public static void rmdir(string target, bool recursive)
{
    string tfilename = Path.GetDirectoryName(target) +
        (target.Contains(Path.DirectorySeparatorChar.ToString()) ? Path.DirectorySeparatorChar.ToString() : string.Empty) +
        Path.GetRandomFileName();
    Directory.Move(target, tfilename);
    Directory.Delete(tfilename, recursive);
}

Я знаю, что не обрабатывает случаи разрешений, упомянутые позже, но для всех намерений и целей НАМНОГО ЛУЧШЕ предоставляет ожидаемая функциональность исходного / стандартного Directory.Delete () - и с гораздо меньшим количеством кода.

Вы можете безопасно продолжить обработку, потому что старый каталог не будет мешать ... даже если не исчез, потому что `` файловая система все еще догоняет '' (или любое другое оправдание, которое MS дала для предоставления неработающей функции).

В качестве преимущества, если вы знаете, что ваш целевой каталог большой / глубокий и не хотите ждать (или беспокоиться об исключениях), последнюю строку можно заменить на:

    ThreadPool.QueueUserWorkItem((o) => { Directory.Delete(tfilename, recursive); });

Вы по-прежнему можете продолжать работу.

Этот ответ основан на: https://stackoverflow.com/a/1703799/184528. Разница с моим кодом заключается в том, что мы рекурсивно обрабатываем многие подкаталоги и файлы для удаления только тогда, когда это необходимо, вызов Directory.Delete завершается неудачно с первой попытки (что может произойти из-за того, что проводник 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);
        } 
    }

добавьте true во второй параметр.

Directory.Delete(path, true);

Он удалит все.

Я решил один из возможных случаев заявленной проблемы, когда методы были асинхронными и закодированы следующим образом:

// delete any existing update content folder for this update
if (await fileHelper.DirectoryExistsAsync(currentUpdateFolderPath))
       await fileHelper.DeleteDirectoryAsync(currentUpdateFolderPath);

С этим:

bool exists = false;                
if (await fileHelper.DirectoryExistsAsync(currentUpdateFolderPath))
    exists = true;

// delete any existing update content folder for this update
if (exists)
    await fileHelper.DeleteDirectoryAsync(currentUpdateFolderPath);

Заключение? Есть некоторый асинхронный аспект избавления от дескриптора, используемого для проверки существования, с которым Microsoft не может связаться. Это как если бы асинхронный метод внутри оператора if имеет оператор if, действующий как оператор using.

Эта проблема может возникнуть в Windows, если в каталоге (или в любом подкаталоге) есть файлы, длина пути которых превышает 260 символов.

В таких случаях вам необходимо удалить \\\\?\C:\mydir вместо C:\mydir. Об ограничении в 260 символов вы можете прочитать здесь.

Следует упомянуть одну важную вещь (я добавил ее в качестве комментария, но мне это не разрешено): поведение перегрузки изменилось с .NET 3.5 на .NET 4.0.

Directory.Delete(myPath, true);

Начиная с .NET 4.0, он удаляет файлы в самой папке, но НЕ в 3.5. Это также можно увидеть в документации MSDN.

.NET 4.0

Deletes the specified directory and, if indicated, any subdirectories and files in the directory.

.NET 3.5

Deletes an empty directory and, if indicated, any subdirectories and files in the directory.

Современный асинхронный ответ

Принятый ответ просто неверен, он может сработать для некоторых людей, потому что время, затрачиваемое на получение файлов с диска, освобождает все, что блокировало файлы. Дело в том, что это происходит потому, что файлы блокируются каким-то другим процессом / потоком / действием. В других ответах используется Thread.Sleep (Yuck), чтобы повторить попытку удаления каталога через некоторое время. Этот вопрос требует пересмотра с более современным ответом.

public static async Task<bool> TryDeleteDirectory(
   string directoryPath,
   int maxRetries = 10,
   int millisecondsDelay = 30)
{
    if (directoryPath == null)
        throw new ArgumentNullException(directoryPath);
    if (maxRetries < 1)
        throw new ArgumentOutOfRangeException(nameof(maxRetries));
    if (millisecondsDelay < 1)
        throw new ArgumentOutOfRangeException(nameof(millisecondsDelay));

    for (int i = 0; i < maxRetries; ++i)
    {
        try
        {
            if (Directory.Exists(directoryPath))
            {
                Directory.Delete(directoryPath, true);
            }

            return true;
        }
        catch (IOException)
        {
            await Task.Delay(millisecondsDelay);
        }
        catch (UnauthorizedAccessException)
        {
            await Task.Delay(millisecondsDelay);
        }
    }

    return false;
}

Единичные тесты

Эти тесты показывают пример того, как заблокированный файл может вызвать сбой Directory.Delete и как описанный выше метод TryDeleteDirectory устраняет проблему.

[Fact]
public async Task TryDeleteDirectory_FileLocked_DirectoryNotDeletedReturnsFalse()
{
    var directoryPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
    var subDirectoryPath = Path.Combine(Path.GetTempPath(), "SubDirectory");
    var filePath = Path.Combine(directoryPath, "File.txt");

    try
    {
        Directory.CreateDirectory(directoryPath);
        Directory.CreateDirectory(subDirectoryPath);

        using (var fileStream = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.Write))
        {
            var result = await TryDeleteDirectory(directoryPath, 3, 30);
            Assert.False(result);
            Assert.True(Directory.Exists(directoryPath));
        }
    }
    finally
    {
        if (Directory.Exists(directoryPath))
        {
            Directory.Delete(directoryPath, true);
        }
    }
}

[Fact]
public async Task TryDeleteDirectory_FileLockedThenReleased_DirectoryDeletedReturnsTrue()
{
    var directoryPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
    var subDirectoryPath = Path.Combine(Path.GetTempPath(), "SubDirectory");
    var filePath = Path.Combine(directoryPath, "File.txt");

    try
    {
        Directory.CreateDirectory(directoryPath);
        Directory.CreateDirectory(subDirectoryPath);

        Task<bool> task;
        using (var fileStream = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.Write))
        {
            task = TryDeleteDirectory(directoryPath, 3, 30);
            await Task.Delay(30);
            Assert.True(Directory.Exists(directoryPath));
        }

        var result = await task;
        Assert.True(result);
        Assert.False(Directory.Exists(directoryPath));
    }
    finally
    {
        if (Directory.Exists(directoryPath))
        {
            Directory.Delete(directoryPath, true);
        }
    }
}

Ни одно из вышеперечисленных решений не помогло мне. В итоге я использовал отредактированную версию решения @ryascl, как показано ниже:

    /// <summary>
    /// Depth-first recursive delete, with handling for descendant 
    /// directories open in Windows Explorer.
    /// </summary>
    public static void DeleteDirectory(string path)
    {
        foreach (string directory in Directory.GetDirectories(path))
        {
            Thread.Sleep(1);
            DeleteDir(directory);
        }
        DeleteDir(path);
    }

    private static void DeleteDir(string dir)
    {
        try
        {
            Thread.Sleep(1);
            Directory.Delete(dir, true);
        }
        catch (IOException)
        {
            DeleteDir(dir);
        }
        catch (UnauthorizedAccessException)
        {
            DeleteDir(dir);
        }
    }

Я решил с помощью этой тысячелетней техники (вы можете оставить Нить. Спать самостоятельно в ловушке)

bool deleted = false;
        do
        {
            try
            {
                Directory.Delete(rutaFinal, true);                    
                deleted = true;
            }
            catch (Exception e)
            {
                string mensaje = e.Message;
                if ( mensaje == "The directory is not empty.")
                Thread.Sleep(50);
            }
        } while (deleted == false);

Вам не нужно создавать дополнительный метод для рекурсии или удалять файлы внутри дополнительной папки. Все это происходит автоматически путем вызова

DirectoryInfo.Delete();

Подробности - здесь.

Что-то вроде этого неплохо работает:

  var directoryInfo = new DirectoryInfo("My directory path");
    // Delete all files from app data directory.

    foreach (var subDirectory in directoryInfo.GetDirectories())
    {
          subDirectory.Delete(true);// true set recursive paramter, when it is true delete sub file and sub folder with files too
    }

передача true в качестве переменной для метода удаления, удалит подфайлы и подпапку с файлами.