当方法是异步的并像这样编码时，我解决了上述问题的一个可能实例:

// 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);

结论?去除用于检查存在的句柄有一些异步的方面，微软无法与之对话。这就好像if语句中的异步方法让if语句充当using语句一样。

上面的答案对我都没用。似乎我自己的应用程序在目标目录上使用DirectoryInfo导致它保持锁定。

强制垃圾收集似乎解决了这个问题，但不是马上就能解决的。在需要的地方尝试删除几次。

注意目录。存在，因为它可以在异常后消失。我不知道为什么我的删除被延迟了(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.");

以上的解决方案都不适合我。我最终使用了一个编辑版本的@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);

这是因为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 ->应用程序。 发生了什么:

删除文件夹时，如果有子文件夹，delete (path, true)会先删除子文件夹。这足以让FileChangesMonitor知道删除和关闭你的应用程序。同时你的主目录还没有删除。这是来自日志的事件:

Delete()没有完成它的工作，因为应用程序正在关闭，它引发了一个异常:

当你正在删除的文件夹中没有任何子文件夹时，Delete()只是删除所有文件和该文件夹，app也会重新启动，但你不会得到任何异常，因为app重新启动不会中断任何事情。但是，你仍然会失去所有进程中的会话，应用程序在重新启动时不响应请求，等等。

现在该做什么?

There are some workarounds and tweaks to disable this behaviour, Directory Junction, Turning Off FCN with Registry, Stopping FileChangesMonitor using Reflection (since there is no exposed method), but they all don't seem to be right, because FCN is there for a reason. It is looking after structure of your app, which is not structure of your data. Short answer is: place folders you want to delete outside of your app. FileChangesMonitor will get no notifications and your app will not be restarted every time. You will get no exceptions. To get them visible from the web there are two ways:

创建一个控制器来处理传入调用，然后通过从应用程序外部(wwwroot外部)的文件夹读取文件返回。 如果你的项目很大，性能是最重要的，那就单独设置一个小型快速的web服务器来提供静态内容。因此，您将把他的具体工作留给IIS。它可以在同一台机器上(Windows的mongoose)，也可以在另一台机器上(Linux的nginx)。好消息是你不需要支付额外的微软许可证来在linux上设置静态内容服务器。

希望这能有所帮助。