Repository navigation
.NET Remoting support broken #276
Description
Opening this issue per request from Denis Akhiyarov in PythonDotNet mailing list discussion.
Tried uploading a .zip file but got error "We don't support that file type." So here is a link to that file:
https://www.dropbox.com/s/66pkgd1m2l3kbmh/DotNetRemotingHelloWorld.zip?dl=0
Activity
jcarole commented on Oct 25, 2016
Forgot to copy original text from PythonDotNet mailing list discussion:
Does pythonnet-2.1.0 support .NET Remoting? When I try to get an interface, python 2.7 crashes:
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at Python.Runtime.ClassDerivedObject.ToPython(IPythonDerivedType obj)
at Python.Runtime.Converter.ToPython(Object value, Type type)
at Python.Runtime.MethodBinder.Invoke(IntPtr inst, IntPtr args, IntPtr kw, MethodBase info, MethodInfo[] methodinfo)
at Python.Runtime.MethodObject.Invoke(IntPtr target, IntPtr args, IntPtr kw,MethodBase info)
at Python.Runtime.MethodBinding.tp_call(IntPtr ob, IntPtr args, IntPtr kw)
It's getting past these lines in my script:
import clr
clr.Addreference(my remoting DLL)
from MyNamespace import *
and choking on a static method in my app's remoting DLL call which returns the interface. Through logging, I can tell that the code in that static method call is successfully executing:
(IMyInterface)Activator.GetObject(typeof(IMyInterface), url);
and returning the object back to Python.
This worked fine before when my app targeted .NET 3.5 and I used the CLR2 version of the Python for .NET package. Now my app targets .NET 4.5.2 so I:
In C:\Python27\Lib\site-packages\ I see:
clr.pyd
Python.Runtime.dll v 2.0.0.2
Python.Runtime.dll.config
jcarole commented on Oct 25, 2016
Denis's reply on PythonDotNet mailing list discussion:
Can you provide minimal reproducible code sample for both C# and Python?
What is the latest pythonnet version in which this works?
Are you testing this from interactive python or ipython? There are some
differences between the 2 options.
Please also open an issue on github.
BTW, why have you not switched to WCF?
jcarole commented on Oct 25, 2016
My reply on PythonDotNet mailing list discussion:
I only ever used pythonnet-2.0-alpha2-clr2.0_131_py27_UCS2 with Python 2.7.2, where it worked when controlling my .Net 3.5-based-based GUI app. I only updated my app to .NET 4.5.2 last week, which is the first time I tried CLR4-compatible PythonDotNet with Python 2.7.12.
Command shell: C:\Python27> python my.py
Yeah, I know, Remoting is deprecated : ( Need to learn about WCF and see what kind of pain it will cause my long-established user base.
den-run-ai commented on Oct 31, 2016
@jcarole I tried your example C# apps and it seems this has nothing to do with pythonnet, but rather only .NET 4.6 vs 3.5 differences. In fact 3.5 is the last version supported for .NET remoting.
jcarole commented on Nov 1, 2016
@denfromufa Sorry, config mgmt fail on my part. Updated the dropbox link with working C# code for the .NET 4.5.2 C# server and client. .NET Remoting may be deprecated, but it is definitely still working.
cadourian commented on Nov 30, 2016
Hi,
I was getting the same exact error as "jcarole commented on Oct 25 " using PythonNet 2.1.0 and then using 2.2.0 from Python 2.7.12 64-bit version and then I tried the python2.0.0 binaries from https://pypi.python.org/pypi/pythonnet/2.0.0
It all worked nicely after that. So, something is broken from 2.0.0 to 2.1.0 and onwards.
The example I used was to communicate with the CAD tool NX from Python.
The attached zip file provides the C# Server and Client codes that always work.
There is also the Python NXConnect.py file which is what I was using to talk to the C# server running in NX. The NXConnect.connect() command was failing with pytonnet 2.1.0 and 2.2.0 but worked with Python 2.0.0.
Hope this help debug the problem
NX10-Remote-IF.zip
cadourian commented on Nov 30, 2016
Well, in the example above, the code
a=NXConnect.connect() succeeds, but there are other issues with type casting which are fixed by not using the typedproxy class as follows:
Replace this code:
def connect(): theSession = typedproxy(System.Activator.GetObject(NXOpen.Session, "http://localhost:4574/Session"), NXOpen.Session) return theSessionwith
def connect(): theSession = System.Activator.GetObject(NXOpen.Session, "http://localhost:4574/Session") return theSessionNeat. The typedproxy code was needed when I was using IronPython to communicate with NX.
den-run-ai commented on Jul 21, 2017
@jcarole I tried extracting your zip file and got an error about bad format.
den-run-ai commented on Jul 21, 2017
@cadourian have you resolved your issue?
Fixed errors breaking .NET Remoting on method invoke (pythonnet#276)
callumnoble commented on Dec 20, 2017
I'm getting the same error here when using a library which uses .NET remoting internally.
As with submitter this worked on v2.0.0 and is broken in v2.1.0 onward.
I identified the issue and a workaround (2bbe5b1) that works for me. I don't know anything about .NET Remoting and can't be sure of any side effect (or other places in the code needing this)
regression introduced in 7e0226f
den-run-ai commented on Dec 20, 2017
@callumnoble thanks for digging this! Your workaround looks reasonable, does this also work for @cadourian and @jcarole?
jcarole commented on Feb 20, 2018
jcarole commented on Feb 21, 2018
@denfromufa @callumnoble How/where do I get compiled bits to see if this fix works for me?
den-run-ai commented on Feb 22, 2018
@jcarole i created a pull request with @callumnoble commit, feel free to grab the wheels/binaries from the build artifacts on this PR from Appveoyr CI:
#631
jcarole commented on Feb 22, 2018
@denfromufa Thanks Denis. I'm not sure exactly what you said means (I'm a github newbie), but I'll check the link you included during the day and hopefully find download links there or on the pages linked to by the details links.
den-run-ai commented on Feb 22, 2018
@jcarole here is direct link to one of builds, pick the one that corresponds to your Python version/architecture:
https://ci.appveyor.com/project/pythonnet/pythonnet/build/master-1147/job/a462ce019ao2nxle/artifacts
jcarole commented on Feb 22, 2018
@denfromufa Thanks for making this easy for me, Denis...it works! I haven't done exhaustive testing, but if I were to run into a problem with a specific feature, that would belong in its own issue. Is there a target date for releasing 2.4?
@callumnoble Thank you for taking the time to make this work!
den-run-ai commented on Feb 23, 2018
@jcarole only one issue is blocking 2.4 release:
#509
jcarole commented on Feb 24, 2018
@denfromufa Thanks Denis. From the comments on the 514 page, looks like robbmcleod submitted a fix. Is that a partial or complete fix? Just trying to gauge how close we may be to the release.
den-run-ai commented on Feb 24, 2018
@jcarole please provide your opinion on how to resolve that issue, but please read all comments and linked issues. What happened is that one fixed bug caused another regression for this particular CLR List <---> numpy.array conversion behavior. I'm not sure how to fix both of them at the same time without double-conversion like described in #451
den-run-ai commented on Feb 26, 2018
@callumnoble @jcarole this PR for .NET Remoting cannot be merged, because more general solution that would work on .NET Core is necessary. .NET Remoting is deprecated and its API is not available in .NET Core and .NET Standard. Here is a pull request with merged master:
#632
Fixed errors breaking .NET Remoting on method invoke (pythonnet#276)
Fixed errors breaking .NET Remoting on method invoke (pythonnet#276)
Merge pull request #637 from callumnoble/fix-remoting
den-run-ai commented on Mar 2, 2018
Resolved in #637