Unloading COM dlls, help needed

[logistix]

Thomas Heller <theller at python.net> wrote in message news:<r8b3sj45.fsf at python.net>...
> Sorry for the somewhat offtopic question, but I know here is an
> interested and competent audience available to answer questions.
> 
> Background:
> 
> I'm implementing a COM server framework in pure Python (TM) on base of
> the ctypes module.
> 
> Everything works very nice - I have a Shell Extension which extends
> the Explorer context menu for .py files, it lets you run tools like
> PyChecker and reindent.  I have also started some ActiveX controls
> which can be shown in several containers, IE among them (not all
> possible interfaces are implemented, but it is already very
> interesting).
> 
> Everything - except the dlls (_ctypes.pyd, together with python22.dll
> and others) are never unloaded from the process.  This makes
> development very slow, I have to restart Explorer each time I want to
> change the source files.
> 
> I think I got everything correct, COM reference counting seems OK,
> DllCanUnloadNow returns correct values, all I can think of.
> 
> A control implemented in ATL, IIRC, behaves different.
> 
> Reading through the MSDN docs shows that it may take 10 minutes after
> the call to CoFreeUnusedLibraries() before the dlls are actually
> unloaded, I've even waited longer, but nothing happpens.
> 
> This leads me to my question: Are there any other things that may
> prevent dlls from being unloaded by COM?
> 
> My understanding is that each DLL mapped into a process has an
> internal reference count, and the DLL is unloaded when this reaches
> zero.  Since Python itself calls LoadLibrary on the _ctypes.pyd (which
> is the COM dll), can it be that this circular reference between the
> dlls prevent unloading?  Oh, btw: is there *any* way to get this
> refcount?
> 
> Or could it simply be that unmatched CoInitialize/CoUninitialize calls
> are responsible?
> 
> Note that I've read the pycom-dev archives the reason why Mark's
> PythonCOM is never unloaded - it returns S_FALSE from
> DllCanUnloadNow() because Python can never be shutdown safely in a
> running process, but I want to try it anyway.
> 
> Any help appreciated,
> 
> Thomas

Did you try to setup an MTS (relabelled 'COM Services' as part of the
COM+ strategy) package around the components?

This will allow you to fake out COM and run in-apartments out of
process.  Then you can kill the MTS package (and attached processes)
explicitly from the MTS mmc.  Saved my ass when I was developing
back-end COM components that IIS was putting locks on.