5

I am using NHunspell in an ASP.net web application. NHunspell wraps either Hunspellx86.dll or Hunspellx64.dll, both of which are unmanaged dlls.

The problem is this: when I dispose of my NHunspell object (which calls FreeLibrary from kernel32.dll), it seems that IIS is still hanging on to it - as evidenced by both windbg and tasklist /m. This is problematic if, say, I try to replace that dll using an automated build process, or run an installer to update my web application: everything fails because that dll is in use.

I'm wondering if anyone can confirm my suspicions that it is, in fact, IIS that is caching it? Also, why can I delete managed dlls right out from under IIS (even when tasklist reports those dlls as used by IIS)?

Finally, I'm looking for suggestions on what to do about actually being able to delete this dll for automated builds/installs?

Thanks very much!

Geoff Huston
  • 363
  • 2
  • 6
  • 1
    The overkill option I guess is `iisadmin /stop` and `iisadmin /start` around those parts of your build - assuming your build is running with enough permissions. – Rup Mar 13 '12 at 17:21
  • Also have you tried [Sysinternals Process Explorer](http://technet.microsoft.com/en-us/sysinternals/bb896653)? You can do a handle search for the DLL name and see exactly what process is still holding on to the DLL - the IIS core service or the application pool. This might not tell you anything new, though. – Rup Mar 14 '12 at 10:21
  • We are having this exact same issue. – Dave Bish May 09 '12 at 14:42

1 Answers1

0

If you are running on IIS 6 or greater, you could just stop the specific application pool. However, what is the exact build command that is not overwriting the file? We use a TFS build automation step that copies our files out to a test server running IIS which has all the dlls in use and it is no problem. What I can't confirm is how it does that, I suspect it is using XCOPY but I can't be sure.

HunterX3
  • 338
  • 1
  • 6
  • 18