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.

StreamJsonRpc StreamJsonRpc is a cross-platform, .NET portable library that implements the JSON-RPC wire protocol. It works over Stream, WebSocket, or System.IO.Pipelines pipes, independent of the underlying transport. Bon

Information

Category: .NET / RPC framework
Watchers: 36
Star: 623
Fork: 141
Last update: Mar 17, 2023

Resource links

https://github.com/Microsoft/vs-streamjsonrpc

StreamJsonRpc

StreamJsonRpc is a cross-platform, .NET portable library that implements the JSON-RPC wire protocol.

It works over Stream, WebSocket, or System.IO.Pipelines pipes, independent of the underlying transport.

Bonus features beyond the JSON-RPC spec include:

Request cancellation
.NET Events as notifications
Dynamic client proxy generation
Support for compact binary serialization via MessagePack
Pluggable architecture for custom message handling and formatting.

Learn about the use cases for JSON-RPC and how to use this library from our documentation.

Supported platforms

.NET Standard 2.0 (e.g. .NET Framework 4.7.2, .NET Core 2.1+)

Compatibility

This library has been tested with and is compatible with the following other JSON-RPC libraries:

json-rpc-peer (npm)
vscode-jsonrpc (npm)

39 Open More issues

Closed

Spec proposal: support for IProgress<T>

The following is a proposal for an extension to the JSON-RPC protocol that serves as a means for a server to provide progress reports on an invoked method to the client, leading to a final result.

In C#, this might be expressed as IProgress<T>. A server method signature might take this form:

async Task DoSomeHeavyWorkAsync(int units, IProgress<WorkUpdate> progress);

A request might look like this:

{
  "jsonrpc": "2.0",
  "id": 153,
  "method": "someMethodName",
  "params": {
    "units": 5,
    "progress": "some-JSON-token"
  }
}

The progress argument may have any name or position, and may have any valid JSON token as its value. A value of null is specially recognized as an indication that the client does not want progress updates from the server. This argument may not be recognizable as an IProgress<T> token from the request, but the JSON-RPC library can offer a means for an application to specify that this argument is used as a progress token during a callback to the client.

For instance, in the above C# method signature, the IProgress<WorkUpdate> parameter type would signify to the JSON-RPC library that it should reinterpret the second/"progress" argument as a progress token and instantiate an IProgress<WorkUpdate> instance whose Report method will send the response message as specified below, carrying that token.

A JSON-RPC client may find it convenient to simply reuse the value from the id in the request itself, but may choose to avoid this so that multiple progress arguments can be passed in via the same request. This would enable different progress updates or frequencies to be supplied at the client's discretion. The progress token SHOULD be unique to the session so that any progress callbacks from the server can be distinctly routed to the right handler on the client side.

In processing such a message, the server provides updates to the client via a notification sent back to the client. These notifications use the special method name $/progress. For example:

{
  "jsonrpc": "2.0",
  "method": "$/progress",
  "params": {
    "token": "some-JSON-token",
    "value": { "some": "status-token" }
  }
}

Parameters are (progressToken, value), which may be named in a params object or as a params array in that order. progressToken must match the value of the argument from the request that progress is being reported for. The value property in this $/progress message may be set to any json token representing the update from the server. It may be a number, string, bool, object, or even the null literal.

Implementation notes

It is conceivable that client applications of a JSON-RPC library that supports this feature would expect that progress notifications are raised to the application in order, and possibly all before the outbound RPC call is marked completed. In multi-threaded environments this can introduce special considerations. In .NET for example, the IProgress<T> interface makes such guarantees hard, and we'll likely need to document that folks use a particular implementation of that interface that guarantees ordering, and also suggest ways to mitigate the chance of their async call completing before the last progress message has been recognized by the client.

enhancement

opened Aug 11, 2018 by AArnott 42

Closed

Add support for IAsyncEnumerable<T>

IAsyncEnumerable<T> is here and it's a more natural fit than Progress<T> when the RPC method wants to exchange data as its result instead of simply reporting progress about its result.

We should add support for it.

For downlevel framework versions, this type is defined in the Microsoft.Bcl.AsyncInterfaces package.

In the spec here, we use the term generator to refer to the app-level implementation of IAsyncEnumerable<T> that produces the values, and consumer to refer to the app-level enumeration of those values. We avoid the terms server and client because the IAsyncEnumerable<T> may be passed to the server via an RPC method argument or passed to the client via an RPC return value.

Sample use case

A server method which returns an async enumeration may be defined as:

IAsyncEnumerable<int> GenerateNumbersAsync(CancellationToken cancellationToken);

Per C# 8 syntax this may be consumed via:

await foreach (int number in this.clientProxy.GenerateNumbersAsync(token))
{
    Console.WriteLine(number);
}

The server method may be implemented in C# 8 as:

public async IAsyncEnumerable<int> GenerateNumbersAsync([EnumeratorCancellation] CancellationToken cancellationToken)
{
    for (int i = 1; i <= 20; i++)
    {
        cancellationToken.ThrowIfCancellationRequested();
        await Task.Yield();
        yield return i;
    }
}

We must support methods which return IAsyncEnumerable<T>. We may also support methods which take IAsyncEnumerable<T> as parameters.

State machine internals

The following describes how IAsyncEnumerable<T> return types will be supported. IAsyncEnumerable<T> method parameters may be supported later.

Client invocation results in an RPC call, and the server invokes the method that returns an IAsyncEnumerable<T>. A C# async-iterator method will return this object without executing user code within the method. The resulting IAsyncEnumerable<T> object will be immediately converted to an IAsyncEnumerator<T> object by the RPC server and this object will be retained. A handle to this enumerator instance will be returned to the RPC client.
The RPC client exposes an IAsyncEnumerable<T> object to the caller, whose GetAsyncEnumerator method will only work once. Subsequent calls to this method will throw InvalidOperationException. To repeat the enumeration, the RPC client should call the RPC method again.
When the RPC client application calls IAsyncEnumerable<T>.GetAsyncEnumerator(CancellationToken), the RPC client library produces an IAsyncEnumerator<T> instance which handles the RPC layer and emulates a local async enumerator. The CancellationToken passed to it applies to each RPC call to the server when asking for more value(s).
When the client application calls DisposeAsync on the IAsyncEnumerator<T>, an RPC call is made to the server so the server can release the memory holding the server's original IAsyncEnumerator<T> in memory.

If the originating request or a subsequent request for values is ever canceled, this cancels the entire enumerator. It is not possible to obtain more values after a request for more values is canceled. However clients must still dispose of the enumerator if they ever received the enumerator handle in response to their originating request.

When the client makes the request on a dynamically generated proxy, and the method returns IAsyncEnumerable<T> directly (not wrapped in Task<T>), the RPC client proxy will have to create an IAsyncEnumerable<T> implementation that is available immediately, and ends up waiting for the async RPC call to complete before returning from the proxy's private implementation of IAsyncEnumerator<T>.MoveNextAsync().

Performance tuning

The IAsyncEnumerator<T> interface is defined assuming that every single value produced may be acquired asynchronously. Thus an RPC implementation of this feature might be that every request for a value results in an RPC call to request that value. Such a design would minimize memory consumption and cost of generating values unnecessarily, but would be particularly noisy on the network and performance would suffer on high latency connections.

To improve performance across a network, the RPC layer will support:

Batching: When the consumer requests a value from the generator, the server may respond with the next several values in the same response message in order to reduce the number of round-trips the client must make while enumerating the sequence. This improves performance when network latency is significant.
Read ahead: The generator will do work to produce the next value(s) before receiving the consumer's request for them. This allows for the possibility that the server is processing the data while the last value(s) are in transit to the client or being processed by the client. This improves performance when the time to generate the values is significant.

The above optimizations are configured individually, and may be used in combination.

To accomplish this, we define these properties which tune the RPC bridge for async enumerables:

        /// <summary>
        /// Gets or sets the maximum number of elements to read ahead and cache from the generator in anticipation of the consumer requesting those values.
        /// </summary>
        public int MaxReadAhead { get; set; }

        /// <summary>
        /// Gets or sets the minimum number of elements to obtain from the generator before sending a batch of values to the consumer.
        /// </summary>
        public int MinBatchSize { get; set; } = 1;

The default values for these properties will result in the same behavior as one would observe with IAsyncEnumerable<T> without any RPC: one value is produced or consumed at a time. Individual services may choose based on expected use cases and performance costs to change these values to improve the user experience.

These properties are defined on the new JsonRpcEnumerableAttribute, which may be applied on the return type of a server method implementation. It will be ignored if used within an interface declaration. For example, the aforementioned C# 8 server method may be defined like this in order to provide all the values to the client in batches of 10:

[return: JsonRpcEnumerable(MinBatchSize = 10)]
public async IAsyncEnumerable<int> GenerateNumbersAsync([EnumeratorCancellation] CancellationToken cancellationToken)
{
    for (int i = 1; i <= 20; i++)
    {
        cancellationToken.ThrowIfCancellationRequested();
        await Task.Yield();
        yield return i;
    }
}

A batch size of 10 with the default MaxReadAhead value of 0 means the server will not produce any values until the client requests them, but when the client requests them, the client will get 10 or the rest of the sequence, whichever is fewer.

Suppose MaxReadAhead = 15 and MinBatchSize = 10. After the client calls GenerateNumbersAsync but before it asks for the first element in the sequence, the server is already generating values till it fills a cache of 15. When the client request comes in for the first value(s), the server will wait till at least 10 items have been produced before returning any to the client. If more than 10 were cached (e.g. the server was able to produce all 15 as part of "read ahead"), the client will get all that are cached. After the client's request is fulfilled, the read ahead server will continue generating items till the read ahead cache is full, in preparation for the next client request.

In short: MinBatchSize guarantees a minimum number of values the server will send to the client except where the sequence is finished, and MaxReadAhead is how many values may be produced on the server in anticipation of the next request from the client for more values.

The state machine and any cached values are released from the generator when the IAsyncEnumerator<T> is disposed.

JSON-RPC Protocol details

Originating request

The original RPC request to the IAsyncEnumerable<T> returning method includes a special expect: "enumerableResponse" property to indicate to the server that it is capable of understanding the lifetime requirements of the returned object. This is important because upon successful completion of this particular RPC call, the server will now retain memory on behalf of the client that may be a memory leak if the client never follows up with another call to the server to release the memory. An RPC call to an IAsyncEnumerable<T>-returning method that lacks this property should result in the server returning an error response and not invoking the method.

{
   "jsonrpc": "2.0",
   "id": 1,
   "method": "GenerateNumbersAsync",
   "params": [ "some", "parameters"],
   "expect": "enumeratorResponse",
}

If the request omits the id property, the client will not get a result, and the server should either reject the request or execute the method but discard the result without leaking memory.

Originating result

A successful result provides the handle to the server's enumerator, which may be any valid JSON token except null:

{
   "jsonrpc": "2.0",
   "id": 1,
   "result": "enum-handle"
}

Client request for values

A request for value(s) from the client:

{
   "jsonrpc": "2.0",
   "id": 2,
   "method": "$/enumerator/next",
   "params": { "token": "enum-handle" },
}

Server response with values

A response with value(s) from the server always comes in an array, even if only one element is returned:

{
   "jsonrpc": "2.0",
   "id": 2,
   "result": {
      "values": [ 1, 2, 3 ],
      "finished": false
   }
}

Note the finished property is a hint from the server for when the last value has been returned. The server may not know that the last value has been returned and should specify false unless it is sure the last value has been produced.

The client may ask for more values without regard to the finished property, but if finished: true the client may optimize to not ask for more values but instead go directly to dispose of the enumerator.

The server should never return an empty array of values unless the last value in the sequence has already been returned to the client.

Client disposes enumerator

The client always notifies the server when the local enumerator proxy is disposed. This is typically a notification (it has no id property).

{
   "jsonrpc": "2.0",
   "method": "$/enumerator/dispose",
   "params": { "token": "enum-handle" },
}

enhancement

opened Aug 27, 2019 by AArnott 21

Closed

support new CancellationStrategy capability added to vscode-jsonrpc in StreamjsonRpc

recently new ability is added to vscode-jsonrpc to support custom cancellation mechanism to jsonrpc (https://github.com/microsoft/vscode-languageserver-node/commit/b1f6a443efad3d61cf83344589099dab5318ca66)

it was added since the current built-in cancellation mechanism assumes consumers can either run concurrently or asynchronously. any synchronous code can't use the existing cancellation mechanism to cancel ongoing request since, at the time, it checks cancellation request, work is already all done.

some of lsp implementation on the node has synchronous lsp implementation (such as typescript, python) so they need different cancellation mechanisms. for example, typescript uses this trick where it creates a cancellation file/pipe and uses the existence of the file/pipe to indicate whether the current request needed to be canceled. python needs yet another way to implement it since they don't want to customize vscode client for cancellation support as typescript did.

to support these various needs and constraints of each LSP implementation, a way to provide its own cancellation mechanism is added to vscode-jsonrpc.

now, we would like to share the same lsp node server with VS but without this custom cancellation mechanism support, we lose a way to cancel any request in VS.

wonder whether it is possible to support this new ability in StreamJsonRpc as well.

enhancement

opened Mar 27, 2020 by heejaechang 17

Closed

ETA for UWP support?

Is there an ETA for when this library might support UWP?

opened Mar 17, 2020 by Noemata 16

Closed

High lock contention in Roslyn DelimitedMessageHandler

From a discussion with @AArnott ,

I'm seeing super high CPU utilization in VS when we use StreamRPC to talk to our OOP server. ETW logs reveal this as the top exclusive problem:

I’m investigating some local traces that show high CPU usage in VS during OOP scenarios. The traces end up showing a large amount of time around locks and contention:

That’s 18% exclusive time in VS time just around these locking primitives. Looking into what calls this I can see the following:

And

opened May 9, 2017 by CyrusNajmabadi 14

Closed

Adding support for end-to-end activity tracing

When StreamJsonRpc is used to power microservices-based architectures, the need for rich (end-to-end) tracing and activity propagation, to enable better troubleshooting and monitoring becomes quite important. This has been an explicit focus in .NET/ASP.NET Core 3.0 and with the brand-new W3C Trace Context recommendation there's an opportunity to introduce this in StreamJsonRpc in a standards-compliant way.

The goal of a built-in activity tracing support would be to enable rich tracing that can correlate calls across multiple remote invocations. This could then be used, for example, in System.Diagnostics.TraceSource for TraceTransfer/Start/Stop which model activities, or EventSource.SetCurrentThreadActivityId to do activity-based logging in ETW traces, or the newer Activity in .NET Core that has built-in support for the W3C standard.

Currently, there doesn't seem to be any specific support for propagating activity identifiers across RPC calls (just a request identifier). One option would be to leverage the fact that the request id does not need to have a specific format and therefore could accomodate a proper W3C trace context.

Attempting to add this support from outside of StreamJsonRpc (in a spike) turned out to be very tricky/hacky and not very satisfactory, which is why I think it's best if this was supported built-in.

This support would allow tools that can properly correlate and visualize traces to provide improved diagnostics like the Service Trace Viewer in this sample screenshot from a spike:

enhancement

opened May 27, 2020 by kzu 13

Open

Touch up marshaled object docs

null

docs

opened Mar 13, 2023 by AArnott 0

Open

Version stabilization for 17. 6 release

opened Mar 9, 2023 by ankitvarmait 5

Open

Bump BenchmarkDotNet.Diagnostics.Windows from 0.13.2 to 0.13.5

Bumps BenchmarkDotNet.Diagnostics.Windows from 0.13.2 to 0.13.5.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

dependencies

opened Mar 1, 2023 by dependabot[bot] 0

Open

ConnectionLostException when invoking re-assigned Remote Targets

Version: 2.6.121 Caller: .NET 4.7.2

Exception:

JsonRpc Error: 10 : Exception thrown from request "68" for method syncElement: StreamJsonRpc.ConnectionLostException: The JSON-RPC connection with the remote party was lost before the request could complete. ---> System.OperationCanceledException: The operation was canceled.
   at System.Threading.CancellationToken.ThrowOperationCanceledException()
   at StreamJsonRpc.MessageHandlerBase.<WriteAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at StreamJsonRpc.JsonRpc.<TransmitAsync>d__159.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully()
   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__143.MoveNext()
   --- End of inner exception stack trace ---
   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__143.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at StreamJsonRpc.JsonRpc.<DispatchIncomingRequestAsync>d__147.MoveNext()
JsonRpc Error: 10 : StreamJsonRpc.ConnectionLostException: The JSON-RPC connection with the remote party was lost before the request could complete. ---> System.OperationCanceledException: The operation was canceled.
   at System.Threading.CancellationToken.ThrowOperationCanceledException()
   at StreamJsonRpc.MessageHandlerBase.<WriteAsync>d__23.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at StreamJsonRpc.JsonRpc.<TransmitAsync>d__159.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully()
   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__143.MoveNext()
   --- End of inner exception stack trace ---
   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__143.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at StreamJsonRpc.JsonRpc.<DispatchIncomingRequestAsync>d__147.MoveNext(), syncElement, 68, Newtonsoft.Json.Linq.JToken[]
JsonRpc Information: 8 : {"id":68,"error":{"code":-32000,"message":"The JSON-RPC connection with the remote party was lost before the request could complete."}}
JsonRpc Verbose: 8 : Sent: {
  "jsonrpc": "2.0",
  "id": 68,
  "error": {
    "data": {
      "type": "StreamJsonRpc.ConnectionLostException",
      "message": "The JSON-RPC connection with the remote party was lost before the request could complete.",
      "stack": "   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__143.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)\r\n   at StreamJsonRpc.JsonRpc.<DispatchIncomingRequestAsync>d__147.MoveNext()",
      "code": -2146233088,
      "inner": {
        "type": "System.OperationCanceledException",
        "message": "The operation was canceled.",
        "stack": "   at System.Threading.CancellationToken.ThrowOperationCanceledException()\r\n   at StreamJsonRpc.MessageHandlerBase.<WriteAsync>d__23.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at StreamJsonRpc.JsonRpc.<TransmitAsync>d__159.MoveNext()\r\n--- End of stack trace from previous location where exception was thrown ---\r\n   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)\r\n   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)\r\n   at System.Threading.Tasks.ValueTask.ThrowIfCompletedUnsuccessfully()\r\n   at StreamJsonRpc.JsonRpc.<InvokeCoreAsync>d__143.MoveNext()",
        "code": -2146233029,
        "inner": null
      }
    },
    "code": -32000,
    "message": "The JSON-RPC connection with the remote party was lost before the request could complete."
  }
}

Signature of the called method:

Remote 1 starts

Client 1 starts

Client 1 calls client1.Rpc.AddRemoteTarget(remote1)

Client 1 makes some calls to Remote 1.

.....

The Server closes the socket associated with Remote 1, disposes the Rpc.

Remote 2 starts, implementing the same targets.

Client 1 calls client1.Rpc.AddRemoteTarget(remote2)

Client 1 tries to make some calls to Remote 2. However, each call throws a ConnectionLostException whenever the server tries to call any remote method.

opened Jan 5, 2023 by pattontim 3

Open

Crash on IL emitting if "out" or "in" are used in method parameters

It seems in and out parameters are not supported. But they do cause a crash in application all in ProxyGeneration.CreateParameterObjectType , line proxyTypeBuilder.CreateTypeInfo();

opened Sep 30, 2022 by roozbehid-ic 0

Open

Error getting value from 'RequestId' on net6.0-ios app

Exception thrown while transmitting message: Newtonsoft.Json.JsonSerializationException: Error writing JSON RPC Message: JsonSerializationException: Error getting value from 'RequestId' on 'StreamJsonRpc.JsonMessageFormatter+JsonRpcError'.
 ---> Newtonsoft.Json.JsonSerializationException: Error getting value from 'RequestId' on 'StreamJsonRpc.JsonMessageFormatter+JsonRpcError'.
 ---> System.ExecutionEngineException: Attempting to JIT compile method '(wrapper delegate-invoke) StreamJsonRpc.RequestId <Module>:invoke_callvirt_RequestId_JsonRpcError (StreamJsonRpc.Protocol.JsonRpcError)' while running in aot-only mode. See https://docs.microsoft.com/xamarin/ios/internals/limitations for more information.

This only happens on AOT compiled Release builds of net6.0-ios. Debug builds don't have AOT compilation enabled, so I suspect this might have something to do with trimming/aot and reflection.

opened Sep 6, 2022 by mmoraga 8

v2.11.35(May 6, 2022)

Changes:

Fixes:

#781: AddLocalRpcTarget<IServerDerived> does not publish events in parent interface

Source code(tar.gz)
Source code(zip)

v2.11.32-alpha(May 6, 2022)

Changes:

Fixes:

#763: Fix activity tracing to track entire execution time of inbound calls
#761: Defend against mutable statics causing JSON serialization failures
#783: Honor user-provided Json IContractResolver while maintaining marshaling capabilities

Enhancements:

#760: Trim dependencies
#758: Add JsonRpcIgnoreAttribute to block RPC access to particular methods
#777: Add RPC marshaling support for custom interfaces

Others:

#770: Bump Microsoft.VisualStudio.Threading from 17.0.64 to 17.1.46

Source code(tar.gz)
Source code(zip)

v2.10.44(Mar 4, 2022)

Fixed

Handle FileNotFoundException thrown while deserializing exceptions by @rruizGit in https://github.com/microsoft/vs-streamjsonrpc/pull/773

Full Changelog: https://github.com/microsoft/vs-streamjsonrpc/compare/v2.10.41...v2.10.44

Source code(tar.gz)
Source code(zip)

v2.10.41(Feb 22, 2022)

Changes:

Fixes:

#630: CancellationToken no longer works on v2.6.121 when setting TypeNameHandling.Objects

Enhancements:

#737: Better handling of serializing exceptions
#733: Add ClientRequiresNamedArguments option for IProgress<T> notifications

Others:

#750: Bump System.IO.Pipelines from 6.0.0 to 6.0.1
#752: Add SendAsync virtual method to JsonRpc
#738: Discriminate dynamic proxy generated methods by argument type?
#734: Honor ClientRequiresNamedArguments when UseSingleObjectParameterDeserialization is set
#736: Honor [JsonConverter] attributes on properties of custom params objects
#735: JsonConverter on named params object properties ignored
#651: Suppress transmission of $type property in named arguments objects
#732: Update Nerdbank.Streams to 2.8.50
#726: Update several dependencies

This list of changes was auto generated.

Source code(tar.gz)
Source code(zip)

v2.9.85(Nov 9, 2021)

Changes:

Enhancements:

#667: Make interface IJsonRpcMessageWithId public
#698: Target netstandard2.1 instead of netcoreapp3.1
#694: Update MessagePack to 2.3.75
#686: Render named arguments in ETW events, including when using the MessagePack formatter
#690: Update Nerdbank.Streams to 2.8.46
#687: Update Newtonsoft.Json dependency to 13.0.1
#666: Omit line info handling

Others:

#717: Expose the IJsonRpcMessageWithId interface publicly

See More

#716: Fix testResults artifact collector when tests haven't run
#715: Bump System.Text.Encodings.Web from 4.5.1 to 5.0.1
#712: Force upgrade of vulnerable System.Text.Encodings.Web 4.5.0 to 4.5.1
#714: Add diagnostic logging to test runner
#713: Run tests on 64-bit processes
#707: Fix tracing regression
#706: Add ETW trace testing to pipeline
#697: Add support for top level properties and delegated dispatch
#699: Switch from XLF (back) to LCL
#696: Apply is null syntax pattern and analyzer
#693: Drop .NET Core 2.1 support
#652: AddLocalRpcTarget should honor base interfaces when T is an interface
#659: Adding automated compliance tools to the build pipeline.

This list of changes was auto generated.

Source code(tar.gz)
Source code(zip)

v2.8.28(Oct 4, 2021)

Revert #652, as this should have been saved for the v2.9 release.

Source code(tar.gz)
Source code(zip)

small package for reading pipe data

shesek-bitcoincore-rpc-json - a fork of bitcoincore-rpc-json with some minor changes

Test the browser request cancellation behavior.

C++ framework for json-rpc (json remote procedure call)

A RPC framework leveraging Spark RPC module

Validation Pipe and GraphQL validation filter for NestJS

websocket-lite - A fast, low-overhead WebSocket client

Turn any gRPC stream into a Go `net.Conn` implementation.

A simple proxy that forwards Websocket messages to Unix sockets and vice versa.

go websocket client for unit testing of a websocket handler

C++ websocket client/server library

Application for capturing, modifying and sending custom WebSocket data from client to server and vice versa.

JsonRpc - Easy and lightweight Json-Rpc Client/Server

Put your assets into the pipe and smoke them.

This opensource project is the local data request proxy. Written by TypeScript, is used to implement offline browsing of the app. The data proxy will be responsible for data request, creation, destruction and expiration detection. We only need to define the data model and leave the rest to the proxy!

RPC explained by writing simple RPC framework in 300 lines of pure Golang.

A websocket library for reason native

nanorpc - lightweight RPC in pure C++ 17

Run RPC over a MessagePort object from a Worker thread (or WebWorker)

JSON-RPC version 2 implement for express.js

a interceptor for OkHttp which can save failed request in storage and will retry request until success or retry times over limit , or request live time over limit

Share this repo

Related Repos

RPC framework

a netty-like TCP/IP communication framework for .net core, support both IOCP and Epoll

RPC framework

623

The StreamJsonRpc library offers JSON-RPC 2.0 over any .NET Stream, WebSocket, or Pipe. Wi...

RPC framework

Ocelot.GrpcHttpGateway

Ocelot.GrpcHttpGateway grpc service gateway used ocelot What functions does he have? load .dll files load proto files support header support unary,client streaming, server streaming, duplex streaming

RPC framework

Thrifty include interface based remote call, tsl support, load balancing, and automatic se...

Thrifty Project Thrifty.Net is a port of Swift（from facebook） for .Net , an attribute-based library for creating Thrift serializable types and services. you can write C# attributed object instead of IDL file and IDL generation c