patrickklaeren
Ambiguous Extension Methods can be generated.
We have some projects named as such, within the same solution (yes I understand it's not ideal, but it's an established naming practice outside my control with a purpose irrelevant to the issue).
Account.Web.Api
Account.WebApi
Both these projects are creating an extension method named AutoRegisterAccountWebApi, which is then being detected as ambiguous.
This is product of ARI being opinionated. I don't see a way around this other than introducing a breaking change to ARI itself, and even then, it's not a direction I'd like to head.
I'm not 100% certain of the impact here yet, I have to replicate the problem.
I suspect a simple workaround would be to create your own (extension) method and call this from the consumer.
Ok, I wasn't sure whether there might be a clean way to allow the consumer to specify the extension method name as an override to convention.
Cleanest way here may be to add an assembly attribute to the library (name suggestions welcome).
[assembly:AutoRegisterInjectLibraryName("AccountApi")] // Or some name that makes sense
Which would then be mapped to the extension method.
services.AutoRegisterAccountApi();
This way there doesn't need to be any sort of complex logic to try and produce a best guess of what API naming should be - in case of conflicts, let the human figure it out.
