There are 4 things to consider: separation of duties, importance, dependencies, and size.
Assemblies, folders/packages, classes, functions, blocks - they all have this in common.
A general rule for size of a given topic:
- >1 class = folder/subfolder.
- >5-10 classes = subfolders.
- >15-25 classes = assembly.
My belief is the purpose of the classes is more important than the size.
A real life example:
I wrote a very simple command line parsing library. This ended up being 3 classes in a "CommandLine" folder in a common library assembly... it wasn't that important and I used it in two related projects.
Then I gave the source of those classes to help someone with their project. Someone else saw it and suggested I add attribute support. I took the opportunity to refactor the code, add unit tests, and make it a much more advanced library. When doing this, I moved it to its own assembly so I could work on it independently over several nights and because of its size, importance, and re-usability outside of my common library.
Why is having many assemblies painful in .net? I would say deployment and creating new projects are marginally more difficult with more references.
Just add an existing project to your solution and a "project reference" to your projects that depend on it. Done.
I could see a compiled assembly reference being a burden by having to build, copy, and test in each solution but you have the source so just add the project to your solution.