【问题标题】:Prevent website build failure due to iis locking dll防止由于 iis 锁定 dll 而导致网站构建失败
【发布时间】:2022-05-14 18:54:35
【问题描述】:

我有一个基于 MVC/C# 的网站。正在使用的 nuget 包之一是 PDFium 的包装器,它是一个非 .NET dll。 PDFium dll 包含在另一个 nuget 包中,它只是一个复制到输出目录中的 dll。

我遇到的问题是,在我使用该网站后,PDFium dll(即非 .net 的,而不是进行包装的)似乎被加载,然后被 IIS 锁定。如果我尝试在 Visual Studio 中进行构建,我会收到一条错误消息:

无法复制文件 [完整源路径]。该进程无法访问文件 [目标路径],因为它正被另一个进程使用。

构建错误日志中的第二行显示了类似的内容并另外确认:

文件被“IIS Worker Process (28776)”锁定

如果我执行iisreset,那么这将导致该工作进程被杀死,因此可能会发生复制,但我想知道是否有更好的方法来做到这一点。我的想法是,nuget 包和类似包中包含的所有其他 DLL 都可以很好地复制,所以也许有一些更“适当”的方法可以解决这个问题,而不是稍微笨拙的 iisreset 方法......

【问题讨论】:

  • 哪个 DLL 被锁定——PDFium.DLL 还是 .NET 包装程序集?
  • @Jazimov:PDFium.DLL 被锁定,而不是 .NET 包装器。我将进行编辑以使其更清晰。

标签: visual-studio iis build-error pdfium locked-files


【解决方案1】:

不确定这是否有帮助,但为了避免 IISReset,一种选择是确保 IIS 使用的 PDFium.DLL 不是在构建期间复制到项目目标目录的那个。但是,如果 PDFium.DLL 必须与包装程序集位于同一文件夹中(我怀疑它确实如此),那么除了使用 IISReset 之外,您可能没有其他好的选择。您可以按照此处的建议 (How to restart the IIS Site when re-compiling an asp.net website) 添加预构建脚本,从而使您免于手动操作。

如果 PDFium.DLL 不必与包装器位于同一文件夹中并且可以在系统上的任何位置注册,则可以尝试将该引用的 Copy Local 属性设置为 false,以便不尝试复制。显然,这只有在包装器可以通过其注册表项找到 DLL 时才有效——如果它可以注册...

【讨论】:

  • 我会看看你的建议。我已经实施了一个预构建步骤来重置 iis,但感觉有点 hacky,所以希望可能有更好的东西。我担心尝试获得您建议的解决方案的实用性可能与构建额外 10 秒的相对较小的缺点以及我的本地网络服务器重置的潜在问题相比有点多......
  • 不能再同意了:我认为 IISReset 是正确的解决方案——尽管它感觉很糟糕。如果您将 IIS 视为具有 DLL 作为依赖项的应用程序,那么它与包含 DLL 引用的 Windows 桌面应用程序 EXE 并没有什么不同。我们都知道解决方案是在那些情况下退出该 EXE(如果可能)或终止其任务条目。如果这让您感觉更好的话,您实际上是在用 IIS 做同样的事情。 :)
  • 是的。我的意思是,我对网络应用程序中的 DLL 的记忆可以追溯到 pre.net 的黑暗时期,如果你想更新一个 DLL,你基本上必须重新启动计算机才能释放锁定。 ;-)
【解决方案2】:

我们的构建报告了相同的错误,IIS 锁定 pdfium.dll 导致构建失败。当我注意到它时,我使用了一个名为 LockHunter 的工具。

  1. 安装 Lockhunter 后,在文件资源管理器中找到由 错误并右键单击它。

  2. 在上下文菜单中,LockHunter 将添加一个菜单选项 “什么锁定了这个文件” - 选择它。

  3. 将出现一个 LockHunter 窗口,报告文件已被锁定 w3wp.exe(IIS 工作进程)。

  4. LockHunter 窗口有一个解锁文件的选项,选择它。 该文件被解锁,然后构建工作。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2018-04-22
    • 2015-09-04
    • 1970-01-01
    • 2023-01-02
    • 2020-11-04
    • 2021-10-13
    • 2018-04-29
    • 1970-01-01
    相关资源
    最近更新 更多