Which IIS version? Is the filter configured as a site or global filter?
Depending on IIS version and sequence of events, you have not shown that
your actions cause an ISAPI Filter to be unloaded (and hence unlocked). For
example:
- if IIS5 and global filter, restarting W3SVC will simply re-load the filter
into memory
- if IIS5/6 and removing from global filter list (I presume you are removing
it from the metabase and not registry [old compat hack]), filter stays in
memory
- if IIS5 and removing from site filter list the filter stays in memory
In other words, you said some of the right things, but ordering matters as
to whether the filter DLL is loaded in memory and hence locked.
Caveats when using managed code with ISAPI, especially ISAPI Filters
http://blogs.msdn.com/david.wang/arc...aged_Code.aspx
I would not use .Net with ISAPI Filter unless you forever use only one
version of .Net at any given time. And even then, why inject managed code
processing into every single request?
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Drew Burchett" <dr**@burchett-family.com> wrote in message
news:eN*************@TK2MSFTNGP05.phx.gbl...
I am currently coding an ISAPI filter and I would like to use some .Net
functionality within the filter. However, when I include calls to anything
in the framework, it locks the dll and will not release it until I restart
the machine. Even after restarting the W3SVC and removing it from the list
of ISAPI filters, it still has a lock on it. Any ideas why?
