Use struct as parameters and return value.

[Ilchert]

I am trying to create simple method with int parameter and it fails with System.Security.VerificationException: 'Method ProtoBuf.Grpc.Configuration.ServerBinder.AddMethod: type argument 'System.Int32' violates the constraint of type parameter 'TRequest'.' is it expected behavior? Should I wrap it to some request class? Are there any limitations to use struct as parameters? Will it be allowed in the future?

[mgravell]

Yes, I'm aware of the struct limitation, and yes the library should hide it from you automatically. So: yes, it is a bug and yes, I'll fix it.

This is a requirement in the underlying gRPC API, but there's no need for me not to hide it.

It was actually already on my list because protobuf-net v3 adds value-type implementations of Empty, Duration, Timestamp, etc. But: great to have it listed here to make sure I get it done.

[mgravell]

Just as an implementation note: what it'll actually do here will depend on the type; if the value-type being sent is a scalar, it'll treat it as though it were a message with a single field with field number 1, of the supplied type and value; if the value-type being sent is a message, it'll send the value as the root message, but in a way that makes gRPC happy.

[Ilchert]

Nice, thanks for the clarification!

[Sossenbinder]

I was just wondering about the progress on this issue - Did you manage to find time to do this as of yet?

[nilmas]

This enhancement would be very welcome.

[mgravell]

I'm wondering if we can fix this at the core API instead ^^^

[LMSDev]

@mgravell I recently came across your library (fantastic work, btw!) and encountered this type constraint. Additionally, I found gRPC's lack of support for multiple parameters discouraging, especially for simple method signatures. I understand the reasoning behind it, but it would still be nice to use them.

As a PoC I wrote a dynamic proxy that intercepts all calls with more than 1 argument (and where the second argument is not CancellationToken) and generates a new type with fields based on the arguments. This type is then serialized to byte[] using protobuf-net and passed to a more generic gRPC call along with the function name. The server uses the function name to locate the function signature and is able to also generate a type suitable for deserialization. The field values are then extracted from the deserialized type and passed to the original function (with multiple parameters), which happily does its work. Returning a value works exactly the same way.

Now I know that this would only work for protobuf-net.Grpc <--> protobuf-net.Grpc but I am wondering if you are interested in implementing a similar scheme. There is definitely a performance hit (a few ms, but did not optimize anything), so perhaps not well suited for high-performance scenarios, but for my use case the ability to call services with multiple parameters and no type constraints easily makes up for it.

[mgravell]

Definitely on the plan, and there's already one PR for similar. I don't think that PR fully works with some recent changes, and I have other ideas about perhaps "generators", but: yes, that's the plan. I have a plan, I just don't have unlimited time.

…

On Mon, 15 Feb 2021, 21:17 LMS, ***@***.***> wrote: @mgravell <https://github.com/mgravell> I recently came across your library (fantastic work, btw!) and encountered this type constraint. Additionally, I found gRPC's lack of support for multiple parameters discouraging, especially for simple method signatures. I understand the reasoning behind it, but it would still be nice to use them. As a PoC I wrote a dynamic proxy that intercepts all calls with more than 1 argument (and where the second argument is not CancellationToken) and generates a new type with fields based on the arguments. This type is then serialized to byte[] using protobuf-net and passed to a more generic gRPC call along with the function name. The server uses the function name to locate the function signature and is able to also generate a type suitable for deserialization. The field values are then extracted from the deserialized type and passed to the original function (with multiple parameters), which happily does its work. Returning a value works exactly the same way. Now I know that this would only work for protobuf-net.Grpc <--> protobuf-net.Grpc but I am wondering if you are interested in implementing a similar scheme. There is definitely a performance hit (a few ms, but did not optimize anything), so perhaps not well suited for high-performance scenarios, but for my use case the ability to call services with multiple parameters and no type constraints easily makes up for it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMAXM5B6OVDXTAAKPL3S7GFPDANCNFSM4JBIMSCA> .