Where to Define Interfaces

Please see my comment to the question; the statement is not clear…

First of all, I hope that by LibA and LibB you mean the assemblies. Actually, every .NET assembly is a library, even if it is named *.EXE (in case you still did not get it); and there are cases when even *.EXE should be a referenced assembly. (This is not a very usual technique, but it is quite legitimate; I can explain why it can be used if you are really curious, but this topic is unrelated to the question.)

Then, you need to understand that there is no such thing as a miracle. If you use some interface, either for implementing it of for using objects by interface reference, you need to have it defined. It can be defined in your using assembly or in any referenced assembly. Of course, if two interfaces are textually identical but are defined in different assemblies, there are different interfaces and cannot be used interchangeably; besides, such definitions would violate the very fundamental DRY principle (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself[^]); so, let's forget such cases and assume that there is only one definition of each interface. By the way, loading assemblies dynamically during runtime changes the character of dependencies but not the facts stated above. This is all you need to know at the moment.

Now, let's follow the simple logic. Imaging you have some interface IMy used by both your assemblies. It means that is should be defined somewhere. Defining it in LibA will make LibB dependent of LibA and visa versa, as you correctly pointed out. In many cases, you really need this dependency. It all depends on the semantic of the assemblies. And yes, there are cases when none of these two assemblies should depend on the other one. In this case, applying the same principle "there is no such thing as a miracle", we come to the only remaining solution: IMy should be defined in another assembly, say, "Interfaces", and then both LibA and LibB assemblies should reference it. As simple as that.

I must note that all the logic is applicable to absolutely any kind of definition; there is nothing specific to interfaces. That said, you might miss the role of interfaces in the architecture of the code and the dependencies. You should do the following: think of interfaces, their implementation and uses without any concern about assemblies.
As to dependencies, please review these design patterns:
http://en.wikipedia.org/wiki/Dependency_injection[^],
http://en.wikipedia.org/wiki/Dependency_inversion_principle[^].

A really productive way of making the architecture is thinking on the dependencies of .NET types first, and when the picture is more or less clear, think about distribution of the code into different assemblies. Well, as a rule of thumb. This is because the dependencies between assemblies is the product of dependency relationships between type, not visa versa, and because the boundaries between .NET assemblies are very light-weight, from the standpoint of development process. In other words, if you move some code from one assembly to another, with corresponding removal and adding of the assembly references, it won't change the using and depending code even a bit.

—SA