[Python.NET] path question: clr.so being picky about paths

Christian Heimes lists at cheimes.de
Wed Dec 3 13:13:04 CET 2008

Link, Hamilton wrote:
> - clr.so bootstraps mono (under Windows the OS knows how to dlload a .net assembly already) to enable .net assembly extensions and I assumed perhaps recklessly that it laterals to clr.pyd

The code in src/monoclr is compiled to a shared library (.so on most 
Unices and .dyload on Mac OS X) and a standalone Python executable. The 
library is a Python extension which initializes Mono, loads the 
Python.Runtime assembly and initializes the rest of PythonDotNET. 
Finally the clr module is replaced by the clr module from PythonDotNET.

However the code is currently broken. svn blame points to r98 jfrayne. :)

> - clr.pyd loads Python.Runtime.dll

clr.pyd is a Windows and .NET only Python extension that loads the runtime.

The clr.so/pyd/dyload module is only required when you want to embed 
.NET code into CPython. For the other way around it's not required.

> - Python.Runtime.dll, regardless of platform, turns around and uses P/Invoke to connect into the libpython2.5.so/dll, and then you're all set

Yeah. The Python.Runtime assembly also provides the clr module you can 
see inside Python and the import hook to import namespaces from .NET 


More information about the PythonDotNet mailing list