UsingRegistrationStrategy -> RegistrationStrategy.Skip - Ability to skip if the implementation exists

[DavidRooney]

I am looking to implement a TryAddTransient solution but for scanning multiple interfaces. Currently my code will either add duplicates or I have a workaround which replaces the existing ones. What I really want is for the code to identify that the interfaces AND the implementations already exist so do nothing.

I'm a BDD kind of dev so here's the scenario:

Given I want to implement a strategy pattern with many classes implementing the same interface When I hit the Scan code more than once Then it will not add duplicates or replace existing services in the container

Current behaviour: The skip functionality will perform a TryAdd which only appears to check the service. So when Scanning it will only add one implementation of that service rather than all the strategies.

Work around: Use .UsingRegistrationStrategy(RegistrationStrategy.Replace(ReplacementBehavior.ImplementationType)). But this will remove and replace those implementations with isn't specifically what I need

The code I wish I had: .UsingRegistrationStrategy(RegistrationStrategy.Skip(SkipBehavior.ImplementationType)).

[khellang]

Hey @DavidRooney! 👋🏻

Sounds reasonable. I'd probably take a PR for this if you're up for it 😄

[khellang]

BTW, the RegistrationStrategy class is public, so you're free to extend this however you want, without having an "official" solution.

[DavidRooney]

I never got any notifications for your replies! When (if) I can find some time then I'll try and get a PR together for this thanks

[sirphilliptubell]

I need a similar feature. In our applications we have a composition root in each library, and sometimes a shared dependency library has it's composition root called multiple times by different dependent libraries. In general it works fine for us to use the Skip strategy, however there are cases where we need the equivalent of TryAddEnumerable() to register multiple implementations (but only once if the composition root is used multiple times.)

I propose a Distinct strategy that is similar to Skip but also compares the implementation.

196

However I think this brings up the question about when people use Scrutor - either before or after adding other dependencies. If Scrutor is used afterwards, it's not aware of the actual implementation type when doing a Replace or Distinct registration strategy since the registration could have been through an instance or factory instead. I think we could re-implement the existing GetImplementationType() to be able to check this as well. Since two instance/factory registrations can be the same, we'll need a Replace strategy that compares both the service and implementation types as well.

197