'Prevent website build failure due to iis locking dll
I have a MVC/C# based website. One of the nuget packages being used is a wrapper around PDFium, a non .NET dll. The PDFium dll is included as part of another nuget package and is just a dll that gets copied into the output directory.
The problem I have is that after I have used the website the PDFium dll (ie the non .net one, not the one that is doing the wrapping) seems to get loaded and then locked by IIS. If I then try to do a build in Visual Studio I get an error saying:
Unable to copy file [Full Source Path]. The process cannot access the file [destination path] because it is being used by another process.
A second line in the build error log shows something similar and additionally confirms:
The file is locked by: "IIS Worker Process (28776)"
If I do an iisreset then this will cause that worker process to get killed and thus the copy can happen but I am wondering if there is any kind of better way of doing this. My thought is that all the other DLLs included by nuget packages and similar get copied just fine so maybe there is something a bit more "proper" that can be done to resolve this rather than the slightly heavy handed iisreset approach...
Solution 1:[1]
Not sure if any of this will help, but in order to avoid an IISReset, one option is to ensure that the PDFium.DLL being used by IIS is not the one that's copied to your project's target directory during a build. However, if the PDFium.DLL must sit in the same folder as your wrapper assembly (as I suspect it does), then you might not have a good option other than to use IISReset. You could follow advice here (How to restart the IIS Site when re-compiling an asp.net website) to add a pre-build script, saving you from the manual effort.
If the PDFium.DLL doesn't have to be in the same folder as the wrapper and can be registered anywhere on your system, you can try to set that reference's Copy Local property to false so that no copy is attempted. Obviously, this would work only if the wrapper can find the DLL through its registry entry--if it can be registered...
Solution 2:[2]
Our builds have been reporting the same error with IIS locking pdfium.dll causing build failure. When I notice it, I use a tool called LockHunter.
When Lockhunter is installed, in file explorer locate the locked file reported by the error and right-click it.
In the context menu, LockHunter will have added a menu option "What's locking this file" - select that.
A LockHunter window will appear which reports the file is locked by w3wp.exe (IIS worker process).
The LockHunter window has an option to unlock the file, select that. The file is unlocked and then the build works.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Jazimov |
| Solution 2 | Gary Barrett |