The StreamJsonRpc library offers JSON-RPC 2.0 over any .NET Stream, WebSocket, or Pipe. With bonus support for request cancellation, client proxy generation, and more.
Other
730
stars
149
forks
source link
Enable generation of proxies that implement multiple interfaces #1066
Previous to this, generated proxies allowed only one (primary) RPC contract interface.
They could also support "optional" interfaces to support [RpcMarshalable] scenarios, but this included a wire protocol difference (the optional interfaces would invoke methods with an integer prefix on each method name), and it wasn't exposed for direct use either.
Going forward for brokered services, we'd like to enable optional interfaces on them (https://github.com/microsoft/vs-servicehub/issues/225). The ideal way to expose this is for the brokered service client (that somehow knows which interfaces are supported by the service) to receive a proxy that implements all the right interfaces.
This change will allow such a client to accomplish the proxy side of the work. The part about the client somehow knowing which interfaces the service supports is outside the scope of this change and probably outside the scope of this library altogether.
I also improved the "skip visibility checks" method to consider all the interfaces the proxy must cover rather than just the primary one.
This is required for microsoft/vs-servicehub#231, which targets the scenario described by microsoft/vs-servicehub#225.
Tips for code reviewers
Use this view instead of the default github code review UI, since the suggested view will make it clearer which code changed vs. just had indentation changes.
Previous to this, generated proxies allowed only one (primary) RPC contract interface. They could also support "optional" interfaces to support
[RpcMarshalable]
scenarios, but this included a wire protocol difference (the optional interfaces would invoke methods with an integer prefix on each method name), and it wasn't exposed for direct use either.Going forward for brokered services, we'd like to enable optional interfaces on them (https://github.com/microsoft/vs-servicehub/issues/225). The ideal way to expose this is for the brokered service client (that somehow knows which interfaces are supported by the service) to receive a proxy that implements all the right interfaces. This change will allow such a client to accomplish the proxy side of the work. The part about the client somehow knowing which interfaces the service supports is outside the scope of this change and probably outside the scope of this library altogether.
I also improved the "skip visibility checks" method to consider all the interfaces the proxy must cover rather than just the primary one.
This is required for microsoft/vs-servicehub#231, which targets the scenario described by microsoft/vs-servicehub#225.
Tips for code reviewers