Would Like: Guarantee Serialization of ValueTuples


#1

I can’t actually find the documentation page anymore but I’ve read that ValueTuples are not guaranteed to be serializable. I’d like to see that changed. I have encountered this:

Since we now can use the tuples to easily return multiple values from methods, they appear in public interfaces. If a server implementation would like to provide a tuple return value, and send back a DataContract XML envelope, to be deserialized by the client, the client would then be receiving the tuple to deserialize. It would be nice if this could “just work”.

Fwiw, if more detail is desired: I simply have a shared service interface:

public interface IMyService
{
    Task<(MyStatus, MyMethodResult)> Get();
}

… The client invokes the method to get the MyMethodResult object, and the service also gives it a little status. (The method is async Task and so cannot declare an out parameter.)

In my implementation I have a simple reflection invoker: on the server side is an implementation of the same service interface. The client service makes a DataContract envelope with the method name and an array of method arguments. It is serialized and sent to the server. The server deserializes the method name and argument array and invokes the named method on its own implementation. The result (after unwrapping a Task invocation) is the tuple. It would be stuck back into an envelope and serialized back to the client. (All of the method argument and return types are DataContract serializable.)

But I can’t work it this way because the ValueTuple is not guaranteed to serialize. It would be nice!

This client-service-server implementation is performed in a single method … Pass the method name and arguments, wrap and serialize to the server, deserialize and invoke, wrap and serialize the result back to the client. The service interface can change arbitrarily and both sides just implement the interface without any layer in between.


.NET Foundation Website | Blog | Projects | Code of Conduct