[python-win32] Loading C extensions in Python 2.6/2.7 from classic ASP

[Mark Hammond]

On 7/09/2011 5:17 AM, Chris Lambacher wrote:
> Hi,
>
> Whenever I load an extension using the ActiveX Script for Python in a
> Classic ASP page, I get an error saying the DLL can't be loaded. I
> have solved this problem thus far by patching the distutils source for
> my local Python instance and rebuilding the extension (see
> http://groups.google.com/group/isapi_wsgi-dev/msg/aa11ed3058e73660).
> Thus far I have suffered no ill effects for doing this, but suspect
> that what actually needs to happen is that the DLL for the python com
> server needs to have the MSVCRT part of the manifest instead.
>
> I had a quick look at the setup.py for pywin32 build 216 and found the
> monkey patching of link that includes the _want_assemply_with_crt flag
> for perfmondata.dll and PyISAPI_loader.dll. Should that list also
> include the COM Server DLL? Is there a better way to solve this than
> rebuilding all my compiled extensions to include the full manifest or
> am I stuck with rebuilding all the time?

"In theory" (gotta love that), COM objects should now be hosted by 
pythoncomloader.dll.  This DLL should be built with the CRT manifest 
included, and the DLL itself has some hacks which should mean the 
extension modules then loaded don't need the manifest reference - these 
hacks are the same as made by Python itself (ie, any module which 
imports correctly under normal Python should also import correctly in a 
COM object hosted by pythoncomloader.dll.  See _build_pycom_loader in 
the pywin32 setup.py.

Is it possible the registration process for asp is still using 
pythoncomxx.dll as the COM entry-point instead of pythoncomloaderxx.dll?

In other words, when you say:

 > what actually needs to happen is that the DLL for the python com
 > server needs to have the MSVCRT part of the manifest instead.

I believe it already should.  Which isn't to say you aren't having a 
problem - it is just I don't quite understand it :)

Mark.