tylerjensen/ServiceWire

Cannot call a dotnetcore service from a donetframework client

Kryptos-FR opened this issue · 3 comments

I was playing around the demo host/client and I noticed that it fails to call methods if the server and client don't run on the same runtime. It fails when trying to match the types because the qualified names are different:

  • Int32, System.Private.CorLib vs Int32, mscorlib
  • Same with Task

However, if I hijacked the running code on the client to remove the assembly qualification, it works fine. Given that the purpose of the library is to be able to serialize primitive types, do you think that scenario should be allowed? If so, we might either need to not qualify the type, or add an alias for types from the core library.

Feel free to submit a PR. I would want to create a comprehensive map to be sure of it and then make it optional to avoid the overhead for those who are in the majority and using either Framework or Core on both ends. This issue is why I introduced a serializer injection mechanism. You can inject a JSON serializer or even a protocol buffers serializer. You may need to use attributes on your data message classes. See ISerializer.cs.

Tests would need to be written to assure that the BinaryFormatter would serialize and deserialized all supported types across the framework/core boundary. Even then I would make this an alternate serializer implementation to avoid breaking or slowing down the default.

Thanks for the quick reply.

That makes a lot of sense. Making a custom serializer that supports a user-provided mapping seems to be the most sensible way.

Depending on time, I will investigate further and try to create a PR.

Closed as I do not think there is a way to resolve this using the binary serializer.