Remove the necessity to couple a service interface to IService to use remoting transport
Currently, in order to use remoting transport, a service interface must inherit from IService marker. like so:
public interface MyService : IService
Instead, if a marker must be used, could it be defined differently, like so for instance:
public interface IService<T>
This way, IMyService would NOT have to inherit from IService, but a service class could be defined like so:
public sealed MyService : IService<IMyService>, IMyService
Of course, for backward compatibility, the generics marker does not have to be called IService, but IService2, for example.
Overall, regardless of implementation, it would be great not to need to couple a service interface to Service Fabric libraries.
Great! Thank you
Peter Bons commented
You already do not need to do this. You can use CreateNonIServiceProxy which accepts an interfave that is not inherited from IService, see https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicefabric.services.remoting.client.serviceproxyfactory.createnoniserviceproxy?view=azure-dotnet