IceRpc, useful for calls like Into<ClientConnection>
IceRpc.Extensions.DependencyInjection, which makes our ServiceCollection extension methods visible
IceRpc.Builder with IInvokerBuilder and IDispatcherBuilder and some extension methods for those
In #3122, Jose moved most (but not all) IInvokerBuilder and IDispatcherBuilder extension methods from IceRpc.Builder to IceRpc.Extensions.DependencyInjection. That's fine but it doesn't go far enough. We don't need this IceRpc.Builder namespace: IInvokerBuilder and IDispatcherBuilder should go into IceRpc.Extensions.DependencyInjection.
With this setup:
DI-container agnostic DI abstractions / extension methods are in namespace IceRpc.Extensions.DependencyInjection and in assemblies IceRpc.dll, IceRpc.Logger.dll etc.
MS DI-container-specific extension methods are in the same namespace but in assembly IceRpc.Extensions.DependencyInjection.dll
This could be slightly confusing but I think that's fine. It's all about DI.
With #3117, we need 3 namespaces when using DI:
IceRpc
, useful for calls likeInto<ClientConnection>
IceRpc.Extensions.DependencyInjection
, which makes our ServiceCollection extension methods visibleIceRpc.Builder
with IInvokerBuilder and IDispatcherBuilder and some extension methods for thoseIn #3122, Jose moved most (but not all) IInvokerBuilder and IDispatcherBuilder extension methods from
IceRpc.Builder
toIceRpc.Extensions.DependencyInjection
. That's fine but it doesn't go far enough. We don't need this IceRpc.Builder namespace:IInvokerBuilder
andIDispatcherBuilder
should go intoIceRpc.Extensions.DependencyInjection
.With this setup:
This could be slightly confusing but I think that's fine. It's all about DI.