However, as any discerning component makers will notice, using friend assemblies will produce tight coupling between interface and its implementors, as you have to specify what specific assembly can be a friend of your assembly. What will happen if there's another ORM vendor who wanted to implement your repository interface? if you used friend assemblies that would entail on your part to recompile repository interface to enable new vendor(s) on implementing your repository interface, which is a complicated routine to do so, entails coordination too. So we must not use friend assemblies, don't use InternalsVisibleTo. The only case that InternalsVisibleTo makes sense is when you don't want anyone to inherit functionalities from your components.

On a bit related note, though it's a bit of disappointment that wildcard on InternalsVisibleTo is not allowed, I think it's a good decision on Microsoft part, politically-wise you don't want to implement someone's interface and at the same time you must rigidly follow their assembly's name just for you to able to use their constants and extension methods sauce, isn't it?

So, the easiest way is just make things public, so those constants and helpers will be available to any vendors who wanted to implement your components. But as most of us wanted to avoid, we don't want components that pollutes the base library types with extension methods that are very domain-specific or has very localized uses only.

However, making things public is the first step to the solution, the last step is to put those RepositoryConstants and Helpers to their own namespace. That way, those constants won't be accidentally exposed to the end-user devs, and those extension methods won't be accidentally polluting the base library types. Alleviating your worries and/or frustrations on non-conforming citizen components.

Then on end-user devs, the following will be the typical code they will write. Notice that on end-user devs side, typically, they will not have a need to use the namespace Ienablemuch.ToTheEfnhX.ForImplementorsOnly, the constants will not be accidentally leaked to end-user devs, and extension methods will not pollute the base library types then. Though we cannot enforce end-user devs from using the namespace ForImplementorsOnly, at least it would take a conscious effort on their part if they wish to do so.