Make support for marshaled objects available for custom types

[matteo-prosperi]

Could you please consider making marshaled object support available for custom interfaces?

The goal would be to allow an RPC interface to expose APIs like

public interface IMyServer
{
  Task<IFoo> GetSomethingAsync();
  Task GiveSomethingAsync(IBar bar);
}

The caller would call await GetSomethingAsync() and receive a disposable proxy of an IFoo object.
The caller would call await GiveSomethingAsync(bar) and the server would receive a disposable proxy for the bar object.

Calls to methods exposed by the IFoo and IBar proxies would result in RPC calls and the corresponding method being executed on the corresponding object.

The receiver of a marshaled object will be responsible for disposing of the proxy. I am not sure if it should be mandatory for interfaces that are marshaled as objects to be IDisposable (i.e., interface IFoo : IDisposable and interface IBar : IDisposable).

This feature request doesn't cover any other members other than methods (e.g. properties), I don't have a use case for that.

Thanks

[AArnott]

The place to start investigation of this feature is probably here:

vs-streamjsonrpc/src/StreamJsonRpc/Reflection/MessageFormatterRpcMarshaledContextTracker.cs

Line 23 in 114ee4f

(typeof(IDisposable), new JsonRpcProxyOptions { MethodNameTransform = CommonMethodNameTransforms.CamelCase }, new JsonRpcTargetOptions { MethodNameTransform = CommonMethodNameTransforms.CamelCase }),

This line (and the surrounding array) is what controls which types will get marshaled instead of serialized.

At the moment this is a static list. I believe the static list should remain, but any use of that list may be augmented with another list that is maintained on a per-JsonRpc instance basis, or perhaps by checking for an attribute on the interface being tested.

I think we should start with requiring any additional interfaces to derive from IDisposable, since that makes it more obvious to the receiver that they should dispose of these proxies. If we need to we can always remove that requirement, but adding it later would be a breaking change, so I prefer to start conservatively.