On 7/09/2011 12:56 PM, Chris Lambacher wrote:
Hi Mark,
It looks like it is trying to use pythoncomloader26.dll. Maybe it is
to due with the Wow64 stuff? I've pasted the Registry values below in
case you can get any insight into it. If you have any suggestions
about how to go about debugging it. I am happy to put a little effort
in here on my end, but this stuff is a little bit beyond my
experience.
That looks right to me. The Wow64 stuff could well be an issue - it
appears you have the 32bit version of Python installed (and therefore
its COM objects got registered in Wow6432Node) which means these objects
will only work with a 32bit version of ASP - but I'm not sure how ASP
gets packaged these days on a 64bit OS.
However, as you mentioned your problem goes away simply rebuilding the
pywin32 extensions with different flags, it doesn't sound like a simple
32bit/64bit problem - can you find the exact changes you had to make to
the build process to get things working?
Mark
Thanks,
Chris
Here are what I think are the registry values for the ActiveX Script
registration:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}]
@="Python ActiveX Scripting Engine"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Debugging]
@="0"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
Categories]
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
Categories\{B3EF80D0-68E2-11D0-A689-00C04FD658FF}]
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
Categories\{F0B7A1A1-9847-11CF-8F20-00805F2CD064}]
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\Implemented
Categories\{F0B7A1A2-9847-11CF-8F20-00805F2CD064}]
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\InprocServer32]
"ThreadingModel"="both"
@="pythoncomloader26.dll"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\LocalServer32]
@="C:\\Python26\\pythonw.exe
\"C:\\Python26\\lib\\site-packages\\win32com\\server\\localserver.py\"
{DF630910-1C1D-11d0-AE36-8C0F5E000000}"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\ProgID]
@="Python.AXScript.2"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\PythonCOM]
@="win32com.axscript.client.pyscript.PyScript"
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{DF630910-1C1D-11d0-AE36-8C0F5E000000}\VersionIndependentProgID]
@="Python"
On Tue, Sep 6, 2011 at 10:28 PM, Mark Hammond<skippy.hamm...@gmail.com> wrote:
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.
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
