Passing interface argument in SF cross-service remoting call

[WhitWaldo]

I would ideally like to export a method such as the following on a service using the v2.1 serialization:

public async Task<MyObj> GetObject(IIdentifier ident, CancellationToken cancellationToken)

From within a service, I can pass concrete objects that implement IIdentifier without any issue at all. However, when calling that method from a separate service, it fails with the following exception:

Type 'X.Y.Z.MyIdentifierA with data contract name '...' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute or by adding them to the list of known types passed to DataContractSerializer.

My concrete implementation of MyIdentifierA looks like:

[DataContract(Name="MyIdentifierA", Namespace = "..."]
public class MyIdentifierA: IIdentifier 
{
  public MyIdentifier()  {}

  public MyIdentifierA(string ident)
  {
    Value = ident;
  }

  [IgnoreDataMember]
  public IdentityContext Context => IdentityContext.A;

  [DataMember]
  public string Value {get;set;
}

[DataContract(Name="IdentityContext", Namespace="..."]
public enum IdentityContext 
{
  [EnumMember(Value="A")]
  A,
  [EnumMember(Value="B")]
  B
}

Presumably this should serialize correctly. Per the documentation, the enumeration is marked with the appropriate attribute values, the class has an empty constructor and I'm not using generics here.

There aren't any complex types being referenced by the class, so I can't really put the [KnownTypes] at the top of MyIdentifierA, so I'm not really sure where the exception is suggesting I put that attribute.

I believe I could write a custom serializer that could handle this, but I'd rather not if I can help it.

The remoting documentation describes the remoting V2_1 stack as being compatible with the V1 stack (but there's really not much in this page that explains the differences between the two), but specifically indicates that this one is "interface compatible". If that's the case, what am I doing incorrectly here?

Thanks!

[JustinKaffenberger]

Hello, Service Fabric consumer here,

It's my understanding that all of the remoting uses DataContract serialization, which isn't even really a Service Fabric-specific technology. The problem you will run into is that your client knows about IIdentifier AND MyIdentifierA, while the Service Fabric service that is hosting the endpoint only knows about IIdentifier, and not the concrete type. At the end of the day, de-serialization has to be done to a concrete type, or some kind of runtime generated proxy type that implements IIdentifier. To my knowledge, while Service Fabric CAN generate the proxy client for your service, the individual parameters for your methods will not have proxy types generated for them.

My recommendation, and how we accomplish this at my company, is to define a base type, and use the KnownType attribute to support polymorphism. So, for example:

[DataContract]
[KnownType(typeof(MyIdentifierA)]
[KnownType(typeof(MyIdentifierB)]
// …
[KnownType(typeof(MyIdentifierZ)]
public class Identifier {
    //...
}

[DataContract]
public class MyIdentifierA : Identifier {
   // ...
}

Then, on the server side you can have logic like:

public async Task<MyObj> GetObject(Identifier ident, CancellationToken cancellationToken) {
    return ident
        {
            MyIdentifierA id => await DoStuffA(id),
            MyIdentifierB id => await DoStuffB(id),
            // ...
            MyIdentifierZ id => await DoStuffZ(id)
            _ => throw new InvalidOperationException()
        };
}

Hope this helps and gives you some ideas!

[WhitWaldo]

I'm sorry I never wrote back to you on this @JustinKaffenberger - thank you very much for the assist here!