Dynamic C# API Clients - Nested interfaces inheriting IRemoteService

[NecatiMeral]

Hi,

I'm experiencing a issue when using nested interfaces for application services.

Example:
Step 1: Create convenience interface for CRUD application services

public namespace Example 
{
    public interface IHierarchyCrudAppService<
                TEntityDto,
                in TKey,
                in TGetListInput,
                in TCreateInput,
                in TUpdateInput> 
            : ICrudAppService<
                TEntityDto,
                TKey,
                TGetListInput,
                TCreateInput,
                TUpdateInput>
        {
            Task<ListResultDto<TEntityDto>> FindChildrenAsync(TKey? parentId, bool recursive = false);
    
            Task MoveAsync(TKey id, TKey? newParentId);
        }
}

Step 2 (should be optional for repro): Create service implementation

Step 3: Try to initialize abp module with Dynamic C# API Clients.

Observation:
The module fails to initialize because it cannot assign the generic interface:

System.Reflection.TargetInvocationException

The type 'Volo.Abp.Http.Client.DynamicProxying.DynamicHttpProxyInterceptor1[Example.IHierarchyCrudAppService5[TEntityDto,TKey,TGetListInput,TCreateInput,TUpdateInput]]' is not assignable to service 'Volo.Abp.Http.Client.DynamicProxying.DynamicHttpProxyInterceptor`1'.

Workaround:
To continue my work, I've removed the convenience interface from my Application.Contracts project and directly added the interface signature to my application services / definitions.

Solution proposal:
I've located the source of this behavior at Volo.Abp.Http.Client > ServiceCollectionDynamicHttpClientProxyExtensions @ L48.

A solution can be a customizable type filter (as the todo says) or a negotiation interface, to explicitly exclude a interface, but not it's inherited interfaces.

[hikalkan]

I think we should ignore generic interfaces for application service interfaces.