>Unfortunately, this just seems to be the way it works. If you have the NT Option pack installed (IIS4.0/Transaction Server) you will note that Transaction Server seems to pick up the thread that creates your COM object. The way I noticed this was that my COM object used SQL Pass Through. When I looked at the current activity in SQL Server, the owner of the query was "Transaction Server Explorer". Once the object has been instantiated by MTS it hangs around for a while. Even stopping the Web Server does not seem to release the COM object. Eventually it seems to time out.

That's because if you click 'Stop' in the IIS service manager you
don't actually stop the Web server...

Also, COM components run only in MTS if you use 'separate application'
as Gary pointed out, otherwise they run in the IIS context. Regardless
of either IIS never releases InProc components while running.

For ISAPI extensions you can also uncheck the 'Cache Extensions' option
which forces extensions to load and unload on each hit - I'm not sure
offhand whether this has any effect on COM objects loaded.

+++ Rick ---


>
>This is probably intentional behavior of MTS (for speed reasons - if someone else needs the COM object it's faster to have it lying around than to reload the DLL) but it annoying during development. I usally test out my COM objects from VFP first until I'm pretty sure that they are stable before testing in ASP.
>
>>Hi All.
>>I created COM object with VFP(mydll.dll) and call this object from ASP
>>page like set yy = createobject("mydll.abc").
>>At the end of script i do set yy = nothing.
>>Everything works fine. But if I need to recreate this dll it gives me
>>error that permission denied even i closed all other application and
>>web browser.Only after rebooting computer i can recreate this dll.
>>I use IIS4 and it seems to me that web server is holding this dll
>>even though i no longer use it service.
>>Any ideas?
>>Thank you . Alex