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:

• Updated to Python 2.7.12
• Updated the copy of my app's remoting DLL in c:\python27\dll
• Removed the old Python for .NET package
• Executed "pip install pythonnet", which gave me version 2.1.0.

In C:\Python27\Lib\site-packages\ I see:
clr.pyd
Python.Runtime.dll v 2.0.0.2
Python.Runtime.dll.config

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?

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.

@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.

@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.

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

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 theSession

with

def connect():
    theSession = System.Activator.GetObject(NXOpen.Session, "http://localhost:4574/Session")
    return theSession

Neat. The typedproxy code was needed when I was using IronPython to communicate with NX.

@jcarole I tried extracting your zip file and got an error about bad format.

@cadourian have you resolved your issue?

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

@callumnoble thanks for digging this! Your workaround looks reasonable, does this also work for @cadourian and @jcarole?

@denfromufa @callumnoble How/where do I get compiled bits to see if this fix works for me?

@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

@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.

@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

@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!

@jcarole only one issue is blocking 2.4 release:

#509

@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.

@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

@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

Resolved in #637