gsdll32.dll 在 API delete/exit 之后保持锁定状态

gsdll32.dll stays locked after API delete/exit

我使用 GhostScriptSharp 构建了一个转换器,可以通过网站生成 PDF 文件的整页图像,并且 gsdll32.dll 似乎在我任何时候都处于锁定状态(以及它 generated/worked 来自的文件)调用 GenerateOutput()。

我的代码片段:

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

调用此方法后,我立即将生成的字节保存到 Azure 上的一个 blob。完成后,我尝试调用:

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

由于文件仍处于锁定状态而引发异常。

然后,当我尝试再次构建时(通过 F5 或什至在实时情况下),我收​​到一条错误消息,提示无法将 gsdll32.dll 复制到我的 bin 文件夹,因为它已被锁定。

我对照 Ghostscript API 检查了 GhostScriptSharp,似乎一切都以正确的顺序被调用。不过,我无法解释为什么 IIS 会保留对 gsdll32.dll 的锁定。

有人 运行 以前参与过这个吗?我似乎找不到有类似问题的人。

更新: 我试着在上面的 catch 中第二次调用 ExitAPI/DeleteAPI 以防它由于某种原因没有第一次调用,它抛出了一个 AccessViolationException。所以看起来 API 正在正常退出,我猜只是 IIS 没有正确释放锁?

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

任何关于我如何解决这个问题以实现构建自动化的进一步输入都将非常有帮助。我现在唯一的解决方法是将 Ghostscript 依赖项卸载到一台单独的机器上,并设置一个消息队列来处理事情(呃)。