DI component registration order

Current behavior in RegisterBus:

serviceRegister.RegisterDefaultServices();
registerServices(serviceRegister);

Also note this comment (which IS NOT true at least for Microsoft.Extensions.DependencyInjection):

I will explain the problem using Microsoft.Extensions.DependencyInjection as an example.

All Register methods use AddXXX (instead TryAddXXX). So the problems are:

1. If I register some EasyNetQ component inside IServiceCollection before RegisterEasyNetQ then RegisterDefaultServices appends new registration to list and it “overwrites” my one.
2. If I register EasyNetQ component after RegisterEasyNetQ then my registration wins (good!) but it contradicts aforementioned xmldoc comment. Besides, I still have doubled registrations in IServiceCollection.
3. There may be side effects when dependencies are injected as IEnumerable<IXXX>. Then both components will be used - one added by RegisterDefaultServices and one added by user delegate. To avoid this, you need to do some Replace call, but IServiceRegister does not provide such API as well as it does not provide the ability to check current registrations.

I believe that it is necessary to refactor the behavior responsible for DI.

1. Change IServiceRegister.Register behavior to TryRegister or provide additional methods, maybe extension methods to keep IServiceRegister thin.
2. Change implementation of DefaultServicesRegistration.RegisterDefaultServices to use TryRegister instead of Register.
3. Change registration order inside RabbitHutch.RegisterBus - move registerServices(serviceRegister); at the top.
4. Review all xml comments in classes responsible for DI to not to mislead users.

[zidad]

I mean this is from LibLog, for me that says it all:

LibLog is now deprecated (see #270).

My recommend course of action for library developers is to use Microsoft.Extensions.Logging.Abstractions as it is now the defacto standard logging interface in the .NET ecosystem.

I think it’s time to move on. EasyNetQ was written to serve a simple set of opinionated use cases, not to be a generic support-everything library. I feel that by using these abstractions it supports the .NET ecosystem the best in an opinionated way, while keeping the library as simple as possible.

I’ve not seen any modern .NET core application that didn’t reference Microsoft.Extensions.DependencyInjection.Abstractions or Microsoft.Extensions.Logging.Abstractions via some dependency.

[sungam3r]

Well, today I came across a bug where an extra connection to RabbitMQ was created. After an hour of investigating, I realized that the problem was caused by the creation of two bus instances with PersistentConnection inside. First - RabbitAdvancedBus from default registration, second - my MyBus class registered via RegisterEasyNetQ:

.RegisterEasyNetQ("host=localhost:5672;virtualhost=test", reg =>
                {
                    reg.Register<IAdvancedBus, MyBus>(); //  public class MyBus : RabbitAdvancedBus
                })

My use case is service warmup when objects are instantiated from the DI container. In my case, there are two implementations associated with the IAdvancedBus interface due to the fact that the Register method adds registration instead of a replacing it. I believe this confirms the existence of the problem. I’m going to do PR soon.