I downloaded the pythonnet-2.0-alpha2-clr2.0_py25 version of Python for .NET code. In a 32-bit compiled version it works beautifully for me. We use Front Arena, an OMS from Sungard, and Front Arena uses Python 2.5 as its extension language. That is, we can extend Front Arena functionality by writing our own Python scripts that integrate with Front Arena. Unfortunately, the GUI builder that comes with Front Arena is poor. Therefore, we decided to build our GUI using WinForms with C# .NET and call our Python code through your Python for .NET Python.Runtime.dll. I have integrated your source code for Python.Runtime into my project.
When running the 32-bit version of Sungard’s Front Arena (which uses python25.dll – a different version for the 32-bit vs. 64-bit versions of Front Arena) everything works great! My C# UI can instantiate the Python.Runtime.dll (“PythonEngine.Initialize();”) which successfully loads the PythonEngine. We connect to Front Arena and then run methods on Front Arena python modules (using _acmModule = PythonEngine.ImportModule("acm"); and then “InvokeMethod”). We also load our own custom python modules.
In order for the Front Arena python modules to be found, I modify my PYTHONPATH by setting my environment variables in C# (e.g. “Environment.SetEnvironmentVariable("PYTHONPATH", @"C:\Program Files\Front\Front Arena\PRIME\2009.2;C:\Program Files\Front\Front Arena\CommonLib\PythonLib25;C:\Program Files\Front\Front Arena\CommonLib\PythonExtensionLib25;" + runPath + ";");” before calling any of your code.
My problem arises when I change my .NET project to compile to 64-bit. When I do that, I notice that none of the paths set in the PYTHONPATH seem to get recognized, and therefore python modules in those paths then cannot be loaded (the “ImportModule” method fails).
Under 32-bit, when I look at the “UpdatePath” method in your assemblymanager.cs, I can see each path that I set in the environment variable above. However, under a 64-bit compilation, the code runs but does not show any of the expected paths from my environment variable. Instead, I see only generic looking paths such as ".\\DLLs", ".\\lib", etc.
Any insight you can provide would be greatly appreciated.
Thanks,
Gene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Was there any resolution here? I too am working with Front Arena, migrating from python v2.5 to v2.6. I have simplified my example so that it is failing outside of Front Arena.
import os
import sys
from datetime import datetime, timedelta
sys.path.append('c:\Python26\Lib\site-packages\Clr') #Contains two files: clr.pyd and Python.Runtime.dll.
import clr
clr.AddReference("SomeProduct")
from SomeProduct import ObjectName
clr.AddReference("MyHelpers")
from MyHelpers import CreateLists
MyListVar = CreateLists.CreateVbList1()
print MyListVar.Count
x=Failhere()
File "TestClr.py", line 6, in <module>
import clr
ImportError: DLL load failed: %1 is not a valid Win32 application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I downloaded the pythonnet-2.0-alpha2-clr2.0_py25 version of Python for .NET code. In a 32-bit compiled version it works beautifully for me. We use Front Arena, an OMS from Sungard, and Front Arena uses Python 2.5 as its extension language. That is, we can extend Front Arena functionality by writing our own Python scripts that integrate with Front Arena. Unfortunately, the GUI builder that comes with Front Arena is poor. Therefore, we decided to build our GUI using WinForms with C# .NET and call our Python code through your Python for .NET Python.Runtime.dll. I have integrated your source code for Python.Runtime into my project.
When running the 32-bit version of Sungard’s Front Arena (which uses python25.dll – a different version for the 32-bit vs. 64-bit versions of Front Arena) everything works great! My C# UI can instantiate the Python.Runtime.dll (“PythonEngine.Initialize();”) which successfully loads the PythonEngine. We connect to Front Arena and then run methods on Front Arena python modules (using _acmModule = PythonEngine.ImportModule("acm"); and then “InvokeMethod”). We also load our own custom python modules.
In order for the Front Arena python modules to be found, I modify my PYTHONPATH by setting my environment variables in C# (e.g. “Environment.SetEnvironmentVariable("PYTHONPATH", @"C:\Program Files\Front\Front Arena\PRIME\2009.2;C:\Program Files\Front\Front Arena\CommonLib\PythonLib25;C:\Program Files\Front\Front Arena\CommonLib\PythonExtensionLib25;" + runPath + ";");” before calling any of your code.
My problem arises when I change my .NET project to compile to 64-bit. When I do that, I notice that none of the paths set in the PYTHONPATH seem to get recognized, and therefore python modules in those paths then cannot be loaded (the “ImportModule” method fails).
Under 32-bit, when I look at the “UpdatePath” method in your assemblymanager.cs, I can see each path that I set in the environment variable above. However, under a 64-bit compilation, the code runs but does not show any of the expected paths from my environment variable. Instead, I see only generic looking paths such as ".\\DLLs", ".\\lib", etc.
Any insight you can provide would be greatly appreciated.
Thanks,
Gene
Hi Gene,
I am encountering the same problem: different behavior between 64 bits and 32 bits environment.
Have you got any update to share?
Was there any resolution here? I too am working with Front Arena, migrating from python v2.5 to v2.6. I have simplified my example so that it is failing outside of Front Arena.
import os
import sys
from datetime import datetime, timedelta
sys.path.append('c:\Python26\Lib\site-packages\Clr') #Contains two files: clr.pyd and Python.Runtime.dll.
import clr
clr.AddReference("SomeProduct")
from SomeProduct import ObjectName
clr.AddReference("MyHelpers")
from MyHelpers import CreateLists
MyListVar = CreateLists.CreateVbList1()
print MyListVar.Count
x=Failhere()
File "TestClr.py", line 6, in <module>
import clr
ImportError: DLL load failed: %1 is not a valid Win32 application.