Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

IIS Express Worker Process doesn't release assembly

I have a MVC 5 Project called MyApp which compiles into MyApp.dll I'm using Visual Studio 2015 and compiling targeting .net Framework 4.5.1

After developing a while I can't compile anymore because the IIS Express Worker Process doesn't release the file \obj\Debug\MyApp.dll

Strange thing that if I do a full recompile afterwards somehow the assembly gets freed and i can then start debugging again, at least most of the time.

(And in some cases a recompile doesn't help anymore and i have to start killing the process)

Any Idea why the IIS Express Worker Process does block my assembly?

The Error Showing in VS 2015: enter image description here

like image 961
gsharp Avatar asked Apr 14 '16 08:04

gsharp


4 Answers

There could be issues with file locking if you have indexing activated on the directory. May be the problem as it turned out was in the settings of the virtual directory in IIS. If the virtual directory still has the index this location flag turned on, it turned out that IIS is placing a temporary lock on these files, even though the web application wasn't being started (ie it was just a compile, not a debug run). After turning the index this location setting off the file locking problem will disappear.

See this for more info.

like image 53
itzmebibin Avatar answered Sep 17 '22 16:09

itzmebibin


I think the real answer here is that Visual Studio is a bit buggy on that side. This happens also sometimes with desktop applications (winforms or WPF) , where the build fail because of locked output of the project (the exe or dll that you are building).

I have similar problems, sometimes, with Visual Studio professional 2013 and i think it happens also on older versions. When this happens i close Visual Studio and reopen it and this solve all the problems.

Some reference:

Visual Studio 2010 build file lock issues

Visual Studio locks output file on build

Locking files when building in Visual Studio 2010

like image 42
fruggiero Avatar answered Sep 18 '22 16:09

fruggiero


What I have faced before when debugging the application using other browser than Internet explorer, visual studio will only detach the process, but wont close the service. sometimes when the handle is released the application is not releasing the resources the service is using (for example a log file being accessed or a long running process attached to the session you just left.) as @Michael Mentions there may be a memory leak. I have had to force close IIS, to release the resources. other thing that has happened is that 2 developers in the same machine (RDP) are processing the same server, and the port/libraries are not released as one or the other is using it. Since we don't have a lot more details on your dev environment all pose to "maybe" scenarios.

like image 35
Gilberto Avatar answered Sep 20 '22 16:09

Gilberto


The root cause is IIS having a lock on the file and VS not being able to delete the file when it compiles. Mark Russinovich (Microsoft Fellow and SysInternals Co-Founder) has a great blog on how to this track down: The case of the mysterious locked file - he basically uses Process Monitor (FileMon) and Process Explorer to investigate.

Until you identify why IIS cant unlock the DLL, here are some workarounds:

  1. Start cmd with elevated privileges and issue a netstat -an -p tcp to check if another application is contending for the port you're using and causing a binding conflict issue. You can check the httperr logs for more information.

  2. Goto properties of the project > tab "Debug" > uncheck "Enable the Visual Studio hosting process".

  3. Start cmd with elevated privileges and issue a net stop iisadmin /y followed by a iisreset.

  4. Do a Clean Solution and full recompile, this works intermittently because there is no 100% safe way to "learn if a file is in use" because milliseconds after you do the check the file may not be in use anymore, or vice versa.

  5. Often I have to fall back to the last resort and rename the locked file MyApp.dll to MyApp1.dll.

One last thing I want to address is @user1438893 comment about "IIS Express being buggy". Maybe this is a bug, perhaps its by design, though more likely a memory leak/unreleased hook/undisposed-unmanaged-resource caused by end-user code. Using Process Monitor and Process Explorer will be able to help you find out.

like image 43
Jeremy Thompson Avatar answered Sep 17 '22 16:09

Jeremy Thompson