What is the best practice when exposing classes from a library consisting of several assemblies?

Question

I am in the process of creating a library which should be consumed by different applications. Those applications should not see the implementation details of the library but just be presented with a well usable interface.

To get a clear project structure I have created several projects in my solution. Some projects only contain code which should not be visible to the outside world because it should only be used internally. However, this code needs to be accessible across project boundaries.

To solve this, I created several internal classes and methods and then marked their assemblies with the InternalsVisibleTo attribute in my AssemblyInfo.cs. This works as expected.

However, I am wondering whether this is really good practice. After all, I am circumventing the internal access modifier which might confuse other developers.

The only other option I have would be to create only one project which must then contain all the internal code marked as internal. However, I dislike this solution as it will mean that I have no clear overview of dependencies in my code anymore.

What is the best practice in this situation?

Answer 1

Hmm, this seems a subjective question, but I would say InternalsVisibleTo primarily exists for unit testing. I would say it's probably not best practices to set up your projects in such a way, and probably points to an underlying problem. Either you aren't making things public that would be no harm to make public, or your dependencies aren't really dependencies, they are monolithic code that should probably be in the same place.

You can read here about friend assemblies. The primary use case is unit testing.