On 9/09/2011 12:58 PM, Chris Lambacher wrote:
Hi Mark,
It is not Wow64. I did a very basic test to see what I get. I
installed 2.7.2 x64 and appropriate pywin32 216, and lxml 2.3, throw:
<script language="python" runat="server">
import sys
Response.Write(sys.version)
import lxml.etree
Response.Write("<br>Worked")
</script>
into an ASP file and get:
2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)]
Python ActiveX Scripting Engine error '80020009'
Traceback (most recent call last): File "<Script Block>", line 3, in
<module> import lxml.etree ImportError: DLL load failed: The specified
module could not be found.
I guess you are saying that that module will have no reference to the
CRT assembly and that you will rebuild it so it does and that will fix
the problem?
If so, that surprises me. To get as far as you did, much of the pywin32
framework was imported, so all those modules must have imported OK.
Apologies if I'm mis-understanding (ie, if it is vice-versa - you need
to rebuild to *remove* the manifest reference) - I'm very busy at the
moment and about to head to the US for a week - I haven't even dug into
the changes you made to distutils to see exactly what they are doing...
Mark
/test/test.asp, line 4
import lxml.etree
Looks like I am continuing to rebuild things for the time being :(
-Chris
On Tue, Sep 6, 2011 at 11:24 PM, Chris Lambacher<ch...@kateandchris.net> wrote:
Hi Mark,
I make changes to *other* extensions. I documented the change I made
to distuils here:
http://groups.google.com/group/isapi_wsgi-dev/msg/aa11ed3058e73660
Basically I disable the step that filters the MSVCRT out of the
manifest. And then re-build the extension. I have not yet ventured
into building Pywin32. I ended up modifying distutils because of a
link to a Python bug when I searched for the error I got when loading
a C extension. | can't remember which bug and I would have to muck
with things to generate the error again, which I will do, just not
tonight :)
I have not tried using x64 all the way though, mostly because when I
got started with this project I wanted to use Psyco (which was a
miserable failure that I have given up on), which only support x86.
I'll try to do a simple x64 test and see what I get. I am on win7 so I
can select x64 or x32 Application Pools in IIS and not disrupt my
other work.
I have also determined that I have no reference to pythoncom26.dll,
only pythoncomloader26.dll, in my registry.
-Chris
On Tue, Sep 6, 2011 at 11:09 PM, Mark Hammond<mhamm...@skippinet.com.au> wrote:
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.
--
Christopher Lambacher
ch...@kateandchris.net
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
