在API删除/退出之后，gsdll32.dll保持锁定

Question

我使用GhostScriptSharp构建了一个转换器，通过一个网站生成PDF文件的完整页面图像，每当我调用GenerateOutput()时，gsdll32.dll似乎仍然被锁定(以及它生成/工作的文件)。

我的代码片段：

GhostscriptSharp.GhostscriptWrapper.GenerateOutput(pdfFile, outputFile, settings);

调用之后，我立即将生成的字节保存到Azure上的blob中。一旦完成，我试着打电话：

try {
    File.Delete(outputFile); // clean up if we can
}
catch { }

这会引发异常，因为文件仍然被锁定。

然后，当我尝试重新构建时(无论是通过F5还是在实际情况下)，我都会看到一个错误，它不能将gsdll32.dll复制到我的bin文件夹，因为它已经锁定了。

我检查了GhostScriptSharp和Ghostscript API，似乎一切都是按照正确的顺序调用的。但是，我无法解释IIS为什么要在gsdll32.dll上保留一个锁。

以前有人遇到过这种情况吗？我似乎找不到有类似问题的人。

更新:我尝试在上面的捕获中第二次调用ExitAPI/DeleteAPI，以防由于某种原因没有第一次调用，并抛出了一个AccessViolationException。所以看起来API是正确退出的，只是IIS没有正确地释放锁吗？

Answer 1

经过更多研究后，这似乎实际上是IIS和本机dll导入之间的行为。在大多数情况下，可以通过在发布之前卸载AppDomain (即循环应用程序池)来避免这个问题。这在使用app_offline.htm的正常发布场景中是可行的，但在Azure持续集成环境中，这不是一个选项(这很可悲，因为我不得不禁用CI并在我的主分支上使用手动发布)。

任何进一步的投入，我可以如何工作，以使构建自动化将是难以置信的帮助。我现在唯一的解决办法是将Ghostscript依赖项卸载到一个单独的机器上，并设置一个消息队列来处理事情(呃)。