markekraus
commented
6 years ago I have looked at doing this before. There is no connection (at least that I could fine) between the deserialized object in the calling session and the original object in the remote session. In order to do this you have to maintain a map to all the objects in the remote session, marshal calls to the method in the calling session to the remote session, deserialize the return objects[s], and map the returned deserialized local objects to the original remote objects.
In doing so, you also deny the GC in the remote session from disposing unused objects unless you also implement some kind of GC handler in both the calling and remote sessions. You can't let any object in the remote session fall to the GC because it may sill be in scope in the calling session.
Additionally, this becomes really messy with things like collections and nested objects returned from the remote session, you have to map all the nested objects because the user may call a method on the collection, an Item of a collection, or a child of any depth of the item or collection.
You could provide partial functionality for it through primary returned objects without nesting, but I suspect that would lead to a bunch of really unexpected behavior, user frustration, and support issues.
IMO, this is something that would need to be implemented in PowerShell itself, as remoting in general would benefit from it. Though, I suspect the cost and complexity may not be worth it.
Just like with remote sessions, when you need to call methods on a remote object, the user should use Invoke-Command, the the case of this module, it would be Invoke-WinCommand
BrucePay
Limitation of using implicit remoting is that the objects are "dead" and any .Net methods on the object cannot be called. However, we should be able to either use ETS to overload the methods or use a custom type that has the methods so that method invocation goes back over implicit remoting and make it a "live" object.