I'm using pythonnet clr within a django application. If I run my django server from the command line, everything works fine. But if I run my server from within apache and mod_wsgi, any call to a django-generated page hangs. (calls to apache-served stuff, like /server-status still work)
I've been able to duplicate this issue on both Windows 7 64-bit and Windows Server 2008 32-bit.
I've attached a zipfile containing a sample project. To run it, you'll need Django, apache, mod_wsgi and pythonnet. This is about as simple a setup as I could think of. The httpd.conf file is in the apache directory -- you'll probably have to copy that to your system's apache conf directory, and you'll have to change the directory paths (look in django.wsgi and httpd-9002.conf for "ccurvey")
To see the system WITHOUT the problem:
1) Go to settings.py and comment out the "import clr"
2) Start your apache server
3) Hit http://localhost:9002/server-status (just to be sure apache is working)
3) hit http://localhost:9002/ -- you will see a "welcome to django" page.
To see the system WITH the problem:
1) Go to settings.py and make sure "import clr" is not commented
2) (re)Start your apache server
3) Hit http://localhost:9002/server-status (just to be sure apache is working)
3) hit http://localhost:9002/ -- the system will hang until you restart the server.
Envrionment
pythonnet-2.0-alpha2-clr2.0_py26
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32
mod_wsgi-win32-ap22py26-3.0.so
Apache 2.2.15
This sounds like SxS hell (formerly DLL hell) that I'm tracking down a solution for at the moment.
First, I'll push the latest version of the py26 build to the download area.
Second, let's make sure that you are launching one of the "real" cPython executables and relying on late binding of the import hook which may be doing some environment setup that doesn't occur in the managed version.
Lastly ,a temporary workaround may be to revert to python 2.5 it possible.
I'm sorry that I'm not set up to run your particular scenario, but I've been up one side and down the other of the -alpha2-clr2.0_py26 release wrt import of all sorts foreign libraries (ie: ctypes, comtypes, wxPython, etc), firing the python26.dll from both pure C python.exe and the managed console - in "Just for me" and "For everyone" installations and have been unable to break it anywhere. (Still struggling with python 2.7, though).
I've pushed one change that may help in tracking down your problem by reporting errors that occur during import sooner.
The most important thing to overcome is the dll search path. As long as clr.pyd can find the python.runtime.dll and the runtime can find the python26.dll and the 26 dll can locate the Microsoft.VC90.CRT (or at least the msvcr90.dll), everything should work just fine.