This project is read-only.

Remoting with MarshalByRefObject and IDynamicMetaObjectProvider

Jun 19, 2010 at 11:38 PM

I expose an IDynamicMetaObjectProvider object from my host application to a Python scope (using SetVariable).

This works very well and my object behaves like a dynamic object as long as the Python engine is in the same AppDomain as my host.

As soon as the Python engine is in a second AppDomain, the objects are remoted through MarshalByRefObject. And now Python totally ignores the fact that they implement IDynamicMetaObjectProvider. I can access the regular members normally, but the dynamic code is not called anymore. My dynamic objects have become plain .NET objects.

I think the problem is because IronPython doesn't see my "real" object but only a Marshalled proxy. So there's no way to call the relevant methods on the scripting side...

Is this a limitation of the IronPython? Is there a way to have dynamic objects accross two AppDomain?

Jun 22, 2010 at 9:49 PM
Edited Jun 22, 2010 at 9:51 PM

Just for your information, I worked around the problem.

To solve all my lifetime and IDynamicMetaObjectProvider problems I did the following thing: I created one single classe, very much like a web service, which exposes all methods available to manipulate the application from scripts. There is no state, all parameters and return values are simple serializable objects, and the class is a kind of singleton. It's kept alive as long as I need it through the use of a sponsor on the host domain side.

Then I created all my API on top of that "service" directly in Python. That way I can easily use all the Python dynamic features, and objects have GC, no remoting or lifetime issues. It works well.

Of course, remoting is really trickier than it looks... A bug slipped through. Since I'm capturing Python output in a stream (IO.SetOutput), the stream is remoted and I have to keep it alive with a sponsor, too.. *sigh*

Jan 22, 2015 at 12:00 PM
Hi! It's still a question. Is that a limitation? How can I pass dynamic objects when using separate AppDomain?
Jan 29, 2015 at 12:06 AM

Hey, nlacka, very sorry for the incredibly long delay in response. No one has really worked on this stuff since 2010 when we released it to the community and quit working on ironpython. A couple of the devs are still around but don't recall all the remoting stuff. IIRC dynamic objects just don’t work across AppDomains. The hosting APIs used ObjectHandles to manipulate remote objects.

We did put some specific support in the DLR binder to make it possible. See where we have “AddRemoteObjectRestrictions”. But it’s up to languages to make this work properly, and that is actually kind of difficult to do as MBROs respond to interface checks rather aggressively.

For IronPython the route we suggested was to use a proxy object – that is pretty easy to create in Ipy.

NOTE: to further this discussion or for other questions about the DLR, please go to the new Roslyn site: . I put a notice on the home page of the DLR site that these sources are moving to github. The stuff that shipped with VS/.NET is moving, but the stuff that only released on codeplex will stay on codeplex. The team/project that continues to own this stuff is the Roslyn project.