Why is IIS Worker Process locking a file?

Question

My website is setup in the D:\RW_System\RW_Webroot\BrokerOffice.Admin folder (screenshot below). It's a .NET, C# WebForms application.

For whatever reason, when I want to deploy changes to the site, I try to copy the files over, but IIS locks DLLs in the path where the site is setup:

C:\Users\rizzo\Desktop>handle64 hiqpdf

Nthandle v4.11 - Handle viewer
Copyright (C) 1997-2017 Mark Russinovich
Sysinternals - www.sysinternals.com

w3wp.exe  pid: 3700   type: File  2954: D:\RW_System\RW_Webroot\BrokerOffice.Admin\bin\HiQPdf.dll

And it's not just that .dll that's locked - it's all of the DLLs in the \bin folder. My understanding was that IIS copied everything to folder under C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\ and executed things from there.

I have a number of other sites on the box with multiple DLL references and, as expected, w3wp.exe has them locked in Temporary ASP.NET Files folder.

Is there a setting in IIS or something in my code that's causing IIS to lock the the DLLs in the /bin folder?

Answer 1

Open IIS manager, stop & restart IIS specific to your project. Than clean & build your project

Answer 2

Looks like an issue with visual studio.

During I was playing around with the "Release" and "Debug" options of Configuration manager, I started encountering the same error.

• I attempted to delete bin and obj folders too, but couldn't succeed as dll files were locked by IIS Express worker process.

• Attempted relaunching visual studio without any luck.

Finally, when I changed the Configuration back to "Debug" and compiled the application, build was succeeded without any errors or warnings.

After that, I even changed the configuration back to "Release" and it still didn't show any dll file lock error. So, most probably its an internal bug of visual studio.

Answer 3

A quick and reliable way to take down a site ready to deploy is to create a file in the root folder of your website called App_Offline.htm (~/App_Offline.htm). Content is optional, if present its served for all requests until the App_Offline.htm is deleted. This method will work under pretty much all cases - including any value used for shadowCopyBinAssemblies.

Basically App_Offline is a feature of IIS used by Web Deploy to ensure it can deploy correctly - avoiding any locking issues and such. It seems to operate at a very low level in IIS, its literally a file system watcher that kills the app pool. This means you can easily just create and delete this text file yourself without web deploy to stop and restart(or at least re-enable) your app.

Taken from MS docs:

When ASP.Net detects that a file by the name of "App_Offline.htm" exists, it will automatically bring down the app domain hosting the application. When the publish process is completed, the App_Offline.htm file will be removed and the site will be online again.

See Microsoft's article on taking an application offline.

Update - 22/5/2019

It might be worth pointing out by creating the app_offline file its causing 2 separate things to happen:

1. IIS will instantly stop serving new requests and start returning a HTTP 503 "temporarily unavailable" response with the contents of the app_offline file.
2. IIS starts a chain of events that leads to the termination of the instance of w3wp.exe - that is your "app domain" (as seen in task manager) - aka the owner of the locks. When that process dies, all locks are released. In my experience that's normally very quickly.

Based on personal/bitter experience of a few high traffic sites and as an absolute last resort... If for whatever reason an IIS site wont stop/release locks/abort existing requests its probably down to load or otherwise something blocking the process exiting - app_offline should kill the site very quickly under normal circumstances. In these cases, and assuming you know the requests wont complete, or you just dont care and need the site to stop or restart, create the app offline file, use task manager to kill the w3wp.exe process, perform your change, then remove the app offline file. The next request starts a new app domain (and obviously abandons any pending requests - so do this with caution - this may or not be a problem depending on your site).

Answer 4

Answering my own question in case someone runs into this problem. Turns out web.config file had the <hostingEnvironment shadowCopyBinAssemblies="false" /> directive, which I didn't even know existed.

This setting tells IIS to execute everything in place rather than in Temporary ASP.NET Files folder.