Ambiguous Extension Methods can be generated.

[ristogod]

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.

[patrickklaeren]

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.

[ristogod]

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.

[TheBrambleShark]

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.